You are viewing a plain text version of this content. The canonical link for it is here.
Posted to infrastructure-dev@apache.org by Tony Stevenson <to...@pc-tony.com> on 2009/05/26 17:29:00 UTC
LDAP - Next Steps
Folks,
Now that we can look to move LDAP on a little more, I have a question
that I'd appreciate some feedback on.
As you know, at the moment the SVN Authz file is in Subversion, when
we move groups into LDAP, this will no longer be the case.
The SVN authz file will be dynamically rebuilt after every change to a
group (or the template that creates the Authz file).
To achieve this we have 2 options:
1) Use OpenLDAP's 'accesslog overlay' to record all changes to the
database.
2) Use a custom script that polls the groups and when it notices a
change, it will force a rebuild.
Now each of these has it's ups and downs. 1 for example logs all
changes, and could be used as an audit log, but it produces shit loads
of output. 2 on the other hand means that the rebuild wont be
triggered as quickly, and it will rely on upon building a reliable
checkpoint from the previous poll to generate a diff, and ultimately a
kick of the build of a new SVN Authz file.
Of course there is always a 3rd hidden option, and that is to do away
with using the SVN Authz file completely, and use <location> stanza's
in httpd, and use mod_authz_ldap to control access this way. Based on
some of my very simple testing, this option provides a slightly faster
turn around in changes, but it would require someone with root
privileges on eris/harmonia to be able to add new location tags, and
add new groups to an existing one.
At the moment I think I am leaning to option 1, for the accesslog
overlay. But in my heart I would love us to use option 3, albeit this
may mean a little more work for us.
Thoughts?
Cheers,
Tony
--------------------------------------------
Tony Stevenson
tony@pc-tony.com - pctony@apache.org
pctony@freenode.net - tony@caret.cam.ac.uk
http://blog.pc-tony.com
1024D/51047D66 ECAF DC55 C608 5E82 0B5E
3359 C9C7 924E 5104 7D66
--------------------------------------------
Re: LDAP - Next Steps
Posted by Emmanuel Lécharny <el...@apache.org>.
Norman Maurer wrote:
> Hi Emmanuel,
>
> I would be really interested to have a look at the source code of that
> "nifty" app. Could you provide a link to the svn path?
>
Sure !
http://svn.apache.org/repos/asf/directory/apacheds/branches/apacheds-replication/syncrepl
It contains some GUI to launch a server (ADS) which is updated with data
received from an OpenLDAP server. It's a preliminary work, but it works.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: LDAP - Next Steps
Posted by Norman Maurer <no...@apache.org>.
Hi Emmanuel,
I would be really interested to have a look at the source code of that
"nifty" app. Could you provide a link to the svn path?
Thx,
Norman
2009/5/26 chris <ch...@ia.gov>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Emmanuel Lécharny wrote:
>> Tony Stevenson wrote:
>>> Emmanuel,
>>>
>>> Can you give us some more detailed information? i.e. how would we
>>> implement this, how would we ensure no chnages are missed?
>> OpenLDAP's replication is based on Syncrepl, described in RFC 4530. We
>> have implemented the first part of the protocol, ie the client to
>> server. Atm, it's a standalone piece of code, which register on a given
>> DN for a refresh-and-persist syncrepl operation. We then get every
>> modifications (ie, addition, modification and removal) done on OpenLDAP.
>>>
>
>
> This sounds very similar to what I have been working on using syncrepl and looking at the contextCSN attrib. I'd like
> to continue down this path. It's pretty simple since we do not need every modification, we only need to know that
> something has changed.
>
>
> crr/arreyder
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAkocQzkACgkQPmaZdRmQd+bjcgCgh/GiToJfSSGHhQep/xP/3tTT
> QHsAnj66YGGgmArHpcJ0/W6wE7vowhku
> =BdQT
> -----END PGP SIGNATURE-----
>
Re: LDAP - Next Steps
Posted by chris <ch...@ia.gov>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Emmanuel Lécharny wrote:
> Tony Stevenson wrote:
>> Emmanuel,
>>
>> Can you give us some more detailed information? i.e. how would we
>> implement this, how would we ensure no chnages are missed?
> OpenLDAP's replication is based on Syncrepl, described in RFC 4530. We
> have implemented the first part of the protocol, ie the client to
> server. Atm, it's a standalone piece of code, which register on a given
> DN for a refresh-and-persist syncrepl operation. We then get every
> modifications (ie, addition, modification and removal) done on OpenLDAP.
>>
This sounds very similar to what I have been working on using syncrepl and looking at the contextCSN attrib. I'd like
to continue down this path. It's pretty simple since we do not need every modification, we only need to know that
something has changed.
crr/arreyder
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkocQzkACgkQPmaZdRmQd+bjcgCgh/GiToJfSSGHhQep/xP/3tTT
QHsAnj66YGGgmArHpcJ0/W6wE7vowhku
=BdQT
-----END PGP SIGNATURE-----
Re: LDAP - Next Steps
Posted by Emmanuel Lécharny <el...@apache.org>.
Tony Stevenson wrote:
> Emmanuel,
>
> Can you give us some more detailed information? i.e. how would we
> implement this, how would we ensure no chnages are missed?
OpenLDAP's replication is based on Syncrepl, described in RFC 4530. We
have implemented the first part of the protocol, ie the client to
server. Atm, it's a standalone piece of code, which register on a given
DN for a refresh-and-persist syncrepl operation. We then get every
modifications (ie, addition, modification and removal) done on OpenLDAP.
>
> I assume this means setting up an ADS LDAP Server, which has this
> option enabled.
Not necessarily in a first step. It will be a standalone application.
> Replicating from OpenLDAP to ADS to then kick off the replication?
That's another step... Give us 4 more months ;)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: LDAP - Next Steps
Posted by Tony Stevenson <to...@pc-tony.com>.
Emmanuel,
Can you give us some more detailed information? i.e. how would we
implement this, how would we ensure no chnages are missed?
I assume this means setting up an ADS LDAP Server, which has this
option enabled. Replicating from OpenLDAP to ADS to then kick off the
replication?
Cheers,
Tony
On 26 May 2009, at 16:45, Emmanuel Lécharny wrote:
> Tony Stevenson wrote:
>> Folks,
>>
>> Now that we can look to move LDAP on a little more, I have a
>> question that I'd appreciate some feedback on.
>>
>> As you know, at the moment the SVN Authz file is in Subversion,
>> when we move groups into LDAP, this will no longer be the case.
>> The SVN authz file will be dynamically rebuilt after every change
>> to a group (or the template that creates the Authz file).
>>
>> To achieve this we have 2 options:
>>
>> 1) Use OpenLDAP's 'accesslog overlay' to record all changes to
>> the database.
>> 2) Use a custom script that polls the groups and when it notices a
>> change, it will force a rebuild.
>>
>> Now each of these has it's ups and downs. 1 for example logs all
>> changes, and could be used as an audit log, but it produces shit
>> loads of output. 2 on the other hand means that the rebuild wont
>> be triggered as quickly, and it will rely on upon building a
>> reliable checkpoint from the previous poll to generate a diff, and
>> ultimately a kick of the build of a new SVN Authz file.
>>
>>
>> Of course there is always a 3rd hidden option, and that is to do
>> away with using the SVN Authz file completely, and use <location>
>> stanza's in httpd, and use mod_authz_ldap to control access this
>> way. Based on some of my very simple testing, this option provides
>> a slightly faster turn around in changes, but it would require
>> someone with root privileges on eris/harmonia to be able to add new
>> location tags, and add new groups to an existing one.
> I would suggest a forth option : we have a syncrepl able java piece
> of code which can be informed from every modification done on
> openldap, which can be used to react when something has changed in
> the server, and modify the authz file immediatly. It's light, not
> too verbose, and not intrusive (no modification needed on Openldap
> configuration).
>
> That might worth the try...
>
> Just met me know.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
Cheers,
Tony
--------------------------------------------
Tony Stevenson
tony@pc-tony.com - pctony@apache.org
pctony@freenode.net - tony@caret.cam.ac.uk
http://blog.pc-tony.com
1024D/51047D66 ECAF DC55 C608 5E82 0B5E
3359 C9C7 924E 5104 7D66
--------------------------------------------
Re: LDAP - Next Steps
Posted by Emmanuel Lécharny <el...@apache.org>.
Tony Stevenson wrote:
> Folks,
>
> Now that we can look to move LDAP on a little more, I have a question
> that I'd appreciate some feedback on.
>
> As you know, at the moment the SVN Authz file is in Subversion, when
> we move groups into LDAP, this will no longer be the case.
> The SVN authz file will be dynamically rebuilt after every change to a
> group (or the template that creates the Authz file).
>
> To achieve this we have 2 options:
>
> 1) Use OpenLDAP's 'accesslog overlay' to record all changes to the
> database.
> 2) Use a custom script that polls the groups and when it notices a
> change, it will force a rebuild.
>
> Now each of these has it's ups and downs. 1 for example logs all
> changes, and could be used as an audit log, but it produces shit loads
> of output. 2 on the other hand means that the rebuild wont be
> triggered as quickly, and it will rely on upon building a reliable
> checkpoint from the previous poll to generate a diff, and ultimately a
> kick of the build of a new SVN Authz file.
>
>
> Of course there is always a 3rd hidden option, and that is to do away
> with using the SVN Authz file completely, and use <location> stanza's
> in httpd, and use mod_authz_ldap to control access this way. Based on
> some of my very simple testing, this option provides a slightly faster
> turn around in changes, but it would require someone with root
> privileges on eris/harmonia to be able to add new location tags, and
> add new groups to an existing one.
I would suggest a forth option : we have a syncrepl able java piece of
code which can be informed from every modification done on openldap,
which can be used to react when something has changed in the server, and
modify the authz file immediatly. It's light, not too verbose, and not
intrusive (no modification needed on Openldap configuration).
That might worth the try...
Just met me know.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: LDAP - Next Steps
Posted by Sander Striker <s....@striker.nl>.
On Thu, May 28, 2009 at 10:12 PM, Tony Stevenson <to...@pc-tony.com> wrote:
>
> On 27 May 2009, at 20:28, Sander Striker wrote:
>
>> On Tue, May 26, 2009 at 11:15 PM, Philip M. Gollucci
>> <pg...@p6m7g8.com> wrote:
>>>
>>> Tony Stevenson wrote:
>>>>
>>>> Of course there is always a 3rd hidden option, and that is to do away
>>>> with
>>>> using the SVN Authz file completely, and use <location> stanza's in
>>>> httpd,
>>>> and use mod_authz_ldap to control access this way. Based on some of my
>>>> very
>>>> simple testing, this option provides a slightly faster turn around in
>>>> changes, but it would require someone with root privileges on
>>>> eris/harmonia
>>>> to be able to add new location tags, and add new groups to an existing
>>>> one.
>>>
>>> Hell yes to option #3.
>>
>> Ick.
>>
>
>
> No need to ick, now. We wont be doing that.
Yeah, sorry, knee jerk reaction :)
CHeers,
Sander
> Cheers,
> Tony
>
>
> --------------------------------------------
> Tony Stevenson
>
> tony@pc-tony.com - pctony@apache.org
> pctony@freenode.net - tony@caret.cam.ac.uk
>
> http://blog.pc-tony.com
>
> 1024D/51047D66 ECAF DC55 C608 5E82 0B5E
> 3359 C9C7 924E 5104 7D66
> --------------------------------------------
>
>
>
>
>
>
Re: LDAP - Next Steps
Posted by Tony Stevenson <to...@pc-tony.com>.
On 27 May 2009, at 20:28, Sander Striker wrote:
> On Tue, May 26, 2009 at 11:15 PM, Philip M. Gollucci
> <pg...@p6m7g8.com> wrote:
>> Tony Stevenson wrote:
>>>
>>> Of course there is always a 3rd hidden option, and that is to do
>>> away with
>>> using the SVN Authz file completely, and use <location> stanza's
>>> in httpd,
>>> and use mod_authz_ldap to control access this way. Based on some
>>> of my very
>>> simple testing, this option provides a slightly faster turn around
>>> in
>>> changes, but it would require someone with root privileges on eris/
>>> harmonia
>>> to be able to add new location tags, and add new groups to an
>>> existing one.
>>
>> Hell yes to option #3.
>
> Ick.
>
No need to ick, now. We wont be doing that.
Cheers,
Tony
--------------------------------------------
Tony Stevenson
tony@pc-tony.com - pctony@apache.org
pctony@freenode.net - tony@caret.cam.ac.uk
http://blog.pc-tony.com
1024D/51047D66 ECAF DC55 C608 5E82 0B5E
3359 C9C7 924E 5104 7D66
--------------------------------------------
Re: LDAP - Next Steps
Posted by Sander Striker <s....@striker.nl>.
On Tue, May 26, 2009 at 11:15 PM, Philip M. Gollucci
<pg...@p6m7g8.com> wrote:
> Tony Stevenson wrote:
>>
>> Of course there is always a 3rd hidden option, and that is to do away with
>> using the SVN Authz file completely, and use <location> stanza's in httpd,
>> and use mod_authz_ldap to control access this way. Based on some of my very
>> simple testing, this option provides a slightly faster turn around in
>> changes, but it would require someone with root privileges on eris/harmonia
>> to be able to add new location tags, and add new groups to an existing one.
>
> Hell yes to option #3.
Ick.
Sander
> --
> ------------------------------------------------------------------------
> 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
> Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
> Consultant - P6M7G8 Inc. http://p6m7g8.net
> Senior Sys Admin - RideCharge, Inc. http://ridecharge.com
> Contractor - PositiveEnergyUSA
> http://positiveenergyusa.com
> ASF Member - Apache Software Foundation http://apache.org
> FreeBSD Committer - FreeBSD Foundation http://freebsd.org
>
> Work like you don't need the money,
> love like you'll never get hurt,
> and dance like nobody's watching.
>
Re: LDAP - Next Steps
Posted by chris <ch...@ia.gov>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>> Of course there is always a 3rd hidden option, and that is to do away
>> with using the SVN Authz file completely, and use <location> stanza's
>> in httpd, and use mod_authz_ldap to control access this way. Based on
>> some of my very simple testing, this option provides a slightly faster
>> turn around in changes, but it would require someone with root
>> privileges on eris/harmonia to be able to add new location tags, and
>> add new groups to an existing one.
> Hell yes to option #3
If you decide that you want to head in this direction, it would take very little effort to adapt the scripts that I have
written to create the authz file from ldap groups + template to the task of generating INCLUDE files with the location
stuff for httpd.
crr/arreyder.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkocYr4ACgkQPmaZdRmQd+YF2gCeMo8XB5JFar6Zih6MErG+8HwV
KIgAoId4KwSxaYpJzkFcvgv9UFm/JVDz
=6dSA
-----END PGP SIGNATURE-----
Re: LDAP - Next Steps
Posted by "Philip M. Gollucci" <pg...@p6m7g8.com>.
Tony Stevenson wrote:
> Of course there is always a 3rd hidden option, and that is to do away
> with using the SVN Authz file completely, and use <location> stanza's in
> httpd, and use mod_authz_ldap to control access this way. Based on some
> of my very simple testing, this option provides a slightly faster turn
> around in changes, but it would require someone with root privileges on
> eris/harmonia to be able to add new location tags, and add new groups to
> an existing one.
Hell yes to option #3.
--
------------------------------------------------------------------------
1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C
Philip M. Gollucci (pgollucci@p6m7g8.com) c: 703.336.9354
Consultant - P6M7G8 Inc. http://p6m7g8.net
Senior Sys Admin - RideCharge, Inc. http://ridecharge.com
Contractor - PositiveEnergyUSA http://positiveenergyusa.com
ASF Member - Apache Software Foundation http://apache.org
FreeBSD Committer - FreeBSD Foundation http://freebsd.org
Work like you don't need the money,
love like you'll never get hurt,
and dance like nobody's watching.
Re: LDAP - Next Steps
Posted by sebb <se...@gmail.com>.
On 27/05/2009, chris <ch...@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-----
>
Re: LDAP - Next Steps
Posted by Tony Stevenson <to...@pc-tony.com>.
On 27 May 2009, at 21:14, chris wrote:
[SNIP ...]
> Certainly doable if deemed needed. I'll wait for more direction on
> this validation before I add it in.
I don't think this is needed as we will be using the repl mechanism,
the webapp will purely serve as a tool for users to edit attributes
such as mail, password, etc.
> I'll have to let Tony address the rest of your comments/questions.
Which one's specifically?
> Thank you for the continued feedback/insight Sebb!
+1
Cheers,
Tony
--------------------------------------------
Tony Stevenson
tony@pc-tony.com - pctony@apache.org
pctony@freenode.net - tony@caret.cam.ac.uk
http://blog.pc-tony.com
1024D/51047D66 ECAF DC55 C608 5E82 0B5E
3359 C9C7 924E 5104 7D66
--------------------------------------------
Re: LDAP - Next Steps
Posted by chris <ch...@ia.gov>.
-----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-----
Re: LDAP - Next Steps
Posted by sebb <se...@gmail.com>.
On 27/05/2009, chris <ch...@ia.gov> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> > In that case, can't the web application trigger the update of the auth file?
>
>
> That certainly would have been an easier way to have done it. Right now I am watching the source (ldap) using the
> syncrep overlay to spot changes. In the event that ldap group membership is changed in some way other than via the web
> application, the authz file will still be regenerated. I think this is the best way to do this, but I'm all ears if you
> know a better way to handle it.
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?
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.
>
> >
> > By the way, will the web app also trigger updates to POSIX groups?
> > Or are these handled separately?
> >
> > I assume the web-app will ensure consistency within LDAP, e.g. all
> > group members need to be in the LDAP equivalent of committers-?.
>
>
>
> 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.
> If it's not this then here's my answer:
>
> The ldap groups are the POSIX groups. There will still be some POSIX groups that are defined local to each system, but
> it is my understanding that those will be a very small set that will be maintained manually.
There are quite a few POSIX groups currently, and these don't always
get updated when the SVN group is updated.
If an LDAP group has a corresponding POSIX group, perhaps the web-app
should trigger an e-mail (or JIRA issue) when a change is made to it.
> The current group file as
> you know it will be (mostly) living in ldap after SVN has been assimilated. (Worth mention -- Committers-[a-z] will
> become one large Committers group within ldap.)
>
> At least that's what I think the plan is Sebb. :) Paul or Tony please correct me if I have gotten lost along the way.
>
>
> crr/arreyder.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.10 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>
> iEYEARECAAYFAkodkYsACgkQPmaZdRmQd+aCGQCdGEzBrBU2AJTZireMeAqXWZwu
> 2Z8AnipTsDYkBpJJfc3bu2t8WVnRay5H
> =wYDh
> -----END PGP SIGNATURE-----
>
Re: LDAP - Next Steps
Posted by Tony Stevenson <to...@pc-tony.com>.
On 28 May 2009, at 07:11, Emmanuel Lécharny wrote:
> chris wrote:
>>> That defeats people who don't want to open a web browser to change a
>>> password... Also the Auth file is not supposed to stay around for
>>> ever, as soon as the LDAP server is proven to be stable.
>>>
>>
>> Hi Emmanuel,
>>
>> It's not quite dead but the hope is that it will be dynamically
>> built. We have some scripts that produce it from an asf-authz-
>> template that
>> will live in SVN where asf-authz once was. The template has
>> everything
>> but the group members in it. In place of those groups are the
>> names of
>> the groups as stored in ldap eg. {ldap:committers} The script
>> reads the
>> template, expands the groups from ldap, and writes out the asf-authz
>> file. It does this anytime the template is modified, or a change is
>> made to a group that it cares about within ldap. The list of group
>> its
>> cares about it determined from the template.
>> Sound good?
>>
> If you forget about the confusion I made (mixing two threads), yes,
> it sounds good as a temporary solution. Also I don't have all the
> elements to define the 'perfect' usage we can do of a LDAP server,
> as I'm not a part of infra per se, being much more a LDAP pure
> player :)
>
Emmanuel,
This is actually the permanent solution as it is the best fit for our
requirements and needs.
Cheers,
Tony
--------------------------------------------
Tony Stevenson
tony@pc-tony.com - pctony@apache.org
pctony@freenode.net - tony@caret.cam.ac.uk
http://blog.pc-tony.com
1024D/51047D66 ECAF DC55 C608 5E82 0B5E
3359 C9C7 924E 5104 7D66
--------------------------------------------
Re: LDAP - Next Steps
Posted by Emmanuel Lécharny <el...@apache.org>.
chris wrote:
>> That defeats people who don't want to open a web browser to change a
>> password... Also the Auth file is not supposed to stay around for
>> ever, as soon as the LDAP server is proven to be stable.
>>
>
> Hi Emmanuel,
>
> It's not quite dead but the hope is that it will be dynamically built.
> We have some scripts that produce it from an asf-authz-template that
> will live in SVN where asf-authz once was. The template has everything
> but the group members in it. In place of those groups are the names of
> the groups as stored in ldap eg. {ldap:committers} The script reads the
> template, expands the groups from ldap, and writes out the asf-authz
> file. It does this anytime the template is modified, or a change is
> made to a group that it cares about within ldap. The list of group its
> cares about it determined from the template.
>
> Sound good?
>
If you forget about the confusion I made (mixing two threads), yes, it
sounds good as a temporary solution. Also I don't have all the elements
to define the 'perfect' usage we can do of a LDAP server, as I'm not a
part of infra per se, being much more a LDAP pure player :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: LDAP - Next Steps
Posted by chris <ch...@ia.gov>.
> That defeats people who don't want to open a web browser to change a
> password... Also the Auth file is not supposed to stay around for
> ever, as soon as the LDAP server is proven to be stable.
Hi Emmanuel,
It's not quite dead but the hope is that it will be dynamically built.
We have some scripts that produce it from an asf-authz-template that
will live in SVN where asf-authz once was. The template has everything
but the group members in it. In place of those groups are the names of
the groups as stored in ldap eg. {ldap:committers} The script reads the
template, expands the groups from ldap, and writes out the asf-authz
file. It does this anytime the template is modified, or a change is
made to a group that it cares about within ldap. The list of group its
cares about it determined from the template.
Sound good?
crr/arreyder
Re: LDAP - Next Steps
Posted by Emmanuel Lécharny <el...@apache.org>.
sebb wrote:
> On 28/05/2009, Emmanuel Lécharny <el...@apache.org> wrote:
>
>>>
>>> That certainly would have been an easier way to have done it.
>>>
>>>
>> That defeats people who don't want to open a web browser to change a
>> password... Also the Auth file is not supposed to stay around for ever, as
>> soon as the LDAP server is proven to be stable.
>>
>
> I think you have conflated two different e-mail threads.
>
Absolutely. I was reading the mail about how to change the user's
password and this thread, thus the confusion. Forgive me for the noise ...
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: LDAP - Next Steps
Posted by sebb <se...@gmail.com>.
On 28/05/2009, Emmanuel Lécharny <el...@apache.org> wrote:
> chris wrote:
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >
> >
> > > In that case, can't the web application trigger the update of the auth
> file?
> > >
> > >
> >
> > That certainly would have been an easier way to have done it.
> >
> That defeats people who don't want to open a web browser to change a
> password... Also the Auth file is not supposed to stay around for ever, as
> soon as the LDAP server is proven to be stable.
I think you have conflated two different e-mail threads.
We were discussing how changes to LDAP groups (e.g. by PMC chairs) are
reflected in the SVN authorization file once we are using LDAP groups
to define permissions. Nothing to do with user login password changes.
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>
Re: LDAP - Next Steps
Posted by Emmanuel Lécharny <el...@apache.org>.
chris wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
>> In that case, can't the web application trigger the update of the auth file?
>>
>
> That certainly would have been an easier way to have done it.
That defeats people who don't want to open a web browser to change a
password... Also the Auth file is not supposed to stay around for ever,
as soon as the LDAP server is proven to be stable.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: LDAP - Next Steps
Posted by chris <ch...@ia.gov>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> In that case, can't the web application trigger the update of the auth file?
That certainly would have been an easier way to have done it. Right now I am watching the source (ldap) using the
syncrep overlay to spot changes. In the event that ldap group membership is changed in some way other than via the web
application, the authz file will still be regenerated. I think this is the best way to do this, but I'm all ears if you
know a better way to handle it.
>
> By the way, will the web app also trigger updates to POSIX groups?
> Or are these handled separately?
>
> I assume the web-app will ensure consistency within LDAP, e.g. all
> group members need to be in the LDAP equivalent of committers-?.
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?
If it's not this then here's my answer:
The ldap groups are the POSIX groups. There will still be some POSIX groups that are defined local to each system, but
it is my understanding that those will be a very small set that will be maintained manually. The current group file as
you know it will be (mostly) living in ldap after SVN has been assimilated. (Worth mention -- Committers-[a-z] will
become one large Committers group within ldap.)
At least that's what I think the plan is Sebb. :) Paul or Tony please correct me if I have gotten lost along the way.
crr/arreyder.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkodkYsACgkQPmaZdRmQd+aCGQCdGEzBrBU2AJTZireMeAqXWZwu
2Z8AnipTsDYkBpJJfc3bu2t8WVnRay5H
=wYDh
-----END PGP SIGNATURE-----
Re: LDAP - Next Steps
Posted by Tony Stevenson <to...@pc-tony.com>.
On 27 May 2009, at 19:38, sebb wrote:
> On 26/05/2009, Tony Stevenson <to...@pc-tony.com> wrote:
>> Jukka,
>>
>> We will be deploying a web app that will enable PMC chairs to edit
>> group
>> memberships.
>
> In that case, can't the web application trigger the update of the
> auth file?
>
> By the way, will the web app also trigger updates to POSIX groups?
> Or are these handled separately?
>
> I assume the web-app will ensure consistency within LDAP, e.g. all
> group members need to be in the LDAP equivalent of committers-?.
>
Sebb, as I think Chris may have mentioned elsewhere in this thread the
POSIX groups will be in LDAP.
We will only maintain a small number of local groups, this is mainly
to ensure we can maintain access in the event of an LDAP issue.
Cheers,
Tony
--------------------------------------------
Tony Stevenson
tony@pc-tony.com - pctony@apache.org
pctony@freenode.net - tony@caret.cam.ac.uk
http://blog.pc-tony.com
1024D/51047D66 ECAF DC55 C608 5E82 0B5E
3359 C9C7 924E 5104 7D66
--------------------------------------------
Re: LDAP - Next Steps
Posted by sebb <se...@gmail.com>.
On 26/05/2009, Tony Stevenson <to...@pc-tony.com> wrote:
> Jukka,
>
> We will be deploying a web app that will enable PMC chairs to edit group
> memberships.
In that case, can't the web application trigger the update of the auth file?
By the way, will the web app also trigger updates to POSIX groups?
Or are these handled separately?
I assume the web-app will ensure consistency within LDAP, e.g. all
group members need to be in the LDAP equivalent of committers-?.
> Option 3 will not allow you to add/remove groups etc. Hence my hesitation
> to make it a firm 3rd option.
>
>
>
>
> On 26 May 2009, at 16:42, Jukka Zitting wrote:
>
>
> > Hi,
> >
> > On Tue, May 26, 2009 at 5:29 PM, Tony Stevenson <to...@pc-tony.com> wrote:
> >
> > > As you know, at the moment the SVN Authz file is in Subversion, when we
> move
> > > groups into LDAP, this will no longer be the case.
> > >
> >
> > When this happens, how will PMC chairs be updating the authorization
> settings?
> >
> > This is what worries me especially with the proposed option 3:
> >
> >
> > > [...] it would require someone with root privileges on eris/harmonia to
> be
> > > able to add new location tags, and add new groups to an existing one.
> > >
> >
> > I definitely don't want root on eris/harmonia, but I'd still like to
> > be able to set up access controls for new incubating projects, etc.
> >
> > BR,
> >
> > Jukka Zitting
> >
>
>
>
>
> Cheers,
> Tony
>
>
> --------------------------------------------
> Tony Stevenson
>
> tony@pc-tony.com - pctony@apache.org
> pctony@freenode.net - tony@caret.cam.ac.uk
>
> http://blog.pc-tony.com
>
> 1024D/51047D66 ECAF DC55 C608 5E82 0B5E
> 3359 C9C7 924E 5104 7D66
> --------------------------------------------
>
>
>
>
>
>
Re: LDAP - Next Steps
Posted by Tony Stevenson <to...@pc-tony.com>.
Jukka,
We will be deploying a web app that will enable PMC chairs to edit
group memberships.
Option 3 will not allow you to add/remove groups etc. Hence my
hesitation to make it a firm 3rd option.
On 26 May 2009, at 16:42, Jukka Zitting wrote:
> Hi,
>
> On Tue, May 26, 2009 at 5:29 PM, Tony Stevenson <to...@pc-tony.com>
> wrote:
>> As you know, at the moment the SVN Authz file is in Subversion,
>> when we move
>> groups into LDAP, this will no longer be the case.
>
> When this happens, how will PMC chairs be updating the authorization
> settings?
>
> This is what worries me especially with the proposed option 3:
>
>> [...] it would require someone with root privileges on eris/
>> harmonia to be
>> able to add new location tags, and add new groups to an existing one.
>
> I definitely don't want root on eris/harmonia, but I'd still like to
> be able to set up access controls for new incubating projects, etc.
>
> BR,
>
> Jukka Zitting
Cheers,
Tony
--------------------------------------------
Tony Stevenson
tony@pc-tony.com - pctony@apache.org
pctony@freenode.net - tony@caret.cam.ac.uk
http://blog.pc-tony.com
1024D/51047D66 ECAF DC55 C608 5E82 0B5E
3359 C9C7 924E 5104 7D66
--------------------------------------------
Re: LDAP - Next Steps
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Tue, May 26, 2009 at 5:29 PM, Tony Stevenson <to...@pc-tony.com> wrote:
> As you know, at the moment the SVN Authz file is in Subversion, when we move
> groups into LDAP, this will no longer be the case.
When this happens, how will PMC chairs be updating the authorization settings?
This is what worries me especially with the proposed option 3:
> [...] it would require someone with root privileges on eris/harmonia to be
> able to add new location tags, and add new groups to an existing one.
I definitely don't want root on eris/harmonia, but I'd still like to
be able to set up access controls for new incubating projects, etc.
BR,
Jukka Zitting