Re: Server Provisioning - Slightly OT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mike M wrote:
Hello,

Since this list deals with OS provisioning (albeit Red Hat-focused), I
figured this would be the right group of people to get some opinions
from.

I work in a data center with >2000 servers, about 90% of which are
running some variation of Red Hat Linux, from 7.3 to ES 4.  The
remainder are Windows Server 2003 and Solaris 10 x86.   As you can
tell, OS provisioning is very important for a shop of this size.

Using kickstart, we have been able to make our larger Linux
deployments very quick, because there is usually a day or two in the
project plan that allows us to get the legwork done in advance.
However, we run into pretty severe problems when we only have one or
two servers that need to be provisioned in one shot.  This is because
there is a lot of stuff that needs to be done in advance in the
standard kickstart process - you need to harvest MAC addresses, enable
portfast on the switch, create DNS entries, create a kickstart config,
etc.  While we could certainly install from CD, there is the
possibility of non-standard package selections, and a by-hand %post of
all non-Red Hat packages and tweaks.

Now, as I see it, there are two options in the provisioning world -
image-based (ghost, partimage), or native installation (kickstart,
RIS).  Each option seems to have pros and cons.

So here are my questions to the group:

If you run a multi-platform server farm, how do you provision the OS?
Have you purchased a product, used one specific package, or cobbled
your own from free tools?  Do you use image-based technology, and if
so, how hard do you find image management?  If you use images, how do
you tackle "uniqueness" (hostnames, IP addresses, etc.) of
newly-provisioned machines?

I only do tens of machines.

I use dhcp on Linux (Debian) for Windows and Linux. I've not tried chaining from pxelinux to the MS boot code, but I suspect it can be done. What gets installed here depends, in part, which network the machine boots on.

I don't understand why people need to harvest the MAC addresses; I choose from the pxelinux menu.

I _do_ configure dhcp to give different replies (including IP address, filename etc) depending what's asking: the BIOS gets a different answer from what I tell Linux. You can also configure it to give different answers for Mac's boot code, and I expect, for *sparc*. Probably for NIC vendor too - an expression involving the hardware address should work.

Here's a fragment to recognise an Intelish box:
class "pxeclients"
        {
match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
                option vendor-class-identifier "PXEClient";
# At least one of the vendor-specific option must be set.       We set
# the MCAST IP address to 0.0.0.0 to tell the bootrom to still use
# TFTP (address 0.0.0.0 is considered as "no address")
#               option PXE.mtftp-ip 192.168.9.1; vendor-option-space PXE;
                option PXE.mtftp-ip 0.0.0.0; vendor-option-space PXE;
        }

Here are some more:-)

class "anaconda"
        {
match if substring (option vendor-class-identifier, 0, 8) = "anaconda";
                option vendor-class-identifier "anaconda";
        }

class "debian-installer"
        {
match if substring (option vendor-class-identifier, 0, 3) = "d-i"; option root-path "192.168.9.4:/tftpboot/PXE/linux-rootfs/kubuntu/edgy";
                option interface-mtu 1500;
        }

Etherboot:
# Filched from http://clic.mandrakesoft.com/documentation/pxe/ch04.html
class "Etherboot"
        {
match if substring (option vendor-class-identifier, 0, 13) = "Etherboot-5.0"; option vendor-encapsulated-options 3c:09:45:74:68:65:72:62:6f:6f:74:ff;
                 option vendor-class-identifier "Etherboot-5.0";
                 filename "tftpboot.vc";
        }


I configured this in hopes:

        pool {
                allow members of "anaconda";
                deny  members of "pxeclients";
                default-lease-time 900;
                filename "http://Fedora.demo.lan/5/i386/os/Fedora/";;
                max-lease-time 1800;
                range 192.168.9.170 192.168.9.179;
                option log-servers 192.168.9.4;
        }


Red Hat's objection was the ill-founded notion they'd need to register something with IANA. Not so.







Any advice you can give will be much appreciated.  I'd love to hear
from anyone, especially those with large mixed environments.  As you
can imagine, we have to use different methods for each OS (Kickstart,
Jumpstart, and RIS/Ghost), and I would love to see something that can
handle them all, or at least simplify and unify the three methods.

Mike

P.S. And yes, as much as it may seem otherwise, I really don't have
rose-colored glasses on...I understand that there's probably no *easy*
way to do it, but I figured it couldn't hurt to ask. ;)

_______________________________________________
Kickstart-list mailing list
Kickstart-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/kickstart-list



--

Cheers
John

-- spambait
1aaaaaaa@xxxxxxxxxxxxxxxx  Z1aaaaaaa@xxxxxxxxxxxxxxxx

Please do not reply off-list


[Index of Archives]     [Red Hat General]     [CentOS Users]     [Fedora Users]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux