match client's shortname in huntgroups file [unclas]

[Ranner, Frank MR]

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