UCS 4.2-0: stunnel startet nicht

UCS - Univention Corporate Server
, ,
#1

Habe 2 UCS Server 4.2-0 (einen Master DC, einen Backup DC). Auf beiden startet stunnel4 beim booten nicht. Wenn ich den service nachstarte, z.B. in der rc.local, starten sie ohne Fehler. Das ist auf beiden Servern identisch.

Braucht man den Dienst überhaupt noch, wofür?
Wenn ja, warum startet der (unter systemd?) nicht mehr sofort beim booten?

Auf beiden DC Servern ist jeweils der andere in der .conf eingetragen…

Logfile:

Apr 19 09:46:00 ucs systemd[1]: Started LSB: Launch atftpd server.
Apr 19 09:46:00 ucs stunnel4[703]: [!] Error binding service [ucsbak.friedrichnet.de] to localhost:/var/run/univention-saml/ucsbak.friedrichnet.de.socket
Apr 19 09:46:00 ucs stunnel4[703]: [!] bind: No such file or directory (2)
Apr 19 09:46:00 ucs stunnel4[703]: [ ] Closing service [memcached]
Apr 19 09:46:00 ucs stunnel4[703]: [ ] Service [memcached] closed (FD=7)
Apr 19 09:46:00 ucs stunnel4[703]: [ ] Service [memcached] closed
Apr 19 09:46:00 ucs stunnel4[703]: [ ] Closing service [ucsbak.friedrichnet.de]
Apr 19 09:46:00 ucs stunnel4[703]: [ ] Service [ucsbak.friedrichnet.de] closed
Apr 19 09:46:00 ucs stunnel4[703]: failed
Apr 19 09:46:00 ucs stunnel4[703]: You should check that you have specified the pid= in you configuration file

Das pid file ist natürlich im Conffile drinnen. Ist vermutlich eine race-condition des systemd?

4.1 to 4.2 upgrade niggles
Problem with ssl tunnel after last errata
#2

kann den fehler mit errata25 bestätigen, auf primary und backup controllern

#3

Bin da auch reingelaufen, bei mehreren Systemen jeweils identisch.

Das Problem ist, dass das Paket univention-saml von stunnel4 abhängt, letztendlich aber seinen eigenen stunnel-Prozess mit einem eigenen ini-Script startet und stunnel4 mit dem eigenen init-Script auf die Nase fällt.

Im Moment, damit man den Fehler nicht mehr bekommt (und versucht einen Fehler zu beheben, der insofern keiner ist), haben wir mit “systemctl disable stunnel4” das Problem “behoben”. Univention-saml startet dann weiterhin problemlos.

Hier mein Bugreport: https://forge.univention.org/bugzilla/show_bug.cgi?id=45455

Hoffe das hilft anderen, die danach gesucht haben. Der aktuelle default macht in meinen Augen nicht wirklich Sinn.

1 Like
Mastodon