[OpenAFS] Ldap & AFS
Leif Johansson
leifj@it.su.se
Mon, 14 Oct 2002 11:34:09 +0200
Derrick J Brashear wrote:
> On Fri, 11 Oct 2002, Tim C. wrote:
>
<snip>
> i argued before and do still that it's not that simple, because the
> ptserver is optimized to be used by the fileserver, particularly the CPS
> operations, so unless you're very careful how you do this, you'll be sad.
>
This is an important point. However having worked with ldap for some
time my opinion is that most of the arguments below are the result of
misinformation. LDAP is neither complex or unstable or slow.
I have seen these claims often enough and they quite often stem from
bad experiences with particular deployments. It may well be that pts
is a special case when redirection to an external service is not a
good idea. I confess that I don't know enough about pts to tell. I
do know that based on the milko pts code it would be relatively easy
to implement a generic backend-structure and an ldap backend. Whether
the end-result would be good/better/good enough is another story.
Personally I believe that pts together with nss_ldap are two of the
applications which requires finished udp support in ldap to really
make it work well. Unless you have this your biggest implementation
issue will be connection management.
> i will confess to not having looked terribly hard at the effort needed to
> do it, because i find ldap to be unnecessarily complex, and because i find
> that it's just not easier to take a system that isn't simple (afs) and
> involve in it a system which is more complicated and as it seems to me,
> less stable (openldap as deployed at carnegie mellon). i may be being
> unfair, or we may just have bad luck.
<see above>
> my opinion is that something which uses pt_util, ptclient, or some
> combination of tools to manage the ptserver database based on operations
> to the ldap server would be less painful than a ptserver ldap backend, but
> again, my opinion.
>
I disagree. Most organizations who deploy ldap these days do it because
of the large-scale management benefits. Again, having said that I tend
to prefer disconnected publishing of data from my ldap-server (i.e I
prefer building /etc/passwd to using nss_ldap). The reason for that may
on the other hand be just as much based on the genetic conservative
outlook of a long-time sysadmin as Dereks distrust of ldap :-) Who
can tell!
> how you run your systems is your business, so i'm not going to tell you
> "you're wrong". if someone writes the necessary support it will 99.9%
> likely be integrated, basically as long as it doesn't break non-ldap-pts
> people
Whomever gets into this (imho) needs to build a backend-layer into pts
which allows for multiple independent backends. You probably need name-
spaces to separate foo-groups from pts groups (you don't need to worry
about two system:administrators for instance). You probably need to
assume that the backend services are under the same administrative
control as the pts-server to make your security analysis easier. And
you need to do very smart connection management to your backend
services.
Cheers leifj