Bug#924401: base-files fails postinst when base-passwd is unpacked

[Russ Allbery]

Control: reassign 924401 base-passwd,base-files
Control: clone 924401 -1
Control: reassign -1 Essential packages only provide functionality after being 
configured
Control: tags -1 patch

Hi all,

Trimming the recipient list to just the relevant maintainers and those who
proposed and (I believe) seconded a change.

This is a very long bug with a *ton* of very useful information about
bootstrapping Debian that I hope someone will capture and document
somewhere, but after reviewing the whole thing, I believe there is only
one actionable change for Policy buried in the middle of it.  It's also
currently assigned to three different packages, and I certainly don't feel
entitled to close the broader issue by applying that change.  Therefore,
I'm going to remove debian-policy from this bug, and create a new bug to
handle just the proposed Policy change discussed below.

(For what it's worth, I love Guillem's idea of converting more maintainer
scripts into declarative metadata and getting out of the problen that
way.)

Helmut Grohne  writes:

> I think at least Guillem and Santiago were arguing that policy should
> not be applied to bootstrap. While I don't like that view, I do find it
> reasonable. It can be made explicit in section 3.8 quite easily:

>  Since dpkg will not prevent upgrading of other packages while an
>  ``essential`` package is in an unconfigured state, all ``essential``
>  packages must supply all of their core functionality even when
> -unconfigured. If the package cannot satisfy this requirement it must not
> +unconfigured after being configured at least once.
> +If the package cannot satisfy this requirement it must not
>  be tagged as essential, and any packages depending on this package must
>  instead have explicit dependency fields as appropriate.

This change looks correct to me based on the discussion in the bug but I
don't know enough to independently confirm that.  I believe Santiago
effectively seconded this change in:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924401#91

It needs one more second.  Ideally, I'd like this to be someone else who
has a lot of understanding of the semantics of essential packages
(Guillem, for instance).  Alas, due to the ordering of the BTS actions,
you may have to hunt down the cloned bug against debian-policy to second
it.

-- 
Russ Allbery (r...@debian.org)  

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

On Fri, Mar 15, 2019 at 04:51:11PM +0100, Helmut Grohne wrote:

>  Since dpkg will not prevent upgrading of other packages while an
>  ``essential`` package is in an unconfigured state, all ``essential``
>  packages must supply all of their core functionality even when
> -unconfigured. If the package cannot satisfy this requirement it must not
> +unconfigured after being configured at least once.
> +If the package cannot satisfy this requirement it must not
>  be tagged as essential, and any packages depending on this package must
>  instead have explicit dependency fields as appropriate.

More to the point: Packages that may have the "awk" role, which is
considered both essential and virtual, will definitely never work
until configured for the first time, because /usr/bin/awk is handled
by the alternatives mechanism, which runs in the postinst.

In other words, your proposed patch seems completely ok to me, as it
represents (what I think it has always been) Debian Policy accurately.

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

On Fri, Mar 15, 2019 at 04:51:11PM +0100, Helmut Grohne wrote:

>  Since dpkg will not prevent upgrading of other packages while an
>  ``essential`` package is in an unconfigured state, all ``essential``
>  packages must supply all of their core functionality even when
> -unconfigured. If the package cannot satisfy this requirement it must not
> +unconfigured after being configured at least once.
> +If the package cannot satisfy this requirement it must not
>  be tagged as essential, and any packages depending on this package must
>  instead have explicit dependency fields as appropriate.

I think that has always been the spirit of Debian Policy, which is
also consistent with the behaviour of current bootstrap tools.

(Note that it's a paragraph which is talking about upgrades, and
related to the fact that dpkg "unconfigures" a package before
upgrading it).

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Helmut Grohne]

Hi Santiago,

On Fri, Mar 15, 2019 at 11:58:12AM +0100, Santiago Vila wrote:
> blame for such bug, is annoying me. (So, Helmut, please file a bug
> in the bootstrapping tool which does not work for you, and do not
> try to fix it here).

I refuse the view that multistrap is buggy. You cite undocumented
behaviour as a reason to mark it buggy. However, multistrap relies on
semantics presently assured by policy. Given that policy talks about
unpacked packages, applying it to bootstrap (in its present wording) is
reasonable. There is a bug somewhere between policy, base-files and
base-passwd, which is exactly how I filed it.  Once this bug is fixed
(in any one of these components), additional bugs can result from that.

I think at least Guillem and Santiago were arguing that policy should
not be applied to bootstrap. While I don't like that view, I do find it
reasonable. It can be made explicit in section 3.8 quite easily:

 Since dpkg will not prevent upgrading of other packages while an
 ``essential`` package is in an unconfigured state, all ``essential``
 packages must supply all of their core functionality even when
-unconfigured. If the package cannot satisfy this requirement it must not
+unconfigured after being configured at least once.
+If the package cannot satisfy this requirement it must not
 be tagged as essential, and any packages depending on this package must
 instead have explicit dependency fields as appropriate.

After doing so, we'll likely need to do something about mmdebstrap and
multistrap as well as furthering our utopia about declarative
replacements for maintainer scripts.

Helmut

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

> > In a practical level, because you already see what happens when
> > you configure any package which uses users defined in /etc/passwd
> > without a minimal /etc/passwd in place. Again in a practical level,
> > once we know it, we can't pretend that we don't know it.
> 
> That's what the traditional bootstrapping tools have been doing, and
> it's all kinds of wrong. For example whether a system even uses an
> /etc/passwd is an implementation detail of that system. Some don't
> even have one. If we added support for such a port, then in addition
> to patching the relevant code that directly deals with this, we'd
> need to also adapt all the bootstrappers to cope with this. Instead
> of them just automatically just working out of the box, w/o needing
> to hardcode package names, internal implementation details, etc.

