PHOTOR

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

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.

  1. 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.
    #
    
  2. 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/
    
  3. 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.
  4. 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:

  1. Im Zweifelsfall also einige Zeit warten und nochmal auschecken:
    # cd ~/OpenWRT/
    # svn co https://svn.openwrt.org/openwrt/trunk
    
    Vielleicht geht es dannach.
  2. 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:

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

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

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 45C (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 70C hält. Sie fällt in den Ruhephasen innerhalb weniger Minuten auf ca. 40C; 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


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


Files


Technische Daten:


Last modified: Thu Sep 6 23:50:49 CEST 2007