Hallo, Robert <pct1004@roottec.com> writes:
Hallo Dieter,
nachdem ich mich nun durch diverse Dokumente gelesen habe komme ich nun auf Dein Angebot mit den weiteren Fragen zurück...
Dieter Kluenter wrote:
Robert <pct1004@roottec.com> writes:
[...]
Im Internet wirst du keine altuelle Beschreibung eines kompletten Lösungsansatzes finden, wohl aber einige wenige Teillösungen. Um auf dem aktuellen Stand zu sein benötigst du Cyrus-SASL-2.1.20 BerkeleyDB-4.3.21 Heimdal Kerberos-0.6 oder MIT KRB5-1.3.1 OpenLDAP-2.2.19 (verfügbar in den nächsten Tagen) OpenSSL-0.9.7 Samba-3.x Als Start sieh dir mal meine Signatur an. Wenn du dir dann selbst bewußt bist, was du wirklich realisieren möchtest, dann frage noch einmal.
Also was ich bauen möchte ist: a) SSO für die lokale Benutzerverwaltung, Samba & SSH später ... na wir werden sehen.
Single Sign On in der Reinkultur wird es noch nicht geben, auch ein Single Point of Administration ist noch Zukunftsmusik, da es immer noch Anwendungen gibt, die eine eigene Benutzerverwaltung betreiben, z.B. Cups, Postgresql usw.. Aber durch geschickte Kombination der Authentifizierungssysteme kannst du die Anzahl der täglichen Authentifizierungsprozesse drastisch reduzieren, insbesondere X.509 Zertifikate und GSSAPI erbringen in meinem lokalen Netzwerk ca. 80% aller Authentifizierungen.
b) soll ich alle SuSE Pakete am Besten rauswerfen und durch die aktuellen von Pacman ersetzen?
Nein, nicht alle SuSE-Pakete, sonst wirst du Probleme bekommen. Aber eine aktuelle Version von BerkeleyDB würde ich selbst kompilieren und zusätzlich parallel installieren, dazu dann noch OPenLDAP-2.2.19. OpenLDAP benötigt mindesten Cyrus-SASL-2.1.16, da solltest du dein System prüfen.
Zudem: gibt es immer noch gewisse Verständnisproblem bei einigen Dingen. So z.B.:
c) bdb: Das ist ja doch auch eine vollwertige und - soweit ich es verstand - äußerst effiziente Datenbank. Warum also noch eine externe SQL-Engine in Form von MySQL oder Postgress? Was bringt das für Vorteile? Entwicklerseitig: Weniger native Treiber?... oder warum?
Das hängt davon ab. was du machen möchtest. BerkeleyDB ist ein Database Management System, aber kein RDBM. MySQL z.B. benutzt BerkeleyDB als storage backend, in deinem Handy wird mit großer Wahrscheinlichkeit BerkeleyDB dein Adressbuch verwalten, aber nicht als SQL RDBM, sondern als schlichte Hash Tabelle. SQL ist eine sehr performante Sprache um aus einzelnen Elementen ein Objekt zu erstellen, aber die einzelnen Elemente müssen auch verwaltet und sehr schnell bereitgestellt werden. OPenLDAP, als hierarchisch strukturierte Objektdatenbank, benutzt BerkeleyDB ebenfalls als storage backend.
d) während meiner Suche und Leserei ich hab das hier gefunden: http://samba.mirror.aarnet.edu.au/samba/docs/man/Samba-HOWTO-Collection/pass... ab der Passage "OpenLDAP Configuration To include support for the sambaSamAccount object..." findet sich eine recht detailierte Beschreibung für die Einbindung von Samba in OpenLDAP. Ist das Originalschema /etc/openldap/schema/samba3.schema das mit der SuSE ok?
Soweit ich weiß, ja
e) Was ich mich jetzt zudem frage ist, wie sich das nun mit der lokalen Benutzerverwaltung verhält?
Zum Einen: Wie binde ich die lokale Benutzerverwaltung an LDAP und dann noch wichtiger:
Dies ist die Aufgabe von PAM und den entsprechenden Modulen ldap_nsswitch und pam_ldap
Wenn die verbunden sind wie wird die Benutzerverwaltung erreicht? Per YAST danach sicher nicht mehr -richtig? Die LDAP Manipulation per ldif ist eigentlich nicht so 'ganz' das, was ich mir da vorstelle. Was empfiehlst Du dafür?
Die Anwenderverwaltung wird nach wie vor über Yast erfolgen, libpam schreibt dann nur nicht mehr in /etc/passwd sondern benutzt das Modul pam_ldap
Ach so bevor ich es vergesse: Es handelt sich nicht um eine Rieseninstallation, sondern primär um eine Testinstallation an der ich lernen kann.
Das ist OK, ob ein einzelner Anwender oder viele tausend Anwender, die administrativen Schritte bleiben gleich. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:01443B53