unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* shepherd service works on host but fails inside system container
@ 2023-03-22 10:20 Vladilen Kozin
  2023-03-22 12:14 ` Vladilen Kozin
  2023-03-27  8:39 ` Attila Lendvai
  0 siblings, 2 replies; 4+ messages in thread
From: Vladilen Kozin @ 2023-03-22 10:20 UTC (permalink / raw)
  To: guix-devel

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

Hello guix.

I put together a tailscale system service that's meant to start a tailscale
daemon managed by the system shepherd, that is to say that my
`tailscaled-service-type` specifies `(service-extension
shepherd-root-service-type tailscaled-shepherd-service)`, where
`tailscaled-shepherd-service` creates a `shepherd-service` with (provision
'(tailscaled)) and (requirement '(networking)).

I tested it by lowering to store via `shepherd-service-file` and then
loading the generated script via `sudo herd load root ...`. This works fine
and the daemon starts without a problem.

Next, I try to spawn tailscaled as part of my OS definition:
(services (cons* (service tailscaled-service-type
(tailscaled-configuration)) %base-services))
;; tried %desktop-services too

To test, we create a container:
sudo guix system -K -L /home/vlad/Code/fullmeta-guix/channel container
os.scm --network --expose=/dev/net=/dev

Earlier runs had it complaining that /dev/net/tun was missing, so I exposed
that. Dunno if that's how I'm supposed to handle this. Now,
/var/log/messages show:

Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48 Linux
kernel version: 5.18.10
Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48 is
CONFIG_TUN enabled in your kernel? `modprobe tun` failed with:
Mar 22 09:38:48 twgter shepherd[1]: [tailscaled] 2023/03/22 09:38:48
wgengine.NewUserspaceEngine(tun "tailscale0") error:
tstun.New("tailscale0"): operation not permitted

I feel like maybe I'm missing some kernel modules, but I would've expected
host and container to share the kernel, so I dunno. In fact, when I
randomly attempted adding (kernel-arguments (cons* "CONFIG_TUN=m"
%default-kernel-arguments)) to my os definition, resulting script hash came
out the same, which tells me, containers don't even look at these kernel
params when generating a script.

Any guesses as to why this works under host but not inside container?

Relatedly, does anyone have a nicer workflow they use to define and test
shepherd services? Such containerization was the next step in testing the
service and would've been ok were it not for the above failure, but the
initial indirection with lowering to store, then `sudo herd load root ...`
is a bit too involved and "indirect" for my liking as well - anyone has an
improved way of developing shepherd services?

Thanks!
-- 
Best regards
Vlad Kozin

[-- Attachment #2: Type: text/html, Size: 4504 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-03-27  8:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-03-22 10:20 shepherd service works on host but fails inside system container Vladilen Kozin
2023-03-22 12:14 ` Vladilen Kozin
2023-03-22 13:11   ` Vladilen Kozin
2023-03-27  8:39 ` Attila Lendvai

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).