Ich hatte schon lange die Nase voll davon, für sowas immer eine Virtuelle Maschine mit Wintendo starten zu müssen und habe daher heute mal ein wenig gefummelt und mir die passende Software unter Linux installiert. Da ich annehme, daß es noch mehr Fahrer gibt, die unter Linux vor dem gleichen Problem stehen, versuche ich mal, meinen Weg dorthin zu zeigen.
Dieses Howto bezieht sich auf Debian Lenny, wird aber wohl so ähnlich auch für andere Distributionen einsetzbar sein. Zusätzlich zu diesem Blogeintrag werde ich es bei den Unixfreunden in der Howto-Sektion veröffentlichen.
Ich habe mir einen SCR331 USB-Kartenleser mal vor Urzeiten über Ebay für kleines Geld besorgt. Für diesen müssen jetzt die passenden Softwarepakete installiert werden:
apt-get install libusb-0.1-4 libpcsclite1 libpcsclite-dev pcscd pcsc-tools build-essential autoconf xlibs-dev libccid
Auf der Rückseite des Kartenlesers ist eine Teilenummer angegeben, liegt diese unter PN: 904622, so muß er geflasht werden, um unter Linux zu laufen. Das Flash-Utilty für Linux gibt es hier, die Firmware ist hier zu bekommen. Das Binary aus dem Firmware-Archiv extrahieren, dann den Firmware-Updater installieren und mit einem Editor /usr/local/scm/ini/fwupdate.ini öffnen und folgendermaßen editieren:
<fwupdate>
<key>DevIdMatch</key>
<value>False</value>
<key>UpgradeOnly</key>
<value>False</value>
<key>UpdateClParams</key>
<value>True</value>
<key>ForceDw</key>
<value>False</value>
<key>SkipVerifyDw</key>
<value>False</value>
</fwupdate>
Danach lässt sich die neue Firmware problemlos in den Reader flashen. Achtung! pcscd darf nicht laufen!
Nach dem Flashen den Reader abziehen und neu einstecken, pcscd starten mit /etc/init.d/pcscd start, der Reader sollte jetzt bei Eingabe von pcsc_scan angezeigt werden.
Wenn bis hierhin alles glatt gelaufen ist, können wir ja zum Eingemachten übergehen:  dem Auslesen der Fahrerkarte, noch dazu archivierungsfähig und auswertbar.
Zuerst brauchen wir noch einige Pakete aus dem Debian-Repository:
apt-get install swig1.3 python-wxgtk2.8
Dann laden wir uns pyscard herunter und entpacken es, wechseln in das Verzeichnis und rufen /usr/bin/python setup.py build_ext install auf.
Zum Auslesen der Fahrerkarte gibt es seit kurzem ein Python-Skript: FahrLinux, das laden wir uns auch herunter und entpacken es in ein Verzeichnis. FahrLinux ist noch beta, geht aber schon prima.
Nun stecken wir unsere Fahrerkarte und rufen Fahrlinux auf:
./fahrlinx

Ein Doppelklick auf die angezeigte Fahrerkarte und danach ein Klick auf „Start“ lesen die Karte aus und legen eine archivierbare .DDD-Datei im Fahrlinux-Verzeichnis ab.
Diese kann man prima von unterwegs per Email ans Büro schicken
Nun zur Auswertung der Daten, man möchte ja auch gerne wissen, was man falsch gemacht hat unterwegs. Für solche Dinge gibt es readesm. Zuerst ziehen wir noch einige Pakete aus dem Repository nach:
apt-get install libboost-program-options-dev libgcrypt11-dev libgmp3-dev
Dann entpacken wir readesm und kompilieren es:

make
make install

Praktischerweise bringt es gleich einige Skripte mit, als KDE-Nutzer habe ich mir die Endung .DDD mit /usr/local/bin/readesm-wrap-kde verknüpft, das konvertiert die Daten in HTML und ruft sie gleich im Standardbrowser auf, so daß man bequem seine Verstöße kontrollieren kann.
/usr/local/bin/readesm-wrap-firefox ruft die Seite im Firefox auf.


Für alle, die das gerne noch ausweiten möchten, hier noch der Hinweis auf opendtacho.org. Das Projekt arbeitet an einer Lösung für Speditionen, die auf Linux basiert. Die mit FahrLinux gezogenen Daten lassen sich dort importieren, es wird mit einem Tomcat gearbeitet und eine hierarchische Nutzerverwaltung ist ebenfalls möglich, so daß man seine Fahrer die Karten auslesen lassen und in die Software einpflegen kann. Es lassen sich Tätigkeitsberichte erstellen, etc.

