On Friday, 23. April 2004 14:49, Ivan Popov wrote:
> Hello Michael,
>
Sorry for taking so much of your time Ivan, but it helps me a lot to 
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...)?

> > Well - I think one point needs to be discussed here: What do we accept to
> > be configured "statically" in the config-files:
>
> do you mean on the client? Then the answer is clear - nothing.
> Coda is global and you never know which Coda realms are going to be
> contacted from some client.
Ok, I understood that coda will be "clever" :-) enough to get proper defaults, 
everything else is the user's responsibilty, which I think is fine (at least 
for the site I am operating).

[...]
>
> > my talking - _how to determine the default_ ? People probably don't know
> > where they got (to stick to the example) their kerberos-tgt from, may it
> > be andrew.cmu.edu or cs.cmu.edu - doing more behind the scenes might help
> > a lot,
>
> All that Kerberos cached credentials stuff is not so interesting for Coda
> as default tgts live for say 10 hours, but tokens live for 25.
> With other words we cache it longer that Kerberos usually does.
> In the current "new" code I do not use tgts at all -
> it is rather straightforward to add if somebody would feel the necessity.
What does that mean - "you do not use tgts at all"? Please explain how the 
following example would work (regarding coda): Let X be a user, sometimes 
working on computers authenticating against Kerberos ANDREW.CMU.EDU, on other 
days he works on some different machines that authenticate against 
CS.CMU.EDU, his home-directory is stored on some coda-server, reachable from 
both machines. How is it possible, that X gets a coda-token *on login*, such 
as his home is writeable immediately?

[...]
>
> > What about using nsswitch on the auth2-server-side? This would provide a
> > generic interface for user-management (and you are still independet of
> > any existing passwd etc. (I would love to have an entry like "coda: files
> > ldap"...)
>
> What do you mean by "generic interface for user management"?
> Coda identities management has little in common with
> account management of a Unix system.
Sorry for my bad english, that was not what I actually was wanting to talk 
about. Actually I meant "a generic interface to user databases" - and this 
information is probably a lot more similar to unix' account management: Some 
kind of database storing information about objects. This would allow 
something like "files", which would mean some coda-specific file(database) 
that stores information (probably the admin data), furthermore something like 
"ldap" or "mysql" and a configuration file specifying the keys to look for 
(e.g. ldap: (&(objectClass=coda)(id=user/auth2@<CODA.REALM>)) )
>
> 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...
>  - which programs would use it?
The auth2-daemon
>  - through which API?
I think (_I have not checked that_) libnss should do it all, it might need 
some patches...

> The only thing Coda is dependent on is a list of groups,
> while a group can contain other groups or identities.
> This database is nice to be able to read from somewhere,
> but I doubt nsswitch is in any way a suitable tool.

> [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???

> Nsswitch is an interface between existing API like getpw*()
> and arbitrary carriers of the corresponding information.
> It means that the different libnss_* modules have knowledge about
> the APIs they implement. So no "coda: files nis ldap"
> would be possible until we rewrite all of the corresponding service modules
> so that they know about "coda: " lookup functions.
>
> Then why would we bother replacing the standard libraries with our extended
> ones? Even if we want different backends for our database(s), we would just
> write them and use, without pretending to force them into an existing
> standard (libnss_* APIs) - just to be able to share the configuration file
> with other totally independent services?!
I just thought it would be easier to use something like nsswitch for 
connecting to the backend, since I wouldn't know ldap and the like are usable 
yet with coda. 

> nsswitch has some sence when _one_ API is using _several_ databases
> and then you have _one_ place to configure where it picks them.
Isn't that possible with coda? That was just the point why a got to 
nsswitch...

> SUN once made a choice of putting _several_ APIs into the same config file
> and into each of libnss_* libraries - let us avoid doing that mistake
> again.
Didn't mean doing that, thought of the above approach...

> May be you meant "passwd: coda files nis ..." ?
No! Of course:
> Then - no way, again. Coda has no notion of a Unix account and hence
> its identity information can not be expressed in terms of a passwd entry.
> Even if you want to map/fake the information, it is the internal business
> of a Unix system administration, in which way to do that mapping,
> and from which Coda realms.
> Rather you'd want it vice versa, populate a Coda realm with identities for
> most of some Unix system's accounts - but it's another story, where passwd
> and group databases can be of help - but most probably still not the same
> as Coda groups and identities.
>
[...]
>
> > But how can a coda-client/server get information, e.g. wheter it is using
> > ssl or not (even worse: ipsec...)
>
> The server advertises which authentication methods with which parameters
> can be used (and usually exactly one per authentication authority, easy
> for the client to make a choice :)
What does "advertise" mean here? Is it answering questions or active 
advertising (I hate broadcasts...)? Does that furthermore mean, that the 
server has configuration files, that contain information about that - or is 
there autodetection planned too???

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 
machine too? Of course this needs a lot more thinking about locking and the 
like, but it would allow being really failsafe...

Best regards,
Michael