You can user attr_rewrite to get the shortname into an item. I used this
when I wanted to get a ldap profile based on shortname. Here is what I
used:
attr_rewrite uprof {
attribute = User-Profile
# may be "packet", "reply", "proxy", "proxy_reply" or
"config"
searchin = config
searchfor = ""
replacewith = "cn=%C,ou=Profiles,dc=defence,dc=gov,dc=au"
ignore_case = no
new_attribute = yes
max_matches = 10
# ## If set to yes then the replace string will be
appended to the original string
append = no
}
Presumably by instantiating the module before preprocess, the attribute
will be available to huntgroup processing.
You could also try the direct approach:
Raddb/hints
DEFAULT
Huntgroup-Name = `%C`
Or
DEFAULT
Hint = `%C`
Which would allow testing in raddb/huntgroups
Hunt1 NAS-Port == 42, Hint == "Provider1"
Regards,
Frank Ranner
> -----Original Message-----
> From:
> [EMAIL PROTECTED]
eradius.org [mailto:freeradius-users->
[EMAIL PROTECTED] On
> Behalf Of Jakob Hirsch
> Sent: Tuesday, 23 January 2007 02:31
> To: FreeRadius users mailing list
> Subject: match client's shortname in huntgroups file
>
> Hi,
>
> is there an easy/good way to determine the huntgroup
> depending on the the shortname from clients.conf? We have
> more than 100 clients configured (with a
> "ProviderLocationCounter" pattern), so the information is
> duplicated in the huntgroups file (multiple times, as the
> huntgroup is also determined by Called-Station-Id). So it
> would really simplify things to have the shortname available
> for matching in the huntgroups file.
> I could extend one of our custom modules to put the name into
> a VSA and use that like 'Client-Shortname == "blub"' (already
> did it in a test environment and it works fine), but that
> seems a little clumsy to me, so I wondered if there's an easier way.
>
>
>
> unrelated side note: As I see, client_find() walks linearly
> through the client list. Shouldn't we keep this in a more
> appropriate data structure, like a btree or a trie, and/or
> save the once found RADCLIENT* pointer in the REQUEST struct?
> I understand that it doesn't matter for most installations
> (and we don't have any performance problems, either), it just
> does not feel right to waste so many cpu cycles :)
>
>
>
> regards,
> J
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