Following such reasoning, the uids defined in /etc/passwd are also an
implementation detail that base-files should not need to know. Moving
such information from base-passwd to base-files and hardcoding it
seems a step in the wrong direction for exactly the same reasons.

> > You want to create a common framework to reuse such knowledge and
> > share it between different bootstrapping tools? Fine, maybe then new
> > bootstrapping tools finally realize that there must be a valid
> > /etc/passwd before configuring anything else.
> 
> That knowledge is already in each relevant package, the passwd stuff
> in the base-passwd package (in Debian) or possibly elsewhere in other
> systems.

So, base-files does not need to know the uids defined in /etc/passwd
because such information is already in the base-passwd package.

> > Please reassign to whatever bootstrapping tool is not doing its job
> > properly. Sorry, but this is starting to annoy me.
> 
> I'm sorry to hear, but TBH, I'm a bit puzzled about your replies. That
> might be due to the apparent conflation of trying to look for a better
> solution to the problem presented, and how to incrementally transition
> to such a bettter place smoothly already right now?
> 
> It's not clear to me whether you oppose the discussion about such
> proposals because you consider the current bootstrapping method the
> ideal solution, or whether you oppose any progressive move towards
> those, as in an all or nothing scenario?

I'm not opposed to discussing new proposals. The current bootstrap
methods may not be ideal, but they are ok to me as far as they do
their job.

My annoyance, as you have rightly pointed out, comes from conflating
the discussion of new proposals with the present problem in the
present bootstrapping tool.

New proposals to bootstrap Debian are welcome here. Trying to fix a
bug in a bootstrapping tool by changing base-files, which is not to
blame for such bug, is annoying me. (So, Helmut, please file a bug
in the bootstrapping tool which does not work for you, and do not
try to fix it here).

I do not exclude the possibility of incremental changes, but the ones
I've heard so far seem steps in the wrong direction to me.


One idea that was floating around was to make dependencies on
essential packages from essential packages explicit instead of
implicit. Does anyone have any idea about how such thing would work?
Would that improve things? Would dpkg and current bootstrapping tools
allow internal simplification or "factoring" if we did that?
Would they still work at all?

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Guillem Jover]

Hi!

On Fri, 2019-03-15 at 00:37:33 +0100, Santiago Vila wrote:
> Maybe, but this is neither a new miscellaneous file nor a new
> bootstrapping action. This is yet another bootstrapping tool
> forgetting the lessons learned from the other bootstrapping tools.

My impression though is that the general consensus is that the
lessons learned from the traditional bootstrapping tools, is that
they are doing it wrong. :)

> Helmut Grohne wrote:
> > How is a bootstrap tool supposed to know
> > that it must configure base-passwd before base-files?
> 
> In a theoretical level, because it's their job to know such things.

As it's been mentioned elsewhere, this is not a property that is
necessary. In the same way that bootstrapping an architecture should
not require manually tracking the order of the build-dependencies
and cycle breakings (which was the case before), etc, even if that
might still be partially the case now, while we have not fully added
build profiles and cross-building support everywhere necessary.

> In a practical level, because you already see what happens when
> you configure any package which uses users defined in /etc/passwd
> without a minimal /etc/passwd in place. Again in a practical level,
> once we know it, we can't pretend that we don't know it.

That's what the traditional bootstrapping tools have been doing, and
it's all kinds of wrong. For example whether a system even uses an
/etc/passwd is an implementation detail of that system. Some don't
even have one. If we added support for such a port, then in addition
to patching the relevant code that directly deals with this, we'd
need to also adapt all the bootstrappers to cope with this. Instead
of them just automatically just working out of the box, w/o needing
to hardcode package names, internal implementation details, etc.

> You want to create a common framework to reuse such knowledge and
> share it between different bootstrapping tools? Fine, maybe then new
> bootstrapping tools finally realize that there must be a valid
> /etc/passwd before configuring anything else.

That knowledge is already in each relevant package, the passwd stuff
in the base-passwd package (in Debian) or possibly elsewhere in other
systems.

> But lack of such a common framework is not an excuse to ditch the
> definition of essential and start doing things "just in case"
> some new bootstrapping tool forgets again that there must
> be a valid /etc/passwd before configuring anything else.

You seem to keep using the definition of essential to justify this,
but as I've mentioned elsehwere, the definition of essential does not
cover what happends before the system has been bootstrapped. If we'd
consider that policy already covers it, that would mean most essential
packages are RC buggy.

(And as I've mention on another reply, dpkg f.ex. is already falling
back to numeric UIDs "just in case". :)

> Please reassign to whatever bootstrapping tool is not doing its job
> properly. Sorry, but this is starting to annoy me.

I'm sorry to hear, but TBH, I'm a bit puzzled about your replies. That
might be due to the apparent conflation of trying to look for a better
solution to the problem presented, and how to incrementally transition
to such a bettter place smoothly already right now?

It's not clear to me whether you oppose the discussion about such
proposals because you consider the current bootstrapping method the
ideal solution, or whether you oppose any progressive move towards
those, as in an all or nothing scenario?

Thanks,
Guillem

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

