Yes, these are all tough issues. The answer as to "why" is that, done correctly, it can significantly reduce the amount of people time to keep systems maintained, and reduce the (not insignificant) cost of DASD storage.
Doing it yourself is hard, which is why Linuxcare has produced Levanta, and Aduva/BMC has their Deployment Manager for Linux. Neither one of them is cheap, in Intel terms, but for mainframe class software they're not bad. The IBM Linux Community Development System has just a couple/few people managing it, which at one point had 600 concurrent Linux/390 guests running. They were able to do this because of their extensive home-grown automation for system creation/deletion, sharing of /usr, etc. (Richard Lewis has given a couple presentations on this automation.) I think they're down to "only" 250 or so at the moment, but they didn't have to remove anyone from the support team because of the reduced workload. The system was just that scalable that the number of guests didn't affect how much work they needed to do. In the final analysis, if you're only going to be dealing with, say, less than 10 Linux/390 systems, it may not be worth your time to worry about the whole thing. If you get up into the 20-30-40 range, suddenly the savings get pretty big, pretty fast. Mark Post -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Eric Sammons Sent: Saturday, January 24, 2004 9:28 AM To: [EMAIL PROTECTED] Subject: Pros and Cons to sharing /usr In today's Unix world we tend to put everything, almost, under /. With the elimination of the 2GB filesystem limit there hasn't been a need to split out every filesystem for quite some time. However, in looking at the cloning documentation there is a suggestion that /usr/src and /usr be shared as R/O. I am wondering what others have found to be the pros and cons to this? Also, is it possible to share other filesystems? I have heard my management state that the sharing of WebSphere binaries would be desired, I am personally not sure that that is possible. And to be honest I am not sure that the sharing of /usr is a good idea. Being experienced in Linux/x86 and other variants of Unix this is my reasoning for not liking the sharing /usr. There have been and will continue to be numerous times where an upgrade to the binaries (found in /usr) depend on a configuration file in /etc. /etc clearly is not a filesystem nor is it part /usr. This being the case my greatest fear is that /usr binaries would be upgraded while leaving legacy /etc configurations behind that may or more likely will not work. One example might be the going from inetd to xinetd. Other examples might be configuration parameters specific to one version of a product, OpenLDAP, may not work in a future version thus preventing the applicaiton from starting. And to make matters worst /var, having to be unique to each system has been known to see changes that are directly impacted by a newer version of a binary. Take Apache as an example when they moved the default DOCROOT from /home to /var. And because apache installs its configurations in /etc, there lies the biggest issue, the potential to change or touch /etc, /home, /var, and /usr. So my question is why would sharing /usr be a good idea? and how would you ensure that the configurations are up-to-date on all guests after an upgrade has been done to the master copy. And finally the entire sharing thing, unless planned very carefully, could result in an all or nothing situation. All guests get upgraded and it works or all guests get upgraded and nothing works. Of course with planning this can be addressed. Thoughts? Is anyone cloning? Yes, how are you addressing the /etc issues? Thanks! Eric Sammons
