Hello Michael,

I think there is a lot of misconceptions around filesystems,
authentication and authorization and so on.
Good that we can discuss that - but I feel I am talking a way too much.
So trying to be concise and apologies if you will feel something is ignored.
It is not meant.

On Sat, Apr 24, 2004 at 06:03:00PM +0200, Michael Tautschnig wrote:

> understand what is/will be possible... One question before: When will all of 
> that be available or could you be helped in any way (to get there faster...)?

As there were no [negative] reaction from Jan or Satya,
I hope the code will be accepted into the mainstream -
but it has undergone just a limited testing, and it is quite different,
so be patient.
I am working (in the very limited spare time) integrating
Mark Phalan's gssapi patches into the new code, and I do not think it is
possible to share the load - except if a bit later somebody can add all
the necessary autoconf stuff which I do not touch.

> What does that mean - "you do not use tgts at all"? Please explain how the 

Exactly as it says. You need to supply a password to get a token.
It can be a suitable (unwritten yet) pam module doing it transparently
at login, but anyway it will have _nothing_ to do with which Kerberos realm(s)
are in the client's /etc/krb5.conf, or which file contains the user's
tgt for which realms, nothing of that is used.
So the client administrator does not have to bother "configuring
Kerberos for Coda's sake."

clog uses Kerberos wire protocols, takes a password, gives a token,
nothing else. Again, no "Kerberos client host configuration" is relevant.
Period.

> > Would you make it clear
> >  - which database are you going to make available through NSS?
> I think, ldap, files, nis, mysql, postgres would make sense...

you're talking about the carrier of the database, i asked about the contents.
never mind.

> > [note, in general a Coda realm does not need a database over
> > identities! It is groups and acls who decide which identities
> > are usable]
> But where are they stored???

Acls are stored in RVM, together with other metainformation about the volumes
and directories. They are read-write from the server point of view.

Groups are stored in the realm database, in a local file on each server,
in an efficient disk format and with a nice API, reimplemented by Jan.
That file is automagicaly synchronised between all servers.

That database is readonly for the server purposes and can be easily abstracted
enough to have a different back-end. On the other side, the back-end must
be of a "suitable quality", being very fast at read/search, very reliable
and distributed. There are not many backends capable of that.
I was going to implement DCE-backend which would be a "right one" but
DCE is being phased out at Chalmers, so it is not going to happen.

The popular LDAP is distributed, can be setup to be rather reliable,
and I think Jan mentioned that there was a project of implementing LDAP
backend for CODA database but at that time LDAP was not up to the task.
May happen later.

An API present in libnss like getgr*() _could_ be used but given
that it refers to the local Unix system group information, in general
very different from what a Coda realm needs, and that most of backends
are not either efficient or reliable or distributed, there would be
little sense in doing that.

IMHO use any backend you like and populate the Coda database once
in a while - is a reasonable way to go.

To make it clear - right now Coda is using the internal database for more
puposes than mentioned above:
 - it maps string identities' and groups' names to numbers which are used
   in the acls instead of the strings
Possibly it will continue to do so. Nevertheless, those numbers are
the internal business of the servers and should not be seen as anything
like Unix uid. They are just implementation decision. These numbers are
not useful outside of the server.

The fact that Venus does leak those numbers is very confusing as e.g. "ls"
interprets them like uid and makes the system administrator believe
that they should/could synchronise Coda internal identities numbers
with the client systems ones... Pitiable. It is not possible by definition,
not by someone's mistake or bad will.

> What does "advertise" mean here? Is it answering questions or active 
> advertising (I hate broadcasts...)? Does that furthermore mean, that the 

The client discovers via dns where to ask , and then _asks_ - and gets
the full list of options, that list I call an "advertisement".

> server has configuration files, that contain information about that - or is 
> there autodetection planned too???

Hmm, there could be no "autodetection" :) as those options and policies
are a conscious choice of the Coda realm administrator. Nobody else can
do that job. Yes, the server has to have a configuration file to be
presented to the asking clients.

> There is another point that seems not that perfect yet: Are there any plans to 
> have/allow multiple SCMs or will the evolving system be based on a single 

I am afraid you miss a point here.
An SCM is just a point to make changes in the databases, shared between
Coda servers of the same realm.
It is the group/identities database and the volume location database.

Is it really a crucial activity to create-delete-modify volumes and groups?
Then you just need a mechanism to automatically choose a new SCM in case
the current one becomes unavailable. There should be exactly one point
of update...
Otherwise you would need to build another level of optimistic
replication and conflict detection (and you do not want a conflict
on the vital database :)

No file access activity depends on SCM being available,
neither has SCM to host a Coda file server. It is just a host with
the master copy of the databases and the database distribution daemon.

Cheers,
--
Ivan