Univention Bugzilla – Bug 28284
Move UCR Template and Info-Files from /etc/univention/ to /usr/share/univention-config/
Last modified: 2023-10-13 10:12:59 CEST
Es gibt eine Reihe von Bugs (Bug #3382, Bug #24010, Bug #24867, Bug #26825, Bug #27872, ...) die sich mehr oder minder alle auf das gleiche Problem zurückführen lassen: Die Template-Dateien liegen unter /etc/ und sind dmait für Debian conffiles, d.h. sie werden bei Updates nicht überschrieben und beim remove ohne purge nicht entfernt. Das führt derzeit zu hässlichen Problemen beim Einrichten und entfernen der dpkg-Diversions und erfodert viel Handarbeit, um bei Paket-Deinstallation diese wieder los zu werden. Aus diesem Grund sollten wir die UCR-Template-Dateien und die zugehörigen Meta-Dateien von /etc/univention/ nach /usr/share/univention-config/ verschieben. Um dem Benutzer weiterhin die Möglichkeit zu geben, die Templates für seine Zwecke anzupassen, sollten wir aber /etc/univention/templates/ beibehalten und UCR so anpassen, daß zuerst die Datei aus /etc/** verwendet wird, sofern diese vorhanden ist. Ansonsten wir die Datei aus /usr/share/univention-config/** verwendet. (udev und systemd implementieren die selbe Logik)
Um ein Template "$FILE" beim Upgrade vom Paket "$PACKAGE" zu löschen sollte man derzeit folgendes machen: debian/$PACKAGE.preinst: #!/bin/sh #DEBHELPER# dpkg-maintscript-helper rm_conffile "/etc/univention/template/files/$FILE" -- "$@" debian/$PACKAGE.postinst: #!/bin/sh #DEBHELPER# dpkg-maintscript-helper rm_conffile "/etc/univention/template/files/$FILE" -- "$@" dpkg-trigger univention-config-wrapper debian/$PACKAGE.postrm: #!/bin/sh #DEBHELPER# dpkg-maintscript-helper rm_conffile "/etc/univention/template/files/$FILE" -- "$@"
This issue has been filed against the UCS version "unstable" which does not really exist. Please change the version value.
Can't we move the directory and make /etc/univention/templates a symlink?
(In reply to Florian Best from comment #3) > Can't we move the directory and make /etc/univention/templates a symlink? No: /etc/ is special for dpkg and it tracks all files therein as "conffiles". The whole point of this bug is that I don't want dpkg to track them, as updating templates is more complex and error prone. The current templates need to be de-registered from dpkg using "dpkg-maintscript-helper rm_conffile" and need to me moved to /usr/share/ anyway. Also note that replacing directories by symlink and vis-versa is buggy in dpkg: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=626203>
Please let's fix this.
A second Problem that arises due to the templates being in /etc is, that some security scanners raise error messages. The two main ones are: a) they do a "find | grep <filename>" over the directory and then compare the UCR template to the expected value b) The second one is, that the Filesystem Hierarchy Standard says "The /etc hierarchy contains configuration files. A "configuration file" is a local file used to control the operation of a program; it must be static and cannot be an executable binary. [4]" and thus any executable is considered an error. (Appart from init scripts apparently)
(In reply to Kevin Dominik Korte from comment #6) > A second Problem that arises due to the templates being in /etc is, that > some security scanners raise error messages. > > The two main ones are: > a) they do a "find | grep <filename>" over the directory and then compare > the UCR template to the expected value Then fix the security scanners. It's not a bug to have other configuration files there. > b) The second one is, that the Filesystem Hierarchy Standard says "The /etc > hierarchy contains configuration files. A "configuration file" is a local > file used to control the operation of a program; it must be static and > cannot be an executable binary. [4]" and thus any executable is considered > an error. (Apart from init scripts apparently) "executable" != binary, as "scripts" are executable too. The keyword here is "binary" - our UCR templates are "text" files - so NOT-A-BUG.
This issue has been filed against UCS 4.2. UCS 4.2 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.
Still the same issue after 8 years...
(In reply to Philipp Hahn from comment #9) > Still the same issue after 8 years... Any chance that we can fix this in UCS 5?
(In reply to Florian Best from comment #10) > (In reply to Philipp Hahn from comment #9) > > Still the same issue after 8 years... > Any chance that we can fix this in UCS 5? 1. Modify tools to install to /usr/share/univention-config/ - univention-install-config-registry - univention-install-config-registry-info - univention-install-service-info 2. Modify Python modules to prefer files from /etc/univention/ over /usr/share/univention-config/ - univention.service_info - univention.config_registry_info - univention.config_registry.handler 3. For every 140 source package in UCS - Bump debian/changelog - for every binary package shipping UCR templates - Create an entry in debian/$binpkg.maintscript to remove the file from /etc/ if unmodified rm_conffile /etc/univention/... $ver~ - re-build package
4. Update documentation - manual - developer-reference - extended/domain