AOL – Nein Danke!!!

Ich dachte ich wäre die AOL-CDs schon vor langer Zeit losgeworden. Leider habe ich mich diesbezüglich wohl getäuscht. Waren die Jahre ohne AOL-CDs etwa nur die berühmte Ruhe vor dem Sturm?

Egal, das geht am Montag sofort unfrei zurück an:

AOL Deutschland GmbH & Co. KG
Millerntorplatz 1
20359 Hamburg

Samba und ACLs

Eigentlich sind ACLs mit Samba kein grosses Problem. Es gibt auch genug Howtos und Anleitungen im Netz und ebensoviele Hinweise in diversen Mailinglisten und Newsgroups. Nur leider deckt nicht eine einzige dieser Anleitungen meine Umgebung ab:

– Samba Server als Fileserver integriert in eine Windows 2003 Domäne, also nicht als Domänen Controller.
– Unix Benutzer und Gruppen (Uid und Gid) kommen über nss-ldap von einem zentralen LDAP-Server.

Alles was ich im Netz gefunden habe, setzte entweder voraus, dass der Samba Server gleichzeitig auch als Domänen Controller arbeitet, oder dass keine zentrale Vergabe von Uids und Gids über LDAP (oder NIS) vorhanden ist, sondern diese dynamisch mittels des winbindd aus den SIDs der Windows Domäne erzeugt werden.

Nach sehr viel Trial and Error kam dann zum Schluss folgende funktionierende Konfiguration heraus:

[global]
 ...
 winbind trusted domains only = yes
 winbind use default domain = yes
 idmap uid = 50000-60000
 idmap gid = 50000-60000
 ...

Die Option winbind use default domain bewirkt, dass Samba den Domänenteil bei der Suche nach dem zur SID passenden Benutzer weglässt. So wird schonmal aus DOMAIN\BENUTZER ein einfaches BENUTZER.

Dies reicht aber noch nicht aus. Als nächstes bewirken die beiden idmap-Einträge, dass die Pseudo-Uids des winbindd auf einen eigentlich nicht existierenden Uid und Gid Bereich gemappt werden, da es ansonsten mit den zentral vergebenen Uids und Gids kollidiert.

Laut man smb.conf und weiterer Dokumentation sollten diese Bereiche mit den existierenden Benutzern überlappen, dies funktioniert aber nur, wenn man die Uids und Gids auch per winbindd erzeugen lässt.

Also kurz um: Man ignoriere jegliche Warnung in man smb.conf, schlage alle Hinweise in den Wind, setze einige laut Dokumentation nicht funktionierende Parameter, und siehe da es funktioniert. Manchmal hilft es einfach die Dokumentation zu ignorieren.

Support für Open Source – Teil 3

ACLs unter Samba laufen nun ja schon, leider musste ich feststellen, dass ACLs über NFSv3 plötzlich nicht mehr gingen, weder ein setzen der ACLs mit setfacl noch das zusätzliche + in der Ausgabe von ls -l funktionierte. Es wurden nur normale Unix-Berechtigunen angezeigt, obwohl ACLs gesetzt waren.

Da ich aber wusste, dass ACLs über NFSv3 schonmal funktionierten, kam mir das äusserst komisch vor. Ich testete also den letzten stabilen Kernel auf meinem NFS Server Zuhause. Mit Kernel 2.6.14.6 funktionierte alles einwandfrei.

Also Bugreport an die ACL Entwicklerliste abgesetzt (bzw. wieder absetzen lassen):

http://acl.bestbits.at/pipermail/acl-devel/2006-January/001942.html

und was passierte? Am Tag darauf war wieder der Patch mit der Lösung des Problems angekommen:

http://acl.bestbits.at/pipermail/acl-devel/2006-January/001943.html

Patch eingespielt, gleich auf Kernel 2.6.15.1 aktualisiert, Kernel installiert und neu gebootet. Und siehe da, jetzt funktionieren auch wieder die ACLs über NFSv3.

Support für Open Source – Teil 2

Nachdem ich durch Performence Tests festgestellt habe, dass ich mit AoE (ATA over Ethernet) beim neuen SAN auf das falsche Pferd gesetzt habe, musste ich schnell zu Plan B greifen und alles auf ENBD (Enhanced Network Block Device) umstellen.

Dies lief an sich auch ziemlich problemlos, nur stellte ich dann am Samstag fest, dass ENBD wohl ein 2 Terabyte Problem hat. Die freigegebenen 4 Terabyte Raid-Systeme wurden auf den Frontends nur mit ca. 1,7 Terybyte Kapazität erkannt. Ein klassischer Überlauf eines Zahlenwertes.

Ohne grosse Hoffnung vor Montag eine Antwort vom Entwickler von ENBD zu erhalten, habe ich einfach mal eine E-Mail an die Mailingliste von ENBD abgesetzt:

http://lists.community.tummy.com/pipermail/enbd/2006/004328.html

Zu meiner Überraschung antwortete der Entwickler von ENBD, Peter T. Breuer, schon 2 Stunden später. Knapp ein dutzend Mails, 3 Espresso und einige Tests später, war das 2 Terabyte-Problem behoben, und das System war endlich funktionstüchtig.

http://lists.community.tummy.com/pipermail/enbd/2006/thread.html

DAS nenne ich Support. Jetzt soll mir bitte jemand mal einen kommerziellen Dienstleister nennen, der mir bei ähnlich gelagerten Problemen noch Samstags Nachts hilft, und man sogar zu einer Lösung kommt! Auch nochmal an dieser Stelle vielen Dank an Peter für seine Hilfe!