Environment containers

Environment containers

[Thompson, David]

Hello Guix hackers,

I am pleased to announce that the patch for adding Linux container
support to 'guix environment' has just landed in master!

Why is this cool, you ask?  Well, it enables one to truly isolate
development environments from the rest of the system, much more so
than --pure does.  The --pure option only clears the environment
variables, but --container goes further and "unshares" kernel
resources (such as the user, mount, and pid namespaces) and creates a
chroot environment that has no file system access to what might be
considered "impurities."  The only file systems from the host that
make it into the container by default are the current working
directory and the store paths for all of the needed software.  This is
especially useful when running Guix on top of another host distro,
where sometimes things from the host sneak into your build environment
because a tool decided to inspect the contents of /usr or something.

You can use it like this:

    guix environment --container guix

The above command will create an isolated container with everything
you need to build Guix from source.

There's more fun to be had, too.  Sometimes it's nice to make ad-hoc
sandboxes just to play around in.  The below command will run a
sandboxed Guile REPL:

    guix environment --container --ad-hoc guile -- guile

By default, containers have no network access.  To share the host
network, use the --network flag.

This is just the beginning!  There's lots more to do.  It would be
nice to be able to create a network bridge so that the container can
have network access without sharing the host devices, a la Docker and
friends.  It would also be great to incorporate cgroups to arbitrarily
restrict container resources.

Coming soon is 'guix system container', which creates full-blown
GuixSD containers.

Since I mentioned Docker, I'd like to point some significant
advantages that Guix containers have over other implementations:

1) The container tools I'm working on are completely declarative.  No
imperative Dockerfiles!  This means that you don't have to worry about
order of operations, something that you have to think about constantly
when using Docker, especially when trying to maximize the use of the
image cache.

2) There are no disk images.  Disk images are opaque blobs that are
often not reproducible, whereas the items in the Guix store tell you
the full story of how the software came to be.  Thus, Guix containers
do not worry at all about the complications involved with layering
disk images in an overlayfs-style setup.  They are simply not needed.

3) Software and other files shared amongst many containers are
deduplicated system-wide.  This is a big deal from my perspective.
With Docker, container images *must* share as many base image layers
as possible to take advantage of deduplication, and there's
limitations to how smart overlay file systems can be to do
deduplication in memory (citation missing because I can't find the
article that explained the issues.)  Some people say that Docker is a
higher-level form of static linking, but instead of static linking the
executables, you "statically link" an entire, albeit more minimal,
operating system for each application that you run.  I'm inclined to
agree, and I'm happy to say that Guix doesn't have this problem.  A
store item present in N containers exists in exactly one place: in the
host store.  We take great advantage of bind mounts to share
everything without duplication.  Once again the fundamental building
block of every Guix tool, the immutable store, proves to be an
invaluable asset in overcoming the problems of our imperative
predecessors and contemporaries.

I hope this excites some of you.  Containers are all the rage right
now, and they have some seriously good properties if you can look past
the Docker hype.  I'd love to get some more hands to help make Guix
containers more featureful and robust in order to compete with the
mainstream tools.

Until next time, happy hacking!

- Dave

Re: Environment containers

[Daniel Pimentel]

It's great!

Thanks,

-- 
Daniel Pimentel (d4n1 3:)

Re: Environment containers

[Alex Vong]

On 26/10/2015, Daniel Pimentel <d4n1@openmailbox.org> wrote:
> It's great!
>
> Thanks,
>
> --
> Daniel Pimentel (d4n1 3:)
>
>

Indeed. With my limited disk space, I find point 3 most attractive. I
also like how the store immutability avoids the duplication problem.
The latest version is not yet available from guix pull though.

Cheers,
Alex

Re: Environment containers

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> I am pleased to announce that the patch for adding Linux container
> support to 'guix environment' has just landed in master!

Thanks for all the work, this is all very exciting!

Ludo’.

Re: Environment containers

[Taylan Ulrich Bayırlı/Kammer]

"Thompson, David" <dthompson2@worcester.edu> writes:

> Hello Guix hackers,
>
> I am pleased to announce that the patch for adding Linux container
> support to 'guix environment' has just landed in master!
>
> Why is this cool, you ask?  Well, it enables one to truly isolate
> development environments from the rest of the system, much more so
> than --pure does.  The --pure option only clears the environment
> variables, but --container goes further and "unshares" kernel
> resources (such as the user, mount, and pid namespaces) and creates a
> chroot environment that has no file system access to what might be
> considered "impurities."  The only file systems from the host that
> make it into the container by default are the current working
> directory and the store paths for all of the needed software.  This is
> especially useful when running Guix on top of another host distro,
> where sometimes things from the host sneak into your build environment
> because a tool decided to inspect the contents of /usr or something.
>
> You can use it like this:
>
>     guix environment --container guix
>
> The above command will create an isolated container with everything
> you need to build Guix from source.
>
> There's more fun to be had, too.  Sometimes it's nice to make ad-hoc
> sandboxes just to play around in.  The below command will run a
> sandboxed Guile REPL:
>
>     guix environment --container --ad-hoc guile -- guile
>
> By default, containers have no network access.  To share the host
> network, use the --network flag.
>
> This is just the beginning!  There's lots more to do.  It would be
> nice to be able to create a network bridge so that the container can
> have network access without sharing the host devices, a la Docker and
> friends.  It would also be great to incorporate cgroups to arbitrarily
> restrict container resources.
>
> Coming soon is 'guix system container', which creates full-blown
> GuixSD containers.
>
> Since I mentioned Docker, I'd like to point some significant
> advantages that Guix containers have over other implementations:
>
> 1) The container tools I'm working on are completely declarative.  No
> imperative Dockerfiles!  This means that you don't have to worry about
> order of operations, something that you have to think about constantly
> when using Docker, especially when trying to maximize the use of the
> image cache.
>
> 2) There are no disk images.  Disk images are opaque blobs that are
> often not reproducible, whereas the items in the Guix store tell you
> the full story of how the software came to be.  Thus, Guix containers
> do not worry at all about the complications involved with layering
> disk images in an overlayfs-style setup.  They are simply not needed.
>
> 3) Software and other files shared amongst many containers are
> deduplicated system-wide.  This is a big deal from my perspective.
> With Docker, container images *must* share as many base image layers
> as possible to take advantage of deduplication, and there's
> limitations to how smart overlay file systems can be to do
> deduplication in memory (citation missing because I can't find the
> article that explained the issues.)  Some people say that Docker is a
> higher-level form of static linking, but instead of static linking the
> executables, you "statically link" an entire, albeit more minimal,
> operating system for each application that you run.  I'm inclined to
> agree, and I'm happy to say that Guix doesn't have this problem.  A
> store item present in N containers exists in exactly one place: in the
> host store.  We take great advantage of bind mounts to share
> everything without duplication.  Once again the fundamental building
> block of every Guix tool, the immutable store, proves to be an
> invaluable asset in overcoming the problems of our imperative
> predecessors and contemporaries.
>
> I hope this excites some of you.  Containers are all the rage right
> now, and they have some seriously good properties if you can look past
> the Docker hype.  I'd love to get some more hands to help make Guix
> containers more featureful and robust in order to compete with the
> mainstream tools.
>
> Until next time, happy hacking!
>
> - Dave

After some PEBKAC David helped me sort out over IRC, I got this running.
Thanks! :-)


Also, for Debian 8 users and maybe others, this might help:

    sudo sysctl -w kernel.unprivileged_userns_clone=1

Credit goes to Efraim.

Taylan

Re: Environment containers

[Thompson, David]

On Mon, Oct 26, 2015 at 10:37 AM, Taylan Ulrich Bayırlı/Kammer
<taylanbayirli@gmail.com> wrote:

> Also, for Debian 8 users and maybe others, this might help:
>
>     sudo sysctl -w kernel.unprivileged_userns_clone=1

Yes, user namespaces are a must-have for this to work.  I will prepare
patches that mention this in the manual and add a test to 'guix
environment' that can detect if user namespaces are unavailable and
display a more helpful error message.

Thanks for bring the UX issues to my attention!

- Dave

Re: Environment containers

[Alex Vong]

On 26/10/2015, Thompson, David <dthompson2@worcester.edu> wrote:
> On Mon, Oct 26, 2015 at 10:37 AM, Taylan Ulrich Bayırlı/Kammer
> <taylanbayirli@gmail.com> wrote:
>
>> Also, for Debian 8 users and maybe others, this might help:
>>
>>     sudo sysctl -w kernel.unprivileged_userns_clone=1
>
> Yes, user namespaces are a must-have for this to work.  I will prepare
> patches that mention this in the manual and add a test to 'guix
> environment' that can detect if user namespaces are unavailable and
> display a more helpful error message.
>
I think the patch could be considered a fix for
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21410> as well. How do
you think?

Thanks!

> Thanks for bring the UX issues to my attention!
>
> - Dave
>
>

Re: Environment containers

[Ludovic Courtès]

Alex Vong <alexvong1995@gmail.com> skribis:

> On 26/10/2015, Thompson, David <dthompson2@worcester.edu> wrote:
>> On Mon, Oct 26, 2015 at 10:37 AM, Taylan Ulrich Bayırlı/Kammer
>> <taylanbayirli@gmail.com> wrote:
>>
>>> Also, for Debian 8 users and maybe others, this might help:
>>>
>>>     sudo sysctl -w kernel.unprivileged_userns_clone=1
>>
>> Yes, user namespaces are a must-have for this to work.  I will prepare
>> patches that mention this in the manual and add a test to 'guix
>> environment' that can detect if user namespaces are unavailable and
>> display a more helpful error message.
>>
> I think the patch could be considered a fix for
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21410> as well. How do
> you think?

Do you still experience the test failures mentioned in that report?  If
not, could you email 21410@debbugs.gnu.org, specifying which commit
works for you?

I suspect 0e3cc31 helped.

Thanks,
Ludo’.

Re: Environment containers

[Alex Vong]

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

Hi everyone,

On 27/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
> Alex Vong <alexvong1995@gmail.com> skribis:
>
>> On 26/10/2015, Thompson, David <dthompson2@worcester.edu> wrote:
>>> On Mon, Oct 26, 2015 at 10:37 AM, Taylan Ulrich Bayırlı/Kammer
>>> <taylanbayirli@gmail.com> wrote:
>>>
>>>> Also, for Debian 8 users and maybe others, this might help:
>>>>
>>>>     sudo sysctl -w kernel.unprivileged_userns_clone=1
>>>
>>> Yes, user namespaces are a must-have for this to work.  I will prepare
>>> patches that mention this in the manual and add a test to 'guix
>>> environment' that can detect if user namespaces are unavailable and
>>> display a more helpful error message.
>>>
>> I think the patch could be considered a fix for
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21410> as well. How do
>> you think?
>
> Do you still experience the test failures mentioned in that report?  If
> not, could you email 21410@debbugs.gnu.org, specifying which commit
> works for you?
>
Yes, there are 4 tests still failing with the latest master branch
without unprivileged container.
But there is a new problem, tests/guix-environment-container.sh fails
even when running the tests as root. The test log is in the
attachment. I am running Debian 8, could anyone verify this? I would
also like to try it on Debian unstable, but currently my PC cannot
boot, I am using my old laptop.

> I suspect 0e3cc31 helped.
>
> Thanks,
> Ludo’.
>

Cheers,
Alex

