Re: Cluster Administration
On Mon, Nov 09, 1998 at 04:17:16AM -0500, Adam Di Carlo wrote:
> In article <[🔎] m0zcmrE-0007ziC@ralf.informatik.uni-stuttgart.de>, Rainer Dorsch <rainer@ralf.informatik.uni-stuttgart.de> writes:
> > We have here a cluster of 30 SUN UltraSparcs and I am looking
> > forward to see Debian UltraLinux. A major concern I have about Linux
> > on UltraSparc is, that it seems to be difficult to keep on all the
> > workstations exactly the same configuration and sharing diskspace
> > using NFS.
>
> > Currently, Debian package management is sufficient for a single
> > workstation, but insufficient for a cluster. This problem has to be
> > addresses sooner or later, if you want to run Debian on a
> > workstation cluster.
>
> > Maybe the Debian UltraLinux developers could try to find a solution
> > for this problem, in the time they are waiting for Sparc64 support
> > for egcs (this is a multiplatform problem and can be addressed on
> > intel machines).
>
> Utterly agree.
>
> Here's some brainstorming. Instead of waiting for the grand-unified
> automated maintainer script solution (which would take about a year to
> complete, assuming we can agree on the design), why not do the
> following:
>
> Define two types of machines:
>
> * OS server; it is a special server that just serves up via NFS the
> disk for the clients
Sounds interesting but I wouldn't be stuck with NFS specifically
I am really anxious to try CODA filesystems and leave NFS behind :)
> * clients: either diskless, or dataless (that would take some work; I
> don't think linux has a cache only filesystem yet, shame -- well you
> could have a local /tmp)
Yes local /tmp... and /etc /bin /boot /var (of course unless its diskless)
Unless it is NFS-root or some other diskles boot, then it will need
these to boot.
> On the OS server, you have your actual Debian installation, and then
> you have the "exported installation". This is dpkg, which has
> operated on a chrooted environment. Complete with kernel, var, all
> that. Let's call the exported installation "export"
>
> clients mount "export" via dhcp/bootp/tftp or what have you
>
> clients have a locked down /var/lib/dpkg in such a way that dpkg
> refuses to install/remove/configure anything when run from the clients
>
> Once we've gotten this far we've solved the baseline requirement, but
> it might be too restrictive that /etc is the same for all these boxes;
> work out a way to overlay on /etc a la the nfsroot package....
>
> All maintenance of the export system is done via dpkg on the OS server
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 other problem here is that you have no way of reconfiguring the
> clients during upgrade -- hmm! That would be a little tricky. At
> worst, you take down all the clients for system maintenance. At best,
> you could work out a way to shove maintainer scripts execution out to
> the clients...
>
> What do you think? I've never tried to run dpkg in a chroot
> environment, but I don't see why it wouldn't work. And with minimal
> hacks required to dpkg.
dpkg works great in a chroot environment. In fact if you untar the
base tgz, then you have a fully working Debian system...you can chroot
and run a shell...use dpkg...it works great (I used it to make diskless
XTerminals)
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...
-Steve
--
/* -- Stephen Carpenter <sjc@delphi.com> --- <sjc@debian.org>------------ */
"People who live in glass houses shouldn't throw orgies"
--The Mahareeshi Hashish Yogi
Reply to: