p003876's it

uwal001 [ …the more powerful nas ]

2009-06-15T06:34:00.000-07:00

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]

2009-02-27T02:12:00.000-08:00

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]

2009-02-26T02:23:00.000-08:00

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]

2009-01-19T01:42:00.000-08:00

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]

2009-01-15T03:20:00.000-08:00

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]

2009-01-13T02:01:00.000-08:00

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]

2008-11-21T03:49:00.000-08:00

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.

nwal002 [mounting samba share mittels cifs]

2008-11-19T07:08:00.000-08:00

nachdem ein samba server [nwal001 unter slugos] erfolgreich seine dienste anbietet, und verschiedene windows clients in meinem haushalt bereits darauf zugreifen, war es an der zeit das gemeinsame storage auch an die übrigen nslu2-devices anzubinden. meine wahl fiel, da für slugos bereits kernel-module verfügbar sind, auf cifs [common internet file system].

folgende zusätzliche überlegungen sind hierfür zu beachten

welches gemeinsame character set unterliegt der server-client kommunikation?
welche daten werden eingebunden und welcher security unterliegen diese?

somit ergibt sich folgender installationsplan:
das characterset des samba-servers [siehe /etc/samba/smb.conf] ist wie folgt definiert
…
# charset settings
unix charset = ISO-8859-1
…
damit sollte auf der client-machine [nwal002] zuminderst dieses charset als nls [national language support] kernel-module installiert werden. locale und language settings sollten entsprechend im environment gesetzt sein.

#ipkg install kernel-module-nls-iso8859-1
#export LC_ALL= de_AT.iso885915
#export LANG= de_AT.iso885915

[bem. 8859-1 ist eine untermenge von 8859-15, welches zudem noch das euro-zeichen beinhaltet…] wie die locale als solches unter slugos erzeugt wird habe ich schon in diesem thread abgehandelt.

die eigentliche träger-software [cifs] wird wie folgt installiert.
#ipkg install cifs
#ipkg install cifs-doc
#ipkg install kernel-module-cifs

weitere konfigurationen entfallen und wir können unseren ersten mount-versuch machen.
[/data wird unser mount-point, und data ist unser share am samba server]

#mkdir /data
#mount -t cifs -o username=xxxx,password=xxxx,workgroup=nwal001_smb //samba_server_ip_address/data /data

die workgroup [netbios name] kann ebenfalls aus der samba[server] konfiguration entnommen werden. im falle eines fehlers wird sowohl stdout/stderr bedient, dmesg gibt über dies entsprechende fehlermeldungen.
im success fall, kann nun ein automatismus in /etc/fstab eingeführt werden, in dem auch bereits das charset berücksichtigt ist, und der mount nach einem reboot durchgeführt wird. [eintrag innerhalb /etc/fstab]
//192.168.0.40/data /data cifs user=xxxx,password=xxxx,iocharset=iso8859-1 0 0

auf der server-seite kann man nun mittels smbstatus –v die verbindung überprüfen.

hinweis:
da die anbindung über kernel-module erfolgt [cifsoplockd], [cifsdnotifyd], [cifsd] ist ein trace mittels lsmod, depmod –a, modprobe der entsprechenden module zu empfehlen.

nwal001 [success with slugos] – part 3

2008-11-14T03:10:00.000-08:00

“slugos from the scratch” – vorbereitung einer nlsu2 für samba und twonkymedia server [teil 3]

twonkymedia installation
die architektur spezifischen downloads findet man unter twonkymedia. wir werden den twonky server unter dem user twonky installieren für die architektur ‚arm big endian’. [tinylogin stellt das utility dar, mit welchen man user, gruppen, etc. verwaltet.]
#ipkg install tinylogin
#mkdir /home/twonky
#adduser –h /home/twonky –s /bin/sh –g twonkymedia twonky
#chown –R twonky /home/twonky

jetzt übrprüfen wir, ob die vorhandenen bibliotheken [gnu c library] den prerequisites gehorchen.
#ipkg list_installed |grep –i glibc
wir erhalten ‚glibc-dbg - 2.5-r8 - GNU C Library’, somit können wir folgendes package downloaden.
#su - twonky
#wget http://www.twonkyvision.com/Download/4.4.9/twonkymedia-armeb-glibc-2.2.5-20081002.zip
#unzip twonkymedia-armeb-glibc-2.2.5-20081002.zip

