IRC channel logs
2023-02-14.log
back to list of logs
<PurpleSym>rekado: I think it was one of Roel's packages we adopted when he left his institution. But I'm not in touch with any of them, so no idea whether it's still used. <zimoun>about SELinux and CentOS, an user is reporting that guix-daemon is not starting correctly. <rekado>does the audit log say anything useful? <rekado>did they install the cil policy file? <rekado>that’s from 2021, but the policy was changed in 2022 already <zimoun>Well, they say: Active: failed (Result: exit-code) since Mon 2023-02-13 12:59:05 CET; 1min 44s ago <zimoun>Process: 2582028 ExecStart=/var/guix/profiles/per-user/root/current-guix/bin/guix-daemon --build-users-group=guixbuild --discover=yes (code=exited, status=203/EXEC) <zimoun>Main PID: 2582028 (code=exited, status=203/EXEC) <zimoun>févr. 13 12:59:05 pc-p-jola-crpp-cnrs-fr systemd[1]: guix-daemon.service: Failed with result 'exit-code' <rekado>the audit log should tell us what capabilities were denied <rekado>it’s also good to confirm which cil file has been installed and whether files have been fully relabeled with restorecon <zimoun>thanks for the help. I know almost nothing about SELinux. <rekado>resources (files and processes and ports) have types, and to perform any operation on any resource there needs to be a rule that allows one type to be transitioned to another <rekado>it says what type certain files have, declares what operations are permitted on them, and states how types can transition <rekado>a file with a certain label could, for example, result in a process with a certain type label, and there is a rule to make a process with that label access a file with some other label <rekado>the file labels are applied according to the (filecon …) statements in the cil file <rekado>permissions from files/resources of one type onto files/resources of another type are specified with (allow …) statements <rekado>and then there are typetransition statements to allow processes to change their types through a series of conversions <rekado>e.g. the init system runs as init_t and launches a file with type guix_daemon_exec_t, and the resulting process should have type guix_daemon_t <rekado>guix_daemon_t then has permissions to do things to certain other files, etc <rekado>(e.g. it can talk to nscd, read the passwd file, open sockets, etc) <rekado>our policy file is rather primitive; few types, little differentiation <rekado>a proper policy would probably add more process domains, e.g. a separate type for build processes and their permissions <zimoun>Thanks for the explanations. I see, I guess. <rekado>we don’t bother with any of that and are content with just a single type for the daemon <rekado>better than just disabling SELinux, but far from nuanced <zimoun>Hum, ok. Are we distributing a CIl file with this type for the guix-daemon? <rekado>but “guix pull” won’t install it. <zimoun>hum, no answer back. I will keep you touch if I have more info. Thanks for the explanations, BTW. <rekado>it’s a bit unfortunate that the “guix” package uses guile-3.0-latest while all the other Guile packages don’t. <rekado>I don’t want to be hit by differences in Guile .go files when using Guix as a library <rekado>so I’m using package transformations to get my guile-3.0-latest variants of all packages. <zimoun>yes it helps! Now I have a better idea where to look. :-) <rekado>I’d like to deploy a package to S3 and I’m not sure how best to accomplish this <rekado>my first attempt was to use “guix pack”, unpack it, and then sync it over to an S3 bucket. <rekado>I wonder if I could do without the unpack step <rekado>the pack is big enough that I don’t want to upload the whole thing every time <rekado>perhaps a custom file or store item handler in “guix pack” would fit the bill here <rekado>yes, I’m building a relocatable pack <rekado>currently, I build it (which copies files to a tar.gz), unpack it, then sync the files to S3, then delete. <rekado>I’d like to skip the unnecessary pack and unpack