bug#36785: Impossible to pull on foreign distro

bug#36785: Impossible to pull on foreign distro

[Julien Lepiller]

Hi guix,

I gave a small tutorial to someone today, where we installed guix on top of a foreign distro. We used the script and everything went smoothly, and after finding out that we were going to build php (we were trying to define a VM that would serve one of their services), we tried to run guix pull:

sudo guix pull —commit=…

However the command failed immediately with:

Migrating profile generations to '/var/guix/profiles/per-user/root'...
Guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/root/current-guix"

Indeed, the file exists and everything looks good. Why does guix try to migrate a profile that's already good?

I was able to work around that situation, but it's not great for our users.

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

> I gave a small tutorial to someone today, where we installed guix on top of a foreign distro. We used the script and everything went smoothly, and after finding out that we were going to build php (we were trying to define a VM that would serve one of their services), we tried to run guix pull:
>
> sudo guix pull —commit=…
>
> However the command failed immediately with:
>
> Migrating profile generations to '/var/guix/profiles/per-user/root'...
> Guix pull: error: symlink: File exists: "/var/guix/profiles/per-user/root/current-guix"
>
> Indeed, the file exists and everything looks good. Why does guix try to migrate a profile that's already good?
>
> I was able to work around that situation, but it's not great for our users.

I’m guessing the machine had remnants of a previous Guix installation,
no?  See:

  ;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks.  Move
  ;; them to %PROFILE-DIRECTORY.
  (unless (string=? %profile-directory
                    (dirname (canonicalize-profile %user-profile-directory)))
    (migrate-generations %user-profile-directory %profile-directory))

Ludo’.

bug#36785: Impossible to pull on foreign distro

[Julien Lepiller]

Le 26 juillet 2019 01:03:08 GMT+02:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :
>Hi Julien,
>
>Julien Lepiller <julien@lepiller.eu> skribis:
>
>> I gave a small tutorial to someone today, where we installed guix on
>top of a foreign distro. We used the script and everything went
>smoothly, and after finding out that we were going to build php (we
>were trying to define a VM that would serve one of their services), we
>tried to run guix pull:
>>
>> sudo guix pull —commit=…
>>
>> However the command failed immediately with:
>>
>> Migrating profile generations to
>'/var/guix/profiles/per-user/root'...
>> Guix pull: error: symlink: File exists:
>"/var/guix/profiles/per-user/root/current-guix"
>>
>> Indeed, the file exists and everything looks good. Why does guix try
>to migrate a profile that's already good?
>>
>> I was able to work around that situation, but it's not great for our
>users.
>
>I’m guessing the machine had remnants of a previous Guix installation,
>no?  See:
>
>;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks. 
>Move
>  ;; them to %PROFILE-DIRECTORY.
>  (unless (string=? %profile-directory
>              (dirname (canonicalize-profile %user-profile-directory)))
>    (migrate-generations %user-profile-directory %profile-directory))
>
>Ludo’.

Not at all, this was the first install on that machine. The OS was even installed recently, so there can't be any remnant of the 0.15 era :). Installation went smoothly and /root/.config/guix/current was already a symlink to /var/guix/profiles/per-user/root. We ran guix pull as user just before and it worked perfectly well (with the message about migrating, although ~/.config/guix/current didn't exist).

Could there be some veird interaction between sudo and these %profile-directory and %user-profile-directory variables?

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

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

Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

> Le 26 juillet 2019 01:03:08 GMT+02:00, "Ludovic Courtès" <ludo@gnu.org> a écrit :

[...]

>>;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks. 
>>Move
>>  ;; them to %PROFILE-DIRECTORY.
>>  (unless (string=? %profile-directory
>>              (dirname (canonicalize-profile %user-profile-directory)))
>>    (migrate-generations %user-profile-directory %profile-directory))

[...]

> Could there be some veird interaction between sudo and these %profile-directory and %user-profile-directory variables?

Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
(canonicalize-profile %user-profile-directory), and here’s what I see
with ‘sudo’:

--8<---------------cut here---------------start------------->8---
$ sudo -E ./pre-inst-env guix pull

;;; (pd "/var/guix/profiles/per-user/root")

;;; (upd "/home/ludo/.config/guix/current")
Migrating profile generations to '/var/guix/profiles/per-user/root'...
guix pull: error: symlink: Dosiero jam ekzistas: "/var/guix/profiles/per-user/root/current-guix"
--8<---------------cut here---------------end--------------->8---

‘%user-profile-directory’ is computed as a function of $HOME, which is
unchanged when using ‘sudo’, whereas ‘%profile-directory’ is computed as
a function of $USER.

I think $HOME should always prevail over the home directory defined in
/etc/passwd, so think we should not change the way
‘%user-profile-directory’ is computed.

We could do this:


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 483 bytes --]

