[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Cluster Administration, a suggestion, and possible intent to package



On Mon, Nov 09, 1998 at 08:36:56AM -0500, Stephen J. Carpenter wrote:
> Sounds interesting but I wouldn't be stuck with NFS specifically
> I am really anxious to try CODA filesystems and leave NFS behind :)

Coda!  Coda!  Coda is fun :)  However, trying to mount even /usr over
coda might be...interesting... it's not quite as debugged as NFS.

> This sounds very usefull :) It would be nice to have dpkg give an error
> if it is used on one of the clients and be able to use rsh or ssh
> or some such to run itself on the server (depending on config)


The ability to lock down dpkg should not be hard, but it should also
not be NECESSARY - just remember, dpkg can't make changes unless run as
root.  If your cluster administrator starts running dpkg on a client
it's already a problem :)  You can still accomplish this with a
wrapper, though, and divert /usr/bin/dpkg.

> Here are my thoughts...
> 
> chances are you want /usr shared between all machines...(afterall this
> is part of the point of the fsstnd/fhs). 
> 
> perhaps a quick hack for simple stuff would be just to share /usr and not even
> have dpkg on the clients...then you would need some simple scripts or add-on
> to dpkg to force an active push of any new files in /bin or any
> of the unshared dirs to be moved to the clients (unless they are diskless
> then just place it on them all)
> 
> Configuration is another matter...that could be kind of delicate...
> 
> Perhaps we need a way to specify configuration files which contain host 
> specific information...
> for instance... /etc/profile generally can be shared between machines (In
> fact I would dare say that would be prefered), but possibly /etc/exim 
> shouldn't be,.... /etc/hostname no way... 

I read this, I think about the cluster (at CMU) that I'm sitting in
right now, and I have a really good idea.  I do not believe it's
packaged, and I am not even sure if it's currently distributed outside
of campus, but there is a (most likely DFSG free, I'll check) program
called depot.  It uses 'sup' (is sup packaged?  Is it going to be?) for
distributing updates, and has the ability to run scripts when files on
the master change, and while it does not quite push, it can be set to
run nightly.  Or if a push is really needed you could manually run it
on all machines (using ssh and authorized_keys for instance).

If I can and it hasn't been, I'll package up depot - I imagine it needs
quite a bit of work, but it certainly could be the basis for
clustering.

Dan


Reply to: