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.
>> 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.
Auf dem Client muß an dieser Stelle die IP des LDAP-Servers stehen. 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.
>>> die Anleitung für Debian/Ubuntu ist nicht passend, weil die Probleme,
>>> die dieser Server an dieser Stelle hat, bei uns einfach nicht relevant
>>> sind. Die UIDs der User (im LDAP) fangen bei uns erst bei 10000 an, die
>>> GIDs ab 1000.
>>>
> Mir geht es nicht darum, die nicht mehr gepflegte Doku des seit Jahren
> nicht mehr betreuten Schulservers Arktur4 hier zu kritisieren oder zu
> verbessern. Aber m.E. hat genau diese Doku bzw. diese Seite(n) das
> beschrieben, wodurch ich einen Zugang zu meinem Anliegen finden konnte.
"Nicht passend" klang hier wie "nicht verwendbar". Aber diese Problem
haben sich ja auf magische Weise bei Debian selbst gelöst. ;-)
Der Denkansatz, die Gruppen/User in der group/passwd zu korrigieren war
etwas merkwürdig. Besser ist die Anhebung der Untergrenze im LDAP, wie
sie auch bei dir schon realisiert ist.
>>> wir verwalten im LDAP nur die User, Gruppen, Rechner und die festen IPs
>>> (also DHCP). Die User, Gruppen und Rechner werden bei uns so angelegt,
>>> wie es die smbldap-Tools machen (würden), allerdings wurden ein paar
>>> Kleinigkeiten von smbldap-populate korrigiert und der root-Account in
>>> 'Administrator' umbenannt. Aber ansonsten alles kompatibel zu den
>>> smbldap-Tools.
>>
>> Kompatibel wozu?
>
> wie ich geschrieben habe: kompatibel zu den smbldap-tools.
>
>> Hier scheint es keinen Standard zu geben. Ich habe mir
>> dazu verschiedene Admin-Tools angeschaut und festgestellt, daß jedes die
>> Daten etwas anders ablegt. Es mögen die smbldaptools auf der jeweiligen
>> Distri damit klarkommen, das stellt aber noch nicht sicher, daß das
>> distributionsübergreifend auch funktioniert.
>
> Da bin ich mir aber sehr sicher. Wenn der LDAP-Baum über die
> smbldap-Tools aufgebaut wird (smbldap-populate), dann kann man diesen
> auch mit den smbldap-Tools verwalten, egal ob auf Debian, SuSE, Solaris
> oder was auch immer. Und wenn man sich mal den Quelltext dieser Tools
> anschaut, dann wird deutlich, dass da praktisch alle Möglichkeiten und
> Eventualitäten erfasst werden.
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.) 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.
smbldap-populate, Zeile 199:
$entries.="\ndn: uid=$adminName,$config{usersdn}
würde diese Eventualität nicht berücksichtigen.
Wenn man verstehen will was die so treiben, wirds schwierig.
Ich sage nicht, daß das Tool den Fehler macht, er kann auch von einem
anderen Tool oder gar von mir selbst stammen. Genauso wenig kann ich
sicher sein, daß sich alle Tools in allen Versionen auf allen OS an die
nicht beschriebene Regel DN: uid=* halten. Genauso wie die nicht
beschriebene Regel der GroupID-Ranges.
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.
>> (Was aber nicht heißt, daß es grundsätzlich nicht funktioniert.)
>
> warum nur grundsätzlich?
Soll heißen, daß nicht alles schiefgehen muß was schiefgehen kann.
> es war ja nur eine Wunschvorstellung. Ich habe selbst keine Angst for
> einem Editor, sofern ich weiss, was man ändern muss - oder anders
> gesagt, sofern ich eine (deutschsprachige) Anleitung habe.
>
>> Für den Rest mußt du etwas lesen und ein wenig verstehen.
>
> Man kann ja nur etwas lesen, wenn es etwas zu lesen gibt. Und da ich
> kein Englisch spreche (das tue ich mir mit weit über 50 Jahren auch
> nicht mehr an), frage ich in dieser deutschsprachigen Liste nach.
Die Frage nach Bilderbüchern hört sich manchmal nach Lernresistenz an.
Deine Reaktion zeigt, daß das bei dir nicht der Fall ist. ;-)
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.
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
> 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.
> 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?
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.
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?
> Würde mich über weitere Antworten freuen.
Gern. :-)
Gruß
Rico
Attachment:
smime.p7s
Description: S/MIME Kryptografische Unterschrift