systemd: move unit into separate files

[flokli]

Having them available upstream in a individual text file simplifies packaging.

Also, encourage using the official packages where available (and direct back to README for a list).

Also, add a yubikey-agent.socket file for file socket based activation.

[flokli]

I removed the socket activation parts (and opened #44 for it).

I mistakenly assumed this would already be supported.

[philandstuff]

I think there's two competing objectives at play in this PR:

1. document a process for installing yubikey-agent manually and setting up a service for it
2. have a reusable systemd service file available for use by downstream distro packages

I think it's proper that, for a manual install, it goes in /usr/local/bin, while for a distro package it goes in /usr/bin; but the wrinkle is that the resulting systemd units are different, which means if the systemd unit in the source tree points at one directory, the other use case needs to do extra work to change it.

Perhaps we could write the systemd unit for the /usr/bin case, targetting packagers, but update the manual instructions to copy the yubikey-agent.service file and then systemctl --user edit yubikey-agent.service to override the binary location?

Or perhaps we could template the systemd unit and have a script to generate it as appropriate?

[flokli]

I'm not convinced in using something to template it. Go doesn't seem to have a concept of installing more than a single binary, and as we can't cover all usecases automatically anyway, writing out own makefile and templating solution causes more harm than just providing a unit file that works in 90% of the usecases, while mentioning points that might need adjustment.

I pushed a new version that doesn't use an absolute path as written in #43 (comment).

Debian Stable, Archlinux, Fedora >=29, Manjaro and Ubuntu >=19.10 all have systemd >= 239, so the ExecStart= line should work on all of them.

I added a comment noting the ExecStart= line needs tweaking on older versions, and also mentioned the same for some of the sandboxing options which should help for #41.

PTAL.

[FiloSottile]

Awesome, thank you for doing the research, too!

[flokli]

@FiloSottile can you craft a release containing this?