Re: Mounting /usr over the network
Nick Cabatoff <firstname.lastname@example.org> writes:
> On Oct 29, Falk Hueffner wrote:
> > I'm working at a university, and they are pondering to use a single
> > linux distributon in the future. They're currently trying Red Hat, but
> > have not decided yet. I suggested Debian, of course :)
> > The main consideration is that to save administration efforts and disk
> > space, all non-essential packages should be on a AFS server. No
> > distribution does support this directly AFAIK.
> > There are different ways to achieve this. One could simply install the
> > packages on the server and export /usr, since many packages don't need
> > files in other directories. The problem is /etc; some packages need
> > files there, but /etc can't be mounted remotely, since there are host
> > specific things in there.
> You could get around this by only installing in /etc the files needed
> to boot the system: inittab, passwd, etc. As part of the boot
> process, once /usr (and presumably /var/lib) is mounted, run cfengine
> to symlink in all of the non-host-specific files, and to update any of
> the files stored locally as needed.
That's a good idea. I guess I'll have a closer look at cfengine.
> Is this really what you want to do though? I mean, aren't you going
> to pay a pretty heavy speed penalty if everything is coming over the
Well, the network's pretty fast here, and you can set up huge AFS
caches (~1 gig perhaps), so netscape etc. would always come from the
> Why not compromise somehow... it's not like disks < 2GB can be found
> nowadays anyway. You could create a basic installation using say,
> 500MB on the clients, and then make available via AFS monsters like
> GIMP, tetex, GNOME, etc. This would still require work, of course,
> both to set up something to keep the clients in sync and to enable
> them to use the networked packages despite dpkg's lack of support
> for nonstandard paths. But cfengine could still do the job IMO, and
> this approach would probably result in much more useable machines
> and a less congested network.
We agreed here that at least some packages should be exported, so I
think to reduce effort as many as possible should be exported. If we
find out that some are too slow, we can install them locally later. So
I guess we will at first only install "base" locally.
Thanks for your comments.