This started in the "To kick or to clone" thread.
The z/VM crowd has a lot of experience with sharing filesystems. Even now, with sophisticated handling of removable media, Linux is still a little rough. What I mean is ... in Linux land we make way too little use of things like on-demand applications, programs which live on their own disk and are used when called for. We're still thinking "RPM or bust", install it formally or it simply doesn't exist.. In the VM/CMS world, everything always lives on its own disk. You want the C compiler? Link its disk and access it. (Where in Linux speak that would be equiv to hot-plugging the media and mounting it. Please forgive me since most of you are well aware of the correlation.) This is all the more elegant because you can, in the VM/CMS model, have multiple installations, multiple releases concurrently. You can upgrade without interrupting active work. The compiler is owned by a virtual machine called (perhaps) IBMC. Maybe this is a good place to discuss Mike's idea? > An idea: In the first install of the golden image, > how about creating a small file system at /var/lib/rpm? > You maintain RPMs, and thus the RPM database, > on the golden image. When you create R/O clones, > they get a R/W /var/ file system of course - BUT! - the > golden image's /var/lib/rpm/ gets overmounted R/O. Sure. This would work fine. And I see that Kyle Black reports some success with that. In my shop, we elected to retain a RW copy of the RPM DB because we can in fact still use RPM on the "clients" as long as the RPMs installed there do not step on RO space. For this to work, an 'rpm --justdb' kind of reconciliation is needed when you upgrade the op sys. -- Rick; <>< ---------------------------------------------------------------------- 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
