Bei den letzten beiden OPSI 4.2-Debian-Paketupgrades des opsiconfd fiel mir auf, das der opsiconfd-Daemon nach dem Upgrade nicht neu gestartet wird. Entweder hängt dann noch ein Zombie-Prozess rum oder aber gar keiner mehr. Man muss dann immer händisch ein "systemctl start opsiconfd.service" abfeuern. Kein großes Ding, solange man Sachen wie unattended-upgrades [1] nicht nutzt. Das Paket kann den Neustart des Daemon ja aber im Rahmen des Upgrades selbst erledigen.
[1] https://wiki.debian.org/UnattendedUpgrades
OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades
Re: OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades
Hatte ich auch, das hat geholfen:
viewtopic.php?f=7&t=11506
Gruß
kinzi
P. S.: Zuvor war noch ein
bei mir notwendig.
viewtopic.php?f=7&t=11506
Gruß
kinzi
P. S.: Zuvor war noch ein
Code: Alles auswählen
apt install opsiconfd --reinstall
Re: OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades
Falls sich jemand hier vorbeikommt, der Link weist auf eine Lösung für opsi 4.1 hin. Die genannte Option gibt es in opsi 4.2 nicht mehr.
Meine Kollegen schauen sich das Problem mit den Debian Paketen noch mal genauer an und melden sich hierüber oder direkt per Release.
Meine Kollegen schauen sich das Problem mit den Debian Paketen noch mal genauer an und melden sich hierüber oder direkt per Release.
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
For productive opsi installations we recommend support contracts.
http://www.uib.de
Re: OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades
Hallo,
ich konnte den Fehler mit den neusten Versionen (opsiconfd 4.2.0.175 und 4.2.0.177) leider nicht nachstellen (Debian 10).
Lässt sich der opsiconfd mit und mit ganz normal starten und stoppen?
Was passiert, wenn das postinst manuell ausgeführt wird?
Welche Versionen haben die anderen Opsi Pakete?
Viele Grüße
fkalweit
ich konnte den Fehler mit den neusten Versionen (opsiconfd 4.2.0.175 und 4.2.0.177) leider nicht nachstellen (Debian 10).
Lässt sich der opsiconfd mit
Code: Alles auswählen
opsiconfd stop
Code: Alles auswählen
opsicofd start -l=5
Was passiert, wenn das postinst
Code: Alles auswählen
/var/lib/dpkg/info/opsiconfd.postinst configure
Welche Versionen haben die anderen Opsi Pakete?
Code: Alles auswählen
dpkg -l | grep opsi
fkalweit
Re: OPSI 4.2-Debian-Pakete: kein daemon-Neustart bei Upgrades
Hallo,
ja, der opsiconfd lässt sich mit "opsiconfd stop" wie auch mit "systemctl ..." stoppen, auch mit dem "-l=5"-Argument. Starten ebenfalls. Beim manuellen Ausführen des postinst-Scriptes kommt:
Die OPSI-Pakete und auch alle anderen installierten Pakete sind tagaktuell:
Wir haben hier mehrere OPSIs laufen, die sind alle gleich aufgebaut, werden aber unabhängig voneinander gepflegt/aktualisiert etc. Die VMs wurden auch alle seinerzeit separat installiert und stammen nicht von einer gleichen Ursprungs-VM ab. Aber bei allen OPSIs fiel das genannte Verhalten auf bei den letzten beiden opsiconfd-Paketupdates (.174 und .175) auf.
Ich würde ggf. jetzt mal das nächste Paketupdate abwarten, ob da der Fehler gleichartig wieder auftritt.
ja, der opsiconfd lässt sich mit "opsiconfd stop" wie auch mit "systemctl ..." stoppen, auch mit dem "-l=5"-Argument. Starten ebenfalls. Beim manuellen Ausführen des postinst-Scriptes kommt:
Code: Alles auswählen
root@centaur:~# /var/lib/dpkg/info/opsiconfd.postinst configure
[5] [2021-06-16 12:17:12.533] [ ] Running opsiconfd setup (setup.py:190)
[5] [2021-06-16 12:17:12.896] [ ] Creating base path: '/var/lib/opsi/config' (File.py:216)
[5] [2021-06-16 12:17:12.959] [ ] Creating opsi base (SQL.py:586)
[5] [2021-06-16 12:17:13.260] [ ] Setting up default values. (ConfigurationData.py:64)
[5] [2021-06-16 12:17:13.422] [ ] Finished setting up default values. (ConfigurationData.py:72)
[5] [2021-06-16 12:17:13.640] [ ] Connection to database 'opsi' on 'localhost' as user 'db_opsi' (MySQL.py:65)
[5] [2021-06-16 12:17:14.158] [ ] Creating opsi base (SQL.py:586)
[5] [2021-06-16 12:17:15.787] [ ] Setting rights on '/etc/shadow' (Rights.py:239)
[5] [2021-06-16 12:17:15.788] [ ] Setting rights on '/var/log/opsi/opsiconfd/opsiconfd.log' (Rights.py:239)
[5] [2021-06-16 12:17:15.789] [ ] Setting rights recursively on '/etc/opsi' (Rights.py:239)
[5] [2021-06-16 12:17:15.790] [ ] Setting rights recursively on '/etc/opsi/ssl' (Rights.py:239)
[5] [2021-06-16 12:17:15.790] [ ] Setting rights on '/etc/opsi/ssl/opsi-ca-cert.pem' (Rights.py:239)
[5] [2021-06-16 12:17:15.791] [ ] Setting rights on '/etc/opsi/ssl/opsi-ca-cert.pem' (Rights.py:239)
[5] [2021-06-16 12:17:15.791] [ ] Setting rights on '/etc/opsi/ssl/opsi-ca-key.pem' (Rights.py:239)
[5] [2021-06-16 12:17:15.792] [ ] Setting rights on '/etc/opsi/ssl/opsiconfd-cert.pem' (Rights.py:239)
[5] [2021-06-16 12:17:15.793] [ ] Setting rights on '/etc/opsi/ssl/opsiconfd-key.pem' (Rights.py:239)
/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
/usr/bin/deb-systemd-helper was not called from dpkg. Exiting.
root@centaur:~#
Code: Alles auswählen
root@centaur:~# dpkg -l|grep opsi
rc opsi-atftpd 0.7.dfsg-7 amd64 advanced TFTP server - opsi version with pcre, fifo and max-blksize patches
ii opsi-configed 4.0.7.6.34-2 all OPSI config editor
ii opsi-linux-bootimage 20210519-1 all opsi bootimage for netboot tasks.
ii opsi-server 4.2.0.54-1 all opsi server
ii opsi-tftpd-hpa 5.2.8-72 amd64 HPA's tftp server
ii opsi-utils 4.2.0.103-1 amd64 Utilities for working with opsi
ii opsiconfd 4.2.0.175-1 amd64 opsi configuration service
ii opsipxeconfd 4.2.0.17-1 amd64 opsi pxe configuration service
rc python-opsi 4.1.1.101-1 all opsi python library
Ich würde ggf. jetzt mal das nächste Paketupdate abwarten, ob da der Fehler gleichartig wieder auftritt.