Re: Problems with Redhat 9

--=-Ub41u52uMlCUgcEm5PjS
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

Sorry for the long e-mail but just catching up on the thread and some of
the items I have seen. (mostly off topic since this is the Grab Mailing
List)

      * Why we use.Redhat
      * Boot CD install method
      * Kickstart for Debian
      * View of md5sum's


Why we use Redhat:

I have been reading the thread and here is my personal reasons for using
Redhat over Debian on multiple servers. My personal systems I can count
on both hands and keeping Debian updated isn't really an issue but for
production/work system (over 100 of them) it started to eat up more of
my time.

     1. The Redhat Kernel rocks! Plain and simple, look at the amount of
        patches to the kernel compared to a stock Debian or a default
        un-patched kernel. Some of my Debian system run custom compiled
        Redhat kernels because of drivers and the patches in the kernel
        were needed.
     2. Redhat Network. Currently nobody has written a tool individuals
        can install and maintain that monitors your different servers
        packages like rhn does Be nice if there was but I haven't found
        it. Make a private Debian Network where an admin could quickly
        see what sytems need what patch and could just click to apply
        them.
     3. Production Tree. I don't need to maintain my own Debian mirror
        of packages that I have patched/upgrade/etc. Upgrading 50
        servers one day and then another 50 a week latter you are left
        with machine with different packages if you need to point at the
        unstable tree in Debian. Keeping a personal stable tree eats up
        a lot of time.
     4. 3rd party software. While alien (tool for installing rpm's under
        Debian) works 90% of the time. You might still have to run
        Debian unstable if there are libs that are required. Not to
        mention dealing with vendors that expect that your running
        Redhat.

Those are my current reasons have for running Redhat over Debian. Mind
you currently we have a lot of Debian systems still... =20


Boot CD install method:

On Fri, 2003-04-11 at 13:52, Greg Kurtzer wrote:
> I am VERY familiar with the LNX-BBC(.org) rescue disk, which is why gave =
me
> the idea for this installer. Thanks for this like, I will check it out!!
>=20
> I will distribute the tools fairly soon...

For OSDN we uses a custom boot CD that I hacked together from the Timo's
Rescue CD  http://rescuecd.sourceforge.net/ and scripts originally
created by an ex-admin Chad. Adding packages to our CD build is simple
since I just chroot to the build env and uses apt-get. Timo's CD is
build around Debian. The stuff we actually install however could be any
Linux distro since it is stored on a NFS mount.

I picked Timo's Rescue CD over some of the others because for me it was
the easiest method to build the CD. The original CD that Chad created
was boot and go. If you wanted to change anything you had to build
another CD by hand and relied on syslinux, plus he didn't even install
vi. Since Timo's CD runs as a rescue CD I can bypass the install and
modify the scripts for any custom needs that come up. At anytime I can
escape and then login to the rescue CD.=20

During the CD install we software raid mirror two disks together using
sfdisk and then temp mount them. From the NFS mount we cpio the files we
need. Once the raid is done rebuilding the install chroots to the temp
mount and install lilo, ejects the CD and reboots.=20

If I burn 10 CD's and pop them in machines I can just boot them and come
back in an hour or so. Then login and register them with rhn. Give the
machine static IP's and place it in our production environment.

The install method relies on DHCP and NFS. Inside the NFS mount are
different chrooted installs. So its easy to keep the handful of
different installs updated. Just chroot to them on the NFS server and
either run up2date or apt-get. During the CD install it lists out the
different server loads and we can pick anyone we need. If I don't pick
one in 30 seconds it uses the default.

Seems to work for us. Thought I'd share. Not sure if I'm allowed yet to
release the modification I made to Timo's CD since this was done while
at work. You all know how that goes, but I should be able to since its
not part of the VA Software commercial product. Drop me an e-mail off
list if you have an interest.

Kickstart for Debian:

I remember reading about someone looking for a kickstart method for
Debian. Well there are a few methods to install all the same packages at
least. Its not kickstart but they can be handy. The methods I know are
for a virgin Debian system already booted.
=20
     1. "dpkg  --get-selections > output" Then copy that output file to
        a virgin Debian install and "dpkg --set-selections < output".
        Then run "apt-get dselect-upgrade". (from memory but that the
        basics)
     2. jablicator - generates  an "apt-get"-able package. The package
        itself is empty. However it has a dependency for every
        non-required Debian  package  that  is on the machine. This
        program will create and populate two directories dists and pool
        in your working directory. You can then move them to a web
        accessible location. (from the man page)=20

View of md5sum's

The md5sum's that Redhat uses on its packages is cool but if your still
using Debian look at the package "debsums". It can build a md5sum
history based on sums in the package or if the package is missing them
will download the package and create them based on the downloaded
package. Its handy but if you got rooted its much better to reinstall
then rely on md5sums. Just how good is a md5sum when someone tacks on
another null character to the end of a file. Every file on your system
will report the incorrect md5sum then. Just things to think about.

   Yazz

--=20
 Yazz D. Atlas <[email protected]>             [ O | S | D | N ]      =20
 Senior Systems Engineer / Senior BOFH   http://www.osdn.com=20
     gpg --keyserver  wwwkeys.pgp.net --recv-key 0x0C57DDA0=20
     GPG: 644C E9FF D0AF 3C5E 5C73 5E05 00EF C7EC 0C57 DDA0

--=-Ub41u52uMlCUgcEm5PjS
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+l1q3AO/H7AxX3aARAp4+AJ93UGHM73WJTJ3Z8IT1/+oVu6mzQACfWQ6G
Qaho3wtJQPOzQkGntOflGnc=
=e57+
-----END PGP SIGNATURE-----

--=-Ub41u52uMlCUgcEm5PjS--