On Mon, Mar 27, 2017 at 5:51 AM, Marc Haber <mh+debian-packa...@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 _______________________________________________ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
