perl-Upgrade unter FreeBSD

Samstag, 18. September 2010

Ganz egal ob es sich um ein major upgrade handelt, also von perl-5.8 auf 5.10 oder 5.12 oder ein minor update, wie zum Beispiel 5.12.1 auf 5.12.2, eine solche Aktualisierung ist je nach Umfang der Installation immer mit Vorsicht vorzunehmen. Aber im Gegensatz zu den ganzen binary package weenies, kann man ueberhaupt nach Belieben updaten, wann und auf welche (major) Version man will.

Es gibt zwar ein Script namens perl-after-upgrade, aber das behandelt nur einen Teil der moeglichen Abhaengigkeiten.

In /usr/ports/UPDATING wird auch immer wieder vorgeschlagen, man moege einfach stur alles rebuilden, zum Beispiel mit portmaster perl-. Ich halte davon ueberhaupt nichts, denn erstens rebuildet es perl selbst noch ein mal (ja, das kann man umgehen), zweitens rebuildet es ports, die perl-after-upgrade bereits ordentlich behandelt hat, man verliert also Zeit und drittens "merkt" sich der Prozess nicht, was bereits erledigt wurde, um im Falle eines Abbruchs und Wiederaufnahme der Prozedur nicht von vorne anfangen zu muessen, was schon wieder enorm Zeit kosten kann.

Darum behelfe ich mir mit folgendem simplen Script, das ich direkt nach dem portupgrade von perl ausfuehre (ports-mgmt/portupgrade muss installiert sein, wegen pkg_which):

#!/bin/sh

perl-after-upgrade

OLDVERSION=5.12.1

find /usr/local/lib/perl5/${OLDVERSION} /usr/local/lib/perl5/site_perl/${OLDVERSION} | xargs pkg_which | sort -u | fgrep -v \? > /root/perl-${OLDVERSION}.ports

Das Ergebnis kann man dann direkt einem portupgrade -f oder portmaster zum Frass vorwerfen, also zum Beispiel: portmaster `cat /root/perl-5.12.1.ports`

Wenn man das Script danach noch einmal ausfuehrt, sollte die Ausgabedatei leer sein. Jetzt sollte man unbedingt in den alten perl-Verzeichnissen nach Files suchen, die man haendisch installiert hat, bei mir ist das zum Beispiel /usr/local/lib/perl5/site_perl/5.12.2/Mail/SpamAssassin/Plugin/ocrtext.pm, diese Datei muss man dann eben von Hand umkopieren. Wenn man sich sicher ist, alles erledigt zu haben, sollte man sich der Verzeichnisse der alten Version mit rm -rf entledigen, so sieht man auch gleich, dass hier ein "sauberes" Upgrade gemacht wurde.

Ein Problem erkennt obiges Script nicht: Binaries, die gegen libperl.so gelinkt sind und keine Files in /usr/local/lib/perl5 hinterlassen, werden nicht aktualisiert. Solche Probleme erkenne ich mit Hilfe von libchk. irc/epic5 ist zum Beispiel so ein Kandidat. Wer aber den Output von perl-after-upgrade genau liest, wird ebenfalls auf dieses Problem hingewiesen.



IPv6 I

Samstag, 10. Juli 2010

CameloT beschaeftigt sich erst seit 2010 mit dem Thema IPv6 in der Praxis.

Eins scheint klar: Es ist jetzt genau der richtige Zeitpunkt um bei v6 einzusteigen. Moeglicherweise wird in 371 Tagen der IPv4-Adressraum aufgebraucht sein. So sieht es jedenfalls Hurricane Electric voraus.

Was das genau bedeutet, kann derzeit niemand vorhersagen.

Natuerlich bricht das Internet nicht an diesem Tag zusammen. Aber es wird mittelfristig einschneidende Auswirkungen auf die Vergabe-Policy haben, die daraufhin jeden Enduser treffen werden.

Wer Lust hat, bei IPv6 mitzumachen, kann sich bei Hurricane Electric eine Art Zertifikat besorgen. Damit kann man darlegen, wie weit man mit IPv6 vertraut ist.

Zu dem Zeitpunkt an dem ich dies schreibe bin ich "Enthusiast", aber ich versuche meinen Status weter zu steigern. Nun bin ich schon "Administrator", weil ich E-Mail ueber v6 empfangen kann. Und weil mein Mailserver natuerlich einen Reverse-DNS-Record besitzt, werde ich "Professional". Und weil meine DNS-Server bereits ueber v6 erreichbar sind, werde ich "Guru Questionnaire".

IPv6 Certification Badge for knarf

Aber zur hoechsten Stufe fehlt mir noch ein v6-Glue-Record in einer meiner Domains. Insgesamt wird das ein gutes Stueck Arbeit, weil jede Top-Level-Domain gewiss seine eigenen Prozeduren fuer diesen Vorfall haben wird. Derzeit sind nur 81% der TLDs v6-ready und es existieren gerade mal 2.767 v6-Glue-Records. Das ist insofern nicht bedrohlich, weil dieser Schritt nur dann unbedingt notwendig ist, wenn ueberhaupt keine v4-Connectity mehr verfuegbar ist.

Nun ist die Aufgabe, sicherzustellen, dass die Anforderungen fuer alle administrierten Domains und Netzwerke erfuellt sind. Dazu zaehlt auch jedes Heimnetzwerk. Jeder kann und sollte mitmachen. Es ist meist einfacher als man denkt.

