PHOTOR

FreeBSD auf Dell Inspiron 8100

Diese Seite löst von Weihnachten 2004 ; die vorherigen Seiten über die Installation von Debian-Gnu/Linux bzw. von Gentoo (die ist ganz verschwunden) auf meinem Laptop, einem DELL Inspiron 8100 (techn. Daten) , ab. Die Debian-Seite wird nur noch minimal gepflegt. Trotzdem sind die Erfahrungen, die dort beschrieben sind, weiter wahr - und vielleicht helfen die ja noch jemandem.

Auf dieser Seite hier werden deshalb oft nur Informationen gegeben, die neu oder anders im Vergleich zur Linux-Installation sind. Ich gehe aber davon aus, dass Leute, die sich an FreeBSD "wagen", eine gewisse Vorbildung durch Linux oder andere richtige Betriebssysteme besitzen.
Diese Seite ist in Form einer Chronik aufgebaut: wird etwas neu installiert, konfiguriert etc, wird es hier vermerkt - vielleicht noch unfertig oder reichlich unelegant gelöst. Bei Gelegenheit werden dann neue Erkenntnisse hinzukommen.
Das alles geschieht in der Hoffnung, dass es irgend jemandem weiter hilft (zumal es noch nicht viele Seiten zu FreeBSD auf Laptops in deutsch gibt). Aber natürlich gilt auch hier der übliche Disclaimer.

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:

  1. 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.
  2. 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".
  3. 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.
  4. 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 ...
  5. Die komplizierte Installation des FreeBSD-Grub kann man Ubuntu nicht anlasten, nur dass es nötig wurde.
  6. 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:

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:

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

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:

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,

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:

  1. Systemtuning
    • Blowfish für master.passwd
    • /tmp ins RAM; dadurch ist eine 256 MB-Partition frei geworden
    • Mandatory Access Control (MAC)-Schnittstelle im Kernel
  2. 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.

  1. 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.
  2. 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 mit 
    root@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
  3. 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"
  4. 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:

  1. 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.

  2. 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!).

  3. Anschließend das Device attachen: 

    gbde attach ad0s2f -l /etc/ad0s2f.lock

    Hierbei wird wieder nach dem Passwort gefragt.

  4. Dem attachten GBDE-Device muss jetzt noch ein Filesystem verpasst werden: 
    newfs /dev/ad0s2f.bde
    wonach dieses prinzipiell gemountet und befüllt werden kann.

  5. 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

  6. Reboot und gut!.

  7. ... 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?).

  8. 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:

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:

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

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:

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

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:

Files

Technische Daten:

Last modified: Sat Nov 11 00:05:34 CET 2006