Bdale Garbee dixit:
>Nothing is "forced on the user", the conffile handling is doing exactly
>what is expected. If the admin chooses to not accept the update, the
>worst that happens is they have to fully qualify command paths until
>they've patched up sudoers.
Yes, that’s inconvenient but manageable (except in the face of
automated upgrades). Also, the normal conffile handling only
has a yes-or-no approach (and a “let me spawn a shell” one),
none where you can interactively merge (like with diff3 when
CVS has a merge conflict) the change…
>> Also, visudo now asks
>> | press return to edit /etc/sudoers.d/README:
>> which, while cosmetic, will lead to much frustration and some
>> confusion under the sysadmins.
>
>I don't see that. What command causes you to get that message?
sudo visudo
⇒ opens an editor on the tmp for /etc/sudoers
^Kx (exits the editor)
⇒ displays the message
<return>
⇒ opens an editor on the tmp for /etc/sudoers.d/README
This is because /etc/sudoers contains
| #includedir /etc/sudoers.d
and /etc/sudoers.d/README is a file in that directory…
must there be one in order for the #includedir line to
be valid? (I’d patch that out.)
bye,
//mirabilos
--
08:05⎜<XTaran:#grml> mika: Does grml have an tool to read Apple
⎜ System Log (asl) files? :)
08:08⎜<ft:#grml> yeah. /bin/rm. ;) 08:09⎜<mrud:#grml> hexdump -C
08:31⎜<XTaran:#grml> ft, mrud: *g*
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
