www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chris <ch...@ia.gov>
Subject Re: LDAP - Next Steps
Date Wed, 27 May 2009 20:14:38 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 > If you are still concerned about the overhead of ldap overlays, then
> why not supplement the web-trigger with a cron job that runs a few
> times a day?

No extra overhead here as Tony was already using the same overlay for replication.  I'm using
a simple perl script to
act as another consumer (replication partner) and watch for changes to the groups db.

> 
> I don't know how likely it is that ldap group changes will be made
> other than by the web application, but it should be possible to set up
> a script that can trigger the svn authz rebuild, and this can used by
> humans or scripts.
> 

Sure if others think this is the best way to go, it could work as you have suggested.  I suppose
I should ask what you
see as the pros/cons of doing it as a trigger from the web app + manual trigger  vs. doing
it automatically on any
change to relevant ldap groups?

My big pro for making it watch LDAP is that it should always keep things in order no matter
how LDAP is altered.  Second
pro is it uses a proven method of monitoring changes that is already in use for replication
and is very simple in it's
logic.  The script can always be run manually if you need instant results and the same code
is used in the post-commit
hook to the rebuild when the template is changed in svn.

Having to rely on someone to manually trigger the update of authz as a result of a ldap change
made by other means than
the web app is a con.  Relying on humans for anything is a big con. Why make something manual
when it can be easily
automated?  Also, it slightly complicates the web application.

You're much more wired in than me, so please fill in the gaps in my very limited pros/cons.
I'm sure there's arguments
for doing this via the web application that I am missing as well as arguments against the
automation of it.

>>
>> My lack of current practices may bite me here.  Are you asking if the application
will check the Committers groups
>>  before allowing a member to be added to any other group?
> 
> Yes, that is one of my questions.

Certainly doable if deemed needed.  I'll wait for more direction on this validation before
I add it in.

I'll have to let Tony address the rest of your comments/questions.

Thank you for the continued feedback/insight Sebb!

crr/arreyder




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkodny4ACgkQPmaZdRmQd+ZWwQCfexhxJpa32wh0pioTIW4XlEgH
qnsAn1BeMz5PLPZUOSi1KEGkZnSe7aIR
=7fvj
-----END PGP SIGNATURE-----

Mime
View raw message