Um nicht lange um den heißen Brei herumzureden: Wir haben es nicht geschafft (Zeit, Lust, und andere Ausreden…). Gestern hab ich nun eine nette Mail bekommen, dass es ab sofort unter https://github.com/fx5/usbdmx einen Linux-Treiber gibt. Vielen Dank an Frank Sievertsen für den freundlichen Hinweis und die Entwicklung eines solchen Treibers!

Es stimmt, an sich ist es nicht schwer, einen WebDAV-Server aufzusetzen. Ein (klein) wenig spannender wird das schon, wenn man den Anspruch hat, dass der Server auch mit mehr als nur Linux kompatibel sein soll. Die ersten Selbstmordgedanken kommen dann, wenn man sich gegen LDAP authentifizieren möchte und spätestens, wenn dann noch ein System hinter dem WebDAV sitzen soll, welches Berechtigungen überprüft ist es gut, wenn alle Fenster des Raums auf Erdgeschosshöhe sind.

Zu den Problemen im Einzelnen:

• Inkompatibilitäten: Windows verwendet eine nicht 100% kompatible Implementierung von WebDAV, d. h. dass man bestimmte Eigenheiten berücksichtigen muss, bevor Windows sich erfolgreich authentifizieren kann. Wenn der Server bereits beim initialisierenden OPTIONS-Request nach Benutzer/Passwort fragt, meckert Windows über eine ungültige Resource.
• LDAP: Für HTTP gibt es zwei Authentifizierungs-Methoden: Basic und Digest. Der Unterschied ist, dass bei Basic Auth das Passwort im Klartext übertragen, bei Digest ein gesalzener Hash verwendet wird. Die Schwierigkeit dabei ist, dass LDAP nur Abfragen zulässt á la “stimmt das Passwort hier?”, also nur mit Klartextpasswörtern arbeiten kann. Wenn man also LDAP verwenden möchte, muss man dabei die Basic Auth-Methode verwenden.
  Jetzt kommt aber wieder Microsoft und sagt: Nein, ohne SSL mag ich kein Basic Auth (oder, um ausführlicher zu sein: Manche Windows-Versionen mögen garkein Basic-Auth, manche nur per SSL und manchen ist es egal. Aber Dokumentationen dazu findet man, außer in der 1&1-FAQ, nicht wirklich, von daher war das ein Probieren ohne Ende) .
• Redmine: Wenn man die ersten Hürden gemeistert hat, bleibt noch, die Authentifizierung über das Redmine-System laufen zu lassen. Es gibt von Redmine selbst ein Perl-Modul für Apache, welches die Authentifizierung für SVN übernehmen kann, testweise hat auch Git funktioniert, spannend (da ebenfalls mager dokumentiert) war, ob das auch für das normale WebDAV funktioniert – tut es.

Wenn man also jetzt keine Ahnung hat, an welcher Stelle dieses Monstrums die vielen Fehler, die man um die Ohren geschmissen bekommt, verursacht werden verzweifelt man regelrecht an den immerwieder auftauchenden niederschmetternden Fehlermeldungen, die – ausführlich, wie man es von Windows und Konsorten gewohnt ist – lediglich besagen: “Geht nicht”.

Rückblickend kann ich sagen: War doch eigentlich ganz einfach, sofern man verstanden hat, was die einzelnen Systeme von einem wollen und wie man sie richtig konfiguriert. Hier mal meine Konfiguration, die man innerhalb eines SSL-vHosts verwenden kann, um WebDAV zu aktivieren:

<Location /webdav>
DAV on
AuthType Basic
AuthName "Redmine WebDAV"
PerlAccessHandler Apache::Authn::Redmine::access_handler
PerlAuthenHandler Apache::Authn::Redmine::authen_handler
RedmineDSN "DBI:Pg:dbname=redmine;host=localhost"
RedmineDbUser "redmine"
RedmineDbPass "topsecret"
<Limit OPTIONS>
Order allow,deny
Allow from all
Require valid-user
Satisfy any
</Limit>
<LimitExcept OPTIONS>
Require valid-user
</LimitExcept>
Options +Indexes
</Location>

Viel Erfolg beim Einrichten!

