3.1.2012 von rmo.

An an meinen Arbeitsplatzsystemen habe ich inzwischen Opensuse 12.1 am Laufen. Dabei bin ich sowohl beim Upgrade meines PCs und bei einer Neuinstallation auf einem Laptop auf ein Problem mit “ssh” reingefallen. Das Problem trat schon bei Opensuse 11.4 auf. Ich hatte es nur vergessen. Deshalb ein kurzer Beitrag für diejenigen, die auch auf das Problem stoßen. Die nachfolgenden Erkenntnisse sind nicht auf meinem Mist gewachsen; das Wichtigste hat bereits Martin Vidner in einem entsprechenden Novell-Bug-Report als Kommentar geschrieben:

https://bugzilla.novell.com/show_bug.cgi?id=686477

Problembeschreibung

Deaktiviert man nach einer Installation von Opensuse 11.4/12.1 im Zuge der Netzwerkeinrichtung mittels Yast IPV6, so funktioniert danach von einem Remote-PC aus zwar noch der ssh-Login und das Arbeiten im ASCII-Terminal auf dem Opensuse 11.4/12.1-System. Das Starten von X- oder KDE-Applikationen wird aber verweigert.

Bei KDE-Applikationen taucht die Warnung auf, dass kein Zugang zum X-Server möglich sei. Dies obwohl man ggf. auf dem Zielsystem mit “xhost + RemotePCAdresse” den Zugriff explizit zugelassen oder aber entsprechende Auth-Mechanismen und Schlüssel korrekt eingerichtet hat.

Bei Standard-X-Applikationen wie “xterm” erhält man eine Nachricht, dass die Umgebungsvariable DISPLAY nicht gesetzt sei. Ein “echo $DISPLAY” zeigt, dass dies auch stimmt. Eigentlich sollte hier ein “localhost:10.0″ als Wert auftauchen.

Problembehebung

Lösung 1: Aktiviert man IPV6 mittel YAST wieder und rebootet man, so läuft danach alles wieder wie man es erwartet.

Lösung 2: Bei diesem Ansatz geht man an die Wurzel des Problems. Diese Lösung ist allerdings nur dann sinnvoll, wenn man IPV6 wirklich nicht verwenden will. Der Grund des Problems liegt in der Konfiguration des SSH-Daemons “sshd”. Die entsprechende Konfigurationsdatei liegt unter

/etc/ssh/sshd_config

Hier gelten weitgehend die Defaulteinstellungen, die man (zumindest bei SuSE) auch in den kommentierten Zeilen der Datei findet. Von Interesse ist die Vorgabe

#AddressFamily any

Auf Basis dieser Einstellungen sucht der ssh-Daemon nach beiden Protokollen gleichzeitig. Obwohl bei deaktiviertem IPV6 nur IPV4 gefunden werden muss. Für reines IPV4 hilft nun statt “any” die Einstellung “inet”, also :

# changed by rmo - because of IPV6 - IPV4 bug (see https://bugzilla.novell.com/show_bug.cgi?id=686477)
AddressFamily inet

Konfigurationsdatei speichern, mittels Yast IPV6 deaktivieren, rebooten und testen. “ssh -X” funktioniert dann von einem Remote-PC aus wie erwartet - obwohl IPV6 auf dem Opensuse 11-4/12.1-Host deaktiviert ist. X-Anwendungen lassen sich nun starten.

Bleibt nur die Frage, wer sich darum kümmern wird, dass bei künftigen Releases das “any” in der sshd-Konfiguration alternativ als IPV6 oder IPV4 interpretiert wird.

Nachtrag 05.12.2012: Zusätzliches sshd-Problem unter Opensuse 12.1 - Fehlermeldung zu DSA-Keys

Bei Upgrades zu und bei einer Neuinstallation von Opensuse 12.1 bin ich darüber gestolpert, dass das Starten des “sshd”-Dämons mit der Meldung:

Generating /etc/ssh/ssh-host-dsa-key
DSA keys must be 1024 bits
Startig SSH daemon
Could not load host key:
/etc/ssh/ssh-host-dsa-key

quittiert wird. Die letzte Meldung ist korrekt: der Key wird zumindest nicht am erwarteten Bestimmungsort erzeugt. Ohne die genaue Fehlerursache in den entsprechenden Skripts analysiert zu haben, möchte ich darauf hinweisen, dass man das Problem über einen mutigen händischen Versuch zur Schlüsselgenerierung

ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key

umgehen kann.

Geschrieben in Opensuse 12.1, Netzwerk | Keine Kommentare »

23.8.2011 von rmo.

Habe in der letzten Zeit auf meinem Opensuse 11.4 keine Samba CIFS-Shares mehr freigegeben. Heute musste ich das jedoch mal wieder tun.

