August 2007: Experimente mit Jails
Die im Desktoprechner frei gewordenen (angeschlagene) Platte wollte ich nicht einfach ausbauen und wegwerfen. Der freie Platz würde sich für ein paar Experimente (also nichts produktives) eignen. Da virtuelle Maschinen gerade groß in Mode sind, könnte man doch einfach mal einen Web-Server (und vielleicht noch einen FTP-Server) in einem Jail betreiben; schön sicher vom Rest des Systems abgeschottet. Und PostgreSQL brauche ich eigentlich auch nicht immer.
Installation
Als erstes wird ein Slice der Platte (mittels passend vergebenem Label ) an /usr/jails gemountet. Darin werden dann für jedes Jail Directories angelegt:
worf# cd /usr/jails worf# mkdir FTP worf# mkdir APACHE worf# mkdir PGSQL
Um darin ein Jail zu erzeugen, muss prinzipiell ein neues System dahinein kopiert werden:
worf# make world DESTDIR=/usr/jails/FTP worf# make distribution DESTDIR=/usr/jails/FTP
Damit wird ein FreeBSD-Basissystem in /usr/jails/FTP angelegt; das dauert auf dem Rechner etwa 2.5 Stunden. Für den Anfang habe ich quasi eine Kopie meines Basissystems angelegt. Später kann man dann /etc/make.conf modifizieren (die Man-Pages und einige andere Teile des Systems braucht man im Jail sicher nicht - sofern man nicht eine vollständige virtuelle Maschine braucht. Ein paar Kandidaten, die mir auf Anhieb einfallen: NO_ACPI, NO_BLUETOOTH, NO_DICT, NO_GAMES, NO_I4B, NO_INFO, NO_LPR, NO_MAN, NO_SHAREDOCS. Das System ist aber sowieso nicht sehr groß: du -s /usr/jails/FTP liefert 124104.
Inbetriebnahme
Mit der folgenden Zeile wird das Jail erstmal gestartet:
worf# jail /usr/jails/FTP ftp.mydomain.home 172.16.0.31 /bin/sh
Man befindet sich im /-Verzeichnis von ftp.mydomain.home:
worf# hostname ftp.mydomain.home
Damit braucht diese "Maschine" natürlich auch eine Grundausstattung: passwd
worf# jls
JID IP Address Hostname Path
19 172.16.0.32 www.mydomain.home /usr/jails/APACHE
17 172.16.0.31 ftp.mydomain.home /usr/jails/FTP
Konfiguration der Jails
In /etc/rc.conf des Hosts trägt man noch das folgende ein, so dass das FTP-Jail (und natürlich das FTP-Jail) auch beim Neustart des Systems automatisch gestartet wird:
# jail_enable="YES" # a Space separated list of names of jails jail_list="FTP APACHE" # # 1. FTP (soll mal ftp.mydomain.home werden) jail_FTP_rootdir="/usr/jails/FTP" jail_FTP_hostname="ftp.mydomain.home" jail_FTP_ip="172.16.0.31" jail_FTP_interface="ed0" jail_FTP_exec_start="/bin/sh /etc/rc" jail_FTP_exec_stop="/bin/sh /etc/rc.shutdown" jail_FTP_devfs_enable="YES" jail_FTP_procfs_enable="NO" jail_FTP_mount_enable="NO" jail_FTP_devfs_ruleset="" jail_FTP_fstab="" jail_FTP_flags="-l -U root" # # 2. APACHE (soll mal www.mydomain.home werden) jail_APACHE_rootdir="/usr/jails/APACHE" jail_APACHE_hostname="www.mydomain.home" jail_APACHE_ip="172.16.0.32" ...
Nachdem die Jails per
worf# /etc/rc.d/jail start
gestartet wurden, stehen die virtuellen Maschinen zur Verfügung. Die vergebenen IPs werden bei mir durch die eine vorhandene Netzkarte mit dem Außennetz verbunden (hier, nachdem das FTP-, APACHE- und das PGSQL-Jail gestartet wurden):
worf# ifconfig ed0
ed0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet 172.16.0.2 netmask 0xffffff00 broadcast 172.16.0.255
inet 172.16.0.31 netmask 0xffffffff broadcast 172.16.0.31
inet 172.16.0.32 netmask 0xffffffff broadcast 172.16.0.32
inet 172.16.0.33 netmask 0xffffffff broadcast 172.16.0.33
ether 00:XX:XX:XX:XX:XX
media: Ethernet autoselect (10baseT/UTP)
Einzelne Gefängniszellen lassen sich mit /etc/rc.d/jail start APACHE starten, unabhängig davon, was in /etc/rc.conf konfiguriert ist.
Damit Anfrage an das Jail (172.16.0.3[1-3]) nicht vom 172.16.0.2-Host-Rechner weggefangen werden, müssen die auf dem Rechner laufenden Daemons so konfiguriert werden, dass sie nur auf der Host-Adresse lauschen. Welche das sind, bekommt man mit sockstat|grep "\*:[0-9]". Bei mir waren das exim, http (Apache, der ja sowieso in's Gefängnis soll), squid, sshd, ntpd.
FTP-Jail: ftp.mydomain.home (172.16.0.31)
Dieses Jail soll FTP-Server spielen (naja, eigentlich ist das bloß ein Lern-Jail; FTP lässt sich halt einrichten, ohne irgendwelche Ports zu installieren). Daher sollte hier ein ftpd gestartet werden:
APACHE-Jail: www.mydomain.home (172.16.0.32)
Das gleiche nochmal mit dem APACHE-Jail. Zusätzlich muss natürlich der Apache (Version 2.2 soll's sein) aus den Ports installiert werden.
www# mount_nullfs /usr/ports /usr/jails/APACHE/usr/ports www# cd /usr/ports/www/apache22 www# make install
Dazu wird dann noch ein bischen was drumrum installiert (lang/perl5.8, devel/autoconf259, devel/libtool15, textproc/expat2, converters/libiconv, devel/m4, misc/help2man, devel/gmake, devel/autoconf-wrapper, devel/p5-Locale-gettext, devel/gettext, www/apache22) was das Jail-Verzeichnis ein bischen dicker macht:
www# cd /usr/jails www# du -s * 191267 APACHE 124489 FTP www#
Um den Apache zu starten, ist dann - wie üblich - die /etc/rc.conf und die /usr/local/etc/apache22/httpd.conf anzupassen (Listen 172.16.0.32:80 reicht erstmal). Dann ganz einfach
www# /usr/local/etc/rc.d/apache22 start Performing sanity check on apache22 configuration: Syntax OK Starting apache22. www#
und schon läuft ein gefangener Web-Server ("It works!"), der jetzt mit Inhalt gefüllt werden kann. Der kann vom Host direkt in das data-Verzeichnis kopiert werden.
https-Protokoll
Wenn schon ein eigener "Web-Server" dann kann man ja auch ein bischen spielen, z.B. einen https-Server. Dazu muss in der Config-Datei /usr/local/etc/apache22/httpd.conf die Zeile
... # Secure (SSL/TLS) connections Include etc/apache22/extra/httpd-ssl.conf ...
einkommentieren. Darin wird dann unter anderem festgelegt, wo Zertifikat (server.crt) und Schlüssel (server.key) hinterlegt werden. Die Erstellung des notwendigen SSL-Zertifikats und Schlüssels wird auf dieser Seite beschrieben. Außerdem wird der Port, Adresse usw. festgelegt. Damit das spielt, muss der Apache nur neu gestartet werden. Dazu muss dann aber die Passphrase des SSL-Schlüssels eingegeben werden. Damit der Apache auch automatisch hoch kommt ...
PHP
devel/pkg-config-0.22, textproc/libxml2, lang/php5
PGSQL-Jail: pgsql.mydomain.home (172.16.0.33)
Wie zuvor wird wieder ein neues Basis-Jail erzeugt und dann aus den Ports database/postgresql82-server installiert (devel/gmake, devel/gettext-0.16.1_3, database/postgresql82-client, devel/libtool, converters/libiconv kommen mit). Allerdings schlägt die Initialisierung der Datenbank mit /usr/local/etc/rc.d/postgresql initdb fehl.
FATAL: could not create semaphores: No space left on device
DETAIL: Failed system call was semget(1, 17, 03600).
HINT: This error does *not* mean that you have run out of disk space.
It occurs when either the system limit for the maximum number of semaphore sets (SEMMNI), or the system wide maximum number of semaphores (SEMMNS), would be exceeded. You need to raise the respective kernel parameter. Alternatively, reduce PostgreSQL's consumption of semaphores by reducing its max_connections parameter (currently 10).
The PostgreSQL documentation contains more information about configuring your system for PostgreSQL.
Erst nachdem jail_sysvipc_allow="YES" war ein /usr/local/etc/rc.d/postgresql initdb erfolgreich:
pgsql# /usr/local/etc/rc.d/postgresql initdb
The files belonging to this database system will be owned by user "pgsql".
This user must also own the server process.
The database cluster will be initialized with locale C.
creating directory /usr/local/pgsql/data... ok
creating directory /usr/local/pgsql/data/base... ok
creating directory /usr/local/pgsql/data/global... ok
creating directory /usr/local/pgsql/data/pg_xlog... ok
creating directory /usr/local/pgsql/data/pg_clog... ok
selecting default max_connections... 40
selecting default shared_buffers... 1000
creating configuration files... ok
creating template1 database in /usr/local/pgsql/data/base/1... ok
initializing pg_shadow... ok
enabling unlimited row size for system tables... ok
initializing pg_depend... ok
creating system views... ok
loading pg_description... ok
creating conversions... ok
setting privileges on built-in objects... ok
creating information schema... ok
vacuuming database template1... ok
copying template1 to template0... ok
Success. You can now start the database server using:
/usr/local/bin/postmaster -D /usr/local/pgsql/data
or
/usr/local/bin/pg_ctl -D /usr/local/pgsql/data -l logfile start
pgsql#
Besser ist es aber, direkt das via sysctl security.jail.sysvipc_allowed=1 zu setzen bzw. es in /etc/sysctl dauerhaft zu setzen.
Juli 2007: Eine neue Platte muss her (im Desktop-Rechner)
So langsam scheint die 80GB-Platte in meinem Desktop-Rechner zu sterben; immer mal wieder tauchen im Log Zeilen, wie diese auf:
Feb 24 00:51:06 worf kernel: ad2: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=93328032 Feb 24 00:51:06 worf kernel: g_vfs_done():ad2s3g[READ(offset=13625245696, length=16384)]error = 5 Feb 24 00:51:08 worf kernel: ad2: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=93328032 Feb 24 00:51:08 worf kernel: g_vfs_done():ad2s3g[READ(offset=13625245696, length=16384)]error = 5 Feb 24 00:51:11 worf kernel: ad2: FAILURE - READ_DMA status=51<READY,DSC,ERROR> error=40<UNCORRECTABLE> LBA=93328032 Feb 24 00:51:11 worf kernel: g_vfs_done():ad2s3g[READ(offset=13625245696, length=16384)]error = 5
Betroffen war meist die /usr/ports - speziell nach einem portupgrade - und viel beunruhigender /usr/home. Also besser neue Hardware besorgen.
Die neue Platte
Platte der Wahl war kurz entschlossen eine MAXTOR (ad2: 238475MB <MAXTOR STM3250820A 3.AAE> at ata1-master UDMA66) 250 GB mit 8 MB Cache. Da nur 8 Partitionen in ein Slice passen, wurden 2 Slices (25 GB und der Rest ca. 210 GB) angelegt:
# fdisk ad2
******* Working on device /dev/ad2 *******
parameters extracted from in-core disklabel are:
cylinders=484521 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=484521 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 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 63, size 51200031 (25000 Meg), flag 80 (active)
beg: cyl 0/ head 1/ sector 1;
end: cyl 1023/ head 11/ sector 57
The data for partition 2 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 51200094, size 437191971 (213472 Meg), flag 80 (active)
beg: cyl 1023/ head 255/ sector 63;
end: cyl 1023/ head 14/ sector 63
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>
ad2s1-Slice
Das erste Slice enthält eine 300MB-Partition (ad2s1d) für /, einen 1GB-SWAP-Bereich (ad2s1b), 300MB für (ad2s1e) /var und ad2s1f für den /usr-Bereich (s.u.). Bis auf den SWAP wird der Teil der Platte aber zunächst mal nicht genutzt, weil ich keine Lust hatte, das Basis-System mit umziehen zu lassen (zumindest den Grub in den Bootsektor zu basteln, hebe ich mir für eine bessere Gelegenheit auf; dann müssen auch die Partitionen noch umbenannt werden).
# bsdlabel ad2s1 # /dev/ad2s1: 8 partitions: # size offset fstype [fsize bsize bps/cpg] b: 2097152 614400 swap c: 51200031 0 unused 0 0 # "raw" part, don't edit d: 614400 0 4.2BSD 2048 16384 38408 e: 614400 2711552 4.2BSD 2048 16384 38408 f: 47874079 3325952 4.2BSD 2048 16384 28552
ad2s2-Slice
Das zweite Slice bekommt Partitionen für /usr/ports (ad2s2d), /usr/home (ad2s2e), /usr/media (ad2s2f, ein Datenbereich, der wohl eigentlich auch in $HOME gehört) (ad2s2g) und /usr/home2, das vielleicht, mal - wie beim Laptop - verschlüsselt wird (oder noch für ganz was anderes gedacht ist).
# bsdlabel ad2s2 # /dev/ad2s2: 8 partitions: # size offset fstype [fsize bsize bps/cpg] c: 437191971 0 unused 0 0 # "raw" part, don't edit d: 20971520 0 4.2BSD 2048 16384 28552 e: 209715200 20971520 4.2BSD 2048 16384 28552 f: 104857600 230686720 4.2BSD 2048 16384 28552 g: 101647651 335544320 4.2BSD 2048 16384 28552
Sollte die Platte mal das gesamte System beherbergen, braucht die natürlich eine "a"-Partition. Diese sollte sich genauso "installieren" lassen, wie beim DELL Inspiron 8100 , als die $HOME-Partition geteilt wurde, um einen Teil zu verschlüsslen, was natürlich auch beim IBM X24 der Fall ist.
GEOM-Label
Der Grund, warum ich hier auch mal was von meinem Desktop einfliessen lasse, ist, dass ich mich mit GEOM-Label beschäftigt habe. Dies erlaubt es, den Filesystemen ein Label zu verpassen und es über dieses anzusprechen. Der Vorteil ergibt sich, wenn man z.B. mehrere USB-Sticks einsetzt, die dann je nach Einsteckreihenfolge, als da0, da1 usw. erscheinen.
Um GEOM-Label nutzen zu können, muss das Modul geom_label.ko geladen sein: kldload geom_label. Befindet sich dann ein UFS auf dem Stick, kann man dem Filesystem direkt und dauerhaft ein Label verpassen:
# tunefs -L keys /dev/da0
Der Stick tritt dann im /dev-Baum als /dev/ufs/keys{cd} auf, so dass man ihn mittels
# mount /dev/ufs/keysd
einbinden kann - egal in welcher Reihenfolge man Sticks und externe Platten in's USB-Hub gestöpselt hat.
Normalerweise haben die Sticks jedoch ein MSDOS-Filesystem (was man aus Kompatibilitätsgründen auch so lassen sollte). Das kann natürlich mit Labels nichts anfangen (was kann MSDOSFS überhaupt?). Trotzdem bringt GEOM-Label hier auch etwas: der Stick taucht dann unter /dev/msdosfs/stick auf, so dass man wenigstens nach dem Filesystem unterscheiden kann.
Die /etc/fstab sieht dann so aus:
# # Device Mountpoint FStype Options Dump Pass# # ---------------------------------------------------------------------------- # Platte 1 (Master an IDE-0): /dev/ad0s1b none swap sw 0 0 #/dev/ad0s1b.eli none swap sw 0 0 /dev/ad0s1a / ufs rw 1 1 /dev/ufs/usr /usr ufs rw 2 2 /dev/ufs/backup /usr/Backup ufs rw 2 2 /dev/ufs/var /var ufs rw 2 2 # # Platte 2 (Master an IDE-1): /dev/ad2s1b none swap sw 0 0 #/dev/ad2s1b.eli none swap sw 0 0 /dev/ufs/home /home ufs rw 2 2 /dev/ufs/media /usr/media ufs rw 2 2 /dev/ufs/ports /usr/ports ufs rw 2 2 /dev/ufs/home2 /usr/home2 ufs rw 2 2 # # /tmp ins RAM md /tmp mfs rw,-s64m 2 0 # # CDROM-Laufwerke (SCSI): /dev/cd0 /cdrom cd9660 ro,noauto 0 0 /dev/cd1 /cdrom1 cd9660 ro,noauto 0 0 # # USB-Stick fuer GnuPG-Schluessel #/dev/da0s1c /mnt/keys ufs rw,noauto 0 0 /dev/ufs/keysd /mnt/keys ufs rw,noauto 0 0 # mein "iPod" von SAMSUNG /dev/da0s1 /mnt/ipod msdos rw,noauto,-u=photor 0 0 # USB-Platte als Backup-Medium /dev/da1s1 /mnt/USB-dos msdos rw,noauto,-u=photor 0 0 /dev/da1s2 /mnt/USB-ext2 ext2fs rw,noauto 0 0 /dev/da1s3e /mnt/USB ufs rw,noauto 0 0 # # procfs proc /proc procfs rw 0 0 linproc /compat/linux/proc linprocfs rw,noauto 0 0
Wenn dann alles gemountet ist, sagt mount das hier:
# mount /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ufs/usr on /usr (ufs, local, soft-updates) /dev/ufs/backup on /usr/Backup (ufs, local, soft-updates) /dev/ufs/var on /var (ufs, local, soft-updates) /dev/ufs/home on /usr/home (ufs, local, soft-updates) /dev/ufs/media on /usr/media (ufs, local, soft-updates) /dev/ufs/ports on /usr/ports (ufs, local, soft-updates) /dev/ufs/home2 on /usr/home2 (ufs, local, soft-updates) /dev/md0 on /tmp (ufs, local, soft-updates) procfs on /proc (procfs, local)
Die Mountpoints (bis auf /) sind jetzt den Labeln zugeordnet. Sollen jetzt die Partitionen auf der neuen Platte den Job machen, brauche ich - nach dem transfer der Daten - nur das Label der alten Partition zu löschen und dem neuen Filesystem das passende Label zu verpassen; ändern der /etc/fstab sollte nicht nötig sein. Nachteil: ich sehe jetzt nicht mehr, welche Partition jetzt wirklich verwendet wird. Man kann sich aber einfach mit glabel status eine Überblick verschaffen, welche Partition welchem Label zugeordnet ist:
# glabel status
Name Status Components
ufs/ports N/A ad2s2d
ufs/media N/A ad2s2f
ufs/home2 N/A ad2s2g
ufs/home N/A ad2s2e
ufs/usr N/A ad0s1e
ufs/var N/A ad0s1d
ufs/keys N/A da0s1
ufs/backup N/A ad0s1f
Eine ausführlichere Ausgabe bekommt man übrigens mit glabel list.
Der Teil-Umzug
Den Umzug habe ich mit dem /usr und /var probiert (/ ist ein zweiter Schritt; zu groß zum Laufenlernen).
-
Zuerst müssen die Daten umziehen. Dazu verwende ich das
erfolgreiche Duo dump -
restore:
# mount /dev/ad2s1e /mnt/DISK # cd /mnt/DISK # dump 0afL - /var | restore xf -
Die dump-Option -L bewirkt, dass zunächst ein Snapshot vom Filesystem gemacht wird und kopiert dann dieses. Zwar war der Rechner mit shutdown now in den Single-User-Mode versetzt. Aber die zu kopierende Partition war ja weiterhin ins System einegebunden. -
Label ("ufs/var") von ad0s1d löschen und
das ad2s2e verpassen:
# glabel destroy ad0s1d # glabel stop var # tunefs -L var ad2s2e
sollte das eigentlich machen. Aber leider wurden die Metadaten auf dem Filesystem von ad0s1d nicht geschrieben (eine entsprechende Warnung wurde angezeigt). Daher wurde beim reboot weiter die alte Partition gemountet. Das blieb auch nach mehreren Versuchen so. -
Als Ausweg ist mir dann eingefallen, statt das Label zu
löschen, der alten Platte ein anderes Label zu geben:
# tunefs -L varalt ad0s1d
Das überschreibt das alte Label und danach funktioniert alles, wie gewünscht; man hat halt zwei zusätzliche Label im System, die nicht gebraucht werden:# glabel status Name Status Components ufs/varalt N/A ad0s1d ufs/usralt N/A ad0s1e ufs/backup N/A ad0s1f ufs/var N/A ad2s1e ufs/usr N/A ad2s1f ufs/ports N/A ad2s2d ufs/home N/A ad2s2e ufs/media N/A ad2s2f ufs/home2 N/A ad2s2g
Bleibt noch, die /-Partition und natürlich den Bootsektor von ad0 nach ad2 zu transferieren (am liebsten auch wieder mit sysutils/grub darin, obwohl der neben den FreeBSD nur einen Eintrag für sysutils/memtest86 enthält). Dann kann die ad0-Platte raus und die neue wandert an ata0. Ob die alte Platte ganz rausfliegt oder für Experimente drin bleibt, entscheidet sich dann.
Juni 2007: Viele Kleinigkeiten
Nach langer Zeit mal wieder eine Nachricht hier auf der Seite. Seit dem letztem Eintrag hat sich an der Lappy-Installation nicht viel - und schon gar nichts grundlegendes - geändert. Dafür sind in der Zeit einige Kleinigkeiten angepasst und hingetunet worden.
ports-mgmt/portconf, um die Port-Konfiguration zu steuern
Relativ nervig finde ich es, wenn Ports bei jedem Update irgendwelche Parameter übergeben werden müssen und ich grundsätzlich nicht mehr weiß, welche denn nun wie definiert sein mussten, um nur das zu können, was ich wohl brauchen werde. Paradebeispiel ist wohl das Monster OpenOffice.org (editor/openoffice); wirklich genervt hat mich aber, dass nach jedem Update Fluxbox nichts mehr von der Imlib2 wissen wollte.
Portconf (ports-mgmt/portconf) wird in /etc/make.conf eingehängt und erlaubt es, Variablen in einem File /usr/local/etc/ports.conf zu definieren. Welche Variablen definiert werden können, schaut man am besten im entsprechenden Makefile nach. Der Syntax des Files sieht dann etwa so aus:
audio/grip-*: WITHOUT_CDPARANOIA=no|WITH_CDDA2WAV=yes databases/pgadmin3-*: WITHOUT_UNICODE=yes editors/openoffice.org-*: WITHOUT_MOZILLA|WITH_CUPS|WITHOUT_KDE emulators/qemu-*: WITH_KQEMU=yes graphics/xsane-*: WITH_GIMP=yes mail/exim*: WITHOUT_NIS=yes math/octave-*: WITH_ATLAS multimedia/mplayer-*: WITHOUT_NVIDIA=yes|WITH_DEBUG=no|WITHOUT_ARTS=yes sysutils/conky: WITH_XFT=yes|WITHOUT_SETI=yes|WITHOUT_OWN_WINDOW=yes x11-wm/fluxbox-devel: WITH_IMLIB2=yes
Distfile-Download mit wget
Da meine Internet-Anbindung manchmal zu wünschen läßt, ist der Download der Distfiles mit wget effektiver als mit fetch. Dazu wird in /etc/make.conf folgendes eingetragen:
# -- ==================================================================== -- # # -- wget statt fetch zum downloaden der ports benutzen. falls existiert -- # .if exists(/usr/local/bin/wget) DISABLE_SIZE= yes FETCH_CMD= /usr/local/bin/wget --continue --passive-ftp -t 2 -T 15 .endif # -- ==================================================================== -- #
Das ist nicht auf meinem Mist gewachsen. Leider weiß ich nicht mehr genau, wo ich es her habe.
Upgrade auf Xorg 7.2
Das war ein größeres Update und man sollte sich tunlichst an die Angaben und die Prozedur in /usr/ports/UPDATING halten. Trotzdem hatte ich ein paar Problemchen, die wohl daran lagen, dass ich nicht den vollständigen Meta-Port x11/xorg installiert hatte. Dadurch fehlten dann einige für Xorg lebenswichtige Ports. Also genau den nachinstallieren, was dazu führte, dass die Anzahl der Ports fast explodierte (immerhin: die Zahl bleibt "abzählbar") und ich jetzt, trotz der Modularisierung von Xorg, Treiber auch für die obskurste Grafikkarte installiert habe. Da bleibt wohl nur, demnächst mal auszumisten.
Nachtrag: genau das habe ich mittlerweile getan, womit sich im einem ersten Versuch 58(!) Ports einsparen ließen. Damit sich die überflüssigen xf86-video-*- und xf86-input-*-Ports per pkg_deinstall deinstallieren lassen, müssen die Meta-Ports xorg-7.2 und xorg-drivers-7.2 entfernt werden: von diesen hängen alle driver- und input-Ports ab; selbst wenn man jetzt eine Deinstallation erzwingt, würden die entfernten Ports beim nächsten portupgrade -a wieder installiert.
Entfernt wurden alle video-Ports bis auf:
xf86-video-apm-1.1.1 xf86-video-ati-6.6.3_2 xf86-video-chips-1.1.1 xf86-video-dummy-0.2.0 xf86-video-fbdev-0.3.1 xf86-video-glint-1.1.1_2 xf86-video-vga-4.1.0
Geblieben sind ebenfalls die input-Ports:
xf86-input-joystick-1.1.0 xf86-input-keyboard-1.1.1 xf86-input-mouse-1.1.2 xf86-input-void-1.1.0
Bei einigen weiß ich einfach nicht, ob sie gebraucht werden oder nicht. Es juckt mich in den Fingern, auch einiger der Fonts zu deinstallieren; aber einerseits weiß man nie, ob man nicht doch mal einen cyrilischen text darstellen muss, andererseits werden die Font-Ports nicht so oft geupdatet, so dass die Wartung nicht so aufwändig wird.
Epiphany
Epiphany ist ein kleiner netter Web-Browser. Ich konnte mich anfangs nur nicht mit seinem Bookmark-System anfreunden und bin bei der Suche nach was handlicherem als Firefox erstmal wieder bei Galeon gelandet - allerdings nicht lange.
Mittlerweile ist es genau das Bookmarksystem von Epiphany, was ich bei der Arbeit nicht mehr missen will: man muss sich nur erstmal daran gewöhnen - und natürlich die alte Bookmark-Sammlung in das Epiphany-System integrieren; das ist allerdings Handarbeit. Die Bedienung anschließend ist super simpel, weil man sich wirklich nicht mehr merken muss, wo man ein Lesezeichen abgeheftet hat.
Eigentlich würde ich konsequenterweise jetzt gerne den Groß-Port www/firefox von der Platte werfen (schon damit nicht bei jedem portupgrade -a die Sourcen gezogen werden müssen; und der Bau des Ports dauert ja auch). Leider benötigt www/epiphany aber Teile (wohl die Gecko-Rendering-Engine) aus dem Firefox-Paket. Hier wäre eine Modularisierung sinnvoll (Split in Gecko und Firefox-GUI z.B. - ich hab aber keine Ahnung, ob das so einfach zu trennen ist).
Windowmanager XFCE
Fluxbox wurde mir auf Dauer dann doch ein bischen altbacken. Da mir aber Gnome (x11/gnome2) (noch) zu gross und KDE (x11/kde3) zu gross und zu haesslich ist, scheint mir XFCE (x11-wm/xfce4) zusammen mit dem Filemanager Thunar (x11-fm/thunar) ein guter Kompromiss zu sein.
November 2006: OpenWRT auf FreeBSD compilieren
Nachdem der Oktober mehr der Pflege des Routers galt, nun wieder was FreeBSD-spezifisches: auf den Router läuft ja ein OpenWRT. Um nicht immer auf gelieferte Images angewiesen zu sein und vielleicht auch mal was beitragen zu können, wollte ich die Firmware selbst kompilieren. Obwohl mein ASUS Router eine mipsel-Architektur hat und OpenWRT auf Debian GNU/Linux basiert, kann das System auf dem FreeBSD cross-compiliert werden. Wie das wird auf dieser Seite beschrieben.
-
Zunächst werden die aktuellen Sourcen - und ich wollte
eigentlich die ganz aktuelle Version "Kamikaze" - aus
dem SVN von OpenWRT in das aktuell Directory (z.B.
~/OpenWRT/) ausgecheckt:
# svn co https://svn.openwrt.org/openwrt/trunk
löst das hier aus:# svn co https://svn.openwrt.org/openwrt/trunk A trunk/rules.mk A trunk/toolchain A trunk/toolchain/uClibc A trunk/toolchain/uClibc/config ... A trunk/package/linux-atm/Makefile A trunk/Makefile A trunk/README U trunk Checked out revision 5498. #
-
Nun sollte festgelegt werden, was alles gebaut werden
soll. Das geschieht mit dem vom Linux-Kernel bekannten
Befehl
# make menuconfig
Man bekommt ein sehr ähnlich strukturiertes Menu, welches es erlaubt, die benötigten Module und Treiber auszuwählen.OpenWrt Kamikaze/r5495 Configuration --------------------------------------------------------------------------------------- +----------------------------- OpenWrt Configuration ------------------------------+ | Arrow keys navigate the menu. <Enter> selects submenus --->. Highlighted | | letters are hotkeys. Pressing <Y> includes, <N> excludes, <M> builds as | | package. Press <Esc><Esc> to exit, <?> for Help, </> for Search. Legend: [*] | | built-in [ ] excluded <M> package < > package capable | | +------------------------------------------------------------------------------+ | | | Target System (Broadcom BCM47xx/53xx [2.4]) ---> | | | | [ ] Select all packages by default | | | | [ ] Advanced configuration options (for developers) ---> | | | | [ ] Build the OpenWrt SDK | | | | Target Images ---> | | | | Base system ---> | | | | Utilities ---> | | | | Libraries ---> | | | | Network ---> | | | | Kernel modules ---> | | | | Kernel drivers ---> | | | | --- | | | | Reset to defaults | | | | Load an Alternate Configuration File | | | | Save Configuration to an Alternate File | | | +------------------------------------------------------------------------------+ | +----------------------------------------------------------------------------------+ | <Select> < Exit > < Help > | +----------------------------------------------------------------------------------+
(die seltsamen Zeichen kommen daher, dass ich rxvt und nicht xterm verwende und die ASCII-Zeichen falsch interpretiert werden). Dannach sieht das Filesystem ~/OpenWRT/trunk/ wie folgt aus:# ls BSDmakefile docs/ target/ Config.in include/ tool_build/ LICENSE package/ toolchain/ Makefile rules.mk toolchain_build_mipsel/ README scripts/ tools/ dl/ staging_dir_mipsel/
-
Und dann wird mit einem make oder
- falls man mehr Infos braucht - mit
# make -V99
der ganze Prozess angeworfen. Zunächst wird die Toolchain wird gebaut, wozu einige Source-Archive aus dem Netz nachgeladen werden. Sollte die Verbindung zum Netz schlecht sein, holt man sie besser mit wget und packt sie manuell in's ~/OpenWRT/trunk/dl/ und wirft make erneut an. In diesem Directory hat sich einiges angesammelt:# ls -l ~/OpenWRT/trunk/dl/ total 154830 -rw-r--r-- 1 photor mafia 12549917 Nov 12 01:49 binutils-2.16.1.tar.bz2 -rw-r--r-- 1 photor mafia 81937 Nov 12 13:27 bridge-utils-1.0.6.tar.gz -rw-r--r-- 1 photor mafia 869561 Nov 12 13:29 broadcom-wl-4.80.17.0.tar.bz2 -rw-r--r-- 1 photor mafia 1404986 Nov 12 13:29 busybox-1.2.1.tar.bz2 -rw-r--r-- 1 photor mafia 227113 Nov 12 13:29 dnsmasq-2.33.tar.gz -rw-r--r-- 1 photor mafia 1473114 Nov 12 13:29 dropbear-0.48.1.tar.gz -rw-r--r-- 1 photor mafia 28193401 Nov 12 01:50 gcc-3.4.6.tar.bz2 -rw-r--r-- 1 photor mafia 31793160 Nov 12 01:50 gcc-4.0.2.tar.bz2 -rw-r--r-- 1 photor mafia 93646 Nov 12 01:50 genext2fs-1.4rc1.tar.gz -rw-r--r-- 1 photor mafia 19480 Nov 12 01:50 ipkg-utils-1.7.tar.gz -rw-r--r-- 1 photor mafia 191820 Nov 12 13:29 iptables-1.3.5.tar.bz2 -rw-r--r-- 1 photor mafia 31132159 Nov 12 13:24 linux-2.4.32.tar.bz2 -rw-r--r-- 1 photor mafia 41272919 Nov 12 13:24 linux-2.6.17.tar.bz2 -rw-r--r-- 1 photor mafia 194914 Nov 12 01:50 lzma432.tar.bz2 -rw-r--r-- 1 photor mafia 3476735 Nov 12 13:33 madwifi-0.9.2.tar.bz2 -rw-r--r-- 1 photor mafia 1335505 Nov 12 01:50 mtd_20050122.orig.tar.gz -rw-r--r-- 1 photor mafia 688092 Nov 12 13:31 ppp-2.4.3.tar.gz -rw-r--r-- 1 photor mafia 767189 Nov 12 01:49 sed-4.1.2.tar.gz -rw-r--r-- 1 photor mafia 384917 Nov 12 01:50 squashfs3.0.tar.gz -rw-r--r-- 1 photor mafia 1763847 Nov 12 01:50 uClibc-0.9.28.tar.bz2 -rw-r--r-- 1 photor mafia 254077 Nov 12 13:31 wireless_tools.28.tar.gz #
Beim ersten Durchlauf ist der Rechner nun eine geraume Zeit ausgelastet (ca. 3 Stunden). Der gesammte trunk-Zweig hat dann eine Größe von etwa 1.2GB. -
Die erzeugten Firmware-Dateien liegen unter
OpenWRT/trunk/bin/:
# ls -l OpenWRT/trunk/bin total 63300 -rw-r--r-- 1 photor mafia 3280896 Nov 11 01:36 openwrt-brcm-2.4-jffs2-128k.trx -rw-r--r-- 1 photor mafia 3280896 Nov 11 01:36 openwrt-brcm-2.4-jffs2-64k.trx -rw-r--r-- 1 photor mafia 2154496 Nov 11 01:36 openwrt-brcm-2.4-squashfs.trx -rw-r--r-- 1 photor mafia 3280924 Nov 11 01:36 openwrt-usr5461-jffs2-128k.bin -rw-r--r-- 1 photor mafia 3280924 Nov 11 01:36 openwrt-usr5461-jffs2-64k.bin -rw-r--r-- 1 photor mafia 2154524 Nov 11 01:36 openwrt-usr5461-squashfs.bin -rw-r--r-- 1 photor mafia 3280904 Nov 11 01:36 openwrt-wa840g-jffs2.bin -rw-r--r-- 1 photor mafia 2154504 Nov 11 01:36 openwrt-wa840g-squashfs.bin -rw-r--r-- 1 photor mafia 3280904 Nov 11 01:36 openwrt-we800g-jffs2.bin -rw-r--r-- 1 photor mafia 2154504 Nov 11 01:36 openwrt-we800g-squashfs.bin -rw-r--r-- 1 photor mafia 3280904 Nov 11 01:36 openwrt-wr850g-jffs2-128k.bin -rw-r--r-- 1 photor mafia 3280904 Nov 11 01:36 openwrt-wr850g-jffs2-64k.bin -rw-r--r-- 1 photor mafia 2154504 Nov 11 01:36 openwrt-wr850g-squashfs.bin -rw-r--r-- 1 photor mafia 3280928 Nov 11 01:36 openwrt-wrt54g-2.4-jffs2.bin -rw-r--r-- 1 photor mafia 2154528 Nov 11 01:36 openwrt-wrt54g-2.4-squashfs.bin -rw-r--r-- 1 photor mafia 3280928 Nov 11 01:36 openwrt-wrt54g3g-2.4-jffs2.bin -rw-r--r-- 1 photor mafia 2154528 Nov 11 01:36 openwrt-wrt54g3g-2.4-squashfs.bin -rw-r--r-- 1 photor mafia 3280928 Nov 11 01:36 openwrt-wrt54gs-2.4-jffs2.bin -rw-r--r-- 1 photor mafia 2154528 Nov 11 01:36 openwrt-wrt54gs-2.4-squashfs.bin -rw-r--r-- 1 photor mafia 3280928 Nov 11 01:36 openwrt-wrt54gs_v4-2.4-jffs2.bin -rw-r--r-- 1 photor mafia 2154528 Nov 11 01:36 openwrt-wrt54gs_v4-2.4-squashfs.bin -rw-r--r-- 1 photor mafia 3280928 Nov 11 01:36 openwrt-wrtsl54gs-2.4-jffs2.bin -rw-r--r-- 1 photor mafia 2154528 Nov 11 01:36 openwrt-wrtsl54gs-2.4-squashfs.bin drwxr-xr-x 2 photor mafia 3072 Nov 11 01:36 packages/ #
und die mit ipkg nachinstallierbaren Packages in dem Ordner OpenWRT/trunk/bin/packages/:# ls -l ~/OpenWRT/trunk/bin/packages/ total 3238 -rw-r--r-- 1 photor mafia 26928 Nov 11 01:36 Packages -rw-r--r-- 1 photor mafia 19914 Nov 11 01:25 base-files-brcm-2.4_8-5495_mipsel.ipk -rw-r--r-- 1 photor mafia 9837 Nov 11 00:53 bridge_1.0.6-1_mipsel.ipk -rw-r--r-- 1 photor mafia 310036 Nov 11 00:58 busybox_1.2.1-1_mipsel.ipk -rw-r--r-- 1 photor mafia 55887 Nov 11 01:00 dnsmasq_2.33-1_mipsel.ipk -rw-r--r-- 1 photor mafia 98736 Nov 11 01:03 dropbear_0.48.1-1_mipsel.ipk -rw-r--r-- 1 photor mafia 40775 Nov 11 01:05 iptables_1.3.5-1_mipsel.ipk -rw-r--r-- 1 photor mafia 687 Nov 11 01:26 kernel_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 9795 Nov 11 01:07 kmod-arptables_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 36773 Nov 11 01:08 kmod-ax25_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 328882 Nov 11 01:25 kmod-brcm-wl_2.4.32+4.80.17.0-1_mipsel.ipk -rw-r--r-- 1 photor mafia 20369 Nov 11 01:08 kmod-crypto_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 8011 Nov 11 01:07 kmod-diag_1+2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 93261 Nov 11 01:07 kmod-fs-cifs_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 26793 Nov 11 01:07 kmod-fs-ext2_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 76095 Nov 11 01:07 kmod-fs-ext3_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 32037 Nov 11 01:07 kmod-fs-vfat_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 7353 Nov 11 01:07 kmod-gre_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 78242 Nov 11 01:08 kmod-ide-core_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 10102 Nov 11 01:08 kmod-ide-pdc202xx_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 26234 Nov 11 01:07 kmod-ip6tables_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 3585 Nov 11 01:07 kmod-ipt-conntrack_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 15284 Nov 11 01:07 kmod-ipt-extra_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 14453 Nov 11 01:07 kmod-ipt-filter_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 3924 Nov 11 01:07 kmod-ipt-imq_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 12355 Nov 11 01:07 kmod-ipt-ipopt_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 1607 Nov 11 01:07 kmod-ipt-ipsec_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 3366 Nov 11 01:07 kmod-ipt-nat_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 30771 Nov 11 01:07 kmod-ipt-nathelper_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 6078 Nov 11 01:07 kmod-ipt-queue_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 3675 Nov 11 01:07 kmod-ipt-ulog_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 118223 Nov 11 01:07 kmod-ipv6_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 9255 Nov 11 01:08 kmod-loop_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 25368 Nov 11 01:26 kmod-ppp_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 9115 Nov 11 01:26 kmod-pppoe_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 75171 Nov 11 01:07 kmod-sched_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 4742 Nov 11 01:08 kmod-soundcore_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 13568 Nov 11 01:08 kmod-switch_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 5071 Nov 11 01:07 kmod-tun_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 44933 Nov 11 01:08 kmod-usb-core_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 14008 Nov 11 01:08 kmod-usb-ohci_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 7738 Nov 11 01:08 kmod-usb-printer_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 93325 Nov 11 01:08 kmod-usb-storage_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 21274 Nov 11 01:08 kmod-usb-uhci_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 15637 Nov 11 01:08 kmod-usb2_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 6506 Nov 11 01:08 kmod-videodev_2.4.32-brcm-1_mipsel.ipk -rw-r--r-- 1 photor mafia 6698 Nov 11 01:08 kmod-wlcompat_2.4.32+brcm-4_mipsel.ipk -rw-r--r-- 1 photor mafia 23395 Nov 11 01:25 libgcc_3.4.6-8_mipsel.ipk -rw-r--r-- 1 photor mafia 477654 Nov 11 01:18 libopenssl_0.9.8d-1_mipsel.ipk -rw-r--r-- 1 photor mafia 4993 Nov 11 01:18 mtd_4_mipsel.ipk -rw-r--r-- 1 photor mafia 75670 Nov 11 01:06 nas_4.80.17.0-1_mipsel.ipk -rw-r--r-- 1 photor mafia 15415 Nov 11 01:06 nvram_1_mipsel.ipk -rw-r--r-- 1 photor mafia 134543 Nov 11 01:18 openssl-util_0.9.8d-1_mipsel.ipk -rw-r--r-- 1 photor mafia 10594 Nov 11 01:24 ppp-mod-pppoe_2.4.3-7_mipsel.ipk -rw-r--r-- 1 photor mafia 103483 Nov 11 01:24 ppp_2.4.3-7_mipsel.ipk -rw-r--r-- 1 photor mafia 194915 Nov 11 01:25 uclibc_0.9.28-8_mipsel.ipk -rw-r--r-- 1 photor mafia 151145 Nov 11 01:25 wireless-tools_28-1_mipsel.ipk -rw-r--r-- 1 photor mafia 61982 Nov 11 01:25 wl_4.80.17.0-1_mipsel.ipk -rw-r--r-- 1 photor mafia 11842 Nov 11 01:25 wlc_4.80.17.0-1_mipsel.ipk -rw-r--r-- 1 photor mafia 35888 Nov 11 01:09 zlib_1.2.3-3_mipsel.ipk #
Mir stellt sich an dem Punkt nur die Frage, warum alle Packages gebaut wurden, obwohl ich einige definitiv abgewählt hatte. Eher aus Bequemlichkeit (weil so vorkonfiguriert) wir der Kernel 2.4.XX verwendet. Nach der Umstellung auf Kernel 2.6.XX
OpenWrt Kamikaze/r5495 Configuration
---------------------------------------------------------------------------------------
+-------------------------- Target System ---------------------------+
| Use the arrow keys to navigate this window or press the hotkey of |
| the item you wish to select followed by the <SPACE BAR>. Press |
| <?> for additional information about this option. |
| +----------------------------------------------------------------+ |
| | ( ) AMD Alchemy AUxx [2.6] | |
| | ( ) Aruba [2.6] | |
| | ( ) Broadcom BCM47xx/53xx [2.4] | |
| | (X) Broadcom BCM47xx/53xx [2.6] | |
| | ( ) Intel XScale IXP4xx [2.6] | |
| | ( ) Magicbox [2.6] | |
+ +--------------------v(+)----------------------------------------+ |
+--------------------------------------------------------------------+
| <Select> < Help > |
+--------------------------------------------------------------------+
compilierte das Ganze leider nicht mehr durch. Das könnte daran liegen, dass ein make clean nicht reicht, die Umgebung für eine Neucompilierung zu reinigen (make distclean ist auf jeden Fall zu viel; es löscht auch alle schon gesaugte Source-Archive - Mist!). Befehl der Wahl dafür ist wohl make dirclean.
Und: natürlich ist "Kamikaze" die absolute "CURRENT"-Variante (AKA "bleeding edge"). Das kann bedeuten, dass das Repository in einem Zustand ist, in dem es sich nicht mal durch-compilieren lässt. Konsequenzen:
-
Im Zweifelsfall also einige Zeit warten und nochmal auschecken:
# cd ~/OpenWRT/ # svn co https://svn.openwrt.org/openwrt/trunk
Vielleicht geht es dannach. - wenn's erstmal durchcompiliert, nicht neu auschecken, solange es nicht wirklich Not tut.
Fazit
Ist ja schon ein spannendes Ding, dass sich ein fremdes Betriebssystem für eine vollkommen andere Architektur compilieren lässt.
Nachtrag
Kurze Zeit später erforderte die Cross-Compiling-Prozedur explizit das GNUautoconf-Tool, was zwar prinzipiell im Portstree von FreeBSD existierte, aber sich nicht mit einigen installierten Ports vertrug. Damit war dann leider die Installation von Debian auf der Testpartition erforderlich, um auch weiterhin OpenWRT selbst compilieren zu können. Schade, dass das nicht mehr unter FreeBSD geht.
September 2006: OLSR-Daemon macht Probleme auf FreeBSD
Ich nehme am Opennet in Rostock mit einem stationären Knoten teil. Zusätzlich dazu würde ich gerne meinen Laptop als mobile Station nutzen. Dazu muss ein spezieller Routing-Daemon auf dem Laptop laufen, der mit den anderen Knoten kommuniziert, so dass diese untereinander ihre Kenntnisse über Routen im WLAN-Netz austauschen können.
Auf dem ASUS-Router läuft der OLSR-Daemon (Optimized Link State Routing) unter OpenWRT - einem Linux-Abkömmling für Embedded Systems. Daher muss auch auf dem Laptop OLSRd laufen, so dass er sich als Knoten in das Netz einfügt und die Informationen über die momentane Netztopoligie zu bekommen. Der OLSR-Daemon findet sich in den Port unter net/olsrd. Er lässt sich auch wie immer installieren und die Konfiguration ist kein großes Problem - die ist im Opennet-eigenen Wiki gut beschrieben.
Da der OLSRd nicht bei jedem Booten automatisch gestartet werden soll, wird erstmal nichts in /etc/rc.conf eingetragen. Um den Daemon von Hand zu starten, kann man
# /usr/local/etc/rc.d/olsrd forcestart
nutzen. Der Daemon startet und bindet sich an das WLAN-Interface wi0 - so wie im config-File angegeben. Die Routen werden aus dem Netz übernommen und können im Web-Interface kontrolliert (ein entsprechendes Plug-in wird im Package mitgeliefert) bzw. beobachtet werden. Gut soweit.
In einem nächsten Schritt wird ein OpenVPN- Tunnel im WLAN vom lokalen wi0-Interface (bzw. den stationären AP) zum Gateway-Rechner aufgebaut und dabei die Default-Route durch diesen Tunnel gelegt (die allermeisten Pakete sollen ja raus in die weite Welt; die Pakete, die innerhalb des Opennets bleiben sollen, finden expliziete Routen direkt in der Tabelle, die der OLSRd liefert). OpenVPN hat in diesem Zusammenhang mehrere Aufgabe:
- wird der Traffic auf der allen zugänglichen Funkstrecke verschlüsselt - und zwar ordentlich und stark, und nicht so halbherzig, wie mit WEP (WPA ist nicht möglich, da auch alte WLAN-Hardware unterstützt werden soll). Und
- lässt sich so der Zugang zum Netz bzw. die Nutzung der Gateways durch die Erteilung von Zertifikaten etwas regulieren (ob und in welchem Ausmaß man das will, wird aktuell im Verein diskutiert).
Das funktioniert auch - allerdings nur eine gewisse Zeit. Dann aber - nach etwa 10 Minuten - wird die Default-Route vom Tunnel weg auf den nächsten erreichbaren stationären Knoten (meist mein eigener AP) gebogen, weil diese durch den OLSRd die beste Bewertung bekommt. Damit laufen die Pakete leider den falschen Weg und kommen nicht mehr aus dem WLAN-Netz in das die Welt-weite-Web heraus. Offensichtlich löscht der OLSRd die Default-Route bzw. überschreibt sie. Das ist schlecht.
Die Default-Route müsste von der Verwaltung durch OLSRd ausgeschlossen werden. Bloß wie, ist mir noch nicht klar.
Juni/Juli 2006: Eine Kindersicherung
Da ich den DELL meinen Nichten vermachen will und die wahrscheinlich recht bald das Stöbern im Internet anfangen werden, soll da ein Content-Filter drauf - der DELL wird allerdings ein Ubuntu bekommen, da ich die Hoffnung habe, dass sie sich vielleicht dafür interessieren. Damit die Kleinen aber nicht gleich beim Spielen in die dreckigsten Ecken des Web-Spaces geraten eben ein Filter.
Interessanterweise gibt es recht wenige fertige OpenSource-Lösungen dafür; ich bin bei der Suche nach einem Filter auf DansGuardian gestoßen, das für den privaten Gebrauch kostenlos ist. Auf dem IBM will ich diese Filterei mal testen.
Squid-Installation
DansGuardian setzt auf www/squid auf. Also wird, um damit erstmal ein bischen rumzuspielen, der bisherige Web-Proxy www/wwwoffle deinstalliert.
Installation von Squid geschieht wie immer aus den Ports mit portinstall www/squid. Die zugehörigen Konfigurationsfiles liegen dannach in /usr/local/etc/squid/, die auch im Wesentlichen übernommen werden können.
Bevor der Squid-Daemon gestartet werden kann, muss noch in /etc/rc.conf eine Zeile
squid_enable="YES"
eingetragen werden (und eventuell noch Flags, die dem Daemon mitgegeben werden sollen). Ein
# /usr/local/etc/rc.d/squid start
führt trotzdem noch nicht direkt zum Erfolg, da vorher noch mit
# /usr/local/sbin/squid -z
die Cache-Directory-Struktur anzulegen ist. Anschließend lässt sich Squid starten. Ist dann im Firefox der Eintrag für WWWoffle durch den für Squid als Proxy ersetzt - de facto muss nur der Port von 8080 in 3128 geändert werden - sollte sich die erste Web-Seite laden lassen.
Leider doch zu schnell geschossen: per Default ist die in der /usr/local/etc/squid/squid.conf ersteinmal jeglicher Zugriff verboten; es muss zunächst eine ACL-Regel definiert werden. Diese hier reicht, um zunächst mal analog zu WWWoffle Surfen zu können
acl our_networks src 192.168.0.0/24 172.16.0.0/16 http_access allow our_networks
Um aber alle Features, die ich beim WWWoffle eingestellt hatte (z.B. kein cachen von Foren), zu nutzen, ist noch einiges an Feintuning in der squid.conf nötig. Ebenso ist die Verwaltung und Wartung des Cache-Directories nicht so simpel wie beim WWWoffle; da ist noch was zu tun.
SquidGuard
Ein erstes Filterprogramm - zu finden in den Ports - ist www/squidguard und soll zunächst mal ausprobiert werden. Nach der Installation finden sich zusätzliche Dateien im Squid-Pfad /usr/local/etc/squid/.
Vom SquidGuard-Entwicklerteam gibt es bereits zusammengestellte Blacklists, die sich auf der Squidguard-Homepage finden, und vom Port unter /var/db/squidGuard abgelegt werden, so dass ein gewisser Grundschutz sofort gegeben ist. Die Listen der verbotenen URLs sind in verschiedene Kategorien eingeteilt, so dass im squidGuard.conf für unterschiedliche Benutzergruppen auch verschiedene Tabus ausgesprochen werden können.
Damit SquidGuard seine Aufgabe übernehmen kann, muss im squid.conf ein redirector_program definiert werden:
redirect_program /usr/local/bin/squidGuard
Tut es aber nicht so richtig! Jedenfalls komme ich auf einer der Seiten, die in der Blacklist-DB aufgeführt ist, ran. Ein Blick in das Log-File von Squid zeigt, dass SquidGuard in den "emergency mode" geht - das heißt er schaltet auf Durchzug:
# less /usr/local/squid/logs/cache.log ... 2006/07/04 19:31:16| Process ID 28555 2006/07/04 19:31:16| With 7296 file descriptors available 2006/07/04 19:31:16| DNS Socket created at 0.0.0.0, port 61014, FD 5 2006/07/04 19:31:16| Adding nameserver 192.168.0.250 from /etc/resolv.conf 2006/07/04 19:31:16| Adding nameserver 192.168.0.254 from /etc/resolv.conf 2006/07/04 19:31:16| helperOpenServers: Starting 5 'squidGuard' processes 2006-07-04 19:31:16 [28556] (squidGuard): can't write to logfile /var/log/squidGuard.log 2006-07-04 19:31:16 [28556] init domainlist /var/db/squidGuard/ads/domains 2006-07-04 19:31:16 [28556] /var/db/squidGuard/ads/domains: Permission denied 2006-07-04 19:31:16 [28556] going into emergency mode 2006-07-04 19:31:16 [28557] (squidGuard): can't write to logfile /var/log/squidGuard.log 2006-07-04 19:31:16 [28557] init domainlist /var/db/squidGuard/ads/domains 2006-07-04 19:31:16 [28557] /var/db/squidGuard/ads/domains: Permission denied 2006-07-04 19:31:16 [28557] going into emergency mode 2006-07-04 19:31:16 [28559] (squidGuard): can't write to logfile /var/log/squidGuard.log 2006-07-04 19:31:16 [28559] init domainlist /var/db/squidGuard/ads/domains 2006-07-04 19:31:16 [28559] /var/db/squidGuard/ads/domains: Permission denied 2006-07-04 19:31:16 [28559] going into emergency mode 2006-07-04 19:31:16 [28558] (squidGuard): can't write to logfile /var/log/squidGuard.log
Die Zeilen darüber zeigen, dass SquidGuard weder in sein Log-File schreiben, noch die Blacklist-Datenbank lesen kann - Permission denied. Scheint somit ein Rechte-Problem zu sein. Beispielsweise gehören die Datenbank-Files dem User nobody und der Gruppe nogroup:
# ll /var/db/squidGuard/ads/ total 32 -r-xr-x--- 1 nobody nogroup 3788 Dec 18 2001 domains -rw-rw---- 1 nobody nogroup 16384 Jun 28 16:05 domains.db -r-xr-x--- 1 nobody nogroup 2127 Dec 18 2001 urls -rw-rw---- 1 nobody nogroup 8192 Jun 28 16:05 urls.db
Squid läuft jedoch unter der UID squid (ist so im squid.conf angeben bzw. ist default), so dass die Files nicht mal lesend zu erreichen sind; die Beschwerde ist korrekt.
Aus Sicherheitsgründen will ich nichts an den Rechten der Files ändern (0666 oder 0777 für die Directories würde ja erstmal helfen, öffnet aber unter Umständen ein riesen Loch). Also bleibt nur, sich auf einen der "ordentlichen" User zu einigen - squid erscheint mir gut und sinnvoll.
# chown squid:squid /var/log/squidGuard.log # chown -R squid:squid /var/db/squidGuard
Dannach funktionierte das Duo Squid und SquidGuard so wie erwartet: Ansurfen einer verbotenen Site zeigt die im squidGuard.conf-File angegebene redirect-Seite (hier eine vom lokal laufenden Apache gelieferte Seite):
acl {
default {
pass !ads !aggressive !audio-video !drugs !gambling !hacking !mail !porn !proxy !violence !warez !in-addr any
redirect http://localhost/Blocked.html
}
}
Beim Test wurden brav die die bösen und dreckigen Seiten geblockt. Da ich zum Debugging (mich selbst muss ich ja nicht kontrollieren) SquidGuards Logging aktiviert hatte, konnte ich genau sehen, aus welcher Blacklist die gesperrte Site stammt.
# ll /var/log/squidGuard/ total 2 -rw-r--r-- 1 squid squid 0 Jul 8 00:13 ads.log -rw-r--r-- 1 squid squid 0 Jul 8 00:13 aggressive.log -rw-r--r-- 1 squid squid 0 Jul 8 00:13 audio-video.log -rw-r--r-- 1 squid squid 0 Jul 8 00:13 drugs.log -rw-r--r-- 1 squid squid 115 Jul 8 00:16 gambling.log -rw-r--r-- 1 squid squid 0 Jul 8 00:13 hacking.log -rw-r--r-- 1 squid squid 0 Jul 8 00:13 mail.log -rw-r--r-- 1 squid squid 0 Jul 8 00:13 porn.log -rw-r--r-- 1 squid squid 0 Jul 8 00:13 proxy.log -rw-r--r-- 1 squid squid 0 Jul 8 00:13 violence.log -rw-r--r-- 1 squid squid 0 Jul 8 00:13 warez.log worf# less /var/log/squidGuard/gambling.log 2006-07-08 00:16:20 [61990] Request(default/gambling/-) http://www.casino.com/ 172.16.0.2/Worf.mydomain.home - GET
Interessanterweise wird Google als Porno-Seite eingestuft und geblockt - Google sollte sich Gedanken um sein Image machen.
Um für unterschiedliche User auf dem System verschiedene Filterregeln definieren zu können, muss Squid Informationen über den Seite-anfordernden Nutzer an SquidGuard liefern. Dies geschieht über den ident-Mechanismus. Dann können im Config-File ACLs für User oder User-Gruppen (z.B. die Eltern) mit weitergehenden Rechten definiert werden. Allerdings wird erstmal keine Information zum aufrufenden User mitgegeben. Da wo eigentlich der User im Log auftauchen müsste, steht leider nur ein -.
Damit dieser Mehanismus funktioniert, muss zum einen Squid mit der SQUID_IDENT-Option compiliert sein (lässt sich während der Installation oder mit make configure einstellen) und zum anderen muss im squid.conf eine ACL definiert werden, die ein ident verlangt; z.B. ganz allgemein:
acl idents ident REQUIRED ... http_access allow idents
Es können natürlich auch kompliziertere Regeln definiert werden, um z.B. bestimmte User direkt ganz auszuschliessen (das wollte ich aber SquidGuard überlassen). Jetzt tauchen im /usr/local/squid/logs/cache.log Einträge der folgenden Form auf, womit auch die SquidGuard-Regeln arbeiten:
1153245414.989 1832 172.16.0.2 TCP_MISS/200 5313 GET http://www.google.de/search? photor DIRECT/66.249.85.99 text/html 1153245415.724 370 172.16.0.2 TCP_REFRESH_HIT/200 4981 GET http://www.google.de/images/logo_sm.gif photor DIRECT/66.249.85.104 image/gif 1153245416.016 369 172.16.0.2 TCP_REFRESH_HIT/200 646 GET http://www.google.de/intl/de/nav_page.gif photor DIRECT/66.249.85.99 image/gif 1153245416.102 454 172.16.0.2 TCP_REFRESH_HIT/200 649 GET http://www.google.de/intl/de/nav_current.gif photor DIRECT/66.249.85.104 image/gif 1153245416.243 518 172.16.0.2 TCP_REFRESH_HIT/200 1786 GET http://www.google.de/intl/de/nav_next.gif photor DIRECT/66.249.85.104 image/gif 1153245416.297 280 172.16.0.2 TCP_REFRESH_HIT/200 5750 GET http://www.google.de/images/t_de.gif photor DIRECT/66.249.85.99 image/gif 1153245418.997 3290 172.16.0.2 TCP_REFRESH_HIT/200 1307 GET http://www.google.de/intl/de/nav_first.gif photor DIRECT/66.249.85.99 image/gif
Der Aufruf zum obigen Log-Eintrag war eine GOOGLE-Anfrage bei aktiviertem SquidGuard mit dieser squidGuard.conf
Ich hoffe jetzt nur, es sieht sich keiner die Logs bei meinem "Internet Service Provider" an - schließlich musste ich einige zweifelhafte Seiten ansurfen, um den Tintenfisch-Beschützer zu testen - und wenn der nicht zuschlägt ...
Jetzt fehlen nur noch ständig und automatisch aktuallisierte, dazu noch gut gewartete Blacklists, sowie eine Einspielprocedur, die auch ein Laie bedienen kann.
DansGuardian
Während SquidGuard angeforderte Web-Seiten nur nach der URL filtert, soll DansGuardian diese auch anhand von Inhalten sperren können. Dazu wird DansGuardian quasi zwischen Squid als Proxy und den Browser eingeschleift.
Obwohl in den Run-Dependencies ausdrücklich Apache 1.3 genannt wird, installiert sich www/dansguardian mit dem bereits vorhandenen www/apache22 ohne Mecker.
# make search name=dansguardian display=path,info,rdeps Path: /usr/ports/www/dansguardian Info: A fast, feature-rich web content filter for Squid proxy servers R-deps: apache-1.3.36 expat-2.0.0_1 perl-5.8.8 squid-2.5.14_1
Damit DansGuardian nun auch brav bei jedem Booten automatisch startet, gehört - wie üblich - ein Eintrag in die /etc/rc.conf:
dansguardian_enable="YES"
Handstart - auch wie üblich - mit: /usr/local/etc/rc.d/dansguardian [start|forcestart] Vorher steht aber noch die ...
Konfiguration
... an. Squid liefert die Seiten an Port 3128 an DansGuardian; bietet sie dann an Port 8080 dem Browser an; dies ist die Defaulteinstellung, die aber im Config-File angepasst werden kann:
... # the port that DansGuardian listens to. filterport = 8080 ... # the port DansGuardian connects to proxy on proxyport = 3128 ...
Um ein Umgehen von DansGuardian zu verhindern, müssen die entsprechenden Ports (z.B. 80 und 8080) für HTTP-Anfragen von innen geschlossen werden, so dass alle Webseiten über das Gespann DansGuardian/Squid laufen müssen.
Ebenfalls konfigurierbar sind die diversen Files mit den erlaubten und verbotenen Web-Sites, Phasen und Worten. Die lasse ich aber erstmal da, wo die Installation die hingepackt hat; für's erste tun es mal die mitgelieferten (Auszug aus der /usr/local/etc/dansguardian/dansguardian.conf):
languagedir = '/usr/local/etc/dansguardian/languages' language = 'german' loglocation = '/var/log/dansguardian.log' filtergroupslist = '/usr/local/etc/dansguardian/filtergroupslist' bannediplist = '/usr/local/etc/dansguardian/bannediplist' exceptioniplist = '/usr/local/etc/dansguardian/exceptioniplist' banneduserlist = '/usr/local/etc/dansguardian/banneduserlist' exceptionuserlist = '/usr/local/etc/dansguardian/exceptionuserlist'
Entweder kann das mitgelieferte cgi-Script in das entsprechende Directory des Apache kopiert und der Pfad im dansguardian.conf vermerkt:
accessdeniedaddress = 'http://localhost/cgi-bin/dansguardian.pl'
Dann muss allerdings der auch der
reportinglevel = 2
gesetzt sein. Man kann es auch gleich kindgerecht und in der Sprache anpassen.
Der vielleicht bessere Weg ist, den reportinglevel = 3 gesetzt lassen und das Template /usr/local/etc/dansguardian/language/german/template.html (Sprache ist ja auf german eingestellt) anzupassen. Wie, das lässt sich leicht aus dem mitgelieferten File lesen.
Betrieb
Blacklists findet man unter einigen auf der DansGuardian-Homepage Interessant ist, dass diese teilweise von DansGuardian selbst gefilter wird. Und natürlich sind die Lizenzbedingungen zu beachten.
Noch etwas ist erwähnenswert: DansGuardian ist dem SquidGuard vorgeschaltet. Das heißt, beide lassen sich schlecht gemeinsam betreiben (fragt sich, ob das sinnvoll wäre). SquidGuard sieht so nämlich immer nur Anfragen des Users, unter dem DansGuardian läuft; in meinem Fall ist das nobody (Nein! Nicht gespielt von Terence Hill). So kann der Tintenfisch-Wächter nicht sinnvoll filtern.
Schluss-Bemerkung
Zum Abschluss ein paar Gedanken zu dem ganzen Vorhaben.
- Die anfängliche Recherche hat zu meinem Erstaunen ergeben, dass es kaum eine brauchbare Web-Filterlösung gibt, die sich einfach installieren, einfach konfigurieren oder warten lässt. Es ist kaum vorstellbar, dass meine Schwester bzw. mein Schwager (beide mit eher geringen Computerkenntnissen) die beiden oben beschriebenen Filter installieren oder konfigurieren sollen.
- Für die Wartung (sprich die regelmäßige Aktualisierung der Blacklists, das unkomplizierte Definieren von eigenen Black- und Whitelists) werde ich mir wohl noch etwas überlegen müssen.
- Warum gibt es eigentlich keine wirklich out-of-the-box brauchbare Web-Content-Filter-Lösung? Ist der Schutz der Kinder vor dem ganzen Netz-Dreck so unwichtig. Dagegen finden sich ausreichend Lösungen für Web-Cams, Bezahlsysteme etc; das Betreiben solcher Dreckschleudern ist also kein Problem (Anleitungen gibt's dafür wohl auch genug). Das sagt was aus! (Ach ja: Disclaimer beachten. )
Und ganz zum Schluss
Da das Ganze jetzt tut, wie es soll, wird es abgeschaltet: dansguardian_enable="NO" bzw. redirect_program /usr/local/bin/squidGuard im squid.conf auskommentieren. Ich brauche mich selbst ja nicht zu schützen (ich kann ja mit Filter nicht mal mein geliebtes SR500-Forum lesen - wegen zu scharfer Kraftausdrücke wohl).
Die ganze Konfiguration geht aber jetzt über auf den DELL Laptop.
Juni 2006: Schlaf, mein Kindlein schlaf
Wichtig für einen mobilen Rechner ist mir, dass ich den mal eben auspacken, was machen und dann wieder wegpacken kann. Und je schneller desto besser. Dafür bietet sich ein Suspend-to-RAM an; der Rechner wird einmal gebootet und bleibt bereit; das Schlafen-legen und Aufwachen geht wesentlich fixer als gleich das ganze System neu zu starten.
Praktischerweise sollte ein Suspend einfach durch Schließen des Deckels ausgelöst werden. Aber den einfach so zuklappen bringt gar nichts; sogar das TFT-Hintergrundlicht bleibt an.
An der Stelle habe ich ein Suche gestartet und diese Seiten der BSD-Crew Dresden gefunden. Der Autor beschreibt sehr gut, wie sich ein Thinkpad schlafen legen lässt.
Meine einzige Änderung betraf das /etc/rc.resume-Script in dem das sysutils/radeontool den DAC und die Displaybeleuchtung wieder einschalten musste:
/usr/local/bin/radeontool dac on /usr/local/bin/radeontool light on
am Ende eingefügt, reicht dafür eigentlich aus. Deckel schließen und der Rechner schläft tatsächlich ein (Display dunkel, Platte schaltet sich aus, Pieps) und Deckel wieder auf: Licht an, Platte startet und Aktivität drauf, dann ein Pieps. Trotzdem bleibt der Schirm dunkel. Ein Wechsel auf die Konsole und zurück reicht, um wieder ein voll sichtbares X zu haben. Das Problem ist offensichtlich bekannt (wie mir der Autor aus der BSD-Crew schrieb) und die Linuxer haben wohl ein eigens dafür geschriebenes Tool. vielleicht reicht es einmal xrefresh aufzurufen.
Was sonst noch passierte
Für Mutt habe ich mir Profile geschrieben, so dass ich für Privatmails eine andere (Mail-)Identität habe als in den diversen Mailinglisten. Hier mal eine anonymisierte muttrc und ein entsprechendes Profile-File dazu.
Mai 2006: Installation
BIOS-Einstellungen
- BIOS-Version 1.26 (1DET64WW)
- Serial Port: Basic I/O 3F8, IRQ 4
- Infrared: Basic I/O 2F8, IRQ 3, DMA 3
- Parallel Port (Bi-directional): Basic I/O 3BC, IRQ 7
- USB ("Allows to boot with USB-Diskette or USB-CDROM drive")
FreeBSD 6 soll drauf
Da ich meine FreeBSD 6-CDs verliehen (oder einfach verlegt) hatte, hab ich erstmal das Basissystem von Version 5 installiert. Die Festplatte hab ich analog zum DELL Inspiron partitioniert, wobei auf der 1. Partition noch ein DOS-Rest rumlungert. Und es sind wieder ca. 8 GB am Ende der Platte frei für ein Testsystem. Die Aufteilung der FreBSD-Partition entspricht ebenfalls der des DELL; $HOME bekommt direkt einen ver- und einen unverschlüsselten Teil.
Die 5er-Basisinstallation habe ich dann über das Netz mittels cvsup, make buildworld, ..., make installkernel und nicht zu vergessen mergemaster geupdatet. Das verlief auch ohne Probleme ( vgl. Inspiron ). Das war auch gleich ein Test für die Hardware.
Anschließend kommen dann die Gebrauchspakete (etwa 450), unter anderem x11/xorg mit meinem geliebten Windowmaker (x11-wm/wmaker). Testweise habe ich auch Fluxbox installiert; vielleicht kann ich mich ja auch an den gewöhnen; er schont die Resourcen jedenfalls noch etwas mehr.
XDM wird gestartet indem in /etc/ttys die Zeile
ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure
in
ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm on secure
geändert wird, so dass der Rechner direkt in eine XDM-Session auf tty8 bootet. Dann stehen auf tty0 bis tty7 Konsolen-Logins zu Verfühgung. Die nutze ich zu meist als ROOT-Login zur Wartung. Allerdings habe ich festgestellt, dass der X24 bei einem von drei Versuchen, wieder zurück zum X zu wechseln, einfriert; warum, konnte ich noch nicht untersuchen.
Special Thinkpad-Goodies
Powermanagement
Der Rechner tut recht brauchbar mit ACPI. Um auf einige IBM-spezifische Features zugreifen zu können, wird beim Booten neben dem acpi.ko auch acpi_ibm.ko via /boot/loader.conf geladen.
Eingesetzt in die mitgelieferte Dockingstation erhält man allerdings einiges an Fehlermeldungen:
acpi0: <IBM TP-1D> on motherboard
acpi_ec_ecdt_probe: can't get handle
ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.FDC_._INI] (Node 0xc2ab2a00), AE_NOT_EXIST
ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__._INI] (Node 0xc2aaa720), AE_NOT_EXIST
ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BGID] (Node 0xc2ab2b40), AE_NOT_EXIST
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BINI] (Node 0xc2ab2b60), AE_NOT_EXIST
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BSTA] (Node 0xc2ab2ba0), AE_NOT_EXIST
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.IDE0.SCND.MSTR._STA] (Node 0xc2ab2a60), AE_NOT_EXIST
ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.IDE0.SCND.MSTR._STA] (Node 0xc2ab2a60), AE_NOT_EXIST
acpi0: Power Button (fixed)
ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BGID] (Node 0xc2ab2b40), AE_NOT_EXIST
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BINI] (Node 0xc2ab2b60), AE_NOT_EXIST
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__.BSTA] (Node 0xc2ab2ba0), AE_NOT_EXIST
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.IDE0.SCND.MSTR._STA] (Node 0xc2ab2a60), AE_NOT_EXIST
ACPI-0239: *** Error: Method execution failed [\\_SB_.PCI0.IDE0.SCND.MSTR._STA] (Node 0xc2ab2a60), AE_NOT_EXIST
(die letzten Zeilen werden mehrfach wiederholt). Ohne Dockingstation sieht das ganze etwas übersichtlicher aus:
acpi_ec_ecdt_probe: can't get handle
ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.FDC_._INI] (Node 0xc2ab2a00), AE_NOT_EXIST
ACPI-0356: *** Error: Region EmbeddedControl(3) has no handler
ACPI-1304: *** Error: Method execution failed [\\_SB_.PCI0.LPC_.EC__._INI] (Node 0xc2aaa720), AE_NOT_EXIST
acpi0: Power Button (fixed)
Trotzdem funktioniert der Rechner erstmal (die verschiedenen Schlafmodi werde ich später in aller Ruhe untersuchen).
Das spannendste Feature des Thinkpads zeigt sich aber, wenn man mittels
powerd_enable="YES" powerd_flags="-a adaptive -b adaptive -n adaptive"
in /etc/rc.conf den POWER-Daemon aktiviert: die CPU-Frequenz passt sich dann der geforderten Leistung an. Welche Frequenzen möglich sind, zeigt sysctl dev.cpu.0.freq_levels an:
dev.cpu.0.freq_levels: 1133/19100 991/16712 849/14325 733/12500 641/10937 549/93 75 458/7812 366/6250 274/4687 183/3125 91/1562
Die aktuell gewählte Frequenz lässt sich mit den entsprechenden Tools (hier z.B. mittels sysutils/torsmo) überwachen. So liegt bei einem scp auf eine mit GELI verschlüsselte Partition (also sind insgesammt 2 Verschlüsselungen beteiligt) liegt die CPU-Frequenz bei etwa 500MHz. Die meiste (idle-)Zeit regelt POWERD den Takt auf 91MHz runter.
Wie sich der POWERD auf die Akku-Laufzeit auswirkt, habe ich erstmal nicht testen können; dazu müsste ich die folgenden Test ohne POWERD wiederholen - das ist mir zu aufwändig). Die CPU-Temperatur fällt aber recht schnell, wenn der Rechner "idle" ist, so dass sich der Lüfter auch schnell wieder beruhigt. Der Nachteil liegt allerdings auch auf der Hand: die Reaktionszeit steigt unter Umständen etwas. Wenn das stört, kann man die powerd_flags in /etc/rc.conf anpassen.
Hier eine Grafik, die das Laden und Entladen des Akkus ohne wirliche Last zeigt beginnend bei nahezu vollem Akku. Bei 6% Restkapazität bekam der Rechner dann wieder Strom von außen. Die Gesamtlaufzeit würde ohne Last etwa 3:20 Stunden betragen.
Interessant ist, dass die Lade- und Entladekurve (rot) etwa die gleiche Steigung haben. Das, obwohl der Rechner nahe zu nichts zu tun hatte (grünen Kurve - die normierte CPU-Frequenz pendelt in den niedrigen Stufen, wobei zwischen den Messungen eigentlich kontinuierlich 92 MHz anlagen und die Messung selbst wohl den Anstieg auf die höheren Frequenzen bewirkt. Im letzten Teil ist sie etwas höher; was der Rechner da macht, weiß ich nicht, weil er unbeaufsichtigt war; Load zeigt aber, dass da mehr Programme was von der CPU wollten). Die Ladung des Akkus wird also jedesmal relativ viel Zeit in Anspruch nehmen, zumal die Ladekurve oberhalb von 90% auch noch deutlich abflacht. Während der ganzen Messung lag die CPU-Temperatur zwischen 40 und 45°C (violette Kurve). Die blaue Kurve zeigt die vom System vorhergesagte Restlaufzeit; das hängt jedoch stark von der Momentanlast ab.
Für die zugehörigen Volllastkurven habe ich zunächst ein portupgrade -arR angeworfen. Es waren allerdings noch nicht sehr viele Pakete zu erneuern. Am Anfang einige kleinere, was dazu geführt hat, dass sich immer wieder Downloads und Übersetzungsphasen abwechseln - an der Systemlast (cyan - Load(1min)) aber auch an der CPU-Frequenz (grün) ablesbar. Die erste längere Compilierung nahm das Update von lang/gcc41 mit GCC, Java, ObjectivC und allem, was das Paket sonst noch dazu liefert, in Anspruch. Dannach folgte - jeweils nach einer kleinen Pause - ein make buildworld und ein make buildkernel. Bei einem Akku-Füllstand von ca. 6% hat der Rechner dann wieder seine Nahrung von außerhalb bekommen und begonnen, neue Vorräte einzulagern.
Es fällt sofort auf, dass die angeforderte Rechenleistung den Akku ganz anständig leer saugt; frischen Strom brauchte der X24 dann auch bei Zeitindex 220, was 110 Minuten entspricht; also hält der Akku unter diesen Umständen ca. 2 Stunden.
Schön zu sehen ist auch, wie die rote Kurve ihre Steilheit ändert, wenn der Prozessor zwischen "Idle" und "Last" wechselt. Das gilt auch für die Ladephase; bei Last wird eher wenig (aber immerhin nocht etwas) Ladung in den Akku gepumpt.
Die violette Kurve zeigt die Temperatur. Die folgt auch sehr schön der CPU-Last, wobei die Kühlung sie bei Volllast zuverlässlich um die 70°C hält. Sie fällt in den Ruhephasen innerhalb weniger Minuten auf ca. 40°C; thermisch ist das Gerät gesund.
CF-Card-Reader
Sehr schön ist der eingebaute CF-Card-Reader, weil meine Digikam genau diesen Speicherkartentyp verwendet. So brauche ich nicht immer mit dem Adapter zu hantieren oder gleich die ganze Kamera per USB-Kabel anzuhängen. Ein Teil weniger, was verloren oder im falschen Moment kaputt gehen kann.
Einstecken der CF-Card in den Reader löst folgende Meldung aus:
ata2: <SunDisk SDP> at port 0x3000-0x300f irq 11 function 0 config 1 on pccard1 ad4: 30MB <SanDisk SDCFB-32 Vdg 1.21> at ata2-master PIO1
so dass die Karte mittels
# sudo mount -t msdos /dev/ad4s1 /mnt
gemountet werden kann. Der passender Eintrag in der /etc/fstab vereinfacht das weiter:
/dev/ad4s1 /mnt/flash msdos rw,noauto,-u=photor 0 0
Der Zugriff auf die Daten ist dann kein Problem mehr.
Lüfter
Der Lüfter ist so leise, dass ich ihn zunächst nicht bemerkt und deshalb bei der ersten System-Neuübersetzung Angst um die CPU hatte. Kein Vergleich zu dem Staubsauger von DELL. Der Rechner ist übrigens auch um einiges schneller als der Inspiron, obwohl der Takt nur unwesentlich schneller ist (make buildworld braucht etwa 1.5 Stunden, make buildkernel handgestoppte 50 Minuten). Hier hat IBM die Komponenten wohl besser aufeinander abgestimmt, als die DELLer das in ihrer schnellen Modellwechselpolitik können.
Zur Sicherheit
Diesmal habe ich sofort die SWAP-Partition verschlüsselt und einige Sicherheitsfeatures (Blowfish-Hashes für /etc/passwd) eingebaut. Die Idee, nur Teile des $HOME-Directories zu verschlüsseln ist natürlich immer noch interessant. Da sich aber das direkte Übereinandermounten von verschlüsseltem und unverschlüsseltem Verzeichnis als unpraktisch erwiesen hat, habe ich mich diesmal entschieden, die mir GELI verschlüsselte Partition in ein extra Verzeichnis zu mounten und dann entsprechende Links zu legen. Das ist zwar nicht besonders innovativ und eher unelegant, erfüllt aber zunächst seinen Zweck. Das ganze ist mittels Script soweit automatisiert, dass ich mir die ganzen komplizierten Abläufe nicht merken muss; ein einfaches ATTACH.sh reicht, um die geheimen Daten in's $HOME-Directory einzublenden (die Passphrase wird natürlich abgefragt) und entsprechend verbirgt ein DETACH.sh sie wieder vor unbefugtem Zugriff. Das Script ATTACH.sh liegt in $HOME/bin (das zu meinen PATH gehört) und DETACH.sh ist ein Link auf das erstere; das Script unterscheidet intern, wie es aufgerufen wurde. Das hat den Vorteil, dass ich nur einmal eine Liste mit den wichtigen Dateien und Mountpoints warten muss.
Jetzt brauche ich nur noch ein Windowmaker-Applet, mit dem man die Scripte aufrufen kann, am besten so, dass man gleich den Status angezeigt bekommt. Beim Verlassen von X (i.A. beim Ausloggen) wird überprüft, ob die Partition noch gemountet ist und diese gegebenenfalls detacht.
Sonstiges
- Um Sound zu nutzen, werden die Module snd_ich.ko und sound.ko in /boot/loader.conf geladen. Die Soundqualität erinnert allerdings mehr an ein Blechbüchsen-Grammophon. Als Qualitätsplärre lässt sich der X24 also nicht nutzen - muss er aber auch nicht. Am verbauten Soundchip liegt's nicht; über die Ohrstöpsel meines SAMSUNG YH-J70 (als iPod-Ersatz, der .ogg kann) kommt "Personal Jesus" von Johnny Cash in ganz brauchbarem Sound. Da sind im X24 wohl Billigst-Lautsprecher verbaut worden; Prioritäten setzen!
- Da der Platz auf einem TFT mit 1024x768 Pixeln etwas beschränkter ist als bei 1600x1280 des DELL, nutze ich das Rootwindow zur Statusanzeige der Maschine. Dazu eignet sich sowohl sysutils/torsmo oder die etwas aufgebohrte Version sysutils/conky (ein Screenshot in Originalgröße; die verwendete conkyrc dazu). Deshalb zeigt mir auch sysutils/xbattbar den Akku-Status an.
- Die USB-Mouse funktioniert stante pede. Genauso meine USB-Beistellplatte.
- Ach ja - es gibt ein ThinkLight und es läßt sich per Tastatur schalten.
Der Kauf
oder: Was lange währt wird endlich gut
Nachden der DELL Inspiron 8100 eher ein großer und schwerer mobiler Computer ist, suchte ich einen leichten kleinen, den man immer überall mitnehmen kann. Die Wahl fiel relative schnell auf die X-Serie der Thinkpads von IBM. Die sind klein, leicht und robust.
Da ich die Leistung der aktuellen Modelle nicht brauche und auch deren Preis reichlich ist, habe ich ein gebrauchtes Modell gesucht. Bei der Firma Lapstore gab es einen X24, den ich mit einer 40GB-Platte und 368 MB RAM (mehr ging leider nicht) bestellte.
Die Lieferzeit sollte 6 Tage betragen, gerechnet nach dem Erhalt der Vorkasse. Daran konnte sich Lapstore nicht halten. Nach 10 Tagen habe ich per Mail nachgefragt und erhielt die Antwort "Lieferschwierigkeiten", aber die Auslieferung erfolge am kommenden Montag - was leider der 1. Mai war - und ich erhielte dann eine automatische Mail: "Eigentor!" würde ich sagen. Spannend in dem Zusammenhang, dass die ganze Zeit immer noch X24 im Angebot waren.
Die Lieferung erfolgte dann tatsächlich und ich hatte den Rechner Donnerstag in der Hand; ordentlich verpackt, mit Netzteil und Dockingstation - alles wie bestellt, gut.
Auch der Akku war logischerweise enthalten. Auf den gibt Lapstore keine Garantie - außer, dass der eine Mindestlaufzeit des Rechners von 20 Minuten liefern soll; ist das nicht der Fall, kann er umgetauscht werden. Der Akku war leer, so dass ich das Gerät erstmal mit Netzteil anwarf (im CD/DVD-Laufwerk eine FreeSBIE-CD ). Das funktionierte auch ganz brauchbar - einzig der Akku war nach 6 Stunden immer noch so leer, dass ein Ziehen des Netzkabels den Rechner augenblicklich sterben ließ - schlecht.
Daher hab ich den Akku mal über Nacht geladen. Aber das Ergebnis blieb das gleiche: der Akku weigerte sich, auch nur einen Hauch von Ladung zu speichern. Von 20 Minuten Laufzeit kann keine Rede sein. Also: Mail an Lapstore, die sich dann auch meldeten: ich solle den Akku einsenden; wäre wohl kaputt; der würde dann getauscht.
Nun gut. Getan. Am Freitag noch den Akku verpackt und zurück zu Lapstore. Am folgenden Mittwoch bekomme ich dann die Bestätigung (via E-Mail) über den Eingang dort. Glaube ich das? Und keine Auskunft, für wann ich mit dem Ersatz rechnen kann. Nicht mal auf Rückfrage. Um dem Rechner auf den Zahn zu fühlen, lege ich eine Memtest-CD (sysutils/memtest86) ein und lass den mal einige Stunden wilde Bitmuster in den Speicher schreiben - keine Fehler.
Ein neuer/anderer Akku ließ auf sich warten, so dass ich den Laptop erstmal nur als imobilen(!) Desktop testen konnte. Erst als ich mich trotzdem für das Gerät entschieden hatte (und bestimmte "Buzz-Words" gefallen sind), ging der Ersatzakku binnen Stunden in den Postversand (Angekündigt mit eienr leicht säuerlichen Mail von Lapstore). Interessantes Timing.
Der Akku erschien (in Begleitung eines DHL-Menschen) dann auch am nächsten Tag (soo langsam ist die Post also nicht). Tatsächlich ist es ein Neuteil, augenscheinlich noch original verpackt und mit Siegel. Folglich wird er auch im Gerät geladen und tut brav seinen Dienst. An die Stelle gehört fairerweise ein Lob für die kulante Reaktion von Lapstore.
Offensichtlich war der Akku auf ca. 70% vorgeladen. Nachdem er im Betrieb vollständig befüllt war, habe ich dem Rechner den Saft abgedreht und ihm ein bischen was zu arbeiten gegeben: Download und Bau von lang/gcc41 hat den Akku dann nach ca. 2 1/4 Stunden leer gesaugt. Das ist natürlich deutlich länger, als die versprochenen 20 Minuten.
Nur, dass aus 6 Tagen jetzt irgendwie ein Monat geworden ist.
Fazit:
Ich weiß ja nicht, ob ich die Firma Lapstore einfach auf dem falschen Fuß erwischt habe, aber ich hätte es gut gefunden, mich zu informieren, wenn sich wirklich Lieferprobleme ergeben. Die Firma hat schließlich gutes Geld und auch pünktlich (nämlich im Voraus!) bekommen.
Und warum nennt man mir den 1. Mai als voraussichtlichen Ausliefertermin? Ein kurzer Blick auf den Kalender, wenn man's schon nicht im Kopf hat, reicht. Hm ... Ist vielleicht nur blöd gelaufen; oder wollte man da einfach Zeit gewinnen (Iss jetzt nur 'ne Frage)? Den Eindruck könnte man aber vermeiden.
Der defekte Akku passt so gesehen dann auch in's Bild (das kann man vorher mal kurz antesten). Und ich hätte ja nichts gesagt, wenn es das einzige gewesen wäre. Dass der Austausch dann wieder sehr lange gedauert hat, kann natürlich ein einfacher Fehler innerhalb der Firma sein; wenn ich böswillig denken würde, könnte auch das Strategie sein.
Ansonsten war das Gerät in Ordnung. Gebraucht natürlich, aber optisch und mechanisch in gutem Zustand. Und es entspricht dem, was ich gesucht habe und exakt dem, was in der Produktbeschreibung versprochen wurde. Die Tastatur hat mittels Aufklebern ein deutsches Layout bekommen (die Caps-Lock-Taste heißt witzigerweise aber immer noch "Blog Mayús", was ja aber die Funktion nicht beeinträchtigt - ist mehr ein individuelles Merkmal).
Durch den erstmal fehlenden Akku ließ sich zunächst nicht feststellen, ob der Defekt nicht doch innerhalb des Rechners zu suchen ist. Erst als mir versichert wurde, dass dieses in dem Fall unter die normale Garantie des Gerätes fällt, habe ich mich entschlossen, den Rechner nicht zurückzusenden. (Für einen Juristen mag das vorher klar gewesen sein; ich bin da eher vorsichtig und hab sowas gerne aus dem Mund/der Mail eines Kompetenten.)
Nachdem das klar war, konnte ich dann beginnen, ein FreeBSD zu installieren, was ich ja eigentlich auf dieser Seite beschreiben wollte.
Es bleibt ein komisches Gefühl bei dem Ganzen. Bei einem Ladengeschäft kann ich mir den Verkäufer ansehen und einschätzen; das ist online halt anders. Im Endeffekt hat der Deal ja dann geklappt und das Gerät ist OK - es war halt 'ne schwere Geburt.
Ach ja: Disclaimer beachten.
ToDo-Liste
- Suspend-to-Disk. Dafür wird allerdings eine spezielle Partition gebraucht. Wie diese unter FreeBSD anzulegen ist, wird allerdings kaum irgendwo beschrieben und "Forschung" wird nötig. Auch, ob FreeBSD das überhaupt unterstützt, ist mir noch nicht klar.
- Modem - für auswärtiges einloggen via Festnetz; WinModem mit comms/ltmdm. Erste Blitzversuche haben den Rechner shock-gefrostet sobald ppp <provider> bzw. ppp> dial aufgerufen wurde; Grund ist noch nicht klar.
- WLAN - speziell für das Opennet in Rostock Sowohl für das freie Surfen in der KTV als auch, um auf die Daten in der Heimat-Station zuzugreifen (OpenVPN-Tunnel mit eigenem Zertifikat).
- IrDA für den Kontakt zum Handy (comms/birda und comms/gnokii) zum Datenaustausch und vielleicht auch zur Einwahl.
Files
Technische Daten:
- IBM Thinkpad X24 (Type 2662-PG3)
- Mobile Pentium III 1133 MHz
- 386 MB SDRAM
- 40 GB IDE Harddisk (TOSHIBA MK4026GAX PA100U)
- 12" LCD Display (1024x768)
- ATI Radeon Mobility M6 LY
- DVD-ROM HITACHI (HITACHI DVD-ROM GD-S200/0034)
- Ricoh RL5c476 CardBus Controller
- Sound: Intel ICH3 (82801CA)
- Ethernet: Intel 82801CAM (ICH3) Pro/100 VE
- Lucent/Agere LT Winmodem 56k 0449144F
-
zugekauft (und vom DELL geerbt):
- Logitech Mouseman Traveler opt. USB-Mouse
- DELL True Mobile 1150 Series WLAN-Karte
- HAMA PCMCIA-Flash-Card-Adapter
- USB-Stick: PNY Technologies