www-infrastructure-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: LDAP - Next Steps
Date Wed, 27 May 2009 20:35:56 GMT
On 27/05/2009, chris <chris@ia.gov> wrote:
> -----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.

OK, fine, I thought it was still an issue.

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

Again, this was only a suggestion as a way to get round the overhead
of overlay, but if you need that anyway ...

>  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.

See above.

>  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.
>

See above.

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