Ergebnis: 1,5 Stunden ging erstmal gar gar nichts. Zwar werden die Shares in “smbtree” und “smbclient” angezeigt, aber ein Versuch, die Inhalte der Share-Verzeichnisse in “smbclient” aufzulisten, endete jedesmal mit

NT_STATUS_ACCESS_DENIED listing \*.

Ebenso schlug das Browsing in Dolphin oder von anderen Rechnern aus fehl.

Natürlich habe ich dann meine Konfiguration geprüft, Passwörter und Rechte gecheckt, meine Zugriffsdaten mehrfach über “smbpasswd” und “pdbedit” upgedated, die Fehlerfreiheit von smb.conf mit “testparm” gecheckt und Zeit in das Studium von Samba-logs investiert. Mein Problem war auch nicht das, dass “/etc/init.d/smb” oder “/etc/init.d/nmbd” nicht gelaufen wären, wie das lt. Internet bei anderen Opensuse 11.4-Usern schon vorgekommen sein muss. Siehe etwa:

http://www.hardwarecrash.de/index.php/faq/software/linux/opensuse/215-opensuse-114-nmbd-startet-nicht
http://forums.opensuse.org/english/get-technical-help-here/network-internet/456049-11-4-samba-wont-run.html
http://www.linux-club.de/viewtopic.php?f=6&t=112904
http://forums.opensuse.org/english/get-technical-help-here/network-internet/455677-mount-cifs-issue-opensuse-11-4-a-2.html

Mein Opensuse 11.4 ist zudem auf dem neuesten Stand. Ich war wirklich ratlos.

Dann habe ich meine SMB-Konfiguration auf einem anderen, nicht vollständig aktualisierten Opensuse 11.4-System nachgestellt. Dort lief die Sache anstandslos. Also mussten irgendwelche Paket-Updates bei mir etwas “verschlimmbessert” haben.

Über weitere Hinweise im Internet bin ich dann auf Apparmor als Ursache vieler Samba-Probleme unter Opensuse 11.4 gestoßen. Ich habe dann zunächst geprüft, ob Apparmor bei mir über das Kontrollpanel unter Yast deaktiviert war. Ja, das war es. Dennoch lag der Fehler im Apparmor-Bereich und zwar in irgendeiner perversen Weise, die man als Endverbraucher nicht mehr verstehen kann und will :

Es half nämlich auch nichts, SMB-bezogene Profile aus Apparmor per Yast zu löschen. Einzig und allein

• ein (zweifaches) Anwenden des “Assistenten zum Aktualisieren von Profilen” unter Yast im Bereich Apparmor
• und ein “Zulassen” bei den hochkommenden SMB-relatierten Profilfragen

brachte die Lösung.

Liebe Leute von Novell:

Solche Bugs sind so dermaßen kontraproduktiv und so dermaßen desillusionierend, das man nur noch müde abwinken kann. (Ich habe meiner Frau versprochen, mich über sowas nicht mehr aufzuregen.) So gewinnt man keine Freunde für Linux in Form der Opensuse Distribution und schon gar nicht für Apparmor. Es führt eher zu dem Reflex, dieses Tool gar nicht mehr zu installieren.

Es trägt übrigens wenig zu meiner Beruhigung bei, dass es unter Fedora mit SELinux mal ein ähnliches Problem gab. Siehe etwa die Diskussion und nachfolgenden Beiträge zu http://lists.samba.org/archive/samba/2007-April/130900.html

Ursache für diese Misere ist aus meiner Sicht mal wieder das aktuelle Kernproblem von Opensource: die mangelnde Qualitätssicherung. Man ist als User - und vor allem als Enduser - halt doch immer Beta-Tester. Nun halt mal in puncto Sicherheit. Na toll …..

Links:
http://www.linux-club.de/viewtopic.php?f=6&t=113044
http://forums.opensuse.org/deutsch-german/hilfe-und-helfen/installation-administration/458037-opensuse-11-4-samba-probleme-wegen-apparmor.html
http://web.archiveorange.com/archive/v/TDuKzixdvQtYbQQ6CLRH
http://www.linux-club.de/viewtopic.php?f=6&t=113221

Geschrieben in Netzwerk, Erfahrungsberichte | Keine Kommentare »

20.7.2010 von rmo.

Immer mal wieder fragt mich jemand, was er tun muss, damit Dateien oder Unterverzeichnisse unterhalb eines bestimmten ext3- oder ext4-Verzeichnisses auf einem Linux-System immer mit der gleichen Gruppe und (!) immer mit den gleichen Gruppen-Rechten erzeugt werden.

Problemstellung

