Re: Building a Docker image for GitLab-CI

[Simon Josefsson via <help-guix@gnu.org>]

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

Ludovic Courtès <ludo@gnu.org> writes:

>> - guix package -i fails: `guix perform-download: error: refusing to
>>   run with elevated privileges (UID 0)`
>
> Should be fixed by running guix-daemon with
> “--build-users-group=whatever” so that downloads run as one of the build
> users, not as root.

Yes, I discovered that too.

>> - GitLab pipeline job entrypoints: three possible entry-point usages
>>   behave somewhat different depending on how `guix pack` was invoked
>
> This image uses Guix installed on Debian though, no?

No - the resulting image is purely from 'guix pack', no Debian in the
final image at all.

I didn't test now but I think Debian images handle all three entrypoint
values, but the 'guix pack' image doesn't.

>> - Adding `nss-certs` to the `guix pack` command breaks: `(symlink
>>   "NetLock_Arany_=Class_Gold=_F?tan?s?tv?ny.pem" #) Throw to key
>>   encoding-error' with args ("scm_to_stringn" "cannot convert wide
>>   string to output locale" 84 #f #f)'.`
>
> You need to run guix-daemon in a UTF-8 locale like “C.UTF-8” (which is
> supported out-of-the-box).
>
> See also <https://issues.guix.gnu.org/75007>.

Thanks - I finally figured this one out in the same way.

>> Finally, you may wonder why things didn't work before.  Some of the
>> major reasons: 1) --max-layer=100 and 2) -S /etc=etc and 3) Missing
>> /etc/protocols etc.  GitLab's docker setup doesn't handle many layers,
>> and it happens to just mount a sub-set of layers (see mount output,
>> missing a lot of layers).  Which files are put at which layer seems to
>> vary between `guix pack` runs for some reason, making it really hard to
>> debug (sometimes things worked partially, sometimes not, depending on
>> which files ended up visible).  I use --max-layers=8 now.
>
> Interesting.  Did you find points in the code (Docker? GitLab?) about
> this subset of layers being mounted?

No, I didn't go down chasing the root cause.  I wonder if maybe it isn't
as simple as some Linux kernel restriction on mount point sizes?  If you
try to load a --max-layer=100 image on GitLab you end up with a
/proc/mounts containing lines like this:

