At 10:49 AM 5/28/01 -0500, James G Smith wrote:
>Gunther Birznieks <[EMAIL PROTECTED]> wrote:
> >At 02:31 AM 5/25/01 -0400, Chip Turner wrote:
> >>Gunther Birznieks <[EMAIL PROTECTED]> writes:
> >>
> >> > However, I think it is reasonable to make the interface to support a
> >> > data source for the widgets flexible and object based to make it easy
> >> > for someone to write a DBI source, a DBM source, an LDAP source, an
> >> > Apache::Session source or whatever anyone wants really. I happen to
> >> > think DBI and Session sources are cool.
> >>
> >>I agree; unfortunately writing classes to interface to all of these
> >>would be difficult, and it would be difficult to be futureproof. When
> >>you hit LDAP and DBI you must then worry about databases, tables,
> >>servers, usernames, passwords, etc. It can become cumbersome to do
> >>the simple things.
> >
> >I disagree. I've written interfaces like this before to LDAP and DBI. The
> >constructor (or config method) on a data source is stuff like usernames/
> >passwords, and in the case of LDAP, schema mappings.
>
>Hmm... Something I'd like to see is a set of classes in Perl for managing
>LDAP. These classes would need to be generic (configurable) enough to work
>with any LDAP schema. They would need to provide an audit trail, transaction
>log, etc., that could be used to replay changes made to LDAP. They would
>need
>to be able to enforce data consistancy across branches and data
>integrity. If
>noone gets to it before I do, I'll port my PHP code to Perl :)
I guess it depends on what you store in LDAP. I find that LDAP is useful
for simple data structures but it can be much nicer to also have the data
in a relational database for most applications to access things in one query.
I think I would like to see a public domain LDAP management console. This
is really what you are talking about right? One of my coworkers wrote one
in Perl back at Barclays Capital several years ago but he never bothered to
open source it. I suspect there are a ton of places like that which custom
design something like this and then never open source it due to laziness.
>Oh, and locking mechanisms used must be transferable between machines -- I
>lock resource A on machine X and then hand off the lock to machine Y -- this
>code must be useful in a distributed environment (web farm) and robust enough
>for use in a PKI.
I guess I don't understand. The locking bit sounds slightly odd to me.
Wouldn't it be easier to administrate a master LDAP server and have a push
model of replication?
I am not sure what you mean by robust being a prerequisite for
PKI? Passwords are passwords -- just that certificates are larger and the
SSL protocol has already decoded it for you.
In fact, certificates can be easier depending on how you deal with it. If
you just look up a Cert Revocation List then you can take the SSL decoded
cert to be whom the user says she is without doing an LDAP lookup. Then
LDAP is only used for user attributes and it has less to do with PKI.
You only need to really store the certs in LDAP if you are talking about a
certificate management system. And then that system should be protected
anyway (the PKI management system) and probably won't need to be clustered
as an app.
Of course, perhaps you use it differently than I am thinking of LDAP and PKI.