Das Problem der Vererbung von GIDs und Gruppenrechten tritt z.B. immer dann auf, wenn mehrere Entwickler einer Gruppe auf einem Verzeichnis arbeiten und neu erzeugte Dateien auch allen anderen Benutzern der Entwicklergruppe mit gleichen Rechten zugänglich gemacht werden sollen. Und das, ohne dass man beim Erzeugen der neuen Dateien und Verzeichnisse spezielle Rechteänderungen über das “chmod”-Kommando vornehmen müsste.

Offenbar ist das Thema weniger trivial, als man meinen möchte. Denn manchmal liest man in Tutorials, dass es genügen würde, das SetGID-Bit für das betroffene Directory zu setzen. Das stimmt so leider nicht - und so mancher beginnt dann mit

“chgrp -R”     und     “chmod -R”

zu experimentieren. Was auch nicht hilft, weil das nur einmalige - wenn auch rekursive - Änderungen im betroffenen Zweig des Dateibaums herbeiführt. Das eigentliche Ziel ist aber, die richtige Gruppenzugehörigkeit und die notwendigen Rechte (meist Schreibrechte) schon beim Erzeugen einer Datei zu erhalten.

Liegen die Dateien auf einem Fremdrechner, so kann man eine Lösung über Samba erreichen. Wir wollen hier aber eine native Lösung für beschreiben.

Die richtige Antwort auf dieses Problem ist eine Kombination aus ACLs und dem SetGID-Bit.

Vorgehen

Wir nehmen zwei User eines Systems - “alpha” (uid 1001; dieser User wird der Entwicklunsgleiter) und “beta” (uid 1002). Beide seine Mitglieder der Gruppe “users” (gid 100). umask habe den Standardwert

umask 022

Was ist nun zu tun?

Schritt 1: Anlegen einer gemeinsamen Usergruppe
Als root: Anlegen einer neuen Gruppe “entwickler” (gid: 101) und Zuordnen der beiden User zu dieser Gruppe. (Unter Opensuse z.B. mit Hilfe von Yast; ansonsten mit “groupadd” und “usermod -A” - siehe die man-Seiten).

Schritt 2: Check, ob ACLs für das Filesystem aktiviert sind
Als root: Prüfe, ob das Filesystems, in dem das Verzeichnis für die Gruppenarbeit angelegt wird, mit der option “acl” gemounted wird. In der Datei “/etc/fstab” sollte sich dafür ein Eintrag der Form

/dev/myFileSystem     /myMountPoint     ext4     acl,user_xattr     1 2

finden. “myFileSystem” steht hier für das betroffene Filesystem. “/myMountPoint” steht dagegegen für das Verzeichnis, auf dem das Filesystem gemounted wird. Entscheidend ist die Option “acl”.

Schritt 3: Anlegen des Verzeichnisses für die gemeinsame Entwicklungsarbeit
Als root oder Entwicklungsleiter “alpha”: Anlegen des Arbeitsverzeichnisses, unter dem die gemeinsame Projektarbeit vor sich gehen soll. Z.B.:

mkdir   /myMountPoint/Entwicklung

Danach Ändern der Gruppe und der Rechte

chgrp   entwicklung     /myMountPoint/Entwicklung
chmod   775     /myMountPoint/Entwicklung

Schritt 4: Setzen des SetGID-Bits
Als Entwicklungsleiter “alpha”:

chmod   g+s     /myMountPoint/Entwicklung

Von nun an erben alle Verzeichnisse und Dateien, die unterhalb des Verzeichnisses “/myMountPoint/Entwicklung” angelegt werden, die die Gruppenzugehörigkeit zur Gruppe “entwicklung”.

Schritt 5: Setzen der ACL-Maske
Als Entwicklungsleiter “alpha”:

cd  /myMountPoint

setfacl -m     m::rwx     Entwicklung

Diese Maske setzt die maximal möglichen Rechte für das Verzeichnis “Entwicklung”.

Schritt 6: Setzen der Default-Rechte für künftige Dateien und Unterverzeichnisse
Als Entwicklungsleiter “alpha”:

cd   /myMountPoint

setfacl -dm     g:entwicklung:rwx     Entwicklung

Schritt 7: Prüfen der Rechte für neue Dateien und Unterverzeichnisse
Als Gruppenmitglied “beta”:

cd   /myMountPoint/Entwicklung

touch   test
ls -l
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul 20:18     test

mkdir   testdir
ls -l
drwxrwsr-x+ 2     beta     entwicklung     4096     20. Jul     21:20     testdir

touch   testdir/test2
ls -l   testdir
-rw-rw-r–+ 1     beta     entwicklung     0     20. Jul     21:22     test2

Viel Spaß nun beim Arbeiten in der Gruppe !

Links
http://wiki.ubuntuusers.de/chmod#SGID-Bit
http://wiki.ubuntuusers.de/ACL#Verzeichnisse

Geschrieben in Netzwerk, LAMP / Webentwicklung | Keine Kommentare »