Feb. 2005: Ubuntu als neues Testsystem
Da ich offensichtlich nicht mehr richtig fit mit Linux bin, aber immer mal wieder um Rat und Hilfe gefragt werde, muss jetzt die FreeBSD-7-Testinstallation einem Ubuntu 5.10 weichen. Also Teste ich mal die Installation dieser ge-hype-ten Distribution.
Prinzipiell sollte die Installation kein Problem sein: CD ("Install", nicht "Live") gesaugt, gebrannt und booten. Gesagt, getan: Ubuntu sucht sich die Partitionen selbst zusammen, und sucht sich doch glatt die zwei primären (die zweite enthaelt dann eine logische) - ohne dass ich hätte eingreifen können (oder wenn, ist's sehr gut versteckt). Und das blieb auch nicht der einzige Klopps:
Die Installation tut erstmal und der Rechner installiert sich. Keine Paketauswahl, ich hab mich also den Ubuntunen anzuvertrauen.
Dann entschließt sich Ubuntu, einen Master-Boot-Record zu installieren - auch ohne Nachfrage, und auch ohne die Möglichkeit, einzugreifen. Dabei kann Ubuntu wohl gar nix mit der FreeBSD-Installation auf Partition 2 anfangen, und Grub (der ist dazu auserkoren) bekommt ein Menu ohne entsprechenden Eintrag gebaut.
Na, Klasse! Ubuntu kann ich jetzt also booten (sogar mit Recovery-Modus! - Na, wer's braucht; ein richtiges loader-Prompt kann das auch und noch mehr - und einem Memtest, was schon eher Sinn macht), vielleicht auch ein Windoze, wenn ich eins hätte (Partition 1 ist immer noch eine "DOS"-markierte mit 700MB (war mal als "Suspend-to-Disk" gedacht). Aber ein richtiges Betriebssystem wird mal eben ignoriert. Gute Leistung, wirklich - wir nähern uns dem Vorbild an (braucht's hier einen Ironie-Indikator?).
Ubuntu wollte ich dann erstmal mit einigen Zusatz-Päckchen ausstatten und hab nach alter Debian-Manier dselect gestartet. Klar, Konsolen-orientiert, was mich hätte warnen sollen. Ein Verlassen von dselect war jedenfalls nicht mehr sinnvoll möglich, da sich Paketabhängigkeiten nicht auflösen ließen - und das obwohl ich noch gar nichts installieren wollte (Ctrl-C geht natürlich immer!). Das Dilemma löste sich erst, nachdem ich zusätzliche Paketquellen in /etc/apt/sources.list angegeben und synchronisiert hatte. Wehe dem, der keinen Netzzugang hat und auf die CD angewiesen ist.
Um wieder mein richtiges Betriebssystem booten zu können, hab ich FreeBSD von FreeSBIE gebootet und ein boot0cfg -B ausgeführt, so dass der Grub'sche Master-Boot-Record gebügelt wird und ich wieder ein normales FreeBSD-Boot-Menu bekomme. Allerding zuckt beim Versuch, FreeBSD zu booten, nur kurz die Platte. Erst wenn man diese Prozedur mit der FreeBSD 6-CD wiederholt, kommt man wieder an FreeBSD. Der installierte MBR bietet dannach auch richtigerweise ein Linux an. Die Hoffnung, das auch direkt so zu starten, erfüllte sich nicht, weil natürlich(?) ein "Linux Loader" fehlt.
Nun könnte man Grub oder LILO in den Bootsektor der Ubuntu-Partition packen, so dass von dort weiter-gebootet werden kann und Linux endlich weiß, wie es ans Leben kommt.
Aber wenn schon Grub, dann auch in den MBR, habe ich mir gedacht (grundsätzlich habe ich ja gar nichts gegen Grub). Dämlicherweise kann der mit Linux gelieferte nichts mit UFS anfangen (warum nicht? Wird da was ignoriert, oder weiß man es einfach nicht besser?) und kommt somit nicht an den Loader bzw. Kernel von FreeBSD ran. Also den FreeBSD-Port sysutils/grub installiert. Dieser Grub läßt sich nur dann im MBR installieren, wenn nicht von diesem gebootet wurde (verstehe ich auch nur bedingt); es gibt sonst eine nicht sehr aussagekräftige Fehlermeldung, die ich mir deshalb auch nicht gemerkt habe.
Deshalb muss zunächst eine Grub-Bootdiskette erstellt werden. Das Problem ist dabei weniger die Prozedure an sich - die wird gut beschrieben . - erstellt werden. Aber wo findet sich im heutigen Rechner-Haushalt noch eine brauch- und benutzbare Diskette (ich hab ca. 7 Stück aus Uraltbeständen - teilweise mehrfach - formatiert und beschrieben, bevor sich eine booten ließ). Gott sei Dank muss diese Prozedur nur einmal zu Beginn durchgeführt werden; ist Grub einmal installiert, reicht es im Weiteren, /boot/grub/menu.lst zu editieren - zumindest solange, bis wieder eine dämliche (Tschulligunk!) Distribution meint, alles überschreiben zu müssen (für den Fall liegt ab jetzt eine Grub-Boot-Diskette im Schreibtisch).
Nun endlich hatte ich wieder Zugang zu FreeBSD zum arbeiten und konnte Ubuntu zum "Spielen" und "Trainieren" booten.
Fazit oder:
Warum kann mich Ubuntu nicht überzeugen?
Ganz einfach: der Versuch, alles ganz einfach zu machen, macht eben genau diesen Fehler:
- Es kann und darf nicht sein, dass ein MBR einfach und ohne Nachfrage überschrieben wird. Das ist mein gewichtigster Kritikpunkt. Mit allen, was hier noch folgt, kann man leben, aber das hier ist eine Frechheit.
- Von der (halb-)automatischen Partitionsaufteilung habe ich auch keine gute Meinung bekommen. Es hätte gereicht, wenn Ubuntu sich genau eine primmäre Partition greift und alle seine Partitionen darin erzeugt - Linux kann schließlich mit logischen Partitionen umgehen. Das wäre eine saubere Lösung gewesen. Stattdessen benimmt sich die Installation wie die Axt im Walde - oder besser: "wie Windoze auf der Platte".
- Ein ROOT-Passwort wird während der ganzen Prozedur nicht vergeben. Einloggen als ROOT ist also gar nicht möglich - Klingt wie ein Sicherheitsplus. Aber: stattdessen wird alles, was ROOT-Rechte braucht, mittels sudo gemacht. Damit kann aber jeder Nutzer, so wie sudos Konfiguration per Default eingestellt ist, mal eben alles machen - ich brauch nur sudo davor zu schreiben und mein Passwort einzugeben. Ob das wirklich sicherer ist, als einen ROOT-Nutzer anzulegen, der dann als einziger am System arbeiten kann? Das trennt wenigstens die normale USER-Arbeit von der ROOT-Systemadministration. Mir ist das sympatischer. Nichts gegen sudo als solches; das nutze ich auch, um Rechte kontrolliert an normale Nutzer abzutreten.
- Ich bekomme mit Ubuntu zwar ein Linux, mit dem ich erstmal unter Gnome klicken - sorry - arbeiten kann. Und das basiert wenigstens auf der besten Linux-Distribution, die ich kenne: Debian . Aber schon beim simplen Starten des altbekannten Debian-Installationstools verirrt sich das in einer Endlosschleife; die Paketlisten scheinen so gut also nicht aufeinander abgestimmt sein, was spätestens beim ersten Update zu Trouble führen wird. Mag sein, dass das mit den "richtigen" ubuntu-eigenen GUI-Tools anderes ist. Mag auch sein, dass das jetzt ein spezifischer Fehler der aktuellen Version (5.10) ist. Aber wirklich anfängerfreundlich ist das auch nicht. Dann lieber Debian, das zwar endlos braucht, bis ein neues Release raus kommt ...
- Die komplizierte Installation des FreeBSD-Grub kann man Ubuntu nicht anlasten, nur dass es nötig wurde.
- Ach ja: Ubuntu liefert eine Startmelodie mit; wie im Fahrstuhl und schön im Raumklang und so.
Vielleicht bin ich aber auch nur grenzenlos altmodisch und trauere den alten Zeiten einer Slackware-Distribution nach. Da gab's gar keine Installationstools, nur HowTos und Man-Pages.
Ich jedenfalls bleib' bei FreeBSD!
Dez. 2005: $HOME teils verschlüsselt als union-Mount
Warum so kompliziert?
Die Sache mit der verschlüsselten SWAP- und $HOME -Partition habe ich mal angefangen, um eine Möglichkeit zu haben, Daten, die herumgetragen werden müssen, vor unbefugtem Zugriff zu schützen.
Es macht Sinn, das $HOME-Verzeichnis durch Verschlüsselung zu schützen. Allerdings würde das bedeuten, dass dieses auch gemountet werden muss, wenn man eigentlich nur an "unwichtigen" Daten arbeitet. Optimal wäre es, wenn die verschlüsselten Daten nur dann in's $HOME eingeblendet werden, wenn sie wirklich gebraucht werden. Daneben bleibt ein Teil der Daten auch unverschluesselt, wenn die verschlüsselten gemountet sind. Das reduziert den Aufwand beim Zugriff und entlastet meinen nicht ganz starken Laptop-Prozessor.
Eine Aufteilung stelle ich mir etwa so vor:
-
unverschlüsselter Bereich:
- Konfigurationsdateien für den Windowmanager und wichtige Applikationen, die in beiden Arbeitsmodi verwendet werden.
- .ogg- und .mp3-Files sind nicht sonderlich schützenswert, da sie ja den von mir gekauften CDs öffentlich zugänglich sind - und beim Abspielen spart man sich den Aufwand für das Decrypting.
- Fotos von der DigiCam (wenn nicht geheim). Auch hier steigt die Ladezeit sicher auch beträchtlich, wenn die Megabyte vor dem laden auch noch decodiert werden müssen.
- Im ~/download-Verzeichnis liegen auch nur frei zugängliche Dateien.
-
verschlüsselter Bereich:
- Passwort-Safe - obwohl ich meine Passwörter und GnuPG-Schlüssel lieber auf einem USB-Stick am Mann trage und nur bei Bedarf einhänge.
- Mails sind meistens auch sehr persönlich. Hier halte ich lieber alle notorischen Datensammler außen vor.
- Kunden- und Kontaktdaten, die der Konkurenz etwas über die eigenen Geschäftsverbindungen verraten könnten.
- Source-Code, Nutzerdaten und Spezifikationen der eigenen Projekte oder gar solche von Geschäftspartnern zur Verfügung gestellten Daten.
Was ist zu tun?
Backup aller wichtigen Daten. Seit den letzten Experimenten ist allerdings noch nicht viel neues dazugekommen - Skipped.
Entscheidung treffen, welche Teile des $HOME verschlüsselt und welcher in den unverschlüsselten soll. Momentan ist das Verhältnis 50:50, so dass das ad0s2f-Slice in zwei etwa gleich grosse Stücke zerlegt werden muss. Am besten man schreibt das Label in eine Datei label.txt:
bsdlabel ad0s2 > label.txt
die jetzt folgendes enthält:
bsdlabel ad0s2 # /dev/ad0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 512000 0 4.2BSD 2048 16384 32008 b: 2097152 512000 swap c: 59295915 0 unused 0 0 # "raw" part, don't edit d: 512000 2609152 4.2BSD 2048 16384 32008 e: 20971520 3121152 4.2BSD 2048 16384 28552 f: 35203243 24092672 4.2BSD 2048 16384 28552
Man editiert das File, so dass aus der letzten Partitionen zwei gleich große werden. Die Einträge der letzten Spalten kann man frei lassen; ebenso braucht der Offset nicht unbedingt berechnet zu werden; ein * reicht und bsdlabel berechnet den selbst (gleiches gilt auch für die Größenangabe der letzten Partition). Sie sieht dann wie folgt aus:
bsdlabel ad0s2 # /dev/ad0s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 512000 0 4.2BSD 2048 16384 32008 b: 2097152 512000 swap c: 59295915 0 unused 0 0 # "raw" part, don't edit d: 512000 2609152 4.2BSD 2048 16384 32008 e: 20971520 3121152 4.2BSD 2048 16384 28552 f: 17601622 24092672 4.2BSD g: 17601621 41694294 4.2BSD
Diese schreibt man anschliessen wieder zurueck:
# bsdlabel -R ad0s2 label.txt
(Das Disklabel kann mit dem Befehl bsdlabel -e ad0s2 auch direkt editiert werden). Das zurückschreiben der Partitionen kann im Single User Mode geschehen - ich hab es von der FreeBSD 7 Test-Installation aus gemacht.
Es ist klar, dass die Daten auf dem ehemaligen ad0s2f-Slice diese Prozedur nicht überleben. Aber es gibt ja ein Backup. Damit FreeBSD nun beim nächsten Booten nicht versucht das $HOME zu mounten - was bei einen Slice ohne Filesystem fehlschlagen muss - den zugehörigen Eintrag in der /etc/fstab noch stilllegen.
Zunächst werden beide Slices mit einem neuen Filessytem versehen (newfs): ad0s2f wird direkt das neue $HOME und ad0s2g nimmt erstmal das Backup-Home.tar.gz auf, um es dann nach $HOME zu entpacken.
Nächster Schritt: entscheiden, ob GBDE oder GELI eingesetzt werden soll. Da ich die Verschlüsselung mit GBDE schon ausprobiert habe und momentan die SWAP-Partition sowieso mittels GELI verschlüsselt wird, soll das das Mittel der Wahl sein. So werden die Module geom_eli.ko und crypto.ko wenigstens mehrfach genutzt und stehen die meiste Zeit nicht ganz nutzlos im Speicher rum. Außerdem erlaubt es GELI, Schlüssel und Passwörter zu ändern oder einen Zweitschlüssel zu definieren.
ad0s2g wird nun erstmal initialisiert:
# geli init -s 4096 -a blowfish -l 256 -K /etc/geli/home.key ad0s2g
Die Sektorgröße ist auf 4096 (-s 4096) eingestellt und verschlüsselt wird mittels 256 Bit langem Schlüssel (-l 256) nach dem Blowfish-Verfahren (-a blowfish). Der Schlüssel wird im unverschlüsselten Teil von $HOME abgelegt (-K). Das geli init verlangt wie bei GBDE auch die 2-malige Eingabe der Passphrase.
Nun kann das GELI-Device mit
geli attach -k /etc/geli/home.key ad0s2g
eingebunden werden, wobei wieder nach der Passphrase gefragt wird.
Bevor das verschlüsselte Device genutzt werden kann, muss es mit einem Filesystem versehen werden (newfs ad0s2g.eli), so dass es jetzt in's Filesystem eingehängt werden kann:
mount -o union /dev/ad0s2g.eli /home/photor
Dabei sorgt -o union dafür, dass der Inhalt des Mountpoints /home/photor "durchscheint". So bleiben die unverschlüsselten Daten der Partition erreichbar; die der verschlüsselten erscheinen dannach zusätzlich. Ein entsprechende Eintrag in /etc/fstab sieht dann so aus:
/dev/ad0s2g.eli /home/photor ufs rw,noauto,union 0 0
Das Mounten funktioniert auch hervorragend; im $HOME tauchen jetzt zusätzlich die Verzeichnisse der verschlüsselten Partition auf. Leider zeigte sich aber, dass der Versuch, sie wieder zu umounten mit einem "device busy", selbst wenn definitiv keiner auf eines der Verzeichnisse zugreift. Bleibt zu klären.
Bemerkungen:
- Und warum nicht einfach die verschlüsselte Partition an einen Mountpoint $HOME/Secret/ mounten? Antwort: weil ich es so eleganter finde. Und: weil ich ausprobieren wollte, ob sich so etwas realisieren lässt.
- Ein Problem zeigt sich beim umount: die Partition wird als "busy" bezeichnet, selbst wenn man in's übergeordnete Verzeichnis wechselt. Grund: bisher nicht kannt.
- Einige Daten wären sicherlich besser auf der verschlüsselten Partition untergebracht (z.B. ~/fetchmailrc enthält Passworte der Mailzugänge), werden aber auch im "unsicheren" Modus gebraucht. Hier muss die normale UNIX-Sicherheit (Zugriffsrechte etc.) ausreichen.
- Die verschlüsselte Partition wird "über" die unverschlüsselte gemountet. D.h., dass neu im $HOME angelegte Files und Directories automatisch im verschlüsseleten Teil landen. Sollen die Files (z.B. neu angelegte Konfigs) also nach dem umount auf den unverschlüsselten Bereich transferriert werden, muss die Partition nochmal extra gemountet werden.
- FreeBSD besitzt auch ein spezielles Union-Filesystem (statt mount -o wird mount -t union bzw. mount_union verwendet). Dieses ist jedoch nicht wirklich stabil (was für ein Experiment ja noch tollerierbar wäre) und hat außerdem den Nachteil, dass Dateien, die neu erzeugt werden, auf beiden zusammengemounteten Filesystemen erscheinen. Das ist nicht, was ich wollte.
Schluss:
Leider zeigt sich, dass, wenn die Secret-Partition quasi "über" die $HOME-Partition gemountet wurde, diese sich nicht mehr ohne weitere unmounten lässt. Man erhält ein device busy. Somit ist die ganze Eleganz dieser Methode zum Einblenden der vertraulichen Daten in's eigene $HOME-Verzeichnis dahin.
Es wird wohl doch ein Script(wird dann hier erscheinen) geben, das die Verzeichnisse über symbolische Links verfügbar macht.
Eine Zugabe
Ach ja: nachdem ich mir in losen Abständen immer mal eine Konfiguration zerschieße, habe ich die wichtigsten Files unter /etc und /usr/local/etc besser unter die Versionskontrolle CSSC (in den Ports unter devel/cssc zu finden) gestellt.
Nov. 2005: Tests mit GELI als Verschlüsselungs-Framework
Verschlüsselter SWAP
In FreeBSD 6 ist neben GBDE ein weiteres Framework für die Verschlüsselung von GEOM-Devices: GELI. Um dieses nutzen zu können, muss der Support entweder in den Kernel eincompiliert werden:
device crypto options GEOM_ELI
Oder man lädt das Modul geom_eli.ko (z.B. in /boot/loader.conf). Dieses lädt automatisch crypto.ko mit (trotzdem lade ich es explizit).
Anfangen will ich wieder mit dem SWAP-Bereich. Dazu den SWAP mit swapoff -a deaktivieren und, wenn der mit GBDE verschlüsselt war, mit gbde detach /dev/ad0s2b detachen.
Jetzt kann die Partition mit Zufallszahlen beschrieben werden:
dd if=/dev/random of=/dev/ad0s2b bs=1m
Um den SWAP-Space jetzt zu initialisieren, folgendes eingeben
geli onetime -d -a aes -l 256 ad0s2b
was den Verschlüsselungsalgorithmus AES (-a aes) mit einem Einmal-Schlüssel (onetime) und einer Schlüssellänge von 256 Bit (-l 256) festlegt. -d sorgt dafür, dass das GELI-Device automatisch detacht wird, wenn der letzte Verweis darauf geschlossen wird. Jetzt kann der SWAP mit swapon /dev/ad0s2b aktiviert werden. Und schon zeigt top mir
Swap: 1024M Total, 1024M Free
an, was etwas mehr ist, als mit GBDE (vgl. "SWAP-Partition verschlüsseln" ).
Um das alles automatisch während des Bootprozesses zu erledigen, braucht es nur eine Zeile mit den Flags in die /etc/rc.conf ein:
geli_swap_flags="-a aes -l 256 -s 4096 -d"
und, analog zur Verschlüsselung mit GBDE, muss noch die /etc/fstab modifiziert werden:
/dev/ad0s2b.eli none swap sw 0 0
Reboot. That's all!
Nov. 2005: FreeBSD 7 auf der Test-Partition
Nachdem FreeBSD 6 als BETA und schließlich als RC1 seinen Dienst auf dem Laptop tut, kann die Test-Partition /dev/ad0s3 eigentlich wieder etwas neues bekommen. Also
- die Source auf "Current" synchronisieren und
- cvsup /etc/cvsup.d/current-supfile, make buildworld, make buildkernel, make installkernel, make installworld, mergemaster, durchlaufen lassen.
Das funktioniert auch ganz gut, nur das nvidia.ko-Modul machte mal wieder Ärger (blödes proprietäres Zeug). Hier hilft nur, nach der System-Installation das Modul - d.h. den Port (x11/nvidia-driver) - zu deinstallieren und erneut bauen. Dann passt es auch zum Kernel. Vor dem Booten des neuen Kernels am besten in /etc/ttys das starten von XDM unterbinden um gar nicht erst Hektik aufkommen zu lassen.
Okt. 2005: Update auf FreeBSD 6
Nach den guten Erfahrungen mit FreeBSD 6 auf der Test-Partition habe ich das eigentliche Arbeitssystem ebenfalls geupdatet. Da die Unterschiede zwischen FreeBSD 5 und 6 nicht so groß sind, sollte dafür der übliche Kanon aus
cvsup make buildworld ... make installworld mergemaster
funktionieren. Das schlug leider fehl (wobei der Fehler wohl eher vor dem Monitor saß).
Bevor ich mich aber tiefer in die Innereien des Systems begebe, habe ich es lieber von Grund auf neu installiert. Um wirklich frisch anzufangen, wollte ich die Filesysteme neu anlegen. Das funktionierte aber erst nachdem ich die Partionierung des Slice /dev/ad2 gelöscht habe. Die prinzipilelle Aufteilung habe ich allerdings beibehalten.
Nach der Installation des Basissystems und der wichtigsten Ports wurden auch wieder die unter "Weitere Sicherheit" beschriebenen Features eingebaut - bis auf die verschlüsselte $HOME-Partition; hierfür suche ich noch nach einer komfortableren Prozedur, diese einzubinden. Entsprechend wurden diese Daten auch nur zum Teil vom Backup zurückgespielt.
Back to the Roots:
Mail mit Fetchmail, Exim, Procmail, Mutt und SpamAssassin
Eine Zeit lang habe ich Thunderbird als Mail-Reader genutzt, da mir recht häufig HTML-Mails zugestellt wurden, die ich auch lesen musste. Die kann Thunderbird ja direkt darstellen. Allerdings erkauft man sich das mit gravierenden Nachteilen:
- ein recht großes Programm, nur um Mails (und News) zu lesen
- alle Funktionen (Mail holen, sortieren, lesen, schreiben und ausliefern) in einem Programm
- (in meinen Augen) unübersichtlich zu konfigurieren
Dazu musste das Ding in letzter Zeit recht häufig neucompiliert werden (Sicherheits-Patches), was auf meiner Hardware (Lappy und Desktop) immer 3-4 Stunden dauert.
Nachdem die Multimedia-Mails aber wegfielen, konnte ich zum alten UNIX-Prinzip "Eine Aufgabe, ein Programm" zurück kehren. Das heißt,
- mail/fetchmail holt die Mail vom Provider auf den lokalen Rechner und kann einfach mehrere verschiedene Accounts abfragen (mittels $HOME/.fetchmailrc konfigurieren),
- mail/exim kenne ich noch aus Debian-Zeiten als relativ leicht zu konfigurierenden Mailtransporteur,
- mail/procmail dient dazu, die Mails vorzusortieren, so dass sich Maillinglisten recht einfach verwalten lassen,
- mail/p5-Mail-SpamAssassin wird von diesem zwischengeschaltet, um die ankommenden Spam-Mails zu meucheln (SpamAssassin benötigt allerdings eine gepatchte Version von Exim, die aber in den Ports vorhanden ist (mail/exim-sa-exim). Am besten, man installiert auch direkt die Filterregeln mail/spamass-rules
- mail/mutt ist als Mail-Reader sehr effektiv zu bedienen - "notfalls" auch in der Text-Konsole - und kann alles, was ich brauche (HTML allerdings nur über Umwege - aber das hatten wir schon).
Alle diese Programme lassen sich ganz übersichtlich mittels (ASCII)-Editor in Text-Files konfigurieren. Keine versteckten Häckchen in noch versteckteren Untermenues oder Tabs.
SpamAssassin besteht aus einem Daemon, den man am besten mittels
spamd_enable="YES"
in /etc/rc.conf während des Bootens startet. procmail füttert dem die Mails wenn in $HOME/.procmailrc folgende Regel eingetragen wird:
:0fw | /usr/local/bin/spamc
Dabei fungiert SpamAssassin als Filter, so dass die folgenden Regeln weiter abgearbeitet werden. Aussortiert wird der Schmutz z.B. durch
:0: * ^X-Spam-Status:\ Yes +SPAM
Ach ja! Auf den guten alten WindowMaker bin ich dann auch wieder umgestiegen - ohne Gnome- oder KDE-Unterstützung. Back to the Roots halt (werde ich auf meine alten Tage noch konservativ?).
Ende Sep. 2005: Mit FreeBSD auf's Handy - ein Versuch
Die Kommandozeile
Habe der Telekom "Auf Wiedersehen" gesagt und mir ein Handy geleistet. Mit USB ließ sich das Handy leider nicht erreichen, das Device wurde bein Einstecken des Handys erkannt; aber es gibt folgende Meldung im Log, die nichts gutes verheißt:
Data kernel: uhub0: port 1, set config at addr 2 failed Data kernel: uhub0: device problem (IOERROR), disabling port 1 Data kernel: ugen0: Motorola Inc. Motorola Phone (V3), rev 1.10/0.01, addr 2
Also bleibt noch die Möglichkeit Bluetooth und ich habe mir einen einfachen USB-Bluetooth-Dongle besorgt. Das wird folgendermaßen in /var/log/messages gemeldet:
Data kernel: ubt0: Broadcom Bluetooth USB Dongle, rev 1.10/0.01, addr 2 Data kernel: ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 Data kernel: ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 Data kernel: ubt_bulk_in_complete2: ubt0 - Bulk-in xfer failed, IOERROR (13). No new xfer will be submitted!
Um die Kommunikation aufzunehmen, muss der Bluetooth-Stack gestartet werden. Dazu wird zunächst das Modul ng_ubt geladen (das kann wie immer auch in /boot/loader.conf eingetragen werden). Dann den Stack starten: /etc/rc.bluetooth start ubt0
BD_ADDR: 00:XX:XX:XX:XX:XX Features: 0xff 0xfe 0xd 0x38 0x8 0x8 00 00 <3-Slot> <5-Slot> <Encryption> <Slot offset> <Timing accuracy> <Switch> <Hold mode> <Sniff mode> <RSSI> <Channel quality> <SCO link> <HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD> <Power control> <Transparent SCO data> Max. ACL packet size: 377 bytes Number of ACL packets: 10 Max. SCO packet size: 16 bytes Number of SCO packets: 0
Auf dem Handy Bluetooth einschalten und nach aussen sichtbar machen. Dann kann man nachsehen, ob sich beide Seiten sehen:
Data# hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:XX:XX:XX:XX:XX Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: ff:01:0c Clock offset: 0x35a5 Inquiry result, num_responses=1
Um nicht bei jedem Befehl die MAC-Adresse tippen zu müssen, kann man in /etc/bluetooth/hcsecd.conf einen Eintrag folgender Form machen:
device { bdaddr 00:XX:XX:XX:XX:XX; name "MotoV3" key nokey; pin "1111"; }
bzw. MAC-Adresse und Gerätename in /etc/bluetooth/hosts eintragen. Dann wird statt der der MAC-Adresse der vergeben Name angezeigt; der kann auch in den weiteren Befehlen statt dieser verwendet werden. Zusätzlich können noch Schlüssel und PIN angegeben werden.
Anpingen kann man das Telefon auch:
Data# l2ping -a MotoV3 44 bytes from 00:XX:XX:XX:XX:XX seq_no=0 time=1620.582 ms result=0 44 bytes from 00:XX:XX:XX:XX:XX seq_no=1 time=21.681 ms result=0 ...
Die sehen sich also; die Funkverbindung ist soweit also aktiv.
Um Daten auf das Handy hochzuladen eignet sich comms/obexapp. Zumindest ließ sich damit mal ein einfaches Bildchen auf's Handy schieben, das man dann als Wallpaper verwenden könnte:
Data# obexapp -a MotoV3 -C OPUSH obex> put /home/karo/WWW/Photor.DE/Bilder/PHOTOR.jpg PHOTOR.jpg Success, response: OK, Success (0x20)
Das Bildchen für das Wallpaper sollte ein 176x220 Pixel großes JPEG sein. Aber, so richtig auf dem Handy-Filesystem navigieren lässt sich so nicht; schon ein einfachen ls scheitert:
obex> ls Failure, response: Forbidden (0x43) obex> di Success, response: OK, Success (0x20) Data#
Der Versuch, sich wenigstens mal das Inhaltsverzeichnis anzusehen wird mit "Forbidden" quitiert (anschließend mit di "disconnectet", was aber immerhin "OK, Success" hatte). Das liegt wohl daran, dass OPUSH dazu gedacht ist, Objekte an's Handy zu senden, also nicht interaktiv ist. Aber auch mit einem anderen Protokoll wird das nichts:
Data# obexapp -a MotoV3 -C FTRN
Das Handy meldet sich mit der Frage, ob die Verbindung aufgebaut werden soll. Nach der Bestätigung will das Handy dann die PIN haben, woraufhin dann folgendes auf der Konsole erscheint:
Could not connect to the remote OBEX server. Response: Bad Request (0x40). Service: None Data#
Ist die komfortable Variante möglich? Gnokii
Gnokii installieren brachte zunächst auch nur begrenzten Erfolg. Aber zumindest konnte ich sehen, dass die Verbindung zwischen Rechner und Handy zustande kommt und nutzbar ist. Das Telefonverzeichnis ließ sich downloaden, allerdings nach Bearbeitung nicht wieder zurückschreiben - xgnokii stürzte einfach ab. Warum, weiß ich noch nicht.
Also doch wieder zurück zur Kommandozeile. Versuche mit dem Kommandozeilen-Interface von Gnokii folgen, aber selbst gnokii --identify gibt nach der Eingabe der PIN folgendes:
karo@worf:~> gnokii --identify GNOKII Version 0.6.8 IMEI : IMEI357397XXXXXXXXX Manufacturer : Motorola CE, Copyright 2004 Modell : GSM900","GSM1800","GSM1900","GSM850","MODEL=V3" Revision : R374_G_0E.40.79R karo@worf:~>
Immerhin, ein Lebenszeichen! Also noch ein bischen was probiert (repräsentativ ausgewählt):
karo@worf:~> gnokii --getringtonelist GNOKII Version 0.6.8 Failed to get the list of ringtones kro@worf:~> gnokii --getactiveprofile GNOKII Version 0.6.8 Cannot get active profile: Command called isn't implemented in model. karo@worf:~> gnokii --getdisplaystatus GNOKII Version 0.6.8 karo@worf:~> gnokii --getphonebook ME 1 end GNOKII Version 0.6.8 1. Name: Xxxxx,Yyy Number: 012345678901234 Group id: 0 2. Name: Xxxxxxxx,Yyyyyyy Number: +49123456789 [...] karo@worf:~> gnokii --getphonebook SM 1 end GNOKII Version 0.6.8 1. Name: Mailbox Number: +491234567889 Group id: 0 [...]
Während --getringtonelist also ein kommentarloses failed liefert, sagt mir --getactiveprofile wenigstens, dass dies auf meinem Handy nicht implementiert ist. Dagegen lassen sich die Telefonbücher aus dem Handyspeicher (ME) und der SIM-Karte (SM) auslesen. Das deckt sich mit dem Ergebnis im GUI-Tool xgnockii.
Links hierzu:
Ende September 2005: QEmu mit Win 2K drin
Nachdem ich schon einmal VMware unter Debian laufen hatte, wollte ich versuchen, die freie Variante QEmu zu installieren. Hintergrund: einige Programme, die leider nur unter dem Spiele-OS laufen, und Wine sich verstolpert.
Installiert wird QEmu aus den Ports (emulators/qemu) z.B. mit
portinstall emulators/qemu
Um wenigstens etwas Geschwindigkeit in den Emulator zu bekommen, sollte man allerdings das Kernel-Modul kqemu nutzen. Um das mitzubauen, trage ich in /usr/local/etc/pkgtools.conf die Zeilen
MAKE_ARGS = { ... 'emulators/qemu-*' => [ 'WITH_KQEMU=1', ], ... }
ein. Das entspricht der folgenden Kommandozeile make -DWITH_KQEMU install und hat den Vorteil, dass das automatisch auch bei einem portupgrade -arR berücksichtigt wird.
Bei der Inbetriebnahme der virtuellen Maschine habe ich mich im wesentlichen an diese Anleitung gehalten. Vorher sollte man aber das mitgebaute kqemu-Modul laden:
kldload kqemu
Dann ein Image-File erzeugen - hier von 3 GB Größe:
qemu-img create qemu_Win2K.img 3G
in dem dann das Windoze installiert wird:
qemu -hda qemu_Win2K.img -cdrom /dev/cdrom -boot d -win2k-hack -m 256
Die Installations-CD liegt im CD-Laufwerk (eigentlich müsste man auch aus einem ISO-File installieren können) und wird gebootet. Dabei bekommt die virtuelle Maschine 256 MB zugewiesen (-m 256). Zusätzlich sollte bei der Installation von Windoze 2000 das Flag -win2k-hack gesetzt werden.
Die ganze Prozedur dauerte trotzdem reichlich lange; wie lang genau, kann ich nicht sagen, weil ich irgendwann zu Bett gegangen bin. Morgens wartete dann eine Abfrage auf mich.
Als Ergebnis der ganzen Sache kann man dann Windoze in the Box starten (wieder mit 256 MB RAM):
qemu -hda qemu_Win2K.img -m 256
und man sieht nach einiger Zeit das folgenden Bild:
Es muss allerdings auch gesagt werden, dass 512 MB Speicher deutlich knapp sind. Sprich, die Kiste kommt recht schnell in's swappen. Große Jobs sollte man der virtuellen Maschine also nicht zumuten.
Bei der Installation von Windoze XP sollte das -win2k-hack-Flag nicht gesetzt werden; sonst dauerte die Prozedure deutlich länger - zu lange, für meinen Geschmack. Aber ich probiere es nochmal - bestimmt.
September 2005: FreeBSD 6 BETA 3
Ein neues Testsystem auf dem frei gelassenen 8.5GB-Slice am Ende der Platte: es ist FreeBSD 6 BETA 3 geworden (ein zwischenzeitlich installiertes NetBSD konnte mich nicht überzeugen). Natürlich bedeutet "BETA 3", dass das alles noch nicht richtig stabil ist.
Aber die Installation ging glatt: CD1 eingelegt, gebootet, und los. Keine besonderen Vorkommnisse. Nur das betreffende Slice ist jetzt nicht mehr Nr.4 sondern Nr.3. fdisk sieht also jetzt so aus. Die SWAP-Partition wird von der 5er Installation übernommen, liegt also auf /dev/ad0s2b. dmesg zeigt die erkannte Hardware.
Erste Aktion ist - wie immer - Kernel neu übersetzen, um die ganzen Debug-Optionen los zu werden. Die blähen den Kernel nur auf und machen das System langsam; ich bin kein FreeBSD-Entwickler und brauche die wirklich nicht.
X- und diverse andere Configs von 5 geerbt, so dass startx sofort funktioniert, nachdem der NVIDIA-Treiber installiert und das Modul geladen ist. Den passenden WindowManager und die wichtigsten Tools aus den Ports übersetzt und das System fühlt sich schon wieder passend an.
Ich war sofort neugierig, ob das leidige Sound-Problem immer noch bestand und habe Xmms installiert. Und ein paar .oggs abgespielt. Und: ging! Keine Spratzer, keine Aussetzer. Spricht dafuer, dass ich den Lappy bald auf FreeBSD 6 umsteigen lasse - sobald das STABLE wird. Schliesslich schimpft DELL das Modell "Multimedia".
Die diversen oben beschriebenen Features habe ich natürlich auch auf FreeBSD 6 ausprobiert:
-
Systemtuning
- Blowfish für master.passwd
- /tmp ins RAM; dadurch ist eine 256 MB-Partition frei geworden
- Mandatory Access Control (MAC)-Schnittstelle im Kernel
- Weitere Sicherheit
Da $HOME keine eigene Partition war, konnte ich sie nicht verschlüsseln.
Sommer 2005: Weitere Sicherheit
Sicherheit bei einem Laptop ist etwas anderes als bei einem Desktop oder gar einem Server; diese müssen sich hauptsächlich gegen Angriffe aus dem Netz verteidgen.
Das gilt natürlich auch für einen Laptop, wenn der im Netz hängt. Zusätzliche Gefahr bei dem ist, dass der ganze Rechner gestohlen wird - der ist schließlich per Definition leicht transportable - und der Dieb in aller Ruhe die Daten nach für ihn brauchbarem durchstöbern kann.
Das bedeutet, dass im Katastrophenfall wenigstens die sensible Daten für den Dieb nicht zugänglich sind (die Hardware ist natürlich trotzdem weg; das ist aber meist der bei weitem geringste Schaden). Deshalb hier ein paar Maßnahmen:
SWAP-Partition verschlüsseln
"Warum soll ich denn den SWAP-Bereich verschlüsseln? Die Daten werden doch meist sowieso wieder überschrieben."
Das ist richtig, wenn die denn überschrieben werden. Gerade Passwörter, Passphrases, SSH-, SSL- oder andere Schlüssel werden im Speicher abgelegt - und vergessen. Bei knappem RAM werden die auf die Platte ausgelagert. Und wenn dann der Rechner ausgeschaltet wird, liegen die da rum - bis eben wieder RAM knapp wird und die Daten dann vielleicht überschrieben werden. Also sollte man besser den SWAP verschlüsseln; am besten mit einem Schlüssel, den niemand - nicht einmal man selbst - kennt.
FreeBSD kennt zwar kein Crypto-Filesystem, wie es etwa NetBSD mit dem cgd bereitstellt. Dafür bietet aber das seit FreeBSD 5 eingeführte GEOM-Konzept eine Möglichkeit mittels gbde.
-
Im Kernel muss gbde aktiviert sein. Am einfachsten,
man läd das entsprechende Modul
root@Data:~> kldload geom_bde.ko
Wenn das geht (d.h. das Modul wird gefunden und verträgt sich mit dem Kernel), trägt man die passende Zeile in die /boot/loader.conf ein:geom_bde_load="YES"
Man kann aber auch options GEOM_BDE in die Kernel-Config eintragen und einen neuen Kernel bauen und so GDBE fest in den Kernel integrieren. -
SWAP-Partition in der /etc/fstab
ändern: dazu zunächst den SWAP mit
root@Data:~> swapoff -a
deaktivieren. Am besten geschieht das im single user-mode damit kein anderes Programm dazwischen plappert. Jetzt wird die fstab geändert:/dev/ad0s1b none swap sw 0 0
wird zu/dev/ad0s1b.bde none swap sw 0 0
Bevor man den SWAP nun wieder mitroot@Data:~> swapon -a
aktivieren kann, muss GBDE initialisiert und die Partition attacht werden. Das macht ein systemeigenes Start-Script im rc.d-Verzeichnis:/etc/rc.d/gbde_swap start
-
Damit das oben erwähnte Startscript bei jedem Booten
automatisch ablaufen kann, fehlt noch ein Eintrag in
der /etc/rc.conf:
gbde_swap_enable="YES"
- Nun Reboot und man hat als Ergebnis statt 1024 MB SWAP-Space nur noch 993 MB, die sind aber dafür verschlüsselt. Dass im Gegenzug die SWAPerei jetzt auch etwas langsamer wird, sollte auch klar sein. Aber einen Laptop wird man nur selten da einsetzen, wo es auf das letzte bischen Geschwindigkeit ankommt. Und swappen sollte der Rechner dann eh nicht.
Der Schlüssel wird für jede Session neu erstellt und nirgendwo (außer im RAM, wo auch /tmp liegt) gespeichert, und ist damit nach ausschalten der Maschine vergessen. Damit sind dann auch alle Daten auf der SWAP-Partition zerstört und damit sicher vor fremden Blicken. Damit ist natürlich auch klar, dass ein Crash-Dump nicht mehr analysiert werden kann. Dies ist also eher eine Option für Anwender-Laptop und nicht für (Kernel-/System-)Entwicklungs-Laptops.
Verschlüsselte $HOME-Partition
Neben eventuell im SWAP verbliebenen Passwörtern sind üblicherweise sensible Daten auf der Festplatte selbst vor unbefugtem Zugriff zu sichern. Die liegen meist auf der $HOME-Partition. Also soll auch die verschlüsselt werden:
-
Weil es auf dem Lappy grundsätzlich eng zugeht, hatte ich keinen Platz für eine Partition parallel zur jetzigen $HOME-Partition. Daher war als erste Maßnahme ein konventionelles Backup nötig (sollte man aber sowieso regelmäßig machen). Dannach die Platte/Partition putzen:
rm -r /usr/home
sollte das machen.
-
Das gbde-Device initialisieren:
gbde init /dev/ad0s2f -L /etc/ad0s2f.lock
Dabei wird nach dem Passwort gefragt (das wie üblich bestätigt werden muss) und eine .lock-Datei in /etc erzeugt (und die sollte da auch bleiben! Nicht löschen! Nicht verschieben!).
-
Anschließend das Device attachen:
gbde attach ad0s2f -l /etc/ad0s2f.lock
Hierbei wird wieder nach dem Passwort gefragt.
-
Dem attachten GBDE-Device muss jetzt noch ein Filesystem verpasst
werden:
newfs /dev/ad0s2f.bde
wonach dieses prinzipiell gemountet und befüllt werden kann. -
Um die Partition automatisch beim Booten einzuhängen, muss ähnlich wie bei der verschlüsselten SWAP-Partition , die /etc/fstab mittels Editor angepasst werden; der Eintrag sieht dann so aus
/dev/ad0s2f.bde /usr/home ufs rw 2 2
Zudem muss in /etc/rc.conf folgendes eingetragen werden:
gbde_devices="AUTO"
damit beim Bootem die Partition direkt eingehängt
- Reboot und gut!.
-
... oder auch nicht! Der Bootvorgang ging bis zu dem Punkt, an dem die Partitionen gemountet werden. Für die $HOME-Partition will der Rechner jetzt natürlich jetzt das Passwort haben:
... Mounting root from ufs:/dev/ad0s2a Pre-seeding PRNG: kickstart. Loading configuration files. Entropy harvesting: interupts ethernet point_to_point kickstart. Configuring Disk Encryption for ad0s2f. Enter passphrase:
eingegeben - und falsch - Hm.
zweitesmal eingeben - und wieder "denied" - Hm?
ebenso beim dritten Versuch. Und dann landet man im Single-User-Mode - Häh?!Watt nu? Naja. Nachsehen, ob vielleicht ein Eintrag in der /etc/rc.conf oder /etc/fstab fehlerhaft war. Dabei fiel mir dann auf, was Sache war: zum Zeitpunkt der Passwort-Abfrage ist das deutsche Tastatur-Layout noch nicht aktiv, so dass die Passwort-Eingabe unbemerkt wirklich falsch war (als gutes Passwort enthält das schließlich auch Sonder- und Satzzeichen).
Also der Tipp: Sich das Passwort hierfür im US-Layout merken (und auf die deutsche Tastatur transformieren). Und man sollte sich vergewissern, dass es keine Zeichen enthält, die auf einer US-Tastatur nur schlecht zu erreichen sind (Wo liegt da denn nur gleich das £ aufdem US-Keyboard? Und wie war das mit dem ä per Compose-Taste?).
- Letzte Amtshandlung ist natürlich, das Backup zurückspielen. Einen wahnsinnig großen Geschwindigleitsunterschied habe ich nicht bemerkt - aber auch nicht nachgemessen.
Allerdings gefällt mir das Ganze noch nicht: viel lieber wäre es mir, wenn die verschlüsselte Partition erst gemountet wird, wenn ich mich über XDM einlogge. Solange niemand das System wirklich braucht, bleibt die Partition wirklich verborgen (das wäre übrigens auch ohne Verschlüsselung sinnvoll). Wie das am besten zu bewältigen ist, weiß ich noch nicht. Aber:
- man bräuchte zwischen dem XDM-Login und dem Start der X-Session eine Konsole oder eine Applikation zur Passwort-Eingabe
- erst bei Erfolg wird dann die Partition gemountet (in der /etc/fstab als noauto markiert)
- und dann die nutzer-eigenen Files, speziell .xsession liest und ausführt
- eine Möglichkeit: Verzeichnis des Mountpoints befinden sich schon ein rudimentäres HOME-Verzeichnis
Diese Prozedur würde auch die Probleme mit einer falschen Tastaturbelegung umgehen.
Bemerkung
Beide oben beschriebenen Maßnahmen wirken nicht gegen Angriffe auf das laufende Laptop z.B. im Netz oder durch Fremdnutzer an der Konsole, da in dem Fall die Partitionen ja über GBDE transparent ins System eingebunden sind. Auf einen guten Schutz vor solchen Angriffen ist also wie bisher zu achten.
Einmal-Passworte
Im FreeBSD-Basissystem ist OPIE (One-time Password in Everything) bereits enthalten, so dass es eigentlich nur aktiviert werden muss. OPIE sollte überall da eingesetzt werden, wo man nicht sicher sein kann, dass irgendjemand einem bei der Passworteingabe über die Schulter schaut. Oder man logt sich von einer fremden Maschine in das eigene System ein, von der man nicht weiß, ob Tastatureingaben mitgeschnitten werden. Da OPIE jedesmal eine andere Eingabe erwartet, kann niemand mit der beobachteten Eingabe etwas anfangen - der eigene Zugang ist also weiterhin sicher.
Zur Aktivierung von OPIE gibt man einfach folgendes an der Konsole ein:
karo@Data:~> opiepasswd -c Adding karo: Only use this method from the console; NEVER from remote. If you are using telnet, xterm, or a dial-in, type ^C now or exit with no password. Then run opiepasswd without the -c parameter. Using MD5 to compute responses. Enter new secret pass phrase: Again new secret pass phrase: ID karo OTP key is 499 Da6278 LIP GLUT ALOE AIM AX TAKE karo@Data:~>
Die Warnung bezüglich des ungesicherten Zugangs über z.B. telnet sollte man Ernst nehmen und im Zweifel lieber abbrechen, bevor die Passphase mitgelauscht werden kann. Anschließend wird noch eine Zusammenfassung sowie der Key für das nächste Einloggen mittels OPIE angegeben: ID karo OTP key is 499 Da6278 bedeutet, das der User karo ein OTP-Schlüssel besitzt, und beim nächsten Login die Antwort Nr. 499 verwenden muss; Da6278 ist der sogenannte Seed-Wert. Die Nummern werden bei jeder Verwendung herunter gezählt, so dass jede Antwort nur einmal verwendet werden kann. Die folgende Zeile gibt die Antwort an, die OPIE bei der nächsten Abfrage erwartet, um den Zugang zu gewähren.
Die Response kann man sich direkt aufschreiben (und sicher verwahren). Man kann sie aber auch jederzeit mit
karo@Data:~> opiekey 499 Da6278 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Enter secret pass phrase: LIP GLUT ALOE AIM AX TAKE karo@Data:~>
erzeugen; es wird auch hierbei wieder nach der Passphrase gefragt. Wenn man nicht mehr weiss, welche Schlüsselnummer und welchen Seed-Wert ich brauche, kann ich die mittels:
karo@Data:~> opieinfo 499 Da6278 karo@Data:~>
in Erfahrung bringen.
Wesentlich praktischer ist es jedoch das Programm OpiePrint (zu finden in den Ports: security/opieprint), das die 100 nächsten Responses im Format einer Scheckkarte druckt (was man tunlichst nicht unter die Tastatur kleben sollte; zwischen den ganzen Kredit-, Krankenkassen- und Kundenkarten fällt das sowieso viel weniger auf):
karo@Data:~> opieprint -5 -s 499 -o OTP.ps
druckt 100 Antworten, startend bei 499 in die Datei OTP.ps. Wieder wird die Passphrase abgefragt. Die Karte packt man sich in die Brieftasche, jedenfalls weit weg vom Lappy.
Geht der Zähler gegen 0 sollte ein neuer Schlüssel erzeugt werden. Das geht wieder mit dem Befehl
karo@Data:~> opiepasswd -n 499 -s <seed>
opiepasswd kann auch verwendet werden, um die Passphrase zu ändern.
Wenn man sich jetzt an der Konsole einloggt, sieht man folgendes:
login: karo otp-md5 499 Da6278 ext Password: otp-md5 499 Da6278 ext Password [echo on]: LIP GLUT ALOE AIM AX TAKE
wobei ich am ersten Password-Prompt einfach RETURN eingegeben habe. Dadurch wird das Tastatur-Echo eingeschaltet. Das heißt zwar, dass jeder die Eingabe mitlesen kann - bloß es hilft ihm nicht: das Passwort ist ja im Moment der Nutzung schon veraltet. Groß-Klein-Schreibung wird übrigens ignoriert.
Juni 2005: Akku schwächelt
So langsam fängt einer der Akkus an zu schwächeln. Das ist relativ unangenehm, weil der Ladezustand bzw. die verbleibende Laufzeit Sprünge macht. Deutlich wird das in den beiden Grafiken (Idee auf Fabian Keil's IBM Laptop- Seite gesehen):
Aufgetrage ist jeweils der Ladezustand in Prozent über der Zeit (Samples alle 30 Sekunden): links im Leerlauf, rechts bei einem Load um 1.0, teilweise höher (grüne Linie: Load x100). Zu erkennen ist, dass spezielle am Ende der Entladung springt der Füllstand von einigen 20 auf 4 Prozent. Da will und sollte der Rechner dann schon Notfallmaßnahmen ergreifen. Auch bei der anschliessenden Ladung zeigt sich ein gewisser "Ladewiderstand" bei 95 Prozent. Auffällig, dass kaum ein Unterschied zwischen hoher und niedriger Systemlast zu finden ist. Ursache dafür: der Prozessor selbst ist zwar "mobile", der Chipsatz aber nicht.
März 2005: Systemtuning
Über Ostern habe ich Zeit gefunden, das System des Laptops ein bischen zu optimieren - auch in Hinblick auf die Sicherheit. Anregungen dazu habe ich zum Teil in Dru Lavignes Buch "BSD Hacks" gesucht und gefunden.
Im einzelnen:-
Passwörter in /etc/master.passwd
mittels Blowfish verschlüsselt:
Dazu ersetzt man in der /etc/login.conf den Eintrag
:passwd_format=md5:\
in:passwd_format=blf:\
Dabei bitte sehr aufmerksam auf Fehler achten; wenn hier ein Fehler auftritt, kann man sich dauerhaft aus dem eigenen System aussperren (Hinweis wieder FreeSBIE-CD ).
Anschließend muss noch einmal
cap_mkdb /etc/login.conf
aufgerufen werden (so, wie im Header der Datei vermerkt). Ab jetzt wird jedes neue Passwort Blowfish-verschlüsselt in der /etc/master.passwd abgelegt. Zum Konvertieren der Passworte einfach einmal passwd aufrufen und ein neues oder altes Passwort eingeben. Zu erkenne ist das daran, dass der Hash-Wert mit $2 beginnt statt mit $1, wie bisher, und der Hash-Wert ist deutlich länger.
- /tmp ins RAM, wobei sich hier das Problem ergab, dass sich das Verzeichnis /tmp/.ICE-unix/ beim Start von Xfce4 nicht anlegen ließ (was kein Problem von Xfce ist); ich landete somit direkt wieder im XDM-Login. Als quick-and-dirty Work-around wird es jetzt mittels sudo-Aufruf erzeugt (sehr unelegant, aber zunächst geht es so).
-
Einige neue Kernel-Konfigurationen getestet:
-
Kernel optimieren, wie es auch bei der Übersetzung
des restlichen Systems geschieht:
makeoptions COPTFLAGS="-O2 -pipe -funroll-loops -ffast-math"
-
der Kernel enthielt noch Code fuer NFS. Da der Rechner
zunächst als Reise-Lappy verwendet werden soll:
#options NFSCLIENT #Network Filesystem Client #options NFSSERVER #Network Filesystem Server #options NFS_ROOT #NFS usable as root device, requires NFS
-
Experimente mit Mandatory Access Control (MAC); deshalb diese
Option:
options MAC
Die einzelnen Features kann ich dann z.B. per:root@Data:~> kldload mac_seeotheruids
nachladen bzw. automatisiert durch einen Eintrag in /boot/loader.conf aktivieren. mac_seeotheruids bewirkt übrigens, dass jeder user nur seinen eigenen Prozesse sieht.
-
Kernel optimieren, wie es auch bei der Übersetzung
des restlichen Systems geschieht:
Feb. 2005: ACPI-Config, ein Versuch
Nach dem ersten Erfolg mit ACPI , habe ich mich ein bischen kundiger gemacht: zunächst sollte man sich ansehen, ob die DSDT (Hardware-Beschreibungs-Tabellen) richtig implementiert ist. Dies kann man, indem sie mit
Pfau# acpidump> -o dell.dsdt> /dev/null
ausliest, um sie mit
Pfau# iasl -d dell.dsdt
zu dekompilieren und anschliessend mit iasl wieder kompilieren. Dabei sollten keine Fehlermeldungen ausgespuckt werden. Ausgabe bei meinem Lappy:
Pfau# iasl dell.dsl Intel ACPI Component Architecture ASL Optimizing Compiler / AML Disassembler version 20041119 [Dec 21 2004] Copyright (C) 2000 - 2004 Intel Corporation Supports ACPI Specification Revision 2.0c dell.dsl 697: Method (\_WAK, 1, NotSerialized) Warning 2026 - ^ Reserved method must return a value (_WAK) ASL Input: dell.dsl - 2845 lines, 82860 bytes, 1138 keywords AML Output: DSDT.aml - 10668 bytes 402 named objects 736 executable opcodes Compilation complete. 0 Errors, 1 Warnings, 0 Remarks, 359 Optimizations Pfau#
Die DSDT kann nun gepatcht werden, so dass man eine korrigierte Version erhält:
Pfau# patch -p0 < dell-dsl.patch Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- dell.dsl.orig Wed May 14 02:07:27 2003 |+++ dell.dsl Tue May 27 22:18:14 2003 -------------------------- Patching file dell.dsl using Plan A... Hunk #1 succeeded at 120. Hunk #2 succeeded at 133. Hunk #3 succeeded at 153. Hunk #4 succeeded at 217. Hunk #5 succeeded at 238. Hunk #6 succeeded at 277. done Pfau#
was dann recompiliert werden kann:
Pfau# iasl dell.dsl Intel ACPI Component Architecture ASL Optimizing Compiler / AML Disassembler version 20041119 [Dec 21 2004] Copyright (C) 2000 - 2004 Intel Corporation Supports ACPI Specification Revision 2.0c dell.dsl 697: Method (\_WAK, 1, NotSerialized) Warning 2026 - ^ Reserved method must return a value (_WAK) ASL Input: dell.dsl - 2845 lines, 82944 bytes, 1148 keywords AML Output: DSDT.aml - 10678 bytes 402 named objects 746 executable opcodes Compilation complete. 0 Errors, 1 Warnings, 0 Remarks, 359 Optimizations Pfau#
Der Patch hat in diesem Fall also nichts gebracht.
Eine bereits korrigierte Version in ASL (ACPI Source Language) findet sich unter http://acpi.sourceforge.net/ und kann während des Bootens geladen werden. Dazu muss sie vorher mittels
iasl Dell_I8100_A15_custom.asl
in die AML (ACPI Machine Language) überesetzt werden; ich habe aus Phantasiemangel keinen speziellen Namen angegeben, so dass sie den Defaultnamen DSDT.aml bekam. Diese habe ich unter /etc/dsdt/ abgelegt. Durch den folgenden Eintrag in der /boot/loader.conf während des Bootens geladen werden kann:
acpi_dsdt_load="YES" acpi_dsdt_name="/boot/dsdt/DSDT.aml"
Das funktionierte auch nach dem 2. Versuch (der erste lief schief: in dem Fall bleibt die Kiste gnadenlos hängen, so dass sich Download und Brennen einer FreeSBIE-CD gelohnt hat).
Während des Bootens wird das Laden der neuen DSDT angezeigt:
ACPI: overriding DSDT/SSDT with custom table ACPI-0377: *** Info: Table [DSDT] replaced by host OS
Abgesehen davon, dass des Booten ein bischen länger dauert, wird seither die Soundkarte gar nicht mehr erkannt:
pcm0: <ESS Technology Maestro3> port 0xec00-0xecff mem 0xf8ffe000-0xf8ffffff irq 5 at device 3.0 on pci2 pcm0: failed: rid 0x10 is ioport, requested 3 pcm0: [GIANT-LOCKED] pcm0: <SigmaTel STAC9721/23 AC97 Codec>
und folglich keine Musik mehr gespielt. Zuvor zeigte sich der Sound allerdings auch nicht in bester Form. Der Schluss liegt nahe, dass ACPI hier ein Problem mit dem Musikabspielen hat.
Die neue DSDT hat leider auch das Problem mit dem Suspend nicht gelöst: schicke ich den Rechner mittels Fn-Suspend in den Schlaf, wird die Konsole vom Keyboard abgekoppelt (keine Eingaben mehr) bleibt aber ansonsten unverändert. Zudem blinkt die "Power"-LED - mehr passiert aber nicht. Glücklicherweise funktioniert die oben beschiebene Funktion des "Power"-Buttons noch, so dass der Rechner wenigstens geordnet ausgeschaltet werden kann.
Der Wechsel der DSDT hat also weiter keine Vorteile gebracht; somit wird das Laden zunächst mal wieder deaktiviert.
Weihnachten 2004: Komplette Neuinstallation
Da FreeBSD 5 mit Version 5.3 jetzt STABLE genannt wird und ich bei Linux doch immer mehr den Eindruck bekomme, dass der Hype wichtiger ist als die Stabilität, sollte jetzt der Zeitpunkt sein, FreeBSD als Standardsystem zu installieren.
Meine Gründe
- alle meine anderen Rechner laufen mittlerweile auf FreeBSD; es bleibt nur ein Betriebssystem zu warten und Pakete des einen Rechners lassen sich auch auf dem anderen instalieren.
- Gentoo kam FreeBSD zwar schon nahe (Portsystem - Portage) konnte mich aber nicht endgültig überzeugen; da bleibe ich lieber beim Original.
- jetzt ist gerade Zeit, um die Umstellung zu machen; bin gerade in einer "Zwischenzeit", und brauche den Rechner nicht zwingend(!); wenn also nicht jetzt, wann denn dann!
Plattenaufteilung
Für ein "Suspend-to-Disk" wird ein erstes Slice von ca. 700 MB angelegt (das sollte reichen fuer 512MB RAM und ein paar Zusatzdaten). Allerdings gab es ein Problem, bei dem Versuch das entsprechende Tool von der DELL-Support-Seite herunter zu laden: folgende Begrüßung im Service-Bereich (unter Angabe des Service-Tags, so dass die DELL-eigene Datenbank alles wissen müsste, was DELL wissen muss! Mehr will ich auch gar nicht Preis geben):
Wenn ich das entspechende Tool nicht laden kann, werde ich auf das Feature "Suspend-to-Disk" verzichten müssen.
Im 2. Slice wird die eigentliche Installation stattfinden; das sollten dann so etwa 30GB sein, die FreeBSD zur Verfügung stehen. Die genaue Partitionierung Partitionierung folgt unten.
Am Ende lasse ich aus alter Tradition ca. 8.5GB Platz für das nächste Testsystem - welches das auch immer sein wird: vielleicht DragonFly , oder ein Solaris zum spielen (vielleicht wird ja auch Debian GNU/Hurd ja doch mal gebrauchsfertig). Ganz absonderlich wäre: Windoze (aber wer weiss schon, was kommt; Außerdem: Kenne deinen Feind!). Für's erste hat diese Partition die Neuaufteilung der Platte überstanden, so dass ich diverse Configs direkt übernehmen kann (sollte man sich aber nicht drauf verlassen).
Installiert habe ich von der ersten CD (Image zu finden auf einem der Mirrors von FreeBSD ) von der sich im Allgemeinen direkt booten lässt. Die gesamte Platte wurde, wie oben berichtet, bis auf das letzte Slice neu aufgeteilt.
Die Partitionstabelle:******* Working on device /dev/ad0 ******* parameters extracted from in-core disklabel are: cylinders=77520 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=77520 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 6 (0x06),(Primary 'big' DOS (>= 32MB)) start 63, size 1429722 (698 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 88/ head 254/ sector 63 The data for partition 2 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 1429785, size 59295915 (28953 Meg), flag 80 (active) beg: cyl 89/ head 0/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: <UNUSED> The data for partition 4 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 60725700, size 17414460 (8503 Meg), flag 0 beg: cyl 1023/ head 255/ sector 63; end: cyl 1023/ head 254/ sector 63
Sysinstall
Nach dem Labeln und Partitionieren können die System-Sourcen, installiert werden. Eingestellt wird dann noch das deutsche Tastaturlayout, es werden die wichtigen Benutzer angelegt, und zunächst der Mouse-Daemon abgeschaltet. Die wichtigsten Einstellungen (/etc/X11/Xorg.conf, /etc/rc.conf etc.) habe ich von der alte Testinstallation gerettet und jetzt wieder eingespielt, so dass sich recht schnell wieder ein ein gut passendes System ergab. Die /etc/fstab zeigt die Aufteilung der Platte.
Grundeinstellungen, Netzwerk, /etc/rc.conf
Compiling a new World
Schon mehrfach erwähnt: erster Funktionstest für eine neue Installation ist die Neu-Compilation von Kernel und World. Dazu synchronisiert man am besten unmittelbar vorher nochmal die Sourcen:
cvsup /etc/cvsup.d/stable-supfile cvsup /etc/cvsup.d/ports-supfile
Damit sind die World- und Kernel-Sources up-to-date. Die beiden Files sind aus den Beispiel-Files entstanden, die bei der Installation des cvsup-Ports unter /usr/share/examples/cvsup/ abgelegt werden. Speziell sollte man sich einen schnellen cvsup-Mirror in der Nähe suchen.
Jetzt kann der normale Update-Prozess ablaufen (vorher aber /usr/src/UPDATING lesen, und befolgen!):
cd /usr/src shutdown now script /var/tmp/mw-<date>.out make buildworld make buildkernel KERNCONF=LAPPY make installkernel KERNCONF=LAPPY reboot shutdown now make installworld mergemaster reboot
Tipp 1: Durch die script-Anweisung
wird die gesamte Ausgabe unter /var/tmp zur
späteren Kontrolle gespeichert (nicht vergessen, ab und zu
löschen).
Jetzt läuft das neue System.
Tipp 2: man kann auch die Zeile KERNCONF=LAPPY in die /etc/make.conf reinschreiben und auf die Angabe der Konfiguration in make buildkernel und make installkernel verzichten.
FreeBSD kommt seit Version 5.3 mit /boot/beastie.4th daher. Es ist ein Auswahlmenue, das es gestattet, FreeBSD in verschiedenen Konfigurationen zu booten (z.B. ACPI-Modul laden oder nicht). Dieses Menu schalte ich aus: alle wesentlichen Einstellungen geschehen in /boot/loader.conf
X.org 6.8.1
Zur X-Konfiguration ist nicht viel neues zu sagen: in FreeBSD 5.3 wird Xorg statt XFree86 verwendet. Die Konfiguration ist jedoch gleich, so dass es ausreicht /etc/X11/XF86Config-4 in /etc/X11/xorg.conf umzubenennen.
Um sowohl das eingebaute Touchpad als auch die USB-Mouse verweden zu können wird der Mouse-Daemon gestartet:
moused_enable="YES"
in /etc/rc.conf. Dieser regelt dann, wie mit den Mouse-Events verfahren wird, egal, ob sie vom PS/2- oder vom USB-Device kommen. In der /etc/X11/xorg.conf wird das Mouse-Device /dev/sysmouse:
Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "Buttons" "5" Option "ZAxisMapping" "4 5" EndSection
So ist es möglich, das Mouserad an der USB-Mouse normal nutzen. Auch ein nachträgliches Anstöpseln der Mouse bekommt der X-Server gemeldet. Alles fein.
ACPI
An die eigentliche ACPI-Konfiguration habe ich mich noch nicht wirklich rangetraut (bin noch in Lohn und Brot und brauche die Daten noch). Aber: ich habe zufällig bemerkt, dass ein Druck auf den POWER-Button FreeBSD ganz geordnet herunterfährt. Sehr bequem!
Port-Installation
Nachdem das Basis-System läuft, sollten einiges an Software installiert werden. Dazu beginnt eine Port-Compilierungsorgie (natürlich werden die benötigten Ports nach und nach installiert; aber zu Beginn werden einige auch größere Ports fällig: Firefox, Thunderbird, OpenOffice sind schon ziemliche Klopper; gut, dass ich WindowMaker statt irgendwelcher Gnome-/KDE-Monster benutze). Zur Zeit sind die folgende Ports installiert (die Liste ist mit pkg_version -v erstellt).
Leider war es nach dem cvsup /etc/cvsup.d/port-supfile zunächst nicht möglich, den INDEX neu zu erzeugen. Das ist jedoch meist ein vorübergehendes Problem; einfach einige Tage später die Prozedur wiederhohlen.
Nov. 2004: Update auf 5.3-STABLE
Endlich ist FreeBSD 5 STABLE! Also, wieder ein Update, wieder mittels cvsup. Dabei ist leider PERL nur auf 5.6.1 mitgezogen worden, so daß ich das System wohl nochmal neu übersetzen muss (mit allen Ports, die ebenfalls von PERL abhängig sind). Da es aber sein könnte, dass der Rechner bald die ganze Platte unter FreeBSD nutzen darf, werde ich vielleicht sowieso ganz neu installieren. Solange tut's auch PERL in Version 5.6.1.
Gleichzeitig sind dann auch die Ports ge-updatet worden. Dazu verwende ich normalerweise portupgrade (findet sich selbst in den Ports). Da beim Umstieg auf 5.3-STABLE der gcc jetzt in Version 3.4 der Default-Compiler ist, sollten alle Ports (also nicht nur welchen mit höherer Versionsnummer) neu übersetzt werden, um zu vermeiden, dass ein Programm noch gegen eine alte Library gelinkt übrig bleibt. Dazu habe ich
portupgrade -afrR
ausprobiert. Damit werden alle Ports (-a) geupdated, die eine neuere Version im Ports-Baum finden; -rR sorgt dafür, dass ebenfalls alle Ports die vom aktuell bearbeiteten abhängig sind, bzw. alle von denen dieser abhängig sind, neu übersetzt werden. -f erzwingt auch dann eine Installation des Paketes - auch, wenn eine aktuelle Version installiert ist. Da noch nicht allzuviele Ports installiert waren, hat das auch gut funktioniert.
WLAN-Karte
Die oben erwähnte WLAN-Karte ist eine Orinoco Gold Karte mit Intersil Prism2 Chipsatz und funktioniert sowohl mit Linux und auch mit FreeBSD; allerdings nur nach Standard 802.11b, was mir aber prinzipiell ausreicht.
wi0: <Dell TrueMobile 1150 Series PC Card> at port 0xe000-0xe03f irq 10 function 0 config 1 on pccard1 wi0: using Lucent Technologies, WaveLAN/IEEE wi0: Lucent Firmware: Station (6.10.1) wi0: Ethernet address: XX:XX:XX:XX:XX:XX wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
An diesem Punkt muss ich jetzt klären, ob ich den Rechner vollständig auf FreeBSD 5 umstelle. Das System ist wohl stabil genug, um als Arbeitsgerät zu funktionieren. Wichtige Features, die ich vorher noch abklären muss:
- vollständig funktionierende WLAN-Karte
- ACPI: "suspend-to-RAM" und "suspend-to-disk" wären schön
- Möglichkeit, die Netzwerkumgebung schnell und einfach zu wechseln
Okt. 2004: Update auf 5.2.1
Update wieder mittels cvsup auf FreeBSD 5.2.1. Dabei habe ich gleichzeitig XFree86 durch Xorg 6.7 ersetzt. Auslöser hierfür war die etwas eigenartige Lizenz-Politik von XFree86; ob die Open Source-Gemeinde XFree86 mit dem gleichen Elan weiterentwickeln wird, wie bisher? (außerdem sollen ab Version 6.8 transparente und Schatten werfende Fenster möglich sein - aber, ob ich aber sowas brauche ...?). Die Konfigurationsdatei /etc/X11/xorg.conf habe ich einfach aus der /etc/X11/XFConfig86-4 übernommen. Allenfalls die Font-Pfade sollten angepasst werden.
Mär. 2004: externe USB-Platte
Nach dem Kauf einer USB-Beistellplatte (als Backup-Medium) stellt sich die Frage, welches Filesystem verwendet werden soll: Linux kann nicht gut mit UFS und FreeBSD nicht ordentlich mit EXT2/3. Daten lassen sich so schlecht tauschen. Also besitzt diese Platte jetzt eine VFAT- für den Austausch mit der DOSen-Welt,eine EXT2- und eine UFS-Partition. Bei Einstecken der Platte an den USB-Port steht folgende Meldung im Log:
umass0: Genesyslogic USB Mass Storage Device, rev 2.00/0.02, addr 2 GEOM: create disk da0 dp=0xc48b5c50 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <WDC WD12 00BB-00FTA0 0811> Fixed Direct Address SCSI-0 device da0: 1.000MB/s transfers da0: 114473MB (234441648 512 byte sectors: 255H 63S/T 14593C)
Zur Aufteilung und Partitionierung der Platte habe ich sysinstall verwendet. newfs musste ich allerdings vom FreeBSD 4-System aus starten; das mit Version 5 erzeugte UFS-Filesystem ließ sich nicht unter FreeBSD 4 mounten.
******* Working on device /dev/da0 ******* parameters extracted from in-core disklabel are: cylinders=14593 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=14593 heads=255 sectors/track=63 (16065 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 12 (0x0c),(DOS or Windows 95 with 32 bit FAT (LBA)) start 63, size 19551042 (9546 Meg), flag 0 beg: cyl 0/ head 1/ sector 1; end: cyl 1023/ head 254/ sector 63 The data for partition 2 is: sysid 131 (0x83),(Linux native) start 19551105, size 58605120 (28615 Meg), flag 0 beg: cyl 1023/ head 254/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 3 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 78156225, size 117210240 (57231 Meg), flag 0 beg: cyl 1023/ head 254/ sector 63; end: cyl 1023/ head 254/ sector 63 The data for partition 4 is: <UNUSED>
Tipp: Der Mountpoint sollte nicht / (oder ein anderer wichtiger Punkt im Filesystem-Baum) sein, da sysinstall die Partition im Anschluss automatisch mountet, wobei Teile des Baums verdeckt werden koennen. Besonders fatal bei der ROOT-Partition, wenn dann /sbin/mount fehlt.
Mai-Jun. 2003: Einige Updates
Mittels cvsup /etc/CVSUP-CONFIG habe ich das System geupdatet - zunächst auf 5.1-CURRENT. Danach warf der Kernel sowohl beim Booten als auch beim Wechsel des Power-Profiles mit Meldungen um sich (ACPI-0625: *** Info: GPE Block0 defined as GPE0 to GPE15 und so weiter). Eine Google-Suche ergab, daß es sich um ein DELL-spezifisches Problem handelt. Später habe ich dann statt des CURRENT- den RELEASE-Zweig verwendet, wonach die Meldungen verschwanden (Debugging ist halt ausgeschaltet; zusätzlich habe ich auch die DEBUG-Optionen aus der /etc/make.conf entfernt.
Noch ein Tipp: Nach einem cvsup oder make update sollte man immer zuerst /usr/src/UPDATING lesen. Sonst kann es passieren, daß sich Kernel bzw. World nicht übersetzen lassen. Im konkreten Fall war noch explizit ein Scheduler auszuwählen (siehe Kernel-Config ).
Ostern 2003: Installation
Die letzte primäre Partition (/dev/hda4 in Linux-Sprech) von ca. 8 GByte war von Anfang an für FreeBSD reserviert. BSDs brauchen definitiv eine primäre Partition ("Slice" genannt), die dann die FreeBSD-"Partitionen" aufnimmt. Vorteil: das gesammte System befindet sich in einer DOS-Partion (dem Slice). Installiert habe ich ein FreeBSD 5.0 von einer FreeX-Heft-CD . Einlegen, booten, Installation beginnen. Die restlichen Partitionen/Slices mit dem Linux-Arbeitssystem sollten dabei nicht angetastet werden (ein Backup beruhigt aber ungemein). Die genaue Aufteilung des Slice habe ich zunächst der Weisheit des Installationstools überlassen; es sollte ja eine Testinstallation werden.
FreeBSD 5.X unterscheidet sich schon deutlich von dem Vorgänger 4.X (mit dem habe ich schon ein bischen Erfahrung, da mein alter P90 als Router/Paketfilter seinen Dienst damit verrichtet). Deshalb wollte ich die neue Version 5 mal testen.
Ein neues Feature ist die ACPI-Unterstützung. Der GENERIC-Kernel besaß dieses Feature und offensichtlich lief der Rechner. Jedenfalls zeigen die Bootmeldungen , dass die entsprechenden Devices ("acpi0" und "acpi_XXXX") gefunden wurden.
ACPI funktioniert auch leidlich: das wichtigste, die Lüfter werden offensichtlich richtig angesteuert. Das war Vorraussetzung für alles weitere, da ich schon einige Horrorgeschichten von gegrillten Prozessoren gehört hatte. Aber auch der Akku- bzw. Stromstatus wird in den WindowMaker-Appletts richtig angezeigt und der Rechner schaltet sich nach einem shutdown -p now artig aus. Wie sich aus den Bootmeldungen entnehmen ließ, wird am Schluss des Bootprozesses in das "power profile economy" gewechselt (der Rechner wurde im Akku-Modus gebootet.
Allerdings komme ich unter FreeBSD nicht mehr in's BIOS-Menü (Tastatur-Kombinationen Fn-F3 bzw. Fn-F5), um das direkt zu prüfen. Ein "Suspend" des Rechners war zunächst nicht relevant ( später mehr dazu).
XFree86-Konfiguration
Die XFree86-Konfiguration habe ich einfach von der Debian-Installation übernommen. Nachdem ich den (leider proprietärer "closed source") NVIDIA-Treiber aus den Ports installiert und geladen hatte, ließ sich X mit startx starten. Daraufhin habe ich die folgende Zeile in /etc/ttys eingetragen habe:
ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm on secure
so daß XDM automatisch gestartet wird. Dazu muss natuerlich das NVIDIA-Module schon beim Booten geladen werden. Das kann durch den Eintrag von nvidia_load="YES" in /boot/loader.conf erreicht werden.
Sound
Der Kernel erkennt die Soundkarte vom Typ "ESS Technology Maestro3" (pcm0). Nach laden der Module "snd_maestro3" und "snd_pcm" ist die Soundkarte einsatzbereit. Ein Eintrag in von
snd_maestro3_load="YES"
in die /boot/loader.conf erledigt auch das zur Boot-Zeit. Unter X zeigte XMMS allerdings nach kurzer Spielzeit Aussetzer und Spratzer bis schliesslich der X-Server reproduzierbar abschmierte. Ich konnte beobachten, wie der Speicher immer knapper wurde, wenn XMMS dudelte. FreeBSD 5.0 hat wohl doch noch Stabilitätsprobleme.
Netzwerk
Die Netzkarte (3COM 3c556) wird als xl0 erkannt, so dass das Netzwerk spielt, sobald der Karte die entsprechenden Parameter (IP, Gateway etc.) zugewiesen werden. Zweckmäßigerweise passiert das durch Einträge in der /etc/rc.conf. Ein Tool, um die Netzwerkumgebung automatisch wechseln zu können, habe ich leider noch nicht gefunden.
PCMCIA/PCCARD
PCMCIA funktioniert, und zwar out-of-the-box. Getestet habe ich mit der WLAN-Karte (DELL TrueMobile 1150 - eine umgelabelte Orinoco Gold mit Intersil Prism2 Chipsatz); mit den Wireless-Tools von GKrellm oder WindowMaker konnte ich die Signalstärke auslesen. Das Netzwerk-Device wi0 wird automatisch angelegt, da FreeBSD 5 einen devfs-Daemon verwendet - die Konfiguration dazu in der /etc/devfs.conf . Fehlt nur noch die automatische Konfiguration der drahtlosen Netzverbindung.
Kernel compilieren
Ist ein neues System installiert, compiliere ich einen neuen Kernel, um einen angepassten Kernel zu erhalten. Dazu habe ich die GENERIC-Konfiguration umbenannt und modifiziert (alles auskommentiert wird, was nicht gebraucht wird, wie SCSI-Devices, die restlichen Netzkarten, RAID-Controler, und ein Paar Extras hinzugenommen; z.B. options EXT2FS). Hier ist die aktuelle Konfiguration .
Literatur und Links
Bücher
-
Greg Lehey, "The Complete FreeBSD", 4th Edition, O'Reilly,
2003
Gutes Buch von Greg Lehey, der auch in den einschlägigen Newsgroups zu lesen ist (auch in deutsch - beeindruckend). Das Buch deckt alle Themen von der Installationsanleitung (FreeBSD 5) bis hin zu komplexeren Themen (vinum) ab. Sprache: englisch -
Michael Lukas, "Absolute BSD: The ultimate Guide to FreeBSD", No
Starch Press, 2002
Ebenfalls ein gutes Buch, befasst sich allerdings noch mit Version 4.x. Es beginnt ebenfalls mit der Installation, setzt aber etwas andere Akzente als Greg Leheys Buch. Deshalb besitze ich beide. Sprache auch hier: englisch -
Dru Lavigne, "BSD Hacks 100 Insider-Tricks & Tools", 1. Auflage
(deutsche Ausgabe), O'Reilly, 2005
Buch ist mehr eine Sammlung von nützlichen Tipps, die ein *BSD-System handlicher und sicherer machen (siehe auch ihre tolle Columne ). - Yanek Korff, Paco Hope, Bruce Potter, "Mastering FreeBSD and OpenBSD Security", O'Reilly, 1. Auflage, 2005
Mit den ersten beiden Büchern ist man im Prinzip gut für FreeBSD gerüstet; zumindest wenn man Linux-mäßig (oder besser gleich mit UNIX) vorgebildet ist. Es werden bei allen Büchern relevante Themen auf eine Weise erklärt, wie man sie leider nur anglo-amerikanischen Fachbüchern findet.
Links zum Thema
Einige Links, die mir bei all dem da oben geholfen haben:- The FreeBSD Project
- Wiki des BSD-Forums
- BSD-Guides
- FreeBSD on laptops
- MobiliX: UniX with Mobile Computers
- Laptop Compatibility for FreeBSD
- FAQ of linux-dell-laptops
- FreeBSD 4.5 on a Dell Inspiron 8100
- Sandcat - ACPI fix for Dell laptops
- Wireless 802.11b Networking
- TuxMobil: Lost and Stolen Mobile Computers
Files
Technische Daten:
- Mobile Pentium III 1000 MHz
- 512 MB SDRAM
- Intel Corp. 82820 820 (Camino 2) Chipset PCI (-M) (rev 03)
- 40 GB IBM IDE harddisk (HITACHI_DK23DA-40)
- 15" UXGA LCD Display (1600x1200)
- 32 MB nVidia GeForce2 Go
- 8x DVD Toshiba (TOSHIBA DVD-ROM SD-C2502)
- ESS Maestro 3i Sound Card
- 3Com PCI 3c556 Laptop Tornado Vers LK1.1.16
- Texas Instruments CardBus Controller
- Texas Instruments IEEE1394 (FireWire) controller
- SMC Fast-IR controller
- BIOS version: A15
- zugekauft:
- Logitech Mouseman Traveler opt. USB-Mouse
- DELL True Mobile 1150 Series WLAN-Karte
- HAMA PCMCIA-Flash-Card-Adapter
- USB-Stick: PNY Technologies