On Thu, Mar 14, 2019 at 10:37:46AM +, Simon McVittie wrote:
> On Thu, 14 Mar 2019 at 10:21:30 +0100, Santiago Vila wrote:
> > The reason I'm often asked to add hacks to base-files.postinst is only
> > that base-files is usually configured in the second place
> 
> I think it's also fair to say that base-files is exactly a collection of
> the miscellaneous files and bootstrapping actions that no other package
> seems particularly responsible for, so if a new miscellaneous file or a
> new bootstrapping action appears, base-files seems a reasonably natural
> home for it (or at least, more natural than a package that contains
> non-bootstrapping code, for example bash or debianutils).

Maybe, but this is neither a new miscellaneous file nor a new
bootstrapping action. This is yet another bootstrapping tool
forgetting the lessons learned from the other bootstrapping tools.

Helmut Grohne wrote:
> If we agree that this would be the best fix for buster, I volunteer to
> write a patch for base-files to implement that.

No, I do not agree, so please don't.

> How is a bootstrap tool supposed to know
> that it must configure base-passwd before base-files?

In a theoretical level, because it's their job to know such things.

In a practical level, because you already see what happens when
you configure any package which uses users defined in /etc/passwd
without a minimal /etc/passwd in place. Again in a practical level,
once we know it, we can't pretend that we don't know it.

You want to create a common framework to reuse such knowledge and
share it between different bootstrapping tools? Fine, maybe then new
bootstrapping tools finally realize that there must be a valid
/etc/passwd before configuring anything else.
 
But lack of such a common framework is not an excuse to ditch the
definition of essential and start doing things "just in case"
some new bootstrapping tool forgets again that there must
be a valid /etc/passwd before configuring anything else.

Please reassign to whatever bootstrapping tool is not doing its job
properly. Sorry, but this is starting to annoy me.

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Helmut Grohne]

On Thu, Mar 14, 2019 at 07:50:27AM +0100, Johannes Schauer wrote:
> > I would certainly consider a lot cleaner to add a new field to base-files in
> > the form "Bootstrap-Depends: base-passwd" than converting all chowns in
> > postinst to use integer numbers.
> 
> I agree that we should not expect maintainers to write numeric user and group
> ids into their maintainer scripts. This is not only hard to write but also 
> hard
> to read and maintain. In my opinion, using numeric ids should only be a
> temporary measure until we have a declarative method or other helper that does
> the correct translation instead. But since no such helper exists right now,
> numeric ids are probably the best way to fix this bug for buster.

I object to this view. It was never suggested to have anyone write
numeric ids. What Simon suggested was writing symbolic names and have
the package build use static allocations to translate these symbolic
names to numeric ids at build time. This is a whole different story than
having to write them.

If we agree that this would be the best fix for buster, I volunteer to
write a patch for base-files to implement that. Doing so would be easier
if using a more featureful template interpolation language than sed. Do
you (Santiago) have any preference here? I could think of
m4/sh/perl/python. sed will work, but might be ugly.

On Thu, 14 Mar 2019 10:21:30 +0100, Santiago Vila wrote:
> The way I see it, if base-files fails during bootstrapping it's not
> because it does not "help" the bootstrapping tool, but because the
> bootstrapping tool didn't bootstrap base-passwd in the first place.

I think this view is difficult. How is a bootstrap tool supposed to know
that it must configure base-passwd before base-files? Where should we
document that? Basically everyone in this thread except you argued that
requiring such out-of-band knowledge is bad. And if that really is
required, I think policy should be a little explicit about that. Even
though Guillem found a paragraph that supports this view, it is quite
implicit at present.

> Now the question would be if we really need to add a paragraph to
> Debian Policy, "Recommendations/guidelines for bootstrapping tools",
> clearly stating that bootstrapping tools should bootstrap base-passwd
> before trying to configure base-files. I think that would be quite
> clear by now, but I could be wrong.

I actually don't think that policy should document this dependency,
because it really should be an implementation detail. From my
perspective, making it explicit that policy only applies post-bootstrap
is sufficient (e.g. copying the "configured at least once" language from
section 6.5).

If on the other hand, we require the literal interpretation that
base-files must be able to configure while other essential packages are
only unpacked and never configured, it all becomes a lot easier to
reason about. Simon's proposal implements that easily and is a
maintainable solution.

Helmut

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Simon McVittie]

On Thu, 14 Mar 2019 at 10:21:30 +0100, Santiago Vila wrote:
> The reason I'm often asked to add hacks to base-files.postinst is only
> that base-files is usually configured in the second place

I think it's also fair to say that base-files is exactly a collection of
the miscellaneous files and bootstrapping actions that no other package
seems particularly responsible for, so if a new miscellaneous file or a
new bootstrapping action appears, base-files seems a reasonably natural
home for it (or at least, more natural than a package that contains
non-bootstrapping code, for example bash or debianutils).

smcv

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

On Thu, Mar 14, 2019 at 07:50:27AM +0100, Johannes Schauer wrote:

> I agree that we should not expect maintainers to write numeric user and group
> ids into their maintainer scripts. This is not only hard to write but also 
> hard
> to read and maintain. In my opinion, using numeric ids should only be a
> temporary measure until we have a declarative method or other helper that does
> the correct translation instead. But since no such helper exists right now,
> numeric ids are probably the best way to fix this bug for buster.
> 
> I was now als able to trigger this bug in mmdebstrap. Here is how to populate 
> a
> chroot directory with a set of packages that is less than the Essential:yes 
> set
> and based on busybox:
> 
> sudo mmdebstrap --mode=root --variant=custom \
> --include=dpkg,busybox,libc-bin,base-files,base-passwd,debianutils \
> --setup-hook='mkdir -p "$1/bin"' \
> --setup-hook='for p in awk cat chmod chown cp diff echo env grep less ln 
> mkdir mount rm rmdir sed sh sleep sort touch uname; do ln -s busybox 
> "$1/bin/$p"; done' \
> --setup-hook='echo root:x:0:0:root:/root:/bin/sh > "$1/etc/passwd"' \
> --setup-hook='printf "root:x:0:\nmail:x:8:\nutmp:x:43:\n" > 
> "$1/etc/group"' \
> unstable ./debian-unstable-busybox
> 
> As one can see, I had to create a minimal /etc/passwd and /etc/group inside 
> the
> chroot filled with entries for root, mail and utmp for the base-files postinst
> to work. Using mmdebstrap like that is indeed quite a hack right now, so I'm
> not claiming that mmdebstrap should be the reason for base-files to change.

