think eMeidi

Debian ist gut und recht, aber leider ist die ganze Geschichte mit Multimedia-Tools auf Grund von Problemen mit geistigem Eigentum unnötig kompliziert.

Das führt dann auch mal zu einer solchen Flut von Fehlermeldungen, wenn man den mencoder benutzen möchte:

$ mencoder
/usr/bin/mencoder: /usr/lib/i686/cmov/libswscale.so.0: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: /usr/lib/i686/cmov/libpostproc.so.51: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: /usr/lib/i686/cmov/libavutil.so.50: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: /usr/lib/i686/cmov/libavcodec.so.52: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: /usr/lib/i686/cmov/libavformat.so.52: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: relocation error: /usr/bin/mencoder: symbol av_reverse, version LIBAVUTIL_50 not defined in file libavutil.so.50 with link time reference

Das Problem konnte ich schlussendlich lösen, indem ich folgende Zeilen wieder in die /etc/apt/sources.list aufnahm:

...
# mplayer
deb		http://www.debian-multimedia.org squeeze main
deb-src		http://www.debian-multimedia.org squeeze main
...

Anschliessend ein apt-get update && apt-get upgrade. Irgendwann einmal waren dann nur noch zwei Fehlermeldungen zu sehen:

$ mencoder
/usr/bin/mencoder: /usr/lib/i686/cmov/libavcodec.so.52: no version information available (required by /usr/bin/mencoder)
/usr/bin/mencoder: /usr/lib/i686/cmov/libavformat.so.52: no version information available (required by /usr/bin/mencoder)

Doch dieses Problem schien nun unmöglich zu lösen zu sein:

# apt-get install ffmpeg libavcodec52 libavdevice52 libavformat52 libavfilter1
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 ffmpeg : Depends: libavfilter1 (>= 5:0.6.1+svn20101128) but 4:0.6.2-3 is to be installed
 libavfilter1 : Depends: libavcodec52 (< 4:0.6.2-99) but 5:0.6.1+svn20101128-0.2 is to be installed or
                         libavcodec-extra-52 (< 4:0.6.2-99) but it is not installable
                Depends: libavutil50 (< 4:0.6.2-99) but 5:0.6.1+svn20101128-0.2 is to be installed or
                         libavutil-extra-50 (< 4:0.6.2-99) but it is not installable
                Depends: libswscale0 (< 4:0.6.2-99) but 5:0.6.1+svn20101128-0.2 is to be installed or
                         libswscale-extra-0 (< 4:0.6.2-99) but it is not installable
E: Broken packages

Die Lösung:

/etc/apt/preferences:

...
Package: *
Pin: origin www.debian-multimedia.org
Pin-Priority: 600

und dann:

# apt-get install -t unstable ffmpeg

Tags: Debian, Howto
Labels: Linux

Samstag, 4. Juni 2011

Eine portable Festplatte unter Linux mit FAT32 formatieren

Windows ist ja mittlerweile recht bockig, wenn es darum geht, übergrosse portable Festplatten mit FAT32 zu formatieren — stattdessen empfiehlt die Formatierungssoftware aus Redmond, man solle doch bitte das proprietäre NTFS verwenden. Der Haken dabei: Linux und Mac OS X bringen immer noch keine saubere Unterstützung dieses Dateisystems mit sich, wenn es um Schreiboperationen geht (im Klartext: auf eigenes Risiko!).

Unter Linux ist es ein Kinderspiel, auch neueste Festplatten mit riesigen Volumina mit FAT32 zu formatieren.

Nachdem man herausgefunden hat, unter welchem Devicenamen à la /dev/sdX die USB-Festplatte ansprechbar ist, erstellt man erstmals eine Partition:

# fdisk /dev/sdd
Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-9729, default 1): <enter>
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-9729, default 9729): <enter>
Using default value 9729
Command (m for help): t
Selected partition 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (W95 FAT32 (LBA))
Command (m for help): w

Mit dieser Befehlsabfolge hat man nun eine primäre Partition mit dem Dateisystem FAT32 angelegt.

Die Festplatte muss nun aber auch noch formatiert werden, damit Daten darauf geschrieben werden können. Das ist noch viel einfacher als die Partitionierung:

