I've re-written the LDAP module in "master". The code is simpler, cleaner, and easier to understand. It is largely compatible in function with the old module, with the following differences: - the eDirectory code has been removed. I don't run eDir, and I can't test it. Patches to re-add it are welcome - the module uses the new connection pool API. As a result, its configuration is more in line with the rest of the server - the config items have been reorganized to make more sense. The names are similar, but they're grouped into sections I've tested it against a number of LDAP servers. It seems to be stable, and performs at 6K queries per second in sustained load. The old module was much less than that. The new connection pool also means that the module can re-use connections in more situations. Previously, the module would close and then re-open connections many times. Now, it does so much less often. The next steps are: - add eDir support (if people need it) - move "ldap.attrmap" to the module configuration. Alan DeKok.
Alan We use the eDir module within FreeRadius quite heavily so wouldn't want to loose that functionality. If you have a RHEL (or Centos), SLES or Solaris instance then it's pretty straight forward how to test if the eDirectory Universal Password functionality is functional or not. You can easily download eDirectory from download.novell.com and I can help with the few steps required to get a working instance after that. the ldap.attrmap is also quite useful externalised as a separate file rather than being part of the specific LDAP module configuration. In our case we run multiple instances of the LDAP Module depending on the path you took to get to the FreeRadius instance. Some of these paths have the same LDAP -> VSA Attribute mapping but have different LDAP Servers and Base DN/Filters we search on, others have slightly different ones. So we reference the same ldap.attrmap against different module instances. Not a biggie either way as we would just duplicate the mapping across the different instances, but I can see the rationale from having everything inside the single module configuration file. Feel free to email me off list if you wanted further details about how to make eDir go. Cheers Peter On Wed, Nov 14, 2012 at 2:48 AM, Alan DeKok <aland@deployingradius.com>wrote:
I've re-written the LDAP module in "master". The code is simpler, cleaner, and easier to understand.
It is largely compatible in function with the old module, with the following differences:
- the eDirectory code has been removed. I don't run eDir, and I can't test it. Patches to re-add it are welcome
- the module uses the new connection pool API. As a result, its configuration is more in line with the rest of the server
- the config items have been reorganized to make more sense. The names are similar, but they're grouped into sections
I've tested it against a number of LDAP servers. It seems to be stable, and performs at 6K queries per second in sustained load. The old module was much less than that.
The new connection pool also means that the module can re-use connections in more situations. Previously, the module would close and then re-open connections many times. Now, it does so much less often.
The next steps are:
- add eDir support (if people need it)
- move "ldap.attrmap" to the module configuration.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
On 13 Nov 2012, at 20:02, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
Alan
We use the eDir module within FreeRadius quite heavily so wouldn't want to loose that functionality.
If you have a RHEL (or Centos), SLES or Solaris instance then it's pretty straight forward how to test if the eDirectory Universal Password functionality is functional or not. You can easily download eDirectory from download.novell.com and I can help with the few steps required to get a working instance after that.
Ok.
the ldap.attrmap is also quite useful externalised as a separate file rather than being part of the specific LDAP module configuration. In our case we run multiple instances of the LDAP Module depending on the path you took to get to the FreeRadius instance. Some of these paths have the same LDAP -> VSA Attribute mapping but have different LDAP Servers and Base DN/Filters we search on, others have slightly different ones. So we reference the same ldap.attrmap against different module instances. Not a biggie either way as we would just duplicate the mapping across the different instances, but I can see the rationale from having everything inside the single module configuration file.
The current mappings file doesn't follow any of the conventions of the server, it uses outdated list names and its confusing for new users. It makes much more sense to use one of the schemes previously discussed in another thread, and if you want to use the same mappings with multiple files, then you can move them to an external file and $INCLUDE that. -Arran
On Wed, Nov 14, 2012 at 9:14 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On 13 Nov 2012, at 20:02, Peter Lambrechtsen <peter@crypt.co.nz> wrote:
the ldap.attrmap is also quite useful externalised as a separate file rather than being part of the specific LDAP module configuration. In our case we run multiple instances of the LDAP Module depending on the path you took to get to the FreeRadius instance. Some of these paths have the same LDAP -> VSA Attribute mapping but have different LDAP Servers and Base DN/Filters we search on, others have slightly different ones. So we reference the same ldap.attrmap against different module instances. Not a biggie either way as we would just duplicate the mapping across the different instances, but I can see the rationale from having everything inside the single module configuration file.
The current mappings file doesn't follow any of the conventions of the server, it uses outdated list names and its confusing for new users. It makes much more sense to use one of the schemes previously discussed in another thread, and if you want to use the same mappings with multiple files, then you can move them to an external file and $INCLUDE that.
Great. I should have thought about an external $INCLUDE file and yes it does make a whole lot more sense to follow the standard mapping schemes used in other modules rather than having a whacky standalone mapping scheme just for LDAP. Carry on and forget I even mentioned it :)
Peter Lambrechtsen wrote:
We use the eDir module within FreeRadius quite heavily so wouldn't want to loose that functionality.
I understand.
If you have a RHEL (or Centos), SLES or Solaris instance then it's pretty straight forward how to test if the eDirectory Universal Password functionality is functional or not. You can easily download eDirectory from download.novell.com <http://download.novell.com> and I can help with the few steps required to get a working instance after that.
I'll see, but I can't make any promises. I'm busy with other work, and eDir isn't something I use at all. Maybe someone else on the list can help. Most of the relevant code is in edir_ldapext.c. That hasn't changed. I *would* want it to be formatted correctly, though. And the whole "apc_conns" craziness needs to go away. There's no need for it. in the new module. That should simplify the code. The "passwd_attr" code is gone. It wasn't necessary, and deleting it simplifies the server. Instead, the module should have a simple boolean "edir = yes / no". I think in the end the code changes aren't much. They just require a bit of time and effort. The rest of the LDAP module was changed for performance, simplicity, and maintainability. The new code is much better than the old. Alan DeKok.
On 13 Nov 2012, at 20:47, Alan DeKok <aland@DEPLOYINGRADIUS.COM> wrote:
Peter Lambrechtsen wrote:
We use the eDir module within FreeRadius quite heavily so wouldn't want to loose that functionality.
I understand.
If you have a RHEL (or Centos), SLES or Solaris instance then it's pretty straight forward how to test if the eDirectory Universal Password functionality is functional or not. You can easily download eDirectory from download.novell.com <http://download.novell.com> and I can help with the few steps required to get a working instance after that.
I'll see, but I can't make any promises. I'm busy with other work, and eDir isn't something I use at all. Maybe someone else on the list can help.
Most of the relevant code is in edir_ldapext.c. That hasn't changed. I *would* want it to be formatted correctly, though.
And the whole "apc_conns" craziness needs to go away. There's no need for it. in the new module. That should simplify the code.
The "passwd_attr" code is gone. It wasn't necessary, and deleting it simplifies the server. Instead, the module should have a simple boolean "edir = yes / no".
I think in the end the code changes aren't much. They just require a bit of time and effort.
The rest of the LDAP module was changed for performance, simplicity, and maintainability. The new code is much better than the old.
Just to conclude this thread. Edir support was added back into the module, but was changed slightly. Users upgrading from 2.0.0 who used to call the ldap module in post-auth should now set edir_autz = yes, and remove the post-auth call. -Arran
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Peter Lambrechtsen