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

[Vanco, Don]

>-----Original Message-----
>From: wplug-bounces+don.vanco=agilysys.com at wplug.org 
>[mailto:wplug-bounces+don.vanco=agilysys.com at wplug.org] On 
>Behalf Of Poyner, Brandon
>Sent: Monday, August 15, 2005 2:42 PM
>To: General user list
>Subject: RE: [wplug] I'm a Linux whimp (need kernel help)
>
>
>> 	OK - since when is rhnsd a requirement of running RHEL? (HINT:
>> it's not)  There are many ways to update from and/or utilize RHN that
>> don't require the daemon.
>
>I'd appreciate some information in that regard.  I didn't get the RHEL
>book with our purchase and was unable to find a way to get the binary
>packages without using up2date.  I can see where they provide the SRPMs
>via public FTP, but I'd rather not have to put a full -devel install on
>my servers and rpmbuild all the time.  I often create chroot
>environments (entirely from RPMs, mind you) and that really breaks the
>rhnsd model.  I have a work-around with up2date but I'd love 
>to know how
>to fetch the binary packages in another manner.

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.


>
>> 	Again, no direct implications meant.  At least part of this
>> (kernel config & bloat) is based in philosophy anyway, so 
>> there's really
>> no right or wrong....
>
>Part philosophy, part reality.  The reality is I don't install many
>packages because 1) I won't use them 2) It's a waste of disk space 3) I
>don't want to back them up and 3) I certainly don't want to waste time
>restoring useless files from tape in an emergency.  So the philosphy is
>if I'll avoid installing packages for those reasons, why should I be
>happy with unnecessary bloat?  I'll agree there's no given right or
>wrong, everybody's needs are different (somebody, somewhere has used
>'true --help', right?).  I do what I can to mitigate what I see as
>problems.  That's just me.  You should see my kickstarts ;)

	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.


>I give serious consideration to any distro that is tailored for being a
>server and comes with the level of support as RHEL.  The problem with
>many distros is that they try to be everything to everyone.  RHEL AS is
>still guilty of this in my opinion, it can work equally as well as a
>server or workstation.  Considering there is a RHEL WS this seems
>pointless to me.

	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 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.....

Don