Da ich immer wieder gefragt werde (und auch selbst immer wieder nach den entsprechenden Zeilen im Internet suche), wie man einen Linux Rechner, der mit dem Internet verbunden ist, Gateway für andere PCs spielen lassen kann, die sehr einfache Lösung hier als Copy&Paste. Bitte das Netzwerkinterface (bei mit eth0) anpassen, damit ist das ausgehende Netzwerkinterface des Gateway-Rechners gemeint:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

Jetzt bei dem/den Client-Rechner(n) die IP des Gateway-Rechners eintragen, fertig.

Im Home-Verzeichnis einfach (sofern nicht vorhanden) ein Verzeichnis mit dem Namen .vmware anlegen, dort eine Datei config die folgenden Inhalt bekommt:

xkeymap.keycode.108 = 0×138 # Alt_R
xkeymap.keycode.106 = 0×135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0×148 # Up
xkeymap.keycode.116 = 0×150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0×152 # Insert
xkeymap.keycode.119 = 0×153 # Delete
xkeymap.keycode.110 = 0×147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0×149 # Prior
xkeymap.keycode.117 = 0×151 # Next
xkeymap.keycode.78 = 0×46 # Scroll_Lock
xkeymap.keycode.127 = 0×100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu

Damit sollten die Probleme erledigt sein. Vielen Dank an http://throwingmywindows.blogspot.com/2008/12/vmware-arrow-key-problem.html, von dieser Seite habe ich diese Lösung.

Der Server mit den Benutzerdaten ist ein “echter” Host, der irgendwo als physische Maschine rumsteht. Damit man sich nicht groß mit SSL, Verschlüsselung und Sicherheit rumschlagen muss habe ich kurzerhand auf Server und Client OpenVPN installiert. Wie genau die Einrichtung funktioniert entnehme man bitte der verlinkten Seite. Jedenfalls hatte ich so ein eigenes Netzwerk, welches sogar Verschlüsselung zwischen den einzelnen Knoten hat, damit sind (vorerst) die gröbsten Löcher gestopft.

Nun schnell MySQL umkonfigurieren, damit der DB-Dienst nicht an localhost sondern an meinem neuen virtuellen VPN-Interface lauscht. Dazu passt man einfach den Eintrag ‘bind-address’ in der Datei /etc/mysql/my.cnf an. Beispiel (unsichere Methode, lauscht überall):

bind-address = *

Außerdem muss man noch (per phpMyAdmin o. ä.) die Datenbank+Tabellen erstellen und, wenn man das System auch benutzen möchte, Daten einpflegen. Hier poste ich nun einfach mal meine Struktur der Tabellen

