Consider adding kernel command-line argument for automatically logging in on console

[bgilbert]

Container Linux supports the coreos.autologin kernel command-line argument, which automatically logs in on the specified console, or on all consoles if none is specified. This is helpful for debugging, since most CL systems don't set passwords on any accounts. It's also used on one platform (Packet) to ease debugging via the platform's console access mechanism.

Consider providing similar functionality in Fedora CoreOS.

[dustymabe]

I like the idea. Here are a few questions

• Is this a relative low priority if we decide not to enable by default (Autologin policy for cloud platform consoles #114)
• If we have this feature would it be too easy for a cloud provider to modify the image we give them and enable it by default even though we chose not to?

[dustymabe]

one more

• if we implement something like this, is it specific to coreos? Should we try to implement it at another layer so it's valuable to the rest of fedora, or other distros?

[bgilbert]

Notes from the meeting last week:

• Instead of a kernel command-line parameter, we could have a file-based mechanism that could be enabled via Ignition. There are several ways to do this:
  • Document an Ignition snippet for writing out the systemd drop-in.
  • Have CT sugar that creates the drop-in.
  • Have a systemd generator that checks for a flag file and creates the drop-in. Document the flag file.
• None of that helps for debugging existing systems, where a dedicated kernel parameter is nice. If the flag file is supported, there's rd.break + creating the file under /sysroot, but that's clunky.
  • single already exists, but doesn't work by default because of the lack of root password. We could fix single and avoid defining a separate parameter.
• For developer/scratch/test systems where the user may not want to figure out how to pass an Ignition config, a kernel command-line parameter would still be useful. AH had developer mode for this case.
• We can always implement an autologin parameter later, but once it's there, it'll be difficult to remove.

[bgilbert]

@dustymabe

Is this a relative low priority if we decide not to enable by default (#114)

It's traditional functionality for users coming from Container Linux, so I'd call it medium priority if we decide to do it.

If we have this feature would it be too easy for a cloud provider to modify the image we give them and enable it by default even though we chose not to?

Even without explicit support, cloud providers could implement the functionality themselves if they wished. It's just overriding the ExecStart command for the appropriate getty.

if we implement something like this, is it specific to coreos? Should we try to implement it at another layer so it's valuable to the rest of fedora, or other distros?

There's nothing distro-specific about the UX. The implementation is somewhat distro-specific, because the autologin user and getty command-line arguments will vary. We could generalize it, but I don't have any sense of whether there'd be interest.

[dustymabe]

We recently did some work around this for live PXE/ISO. @bgilbert any thoughts on making it more generic to apply to other use cases, but only if the user asked for it.

[bgilbert]

My current view is that we should proceed without it and see what sort of feedback we get. We can always add the feature, but can never remove it.

[dustymabe]

Should we close this issue out or is there something left to do?

[bgilbert]

This isn't a priority for now, but let's leave the issue open to centralize discussion in case there's interest in pursuing it later.

[dshinton-qstart]

Given the announcement of EOL for CoreOS, it is driving folks like myself to FCOS. We absolutely need a password recovery process for FCOS and for CoreOS that used coreos.autologin.

I don't care how it is done, either via coreos.autologin or by allowing users to inject an ignition snippet via the bootloader, we just need a solution that someone who isn't an admin can follow to reset the password because I have had customers lose their CoreOS password and SSH keys before. I cannot switch to FCOS if something like this isn't nailed down because backdooring my customer's systems or hacking their password via rescue images are not viable options.

[jlebon]

I added some docs about access recovery at coreos/fedora-coreos-docs#48.

[dustymabe]

We discussed this during the meeting today. There are two use cases for something like this:

• making it easier for users to debug problems (ignition, bootup, credentials, etc)
• making tutorials/labs easier (don't have to fiddle with SSH keys)

The primary use is obviously the first one. The second use case is mostly a convenience and not necessary. Considering that, the outcome of the discussion today was:

  * we'll investigate allowing the use of `single` with a locked root
    account to see if that gives us the ergonomics we want for debugging
    user's issues  (dustymabe, 17:18:55)

@bgilbert is that something you might be able to investigate? If we do go with single then we should probably add it to the docs as well.

[dustymabe]

There are two use cases for something like this:

• making it easier for users to debug problems (ignition, bootup, credentials, etc)
• making tutorials/labs easier (don't have to fiddle with SSH keys)

A 3rd use case I can think of: development. I often am crafting fcct/ignition configs for dev purposes and copying my SSH pubkey around everywhere is a pain. I guess I should use a platform that can take advantage of afterburn to get SSH keys that way.

[cgwalters]

xref coreos/fedora-coreos-config#311

[dustymabe]

Considering the outcome of the meeting on March 11th and the fact that single now works (docs PR). I think we can close this as WONTFIX.