LDAP: Unterschied zwischen den Versionen

aus Metalab Wiki, dem offenen Zentrum für meta-disziplinäre Magier und technisch-kreative Enthusiasten.
Zur Navigation springenZur Suche springen
 
(3 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt)
Zeile 1: Zeile 1:
Hier muss man zwischen zwei LDAP Systemen trennen:
+
Hier muss man zwischen zwei LDAP Systemen unterscheiden:
  
Zum einen gibt es den internen LDAP Server der dazu verwendet wird Benutzeraccounts und Berechtigungen für interne Workstations, Server, Terminal Server und Fileserver, etc. zu halten.
+
== Metalab interne Systeme ==
 +
Zum einen gibt es den internen LDAP Server der dazu verwendet wird Benutzeraccounts und Berechtigungen für interne Workstations, Server, Terminal Server und Fileserver, etc. zu halten. Hier ist nicht geplant ein grossartiges Benutzerprofil zu speichern sondern möglichst nur was wirklich benötigt wird um alle internen Rechner mit einer Benutzerdatenbank zu versorgen.
  
 +
== MOS Verwaltungsteil ==
 
Zum anderen gibt es optional, falls eines unserer externen Services dies benötigt, einen slapd-sql [http://www.die.net/doc/linux/man/man5/slapd-sql.5.html man page] der lesenden Zugriff auf die [[Metalab OS]] Benutzerdaten bietet.
 
Zum anderen gibt es optional, falls eines unserer externen Services dies benötigt, einen slapd-sql [http://www.die.net/doc/linux/man/man5/slapd-sql.5.html man page] der lesenden Zugriff auf die [[Metalab OS]] Benutzerdaten bietet.
  
Den SQL basierenden LDAP Server kann man eventuell auch ganz weglassen, wenn die [[MOS Benutzerverwaltung]] ersteren LDAP Server als Quelle der Benutzerdaten verwendet. Da dafür aber in den Innereien von Django herumgebastelt werden muss wird es vorerst wahrscheinlich keine vollständige Integration geben.
+
Wenn die [[MOS Benutzerverwaltung]] ersteren LDAP Server als Quelle der Benutzerdaten verwendet kann man sich den zweiten LDAP Server sparen und einfach ein Replikat des internen LDAPs verwenden. Da dafür aber in den Innereien von Django herumgebastelt werden muss wird es vorerst wahrscheinlich keine vollständige Integration geben.
  
Und um weitere Diskussionen zu vermeiden, hier noch mal der Grund warum SQL als volles Backend für einen LDAP Server keine gute Idee ist und anscheinend auch nicht vollständig implementiert wurde [http://www.openldap.org/faq/data/cache/378.html].
+
== Könnte man denn nicht die Datenbank als Backend für unser internes LDAP nehmen? ==
 +
'''Nein, kann man nicht.'''
  
[[Kategorie:Metalab OS]]
+
Und um weitere Diskussionen zu vermeiden, hier auch der Verweis zum Grund warum eine relationale Datenbank als volles Backend für einen LDAP Server keine gute Idee ist und anscheinend auch nicht vollständig implementiert wurde [http://www.openldap.org/faq/data/cache/378.html].
[[Kategorie:Server]]
+
 
 +
[[Kategorie:Metalab_OS]]
 +
[[Kategorie:Netzwerk]]

Aktuelle Version vom 27. Januar 2013, 00:46 Uhr

Hier muss man zwischen zwei LDAP Systemen unterscheiden:

Metalab interne Systeme

Zum einen gibt es den internen LDAP Server der dazu verwendet wird Benutzeraccounts und Berechtigungen für interne Workstations, Server, Terminal Server und Fileserver, etc. zu halten. Hier ist nicht geplant ein grossartiges Benutzerprofil zu speichern sondern möglichst nur was wirklich benötigt wird um alle internen Rechner mit einer Benutzerdatenbank zu versorgen.

MOS Verwaltungsteil

Zum anderen gibt es optional, falls eines unserer externen Services dies benötigt, einen slapd-sql man page der lesenden Zugriff auf die Metalab OS Benutzerdaten bietet.

Wenn die MOS Benutzerverwaltung ersteren LDAP Server als Quelle der Benutzerdaten verwendet kann man sich den zweiten LDAP Server sparen und einfach ein Replikat des internen LDAPs verwenden. Da dafür aber in den Innereien von Django herumgebastelt werden muss wird es vorerst wahrscheinlich keine vollständige Integration geben.

Könnte man denn nicht die Datenbank als Backend für unser internes LDAP nehmen?

Nein, kann man nicht.

Und um weitere Diskussionen zu vermeiden, hier auch der Verweis zum Grund warum eine relationale Datenbank als volles Backend für einen LDAP Server keine gute Idee ist und anscheinend auch nicht vollständig implementiert wurde [1].