|
Saturday, 28. January 2012
Das Ziel: Existierende Dateien werden normal angezeigt. Bei nicht existierenden Dateien wird statt Error 404 der Erfolgsstatus 200 und ein Standard-Dokument ausgegeben.
Klingt einfach? Ist es nicht. Das liegt primär daran, dass dafür mod_rewrite braucht, wofür keine gescheite Dokumentation existiert (ist ja schön, wenn die offizielle Doku alle verfügbaren Variablen auflistet, sie aber nirgends erklärt...) und alle bestehenden Howtos irgendwo einen Fehler machen oder diesen zugegebenermassen sehr speziellen Fall überspringen.
So scheitern praktisch alles bestehenden Vorschläge an der fehlerhaften RewriteCond: RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
-d und -f prüfen aber den absoluten Dateisystempfad, während REQUEST_FILENAME nur den Teil enthält, welcher in der URL nach dem Hostname steht, d.h. http://www.example.com /requested/filename.html. Somit werden diese Rewrite Conditions sowieso niemals zutreffen. Nun gibt es zwei Lösungen dafür. Entweder den ausschliessenden Weg, dass man alle existierenden Dateien von Hand explizit spezifiziert, z.B. RewriteCond %{REQUEST_FILENAME} !^/robots.txt$
RewriteCond %{REQUEST_FILENAME} !^/favicon.ico$
Nur hat dies zwei Nachteile, es ist aufwändig und unflexibel. Na gut, die simplere Lösung ist es den vorangehenden Pfadnamen hinzuzufügen, dafür gibt es die glücklicherweise vom Namen her sprechende DOCUMENT_ROOT Variable (eine offizielle Dokumentation, wo diese beschrieben wird, ist aus irgendwelchen Gründen schwierig zu finden...), so dass eine funktionierende, flexible und universelle Regel etwa so aussehen könnte: RewriteEngine on
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-d
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME} !-f
RewriteRule ^.+$ /index.html [L]
Thursday, 19. January 2012
Hat man fetchmail erfolgreich konfiguriert und als Cronjob ein simples fetchmail -s eingerichtet, so wird sich der Cron Daemon über einen Fehler beschweren, wenn keine Mails im Postfach zur Abholung bereit lagen. Grund dafür ist, dass fetchmail nur 0 als Exit Code zurückgibt, wenn es erfolgreich Mails abgeholt hat. Lagen keine Mails im Postfach, lautet der Exit Code 1, was von Cron völlig berechtigt als Fehler bemängelt wird. Ein kurzes Studium von man fetchmail hat mir dann die Lösung gebracht, der Cronjob ist jetzt folgendermassen konfiguriert:
*/15 * * * * fetchmail -s || [ $? -eq 1 ]
Friday, 13. January 2012
Der rar-Archiver scheint eine praktische Funktion zu besitzen, nämlich das automatische Splitten beim packen. Ich muss diese Funktionalität mutmassen, da ich rar nicht zum packen verwende, da es unfrei ist. Und überhaupt gibt es in der freien Welt so viele Formate, dass ich dieses problemlos links liegen lassen kann. Jedenfalls resultiert das ganze in Dateien mit der Endung foobar.part1.rar, foobar.part2.rar etc. Das scheint wohl ganz praktisch zu sein für ein very poor man's Backup auf CDs.
Nun hatte ich neulich das Vergnügen, so eine Archivserie zu entpacken, bei welcher eines dieser Teilstücke verloren gegangen ist. Beim packen könnte wohl angeben, dass ein "recovery volume" angelegt werden soll, womit der Verlust eines Teils kompensiert werden kann. Aber wer denkt schon an sowas  Rar wird nun zwar anfangen zu entpacken, bricht dann aber bei der ersten Datei ab, welche sich (partiell) im verlorenen Teil befindet. Tja, nun hat man also den ersten Teil seines Backups, aber die Daten von hinter dem fehlenden Stück scheinen nicht zugänglich zu sein. Auch eine Suche mit Google hat hier nicht gross weitergeholfen, der Tenor war stets " kannst du vergessen, geht nicht". Aber das stimmt definitiv nicht! Man braucht sich also nicht zu ärgern, dass das Einlesen von 20 CDs oder das herunterladen von 100GB Daten für die Katz war. Zwar kennt rar den Parameter -kb, welcher defekt extrahierte Dateien behalten soll, aber das funktioniert in diesem Fall nicht. Der Entpackvorgang bricht trotzdem ab ( hier für Klickibunti-Windosen).
Hier der Trick: Angenommen, part4.rar fehlt. Also erstellt man erst einen scheinbaren Teil 4. Am einfachsten kopiert man einen anderen Teil:
cp foobar.part3.rar foobar.part.4.rar
Nun startet man den nächsten Entpackvorgang, schliesst jedoch die als defekt gemeldete(n) Dateien über den exclude-Parameter aus. Wichtig ist die korrekte Syntax zu beachten, nach dem -x darf kein Leerzeichen folgen und Dateinamen mit Leerzeichen müssen zwischen Hochkommata stehen:
unrar x -x'pfad/zu/defekter datei.xls' -x'pfad/zu/ebenfalls defekter datei.doc' foobar.part1.rar
Schon entpackt es weiter.
Natürlich fehlen letztendlich ein paar Daten unwiderbringlich. Aber sofern es sich um eine Notrekonstruktion aus einem defekten "very poor man's" Backup handelt, ist das doch schon besser als gar nichts mehr zu haben.
Friday, 6. January 2012
Vor etwa einem Jahr habe ich mir einen neuen Server zusammengebaut. Eigentlich wollte ich damals eine CPU, welche drei Anforderungen erfüllt: x86 64bit, virtualisierungsfähig und sehr stromsparend. Leider konnte jede vorhandene CPU höchstens zwei der Kriterien erfüllen, insbesondere bei Intels Atom sind auch heute noch Punkt eins und zwei gegenseitig ausgeschlossen. Und das stromsparendste von AMD war der Athlon X2 240e, welchen ich zuletzt ausgewählt hatte. Monate später wurden dann die Atom-Konkurrenten von AMD veröffentlicht. Zwei Geräte für Tests mit Cluster- und sonstigen Basteleien mit einer derartigen Zacate-CPU habe ich mir nun besorgt, und zwar zwei ZBOXen von Zotac. Diese sind extrem günstig, komplett ausgestattet und befreit von Microsoftsteuern. Zum einen habe ich mir einen Nano gekauft, da dieser mit Fernbedienung geliefert wird, so dass ich diesen später zu einem Multimediarechner umfunktionieren kann. Und zum anderen einen ADO2, da dieser im Gegensatz zum Nano Platz für zwei Speichermodule bietet, so dass er auf 8GB RAM ausgebaut werden kann.
Bei so schönen Geräten muss natürlich erst mal die Hardware etwas genauer getestet werden, statt sie nur im Konsolenmodus zu betreiben. Dazu wollte ich ein paar Betriebssysteme installieren. Ubuntu Desktop 11.10 lässt sich fast problemlos installieren. Die Installation von Ubuntu Server 11.10, Debian 6 und CentOS 6.2 scheitert jedoch an einem Punkt: Beim Laden des Installers geht plötzlich die Tastatur verloren. Natürlich kann jedes Huhn Debian installieren, wenn genügend Körner auf der Tastatur liegen. Aber die Tastatur muss halt funktionieren. Interessanter- und glücklicherweise tritt das Problem beim Ubuntu Desktop nicht auf, so, dass sich dieser mässig bequem installieren lässt.
Das Problem mit den USB-Tastaturen lässt sich auch mit keiner BIOS bzw EFI-Konfiguration beheben. Ich habe alle USB-Einstellungen in jeder Kombination getestet, in letzter Verzweiflung sogar USB-Legacy deaktiviert. Dazu steht im BIOS-Setup, dass dadurch USB-Geräte nur noch in EFI-Applikationen zur Verfügung gestellt würden. Tja, das BIOS-Setup ist blöderweise keine EFI-Applikation, so dass ich nun ganz ohne Tastatur dastand und dies somit nicht mehr einfach korrigieren konnte. Daher musste ich erst mal das CMOS resetten, was zum Glück recht simpel ist. Man muss die Bodenplatte des Geräts entfernen, d.h. erst die vier Daumenschrauben lösen, welche auch als Standfüsse dienen, und dann an der eingekerbten Ecke den Fingernagel einsetzen und die Bodenplatte herausreissen. Nun hat man Zugriff auf alle relevanten Innereien, d.h. Festplatte, WLAN-Karte und RAM-Sockel, so dass man an dieser Stelle auch einfach ein RAM-Upgrade durchführen kann. Für den Reset muss einfach der gummierte, unbeschriftete Knopf zwischen WLAN- und Speichermodul ein paar Sekunden gedrückt werden. Eine bebilderte Anleitung dafür findet sich leicht, jedoch ist in dieser der Reset-Knopf nicht ersichtlich.
Die Geräte verfügen über kein BIOS sondern das modernere EFI. So schöne Vorteile (wie z.B. richtig grosse Platten ohne Workarounds) das bietet, so wüste Nachteile bei der Bootloader-Installation zieht es mit sich. Zur Installation von Ubuntu bin ich folgendermassen vorgegangen: - Zuerst habe ich von meinem bevorzugten Mirror das CD-Image für Ubuntu Live 64bit heruntergeladen und dieses mittels unetbootin auf einen bootbaren USB-Stick geschrieben. Diesen habe ich dann in den Zotac eingsteckt und das Gerät eingeschaltet.
- Wenn die Startpiepser ertönen (ähnlicher Klang wie die Telefone in 24), ein paar mal auf DEL hämmern, um ins BIOS-Setup zu gelangen. Unter "Boot" muss die Startreihenfolge angepasst werden, so dass zuerst ab USB-Stick gestartet wird.
- Jetzt erscheint der Bootloader und kann man entweder Ubuntu Live starten und dort das Setup aufrufen oder grad den Installer starten.
- Die Festplatte muss unbedingt manuell partitioniert werden, denn EFI verlangt eine EFI-Partition. Der gparted-Verschnitt des Ubuntu-Installers legt gleich eine GPT-Partitionstabelle an, so dass als erste Partition eine FAT32-Partition von mindestens 200MB angelegt werden kann. Die Schwierigkeit besteht darin, dieser noch das Flag bios_grub gesetzt werden muss. Unter Ubuntu Live ist das kein Problem, da partitioniert man einfach vorher rasch mit gparted. Wichtig ist, dass man die ganze Platte löscht und eine neue Partitionstabelle vom Typ GPT anlegt.
Im reinen Installer-Modus wechselt man mittels ctrl-alt-F1 in die Konsole, startet mittels
$ sudo parted
eine parted-Shell und setzt das Flag rasch per Kommando
set 1 bios_grub on
(tatsächlich habe ich im Arch-Wiki gelesen, dass man das Flag boot setzen muss, aber dann meckern später EFI und grub-installer). Zurück zum Installer gelangt man durch alt-F7. - Nun installiert man Ubuntu ganz normal fertig. Bloss neu starten sollte man noch nicht! Zuerst muss grub noch richtig installiert werden. Dazu wechselt man wieder in die Kommandozeile (bzw öffnet eine Shell in Ubuntu Live) und gibt folgende Befehle ein:
$ sudo mount /dev/sda2 /mnt (/dev/sda2 muss ggf durch die korrekte Angabe für die Root-Partition ersetzt werden) und
$ sudo grub-install --root-directory=/mnt /dev/sda (auch hier muss /dev/sda ggf durch die korrekte Angabe für die Platte, worauf Ubuntu installiert wurde, ersetzt werden). - Jetzt kann man neu starten und Ubuntu sollte fehlerfrei booten. Die EFI-Warnmeldungen bezüglich Bildschirmauflösung und "file not found" kann man ignorieren.
Die Leistung der Geräte ist nicht schlecht. Sogar Nexuiz läuft passabel wenn der proprietäre AMD-Treiber fglrx installiert wird, bei 1024x768 ist es mit 40-70FPS absolut spielbar. Bei höheren Auflösungen kommt die Grafikeinheit aber an den Anschlag.
Wednesday, 17. August 2011
Ab und zu braucht oder möchte man mal unter Debian Stable ein neueres Programm installieren. Oft findet sich dies in Unstable oder gar Testing, aber leider gibt's dann oft keinen Backport. Das ist aber kein Problem. Meine Backports bau ich anhand dieser Anleitung, mit einigen Ergänzungen. Hier erläutere ich dies am Beispiel des Messengers Pidgin:
Als erstes werden mir root-Rechten die benötigten Abhängigkeiten für den Bau des Pakets installiert: # aptitude build-dep pidgin
Bis auf weiteres können alle weiteren Schritte als normaler User ausgeführt werden. Als nächstes wird die Source und die Debian-Modifikation von packages.debian.org heruntergeladen und in ein eigens für den Build erstelltes Verzeichnis kopiert: $ mkdir pidgin
$ cd pidgin
$ wget http://ftp.de.debian.org/debian/pool/main/p/pidgin/pidgin_2.9.0.orig.tar.bz2
$ wget http://ftp.de.debian.org/debian/pool/main/p/pidgin/pidgin_2.9.0-3.debian.tar.gz
Nun wird entpackt: $ tar -jxf pidgin_2.9.0.orig.tar.bz2
$ cd pidgin-2.9.0
$ tar -zxf ../pidgin_2.9.0-3.debian.tar.gz
Der nächste Schritt ist etwas fummelig. Allenfalls müssen Abhängigkeiten angepasst werden, weil das Debian-Skript eine neuere Version einer Abhängigkeit fordert als nötig und/oder für Debian Stable verfügbar ist. Fehlerhafte Abhängigkeiten können einfach bestimmt werden, indem man den nächsten Schritt ausführt und den Kompiliervorgang versucht zu starten. Zur Bereinigung von Abhängigkeiten mit unnötig hoher Version muss die Datei debian/control bearbeitet werden.
Einige benötigte Abhängigkeiten mit höherer Version lassen sich aus den Backports installieren, dies klappt mittels aptitude -t squeeze-backports install myrequireddependency (vorausgesetzt, das backports-Repository ist konfiguriert). Für einige ganz fiese Abhängigkeiten kann es nötig sein, dass man davon selbst ein Update gemäss dieser Anleitung erstellen und installieren muss.
Sind alle Probleme behoben, kann man nun den Compiler anwerfen lassen: $ dpkg-buildpackage -rfakeroot -uc -b
Wenn dies erfolgreich war, erhält man ein installationsbereites .deb-Paket. Für die Installation sind natürlich wieder root-Rechte erforderdlich: $ cd ..
$ su
# dpkg -i *.deb
Saturday, 30. April 2011
Bislang gab es relativ gute Pakete für Mumble 1.2.3 aus Debian Experimental, welche sich sauber unter Debian Squeeze installieren liessen. Unterdessen gibt es einen neuen Build, der auch grad das ganze QT aktualisieren will. Da dürfte ein ziemlich defektes System daraus resultieren. Logische konsequenz? Selber bauen natürlich 
zuerst das alte Mumble deinstallieren: aptitude purge mumble
Danach geht's eigentlich streng gemäss Wiki. Als nächstes muss man die benötigten Entwicklungspakete installieren: apt-get build-dep mumble
Und nun die Source mit den gewünschten Parametern kompilieren. Ich brauch weder Server noch den Mumble 1.1 Clienten. Letzterer wird über den nicht dokumentierten Switch no-11x deaktiviert. Unter Debian werden die Lokalisierungen nicht gefunden und integriert, daher werden diese einfach ausgeschaltet. Vermutlich liesse sich das über Symlinks korrigieren tar -zxf mumble-1.2.3.tar.gz
cd mumble-1.2.3
qmake-qt4 -recursive main.pro CONFIG+=no-server CONFIG+=no-embed-qt-translations CONFIG+=no-11x
make
su -c 'cp -r release /opt/mumble'
su -c 'cp icons/mumble.xpm /opt/mumble'
Und nun noch die Sache starten: /opt/mumble/mumble
Tuesday, 22. February 2011
Dank virt-manager kann man auch mit kvm und xen per Klickibunti übers Netzwerk administrieren. Nur, unter Debian kann es vorkommen, dass alles korrekt eingerichtet ist (libvirtd läuft, User ist in der Gruppe libvirtd, /var/run/libvirt/libvirt-sock ist zugreifbar), trotzdem weigert sich der virt-manager mit der Meldung "Unable to open a connection to the libvirt management daemon. Verify that: - The 'libvirtd' daemon has been started"
Liest man die Meldung weiter, so stösst man auf die Zeile error: server closed connection: nc: invalid option -- 'U'
Die Lösung: Debian installiert standardmässig netcat-traditional. Das unterstützt aber die Option U nicht. Dafür wird netcat-openbsd benötigt. Folglich kann man das beheben mittels aptitude install netcat-openbsd
Zum Glück ist Debian Stable ja sooo bugfrei.
Friday, 18. February 2011
Sobald man mehr als zwei Monitore angeschlossen hat, beginnt Gnome bei der Multimonitorfähigkeit zu versagen. Ich habe zwei Monitore zu einem grossen Desktop zusammengefasst (AMD nennt dies in seinen proprietären Treibern BigDesktop) und einen weiteren Monitor separat laufen. Leider maximieren sich Fenster nun über den ganzen Dualscreen statt sich perfekt auf einen Monitor einzupassen. Besonders mühsam ist dies, wenn man ein Video im Vollbildmodus betrachten will. Mit nur zwei angeschlossenen Monitoren passiert dies nicht - selbst wenn diese zu einem grossen Desktop zusammengefasst werden. Interessanterweise sind aber das Hintergrundbild sowie die Panel perfekt an den Monitor angepasst. Da kommt als Verdächtiger folglich rasch der Window Manager, also Metacity in Frage.
Folglich habe ich diesen durch diverse andere Varianten ersetzt. openbox scheitert genau so am Multimonitor und mutter stürzt direkt mit Speicherzugriffsfehler ab. Aber xfwm4 aus Xfce4 funktioniert gemäss Wunsch. Allerdings braucht es dann noch einiges an Tweaking, bevor das ansonsten gewohnte Metacity-Verhalten wiederhergestellt ist (und ein paar sehr nette Komfortfunktionen dazugewonnen wurden).
Zunächst muss xfwm mit ein paar Accessoires installiert, gestartet und konfiguriert werden. Alle Angaben sind wie üblich für Debian und verwandte Systeme:
su
aptitude install xfwm4 xfce4-utils xfce4-settings
exit
xfmw4 --replace &
xfwm4-settings
xfce4-settings-helper
Der xfce4-settings-helper verschwindet sofort im Hintergrund und aktiviert die Tastenkürzel wie z.B. Alt-F2 wieder.
Jetzt stört mich nur noch, dass Fenster auch beim Scrollen mit dem Mausrad Fokus bekommen. Dies lässt sich über den xfce4-settings-editor abstellen, indem man den Wert des Eintrags /xfwm4/raise_with_any_button auf FALSE setzt.
Soweit so einfach. Kommen wir nun zum zeitlich aufwändigsten Teil. Um nun xfwm4 permanent als Standard einzurichten, gibt es unzählige Möglichkeiten. Ich habe nur eine gefunden, die "gefühlt fehlerfrei" funktioniert und diese ist technisch gesehen totaler Blödsinn. Und zwar habe ich in gnome-session-properties zwei neue Starter angelegt. Einer startet /usr/bin/xfwm4 --replace und ein zweiter /usr/bin/xfce4-settings-helper. Das ist natürlich insofern doof, da erst metacity und danach xfwm4 als Ersatz gestartet wird. Dies führt bei mir jedoch zu absolut keiner Startverzögerung, ganz im Gegensatz zu der Variante, eine ~./gnomerc anzulegen und darin die Zeile export WINDOW_MANAGER="/usr/bin/xfwm4" einzufügen. Das Resultat ist ein um 10 Sekunden verzögertet Start von Gnome. Das ist natürlich nicht akzeptabel. Ebenso gibt es die Variante im gconf-editor unter /desktop/gnome/session/required_components den Schlüssel windowmanager von gnome-wm zu xfwm4 zu ändern. Das Resultat hierbei war, dass gar kein Window Manager mehr gestartet wurde. Also noch schlimmer! Tja, und unter Debian gibt's noch die /etc/alternatives/x-window-manager. Diesen Symlink von /usr/bin/metacity auf /usr/bin/xfwm4 zu ändern bringt grad gar nichts, da dieser Symlink auf meinem System von gnome-wm (ist nur ein Shellskript) gar nicht ausgewertet wird.
Somit wär also ein Freitagabend verschwendet, weil Debian Stable ja sooo bugfrei ist.
Tuesday, 25. January 2011
Schade, dass nagelneue Boards immer noch dieses eklige BIOS statt dem wesentlich moderneren EFI mitbringen. BIOS und Grub können nämlich nichts mit GPT anfangen, was für grosse Partitionen über 2TB aber notwendig ist. Und BIOS bzw MBR begrenzt die Partitionsgrösse auf anachronistische 2TB. Denn wenn man schon 4*2TB kauft, um ein anständiges NAS zu basteln, will man sich nicht lange mit Daten hin-und-her-Schaufelei von Partition A nach Partition B und zurück befassen. Doch auch dafür gibt es eine Lösung:
Es darf einfach keine Partition über 2TB Grösse existieren, auch nicht als Software-RAID-Verbund. Aber LVM darf sich darüber hinwegsetzen.
Daher mein Setup:
- Am Anfang der Platten eine kleine Partition von 128MB als RAID-1 für /boot
- Danach drei Partitionen à 666GB, welche jeweils als RAID-10 zusammengefasst werden
- Die drei RAID-10 Partitionen werden mittels LVM zu einem gigantischen logischen Volume zusammengefasst. Alternativ kann man natürlich auch ein RAID-5 nehmen, dann tauscht man 2TB mehr Festplattenplatz gegen massiven CPU-Overhead bei allen Zugriffen ein.
Zuerst mal mit einer Live-CD nach Wahl starten und die Disks vorbereiten. Zu beachten ist, dass so grosse Festplatten gerne mit 4k-Sektoren ausgeliefert werden:
cfdisk -h224 -s56 /dev/sda #erstellen von 4 Partitionen vom Typ FD (RAID autodetect) unter Beachtung der 4k-Sektorengrenze
sfdisk -d /dev/sda | sfdisk --force /dev/sdb #sfdisk mag die 4k-Sektorengrenzen nicht, daher erzwingen wir sie
sfdisk -d /dev/sda | sfdisk --force /dev/sdc
sfdisk -d /dev/sda | sfdisk --force /dev/sdd
mdadm --create --verbose /dev/md0 --level=1 --raid-devices=4 /dev/sd?1
mdadm --create --verbose /dev/md1 --level=10 --raid-devices=4 /dev/sd?5
mdadm --create --verbose /dev/md2 --level=10 --raid-devices=4 /dev/sd?6
mdadm --create --verbose /dev/md3 --level=10 --raid-devices=4 /dev/sd?7
pvcreate /dev/md[123]
vgcreate bigdisk /dev/md[123]
vgchange -a y bigdisk
Danach erstellt man ein paar logische Volumen nach Bedarf, startet die Setup-CD (in meinem Fall natürlich Debian Squeeze) und schon läuft die Sache rund. Partman wird sich zwar trotzdem beschweren, lässt aber die Installation zu. Und Grub installiert sich ganz normal im MBR.
Tuesday, 25. January 2011
Da heute LibreOffice 3.3 in stabiler Version freigegeben wurde, wird es höchste Zeit, das proprietär gewordene OpenOffice.org loszuwerden. Da LibreOffice schon im experimental-Zweig von Debian Einzug gehalten hat, lässt es sich sehr elegant auch unter Squeeze (derzeit noch testing) installieren.
Zuerst muss der experimental-Zweig zu apt hinzugefügt werden:
cat >> /etc/apt/source.list <<EOF
deb http://ftp.ch.debian.org/debian/ experimental main
deb-src http://ftp.ch.debian.org/debian/ experimental main
EOF
cat >> /etc/apt/preferences <<EOF
Package: *
Pin: release a=testing
Pin-Priority: 700
Package: *
Pin: release a=experimental
Pin-Priority: 600
EOF
aptitude update
Anschliessend kann bequem irgendwelche Software aus experimental hinzugefügt werden, indem mittels dem Parameter -t an aptitude/apt-get signalisiert wird, welcher Debian-Zweig verwendet werden soll. Die LibreOffice-Paket haben jedoch noch ein paar unsaubere Abhängigkeiten, so dass derzeit einige davon aus testing verwendet werden müssen.
aptitude install libhsqldb-java
aptitude -t experimental install libreoffice libreoffice-l10n-de libreoffice-gnome ttf-opensymbol
Monday, 24. January 2011
Irgendwie läuft der Ati-Kram noch nicht ganz zufriedenstellend. Immerhin hat es AMD unterdessen fertiggebracht, ihr Treiberpaket mit korrekten md5-Signaturen zu versehen. Ich hab daher auf meinem Debian Squeeze ein Kernel-Update auf 2.6.36.3 vorgenommen (mit dem 2.6.37 kann man den Ati-Murks unmöglich kompilieren) und dann den aktuellen Ati-Treiber versucht zu installieren. Nicht ganz trivial, aber es geht. Ich setze mal voraus, dass ein vollständiges build-environment samt gcc und xorg-dev installiert ist.
Erst ein Kernel-Update:
cd /usr/src
tar -jxf /path/to/linux-2.6.36.3.tar.bz2
cd linux-2.6.26.3
cp /boot/config-2.6.32-5-amd64 .config
make oldconfig
fakeroot make-kpkg --initrd --revision=custom.1.0 kernel_image --jobs=8
dpkg -i ../linux-image-2.6.36.3_custom.1.0_amd64.deb
Mit --jobs=8 wird der nagelneue Quadcore auch endlich mal etwas ausgereizt
Gut, danach reboot und Installation der Ati-Treiber samt der dubiosen Patches von hier:
sh ati-driver-installer-10-12-x86.x86_64.run
cd /
patch -p1 < /path/to/arch-2.6.36.patch
patch -p2 < /path/to/ati-drivers-2.6.36.patch
patch -p1 < /path/to/ati-drivers-fix_compilation-bug-297322.patch
patch -p1 < /path/to/sema_init.patch
cd /lib/modules/fglrx/build_mod
./make.sh
cd ..
./make_install
modprobe fglrx
Dann klappt's auch mit AMD. Die grosse Stolperfalle ist der zweite Patch, welcher anders codierte Pfadangaben drin hat und darum mit -p2 statt -p1 aufgerufen werden will. Der Rest ist ziemlich geradeaus.
Tuesday, 21. September 2010
Neulich bin ich mal gefragt worden, wie ich Backups mache. Die Antwort: Mit einem relativ simplen Cron-Skript und rdiff-backup per SSH auf den Fileserver. Das gibt ein schönes inkrementelles Backup, bei dem man beliebig weit zurückgehen kann, allerdings behalte ich nur die Daten der letzten zwei Monate. Rdiff-Backup braucht relativ wenig Rechenleistung, Bandbreite und Speicherplatz und funktioniert auch hervorragend über's Internet. Wird das Cron-Skript häufig genug aufgerufen, emuliert dieses Backup recht gut das Verhalten von Apples Time-Machine. Nachteilig ist lediglich, dass es in meinem Fall ein vom Clienten initiiertes Backup ist. Solange der zu sichernde Rechner die Daten auf den Backup-Server schreibt, ist ein Backup nicht sicher vor Manipulationen. Besser wäre es, wenn der Server vom Clienten lesen würde. Nur bräuchte der Server dann root-Login auf dem Clienten, was auch nicht unbedingt der Sicherheit förderlich ist...
Folgendes muss man auf dem Server einrichten: - SSH-User für's Backup
- Im $HOME/.ssh/authorized_keys die public-SSH-Keys des root-Users der zu sichernden Systeme eintragen (ja, das Backup-Skript wird in der Regel als root laufen, da man z.B. auch /etc sichern will).
- Im Verzeichnis, welches die Backups enthalten soll, muss für jeden zu sichernden Rechner ein Verzeichnis erstellt werden, das so heisst, wie der Host (zu erfahren durch Eingabe von "hostname" auf dem Client)
- In diesen Verzeichnissen muss jeweils eine Verzeichnisstruktur erstellt werden, welche der $DIRECTORIES-Variable aus untenstehendem Skript entspricht.
- Zuletzt chownt man diese gesamte Struktur an den zuerst erstellen SSH-User.
Und so schaut mein Skript aus: #!/bin/bash
### Settings ###
DIRECTORIES="/etc /home /usr/local/bin"
EXCLUDES="/home/*/.local/share/Trash"
SSHUSER="rdiff-backup"
SSHHOST="192.168.0.1"
REMOTEDIR="/mnt/backup/$(hostname)/"
RDIFF="/usr/bin/rdiff-backup"
RDIFFOPTIONS="ssh -p 2222 %s rdiff-backup --server"
FILEAGE="2M"
NOW=$(date +"%Y-%m-%d")
GZIP="$(which gzip)"
STATUSFILE="/var/tmp/rdiff-backup-status"
LOCKFILE="/var/lock/rdiff-backup-lock"
DUMPDIR="/home/backup"
if [ -e "$LOCKFILE" ]; then
echo "Lockfile exists, quitting..."
exit 255
fi
touch "$LOCKFILE"
### Packages List ###
dpkg --get-selections | $GZIP > $DUMPDIR/dpkg.$NOW.txt.gz
RETVAL=$(($RETVAL + $?))
### File based Backup ###
for DIR in $DIRECTORIES; do
EXCLUDESLIST=""
for EXCLUDE in $EXCLUDES; do
SIZE=$(expr match "$EXCLUDE" "$DIR")
if [ $SIZE -gt 0 ]; then
EXCLUDESLIST="$EXCLUDESLIST --exclude $EXCLUDE"
fi
done
$RDIFF $EXCLUDESLIST --remote-schema "$RDIFFOPTIONS" $DIR $SSHUSER@$SSHHOST::$REMOTEDIR/$DIR
RDIFFRETVAL=$?
RETVAL=$(($RETVAL + $RDIFFRETVAL))
if [ $RDIFFRETVAL = 0 ]; then
$RDIFF --force --remote-schema "$RDIFFOPTIONS" --remove-older-than $FILEAGE $SSHUSER@$SSHHOST::$REMOTEDIR/$DIR
RETVAL=$(($RETVAL + $?))
fi
done
find $DUMPDIR -ctime +7 -exec rm -f '{}' ';'
RETVAL=$(($RETVAL + $?))
echo $RETVAL > "$STATUSFILE"
rm -f "$LOCKFILE"
exit $RETVAL
Was bedeuten nun all die Variablen unter "Settings"? - DIRECTORIES: Die zu sichernden Verzeichnisse.
- EXCLUDES: Nicht zu sichernde Verzeichnisse
- SSHUSER: Mit welchem User wird per SSH am Server angemeldet
- SSHHOST: Die Adresse des Backup-Servers. Entweder eine IP oder ein Hostname.
- REMOTEDIR: Das Basisverzeichnis, worin auf dem Server die Backups gespeichert werden.
- RDIFF: Pfad zum lokal rdiff-backup Binary
- RDIFFOPTIONS: Wenn man zusätzliche Optionen angeben will, z.B. einen alternativen SSH-Port. Kann man auch leer lassen
- FILEAGE: Nach wie vielen Tagen/Monaten/Jahren die Inkremente gelöscht werden sollen
Monday, 18. January 2010
Nachdem ich mir mal wieder einen neuen Hirngrill besorgt hab, wollte ich dessen Daten natürlich bei Gelegenheit wieder auf den PC sichern. Programm der Wahl ist hierfür natürlich opensync. Als Übertragung würde sich zwar Bluetooth anbieten, was in einer theoretisch einfacheren Konfiguration von Opensync enden würde. Jedoch ist mir Bluetooth im Allgemeinen etwas zu fummelig. Daher bin ich ganz froh darüber, dass mein neues Gerät auch über USB synchronisiert werden kann. Das erfordert zwar eine etwas aufwändigere Konfiguration, dafür erhoffe ich mir davon längerfristig einfachere Ausführung des Synchronisationsvorgangs.
Eine ältere aber sehr gute Anleitung für ein anderes, vergleichbares Gerät habe ich ziemlich schnell gefunden. Daher an dieser Stelle nur ein kurzes Update für mein Modell:
Zur Programminstallation gilt eigentlich nur zu sagen, dass Ubuntu in der Geschmacksrichtung "Krüppliger Koala" schon alle Programme in den Standard-Repositories hat, ein einfaches aptitude install multisync0.90 multisync-tools opensync-plugin-syncml opensyncutils opensync-plugin-file
reicht also schon (ggf noch weitere Plugins nach Bedarf hinzufügen).
Danach musste ich auch wieder eine handgefertige udev-Regel für den Zugriff als eingeschränkten Benutzer anlegen. Dies funktioniert analog zur verlinkten Anleitung, lediglich die Device-ID muss angepasst werden. lsusb meldet folgende Daten: Bus 001 Device 006: ID 0421:0223 Nokia Mobile Phones
woraus sich folgende Regel ableiten lässt: BUS=="usb", SYSFS{idVendor}=="0421",SYSFS{idProduct}=="0223",GROUP="plugdev",USER="lukas"
Das neue Upstart-System vom Koala erfordert einen etwas anderen Befehl zum Neustart von udev: sudo service udev restart
anschliessend sollte das Gerät auch neu angestöpselt werden. Das Handy fragt dann auch nach dem Betriebsmodus, für die Synchronisation hab ich immer "PC Suite" angewählt. Damit funktioniert die Synchronisation problemlos, folglich habe ich auch keinen anderen Modus getestet. Der Befehl syncml-obex-client -u sollte nun genauere Geräteinformationen ausgeben. Nun lassen sich im multysync-GUI oder mit den opensync-Kommandozeilentools die Plugins konfigurieren. Diese sind relativ gut dokumentiert, wodurch sich auch die XML-Konfigurationsdateien sehr einfach den eigenen Bedürfnissen anpassen lassen.
Saturday, 14. November 2009
Da mein krüppliger Koala immer noch nach dem Booten etwas gar schweigsam ist und die Entwickler bislang kein Update zur Verfügung gestellt haben, hab ich halt einen Würgaround gebastelt:
Erstelle ein Skript /usr/local/bin/unmute.sh mit Berechtigung +x mit folgenden Inhalt und füge es zum Gnome-Session-Management als Autostart-Programm hinzu
#!/bin/sh
pactl set-sink-mute 1 0
pactl set-sink-volume 1 35000
pactl set-sink-mute 0 0
pactl set-sink-volume 0 35000
Das setzt die Ausgabelautstärke auf beiden Soundkarten auf 53%. Keine Ahnung, wieso 35000 53% entspricht.
Friday, 15. May 2009
In einer der letzten Ausgaben des Linux-Magazins war ein Artikel über Fileserver und iSCSI drin. iSCSI ist ein Protokoll, welches SCSI-Befehle über TCP transportiert. Man kann damit also Massenspeicher übers Netzwerk verwenden. Eine sehr interessante Sache. Leider ist der Linux-Magazin-Artikel ausgesprochen unvollständig und geht nur auf die Clientseite ein. Wie also bau ich meinen eigenen iSCSI-Server?
Das Gentoo-Wiki hilft hier mal wieder mit einer simplen Anleitung aus der Patsche. Nun gilt es nur noch, diese auf Debian/Ubuntu anzupassen. Mein iSCSI-Target (Server) läuft auf Debian Lenny, da braucht's folgende Pakete: aptitude install iscsitarget iscsitarget-modules-$(uname -r)
Danach wird die zu exportierende Festplatte in der Datei /etc/ietd.conf definiert: Target iqn.2009-05.com.example.debianhost:storage.disk1
Lun 0 Path=/dev/hda,Type=fileio
MaxConnections 1
Und anschliessend der Dienst gestartet: sed 's/false/true/' -i /etc/default/iscsitarget
/etc/init.d/iscsitarget start
Auf der Clientseite braucht's nur die Installation des Pakets open-iscsi sowie dessen Anpassung. Die Datei /etc/iscsi/initiatorname.iscsi bekommt folgenden Inhalt: InitiatorName=iqn.2009-05.com.example.debianhost:storage.disk1
Ausserdem wird das zu benutzende Netzwerk-Interface definiert:
ifconfig eth0
iscsiadm -m iface -I iface0 --op=new
iscsiadm -m iface -I iface0 --op=update -n iface.hwaddress -v xx:xx:xx:xx:xx:xx
Danach wird open-iscsi gestartet mittels /etc/init.d/open-iscsi start
Nun kann man nach Targets suchen, sie einbinden, mounten, nutzen, wieder aushängen... wofür man es halt auch immer nutzen will: iscsiadm -m discovery -t st -p 192.168.0.6 -P 1
iscsiadm -m node -T iqn.2009-05.com.example.debianhost:storage.disk1 -l
mount /dev/sdc1 /mnt
umount /mnt
iscsiadm -m node -T iqn.2009-05.com.example.debianhost:storage.disk1 -u
Coole Sache, da muss ich auf jeden Fall noch weiter mit rumspielen Insbesondere, da man damit nicht nur SCSI-Geräte übers Netz transportieren kann, wieder Name vielleicht suggeriert. In der Tat habe ich meinen ersten Gehversuch mit einer ganz normalen IDE-Platte gemacht (erkennbar an der Freigabe des Geräts /dev/hda). Das funktioniert also wirklich mit allen Blockgeräten. Sehr cool
Wofür ich das nun abseits eines Servers brauchen könnte? Nun, z.B. kann ich eine DVD ins Laufwerk meines Desktop-Rechners legen und sie dann über WLAN auf meinem Netbook abspielen (sofern die Bandbreite ausreicht... was noch zu testen wäre).
|
arbeit 
