Followup: systemd user instances

In this last post, I wrote about how to fix systemd user instances for older/broken systemd versions. Here, I'd like to explain how we managed to get the solution for, say, more than a single host where you can't do those changes by hand (at least not while keeping you sane and your customers happy).

In order to keep track here, we need to do the following:

1. generate an SSH key for root if missing
2. deploy that SSH key for the users in question if missing
3. deploy our-user@.service on the host
4. enable our-user@.service for the users in question

For that purpose, we built an RPM package (I guess the same will be possible with your favorite package management system as well), which looks like this:

[Unit]
Description=Alternative User Manager for %I
After=sshd.service

[Service]
ExecStartPre=/bin/bash -c "test -e ~/.ssh/id_rsa || ssh-keygen
                                                     -t rsa -N '' -f ~/.ssh/id_rsa"
ExecStartPre=/bin/bash -c "/usr/bin/ssh -oBatchMode=yes %I@localhost /usr/bin/echo
   || cat ~/.ssh/id_rsa.pub | /usr/bin/su -l %I -c 'tee -a ~/.ssh/authorized_keys'"

ExecStart=/usr/bin/ssh %I@localhost /usr/lib/systemd/systemd --user

Restart=on-failure

[Install]
WantedBy=default.target

NOTE: don't break the lines.

The noticeable difference to our first version is the addition of two additional ExecStartPre options which perform (1) and (2) of our TODO list. Especially (2) turned out to be very tricky using all sorts of shell magic.

The remaining points (3) and (4) requires us to perform remote execution powered by SaltStack's (also on github). This way, we can deploy our additional package hassle-freely on all affected hosts and with it the service unit. Enabling and starting the service (via salt) also performs steps (1) and (2) and we are all set!

Best,
Sven