Hacks to install Guix packages without root

Hacks to install Guix packages without root

[Ricardo Wurmus]

Hi,

this blog post contains many great examples of how to deploy Guix
applications without root access:

    http://guix-hpc.bordeaux.inria.fr/blog/2017/10/using-guix-without-being-root/

I think that all of these methods should be wrapped up by Guix itself,
so that none of this has to be done manually.  I’d also like to include
Pjotr’s hack in this, which involves rewriting /gnu/store references.
It’s icky but effective and one of the reasons why Conda is so popular
(they rewrite references in their binaries as well, but less principled
than, say, grafts).

How about an extension of “guix pack” that will rewrite the /gnu/store
references to a user-provided directory before bundling things up in a
tarball?  I’d *really* like to be able to just use the tarball bundle
“guix pack” produces by default, but currently deploying it requires
root access or proot shenanigans at runtime.

How about making manual hacking with unshare and chroot obsolete by
including a simple executable in the pack that handles this rewriting
for the user…?  With that we would be one step closer to the user
experience of Docker — without having a runtime dependency on Docker.

What do you think?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Hacks to install Guix packages without root

[Ludovic Courtès]

Hi!

Ricardo Wurmus <rekado@elephly.net> skribis:

> How about an extension of “guix pack” that will rewrite the /gnu/store
> references to a user-provided directory before bundling things up in a
> tarball?

I’ve thought about this (we have rewriting machinery in (guix build
grafts) that we could adjust and use), but then I thought that maybe
PRoot, unshare, and all the rest are good enough?

> I’d *really* like to be able to just use the tarball bundle “guix
> pack” produces by default, but currently deploying it requires root
> access or proot shenanigans at runtime.
>
> How about making manual hacking with unshare and chroot obsolete by
> including a simple executable in the pack that handles this rewriting
> for the user…?

The tarballs could include proot-static and another statically-linked
program that essentially tries to call unshare(2).  Would that make
sense?

> With that we would be one step closer to the user experience of Docker
> — without having a runtime dependency on Docker.

It’s also fine to use Docker when it’s available, I think.

Thoughts?

Ludo’.

Re: Hacks to install Guix packages without root

[Pjotr Prins]

On Thu, Oct 26, 2017 at 05:48:20PM -0700, Ludovic Courtès wrote:
> Hi!
> 
> Ricardo Wurmus <rekado@elephly.net> skribis:
> 
> > How about an extension of “guix pack” that will rewrite the /gnu/store
> > references to a user-provided directory before bundling things up in a
> > tarball?
> 
> I’ve thought about this (we have rewriting machinery in (guix build
> grafts) that we could adjust and use), but then I thought that maybe
> PRoot, unshare, and all the rest are good enough?

PRoot is too slow for most HPC purposes but can be used to build
non-proot binaries, as I do here:

  https://gitlab.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org

But it is a roundabout way and too much for most people to handle.
Also we are not reusing Guix binaries that way.

> The tarballs could include proot-static and another statically-linked
> program that essentially tries to call unshare(2).  Would that make
> sense?

proot is a no-go for actual use involving IO.

> > With that we would be one step closer to the user experience of Docker
> > — without having a runtime dependency on Docker.
> 
> It’s also fine to use Docker when it’s available, I think.

Docker is a no-go on 90% HPC's out there (that number may go down
slowly). Also Docker is a royal pain to deal with: every time I have
to install it somewhere it gives me some grief. I don't think it is
that useful for distributing software.

I think if we have a proper replacement for Docker - like Conda does -
the need for Docker will actually go away.

+1 for providing relocatable packages as far as I am concerned.

Pj.

Re: Hacks to install Guix packages without root

[Dave Love]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> PRoot is too slow for most HPC purposes but can be used to build
> non-proot binaries, as I do here:
>
>   https://gitlab.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org

I've never tried to measure it, but how does it affect most HPC
purposes?  It's not as if they're going to be using a lot of syscalls.
(However, it's not clear to me how PRoot wins over fakeroot+fakechroot.)

>> The tarballs could include proot-static and another statically-linked
>> program that essentially tries to call unshare(2).  Would that make
>> sense?
>
> proot is a no-go for actual use involving IO.

Presumably that depends on the i/o (amount and type, which might just be
in userspace).

>> > With that we would be one step closer to the user experience of Docker
>> > — without having a runtime dependency on Docker.
>> 
>> It’s also fine to use Docker when it’s available, I think.
>
> Docker is a no-go on 90% HPC's out there (that number may go down
> slowly).

