Your message dated Tue, 19 Nov 2019 09:42:03 +0100
with message-id <[email protected]>
and subject line Re: Bug#858818: please consider implementing or at least
documenting a headless-friendly emergency target
has caused the Debian Bug report #858818,
regarding please consider implementing or at least documenting a
headless-friendly emergency target
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
858818: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858818
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
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.
(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.
In the ideal wishlist case, this would be implemented either through
trivial configuration (such as, for example, systemd enable
emergency-login.service, systemd enable emergency-ssh.service), or it
would be at least documented how to achive this behavior.
Documentation of this is especially important since a systemd user
usually wants to avoid the knee-jerk "you're doing it wrong, take a
hike" reaction that is so common when one talks about a systemd issue
while having been creative with system configuration.
Please consider having a "Debian way" of making Debian great again for
datacenter usage.
Greetings
Marc
--- End Message ---
--- Begin Message ---
On Mon, 27 Mar 2017 20:49:46 +0200 Martin Pitt <[email protected]> wrote:
> Michael Biebl [2017-03-27 18:03 +0200]:
> > 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.
>
> Ubuntu's friendly-recovery might serve as a base here -- it does the above
> "opportunistic" network bringup, offers fsck and apt-get -f install and others
> (but not SSH as far as I know, but it's easy enough to extend with shell
> plugins).
Since we have friendly-recovery in Debian, I'm closing this bug report.
I haven't tested it myself yet, but if there is functionality, bugs
should best be filed there.
It would also be great if someone interested in this issue would pick up
the package:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924369
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
--- End Message ---
