Horde container machine password mismatch in configuration - users cannot login

Apps & App Center
#1

Hello,

we had a problem with the running horde container on a domain master twice in the last few weeks. Users were not able to login and after some digging we realized that the machine password is not correctly reflected to /etc/horde/horde/conf.d/10-ucs.php after a machine password change. We have to manually run ucr commit /etc/horde/horde/conf.d/10-ucs.php in this case.

How should the change be triggered usually? Machine password changes seem to work correctly on a second domain backup server.

Thanks,
Robert

Horde login fails with "invalid credentials" after errata390
#2

Hey,

this is a very interesting case. For machine password changes there are a bunch of scripts in /usr/lib/univention-server/server_password_change.d which take care of executing ucr commit for all known files the machine secret is used in. In my Horde container there is no file in that directory that does so for the file youā€™ve mentioned.

However, it gets even stranger. On my Horde container the content of /etc/machine.secret matches the LDAP password in ā€¦/10-ucs.php. So how can that be? Well, looking at the modification timestamps for both files shows that they havenā€™t been modified since August, which is likely when I first installed the app.

How can that be? Well, the interval between server password changes can be configured via the UCR variable server/password/interval which is set to 21 for me ā€” meaning the server password should have been changed several times by now.

The server password change is triggered via a cron job. And thatā€™s when I noticed that the cron daemon isnā€™t running in my Horde container ā€” no cron jobs were executed at all. In fact, cron isnā€™t even installed.

So my question to you is ā€” did you modify your Horde Docker container somehow?

m.

#3

Except for adding some horde config to enable ActiveSync I did not change anything in the container. Cron is up and running here, should it be?

root@horde-30690xxx:/# systemctl is-enabled cron; echo $?
enabled
0

And my backups show, that cron has been enabled for at least two months, whereas the problem arose first few weeks ago.

#4

systemctl is-active would be more interesting (enabled = is supposed to be started, active = is actually started). However, I donā€™t know enough about the inner workings of the UCS Horde app to say how this is all supposed to work (meaning if cron should be installed & running ā€” my gut feeling says ā€œdefinitely, yesā€ as things such as log file rotation wouldnā€™t work without cron).

Can you tell me the version of your Horde app? See univention-app info

Next, please show me the output of the following commands from inside your Horde container:

dpkg -l|grep -i cron
ls /usr/lib/univention-server/server_password_change.d

You should be able to work around the problem by disabling the automatic server password change inside the Horde container:

ucr set server/password/change=false

Note that the variable seems to be undocumented, but it is used in the corresponding script, /usr/lib/univention-server/server_password_change.

Kind regards
mosu

#5

Cron is also running and the system is more or less up to date:

UCS: 4.3-2 errata390
Installed: dhcp-server=12.0 horde=5.2.17-2 mailserver=12.0 nagios=4.3 self-servi                                            ce=3.0

Inside the container:

root@horde-30690xxx:/# dpkg -l|grep -i cron
ii  cron                                    3.0pl1-128+deb9u1                                amd64        process scheduling daemon

root@horde-30690xxx:/# ls /usr/lib/univention-server/server_password_change.d
50univention-mail-server  README.API  univention-libnss-ldap  univention-nscd
#6

Thatā€™s very strange. My appā€™s version is the same as yours, but cron isnā€™t installed.

I donā€™t see any script in your server password change directory that could take care of rebuilding the 10-ucs.php file either, meaning I donā€™t think this will ever work for you. Like I said above you should probably disable the server password change mechanism in the container.

Additionally itā€™d be good to file a bug report for this.

#7

Addendum: Iā€™ve just finished running univention-upgrade on the host running the Horde container. Now I have cron installed in the container, too. Iā€™ll probably start experiencing the same issues you are soon.

#8

Hooray.

Bug report is here:
https://forge.univention.org/bugzilla/show_bug.cgi?id=48486

#9

Thank you very much for filing the report. I was about to do the same today, but you beat me to it.

And yes, it happens to me now, too. Today /etc/machine.secret was updated whereas /etc/horde/horde/conf.d/10-ucs.php wasnā€™t. Clearly a bug.

My gut feeling is that this is simply an edge case. During development the cron daemon simply wasnā€™t running (meaning it wasnā€™t present in the minimal installation used for the Docker images). Due to certain package dependencies it was sucked in during upgrades, but that only started to happen recently, and therefore the developers never stumbled across this situation.

Itā€™s really easy enough to fix; just include a server password change script that ucr commits 10-ucs.php after a successful change.

#10

Thanks for filing this bug. This problem has been affecting me and now I know why. Iā€™ve been fixing it by going into the horde app settings on the web gui and just saving the settings without making any changes. That must be running the script you mentioned.

Anyway, Iā€™m about ready to ditch horde and just use the calendar and webmail app in next cloud. I am finding horde to be more trouble than itā€™s worth. The only thing I think I would be missing in nextcloud is activesync, but I think that can be installed with zpush. Not sure if itā€™s worth installing it or not though. Iā€™m not sure what would happen with minor updates. Might have to reinstall it or something.

#11

Had this happen again on the latest horde update 5.2.17-3. Went into settings and hit the apply button and users can login again. Anyone else have the issue in the latest version? Maybe I should try uninstalling and reinstalling if itā€™s just me.

1 Like
#12

Same here. Yesterday updated a customers server to latest UCS release and horde to its last release.

After 0.00 nightly no login possible. The hours before all was running well. Also opened the app-settings in the portal, changed NOTHING and after applying the settings all was running well again!

What job is running ad midnight which can cause this problem?

1 Like
#13

Please post your experience and information (such as relevant version numbers) in the corresponding bug. Yes, itā€™s marked as closed, but if the supposed fix isnā€™t working for you, the devs should need to hear about it.

#14

Please do not add additional comments to already closed bugs. If the issue occurs again, use the ā€˜Clone This Bugā€™ link at the bottom of the bug website.

#15

I cloned it.

https://forge.univention.org/bugzilla/show_bug.cgi?id=49449

I donā€™t have a lot of info on this as I usually find out about it when someone needs it, so I do the quick fix of applying the settings again and move on. If thereā€™s any more information someone has on what I should be looking at to find the source of the problem let me know and Iā€™ll try to collect what info I can the next time it happens.

#16

It is october 2019 now - running the latest version of UCS/horde ā€¦ and still the problem exist.
ucs commit ā€¦ within docker helps.

UCS: 4.3-5 errata595
Installed: horde=5.2.17-3

#17

I believe they have made an update available (5.2.17-4) just in the past couple of days that is supposed to fix it. Not sure if it does yet or not. I just ran it on a customers server. It usually takes 2-3 weeks for someone to have a need to log in via webmail, so if they donā€™t have any login issues after a few weeks Iā€™ll be pretty confident that itā€™s finally been resolved.

Mastodon