File operations before package installation

[martin-29]

I have a question regarding the capabilities of ELBE related to a specific problem we currently try to solve.

The specific scenario is the following:

We would like to fix the UIDs and GIDs of users and groups created by packages in their postinst.
Which is often required in an A/B update scenario for embedded devices where flipped IDs can cause problems when having update persistent files.

The workaround of fixing the ownership of files during some update hook is not a solution we want to go with, especially because it should be fairly easy to fix IDs by already existing mechanisms during the build.

The idea is to create conf files in /etc/adduser-pool.d for such packages or in case of packages which rely on systemd-sysuser a file in /etc/sysuser.d/ which masks the file from the package.

In addition, we need to adapt the default config of adduser (/etc/adduser.conf) to enable the lookup inside /etc/adduser-pool.d/.

Normally we can do such things quite simply using the archivedir or the finetuning.

But in this case the files would be required before the installation of packages and not afterwards.

Is there any already existing mechanism in ELBE we can rely on to achieve our goal?
And if not, is that something you think would be worth to implement?

[t-8ch]

Does this also affect packages installed through debootstrap?

How often does this fixup logic change? Would it be enough to have a custom Debian package which provides these configuration files and install it first?

[martin-29]

We also thought about delivering the conf files via a custom Debian package, but in a test, we discovered that this only worked for most of the users and groups. We thought this was just a problem with the installation order.

But you are right, there are some exceptions were even packages installed through debootstrap create users or groups without fixed IDs like systemd (systemd-journal and systemd-network).

The IDs from base-passwd are already fixed and here we shouldn't have any problems here. And if so, there is already a mechanism with update-passwd that could help us fix the IDs during the finetuning.

So if we can handling all "dynamic" IDs using a custom Debian package, that would be fine for us. But if it only fixes the problem for most of the packages, we still need a workaround from time to time.

Is there a way to include this package earlier or within the debootstrap process?
The include for debootstrap probably won't work for a custom package on a different package source.

[t-8ch]

Debootstrap implements its own package management logic and doesn't use apt. It can't handle different repositories, configurations, hooks, etc.

As you only want to modify the behavior of package postinst scripts, which are executed at the end of the installation process, any files in your custom package should already be there when other packages scripts are invoked.
(Except for Essential packages, but there are already installed by debootstrap anyways)
While this ordering doesn't seem to be guaranteed [0], I don't see it changing anytime soon.

[0] https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#summary-of-ways-maintainer-scripts-are-called

[martin-29]

Ok that makes sense.

I made a quick manual test with debootstrap on my hostsystem where I copied the relevant conf files between the first and the second stage, so before the packages installed by debootstrap are configured.
This worked fine for me.

Do you think it would be a useful feature for ELBE to have a mechanism like another archivedir for the debootstrap stage?

Example:

<debootstrap>
	<include>ca-certificates</include>
        <variant>minbase</variant>
        <archivedir>rfs_archive/ids_override</archivedir>
</debootstrap>

[t-8ch]

I think it's a very niche usecase. If you can do with a custom package, that would be preferable.

[martin-29]

Ok I understand your point.
Thanks for the exchange.

We will think about that topic again and maybe we go with a solution, which fix the IDs after the creation, to be able to handle all cases (similar to update-passwd, but with a different ID range).

[t-8ch]

Does the custom package not work?

[martin-29]

It works for all packages and their dependencies from the pkg-list, but not for packages which are installed by debootstrap.

So, there is still the possibility that an ID (for example of systemd-journal) changes and then we need to fix that anyway.

[t-8ch]

Ah, I misread you message above.

I made a quick manual test with debootstrap on my hostsystem where I copied the relevant conf files between the first and the second stage, so before the packages installed by debootstrap are configured.
This worked fine for me.

I interpreted it as stage 1 being debootstrap and stage 2 being apt.

I'll think about it.