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

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

[symphonia]

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

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

[Gábor Boskovits]

Hello,

<symphonia@disroot.org> ezt írta (időpont: 2020. jan. 7., K, 22:32):
>
> 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

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

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 527 bytes --]

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,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[Gábor Boskovits]

Oops, I missed that.

Tobias Geerinckx-Rice <me@tobias.gr> ezt írta (időpont: 2020. jan.
22., Sze, 4:53):
>
> 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.

> T G-R


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

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

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 1306 bytes --]

Gábor,

Gábor Boskovits 写道：
> Oops, I missed that.

I'm suprised I haven't confused add* & *add once so far in this 
thread :-)

> 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.

Kind regards,

T G-R

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

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

[Gábor Boskovits]

Tobias Geerinckx-Rice <me@tobias.gr> ezt írta (időpont: 2020. jan.
22., Sze, 20:58):
>
> 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.

>
> > 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.

>
> 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

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

[zimoun]

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

bug#39023: adduser/addgroup vs useradd/groupadd

[zimoun]

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):
>>

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

bug#39023: adduser/addgroup vs useradd/groupadd

[Tobias Geerinckx-Rice via Bug reports for GNU Guix]

[-- Attachment #1: Type: text/plain, Size: 845 bytes --]

Hullo Simon,

zimoun 写道：
> 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/.

> What do the *NIX gurus think?

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

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#39023: adduser/addgroup vs useradd/groupadd

[zimoun]

Hi Tobias,

On Wed, 22 Jan 2020 at 05:03, Tobias Geerinckx-Rice <me@tobias.gr> wrote:
> 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. :-)


>   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.


> 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'.


> 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'.


> 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. :-)


> > 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. :-))

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

[Vincent Legoll]

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

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

[zimoun]

Hi Vincent,

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

> 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

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

[Vincent Legoll]

Hello,

On 23/04/2020 15:29, zimoun wrote:
> 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. ;-)

> 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
     fi
==========================================================

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