Okay, I have yet again refactored the service massively and am eager to hear feedback on it. Sorry, I took a bit, but since I was in the middle of making a new release for spacecookie anyways, I held back until I had everything sort of figured out (not released yet, but I know at least what the configuration changes will be).

New options:

• package, allowing to change the derivation
• openFirewall, doing the allowedTCPPorts dance for you
• address, allowing to customize the address to listen on

I also moved everything except port into the settings attribute which is converted into the config file using pkgs.formats.json.

The thing I'm a bit bothered about is the question of port and address. The problem here is that we don't actually use the capabilities of spacecookie for these options, as the socket is handled by systemd which is why I currently have it outside of settings, but this could be confusing for users possibly.

Another reason for this is, that in the next spacecookie release the top level port option will be deprecated in favor of something like this:

{
  "listen": {
    "port" : 70,
    "addr" : "::1"
  }
}

…where addr does what address does in this version of the service, but won't have any effect if socket activation is used which we do (we only need to pass the port to spacecookie because this is relevant to know at runtime). I've thought about hijacking the listen set from settings, removing addr (because if set it generates a warning if socket activation is used) and using the information gathered to set up spacecookie.socket. However, the catch here is that the syntax for IPv6 addresses in getaddrinfo(3) and systemd.socket(5) is slightly different, so I feel like separating our socket configuration from the settings set makes things a bit clearer, but I'm interested to hear opinions on this.

I have the adjustments for the next version on a separate branch and will PR them when the update hits haskellPackages, but there's no rush or timing to consider as the configuration will stay compatible (even for port).

@GrahamcOfBorg test spacecookie

@sternenseemann not sure what to say about that failed test... 🤷‍♂️

@sternenseemann not sure what to say about that failed test... man_shrugging

That's really weird, since the curl call seems to produce the correct output, but then fails with 56 (“Failure in receiving network data”). I'll ponder this some more tomorrow, I guess.

Seems like the curl -f call is flaky sometimes, I can't reproduce it locally and it doesn't happen on ofborg every time. Maybe we should remove the succeed and just check the output for curl to make sure we never block the channel accidentally?

Edit: Done, see also sternenseemann/spacecookie#42

Found a less ugly workaround for the curl problem, namely using netcat. Upstream issue is also fixed, really need to get this release out the door now :)

With #116096 we have spacecookie 1.0.0.0 including a fix for the curl flakiness making the test fail! I've reverted the workaround for that in the test and added the new options' description to settings.

@ofborg test spacecookie

Yes! Almost forgot it as well.