re: Drafting a Guix blog post on the FHS container

re: Drafting a Guix blog post on the FHS container

[Jim Newsome]

Sorry for (presumably) breaking threading; I came across this online and 
don't see a way to set my in-reply-to-email header properly.

Anyways just thought I'd mention that I recently learned about this 
feature, and was able to use it to get a downloaded [Tor Browser Bundle] 
running with:


```
guix shell \
   --container \
   --network \
   --emulate-fhs \
   --preserve='^DISPLAY$'
   --share=/run/user/$(id -u)/gdm \
   openssl@1 \
   libevent \
   pciutils \
   dbus-glib \
   bash \
   libgccjit \
   libcxx \
   gtk+ \
   coreutils \
   grep \
   sed \
   file \
   alsa-lib \
   -- \
   ./start-tor-browser.desktop -v
```

`--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to get 
access to the display. I'm not sure the second parameter is universally 
correct; I reverse-engineered it via roughly `ps aux | grep -- -auth`.

The `-v` parameter to the browser script keeps it from trying to 
background itself, which otherwise causes the container and browser to 
terminate.

It'd ultimately be nice to package the Tor Browser Bundle properly for 
guix, but it's nice to be able to use it this way in the meantime.

-Jim

[Tor Browser Bundle]: https://www.torproject.org/download/

Re: Drafting a Guix blog post on the FHS container

[Ludovic Courtès]

Hi Jim,

Jim Newsome <jim@sporksmith.net> skribis:

> Anyways just thought I'd mention that I recently learned about this
> feature, and was able to use it to get a downloaded [Tor Browser
> Bundle] running with:

That’s another good example, thanks for sharing!  It’s especially
interesting because the Tor project vets the binaries they provide.

Ludo’.

Re: Drafting a Guix blog post on the FHS container

[Csepp]

Jim Newsome <jim@sporksmith.net> writes:

> Sorry for (presumably) breaking threading; I came across this online
> and don't see a way to set my in-reply-to-email header properly.
>
> Anyways just thought I'd mention that I recently learned about this
> feature, and was able to use it to get a downloaded [Tor Browser
> Bundle] running with:
>
>
> ```
> guix shell \
>   --container \
>   --network \
>   --emulate-fhs \
>   --preserve='^DISPLAY$'
>   --share=/run/user/$(id -u)/gdm \
>   openssl@1 \
>   libevent \
>   pciutils \
>   dbus-glib \
>   bash \
>   libgccjit \
>   libcxx \
>   gtk+ \
>   coreutils \
>   grep \
>   sed \
>   file \
>   alsa-lib \
>   -- \
>   ./start-tor-browser.desktop -v
> ```
>
> `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to
> get access to the display. I'm not sure the second parameter is
> universally correct; I reverse-engineered it via roughly `ps aux |
> grep -- -auth`.
>
> The `-v` parameter to the browser script keeps it from trying to
> background itself, which otherwise causes the container and browser to
> terminate.
>
> It'd ultimately be nice to package the Tor Browser Bundle properly for
> guix, but it's nice to be able to use it this way in the meantime.
>
> -Jim
>
> [Tor Browser Bundle]: https://www.torproject.org/download/

Any idea how to use this for running appimages?  Or anything that
requires FUSE in general?

Re: Drafting a Guix blog post on the FHS container

[John Kehayias]

Hi all,

On Fri, Dec 23, 2022 at 03:04 AM, Csepp wrote:

