binary installation manual doesn't work on Alpine Linux

Open

Details

5 participants

Gábor Boskovits
Tobias Geerinckx-Rice
symphonia
Vincent Legoll
zimoun

Owner: unassigned

Submitted by: symphonia

Severity: normal

symphonia wrote on 7 Jan 2020 22:29

Recipients:(address . bug-guix@gnu.org)

Message-ID:4678e0a6a529877fee91a452424115c1@disroot.org

The commands in https://guix.gnu.org/manual/en/guix.html#Build-Environment-Setup
do not work on busybox-based systems such as Alpine Linux by default.
This is because they do not have 'groupadd' or 'useradd' by default (from 'shadow' package).

# groupadd --system guixbuild
# for i in `seq -w 1 10`;
  do
    useradd -g guixbuild -G guixbuild           \
            -d /var/empty -s `which nologin`    \
            -c "Guix build user $i" --system    \
            guixbuilder$i;
  done

I suggest adding another example which works by default on busybox.
Explanation: -S means 'add system group/user'; -h is 'home directory'; -g is 'GECOS field'
Also, Alpine Linux fails to boot if /var/empty is not owned by root, so that needs to be fixed afterward as well.

addgroup -S guixbuild
for i in `seq -w 1 10`;
do
adduser -G guixbuild \
-h /var/empty -s `which nologin` \
-g "Guix build user $i" -S \
guixbuilder$i;
done
chown root:root /var/empty # /var/empty must be owned by root, fix permission after `adduser` modified it

Gábor Boskovits wrote on 8 Jan 2020 13:34

Recipients:(address . symphonia@disroot.org)(address . 39023@debbugs.gnu.org)

Message-ID:CAE4v=phMbf=PsT4zvrkRA3kCkemJuWQfR5ciA_JZbwJY1OR+Pg@mail.gmail.com

Hello,

<symphonia@disroot.org> ezt írta (id?pont: 2020. jan. 7., K, 22:32):

Toggle quote (30 lines)>
> The commands in https://guix.gnu.org/manual/en/guix.html#Build-Environment-Setup
> do not work on busybox-based systems such as Alpine Linux by default.
> This is because they do not have 'groupadd' or 'useradd' by default (from 'shadow' package).
>
> # groupadd --system guixbuild
> # for i in `seq -w 1 10`;
>   do
>     useradd -g guixbuild -G guixbuild           \
>             -d /var/empty -s `which nologin`    \
>             -c "Guix build user $i" --system    \
>             guixbuilder$i;
>   done
>
> I suggest adding another example which works by default on busybox.
> Explanation: -S means 'add system group/user'; -h is 'home directory'; -g is 'GECOS field'
> Also, Alpine Linux fails to boot if /var/empty is not owned by root, so that needs to be fixed afterward as well.
>
> addgroup -S guixbuild
> for i in `seq -w 1 10`;
> do
> adduser -G guixbuild \
> -h /var/empty -s `which nologin` \
> -g "Guix build user $i" -S \
> guixbuilder$i;
> done
> chown root:root /var/empty # /var/empty must be owned by root, fix permission after `adduser` modified it
>
>
>

I assume that the command you gave would work on non-busybox also. I

would say we should replace the

command we have with this more compatible one.

I would wait for a few more responses, though.

If that sounds good to you could you create a patch to that effect?

Best regards,

g_bor

OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

zimoun wrote on 22 Jan 2020 02:44

bug#39023: adduser/addgroup vs useradd/groupadd

Recipients:(address . symphonia@disroot.org)

Message-ID:CAJ3okZ0NKRzzisinoyPYUkAYcA0jYtzJekqjgKrHkWEYAn1VAA@mail.gmail.com

Dear,

The bug [1] reports that useradd/groupadd are not provided on BusyBox.

And for example, they had this discussion [2].

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39023

[2] http://lists.busybox.net/pipermail/busybox/2016-February/083907.html

For example, on Debian, adduser is a Perl script calling useradd under the hood.

And the current Guix manual says:

On a GNU/Linux system, a build user pool may be created like this

(using Bash syntax and the shadow commands):

Toggle quote (2 lines)

where the parenthesis should be understood as: "adapt to your distribution".

Two options:

a/ explicitly notice in the parenthesis that the chunk needs to be

adapted; mentioning adduser/addgroup instead of useradd/groupadd for

example.

b/ replace useradd/groupadd by adduser/addgroup using the

corresponding options.

The option b/ means that 'adduser/addgroup' is more portable (more

chance to work on everywhere GNU/linux). I am not convinced.

Personally, I am in favor for option a/.

What do the *NIX gurus think?

All the best,

simon

Tobias Geerinckx-Rice wrote on 22 Jan 2020 04:53

