Univention Bugzilla – Bug 48486
Cron running in Horde container triggers server password change
Last modified: 2019-06-03 14:36:19 CEST
As described in this forum post: https://help.univention.com/t/horde-container-machine-password-mismatch-in-configuration-users-cannot-login/10944 We have a machine running UCS: 4.3-2 errata390 as Univention master with the following modules: Installed: dhcp-server=12.0 horde=5.2.17-2 mailserver=12.0 nagios=4.3 self-service=3.0 The Horde container was freshly (re-)installed when it was updated from 5.2.7 version due to problems with the update. Inside the container the cron daemon is enabled and running. It is triggering a server password update, which is not reflected into /etc/horde/horde/conf.d/10-ucs.php. Due to this, users are not able to login to horde after that password update and we need to run "ucr commit /etc/horde/horde/conf.d/10-ucs.php", which again copies the machine password to the LDAP config section. Is the cron daemon supposed to be running?
I can confirm this happening on my own Horde container, too. It only started happening after updating yesterday. Before the update the cron package wasn't installed inside my Horde container, but after the update it was. After the update a server password change was triggered a couple of hours later modifying `machine.secret` but leaving `10-ucs.php` intact. The app version itself was 5.12.17-2 both before and after the upgrade. My interpretation of what the desired state should be is: 1. Cron should always be installed. Otherwise things such as log file rotation simply won't work. 2. A server password change script should be included that simply calls `ucr commit` for `10-ucs.php` after a successful change. There's a wider question here whether server password changes are really all that useful for UCS-based Docker containers. I've read various forum posts about issues in various apps that were traced back to the server password change not working properly or the changed password not being distributed to additional configuration files properly. The question remains whether this is a mechanism that's really necessary: it adds a certain amount of complexity, and such complexity is always a source for bugs.
For the sake of people affected by this issue: you should be able to get your installation working again by executing the following commands: # This one must be run on the server the Horde app is installed on: univention-app shell horde # The next two will be run inside the Horde container spawned by the first command: ucr commit /etc/horde/horde/conf.d/10-ucs.php exit
Also simply going into the Horde settings page in the web portal and hitting apply changes seems to fix it as well.
Hit another customer environment today. I can provide logs if necessary.
fixed in univention-mail-horde by adding a server password change hook created a new app version 5.2.17-3 manual tests ok (with server password change) Jenkins still running Please QA and re-open (so that i can release the app)
OK, works. Released
I did the horde update in a customer environment last friday and the same behaviour appeared again. _____________________________________________________________ root@ucs05:~# univention-app info UCS: 4.3-4 errata523 Installed: horde=5.2.17-3 ______________________________________________________________ After the update to 5.2.17-3, I unset the ucr variable server/password/change, which was set to "false" before. ___________________________________________________________ var/log/univention/server_password_change.log: Starting server password change (Fri May 31 01:01:23 UTC 2019) Server password change is disabled by the UCR variable server/password/change Starting server password change (Sat Jun 1 01:05:54 UTC 2019) Proceeding with regular server password change scheduled for today ntion-mail-server prechange rechange ion-libnss-ldap prechange ion-nscd prechange merhaven,dc=intranet ntion-mail-server postchange File: /etc/listfilter.secret Multifile: /etc/postfix/ldap.distlist Multifile: /etc/postfix/ldap.groups Multifile: /etc/postfix/ldap.external_aliases Multifile: /etc/postfix/ldap.sharedfolderlocal Multifile: /etc/postfix/ldap.virtualwithcanonical Multifile: /etc/postfix/ldap.virtual_mailbox Multifile: /etc/postfix/ldap.sharedfolderremote Multifile: /etc/postfix/ldap.sharedfolderlocal_aliases Multifile: /etc/postfix/ldap.virtual Multifile: /etc/postfix/ldap.canonicalrecipient Multifile: /etc/postfix/ldap.transport Multifile: /etc/postfix/ldap.canonicalsender Multifile: /etc/postfix/ldap.saslusermapping Multifile: /etc/postfix/ldap.virtualdomains ostchange File: /etc/horde/horde/conf.d/10-ucs.php ion-libnss-ldap postchange File: /etc/libnss-ldap.conf ion-nscd postchange Restarting nscd (via systemctl): nscd.service. done (Sat Jun 1 01:06:00 UTC 2019) Starting server password change (Sun Jun 2 01:06:18 UTC 2019) No server password change scheduled for today, terminating without a change Starting server password change (Mon Jun 3 01:07:29 UTC 2019) No server password change scheduled for today, terminating without a change
(In reply to Stefanie Schneider from comment #7) > I did the horde update in a customer environment last friday and the same > behaviour appeared again. > > _____________________________________________________________ > root@ucs05:~# univention-app info > UCS: 4.3-4 errata523 > Installed: horde=5.2.17-3 > > ______________________________________________________________ > After the update to 5.2.17-3, I unset the ucr variable > server/password/change, which was set to "false" before. > > ___________________________________________________________ > var/log/univention/server_password_change.log: > > Starting server password change (Fri May 31 01:01:23 UTC 2019) > Server password change is disabled by the UCR variable server/password/change > Starting server password change (Sat Jun 1 01:05:54 UTC 2019) > Proceeding with regular server password change scheduled for today > ntion-mail-server prechange > rechange > ion-libnss-ldap prechange > ion-nscd prechange > merhaven,dc=intranet > ntion-mail-server postchange > File: /etc/listfilter.secret > Multifile: /etc/postfix/ldap.distlist > Multifile: /etc/postfix/ldap.groups > Multifile: /etc/postfix/ldap.external_aliases > Multifile: /etc/postfix/ldap.sharedfolderlocal > Multifile: /etc/postfix/ldap.virtualwithcanonical > Multifile: /etc/postfix/ldap.virtual_mailbox > Multifile: /etc/postfix/ldap.sharedfolderremote > Multifile: /etc/postfix/ldap.sharedfolderlocal_aliases > Multifile: /etc/postfix/ldap.virtual > Multifile: /etc/postfix/ldap.canonicalrecipient > Multifile: /etc/postfix/ldap.transport > Multifile: /etc/postfix/ldap.canonicalsender > Multifile: /etc/postfix/ldap.saslusermapping > Multifile: /etc/postfix/ldap.virtualdomains > ostchange > File: /etc/horde/horde/conf.d/10-ucs.php > ion-libnss-ldap postchange > File: /etc/libnss-ldap.conf > ion-nscd postchange > Restarting nscd (via systemctl): nscd.service. > done (Sat Jun 1 01:06:00 UTC 2019) > Starting server password change (Sun Jun 2 01:06:18 UTC 2019) > No server password change scheduled for today, terminating without a change > Starting server password change (Mon Jun 3 01:07:29 UTC 2019) > No server password change scheduled for today, terminating without a change Some more info: root@horde-24172180:/# dpkg -l univention-mail-horde Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-==============-============-============-================================= ii univention-mai 4.0.0-9A~4.3 all UCS - horde webmail