From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id MPjgGRxy2GIwHQEAbAwnHQ (envelope-from ) for ; Wed, 20 Jul 2022 23:22:36 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id mGnuGRxy2GKDRgAA9RJhRA (envelope-from ) for ; Wed, 20 Jul 2022 23:22:36 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 0B76B18E40 for ; Wed, 20 Jul 2022 23:22:36 +0200 (CEST) Received: from localhost ([::1]:33342 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oEH9O-0002gC-RV for larch@yhetil.org; Wed, 20 Jul 2022 17:22:34 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58272) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEH9A-0002en-89 for guix-devel@gnu.org; Wed, 20 Jul 2022 17:22:20 -0400 Received: from mail-40133.protonmail.ch ([185.70.40.133]:53295) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oEH97-0007US-Ro for guix-devel@gnu.org; Wed, 20 Jul 2022 17:22:19 -0400 Date: Wed, 20 Jul 2022 21:22:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1658352133; x=1658611333; bh=uCwzGkxeUz/87nXH97L8/tszi06QHVO0BaihMGu6/94=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=v/EZO3oRsnyc5V10lXq21wrYSdsG+rxVUjMq1LtsPqcDO6pIyyYM+FHDVojqrigEx tUJLbxGNDiwtEv3TZjxY+OBh7X7grIFSduPbxtxKIBEjnuFNb3c89ekpTLHMX9poY6 +v8Xf1UJKH4UMUidfjr4Zp4R8ZRSd9CElVugwFx+Ijoe5mf5CwXaCvtnhrQkUyPMMB b3xl3t3B92u+8sBVl663CpoNuW+wzUUABc04TtdaptVwmWa+RhtyKALMQLKpUCAR9S wOWx7YWGTHxKb7f0kYmds0FAOVz+eKVVXtY1NvTQLYBauw8wvQIF324cx1BNKWW7X6 JZu1BAFydSQxA== To: =?utf-8?Q?Ludovic_Court=C3=A8s?= From: John Kehayias Cc: "guix-devel@gnu.org" Subject: Re: [WIP Patch] Adding an FHS container to guix shell Message-ID: In-Reply-To: <875yju1wev.fsf@gnu.org> References: <875yju1wev.fsf@gnu.org> Feedback-ID: 7805494:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.133; envelope-from=john.kehayias@protonmail.com; helo=mail-40133.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: John Kehayias Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN X-Migadu-To: larch@yhetil.org X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1658352156; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=uCwzGkxeUz/87nXH97L8/tszi06QHVO0BaihMGu6/94=; b=awt6wL67iXswBqx7nufjeFZcSANQHHh9oFv1dovuesjCFf5hUm+wZnWaCKThoUGdwkaEHL RMYHwm/L/Mp3UC6HeY0knzurFONuPskVgzOskKvxd7pIv+O5J/XHJ/TUWnFY6fxB8Piu5V wQiKERQ74Zcm+a+TZFFD7/mxSp49/E/IovDIa9ehrSy/3UnokdHalBaIDTUpvcZiuFQwUx isKz+Wto+N7ILFXgyr5WgAHYZ8ulfgCYEkuWI66CZTk8stixZaLe1vyemGogCwWCzkOwt3 cxyJBmT3f73bVuENSjvsrgm7xCOfrNYregEvy6VSobABJfgxz7rfMx27rey9Rg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1658352156; a=rsa-sha256; cv=none; b=kasV5UWwL2izxO2Yw1nIo8FlZHOwtFh1RQg/lUIr+x1uQqYkg2KYYOBlvpMG9LhVNUVIAa xKXeMe5RI6jUkfTua+z26ILsLlFxWtFwIOhjxsFHa5LyHVoz861dkd1zCoz9ImJZ8xc1sC tTH+vXv8LG64HNAJGd9st0WLFnTntorT1tYjEfZalCoDBop6JI5mJLoJhtV0y1MQIPRoN+ F387+A9MAHFtUNEidTDAjHQ2ttzz9cDZ+Jl4dbhHxNcgbTKT9d1AunDw2mZVv9ZIKBEt+p OanMsfWXp/Tk0qcxZzsprdw1ipVyBRUfrN/n8F2nlEe+PaBOeiLOHRMvmQie2w== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b="v/EZO3oR"; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -5.93 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b="v/EZO3oR"; dmarc=pass (policy=quarantine) header.from=protonmail.com; spf=pass (aspmx1.migadu.com: domain of "guix-devel-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="guix-devel-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 0B76B18E40 X-Spam-Score: -5.93 X-Migadu-Scanner: scn0.migadu.com X-TUID: NAYLrXawHyEp Hi Ludo=E2=80=99, ------- Original Message ------- On Monday, July 18th, 2022 at 7:40 AM, Ludovic Court=C3=A8s wrote: > Hello! > > John Kehayias skribis: > > > 2. Typically binaries will expect the ld loader to use > > /etc/ld.so.cache for finding libraries. > > Not necessarily. /etc/ld.so.cache is an optimization, but it=E2=80=99s en= tirely > possible to opt out: if that file is missing, things will work fine, but > libc will =E2=80=98stat=E2=80=99 more to find files. That would make glib= c-for-fhs > unnecessary. > I was thinking mostly of binaries, though I've also encountered code that w= anted to read the ldcache (e.g. parsing ldconfig -p directly), for some rea= son. Is there any difficulty with having already some /etc/ld.so.cache from= some package in the container profile? Perhaps that leads some programs to= rely on the cache and then not continue searching for libraries? I'm not s= ure how that works, but only know that I've found the ldcache necessary (at= least without modifying source) for things I would need the FHS container = for. My overall goal with this FHS option is to mimic both the standard and the = typical expectations of distros that follow it (global ld cache, certain di= rectories in PATH, etc). In my testing I didn't get very far without the mo= dified glibc, though perhaps there are other ways around it. (There's patch= elf, though hard to scale that I think.) For example, lots of language build sytems/package managers will bring in s= ome binaries, whether it is just to install (rustup does this) or because s= omething like a web automation framework downloads browser binaries to use.= My goal here was to make this all "just work," but I can understand wantin= g to keep it minimal. I'll proceed with the glibc-for-fhs and ldcache for now, but open to discus= sing and hearing what everyone thinks. Overall, I find it necessary to enab= le the use-cases I'm thinking of. > > + ;; Set up an FHS container. > > + (when fhs-container? > > + ;; Set up the expected bin and library directories as symlinks to > > + ;; the profile lib directory. Note that this is assuming a 64bit > > + ;; architecture. > > + (let ((lib-dir (string-append profile "/lib"))) > > + (symlink lib-dir "/lib64") > > + (symlink lib-dir "/lib") > > + (mkdir-p "/usr") > > + (symlink lib-dir "/usr/lib")) > > Instead of adding code here, maybe you could do in a more declarative > fashion, like: > > (define fhs-mappings > (list (file-system-mapping > (source (string-append profile "/bin")) (target "/bin")) > =E2=80=A6)) > > and append that to the =E2=80=98mappings=E2=80=99 variable there. It= =E2=80=99s not necessarily > more compact, but maybe marginally easier to read? > Thanks, that's all a good idea for tidying up! I did so, further breaking d= own the FHS directories to ones we can map directly like this, others that = need directory contents symlinked (because the container already has e.g. /= bin not empty), and then creating the optional FHS directories to link to t= hese. For example, /lib is mapped to profile/lib and /usr/lib is linked to = /lib. Again, not strictly necessary, but I was trying to follow the structu= re of other distros here. And this way there is still "one" place where eve= rything from the profile ends up, /lib, /bin, etc. > > + ;; Define an entry script to start the container: generate > > + ;; ld.so.cache, supplement $PATH, and include command. > > I=E2=80=99d leave ld.so.cache generation out. > As discussed above, I'm finding this rather necessary and makes for a smoot= h FHS-container experience. I'm open to other options, maybe making this an= additional option or hiding it away, though I think the design here fits t= he "pretend to be like another distro and just work" that I was going for. > > + (call-with-output-file "/tmp/fhs.sh" > > + (lambda (port) > > + (display "ldconfig -X -f /tmp/ld.so.conf" port) > > + (newline port) > > + (display "export PATH=3D/bin:/usr/bin:/sbin:/usr/sbin:$PATH" port) > > I think the default value of PATH in our libc is the FHS one: > > --8<---------------cut here---------------start------------->8--- > > $ env -i $(type -P strace) -e execve -f $(type -P guile) -c '(system* "wh= atever")' > execve("/gnu/store/lpcjxka7hx3ypv4nz47g08k4m2syqwlj-profile/bin/guile", [= "/gnu/store/lpcjxka7hx3ypv4nz47g0"..., "-c", "(system* \"whatever\")"], 0x7= ffede27ad38 /* 0 vars /) =3D 0 > /home/ludo/.guix-home/profile/bin/strace: Process 9727 attached > /home/ludo/.guix-home/profile/bin/strace: Process 9728 attached > /home/ludo/.guix-home/profile/bin/strace: Process 9729 attached > /home/ludo/.guix-home/profile/bin/strace: Process 9730 attached > /home/ludo/.guix-home/profile/bin/strace: Process 9731 attached > /home/ludo/.guix-home/profile/bin/strace: Process 9732 attached > [pid 9732] execve("/bin/whatever", ["whatever"], 0x7ffed6d967c8 / 0 vars = /) =3D -1 ENOENT (No such file or directory) > [pid 9732] execve("/usr/bin/whatever", ["whatever"], 0x7ffed6d967c8 / 0 v= ars */) =3D -1 ENOENT (No such file or directory) > In execvp of whatever: No such file or directory > --8<---------------cut here---------------end--------------->8--- > > > So you could leave it undefined, but =E2=80=98load-profile=E2=80=99 in > =E2=80=98launch-environment=E2=80=99 will define it. > I'm not sure what you were showing here/I'm a bit confused. If I do just 'g= uix shell -C' for example, I can't just do 'sh' or 'exec sh' in this enviro= nment although /bin/sh exists (as a link to /gnu/store/...bash-.../bin/sh).= While your example does indeed find sh (if I include the needed inputs to = run the example), I'm not sure how that relates to running things directly.= But maybe you just mean in terms of libc directly. Sorry, I don't know qui= te enough in this area. In the container PATH only has profile/bin. Additionally, we frequently see= hardcoded path assumptions like /bin or /usr/bin, or expectations of PATH = being set with these. Adding, e.g. coreutils and which to the shell, which = will happily find 'ls' but not 'sh', as which just searches PATH of course. This could be worked around by the user, but again, I was going for "just w= orks" as much as possible. Or at least as other distros "just work". (Side = note: not that I think this is better! All this FHS stuff gives me even bet= ter appreciation for the design of Guix, despite the initial complications = one sees as a new user.) > Instead of the wrapper script, maybe you could extend > =E2=80=98launch-environment=E2=80=99 so the caller can make it override c= ertain > variables? I would find it a bit clearer. > Would this still be better if we do keep the ldcache being generated? I did= n't see a quick way to just add in some setup commands to the container, th= ough that could be a nice extension. Admittedly, my script here was the sim= plest hack I saw that worked, so I'm not married to it by any means. Again,= the user could also generate the ldcache, but was trying to make it all au= tomatic. > Thanks, > Ludo=E2=80=99. Thanks for the constructive comments! It definitely helped me clean up the = implementation, which I'll be sending shortly to the patches list. I'll fol= lowup on this thread as well to point people to a patch they can try. For my testing I've been able to do work with web automations (uses binarie= s of browsers), tested that AppImages can work, built a Rust project, etc. = A useful tool, even if it is one I hope I don't have to reach for too often= . John