On Sat, Apr 30, 2016 at 12:55 AM, Konstantin Olchanski
<[log in to unmask]> wrote:
> On Tue, Apr 26, 2016 at 12:06:42PM -0500, Pat Riehecky wrote:
>> On 04/26/2016 11:59 AM, Dan McDaniel wrote:
>> >Is there any way to get yum-cron to read environment variables? There
>> >doesn't seem to be anyway in /etc/yum/yum-cron.conf. They seem to expect
>> >you to edit that file on every single system.
>> >
>> >I want to change the email_from setting because getting 100 emails all
>> >from "root@localhost" is less than helpfull. On 6.x the emails came from
>> >root@$HOSTNAME, but I can't find any way to make this work on 7.x.
>> >
>> >Am I missing something simple?
>> >
>>
>> Alas no you are not missing anything:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1121189
>
>
> Use the much better yum-autoupdate from CERN instead:
>
> http://www.triumf.info/wiki/DAQwiki/index.php/SLinstall#Enable_automatic_system_updates_.28CentOS7.29

Sorry, but that thing is a complex nightmare. Running it out of
systemd is begging for repeated breakage in any complex environment.
And any automagical "udpate every time any update is available" system
is likely to break stable environments. I've seen this with production
systems in Scientific Linux, CentOS, and RHEL.

Part of the difficulty is that auto-udpate tools restart daemons. It's
not such a big deal with forked off daemons like openssh or httpd, but
if you do it to MySQL or any database, restarting in the middle of
lengthy operations unplanned and pre-automated updates at the whim of
some upstream repository can, and should get you fired.

Another part of the difficulty is weaving yet another tool into
systemd when it doesn't need to be and helps guarantee architectural
incompatibility with non-Linux environments, old environments, and
those that have not drunk the systemd Kool-Aid. For pete's sake, you
don't *need* a daemon to run updates. A cron job works *fine*, and is
trivially configured to simply report updates, it's testable from the
shell instead of waiting for systemd to get around to running it hide
the logs, and it's trivially configurable and readable to mortal
users, those without root access to poke the systemd config files,  to
support yum options such as "--disablerepo=whatver" or
"--ignore=pkgname" for those of us who pull mysql components from
third-party repositories and are dealing with dependency hell.

The placement of yum-cron in /etc/cron.daily is itself a bit awkward:
it runs at what is expected to be an idle time of day, along with
other daily scripts, but which can be in the midst of production. If
you need control of precisely when it runs, and of alternative reports
to simply *report* expectant updates, it can be run out of /etc/cron.d
with a bit of work.