Univention Bugzilla – Bug 56127
univention-admingrp-user-passwordreset unnecessarily restarts slapd at least once per day
Last modified: 2023-06-08 16:42:15 CEST
In a charity support case für a UCS 5.0-3 system we found that slapd is restarted periodically for no clear reason. Debugging showed that this can be reproduced like this: * Create a bunch of domain admins: eval "$(ucr shell)"; for i in $(seq 10); do udm users/user create --position "cn=users,$ldap_base" --set username="admin$i" --set lastname="DA member $i" --set password=univention --set primaryGroup="cn=Domain Admins,cn=groups,$ldap_base"; done * univention-install univention-admingrp-user-passwordreset * Then observe/var/log/univention/config-registry.replog: ========== 2023-06-08 10:51:05: set ldap/acl/user/passwordreset/internal/groupmemberlist/Domain Admins=Administrator,admin10,admin2,admin8,admin7,admin6,admin5,admin1,admin4,admin9,admin3 old:[Previously undefined] 2023-06-08 10:51:23: set ldap/acl/user/passwordreset/internal/groupmemberlist/Domain Admins=admin7,admin5,admin1,admin4,Administrator,admin3,admin9,admin8,admin2,admin6,admin10 old:Administrator,admin10,admin2,admin8,admin7,admin6,admin5,admin1,admin4,admin9,admin3 ========== Hmm last line looks interesting. random sort order? * Correlate with: egrep "slapd (stop|start)" /var/log/syslog ========== Jun 8 10:51:09 primary20 root: /etc/init.d/slapd stop (pid: 6314, ppid: 1 systemd) Jun 8 10:51:09 primary20 slapd[6261]: slapd stopped. Jun 8 10:51:09 primary20 root: /etc/init.d/slapd start (pid: 6329, ppid: 1 systemd) Jun 8 10:51:09 primary20 slapd[6342]: slapd starting Jun 8 10:51:26 primary20 root: /etc/init.d/slapd stop (pid: 6603, ppid: 1 systemd) Jun 8 10:51:26 primary20 slapd[6342]: slapd stopped. Jun 8 10:51:27 primary20 root: /etc/init.d/slapd start (pid: 6618, ppid: 1 systemd) Jun 8 10:51:27 primary20 slapd[6631]: slapd starting ========== * Run /usr/lib/univention-pam/ldap-group-to-file.py again manually * Check: /var/log/univention/config-registry.replog ========== 2023-06-08 10:58:21: set ldap/acl/user/passwordreset/internal/groupmemberlist/Domain Admins=admin7,admin8,admin4,admin2,admin6,admin1,admin9,admin3,Administrator,admin10,admin5 old:admin7,admin5,admin1,admin4,Administrator,admin3,admin9,admin8,admin2,admin6,admin10 ========== Again: random order of group members in this UCRV-value * egrep "slapd (stop|start)" /var/log/syslog ========== Jun 8 10:58:24 primary20 root: /etc/init.d/slapd stop (pid: 7054, ppid: 1 systemd) Jun 8 10:58:24 primary20 slapd[6631]: slapd stopped. Jun 8 10:58:24 primary20 root: /etc/init.d/slapd start (pid: 7069, ppid: 1 systemd) Jun 8 10:58:24 primary20 slapd[7082]: slapd starting ========== Analysis: * /usr/lib/univention-pam/ldap-group-to-file.py is run periodically via cron * That script is also run by the nss.py listener postrun, after membership of *any* group changed * That script uses a Python set() to write members to /var/lib/extrausers/group and that doesn't have a defined sort order by definition * That script calls /var/lib/ldap-group-to-file-hooks.d/admingrp-user-passwordreset whci restarts the slapd
Have you checked Bug #56099, which has been released yesterday as <https://errata.software-univention.de/#/?erratum=5.0x704> ?
Maybe that mitigates stuff, but the sort order is still undefined, and as such ldap-group-to-file-hooks.d/admingrp-user-passwordreset will every now and then detect differences between the memberlist obtained from /var/lib/extrausers/group compared to the string stored in the UCR variable. See proposed merge request in issue URL.
Relevant docs: https://docs.software-univention.de/manual/5.0/en/domain-ldap/ldap-directory.html#delegation-of-the-privilege-to-reset-user-passwords
(In reply to Arvid Requate from comment #2) > Maybe that mitigates stuff, but the sort order is still undefined, > and as such ldap-group-to-file-hooks.d/admingrp-user-passwordreset will > every now and then detect differences between the memberlist obtained from > /var/lib/extrausers/group compared to the string stored in the UCR variable. No, it will not as both are compared now as set(), where order does not matter.
Right, 188ea58b38 for Bug #56099 should fix this.
*** This bug has been marked as a duplicate of bug 56099 ***