prevent guix pull from trying to process example
Add generic support for lower-able objects, with example.
Remove tests that broke `guix pull`
The unit tests are running for guix pull, for some reason. And they
fail because they are not in the load path. I don't know how to include
the tests without breaking guix pull, so I'm removing them until I
find out.
Add module and syntax for declaring mount namespaces
This commit adds the (aqwari namespace) module, which provides the
following syntax:
(namespace
(bind "/" (list nss-certs tzdata util-linux iproute))
(bind "/etc/hosts" #~(plain-file "hosts" "127.0.0.1 localhost\n"))
(bind "/var")
(bind "/etc/resolv.conf"))
It allows you to compose a new mount namespace as a series of bindings
to directories in the root namespace, or resources in the GNU store,
which will get built on-demand. The same directory can be bound to
multiple resources, which will result in the creation of a union mount
using overlayfs.
The namespace is a run-time concept, so this expression actually builds a
directory tree and an `exec` binary which creates an anonymous instance
of the described namespace, occupied by a single process; itself. It
can then execv(2) into a program provided on its commandline.
The `exec` binary is statically compiled and has no dependencies other
than the linux kernel. It can be run multiple times, and will create
a new namespace each time. Once the process exits, the namespace will
be destroyed.
My initial intent is to use this to create a root file system from which
I can run an s6 supervision tree that will run various network servers
on my PC and on my remote servers. I can build it with Guix and ship a
`guix pack` tarball to machines that don't have Guix.
A secondary goal is to explore mount namespaces as an alternative to
guix profiles. There are some very real usability obstacles to that,
first and foremost the problem that the creation of mount namespaces
requires elevated privileges on most Linux distributions.
small updates, remove example
Fix build errors, some refactoring.
We can now define s6-service directories and supervision trees. The
high-level expression
(s6-service
(name foo)
(log (... execline expression ...))
(run (... execline expression ...))
(env (("key1" "val1") ("key2" "val2")))
(notification-fd 5)
(data (("file1" "content1") ("file2" "content2")))
(finish (... execline expression ...)))
is lowered to the directory
+ /gnu/store/...-s6-service-foo
- run # execlineb script from "run" field
- finish # execlineb script from "finish" field
- notification-fd # 5
+ log
- run # execlineb script from "log" field
+ data
- file1 # content1
- file2 # content2
+ env
- key1 # val1
- key2 # val2
And the function
(s6-svscan "name" svc1 svc2 ...)
produces the computed file
+ /gnu/store/...-s6-svscan-name
- svc1 -> /gnu/store/...-s6-service-svc1
- svc2 -> /gnu/store/...-s6-service-svc2
What remains to be done:
Test how G-expressions can be provided in the high-level expressions.
For example:
(s6-service
(name "bird")
(run (execline (#$bird/bin/bird -c "data/bird.conf" -f))))
Would replace #$bird in the runs script with /gnu/store/...-bird and
automatically add the `bird` package as a dependency for the service.
Currently run scripts are quoted S-expressions that are converted to a
string during compilation, and the `execline` macro doesn't exist.
Define a helper function for creating a full-fledged profile that is suitable
as a supervision tree:
$out/service - the s6-svscan supervision tree
$out/etc/profile - define PATH for s6 utilities, coreutils, and so on
Determine what would be needed to make this profile friendly to
chroot/pivot-root. The use of absolute symlinks prevents it, currently,
and there also needs to be a writable `supervise` subdirectory in each
service directory.
Checkpoint. Not in a working state, but getting there.
This is an attempt to declaratively define s6 service directories
as S-expressions that get converted to the actual directories, and
to define supervision trees as a collection of those directories.
example/router.scm is an example that defines a service to run BIRD under
s6, and put it in a directory together with a service to initialize a
linux bridge.
The end goal is to be able to construct a guix profile containing the
following:
service/ - a directory of s6 service directories
bin/ - a union of all paths needed to supervise /service
etc/profile - environment variables for s6-svscan
Then, s6-svscan can be run from shepherd or systemd or whatever init
system is in use, to monitor the service/ directory. It would be nice
to make it use bind mounts instead of symlinks, because then I could
put s6-svscan in a mount namespace rooted at the profile. But that's
not a hard requirement.
The current code does not quite work, and I am having some difficulty
debugging it and still getting familiar with the guix codebase and
concepts. Currently I'm hitting what seems to be a trivial error in the
build-side code of the s6-service-compiler's G-expression, but
I can't figure out where the error is, and stack traces aren't helping.