rw,relatime,lowerdir=l/ZPVAK6UICUAWUUE4GUD6AYFCEM:l/HI6HL2SJWTZDQHPTA3SGR4PWNE:l/OAJJQ5NKJAJLIAOEWBNLI6WRNC:l/MRDSZ2V6PLTEQGMEDSOPX6FKEY:l/FG4SISAU6TZNHB6CQR5X5GNEJB:l/EZGDP6A5CMVPA5O6IKOOKPDMBE:l/DA5NZCY6NVIGU2X6U5XQQXV54M:l/P4MIVQ3I7VCYFTQ3AG6RCXZVW5:l/FGPCINKKCYRDHZI5BAAU7HEETW:l/MUYJFZRJLR4Z3BNBFRBRTGP4S5:l/UPGZHVDAILBRLLEH6T5RKWIFG7:l/YNTBNOTPU7QRK5K6RD63VSXG5Q:l/XUPHFGGN36OPHNU334M3V7HDXP:l/PVA2QRQE4D5MAKI6BMGVPETNZN:l/VTGADKUDL4KA4HPA2YCCQ2JQNI:l/WZHWY243PTUZTQIZJM26PVSYG4:l/7YLLGUSIRSUFPXIFI57F2UQSFQ:l/ZEOCYJR44JGRBRKGEM4AMWUHQE:l/YXFWBRXLFSBMYDDCTNODGJWWUV:l/NQK5YT5BWDWSTKFRB3KOGVGYLC:l/6CC2D5S3LSZOOKLULC2JJ5BUHG:l/OMQ7M7FSULZ2WHTQPIOIYP7HYQ:l/VRGMNYJNRPOBPP5IZCJR3YV7FP:l/5L2O6RAVRTGGTB7I2YKS6RMX64:l/57QINIJWW7ECMX3DKLCDL5UMUS:l/HTIS4VRXRVO24AWC6AYPQ4LPRG:l/DOTULUURRI6Z4XR2B4LPQTP33T:l/LZYLE6JUKQFJBIAEMBQMQIWZEE:l/2WEGBKQG6D3VAWLXJ5NCZPFGNP:l/QYVPGN6K2A3Y4VVVPKYLR5JVL7:l/IPS4YGXCRZ47O4AOKMZ4TYD2N3:l/2MZU46ZBHYS5IQI4NAVFD3PNYR:l/HW6B6GDN33YB7GBY3LEOW2XXB4:l/FRINUFWGYICMVPLOJULIHQ3XKV:l/HSHVRY3DQIT5LUS3EONQQCKNL3:l/CRUDGYNQRSSDKB4TYALBBVFIL3:l/QJRZZB6NOMXWO46YCAJ4U53VSH:l/BZPO5MYEYX3YFX5NXYR32E6VRM:l/FDWSYXJR7RNKG42AMXGSC6NUQE:l/Z6BTLASGE6ZXGQZUFIHG4QXQLU:l/DWTG7Y6N4DNP5AZLI6MIDZEBHQ:l/TY4DSPRKETTLFE5WB7KFBO2VSM:l/SAE7PNZP6FFK2NVDOQQTZMO2BV:l/ZCL7CRORSVNYVFKNW2WT7TMGFZ:l/KVH3MQTKJ6SH46B2FEHW7UCYGK:l/XMDKZU7KD755BFINQOBKPLKMZQ:l/MFKZPIVLWDKG5PIVI3UQUU3ILT:l/I24GPDX2SRV3Y4YSJDYVKEBDQE:l/W6OZHVZW2NCSQOJEGMP45P2D6W:l/ZD4RI6B4WQ65QO7EMDQZSCZFHS:l/ZS7D35LTVLE6NSGCCY4SQQANE5:l/2ZIJ6PAUHDPBOXR72A6HGU6L4B:l/ZL5XOQ6XMF6ZYQSXVAK7744SX7:l/A3WXIZD22NL62JYHBZVL5K36IK:l/KUDHAVWVBDXKHHQQVF33KDPHF4:l/6O5OF37ORZTEUV2JXNOPO3WNTQ:l/YVGTC6PVMDS2GVOF57TJWCN5DM:l/VYM3JKFOWAY7UIYGU6TPJTZVD5:l/2BT7MWUS2JMZMQXQ3MRLO5AH6I:l/CNZTAOCVMGIFCNP4IF77OQ5MU6:l/KQCUQ7H6EY7U423TWBX6N6QNU7:l/VNZNN2P4U26XHEDRSNIQ656GRE:l/7YG6BVIVDJYCCGLISSU4APAR4S:l/ELR3M2R3NLUI4U2YCKYKG6MWUV:l/PK34AGBR7JY4PUJIVEAO4J7UAK:l/ELIDWT3IMYDRR5L5VTA3REN3LH:l/DK7VEQCTNIWW4BOYCOVXZX2GQY:l/6BCYXFR5B6S3EYCMVCXKQPEP3M:l/GAF6PUKMPKABSXDZCMVE3NM2K5:l/ASVMZMXSKHAVGH5UFXXRFE7TUX:l/25QORLMIGZEEIBQGTV6UBNZEAH:l/FH5SA2MBXXRRAMDYI72FPK7RXU:l/77IRT3TXX3H7XH66YGR7O5AIYK:l/FIQQSP7XQLUH3IWBXF4DZXWTFN:l/NG6ZAASCTOH6SQVUBR2FR6YE4T:l/QAHEWNHBILTWWWJ4QMX4ISWIT4:l/VCSGZSH4SQRVHK4EWSLGFECG2S:l/7FAMLBB6DJW7VWYEOIN6FLBI2E:l/C4ZXSOLVY36PYMTRL2E2YIKTKY:l/NVH5IIZJ5SO422GGMFGNTFCAOA:l/E6EE3L3EB2B36E5A5PL5KF32FL:l/RPXH632CD3Y54UYAMMULLEZOE4:l/662KE3GHNLWZEUTFCRZXOKVA3P:l/3ZDSIX7ZFSLT2FIEYD6TB6GA7R:l/ZS7SJOXF7XF6OFTLVHYMRYZANK:l/F3CEOKDDPOK72QLUWGKHDIJTPG:l/65CFVU5ZFM4XVSTLDO2WGQE3GU:l/3C2OJ5ZVICH5QP733HTS2DHPJM:l/B37PUETDZKC3MUZZX6CT3M6ZEC:l/LTVIXAHIS7O45NFIVNPDVGYMR4:l/GGBS4BWCAD6UMV3755MJ3BQRI5:l/4XGXVIO5QQ2ARZTTG74M4UDK4V:l/X673P4Q5TGPWBLQIXOQ5JXKG2C:l/3K2Q6NGZ5EEIKCFBRMEWWZFWQK:l/ALTG2QI6YZVKXIP4UCRDMQWS5Q:l/P4AE6X6G5GK66GHHRBZ27BTBF3:l/2UEJWLKTB2GNGT2G6UWFZVDFRN:l/OCTYS4BHPFX4HC3OXJJVGABEPX:l/M766VP6Y5QL2OGI6EYO5OEB6H4:l/DNITYWJFFEVGWQPFQ37S57EIB5:l/PQE5T2ER2OKPNC2YNHZEJXVIY6,upperdir=98dac307f50ae5da4c8f2cc5fdf024465f63600e30fc3bb434fca31191e2efdc/diff,workdir=98dac307f50ae5da4c8f2cc5fdf024465f63600e30fc3bb434fca31191e2efdc/work