> Jim Newsome <jim@sporksmith.net> writes:
>
>> Sorry for (presumably) breaking threading; I came across this online
>> and don't see a way to set my in-reply-to-email header properly.
>>
>> Anyways just thought I'd mention that I recently learned about this
>> feature, and was able to use it to get a downloaded [Tor Browser
>> Bundle] running with:
>>
>>
>> ```
>> guix shell \
>>   --container \
>>   --network \
>>   --emulate-fhs \
>>   --preserve='^DISPLAY$'
>>   --share=/run/user/$(id -u)/gdm \
>>   openssl@1 \
>>   libevent \
>>   pciutils \
>>   dbus-glib \
>>   bash \
>>   libgccjit \
>>   libcxx \
>>   gtk+ \
>>   coreutils \
>>   grep \
>>   sed \
>>   file \
>>   alsa-lib \
>>   -- \
>>   ./start-tor-browser.desktop -v
>> ```
>>
>> `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to
>> get access to the display. I'm not sure the second parameter is
>> universally correct; I reverse-engineered it via roughly `ps aux |
>> grep -- -auth`.
>>

Thanks for the example! That's a slight variation of what I've seen/used for display access, as you can see in my previous examples and the current draft of the blog post: <https://issues.guix.gnu.org/60112>

>> The `-v` parameter to the browser script keeps it from trying to
>> background itself, which otherwise causes the container and browser to
>> terminate.
>>
>> It'd ultimately be nice to package the Tor Browser Bundle properly for
>> guix, but it's nice to be able to use it this way in the meantime.
>>

Yes, that's handy, and some extra isolation via the container too.

>> -Jim
>>
>> [Tor Browser Bundle]: <https://www.torproject.org/download/>
>
> Any idea how to use this for running appimages?  Or anything that
> requires FUSE in general?

Please see my previous emails and the current draft, linked above, for exactly that. In short, use '--appimage-extract-and-run' instead of letting the appimage try to mount itself via FUSE.

For FUSE, one can't run it directly in the container as it is setuid. You can use flatpak-spawn from flatpak-xdg-utils though, to work around that, sort of. To be merged as soon as I have a chance (sadly dealing with an unexpected crisis at home these past weeks so I haven't committed anything yet): <https://issues.guix.gnu.org/59825>

Unfortunately the container that does this, or actually any created before the mounting, will not see the mounted appimage. I think this has something to do with namespaces and how containers are created, but I'm not sure the details. You can see some discussion of this in the IRC logs, but I can provide more summary later if you are interested, roughly <https://logs.guix.gnu.org/guix/2022-12-08.log#211221> and <https://logs.guix.gnu.org/guix/2022-12-09.log#020202> has the discussion.

John

Re: Drafting a Guix blog post on the FHS container

[John Kehayias]

Hi Jim,

On Fri, Dec 16, 2022 at 05:39 PM, Jim Newsome wrote:

> Sorry for (presumably) breaking threading; I came across this online and
> don't see a way to set my in-reply-to-email header properly.
>
> Anyways just thought I'd mention that I recently learned about this
> feature, and was able to use it to get a downloaded [Tor Browser Bundle]
> running with:
>
>
> ```
> guix shell \
>    --container \
>    --network \
>    --emulate-fhs \
>    --preserve='^DISPLAY$'
>    --share=/run/user/$(id -u)/gdm \
>    openssl@1 \
>    libevent \
>    pciutils \
>    dbus-glib \
>    bash \
>    libgccjit \
>    libcxx \
>    gtk+ \
>    coreutils \
>    grep \
>    sed \
>    file \
>    alsa-lib \
>    -- \
>    ./start-tor-browser.desktop -v
> ```
>
> `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to get
> access to the display. I'm not sure the second parameter is universally
> correct; I reverse-engineered it via roughly `ps aux | grep -- -auth`.
>
> The `-v` parameter to the browser script keeps it from trying to
> background itself, which otherwise causes the container and browser to
> terminate.
>
> It'd ultimately be nice to package the Tor Browser Bundle properly for
> guix, but it's nice to be able to use it this way in the meantime.

Thanks again for this! I slightly modified it for the blog post, which you can see in draft form at <https://issues.guix.gnu.org/60112>. I used 'gcc:lib' instead of 'libgccjit' as it is smaller, and changed the needed display options to be like the previous ones I had. Yours didn't work for me since it looks like it relies on sharing something from GDM, which I don't use. But do let me know if my version doesn't work for you.

