Add documentation for tukit.conf (bsc#1192307)

[aplanas]

No description provided.

[laenion]

I'll merge this for transactional-update 4.0 along with a man page for tukit itself (which is also still undocumented yet).

Just one note: I think we never want to add /var/lib to the list of bind mounts.
The whole concept of transactional updates is based around the concept that an update can not break the currently running system. By bind-mounting such a vital directory that whole concept is basically nullified - and on the contrary will cause significant side effects:

/var/lib contains a lot of data, including databases, docker images or sssd data. That data is often bound to a specific version of the software.
A simple example: Imagine that a database package is updated, and that update also includes a schema change which the post script will perform if a database is found. Now we run into the situation that the database is still running the old version in the currently active system and suddenly gets confronted with a changed and probably incompatible new data set belonging to the new version (with the new database daemon only available in the new snapshot which hasn't been booted yet). Due to the bind mount however the new data leaks into the current system. This is playing with fire.

Because of that I'm really interested to hear what the use case for adding /var/lib to the bind mounts would be.

[aplanas]

I'll merge this for transactional-update 4.0 along with a man page for tukit itself (which is also still undocumented yet).

Sure. Will you prepare this?

Just one note: I think we never want to add /var/lib to the list of bind mounts. The whole concept of transactional updates is based around the concept that an update can not break the currently running system. By bind-mounting such a vital directory that whole concept is basically nullified - and on the contrary will cause significant side effects:

Indeed.

The issue is that there are some kubernetes installers that are doing this: updating /var/lib, adding directories there (like /var/lib/rancher). This can be view as a bug in the installer (should use something different that /var/lib), but sadly is required as today.

/var/lib contains a lot of data, including databases, docker images or sssd data. That data is often bound to a specific version of the software. A simple example: Imagine that a database package is updated, and that update also includes a schema change which the post script will perform if a database is found. Now we run into the situation that the database is still running the old version in the currently active system and suddenly gets confronted with a changed and probably incompatible new data set belonging to the new version (with the new database daemon only available in the new snapshot which hasn't been booted yet). Due to the bind mount however the new data leaks into the current system. This is playing with fire.

I will add as a comment in the documentation.

Because of that I'm really interested to hear what the use case for adding /var/lib to the bind mounts would be.

Rancher.

[laenion]

Because of that I'm really interested to hear what the use case for adding /var/lib to the bind mounts would be.

Rancher.

But I guess to bind mount /var/lib/rancher would be enough then? Otherwise the whole concept of transactional-update is spoiled...

[aplanas]

Because of that I'm really interested to hear what the use case for adding /var/lib to the bind mounts would be.

Rancher.

But I guess to bind mount /var/lib/rancher would be enough then? Otherwise the whole concept of transactional-update is spoiled...

IIUC not always, as this can be created by the installer. This should be OK if:

1. The user create first the directory.

2. There is an specific partition created during the installation, and is already in fstab

[aplanas]

I changed the example, and I try to integrate the dangers of exposing /var/lib

[MaxiMii05]

Just seeing this by chance and thought I could suggest fixing a typo and maybe a logical error (depending on how it's meant).
is -> in
should -> could

[aplanas]

I found and fixed the "is -> in", but I am not sure about the second one.

Thanks!

[laenion]

I agree on the "should" -> "could" comment: One may or could be tempted, but one never should be tempted ;-)

Again, to avoid the "we" form I'd suggest you could write "... one may be tempted to ...".

[laenion]

Thanks a lot for the documentation! Generally I really like it, just a few nits inline.

[laenion]

I agree on the "should" -> "could" comment: One may or could be tempted, but one never should be tempted ;-)

Again, to avoid the "we" form I'd suggest you could write "... one may be tempted to ...".

[laenion]

The 4.0 release is very near, so finally merging this PR.