dnf replacement for yum-cron
drago01 at gmail.com
Mon Jun 16 15:41:28 UTC 2014
On Mon, Jun 16, 2014 at 5:37 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> drago01 wrote:
>> On Mon, Jun 16, 2014 at 5:14 PM, Matthew Miller
>> <mattdm at fedoraproject.org> wrote:
>>> On Mon, Jun 16, 2014 at 05:06:45PM +0200, drago01 wrote:
>>>> > That's not the most descriptiony of all descriptions ever, but if the name
>>>> > is any indication, it is just a thing which keeps the cache up to date.
>>>> > yum-cron can actually apply updates [....]
>>>> That sounds dangerous ... updates are not really atomic (i.e not at
>>>> all) doing them silently in the background is a very bad idea.
>>> Yet, it works pretty well most of the time. I've done it at decent scale on
>>> production machines with no real issues -- and, most critically, with
>>> *fewer* issues than on unpatched systems.
>>> Real issues do _occasionally_ occur, but so do bad disks, failed ram, bad
>>> offline updates, etc., etc. Fear over lack of atomicity is letting "it's not
>>> perfect!" get in the way of real world usefulness.
>>> Additionally, these updates aren't _silent_ -- they're logged and there's an
>>> e-mailed report.
>> Well I meant things like:
>> Admin: "OK I will reboot box 'foo'"
>> <reboots box 'foo' that was running an update>
>> (well actually that case can be "solved" by using systemd-inhibitors
>> ... does it do that?)
> This server is almost never rebooted, and in many years running yum-cron I've
> never had any problem.
> What is the difference between automated update vs. a manual update, in terms
> of potential for problems anyway?
The former is happening silently while you (the admin) knows that an
update is going on in the latter case.
More information about the devel