Univention Bugzilla – Bug 12482
"Cannot find service-record of _pkgdb._tcp."-Meldung
Last modified: 2010-08-07 16:30:54 CEST
Diese Meldung sollte nur erscheinen, wenn in der Domäne auf einem System pkgdb installiert ist. pkgdb sollte den Service Eintrag bei dem Rechner setzen und es sollte ein Listener Modul erst dann pkgdb per UCR ansachalten, wenn der Dienst vergeben ist.
Bei diese Änderung sollten wir den Default nicht ändern. Ggf. macht es mehr Sinn das erst zur 2.4 umzusetzen, wenn ja, dann bitte auf 2.4 verschieben.
(In reply to comment #0) > pkgdb sollte den Service Eintrag bei dem Rechner setzen Das hat keine weiteren Auswirkungen und kann so umgesetzt werden > Diese Meldung sollte nur erscheinen, wenn in der Domäne auf einem System pkgdb > installiert ist. Ist mit dem ersten Punkt auch umsetzbar. Dann wird zuvor der Service abgefragt > und es > sollte ein Listener Modul erst dann pkgdb per UCR ansachalten, wenn der Dienst > vergeben ist. Update: Das dürfte nicht dazu führen, dass durch das Listener-Modul pkgdb aktiviert wird, obwohl es explizit ausgeschaltet wurde. Also darf das Listener Modul die Variable eigentlich nur setzen, wenn sie nicht existiert. univention-pkgdb-tools darf die Variable also nicht setzen bei der Installation Neuinstallation: Sobald der Service gesetzt wird kann das Listener-Modul die Variable setzen (wenn nicht existent) und dann ggf. einen Scan ausführen. Somit sollten wir das Standard-Verhalten eigentlich nicht ändern.
(In reply to comment #2) > (In reply to comment #0) > > und es > > sollte ein Listener Modul erst dann pkgdb per UCR ansachalten, wenn der Dienst > > vergeben ist. Das Modul darf aber nur zum Anschalten verwendet werden und nicht zum abschalten. Sonst würden wir den Standard verändern bzw. wir würden evtl. eine UCR-Variable setzen, die durch den Benutzer explizit auf einen anderen Wert gesetzt wurde. Sprich, wenn wir an- und ausschalten unterstützen wollen, dann müssten wir beim Anschalten auf eine gesetzte Variable überschreiben, dass würde nicht dem jetzigen Verhalten entsprechen. So etwas sollten wir denke ich erst zu 2.4 machen. Wollen wir dann den ganzen Bug auf 2.4 taggen oder teile wie den Serviceeintrag , das unterdrücken der Meldung und das Anschalten bei nicht gesetzter Variable schon implementieren? RFC
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > und es > > > sollte ein Listener Modul erst dann pkgdb per UCR ansachalten, wenn der Dienst > > > vergeben ist. > > Das Modul darf aber nur zum Anschalten verwendet werden und nicht zum > abschalten. Sonst würden wir den Standard verändern bzw. wir würden evtl. eine > UCR-Variable setzen, die durch den Benutzer explizit auf einen anderen Wert > gesetzt wurde. Sprich, wenn wir an- und ausschalten unterstützen wollen, dann > müssten wir beim Anschalten auf eine gesetzte Variable überschreiben, dass > würde nicht dem jetzigen Verhalten entsprechen. > > So etwas sollten wir denke ich erst zu 2.4 machen. Ja. > Wollen wir dann den ganzen Bug auf 2.4 taggen oder teile wie den Serviceeintrag > , das unterdrücken der Meldung und das Anschalten bei nicht gesetzter Variable > schon implementieren? Ich denke das kann schon jetzt implementiert werden.
(In reply to comment #4) > (In reply to comment #3) > > Wollen wir dann den ganzen Bug auf 2.4 taggen oder teile wie den Serviceeintrag > > , das unterdrücken der Meldung und das Anschalten bei nicht gesetzter Variable > > schon implementieren? > > Ich denke das kann schon jetzt implementiert werden. Das ist jetzt umgesetzt. Für die anderen Teile klone ich den Bug
Auf einem Mobile Client bekomme ich den Traceback in der listener.log: 07.05.10 12:32:30 LISTENER ( WARN ) : handler: pkgdb-watch (failed) UNIVENTION_DEBUG_BEGIN : uldap.__open host=localhost port=389 base=dc=univention,dc=qa UNIVENTION_DEBUG_END : uldap.__open host=localhost port=389 base=dc=univention,dc=qa Traceback (most recent call last): File "/usr/lib/univention-directory-listener/system/pkgdb-watch.py", line 41, in handler if univention.pkgdb.is_service_available(): File "/usr/lib/python2.4/site-packages/univention/pkgdb.py", line 126, in is_service_available ldap_conn = univention.uldap.access( base = ldap_base ) File "/usr/lib/python2.4/site-packages/univention/uldap.py", line 113, in __init__ self.__open() File "/usr/lib/python2.4/site-packages/univention/uldap.py", line 152, in __open self.lo.start_tls_s() File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 532, in start_tls_s return self._ldap_call(self._l.start_tls_s) File "/usr/lib/python2.4/site-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) ldap.SERVER_DOWN: {'desc': "Can't contact LDAP server"}
Das Listener Modul fragt jetzt nicht mehr das LDAP ab sondern prüft nur das aktuelle Objekt.
Ok
UCS 2.3-2 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".