Re: bug#39023: binary installation manual doesn't work on Alpine Linux

Recipients:(address . 39023@debbugs.gnu.org)

Message-ID:87ftg89mfd.fsf@nckx

Gábor,

Gábor Boskovits ???

Toggle quote (5 lines)

> <symphonia@disroot.org> ezt írta (id?pont: 2020. jan. 7., K,

> 22:32):

>> I suggest adding another example which works by default on

>> busybox.

[…]

Toggle quote (2 lines)

>> addgroup -S guixbuild

[…]

Toggle quote (5 lines)

> I assume that the command you gave would work on non-busybox

> also. I

> would say we should replace the

> command we have with this more compatible one.

It doesn't even work on Guix:

nckx@berlin ~$ adduser

-bash: adduser: command not found

Kind regards,

T G-R

Tobias Geerinckx-Rice wrote on 22 Jan 2020 05:03

Re: bug#39023: adduser/addgroup vs useradd/groupadd

Recipients:(address . 39023@debbugs.gnu.org)(name . zimoun)(address . zimon.toutoune@gmail.com)

Message-ID:87eevs9lyo.fsf@nckx

Hullo Simon,

zimoun ???

Toggle quote (8 lines)

> options:

> a/ explicitly notice in the parenthesis that the chunk needs to

> be

> adapted; mentioning adduser/addgroup instead of useradd/groupadd

> for

> example.

There's also:

c/ do nothing, or

d/ include the complete code snippet provided by symphonia, but

as an ‘out-of-band’ footnote to avoid confusion/blind

copy-pasting/distracting the majority of (GNU) users with

irrelevant variants.

With a/, the user won't know which options to change, or how.

They might not understand our ‘useradd’ syntax, and won't have its

man page installed.

As implied by my reply to Gábor, b/ isn't an option so I've

snipped it.

I strongly prefer option d/.

Toggle quote (2 lines)

> What do the *NIX gurus think?

GNU's not *NIX! :o) (Nor is it POSIX.)

Kind regards,

T G-R

zimoun wrote on 22 Jan 2020 09:31

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)(address . 39023@debbugs.gnu.org)

Message-ID:CAJ3okZ0+8dJmTX5crHuhAG_bvEP8rNUNHxMdq0M4GF3vVXdZAQ@mail.gmail.com

Hi Tobias,

On Wed, 22 Jan 2020 at 05:03, Tobias Geerinckx-Rice <me@tobias.gr> wrote:

Toggle quote (12 lines)

> zimoun ???

> > a/ explicitly notice in the parenthesis that the chunk needs to

> > be

> > adapted; mentioning adduser/addgroup instead of useradd/groupadd

> > for

> > example.

> There's also:

> c/ do nothing, or

It is not fair, IMHO. :-)

Toggle quote (5 lines)

> d/ include the complete code snippet provided by symphonia, but

> as an ‘out-of-band’ footnote to avoid confusion/blind

> copy-pasting/distracting the majority of (GNU) users with

> irrelevant variants.

Well, mixing the option a/ and b/. :-)

- telling explicitly

- providing copy/paste-able variant snippet

Yes, it is a better option.

Toggle quote (4 lines)

> With a/, the user won't know which options to change, or how.

> They might not understand our ‘useradd’ syntax, and won't have its

> man page installed.

Yes, and they would not know neither if their foreign distro comes

with exotic 'adduser/addgroup'.

Toggle quote (3 lines)

> As implied by my reply to Gábor, b/ isn't an option so I've

> snipped it.

Yes, it is my assumption --based on my small experience-- that

'adduser/addgroup' is less portable than 'useradd/groupadd'.

Toggle quote (2 lines)

> I strongly prefer option d/.

Let go to this one. :-)

Hum? let see I am able to include the complete code snippet as an

footnote using Texinfo...

(Maybe someone will beat me. :-)

Toggle quote (4 lines)

> > What do the *NIX gurus think?

> GNU's not *NIX! :o) (Nor is it POSIX.)

Héhé! Schrödinger's distro: by installing Guix on your foreign *NIX

distro, the user will have in the same time "not *NIX" and *NIX. ;-)

(Even if *NIX needs to run linux which mitigate the joke. :-))

Gábor Boskovits wrote on 22 Jan 2020 20:42

Re: bug#39023: binary installation manual doesn't work on Alpine Linux

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)

Message-ID:CAE4v=phKi5WqOPu1zKvMp3fC+PKhscsdXoEm9NRY=29+_-X9Jg@mail.gmail.com

Oops, I missed that.

Tobias Geerinckx-Rice <me@tobias.gr> ezt írta (id?pont: 2020. jan.

22., Sze, 4:53):

