One of the requests from some prospective clients was to not have a generic “ubuntu” user. We wanted to evaluate how hard it would be to set that up, and what it would break with Juju if you did create that environment.
To that end, I creating a charm lovingly called
cs:~jameinel/no-ubuntu-user based on the ‘ubuntu-lite’ charm. It adds a few things:
installhook that kills any processes running as the
ubuntuuser and then removes that user.
- A bit of configuration so that you can optionally create an alternative user, along with either an
ssh-import-idto add for that user
The simple usage is:
$ juju deploy cs:~jameinel/no-ubuntu-user \ --config username=jameinel --config ssh-import-id=jameinel
That will create a Bionic machine, remove the
ubuntu user, and then create a
jameinel user and run
ssh-import-id jameinel as that user, bringing in my SSH keys from launchpad.
After deploying this charm, as expected:
$ juju ssh no-ubuntu-user/0
Fails, because there is no ‘ubuntu’ user to connect as. However, both
juju ssh and
juju scp already support
user@host syntax so:
$ juju ssh jameinel@no-ubuntu-user/0 $ juju scp test-file jameinel@no-ubuntu-user/0:.
Work as expected.
The other command that no longer works is:
$ juju debug-hooks
because that command used the
ubuntu user to get onto the machine to run a tmux session. We currently do not support supplying an alternative user for that machine.
Note that ‘juju run’ no longer uses SSH to connect to the machine, but uses the actions infrastructure to run, run for a unit works fine:
$ juju run --unit no-ubuntu-user/1 'echo $(hostname) says hello' juju-4eeb15-2 says hello
However, ‘juju run’ as a machine was designed to
su - ubuntu before running the command, and now that the user doesn’t exist, it fails:
$ juju run --machine 2 'echo $(hostname) says hello' No passwd entry for user 'ubuntu'
Another agent that stops working is the
ssh-authkeys-updater. It wants to make sure the “ubuntu” user on every machine has the right .ssh/authorized-keys file. But obviously if ubuntu isn’t there, it cannot update. It would need to stop itself cleanly if there is no ubuntu user on the machine.
I’m still evaluating whether any other commands start failing, but so far the only obvious fallout is
juju debug-hooks and
juju run --machine. We can certainly consider if we want to allow passing in an alternative username (and possibly have
juju run --machine run as root always/only if ubuntu isn’t available).
It would also be good to have other people test out the charm, just in case I didn’t actually publish it correctly.