im ~/twonkymedia.sh script muss lediglich folgendes angepasst werden...
WORKDIR1=“/home/twonky“
PIDFILE=“/home/twonky/twonky.pid“

jetzt können wir den server das erste mal starten [!immer mit usage - full qualified path]
#/home/twonky/twonkymedia.sh start
#ps –fu twonky
#netstat –an | grep 9000
letztere 2 commands überprüfen den erfolg des serverstarts [der twonkyserver lauscht default mäßig auf port 9000]

die eigentliche konfiguration des servers erflogt nun bequem im browser. [ http://your_slug_ip:9000/config ]
registrationskey eingeben bzw. unter dem menüpunkt freigaben [sharing / je nach gewählter sprache] kann man die medienverzeichnisse, welche gescannt werden angeben. der default ist das wurzelverzeichnis / . achtung: der user twonky muß lese-rechte auf dieses verzeichnis [bzw. unterverzeichnisse] haben, sonst wird nichts gefunden.

einrichtung des automatischen startes bei boot
unter /etc/init.d ein wrapper script twonkymedia.sh einrichten [sudo]
#!/bin/sh
case "$1" in
'start')
sudo -u twonky /home/twonky/twonkymedia.sh start
;;
'stop')
sudo -u twonky /home/twonky/twonkymedia.sh stop
;;
'restart')
sudo -u twonky /home/twonky/twonkymedia.sh restart
;;
'status')
sudo -u twonky /home/twonky/twonkymedia.sh status
;;
esac

dannach
#cd /etc/rc3.d
#ln –s ../init.d/twonkymedia.sh S44twonky
#ln –s ../init.d/twonkymedia.sh K46twonky

als twonkymedia – client läuft in meinem badezimmer ein noxon i-radio

enjoy :)

nwal001 [success with slugos] – part 2

2008-11-13T07:19:00.000-08:00

“slugos from the scratch” – vorbereitung einer nlsu2 für samba und twonkymedia server [teil 2]

die richtige timezone setzten
#ipkg install tzdata
#ipkg install tzdata-europe
#ln -s /usr/share/zoneinfo/Europe/Vienna /etc/localtime
#unset TZ

locale specific
samba speichert default-mässig dateien im utf8-format, daher möchte ich auch dieses format als locale specific haben. [da der österreichische zeichensatz bereits im ISO-8859-1 abgebildet ist, soll lediglich die locale de_AT mit ISO-8859-15 gebaut werden]
#ipkg install glibc-localedata-en-us
#ipkg install glibc-localedata-de-at+euro
#ipkg install glibc-charmap-iso-8859-15
#ipkg install glibc-charmap-utf-8
#mkdir /usr/lib/locale
#localedef -i de_AT -f ISO-8859-15 de_AT

install additional software packages [crontab, timeserver, perl]
#ipkg install cron
#ipkg install ntp
#ipkg install perl
perl unter slugos ist ein kapitel für sich und ich werde einen eigenen blog darüber verfassen.

ein bißchen memory sparen. wir haben kein serielles terminal angeschlossen, da die slug auch keine serielle schnittstelle hat. wir können problemlos /sbin/getty killen. auskommentieren von S:2345:respawn:/sbin/getty 115200 ttyS0 in /etc/inittab
#telinit q

samba installation und anpassen der konfiguration /etc/samba/smb.conf
#ipkg install samba
#ipkg install cifs-doc
#ipkg install cifs
meine veränderten settings zum default template

[global]
workgroup = myWorkGroupName
server string = myServerString
security = user
hosts allow = myNetwork [192.168.0 127.], also mein gesamtes 192.168.0 netz und localhost
load printers = no
printcap name = /dev/null
guest account = guest
local master = no
unix charset = ISO-8859-1

… und dann meine share definitions [hier eines exemplarisch]
[p003876]
comment = p003876's home
valid users = p003876
path = /home/p003876
public = no
writable = yes
printable = no

achtung: da security user, muß der user sowohl betriebssystemseitig [/etc/passwd] als auch im samba [/usr/bin/smbpasswd] angelegt sein.

