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(a)sandia.gov
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