That doesn't contain all of the 100 layers (although I didn't double
count..).  Something is truncating those lines.

That would explain why it works for me locally with 'podman': it seems
podman uses much shorter names, like:

rw,relatime,lowerdir=0:1:2:3:4..

instead of those longer strings above.

>> Re /etc=etc it seems GitLab's docker setup bind-mounts things below
>> /etc/ and it cannot handle the root /etc symlink.  A workaround is to
>> use `lndir` which I use in the `test-amd64-package-install` job.  This
>> is limitation of GitLab's docker setup: I tried running a `-S
>> /etc=etc` image on my own GitLab runner based on Trisquel [1] and it
>> worked fine, it mounted things below the symlinked tree properly.
>> Could `guix pack` be teached how to do a lndir-approach for /etc
>> instead of symlink, perhaps?
>
> It could symlink individual files and make /etc a directory.

Is this possible now?  How?

The --symlink is defined like this now:

‘-S SPEC’
     Add the symlinks specified by SPEC to the pack.  This option can
     appear several times.
     SPEC has the form ‘SOURCE=TARGET’, where SOURCE is the symlink that
     will be created and TARGET is the symlink target.
     For instance, ‘-S /opt/gnu/bin=bin’ creates a ‘/opt/gnu/bin’
     symlink pointing to the ‘bin’ sub-directory of the profile.

Could we extend that somehow to support the model of recursively
creating directories, but symlink files within them?

Or a new --symlink-mkdir parameter or similar?

> (What’s ‘lndir’, if I may ask?)

Exactly that :)

One of those ancient tools that still is surprisingly useful:

https://manpages.debian.org/bookworm/xutils-dev/lndir.1.en.html
https://gitlab.freedesktop.org/xorg/util/lndir/-/blob/master/lndir.c

/Simon

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]