Toggle quote (28 lines)>
> Gábor,
>
> Gábor Boskovits ???
> > <symphonia@disroot.org> ezt írta (id?pont: 2020. jan. 7., K,
> > 22:32):
> >> I suggest adding another example which works by default on
> >> busybox.
>
> […]
>
> >> addgroup -S guixbuild
>
> […]
>
> > I assume that the command you gave would work on non-busybox
> > also. I
> > would say we should replace the
> > command we have with this more compatible one.
>
> It doesn't even work on Guix:
>
>   nckx@berlin ~$ adduser
>   -bash: adduser: command not found
>
> Kind regards,
>

I believe these can be implemented using simple manipulation of config files.

Also useradd is part of the linux standard base, while adduser is not.

We could add the busybox example, but it might be better to come up

with something

universal.

There was some upstream discussion to get useradd and groupadd to

busybox upstream,

as this seems to be causing problems everywhere. They told that they

are unwilling to include them as is,

but would accept a wrapper thar forward to their adduser/addgroup

implementation.

Toggle quote (3 lines)

> T G-R

Best regards,
g_bor
-- 
OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

Tobias Geerinckx-Rice wrote on 22 Jan 2020 20:58

Recipients:(name . Gábor Boskovits)(address . boskovits@gmail.com)

Message-ID:87lfpzfel9.fsf@nckx

Gábor,

Gábor Boskovits ???

Toggle quote (2 lines)

> Oops, I missed that.

I'm suprised I haven't confused add* & *add once so far in this

thread :-)

Toggle quote (10 lines)> There was some upstream discussion to get useradd and groupadd 
> to
> busybox upstream,
> as this seems to be causing problems everywhere. They told that 
> they
> are unwilling to include them as is,
> but would accept a wrapper thar forward to their 
> adduser/addgroup
> implementation.

I don't know which discussion you're referring to, and much might

have changed since 2016, but I read this[0] to mean the opposite:

Busybox should provide the shadow-compatible *add variants, and

reimplement their old add* as simple wrappers around that. That's

from an upstream(ish) person.

“adduser/addgroup tend to be symlinks or wrappers, if they exist

all, but by and large are deprecated. busybox should implement

applets that mimic shadow here and deprecate the old ones, if

not

throw them out. although we can probably rename & massage the

sources in these cases”

Still, Busybox *add patches welcome, it would seem. We'll still

have to deal with this for the lifetime of the older version.

Kind regards,

T G-R

[0]:

http://lists.busybox.net/pipermail/busybox/2016-February/083909.html

Gábor Boskovits wrote on 22 Jan 2020 21:03

Recipients:(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)

Message-ID:CAE4v=pgMQ9-Gd6WpvsAY3OWQ_Cd7PCUouS4Vwfv4cp4mDBD1bw@mail.gmail.com

Tobias Geerinckx-Rice <me@tobias.gr> ezt írta (id?pont: 2020. jan.

22., Sze, 20:58):

Toggle quote (9 lines)

> Gábor,

> Gábor Boskovits ???

> > Oops, I missed that.

> I'm suprised I haven't confused add* & *add once so far in this

> thread :-)

Yes, I am also a bit confused.

Toggle quote (28 lines)>
> > There was some upstream discussion to get useradd and groupadd
> > to
> > busybox upstream,
> > as this seems to be causing problems everywhere. They told that
> > they
> > are unwilling to include them as is,
> > but would accept a wrapper thar forward to their
> > adduser/addgroup
> > implementation.
>
> I don't know which discussion you're referring to, and much might
> have changed since 2016, but I read this[0] to mean the opposite:
> Busybox should provide the shadow-compatible *add variants, and
> reimplement their old add* as simple wrappers around that.  That's
> from an upstream(ish) person.
>
>   “adduser/addgroup tend to be symlinks or wrappers, if they exist
>   at
>    all, but by and large are deprecated.  busybox should implement
>    applets that mimic shadow here and deprecate the old ones, if
>    not
>    throw them out. although we can probably rename & massage the
>    sources in these cases”
>
> Still, Busybox *add patches welcome, it would seem.  We'll still
> have to deal with this for the lifetime of the older version.

Yes, I referred to this, but I might have misunderstood something.

Toggle quote (10 lines)

> Kind regards,

> T G-R

> [0]:

> http://lists.busybox.net/pipermail/busybox/2016-February/083909.html

OpenPGP Key Fingerprint: 7988:3B9F:7D6A:4DBF:3719:0367:2506:A96C:CF63:0B21

zimoun wrote on 19 Feb 2020 16:56

Recipients:(name . Gábor Boskovits)(address . boskovits@gmail.com)

