Univention Bugzilla – Bug 27992
OpenLDAP in UCS 3.1
Last modified: 2012-12-12 21:07:58 CET
Es sollte geprüft werden, ob eine aktuellere OpenLDAP Version, z.B. 2.4.31, ohne die in 2.4.25 beobachteten Performanceprobleme (Bug 22879) funktioniert und sich zum Einsatz in einer kommenden UCS Version eignet. +++ This bug was initially created as a clone of Bug #22468 +++
OpenLDAP 2.4.31 ist nach 3.1-0 importiert, Patches aus UCS 3.0 sind gemerged und angepasst und das neue Paket ist gebaut. Eine weitere intern definierte OID kam hinzu, die jetzt zusätzlich in slapd.postinst und univention-directory-replication herausgefiltert wird. Basis Tests OK: * Master und Slave unter ucs3.0-1 gejoined * Master slapd auf 2.4.31 upgedated, Replikation zum Slave weiter OK * Slave slapd und univention-directory-replication upgedated, Replikation OK * Neujoin Slave OK
Erste Performance Tests mit 5000 Domain Users (auf 512MB Master) sahen OK aus: ### ucr set ldap/acl/read/anonymous=no; /etc/init.d/slpad restart # ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base \ -D cn=admin,$ldap_base -y /etc/ldap.secret real 0m1.197s user 0m0.284s sys 0m0.060s # ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base \ -D cn=master,cn=dc,cn=computers,$ldap_base -y /etc/machine.secret real 0m13.385s user 0m0.300s sys 0m0.088s # ldapsearch -ZZ -x uid=* -LLL -s one -b cn=users,$ldap_base \ -D cn=admin,$ldap_base -y /etc/ldap.secret real 0m0.946s user 0m0.424s sys 0m0.052s # ldapsearch -ZZ -x uid=* -LLL -s one -b cn=users,$ldap_base \ -D cn=master,cn=dc,cn=computers,$ldap_base -y /etc/machine.secret real 0m14.336s user 0m0.548s sys 0m0.100s ### ucr set ldap/acl/read/anonymous=yes; /etc/init.d/slpad restart # ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base \ -D cn=admin,$ldap_base -y /etc/ldap.secret real 0m1.118s user 0m0.288s sys 0m0.056s # ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base \ -D cn=master,cn=dc,cn=computers,$ldap_base -y /etc/machine.secret real 0m13.330s user 0m0.312s sys 0m0.076s # ldapsearch -ZZ -x uid=* -LLL -s one -b cn=users,$ldap_base \ -D cn=admin,$ldap_base -y /etc/ldap.secret real 0m1.259s user 0m0.496s sys 0m0.084s # ldapsearch -ZZ -x uid=* -LLL -s one -b cn=users,$ldap_base \ -D cn=master,cn=dc,cn=computers,$ldap_base -y /etc/machine.secret real 0m13.963s user 0m0.504s sys 0m0.136s ### anonymous search # ldapsearch -x uid=* -LLL -s one -b cn=users,$ldap_base real 0m7.810s user 0m0.176s sys 0m0.076s ## again real 0m7.789s user 0m0.176s sys 0m0.076s
Changelog Eintrag ist eingecheckt, amd64 Tests und ucs-test stehen noch aus.
univention-ldap wurde noch angepasst, weil slapd.postinst versuchte die Datei '"rootpw.conf"' zu öffnen. Jetzt wird rootpw.conf wie alle anderen includes auch ohne quotation included, wodurch in Zukunft ein paar seltsame Meldungen im postinst entfallen. Falls univention-ldap erst nach slapd installiert wird, treten diese zwar dann aktuell noch auf, sind aber unkritisch.
Bei einer Neu-Installation gibt es zum Zeitpunkt des Join (UCS Master) ein Verzeichnis "/etc/ldap/slapd.conf". Damit klappt ein ucr commit auf das slapd.conf nicht mehr und es gibt keine Konfiguration für den slapd. Das hat irgendetwas mit dem Patch 3.1-0-0-ucs/2.4.31-1/63_disable_migrate_to_slapd_d_style.patch und dem slapd.postinst zu tun.
Ich hatte in /etc/default/slapd statisch SLAPD_CONF=/etc/ldap/slapd.conf gesetzt, aber die Funktion create_new_slapd_conf, die bei Erstinstallation in slapd.postinst aufgerufen wird, verwendet das als Verzeichnisname... Die Anpassung von /etc/default/slapd ist nicht notwendig und wurde wieder entfernt, Paket baut.
Es gibt inzwischen auch eine neue Upstream-Version, ggf. sollte zu einen geeigneten Zeitpunkt nochmal geschaut werden, ob man nochmal eine neuere Version importiert. Der Aufwand für den Import war bisher nicht sehr hoch. http://www.openldap.org/software/release/changes.html
Created attachment 4677 [details] Performancevergleich
Performance-Messungen in VM unterlagen zu starten Schwankungen, siehe Attachment 4677 [details] (Testreihe mit 32k Benutzers). Deswegen nochmal auf den Schulungsraumrechnern wiederholt, aber selbst auf realer Hardware schwanken die Ergebnisse relativ stark. Die wenigen unter <https://hutten.knut.univention.de/mediawiki/index.php/Produkttests_UCS_3.0_LDAP> angegebenen Zeiten passen allerdings absolut nicht zu meinen Tests. Auf den Schulungsraumrechnern lagen die Werte im Vergleich zwischen amd64, i386 und amd64 aus UCS-3.0 zum Vergleich nahe genug beisammen. Ansonsten wurden keine Probleme mit dem neueren OpenLDAP festzustellen. Allgemein ist aber aufgefallen, daß der Listener noch Stunden nach dem Anlegen der Benutzer damit beschäftigt ist, irgendwelche temporären Lock-Objekte zu replizieren. Das war noch ein Bug an Bug #27330 comment 8. Auch aufgefallen ist das jede Menge Locks für Samba SID zurückbleiben # udm settings/lock list | sed -ne 's/^DN: //p' | wc -l 2002 Das Muster ist dabei immer ähnlich: Das Lock-Objekt wird angelegt, dann freigegeben, und danach nochmals angelegt (und nicht mehr freigegeben). OK: openldap_2.4.31-1.73.201208231905
Das Aktualisieren eines ungejointen UCS-3.0-2-Generic Backup auf UCS-3.1 geht schief: Irgendwas™ geht schief: > Vorbereiten zum Ersetzen von slapd 2.4.23-7.2.64.201110290030 (durch .../slapd_2.4.31-1.73.101208231905_amd64.deb) ... > Stopping ldap server(s): slapd ...done. > Dumping to /var/backup/slapd-2.4.23-7.2.64.201110290030: > - directory dc=ucs,dc=test... bdb_db_open: database "dc=ucs,dc=test": db_open(/var/lib/univention-ldap/ldap/id2entry.bdb) failed: No such file or directory (2). > backend_startup_one (type=bdb, suffix="dc=ucs,dc=test"): bi_db_open failed! (2) > slap_startup failed > failed > dpkg: Fehler beim Berarbeiten von /var/cache/apt/archives/slapd_2.4.31-1.73.201208231905_amd64.deb (- > Unterprozess neues pre-installation-Skript gab den Fehlerwert 1 zurück > configured to not write apport reports ... > Checking Schema ID: ....invoke-rc.d: initscript slapd, action "start" failed. > dpkg: Fehler beim Aufräumen: > Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück ... > Ersatz für libldap-2.4.2 wird entpackt ... Danach ist eine Mischung von altem "slapd"-Paket und neuer "libldap" installiert. slapcat funktioniert danach nicht mehr und meckert: > slapcat: Symbol `ldap_int_global_options' has different size in shared object, consider re-linking. Da das im prerm zum Sichern der LDAP-DB aufgerufen wird, funktioniert dann weder ein Down- noch Upgrade. Das sieht so erstmal danach aus, als ob die Shared-Library-Versionsnummer von libldap-2.4 nicht erhöht worden ist, obwohl sich das Interface einer Funktion gegenüber der früheren version geändert hat. Ggf. REOPEN?
(In reply to comment #10) > Das Aktualisieren eines ungejointen UCS-3.0-2-Generic Backup auf UCS-3.1 geht > schief: Irgendwas™ geht schief: > > Vorbereiten zum Ersetzen von slapd 2.4.23-7.2.64.201110290030 (durch .../slapd_2.4.31-1.73.101208231905_amd64.deb) ... > > Stopping ldap server(s): slapd ...done. > > Dumping to /var/backup/slapd-2.4.23-7.2.64.201110290030: > > - directory dc=ucs,dc=test... bdb_db_open: database "dc=ucs,dc=test": db_open(/var/lib/univention-ldap/ldap/id2entry.bdb) failed: No such file or directory (2). > > backend_startup_one (type=bdb, suffix="dc=ucs,dc=test"): bi_db_open failed! (2) > > slap_startup failed > > failed > > dpkg: Fehler beim Berarbeiten von /var/cache/apt/archives/slapd_2.4.31-1.73.201208231905_amd64.deb (- > > Unterprozess neues pre-installation-Skript gab den Fehlerwert 1 zurück > > configured to not write apport reports > ... > > Checking Schema ID: ....invoke-rc.d: initscript slapd, action "start" failed. > > dpkg: Fehler beim Aufräumen: > > Unterprozess installiertes post-installation-Skript gab den Fehlerwert 1 zurück > ... > > Ersatz für libldap-2.4.2 wird entpackt ... > > Danach ist eine Mischung von altem "slapd"-Paket und neuer "libldap" > installiert. slapcat funktioniert danach nicht mehr und meckert: > > slapcat: Symbol `ldap_int_global_options' has different size in shared object, consider re-linking. > > Da das im prerm zum Sichern der LDAP-DB aufgerufen wird, funktioniert dann > weder ein Down- noch Upgrade. > > Das sieht so erstmal danach aus, als ob die Shared-Library-Versionsnummer von > libldap-2.4 nicht erhöht worden ist, obwohl sich das Interface einer Funktion > gegenüber der früheren version geändert hat. > Ggf. REOPEN? Bug #28820 eröffnet.
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".