Univention Bugzilla – Bug 35363
Allow initial run of Directory Policy during rollout
Last modified: 2014-12-08 12:46:29 CET
In UCR we have two different kinds of variables: - Locally set variables (/etc/univention/base.conf) - variables set from a policy (/etc/univention/base-ldap.conf) On UCC desktop systems or on UCS systems both are stored on persistent storage, i.e. if a system is booted and the retrieval of the LDAP policy isn't possible it can fall back to the values retrieved by the last run. On UCC thin clients we use an overlayfs. As such the values written to base-ldap.conf are not available on the next reboot. In UCC 1.0 we had a bug in the initrd; when rolling out a thin client, the system was kept in r/w mode until it was rebooted. As such, the variables stored during the rollout were retained as a fallback. This bug has been fixed in UCC 2.0 and as a consequence no "default UCR values" exist inside the image. We should provide a join script which executes univention-directory-policy. Since the thin client is r/w during the join, this will allow setting a fallback value again. The join script should not enabled by default (e.g. by adding it to a separate binary package). To facilitate the handling of these variables during updates we should also add a new variable like ucc/persistent/ldapucr. If enabled, the values stored in /etc/univention/base-ldap.conf would be kept across the image update.
It should also be checked if the locally cached policy values should be made persistent. This would add more consistency, as several scripts get parameters from the local host and user policy cache host policy cache: /var/cache/ucc/client-policy-"$(hostname)".txt univention-ucc-software-update univention-ucc-setup-multimonitor user policy cache: /var/cache/ucc/user-policy-"$USER".txt sessions/RDP
(In reply to Moritz Muehlenhoff from comment #0) > We should provide a join script which executes univention-directory-policy. A join-script has the disadvantage that it will only be executed once. If the policies are changed later on, the fallback values are outdated. For a customer we added the following line to initramfs-tools/scripts/ucc: > chroot /root /usr/sbin/univention-ucc-fetch-system-policies This reads the policies during each boot and writes the UCR variables persistantly to the image. Maybe that's already sufficient? I think for a product integration, it should be configurable and probably be disabled by default. See Ticket#2014110321000159 for more details.
Idea for a solution: - Add univention-ucc-fetch-system-policies call to the initramfs to always fetch the polices, but save them to a temporary file. Should be saved outside the image to retain the "Do not write into the image on thinclients" rule. - Check this temporary file if a tbd. policy option is set to update policies on every boot - If yes, move the temporary file into the image
The suggested idea would have required a considerable rewrite of the initramfs script, which will not be done as an erratum. To support the different scenarios, two now binary packages were added to the univention-corporate-client source package: * univention-ucc-eval-policies-on-join runs univention-ucc-fetch-system-policies during the initial join process to recreate the ucc 1 behavior. It has to be manually included during the image build process * univention-ucc-eval-policies-on-boot puts a link to univention-ucc-fetch-system-policies at /usr/lib/univention-run-parts-initramfs/. This is a new directory provided by univention-ucc-initramfs >=3.0.2-3. During local boot, the initramfs will do a run-parts on that directory in a R/W mounted ucc-image. This way, system policies are written persistently into the image to serve as up-to-date fallback values r56514 univention-corporate-client 2.0.3-2.103.201412051427 r56515 univention-ucc-initramfs 3.0.2-3.119.201412051431 r56517 yaml
I've built a thin client image which included univention-ucc-eval-policies-on-join; after a rollout of a thin client and a reboot the current /var/cache/ucc/client-polixy-HOSTNAME.txt is written to the overlayfs with the current time stamp. Mounting /ucc_root/IMAGE to a loopback device provides the fallback values with the old timestamp during rollout of the client.
I've built a thin client image which included univention-ucc-eval-policies-on-boot; after a rollout of a thin client and a reboot the current /var/cache/ucc/client-polixy-HOSTNAME.txt is written to the overlayfs with the current time stamp. Mounting /ucc_root/IMAGE to a loopback device provides the fallback values with the current time stamp (as of system boot) as well. The same behaviour could be seen after a reboot.
http://errata.univention.de/ucc/2.0/5.html http://errata.univention.de/ucc/2.0/6.html