Scott Rohling wrote:
Hi Doug -- Yep, we sure had some fun kicking Linux servers!
Not sure how Linux not doing restarting itself is an IBM issue... but that
'is' a nasty downside to kickstarting -- ending up at a 'You may safely
reboot' screen doesn't help automation.
Reboot issue fixed in RHEL 5.3 :-)
And we should add that kickstarting is faster than cloning 'if' the DASD is
already Linux formatted.. if not, the kickstart does the formatting, adding
time to the install.
Scot
On Tue, Jun 9, 2009 at 11:39 PM, WILLIAM CARROLL <v...@smgvbest.com> wrote:
Hi Scott,
I'll jump on your bandwagon but then again you already know I perfer
Kickstarting over cloning
you should also mention that unless you have Flashcopy for your DASD
Kickstarting is actually faster than cloning.
unless your clone master is very small.
as you recall ours was on a mod3 (lots of required garbage) and cloning
that mod3 was slower than kickstarting
also after the kickstart was done the server was ready, no additional
steps
to change IP's or anything.
if only redhat would fix that re-ipl after the reboot.
they say it's an IBM issue not thiers
Doug Carroll
----- Original Message -----
From: "Scott Rohling" <scott.rohl...@gmail.com>
To: <LINUX-390@VM.MARIST.EDU>
Sent: Wednesday, June 10, 2009 12:00 AM
Subject: To kick or to clone ... that is the question
This is a blatant request for discussion about the pros and cons of using
an
automated installation (e.g. RH kickstart - Suse autoyast (though maybe
this
has changed - I'm not current on Suse) - vs cloning a system from a
'golden
image'... and I should say: on zSeries.
I'm a fan of kickstart - and I'll list my reasons in approximate order of
importantance to me (most to least):
- kickstart forces a scripted and recreatable installation. You specify
the rpm's and can do some limited scripting within the kickstart file
itself
to end up with (hopefully) a working Linux system that requires no manual
tweaking (at least - if you do it 'right'). The alternative is a cloned
system that the Linux SA's have been on, and perhaps several other teams -
all performing manual tasks to end up with the final product - all sorts
of
shoeprints and no good detectives. Whereas a kickstart config is
self-documenting - a clone is not. With good scripting and good use of
rpm
packaging for your 'local' or even 'vendor' products - you can end up with
a
very KISS config file that might even go multiplatform. (e.g. arch=`uname
-m` )
- with a proper building of conf and parm files on z/VM - a guest can be
kicked already configured with a working network -- no need for some
outside
scripting or manual config.
- you can have different kickstart files for different server 'types'
(web,
app, db, etc) - these can even be built dynamically and requested via a
URL
to to the kickstart ( e.g.
http://mykicker/kick.web&ip=xx.xx.xx.xx+etc+etc.....)
- The size of the DASD can be flexible.. cloning requires copying the
same
size DASD as the source..
- The latest fixes can be applied by keeping the repository the kickstart
uses current - rather than updating a clone source. (of course - testing
is
still required and would require kickstarting a guest to truly do any
testing - a good thing imo)
- It encourages packing by rpm rather than manual 'tarball' methods..
this
is in line with a 'recreatable' install. Yes, you can still do 'tar'
commands in the kickstart file itself.. but specifying an rpm package is
oh
so much easier.
- Servers start 'clean' - ie no old log files from the clone source and
no
need to try and script a 'cleanup'
- No worrying about whether a clone source is 'up' when a new server is
clone and possibly clone a live system
There are downsides.. but I'll leave those to the rest of you to expound
on, since I'm taking a position of 'kickstart good, Jane'
Thanks and hope this is valuable to some ..
Scott
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
Brad Hinson <bhin...@redhat.com>
Sr. Support Engineer Lead, System z
Red Hat, Inc.
(919) 754-4198
www.redhat.com/z
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
