[Infrastructures] how to build an internal (local) filestructure?

[Ivan Popov]

Hi Steve,

On Thu, Mar 31, 2005 at 12:49:11PM -0800, Steve Traugott wrote:
> This must be the week for the list founders to get pummelled.  ;-)

ouch, I didn't mean that!

> right, for the right reasons, and others can learn a great deal from
> what you're doing.  That's why I mentioned you as an exception case.  I

Thanks.

> of thought into this.  (Building on the Gnome example from the FAQ,
> imagine a world in which the head of a client business unit is a
> physicist-turned-trader who's living on coffee, can't hold a

[a nice and trustworthy example]

Well, I mentioned Gnome to show that its design is "somewhat" faulty
and that such limitations are totally arbitrary, due to the designers
which sacrificed flexibility.

It is no problem in itself to put and use Gnome on Konvalo -
it is just that it will be more expensive in the maintenance than otherwise.

You will be unable to upgrade one library and test if it works - you will have
to compile another instance of the whole Gnome to be able to use a different
set of libraries. When you add a program, you add it to a certain
instance of Gnome and cannot use with other instances...

> year in salary plus bonus.  For some insane reason he can't live without
> Gnome, so you *have* to make it work, and keep it up to date with the
> latest bells and whistles with every release, or he's going to go find

No problem, but such a customer would have to pay a bit more than others :-)

>   http://www.usenix.org/publications/library/proceedings/lisa95/gittler.html
> 
> I can testify that Aurora works.  Ivan, Xev's paper also provides a good
> description of the sort of "mission-critical" we've been talking about

Sure. Thanks for the link, it is an exciting reading.

> My cautions are aimed at cases where shops are *not* willing to deploy
> AFS, Coda, or a globally consistent NFS/amd tree, they *don't* have 1800

One important difference Coda makes in that context is that it is almost
"as hard" to deploy on the client side as say ext3 or ufs.
(no customer says "we do not want to deploy ufs", or do they?)

A Coda client does not "belong" to a certain cell, it does not depend on
custom mounts like Aurora does with AFS. It can authenticate the users
against arbitrary Coda realms, without dependency on which Kerberos version
is present on that particular client.

Still, I understand you meant the server side as well. It is not as trivial.

> applications, they *don't* have, or want to have, enough skilled people
> or political will to sustain the upkeep effort forever, they *don't*
> have a good network, and they *don't* want to rely on an external third
> party for file and application service.  The worst case I've experienced

If all they have or accept is *no* then of course they will be prepared
to pay a lot of money to get the job done. Then a global file system
may be unnecessary. Develop a unique system which fits their current needs
and come back in a year - they will find they need more and will be ready
to pay again :)

> personally is the one I described in my previous message, in which the

Agreed, it is terrifying when you see skills and resources wasted by applying
in a wrong way...

> There is another hard problem here that doesn't get talked about enough;
> what is the right thing to do for perimeter and DMZ machines, bastion
> hosts, firewalls?

I have no certain point of view there. As they tend to be relatively few,
it is often manual maintainance with temporary tools.

> Ivan, do you have any way of managing the Coda client, kernel, and other
> bits which are still on local disk?  I get the impression from

I had a procedure for setting up new "bare bones" hosts,
which run almost all daemons (excluding init and Coda cache manager)
from a global file system and essentially all they need locally is
a certificate to ensure the file servers are the authentic ones.
It worked fine.

Nevertheless, I have consciously put it aside and instead use various
occasional installation methods - as they are relatively cheap.
I want to prove the point about separating host setup from software setup.

At work I am running KickStart-ed Red Hat workstations (and for myself
just ignore all software kickstart installs), my main workstation is a
bare-bones Debian (which gives me networking, local password hash for
authentication and that's all), at home just for curiosity I run the same
environment on an out-of-the-box FreeBSD installation.
(which provides a kernel with an almost full Linux ABI and a bourne /bin/sh)

> konvalo.org that right now you state the minimum requirements for local
> disk content, and it's up to the user to manage that however they see
> fit.  Have you worked out any ways for doing it for your own machines,
> and how would you scale up?

I happen to develop such solution right now for Chalmers, while
it is not at all Konvalo-related. It is based on our own previous work
here at Chalmers and heavily inspired by your "Turing" article about
congruent management. It happens also to rely on a global filesystem view.

Such or another solution could be easily applied to the modest needs
of "konvalo-workplaces".

Regards,
--
Ivan