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

Michael Biebl biebl at debian.org
Mon Mar 27 17:03:34 BST 2017


Am 27.03.2017 um 17:07 schrieb 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.

You don't want to involve the whole PAM stack in an emergency situation.
PAM can be almost arbitrarily complex, involving network services (LDAP,
SSSD, etc.)

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

I don't think such a service needs to be part of ssh (or systemd for
that matter), it might actually be better if that was shipped by a
separate package, which can be installed on demand for cases likes your
(and is ideally maintained by users of such functionality).

Such a package could try to bring up the network by itself, by first
trying to directly run NM , ifup or even attempting a simple dhclient.
Directly, meaning not using the .service units which might have
dependencies which might not be satisfied by emergency.target/rescue.target.

Then it could try to start an SSH server (with possibly a minimal
config). It could even try different implementations, like openssh,
dropbear etc.

Again, I think this is not something which necessarily has to live in
the systemd package.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20170327/ada001f8/attachment-0002.sig>


More information about the Pkg-systemd-maintainers mailing list