Mag Gam on 6 Aug 2007 20:26:05 -0000


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

Re: [PLUG] Kickstart Question

  • From: "Mag Gam" <magawake@gmail.com>
  • To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
  • Subject: Re: [PLUG] Kickstart Question
  • Date: Mon, 6 Aug 2007 16:26:02 -0400
  • Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=gMnPEDxnVw8C23J1D1pcLLE97QhsO+86FoslkXapQsyODJdoAFbC7FQBIWAOao+nhRiJSbhmgAiA4s6BB7CpXaJjByFExWRxFsYNzvf/W9WmGZHHzhqkAJ8MD0UOSkaLvkqhnOTi4zCuiELNGKNjIvNhClMzthFKt83NjP/lfLc=
  • Reply-to: Philadelphia Linux User's Group Discussion List <plug@lists.phillylinux.org>
  • Sender: plug-bounces@lists.phillylinux.org

Thanks steve! Very nicely documented. I will try these later today
 

On 8/6/07, Stephen Brown <sbrown@mediaguide.com > wrote:
There are a few tools around for doing various kickstart related things,
but it depends on what you end goal is as to how well they fit your
situation. Revisor is a tool that seems to be aimed as live-cd's, and
http://cobbler.et.redhat.com/index.php looks interesting if you want a
tool to assist you in managing kickstart deployments.

As I didn't learn about Cobbler till this year, I have been doing the
more manual PXE-based installs for several years now and am comfortable
with the following setup.  Is also has the advantage of once you set it
up, it is easy to tar up everything from the install server and transfer
it elsewhere to be used again.

If you are trying to do a network-based (PXE) install you will want a
- dchp server
- tftp server
- ftp/http/nfs server to server up the install sources
- a local Yum repository (Optional but recommended)
- pre-patched install tree (Optional but saves time if you do a lot of
installs)

I find it is most handy to have all of these on one computer with enough
space to serve up the files and a free gigabit card that you can
dedicate to an install network so you don't mess up anything on your
main network.

What I typically do when a new distro comes out that I need to work with
is download the iso's, burn the first CD/DVD but unpack all of them on
my install server so that I can do a network install. Then I used the CD
to boot and added an askmethod to the boot prompt so that I could kick
of an network install. I then to a minimal install just to be sure that
the distro will install properly on my test boxes, and resolve any odd
boot-time parameters that make need to be added (like nodmraid).

Take the /root/anaconda-ks.cfg file that you created during the install
as your starting point for you real kickstart files.

As to the install server, assuming you are using a fedora-ish distro for
the install server, make sure you have the following installed:
dhcp
tftp-server
syslinux
xinetd
memtest86+    (often handy.. not required)

I set up iptables to do a masquerade from the install network out to the
normal network, and set up bind as a caching nameserver. Syslinux will
give you the pxe stuff to do a network install from a tfp server. You
will want to find the pxelinux.0 file under /usr/share/syslinux* and
copy it to /tftpboot

Set up dhcpd on the install network with something like this in your
/etc/dhcpd.conf, assuming yout install network is 10.248.17.0/24.

subnet 10.248.17.0 netmask 255.255.255.0 {
        range 10.248.17.100 10.248.17.250;
        option routers 10.248.17.1;
        option domain-name "tempdeploy.example.foo";
        option domain-name-servers 10.248.17.1;
        default-lease-time 3600;
        option time-offset -18000;
        option subnet-mask 255.255.255.0;
        filename "pxelinux.0";
        next-server 10.248.17.1;
}

The key bits in that are the filename and next-server options that tell
PXE where to load the boot from the network.


Next up is your PXE boot menu.  I set them up to wait a bit then boot
from the local disk so it doesn't interfere too much after an install
has completed. Something like this for /tftpboot/pxelinux.cfg/default
will get you started, there are more examples and notes in the syslinux
documentation:

prompt 1
default local
timeout 150
say You have 15 seconds to choose an option or the local disk will boot
say Options are:
say local, memtest, ...

label local
        localboot 0

label disk
        localboot 0

label memtest
        kernel memtest

label nfs-example
        kernel vmlinuz.f7
        append initrd= initrd.f7.img ramdisk_size=8192
ks=nfs:deployer:/install/ks/single-scsi-f7.cfg ksdevice=eth0

label http-example
        kernel vmlinuz.mg7-x86_64
        append initrd=initrd.mg7-x86_64.img ramdisk_size=8192
ks=http://deployer/ks/mg7-x86_64.cfg ksdevice=eth0 nodmraid

Note that the append line in each clause there is one line even though
it got wrapped.  I have deployer set up in the bind on the the install
server to resolve to the private deployment-net IP on the install
server. You will also want to set up the reverse-mapping for your
deployment network on the install server so that things don't hang or
act odd when starting up. The ksdevice option is handy if the system you
are installing to has multiple interfaces - anaconda will ask you which
you want to install from if you don't add it in.

The kernel image and initrd files referenced in the pxe config file
should reside in your /tftpboot directory. I grabbed the kernel and
initrd from the "isolinux" directory on the DVD/CD images or from the
full install tree.

The final bit is the kickstart file. Above are examples of how to
reference it by nfs or http. Both seem to work fine in my experience so
it depends on what you want to set up. You can get creative if you use
http however and use a php script or something to generate the kickstart
on the fly. I would suggest starting with the anaconda-ks.cfg that you
got from your initial install and checking that you un-comment the
partitioning lines so that it actually wipes your disk and double check
the install source location will be valid. Then boot up your test box
and see what happens. A full f7 install takes < 10 min for me.

Once you get that working they you can start to customize the kickstart
file to your needs.


As this email is already super-long, that should give you an idea of the
process. If you have any questions don't hesitate to ask.

Good luck with Kickstarts, while it takes a while to get everything set
up, once you do you won't bother with pesky cd's again.

- Steve


Mag Gam wrote:
> Claude:
>
> Yes, I will need it thanks. I am just trying to learn the Kickstart
> process. I am familar with AIX's NIM, just want to see Linux's Kickstart.
>
>
>
> On 8/5/07, *Claude M. Schrader* <plug@claudeschrader.com
> <mailto:plug@claudeschrader.com>> wrote:
>
>     You do not necessarily need a DHCP server to use kickstart. You can
>     burn a
>     custom CD with the kickstart config file on it to automatically fill in
>     all the values in the installer. I believe you can even customize the
>     packages on the install disc. I have more information on this at my
>     computer at work, so I should be able to send you some links during
>     the day tomorrow if you need it.
>     Claude
>
>     On 19:12 Sun 05 Aug     , Mag Gam wrote:
>     >    Anyone familar with Redhat's kickstart feature?
>     >    I was wondering if you need a DHCP server?
>     >    thanks!
>
>     >

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug

___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug