Re: Debian als Client an Samba-Domäne
Hallo,
Am 05.08.2011 18:25, schrieb Rico Koerner:
Am 05.08.2011 10:28, schrieb Hans-Dietrich Kirmse:
Hallo Rico,
Am 04.08.2011 19:51, schrieb Rico Koerner:
Am 04.08.2011 14:42, schrieb Hans-Dietrich Kirmse:
Die Fehlermeldungen kamen durch irgendwelche udev-Regeln, die nicht
erfüllt waren.
Ich kann mir nur schwer vorstellen, daß das etwas mit LDAP zu tun hatte.
Es müssen die Systemgruppen nvram, rdma, kvm, fuse, scanner und tss
angelegt werden, außerdem der Systemuser tss in der Gruppe tss. Es ist
dann so, dass dadurch diese Boot-Probleme mit dem LDAP weg sind -
definitiv.
Systemgruppen würde ich prinzipiell nicht ins LDAP stopfen und die
sollten bei der Installation der davon abhängigen Pakete auch in
/etc/group bzw. /etc/passwd angelegt werden. Diese Quellen sind ja
weiterhin verwendbar.
Ich kann da immer noch keinen direkten Zusammenhang erkennen, ist wohl
eher ein Seiteneffekt. Würde mich aber mal interessieren wie das
zustande kommt.
die Mail mit der Erklärung, wie unser Mitstreiter das gefunden hat,
leite ich dir per PM weiter. Da steht auch (sogar für mich
nachvollziehbar), wie das zustandekommt.
Damit sich der Client dann direkt am LDAP übers Netz anmelden darf, muß
dies natürlich dafür freigegeben werden, wo der Sambaserver sonst nur
per localhost bzw. Socket darauf zugreift. Das betrifft aber eher die
Interface-Einstellung des LDAP-Servers und/oder die Firewall, an den
ACLs muß dazu nichts geändert werden.
Verstehe ich das richtig, dass dann auf dem Server in der ldap.conf,
libnss-ldap.conf und pam_ldap.conf (eine slapd.conf haben wir nicht
mehr) dann nicht mehr 'localhost' bzw. '127.0.0.1' stehen sollten?
Die libnss-ldap.conf und pam_ldap.conf auf dem Server bleiben unberührt.
Das ist doch schonmal gut.
Auf dem Client muß an dieser Stelle die IP des LDAP-Servers stehen.
Okay.
Die
wird aber schon bei der Installation der Pakete abgefragt werden. Es
geht auch der Rechnername, aber das würde ich in dem Falle nicht tun.
Dann muß auf die Namensauflösung gewartet werden, was schlimmstenfalls
für ein hängendes System sorgt.
Wenn du keine slapd.conf hast, ist ein Online-Konfiguration vorhanden
(olc). Dann sollte ein Verzeichnis slapd.d existieren. Die OLC kannst du
wieder per LDAP abfragen/manipulieren. Die Dateien im
slapd.d-Verzeichnis können im Notfall bei abgeschalteten slapd verändert
werden.
Das ist aber nicht Sinn und Zweck der OLC. ;-) Dort würde ich max.
olcRootDN und olcRootPW eintragen, falls der Zugang dazu fehlt.
Der Rest dann online über ein Admintool oder Kommandozeile.
dieser OLC-Zweig wurde nicht von mir eingerichtet, sondern genau von
dem, der diese Fehlermeldungen beseitigt hat. Ansonsten ist die
Einrichtung des LDAPs auf meinen Mist gewachsen. Für die Konfiguration
unseres LDAPs haben wir (wie für die anderen Dienste auch) ein eigenes
Paket erstellt, das "nichts weiter" machen, als über das postinst-Script
den Dienst (hier den LDAP) zu konfigurieren.
Du kannst dir dieses Script gern anschauen:
http://dev.delixs.de/wsvn/delixs/delixs-ldap/trunk/debian/postinst
Anm.: das Anlegen der Gruppen geschieht in der Subroutine
'workaround_groups'.
:
Ich hab mir den Quelltext selbst nicht angeschaut, schon gar nicht unter
verschiedenen Systemen. Alle Eventualitäten abzufangen ist einfach
unmöglich.
Als ich angefangen habe, mich mit dem Thema zu beschäftigen, sah es etwa
so aus. Die Konfigurationen verschiedener Tools benutzen die OUs
"computers", "hosts" oder "machines" für Computer. Dabei war unklar, ob
alle Tools mit allen Varianten umgehen können. (Nicht nur die
smbldaptools, es gibt ja noch weitere Systeme.)
richtig, es gibt u.a. auch die LDAPScripts siehe unter
http://sourceforge.net/projects/ldapscripts/
m.E. hast du und Martin hier bzw. gerade wegen dieser etwas ungüngstigen
Bezeichnung aneinander vorbeigeredet. Mir sind auch noch weitere
bekannt, aber da ich kein Shellscripting kann, nur ein klein wenig Perl,
da waren mir die smbldap-Tools doppelt sympatisch ;)
Die Dokumentationen,
Howtos und Suchmaschinen machten mich auch nicht schlauer.
Unabhängig davon kann ich einen User mit DN uid=User,* oder cn=User,*
anlegen, beides vollkommen korrekt für LDAP, auch dazu nichts dokumentiert.
Für unseren Schulserver habe ich eine Zusammenfassung erstellt:
http://www.delixs.th.schule.de/alpha18/userverwaltung.txt
:
Wenn man nur auf einem OS mit einem Tool und einem Dienst arbeitet, sind
kaum Probleme zu erwarten. Wenn man aber dort noch andere Dienste mit
anderen Tools verwaltet, *kann* es sein, daß eben nicht alles
*kompatibel* zueinander ist.
Für einen Schulserver braucht man schon komfortablere Tools der
Userverwaltung (z.B. klassenweise User anlegen, versetzen und löschen).
Deswegen werden alle Scripte für die Userverwaltung bei uns selbst
geschrieben, aber diese sind dann trotzdem kompatibel mit diesen
smbldap-Tools. Anders gesagt, wenn einer um Hilfe gebeten wird und kennt
nicht unsere Scripte, dafür aber die smbldap-Tools, dann kann er damit
dasselbe erreichen (siehe oben den Link)
:
Die Frage nach Bilderbüchern hört sich manchmal nach Lernresistenz an.
Deine Reaktion zeigt, daß das bei dir nicht der Fall ist. ;-)
es geht doch nicht nur um den Server, den ich an meiner Schule betreue,
sondern ich versuche das Projekt zu unterstützen, was einen Nachfolger
von diesen Arktur4 baut - allerdings auf Debian-Basis. Aber für die
zukünftigen Anwender soll natürlich die Bedienung so einfach sein wie
von Arktur (hier ist Debian kein Vorbild) und die Doku soll eben so
verständlich und vollständig sein => "Bilderbuch" mit Text.
Bin nicht ganz so alt, aber mit Englisch auch nicht so bewandert, kann
ich dich verstehen. Über die mangelnde Doku hab ich mich ja oben schon
ausgelassen.
bei uns wird beim Anmelden an der Domäne dem User 4 Laufwerke zur
Verfügung gestellt:
Laufwerk u: Homeverzeichnis /home/<gruppe>/<user>
Laufwerk t: Tauschverzeichnis /home/all
Laufwerk r: Gruppenverzeichnis (Klassen) /home/groups
Laufwerk p: Programme (serverbasiert) /home/software
Das läßt sich mit nfsmount für /home ganz pauschal lösen. Ggf. sind die
Rechte auf Linuxebene nochmal zu kontrollieren/korrigieren.
Auf dem Server passt diesbezüglich schon alles, zumindest kann das hier
angenommen werden. Dazu haben wir 2 Pakete, die Samba einrichten. (im
SVN 'delixs-samba-base' und 'delixs-samba-school')
1. Homeverzeichnis hängt davon ab, ob im LDAP jeder Benutzer eine eigene
primäre Gruppe hat und in den anderen Gruppen nur zusätzlich aufgenommen
wird. Dann paßt hier ein chmod 770 auf sein Verzeichnis.
Sind dagegen gemeinsame Gruppen wie "users" als primäre Gruppe
zugeordnet, sollte hier eher 700 verwendet werden.
2. Tauschverzeichnis: chmod 777
falls eine gemeinsamme Gruppe existiert, reicht auch 770 und chgrp.
3. Gruppenverzeichnis: Ich gehe mal davon aus, daß unterhalb von
/home/groups Verzeichnisse für die jeweiligen Gruppen liegen. Dafür:
chmod 2770 (sgid-Bit setzen), chgrp $gruppe
4. ich vermute mal es gehört dem Admin und ist readonly für alle
verfügbar, also chmod 755
Das ist alles kein Thema, sondern ist wie schon angegeben m.E. bis ins
Detail ausklamüsert - aber bis jetzt nur für Windows. Mal ein Beispiel:
im Laufwerk r: (/home/groups) wird für jede Klasse (automatisch) ein
Verzeichnis erstellt, dass nur die Schüler dieser Klasse sehen können.
Das bedeutet, jede Klasse hat ihr Verzeichnis, aber es ist trotzdem für
die Schüler sehr übersichtlich, weil der Schüler die anderen Klassen
nicht sieht, sondern nur seine Klasse. Zusätzlich gibt es noch ein
Verzeichnis, wo die Lehrer Materialien bereitstellen (für die Schüler
schreibgeschützt). Das die Lehrer auch auf die Schülerverzeichnisse
zugreifen können, wird über ACLs geregelt. Noch nicht implementiert:
Projekte. Wenn der Schüler dann z.B. in 3 Projekten ist, dann sieht er
in diesem Laufwerk (Share) genau 5 (Unter-)Verzeichnisse. Auch für die
anderen Laufwerke haben wir uns so intensive Gedanken gemacht. - und das
ist auch so umgesetzt. Die Konfiguration läuft "vollautomatisch", aber
das betrifft nur den Server!
zusätzlich gibt es weitere Shares, auf die aber nur über die
Netzwerkumgebung zugegriffen werden kann.
Die könnten dann immer noch per smbmount eingebunden werden oder
ebenfalls als NFS-Freigaben existieren.
und wie richtet man das als Admin ein, dass der User, egal ob Schüler
oder Lehrer, diese (und möglichst nur diese) Laufwerke / Verzeichnisse
zur Verfügung hat?
In Hinblick darauf, dass die User an den Linux-Clients nicht schlechter
gestellt sein sollten als an Windows-Clients und in einer vorherigen
Mail geschrieben wurde, dass die Nutzung von Samba nicht das Gelbe von
Ei sei, stellt sich für mich schon die Frage, wie wird sowas dann
linuxtypisch gelöst? Und ich habe dazu recherchiert - leider nichts
gefunden und konnte deshalb dazu nichts lesen und auch nichts verstehen.
Was heißt nicht schlechter gestellt? Was wird an den WinClients benutzt?
siehe weiter oben. Ich hatte zu den Laufwerken unter Windows die
Verzeichnisse angegeben, die müssen irgendwie für die User zur Verfügung
gestellt werden. Für einen Schüler 'mmustermann' sieht die
Netzwerkumgebung unter Windows so aus, wie auf dem letzten Bild von
dieser Seite dargestellt:
http://www.delixs.de/dwiki/index.php/Delixs10:winxp
Darunter ist angegeben, was die Shares bedeuten.
Was nicht sein kann: von einem Schüler bei uns ab Klasse 5 (Medienkunde)
kann nicht erwartet werden, das er irgendetwas mountet. Und es kann auch
nicht erwartet werden, das /home bereitgetellt wird und er soll sich in
dieser Ordnerstruktur die entsprechenden Verzeichnisse heraussuchen. -
bei Windows wird das beim Anmelden durch die logon.bat ja automatisch
gemacht.
Und es kommt nochetwas hinzu: wir haben 15 WinXP- und 15
Windows7-Clients. Schon da ist es so, dass die Schüler ebenso wie die
Lehrer viel lieber in das Kabinett mit den Windows7-Clients gehen, ist
einfach attraktiver. Wenn jetzt Linux-Clients bereitgestellt werden,
dann sollen die kein Schattendasein fristen, nur weil Windows leichter
zu händeln und attraktiver ist, von möglichen Umstellungsproblemen mal
ganz zu schweigen.
Nochmal: ich bin selbst ein Linux-Laie (schreibe diese Mail auch unter
Windows), aber ich wurde darum gebeten, einen Linux-Client zu erstellen,
genauer: an den Server anzubinden und das muss für die User mindestens
genauso einfach zu nutzen sein wie unsere Windows-Clients.
Ich denke mal, es geht um die Anmeldung an sich, um die
Laufwerksfreigaben und evtl. um Druckdienste. Die ersten beiden Punkte
haben wir ja jetzt abgearbeitet.
nö. aus meiner Sicht ist genau die Bereitstellung dieser "Laufwerke"
eben nicht klar. Mit Samba würde ich ja zumindest eine Lösung
sehen/vermuten - aber das wurde so gewertet: "lässt einem fast die
Nackenhaare hochstehen". " Aber wie macht man das wie hier vorgeschlagen
mit LDAP/PAM und NFS? Das ist immernoch völlig unklar.
Für den Druckservice wäre CUPS nötig, bei einem Netzwerkdrucker ist die
Authorisierung unwichtig, falls kein Accounting benötigt wird. D.h. CUPS
wird unabhängig vom Rest auf dem Client für den Drucker installiert.
Ansonsten mußt du dich hierzu nochmal etwas genauer äußern.
Werden weitere Dienste benutzt? Evtl. ein Proxy mit Anmeldung?
Webserver?
klar haben wir einen Apache, jeder Schüler hat ein
html_public-Verzeichnis, wir haben einen Squid mit Squidguard und mit
Anmeldezwang (am LDAP). Und wir haben auch einen Mailserver (Postfix und
Dovecot) und einen Webmailer (Roundcube). Auch das wird alles durch
eigene Pakete automatisch eingerichtet. Allerdings einen CUPS haben wir
nicht - noch nichtmal eine Anleitung. :(
wegen dem Apache und dem Squid: unter Windows nutzen wir vor allem
Mozilla Firefox. Dieser wird für alle User über den
autoconfig-Mechanismus konfiguriert. Das sollte auch für den Firefox
unter Linux so gehen und damit sind weder der Apache, Squid noch Mail
(wegen Roundcube) ein Problem für mich.
Aber wie der Zugriff auf den Fileserver eingerichtet wird (oder anders
gesagt, die Laufwerke simuliert werden können), das ist mir als Einziges
noch nicht klar bzw. habe noch nichtmal einen Ansatz.
Wäre für weitere Ideen und Hinweise dankbar.
Viele Grüße
Hans-Dietrich
Reply to: