nixos: Manage files using systemd services

[talyz]

Manage files by creating a systemd oneshot service for each file. The service links or bind mounts the file as appropriate on start and removes the link or unmounts it when stopped. Whether a symlink or bind mount is used is determined by if the target exists - if it does, it's bind mounted, otherwise symlinked. To make sure files are available early enough, also run the start portion in the activation script.

This lifts the restriction on files being placed in /etc and should finally close #1.

[colemickens]

I'm using this PR, and I'm seeing this behavior.

1. At some point, I get things all working.
2. I reboot.
3. Things come back correctly! (etc machine-id, and ssh host keys)
4. As soon as I try to activate a new generation I get errors:

...
updating GRUB 2 menu...
activating the configuration...
mount already exists at '/etc/machine-id', ignoring
reloading user units for cole...
setting up tmpfiles

Frustratingly there's a sort of silent rollback there and the new generation is not activated or marked as the running generation. I guess I can just reboot after I set the system profile every time, but that's not ideal...

[colemickens]

Seems like it fixed it!

[talyz]

Great! Thanks again for trying it out!

[ambroisie]

What's the state on this PR? Is it going to be merged soon?

[talyz]

I think it's done, but I would prefer to get some more testing and reviews before merging it.

Ping @etu @lovesegfault @cole-h

[lovesegfault]

I'm going to test this today without fault.

[lovesegfault]

Seems to be working AOK :)

• I wish we had separate services for binding and linking, so bind-foo, link-bar, instead of bindOrLink-foo, bindOrLink-bar
• I wonder whether the unit names having impermanence on them would be good? This way a user knows what they are when looking at systemctl

[ambroisie]

@lovesegfault I think having impermanence- as a prefix is necessary to be able to distinguish between link-foo and bind-bar while still having a simple "namespace".

[talyz]

@lovesegfault Well, the problem is that we don't know wether we'll link or bind mount until the service runs, so I think bindOrLink is as accurate as it gets. We could of course append impermanence or maybe persistence, since that's what the option is called. It would make the names very long, but maybe that's okay.

[lovesegfault]

@lovesegfault Well, the problem is that we don't know wether we'll link or bind mount until the service runs, so I think bindOrLink is as accurate as it gets. We could of course append impermanence or maybe persistence, since that's what the option is called. It would make the names very long, but maybe that's okay.

How about just persist-$path?

[talyz]

Yeah, that sounds good!

[talyz]

@lovesegfault Changed! :)

[talyz]

@cole-h All done! I kept the names of the ExecStart and ExecStop scripts, since I found the names more descriptive than something like persist-start-*, but all the other instances were changed.

[lovesegfault]

Thank you for tackling this @talyz!