unter /etc/init.d liegt das controlscript samba, das mittels stop | start | etc. gesteuert werden kann.

nwal001 [success with slugos] - part 1

2008-11-13T05:34:00.000-08:00

“slugos from the scratch” – vorbereitung einer nlsu2 für samba und twonkymedia server [teil 1]

unslung war dennoch nicht meine wahl für meine erste slug, denn diese sollte zuminderst mehr als 2 festplatten verwalten können [zumal ein port bereits von einem memory stick, auf dem die root partition liegt, belegt ist]. Meine wahl fiel auf slugos/be [nachfolger von openslug], da hier bereits eine unterstützung von usb2.0 hubs im kernel [linux 2.6.21.7] gewährleistet ist. So ergibt sich folgendes hardware-layout für die portzuteilung der nlsu.< br/>
disk2 port: usb-stick, 8gb, transcend jetflash v10 [r:10mb/s, w:3mbyte/s]
disk1 port: dlink dub-h7/e hub

die installations prozedur im detail:

beginnend mit #upslug2 wird die firmware slugos 4.8-beta release geflasht. [ssh ist bereits teil der firmware]

nach erfolgtem reboot – partitionierung des boot-devices [memory stick an port2]
/dev/sda1 wird träger des rootfs, /dev/sda2 wird swap bereich, /dev/sda3 user-data

disk initialisierung und rootfs-migration
#mkfs.ext3 /dev/sda1
#mkswap /dev/sda2
#swapon /dev/sda2
#mkfs.ext3 /dev/sda3
#turnup memstick –i /dev/sda1 –t ext3
[die option memstick wurde aus dem grunde gewählt, damit keine unnötigen logging zugriffe i/o waits durch den langsamen memory stick verursachen. das /var und /tmp filesystem liegt zur gänze im ram bereich!]

editieren der /etc/fstab

reboot – ein vollständiges slugos system steht zur verfügung, und additional software-packages können installiert werden.

anpassung /etc/hosts und /etc/resolv.conf

installation von udev [automatisches mounten von usb-devices hinter dem usb hub]
#ipkg install udev
[usb-hub wird an port disk1 angehängt, jetzt kann ich dahinter bis zu sieben usb devices verwalten. 3 vorhanden ext3-formatierte hdisks werden attached.]
um den nachteil vom automatischen mount [zuteilung device und fs-mountpoint] und deren willkürlichkeit zu umgehen, entscheide ich mich für den einsatz von uuids.

#/lib/udev/vol_id –u devicename
liefert eine unique uuid, die im /etc/fstab berücksichtigt wird. das automatische mounten mittels eintrag von sd[b-z][1-9]$ in /etc/udev/mount.blacklist verhindern. somit ergibt sich eine starre zuordnung von /dev/sdb1, /dev/sdc1 und /dev/sdd1 an die mountpoints /backup, /multimedia und /data. damit ergibt sich die neue fstab

nslu2 firmware aspekte [linksys vs. unslung]

2008-11-13T02:57:00.000-08:00

wie verwalte ich meine usb festplatten?

wir haben jetzt ein computer device mit einem schnellen 266 mhz prozessor, und mit dem vorhandenen microcode v2.3r63/a5 (etsi) von linksys läßt sich sehr schnell einen gewissen erfolg erzielen, jedoch stoßt man ebenso schnell an die grenzen dieses kernels. der hauptgrund sich auf die suche einer alternativen firmware zu begeben war aber das black-box modell von linksys, das sich gewissermassen hinter einer web-applikation versteckt. die festplatten können zwar formatiert werden [partitionen werden nicht unterstützt], die wahl des zugrunde liegenden filesystems wird schon wieder kompliziert [fat, fat32, ntfs, ext2, ext3, raiserfs, etc...]. logische datenträger-verwaltung [raid verbände] werden zur gänze ignoriert. die verwaltung des built-in samba und das dahinterliegende benutzerschema mehr als kompliziert.

irgendwann stößt man auf nslu2-linux.org, das forum schlecht hin, wenn es um die slug geht, und schon vollziehe ich mein erstes firmware-flash [unslung 6.8 beta]. Die funktionalität des linksys-kernels bleibt bei diesem microcode vollständig erhalten, die zu erwähnenden additonal capabilities sind:

ntfs volumes werden unterstützt
ext3 filesysteme an beiden usb ports
ein gewisser support von usb hubs [ubs 1.0]
möglichkeit zur installation von samba 3
software-package installation [ipkg]
telnet zugang zur slug

auf grund der internen 32mbyte speicher begrenzung stellt sich sehr schnell die frage, wie und wann die rootfs [das, dem kernel zugrunde liegende root filesystem] auf einen externen datenträger [usb memory stick, hard disk, nfs, etc.] ausgelagert werden kann. die neu geflashte unslung firmware bietet hier bereits abhilfe. usb-stick an port2 angeschlossen, formatiert [ext3 fs], telnet aktiviert [http://your_slug_ip/Management/telnet.cgi] und schon gelangt man mittels telnet-client als user root [pwd: uNSLUng] auf die box. endlich wird es spannend, unter /sbin liegt ein shell script namens unsling, denn so wird auch der vorgang des auslagerns der rootfs genannt. dem trivialen argument [disk1/2 – wohin soll ausgelagert werden] kann auch ein [-nopw] folgen, das eine mandatory änderung des root passwords im script ablauf verhindert. „/sbin/unsling disk2“ wird in meinem fall ausgeführt, das im memory liegende jffs2 [journalling flash file system version 2] wird an /initrd unter /dev/sda1 gemountet. nach erfolgtem reboot erkennt man zunächst unter http://your_slug_ip einen status in der fuß-zeile [unslung to disk2, /dev/sda1] und im header die aktuelle firmare version [v2.3r63-uNSLUng-6.8-beta]. das offensichtlich neue unslung logo erhält man auch bereits ohne auf ein externes device ungeslingt zu haben.

erneut wird telnet aktiviert und nach erfolgtem root zustieg wird als erstes software package ssh installiert. „ipkg install openssh“ – wir wollen in der zukunft keinen browser mehr öffnen müssen und den zugang zur slug lediglich mittels ssh abwickeln.

network storage link for usb 2.0 disk drives [nslu2]

2008-11-13T01:02:00.001-08:00

in der zwischenzeit verlasse ich mich bereits auf die stabilität und zuverlässigkeit von drei dieser kleinen devices. anfänglich als billiges nas zur verwaltung meiner daten gedacht, stoßt man ziemlich schnell an die grenzen der out-of-the-box firmware von linksys. zu viele verlockende software packages werden in alternativen firmware kernels propagiert, zumal ein 24x7 betrieb wirtschaftlich deutlich kostengünstiger abschneidet als ein fetter server. mit einem stromverbrauch von gerade mal 5-20 watt [je nach angeschlossener peripherie ~ drucker, festplatten, usb-devices, etc.] kostet der einsatz einer box gerade mal ~35 euro per anno. im folgenden die technischen success stories der devices.

mein stromsparscript

2008-09-22T02:22:00.000-07:00

ich vertraue prinzipiell nicht etwaigen guis, die mit ein paar check-boxen bedient werden, und schon hat man einen energiesparplan!?! [start - einstellungen - systemsteuerung - energieoptionen - ...]! nein, ich möchte auf meine art steuern können, wann und wie mein htpc schlafen geht. das folgende perl-script, welches alle 5 minuten unter der kontrolle des vista task scheduler läuft, tut genau dies.

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

teil 1 des scriptes
initialisierung des scriptes, win32::mutex wird geladen, damit eine gewisse option offengehalten wird, andere scripts parallel auszuführen. tlist.exe zur überprüfung, welche prozesse laufen, ehrec.exe [läuft eine aufnahme?], ehshell.exe [vmc shell aktiv], und natürlich ein shutdown commando. gibt es das unc-share \\nwal001\... so werden hier parameter überschrieben. nwal001 ist eine linksys nslu mit openslug os.

teil 2 des scriptes [logik]
zeile 44: ist ein mutex namens 'backup_active' gesetzt [ein anderes script, welches dateien sichert und lange läuft, hier soll natürlich nicht schlafen gegangen werden!!], zeile 49: hier wird händisch gesteuert, ob aus irgend einem grund kein schlaf erwünscht ist, und falls doch [zeile 55] bitte nicht schlafen, sondern herunterfahren [shutdown /r /f]. ansonsten wie gewohnt einmal einen netstat befehl absetzten um zu sehen ob ein client [xbox360] vielleicht connected ist.

teil 3 des scriptes [logik]
kein client connected [else zweig zeile 80], prüfe ob andere faktoren zutreffen, sodass keine hibernation laufen soll, wie z.b. - läuft vielleicht mce local, oder wird gerade aufgenommen? trifft dies alles nicht zu, bitte schlafen gehen! [zeile 98 mit shutdown.exe /h /f !...]

teil 4 des scriptes [subroutine]
hier wird lediglich ein rotierendes log file initialisiert [log4perl], wohin stdout bzw. stderr wandern und housekeeping gewährleistet ist.

denkbar einfach, doch letzten endes entscheide nur ich, wann der rechner wirklich schlafen geht, ausserdem ist dieses script beliebig erweiterbar!

wirtschaftliche überlegungen!

2008-09-02T01:39:00.000-07:00

es war von aller erster stunde klar, dass dieser multimedia pc stets für etwaige clients zur verfügung stehen muss. vmc liefert ein bereits bekanntes konzept [windows xp professional] namens media center extender [mcx]. heute aber eine technologie der zweiten generation [codename pica] die keine abwärtskompatiblität aufweist. da mein rechner im idle zustand durchschnittlich gemessene 120 watt verbraucht, ergibt sich für das 'nichtstun [=warten auf etwaige clients]' ein jährlicher aufwand von ca. 200€.
das muss sich ändern, das os bringt ja auch genügend möglichkeiten [stromsparpläne] dafür mit. verschiedenste hardware unterstützt unterschiedliche acpi modi [einfach rausfinden - cmd.exe/powercfg]. nach mehrmaligen messen und herumspielen, stellt sich der s3 modus [suspend to memory] als optimal heraus. die leistungsaufnahme beträgt nur noch durchschnittlich 5 watt, ein 'zurückholen' in den s0 modus mittels wakeonlan dauert knappe 10 sekunden. s4 [suspend to disk] weist sich als weniger effizient heraus, da die leistungsaufnahme sich zwar nur mehr mit 2-3 watt darstellt, aber ein 'aufwachen' mehr als [lange] 40 sekunden benötigt. der in der vmc [extender] einrichtung empfohlene 'away modus' [mischung aus s1/s2], also abschaltung nicht mehr benötigter komponenten [z.b. monitor], ist definitiv eine teure alternative. das system steht zwar immer zur verfügung, benötigt aber ebensoviel leistung wie ein herkömmlicher s0 modus. da nun die stromspar-strategie gefunden war, musste ein implementierungsplan erstellt werden.

vista media center ...

2008-09-01T02:25:00.001-07:00

das betriebssystem meines neuen rechners war mit microsoft windows vista home premium 32 bit quasi vorgegeben. persönlich hatte ich schon lange nicht mehr mit windows gearbeitet. so war es nicht erstaunlich, dass die neue oberfläche anfänglich sehr schwer zu bedienen war. als erster schritt wird als gegenmassnahme quasi, ein alter windows nt resource kit deployed. sehr schnell bemerke ich, dass unter der haube des os nicht sehr viel neues steckt [service manager, acl, registry, etc. ~alles sehr vertraut], zumal mein vergleich [=letzte windows erfahrung] windows professional 2000 darstellt. der hersteller des desktops [sony] spart zusätzlich nicht mit [eigener] software. ich konzentriere mich aber lediglich auf das wesentliche, unnötige software wird sofort deinstalliert. mein fokus liegt definitiv an der reibungslosen funktionalität von vista media center, welches die multimediale schnittstelle auf diesem rechner darstellen soll.

user account control [endlich mal was neues!] wird deaktiviert [hklm\software\microsoft\windows\currentversion\policies\system enablelua {dword} 0|1 ], nicht benötigte services ['themes' der resourcenkiller schlechthin!] werden mittels sc command disabled. noch die neuen treiber darauf [nvidia, intel gigabit ehternet lan], perl als mein persönlicher favorite für zukünftige batch-scripts installiert, der wirelss ethernet adapter disabled. [bermerkung - diese zeilen lesen sich womöglich flüssig, es entseht ein eindruck - rechner auspacken, und los. aber jeder meiner erwähnten schritte war für sich ein kampf, diverse beiträge darüber füllen ganze foren. hiermit mal ein grosses dankeschön an die foren www.mce-community.de, www.avsforum.com, thegreenbutton.com, und andere, ohne deren beiträge und erfahrungen für mich sehr viele probleme ungelöst bleiben [ich denke nur an das 'black screen boot' problem - nvidia geforce 7600gtl / 1080p hdmi].

endlich, dass erste mal vista media center im vollbildmodus aufgerufen. das initiale setup beider avermedia hybrid tv-karten verläuft unspektakulär, der download des aktuellen epg rasch. das demovideo zur einrichtung der bildschirmauflösung verspricht lust auf hd, zumal flat-tv und video-karte full hd unterstützen. die bedienung mittels media center remote control ist noch sehr gewöhnungbedürftig, meine harmony remote 785 wird in zukunft diese aufgaben übernehmen. indirekt habe ich bereits jetzt einen funktionstüchtigen video-recorder mit time-shifting funktionalität. gedanken zur seperation von userdaten [=aufnahmen, multimedia dateien, etc] und systemsoftware mache ich mir zu diesem zeitpunkt noch nicht. bald werden terabyte platten im raid-1 [spiegelung] verbund, träger dieser daten sein. meine alten vhs-kassetten sind bereits - dank den zahlreichen anschluss-möglichkeiten [cinch, super-vhs] digitlisiert und werden problemlos im mpeg format abgespielt. meine mp3 daten [ca. 1200 alben!] werden im laufe der zeit immer wieder im windows media player 11 [datenquelle für vmc] erfasst, analog meine bilder.

mittels optischen kabel wird der wirklich beeindruckende sound vom 'sigmatel cxd9872rd chip' an meinen 5.1 receiver weitergegeben, ein component kabel hat das leider noch immer nicht funktionierende hdmi [handshake] zum flat-tv ersetzt. es wird zeit, dieses multimediale vergnügen einer stromverbrauchs-rechnung zu unterziehen.

die magritzer familie

mein neuer htpc!

2008-08-29T02:41:00.000-07:00

im mai 2007 traf ein neuer‚ sony vaio vgx-xl301 bei mir ein. die vorteile dieses rechners werden ausführlich [z.b. hier] beschrieben. meine anforderungen und erwartungen an das gerät waren zudem vielschichtig.

absolut geräuschloser betrieb [7x24]
verteilen des tv-signales (upc telekabel analog) in meine unteren räume
digitalisieren meiner vorhandenen vhs-video-tapes
ersatzloser austausch meines in die jahre gekommenen video recorders
einführung eines epg zur erleichterung der aufnahmen
aufbau einer multimedialen datenbank verschiedenster quellen (cd, dvd, mp3, pics, etc…)
internet surfen im wohnzimmer vom sofa aus, auf meinem flat tv (‚sony bravia kdl 40 w2000')

heute mehr als ein jahr später, [ein paar ungeplante zusätzliche euro ärmer !] kann ich sagen, dass alle oben erwähnte punkte zu meiner zufriedenheit umgesezt wurden. Im folgenden werde ich mit euch die fallen, problemchen und workarounds teilen, welche die hochglanzfolder der hersteller hartnäckig verschweigen.

topologischer überblick

2008-08-28T04:33:00.000-07:00

mein erstes mal!

2008-08-28T00:58:00.000-07:00

beruflich, als senior system engineer hat mich das private dokumentieren [=bloggen] zusätzlich zur arbeit, eigentlich nie so richtig interessiert. aber man muss mit dem zeitgeist gehen, und so hab ich demnächst hier viel vor... ich möchte hier mit euch meine erfahrungen teilen, technische details austauschen, rezepte für allerlei technischen schick-schnack preisgeben, und so vielleicht auch für mich ein kleines dokumentationsarchiv zum nachschlagen erschaffen.

mein hauptinteresse an der it im privaten umfeld ist zum einen interesse an technischen neuheiten, aber auch zweckmässiges, wie archivieren von persönlichen daten. dies hier als mein erstes post, soll lediglich eine art begrüssung darstellen. euer p003876