I believe the following are desirable features: - bit-for-bit identical filesystem - ability to group nodes into classes of functional roles - inheritance hierarchy for functional roles - ability to have different behavior for any node/role - ability to locally deploy chosen bits of the rootfs onto a local disk - ability to boot fully diskless - central configuration - distribution independent - easy to use oneSIS (http://onesis.sourceforge.net) has all of these features and more. I've set it up on many, many systems, and have found it to be very flexible, easy to use, and easily extensible. I've used it in production environments (+500 machines, several roles, single root FS) for several years. I would very much encourage you guys to take a look at the software and leave feedback. More than a starting point, it already provides a complete solution for much of what I think you're trying to accomplish. -JE ----------------------------------------------- Josh England Sandia National Laboratory, Livermore, CA High Performance Computing and Networking email: jjengla@xxxxxxxxxx phone: (925) 294-2076 On Tue, 2004-09-14 at 10:44, Josh England wrote: > On Tue, 2004-09-14 at 09:45, Steve Coleman wrote: > > John Hearns john.hearns-at-clustervision.com |fedora| wrote: > > > I was just basically saying to make sure security is thought about early > > in the boot process, or at least as early as possible. > > I believe the best way to implement a security model here would be to > add the authentication into the initrd. Some form of authentication > could be done before the root filesystem is ever mounted, but NFS v3 is > not a secure protocol. If NFS is being exported to a certain node, no > amount of client-side authentication can stop someone from getting to a > prompt and running the 'mount -t nfs' by hand. This pushes the security > concerns onto the NFS server. I believe that NFS v4 has paid more > attention to security details. > > -JE >
