Seite wählen

NETWAYS Blog

Openldap Schema Erweiterung cn=config

von | Aug 26, 2011 |

In dem Artikel wurde beschrieben welche Neuerungen in OpenLDAP 2.4 enthalten sind.
In diesem Artikel möchte ich kurz darauf eingehen wie man das Schema mit dem cn=config Konfigurationsbackend erweitern kann.
Um neue Schema einzubinden müssen zunächst alle vorhanden inkl. dem neuen Schema in ein LDAP Format exportiert werden.
1. Eine schema_convert.conf erstellen mit dem Inhalt aller vorhandenen Schema:

include /etc/ldap/schema/core.schema
include /etc/ldap/schema/corba.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/misc.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/openldap.schema
include /etc/ldap/schema/netways.schema

Wichtig: Das neue Schema (in diesem Fall netways.schema) muss unter /etc/openldap/schema liegen.
2. Schema an einen temporären Ort exportieren:

# mkdir /tmp/ldapexport
# slaptest -f schema_convert.conf -F /tmp/ldapexport

3. Editieren der Datei /tmp/ldapexport/cn=config/cn=schema/cn={8}netways.ldif und folgende Attribute abändern:

dn: cn=netways,cn=schema,cn=config
...
cn: netways

Folgende Zeilen am Ende der Datei entfernen:

structuralObjectClass: olcSchemaConfig
entryUUID: 10dae0ea-0760-102d-80d3-f9366b7f7757
creatorsName: cn=config
createTimestamp: 20080826021140Z
entryCSN: 20080826021140.791425Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20080826021140Z

4. Abschließend muss das erweiterte Schema mit ldapadd wieder importiert weden.

# ldapadd -x -D cn=admin,cn=config -f /tmp/ldapexport/cn=config/cn=schema/cn={8}netways.ldif

In unserem LDAP Backend (cn=config) sollte nun die DN: cn={8}netways,cn=schema,cn=config auftauchen.
Anmerkung:
Der Name {8}netways kann variieren.
Mit folgendem Befehl kann der korrekte Name herausgefunden werden:

slapcat -f schema_convert.conf -F /tmp/ldapexport -n 0 | grep netways

Weekly Snap: MySQL, Puppet & OpenLDAP tricks

von | Mai 23, 2011 |

16 – 20 May was filled with tips and tricks for MySQL, Puppet, OpenLDAP and thoughts on social networking usage.
To begin, Bernd discussed the MySQL concurrent read/write function. Unlike InnoDB which supports real ACID transaction administration, MyISAM nonetheless enables concurrent reading/writing. For this he recommends the concurrent_insert parameter which controls simultaneous access to a table, alongside the regular use of ‘optimise table’. Unfortunately, this may no longer work if the writing is activated by Binlogs as the database engine is “forced” into following the correct serial order to maintain its uniqueness in the Binlog.
Continuing on the topic of MySQL, Gunnar offered his tip to accelerate test imports. With the libeatmydata library, the fsync() function can be deactivated for certain applications. But he cautioned that it can lead to data loss and irreparable database damage when inappropriately implemented.
From databases to their directory services, Philip looked at OpenLDAP. He considered the purpose of directory services and the current version OpenLDAP 2.4 in terms of performance and functionality. Of note were two new features which enable greater replication: MirrorMode distributes LDAP servers across two locations, and enables data replication via two providers, while N-Way Multimaster allows the replication of multiple active masters, which can be combined in any number of ways and in turn possess slave servers.
Manuela shared the results of a study into the European use of email, Facebook, Twitter and other social media. She noted that 50% of all Europeans use both email and social networks, with Facebook the undisputed leader (Hyves in Holland being the exception). Also dubbed “multi-channel countries”, company fan pages are best received in Great Britain, Italy and Spain. In contrast, Germany, France and Holland tend more towards being“email countries”. The study includes consumer and decision maker surveys, and can be found at eCircle.
Finally, Christoph showed us how SSH key administration can be done with Puppet in 3 steps. First by creating an SSH class, then SSH keys for root registration and lastly SSH keys for user registration.

OpenLDAP – Flaggschiff unter den OpenSource Verzeichnisdiensten

von | Mai 18, 2011 | , , ,

