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-packa...@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 _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
