Kaum installiert, schon wieder veraltet? Ein FreeBSD-Upgrade ist nicht schwer, vorausgesetzt, man lässt sich vom kleinen Dämonen nicht ins Bockshorn jagen. Mit frisch aktualisierter Software gehen die ersten Schritte auf dem etwas anderen freien Betriebssystem gleich viel leichter von der Hand.

Über den Tellerrand zu schauen – dieses Motto des letzten “Answer Girls” [1] stieß den Leser-Zuschriften zufolge auf ein ausgesprochen positives Echo. So raffen wir uns in dieser Ausgabe dazu auf, das installierte FreeBSD-System ein wenig näher zu inspizieren. Mittlerweile halten die diversen Mirror bereits Version 4.7 bereit, so dass die denn auch die Grundlage dieses Artikels bildet. Doch zu diesem Zweck müssen wir erst einmal updaten.

Erstmal ein Upgrade

Ein Binär-Upgrade von der Vorgängerversion 4.6 ist recht leicht über das schon von der Installation her bekannte Tool /stand/sysinstall möglich (Abbildung 1). Als root von der Kommandozeile aufgerufen, wählen wir darin den Punkt Upgrade aus und bestätigen, dass wir uns über Risiken und Nebenwirkungen im Klaren ist. Wen jetzt doch noch die Panik überfällt, bricht das sysinstall-Programm mit [Strg-C] und anschließender Auswahl des Menüpunktes Abort ab.

Das tun wir an dieser Stelle tatsächlich, um uns die leidvolle Erfahrung zu ersparen, dass zwar massenweise Daten auf die Festplatte geschaufelt werden, am Ende aber doch keine Version 4.7 zur Verfügung steht. Der gar nicht so leicht zu findende Grund: sysinstall “weiß” ohne aktiven Eingriff der Installateurin weder, dass es eine neue Version gibt, noch dass sich das Upgrade-Begehren darauf bezieht. Stattdessen aktualisiert die Auswahl des Punktes Upgrade immer die derzeit eingestellte Version; bei einer FreeBSD-4.6-Installation also diese “mit sich selbst”. Das ist auch sinnvoll, denn schließlich fallen immer wieder mal Security-Updates an, ohne dass an der FreeBSD-Versionsnummer gedreht wird.

Doch wie erfährt sysinstall, dass nicht das Update der aktuell installierten Version, sondern ein Upgrade auf die neue 4.7 auf dem Plan steht? Gut versteckt, nämlich im Menü Configure gibt es einen Punkt

Options  View/Set various installation options

Wählen wir diesen aus, so erscheint der Options Editor (Abbildung 2), in dem der Wert des Parameters Release Name zur Debatte steht: Für ein Upgrade von 4.6 auf 4.7 muss der String 4.6-RELEASE in 4.7-RELEASE geändert werden. Zu diesem Zweck geht root mit der Pfeiltaste nach unten auf die entsprechende Zeile und drückt die [Leer]-Taste. Dies bringt ein Zeileneditor-Fensterchen namens Value Required (Abbildung 2) auf den Plan, in dem wir den Wert korrigieren und anschließend mit [Enter] bestätigen. Ein [q] und die Wahl des Punktes

X Exit            Exit this menu (returning to previous)

bringt die Installateurin zurück zum Hauptmenü, von wo aus sie einen erneuten Upgrade-Versuch startet.

Neuer Anlauf

Die erste echte Entscheidung gilt es nun zu treffen, wenn die Frage nach der upzudatenden Distribution aufkommt: Wer sich bei der Installation für das umfassende X-Kern-Developer-Set entschieden hat, sollte das an dieser Stelle wieder tun. Auch die Frage, ob die Ports-Kollektion installiert werden soll, bestätigen wir und wählen anschließend den Menüpunkt Exit.

sysinstall informiert nun darüber, dass in /usr/src installierte Quellcode-Pakete beim beabsichtigten Binär-Update nicht auf den neuesten Stand gebracht werden, und erfragt, wohin es ein Backup des Konfigurationsverzeichnisses /etc ablegen soll (Abbildung 3). Nach dem Upgrade spielt sysinstall die dortigen Daten wieder an ihren alten Platz zurück, so dass sich das System anschließend wieder individuell konfiguriert präsentiert. Die neuinstallierten Konfigfiles liegen zum Vergleichen (etwa mit dem sehr nützlichen Kommandozeilentool sdiff) in /etc/upgrade vor. Auch der alte Kernel wird für den Fall, dass das Upgrade schief geht, unter /kernel.prev gesichert.