Also gave you credit for this example; if you prefer not to be mentioned by name/link to the mailing list for any reason, just let me know.

Oh, and we do have some (older) patches for building the Tor Browser from source, but I don't know if they currently work: <https://issues.guix.gnu.org/42380> Your example was great though, something very useful!

John

Re: Drafting a Guix blog post on the FHS container

[Jim Newsome]

On Wed, Jan 4, 2023, at 5:47 PM, John Kehayias wrote:
> Hi Jim,
> 
> On Fri, Dec 16, 2022 at 05:39 PM, Jim Newsome wrote:
> 
> > Sorry for (presumably) breaking threading; I came across this online and
> > don't see a way to set my in-reply-to-email header properly.
> >
> > Anyways just thought I'd mention that I recently learned about this
> > feature, and was able to use it to get a downloaded [Tor Browser Bundle]
> > running with:
> >
> >
> > ```
> > guix shell \
> >    --container \
> >    --network \
> >    --emulate-fhs \
> >    --preserve='^DISPLAY$'
> >    --share=/run/user/$(id -u)/gdm \
> >    openssl@1 \
> >    libevent \
> >    pciutils \
> >    dbus-glib \
> >    bash \
> >    libgccjit \
> >    libcxx \
> >    gtk+ \
> >    coreutils \
> >    grep \
> >    sed \
> >    file \
> >    alsa-lib \
> >    -- \
> >    ./start-tor-browser.desktop -v
> > ```
> >
> > `--preserve='^DISPLAY$'` and `--share=/run/user/$(id -u)/gdm` are to get
> > access to the display. I'm not sure the second parameter is universally
> > correct; I reverse-engineered it via roughly `ps aux | grep -- -auth`.
> >
> > The `-v` parameter to the browser script keeps it from trying to
> > background itself, which otherwise causes the container and browser to
> > terminate.
> >
> > It'd ultimately be nice to package the Tor Browser Bundle properly for
> > guix, but it's nice to be able to use it this way in the meantime.
> 
> Thanks again for this! I slightly modified it for the blog post, which you can see in draft form at <https://issues.guix.gnu.org/60112>. I used 'gcc:lib' instead of 'libgccjit' as it is smaller, and changed the needed display options to be like the previous ones I had. Yours didn't work for me since it looks like it relies on sharing something from GDM, which I don't use. But do let me know if my version doesn't work for you.
> 
> Also gave you credit for this example; if you prefer not to be mentioned by name/link to the mailing list for any reason, just let me know.
> 
> Oh, and we do have some (older) patches for building the Tor Browser from source, but I don't know if they currently work: <https://issues.guix.gnu.org/42380> Your example was great though, something very useful!
> 
> John

Thanks, looks good, and the command in your patch also works for me.

I agree that passing and exposing XAUTHORITY seems better. Experimentally, sharing the directory read-only also works (using `--expose` instead of `--share`) also works, but I'm not familiar enough with this mechanism to be confident that'll work for everyone, or whether making it read-only is worth the fuss.

Btw it turns out that `libevent` and `openssl@1` can be dropped; they're already bundled. All together, here's my current "best" version:

```
guix shell --container --network --emulate-fhs \
    --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY \
    alsa-lib bash coreutils dbus-glib file gcc:lib grep gtk+ \
    libcxx pciutils sed \
    -- ./start-tor-browser.desktop -v
```

Re: Drafting a Guix blog post on the FHS container

[John Kehayias]

Hi Jim,

On Wed, Jan 04, 2023 at 06:07 PM, Jim Newsome wrote:

> Thanks, looks good, and the command in your patch also works for me.
>

Great, thanks for testing!

> I agree that passing and exposing XAUTHORITY seems better. Experimentally, sharing the directory
> read-only also works (using `--expose` instead of `--share`) also works, but I'm not familiar enough with
> this mechanism to be confident that'll work for everyone, or whether making it read-only is worth the
> fuss.
>

