some patches for branch v2.1.x
While migrating the configuration of our commercial radius to freeradius I needed to customise (parts of) the freeradius sources to our needs. Perhaps those patches are useful for others, so I want to contribute them and ask if you are willing to accept them: rlm_linelog: The original module does not create parent directories when needed. The patch fixes this behavior, so you can define filenames for logging like: filename = ${logdir}/whatever/%Y/%m/detail.%d This patch is trivial and has no effects to in-use installations. rlm_ldap: Our LDAP scheme provides 4 data fields, two for check-items and two for reply-items (RadiusReplyattrDSL/RadiusCheckattrDSL and RadiusReplyattr/RadiusCheckattr). Those fields contain attributes/value pairs in one row, eg: RadiusReplyattrDSL: Framed-IP-Address = 1.2.3.4, Session-Timeout = 86400, Uni-Egress-Policy-Name="pol6144",Uni-Ingress-Policy-Name="pol512" Which pair is used depends on values found in the request, i.e. if the request was sent by a BRAS then RadiusReplyattrDSL/RadiusCheckattrDSL are used, if sent by a (ISDN-) NAS then RadiusReplyattr/RadiusCheckattr are used. So I needed a way to extract those one-liners to a list of attribute/value pairs. To avoid rlm_perl I patched rlm_ldap, so you can configure the rows to use via configuration, especially in the hints file. While working on this module I also found it useful to be able to set the basedn via hints. So you can additionally provide the basedn: DEFAULT NAS-IP-Address =~ "(1.2.3.4|4.3.2.1)" LDap-basedn := "ou=Service-11200,ou=people,dc=company,dc=com", LDap-Multimap-reply := "RadiusReplyattrDSL", LDap-Multimap-check := "RadiusCheckattrDSL" rlm_ldap will then look for values in these fields and attach them to the reply set. rlm_translate: Additionally I found it useful to have the functionality of the unix 'tr' command in freeradius so I wrote rlm_translate. This module implements the full tr functionality as a freeradius module. The module configuration looks like: translate username_tolower { attribute = "User-Name" searchin = packet set1 = "A-Z" set2 = "a-z" complement = no translate = yes squeeze = no delete = no } I know those changes are not vital but I believe useful. If you like them I will provide (git-) .diff files. Currently I'm going with v2.1.x but can provide diffs for 3.x, too. What do you think? Regards, Oliver
On 17 Aug 2011, at 10:38, Oliver Schröder wrote:
While migrating the configuration of our commercial radius to freeradius I needed to customise (parts of) the freeradius sources to our needs. Perhaps those patches are useful for others, so I want to contribute them and ask if you are willing to accept them:
rlm_linelog:
The original module does not create parent directories when needed. The patch fixes this behavior, so you can define filenames for logging like: filename = ${logdir}/whatever/%Y/%m/detail.%d
There's already code to recursively create directories in /src/main please call this if you want to add the functionality.
This patch is trivial and has no effects to in-use installations.
rlm_ldap:
Our LDAP scheme provides 4 data fields, two for check-items and two for reply-items (RadiusReplyattrDSL/RadiusCheckattrDSL and RadiusReplyattr/RadiusCheckattr). Those fields contain attributes/value pairs in one row, eg: RadiusReplyattrDSL: Framed-IP-Address = 1.2.3.4, Session-Timeout = 86400, Uni-Egress-Policy-Name="pol6144",Uni-Ingress-Policy-Name="pol512" Which pair is used depends on values found in the request, i.e. if the request was sent by a BRAS then RadiusReplyattrDSL/RadiusCheckattrDSL are used, if sent by a (ISDN-) NAS then RadiusReplyattr/RadiusCheckattr are used. So I needed a way to extract those one-liners to a list of attribute/value pairs. To avoid rlm_perl I patched rlm_ldap, so you can configure the rows to use via configuration, especially in the hints file. While working on this module I also found it useful to be able to set the basedn via hints. So you can additionally provide the basedn:
DEFAULT NAS-IP-Address =~ "(1.2.3.4|4.3.2.1)" LDap-basedn := "ou=Service-11200,ou=people,dc=company,dc=com", LDap-Multimap-reply := "RadiusReplyattrDSL", LDap-Multimap-check := "RadiusCheckattrDSL"
rlm_ldap will then look for values in these fields and attach them to the reply set.
No, the same can be achieved with unlang.
rlm_translate:
Additionally I found it useful to have the functionality of the unix 'tr' command in freeradius so I wrote rlm_translate. This module implements the full tr functionality as a freeradius module. The module configuration looks like:
translate username_tolower { attribute = "User-Name" searchin = packet set1 = "A-Z" set2 = "a-z" complement = no translate = yes squeeze = no delete = no }
I know those changes are not vital but I believe useful. If you like them I will provide (git-) .diff files. Currently I'm going with v2.1.x but can provide diffs for 3.x, too.
This is already provided in unlang XLAT. Most of the problems can be solved with generic unlang instead of using module specific code which makes the patches kind of redundant. Recursively creating directories would be useful though. Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Half the complexity of Diameter
Am 17.08.2011 12:01, schrieb Arran Cudbard-Bell:
On 17 Aug 2011, at 10:38, Oliver Schröder wrote:
The original module does not create parent directories when needed. The patch fixes this behavior, so you can define filenames for logging like: filename = ${logdir}/whatever/%Y/%m/detail.%d
There's already code to recursively create directories in /src/main please call this if you want to add the functionality.
My patch uses this code. See the attached .diff
DEFAULT NAS-IP-Address =~ "(1.2.3.4|4.3.2.1)" LDap-basedn := "ou=Service-11200,ou=people,dc=company,dc=com", LDap-Multimap-reply := "RadiusReplyattrDSL", LDap-Multimap-check := "RadiusCheckattrDSL"
rlm_ldap will then look for values in these fields and attach them to the reply set.
No, the same can be achieved with unlang.
I have not found any documentation helping me to implement this via unlang. Can you nudge me in the right direction? Regards, Oliver
On 17 Aug 2011, at 12:34, Oliver Schröder wrote:
Am 17.08.2011 12:01, schrieb Arran Cudbard-Bell:
On 17 Aug 2011, at 10:38, Oliver Schröder wrote:
The original module does not create parent directories when needed. The patch fixes this behavior, so you can define filenames for logging like: filename = ${logdir}/whatever/%Y/%m/detail.%d
There's already code to recursively create directories in /src/main please call this if you want to add the functionality.
My patch uses this code. See the attached .diff
Could you please submit it via GitHub. http://wiki.freeradius.org/GitHub That way you get the credit/blame :)
DEFAULT NAS-IP-Address =~ "(1.2.3.4|4.3.2.1)" LDap-basedn := "ou=Service-11200,ou=people,dc=company,dc=com", LDap-Multimap-reply := "RadiusReplyattrDSL", LDap-Multimap-check := "RadiusCheckattrDSL"
rlm_ldap will then look for values in these fields and attach them to the reply set.
No, the same can be achieved with unlang.
I have not found any documentation helping me to implement this via unlang. Can you nudge me in the right direction?
If(%{my_attribute} =~ /^([^,]+)?,?([^,]+)?,?([^,]+)?,?([^,]+)?,([^,]+)?,?([^,]+)?,?([^,]+)?,?([^,]+)?$/){ update reply { my_reply_attr_0 := "%{1}" my_reply_attr_1 := "%{2}" ... } } or if(%{parent_attribute} =~ /my_attribute=([^,]+)/){ update reply { my_attribute := "%{1}" } } You can still use the users file to set a reply attribute with the comma delimited value, and then process it with unlang later. Yes it's not perfect, but unlang/regexps are pretty fast, and you're not likely to have more than a few attributes in the response. Group the unlang statements in a policy to avoid duplication. -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Half the complexity of Diameter
Am 18.08.2011 03:26, schrieb Alan DeKok:
Oliver Schröder wrote:
My patch uses this code. See the attached .diff
OK... what is "libgen"? And why is its header file included in the patch?
I've overseen this header. It was included to use dirname(3) and basename(3) and can be removed.
And the patch doesn't apply to the git head. This is why github is best.
I'm currently trying to find my way through git.
Anyways, I've fixed the patch&& applied it.
Thank you, Oliver Schröder
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Oliver Schröder