Abbildung 1: Bevor man “Upgrade” wählt, sollte man zwingend dem Punkt “Configure” einen Besuch abstatten

Abbildung 2: Nur wer den Versionsnamen anpasst, kann auf eine neue Version upgraden

Abbildung 3: Solange der Platz in /var/tmp reicht, ist dies ein guter Ort für ein Backup der Systemkonfigurationsdateien

Soll das Update von einem Datenträger-Set oder vom Netz installiert werden? Wenn letzteres der Fall ist, gilt es, einen passenden Server möglichst in der Nähe auszuwählen. Zu Redaktionsschluss hatte von den deutschen Servern nur ftp://ftp7.de.FreeBSD.org die neue Version 4.7 auf Lager, inzwischen dürften auch die anderen Mirrors nachgezogen haben. Eine kurze Abfrage, ob das Netzwerk konfiguriert ist, und schon geht’s los …

Nach dem eher unspektakulären Ende der Installation beenden wir sysinstall über die Schaltfläche [X Exit Install] (Abbildung 1) und landen kommentarlos wieder in der root-Shell. Zum Starten des neuen Kernels muss jetzt nur noch ein Reboot her (auch hier funktioniert der von Linux bekannte “Affengriff” [Strg-Alt-Entf]), und der kann sich als tückisch erweisen, wie Kasten 1 zeigt.

Unable to load kernel:
Aborted!

Type '?' for a list of commands, 'help' for more detailed help.
ok

boot    boot a file or loaded kernel
load    load a kernel or module

can't load 'kernel'
can't load 'kernel.old'
no bootable kernel

ok load kernel.prev
/kernel.prev text=0x2c6f35 data=0x46db4+0x3dea0 syms=[0x4+0x3d820+0x4+0x43e32]
ok

# ls -l /kernel*
-r-xr-xr-x  1 root  wheel  4028952 Oct  9 17:08 /kernel.GENERIC
-r-xr-xr-x  1 root  wheel  3773566 Oct 11 16:49 /kernel.prev

cd /
ln -s kernel.GENERIC kernel
ln -s kernel.prev kernel.old

$ uname -a
FreeBSD testmaskin.linuxnewmedia.de 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Wed Oct
 9 15:08:34 GMT 2002     root@builder.freebsdmall.com:/usr/obj/usr/src/sys/GENERIC  i386

Am Steuer nicht zugelassen

Doch bereits beim Versuch, für den Aufruf von /stand/sysinstallroot zu werden, lauert die erste Falle: Wer sich pflichtbewusst als unprivilegierter User angemeldet hat und nun mit su versucht, root-Rechte zu erlangen, landet auf dem Bauch:

su: you are not in the correct group (wheel) to su root.

Nur, diejenigen, die “am Steuer sitzen” dürfen (auf Englisch “to be at the wheel”), haben die Vollmacht, root zu werden. Als Systemadministratorin lohnt es sich also, den eigenen Arbeitsaccount in die Gruppe wheel aufzunehmen. Das geht zum Glück so wie unter Linux auch, indem root die Datei /etc/group modifiziert: Gleich in der ersten, nicht auskommentierten Zeile …

wheel?:0:root

steht, dass bislang nur root Mitglied dieser Gruppe mit der Gruppen-ID 0 ist. Soll die Benutzerin pjung ebenfalls aufgenommen werden, hängt root sie einfach durch Komma getrennt an die bisherige Mitgliederliste an:

wheel?:0:root,pjung

Editieren, aber wie?

… was einfacher gesagt als getan ist: Wer nicht bereits bei der Installation darauf geachtet hat, den Lieblings- (oder zumindest einen bekannten) Editor zu installieren, hat unter Umständen ein Problem. Aber halt! Bekamen wir nicht von sysinstall bereits bei der Installation einen Texteditor zum Ändern von Dateien an die Hand? Dieser ist unter dem Namen ee auch jetzt noch zugänglich.