# mkfs -t vfat /dev/sdd1

Tags: Debian, Howto, Uncategorized
Labels: Linux

Samstag, 4. Juni 2011

Debian meldet „error in version: version number does not start with digit“

Der täglich ausgeführte Cron-Job /etc/cron.daily/man-db meldete seit dem Upgrade auf die neueste Debian-Version folgende Probleme:

dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 22552 package 'am-utils':
 'Replaces' field, reference to 'amd': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 22555 package 'am-utils':
 'Conflicts' field, reference to 'amd': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 52773 package 'root-tail':
 'Conflicts' field, reference to 'rt': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 65726 package 'wmnetselect':
 'Suggests' field, reference to 'mozilla': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 69143 package 'e3':
 error in Version string 'e3-2.30-1': version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 75804 package 'tac-plus':
 error in Version string 'F4.0.4.alpha-9.1': version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 125732 package 'epic4-script-thirdeye':
 'Depends' field, reference to 'epic4': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 149557 package 'cnews':
 error in Version string 'cr.g7-31': version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 152423 package 'kernel-image-2.4.25':
 error in Version string 'mad.8': version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 168065 package 'mkcdrec':
 error in Version string 'v0.8.0-2': version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 189590 package 'request-tracker1':
 'Conflicts' field, reference to 'rt': error in version: version number does not start with digit
dpkg-query: warning: parsing file '/var/lib/dpkg/available' near line 201432 package 'epic4':
 'Conflicts' field, reference to 'epic4-help': error in version: version number does not start with digit

Nachdem ich mir die Datei /var/lib/dpkg/available angeschaut hatte, kam ich zum Schluss, dass ich lieber die Finger von dieser Auflistung lasse (ich überlegte mir kurz, die Versionsangaben der betreffenden Pakete manuell anzupassen).

Die Überprüfung auf das Vorhandensein all dieser Pakete förderte nichts zu Tage:

$ dpkg --list | grep am-utils
$ dpkg --list | grep root-tail
$ dpkg --list | grep wmnet
$

Komisch! Stattdessen fand ich nach ein wenig Googlen das Patentrezept gegen solche Probleme:

# dpkg --clear-avail
# apt-get update

Tags: Debian
Labels: Linux

Mittwoch, 18. Mai 2011

LDAP-Authentifizierung unter Apache funktioniert nach dem Upgrade auf Debian Squeeze nicht mehr

Heute entschloss ich mich, einen unserer produktiven Web-Server von Debian Lenny nach Squeeze zu migrieren, das seit März 2011 stabile Release 6 der Debian GNU/Linux-Distribution. Wie erwartet klappte beim Upgrade vorerst nicht alles wie am Schnürchen — doch schlussendlich obsiegte meine Wagemutigkeit.

Symptom

Eines der grössten Probleme war, dass die unter Apache 2.2.16 gegen LDAP authentifizieren beschriebene Authentifizierung gegen einen LDAP-Server nicht mehr funktionierte. Der Web-Browser zeigte bei jedem Login-Versuch die Meldung „500 — Internal Server Error“ an, ohne dass im Apache error.log irgendwelche Meldungen aufgeführt wurden.

Apache die exakte Fehlermeldung entlocken

Als erstes hiess es deshalb, in /etc/apache2/apache2.conf den LogLevel heraufzusetzen:

...
#LogLevel warn
LogLevel debug
...

Nach einem erneuten Login-Versuch fanden sich nun erleuchtende Einträge im Apache error.log:

