RE: match client's shortname in huntgroups file [unclas]

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:
> freeradius-users-bounces+frank.ranner=defence.gov.au@lists.fre
eradius.org [mailto:freeradius-users->
bounces+frank.ranner=defence.gov.au@lists.freeradi us.org] 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