[wplug] I'm a Linux whimp (need kernel help)

[Poyner, Brandon]

> There's a couple options -
> 1) (what I employ) keep a single system attached to RHN and synch all
> updates, broadcasting to other machines by whatever mechanism 
> works for
> you
> 	- clunky, requires another machine (as it happens I use a VM)
> but is rather immediate
> 	- all gets are manual, no running of rhnsd
> 	- when done via an install server (like with xCAT) the updates
> can then be applied to both new installs (as part of 
> kickstart POST) and
> existing servers
> 2) wait for the next update CDs to be generated
> 	- works, but systems exposed to the world may sit with a known
> vulnerability or bug for several weeks / months
> 3) manually pull updates from the channels via browser
> 	- can't believe anyone would do this, but it's an option
> 
> 	I will say that in the grand scheme of things the images we
> deploy rarely have much that needs updated, so the above is low-stress
> to maintain.
> 
> 	There are ways to "trick" RHN with multiple machines appearing
> as one entry, but it can't be done simultaneously with the 
> rhnsd running
> on all nodes, and is clearly a violation of the EULA, so I'll say
> nothing further on that subject.

I'd say my way is closest to 1.  I wrote a perl script to do an up2date
--showall, in the chroot I do an rpm --qa, compare the outputs to see
what's updated, and then download with a up2date --get -d.  I haven't
written the part to automatically apply the patches but I easily could.
Waiting for an official patch pack or manually pulling with a web
browser isn't very acceptable.  It just feels like RHN forces you into a
kludge if you have anything non-standard.  It's kind of funny because
last time I read the EULA it seemed to be on an honor system more than
anything else.  That is, it seemed very unlikely the BSA would be
knocking down your door to audit your RHEL licensing.

> 	We don't config to back up OS - only conf files / user data, but
> even if we did a full followed by incrimentals would not be _too_ bad.
> xCAT and kickstart profiles can recover the OS and 
> application levels we
> require.  Even copying off /var/log/rpmpackages will provide the basis
> for a fast kickstart recover of the base package level (of 
> course, does
> nothing for conf data).  But I see your point..... 
> ferinstance I really,
> really hate the fact that pretty much all the "-devel" packages go in
> these days - hence my heavy reliance on kickstart over the CD 
> installer.
> But I also don't see Red Hat ever changing this behavior - it 
> works far
> too well as is.
> 
> 	The longest kickstart I've worked with to date is 94 printed
> pages.  Not all my work (thank God).  Surprisingly even with all the
> pre-/post-loading work the install still completes in under 15 minutes
> on current hardware and a fast network (NFS or FTP (or perhaps local
> disk mechanics) starts to degrade after about 8 machines installing
> simultaneously).  It's fairly amazing what some guys are doing before
> the install even reboots.

Kickstarts are a big part of the reason I like RedHat over other
distros.  Ok, mine isn't 94 printed pages, not even close.  I get the
feeling you're dealing with a few more systems than I am if you're using
xCAT.

> 	Agreed - I'm sure it has everything to do with keeping the
> phones from ringing at the RH support desk.  If it comes with 
> it out of
> the box, there's less chance of a user calling because they dorked a
> system trying to make some device / service / app functional.  You
> likely know this, but there's no difference in the kernels on these
> releases - it's purely in the support RH will offer you.  
> Actually, the
> only real differences in the install media are the splash screens and
> the system ID files that get generated......
> 	This has had some fairly heavy consequences tho - look at the
> length of time that RHEL2.1 was the only release out there 
> and it had no
> LVM support - and Oracle would not let you recompile the kernel to get
> it.  That handed a lot of market share to SuSE.....
> 	I think it's stupid, but it's helped pay my mortgage :)

I had heard there was no real difference but didn't have any evidence to
back it up.

> 	I just started to look at cAos (http://linux.caosity.org/) it
> appears to use a very intelligent package management framework (all
> packages "stand alone" from what I can tell)  This is the 
> kind of distro
> that needs ISV support, but it will prolly never happen.....

That looks really nice.  The only thing obviously missing from the
feature list is GFS.  I can't tell how mature it is though and how
likely it is to stick around.

One thing that bugs me about Fedora Core is that they provide patches
for 1 year and then you're off to fedora legacy.  And fedora legacy
depends upon the interest of a loose group of people.  Anybody that ran
RedHat 8.0 got burned by the lack of interest in the community because
of the unstable desktop environment.  Forget that 8.0 was rock solid as
a run level 3 server.  

Thanks for your input.

Brandon Poyner
Network Engineer III
CCAC - College Office
412-237-3086