Bug#769388: 'PermitRootLogin without-password' in new installations breaks some use cases
On 2015-01-26 00:16, Cyril Brulebois wrote:
> Niels Thykier <email@example.com> (2015-01-16):
>> On Thu, 13 Nov 2014 11:08:45 +0000 Simon McVittie <firstname.lastname@example.org> wrote:
>>> Another possibility would be to use a low-priority question that is
>>> only shown in the "expert" installer, but can be pre-seeded.
>> Please also keep in mind that such questions need to be translated.
>> I am not certain on the policy for d-i for having pre-seedable
>> configuration without an "expert" question.
> Preseedable configuration is way lighter than (expert or not) questions,
> since it's only about an extra key/value to handle in scripts, and
> there's no need for translations. We have many of those, and we could
> support an extra one without too much hassle.
Ok, sounds good. :)
> At first glance, having this question asked in expert mode wouldn't seem
> too crazy. I'm a bit worried about the timing though; this should have
> been noticed and worked on way earlier (this change happened in March).
Sadly, we have had tons of issues in Debian, we ought to have discovered
months ago. :-/
>> If this is not an issue for d-i, I suppose it could be added solely in
>> the openssh-server-udeb package.
> Nice try. :) That udeb is here to provide ssh support during the
> installation process, it doesn't quite control what's happening in the
> system getting installed.
Ok, where would something like this go then? I tried checking out the
d-i source and I am yet to figure out the place where "random"
preseedable/expert questions go.
Is this case basically "shove the debconf selections into the target
system and let the regular .deb packages deal with it"? If so, it seems
that openssh "mostly" already permits this to be preseeded:
if dpkg --compare-versions "$2" lt-nl 1:6.6p1-1 && \
[ "$(get_config_option PermitRootLogin)" = yes ] &&
db_get openssh-server/permit-root-login && [ "$RET" = true ]; then
set_config_option PermitRootLogin without-password
(I suspect it just needs a little fiddling with the --compare-versions)
>> If we are going down this route, then let us have it documented in the
>> installation-guide. If needed be, we can add a reference from the
>> release notes to the relevant part of the installation guide (or maybe
>> just a remark about it).
>> Though note that the release-notes only handles upgrades between the
>> (soon-to-be) previous and the (soon-to-be) current release, so I firmly
>> believe it should be documented in the installation-guide to ensure it
>> is a stand-alone document.
> We can either document that late_command option (right now) or implement
> something specific to be preseeded, and document it when it's done.
> By the way: You wrote about the need for translations above, that applies to
> the installation guide as well.
True - I assumed that the installation-guide was as easy to update on
the website as the release-notes.
I am ready to look into writing a patch for d-i to provide this to be
preseedable. I am presume it needs to be "documented somewhere" in d-i
(either as an expert question, in the installation-manual or in the
standard preseed-example file). I do not mind doing it as an expert
question as well assuming we still have time for getting translations.