...
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(982): [24124] auth_ldap url parse: `ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)', Host: ldap.domain.tld, Port: 636, DN: o=company,c=ch, attrib: uid, scope: subtree, filter: (gidNumber=1160), connection mode: using SSL
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [debug] mod_authnz_ldap.c(379): [client 192.168.1.2] [24124] auth_ldap authenticate: using URL ldaps://ldap.domain.tld/o=company,c=ch?uid?sub?(gidNumber=1160)
[Wed May 18 16:11:17 2011] [info] [client 192.168.1.2] [24124] auth_ldap authenticate: user maeby authentication failed; URI /admin [LDAP: ldap_simple_bind_s() failed][Can't contact LDAP server]
...

Das Kernproblem

Eine Google-Suche führte mich auf die richtige Spur:

To reenable my running lenny configuration in squeeze I had to add
LDAPTrustedGlobalCert.

Quelle: Bug#620398: Apache LDAP/S Authentication Causes

Offenbar fehlte dem Server nach dem Upgrade also ein GlobalCert, welches die Kommunikation mit dem LDAP-Server verschlüsselt. Wie konnte ich mir dieses beschaffen?

Wer bürgt für die Verschlüsselung?

Zuerst hiess es nun also, herauszufinden, mit welchem Zertifikat der IT-Dienstleister die Kommunikation verschlüsselte. Hierzu behalf ich mir mit folgendem Befehl:

$ openssl s_client -connect ldap.domain.tld:636 -showcerts
depth=2 /C=BM/O=QuoVadis Limited/CN=QuoVadis Root CA 2
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=CH/ST=Bern/L=Bern/O=Company/OU=Department - Security/CN=ldap.domain.tld
  i:/C=BM/O=QuoVadis Limited/OU=www.quovadisglobal.com/CN=QuoVadis Global SSL ICA
-----BEGIN CERTIFICATE-----
MIIFFjCCA/6gAwIBAgICKIcwDQYJKoZIhvcNAQEFBQAwazELMAkGA1UEBhMCQk0x
GTAXBgNVBAoTEFF1b1ZhZGlzIExpbWl0ZWQxHzAdBgNVBAsTFnd3dy5xdW92YWRp
...

Der Zertifikatsherausgeber war also QuoVadis, dessen QuoVadis Global SSL ICA von unserer IT-Abteilung zur Signierung der eigenen Verschlüsselungszertifikate verwendet wurde.

Gebt mir das Rootzertifikat!

Mit dieser Information bewaffnet konnte ich nun auf die Suche nach dem öffentlichen Zertifikat gehen. Jeder Zertifikatsanbieter bietet auf seiner Web-Site nämlich die firmeneigenen GlobalCerts zum Download an, so auch QuoVadis. Unter QuoVadis Root Download fand sich eine Liste, in welcher ich mich — aus offensichtlichen Gründen — für das QuoVadis Global SSL ICA entschied.

Installation des Zertifikats auf dem Server

Dieses Zertifikat kopierte ich von der Web-Site und fügte es auf dem Server in die Datei /etc/ldap/certs/qv_root.pem ein (Gratistipp: vim ist mit :set paste auf die Kopieraktion vorzubereiten).

Anschliessend musste ich noch /etc/apache2/mods-enabled/ldap.conf mit folgender Zeile ergänzen:

...
LDAPTrustedGlobalCert CA_BASE64 /etc/ldap/cacerts/qv_root.pem
...

Nach einem Neustart von Apache (/etc/init.d/apache2 restart) klappte der Login schlussendlich wieder.

Tags: Apache, Authentifizierung, Debian, LDAP
Labels: Linux

Mittwoch, 23. Februar 2011

Ruby on Rails 3 unter Debian GNU/Linux installieren

Aus gegebenem Anlass habe ich mich heute Morgen das erste Mal seit langem wieder mit dem Web-Framework Ruby on Rails aus der Küche von David Heinemeier Hansson (einer der Partner hinter 37signals) auseinandergesetzt.

Nachfolgend habe ich zusammengefasst, wie ich das Framework auf meinem heimischen Entwicklungsserver zum Laufen gekriegt habe.

Installation Ruby

(Ich folge der englischen Anleitung Debian Lenny – Ruby on Rails von SliceHost)

Zuerst lädt man Debian-Pakete herunter und installiert diese:

# apt-get install ruby-dev ruby ri rdoc irb libreadline-ruby libruby libopenssl-ruby sqlite3 libsqlite3-ruby libsqlite-dev libsqlite3-dev

Anschliessend lädt man die Quellen von RubyGems herunter und kompiliert diese (man sollte auf das vorkompilierte Debian-Paket verzichten weil es mit Version 1.2.0 unglaublich veraltet ist):

# cd /tmp
# wget "http://rubyforge.org/frs/download.php/74234/rubygems-1.5.2.tgz"
# tar xvzfz rubygems-1.5.2.tgz
# cd rubygems-1.5.2
# ruby setup.rb

Nun noch die obligatorischen Update-Anweisungen, die man sich als Linux-Benutzer von vielen Paketmanagern kennt, und dann ist man bereit:

# gem update

Bei mir erhielt ich bei der Ausführung von gem update folgende Fehlermeldung zu Gesicht:

# gem -v
/usr/bin/gem:10: undefined method `manage_gems' for Gem:Module (NoMethodError)

