'sudo guix pull' failure in the profile migration code

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.

Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

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

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

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?

Hi Julien,

Julien Lepiller <julien@lepiller.eu> skribis:

[...]

[...]

Indeed. I added ‘pk’ calls to print ‘%profile-directory’ and

(canonicalize-profile %user-profile-directory), and here’s what I see

with ‘sudo’:

‘%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:

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

Otherwise I’m thinking of this gross hack:

I think it’s acceptable because that’s “throw away” code anyway, and

it’s not supposed to be triggered these days.

Thoughts?

Ludo’.

retitle 36785 'sudo guix pull' failure in the profile migration code

quit

merge 36785 37148

quit

Hi,

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

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

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

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

Hello Ludo,

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

0:04):

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.

Best regards,

g_bor

--

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

Hi,

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

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

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

Wow. Changing fundamental behaviour like that is bad.

This sounds fine to me.

--

Ricardo

Hi,

Ricardo Wurmus <rekado@elephly.net> skribis:

[...]

I went ahead and pushed that as

ee25048e51dd45ad91a1ad4b0f25f4013843c52b.

Thanks,

Ludo’.

Hello,

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

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

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

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

Thanks,

Ludo’.

Hello,

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

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:

And the result:

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?

Thanks,

Maxim

Hello,

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

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:

And the result:

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?

Thanks,

Maxim

Hi Maxim,

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

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

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

10:29):

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

someone confirm?

Best regards,

g_bor

Hi Gábor,

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

I think so, yes.

Ludo’.

Hello,

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

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.

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

Hi,

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

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

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

Hi!

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

[...]

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

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

Hi Maxim!

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

[...]

Nitpicking: index entries are usually lower-case.

Perhaps add:

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

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

Hello Ludovic!

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

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

pointing it out.

Great additions.

Pushed as 5510bb01e9.

Thank you!

Maxim