Samba/CIFS und Kerberos Authentifizierung

Nachdem ich NFS und Kerberos installiert hatte, wollte ich auch Samba/CIFS an Kerberos anbinden. Das gestaltete sich schwerer als erwartet.

Das Einrichten auf Serverseite gestaltete relativ reibungslos. Einfach dem Samba-Dienst entsprechend Konfigurieren.

Im Kerberos hinterlegt man einen entsprechenden Principal und fügt ihn dem CIFS-Server hinzu.

Nach einem Neustart des Dienstes werden die User-Credentials von Samba gegenüber Kerberos Authentiziert.

Auf Client-Seite war dem ganzen nicht so leicht bei zu kommen. Als erstes muss ein Client-Key am Kerberos erzeugt werden und in der Client Keytab hinterlegt werden.

Anschließend mounted man den Share wie folgt:

Bis dahin hat mich das „nur wenige“ Stunden gekostet. Der Parameter „uid“ wird scheinbar gebraucht wenn Winbind nicht so will, wie es soll. Ich hab es ums verrecken nicht hinbekommen, dass der Winbind mehr schmeißt als nur Fehler.

Daneben war es mit nicht möglich den krb5i-Modus zu aktivieren, also Schutz gegen Veränderung der einzelnen Daten-Pakete. Zudem scheint CIFS/Samba nur beim Mount die Usercredentials zu überprüfen und die Verbindung dann an den User zu knüpfen. Wenn ein anderer User (root) auf den Share zugrifft, erfolgt das unter der UID des Users der den Mount aufgemacht hat.

serverseitige Profile

Wer mehrere Rechner sein eigen nennt und dazu noch einen Server beseitzt wird über kurz oder lang auf die wahnsinnige Idee kommen, alle userbezogenen Daten auf dem Server abzulegen, um im Falle eines Crashes alles wieder bei sammen zu haben oder schlicht um an allen Rechnern auf die gleichen Daten zuzugreifen.

Dies kann man unter Linux sehr bequem mittels mounting sehr elegant lösen. Einfach den Pfad /home/$(USERNAME) mittels pam_mount auf ein externe Quelle/Server mounten.

Unter Windows geht das nur über eine Domäne, bei der (nach wunsch) das Userprofiel serverseitig gespeichert wird.

Fährt man den Server jedoch mal runter  (kann im wartungsfall passieren) oder nutzt man das Ganze an einem Laptop und ist nicht im privaten netzt wird man folgendes festellen:

  • Linux: die GUI (Gnome/KDE/whatever) fährt hoch, aber alles sieht aus wie beim ersten Start.
  • Windows: man wird darauf hingewiesen, dass die Domäne samt serverseitgen Profielen nicht verfügbar ist. Sonst merkt man nichts.

Dies liegt an dem Umstand das Windows die Profile nach dem Anmelden downloaded und beim Abmelden wieder zurück kopiert. Steht der Server einmal nicht zur Verfügung wird mit der Kopie weitergearbeitet.

Steht ein Server bei einem Linux-Mount mittels CIFS oder NFS  nicht zur verfügung, schlegt der Mount fehl (was einem aber nur im syslog vermerkt wird) und man arbeitet nur noch lokal. Solange der Server online ist, schreibt man aber alles „direkt“ auf dem Server. Ohne nutzbare lokale kopie.

Ideal wäre eine DFS -implemntierung die einen das alles transparent abnimmt. Diese eierlegende Wollmichsau habe ich leider nicht gefunden. Deswegen habe ich folgenden Lösungsansatzt benutzt.

Die Idee von Microsoft für unterschiedliche „Systeme“ unterschiedliche Profile anzulegen, fand ich ganz vernünftig. Es gibt also Profile für ein WinXP64, WinXP32 usw… Auf einem DoppelKern mit dicker Graka läuft was anderes als auf einem Atom-Laptop. Nachteilig ist, dass das auch die „Eigenen Dateien“ betrifft, welche eigendlich Systemunabhängig sein sollten, wenn sich mal alle Entwickler drann halten würden.

Unter Linux lässt sich diese Trennung wesentlich leichter durchziehen, dank der Disziplin. Auf dem Server werden zwei Verzeichnisse angelegt und verfügbar gemacht.

  • Home-Verzeichniss: hier kommt alles rein was auf allen Rechnern zur verfügung stehen soll.
  • Profiles\$(System): hier kommt alles rein, was ein bestimmtes system betrifft.

Am Client muss man diese beiden verzeichnisse nur noch mittels mount irgendwohin mounten. „/mnt/.serverprofile“ und „/mnt/homedir“ bieten sich an . Da man den String der das System identifieziert selber wählen kann, steht einem die aufteilung frei. Sinnvoll ist eine auftreilung nach KDE/Gnome/Xfce. Es sind aber auch andere Aufteilungen möglich.

jetzt braucht es zwei scripte die das kopieren übernehmen:

  • Server->Lokale Kopie:
  • Lokale Kopie->Server:

