help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Drafting a Guix blog post on the FHS container


From: John Kehayias
Subject: Re: Drafting a Guix blog post on the FHS container
Date: Mon, 26 Dec 2022 05:36:26 +0000

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]