The following are a collection of somewhat related thoughts on the cloning matter...
It's occurred to me to wonder "Why bother worrying about whether the rpm database is correct on a cloned system?" If the only system that will be applying RPMs is the master system, and you forbid clones from installing RPMs, you can do away with the whole "make scratch disk, install rpm, swap volumes, reboot with RO vol, rebuild scratch disk, repeat" business. It does not seem to be that large of a concession, especially considering that production systems should not be getting things installed on them that have not been checked out on test systems first. Since you did check it out on a test system first ( you did, right?) then you should clone the production machine from the test machine. Like VM's service process... For MVS folks - this is basically like having one set of sysres volumes that you clone everwhere, but only keep one CSI around on the master version for maintenance. Theres no point having more than one CSI since you will only install on one system anyway. Of course, when the RPMs scatter their files all over the filesystem, it makes the cloning process tougher since you have to copy the non shared parts around, but if it's a real RPM you can do a 'rpm -ql <rpmname>' to list out all the files that it installed. Using that list, you can copy the parts that live in the non-shared areas like /var, /etc, and so on. The **real** pain comes when you want to clone something that uses the java based installshield ( like, say... WebSphere ). Stuff that's packaged like that installes these little stub RPMs that don't actually contain any package information. When you try to query what files that RPM has in it you get the informative answer '(contains no files)' Sigh. Not impossible though. Just takes some pre-planning. Before installing something like WebSphere, create a list of the entire file system's contents with find: 'find / > /root/filesyslist.prewas' Then install WAS. Then do the find again: 'find / > /root/filesyslist.postwas' Do a diff on the two files and you have your list of installed WAS parts. The same process then applies to cloning the system with WAS installed - use the list to determine what to copy to the RW areas on the cloned system. Then theres the problem of convincing the WAS on system B ( the clone ) that it is no longer on system A ( the master ), but I'm pretty sure thats just a matter of extensive search and replacing of hostnames in WAS's xml config files on system B. But then - WAS likes to install it's config files in a subdirectory of where the rest of the procuct lives - which is on a read only volume, since that's the whole point of this exercise. Sigh. Also not impossible. A pain, but not impossible. Since we're on VM, we can create tdisks for stuff like this. Allocate a tdisk for the clone to use for config information. Create a WAS-O-matic script that runs at boot time. The script should format the tdisk, mount it somewhere, and copy all of WAS's config to there. Then it should do lots of search and replace mojo on those RW xml files to convince WAS that it's actually on system B. The last thing the script does is to unmount the tdisk, and remount it **over** the RO directory that contains the old config files. Then WAS starts, knows it's on system B, and everyone goes and gets a frosty beverage. Hrm. That was quite a ramble. I think I see the beginnings of a SHARE presentation in there... Anyone interested? Jay Brenneman ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