Das erste Bash-Listing dürfte nicht verwundern. Alle Dateien aus den serververzeinissen werden in das Uservervzeichniss kopiert. „rsync -a“ sorgt nur dafür das alle gesetzten Rechte erhalten bleiben (außer ACLs was mich aber nicht stört)

Beim zweite Listing könnte nur der Ausdruck „~/.[a-Z,0-9]*“ verwirren. Der sorgt dafür das nur Files kopiert werden die mit einem Punkt beginnen. (Korrekt: es werden nur Dateien/Ordner kopiert die mit Punkt beginnen gefolgt von einem Buchstaben oder Zahl. Bei Bedarf muss das angepasst werden)

Die scripte sind nicht sonderlich intelligent und werden von mir im laufe der  Zeit auf effizents getrimmt. Man gewinnt viel zeit wenn man nur änderungen übertragt. Ich werde mal schauen was mit tar so gemacht werden kann…

Jetzt müssen diese beiden Scriptes nur noch bei an/abmeldung ausgeführt werden. Jeh nachdem welchen Desktopmanager man benutzt, ändert sich das vorgehen.

  • KDE: Unter „Systemeinstellung“ -> „Erweiterte Benutzereinstellung“ -> „Autostart“ kann man die Scriptes verlinken. Das ist unschön, da man es für jeden benutzer einzeln machen muss, für eine größere Anzahl an Rechner ist das nicht zu administrieren. Unter /usr/shutdown kann man auch scriptes ablegen. Diese Scriptes ziehen aber nur bei „Shutdown“ nicht logoff. Hier bin ich noch auf der suche nach einem entsprechend besseren Lösung.
  • Gnome: Hier bietet der GDM entsprechende Einsprungpunkte. /etc/gdm/PostSession und /etc/gdm/PreSession
  • Xcfe: hab ich (noch) nicht einsatzt. Wird aber im Laufe der nächsten Wochen geändert.

Mit den gemachten einstellung hat man sein Profiel auch wenn der Server mal nicht verfügbar ist.

PS: unter KDE wird er Kopie-Script ausgeführt wenn die Oberfläche oben ist. Es empfiehlt sich also vor dem ersten start, in der Konsole alles zu kopieren. Sonst könnte der geneigte user beim ersten start ein Schock bekommen: „Whaaa alles weg“.

Sambafreigaben und das Homedir

Wie schon im vorherigen Eintrag erwähnt, gibt es einige Haken und Ösen wenn man mittels CIFS einen Samba Share als Homedir mountet.

Ein weiterer Haken tritt auf, wenn die GroupIDs und UserIDs zwischen Server und Clienten nicht matchen.

Wichtig bei zu verstehen bei (fast) allen Netzwerk-FileSystems ist. Der Benutzer mit dem man sich authentifiziert, ist nicht unbedingt der Benutzer mir dem man die „Dateien“ erstellt. Beispiel, der Admin mountet unter UserA einen Share und UserB ist auch angemeldet und greift auf diesen Share (auf der gleichen Maschine) zu. Alle Dateien die jetzt UserB anlegt (sofern er das denn darf) werden mit seiner UserID angelegt…

nun kann man um sowas zu unterbinden, sowohl unter SAMBA(Server) als auch beim CIFS (Client) angeben, dass die Gruppen und UserIDs überschrieben werden sollen.

Das nützt blos nicht immer etwas. Einige Programme scheinen den Weg über die Inodes zu nehmen und „umgehen“ dabei dieses force-mapping. Symptome dieses Umstandes sind Probleme mit fehlenden Schreib/Leserechte obwohl man doch mittels „ls -la“ sichtbar alle rechte hat…

In diesem Fall hilft es das clienseitige mapping abzuschalten (gid und uid Parameter beim mounten) und die GroupIDs und UserIDs dem Server anzugleichen (/etc/group und /etc/passwd anpassen)

Sambafreigaben und „stale lockfiles“

Wenn man unter Linux auf die Idee kommt sein HomeDir mittels Samba/CIFS auf einem NAS-Laufwerk abzulegen, ist das prinzipiell gut, es kommt aber unweigerlich zu Schwierigkeiten (oder man kennt den Trick schon…)

Auffälligkeiten sind: OpenOffice und einige andere KDE programme zicken „seltsam“ rum. Starten nicht, lassen sicht nicht ordnungsgemäß beenden oder müssen zwei mal Gestartet werden …

Kandidaten dafür sind: K3B, Amarok, Open Office usw…

All diese Programme schreiben Lockfiles in das .kde/share/ verzeichniss (meist .kde/share/config). Startet man über die Konsole bekommt man nach einiger Zeit Fehlermeldungen der Art „Cannot delete stale lockfile …“

löscht man diese Dateien per Hand, kommt das Programm hoch.

Bei CIFS kann man das Problem recht elegant über den „serverino“-Parameter lösen. Einfach beim mounten diese Parameter mitgeben und schon läuft alles wie geschmiert…