Bug#858818: please consider implementing or at least documenting a headless-friendly emergency target

[Felipe Sateler]

On Mon, Mar 27, 2017 at 5:51 AM, Marc Haber
<mh+debian-packages at zugschlus.de> wrote:
> Package: systemd
> Version: 232-21
> Severity: wishlist
>
> Hi,
>
> in the pre-systemd era, a system would continue booting even after an
> error. This frequently resulted in a crippled, but running system
> which allowed a (sometimes crippled) remote login which allowed fixing
> things from remote without having to access the console.
>
> On the other hand, systemd tends to jump into emergency.target at the
> slightest possibility of an issue with booting, the the default
> emergency.service is a train wreck when it comes to having a system in
> a corporate datacenter, especially in a cheap one: It demands that one
> enters the root password on a console. This needs (a) access to the
> console, and (b) to the root password.
>
> A console is debateably accessible in the majority of cases. I do,
> however, have a number of systems in cheap datacenters where I either
> need to rent a console server to get access to the console or to
> actually talk to a human who types commands into the console.
>
> In many companies, the access to the actual root password is severely
> restricted because you usually do your admin tasks with sudo after
> logging in as a mere user. The actual root password is often in a safe
> with the key being unter management control, or it is divided into
> parts that are stored with different individuals so that you need to
> wake all of them to use the root password.
>
> Please consider at least documenting a way to get a more
> admin-friendly emergency mode, which could include one or more of the
> following measures:
>
> (1) allow regular login in emergency mode
> Instead of using sulogin in the emergency target, one could use a
> regular login process which would allow logging in as a regular user
> and use sudo to get root privileges. I do admit that systems can be so
> broken that sudo won't work, but being deprived of the actual _chance_
> for that to work is frustrating.

I suppose this would be as simple as replacing the `ExecStart`
directives of `emergency.service` to invoke login instead of sulogin.
Or the new[1] script could be enhanced to read that configuration from
somewhere.

[1] https://github.com/systemd/systemd/pull/5623

>
> (2) try to bring the network up and start an (emergency) sshd
> I have had cases where the system boot was aborted because /var could
> not be mounted. In those cases, it would have been possible to ssh in
> if the system had bothered to try starting sshd. This used to be the
> case in the pre-systemd era, and I'd love to get this possibility back.

I don't think this can work as long as ssh.service has
`DefaultDependencies=yes`, because that implies
`Requires=sysinit.target`, which is likely involved in the failure
that resulted in the emergency target being started.


-- 

Saludos,
Felipe Sateler