mysql-server

[Pettit, Paul]

> David Rees wrote:
> 
> On Tue, March 29, 2005 3:45 pm, Pettit, Paul said:
> >> > Heh, well do you happen to know when the yum auto update
> >> > runs?
> >>
> >> When ever you tell it to.
> >
> > Ooooh, so tempting ...
> >
> > Um, no. It runs when cron.daily runs and that runs at ONE 
> time in the
> > day. Move the time cron.daily runs and you move the time a 
> ton of other
> > things run.
> >
> > Remember we are talking with the *stock* setup as detailed in the
> > documentation.
> 
> The *stock* setup *works* for the vast majority of FL users.  You
> obviously have different needs. 
>

No, not much different than everyone else. 

I only possed an opinion (for which I have been thoroughly reamed for)
in regards to timing the release of updates. My only mistake was not
thinking of the problem on a more global scale in relation to timed
releases. It's apparent that this must be done based on each persons
local conditions. I had incorrectly thought it was something that FL
might want to control or lend a hand dealing with.

> I've suggested a solution and even wrote
> a small script in attempt to solve your problem.  Did you see it?
> 

Yes I did and it's the bet response of all the posts here. I thank you
for actually trying to solve the problem, that's what a community is
for. Saddly you're the only one that really did that. Tom had the same
idea but (heh) did it in less useful terminology. :)

I'm looking at your script and I've made another (in Perl) that has a
bit more granular control to it. I'm not much of a shell scripter so if
I use your script it wil probably be 'as is'.

I really appriciate the help man. 

> If you wan yum to run at 7:00AM Mon-Fri, it's pretty simple 
> to set it up
> to do so.  Make sure that the yum service is off (`service yum stop;
> chkconfig yum off`), copy the yum.cron script somewhere you see fit,
> modify it to not check the config status of yum and not to sleep some
> random time between 0 and 120 minutes and add the following to root's
> crontab:
> 
> 0 7 * * 1,2,3,4,5 /etc/<somewhere>/yum.cron
> 

Yeah that will work for now but dealing with holidays is a bit more
tricky. Yum nor Crom really don't have any method for dealing with it
and I'm not aware of another job scheduler for linux that would resolve
the core issue.

There in is the nut I need to crack. FL will be of no help in dealing
with it and I can see why: tz issues, lack of ownership, no drive to
resolve, and the mantra of security (updates out asap when "ready", not
that that's bad).

I'll have to do some more programing and I'll try and send out the
improved script (if I get it to work well) so others can use it. Did a
test run but it took like 3 hours to run and I'm not sure why. :P

> > Just why is scheduling updates (or limiting them to business days in
> > what ever TZ your in) bad? You rejected it but with no actual
> > explaination.
> 
> When it comes to security updates (the goal of FL), the sooner these
> updates are released to the community, the better.  If you 
> would only like
> updates to be applied during a specific time period, see my solution
> above.
> 

Actually Peter put it better:
|> Peter J. Holzer
|> 
|> I agree with others that FL should NOT consider timing. Local
policies
|> vary wildly between organisations. One organization may have 
|> a policy to
|> make updates only on monday to thursday, while another may 
|> have a policy
|> to make them only on sunday morning (I do know one company 
|> where changes
|> on production servers are only allowed on sunday from 00:00 to
06:00).
|> These are local policies, and they should be implemented locally. FL
|> cannot know about them and I think it is not a good idea for FL to
|> decide for its users when they should update their systems. 
|> 
|> 	hp

Simply put the problem is far to complicated for FL to deal with thus
they feel it's not their problem. Its up to the local admins to find a
solution, which is fine as I'm sure we are all up to it. I only thought
that FL might try and help but as I said it's too complex for them (as
many global issues are for many support service geared organizations).

The documentation however will need to be changed. I'm working on that
and will try and edit it once I figure out wiki (never used it before).

> > Because you have rejected the problem without explination of why you
> > feel this isn't a problem beyond the "you shouldn't use 
> auto-updating"
> > or "it's a yum problem" answer of which neither is valid. 
> As stewards of
> > these updates you bear a bit more responsibility than that.
> 
> See above.
> 
> -Dave
> 

I still feel they hold some responsibility in regards to addressing this
but they feel that they are only responcible for hosting the docs, the
update files, and coordinating testing. Understandable, more than that
is probably outside the scope of their ability. Releasing updates as
soon as they are up is the only compromise FL is capable of considering
all the above. I don't hold any animosity for that, it's just the way it
is.

Thanks Dave, I'll get back to you with a script and see what you think.
:)

Paul Pettit