Netterweise zeigt der auf den Aufruf ee /etc/group hin oberhalb der gestrichelten Trennlinie eine kleine Kommandoübersicht: Das ^ symbolisiert dabei die [Strg]-Taste. So ruft [Esc] oder [Strg]-[AltGr]-[8] (also [Strg-[]) auf einer deutsch belegten Tastatur das in Abbildung 4 gezeigte Menü auf den Plan, in dem sich mit den Pfeiltasten nach oben und unten manövrieren sowie mit [Enter] auswählen lässt – schneller geht es durch Eintippen des vor der Klammer stehenden Buchstabens. Zum Abspeichern der unterhalb der Trennlinie veränderten Daten dient also die Anwahl des Eintrags a) leave editor im main menu und a) save changes im leave menu .

Am Anfang der Strichellinie zeigt ee immer den Standort des Cursors an: In Abbildung 4 steht er auf dem ersten Zeichen (“Character”) in Zeile (“Line”) 3.

Abbildung 4: ee bei der Bearbeitung von /etc/groups

Wo sind die Befehle?

Ein bisschen hier geschaut, ein bisschen dort – wer bislang unter Linux die Bash als Kommandozeilen-Shell gewohnt war, flucht unter FreeBSD erst einmal, wenn die gewohnte zweimalige Betätigung der [Tab]-Taste keineswegs alle an dieser Stelle möglichen Datei- oder Programmnamen auflistet. Nur ein einmaliges [Tab], sofern bereits ein eindeutiger Namensanfang in der Shell steht, sorgt bei root für eine vernünftige Dateinamenserweiterung. Die unprivilegierte Benutzerin pjung malt hingegen fleißig Tabulatorzeichen auf die Kommandozeile.

Der Grund ist mit einem Blick in die Passwortdatei /etc/passwd leicht zu ersehen:

root?:0:0:Charlie &:/root:/bin/csh
[…]
pjung?:1002:1003:Patricia Jung:/home/pjung:/bin/sh

Weder root noch pjung haben die Bash als Login-Shell; letztere Benutzerin vor allem deshalb nicht, weil sysinstall beim Anlegen neuer User im Menüpunkt Configure / User Management / User einfach keine Möglichkeit bietet, Login-Shells auszuwählen, deren Pfad man nicht kennt (Abbildung 5).

Abbildung 5: Anlegen neuer User mit sysinstall

Dieses Problem haben wir auch, wenn wir den Shell-Eintrag in der /etc/passwd verändern wollen. Ein Tool sollte uns jedoch zur Seite stehen, wenn wir nach der ausführbaren Datei bash fahnden. Sein Name: locate. Dumm nur, dass locate bash das System zu folgender Ausrede veranlasst:

locate: database too small: /var/db/locate.database

Ein Blick auf die locate-Datenbank-Datei zeigt, wie locate zu dieser Behauptung kommt:

$ ls -al /var/db/locate.database
-rw-r--r--  1 nobody wheel  0 Aug 14 21:21 /var/db/locate.database

Ganze null Byte ist einfach immer zu klein … Aus Linux-Erfahrung wissen wir, dass das Kommando updatedb für die Erstellung der locateschen Datenbasis verantwortlich zeichnet. Doch da beißt sich die Katze in den Schwanz: Wie sollen wir updatedb finden, wenn ein Aufruf des Kommandos als root

# updatedb
updatedb: Command not found

nur die misslaunige Antwort der Shell hervorruft, dass updatedb nicht im Suchpfad enthalten ist? locate kann uns den Ort des Befehls aus guten Gründen nicht verraten. Also bleibt der pragmatische Griff zur Manpage (Listing 1).

$ man locate
[…]
FILES
[…]
   /usr/libexec/locate.updatedb     Script to update the locate database
   /etc/periodic/weekly/310.locate  Script that starts the database rebuild
[…]

Et voilà – dann ruft root eben nicht updatedb, sondern das Skript zum Generieren der Datenbank mit

/usr/libexec/locate.updatedb &

