Mostly I'm quiet when it comes to messages like this, but
I don't think I agree with much of what is being said
by Herber...
"No! AFS runs in a AFS environment.
The UNIX operating system is a support environment for AFS;
not the converse."
I don't think so. In fact, most of the traditional tools
work just fine, and the servers have to bend over backwards
trying to deal with old silly semantics (non distributed
file system semantics). For example, even if you can't write
the file, if it was just creat'd, and you did the creat,
then you can write the file....
I think it was real nice that AFS appeared with Unix, cause
otherwise we would have had to scrap Unix's over time,
cause it wasn't dealing well with the distributed file
systems... I would likely have a novell/banyan file server.
"When I can not run set-uid and set-gid programs in the form they
were developed, I feel something is broke."
Big mistake here. Most admins curse the set-uid patent.
Most system programmers will never admit to writing a
good set-uid program. Given the most recent troubles
with rdist, I doub't any truly correct set-uid programs can
be written.
BTW: what exactly do you mean by suid in a network?
does the suid pass through the network? So that some other
czech-admined process-oriented NFS server could deliver
to you a suid program, and you want it to run as root?
What about suid on non root, when you can't get
a congruent uid image? (ie: who's uid so and so,
cause that's a local administration issue)
It was with great relief that AFS provides little meaning for
root. This was among the first great victories.
"When I can not run programs without making them also readable,
I feel something is broke."
In a distributed file system sense, if you can execute the file,
you've read the file. I can always grunge around in my cache
to collect a file read from the server.
An alternative is to encrypt the data for an executable under
a session key established for the duration of the connection,
based on some principle (the machine I'd assume); but
even if I could live with the key distribution problems,
broken (fixed-in-the-right-way) kernels would still allow me
to save the executable images, since the machine can't
run encrypted data streams.
"I feel that the fact that ``quite a bit of user retraining''
is required shows that something is broke."
We've got this neat project called 'disconnect AFS' which
solves lots of troublesome AFS issues, and causes new ones...
The net benefit is positive, but it requires understanding
more of what is going on. I believe (as other do), that
some of the users will be willing to deal with the
additional things they need to learn...like reconcilitaion...
"When AFS or its successor is as transparent to the user as
NFS is, then it will be repaired."
I'm surprised about this comparision. Ever get a 'Network timed out' error
while writing an NFS file via 'vi'? I wouldn't consider that
transparent....
Or how about a 'pwd' from NFS while using the automounter. What's
that path name mean? Or other interesting NFS behaviors, like
'what's that extra file in my directory when I unlink files?'
Or how about 'ls -l', and getting wild owners...
mts.
I figured a NON transarc person ought to defend AFS.
