Univention Bugzilla – Bug 35144
Migrate listener / notifier to UCS 4
Last modified: 2014-11-26 06:55:27 CET
Listener and notifier should be migrated to UCS 4. Please consider the package migration list: https://hutten.knut.univention.de/mediawiki/index.php/UCS-4.0_Univention_Package_Update
Packsges: univention-directory-listener univention-directory-notifier univention-directory-replication
We have to think about the local LDAP cache. Currently we use libdb3. I think at least for the first milestone we should use libdb3 again. Do we need to change it for the final UCS 4 release? If we need to change, should we switch to sqlite or db4?
(In reply to Stefan Gohmann from comment #2) > Do we need to change it for the final UCS 4 release? If we need to change, > should we switch to sqlite or db4? The listener always look-up entries through their DN, which is hierarchical by nature. SQLlite on the other hand is relational by nature, so those two data modules do not match. (Implementing a hierarchical model in SQL is not fun and I have personal experience with one project, were an application crash destroyed the complete DB.) It don't give us any benefit (expect perhaps implementation robustness). A simple key-value-store like DB is AFAIK enough. There are some additional settings (last-id,...), which are stored in one value per file; code exists to store that in DB4 as well, but it's IMHO over-kill to use SQLite to store those values. IMHO it would make more sense to use the local LDAP as the cache on DCs and only use a custom implementation on Member-Servers (and other external system roles). AFAIK the only extra information, which is stored in the listener cache but not in the local LDAP, is the list of modules handling an entry, which is only needed by handlers_delete() to call the handlers for previously handled objects.
> use a custom implementation on Member-Servers (and other external system roles). How about running a local LDAP server on every system role and just adjust its configuration on memberservers to only bind to IPv4 localhost (or even just use LDAPI).
(In reply to Arvid Requate from comment #4) > > use a custom implementation on Member-Servers (and other external system roles). > > How about running a local LDAP server on every system role and just adjust > its configuration on memberservers to only bind to IPv4 localhost (or even > just use LDAPI). OK, that sounds good. I think we should start with libdb3 and re-check this issue later in the UCS 4 development. Then we have to compare this with other issues.
In univention-ssl the dependency to univention-directory-listener has been disabled temporarily. If univention-directory-listener has been built successfully, the dependency has to be reenabled!
migrated univention-directory-reports, univention-directory-listener, univention-directory-notifier and univention-directory-replication to UCS 4.0 added olcMdbConfig OID to BUILTIN_OIDS in replication.py readded dependency to univention-directory-listener in univention-ssl
The following traceback occurs: 20.08.14 12:37:57.728 LISTENER ( ERROR ) : import of filename=/usr/lib/univention-directory-listener/system/faillog.py failed in module_import() 20.08.14 12:37:57.732 LISTENER ( ERROR ) : import of filename=/usr/lib/univention-directory-listener/system/bind.py failed Traceback (most recent call last): File "/usr/lib/univention-directory-listener/system/bind.py", line 40, in <module> import listener ImportError: No module named listener
(In reply to Stefan Gohmann from comment #8) > The following traceback occurs: > > 20.08.14 12:37:57.728 LISTENER ( ERROR ) : import of > filename=/usr/lib/univention-directory-listener/system/faillog.py failed in > module_import() > 20.08.14 12:37:57.732 LISTENER ( ERROR ) : import of > filename=/usr/lib/univention-directory-listener/system/bind.py failed > Traceback (most recent call last): > File "/usr/lib/univention-directory-listener/system/bind.py", line 40, in > <module> > import listener > ImportError: No module named listener Fixed with r52868
I've added a changelog for all migrated packages: r52983
There are additional builtin OIDs to be considered in replication.py for MDB: 1.3.6.1.4.1.4203.666.11.1.3.2.12.1 # olcDbMaxReaders 1.3.6.1.4.1.4203.666.11.1.3.2.12.2 # olcDbMaxSize 1.3.6.1.4.1.4203.666.11.1.3.2.12.3 # olcDbEnvFlags See openldap-2.4.35/servers/slapd/back-mdb/config.c
(In reply to Arvid Requate from comment #11) > There are additional builtin OIDs to be considered in replication.py for MDB: > > 1.3.6.1.4.1.4203.666.11.1.3.2.12.1 # olcDbMaxReaders > 1.3.6.1.4.1.4203.666.11.1.3.2.12.2 # olcDbMaxSize > 1.3.6.1.4.1.4203.666.11.1.3.2.12.3 # olcDbEnvFlags > > See openldap-2.4.35/servers/slapd/back-mdb/config.c do you mean 1.3.6.1.4.1.4203.1.12.2.3.2.12.1 1.3.6.1.4.1.4203.1.12.2.3.2.12.2 1.3.6.1.4.1.4203.1.12.2.3.2.12.3 (OLcfgDbAt + 12.1 etc.) Added those three to BUILTIN_OIDS in replication.py
Yeah, right, there is our 31_avoid_OID_changes.patch, which patches the OpenLDAP internal OIDs back so the OpenLDAP 2.3 conventions. We might consider to drop that patch at some point. I added a comment to Bug 35697.
But as 31_avoid_OID_changes.patch patches - { "OLcfg", "1.3.6.1.4.1.4203.1.12.2" }, + { "OLcfg", "1.3.6.1.4.1.4203.666.11.1" }, I guess we need to add the .666. variants as well. Better keep both conventions, in case we drop the patch.
(In reply to Arvid Requate from comment #14) > But as 31_avoid_OID_changes.patch patches > > - { "OLcfg", "1.3.6.1.4.1.4203.1.12.2" }, > + { "OLcfg", "1.3.6.1.4.1.4203.666.11.1" }, > > I guess we need to add the .666. variants as well. Better keep both > conventions, in case we drop the patch. ok
Ok.
UCS 4.0-0 has been released: http://docs.univention.de/release-notes-4.0-0-en.html http://docs.univention.de/release-notes-4.0-0-de.html If this error occurs again, please use "Clone This Bug".