jobstl
Anmeldungsdatum: 29. September 2006
Beiträge: 80
|
Hallo, ich habe einen Ubuntu NFS-Server (Ubuntu 7.10 glaub ich), der die Home-Verzeichnisse exportiert. Dies funktioniert auch einwandfrei. Nun möchte ich dies an einem Client wiederum unter /home mounten. Ich dachte, dass das kein allzu großes Problem ist. Allerdings hängt gnome beim Login, wenn das Home-Verzeichnis gemountet ist. 🙄 In der Konsole geht das Login aber ohne Probleme. Und in /var/log/auth.log kommen viele Meldungen wie: Feb 24 00:55:11 desktop gdm[10042]: gnome-keyring-daemon: couldn't lookup keyring component setting: Der Konfigurationsserver konnte nicht kontaktiert werden; mögliche Fehlerquellen sind, dass TCP/IP für ORBit nicht aktiviert ist oder auf Grund eines Systemabsturzes alte NFS-Sperren gesetzt sind. Unter http://www.gnome.org/projects/gconf/ erhalten Sie weitere Informationen (Details - 1: Verbindung zur Sitzung konnte nicht abgerufen werden: dbus-launch failed to autolaunch D-Bus session: No protocol specified
Feb 24 00:55:11 desktop gdm[10042]: Autolaunch error: X11 initialization failed Ich dachte, dass es in Netzen Standard ist, die Home-Verzeichnisse von einem Server zu mounten und bin daher über diesen Fehler sehr überrascht. 👿 Kann es sein, dass Gnome oder GDM mit root-Rechten auf das Filesystem zugreifen? (hab das auf dem Server unterbunden) Ich hoffe, dass jemand weiß, wie man dieses Problem beheben kann!
|
stfischr
Anmeldungsdatum: 1. März 2007
Beiträge: 19197
|
jobstl schrieb: Kann es sein, dass Gnome oder GDM mit root-Rechten auf das Filesystem zugreifen? (hab das auf dem Server unterbunden)
Wie genau hast du denn den Server eingestellt, das währe mal sehr interessant. Poste mal /etc/exports. NFS Edit: und die /etc/fstab vom Client.
|
jobstl
(Themenstarter)
Anmeldungsdatum: 29. September 2006
Beiträge: 80
|
Also der entsprechende Eintrag in /etc/exports ist: /srv/homes 192.168.1.0/25(rw,sync,no_subtree_check) und der Eintrag in /etc/fstab am Client ist: homes:/srv/homes /home nfs rw,user,noauto,rsize=8192,wsize=8192 0 0 Gibt es so etwas wie Locks von GDM? weil ich habe die Homes schon eingebunden gehabt (glaub allerdings, dass ich sie erst nach dem login in gdm gemountet habe), die Sitzung hat dann aber Troubles gemacht, ist abgestürzt, und seitdem geht es gar nicht mehr.
|
jobstl
(Themenstarter)
Anmeldungsdatum: 29. September 2006
Beiträge: 80
|
Die Frage ist, wie muss ich gdm konfigurieren, damit er mit Home-Verzeichnissen auf NFS umgehen kann? Ich dachte, das geht "out-of-box", wurde leider eines Besseren belehrt. Oder ist es nur ein Problem mit meinem System? Kann mir jemand helfen? Danke!
|
synapsen.stau
Anmeldungsdatum: 27. Mai 2007
Beiträge: 266
Wohnort: Südharz
|
ich glaube der fehlerteufel hat zugeschlagen: jobstl schrieb: Also der entsprechende Eintrag in /etc/exports ist: /srv/homes 192.168.1.0/25(rw,sync,no_subtree_check)
^^
^^
du hast als sunbnetzmaske 25 und nicht 24 angegeben. dadurch ändert sich doch die adresszuornung innerhalb der ip, weil ja jetzt die letzten 25 bits für das subnetz zuständig sind. dadurch "wohnt" dein server z.b. in hausnummer 8 und der "client" klingelt die ganze zeit an hausnummer 7 und bitte vergeblich um einlass. grüße maik
|
jobstl
(Themenstarter)
Anmeldungsdatum: 29. September 2006
Beiträge: 80
|
synapsen.stau schrieb: ich glaube der fehlerteufel hat zugeschlagen: jobstl schrieb: Also der entsprechende Eintrag in /etc/exports ist: /srv/homes 192.168.1.0/25(rw,sync,no_subtree_check)
> ^^
> ^^
vielen Dank für den Hinweis, aber die Zahl 25 ist beabsichtigt. Hintergrund ist, dass ich nur alle Clients bis IP *.128 am Server zulassen möchte. Fakt ist aber, dass ich die Freigabe problemlos mounten kann. D.h. der Fileserver funktioniert, ebenso ist der Client korrekt konfiguriert (denke ich zumindest). Ein Login auf der Konsole ist ohne weiteres möglich, die Daten im Home-Verzeichnis sind die, die auf dem Server liegen. Das Problem das ich habe ist, dass ein Login in Gnome nicht funktioniert. Nach der Eingabe der Anmelde-Daten sehe ich lediglich einen vollständig hellbraunen Bildschirm (so wie das normalerweise die ersten Sekunden ist) und danach passiert gar nichts mehr.
|
jobstl
(Themenstarter)
Anmeldungsdatum: 29. September 2006
Beiträge: 80
|
Hat denn irgendjemand so ein System (Fileserver, der den Clients die Home-Verzeichnisse zur Verfügung stellt) im Einsatz? Ich hätte gerne Erfahrungsberichte, wo es da haken kann. So komplex kann das doch nicht sein, oder?
|
synapsen.stau
Anmeldungsdatum: 27. Mai 2007
Beiträge: 266
Wohnort: Südharz
|
könnte mir vorstellen das gdm ein problem mit den dateizugriffrechten ist. habe das hier gefunden (optionen für die exports datei) http://de.linwiki.org/wiki/Linuxfibel_-_Netzwerk_Server_-_NFS_Server#Exportfs root_squash, no_root_squash Root erhält die UserID des Pseudobenutzers »nobody«, womit der Root-Benutzer des Client-Rechners keine Root-Rechte auf dem vom Server importierten Verzeichnis erhält (Voreinstellung); >mit »no_root_squash« bleiben die Root-Rechte auf Clientseite auf dem Verzeichnis erhalten. all_squash, no_all_squash Alle Zugreifenden erhalten die Nobody-UID; Voreinstellung ist »no_all_squash«, womit die Nutzerkennungen erhalten bleiben
die beiden fett markierten befehle könnten helfen, das sonst auf der clientenseite die daten dem benutzer nobody zugeordnet werden. köönte mir denken, das das blöd ist, weil es ja eigentlich um user xyz geht und nicht nobody.
|
jobstl
(Themenstarter)
Anmeldungsdatum: 29. September 2006
Beiträge: 80
|
no_root_squash: das ist eine Option, die ich sicherlich testen werde. Allerdings gefällt es mir aus sicherheitsrelevanten Überlegungen nicht wirklich. Es ist auch eine meiner Befürchtung gewesen, dass gdm versucht, als root auf die Freigabe zuzugreifen. Das sollte doch nicht unbedingt notwendig sein, oder?
|
synapsen.stau
Anmeldungsdatum: 27. Mai 2007
Beiträge: 266
Wohnort: Südharz
|
jobstl schrieb: Es ist auch eine meiner Befürchtung gewesen, dass gdm versucht, als root auf die Freigabe zuzugreifen. Das sollte doch nicht unbedingt notwendig sein, oder?
das ist ne gute frage..... ich denke das "Voreinstellung ist »no_all_squash«, womit die Nutzerkennungen erhalten bleiben " auch wichtig ist, weil der user "frank" dann zu nobody im eigene home verzeichnis wird. der sicherheitsaspekt ist natürlich nicht ganz unintressant. nfs v4 würde da helfen. ist mit authentification und ein paar anderen verbesserungen.... http://www.brennan.id.au/19-Network_File_System.html#nfs4
|
HMuenz
Anmeldungsdatum: 13. Juli 2007
Beiträge: 611
Wohnort: Rhein/Westerwald
|
Das Problem könnte User-ID der Nutzer in der /etc/passwd sein. Die muss nämlich auf den beiden Systemen identisch sein, sonst geht das nicht. NFS verwendet beim Zugriff auf den Server die UserID, die der jeweilige Nutzer auf dem Client-Rechner hat. Wenn Du nun auf dem Server als ersten User den Nutzer "ernie" anlegst, erhält der normalerweise die UserID 1001. Legst Du anschließend den User "bert" an, erhält der die UserID 1002. Wenn Du jetzt auf dem ersten Client den User "ernie" als ersten User anlegst, erhält der auch die User-ID 1001 und dürfte keine Probleme haben. Legst Du auf dem zweiten Client den User "bert" als ersten User an, erhält der ebenfalls die UserID 1001. Auf dem Server hat er aber die UserID 1002 und kann daher nicht auf das Verzeichnis "bert" zugreifen. Noch schlimmer: er hat in diesem Szenario vollen Zugriff auf das Verzeichnis "ernie", weil der auf dem Server die UserID 1001 hat. Folgende Lösung wäre denkbar: Lege zuerst auf dem Server alle User an, die darauf zugreifen dürfen. Dann druckst Du Dir die /etc/passwd aus, in der Du alle User mit ihrer User-ID findest. Jetzt nimmst Du Dir einen Client nach dem anderen vor und legst den Hauptnutzer jeweils mit der UserID an, die er auf dem Server hat. Im obigen Beispiel müsstest Du also den User bert auf dem Client auf der Konsole wie folgt einrichten:
| sudo useradd -u 1002 bert
|
Damit hätte Bert von seinem Rechner aus vollen Zugriff auf sein Home-Verzeichnis dem Server - und nur darauf.
|
synapsen.stau
Anmeldungsdatum: 27. Mai 2007
Beiträge: 266
Wohnort: Südharz
|
das hört sich logisch an. habe dazu noch folgendes gefunden: anongid=gid Squashing der Gruppe; die Gruppen-ID wird auf »gid« gesetzt. Bei dieser Option kann Root entscheiden, mit welcher Server-GID die Client-Benutzer arbeiten sollen, sobald sie Zugriff auf den Server haben
anonuid=uid Squashing des Benutzers. Die zugreifenden Benutzer bekommen die UID »uid« verpasst und Squashing
Gerade wurde bei den Optionen und Parametern der Begriff »Squashing« eingeführt, doch was bedeutet er?
Lassen Sie es mich an einem Beispiel erklären: Auf dem System »sonne« (NFS-Server) existieren in einem exportierten Verzeichnis folgende Dateien:
user@sonne> ls -l
-rw-r----- 1 root root 166 Apr 27 10:45 foo.bar
-rw------- 1 tux users 16 Apr 27 10:45 testdaten.txt
Des weiteren existieren Benutzer mit folgender UID: root 0 tux 501
Auf System »venus« (unser NFS-Client) existieren Benutzer mit folgenden UIDs: root 0 alf 501 tux 502
Was passiert nun, wenn wir auf dem Client eine Serverfreigabe mounten?
Dazu muss man wissen, dass Unix die Zugriffsrechte nicht aufgrund der Benutzernamen verwaltet, sondern einzig anhand der zugrundeliegenden UIDs. In unserem Falle hat der Benutzer »alf« (auf dem Client) plötzlich
Zugriff auf die Datei »testdaten.txt« von Benutzer «tux«, da beide dieselbe UID 501 besitzen. Gleiches gilt natürlich ebenso für den Benutzer »root«.
Um dies zu verhindern, gibt es das »Squashing«. Hierbei werden die UIDs und GIDs der auf die gemounteten Verzeichnisse zugreifenden Benutzer auf eine neutrale UID (der Pseudouser nobody mit UID -2) und GID
(nogroup mit GID -2) gesetzt, wenn dieses mit der Option »all_squash« exportiert wurde. Die UID 0 (GID 0; also Root) wird in der Voreinstellung stets nach »nobody/nogroup« gemappt; erst die Option
»no_root_squash» verhindert die Umsetzung.
Der alte User-Space-NFS-Server erlaubte das »Squashen« jeder UID auf jede beliege andere und ebenso konnte jede Gruppenkennung (GID) auf jede andere gemappt werden. Der neuer Kernel-NFS-Server arbeitet wesentlich
restriktiver und gestattet einzig, anstatt dem Pseudobenutzer »nobody« bzw. der Pseudogruppe »nogroup« mittels »anonuid=<UID>« bzw. »anonguid=<GID>« andere Kennungen zu vergeben. Diese gelten dann jedoch für
beliebige Gruppen oder Benutzer.
Bez. unserer oben angegebenen Benutzerstrukturen würde bei Export des Verzeichnisses mittels der Option »all_squash« der Client-Benutzer »alf« nur noch ein »Nobody« sein und hätte somit nur Lesezugriff auf die
Datei »testdaten.txt« ich hoffe es hilft
|
HMuenz
Anmeldungsdatum: 13. Juli 2007
Beiträge: 611
Wohnort: Rhein/Westerwald
|
Der alte User-Space-NFS-Server erlaubte das »Squashen« jeder UID auf jede beliege andere und ebenso konnte jede Gruppenkennung (GID) auf jede andere gemappt werden. Der neuer Kernel-NFS-Server arbeitet wesentlich restriktiver und gestattet einzig, anstatt dem Pseudobenutzer »nobody« bzw. der Pseudogruppe »nogroup« mittels »anonuid=<UID>« bzw. »anonguid=<GID>« andere Kennungen zu vergeben. Diese gelten dann jedoch für beliebige Gruppen oder Benutzer.
Soweit ich das verstanden habe, ist Squashing ganz nett für "Share-Verzeichnisse", auf die alle User zugreifen dürfen. Für die Home-Verzeichnisse sollte man da schon etwas restriktiver sein. Bei kleinen Netzwerken würde ich da so vorgehen, wie ich es oben beschrieben habe (netzweit eindeutige UID). Bei größeren Netzwerken sollte man eher auf eine zentrale Nutzerverwaltung mit LDAP und Kerberos zurückgreifen - aber das sprengt hier wohl den Rahmen. 😉 Gruß
Heiner
|
jobstl
(Themenstarter)
Anmeldungsdatum: 29. September 2006
Beiträge: 80
|
Hallo, danke für die Hinweise, werd das bei Zeiten überprüfen (Hatte nur derzeit gerade viel um die Ohren). HMuenz schrieb: Soweit ich das verstanden habe, ist Squashing ganz nett für "Share-Verzeichnisse", auf die alle User zugreifen dürfen.
das klingt interessant, sollte ich mir mal dafür ansehen
Für die Home-Verzeichnisse sollte man da schon etwas restriktiver sein. Bei kleinen Netzwerken würde ich da so vorgehen, wie ich es oben beschrieben habe (netzweit eindeutige UID).
Das habe ich ziemlich sicher so konfiguriert. Aber ich werde das nochmal prüfen.
Bei größeren Netzwerken sollte man eher auf eine zentrale Nutzerverwaltung mit LDAP und Kerberos zurückgreifen - aber das sprengt hier wohl den Rahmen.
Das würde ich sowieso gerne mal ausprobieren, aber mich schreckt der viele Aufwand ein wenig. synapsen.stau schrieb: nfs v4 würde da helfen. ist mit authentification und ein paar anderen verbesserungen.... http://www.brennan.id.au/19-Network_File_System.html#nfs4
Wo bekomme ich mehr Informationen zur Authentifikation bei NFS4 ? Konnte unter dem Link diesbezüglich nichts finden!
|
HMuenz
Anmeldungsdatum: 13. Juli 2007
Beiträge: 611
Wohnort: Rhein/Westerwald
|
Die Aussage, dass NFS V4 die Nutzerverwaltung vereinfacht, kann ich nicht bestätigen. Soweit ich das bisher testen konnte, kann man mit dem "nackten" NFS V4 sogar noch weniger machen, weil alle User auf den Server mit der UID von nobody zugreifen. Eine echte Nutzerverwaltung mit dezidierten Zugriffsrechten ist m.E. hier nur über Kerberos möglich. Aber ich bin kein NFS-Spezialist und lasse mich gerne eines Besseren belehren.
|