I prefer Backup and Restore as a dual purpose DR plan and offline storage of images in compressed format. That is why I wrote VMLMAT to facilitate that strategy: http://vmlmat.sourceforge.net
On Tue, Jun 9, 2009 at 11:00 PM, Scott Rohling <scott.rohl...@gmail.com>wrote: > 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
