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: [tailscaled] 2023/03/22 09:38:48 Linux kernel version: 5.18.10
Mar 22 09:38:48 twgter shepherd: [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: [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?