Ich habe ja am Wochenende Debilian installiert, nach meinem Headcrash. Unterwegs bekam ich dann die USB-Geräte nur sporadisch zum laufen, Logs waren wenig hilfreich.
ehci_hcd entpuppte sich als der Übeltäter.
Eine Datei /etc/modules.d/ehci_hcd.conf mit dem Inhalt
blacklist ehci_hcd hat da schnell Abhilfe geschaffen. Endlich kann ich wieder ins Internet und auch fernsehen..

Gestern habe ich mich um ein kleines Problem mit fail2ban gekümmert, das ich vor mir hergeschoben habe.
Debian liefert vorkonfigurierte Filter für fail2ban mit, die leider nicht für proftpd passen. Die Logfiles des Servers waren voll von chinesischen Einbruchsversuchen auf den FTP-Server.
Nu ist regexp nicht gerade meine Stärke und es bedurfte einiger Fummelei sowie fachlicher Unterstützung durch Disastersmaster. Damit konnte das Problem aber schnell eingekreist und beseitigt werden.
Eigentlich sinds 2 Probleme.. Zum einen passen die regexp nicht auf die Logfiles vom proftpd und zum anderen verweigern die iptables den Dienst, wenn man bei kommaseparierter Portliste kein multiport verwendet.
Da ich aus meiner Google-Suche weiß, daß ich nicht alleine mit dem Problem da stehe, poste ich hier mal meine /etc/fail2ban/filter.d/proftpd.conf:
# Fail2Ban configuration file
#
# Author: Yaroslav Halchenko
#
# $Revision: 677 $
#
[Definition]
# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P\S+)
# Values: TEXT
#
failregex = \(\S+\[\]\)[: -]+ USER \S+: no such user found from \S+ \[[0-9.]+\] to \S+:\S+\s*$
\(\S+\[\]\)[: -]+ USER \S+ \(Login failed\): Incorrect password\.\s+$
\(\S+\[\]\)[: -]+ USER \S+ \(Login failed\): No such user found\.\s+$
\(\S+\[\]\)[: -]+ SECURITY VIOLATION: \S+ login attempted\.\s+$
\(\S+\[\]\)[: -]+ Maximum login attempts \(\d+\) exceeded\s+$
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =

Vielleicht erspare ich ja dem Einen oder Anderen damit etliche Stunden voller Kopfzerbrechen..

Kopieren der Datei /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi
nach /etc/hal/fdi/policy und darin das Ersetzen von „us“ durch „de“ löst
das Problem…

Noja..Linuxer wissen das sicher. Wer einen Beweis braucht, kann ja mal
cat /etc/apache2/envvars eintippen..

# envvars - default environment variables for apache2ctl
# Since there is no sane way to get the parsed apache2 config in scripts, some
# settings are defined via environment variables and then used in apache2ctl,
# /etc/init.d/apache2, /etc/logrotate.d/apache2, etc.
export APACHE_RUN_USER=root
export APACHE_RUN_GROUP=root
export APACHE_PID_FILE=/var/run/apache2.pid
Bei sowas könnt ich ja im Stehen kotzen..
Nachtrag: Wen wunderts da noch, wenn in der php.ini safemode = Off und AllowFurlOpen = On zu finden ist..
Es ist definitiv mehr Arbeit, das System sicher zu konfigurieren, als es einmal neu hochzuziehen.
Ich kann vor dem Einsatz von Ubuntu auf einem Webserver nur warnen..
*kopfschüttel*
Noch ein Nachtrag: Nachdem ich dann nnoch einige Dinge näher angeschaut habe, bin ich zu dem Entschluß gekommen, per debootstrap ein richtiges Debian zu installeren..sonst brauche ich 3-4 Tage, bis das rund läuft..

Plötzlich reisst das emerge -u world ab.. Mitten im acl..
error while loading shared libraries: libacl.so.1: cannot open shared object file: No such file or directory
Google brachte nichts wirklich brauchbares in der Suche. Also bastelt man sich halt einen workaround.
Die Dateien bekommt man bei openswan.com, reinkopieren in /usr/lib und alles geht wieder wie gewohnt. Danach unbedingt die coreutils mit „-acl“ neu mergen..
Für faule hier zum rauskopieren:

cd /lib/
wget http://actrophp.de/gentoo/libacl.so.1
wget http://actrophp.de/gentoo/libattr.so.1
# ls, mv, cp funtionieren jetzt wieder
echo „sys-apps/coreutils -acl“ >> /etc/portage/package.keywords
emerge -v coreutils
# aufräumen, die Dateien werden nicht mehr gebraucht
rm /lib/libacl.so.1
rm /lib/libattr.so.1