[Yum] Yum cron defaults
mhedemark at trueposition.com
Mon Jan 5 12:52:51 UTC 2004
Josko Plazonic [mailto:plazonic at Math.Princeton.EDU] said:
> Don't most people want to be notified when
> something like
> software upgrade happens with their machine?
For my small handful of home machines? Maybe. But for every machine I am
responsible for at work? No, thanks.
> I have over 100 machines doing updates with autoupdate (not
> yum but same
> principles apply) from local dir and I do want emails from them when
> changes occur.
I could be wrong, but I'm ass-uming that most people with large deployments
like this are rolling their own yum rpm with a site-specific config. I
think it is a given that anyone rolling their own yum rpm should be expected
to go over the couple of small config files and customize to their own
liking. Seth is never going to please everyone with the default settings,
and might very well piss a lot of people off if he changes those defaults to
give more verbose output and suddenly lots of sysadmins start getting
> Even if I was not (quickly!) glancing at them to make
> sure everything looks good - disk space is cheap and procmail is your
Far better to not send in the first place than to block with procmail.
> Hm, that makes me think - it should be doable to add a few
> lines to yum
> to get it to syslog it's basic actions. Add to that a module
> for epylog
> that summarizes such output and you have a way to quickly see
> how many
> machines did a particular update...
I would be *completely* happy with syslogging everything rather than
emailing it. That way I could use something like logwatch against my
central syslog server to consolidate package reporting (something like
"Package foo was upgraded 224 times" rather than seeing 224 emails each
saying that the package "foo" was upgraded).
But if this were accepted as an enhancement, one thing I would ask is to
make it a modular thing. i.e. some people might want to log to syslog, some
to snmp trap, others still to an http post. So rather than hard code the
logging to one form of output, put the hooks there to call an external
function or script. That would give us the most flexibility in figuring out
how to track client package upgrades without having to be "spammed" :)
More information about the Yum