Der Anleitung unter RubyGems: undefined method ‘manage_gems’ for Gem:Module (NoMethodError) – easy fix folgend wurde ein veraltetes Binary installiert, welches zuerst mit einer aktuellen Version ersetzt werden muss:

# mv /usr/bin/gem /usr/bin/gem-backup
# ln -s /usr/bin/gem1.8 /usr/bin/gem

Anschliessend aktualisiert man das System (nun hoffentlich erfolgreich):

# gem update
# gem update --system

Notabene: Bei mir wurden keine Updates nachgeladen, alles war bereits auf dem neuesten Stand …

Installation sqlite3

Damit Ruby mit der Datenbank sqlite3 sprechen kann, muss ein entsprechender Treiber bereitgestellt werden. Falls bei

# gem install sqlite3

die Fehlermeldung

Fetching: sqlite3-1.3.3.gem (100%)
Building native extensions.  This could take a while...
ERROR:  Error installing sqlite3:
	ERROR: Failed to build gem native extension.

        /usr/bin/ruby1.8 extconf.rb
extconf.rb:3:in `require': no such file to load -- mkmf (LoadError)
	from extconf.rb:3


Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/sqlite3-1.3.3 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/sqlite3-1.3.3/ext/sqlite3/gem_make.out

erscheint, hat man im obigen apt-get für die Grundinstallation vergessen, die Header-Pakete von Ruby zu installieren (via Stackoverflow). Dies holt man mit folgendem Befehl nach:

# apt-get install ruby-dev libsqlite3-dev

Installation MySQL-Treiber

Obwohl man Ruby (on Rails) natürlich auch mit sqlite3 benutzen könnte, ist der LAMP-Web-Entwickler primär mit MySQL vertraut — so kann diese Datenbank mit der ansprechenden GUI phpMyAdmin administriert werden und ist bei grösseren Datenmengen auch klar performanter als sqlite3.

Um den Treiber zu installieren, bemächtigt man sich folgender Debian-Pakete:

# apt-get install libmysql-ruby libmysqlclient-dev

Anschliessend ist

# gem install mysql

Problemlos möglich.

Installation Rails

Mit dem Ruby-Paketmanager gem kann man sich nun endlich Rails aus dem Netz herunterladen und installieren lassen:

# gem install rails

Fertig! Jetzt sollte man eine funktionierende Ruby on Rails-Installation auf dem Server liegen haben und man ist bereit, mit Bordmitteln das erste Projekt anzulegen. Wie dies genau vor sich geht, folgt in einem weiteren Artikel.

Tags: Debian, Howto, RoR, Ruby, Ruby on Rails, Web-Entwicklung
Labels: Linux, Web

Sonntag, 26. Dezember 2010

Netgear ReadyNAS Duo mit eigener FTP-Backuproutine sichern

Die Gründe hinter einem solchen Vorhaben können vielfältig sein — aber wer will es einem Linux-Hacker verübeln, wenn er sich des in einem ReadyNAS Duo werkelnde (aber völlig veraltete) Debian GNU/Linux‘ bemächtigen will?

Pakete nachinstallieren

Von der ReadyNAS-Web-Site lädt man sich zwei Binärpakete herunter, die mit der Installation über die Web-Oberfläche des Gerätes a) den Root-Zugang und b) apt-get nachrüsten:

Tipps

Falls die Download-Links nicht mehr funktionieren, schaut man am Besten unter Add-ons for RAIDiator 4.1.3+ nach. Klappt dieser Link auch nicht, hangelt man sich über die Web-Site via
Support > Downloads > ReadyNAS Add-Ons > Add-ons for RAIDiator 4.1.3+
durch.
Das Root-Passwort entspricht dem Administrator-Passwort, welches man zum Login auf der Web-Oberfläche verwendet.

lftp nachrüsten

Für das Backup der lokal auf dem NAS gespeicherten Daten auf einen entfernten FTP-Server habe ich mich für das Tool lftp entschieden:

# apt-get install lftp

Backup-Script einrichten

Damit man die Datensicherung automatisieren kann, sollte man unter /usr/local/bin/backup-emeidi.sh folgendes Script ablegen und gemäss seinen eigenem Gutdünken anpassen:

#!/bin/bash    

HOST="www.host.tld"
USER="user"
PASS="pass"
LCD="/c/"
RCD="/"

echo "---------------------------------------------------------------------"
echo "Backing up $LCD to $HOST/backup$RCD with user $USER"
echo "---------------------------------------------------------------------"
echo `date`
echo "---------------------------------------------------------------------"

lftp -c "
open ftp://$USER:$PASS@$HOST; 
lcd $LCD;
cd $RCD;
mirror --reverse \
       --verbose \
       --no-perms \
       --no-umask \
       --ignore-time"

echo "---------------------------------------------------------------------"
echo "Backup finished."
echo "---------------------------------------------------------------------"
echo `date`
echo "---------------------------------------------------------------------"
echo ""

exit 0

Die Variable LCD speichert das lokale Verzeichnis, die Variable RCD das entfernte (auf dem FTP-Server liegende) Verzeichnis.

Am Ende macht man das Script mittels folgendem Befehl ausführbar:

# chmod 755 /usr/local/bin/backup-emeidi.sh

Cron-Job einrichten

Damit das Script nun täglich einmal mitten in der Nacht ausgeführt wird, erstellt man sich unter /etc/cron.d/backup-emeidi einen entsprechenden Cron-Job:

...
0 1     * * *   root    /usr/local/bin/backup-emeidi.sh | mail -s "Backup ReadyNAS" -c syslog@server.tld syslog@customer.tld
...

Dieser Cron-Job wird täglich um 1 Uhr morgens gestartet und mailt das Ergebnis an syslog@customer.tld wie auch an syslog@server.tld. So kann der Sysadmin, wie auch der Kunde, täglich die Ergebnisse des Backuplaufes überprüfen.

Problem

Bei meinem Kunden werden lustigerweise gewisse Dateien in jeder Nacht gebackupt, obwohl diese nachweislich nicht verändert wurden. Ich vermute hier einen Bug in lftp.

Tags: Backup, Debian, FTP, Hack, Hacking, Netgear
Labels: Linux

Montag, 6. Dezember 2010

Debian Etch auf Lenny aktualisieren

Heute hatte ich es mit einer längst vergessen geglaubten Virtuellen Maschine zu tun, auf welcher noch ein Debian GNU/Linux mit einem 2.4er-Kernel installiert war. Im Grunde ging es nur darum, die aktuellsten VMware-Tools auf dieser Kiste zu installieren — doch wie immer zog dies umgehend einen riesigen Rattenschwanz an Debugging und sonstigen Upgrade-Arbeiten mit sich.

Nach etlichem Pröbeln und apt-get-Endlosschleifen hier die Kurzzusammenfassung, wie man Etch auf Lenny bringt:

sources.list

Zuerst einmal muss man Etch auf den letzten verfügbaren Stand aktualisieren. Da die Etch-Pakete von den Mirrors verschwunden sind, muss man alle vorhandenen Zeilen in der Datei /etc/apt/sources.list auskommentieren und folgende Zeilen einfügen:

deb http://archive.debian.org/debian-archive/debian/ etch main
deb-src http://archive.debian.org/debian-archive/debian/ etch main

Quelle: Debian (etch): sources.list

GPG

Natürlich funktioniert das apt-get update auf meiner Installation nicht sauber, weil mir einige PGP-Schlüssel fehlen. Da deren Fingerprint angegeben wird, kann ich diese ganz simpel mit folgendem Befehl mit meinem System bekannt machen:

# gpg --keyserver pgpkeys.mit.edu --recv-key  010908312D230C5F 
# gpg -a --export 010908312D230C5F | apt-key add -

Quelle: [Debian] Apt-get : NO_PUBKEY / GPG error

apt-get upgrade && dist-upgrade

Jetzt folgt das obligate

# apt-get update
# apt-get install apt aptitude
# apt-get upgrade
# apt-get dist-upgrade

um die neuesten Pakete zu installieren. Das System ist nun bereit, um auf einen neuen Kernel gehoben zu werden:

# apt-get install linux-image-2.6.18-6-686

Ist der Kernel installiert und GRUB angepasst (geschieht automatisch), sollte man den Server einmal neu starten (reboot).

sources.list

Frisch zurück im System mit Kernel 2.6, werden die oben hinzugefügten Zeilen nun wieder auskommentiert. Stattdessen fügt man nun folgende Repositories in /etc/apt/sources.list ein:

deb http://mirror.switch.ch/ftp/mirror/debian lenny main
deb-src http://mirror.switch.ch/ftp/mirror/debian lenny main

deb http://security.debian.org/ lenny/updates main

Quelle: Upgrading Debian Etch to Lenny stuck on kernel/libc issue

aptitude

ACHTUNG: Anstelle dieses kritische Kernel-Upgrade nun mit apt-get zu machen, hält man sich lieber an die Anweisungen der Debian-Maintainer und verwendet aptitude. Dieses kann viel besser mit Abhängigkeiten umgehen (Stichwort: libc6, dpkg (mit Breaks) etc.)

# aptitude update
# aptitude upgrade
# aptitude dist-upgrade

Quelle: Howto Upgrade Debian 4 Etch to Debian 5.0 Lenny

Dies bringt alle Pakete auf den neuesten Stand, die für das nun definitive dist-upgrade zwingend sind.

Kernel-Sourcen

Da die Kernel-Sourcen für Kernel 2.6.18 irgendwie nicht verfügbar sind, aktualisiert man kurzerhand auf Kernel 2.6.26:

# apt-get install linux-image-2.6.26-686
# reboot

Damit die VMware-Tools korrekt installiert werden können, lädt man sich nun auch noch die korrespondieren Quellen herunter:

# apt-get install linux-headers-`uname -r`

VMware-Tools

Anschliessend spielt man die VMware-Tools in gewohnter Manier ein. Fertig!

Tags: Debian
Labels: IT, Linux

Dienstag, 30. November 2010

Debian-Installation hängt mit 1% bei „Select and Install Software“

Heute konnte ich auf der Arbeit wieder einmal einen ausgemusterten PC mit Debian GNU/Linux versehen und zu einem Server (cups mit Samba inkl. Windows-Druckertreiber) umwandeln. Obwohl heuer, 2010, die Installation eines Linux-Betriebssystems kaum mehr grosse Mühe bereitet, fanden sich auch dieses Mal wieder Stolpersteine.

Konkret: Die Installation hing beim Aktualisieren der Pakete über den Internet-Mirror von SWITCH. Der Fortschrittsbalken im Dialog „Select and Install Software“ blieb bei 1% stecken und bewegte sich auch nach mehreren Minuten warten nicht weiter.

Nach etwas Googeln fand ich als erstes heraus, dass man mit Druck auf die Tasten Ctrl-Alt-F4 in die textbasierte Log-Ansicht der Installationsroutine schalten konnte. Dort stand etwas in der Form:

...
Nov 30 15:04:00 in-target:  To continue, enter "Yes"; to abort, enter "No"

Die Installation hing also, weil die Entwickler der Routine nicht vorhergesehen hatten, solche Eingabeaufforderungen automatisch mit „yes“ zu beantworten.

Als nächstes startete ich deshalb den Rechner neu, spielte die Installation durch, vermied es aber tunlichst, die Netzwerkkarte zu konfigurieren. So wurde die Internet-Aktualisierung zwar übersprungen und der Rechner bootete nach der Installation brav in die Shell — doch ich war danach aber schlichtweg nicht in der Lage, das Netzwerk zu laden (wahrscheinlich hätte ich das entsprechende Treibermodul laden müssen). Es trennt mich somit noch ein weiter Weg bis zum bombensicheren Linux-Admin.

Also hiess es ein weiteres Mal zurück zum Start. Dieses Mal initialisierte ich die Netzwerkkarte wieder von Beginn weg mit den benötigten Informationen. Als der Balken aber erneut hing, wechselte ich mittels Ctrl-Alt-F2 in ein interaktives Shell. Dort versuchte ich mich der brachialen Methode:

# ps ax | grep aptitude
 5760 ?        Ss     0:00 aptitude ...
# kill 5760

Der blockierte Prozess wurde so nullkommaplötzlich abgetötet. Mittels Ctrl-Alt-F1 ging es zurück in den Installationsbildschirm, wo mir eine rotgefärbte Fehlermeldung entgegenleuchtete und mir mitteilte, dass der wichtige Prozess verschwunden war.

Ich folgte den Anweisungen auf dem Bildschirm, drückte „Continue“, um die Installation trotz des Fehlers fortzusetzen und wählte aus der nun angebotenen Liste aus, dass nun der Bootloader grub in den MBR der Festplatte geschrieben werden sollte.

Die Installation lief durch, der Rechner startete neu — und sobald ich mich eingeloggt hatte, führte ich folgenden Befehl aus:

# apt-get update
...
# apt-get dist-upgrade

So hievte ich mein Debian GNU/Linux 5.0.6 auf 5.0.7 — und der Tag war gerettet.

Tags: Debian, IT-Support
Labels: Linux

Donnerstag, 2. Juli 2009

lprng debuggen

Gerade habe ich eine Stunde mit debuggen von LPRng verbracht, bis ich schlussendlich feststellen musste, dass das angebliche Druckerproblem mit einem Kaltstart des Druckers (!) gelöst werden konnte.

Dennoch ist es für die Nachwelt sicherlich von Interesse, wie man LPRng im speziellen und Druckerprobleme unter Linux im allgemeinen debuggt.

lprng ausschalten

Damit man ungestörten Zugriff auf den Parallelport hat, schaltet man kurzerhand den von Debian automatisch geladenen Druckserver aus:

# /etc/init.d/lprng stop

Module überprüfen

Anschliessend überprüfen wir grundlegend, ob die Parallelporttreiber geladen wurden:

$ lsmod | grep lp
lp                     11076  0 
parport                34280  2 lp,parport_pc

Berechtigungen des Parallelports

$ ls -l /dev/lp0
crw-rw---- 1 root lp 6, 0 2009-07-02 13:07 /dev/lp0

Sieht gut aus. Falls der Port nicht existiert, legt man in anhand einer anderen auf diesem Blog publizierten Anleitung an.

Auf Parallelport drucken

# cat sample.ps > /dev/lp0

ACHTUNG: Drucker, die kein Postscript sprechen (würde ich nie mehr in meinem Leben anschaffen!), werden seitenweise kryptische Codes ausdrucken. Eine Beispieldatei im Postscript-Format findet sich unter samplec.ps

In meinem Fall beendete sich dieser Befehl auch nach 20 Sekunden nicht, weshalb ich ihn mit Ctrl+C von Hand abbrechen musste (ansonsten hat man nach 1-2 Sekunden wieder freie Hand, sofern die Postscript-Datei nicht gerade 50 MB gross ist …). Hier ging mir plötzlich ein Lichtlein auf, dass das Problem wohl nicht am Druckserver selber zu suchen war, sondern irgendwo an oder zwischen dem Drucker und dem Server lag.

lprng debuggen

Wenn bis hierhin alles geklappt hat, muss das Problem wirklich an lprng liegen. Deshalb starten wir den Druckserver im Debug-Modus:

# lpd -F -D1 >&/tmp/lprng.debug &

Ich habe Werte für D von 1, 2 und 9 ausprobiert, hat alles geklappt. In /tmp/lprng.debug werden alle Statusmeldungen akribisch aufgelistet. Anhand dieser ist es im Zusammenspiel mit Google möglich, andere Leidensgenossen zu finden und eventuell sogar die Lösung des Problems präsentiert zu erhalten.

Tags: Debian, Debug, Druck
Labels: IT, Linux