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