On Sat, Apr 30, 2016 at 12:55 AM, Konstantin Olchanski <[email protected]> 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.
