Hi Katolaz,
Apologies for the delay.
KatolaZ writes:
> On Thu, Feb 14, 2019 at 09:14:45PM +0900, Olaf Meeuwissen wrote:
>
> [cut]
>
>> > It's in my todo-list, but I would be grateful of you would be so kind
>> > to please open a bug on bugs.devuan.org, so we are sure we don't
>> > forget it.
>>
>> Against which package?
>
> Against tasksel, please.
Done. It's bug#294 and stuck in the moderation queue because I appended
a rather long list of the recursive task-kde-desktop dependencies :-/
>> BTW, why again are we trying so hard to not pull in unattended-upgrades?
>> I think I lost track and considering my own Devuan (server) experiences,
>> which have been good, I'm not quite sure I still understand :-/
>
> Because this is something that users should be aware of, and clearly
> notified about. We are neither Microsoft nor Apple.
Ack.
> Unattended upgrades should be used by people who know what they want
> out of it. If you know (as you do, in this case), you also know how to
> find, install, and configure it. If you don't know what this is about,
> and unattended-upgrades is installed, you start believing in ghosts :)
>
>> # It was my Debian server that needed a dbus cluebat ... ;-)
>> # And then only because I insist on self-inflicted "pain" by telling APT
>> # to not install recommended packages in the first place.
>>
>> Your average KDE/GNOME desktop user might actually appreciate their
>> security upgrades getting applied "behind their backs" or "without user
>> intervention", depending on your point of view.
>
> Let's be honest: considering security an automatic process is just a
> myth, and a quite misleading one, IMHO :)
Security is not an automatic process but being able to automate some of
its steps definitely cuts down on the amount of work you need to put in.
> There is no single size that fits all the possible uses of
> unattended-upgrades, and while some users might find it desirable,
> some others might find that the "smart" upgrade silently broke their
> setup, in a way or another. This was the case with several important
> upgrades of stuff like php or mysql/mariadb in the past (mainly due to
> local customisations, I admit, but still, a sysadmin is free to do
> what they want on the system they manage...).
The machines I administer only have the packages installed that are
really needed. There is no "fluff". I keep /etc in git with the help
of etckeeper (and tweaked that to log which packages are upgraded from
which version to what version). The services these machines provide are
all Dockerized. The only time, so far, fingers crossed, that things
went awry was when the Docker folks pulled support for sysvinit :-/
> In general, in a server environment an admin wants to make sure that
> an upgrade actually does not stop the running services from doing
> their job as planned. Especially if there are customisations and/or
> other hacks put in place to hold things together.
Yes, that's why I run my services in Docker containers and test those
upgrades on other hardware before deploying. Each service's set up is
kept under version control too.
I did disable unattended-upgrades when I went on a holiday to make sure
the host systems didn't go belly-up while I was away. Don't worry, we
are doing something about me being a single point of failure ;-)
> IMHO, the reasonable solution is to make sure that unattended-upgrades
> does not slip in a standard Devuan installation unnoticed, under any
> circumstance. If a user know about it and want it running, it's just
> an `apt-get install` away.
While I agree with not letting slip unattended-upgrades in unnoticed,
I'd like to warn against saying that a package is just an `apt install`
away without giving real, concrete reasons (like you did above for the
case of unattended-upgrades) why a package dependency should be demoted
from a Recommends: to a Suggest: (or removed altogether).
Hope this helps,
--
Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27
GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9
Support Free Softwarehttps://my.fsf.org/donate
Join the Free Software Foundation https://my.fsf.org/join
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
