Univention Bugzilla – Bug 57221
univention-check-template will not find modifications in opsi-auth anymore
Last modified: 2024-04-19 16:03:45 CEST
We have a nearly similar issue as Bug #53051. We will also create an other bug for the special case. In a customer environment opsi4ucs was installed. We replaced this package with opsi-server-full which provides now the opsi-auth file: root@backup:~ # dpkg -S opsi-auth lokale Umleitung von: /etc/pam.d/opsi-auth lokale Umleitung zu: /etc/pam.d/opsi-auth.debian lokale Umleitung von: /etc/pam.d/opsi-auth lokale Umleitung zu: /etc/pam.d/opsi-auth.debian opsi-server-full: /usr/share/opsi-server/ucs/opsi-auth The template /etc/univention/template/files/etc/pam.d/opsi-auth has now a new md5sum, different from the old one in /var/lib/dpkg/status In /var/lib/dpkg/status now we do not have this file mentioned at all. Package: opsi-server-full Status: install ok installed Priority: optional Section: opsiso Installed-Size: 71 Maintainer: uib GmbH <info@uib.de> Architecture: all Source: opsi-server Version: 4.3.1.2-1 Replaces: opsi4ucs Provides: opsi-depotserver (= 4.3), opsi-server (= 4.3) Depends: opsiconfd (>= 4.3.1.0), opsipxeconfd (>= 4.3.1.0), opsi-linux-bootimage (>= 20231116), opsi-tftpd-hpa | opsi-tftp-hpa-server | tftpd-hpa, opsi-utils (>= 4.3.1.0) , opsi-webgui (>= 4.3.21), univention-samba | samba, sudo, wget, unzip, univention-mariadb | univention-mysql | mariadb-server | mysql-server, redis-server (>= 6.0), redis-timeseries, grafana, cabextract, wimtools | wimlib, smbclient | samba-client Conflicts: opsi-server, opsi-server-expert, opsi4ucs, python-opsi (<< 4.2) Description: opsi server opsi server Homepage: http://www.opsi.org old /var/lib/dpkg/status ------------------------ Package: opsi4ucs Status: deinstall ok config-files Priority: optional Section: opsi Installed-Size: 120 Maintainer: uib GmbH <info@uib.de> Architecture: all Version: 4.1.1.10-1 Config-Version: 4.1.1.10-1 Depends: debconf, dpkg, univention-join (>= 5.0.20-1), shell-univention-lib (>= 2.0.17-1), python (>= 2.7), python-opsi (>= 4.1.1.71), opsiconfd (>= 4.1.1.17), opsipxeconfd (>= 4.1), opsi-utils (>= 4.1), opsi-linux-bootimage (>= 20170620), univention-samba4 | univention-samba, univention-s4-connector | univention-samba, sudo, wget, debconf (>= 0.5) | debconf-2.0, univention-config (>= 7.0.25) Conffiles: /etc/opsi/.ucs_temp/opsi-configed.png 5d725e4ef3262f846067e1236a007cdf /etc/opsi/backendManager/dispatch.conf.jsonrpc 35d3b06844a5869114aeb04aa8951f1b /etc/univention/templates/files/etc/pam.d/opsi-auth 41b2fa891296e7a3ea4741c6c0446e16 /etc/univention/templates/info/opsi4ucs.info f77aa7df63b9be489106d8e6b17f6d63 Description: opsi software deployment for ucs opsi4ucs integrates opsi into an ucs server. . http://www.opsi.org root@backup:~ # md5sum /etc/univention/templates/files/etc/pam.d/opsi-auth 65942cfdd76cc47ec5618d4024ddb065 /etc/univention/templates/files/etc/pam.d/opsi-auth So in an environment, with previously installed opsi4ucs the check-template failes and the systemdignose informs the customer about that → which might generate tickets. And in environments, where opsi is new installed, I can manipulate the template as I like, and the univention-check-template will not complain at all. Editing the template now [..] auth [success=done new_authtok_reqd=ok user_unknown=ignore service_err=die authinfo_unavail=die default=ignore] pam_krb5.so no_ccache use_first_pass minimum_uid=1000 auth [success=done new_authtok_reqd=ok user_unknown=die service_err=die authinfo_unavail=die default=die] pam_ldap.so use_first_pass auth required pam_env.so @include common-session 12345 ~ "/etc/univention/templates/files/etc/pam.d/opsi-auth" 24L, 1038C geschrieben resoves in a fine check-template result: root@backup:~ # univention-check-templates but the md5sum changed root@backup:~ # md5sum /etc/univention/templates/files/etc/pam.d/opsi-auth 8b0bceacd79deb78970d7700b8487536 /etc/univention/templates/files/etc/pam.d/opsi-auth
:bomb: `/usr/share/opsi-server/ucs/ucs-join-script.inst`:570 `cp /usr/share/opsi-server/ucs/opsi-auth /etc/univention/templates/files/etc/pam.d/opsi-auth` This is a big no-no as all files below `/etc/` are [conffiles](https://www.debian.org/doc/debian-policy/ch-files.html#configuration-files), which *MUST NOT* be modified by package installation! (In reply to Christina Scheinig from comment #0) > In a customer environment opsi4ucs was installed. We replaced this package > with opsi-server-full which provides now the opsi-auth file: ... > The template /etc/univention/template/files/etc/pam.d/opsi-auth has now a > new md5sum, different from the old one in /var/lib/dpkg/status > In /var/lib/dpkg/status now we do not have this file mentioned at all. If `/e/u/t/f/etc/pam.d/opsi-auth` is no longer mentioned in `/var/lib/dpkg/status`, there is nothing for `u-check-template` to check against. > old /var/lib/dpkg/status > ------------------------ > > Package: opsi4ucs > Status: deinstall ok config-files > Conffiles: > /etc/univention/templates/files/etc/pam.d/opsi-auth 41b2fa891296e7a3ea4741c6c0446e16 With that present, `univention-check-join-status` should report the file as modified: # dpkg-query -Wf '${Status}\n' opsi4ucs deinstall ok config-files # /usr/sbin/univention-check-templates --dpkg /etc/univention/templates/files/etc/pam.d/opsi-auth > root@backup:~ # univention-check-templates Works as expected for me: # dpkg -P opsi4ucs # univention-check-templates # I'm closing this bug as WORKS-FOR-ME as `u-c-t` works as expected; the information provided here looks inconsistent: 1. with `opsi4ucs` only removed, `u-c-t` should report the file as modified. 2. with `opsi4ucs` purged, `u-c-t` should remain quiet. If this is not the case please feel free to re-open this bug.
Reopened, because it does not work for me: So what happens on a live system, with a runnning OPSI, using the same configuration files, and now I purge the old package, which will remove the current in use config files? I guess, this might destroy something in the customer environment. So I maybe have to reinstall opsi, which we decided not to do in the first place, because we do not know, what happens with maybe customized configs.