After some research it turned out, that it is easily possible to convert WAV to ULAW in directly using SOX. The following command works like charm:

find . -name \*.wav -exec sox -V {} -r 8000 -c 1 -t ul -w {}.ulaw \;

In order to see what exactly is going on when vchanger tries to load a volume, I ran:


strace -f vchanger /etc/bacula/vchanger.conf -u bacula -g disk load 8 usbchanger1 0


You’ll never guess what the problem was! I forgot to set the number of reserved blocks to zero when preparing the file system of the disks, so from a normal users perspective the disk was just out of space.

Here you can see the important lines of the strace call:
open("/mnt/vchanger/donnerstag/loaded0", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77c2000
write(5, "usbchanger1_0004_0008\n"..., 22) = -1 ENOSPC (No space left on device)
close(5) = 0

A tune2fs -m 0 /dev/sdc1 solved the problem, but why isn’t vchanger’s first load failing with an error message that tells me that it was not possible to update the loaded0 file? I think I am going to write a patch for this now.

UPDATE: Here is my patch to correctly interrupt loading and write useful log information: diskmanager.patch

main: TLS init def ctx failed: -69

in your syslog, just remove the f**k**g passphrase from the key.

Maybe the error message is to obvious, because I found nothing helpful in the web. BTW: Confucius says: Building LDAP server on ONE day, will prevent you from getting headache, mkay!

Soweit alles wie immer. Aber dann weigerte GRUB sich installieren zu lassen. Egal was man versuchte, es endete immer in der Meldung “bad file or directory type”. Leider fand sich dazu rein gar Nichts, was auf die Ursache des Problems hingewiesen hätte.

Ich erinnerte mich dann daran, dass ich irgendwann mal das Problem hatte, dass sich die Standard-Inode-Size zwischenzeitlich mal von 128 auf 256 geändert hat, was auch dazu geführt hatte, das man GRUB zwar installieren konnte aber ein Start nicht möglich war.

Also machte ich mich auf die Suche nach einem ähnlichen Unterschied und wurde bei mdadm fündig.

Erst als ich das Software RAID mit

mdadm create /dev/md0 -e 0.90 --raid-devices=2 --level=1 /dev/sda1 /dev/sdb1

,also zwingend mit dem alten Format der Metadaten, erstellt habe, konnte man GRUB auch erfolgreich installieren.

[..] and it’s fun to say. Shelldap! Shelldap! Shelldap!

Webseite von Shelldap: http://projects.martini.nu/shelldap

1. Sichere Anmeldung am System mittels Kerberos
2. Benutzer und Gruppeninformationen sollen aus dem zentralen LDAP-Verzeichnis kommen
3. LDAP-Benutzer sollen automatisch Mitglieder lokaler Systemgruppen werden, um z.B. Zugriff auf Geräte zu habe
4. Nicht existierende Home-Directories sollen beim ersten Anmelden erstellt werden
5. Mobile Geräte müssen auch ohne Netzwerkverbindung eine Authentifizierung ermöglichen

Auf Serverseite habe ich ebenfalls ein Ubuntu 10.04 LTS laufen (mein Mediacenter System). Dort habe ich bereits Kerberos und LDAP nach der Anleitung aus dem Ubuntu Serverguide eingerichtet.

Die anderen Anleitungen des Serverguides sind leider nun dann hilfreich, wenn man nur Kerberos oder nur LDAP-Authentifizierung machen möchte. Abgesehen davon schießen sich die Tools pam-auth-update und auth-client-config gegenseitig in’s Knie, weshalb man schon genau wissen sollte was man tut. Andernfalls hat man sich schneller aus dem eigenen System ausgesperrt als man Kerberos rückwärts buchstabieren kann. Ich verwende daher ein eigenes auth-client-config Profil für die Anpassungen an der nsswitch.conf und alle Änderungen an PAM nehme ich mittels pam-auth-update vor.

Fangen wir also mit der Installation der benötigten Pakete an. Als Basis dient eine ganz gewöhnliche Ubuntu 10.04 Desktop Installation.

sudo aptitude install libpam-krb5 libpam-ldap libpam-ccreds krb5-user nscd nss-updatedb

Während der Installation wird die Kerberos Realm und die LDAP-Verbindungsparameter von debconf abgefragt.
Auch wenn wir eigentlich libpam-ldap gar nicht benötigen installiert sich das als Abhängigkeit ohnehin mit. libpam-ccreds sorgt dafür, dass wir bei Nicht-Erreichen des Kerberos Server dennoch eine Anmeldung durchführen können, sofern der entsprechende Benutzer schon einmal angemeldet war.

Nun optimieren wir noch ein wenig die Standardwerte für LDAP-Timeout und das Verhalten, wenn der Server nicht erreicht werden kann. Dazu habe ich folgende Werte in der /etc/ldap.conf auskommentiert und angepasst:

ldap_version 3
timelimit 5
bind_timelimit 5
bind_policy soft


Damit das System nicht versucht numerische UID < 1000 (in der Regel lokale Systembenutzer) per LDAP aufzulösen muss einmal nssldap-update-ignoreusers ausgeführt werden.

Um nun dem System beizubringen, bei der Suche nach Benutzer- oder Gruppeninformationen zunächst die Dateien /etc/passwd bzw. /etc/groups zu befragen, dann das LDAP-Verzeichnis und bei Nicht-Erreichbarkeit die zwischengespeicherte NSS Datenbank zu nehmen, muss ein entsprechendes auth-client-config-Profil erstellt werden. Wir nehmen als Namen dafür einfach den DNS Namen der Domäne.

# /etc/auth-client-config/profile.d/example.com
[example.com]
nss_passwd=passwd: files ldap [NOTFOUND=return] db
nss_group=group: files ldap [NOTFOUND=return] db
nss_shadow=shadow: files
nss_netgroup=netgroup: nis


und aktivieren das Ganze mit:

auth-client-config -t nss -p example.com

Haben wir bei der Konfiguration der LDAP-Einstellungen alles richtig gemacht, sollte es nun möglich sein, mit getent passwd und getent groups die zusammengesetzte Liste aus Lokalen- und LDAP-Benutzern bzw. Gruppen zu erhalten. Damit diese Informationen auch offline Verfügbar sind, führt man nss_updatedb wie folgt aus:

sudo nss_updatedb ldap

Nun kann der richtige Spaß beginnen: Die PAM Authentifizierung. Dazu müssen einige Dateien unter /usr/share/pam-configs/ angelegt werden. Teils ist es nicht ganz Nachvollziehbar, warum diese nicht schon vorhanden sind, da es die Benutzung auf dem System vorhandener PAM-Module doch deutlich erschwert. Auf der einen Seite mag pam-auth-config es nicht eigene Änderungen an den /etc/pam.d/common-* Dateien zu machen, auf der anderen Seite fehlen Konfigurationsdateien um relativ gebräuchliche PAM-Module über pam-auth-config zu aktivieren. Schein derzeit Alles ein bisschen in Bewegung zu sein.

Zum Erstellen nicht existenter Home-Directories benötigen wir eine Konfiguration für das PAM-Modul mkhomedir. Die sieht wie folgt aus:

# /usr/share/pam-configs/mkhomedir
Name: Create missing home directory on login
Default: yes
Priority: 0
Session-Type: Additional
Session-Final:
required pam_mkhomedir.so skel=/etc/skel umask=0077 silent


Um Nicht-Lokale Benutzer nach der Anmeldung für die Dauer der Sitzung Mitglied in lokalen Gruppen werden zu lassen benötigen wir das PAM-Modul group. Die Mitgliedschaften werden über die Datei /etc/security/group.conf verwaltet. Die entpsrechende Konfiguration zu Benutzung mit pam-auth-config findet sich im Folgenden:


# /usr/share/pam-configs/group
Name: Default group memberships
Default: yes
Priority: 0
Auth-Type: Additional
Auth:
optional pam_group.so


So, kommen wir nun zum Sahnehäubchen der Konfiguration: Die Offline-Anmeldung ermöglichen. Die Konfiguration für libpam-ccreds ist dabei auf zwei Dateien aufzuteilen. Eine konfiguriert das Prüfen der Anmeldedaten und ggf. das Aktualisieren der Zwischengespeicherten Informationen, die Andere das Speichern der Passwörter. Die Dateien sehen wie folgt aus und stammen aus einem aktuelleren libpam-ccreds Debianpaket (Debian Squeeze oder Ubuntu Maverick) bei dem sich dem Fehlen der entsprechenden Dateien bereits angenommen wurde.


# /usr/share/pam-configs/ccreds-check
Name: Ccreds credential caching - password checking
Default: yes
Priority: 0
Auth-Type: Primary
Auth:
[success=end default=ignore] pam_ccreds.so minimum_uid=1000 action=validate use_first_pass
[default=ignore] pam_ccreds.so minimum_uid=1000 action=update



# /usr/share/pam-configs/ccreds-save
Name: Ccreds credential caching - password saving
Default: yes
Priority: 512
Auth-Type: Additional
Auth:
optional pam_ccreds.so minimum_uid=1000 action=store


Nun kommt der grosse Moment wo das Ganze im System aktiviert wird. Wir führen den Befehl

sudo pam-auth-update

aus und wählen alle Profile ausser LDAP aus. Das soll es gewesen sein. Alle Anforderungen sind mit der Konfiguration erfüllt.

Der Ort für das Social Event am Samstag Abend im Foyer des Rheinischen Industrie Museum Oberhausen hätte wohl kaum stimmungsvoller sein können. Ich habe leider keine eigenen Bilder gemacht, hoffe aber in den kommenden Tagen an dieser Stelle ein paar Links auf andere Blogs setzen zu können, die Bilder vom Event zeigen.

Update: Bilder gibt es nun hier