Add systemd unit

[hseg]

Very belated, but I finally wrote the systemd unit.
(Certain idiosyncrasies of my system added unnecessary complications to the
development here, but at least I can finally give you this)

Also includes a configuration template for using gpg as the encryption
backend, which I'd understand if you want to remove. Included it because I had
some difficulty getting gpg to cooperate and thought the next person to use
gpg here might need the pointers.

Closes: #21

[hseg]

Just noticed I had failed to account for code drift since I last touched
pizauth, rebased the PR to simplify history.

[hseg]

Just noticed this PR should also contain an edit to make install to also
install the new files appropriately, will leave this for after the weekend.
(Same applies for #25)

[ltratt]

Thanks for this! We want to put this into some sort of subdir, since it's specific to one platform (and pizauth runs on several). I'm unsure what the convention is on this but I'd be inclined to think that examples/systemd/ would be appropriate (though it looks like apps install these files into lib/systemd/user?).

[hseg]

On Fri, Dec 22, 2023 at 03:20:50PM -0800, Laurence Tratt wrote: Thanks for this! We want to put this into some sort of subdir, since it's specific to one platform (and pizauth runs on several). I'm unsure what the convention is on this but I'd be inclined to think that `examples/systemd/` would be appropriate (though it looks like apps install these files into `lib/systemd/user`?).

Sure, works for me. If that's how you're seeing the systemd unit, I guess you'd then want some way of signalling to `make` whether to install the unit? Though that'd complicate the Makefile somewhat. Maybe something like https://unix.stackexchange.com/a/703535 ? And yes, installation location for user units (as opposed to system units) is usually /usr/lib/systemd/user (my system has the `/usr` merge, so `/lib -> /usr/lib`).

[ltratt]

Is the empty line deliberate? [I ask naively -- I have no idea!]

[ltratt]

Good point. On reflection this should go into /usr/[local/]share/pizauth and then users can know it's an example rather than a command. I think let's aim to get this in, then I can fiddle with installation instructions when it's in-tree.

[hseg]

On Sun, Dec 24, 2023 at 01:40:02AM -0800, Laurence Tratt wrote: @ltratt commented on this pull request. > @@ -0,0 +1,6 @@ +[Service] +Environment="PIZAUTH_STATE_FILE=%S/%N.dump" +ExecStartPost=-sh -c 'age --decrypt --identity AGE_PRIV_KEY -o - "$PIZAUTH_STATE_FILE" | pizauth restore' +ExecStop= Is the empty line deliberate? [I ask naively -- I have no idea!]

Yes -- systemd's semantics for drop-in configuration is simple (perhaps overly so) -- all relevant drop-in files are appended to the unit. In particular, this means that while _appending_ to a list configuration is straightforward, inserting at any other point in the list or removing from the list requires clearing the list and re-adding the entire updated value. cf systemd.unit(5)

Note that for drop-in files, if one wants to remove entries from a setting that is parsed as a list (and is not a dependency), such as AssertPathExists= (or e.g. ExecStart= in service units), one needs to first clear the list before re-adding all entries except the one that is to be removed. Dependencies (After=, etc.) cannot be reset to an empty list, so dependencies can only be added in drop-ins. If you want to remove dependencies, you have to override the entire unit.

(note the repeated `ExecStop=/usr/bin/pizauth/shutdown`)

[hseg]

On Sun, Dec 24, 2023 at 01:40:31AM -0800, Laurence Tratt wrote: Good point. On reflection this should go into `/usr/[local/]share/pizauth` and then users can know it's an example rather than a command. I think let's aim to get this in, then I can fiddle with installation instructions when it's in-tree.

Would agree with putting the `.conf` files there. (The .conf files are templates of files that should be dropped into `$XDG_CONFIG_HOME/systemd/user/pizauth.service.d/`, so make more sense as documentation as your alternative installation location suggests) Am unsure what you mean by

users can know it's an example rather than a command

If you're concerned about installing the `.service` file to `/usr/lib/systemd/user/` for fear it will autostart the unit or somesuch, don't be -- that just _provides_ the unit to be used by the user, the user then needs to run `systemctl --user enable pizauth.service` to configure it to autostart at login.

[ltratt]

Thanks! I'm going to merge this and do a little bit of moving around when it's in-tree.