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

[Marc Haber]

Hi Felipe,

thanks for your fast answer. I really appreciate your consideration.

On Mon, Mar 27, 2017 at 11:47:40AM -0300, Felipe Sateler wrote:
> On Mon, Mar 27, 2017 at 5:51 AM, Marc Haber
> <mh+debian-packages at zugschlus.de> wrote:
> > (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

I like the idea of a configurable script. But I also like the idea of
having an emergency-login.service which could be used as a drop-in
replacement, keeping emergency.service simple. But, it looks like, it
is not as simple any more anyway.

I am however worried that sulogin is used here instead of login for a
reason. Does anybody reading thie remember why sulogin was invented in
the first place? I have never understood why one would restrict login
in this mode of operation.

> > (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.

I guess that the ssh maintainer could be coaxed into including an
sshd-emergency.service (maybe even socket activated for simplicity,
possible with privilege separation disabled to heighten the chance of
the service being successful) which systemd could use in this case. I
do understand that doing this with the default sshd.service unit would
be a challenge.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421