CREATE TABLE IF NOT EXISTS `sys_groupmembers` (
`uid` int(11) NOT NULL default ’0′,
`gid` int(11) NOT NULL default ’0′
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

CREATE TABLE IF NOT EXISTS `sys_groups` (
`gid` int(11) NOT NULL auto_increment,
`groupname` varchar(30) character set latin1 NOT NULL,
`group_password` varchar(64) character set latin1 NOT NULL default ‘x’,
PRIMARY KEY (`gid`)

) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1000;

CREATE TABLE IF NOT EXISTS `sys_users` (
`uid` int(11) NOT NULL auto_increment,
`username` varchar(50) character set latin1 NOT NULL,
`realname` varchar(32) character set latin1 NOT NULL default ”,
`shell` varchar(20) character set latin1 NOT NULL default ‘/bin/sh’,
`password` varchar(40) character set latin1 NOT NULL default ”,
`gid` int(11) NOT NULL default ’65534′,
`homedir` varchar(32) character set latin1 NOT NULL default ‘/bin/sh’,
`lastchange` varchar(50) character set latin1 NOT NULL default ”,
`min` int(11) NOT NULL default ’0′,
`max` int(11) NOT NULL default ’0′,
`warn` int(11) NOT NULL default ’7′,
`inact` int(11) NOT NULL default ‘-1′,
`expire` int(11) NOT NULL default ‘-1′,
PRIMARY KEY (`uid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci AUTO_INCREMENT=1000 ;

Auf dem Client installiert man nun die Pakete nscd und libnss-mysql (ich benutze eigentlich immer Debian/Ubuntu, da heißen die Pakete direkt so und die Installation ist mit apt-get install schnell erledigt. Bei anderen Distributionen bitte entsprechende Befehle verwenden oder die Pakete einfach von Hand installieren). Dann werden die entsprechenden Konfigurations-Dateien angepasst:

nsswitch.conf ist für das Betriebssystem ein Hinweis wo/wie überall nach Benutzern gesucht werden kann. nss-mysql.conf gibt an, wie man alle interessanten User-Details mit Ausnahme des Passworts bekommen kann. nss-mysql-root.conf füllt eben genau diese Lücke. Daher sollten für beide Configs verschiedene Benutzer verwendet werden, der Datenbankbenutzer der nss-mysql.conf – Config (also der, der nicht nach dem PW gefragt wird) sollte auch keine Rechte haben, auf die Passwort-Spalte in MySQL zuzugreifen. Außerdem verlangt libnss, dass die nss-mysql-root.conf nur von Benutzer root gelesen werden kann (also chmod 600), denn niemand außer root sollte generell an die System-Passwörter kommen, was man allerdings mit Hilfe des in dieser Datei notierten MySQL-Passworts doch erreichen könnte.

/etc/nsswitch.conf:
An das Ende der Zeilen, die mit “passwd”, “group” bzw. “shadow” anfangen, hängt man (mit einem Leerezeichen Abstand zum bisherigen letzten Wort) das Wörtchen “mysql” hintendran. So siehts dann aus:

passwd: compat mysql
group: compat mysql
shadow: compat mysql

/etc/nss-mysql.conf:
Ich gebe hier nur die Zeilen wieder, die kein Kommentar sind. Hostname, Datenbankname, Benutzername und Passwort sind erfunden und sollten den jeweiligen Bedingungen angepasst werden:

conf.version = 2;
users.host = inet:mein.server.tld:3306;
users.database = userdata;
users.db_user = nss-auth-normal;
users.db_password = 123geheim;
users.table = sys_users;
users.where_clause =;
users.user_column = sys_users.username;
users.password_column = sys_users.password;
users.userid_column = sys_users.uid;
users.uid_column = sys_users.uid;
users.gid_column = sys_users.gid;
users.realname_column = sys_users.realname;
users.homedir_column = sys_users.homedir;
users.shell_column = sys_users.shell;
groups.group_info_table = sys_groups;
groups.where_clause =;
groups.group_name_column = sys_groups.groupname;
groups.groupid_column = sys_groups.gid;
groups.gid_column = sys_groups.gid;
groups.password_column = sys_groups.group_password;
groups.members_table = sys_groupmembers;
groups.member_userid_column = sys_groupmembers.uid;
groups.member_groupid_column = sys_groupmembers.gid;

/etc/nss-mysql-root.conf:
Diese Konfiguration wird für den Abgleich von Passwörtern verwendet:

conf.version = 2;
shadow.host = inet:mein.server.tld:3306;
shadow.database = userdata;
shadow.db_user = nss-auth-root;
shadow.db_password = 124geheim;
shadow.table = sys_users;
shadow.where_clause =;
shadow.userid_column = sys_users.uid;
shadow.user_column = sys_users.username;
shadow.password_column = sys_users.password;
shadow.lastchange_column = sys_users.lastchange;
shadow.min_column = sys_users.min;
shadow.max_column = sys_users.max;
shadow.warn_column = sys_users.warn;
shadow.inact_column = sys_users.inact;
shadow.expire_column = sys_users.expire;

Das wars eigentlich. Nun noch alle betroffenen Dienste (nscd, mysql,openvpn) neustarten und der Spaß sollte funktionieren.

Was ich leider noch nicht geschafft habe, ist die Administration der in der Datenbank gespeicherten Benutzer und Gruppen per Kommandozeilen-Tools, ein erster Ansatz wäre z. B. schonmal passwd, aber selbst das klappt (noch) nicht… Sollte jemand wissen, wie das funktioniert: Da unten ist ein Kommentarfeld Ansonsten: Viel Erfolg bei euren Installationen, bei Fragen und Problemen einfach melden.