Bug 35363 - Allow initial run of Directory Policy during rollout
Allow initial run of Directory Policy during rollout
Status: CLOSED FIXED
Product: Univention Corporate Client (UCC)
Classification: Unclassified
Component: initrd
unspecified
Other Linux
: P5 enhancement
: UCC 2.0-errata
Assigned To: Erik Damrose
Moritz Muehlenhoff
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-07-15 13:03 CEST by Moritz Muehlenhoff
Modified: 2014-12-08 12:46 CET (History)
4 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Moritz Muehlenhoff univentionstaff 2014-07-15 13:03:40 CEST
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.
Comment 1 Erik Damrose univentionstaff 2014-07-15 13:32:39 CEST
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
Comment 2 Michael Grandjean univentionstaff 2014-11-13 20:59:48 CET
(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.
Comment 3 Erik Damrose univentionstaff 2014-11-14 09:28:00 CET
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
Comment 4 Erik Damrose univentionstaff 2014-12-05 14:48:55 CET
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
Comment 5 Moritz Muehlenhoff univentionstaff 2014-12-08 11:20:38 CET
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.
Comment 6 Moritz Muehlenhoff univentionstaff 2014-12-08 12:17:07 CET
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.