Ah, you are right, that seems to be just fine for VSCodium and Tor, in my quick test. I think I'll change that.

> Btw it turns out that `libevent` and `openssl@1` can be dropped; they're already bundled. All together,
> here's my current "best" version:
>
> ```
> guix shell --container --network --emulate-fhs \
>     --preserve='^DISPLAY$' --preserve='^XAUTHORITY$' --expose=$XAUTHORITY \
>     alsa-lib bash coreutils dbus-glib file gcc:lib grep gtk+ \
>     libcxx pciutils sed \
>     -- ./start-tor-browser.desktop -v
> ```

Nice, thanks for that too! I tried eliminating a few random inputs, but they were needed. It is difficult sometimes to get a really minimal set, but this looks good to me.

John

[bug#60112] Drafting a Guix blog post on the FHS container

[jman via Guix-patches via]

Hello and sorry for getting into this comment thread.

I have posted a few days ago a question about preserving env vars
when creating a container with FHS emulation:
https://lists.gnu.org/archive/html/help-guix/2023-01/msg00002.html

I think it's something about me not understanding how it works. By
reading my question, is there anything useful to add to the blog post to
clarify its usage?

If not, simply discard this comment :-)

thanks

[bug#60112] [PATCH] website: Add post about guix shell fhs option.

[Ludovic Courtès]

Hi jman,

jman <srht@city17.xyz> skribis:

> Hello and sorry for getting into this comment thread.
>
> I have posted a few days ago a question about preserving env vars
> when creating a container with FHS emulation:
> https://lists.gnu.org/archive/html/help-guix/2023-01/msg00002.html

The ‘PATH’ environment variable, and only this one, is overridden
unconditionally when using ‘--emulate-fhs’; quoth ‘environment.scm’:

   (when emulate-fhs?
     ;; When running in a container with EMULATE-FHS?, override $PATH
     ;; (optional, but to better match FHS expectations), and generate
     ;; /etc/ld.so.cache.
     (setenv "PATH" "/bin:/usr/bin:/sbin:/usr/sbin")
     (invoke "ldconfig" "-X"))

Other variables are preserved, as in this example:

--8<---------------cut here---------------start------------->8---
$ FOO=bar guix shell -CF -E ^FOO coreutils -- env | grep FOO
FOO=bar
--8<---------------cut here---------------end--------------->8---

HTH!

Ludo’.

[bug#60112] [PATCH] website: Add post about guix shell fhs option.

[John Kehayias via Guix-patches via]

On Thu, Jan 05, 2023 at 10:00 PM, Ludovic Courtès wrote:

> Hi jman,
>
> jman <srht@city17.xyz> skribis:
>
>> Hello and sorry for getting into this comment thread.
>>
>> I have posted a few days ago a question about preserving env vars
>> when creating a container with FHS emulation:
>> <https://lists.gnu.org/archive/html/help-guix/2023-01/msg00002.html>
>
> The ‘PATH’ environment variable, and only this one, is overridden
> unconditionally when using ‘--emulate-fhs’; quoth ‘environment.scm’:
>
>    (when emulate-fhs?
>      ;; When running in a container with EMULATE-FHS?, override $PATH
>      ;; (optional, but to better match FHS expectations), and generate
>      ;; /etc/ld.so.cache.
>      (setenv "PATH" "/bin:/usr/bin:/sbin:/usr/sbin")
>      (invoke "ldconfig" "-X"))
>
> Other variables are preserved, as in this example:
>
> $ FOO=bar guix shell -CF -E ^FOO coreutils -- env | grep FOO
> FOO=bar
>
> HTH!
>
> Ludo’.

Now filed by jman as <https://issues.guix.gnu.org/60566> after discussion on #guix. I think it is a bug (say you want to preserve PATH as you have some scripts in ~/.local/bin for example) and I have a patch to fix. I'll send it to that bug and CC you (Ludo’) as well.

John