[-- Attachment #2: guix-environment-container.log --]
[-- Type: text/x-log, Size: 2326 bytes --]

+ set -e
+ guix environment --version
warning: daemon is running as root, so using `--build-users-group' is highly recommended
guix environment (GNU Guix) 0.9.0
Copyright (C) 2015 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
+ tmpdir=t-guix-environment-9613
+ trap 'rm -r "$tmpdir"' EXIT
+ mkdir t-guix-environment-9613
+ guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile -c '(exit 42)'
accepted connection from pid 9621, user root (trusted)
+ test 42 = 42
+ mount_test_code='
(use-modules (ice-9 rdelim)
             (ice-9 match)
             (srfi srfi-1))

(define mappings
  (filter-map (lambda (line)
                (match (string-split line #\space)
                  ;; Empty line.
                  (("") #f)
                  ;; Ignore these types of file systems.
                  ((_ _ (or "tmpfs" "proc" "sysfs" "devtmpfs"
                            "devpts" "cgroup" "mqueue") _ _ _)
                   #f)
                  ((_ mount _ _ _ _)
                   mount)))
              (string-split (call-with-input-file "/proc/mounts" read-string)
                            #\newline)))

(for-each (lambda (mount)
            (display mount)
            (newline))
          mappings)'
+ guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile -c '
(use-modules (ice-9 rdelim)
             (ice-9 match)
             (srfi srfi-1))

(define mappings
  (filter-map (lambda (line)
                (match (string-split line #\space)
                  ;; Empty line.
                  (("") #f)
                  ;; Ignore these types of file systems.
                  ((_ _ (or "tmpfs" "proc" "sysfs" "devtmpfs"
                            "devpts" "cgroup" "mqueue") _ _ _)
                   #f)
                  ((_ mount _ _ _ _)
                   mount)))
              (string-split (call-with-input-file "/proc/mounts" read-string)
                            #\newline)))

(for-each (lambda (mount)
            (display mount)
            (newline))
          mappings)'
accepted connection from pid 9627, user root (trusted)
++ wc -l
+ test 4 -eq 3
+ rm -r t-guix-environment-9613

bug#21410: Environment containers

[Ludovic Courtès]

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

Alex Vong <alexvong1995@gmail.com> skribis:

> On 27/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:

[...]

>> Do you still experience the test failures mentioned in that report?  If
>> not, could you email 21410@debbugs.gnu.org, specifying which commit
>> works for you?
>>
> Yes, there are 4 tests still failing with the latest master branch
> without unprivileged container.

Which tests?  Does tests/container.scm pass?

> But there is a new problem, tests/guix-environment-container.sh fails
> even when running the tests as root. The test log is in the
> attachment.

[...]

> (for-each (lambda (mount)
>             (display mount)
>             (newline))
>           mappings)'
> accepted connection from pid 9627, user root (trusted)
> ++ wc -l
> + test 4 -eq 3

Could you apply the patch below, run:

  make check TESTS=tests/guix-environment-container.sh

and send ‘guix-environment-container.log’?

Also, what does:

  make check TESTS=tests/container.scm

report?

TIA!

Ludo’.


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

--- a/tests/guix-environment-container.sh
+++ b/tests/guix-environment-container.sh
@@ -66,6 +66,7 @@ mount_test_code="
 guix environment --container --ad-hoc --bootstrap guile-bootstrap \
      -- guile -c "$mount_test_code" > $tmpdir/mounts
 
+cat $tmpdir/mounts
 test `wc -l < $tmpdir/mounts` -eq 3
 
 grep -e "$PWD$" $tmpdir/mounts # current directory

bug#21410: Environment containers

[Alex Vong]

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

On 28/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
> Alex Vong <alexvong1995@gmail.com> skribis:
>
>> On 27/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
>
> [...]
>
>>> Do you still experience the test failures mentioned in that report?  If
>>> not, could you email 21410@debbugs.gnu.org, specifying which commit
>>> works for you?
>>>
>> Yes, there are 4 tests still failing with the latest master branch
>> without unprivileged container.
>
> Which tests?  Does tests/container.scm pass?
>
It doesn't pass if I run as unprivileged user. It passes if I run as
root. I will be mailing the test logs on another mail.

>> But there is a new problem, tests/guix-environment-container.sh fails
>> even when running the tests as root. The test log is in the
>> attachment.
>
> [...]
>
>> (for-each (lambda (mount)
>>             (display mount)
>>             (newline))
>>           mappings)'
>> accepted connection from pid 9627, user root (trusted)
>> ++ wc -l
>> + test 4 -eq 3
>
> Could you apply the patch below, run:
>
>   make check TESTS=tests/guix-environment-container.sh
>
> and send ‘guix-environment-container.log’?
>
Sure! It is in the attachment. (Note that I run the test as root to
bypass the unprivileged container issue.)

> Also, what does:
>
>   make check TESTS=tests/container.scm
>
> report?
>
I will send the test log in another mail.

> TIA!
>
> Ludo’.
>
>

Cheers,
Alex

[-- Attachment #2: guix-environment-container.log --]
[-- Type: text/x-log, Size: 2564 bytes --]

+ set -e
+ guix environment --version
warning: daemon is running as root, so using `--build-users-group' is highly recommended
guix environment (GNU Guix) 0.9.0
Copyright (C) 2015 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
+ tmpdir=t-guix-environment-12182
+ trap 'rm -r "$tmpdir"' EXIT
+ mkdir t-guix-environment-12182
+ guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile -c '(exit 42)'
accepted connection from pid 12190, user root (trusted)
+ test 42 = 42
+ mount_test_code='
(use-modules (ice-9 rdelim)
             (ice-9 match)
             (srfi srfi-1))

(define mappings
  (filter-map (lambda (line)
                (match (string-split line #\space)
                  ;; Empty line.
                  (("") #f)
                  ;; Ignore these types of file systems.
                  ((_ _ (or "tmpfs" "proc" "sysfs" "devtmpfs"
                            "devpts" "cgroup" "mqueue") _ _ _)
                   #f)
                  ((_ mount _ _ _ _)
                   mount)))
              (string-split (call-with-input-file "/proc/mounts" read-string)
                            #\newline)))

(for-each (lambda (mount)
            (display mount)
            (newline))
          mappings)'
+ guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile -c '
(use-modules (ice-9 rdelim)
             (ice-9 match)
             (srfi srfi-1))

(define mappings
  (filter-map (lambda (line)
                (match (string-split line #\space)
                  ;; Empty line.
                  (("") #f)
                  ;; Ignore these types of file systems.
                  ((_ _ (or "tmpfs" "proc" "sysfs" "devtmpfs"
                            "devpts" "cgroup" "mqueue") _ _ _)
                   #f)
                  ((_ mount _ _ _ _)
                   mount)))
              (string-split (call-with-input-file "/proc/mounts" read-string)
                            #\newline)))

(for-each (lambda (mount)
            (display mount)
            (newline))
          mappings)'
accepted connection from pid 12196, user root (trusted)
+ cat t-guix-environment-12182/mounts
/
/home/alexvong1995/guix
/home/alexvong1995/guix/test-tmp/store/bdg31cb28ki1b0xi4rqrc721hadn3lfw-bash
/home/alexvong1995/guix/test-tmp/store/92vjphkx545ndw82vn4fp9m3xxkv3mzd-guile-bootstrap-2.0
++ wc -l
+ test 4 -eq 3
+ rm -r t-guix-environment-12182

Re: Environment containers

[Thompson, David]

On Wed, Oct 28, 2015 at 11:14 AM, Alex Vong <alexvong1995@gmail.com> wrote:
> On 28/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
>> Alex Vong <alexvong1995@gmail.com> skribis:
>>
>>> On 27/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
>>
>> [...]
>>
>>>> Do you still experience the test failures mentioned in that report?  If
>>>> not, could you email 21410@debbugs.gnu.org, specifying which commit
>>>> works for you?
>>>>
>>> Yes, there are 4 tests still failing with the latest master branch
>>> without unprivileged container.
>>
>> Which tests?  Does tests/container.scm pass?
>>
> It doesn't pass if I run as unprivileged user. It passes if I run as
> root. I will be mailing the test logs on another mail.

This is because Debian doesn't let unprivileged users create user
namespaces without explicitly overriding some configuration.

- Dave

Re: Environment containers

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Wed, Oct 28, 2015 at 11:14 AM, Alex Vong <alexvong1995@gmail.com> wrote:
>> On 28/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
>>> Alex Vong <alexvong1995@gmail.com> skribis:
>>>
>>>> On 27/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
>>>
>>> [...]
>>>
>>>>> Do you still experience the test failures mentioned in that report?  If
>>>>> not, could you email 21410@debbugs.gnu.org, specifying which commit
>>>>> works for you?
>>>>>
>>>> Yes, there are 4 tests still failing with the latest master branch
>>>> without unprivileged container.
>>>
>>> Which tests?  Does tests/container.scm pass?
>>>
>> It doesn't pass if I run as unprivileged user. It passes if I run as
>> root. I will be mailing the test logs on another mail.
>
> This is because Debian doesn't let unprivileged users create user
> namespaces without explicitly overriding some configuration.

How could we determine whether this restriction is in place?  That would
allow us to skip the test on these systems.

Ludo’.

Re: Environment containers

[Thompson, David]

On Wed, Oct 28, 2015 at 11:56 AM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Wed, Oct 28, 2015 at 11:14 AM, Alex Vong <alexvong1995@gmail.com> wrote:
>>> On 28/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
>>>> Alex Vong <alexvong1995@gmail.com> skribis:
>>>>
>>>>> On 27/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
>>>>
>>>> [...]
>>>>
>>>>>> Do you still experience the test failures mentioned in that report?  If
>>>>>> not, could you email 21410@debbugs.gnu.org, specifying which commit
>>>>>> works for you?
>>>>>>
>>>>> Yes, there are 4 tests still failing with the latest master branch
>>>>> without unprivileged container.
>>>>
>>>> Which tests?  Does tests/container.scm pass?
>>>>
>>> It doesn't pass if I run as unprivileged user. It passes if I run as
>>> root. I will be mailing the test logs on another mail.
>>
>> This is because Debian doesn't let unprivileged users create user
>> namespaces without explicitly overriding some configuration.
>
> How could we determine whether this restriction is in place?  That would
> allow us to skip the test on these systems.

I think it is /proc/sys/kernel/unprivileged_userns_clone, but I don't
know what the contents are exactly.  0 when off, 1 when on?  Can
someone on Debian confirm?

If we can get the test suite passing, I'd like to extract these user
namespace presence tests to a procedure that 'guix environment' can
use to give the user an informative error message in these cases.

- Dave

Re: Environment containers

[Alex Vong]

On 29/10/2015, Thompson, David <dthompson2@worcester.edu> wrote:
> On Wed, Oct 28, 2015 at 11:56 AM, Ludovic Courtès <ludo@gnu.org> wrote:
>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>
>>> On Wed, Oct 28, 2015 at 11:14 AM, Alex Vong <alexvong1995@gmail.com>
>>> wrote:
>>>> On 28/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
>>>>> Alex Vong <alexvong1995@gmail.com> skribis:
>>>>>
>>>>>> On 27/10/2015, Ludovic Courtès <ludo@gnu.org> wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> Do you still experience the test failures mentioned in that report?
>>>>>>> If
>>>>>>> not, could you email 21410@debbugs.gnu.org, specifying which commit
>>>>>>> works for you?
>>>>>>>
>>>>>> Yes, there are 4 tests still failing with the latest master branch
>>>>>> without unprivileged container.
>>>>>
>>>>> Which tests?  Does tests/container.scm pass?
>>>>>
>>>> It doesn't pass if I run as unprivileged user. It passes if I run as
>>>> root. I will be mailing the test logs on another mail.
>>>
>>> This is because Debian doesn't let unprivileged users create user
>>> namespaces without explicitly overriding some configuration.
>>
>> How could we determine whether this restriction is in place?  That would
>> allow us to skip the test on these systems.
>
> I think it is /proc/sys/kernel/unprivileged_userns_clone, but I don't
> know what the contents are exactly.  0 when off, 1 when on?  Can
> someone on Debian confirm?
>
Yes, I think that's the case.
Before I run `$ sysctl -w kernel.unprivileged_userns_clone=1',
`$ cat /proc/sys/kernel/unprivileged_userns_clone' returns 0.
After I run `$ sysctl -w kernel.unprivileged_userns_clone=1',
`$ cat /proc/sys/kernel/unprivileged_userns_clone' returns 1.

> If we can get the test suite passing, I'd like to extract these user
> namespace presence tests to a procedure that 'guix environment' can
> use to give the user an informative error message in these cases.
>
> - Dave
>

Re: Environment containers

[Ludovic Courtès]

"Thompson, David" <dthompson2@worcester.edu> skribis:

> I think it is /proc/sys/kernel/unprivileged_userns_clone, but I don't
> know what the contents are exactly.  0 when off, 1 when on?  Can
> someone on Debian confirm?
>
> If we can get the test suite passing, I'd like to extract these user
> namespace presence tests to a procedure that 'guix environment' can
> use to give the user an informative error message in these cases.

That would be perfect.

The test machinery would still need to test them explicitly, though, to
mark tests as skipped instead of failed.

Ludo’.

Re: Environment containers

[Thompson, David]

On Thu, Oct 29, 2015 at 3:24 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> I think it is /proc/sys/kernel/unprivileged_userns_clone, but I don't
>> know what the contents are exactly.  0 when off, 1 when on?  Can
>> someone on Debian confirm?
>>
>> If we can get the test suite passing, I'd like to extract these user
>> namespace presence tests to a procedure that 'guix environment' can
>> use to give the user an informative error message in these cases.
>
> That would be perfect.
>
> The test machinery would still need to test them explicitly, though, to
> mark tests as skipped instead of failed.

Yes, of course.  I have no intention of removing those checks from the tests.

- Dave

Re: bug#21410: Environment containers

[Ludovic Courtès]

What’s the status of this now?  I would think b7d48312 addressed at
least part of it?

Alex: Are you still getting test failures with current ‘master’?

TIA,
Ludo’.

Re: bug#21410: Environment containers

[Alex Vong]

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

Hi,

On 20/11/2015, Ludovic Courtès <ludo@gnu.org> wrote:
> What’s the status of this now?  I would think b7d48312 addressed at
> least part of it?
>
> Alex: Are you still getting test failures with current ‘master’?
>
> TIA,
> Ludo’.
>

Yes, I still get a test failure with the latest master branch, the
test log is in the attachment.

Cheers,
Alex

[-- Attachment #2: test-suite.log --]
[-- Type: text/x-log, Size: 1342 bytes --]

======================================
   GNU Guix 0.9.0: ./test-suite.log
======================================

# TOTAL: 54
# PASS:  52
# SKIP:  1
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

SKIP: tests/containers
======================

;;; note: source file ./srfi/srfi-64.scm
;;;       newer than compiled /gnu/store/5i87jzm90nw8j692y7z1j2qfx16h6ni3-guile-2.0.11/lib/guile/2.0/ccache/srfi/srfi-64.go
SKIP tests/containers.scm (exit status: 77)

FAIL: tests/guix-environment-container
======================================

+ set -e
+ guix environment --version
guix environment (GNU Guix) 0.9.0
Copyright (C) 2015 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
+ tmpdir=t-guix-environment-29930
+ trap 'rm -r "$tmpdir"' EXIT
+ mkdir t-guix-environment-29930
+ guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile -c '(exit 42)'
guix environment: error: cannot create container: unprivileged user cannot create user namespaces
guix environment: error: please set /proc/sys/kernel/unprivileged_userns_clone to "1"
+ test 1 = 42
+ rm -r t-guix-environment-29930
FAIL tests/guix-environment-container.sh (exit status: 1)

Re: bug#21410: Environment containers

[Ludovic Courtès]

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

Alex Vong <alexvong1995@gmail.com> skribis:

> FAIL: tests/guix-environment-container
> ======================================
>
> + set -e
> + guix environment --version
> guix environment (GNU Guix) 0.9.0
> Copyright (C) 2015 the Guix authors
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> + tmpdir=t-guix-environment-29930
> + trap 'rm -r "$tmpdir"' EXIT
> + mkdir t-guix-environment-29930
> + guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile -c '(exit 42)'
> guix environment: error: cannot create container: unprivileged user cannot create user namespaces
> guix environment: error: please set /proc/sys/kernel/unprivileged_userns_clone to "1"

Oh I see, that part fell through the cracks.

Could you confirm that the test is skipped with the attached patch?

TIA!

Ludo’.


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

--- a/tests/guix-environment-container.sh
+++ b/tests/guix-environment-container.sh
@@ -24,6 +24,12 @@ set -e
 
 guix environment --version
 
+if ! guile -c '((@@ (guix scripts environment) assert-container-features))'
+then
+    # User containers are not supported; skip this test.
+    exit 77
+fi
+
 tmpdir="t-guix-environment-$$"
 trap 'rm -r "$tmpdir"' EXIT
 

Re: bug#21410: Environment containers

[Mathieu Lirzin]

ludo@gnu.org (Ludovic Courtès) writes:

>
>> FAIL: tests/guix-environment-container
>> ======================================
>>
>> + set -e
>> + guix environment --version
>> guix environment (GNU Guix) 0.9.0
>> Copyright (C) 2015 the Guix authors
>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> + tmpdir=t-guix-environment-29930
>> + trap 'rm -r "$tmpdir"' EXIT
>> + mkdir t-guix-environment-29930
>> + guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile -c '(exit 42)'
>> guix environment: error: cannot create container: unprivileged user cannot create user namespaces
>> guix environment: error: please set /proc/sys/kernel/unprivileged_userns_clone to "1"
>
> Oh I see, that part fell through the cracks.
>
> Could you confirm that the test is skipped with the attached patch?

this test was failing on my system too, and it is skipped successfully
with this patch.

--
Mathieu Lirzin

Re: bug#21410: Environment containers

[Ludovic Courtès]

Mathieu Lirzin <mthl@gnu.org> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>>
>>> FAIL: tests/guix-environment-container
>>> ======================================
>>>
>>> + set -e
>>> + guix environment --version
>>> guix environment (GNU Guix) 0.9.0
>>> Copyright (C) 2015 the Guix authors
>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> + tmpdir=t-guix-environment-29930
>>> + trap 'rm -r "$tmpdir"' EXIT
>>> + mkdir t-guix-environment-29930
>>> + guix environment --container --ad-hoc --bootstrap guile-bootstrap -- guile -c '(exit 42)'
>>> guix environment: error: cannot create container: unprivileged user cannot create user namespaces
>>> guix environment: error: please set /proc/sys/kernel/unprivileged_userns_clone to "1"
>>
>> Oh I see, that part fell through the cracks.
>>
>> Could you confirm that the test is skipped with the attached patch?
>
> this test was failing on my system too, and it is skipped successfully
> with this patch.

Thanks, pushed as 6493fd0.

Ludo’.

Re: bug#21410: Environment containers

[Alex Vong]

Sorry for late reply. I can confirm the two tests are now skipped with
the latest master.

Cheers,
Alex

On 22/11/2015, Ludovic Courtès <ludo@gnu.org> wrote:
> Mathieu Lirzin <mthl@gnu.org> skribis:
>
>> ludo@gnu.org (Ludovic Courtès) writes:
>>
>>>
>>>> FAIL: tests/guix-environment-container
>>>> ======================================
>>>>
>>>> + set -e
>>>> + guix environment --version
>>>> guix environment (GNU Guix) 0.9.0
>>>> Copyright (C) 2015 the Guix authors
>>>> License GPLv3+: GNU GPL version 3 or later
>>>> <http://gnu.org/licenses/gpl.html>
>>>> This is free software: you are free to change and redistribute it.
>>>> There is NO WARRANTY, to the extent permitted by law.
>>>> + tmpdir=t-guix-environment-29930
>>>> + trap 'rm -r "$tmpdir"' EXIT
>>>> + mkdir t-guix-environment-29930
>>>> + guix environment --container --ad-hoc --bootstrap guile-bootstrap --
>>>> guile -c '(exit 42)'
>>>> guix environment: error: cannot create container: unprivileged user
>>>> cannot create user namespaces
>>>> guix environment: error: please set
>>>> /proc/sys/kernel/unprivileged_userns_clone to "1"
>>>
>>> Oh I see, that part fell through the cracks.
>>>
>>> Could you confirm that the test is skipped with the attached patch?
>>
>> this test was failing on my system too, and it is skipped successfully
>> with this patch.
>
> Thanks, pushed as 6493fd0.
>
> Ludo’.
>

Re: Environment containers

[Taylan Ulrich Bayırlı/Kammer]

taylanbayirli@gmail.com (Taylan Ulrich "Bayırlı/Kammer") writes:

> After some PEBKAC David helped me sort out over IRC, I got this running.
> Thanks! :-)

I just (partly) figured out the reason of one of the mysterious problems
I was encountering.

taylan@T420:~$ cd ~
taylan@T420:~$ guix environment --container --ad-hoc bash -- bash -c 'echo foo' || echo FAIL
FAIL
taylan@T420:~$ mkdir TEST; cd TEST
taylan@T420:~/TEST$ guix environment --container --ad-hoc bash -- bash -c 'echo foo' || echo FAIL
foo
taylan@T420:~/TEST$

When I use strace -f, I see the following in the failing variant:

mount("/home/taylan", "/tmp/guix-directory.wfzVlc//home/taylan", 0x17db9f0, MS_BIND, NULL) = -1 EINVAL (Invalid argument)

The two directories have the exact same permission bits (0755), UID, and
GID, as per stat(1).

When I create another directory with the same owner and permissions in
/home, it works fine there.

/home/taylan has some mount-points of its own, e.g. ~/media is a
mount-point.  My best guess is that it's related to that.  /home/taylan
itself is not a mount-point, FYI.


I wish C had a proper error reporting system. :-)

Taylan

Re: Environment containers

[Christopher Allan Webber]

David, you are kicking ass on this.  *Thank you* so much for working so
hard to get this in... I know it was a challenging task, but I think
this helps pave the way for even greater things!

Keep on rocking for the free world,
 - Chris

Re: Environment containers

[Thompson, David]

On Mon, Oct 26, 2015 at 12:23 PM, Christopher Allan Webber
<cwebber@dustycloud.org> wrote:
> David, you are kicking ass on this.  *Thank you* so much for working so
> hard to get this in... I know it was a challenging task, but I think
> this helps pave the way for even greater things!

Thanks for your kind words, Chris!  Much appreciated.

- Dave

Re: Environment containers

[Ricardo Wurmus]

Thompson, David <dthompson2@worcester.edu> writes:

> Hello Guix hackers,
>
> I am pleased to announce that the patch for adding Linux container
> support to 'guix environment' has just landed in master!

Yay!  Thank you so much for your work on this!

> 2) There are no disk images.  Disk images are opaque blobs that are
> often not reproducible, whereas the items in the Guix store tell you
> the full story of how the software came to be.  Thus, Guix containers
> do not worry at all about the complications involved with layering
> disk images in an overlayfs-style setup.  They are simply not needed.

Beautiful!

~~ Ricardo

Re: Environment containers

[Efraim Flashner]

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

On Wed, 28 Oct 2015 16:32:54 +0100
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> wrote:

> Thompson, David <dthompson2@worcester.edu> writes:
> 
> > Hello Guix hackers,
> >
> > I am pleased to announce that the patch for adding Linux container
> > support to 'guix environment' has just landed in master!  
> 
> Yay!  Thank you so much for your work on this!
> 
> > 2) There are no disk images.  Disk images are opaque blobs that are
> > often not reproducible, whereas the items in the Guix store tell you
> > the full story of how the software came to be.  Thus, Guix containers
> > do not worry at all about the complications involved with layering
> > disk images in an overlayfs-style setup.  They are simply not needed.  
> 
> Beautiful!

agreed.

efraim@debian-netbook:~$ ls -la /gnu/store/*sh
-r-xr-xr-x 27 root root         1425560 Jan  1  1970 /gnu/store/gvwf71vddp8c1d7ydqg02p43mgdjrx6s-bash
-r--r--r--  2 root root            1153 Jan  1  1970 /gnu/store/jd51fxgzf2bj3v9naliq44vgcib06ay9-build-bootstrap-guile.sh
-r-xr-xr-x 27 root root         1351732 Jan  1  1970 /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash
-r--r--r--  2 root root            1153 Jan  1  1970 /gnu/store/x06d80rn9lxbh3305pkizf4k2dswsbn1-build-bootstrap-guile.sh
-r-xr-xr-x  2 root guix-builder     765 Jan  1  1970 /gnu/store/zrnjijsg19f52ficwlk4n5cccf6smhya-run-vm.sh

765 bytes is the smallest VM I've ever seen :)


-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Environment containers

[Thompson, David]

On Wed, Oct 28, 2015 at 3:09 PM, Efraim Flashner <efraim@flashner.co.il> wrote:

> efraim@debian-netbook:~$ ls -la /gnu/store/*sh
> -r-xr-xr-x 27 root root         1425560 Jan  1  1970 /gnu/store/gvwf71vddp8c1d7ydqg02p43mgdjrx6s-bash
> -r--r--r--  2 root root            1153 Jan  1  1970 /gnu/store/jd51fxgzf2bj3v9naliq44vgcib06ay9-build-bootstrap-guile.sh
> -r-xr-xr-x 27 root root         1351732 Jan  1  1970 /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash
> -r--r--r--  2 root root            1153 Jan  1  1970 /gnu/store/x06d80rn9lxbh3305pkizf4k2dswsbn1-build-bootstrap-guile.sh
> -r-xr-xr-x  2 root guix-builder     765 Jan  1  1970 /gnu/store/zrnjijsg19f52ficwlk4n5cccf6smhya-run-vm.sh
>
> 765 bytes is the smallest VM I've ever seen :)

Do note that this is just a *script* to boot a virtual machine, which
is completely different from the scripts that boot GuixSD containers.
What you're not seeing in that directory listing is the disk image
that was generated for qemu to boot.  Guix environment containers do
not generate scripts like this.

- Dave