bring forward nice login prompts from container linux

[dustymabe]

When you log in to container linux you get a nice prompt that tells you some information about the machine.

$ ssh core@192.168.122.136
Container Linux by CoreOS stable (1800.7.0)
Failed Units: 1
  example.service
core@localhost ~ $ 

On the serial console there is a nice message telling you what the IP address is for the machine.

This is localhost (Linux x86_64 4.14.16-coreos) 14:19:32
SSH host key: SHA256:yP+/44/bfuj6UKHdUwAVURsO3y6haKLKfSFNcnmn7bY (ECDSA)
SSH host key: SHA256:gGDZ/JQzwL76UpT29dyZ/M6Zua7QvGyegP8aTLc/D+Y (DSA)
SSH host key: SHA256:nQEysCYP3hZgkus2+e28KQGrs0pRI2NOgJGQ6L8PnyU (RSA)
SSH host key: SHA256:A3c6toZ3/eTMKNDmyyG9CYUSWsdSunmTeOC68iuDfAg (ED25519)
eth0: 192.168.122.36 fe80::5054:ff:fe85:43a6

we should carry these nice features forward for Fedora CoreOS.

[cgwalters]

See also https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject.org/thread/55SWJA6ERCC3ZPAGEQFJK5EGAXTFX7OJ/

[cgwalters]

Also, one thing I think is very important is to report whether or not Ignition ran.

I'd also note if any ssh keys or users were added.

[lucab]

@dustymabe for reference, the first comes from https://github.com/coreos/init/blob/master/scripts/motdgen and the second from https://github.com/coreos/init/blob/master/scripts/issuegen.

[lucab]

Also, one thing I think is very important is to report whether or not Ignition ran.

@cgwalters what are you specifically looking for here? I'm asking because we can be sensibly report whether ignition ran on the current boot.
But for the generic case (any boot) the answer is always "yes": if you are in the rootfs, then ignition ran at some arbitrary point in the past, otherwise machine provisioning would have failed in initramfs.

[cgwalters]

if you are in the rootfs, then ignition ran at some arbitrary point in the past, otherwise machine provisioning would have failed in initramfs.

True, though we've had bugs where it hasn't run. There's also the case of "I want to perform a system reset", or "I'm testing something and want Ignition to re-run".

[rfairley]

Off-topic from the login prompts, but while ignition is in discussion: do we have an "official" way to re-run ignition? So far touch /boot/coreos-firstboot will re-run it. But I found more needs to be supplied for it to behave the same as if it were a first boot, e.g. a coreos.config.url to get it to re-fetch the config data.

Would we look to have some factory reset button available? It might take the form of a shell script, and would set things up so the next reboot is like a first boot. Its use case would be directed at testing as @cgwalters mentioned. Or is this already achieved by touch /boot/coreos-firstboot?

[ajeddeloh]

@rfairley As of right now there isn't a way to do a "factory reset" since we can't redeploy the ostree from the initramfs. It's something that I think would be possible afterwards though. Basically just use Ignition to recreate the filesystems (including var) and verify the partitions. redeploy, rerun the files stage and blammo, you're factory reset.

[cgwalters]

Why do we need to redeploy? Since everything except /etc and /var is immutable, factory reset is basically:

rsync -av --delete /usr/etc/ /etc/
rm -rf /var/*
touch /boot/coreos-firstboot

right?

(Except of course today you want to keep at least /etc/fstab)

[ajeddeloh]

Right, but having Ignition do it makes it simpler/less error prone. No weirdness of having the running system using the /etc it's actively reseting. No logs trying to be written to places in /var that don't exist. No weirdness with /etc/fstab. No special handling of extra partitions you brought with you. Plus you can keep the node as is until you go down for reboot.

[cgwalters]

Right, but having Ignition do it makes it simpler/less error prone.

Yep, agreed!

(Though most of this is really "in the initramfs" in general - if we still have the initramfs filesystem around we could also pivot to it at shutdown time and do system reset there, but eh, might as well do it on boot)