Re: [gentoo-dev] usr merge

[Richard Yao]

On 04/06/2016 12:33 PM, Richard Yao wrote:
> On 04/06/2016 12:20 PM, Alexis Ballier wrote:
>> On Wednesday, April 6, 2016 6:06:35 PM CEST, Richard Yao wrote:
>>
>>> That is unless you put per-system state in /usr/local, do symlinks to it
>>> in / and mount /usr/local as part of system boot, which is the other way
>>> of doing this. I have seen a variant of this done in asuswrt-merlin on
>>> routers.
>>
>> This doesnt seem to have anything to do with what I was describing.
>>
>> Another option I'm using a lot is nfsroot. This doesn't have the same
>> level of flexibility: running multiple hosts with nfsroot and thus
>> shared /etc/fstab tends to be annoying.
>>
>>>> See https://fedoraproject.org/wiki/Features/UsrMove for a more complete
>>>> discussion.
>>>
>>> That does not address the problems of supporting this configuration in a
>>> rolling release.
>>>
>>> Formats in /etc can fall out of sync with software in /usr. If boot
>>> options change, the stuff in /etc/init.d is not updated. If you add
>>> software, the update to /etc/init.d is omitted. If you have a baselayout
>>> change, it is not propagated.
>>
>> Ever heard of CONFIG_PROTECT ? :) What you describe is already what
>> happens and what most people want.
>
> Leveraging the /usr merge to enable easier updating of multiple systems
> means that you are updating a Gentoo system image on a build server,
> snapshotting /usr both before/after the update and then distributing the
> delta on /usr to other systems without any of the changes that occurred
> outside of /usr. A proper update requires finding all of those changes
> and then applying them manually. That really is not the same thing that
> RHEL and Solaris have, where the necessity of propagating changes
> outside of /usr is minimized by having none to propagate.

After thinking about it some more, maybe git can be (ab)used to do this
by having the image's root be a git repository with /usr in .gitingore.

When updates are done, you would run etc-update on the build host by
committing the changes to / into git with ./usr in .gitignore. Then you
would have the delta from /usr via whatever mechanism that the user
wishes to use with a patch on / from the build system that can be merged
into each target's / repository. The procedure would require more effort
than what Solaris and RHEL do, but if documented, it should fix the
partial update problem that occurs when you do a /usr merge in a rolling
release and then do what people on Solaris and RHEL do to update systems
configured for updates via deltas of /usr.

To give an example, lets assume:

1. /path/to/build/image has a git repository with ./usr in .gitignore on
the build host while the targets have the same (with paths being / and
/usr of course).

2. Things are on ZFS on the build host and the targets.

3. There is a snapshot of the build environment that the targets have.

4. tank/BUILD/gentoo is the / and tank/BUILD/gentoo/usr is the /usr on
the build host.

5. The targets have rpool/SYSTEM/USR/gentoo as their /usr and
rpool/SYSTEM/USR is set readonly (so /usr is not modified due to
inheritance of readonly).

The delta generation would be something like this:

# Setup build environment
sudo -i /path/to/enter-container.sh /path/to/build/image
https://gist.github.com/ryao/3c345f206b19c9795109)

# Update portage
emerge-webrsync / emerge-delta-webrsync / emerge --sync
# Preferably one of the first two with PORTAGE_GPG_* configured

# Install updates
emerge -avDuN @world

# Update config files
etc-update

# Exit build environment
exit

# Commit changes to /
git -C /path/to/build/image commit -a

# Snapshot the build environment
sudo -i zfs snapshot -r tank/BUILD/gentoo@"$(date +%Y%m%d)"

Then a child could be updated by something like:

# First /usr
zfs send -i tank/BUILD/gentoo@previous tank/BUILD/gentoo/usr@"$(date
+%Y%m%d)" | ssh root@$CHILD zfs recv rpool/SYSTEM/USR/gentoo

# Then /
git -C /path/to/build/image diff HEAD^ | ssh root@$CHILD git -C
/other/location apply

# If conflicts occurred, fix whatever was broken
ssh root@$CHILD

# Reboot / restart services
reboot

This is intended to only be an example, but there are a few problems
with this simple example that are worth mentioning:

1. You probably want to have a shell into the system in case the update
to / does not go well, which makes the update to / somewhat hackish.

2. The way Solaris does things is to have boot environments where the
change is in a different boot environment that only takes effect as part
of a reboot. If you are doing a boot environment type thing, you could
probably update / for the new reboot, although you would want to
implement easy rollback if anything goes wrong.

That step on / is somewhat hackish, but it is intended to be an example.

Doing something similar to what Solaris did to make management of
multiple systems easier is likely doable with some way of handling
changes outside of /usr.

> I do not understand how CONFIG_PROTECT is relevant here. Whatever
> CONFIG_PROTECT did was done on the build system. The systems receiving
> the updates via ZFS send/recv or some similar mechanism are not going to
> have CONFIG_PROTECT evaluated. Even if it were somehow evaluated, all of
> the paths in CONFIG_PROTECT should be outside of /usr anyway.