Hallo Klaus, Klaus <[EMAIL PROTECTED]> wrote: > Joerg Sommer escribió: >> >>> Ich habe jetzt überlegt, ob die nis-Ersatzprogramme auch auf dem Server >>> statt der Originale eingesetzt werden sollten, aber ich glaube da habe >>> ich dummes Zeug gedacht! >> >> Das sind doch zwei Paar Schuhe. Der Server hat doch nichts mit den >> Clients zu tun. Sollen sich denn deine Benutzer auch auf dem Server >> einloggen können? >> > Hmm, jetzt bringst Du mich aber ins Grübeln! Die /home liegen ja alle > auf dem Server und werden per nfs an die Clients exportiert. Indirekt > sind ja dann alle user am Server eingeloggt, oder?
Nein. NFS ist ein reiner Verteildienst. Der Admin des Clients ist auf dem Server "eingeloggt" -- nein, das stimmt so auch nicht --, er greift vielmehr auf irgendwelche Resourcen zu und so abstrakt gesehen ist es nichtmal root. Das ist so als ob sich jemand mit einem Browser deine Webseiten ansieht. > Theoretisch könnten sie sich dann auch am Server per ssh einloggen. Ist > das denn ein Risiko? Ich habe ssh für das ganze lokale Netz > freigegeben. Keine Ahnung. Natürlich kann es sinnvoll sein, dass ein zentraler Rechner existiert. Aber der zentrale Rechner muss da nicht gleich dem Fileserver sein. Das sind zwei Paar Schuhe, die du auch trennen kann. Bei uns an der Uni wird das z. B. so gemacht. Wenn du keinen Grund für den zentralen Server hast, dann würde ich ihn auch nicht anbieten. Das ist meine _persönliche_ Meinung. >>> Die Übernahme der Passwörter aus /etc/passwd nach /var/yp muss ja >>> sowieso durch ein make angestossen werden. >> >> Ich würde die beiden Dinge trennen. In der passwd auf dem Server würde >> ich nur die lokalen Accounts aufführen. Die Accounts, die per NIS über >> das Netz verwaltet werden sollen, stehen dann auch nur in /var/... >> > Das verstehe ich jetzt nicht so ganz. Ich erstelle die User doch am > Server mit passwd, und zwar alle. Die Clients haben keine eigenen User. Du vermischt da etwas. Die Bits und Bytes werden nur aufgrund ihrer Interpretation zu Benutzernamen und Passwörtern. So gesehen, sind es einfach nur Bits und Bytes. Und diese können eben über irgendeinen Dienst im Netz verbreitet werden -- das könnte z. B. auch eine Datenbank mit SQL-Interface sein. Anbieten tut sich für diese Aufgabe natürlich NIS. NIS ist also nichts anderes, als ein Dienst, der Bits und Bytes durchs Netz schickt, die Clients dann zu Benutzern und Passwörtern machen bzw. die als diese gekennzeichnet sind. Eine Zeichenkette ist also nicht ein Benutzername, weil sie auf dem Server in der /etc/passwd steht, sondern weil NIS sie als diesen verteilt/kennzeichnet. Und NIS verwaltet seine Daten getrennt von der /etc/passwd in /var/... Das was du also in /etc/passwd auf dem Server einträgst, hat erstmal nichts mit NIS und den Clients zu tun. Dem Benutzerverwaltungssystem für die Anmeldung kannst du aber verschiedene Quellen für Benutzerinformatio- nen zuordnen. Eine ist eben /etc/passwd, eine andere wäre Kerberos, NIS, LDAP, RADIUS, MySQL oder eine schöne Textdatei. Die Informationen, die der Client über den Dienst abfragt, liegen in einer für den Dienst speziellen Datenbank, die sich in der Regel unter /var/... auf dem Server für den Dienst befindet. In einer großen Umgebung würdest du diese Server wahrscheinlich auch technisch Trennen: also einen Rechner für die Accountverwaltung und einen Rechner für NFS. Ist dir die Sache etwas klarer geworden? > Änderungen der Passwörter können die User an den Clients per passwd > (ersetzt durch yppasswd) durchführen. Passwortänderung bedeutet nichts anderes, als dass das lokale Benutzerverwaltungssystem dem Dienst sagt: "Trage das jetzt an die Stelle in die Datenbank ein." > Das funktioniert so weit (abgesehen von Samba, das die Änderung nicht > mitkriegt). Schau die mal PAM /usr/share/doc/libpam-doc/txt/pam.txt.gz an. Damit ist es auch möglich, dass das normale passwd-Programm die Änderungen in eine andere Datenbank schreibt (über einen anderen Dienst ändern lässt) -- genauso wie login die Informationen auch aus einem anderen Dienst holen kann. > So ganz durchschaue ich das noch nicht (s.o.), aber offensichtlich ist > es einfacher, die ganze Angelegenheit nicht mit NIS sondern mit ldap zu > machen. Wollte mir das wegen der etwas aufwendigeren Konfiguration > eigentlich sparen, aber wenn ich vergleiche stelle ich fest, dass auch > NIS im Zusammenspiel mit Samba einigen Aufwand verursacht. Nochmal drei Schritte zurück: Wenn du schon über Samba deine Accounts mit verwaltest, warum verwendest du dann nicht gleich Samba? Habe ich dich irgendwie falsch verstanden? > Vielleicht kannst Du mir dazu einige Tipps geben, vor allem interessiert > mich in diesem Zusammenhang eine problemlose Migration der schon > angelegten Accounts inklusive der Passwörter. Wo sind die Passwörter und wo soll es nochmal hingehen? Schöne Grüße, Jörg. -- - StGB §§ 328 Absatz 2, Nr.3 : Mit Freiheitsstrafe bis zu fünf Jahren oder mit Geldstrafe wird bestraft, wer eine nukleare Explosion verursacht. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject "unsubscribe". Probleme? Mail an [EMAIL PROTECTED] (engl)
