As the only consequence of isSystemUser is that if the uid is null then
it's allocated below 500, if a user has uid = something below 500 then
we don't require isSystemUser to be set.
Motivation: https://github.com/NixOS/nixpkgs/issues/112647
* Make it clearer what code comments apply to
* Fix the state directory (this was changed in the update)
* Add m1cr0man as a maintaner
Co-authored-by: Lucas Savva <lucas@m1cr0man.com>
Co-authored-by: Sandro <sandro.jaeckel@gmail.com>
Pass the args from kernel-generic.nix's top-level to the individual
tests. Makes `nix-build -A nixosTests.kernel-generic.<attr>` and
`nix-build nixos/tests/kernel-generic.nix -A <attr>` work as expected.
The haskellPackages.spacecookie derivation also includes a library and
thus a lot of propagated haskell dependencies. The top-level attribute
uses haskell.lib.justStaticExecutables and therefore only the
executable. This should reduce the runtime closure users have to
download considerably if they only want the server.
* Move `hostname` and `root` into a settings submodule with a freeform
type, allowing users to also use options not known to the NixOS
service. Compatibility with a warning for the renamed options is also
trivial to achieve.
* `port` stays where it is as we don't actually use the `port` option of
spacecookie to set up the socket, but only to inform spacecookie about
the port we have set in the `systemd.socket` file, this makes more
sense. Additionally the configuration of the listening port and
address change in the next spacecookie release — we can dodge this
issue altogether by doing our own thing, but I'm interested to hear
opinions on this.
To ensure that this is not misconfigured, we add an assertion for
the port option.
* Add an assertion for `user` in settings which has no effect the way
we are starting spacecookie as it wouldn't be able to call setuid.
The message also explains how a specific user can be used with
spacecookie if desired.
This configuration option reflects a new feature from the unreleased
spacecookie version allowing to customize the address spacecookie will
listen on (e. g. "::1" to bind on link-local addresses only). We will
not use this feature in the future, since the configuration option of
spacecookie naturally only has an effect if we don't use socket
activation (and spacecookie sets up its own socket), but having the same
functionality in the service seems like a good idea.
We can luckily emulate this behavior with socket activation as well.
This allows to change the derivation to use for the spacecookie server
binary. We probably should also use justStaticExecutables by default to
reduce the runtime closure of the service.
* Use proper gopher urls
* The client vms name is also controlled in a single place now
* fileContent holds the precise file content now
* wait for the spacecookie unit instead of the port
* avoids sending an empty request
* since spacecookie is a notify service it only is fully started when
the socket has been set up.
