uwal001 [ …the more powerful nas ]

die schwachstellen meiner bestehenden nas-lösung waren schnell identifiziert, und die suche nach etwas performanteren ergab positives [ ib-nas4220-b icy box von raidsonic ]. zum einen wollte ich weg von dem langsamen netzwerkzugriff zur nslu2, welcher unter optimalen voraussetzungen [messung mittels iperf ] nicht mehr als 90 mbit ergab. da meine multimedialen daten ausschliesslich auf rechnern mit gigabit anschluss liegen, war diese netzwerkanbindung ein muß. dem performance sheet folgend - erhalte ich folgende werte.

	nslu2	icy_box
hdparm [mb/s]
cached	40-43	65-68
bufferd	10-12	20-23
dd [mb/s]
write	12	15
read	12	33
samba [mb/s]
write	1,8	3,7
read	2,5	2

somit kann man in unserem fall den unterschied von usb zu sata2 mit einem faktor von 2 titulieren. Linearität zufolge erziele ich hiermit einen faktor 20 über das netz.
zur installation der icy_box:
die hardware einrichtung meiner beiden seagate barracuda [je 1.5 tb] erfolgt unspektakulär.
der erste bootvorgang, das flashen der aktuellen firmware v2.6.3.1 über das webgui erfolgt lt. handbuch. erneuter start, wir kommen zur konfiguration der platten. dieses nas soll lediglich als backup bzw. daten-server [samba] dienen. somit entscheide ich mich auf den verzicht von all built-in-software elementen wie raid-verbunde, sausalito framework, printserver, etc.
die aktuelle firmware bietet die möglichkeit unter /{mountpoint}/public/applications/new_software neue softwarepackages abzulegen und nach erfolgtem reboot diese automatisiert zu installieren. dieses verzeichnis ist in unserem falle /mnt/ide2/public/ applications/new_software, da die systempartition auf der 2ten unserer beiden festplatten abgelegt wurde. [ cat /usr/sausalito/codb/objects/1/Disk.rootdir ] das erste der zu installierenden packages dient dem sicheren-consolen zugang als alternative zum bereits aktivierten telnet [user:root / pwd: admin]. die offiziellen pakete von raidsonic [http://de.nas-4220.org/index.php/Packages] bieten hier zunächst einmal das paket ssh-server.tgz [ dropbear ] an.
der eigentliche tricky part – das ersetzten der built-in-packages durch analoge im optware feed, wird wie folgt initiert.
download von optware-hd-010209 [siehe obiger link zu packages::optware]. nach einem erneuten reboot werden ssh-schlüsselpaare erzeugt und der optware-ssh-server wird gestartet. [macht das dropbear package überflüssig, welches nun gelöscht werden kann !]. von nun an kann wie gewohnt mittels ipkg operiert werden. wir werden samba, cron und syslog-ng aus dem optware feed installieren.

# ipkg install cron
# ipkg install samba
# ipkg install syslog-ng
wie persistieren wir nun dieses packages und eliminieren die built-in-packages der aktuellen firmware? die software-elemente in der raidsonic firmware werden durch das sausalito framework gesteuert, welches mittels constructoren aufgerufen werden. wir disablen gewisse davon. [ftp, nfs, printserver, bonjour, bt2]
# rm -f /usr/sausalito/constructor/50_construct_ftp
# rm -f /usr/sausalito/constructor/50_construct_nfs
# rm -f /usr/sausalito/constructor/50_construct_printer
# rm -f /usr/sausalito/constructor/91_construct_bonjour
# rm -f /usr/sausalito/constructor/89_construct_bt2
der trick besteht nun darin, dass wir genau einen einstiegspunkt haben, in dem wir diese abläufe persistieren können, nämlich im startscript des optware-packages [ /mnt/ide2/public/applications/optware/init]…
obige befehle werden bequem in dieses script eingpflegt, zudem behalten wir uns mit dem eintrag von
ln -sf /opt/etc/init.d/S01p003876 /etc/rc.d/S01p003876.sh
ein weiteres script vor um weitere usergesteuerte packages zum zeitpunkt des bootes zu starten. durch die verlinkung auf /etc/rc.d [startverzeichnis der raidsonic-firmware ] wird dieses script nun bei jedem boot ausgeführt. der inhalt gewährleistet das herunterfahren sämtlicher firmware-prozesse und starten der konfigurierten und installierten optware-prozesse. [listing von S01p003876.sh]

#!/bin/sh
#
# no raid, we kill slotDiskButton
killall slotDiskButton
# no bonjour, we kill bonjour/linkChg
killall linkChg
# no sausalito powermanagement
killall powermgmt
# no sausalito storudp
killall storudp
# no sausalito cced
killall cced
# no twonky running
killall upnpdevice
# no icy_box webinterface needed
killall thttpd
# use my hostfile ...
if [ -e /opt/etc/hosts ]; then
ln -sf /opt/etc/hosts /etc/hosts
fi
# use my profile ...
if [ -e /opt/etc/profile ]; then
ln -sf /opt/etc/profile /etc/profile
rm /root/.profile
fi
# home directories...
if [ -e /home ]; then
rm -R /home
ln -s /mnt/ide2/home /home
fi
# passwd directories...
if [ -e /etc/passwd ]; then
rm -R /etc/passwd
ln -s /opt/etc/passwd /etc/passwd
fi
# group directories...
if [ -e /etc/group ]; then
rm -R /etc/group
ln -s /opt/etc/group /etc/group
fi
# start samba 3 [optware]
/opt/etc/init.d/S08samba
# start nagios nrpe [optware]
/opt/etc/init.d/S99nrpe start
# link locale specific from debian etch compilation
rm /usr/share/locale
rm /usr/lib/locale
rm /usr/share/i18n
ln -s /opt/share/locale /usr/share/locale
ln -s /opt/lib/locale /usr/lib/locale
ln -s /opt/share/i18n /usr/share/i18n
# link ssl libraries...
rm /usr/lib/libz.so.1
rm /usr/lib/libssl.so.0.9.8
rm /usr/lib/libcrypto.so.0.9.8
ln -s /opt/lib/libz.so.1 /usr/lib/libz.so.1
ln -s /opt/lib/libssl.so.0.9.8 /usr/lib/libssl.so.0.9.8
ln -s /opt/lib/libcrypto.so.0.9.8 /usr/lib/libcrypto.so.0.9.8
# launch ssh daemon
/opt/etc/init.d/S40sshd
# set correct timezone
rm /etc/localtime
ln -s /opt/share/zoneinfo/Europe/Vienna /etc/localtime
/opt/bin/ntpclient -h pool.ntp.org -s &>/dev/null
# link operational
rm /operational
ln -s /mnt/ide2/operational /operational
# link operational
rm /etc/rc.d/S12syslog.sh
/opt/etc/init.d/opt_syslog start
# nagios has problems with /bin/ps
rm /bin/ps
ln -s /opt/bin/ps /bin/ps
# link perl
rm /usr/bin/perl
ln -s /mnt/ide2/perl/bin/perl /usr/bin/perl

viele der obigen befehlsketten machen erst dann sinn, wenn eine chroot umgebung – in meinem fall debian etch auf der icy_box installiert wurde, und hier native comiliert wird.

nwal002 [nagios unter slugos/be]

die verlockung war zu gross, doch das ergebnis war mehr als zufriedenstellend. anfängliche ängste, dass die system-ressourcen nicht ausreichend seien, nagios auf dieser plattform zu betreiben waren schnell verflogen. heute läuft diese monitoring software auf allen meinen nslu2-devices und betreibt neben system auch application-monitoring.
der reihe nach. wir holen uns die aktuellen sourcen [stable] des nagios systems von http://www.nagios.org, aktuelle version 3.0.6. zusätzlich downloaden wir die sourcen der vordefinierten system-monitore ‚nagios-plugins’, version 1.4.13. die nagios-endpoints [clients] werden mit dem aktuellen nrpe-addon versorgt, version 2.12.
all diese sourcen werden wir auf der slug selbst kompilieren [native development umgebung]. das eigentliche kompilieren verläuft recht rasch, es hat sich gezeigt, dass zudem ccache-2.4 bzw. gd-2.0.35 benötigt wird. folgend dem ubuntu quickstart legen wir zunächst auf allen nagios-endpoints und auf dem nagios-server einen eigenen user an.

# addgroup –g 20 nagios
# adduser –h /home/nagios –g nagios –s /bin/sh –G nagios nagios

zusätzlich auf dem nagios server eine nagiosec [nagios-external-command] gruppe, welchem der eigentliche nagios-user bzw. der user unter welchem unser apache server läuft [daemon], zugeordnet wird. dieser schritt wird benötigt, da die verwendung der console [apache-context] nagios-befehle [z..b. re-scheduling] absetzt und somit zugriff auf das locale filesystem haben muß [/usr/local/nagios/var/rw].

# addgroup –g 25 nagiosec
# chown –R nagios:nagiosec /usr/local/nagios/var/rw
# chmod g+s /usr/local/nagios/var/rw
editiere /etc/group, sodaß nagios user und apache user der gruppe angehören.
[nagiosec:x:25:nagios,daemon]

compile nagios server
# cd nagios-3.0.6
# ./configure –with-command-group=nagiosec
# make all
# make install
# make install-init
# make install-config
# make install-commandmode

alles recht straight, wie in der documentation beschrieben. die schnittstelle zum apache konfigurieren und einen nagios-consolen-benutzer anlegen.

# /opt/bin/htpasswd –n nagiosadmin

den output in das file /usr/local/nagios/etc/htpasswd.user pasten, und apache restarten. runlevel [rc3.d] verlinken mit /etc/init.d/nagios

# ln –s /etc/init.d/nagios /etc/rc3.d/S99nagios

nagios plugin compilieren

# cd nagios-plugins-1.4.13
# configure –with-nagios-user=nagios –with-nagios-group=nagios
# make
# make install

es hat sich gezeigt, daß manche plugins unter dem root user ausgeführt werden sollten [/usr/local/nagios/libexec/check_icmp]. hier empfiehlt es sich, das entsprechende sticky bit zu setzten.

# chown u+s /usr/local/nagios/libexec/check_icmp

wir können nagios das erste mal starten und unseren browser auf die console richten [http://apache_server/nagios] mit den credentials von nagiosadmin.

# /etc/init.d/nagios start

nwal002 [system-management]

in diesem abschnitt beschäftige ich mich mit den prerequisites für ein erfolgreiches system-management [monitoring] unter der arm-basierenden nslu2. die eigentliche open-source-software nagios, welche system-management agenden übernehmen wird, behandle ich zu einem späteren zeitpunkt.
welche schnittstellen [output] soll mein monitoring-system anbieten? einerseits spielt notification eine wichtige rolle, damit incidents bzw. störungen jedweiliger art irgendwo einmal eingeworfen werden. zum anderen soll natürlich die möglichkeit bestehen, aktiv die jeweiligen system/applikations-schichten zu beobachten. letzten endes soll ein gewisser workflow implementiert werden, die auf störungen automatisiert reagieren und diese beheben.
die ersten zwei punkte sind schnell abgehandelt, wir werden mails als notification instrument verwenden und apache2 als front-end bzw. console.

einrichtung eines mail-clients zur verständigung von störungen.
zunächst einmal installieren wir ein kleines command-line unix-utility, bekannt als ‚mail user agent’. dieses findet sich im cross-feed der slugos/be umgebung.

# /usr/bin/ipkg install mailx

weiters benötigen wir ein transfer protocol, welches die kommunikations-schicht zwischen mail-server und mail-client erst ermöglicht. den internet-standard spiegelt hier smtp [simple mail transfer protocol] wieder, mit sendmail als eingentliche träger-software. Aufgrund der komplexität der konfiguration dieser software, zudem eine limitation der architektur [32mb speicher, 266mhz processing], entscheide ich mich für die low-budget lösung – ssmtp.
# /usr/bin/ipkg install ssmtp
mit dieser simplen konfiguration [ssmtp_config.jpg].

auch der webserver ist schnell installiert bzw. konfiguriert. ein binary des servers liegt bereits im optware feed und kann mittels
# ipkg install apache
auf das system gebracht werden. komplexer gestaltet sich hier die konfiguration [/opt/etc/apache/httpd.conf]. wir werden diesen abschnitt gesondert abhandeln. Wir verlinken derzeit lediglich den runlevel mit dem startskript [/opt/sbin/apachectl].
# ln –s /opt/etc/init.d/opt_apache /etc/rc3.d/S80apache

nwal002 [zentrales syslog / syslog-ng]

mit wachsender peripherie innerhalb der it, stellt sich irgendwann die frage ob ein zentrales logging diverser hard/software-schichten nicht von vorteil wäre. untermauert wird jenes argument durch die tatsache, dass meine nslu2-devices zum teil nur durch einen memory stick betrieben werden, eine exzessives lokales logging zu io waitstates führen würde. hängt an einem dieser devices eine usb-festplatte spricht nichts dagegen, events, logging-einträge und protokolle an dieses gerät mittels udp zu übertragen.
man findet als eine freie implementierung [open source] eines syslog-servers unter linux syslog-ng. die installation ist unter slugos/be native als paket unter dem optware feed gegeben, und die durchführung dessen verläuft unspektakulär.

# ipkg install syslog-ng
# /etc/init.d/syslog stop
# ln –s /opt/etc/init.d/opt_syslog /etc/rc3.d /S02syslog

der syslog-ng server horcht nun unter port 514 [ syslog udp default port ] auf events von syslog-ng clients. es empfiehlt sich gewisse anpassungen unter /opt/etc/syslog-ng/syslog-ng.conf hinsichtlich was geloggt werden soll, zu tätigen. auf der client seite wird /etc/syslog.conf file lediglich um folgende einträge erweitert.

DESTINATION="remote"
REMOTE=nwal002:514

im zusammenhang mit syslog-ng empfiehlt sich der einsatz von logrotate, welches ebenso standardgemäß im optware feed als package angeboten wird. /opt/etc/logrotate.conf ist in meinem fall so konfiguriert. [ rotiere einträge älter als 5 tage ]

nocompress
/opt/var/log/* {
rotate 5
size 100k
postrotate
/opt/etc/init.d/opt_syslog stop
/opt/etc/init.d/opt_syslog start
endscript
}
include /opt/etc/logrotate.d

und das rotieren läuft als cronjob
15 0 * * * /opt/sbin/logrotate /opt/etc/logrotate.conf &>/dev/null

von nun an loggen meine nslu2-devices und mein d-link router alles zentral.

nwal003 [wake on lan und linksys dma 2200]

ein bedeutender nachteil des linksys dma 2200 extenders ist das nicht-vorhanden-sein eines wake on lan features innerhalb der existierenden firmware. was nützen stromsparpläne eines vista media servers [vmc], wenn der extender nicht in der lage ist, diesen aus seinem ruhezustand zu erwecken. während dies mit der x-box 360 bereits initial berücksichtigt wurde, haben die firmware-entwickler von linksys [cisco] bereits resigniert, denn das gerät ist bereits seit mehr als 2 jahren auf dem markt erhältlich.
mein beitrag zu diesem problem war ein pragmatischer. da ich mehrere nslu2-devices am laufen habe, war es kaum eine herausforderung einen entsprechenden dämon zu implementieren, der genau dieses gewünschte feature abbildet. eine denkbar einfache logik, die in einem perl-script entwickelt wurde.

das eigentliche script gibt es einfach hier zum download [click auf grafik !]
perl script [wol2.txt] sollte umbenannt werden auf [wol2.pl]
 

bootet der extender bekommt er vom dhcp-server eine fixe ip-adresse zugeordnet. sobald diese adresse in meinem lan erreichbar ist [check von nslu2 / net::ping ], sendet eben das kleine linux device den wake on lan zum mediaserver. dannach kann bequem im menu des extenders das windows media center aufgerufen werden und die kommunikation funktioniert.
ein ‚status’-semaphore verhindert das erneute senden eines wol requestes.

:) enjoy

nwal002 [mjpg streams and slugos]

vor mehr als 2 monaten hatte ich den wunsch, live-bilder von meinem wohnzimmer aus ins internet zu streamen. hardware hatte ich schnell gefunden, die logitech quickcam pro 9000 sollte meine bedürfnisse abdecken, zumal hd-qualität [1600x1200] unterstützt wird.
leider gibt es unter dem derzeitigen kernel [2.6.21.7] von slugos 4.8 keine oder nur mangelhafte v4l [video for linux] unterstützung und die suche nach dem passenden treiber wurde zu einem hürdenlauf. dennoch läuft bei mir seit heute erfolgreich ein mjpg streamer server dienst unter slugos. legt man auf die distro weniger wert, findet man unter diesem blog bereits ein binary firmware image basierend auf openwrt für die nslu2. hier eine anleitung für all jene die slugos als zielplattform haben.
wir werden die v4l sourcen gegen den aktuell laufenden kernel kompilieren. innerhalb dieses paketes gibt es auch den passenden treiber [ http://linux-uvc.berlios.de/ ] für die logitech quickcam pro 9000.
der reihe nach - wir stecken die camera am usb hub der slug an. lsusb erkennt das device sofort und meldet:

# lsusb –s 2:4 -v
Bus 2 Device 4: ID 046d:0990 Logitech, Inc.
somit kommen wir zur treiberinstallation. download des archives

# wget http://linuxtv.org/hg/~pinchartl/uvcvideo/archive/tip.tar.gz
# gzip –d tip.tar.gt
# tar xvf tip.tar

dannach ins ausgepackte archiv wechseln

# cd uvcvideo-33fd4f6f3afa
# make
# make install

um erfolgreich zu kompilieren wird eine aktuelle linux-src-umgebung vorausgesetzt, zudem benötigt man eine ‚cross-compile-umgebung’ [benötigte packages mittels ipkg zu installieren - autoconf, automake, cpp, g++, g++-symlinks, gcc, glibc-utils, gnu-config, kernel-dev, ldd, libgcc, libglib, make, makedevs, ncurses, ncurses-dev, update-modules ]. ausserdem um kernel module zu kompilieren – git und svn [optware repository].

linux sourcen installieren:

# cd /usr/src
# wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.21.7.tar.gz
# gzip –d linux-2.6.21.7.tar.gz
# tar –xvf linux-2.6.21.7.tar
# ln –s /usr/src/ linux-2.6.21.7 linux
# ipkg install kernel-dev
# cp /boot/ config-2.6.21.7 /usr/src/ linux/.config

damit eventuelle referenzen des treiberpaketes [uvc] auf native kernel-objects gelinkt werden können, kompilieren wir alle kernel-module [nativ auf der slug dauert das etwas ~2h]

# cd /usr/src/linux
# make menuconfig
# make modules

jetzt haben wir unter /lib/modules/2.6.21.7/kernel/drivers/media/video die aktuellen kernel-module der video4linux umgebung, und diese werden von nun an in das memory geladen.

# cd /lib/modules/2.6.21.7/kernel/drivers/media/video
# insmod v4l2-compat-ioctl32.ko
# insmod v4l1-compat.ko
# insmod videodev.ko

… der erste erfolg dmesg liefert
Jan 10 12:07:43 nwal002 Linux video capture interface: v2.00 - von nun an haben wir unser device [ /dev/video0 ]

# cd uvc
# insmod uvcvideo.ko

…
Jan 10 12:08:36 nwal002 uvcvideo: Found UVC 1.00 device (046d:0990)
Jan 10 12:08:36 nwal002 input: UVC Camera (046d:0990) as /class/input/input4
Jan 10 12:08:36 nwal002 usbcore: registered new interface driver uvcvideo
Jan 10 12:08:36 nwal002 USB Video Class driver (v0.1.0)

die installation etwaiger kompatibler softwarepakete [ http://www.quickcamteam.net/software/linux/v4l2-software ] verläuft unspektakulär. recht schnell findet man sich mit uvccapture-0.5, uvc-streamer und eben mjpg-streamer zurecht.
von nun an läuft
# ./mjpg_streamer -o "output_http.so -w `pwd`/www" -o "output_file.so -f pics -d 300000"
als daemon unter non-root-user [ ! /dev/video sollte gruppen berechtigung write gesetzt haben! ] und schreibt zudem alle 5 minuten ein statisches bild, wie z.b. hier.
um den mjpg stream zu genießen [mozilla firefox], browser auf
http://80.109.78.83:443/webcam/ [user:walcherstrasse17, pwd: webcam] und
geniessen...

nwal003 [printserver unter slugos - cups]

während cups [common unix printing system] quasi out-of-the-box seit mehr als einem halben jahr bei mit unter unslung gelaufen ist, war es zeit diese software entsprechend auf slugos zu portieren. die nachteile von unslung habe ich ja bereits ausführlich erörtert, zudem wollte ich weg von dem heterogenen gemisch, hin zu einem einheitlichen standard meiner nslu2 devices.
vorab sei gesagt, daß die schwierigkeit der implementierung dieser software unter slugos lediglich darauf zu führen ist, daß unterschiedliche installations-anleitungen im internet zu verfügung stehen. es hilft hier nichts einen leitfaden für cups unter unslung oder openslug oder debian zu folgen, vielmehr sind die hinweise aller howto’s entsprechend zu beachten. im folgenden eine anleitung und eine auflistung möglicher fallen wie der druckserver unter slugos von mir implementiert wurde, mit einem augenmerk auf vorhandene anleitungen und deren entscheidenden abweichungen zu slugos.
cups steht als package [ipkg] in den meisten distributionen zur verfügung. Während aber unter unslung ein ‚ipkg install cups’ bereits das fundament darstellt, muß unter slugos zunächst einmal gepatcht werden [optware]. es gibt leider kein ‚stable package cups’, dennoch wird man auch für slugos im ‚optware feed’ fündig. cups [version 1.3.9-1] kann hier [http://ftp.easysw.com/pub/cups/1.3.9/cups-1.3.9-source.tar.bz2] downgeloadet werden. damit aber die ‚package chain’ [abhängigkeiten zu anderen packages] berücksichtigt wird, sollte zunächst ipkg einem manuellen bootstrap unterzogen werden. ipkg in der grundinstallation bietet ‚considered stable packages’ als feed an. ‚ipkg update’ hält unter /var/lib/ipkg listen der angebotenen packete zur verfügung. will man aber auf optware repositories [ /opt/lib/ipkg/lists/ ] zugreifen muß man eben ipkg patchen. die grundanleitung gibt es hier.
somit können wir von nun an lediglich durch setzten der path-variable steuern ob wir ipkg mit stable oder eben unstable [optware ] feeds ausführen wollen. beginnend mit
#export PATH=/opt/bin:/opt/sbin:$PATH
setzten wir entsprechend ipkg auf optware-feed [ /opt/bin/ipkg wird nun zuerst berücksichtigt]. weiter der anleitung folgend:
#ipkg install cups
#ipkg install cups-doc [ die statischen html-seiten des web-guis ]
die abhängigen packages libjpeg, libpng, libtiff, openssl, zlib, openldap-libs werden ohne zutun automatisch installiert! wir wechseln in das konfigurations-directory /opt/etc/cups und erkennen die entscheidende config-datei cupsd.conf . [diese ist sehr groß gehalten, und für den ersten schnellen erfolg ungeeignet – security probleme, basic authentication und location directiven werden hier zur ersten unüberwindlichen hürde !!] wir erstellen eine minimalistische cupsd.conf:

[!achtung! – es hat sich herausgestellt, daß eine default policy zieht, falls nicht bestückt wird, die seines zeichen auf basic-authentication beruht. man sieht das sehr schön, wenn man cups hochfährt im error-log.

…
I [21/Nov/2008:10:14:00 +0100] Creating CUPS default administrative policy:
I [21/Nov/2008:10:14:00 +0100] <Policy default>
I [21/Nov/2008:10:14:00 +0100] <Limit Send-Document Send-URI Cancel-Job Hold-Job Release-Job Restart-Job Purge-Jobs Set-
I [21/Nov/2008:10:14:00 +0100] Order Deny,Allow
I [21/Nov/2008:10:14:00 +0100] Require user @OWNER @SYSTEM
I [21/Nov/2008:10:14:00 +0100] </Limit>
I [21/Nov/2008:10:14:00 +0100] <Limit Pause-Printer Resume-Printer Set-Printer-Attributes Enable-Printer Disable-Printer
I [21/Nov/2008:10:14:00 +0100] Order Deny,Allow
I [21/Nov/2008:10:14:00 +0100] AuthType Default
I [21/Nov/2008:10:14:00 +0100] Require user @SYSTEM
I [21/Nov/2008:10:14:00 +0100] </Limit>
…

wir wollen aber diese erste falle vermeiden und definieren eben schön eine policy mit AuthType None !]
damit ist die cupsd.conf konfiguration abgeschlossen und wir widmen uns der eigentlichen printer-installation und treiberdefinition. der mit cups mitgelieferte printers.conf in /opt/etc/cups/ weist einen hp990c drucker aus. dieser ist natürlich nicht meiner, ich verwende vielmehr einen hp deskjet f2100. wesentlich ist aber die device definition unter slugos. wir werden /dev/lp0 als standard drucker device verwenden, obwohl wir eigentlich keinen lp0 – also eine parallele schnittstelle – haben. unter unslung funktionierte derselbe drucker unter /dev/usb/lp0. für die korrekte umsetzung des notwendigen devices wird ein weiteres kernel module zuständig sein. [! achtung ! ipkg feed ist nun cross oder stable – wir entfernen /opt/bin:/opt/sbin aus dem pfad ]

#export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
#ipkg install kernel-module-usblp
#depmod –a /lib/modules/2.6.21.7/kernel/drivers/usb/class/usblp.ko
und editieren unser printers.conf folgedermassen:

jetzt schreiben wir noch ein startskript damit alles richtig zusammenspielt, dabei verwenden wir das mit cups mitgelieferte template /opt/doc/cups/S88cups.
zwei kleine adaptionen sind hierbei notwendig:

• ersetzten der printertreiber-definition
  if ( !(lsmod | grep "^printer" -q) ); then
  insmod /opt/lib/modules/printer.o
  fi
  
  mit siehe [ http://www.nslu2-linux.org/wiki/OpenSlug/InstallCups ]
  
  if ( !(lsmod | grep "^usblp" -q) ); then
  modprobe usblp
  fi
  


• ein vollständiges /etc/init.d/cups.sh script erstellen
  [! Bei einem boot wird das device /dev/lp0 zurückgesetzt auf root:root – wir benötigen aber lp:users ]… somit das vollständige script
  

und die entsprechende verlinkung
#cd /etc/rc3.d
#ln –s ../init.d/cups.sh S88cups
#ln –s ../init.d/cups.sh K11cups

wir starten cups mittels /etc/init.d/cups.sh start
und testen mit einem browser das web-gui http://nwal003:631 – die cupsoberfläche erscheint.
da ich aber primär über windows drucke, werde ich nicht auf das web-gui eingehen, es soll lediglich einen ersten eindruck ergeben.
unter windows installiere ich den druckertreiber, wir haben kein .ppd file in cups hinterlegt [der printer dient quasi als raw device]. Wir definieren ihn als gültigen tcp-netzwerkdrucker und können ab sofort die druckersteuerung vom druckmanager ausführen.