v4 ganz aus dem LAN zu verbannen erscheint derzeit eher schwierig bis unmoeglich. Mein Drucker und mein SIP-Device koennen ueberhaupt kein v6.

FreeBSD 8.0-RELEASE ist da - jetzt aber wirklich!

Freitag, 27. November 2009

Nachdem die Meldung verfrueht schon bei Heise und Golem zu lesen war, was zu diverser Kritik fuehrte, nun auch hier: Vor etwa 24 Stunden wurde FreeBSD 8.0-RELEASE offiziell veroeffentlicht.

Fuer die Ungeduldigen gibt es die Highlights, fuer die Interessierten mit etwas Zeit zum Lesen: Die kompletten Release Notes. Darin sind auch die Aenderungen gegenueber 7.1 und 7.2 zu finden.

FreeBSD 8.0 macht Spass. Ich habe die letzten Tage, seit dem 8.0-RELEASE im cvs tree getagt war, damit verbracht die Maschinen in meinem Umfeld auf 8.0-RELEASE zu bringen. Zuerst die, die zum Test in einer voellig unwichtigen VMWare irgendwo rumduempelten, teilweise mit einem ueppig installierten ports-tree, um auch das Verhalten von den anstehenden portupgrade -f Massenaufrufen beurteilen zu koennen. Aber da war nichts.

Der eben erst aufgesetzte Kundenserver mit 8.0-RC3 machte das Update erwartungsgemaess problemlos mit.

Fuer den speziellen Fall, dass jemand lagg(4) zusammen mit em(4) verwendet: Es funktioniert nicht. Ich musste die schoenen Intel-Karten echt gegen Realtek-Schrott austauschen und schon war wieder alles beim alten. Der FreeBSD-Intel-Treiber wird von Intel persoenlich entwickelt. So aendern sich die Zeiten. Dranbleiben. Das muss eigentlich sofort in die ERRATA.

Fuer AMD-Xen-User: Das noetige Tuneable fuer AMD-Xens heisst hw.clflush_disable=1.

Spannend finde ich die Tatsache, dass die Verteilung des Interesses von i386 (32bit) und amd64 (64bit) im FreeBSD Torrent Tracker gleich verteilt erscheint.

Die aelteren unter uns mag interessieren, dass COM1: jetzt /dev/cuau0 heisst. Die Zeiten von mgetty, uucico und pppd sind leider lange vorbei. Wir haben jetzt uart(4) statt sio(4). Ob man nun einen 16550 oder einen 16550A hat, interessiert lange keinen mehr. Ich verwende tatsaechlich noch den apcupsd ueber die Serielle.

FreeBSD 8.0 ist das erste FreeBSD in dem der ZFS-Support nicht mehr als experimental gekennzeichnet ist (quasi seit dem Import von zfsv13). Ich habe ZFS in v6 mit unterdimensionierter Hardware (i386, wenig RAM, bisschen Gefummel an den tuneables) getestet und habe nicht zuletzt durch nicht ganz gewolltes Fehlverhalten ein desastroeses Ergebnis produzieren koennen. Seit v13 habe ich zwei amd64-Maschinen mit ausreichend RAM (8 und 16 GByte) mit zfs im Einsatz und es macht seit Wochen im Produktivbetrieb keinerlei Aerger. Snapshots werden intensiv genutzt: zfs-snapshot-mgmt ist ein toller port, aber auch das gute alte freebsd-snapshot laesst sich problemlos parallel einsetzen. Ohne wenigstens eines der beiden moechte ich am liebsten kein Unix-System mehr betreuen, anstaendig konfigurierte Snapshots (mit mount via amd, ich sage nur cd /snap/home:daily.0) sind echt ein Segen.

Da ja nun fdisk und mbr bald (also in ein paar Jahren oder so) ausgedient haben werden, ist dies nun auch der richtige Zeitpunkt, um sich mit gpt auseinanderzusetzen. Vor dreieinhalb Jahren kam ich mit meinem 2.4TiB 3ware-RAID5 zum ersten mal in die Verlegenheit. Da hiess das FreeBSD-Kommando noch gpt(8). Nun ist es gpart(8). Es wird die Zeit kommen in der man regelmaessig Festplatten mit >2TiB in den Haenden hat.

Ganz aktuell gibt es eine schoene Anleitung um FreeBSD mit gpt, zfsroot und ganz ohne ufs-Partition zu installieren: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot

Die ganze Aktion ist gewiss nichts fuer Leute mit einer Kommandozeilenaversion. Es bleibt abzuwarten wie lange es benoetigt, bis der aufgezeigte Pfad seinen Weg in sysinstall findet. Ich habe die Schritte nachvollzogen und habe nun in einer weiteren VMWare-Instanz ein GPT-ZFS-only-FreeBSD-8.0-RELEASE. Diese Installationsmethode koennte ich problemlos auf einem Hetzner-Server mit Hilfe des FreeBSD-Rescue-Systems durchfuehren. Bei 1&1 bleibt immer noch nur die Holzhammermethode: VMWare-Minimal-Disk-Image via ssh | dd auf die Platte schreiben und hoffen, dass es von der hoffentlich korrekt konfigurierten Seriell-Console bootet. Das mbrlabel kann man unter FreeBSD problemlos mit fdisk(8) auf die tatsaechliche Groesse aendern. Dass das auch mit gpart(8) geht, ist anzunehmen, aber mir liegen hierzu keine Erfahrungen vor...