Re: migrating external programs from xtradius to freeradius

2004-12-08 Thread Alan DeKok
"L.C. (Laurentiu C. Badea)" <[EMAIL PROTECTED]> wrote:
>  Uppercasing is actually the worst problem, as it's not easily reversible.

  So edit src/main/exec.c  You have the source.

  Alan DeKok.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: migrating external programs from xtradius to freeradius

2004-12-08 Thread L.C. \(Laurentiu C. Badea\)
Thank you Alan and Paul for your replies.

> > Freeradius converts the attribute names to make them more like
> > standard "sh" variables. It also wraps the string values in double
> > quotes, such that echo ${USER_NAME} yields "username".
> 

>   The first issue is a result of deciding that '-' is a magic
> character to many programs.
> 

>   The second issue is probably unnecessary, and should be resolved.
> See src/main/exec.c, change "vp_prints_value(..., 1)" to "..., 0)"
> 

>   You can also fix src/main/exec.c to NOT uppercase the attribute
> names.  It should be pretty easy.

Uppercasing is actually the worst problem, as it's not easily reversible.
I have done workarounds in my client for all these, but the case fix did 

not come out too pretty.

Since this is a production deal, my goal is to minimize hacks that might
cause things to break should someone else upgrade freeradius on the 

servers, hence I'm not too keen on compiling my own version, especially
as it is now prepackaged on the newer Fedora releases.


> > Xtradius uses Auth-Type = External, freeradius appears to need
> > Auth-Type = Accept with an external script. Not a big deal, just
> > thought I should mention it because it is somewhat less intuitive
> > (since after all, you can turn it into a Reject via exit code).
> 

>   So add 'External' as a duplicate name for 'Accept' in the dictionaries.

It doesn't bother me all that much that it doesn't say External, now that
I got it to work. I only pointed it out because, by being non-obvious, 

might become a stumbling block for others.
--
Regards,
L.C. (Laurentiu Badea)
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: migrating external programs from xtradius to freeradius

2004-12-07 Thread Paul Hampson
On Tue, Dec 07, 2004 at 12:40:41PM -0800, L.C. (Laurentiu C. Badea) wrote:
> Xtradius uses Auth-Type = External, freeradius appears to need Auth-Type = 
> Accept with an external script. Not a big deal, just thought I should 
> mention it because it is somewhat less intuitive (since after all, you can 
> turn it into a Reject via exit code).

You could add an Auth-Type to your local dictionary, and force Auth-Type
to that in authorization, if you're only ever going to authenticate from
that external script.

Otherwise, an rlm_exec in authorization which checks for conditions and
sets your custom Auth-Type would be the obvious method to me.

_Or_ your could put your script in post-auth, so it's always called, and
just have the authorisation section always return accept. ^_^

I guess there's no "External" Auth-Type because very few people are
doing checking that can't be handled in one of the auth-types supplied
already?

-- 
Paul "TBBle" Hampson, on an alternate email client.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


Re: migrating external programs from xtradius to freeradius

2004-12-07 Thread Alan DeKok
"L.C. (Laurentiu C. Badea)" <[EMAIL PROTECTED]> wrote:
> Freeradius converts the attribute names to make them more like
> standard "sh" variables. It also wraps the string values in double
> quotes, such that echo ${USER_NAME} yields "username".

  The first issue is a result of deciding that '-' is a magic
character to many programs.

  The second issue is probably unnecessary, and should be resolved.
See src/main/exec.c, change "vp_prints_value(..., 1)" to "..., 0)"

  You can also fix src/main/exec.c to NOT uppercase the attribute
names.  It should be pretty easy.

> Xtradius uses Auth-Type = External, freeradius appears to need
> Auth-Type = Accept with an external script. Not a big deal, just
> thought I should mention it because it is somewhat less intuitive
> (since after all, you can turn it into a Reject via exit code).

  So add 'External' as a duplicate name for 'Accept' in the dictionaries.

> May I suggest to have the sample code (prepaid.py, radiusd_test.py
> etc) installed in the doc directory for the rpm packages ?

  Sure.

  Alan DeKok.

- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html


migrating external programs from xtradius to freeradius

2004-12-07 Thread L.C. \(Laurentiu C. Badea\)
As the subject says, I am currently using xtradius in production with 
external programs for authentication and accounting. Freeradius is very similar 
in its handling of external scripts, but has its own peculiarities which made 
things a bit more complicated than they should be:
Xtradius puts the RADIUS attributes in the environment with their real names (i.e. echo ${User-Name} yields the username value. Freeradius converts the attribute names to make them more like standard "sh" variables. It also wraps the string values in double quotes, such that echo ${USER_NAME} yields "username". 

Both operations seem unnecessary and make writing external accounting 
applications very painful. The mangled names cannot be found or converted back 
to RADIUS attributes in a clean manner without using the dictionary. One also 
has to remove the double quotes wherever they are found. I had to write 
wrappers around getenv() and family where I could use just getenv() before.
Xtradius uses Auth-Type = External, freeradius appears to need Auth-Type = 
Accept with an external script. Not a big deal, just thought I should mention 
it because it is somewhat less intuitive (since after all, you can turn it into 
a Reject via exit code).
I understand external scripts are not much of a priority in the grand scheme of 
things; I am trying to see how freeradius performs in the same environment as 
xtradius and will probably be using that until I write a better solution. I 
plan to use the in-core python module next. I was excited because it is exactly 
what I was looking for but I couldn't find docs and temporarily gave up. May I 
suggest to have the sample code (prepaid.py, radiusd_test.py etc) installed in 
the doc directory for the rpm packages ?
--
Regards,
L.C. (Laurentiu Badea)
- 
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html