auf, und nach einer Weile mag locate Antworten geben – ein paar zuviele vielleicht, die sich zum seitenweisen Anzeigen wie unter Linux mit einer Pipe an less verfüttern lassen: locate /bash |less. Allerdings hätten wir die richtige Antwort, bash sei unter /usr/local/bin/bash zu finden, auch einfacher haben können: Zum einen mit which bash (/usr/local/bin ist Bestandteil des Suchpfades), zum anderen mit man shells: Diese Manpage verrät, dass die Datei /etc/shells (übrigens wie unter Linux) alle auf dem System installierten Shells mit Pfadangabe auflistet.

Solche hilfreichen Manpages gibt es übrigens mehrere: Wer der Login-Meldung einen genaueren Blick schenkt, wird zum Beispiel auf man hier aufmerksam, das einen lesenswerten Spaziergang durch den FreeBSD-Dateibaum unternimmt.

Der Master-Plan

Wenn root jetzt allerdings frohgemut zum Editor greift und in der /etc/passwd den Shell-Eintrag /bin/sh bei pjung in /usr/local/bin/bash ändert, hat die Rechnung ohne den kleinen Dämon gemacht. Loggt sich pjung erneut ein, funktioniert [Tab] immer noch nicht wie in der Bash und die Pfeiltasten für die History auch nicht.

man 5 passwd (in Sektion 5 befinden sich die Manpages zu Dateien) klärt auf: Wie mittlerweile auch unter Linux gängig, benutzt FreeBSD ein Shadow-Passwort-System: /etc/passwd enthält anstelle der verschlüsselten Passwörter ein *; diese sind in eine nur root zugängliche Schatten-Passwort-Datei ausgelagert. Während die /etc/shadow unter Linux jedoch komplett anders aufgebaut ist als /etc/passwd und außer dem User-Namen keine Daten daraus wiederholt, speichert die FreeBSD-Master-Passwort-Datei /etc/master.passwd auch alle aus /etc/passwd ersichtlichen Daten noch einmal.

Maßgebend für ein Login sind die Daten aus /etc/master.passwd. Doch selbst wenn root diese per Editor ändert, passiert noch nichts: Da das Parsen einer Textdatei vergleichsweise ressourcenintensiv ist, greift das login-Programm auf eine binäre Version der Master-Datei zu. Solange die nicht auch auf dem aktuellen Stand ist, sieht es schlecht aus für pjung.

Die passwd-Manpage legt im Abschnitt SEE ALSO immerhin den Gedanken nahe, einmal das Kommando pwd_mkdb (“passwd_makedatabase”) unter die Lupe zu nehmen. Tatsächlich kann root mit

pwd_mkdb -u pjung /etc/master.passwd

gezielt den veränderten Eintrag für pjung aus /etc/master.passwd in den binären Datenbankdateien /etc/spwd.db (nur für root zugänglich, enthält die verschlüsselten Passwörter) und /etc/pwd.db (ohne Passwort, für alle lesbar) aktualisieren.

Zwei Dateien editieren und dann noch ein kryptisches Kommando aufrufen? Da greift jede Sysadmine gerne zu bereitgestellten Helfer-Tools: FreeBSD kennt vipw, ein Werkzeug, von dem in der Linux-Welt zumindest Debian-Nutzer(inne)n schon einmal gehört haben dürfen. In der FreeBSD-Version lädt es die Master-Passwort-Datei in den Editor vi (daher der Name) und erledigt die übrigen Aktionen automatisch. Will die Admine lieber ee benutzen, sagt sie (sofern sie mit der Default-C-Shell arbeitet) vor dem vipw-Aufruf einfach setenv EDITOR ee.

Umzugshilfe

Allein auf sich gestellt in der neuen BSD-Welt herumzustochern mag spannend sein. Aber wer sich häuslich auf dem neuen System einrichten will, muss nicht immer bei Null anfangen: Ob KDE oder Apache unter Linux oder FreeBSD laufen, spielt bei den Konfigurationsdateien keine Rolle. Da wäre es sinnvoll, die Linux-Partitionen zu mounten und die Dateien einfach zu kopieren. Doch roots Versuch, die erste Slice (/dev/ad0s1, unter Linux /dev/hda1 genannt) auf der ersten IDE-Master-Festplatte /dev/ad0 mit

# mount -t ext2fs /dev/ad0s1 /mnt
ext2fs: vfsload(ext2fs): No such file or directory

