> 1 - each group needs a common storage for their work. > NFS appears to be the best choice because it tracks > distributions better than say AFS, which may not work > with bleeding edge products.
I'd disagree with that. AFS tracks the OS releases pretty well. For the last two major AFS releases, it's been about a week lag at worst, if not available first day (depending on how cooperative the vendors have been on granting access to new platforms and OSes). For ISV products, that may be a different story, but that should be a hint on the behavior of that application in general. It could be done with NFS as well, though. > 2 - With a common storage, userids and groups > (uid/gid) need to be consistent amongst all platforms > to access the data. That's always a good idea, but that would be another point for AFS; the identifier for AFS is not really tied to the password file, but controlled via Kerberos, so that actually would be a more secure approach. Use of the AFS @sys architecture variable would make this very simple, and be able to have common build processess for the actual machines. I'd suggest a common AFS pool for storage, with specific architecture variables for each release. That will easily scale and fit nicely into your LPAR base as well. The testing and certification environments can easily be satisfied by having small numbers of boxes as running completely from AFS space (OS in AFS and only local boot code) which would allow the same machine to be recycled between groups by changing a set of boot parms. That should be easy to develop and maintain as well. ---------------------------------------------------------------------- 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