I think from all the above that it should be not only mmdebstrap but
maybe also every other bootstrapping tool the one to create a minimal
/etc/passwd to bootstrap base-passwd.

The reason I'm often asked to add hacks to base-files.postinst is only
that base-files is usually configured in the second place, but the same
thing base-files does could be done by any other essential package.

The way I see it, if base-files fails during bootstrapping it's not
because it does not "help" the bootstrapping tool, but because the
bootstrapping tool didn't bootstrap base-passwd in the first place.

> But maybe this is a useful way for you of how to see this problem
> happening for yourself.

If those setup hooks are the workaround for the problem, I see the
problem in this case, and in my opinion creating a minimal /etc/passwd
and configuring base-passwd before base-files would be the optimal way
to fix this particular problem (i.e. moving two of the setup hooks
into mmdebstrap itself).

Now the question would be if we really need to add a paragraph to
Debian Policy, "Recommendations/guidelines for bootstrapping tools",
clearly stating that bootstrapping tools should bootstrap base-passwd
before trying to configure base-files. I think that would be quite
clear by now, but I could be wrong.

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Johannes Schauer]

Hi Santiago,

Quoting Santiago Vila (2019-03-13 13:50:11)
> On Wed, Mar 13, 2019 at 01:15:02PM +0100, Johannes Schauer wrote:
> > I'm not advocating for doing "hacks here and there so that bootstrapping 
> > tools
> > work properly" as you put it but that we think about the question of whether
> > maybe there is a better way to populate an empty directory with software
> > components that does not require as much magic as currently has to be 
> > supplied
> > by tools like debootstrap. The result would not be "hacks here and there" 
> > but a
> > cleaner and more robust setup procedure.
> > 
> > So what I want you to take away from this long mail is: maybe we should
> > re-think the way we are currently creating a Debian chroot because maybe 
> > there
> > exists a different approach that would give us benefits that are actually
> > important to our users and make maintaining the universal operating system
> > easier?
> Sounds good in theory, but I'd like to know what kind of new architecture are
> you thinking of, how would it be implemented, or how would it work in
> practice.

I assume by "architecture" here you don't mean Debian architecture but are
talking about the architecture that would improve on the current situation? I
already linked to two examples of approaches. I think in essence we somehow
have to manage the maintainer scripts.

One way would be support for chrootless maintainerscripts. Helmut filed #824594
against src:base-files but the maintainer was not convinced about the merits of
the approach and wanted to see some data about how a debootstrap-like tool
could take advantage of it. This was indeed my main motivation to write
mmdebstrap: to show that the approach was viable. Honestly, only now that I was
reading #824594 again, I realize that we are back at src:base-files talking
about the same topic that got me to write mmdebstrap in the first place. :D

Another way would be replacing maintainer scripts by more declarative
approaches, like pointed out by Guillem. I like this method a lot and it does
not conflict with the chrootless method which is still useful in situations
where one wants to (for example) create either a foreign architecture chroot or
create a chroot without needing superuser privileges.

And yet another would be, to allow dependencies between Essential packages or
by defining a package set even smaller than current Essential. But I like this
version the least.

> For example, for people bootstrapping new architectures, we introduced
> build-stages (afaik now called build-profiles).  (The  in gettext,
> for example).

Build profiles are for bootstrapping in the context of building software
packages.  Here, we talk about bootstrapping in the context of debootstrap
where we bootstrap a directory filled with unpacked binary packages from
"zero". The arguments brought forth here only concern bootstrapping new
architectures in so far that an Essential:yes set with less maintainer scripts
makes bootstrapping a new architecture easier.

> Maybe in the same line we could add a special Depends field only meaningful
> for bootstrapping tools? Is this the sort of thing you have in mind?
> 
> I would certainly consider a lot cleaner to add a new field to base-files in
> the form "Bootstrap-Depends: base-passwd" than converting all chowns in
> postinst to use integer numbers.

I agree that we should not expect maintainers to write numeric user and group
ids into their maintainer scripts. This is not only hard to write but also hard
to read and maintain. In my opinion, using numeric ids should only be a
temporary measure until we have a declarative method or other helper that does
the correct translation instead. But since no such helper exists right now,
numeric ids are probably the best way to fix this bug for buster.

I was now als able to trigger this bug in mmdebstrap. Here is how to populate a
chroot directory with a set of packages that is less than the Essential:yes set
and based on busybox:

sudo mmdebstrap --mode=root --variant=custom \
--include=dpkg,busybox,libc-bin,base-files,base-passwd,debianutils \
--setup-hook='mkdir -p "$1/bin"' \
--setup-hook='for p in awk cat chmod chown cp diff echo env grep less ln 
mkdir mount rm rmdir sed sh sleep sort touch uname; do ln -s busybox 
"$1/bin/$p"; done' \
--setup-hook='echo root:x:0:0:root:/root:/bin/sh > "$1/etc/passwd"' \
--setup-hook='printf "root:x:0:\nmail:x:8:\nutmp:x:43:\n" > "$1/etc/group"' 
\
unstable ./debian-unstable-busybox