[Perhaps not as many as it should be no go...]

> Also Docker is a royal pain to deal with: every time I have
> to install it somewhere it gives me some grief. I don't think it is
> that useful for distributing software.
>
> I think if we have a proper replacement for Docker - like Conda does -
> the need for Docker will actually go away.

What would a proper replacement do that existing solutions don't?  Also,
what does Conda provide?  I don't remember seeing anything like that
with it.

Re: Hacks to install Guix packages without root

[Pjotr Prins]

On Tue, Oct 31, 2017 at 02:19:55PM +0000, Dave Love wrote:
> Pjotr Prins <pjotr.public12@thebird.nl> writes:
> 
> > PRoot is too slow for most HPC purposes but can be used to build
> > non-proot binaries, as I do here:
> >
> >   https://gitlab.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org
> 
> I've never tried to measure it, but how does it affect most HPC
> purposes?  It's not as if they're going to be using a lot of syscalls.
> (However, it's not clear to me how PRoot wins over fakeroot+fakechroot.)

Best to try for the specific use case. For bioinformatics it won't
work.

> >> The tarballs could include proot-static and another statically-linked
> >> program that essentially tries to call unshare(2).  Would that make
> >> sense?
> >
> > proot is a no-go for actual use involving IO.
> 
> Presumably that depends on the i/o (amount and type, which might just be
> in userspace).

yes

> >> > With that we would be one step closer to the user experience of Docker
> >> > — without having a runtime dependency on Docker.
> >> 
> >> It’s also fine to use Docker when it’s available, I think.
> >
> > Docker is a no-go on 90% HPC's out there (that number may go down
> > slowly).
> 
> [Perhaps not as many as it should be no go...]
> 
> > Also Docker is a royal pain to deal with: every time I have
> > to install it somewhere it gives me some grief. I don't think it is
> > that useful for distributing software.
> >
> > I think if we have a proper replacement for Docker - like Conda does -
> > the need for Docker will actually go away.
> 
> What would a proper replacement do that existing solutions don't?  Also,
> what does Conda provide?  I don't remember seeing anything like that
> with it.

I was not clear. Conda essentially is a light replacement for Docker
if you just think of Docker as a deployment option *only*. Docker 
is overkill for just deploying software. Guix proves that. Conda
proves that too though it is less robust than Guix and less well at
handling dependencies. Both have support for containers thrown in.

In other words, in my area, quite a few people started preferring Conda over
Docker and replacing it in practise. That is what I meant to say.

Docker is not going away, mind. We may end up putting Conda and Guix
in Docker containers ;)

Pj.

-- 

Re: Hacks to install Guix packages without root

[Dave Love]

Pjotr Prins <pjotr.public12@thebird.nl> writes:

> On Tue, Oct 31, 2017 at 02:19:55PM +0000, Dave Love wrote:
>> Pjotr Prins <pjotr.public12@thebird.nl> writes:
>> 
>> > PRoot is too slow for most HPC purposes but can be used to build
>> > non-proot binaries, as I do here:
>> >
>> >   https://gitlab.com/pjotrp/guix-notes/blob/master/GUIX-NO-ROOT.org
>> 
>> I've never tried to measure it, but how does it affect most HPC
>> purposes?  It's not as if they're going to be using a lot of syscalls.
>> (However, it's not clear to me how PRoot wins over fakeroot+fakechroot.)
>
> Best to try for the specific use case. For bioinformatics it won't
> work.

This may be a bit off-topic, but perhaps it helps in packaging:  I don't
know whether that refers to using PRoot or fakechroot, but anyway,
what specifically is the problem in bioinformatics?

By the way, I measured compressed tar/untar under PRoot on CentOS 6 of
the CentOS root image.  It's around a factor of two slower than native
on untar and about 40% slower on tar.

>> What would a proper replacement do that existing solutions don't?  Also,
>> what does Conda provide?  I don't remember seeing anything like that
>> with it.
>
> I was not clear. Conda essentially is a light replacement for Docker
> if you just think of Docker as a deployment option *only*. Docker 
> is overkill for just deploying software. Guix proves that.

Oh, sure, and there are longer standing solutions anyhow, if OS packages
are out.

> Conda
> proves that too though it is less robust than Guix and less well at
> handling dependencies. Both have support for containers thrown in.

[I didn't realize conda had containers built in, but it seems
Python-centric anyway.]

> In other words, in my area, quite a few people started preferring Conda over
> Docker and replacing it in practise. That is what I meant to say.
>
> Docker is not going away, mind. We may end up putting Conda and Guix
> in Docker containers ;)

