SCIENTIFIC-LINUX-DEVEL Archives

July 2007

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Troy Dawson <[log in to unmask]>
Reply To:
Troy Dawson <[log in to unmask]>
Date:
Fri, 20 Jul 2007 16:13:45 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (87 lines)
Stephen John Smoogen wrote:
> On 7/20/07, Jon Peatfield <[log in to unmask]> wrote:
>> On Fri, 20 Jul 2007, R P Herrold wrote:
>>
>> > On Fri, 20 Jul 2007, Troy Dawson wrote:
>> >
>> >>  Just out of curiosity, since I don't use it, what do you usually 
>> set for
>> >>  the default number.  In the past, I had it set to 2.  Is that 
>> reasonable,
>> >>  or would people rather have it higher? like 3 or 4?
>> >
>> > The centos group have discussed this -- with the pace of kernel 
>> updates,
>> > particularly near the start of a release of a new Major, it is 
>> inprovident to
>> > think that end users running yum on a cron autopilot will reboot 
>> when new
>> > kernels are walked in.
>>
>> Personally I think that *some* updates should be marked 'reboot needed'
>> since carrying on running with the old version means that tools will say
>> 'no new updates are needed' but the machine is still running with the
>> old/insecure/broken version.
>>
> 
> The EL5 Gui has support for this and flags updates to glibc,kernel,
> and some others as requiring a reboot. However, doing this via a cron
> job at 4am means an email or some other such thing to tell a person a
> reboot should be done. Which is probably a good idea for the
> yum-cronjob program to have in it.
> 
> 
> 
>>
>> > mkinitrd is fragile enough, and yum's error detection historically
>> > insufficiently granular, that I worry that a number of people are 
>> going to be
>> > going to recovery media ;(
>> >
>> > Throw in non-stock controller kernel modules, and a trainwreck seems 
>> to be on
>> > a horizon.
>> >
>> > Dialling up to say at least 4, if leaving it enabled at all, seems 
>> prudent,
>> > to let others be the pioneers -- you know - the ones with the arrows 
>> sticking
>> > out of their backs  ;0.
>>
>> Or just don't install it on such systems...
>>
>> Note that installonlyn has been installed and on by default in 
>> Fedora-Core
>> for quite some time (FC3 I think).  If it broke lots of things it would
>> have been very widely reported by now.
>>
> 
> I have seen some reports in the past. They usually were along the
> lines of kernel-headers going away when the kernel didnt (i am sure
> this bug got caught). The issue is if the fixes work in 'back-porting'
> this to 3.x/4.x (which i think they are), and that the problems listed
> above are listed in a man page or something for people who shoot
> themselves can be pointed tothe man page on how to pull bullets out of
> foot.
> 
> 
Hi,
Just to put minds at ease.
Scientific Linux's nightly cron job excludes kernel's, and anything that is 
dependant on them (openafs, GFS, kernel-modules)
This excludes list is at
   /etc/yum.d/yum.cron.excludes

That list only affects the automatic updates.  If a user does a "yum update" by 
hand, or by some gui way, it isn't affected, and they will get a kernel update.

Also, if a user has a specific rpm that they don't want automatically updated, 
they can just add that to the list.

Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LCSI/CSI DSS Group
__________________________________________________

ATOM RSS1 RSS2