Ok, I've just had issues this morning, and went and *looked*. I can see a yum-cron running monthly, sure. Running weekly, I guess. Running daily? Why? And there is *NO* reason whatever for a "yum-hourly*. None. This is CentOS, not ubuntu-snapshot-of-the-moment. I don't know if this is from upstream or not, but it's wrong. I mean, even Redmond only pushes out patches once or twice a month, except for critical fixes.,,,.
On Fri, May 11, 2018 at 10:36 AM, <m.roth at 5-cent.us> wrote:> > And there is *NO* reason whatever for a "yum-hourly*. None. This is > CentOS, not ubuntu-snapshot-of-the-moment. > > I don't know if this is from upstream or not, but it's wrong. I mean, even > Redmond only pushes out patches once or twice a month, except for critical > fixes.,,,. >Are willing to wait up to 24 hours for new security patches, or only an hour?
On Fri, 11 May 2018, m.roth at 5-cent.us wrote:> And there is *NO* reason whatever for a "yum-hourly*. None. This is > CentOS, not ubuntu-snapshot-of-the-moment.Did you have a look at what the hourly run does by default? jh
Jon Pruente wrote:> On Fri, May 11, 2018 at 10:36 AM, <m.roth at 5-cent.us> wrote: >> >> And there is *NO* reason whatever for a "yum-hourly*. None. This is >> CentOS, not ubuntu-snapshot-of-the-moment. >> >> I don't know if this is from upstream or not, but it's wrong. I mean, >> even Redmond only pushes out patches once or twice a month, except for >> critical fixes.,,,. > > Are willing to wait up to 24 hours for new security patches, or only an > hour?In a work environment? Or production? No way is there going to be an instant update. In most cases, you need to test whether that update is going to break things, and that will get you a ton more grief from users and management. Even if it's rated "critical", it needs to be tested one predetermined systems before rolling it out to everyone. mark
John Hodrien wrote:> On Fri, 11 May 2018, m.roth at 5-cent.us wrote: > >> And there is *NO* reason whatever for a "yum-hourly*. None. This is >> CentOS, not ubuntu-snapshot-of-the-moment. > > Did you have a look at what the hourly run does by default? >Ok, I just did, and I see in the configuration file for yum-cron-hourly that it won't do anything by default, so my aggro level is subsiding. Still, I literally do not see any need whatever for an hourly check. As I noted, this isn't ubuntu current (as opposed to LTS).... mark
On 11 May 2018 at 11:36, <m.roth at 5-cent.us> wrote:> Ok, I've just had issues this morning, and went and *looked*. I can see a > yum-cron running monthly, sure. Running weekly, I guess. Running daily? > Why? > > And there is *NO* reason whatever for a "yum-hourly*. None. This is > CentOS, not ubuntu-snapshot-of-the-moment. > > I don't know if this is from upstream or not, but it's wrong. I mean, even > Redmond only pushes out patches once or twice a month, except for critical > fixes.,,,. >So first off I am not seeing this installed by default on my EL-7 systems so something/someone installed yum-cron . Now if someone has installed this package, they also have to have edited the configuration file /etc/yum/yum-cron.conf # Whether updates should be applied when they are available. Note # that download_updates must also be yes for the update to be applied. apply_updates = no If that is not set to no.. someone has changed it from the defaults. In that case.. you need to find out who made the changes. All yum-cron is meant to do is make the cache updated to the latest so various other tools can alert a user that updates are needed. Otherwise you end up with someone keeping a box months out of date and then complaining that no one told them that they needed to update 4000 packages. If you need more control over testing before release, then you need to set up your own internal mirror which you can gate updates to. At that point you get the yum repos pointed to that mirror versus the world and you control your destiny.> _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos-- Stephen J Smoogen.