As one can see, I had to create a minimal /etc/passwd and /etc/group inside the
chroot filled with entries for root, mail and utmp for the base-files postinst
to work. Using mmdebstrap like that is indeed quite a hack right now, so I'm
not claiming that mmdebstrap should be the reason for base-files to change. But
maybe this is a useful way for you of how to see this problem happening for
yourself.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

On Wed, Mar 13, 2019 at 01:15:02PM +0100, Johannes Schauer wrote:

> I'm not advocating for doing "hacks here and there so that bootstrapping tools
> work properly" as you put it but that we think about the question of whether
> maybe there is a better way to populate an empty directory with software
> components that does not require as much magic as currently has to be supplied
> by tools like debootstrap. The result would not be "hacks here and there" but 
> a
> cleaner and more robust setup procedure.
> 
> So what I want you to take away from this long mail is: maybe we should
> re-think the way we are currently creating a Debian chroot because maybe there
> exists a different approach that would give us benefits that are actually
> important to our users and make maintaining the universal operating system
> easier?

Sounds good in theory, but I'd like to know what kind of new
architecture are you thinking of, how would it be implemented,
or how would it work in practice.

For example, for people bootstrapping new architectures,
we introduced build-stages (afaik now called build-profiles).
(The  in gettext, for example).

Maybe in the same line we could add a special Depends field only
meaningful for bootstrapping tools? Is this the sort of thing you have
in mind?

I would certainly consider a lot cleaner to add a new field to
base-files in the form "Bootstrap-Depends: base-passwd" than
converting all chowns in postinst to use integer numbers.

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Johannes Schauer]

Hi Santiago,

Quoting Santiago Vila (2019-03-12 23:43:02)
> > > Do any of them still don't know that base-passwd should be configured
> > > first because otherwise any other package using root (be it base-files or
> > > any other) will fail? I think this was already settled in the last
> > > discussion we had about this several years ago.
> > multistrap doesn't take care of this and you can provoke a
> > base-files.postinst failure this way.
> In such case I would say that as a bootstrapping tool it's not doing its job
> properly.
> 
> The first rule of a bootstrapping tool is that it has to work.
> (And there are actually no other rules. As far as it does its job,
> you are allowed to do all sorts of dirty hacks).
> 
> Bootstrapping tools exist so that we don't have to worry about
> dependencies on essential packages. It has always been my opinion that
> if we start to do hacks here and there so that bootstrapping tools
> work properly, we are already doing it wrong.
> 
> > [,,,] Just because debootstrap encodes a ton of hacks to make things barely
> > work (and break every so often) doesn't mean we have to maintain them until
> > eternity.
> I would say: Just because people writing new bootstrapping tools seem to
> forget the lessons learned from previous bootstrapping tools, we have to
> learn again what bootstrapping really means: It's not adding hacks to the
> normal packages, it's concentrating all the hacks in the bootstrapping tools,
> so that we can keep ordinary packages clean of hacks.
> 
> (Or at least that's what I think it was the idea behind the essential
> definition).

I'm writing as the author of another "bootstrapping tool", namely mmdebstrap
which currently (really accidentally only) does not suffer from this bug but
might happen to be affected by it in the future.

I would especially like to challenge your view that (if I understood it
correctly) all the magic for getting from nothing to a Debian chroot should be
encoded in a bootstrapping script or program. You are right that currently this
is how it's done but I'd like to convince you that maybe it would be worth
reevaluating how we are currently doing this because maybe there is a better
way to do it.

Let me also point out here, that debootstrap has a place even in a world where
all the magic (the things you call hacks twice above) were moved into the
individual packages instead of being encoded in a central bootstrapping script.
This is because we will still need something that would be considered a hack
from the Debian perspective when we create a Debian chroot on systems that are
not Debian. My tool mmdebstrap for example will likely only work on Debian or
derivatives because it requires apt to be installed.

Lets look at the bigger picture: we have an archive with multiple software
components we call packages on some remote server and locally we have a fresh
empty directory which we somehow want to populate with the functionality that
these software components provide. The question is: what would be the best way
to do it? Or what would be a good engineering solution to this problem?