Message-ID:CAJ3okZ22oqLYgkYSghZs2FMbOLn5XgOEKO72XLQM4wmVUy2gwQ@mail.gmail.com

Hi,

I am a bit confused. At the end, what is the fix?

From my knowledge, 'useradd/groupadd ' are the standard commands. The

other ones, not.

Personally, I am in favour of the option a/ that is described here

[1]: write in the manual in a footnote it should be adapted for the

underlining distro, i.e., mention 'adduser/addgroup'.

Tobias mentioned [2] an option /d: provide in addition of the existing

one a complete example using 'adduser/addgroup'.

But then Tobias sent this message [3] explaining that BusyBox is doing

wrong. ;-) Which IMHO leads to the option a/. :-)

What is the consensus for the bug?

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39023#11

[2] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39023#17

[3] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39023#26

All the best,

simon

Vincent Legoll wrote on 23 Apr 2020 13:55

Recipients:(address . 39023@debbugs.gnu.org)

Message-ID:b041d4ae-0457-02f4-3f31-9a1a1a111e0e@gmail.com

Hello,

as I had been working on the installer lately [1],

I tried to tackle this bug also, I have it mostly

working.

I added support for openrc-based init systems.

I opted to support both adduser & useradd, changed

some tool calls to work on busybox, etc... Then

sprinkled a bit of cleanup & polish over the top.

It's not finished, because I could not test it. I

have a problem building the binary-tarball since I

switched to the 1.1.0 release and I've yet to try

to build on an earlier version.

Stay tuned, patches incoming for review.

[1] https://issues.guix.gnu.org/40601

Vincent Legoll

zimoun wrote on 23 Apr 2020 15:29

Recipients:(name . Vincent Legoll)(address . vincent.legoll@gmail.com)

Message-ID:CAJ3okZ25BEr5vHRgFqjjP6fz4v-kOWiYVxCgyRZE+=+czhR0og@mail.gmail.com

Hi Vincent,

On Thu, 23 Apr 2020 at 13:55, Vincent Legoll <vincent.legoll@gmail.com> wrote:

Toggle quote (19 lines)> as I had been working on the installer lately [1],
> I tried to tackle this bug also, I have it mostly
> working.
>
> I added support for openrc-based init systems.
>
> I opted to support both adduser & useradd, changed
> some tool calls to work on busybox, etc... Then
> sprinkled a bit of cleanup & polish over the top.
>
> It's not finished, because I could not test it. I
> have a problem building the binary-tarball since I
> switched to the 1.1.0 release and I've yet to try
> to build on an earlier version.
>
> Stay tuned, patches incoming for review.
>
> [1] https://issues.guix.gnu.org/40601

Do you mean that the incoming patches will include an explanation in

the manual about adduser/useradd?

Do you mean that guix-install.sh will now include a conditional test

on the kind of foreign distibution to use adduser or useradd?

Thank you for working on that.

Cheers,

simon

Vincent Legoll wrote on 23 Apr 2020 16:15

Recipients:(name . zimoun)(address . zimon.toutoune@gmail.com)

Message-ID:095da2c7-c029-613d-3957-869fefc8d5ff@gmail.com

Hello,

On 23/04/2020 15:29, zimoun wrote:

Toggle quote (3 lines)

> Do you mean that the incoming patches will include an explanation in

> the manual about adduser/useradd?

I'll be writing new / amending existing doc after the patches have

received the first round of review. ;-)

Toggle quote (3 lines)

> Do you mean that guix-install.sh will now include a conditional test

> on the kind of foreign distibution to use adduser or useradd?

guix-install.sh will include conditional test on the availability of

the commands.

Like that:

==========================================================

if command -v groupadd &>/dev/null; then

groupadd --system guixbuild

_msg "${PAS}group <guixbuild> created"

elif command -v addgroup &>/dev/null; then

addgroup -S guixbuild

_msg "${PAS}group <guixbuild> created"

else

_err "${ERR}cannot add group for guix build users"

exit 1

==========================================================

Seems not too much bloated, and I tested it manually on

alpine & another one (cannot remember, probably debian).

Did not break the previously working & works fine on

busybox-based (alpine).

I'll test extensively (range of OS & range of HW archs)

before submitting for review.

I'll resume working on this, hoping the gromacs package is

ok...

I've removed the CC to 40601@debbugs.gnu.org as I just wanted

to make a link between the two, but don't want to spam the

other issue... I hope this was OK to do.

Vincent Legoll

Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 39023@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it

mumi current 39023

Then, you may apply the latest patchset in this issue (with sign off)

mumi am -- -s

Or, compose a reply to this issue

mumi compose

Or, send patches to this issue

mumi send-email *.patch

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date