als Ext2-Dateisystem unter /mnt zugänglich zu machen, scheitert. Das von mount zum Zwecke der Einbindung einer Ext2-Linux-Partition aufgerufene Tool /sbin/mount_ext2fs existiert – allein es fehlt die Ext2-Unterstützung des FreeBSD-Kernels. Da bleibt nichts anderes, als einen neuen Kernel zu bauen. Das ist insofern einfacher als unter Linux, als dass wir uns gar nicht erst durch ein Konfigurationstool mit tausenden Abfragen quälen müssen. Wir brauchen einfach nur die aktuelle (generische) Konfiguration nehmen und sie um den Wunsch nach Ext2-Support erweitern.

Doch zunächst brauchen wir frische Kernel-Sourcen, denn die wurden wie erwähnt beim Upgrade nicht aktualisiert. Wieder kommt sysinstall zum Einsatz; wir bewegen uns über Configure / Distributions / src bis zu dem Dialog, der nachfragt, welche Quelltexte wir installieren wollen. Die Auswahl fällt auf

[ ] sys    /usr/src/sys (FreeBSD kernel)

und wir hangeln uns über zwei “X Exit“-Einträge zur nunmehr altbekannten Abfrage des Installationsmediums.

In /usr/src/sys/i386/conf finden wir die aktuelle Kernel-Konfiguration in der Datei GENERIC, die wir als Ausgangsbasis für unseren eigenen Kernel kopieren:

cd /usr/src/sys/i386/conf
cp GENERIC WITH_EXT2

Das ebenfalls in diesem Verzeichnis enthaltene File namens LINT dokumentiert alle möglichen Optionen. Hier finden wir den Eintrag

options         EXT2FS

den wir einfach in WITH_EXT2 übertragen, nicht ohne die Warnung vernommen zu haben, dass die Ext2-Unterstützung etwas instabil sei und man Ext2-Partitionen, um Datenverlusten vorzubeugen, nur lesbar (“read-only”) mounten solle. Doch tapfer, wie wir sind, bereiten wir mit

/usr/sbin/config WITH_EXT2

alles für die Kompilation vor, um sie anschließend im Verzeichnis /usr/src/sys/compile/WITH_EXT2 anzustoßen:

cd ../../compile/WITH_EXT2
make depend
make

Anhand von make -n install sehen wir, dass bei der abschließenden Installation mit make install der bisher verwendete /kernel nach /kernel.old kopiert wird. Das stört nicht weiter, denn da sowohl /kernel als auch /kernel.old bei uns nur Symlinks sind (siehe Kasten 1), überschreiben wir nichts, sondern können notfalls auch noch die beiden alten Kernel verwenden.

Mutig rebootet, meldet sich nunmehr der neue Standard-Kernel 4.7-RELEASE (WITH_EXT2) zu Dienst, doch der Mount-Versuch

# mount -t ext2 /dev/ad0s1 /mnt
mount: exec mount_ext2 not found in /sbin, /usr/sbin: No such file or directory

schlägt fehl. Aber ja doch! Der Hilfsbefehl heißt mount_ext2fs, nicht mount_ext2 – daher lautet die “type”-Option anders als unter Linux ext2fs. Doch um nun doch ein wenig vorsichtig zu sein und die Linux-Partition read-only zu mounten, kommt wieder die altbekannte Option ro ins Spiel:

mount -t ext2fs -o ro /dev/ad0s1 /mnt

oder etwas kürzer mount_ext2fs -o ro /dev/ad0s1 /mnt erlaubt den lesenden Zugriff auf die Linux-Partition unterhalb von /mnt; umount /mnt entfernt sie wieder aus dem Dateibaum. Auch logische Partitionen (etwa ein unter Linux als /home eingehängtes Device /dev/hda6) lässt sich als /dev/ad0s6 unter /mnt einbinden. Die mühsam erstellte Linux-.bashrc aus dem Homeverzeichnis der dortigen Benutzerin pjung findet so durch Kopieren (cp /mnt/pjung/.bashrc /home/pjung/) und Berichtigung der Eigentumsverhältnisse mit chown eine neue Heimat auf deren FreeBSD-Account.