For a while now, anaconda has had the ability to fire up an sshd server in the install environment. It's useful to be able to ssh into the system as it's being installed and poke around on the shell. Doubly useful when doing remote installs of headless systems. Required for doing installs on systems that have crap for a (remote) console like s390x.
Anaconda had 2 ways of bringing up sshd, on s390x a replacement for /sbin/init would get ran and bring up the sshd server automatically. But on other arches it was up to anaconda itself to bring up the ssh server, if the "sshd" boot option was encountered. Along with the sshd boot argument there was a kickstart argument "sshpw" that would get handled to set a password for the user(s) who could log in via ssh. Of course, s390x couldn't make use of this because sshd was started prior to anaconda, and in fact, anaconda wouldn't start until somebody ssh'd in as the "install" user. Hurray for differences!
Now that we've got systemd bringing things up and anaconda isn't "init" any more , it's just a service and target, we can do some fun things. We can create our own anaconda-sshd.service to go along with our own sshd config specific to anaconda. We can use a systemd generator to look for "inst.sshd" boot argument (all anaconda boot args were renamed to start with inst. in F17) or s390x arch and if found make the anaconda-sshd.service be a part of the anaconda.target. The anaconda-sshd.service makes use of an ExecStartPre script to parse the "sshpw" kickstart line (if it exists) and setup users/passwords accordingly, before sshd itself is brought up.
This accomplishes a few goals:
- ssh bring up is the same on s390x vs other arches
- passwords are configurable for s390x just like other arches
- anaconda code doesn't have to deal with service bring up
- gets us closer to s390x bring up without having to replace init
- results in net-negative code in the repository