Ein Verzeichnisdienst gehört zu den Grundbausteinen jeder IT-Infrastruktur und dabei ist es ganz egal ob es sich um 20 oder 2000 Anwender im Unternehmen handelt.
Sinn und zweck von Verzeichnisdiensten
In der Regel dient er als hierarchische angeordnete Ablage zur zentralen Speicherung von Benutzerdaten, der Gruppenverwaltung, dem Rechtemanagement oder dem bereitstellen von Applikationen.
Meist liegt dieser Datensammlung eine Datenbank zu Grunde welche die Informationen speichert und über verschiedene Netzwerkprotokolle (DAP, LDAP, LDAPS, Kerberos, NCP etc.) zur Verfügung stellt. Weil es in der Datenbank selten große Schreibvorgänge gibt ist sie dahingehend optimiert beim reinen Lesezugriff schnell zu antworten.
LConf nutzt diese Funktionalität ebenfalls, dient aber nicht zum speichern von Benutzerdaten sondern, dank eines angepassten Schemas, zum speichern der Nagios- oder Icingakonfigurationsdaten. Durch die hierachische Vererbung von Objekten lassen sich so schnell eigene und effiziente Strukturen aufbauen.
OpenLDAP ist DER Verzeichnisdienst unter den OpenSource Verzeichnisdiensten und muss sich schon lange nicht mehr hinter propertären Lösungen wie ActiveDirectory (Microsoft) oder eDirectory (Novell) verstecken. Auch eine möglicher Einsatz als Metadirecotry Server ist möglich. In einem solchen Szenario würden Identitätsdaten mittels verschiedener Konnektoren zu anderen Verzeichsdiensten repliziert bzw. synchronisiert.
Das OpenLDAP Projekt gibt es seit 1998 und wird von drei Hauptentwicklern vorangetrieben (Weitere Informationen: http://www.openldap.org/project/).
OpenLDAP 2.4
Die aktuelle Version OpenLDAP 2.4 hat im Bereich Performance und Funktionalität zugelegt so das dieser auch oft als zentrale Instanz in IdentityManagement Konstrukten eingesetzt wird.
Ein großer Vorteil ist das relativ neue Konfigurationsschema bei dem die Einstellungen direkt im DIT (Directory Information Tree) landen. Viele Konfigurationsänderungen können auf diese Weise ohne einen Neustart des LDAP-Servers übernommen werden. Neben diesen Features wurde das Replikationsschema um zwei weitere Möglichkeiten erweitert die jede denkbare Replikation erlauben: MirrorMode und N-Way MultiMaster
OpenLDAP 2.4 Mirror ModeBeim MirrorMode lassen sich LDAP Server verteilt über beispielsweise zwei Standorte aufbauen und erlauben eine Replikation der Daten über zwei Provider.
In diesem Fall hat der erste Provider die Verbindung zu jedem MasterServer, schreibt aber die Daten nur auf einen Server, welcher diese wiederum repliziert. Der zweite Provider läuft als Standby mit und fängt den ersten Provider auf sollte dieser ausfallen und führt die restlichen Schreibvorgänge solange durch bis Provider 1 wieder online ist.
Der N-Way MultiMaster Replikationsweg ermöglicht es mehrere aktive Master Replikationen zu schalten welche in N-Wegen zueinander stehen können und wiederum Slaveserver besitzen können.OpenLDAP Standalone Ldap Proxy
Neben dem „Standardaufbau“ von Master / Slave Konstrukten lassen sich mit OpenLDAP auch LDAPProxy Server zwischenschalten um ggf. an Standorten die Administration in den Slave hinein zu ermöglichen ohne Zugriff auf den Master zu benötigen.
Mittels dieser verschiedenen Architekturmöglichkeiten die OpenLDAP bietet lassen sich viele beliebige Szenarien abbilden.
OpenLDAP ermöglicht ein Onlinebackup der Datenbank (ldapsearch) oder ein Offlinebackup (slapcat).
Zudem nutzt OpenLDAP Checkpointing, welches die Fehlertoleranz anhand von einem Snapshot ähnlichem Mechanismus bietet um im Fehlerfall oder Absturz Datenbankinkonsistenz zu vermeiden.
Die Replikation sowie das Laufzeitverhalten lässt sich mit verschiedenen Nagios und Icinga Plugins monitoren.

Trainings

Web Services

Events