Hi Justin, Andrei, Thanks for the proposed text below. I struggle a bit with where to place it. What do you suggest? It's not really an upgrading issue, is it?
Paul @Andrei, I guess I should put it in the equivalent place in the buster release notes too, right, after fixing suite names in the text? On 10-04-2021 19:44, Justin B Rye wrote: > Andrei POPESCU wrote: >>> (Should there be some hint here at the fact that this has happened >>> because we've switched to an implementation of sulogin without the >>> slightly dodgy Debian-specific patches?) >> >> This is explained in the bug report for who cares to investigate, in my >> opinion it's not needed in the Release Notes. > > This was mostly a note to myself in the hope that I'd find a way of > leading into it that accentuated the positive - after all, this is > just a side-effect of improvements elsewhere. But when we're this > late documenting it, it's a non-starter. > > [...] >>> This probably needs an external link, but I'm not optimistic we'll >>> find one. Maybe this is another case where we'll need a dedicated >>> page on wiki.debian.org. >> >> As you probably know, it's as simple as: >> >> systemctl edit rescue.service >> >> and add >> >> [Service] >> Environment=SYSTEMD_SULOGIN_FORCE=1 >> > > Well, I know that now, because I've been looking it up, but I wasn't > sure as I wrote that, and it's not as easy to pull the details > together as it should be. Still, at least it doesn't need the usual > reminders to run daemon-reload or reboot. But instead of telling > people all about where to hunt for the information it might be quicker > in this case just to put the answer in the text! > > <title> > The <literal>rescue</literal> boot option is unusable without a root > password > </title> > <para> > Booting with the <literal>rescue</literal> option always requires > the root password. If one has not been set, this makes the rescue > mode effectively unusable. However it is still possible to boot > using the kernel parameter <literal>init=/sbin/sulogin --force</literal> > </para> > <para> > To configure systemd to do the equivalent of this whenever it boots > into rescue mode (also known as single mode: see <ulink > url="&url-man;/bullseye/systemd/systemd.1.html">systemd(1)</ulink>), > run <command>sudo systemctl edit rescue.service</command> and create > a file saying just: > </para> > <screen> > [Service] > Environment=SYSTEMD_SULOGIN_FORCE=1 > </screen> > <para> > It might also (or instead) be useful to do this for the > <literal>emergency.service</literal> unit, which is started > <emphasis>automatically</emphasis> in the case of certain > errors (see <ulink > > url="&url-man;/bullseye/systemd/systemd.special.7.html">systemd.special(7)</ulink>), > or if <literal>emergency</literal> is added to the kernel > command line (e.g. if the system can't be recovered by using > the rescue mode). > </para> > > [...] >>> (Why *did* setting these systems up with passwords in the first place >>> go out of fashion?) >> >> For me it was a natural consequence of using sudo exclusively ;) > > Ah, well, it's the old slogan - "Debian: giving you the power to shoot > yourself in each toe individually." > >>>> For background and a discussion on the security implications see >>>> bts:802211. >>> >>> I forget if we've got special markup for this or whether we just say >> >> All entities are in a dedicated file (I don't have a checkout handy to >> look it up). > > I can't see the definition, but judging by old .po files we want > > <para> > For background and a discussion on the security implications see > <ulink url="&url-bts;/802211">#802211</ulink>. > </para> >
OpenPGP_signature
Description: OpenPGP digital signature