I claim (and that's where I want to challenge your view) that a better
engineering solution than the status quo in Debian would be to let each of
these software components (or packages) encode their requirements in a way that
lets a bootstrapping tool solve the installation task without involving the
other components and thus solve the chicken-and-egg problem of bootstrapping.
If this were possible, we can achieve a number of benefits which I'll be
getting to in a bit. That this *is* possible is shown by [guillem]'s mail to
this bug report. Another approach would be to use functionality of packages
installed on the outside of the chroot to fulfill requirements of the packages
inside the new chroot [detached chroot].

[guillem] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924401#35
[detached chroot] https://wiki.debian.org/Teams/Dpkg/Spec/InstallBootstrap

So if you can accept that it is technically achievable to create a component
based operating system with only very little "magic" in the bootstrapping tools
but all required information about interaction of even essential packages in
the components itself, then we can achieve multiple benefits:

 - solving dependencies is a complex matter [sudoku] and implementing a
   software that can handle NP-complete [np-complete] problem instances is not
   trivial (see code of apt, aptitude, dose, aspcud...). Existing tools like
   (c)debootstrap only understand just enough about package dependencies that
   they happen to be able to install a very minimal system. The status quo is
   to not add many packages via the --include option but install them via apt
   inside the chroot after debootstrap is done (#768062, #878961). If we could
   use existing tools that have a better understanding of Debian dependencies
   (like apt, aptitude, dose...) for bootstrapping a Debian chroot then we
   could:

 

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Guillem Jover]

Hi!

On Tue, 2019-03-12 at 16:17:10 +0100, Helmut Grohne wrote:
> Package: base-passwd,base-files,debian-policy
> 
> Debian policy section 3.8 says:
> | Essential is defined as the minimal set of functionality that must be
> | available and usable on the system at all times, even when packages
> | are in the “Unpacked” state.

The behavior for Essential package is scattered around the policy
document, there's also this in § 6.5 for the preinst maintscript:

  ,---
  The package will not yet be unpacked, so the "preinst" script
  cannot rely on any files included in its package. Only essential
  packages and pre-dependencies ("Pre-Depends") may be assumed to be
  available. Pre-dependencies will have been configured at least
  once, but at the time the "preinst" is called they may only be in
  an “Unpacked” or “Half-Configured” state if a previous version of
  the pre-dependency was completely configured and has not been
  removed since then.
  `---

I do think the same things that currently apply to Pre-Depends,
apply to the pseudo-essential set here, even if this is probably
a bit implicit.

> Now we can make a choice:

On Tue, 2019-03-12 at 16:32:30 +, Simon McVittie wrote:
> On Tue, 12 Mar 2019 at 16:17:10 +0100, Helmut Grohne wrote:
> > A. /etc/passwd is part of base-passwd's interface and base-files is
> >right in relying on it working at all times. Then base-passwd is rc
> >buggy for violating a policy must. Fixing this violation is
> >technically impossible.

(This assumes that policy covers the bootstrapping process, which I
don't think it has ever done.)

> If it isn't implementable then it's probably the wrong design.

This is not possible right now, but I think it should be possible in
the future.

> Strictly speaking, I think /etc/passwd *is* part (or maybe all?) of
> base-passwd's Essential interface, but then the Policy requirement that
> it provide this interface even when unconfigured is unimplementable, and
> we can't do unimplementable things.

Yes and no (see above). I also agree these are part of the Essential
interface, but I do not agree it's specified when it is unconfigured
*and* has never been configured before.

> I think it would be reasonable to say that Essential packages are *not*
> entitled to assume that base-passwd provides /etc/passwd, even though
> non-Essential packages are entitled to assume it.

Taking this in its general form seems extremely restrictive to me,
when the only problematic case here is for when the Essential packages
have never been configured before. This would mean possibly more
painful or no logic at all for upgrades and similar.

> > B. /etc/passwd is not part of base-passwd's interface and base-files
> >wrongly relies on its presence rendering base-files rc buggy.

(I think this is also the wrong interpretation, and would mean no
other package could rely on these being always present.)

> Perhaps base-files should use chown 0:0, etc.? That would be more robust.

While that would indeed solve part of the problem, and it's actually
what dpkg is doing itself:

  

it's still a workaround to the more general problem presented here.

> >Given that
> >we have debootstrap, cdebootstrap, multistrap, and mmdebstrap, it
> >seems like specifying the bootstrap interface would be a good idea.
> >Unfortunately, I don't exactly understand the bootstrap interface at
> >present. In practise, you cannot run postinsts of essential packages
> >in arbitrary order.
> 
> This is certainly more fragile than I'd hope: I've seen debootstrap fail
> in Open Build Service chroots when presented with a modified Essential
> set (in a Debian derivative targeting containers that are not multi-user
> systems and never run on bare metal, which doesn't need everything that a
> "real" Debian system does).
> 
> If we rely on bootstrap implementations having out-of-band knowledge
> of the right order to configure the Essential set, the risk is that
> they need to have different out-of-band knowledge for different target
> distributions, leading to the bootstrap implementation becoming relatively
> tightly coupled to the target distribution.

Yes, off-loading this knowledge from the packages themselves into
external bootstrapping tools is bogus IMO, and something we should
try to fix.

> Maybe the rule should be to retry configuration of each unconfigured
> package until either they all succeed, or forward progress stops being
> made? Pythonesque pseudocode:

I think this would too be a non-ideal workaround.

On Tue, 2019-03-12 at 16:17:10 +0100, Helmut Grohne wrote:
> C. Guillem Jover hinted that policy expects every essential package to
>be configured at least once. The current text does not make this
>assumption clear. If it holds, policy would simply say nothing about
>how to bootstrap an essential system, which may be fine. Given that
>we have 

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

On Tue, Mar 12, 2019 at 07:30:21PM +0100, Helmut Grohne wrote:

> > Do any of them still don't know that base-passwd should be configured
> > first because otherwise any other package using root (be it base-files
> > or any other) will fail? I think this was already settled in the last
> > discussion we had about this several years ago.
> 
> multistrap doesn't take care of this and you can provoke a
> base-files.postinst failure this way.

In such case I would say that as a bootstrapping tool it's not doing
its job properly.

The first rule of a bootstrapping tool is that it has to work.
(And there are actually no other rules. As far as it does its job,
you are allowed to do all sorts of dirty hacks).

Bootstrapping tools exist so that we don't have to worry about
dependencies on essential packages. It has always been my opinion that
if we start to do hacks here and there so that bootstrapping tools
work properly, we are already doing it wrong.

> > Can you provide at least a bug number for the bootstrapping tool that
> > apparently still tries to configure all packages at once, or
> > base-passwd and base-files in the same row?
> 
> #924401, but I'm not yet sure which part we need to fix.

Hmm, but that's the present bug.

I meant a bug in a bootstrapping tool.

> [,,,]
> Just because debootstrap encodes a ton of hacks to make things barely
> work (and break every so often) doesn't mean we have to maintain them
> until eternity.

I would say: Just because people writing new bootstrapping tools seem
to forget the lessons learned from previous bootstrapping tools, we
have to learn again what bootstrapping really means: It's not adding
hacks to the normal packages, it's concentrating all the hacks in the
bootstrapping tools, so that we can keep ordinary packages clean of
hacks.

(Or at least that's what I think it was the idea behind the essential
definition).

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Helmut Grohne]

Hi Santiago,

On Tue, Mar 12, 2019 at 06:17:50PM +0100, Santiago Vila wrote:
> To be precise: Who is unpacking (but not configuring) a buster or
> unstable essential package set, if not a bootstrapping tool?

multistrap is doing just that.

https://manpages.debian.org/testing/multistrap/multistrap.1.en.html
| Once installed, the packages themselves need to be configured using
| the package maintainer scripts and "dpkg --configure -a", unless this
| is a native multistrap.

> Do any of them still don't know that base-passwd should be configured
> first because otherwise any other package using root (be it base-files
> or any other) will fail? I think this was already settled in the last
> discussion we had about this several years ago.

multistrap doesn't take care of this and you can provoke a
base-files.postinst failure this way.

Then there is mmdebstrap. I looked into it and couldn't find any code
that orders base-passwd or base-files or creates an /etc/passwd. It
might not fail now.

> Can you provide at least a bug number for the bootstrapping tool that
> apparently still tries to configure all packages at once, or
> base-passwd and base-files in the same row?

#924401, but I'm not yet sure which part we need to fix.

I really like Simon's (thank you for that enlightening reply) view of
interpolating the uids. It removes a bunch of problems from the equation
and works well when bootstrapping from non-Debian or from ancient Debian
releases even in chrootless mode. At the same time, it is quite safe
(due to the static allocation) and easy to implement. I fail to see
downsides.

Just because debootstrap encodes a ton of hacks to make things barely
work (and break every so often) doesn't mean we have to maintain them
until eternity.

> In other words: Is the present bug report to be considered in a
> theoretical way, or it is the result of some problem that you actually
> found recently with a bootstrapping tool?

I don't have a minimal test case at hand, but I can reproduce it with
multistrap at least.

Helmut

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

On Tue, Mar 12, 2019 at 04:17:10PM +0100, Helmut Grohne wrote:
> Package: base-passwd,base-files,debian-policy
> 
> Debian policy section 3.8 says:
> 
> | Essential is defined as the minimal set of functionality that must be
> | available and usable on the system at all times, even when packages
> | are in the “Unpacked” state.
> 
> When unpacking (but not configuring) a buster or unstable essential
> package set, nothing creates /etc/passwd. Creation of that file is
> performed by base-passwd.postinst. base-files.postinst relies on a
> working /etc/passwd by using e.g. "chown root:root".

I think this is expressed in very generic terms.

To be precise: Who is unpacking (but not configuring) a buster or
unstable essential package set, if not a bootstrapping tool?

Do any of them still don't know that base-passwd should be configured
first because otherwise any other package using root (be it base-files
or any other) will fail? I think this was already settled in the last
discussion we had about this several years ago.

Can you provide at least a bug number for the bootstrapping tool that
apparently still tries to configure all packages at once, or
base-passwd and base-files in the same row?

In other words: Is the present bug report to be considered in a
theoretical way, or it is the result of some problem that you actually
found recently with a bootstrapping tool?

(Or maybe it is the result of someone trying to bootstrap a Debian
system/chroot without using a bootstrapping tool at all?)

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Simon McVittie]

It would probably be good for the overall robustness of the system if
we try to solve this from multiple angles.

On Tue, 12 Mar 2019 at 16:17:10 +0100, Helmut Grohne wrote:
> A. /etc/passwd is part of base-passwd's interface and base-files is
>right in relying on it working at all times. Then base-passwd is rc
>buggy for violating a policy must. Fixing this violation is
>technically impossible.

If it isn't implementable then it's probably the wrong design.

Strictly speaking, I think /etc/passwd *is* part (or maybe all?) of
base-passwd's Essential interface, but then the Policy requirement that
it provide this interface even when unconfigured is unimplementable, and
we can't do unimplementable things.

I think it would be reasonable to say that Essential packages are *not*
entitled to assume that base-passwd provides /etc/passwd, even though
non-Essential packages are entitled to assume it.

The lateral-thinking approach to solving this would be to have an
Essential or transitively-Essential fallback NSS module that provides
uids and gids 0 to 99 and 65534 without needing /etc/passwd. After all,
they're part of the ABI of a Debian system, so deleting them is not a
supported action (although reconfiguring their shells, etc. in /etc/passwd
is supported, especially for uid 0, so nsswitch.conf would need to have
either files or compat before this module). However, that's probably
a bigger hammer than people really want, and is annoying for multiarch
(we'd want it installed for each foreign architecture).

libnss-systemd partially solves this: it guarantees to provide uid and
gid 0 and 65534, but doesn't provide the 1-99 range, isn't Essential,
isn't portable to non-Linux, depends on systemd, and would cause political
objections.

> B. /etc/passwd is not part of base-passwd's interface and base-files
>wrongly relies on its presence rendering base-files rc buggy.

Perhaps base-files should use chown 0:0, etc.? That would be more robust.

In addition to the root user and group, it would have to hard-code
the numeric group IDs of staff, mail and utmp, AFAICS. That doesn't
seem awful? They're all in the statically-allocated range.

The postinst is already a built file (a .in file with sed substitutions),
so it could take the numeric staff, mail and utmp gids at build time
and hard-code them in the binary package without also having to hard-code
them in the source package, if preferred.

Other possibilities in this direction include:

- complete the staff-group-for-usr-local transition and stop using the
  staff group
- use systemd-tmpfiles (or something compatible with tmpfiles.d(5)
  on non-systemd systems) to create /var/log/*tmp, /var/log/lastlog,
  /run/utmp, /var/mail and any other /var files that are needed during boot
  (in fact systemd already has tmpfiles snippets for all the files I named,
  except /var/mail)

>Given that
>we have debootstrap, cdebootstrap, multistrap, and mmdebstrap, it
>seems like specifying the bootstrap interface would be a good idea.
>Unfortunately, I don't exactly understand the bootstrap interface at
>present. In practise, you cannot run postinsts of essential packages
>in arbitrary order.

This is certainly more fragile than I'd hope: I've seen debootstrap fail
in Open Build Service chroots when presented with a modified Essential
set (in a Debian derivative targeting containers that are not multi-user
systems and never run on bare metal, which doesn't need everything that a
"real" Debian system does).

If we rely on bootstrap implementations having out-of-band knowledge
of the right order to configure the Essential set, the risk is that
they need to have different out-of-band knowledge for different target
distributions, leading to the bootstrap implementation becoming relatively
tightly coupled to the target distribution.

Maybe the rule should be to retry configuration of each unconfigured
package until either they all succeed, or forward progress stops being
made? Pythonesque pseudocode:

to_configure = set(["base-files", "base-passwd", ...])

while to_configure is non-empty:
failed = set()

for p in to_configure:  # can be in arbitrary order
if run_postinst(p) fails:
failed.add(p)

if len(failed) == len(to_configure):
# Nothing succeeded since the last iteration of the outer loop.
# Assume that trying again isn't going to help.
fatal("Could not configure Essential packages:", failed)
else:
# Progress has been made, so retry any failures in the hope that
# the progress we made has unblocked them, or terminate the loop
# if there were none
to_configure = failed

assert(to_configure is empty)
log success

Regards,
smcv

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Santiago Vila]

On Tue, Mar 12, 2019 at 04:17:10PM +0100, Helmut Grohne wrote:
> Package: base-passwd,base-files,debian-policy
> 
> Debian policy section 3.8 says:
> 
> | Essential is defined as the minimal set of functionality that must be
> | available and usable on the system at all times, even when packages
> | are in the “Unpacked” state.
> 
> When unpacking (but not configuring) a buster or unstable essential
> package set, nothing creates /etc/passwd. Creation of that file is
> performed by base-passwd.postinst. base-files.postinst relies on a
> working /etc/passwd by using e.g. "chown root:root".
> 
> Now we can make a choice:
> A. /etc/passwd is part of base-passwd's interface and base-files is
>right in relying on it working at all times. Then base-passwd is rc
>buggy for violating a policy must. Fixing this violation is
>technically impossible.
> B. /etc/passwd is not part of base-passwd's interface and base-files
>wrongly relies on its presence rendering base-files rc buggy.
> C. Guillem Jover hinted that policy expects every essential package to
>be configured at least once. The current text does not make this
>assumption clear. If it holds, policy would simply say nothing about
>how to bootstrap an essential system, which may be fine. Given that
>we have debootstrap, cdebootstrap, multistrap, and mmdebstrap, it
>seems like specifying the bootstrap interface would be a good idea.
>Unfortunately, I don't exactly understand the bootstrap interface at
>present. In practise, you cannot run postinsts of essential packages
>in arbitrary order.

I think you actually can as soon as the system has been properly
bootstrapped, which is precisely the work of bootstrapping tools.

Can we please reassign this to whatever package is not bootstrapping
the system properly in your case?

Thanks.

Bug#924401: base-files fails postinst when base-passwd is unpacked

[Helmut Grohne]

Package: base-passwd,base-files,debian-policy

Debian policy section 3.8 says:

| Essential is defined as the minimal set of functionality that must be
| available and usable on the system at all times, even when packages
| are in the “Unpacked” state.

When unpacking (but not configuring) a buster or unstable essential
package set, nothing creates /etc/passwd. Creation of that file is
performed by base-passwd.postinst. base-files.postinst relies on a
working /etc/passwd by using e.g. "chown root:root".

Now we can make a choice:
A. /etc/passwd is part of base-passwd's interface and base-files is
   right in relying on it working at all times. Then base-passwd is rc
   buggy for violating a policy must. Fixing this violation is
   technically impossible.
B. /etc/passwd is not part of base-passwd's interface and base-files
   wrongly relies on its presence rendering base-files rc buggy.
C. Guillem Jover hinted that policy expects every essential package to
   be configured at least once. The current text does not make this
   assumption clear. If it holds, policy would simply say nothing about
   how to bootstrap an essential system, which may be fine. Given that
   we have debootstrap, cdebootstrap, multistrap, and mmdebstrap, it
   seems like specifying the bootstrap interface would be a good idea.
   Unfortunately, I don't exactly understand the bootstrap interface at
   present. In practise, you cannot run postinsts of essential packages
   in arbitrary order.

I argue that something is buggy. I'm not sure what. I gave three
options. Can we gather consensus on one of these?

Helmut