--- a/guix/profiles.scm
+++ b/guix/profiles.scm
@@ -1721,7 +1721,8 @@ because the NUMBER is zero.)"
 
 (define %profile-directory
   (string-append %state-directory "/profiles/"
-                 (or (and=> (or (getenv "USER")
+                 (or (and=> (or (getenv "SUDO_USER")
+                                (getenv "USER")
                                 (getenv "LOGNAME"))
                             (cut string-append "per-user/" <>))
                      "default")))

[-- Attachment #3: Type: text/plain, Size: 124 bytes --]


… but then ‘sudo guix pull’ won’t update root’s guix at all.

Otherwise I’m thinking of this gross hack:


[-- Attachment #4: Type: text/x-patch, Size: 816 bytes --]

diff --git a/guix/scripts/pull.scm b/guix/scripts/pull.scm
index 54bbaddf30..8d8a8aa889 100644
--- a/guix/scripts/pull.scm
+++ b/guix/scripts/pull.scm
@@ -293,8 +293,9 @@ true, display what would be built without actually building it."
 
   ;; In 0.15.0+ we'd create ~/.config/guix/current-[0-9]*-link symlinks.  Move
   ;; them to %PROFILE-DIRECTORY.
-  (unless (string=? %profile-directory
-                    (dirname (canonicalize-profile %user-profile-directory)))
+  (unless (or (getenv "SUDO_USER")
+              (string=? (pk 'pd %profile-directory)
+                        (dirname (pk 'upd (canonicalize-profile %user-profile-directory)))))
     (migrate-generations %user-profile-directory %profile-directory))
 
   ;; Make sure ~/.config/guix/current points to /var/guix/profiles/….

[-- Attachment #5: Type: text/plain, Size: 154 bytes --]


I think it’s acceptable because that’s “throw away” code anyway, and
it’s not supposed to be triggered these days.

Thoughts?

Ludo’.

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Hi,

Ludovic Courtès <ludo@gnu.org> skribis:

> Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
> (canonicalize-profile %user-profile-directory), and here’s what I see
> with ‘sudo’:
>
> $ sudo -E ./pre-inst-env guix pull
>
> ;;; (pd "/var/guix/profiles/per-user/root")
>
> ;;; (upd "/home/ludo/.config/guix/current")

I used ‘-E’ above, which is why HOME was ~ludo instead of ~root.
Without ‘-E’, HOME is ~root as expected, and so “sudo guix pull” does
the right thing (this is on Guix System):

--8<---------------cut here---------------start------------->8---
$ sudo guix repl
GNU Guile 2.2.4
Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guix-user)> (getenv "HOME")
$1 = "/root"
scheme@(guix-user)> ,m(guix scripts pull)
scheme@(guix scripts pull)> %profile-directory
$2 = "/var/guix/profiles/per-user/root"
scheme@(guix scripts pull)> %user-profile-directory
$3 = "/root/.config/guix/current"
scheme@(guix scripts pull)> (cache-directory)
$4 = "/root/.cache/guix"
scheme@(guix scripts pull)> (config-directory)
$5 = "/root/.config/guix"
--8<---------------cut here---------------end--------------->8---

So ‘sudo guix pull’ really updates root’s profile and writes to
~root/.cache, everything is fine.

Done?

I investigated a bit, tried Debian, then Ubuntu, and found that ‘sudo’
on Ubuntu behaves differently: it preserves ‘HOME’ by default:

  $ sudo env | grep HOME
  HOME=/home/ubuntu

This is written here:

  https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells

(That’s with sudo 1.8.21p2, FWIW.)

Ubuntu’s /etc/sudoers doesn’t have anything special.  Actually, Debian
has (almost) the same /etc/sudoers and yet it does not preserve HOME.

(Time passes…)

Digging further, I fetched the source from
<https://packages.ubuntu.com/bionic/sudo>, and boom! I found the
culprit: it’s called ‘debian/patches/keep_home_by_default.patch’.

--8<---------------cut here---------------start------------->8---
Description: Set HOME in initial_keepenv_table
 Set HOME in initial_keepenv_table; without this, $HOME will never be 
 preserved unless added to keep_env.  There's appropriate logic to handle
 resetting the home for -H and -i options, so this is the only part that's
 missing.
Author: Steve Langasek <steve.langasek@canonical.com>
--- a/plugins/sudoers/env.c
+++ b/plugins/sudoers/env.c
@@ -189,6 +189,7 @@
     "COLORS",
     "DISPLAY",
     "DPKG_COLORS",
+    "HOME",
     "HOSTNAME",
     "KRB5CCNAME",
     "LS_COLORS",
--8<---------------cut here---------------end--------------->8---

(This patch is playing with fire IMO.  If you’re an Ubuntu user,
consider reporting a bug!)

But anyway, what can we do?

We could ignore the issue, it’s-Ubuntu’s-fault, done.

We could also add some logic to detect whether (1) we’re running under
sudo, and in that case, and whether (2) $HOME matches $USER’s home
directory as it appears in /etc/passwd.  If both conditions are
satisfied, we could ignore $HOME and use the home directory from
/etc/passwd instead.

But… that’s complicated, and it’d break uses of ‘sudo -H’.

We could apply the patch I posted earlier, which simply disables profile
migration when SUDO_USER is set.  That won’t address the fact that root
writes to the user’s ~/.cache, but there’s not much we can do here.

Thoughts?

Ludo’.

bug#36785: Impossible to pull on foreign distro

[Gábor Boskovits]

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

Hello Ludo,

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. szept. 18., Sze,
0:04):

> Hi,
>
> Ludovic Courtès <ludo@gnu.org> skribis:
>
> > Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
> > (canonicalize-profile %user-profile-directory), and here’s what I see
> > with ‘sudo’:
> >
> > $ sudo -E ./pre-inst-env guix pull
> >
> > ;;; (pd "/var/guix/profiles/per-user/root")
> >
> > ;;; (upd "/home/ludo/.config/guix/current")
>
> I used ‘-E’ above, which is why HOME was ~ludo instead of ~root.
> Without ‘-E’, HOME is ~root as expected, and so “sudo guix pull” does
> the right thing (this is on Guix System):
>
> --8<---------------cut here---------------start------------->8---
> $ sudo guix repl
> GNU Guile 2.2.4
> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guix-user)> (getenv "HOME")
> $1 = "/root"
> scheme@(guix-user)> ,m(guix scripts pull)
> scheme@(guix scripts pull)> %profile-directory
> $2 = "/var/guix/profiles/per-user/root"
> scheme@(guix scripts pull)> %user-profile-directory
> $3 = "/root/.config/guix/current"
> scheme@(guix scripts pull)> (cache-directory)
> $4 = "/root/.cache/guix"
> scheme@(guix scripts pull)> (config-directory)
> $5 = "/root/.config/guix"
> --8<---------------cut here---------------end--------------->8---
>
> So ‘sudo guix pull’ really updates root’s profile and writes to
> ~root/.cache, everything is fine.
>
> Done?
>
> I investigated a bit, tried Debian, then Ubuntu, and found that ‘sudo’
> on Ubuntu behaves differently: it preserves ‘HOME’ by default:
>
>   $ sudo env | grep HOME
>   HOME=/home/ubuntu
>
> This is written here:
>
>
> https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells
>
> (That’s with sudo 1.8.21p2, FWIW.)
>
> Ubuntu’s /etc/sudoers doesn’t have anything special.  Actually, Debian
> has (almost) the same /etc/sudoers and yet it does not preserve HOME.
>
> (Time passes…)
>
> Digging further, I fetched the source from
> <https://packages.ubuntu.com/bionic/sudo>, and boom! I found the
> culprit: it’s called ‘debian/patches/keep_home_by_default.patch’.
>
> --8<---------------cut here---------------start------------->8---
> Description: Set HOME in initial_keepenv_table
>  Set HOME in initial_keepenv_table; without this, $HOME will never be
>  preserved unless added to keep_env.  There's appropriate logic to handle
>  resetting the home for -H and -i options, so this is the only part that's
>  missing.
> Author: Steve Langasek <steve.langasek@canonical.com>
> --- a/plugins/sudoers/env.c
> +++ b/plugins/sudoers/env.c
> @@ -189,6 +189,7 @@
>      "COLORS",
>      "DISPLAY",
>      "DPKG_COLORS",
> +    "HOME",
>      "HOSTNAME",
>      "KRB5CCNAME",
>      "LS_COLORS",
> --8<---------------cut here---------------end--------------->8---
>
> (This patch is playing with fire IMO.  If you’re an Ubuntu user,
> consider reporting a bug!)
>
> But anyway, what can we do?
>
> We could ignore the issue, it’s-Ubuntu’s-fault, done.
>
> We could also add some logic to detect whether (1) we’re running under
> sudo, and in that case, and whether (2) $HOME matches $USER’s home
> directory as it appears in /etc/passwd.  If both conditions are
> satisfied, we could ignore $HOME and use the home directory from
> /etc/passwd instead.
>
> But… that’s complicated, and it’d break uses of ‘sudo -H’.
>
> We could apply the patch I posted earlier, which simply disables profile
> migration when SUDO_USER is set.  That won’t address the fact that root
> writes to the user’s ~/.cache, but there’s not much we can do here.
>
> Thoughts?
>

We could simply document a proper sudo invocation for updating root's guix,
that
always works. Wdyt?

We could provide it simply as a hint if it fails.


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

[-- Attachment #2: Type: text/html, Size: 5773 bytes --]

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Hi,

Gábor Boskovits <boskovits@gmail.com> skribis:

> We could simply document a proper sudo invocation for updating root's guix,
> that
> always works. Wdyt?

The thing is “sudo guix pull” works on all (?) distros but Ubuntu, which
provides a patched sudo.  So we’d have to explicitly mention Ubuntu.

That’s probably a good idea, though chances are people will run “sudo
guix pull” before they’ve read that footnote in the manual.  (A
colleague of mine ran “sudo guix pull” mostly because they were used to
“sudo apt-get update” and didn’t really think ‘sudo’ was unnecessary.)

Ludo’.

bug#36785: Impossible to pull on foreign distro

[Maxim Cournoyer]

Hello,

Gábor Boskovits <boskovits@gmail.com> writes:

> Hello Ludo,
>
> Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. szept. 18., Sze,
> 0:04):
>
>> Hi,
>>
>> Ludovic Courtès <ludo@gnu.org> skribis:
>>
>> > Indeed.  I added ‘pk’ calls to print ‘%profile-directory’ and
>> > (canonicalize-profile %user-profile-directory), and here’s what I see
>> > with ‘sudo’:
>> >
>> > $ sudo -E ./pre-inst-env guix pull
>> >
>> > ;;; (pd "/var/guix/profiles/per-user/root")
>> >
>> > ;;; (upd "/home/ludo/.config/guix/current")
>>
>> I used ‘-E’ above, which is why HOME was ~ludo instead of ~root.
>> Without ‘-E’, HOME is ~root as expected, and so “sudo guix pull” does
>> the right thing (this is on Guix System):
>>
>> --8<---------------cut here---------------start------------->8---
>> $ sudo guix repl
>> GNU Guile 2.2.4
>> Copyright (C) 1995-2017 Free Software Foundation, Inc.
>>
>> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>> This program is free software, and you are welcome to redistribute it
>> under certain conditions; type `,show c' for details.
>>
>> Enter `,help' for help.
>> scheme@(guix-user)> (getenv "HOME")
>> $1 = "/root"
>> scheme@(guix-user)> ,m(guix scripts pull)
>> scheme@(guix scripts pull)> %profile-directory
>> $2 = "/var/guix/profiles/per-user/root"
>> scheme@(guix scripts pull)> %user-profile-directory
>> $3 = "/root/.config/guix/current"
>> scheme@(guix scripts pull)> (cache-directory)
>> $4 = "/root/.cache/guix"
>> scheme@(guix scripts pull)> (config-directory)
>> $5 = "/root/.config/guix"
>> --8<---------------cut here---------------end--------------->8---
>>
>> So ‘sudo guix pull’ really updates root’s profile and writes to
>> ~root/.cache, everything is fine.
>>
>> Done?
>>
>> I investigated a bit, tried Debian, then Ubuntu, and found that ‘sudo’
>> on Ubuntu behaves differently: it preserves ‘HOME’ by default:
>>
>>   $ sudo env | grep HOME
>>   HOME=/home/ubuntu
>>
>> This is written here:
>>
>>
>> https://help.ubuntu.com/community/RootSudo#Special_notes_on_sudo_and_shells
>>
>> (That’s with sudo 1.8.21p2, FWIW.)
>>
>> Ubuntu’s /etc/sudoers doesn’t have anything special.  Actually, Debian
>> has (almost) the same /etc/sudoers and yet it does not preserve HOME.
>>
>> (Time passes…)
>>
>> Digging further, I fetched the source from
>> <https://packages.ubuntu.com/bionic/sudo>, and boom! I found the
>> culprit: it’s called ‘debian/patches/keep_home_by_default.patch’.
>>
>> --8<---------------cut here---------------start------------->8---
>> Description: Set HOME in initial_keepenv_table
>>  Set HOME in initial_keepenv_table; without this, $HOME will never be
>>  preserved unless added to keep_env.  There's appropriate logic to handle
>>  resetting the home for -H and -i options, so this is the only part that's
>>  missing.
>> Author: Steve Langasek <steve.langasek@canonical.com>
>> --- a/plugins/sudoers/env.c
>> +++ b/plugins/sudoers/env.c
>> @@ -189,6 +189,7 @@
>>      "COLORS",
>>      "DISPLAY",
>>      "DPKG_COLORS",
>> +    "HOME",
>>      "HOSTNAME",
>>      "KRB5CCNAME",
>>      "LS_COLORS",
>> --8<---------------cut here---------------end--------------->8---
>>
>> (This patch is playing with fire IMO.  If you’re an Ubuntu user,
>> consider reporting a bug!)
>>
>> But anyway, what can we do?
>>
>> We could ignore the issue, it’s-Ubuntu’s-fault, done.
>>
>> We could also add some logic to detect whether (1) we’re running under
>> sudo, and in that case, and whether (2) $HOME matches $USER’s home
>> directory as it appears in /etc/passwd.  If both conditions are
>> satisfied, we could ignore $HOME and use the home directory from
>> /etc/passwd instead.
>>
>> But… that’s complicated, and it’d break uses of ‘sudo -H’.
>>
>> We could apply the patch I posted earlier, which simply disables profile
>> migration when SUDO_USER is set.  That won’t address the fact that root
>> writes to the user’s ~/.cache, but there’s not much we can do here.
>>
>> Thoughts?
>>
>
> We could simply document a proper sudo invocation for updating root's guix,
> that
> always works. Wdyt?
>
> We could provide it simply as a hint if it fails.

Indeed, the default recommended invocation to update the root's guix
could be changed to be 'sudo -i guix pull', which should work on all
systems including Ubuntu.

Maxim

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Indeed, the default recommended invocation to update the root's guix
> could be changed to be 'sudo -i guix pull', which should work on all
> systems including Ubuntu.

Oh right.  Could you make this change in the manual?

Thanks,
Ludo’.

bug#36785: Impossible to pull on foreign distro

[Maxim Cournoyer]

[-- Attachment #1.1: Type: text/plain, Size: 3968 bytes --]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Indeed, the default recommended invocation to update the root's guix
>> could be changed to be 'sudo -i guix pull', which should work on all
>> systems including Ubuntu.
>
> Oh right.  Could you make this change in the manual?
>
> Thanks,
> Ludo’.

I looked at what was in the manual, and became less sure, thought maybe
'sudo -E' could be better, so I've done the following little experiment
using Docker to test an Ubuntu enviroment:

Here's the Dockerfile, with instructions to reproduce in it:

--8<---------------cut here---------------start------------->8---
FROM ubuntu

RUN apt-get update && apt-get install sudo
RUN useradd -ms /bin/bash user
RUN usermod -aG sudo user
RUN echo user:user | chpasswd

USER user

CMD bash

# To test (in the directory where this file is written as 'Dockerfile'):
# docker build .
# docker run -it --rm <container_id>

# Then run the following commands:
# export PATH=extra-stuff:$PATH
# sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
# sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
# sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
--8<---------------cut here---------------end--------------->8---

And the result:

--8<---------------cut here---------------start------------->8---
echo $PATH
echo $PATH
extra-stuff:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0;user@e538556bf337: /\auser@e538556bf337:/$ sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
-e env when using -E:
SUDO_GID=1000
USER=root
HOSTNAME=e538556bf337
SHLVL=1
HOME=/home/user
SUDO_UID=1000
LOGNAME=root
_=/usr/bin/sudo
TERM=xterm
USERNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:[...]

SUDO_COMMAND=/bin/sh -c echo -e "env when using -E:
$(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/

0;user@e538556bf337: /\auser@e538556bf337:/$ sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
-e env when using -i:
SUDO_GID=1000
MAIL=/var/mail/root
USER=root
HOSTNAME=e538556bf337
SHLVL=1
HOME=/root
SUDO_UID=1000
LOGNAME=root
_=/bin/sh
USERNAME=root
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:ln=01;36: [...]

$(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/root

user@e538556bf337: /\auser@e538556bf337:/$ sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
-e env with plain sudo: SUDO_GID=1000
MAIL=/var/mail/root
USER=root
HOSTNAME=e538556bf337
HOME=/home/user
SUDO_UID=1000
LOGNAME=root
TERM=xterm
USERNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:ln=01;36: [...]
SUDO_COMMAND=/bin/sh -c echo -e "env with plain sudo: $(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/
--8<---------------cut here---------------end--------------->8---

What do we get from this?

Well, first, the user's PATH is *not* preserved when using 'sudo', at
least on Debian and Ubuntu.  These are configured out of the box to
reset the PATH to a 'safe' value, even when using the -E option of sudo.

We also see, as Ludovic found out, that the user's HOME is preserved for
the normal invocation of sudo on Ubuntu.

In light of this, I suggest the attached patch to our documentation.
It's a bit sub-optimal in that it modifies a section of the 'Guix
System', which behaved as described; but given that it's the only place
where we mention of 'sudo guix pull', better safe than sorry, I'd say
(foreign distribution users might read it, thinking it also applies to
themselves).

Does that seem worthwile/reasonable?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-doc-Adapt-the-guix-pull-command-recommendation.patch --]
[-- Type: text/x-patch, Size: 2011 bytes --]

From bfa2f754592a00fefa4fcd20080582268b6273dd Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Sat, 21 Sep 2019 20:36:04 +0900
Subject: [PATCH] doc: Adapt the guix pull command recommendation.

This change follows the discussion for issue #36785 (see:
https://bugs.gnu.org/36785).

* doc/guix.texi (After System Installation): Add the '-i' sudo option to the
suggested commands used to keep a Guix System up-to-date.  Although this
section is specific to Guix System, it is likely to be read by users of
foreign GNU/Linux distributions as well.  Remove the note, given that sudo
doesn't preserve the user's PATH on foreign distributions such as Debian.
---
 doc/guix.texi | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 0ed59072c9..3690e3b152 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From then on, you can update the
 system whenever you want by running, say:
 
 @example
-guix pull
-sudo guix system reconfigure /etc/config.scm
+sudo -i guix pull
+sudo -i guix system reconfigure /etc/config.scm
 @end example
 
 @noindent
@@ -2396,14 +2396,6 @@ This builds a new system generation with the latest packages and services
 (@pxref{Invoking guix system}).  We recommend doing that regularly so that
 your system includes the latest security updates (@pxref{Security Updates}).
 
-@c See <https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
-@quotation Note
-@cindex sudo vs. @command{guix pull}
-Note that @command{sudo guix} runs your user's @command{guix} command and
-@emph{not} root's, because @command{sudo} leaves @code{PATH} unchanged.  To
-explicitly run root's @command{guix}, type @command{sudo -i guix @dots{}}.
-@end quotation
-
 Join us on @code{#guix} on the Freenode IRC network or on
 @email{guix-devel@@gnu.org} to share your experience!
 
-- 
2.23.0


[-- Attachment #1.3: Type: text/plain, Size: 16 bytes --]


Thanks,

Maxim

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

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> --- a/doc/guix.texi
> +++ b/doc/guix.texi
> @@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From then on, you can update the
>  system whenever you want by running, say:
>  
>  @example
> -guix pull
> -sudo guix system reconfigure /etc/config.scm
> +sudo -i guix pull
> +sudo -i guix system reconfigure /etc/config.scm
>  @end example
>  
>  @noindent
> @@ -2396,14 +2396,6 @@ This builds a new system generation with the latest packages and services
>  (@pxref{Invoking guix system}).  We recommend doing that regularly so that
>  your system includes the latest security updates (@pxref{Security Updates}).
>  
> -@c See <https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
> -@quotation Note
> -@cindex sudo vs. @command{guix pull}
> -Note that @command{sudo guix} runs your user's @command{guix} command and
> -@emph{not} root's, because @command{sudo} leaves @code{PATH} unchanged.  To
> -explicitly run root's @command{guix}, type @command{sudo -i guix @dots{}}.
> -@end quotation

I think these bits were correct.

That is, when running “sudo foo”, “foo” is looked up in the user’s
$PATH, not in root’s $PATH.  That’s what led to this text in commit
796a4491fdaa4a0a3d669457b89356f9fbfc966e.

So this part is fine.

Perhaps we need another section for this?  Or perhaps we can drop the
ball…

Thanks,
Ludo’.

bug#36785: Impossible to pull on foreign distro

[Gábor Boskovits]

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

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2019. szept. 23., Hét
10:29):

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
> > --- a/doc/guix.texi
> > +++ b/doc/guix.texi
> > @@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From
> then on, you can update the
> >  system whenever you want by running, say:
> >
> >  @example
> > -guix pull
> > -sudo guix system reconfigure /etc/config.scm
> > +sudo -i guix pull
> > +sudo -i guix system reconfigure /etc/config.scm
> >  @end example
> >
> >  @noindent
> > @@ -2396,14 +2396,6 @@ This builds a new system generation with the
> latest packages and services
> >  (@pxref{Invoking guix system}).  We recommend doing that regularly so
> that
> >  your system includes the latest security updates (@pxref{Security
> Updates}).
> >
> > -@c See <
> https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
> > -@quotation Note
> > -@cindex sudo vs. @command{guix pull}
> > -Note that @command{sudo guix} runs your user's @command{guix} command
> and
> > -@emph{not} root's, because @command{sudo} leaves @code{PATH}
> unchanged.  To
> > -explicitly run root's @command{guix}, type @command{sudo -i guix
> @dots{}}.
> > -@end quotation
>
> I think these bits were correct.
>
> That is, when running “sudo foo”, “foo” is looked up in the user’s
> $PATH, not in root’s $PATH.  That’s what led to this text in commit
> 796a4491fdaa4a0a3d669457b89356f9fbfc966e.
>
> So this part is fine
>
I believe sudo -H would work in all distros for doing a root guix pull. Can
someone confirm?

>
> Perhaps we need another section for this?  Or perhaps we can drop the
> ball…
>
> Thanks,
> Ludo’.
>
Best regards,
g_bor

>

[-- Attachment #2: Type: text/html, Size: 2835 bytes --]

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Hi Gábor,

Gábor Boskovits <boskovits@gmail.com> skribis:

> I believe sudo -H would work in all distros for doing a root guix pull. Can
> someone confirm?

I think so, yes.

Ludo’.

bug#36785: Impossible to pull on foreign distro

[Maxim Cournoyer]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Maxim,
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> --- a/doc/guix.texi
>> +++ b/doc/guix.texi
>> @@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From then on, you can update the
>>  system whenever you want by running, say:
>>  
>>  @example
>> -guix pull
>> -sudo guix system reconfigure /etc/config.scm
>> +sudo -i guix pull
>> +sudo -i guix system reconfigure /etc/config.scm
>>  @end example
>>  
>>  @noindent
>> @@ -2396,14 +2396,6 @@ This builds a new system generation with the latest packages and services
>>  (@pxref{Invoking guix system}).  We recommend doing that regularly so that
>>  your system includes the latest security updates (@pxref{Security Updates}).
>>  
>> -@c See <https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
>> -@quotation Note
>> -@cindex sudo vs. @command{guix pull}
>> -Note that @command{sudo guix} runs your user's @command{guix} command and
>> -@emph{not} root's, because @command{sudo} leaves @code{PATH} unchanged.  To
>> -explicitly run root's @command{guix}, type @command{sudo -i guix @dots{}}.
>> -@end quotation
>
> I think these bits were correct.

They are correct when applied to a Guix System; what my commits aim to
do is make them generally true regardless of the Guix System vs foreign
distro situation, in an attempt to negate possible confusion.  It's not
succeeding, obviously :-).

I had modified that bit of the manual because that's apparently the only
place where we mention 'sudo guix pull' in the manual.

In the commit message I wrote:

   Although this section is specific to Guix System, it is likely to be
   read by users of foreign GNU/Linux distributions as well.  Remove the
   note, given that sudo doesn't preserve the user's PATH on foreign
   distributions such as Debian.

> That is, when running “sudo foo”, “foo” is looked up in the user’s
> $PATH, not in root’s $PATH.  That’s what led to this text in commit
> 796a4491fdaa4a0a3d669457b89356f9fbfc966e.
>
> So this part is fine.
>
> Perhaps we need another section for this?  Or perhaps we can drop the
> ball…

Agreed, until more real use cases come so that the proper solution can
be more clear (in regards to what needs to be changed in the manual).

Maxim

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hi Maxim,
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> --- a/doc/guix.texi
>>> +++ b/doc/guix.texi
>>> @@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From then on, you can update the
>>>  system whenever you want by running, say:
>>>  
>>>  @example
>>> -guix pull
>>> -sudo guix system reconfigure /etc/config.scm
>>> +sudo -i guix pull
>>> +sudo -i guix system reconfigure /etc/config.scm
>>>  @end example
>>>  
>>>  @noindent
>>> @@ -2396,14 +2396,6 @@ This builds a new system generation with the latest packages and services
>>>  (@pxref{Invoking guix system}).  We recommend doing that regularly so that
>>>  your system includes the latest security updates (@pxref{Security Updates}).
>>>  
>>> -@c See <https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
>>> -@quotation Note
>>> -@cindex sudo vs. @command{guix pull}
>>> -Note that @command{sudo guix} runs your user's @command{guix} command and
>>> -@emph{not} root's, because @command{sudo} leaves @code{PATH} unchanged.  To
>>> -explicitly run root's @command{guix}, type @command{sudo -i guix @dots{}}.
>>> -@end quotation
>>
>> I think these bits were correct.
>
> They are correct when applied to a Guix System;

It’s a paragraph that explains how to upgrade Guix System, so I think
foreign distros should be discussed elsewhere.  (I appreciate your
attempt to add proper documentation about that for foreign distros!)

> what my commits aim to do is make them generally true regardless of
> In the commit message I wrote:
>
>    Although this section is specific to Guix System, it is likely to be
>    read by users of foreign GNU/Linux distributions as well.  Remove the
>    note, given that sudo doesn't preserve the user's PATH on foreign
>    distributions such as Debian.

But users of foreign distros would hopefully realize that ‘guix system
reconfigure’ (in the same snippet) is not for them.  :-)

What about adding a section that we could call “Upgrading Guix”
under “Application Setup”, which is where setup on foreign distros is
discussed?

The section could say:

  1. Run ‘guix pull’ to upgrade Guix.

  2. When you need to upgrade the build daemon, for instance, which runs
     as root, run:

       sudo -i guix pull

How does that sound?

Thanks,
Ludo’.

bug#36785: Impossible to pull on foreign distro

[Maxim Cournoyer]

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

Hi!

Ludovic Courtès <ludo@gnu.org> writes:

[...]

> It’s a paragraph that explains how to upgrade Guix System, so I think
> foreign distros should be discussed elsewhere.  (I appreciate your
> attempt to add proper documentation about that for foreign distros!)
>
>> what my commits aim to do is make them generally true regardless of
>> In the commit message I wrote:
>>
>>    Although this section is specific to Guix System, it is likely to be
>>    read by users of foreign GNU/Linux distributions as well.  Remove the
>>    note, given that sudo doesn't preserve the user's PATH on foreign
>>    distributions such as Debian.
>
> But users of foreign distros would hopefully realize that ‘guix system
> reconfigure’ (in the same snippet) is not for them.  :-)

I've been guilty myself of using C-s or 'i' in the manual and reading
something that didn't apply to my system but *did* match my
search... :-) 

>> What about adding a section that we could call “Upgrading Guix”
> under “Application Setup”, which is where setup on foreign distros is
> discussed?
>
> The section could say:
>
>   1. Run ‘guix pull’ to upgrade Guix.
>
>   2. When you need to upgrade the build daemon, for instance, which runs
>      as root, run:
>
>        sudo -i guix pull
>
> How does that sound?

This sounds much simpler than attempting to twist some other section
into something it wasn't really meant for ;-).

I've attached a simple patch implementing the idea.

Thanks for your patience!

Maxim


[-- Attachment #2: 0001-doc-Add-a-Upgrading-Guix-section-to-the-Installation.patch --]
[-- Type: text/x-patch, Size: 1966 bytes --]

From a289eb3fd6239287d4a802fbba69abf21604591f Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Sat, 28 Sep 2019 00:11:28 +0900
Subject: [PATCH] doc: Add a 'Upgrading Guix' section to the 'Installation'
 chapter.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This follows a discussion regarding issue #36785 (see:
https://bugs.gnu.org/36785).

* doc/guix.texi (Upgrading Guix): New section.

Co-authored-by: Ludovic Courtès <ludo@gnu.org>
---
 doc/guix.texi | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/doc/guix.texi b/doc/guix.texi
index 9fcce27597..45e6dfc442 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -513,6 +513,7 @@ ready to use it.
 * Setting Up the Daemon::       Preparing the build daemon's environment.
 * Invoking guix-daemon::        Running the build daemon.
 * Application Setup::           Application-specific setup.
+* Upgrading Guix::              Upgrading Guix and its build daemon.
 @end menu
 
 @node Binary Installation
@@ -1777,6 +1778,28 @@ invoke the actual linker with this new set of arguments.  You can instruct the
 wrapper to refuse to link against libraries not in the store by setting the
 @code{GUIX_LD_WRAPPER_ALLOW_IMPURITIES} environment variable to @code{no}.
 
+@node Upgrading Guix
+@section Upgrading Guix
+
+@cindex Upgrading Guix, on a foreign distro
+
+To upgrade Guix, run:
+
+@example
+guix pull
+@end example
+
+@cindex Upgrading Guix for the root user, on a foreign distro
+@cindex Upgrading the Guix daemon, on a foreign distro
+@cindex @command{guix pull} for the root user, on a foreign distro
+
+When you need to upgrade the build daemon, for instance, which runs as
+root, run:
+
+@example
+sudo -i guix pull
+@end example
+
 @c TODO What else?
 
 @c *********************************************************************
-- 
2.23.0

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Hi Maxim!

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> From a289eb3fd6239287d4a802fbba69abf21604591f Mon Sep 17 00:00:00 2001
> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
> Date: Sat, 28 Sep 2019 00:11:28 +0900
> Subject: [PATCH] doc: Add a 'Upgrading Guix' section to the 'Installation'
>  chapter.
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> This follows a discussion regarding issue #36785 (see:
> https://bugs.gnu.org/36785).
>
> * doc/guix.texi (Upgrading Guix): New section.
>
> Co-authored-by: Ludovic Courtès <ludo@gnu.org>

[...]

> +@node Upgrading Guix
> +@section Upgrading Guix
> +
> +@cindex Upgrading Guix, on a foreign distro

Nitpicking: index entries are usually lower-case.

> +To upgrade Guix, run:
> +
> +@example
> +guix pull
> +@end example

Perhaps add:

  @xref{Invoking guix pull}, for more information.

> +When you need to upgrade the build daemon, for instance, which runs as
> +root, run:
> +
> +@example
> +sudo -i guix pull
> +@end example

What about restating upfront that we’re talking about foreign distros
specifically:

  On a foreign distro, you can upgrade the build daemon by running:

  @example
  sudo -i guix pull
  @end example

  @noindent
  followed by (assuming your distro uses the systemd service management
  tool):

  @example
  systemctl restart guix-daemon.service
  @end example

  On Guix System, upgrading the daemon is achieved by reconfiguring the
  system (@pxref{Invoking guix system, @code{guix system reconfigure}}).

?

Feel free to push something along these lines.

Thank you,
Ludo’.

bug#36785: Impossible to pull on foreign distro

[Maxim Cournoyer]

Hello Ludovic!

Ludovic Courtès <ludo@gnu.org> writes:

> Hi Maxim!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> From a289eb3fd6239287d4a802fbba69abf21604591f Mon Sep 17 00:00:00 2001
>> From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
>> Date: Sat, 28 Sep 2019 00:11:28 +0900
>> Subject: [PATCH] doc: Add a 'Upgrading Guix' section to the 'Installation'
>>  chapter.
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> This follows a discussion regarding issue #36785 (see:
>> https://bugs.gnu.org/36785).
>>
>> * doc/guix.texi (Upgrading Guix): New section.
>>
>> Co-authored-by: Ludovic Courtès <ludo@gnu.org>
>
> [...]
>
>> +@node Upgrading Guix
>> +@section Upgrading Guix
>> +
>> +@cindex Upgrading Guix, on a foreign distro
>
> Nitpicking: index entries are usually lower-case.

Oh! I hadn't realized this was the convention used in Guix, thanks for
pointing it out.

>> +To upgrade Guix, run:
>> +
>> +@example
>> +guix pull
>> +@end example
>
> Perhaps add:
>
>   @xref{Invoking guix pull}, for more information.
>
>> +When you need to upgrade the build daemon, for instance, which runs as
>> +root, run:
>> +
>> +@example
>> +sudo -i guix pull
>> +@end example
>
> What about restating upfront that we’re talking about foreign distros
> specifically:
>
>   On a foreign distro, you can upgrade the build daemon by running:
>
>   @example
>   sudo -i guix pull
>   @end example
>
>   @noindent
>   followed by (assuming your distro uses the systemd service management
>   tool):
>
>   @example
>   systemctl restart guix-daemon.service
>   @end example
>
>   On Guix System, upgrading the daemon is achieved by reconfiguring the
>   system (@pxref{Invoking guix system, @code{guix system reconfigure}}).
>
> ?

Great additions.

> Feel free to push something along these lines.

Pushed as 5510bb01e9.

Thank you!

Maxim

bug#36785: Impossible to pull on foreign distro

[Maxim Cournoyer]

[-- Attachment #1.1: Type: text/plain, Size: 3968 bytes --]

Hello,

Ludovic Courtès <ludo@gnu.org> writes:

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Indeed, the default recommended invocation to update the root's guix
>> could be changed to be 'sudo -i guix pull', which should work on all
>> systems including Ubuntu.
>
> Oh right.  Could you make this change in the manual?
>
> Thanks,
> Ludo’.

I looked at what was in the manual, and became less sure, thought maybe
'sudo -E' could be better, so I've done the following little experiment
using Docker to test an Ubuntu enviroment:

Here's the Dockerfile, with instructions to reproduce in it:

--8<---------------cut here---------------start------------->8---
FROM ubuntu

RUN apt-get update && apt-get install sudo
RUN useradd -ms /bin/bash user
RUN usermod -aG sudo user
RUN echo user:user | chpasswd

USER user

CMD bash

# To test (in the directory where this file is written as 'Dockerfile'):
# docker build .
# docker run -it --rm <container_id>

# Then run the following commands:
# export PATH=extra-stuff:$PATH
# sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
# sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
# sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
--8<---------------cut here---------------end--------------->8---

And the result:

--8<---------------cut here---------------start------------->8---
echo $PATH
echo $PATH
extra-stuff:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0;user@e538556bf337: /\auser@e538556bf337:/$ sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
sudo -E sh -c 'echo -e "env when using -E: \n$(env)\n\n"'
-e env when using -E:
SUDO_GID=1000
USER=root
HOSTNAME=e538556bf337
SHLVL=1
HOME=/home/user
SUDO_UID=1000
LOGNAME=root
_=/usr/bin/sudo
TERM=xterm
USERNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:[...]

SUDO_COMMAND=/bin/sh -c echo -e "env when using -E:
$(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/

0;user@e538556bf337: /\auser@e538556bf337:/$ sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
sudo -i sh -c 'echo -e "env when using -i: \n$(env)\n\n"'
-e env when using -i:
SUDO_GID=1000
MAIL=/var/mail/root
USER=root
HOSTNAME=e538556bf337
SHLVL=1
HOME=/root
SUDO_UID=1000
LOGNAME=root
_=/bin/sh
USERNAME=root
TERM=xterm
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:ln=01;36: [...]

$(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/root

user@e538556bf337: /\auser@e538556bf337:/$ sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
sudo sh -c 'echo -e "env with plain sudo: $(env)\n\n"'
-e env with plain sudo: SUDO_GID=1000
MAIL=/var/mail/root
USER=root
HOSTNAME=e538556bf337
HOME=/home/user
SUDO_UID=1000
LOGNAME=root
TERM=xterm
USERNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
LS_COLORS=rs=0:di=01;34:ln=01;36: [...]
SUDO_COMMAND=/bin/sh -c echo -e "env with plain sudo: $(env)

"
SHELL=/bin/bash
SUDO_USER=user
PWD=/
--8<---------------cut here---------------end--------------->8---

What do we get from this?

Well, first, the user's PATH is *not* preserved when using 'sudo', at
least on Debian and Ubuntu.  These are configured out of the box to
reset the PATH to a 'safe' value, even when using the -E option of sudo.

We also see, as Ludovic found out, that the user's HOME is preserved for
the normal invocation of sudo on Ubuntu.

In light of this, I suggest the attached patch to our documentation.
It's a bit sub-optimal in that it modifies a section of the 'Guix
System', which behaved as described; but given that it's the only place
where we mention of 'sudo guix pull', better safe than sorry, I'd say
(foreign distribution users might read it, thinking it also applies to
themselves).

Does that seem worthwile/reasonable?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: 0001-doc-Adapt-the-guix-pull-command-recommendation.patch --]
[-- Type: text/x-patch, Size: 2011 bytes --]

From bfa2f754592a00fefa4fcd20080582268b6273dd Mon Sep 17 00:00:00 2001
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
Date: Sat, 21 Sep 2019 20:36:04 +0900
Subject: [PATCH] doc: Adapt the guix pull command recommendation.

This change follows the discussion for issue #36785 (see:
https://bugs.gnu.org/36785).

* doc/guix.texi (After System Installation): Add the '-i' sudo option to the
suggested commands used to keep a Guix System up-to-date.  Although this
section is specific to Guix System, it is likely to be read by users of
foreign GNU/Linux distributions as well.  Remove the note, given that sudo
doesn't preserve the user's PATH on foreign distributions such as Debian.
---
 doc/guix.texi | 12 ++----------
 1 file changed, 2 insertions(+), 10 deletions(-)

diff --git a/doc/guix.texi b/doc/guix.texi
index 0ed59072c9..3690e3b152 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -2387,8 +2387,8 @@ Success, you've now booted into Guix System!  From then on, you can update the
 system whenever you want by running, say:
 
 @example
-guix pull
-sudo guix system reconfigure /etc/config.scm
+sudo -i guix pull
+sudo -i guix system reconfigure /etc/config.scm
 @end example
 
 @noindent
@@ -2396,14 +2396,6 @@ This builds a new system generation with the latest packages and services
 (@pxref{Invoking guix system}).  We recommend doing that regularly so that
 your system includes the latest security updates (@pxref{Security Updates}).
 
-@c See <https://lists.gnu.org/archive/html/guix-devel/2019-01/msg00268.html>.
-@quotation Note
-@cindex sudo vs. @command{guix pull}
-Note that @command{sudo guix} runs your user's @command{guix} command and
-@emph{not} root's, because @command{sudo} leaves @code{PATH} unchanged.  To
-explicitly run root's @command{guix}, type @command{sudo -i guix @dots{}}.
-@end quotation
-
 Join us on @code{#guix} on the Freenode IRC network or on
 @email{guix-devel@@gnu.org} to share your experience!
 
-- 
2.23.0


[-- Attachment #1.3: Type: text/plain, Size: 16 bytes --]


Thanks,

Maxim

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

bug#36785: Impossible to pull on foreign distro

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Digging further, I fetched the source from
> <https://packages.ubuntu.com/bionic/sudo>, and boom! I found the
> culprit: it’s called ‘debian/patches/keep_home_by_default.patch’.
>
> --8<---------------cut here---------------start------------->8---
> Description: Set HOME in initial_keepenv_table
>  Set HOME in initial_keepenv_table; without this, $HOME will never be 
>  preserved unless added to keep_env.  There's appropriate logic to handle
>  resetting the home for -H and -i options, so this is the only part that's
>  missing.
> Author: Steve Langasek <steve.langasek@canonical.com>
> --- a/plugins/sudoers/env.c
> +++ b/plugins/sudoers/env.c
> @@ -189,6 +189,7 @@
>      "COLORS",
>      "DISPLAY",
>      "DPKG_COLORS",
> +    "HOME",
>      "HOSTNAME",
>      "KRB5CCNAME",
>      "LS_COLORS",
> --8<---------------cut here---------------end--------------->8---
>
> (This patch is playing with fire IMO.  If you’re an Ubuntu user,
> consider reporting a bug!)

Wow.  Changing fundamental behaviour like that is bad.

> We could apply the patch I posted earlier, which simply disables profile
> migration when SUDO_USER is set.  That won’t address the fact that root
> writes to the user’s ~/.cache, but there’s not much we can do here.

This sounds fine to me.

-- 
Ricardo

bug#36785: Impossible to pull on foreign distro

[Ludovic Courtès]

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>> We could apply the patch I posted earlier, which simply disables profile
>> migration when SUDO_USER is set.  That won’t address the fact that root
>> writes to the user’s ~/.cache, but there’s not much we can do here.
>
> This sounds fine to me.

I went ahead and pushed that as
ee25048e51dd45ad91a1ad4b0f25f4013843c52b.

Thanks,
Ludo’.