Richard Basch sez:
> operation. Unfortunately, it is hard to do all the checks since at any
> time, one group may be added to another, and it is hard to tell if the
> group you are including does not already have <n> groups (or even worse
> <n-1> and the list you are adding it to is a member of some other
> group).
If I am a ptserver, I know all the groups of which another group is a
member AND all the groups which are members of it. I need merely to
recursively search: in the "up" direction, I will eventually find a
group which is not a member of any other groups; in the "down"
direction, I will find groups made up entirely of users (or empty). If
the admin has imposed a maxgoglevel, then the test fails as soon as I
find maxgoglevel+1 levels, and I disallow the addmem. Is that hard?
Again, I don't know the code, and if Richard tells me that won't work
in the current implementation or something very similar to it, I have
to believe him. I simply comment that I can see no reason why it shouldn't.
Pierrete sez:
> But I had 15000 users and 3000 new ones each semester. Sometimes you feel
> lucky if you can get them to understand what klog does.
> Not contrived. I was the Sys Admin for AFS at CMU for 5 years and
> when we gave the users "the rope with which to hang themselves" - they
> did. It becomes tiring to bail the "not-so-clever" people out of
> these little crisises - we had better things to do with our time. It
Sure. We're about 10 times smaller, but have the same problems. But
most people understand the concept of file ownership and the risks of
giving access to others - ownership of a group is unlikely to be a
different problem if introduced at the start.
I don't claim that people won't hang themselves, simply that the
problem will not be significantly worse than at present, and that
denying the rest of the world a useful facility is not the correct
answer. There are many ways to shoot ones one own foot on any system,
and a new one doesn't make things much worse. Most of the time people
don't shoot their feet, because they've been told about the problems in
advance (no need to know the details, just that they should proceed
with caution), or because the system warns them if they're about to do
something silly, and lets them opt out.
Face it - most users use <2% of the facilities available to them. A few
may understand ACLs and groups; fewer still use actually use them. If
Richard says MIT have no problem, I believe him.
Pierette also says:
> Agreed. But coding in the ability for each administrator to customer
> configure their AFS software would be a very time consuming task,
> would make the system more complicated to install, configure and
> administer, and must be weighed against the other fixes/features that
> are needed/requested. Remember, groups within groups is only one tiny
> corner of the system. If time is spent on an effort for super custom
> configuration, do you really want it spent on this corner of AFS?
set gripe +flame
NO NO NO NO!!! This is a typical knee-jerk reaction when I express this
belief - "Pity the poor tyro sysadmin having to learn and install this
stuff - oh and it's such hard work for us to do". RUBBISH.
set gripe -flame
You - the s/w supplier - need only deliver the system in a working
configuration where the defaults are such that the system behaves as it
has always done (or in a rational default way). Then, after the
sysadmin has gained experience and when the facility will become useful
to him you allow him to switch it on - or off if it was on by default.
I see no problem about any controls I have just described being completely dynamic.
The "difficulty" argument is equally wrong. No packages like AFS, or
even just ptserver are fully functional from scratch - facilities are
added on as demands state. If your software is designed sanely, it
should be entirely possible to switch new functionality on and off -
you effectively just reduce it to a previous version.
Don't take this gripe personally; Transarc is vastly better than most
in this respect :-). But please, do accept that arguments like "We
can't add this because it cause this problem for some sites" are based
entirely on an assumption that a) the facility in question will NOT be
under the sysadmin's control and b) the default behaviour will be
change from the previous version. They're only true if the s/w supplier
makes them true; which leaves them in no position to base an argument on them.
Peter Lister [EMAIL PROTECTED]
Computer Centre,
Cranfield Institute of Technology, Voice: +44 234 754200 ext 2828
Cranfield, Bedfordshire MK43 0AL England Fax: +44 234 750875