Does that mean containers or images?  (The way the terminology has gone
is rather unhelpful...)  Docker is a nightmare for use with HPC-type
resource managers, but you can run from OCI-type images more sanely, of
course.

I probably basically agree!

Re: Hacks to install Guix packages without root

[Pjotr Prins]

On Mon, Nov 06, 2017 at 03:03:30PM +0000, Dave Love wrote:
> > Best to try for the specific use case. For bioinformatics it won't
> > work.
> 
> This may be a bit off-topic, but perhaps it helps in packaging:  I don't
> know whether that refers to using PRoot or fakechroot, but anyway,
> what specifically is the problem in bioinformatics?

Large data sets. Many files.

> By the way, I measured compressed tar/untar under PRoot on CentOS 6 of
> the CentOS root image.  It's around a factor of two slower than native
> on untar and about 40% slower on tar.

Exactly. Too slow when IO is already the bottleneck.

> > Docker is not going away, mind. We may end up putting Conda and Guix
> > in Docker containers ;)
> 
> Does that mean containers or images?  (The way the terminology has gone
> is rather unhelpful...)  

Containers.

> Docker is a nightmare for use with HPC-type
> resource managers, but you can run from OCI-type images more sanely, of
> course.

There is no love between Docker and me ;)

> I probably basically agree!

Probably :)


-- 

Re: Hacks to install Guix packages without root

[Konrad Hinsen]

On 26/10/2017 23:46, Ricardo Wurmus wrote:

> How about an extension of “guix pack” that will rewrite the /gnu/store
> references to a user-provided directory before bundling things up in a
> tarball?  I’d *really* like to be able to just use the tarball bundle
> “guix pack” produces by default, but currently deploying it requires
> root access or proot shenanigans at runtime.

That would be nice indeed as a deployment option. In particular for 
distributing binaries to less experienced users.


On 27/10/2017 02:48, Ludovic Courtès wrote:

 > The tarballs could include proot-static and another statically-linked
 > program that essentially tries to call unshare(2).  Would that make
 > sense?

That's perhaps good enough as well. Suggestion: try to write the user 
instructions for deploying these tarballs first, and pick the method 
that is easiest to describe.

I see basically two usage scenarios. One is a form of software 
installation: users download a tarball, follow the instruction 
procedure, and than have some additional commands in their PATH. The 
other scenario is the creation of a somewhat isolated environment, with 
users wanting a shell for working in just that environment. For that 
second scenario, proot is probably just fine, but I am less convinced 
about the first one.

Konrad.

Re: Hacks to install Guix packages without root

[Pjotr Prins]

On Thu, Oct 26, 2017 at 11:46:52PM +0200, Ricardo Wurmus wrote:
> Hi,
> 
> this blog post contains many great examples of how to deploy Guix
> applications without root access:
> 
>     http://guix-hpc.bordeaux.inria.fr/blog/2017/10/using-guix-without-being-root/
> 
> I think that all of these methods should be wrapped up by Guix itself,
> so that none of this has to be done manually.  I’d also like to include
> Pjotr’s hack in this, which involves rewriting /gnu/store references.
> It’s icky but effective and one of the reasons why Conda is so popular
> (they rewrite references in their binaries as well, but less principled
> than, say, grafts).
> 
> How about an extension of “guix pack” that will rewrite the /gnu/store
> references to a user-provided directory before bundling things up in a
> tarball?  I’d *really* like to be able to just use the tarball bundle
> “guix pack” produces by default, but currently deploying it requires
> root access or proot shenanigans at runtime.
> 
> How about making manual hacking with unshare and chroot obsolete by
> including a simple executable in the pack that handles this rewriting
> for the user…?  With that we would be one step closer to the user
> experience of Docker — without having a runtime dependency on Docker.

I wrote a fast executable in D that does that

  https://gitlab.com/pjotrp/guix-relocate/blob/master/src/main.d

It is part of my installer which I wrote in Ruby (sorry, I know ;)

  https://gitlab.com/pjotrp/gnu-install-bin/blob/master/bin/gnu-install-bin

Note it first uses Nix's patchelf and then the D program - I could
have linked the two, but did not bother. The logic is here:

  https://gitlab.com/pjotrp/gnu-install-bin/blob/master/lib/installer.rb

I remember sweating over this in a dark hotel in Zanzibar last winter.
There was a heat wave and the airco was ineffective. It was a fun
thing to do, even so.

Pj