First post please be gentle. Working on a migration from XtRadius 1.2.1B2 to FreeRadius 3.0.8. In my XtRadius users file, I have the following line: ------------------------------ DEFAULT Acct-Status-Type = "Start" Exec-Program-Account = "/radius/scripts/startrad.sh %u %f %y %n %p" ------------------------------ From what I understand in the documentation, I created the following the file in mods-enabled called startrad. The file contains: ------------------------------- # -*- text -*- exec startrad { wait = yes program = "/radius/scripts/startrad.sh %{User-Name} \ %{Framed-IP-Address} \ %{NAS-Port-Type} \ %{NAS-IP-Address} \ %{NAS-Port-Id}" input_pairs = request output_pairs = reply packet_type = Access-Accept } --------------------------------- The shell script right now just dumps the arguments to a flat text file. I call this module in my sites-enabled/default config in the accounting section like so: --------------------------------- accounting { detail unix radutmp sradutmp -sql exec if ( "%{Acct-Status-Type}" == "Start"){ startrad } } ----------------------------------- From there, I execute "radius -X | tee -a log" and I see the module enabled and executed, but the result is (showing what I think are relevant entries): ------------------------------------ ... including configuration file /radius/raddb/mods-enabled/startrad ... ... # Instantiating module "startrad" from file /radius/raddb/mods-enabled/startrad exec startrad { wait = yes program = "/radius/scripts/startrad.sh %{User-Name} %{Framed-IP-Address} %{NAS-Port-Type} %{NAS-IP-Address} %{NAS-Port-Id}" input_pairs = "request" output_pairs = "reply" shell_escape = yes } ... ... (1) User-Name = 'testuser' (1) Acct-Authentic = RADIUS ... ... (1) Acct-Status-Type = Stop (1) NAS-Port-Type = Virtual (1) NAS-Port = 16777297 (1) Class = 0x61693a6238623938653064353564393061376235626533303763663239313737363134 (1) Service-Type = Framed-User ... ... ... (0) if ( "%{Acct-Status-Type}" == "Start") { (0) EXPAND %{Acct-Status-Type} (0) --> Stop (0) if ( "%{Acct-Status-Type}" == "Start") -> FALSE (0) startrad: Executing: /radius/scripts/startrad.sh %{User-Name} %{Framed-IP-Address} %{NAS-Port-Type} %{NAS-IP-Address} %{NAS-Port-Id}: (0) startrad: EXPAND %{User-Name} (0) startrad: --> testuser (0) startrad: EXPAND %{Framed-IP-Address} (0) startrad: --> ***.***.***.238 (0) startrad: EXPAND %{NAS-Port-Type} (0) startrad: --> Virtual (0) startrad: EXPAND %{NAS-IP-Address} (0) startrad: --> ***.***.***.226 (0) startrad: EXPAND %{NAS-Port-Id} (0) startrad: --> (0) startrad: Program returned code (0) and output '' (0) startrad: Program executed successfully (0) [startrad] = ok (0) } # accounting = ok ... ... ------------------------------------- So, despite the if/then statement being false, the startrad module is still being executed. I've seen numerous postings on similar question, but any answers I did find are several years old. Am I correct in moving the script to a module and sites-enabled/default files from the mods-config/files/authorize (aka users)? Please advise. Thanks. -- Paul Boehmer pboehmer@seidata.com
...And the first post is an epic fail. Seems the code below works as advertised. As a part of troubleshooting, I had erroneously put a stray "startrad" in my sites-enabled/default without a test condition, thus executing the script regardless of Acct-Status-Type. That being said, am I on the right track as far as best practices? On 05/12/15 09:22, Paul Boehmer wrote:
First post please be gentle.
Working on a migration from XtRadius 1.2.1B2 to FreeRadius 3.0.8. In my XtRadius users file, I have the following line:
------------------------------ DEFAULT Acct-Status-Type = "Start" Exec-Program-Account = "/radius/scripts/startrad.sh %u %f %y %n %p" ------------------------------
From what I understand in the documentation, I created the following the file in mods-enabled called startrad. The file contains:
------------------------------- # -*- text -*- exec startrad { wait = yes program = "/radius/scripts/startrad.sh %{User-Name} \ %{Framed-IP-Address} \ %{NAS-Port-Type} \ %{NAS-IP-Address} \ %{NAS-Port-Id}"
input_pairs = request output_pairs = reply packet_type = Access-Accept } ---------------------------------
The shell script right now just dumps the arguments to a flat text file. I call this module in my sites-enabled/default config in the accounting section like so:
--------------------------------- accounting { detail unix radutmp sradutmp -sql exec
if ( "%{Acct-Status-Type}" == "Start"){ startrad }
} -----------------------------------
From there, I execute "radius -X | tee -a log" and I see the module enabled and executed, but the result is (showing what I think are relevant entries):
------------------------------------ ... including configuration file /radius/raddb/mods-enabled/startrad ... ... # Instantiating module "startrad" from file /radius/raddb/mods-enabled/startrad exec startrad { wait = yes program = "/radius/scripts/startrad.sh %{User-Name} %{Framed-IP-Address} %{NAS-Port-Type} %{NAS-IP-Address} %{NAS-Port-Id}" input_pairs = "request" output_pairs = "reply" shell_escape = yes } ... ... (1) User-Name = 'testuser' (1) Acct-Authentic = RADIUS ... ... (1) Acct-Status-Type = Stop (1) NAS-Port-Type = Virtual (1) NAS-Port = 16777297 (1) Class = 0x61693a6238623938653064353564393061376235626533303763663239313737363134 (1) Service-Type = Framed-User ... ... ... (0) if ( "%{Acct-Status-Type}" == "Start") { (0) EXPAND %{Acct-Status-Type} (0) --> Stop (0) if ( "%{Acct-Status-Type}" == "Start") -> FALSE (0) startrad: Executing: /radius/scripts/startrad.sh %{User-Name} %{Framed-IP-Address} %{NAS-Port-Type} %{NAS-IP-Address} %{NAS-Port-Id}: (0) startrad: EXPAND %{User-Name} (0) startrad: --> testuser (0) startrad: EXPAND %{Framed-IP-Address} (0) startrad: --> ***.***.***.238 (0) startrad: EXPAND %{NAS-Port-Type} (0) startrad: --> Virtual (0) startrad: EXPAND %{NAS-IP-Address} (0) startrad: --> ***.***.***.226 (0) startrad: EXPAND %{NAS-Port-Id} (0) startrad: --> (0) startrad: Program returned code (0) and output '' (0) startrad: Program executed successfully (0) [startrad] = ok (0) } # accounting = ok ... ... -------------------------------------
So, despite the if/then statement being false, the startrad module is still being executed.
I've seen numerous postings on similar question, but any answers I did find are several years old. Am I correct in moving the script to a module and sites-enabled/default files from the mods-config/files/authorize (aka users)?
Please advise. Thanks.
-- Paul Boehmer SEI Data, Inc pboehmer@seidata.com 888-200-4392
On May 12, 2015, at 12:23 PM, Paul Boehmer <pboehmer@seidata.com> wrote:
...And the first post is an epic fail.
Seems the code below works as advertised. As a part of troubleshooting, I had erroneously put a stray "startrad" in my sites-enabled/default without a test condition, thus executing the script regardless of Acct-Status-Type.
I was wondering how we overlooked such a major defect.
That being said, am I on the right track as far as best practices?
Well other than using exec at all... sure. It really is horrifically slow, and there's not much we can do about that. For 3.0.8 you might find the back ticks syntax is more convenient. update { Tmp-String-0 := `/my/shell/script --arg '%{arg}'` } Behaviour changes based on the operator and LHS expression. := will copy stdout to the attribute Tmp-String-0. <list>: += will look for attributes in the environment of the shell script and add them to the specified list. The reason why the exec module is sticking around, is because it allows you toggle more stuff, like not waiting for the script to complete before continuing. -Arran
On Tue, May 12, 2015 at 12:23:15PM -0400, Paul Boehmer wrote:
That being said, am I on the right track as far as best practices?
...
The shell script right now just dumps the arguments to a flat text file.
If that's all you want to do, look at the 'linelog' module, which will be a *lot* faster. Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
No, in the end the script will be checking VPI/VCI ports numbers for conflicts and additional sanity checks. On 05/12/15 13:15, Matthew Newton wrote:
On Tue, May 12, 2015 at 12:23:15PM -0400, Paul Boehmer wrote:
That being said, am I on the right track as far as best practices?
...
The shell script right now just dumps the arguments to a flat text file.
If that's all you want to do, look at the 'linelog' module, which will be a *lot* faster.
Matthew
-- Paul Boehmer
On May 12, 2015, at 1:35 PM, Paul Boehmer <pboehmer@seidata.com> wrote:
No, in the end the script will be checking VPI/VCI ports numbers for conflicts and additional sanity checks.
You can write most of those checks in "unlang". That's the policy language included with FreeRADIUS. See the many examples in raddb/ Alan DeKok.
It would be nice if we could do that within the configuration, but I'm trying to figure out how you would handle a scenario like: Customer connected to specific VPI/VCI and gets locked out due to billing issue. Customer attempts to bypass by using a different account credentials, though they are still on the same VPI/VCI. On the XtRadius system we are migrating from, we log which customers are on which VCI/VPI and if there is a User-Name conflict at some point, an email is sent to the administrators with notification of the conflict. Keep in mind that this configuration has been in use since early 2000 and has various other support programs that depend on the output of the exec scripts. Not pretty, but it worked. Ideally, we will be moving from flat text files to SQL, but this will be in baby steps. Thanks again for the assistance! On 05/12/15 14:03, Alan DeKok wrote:
On May 12, 2015, at 1:35 PM, Paul Boehmer <pboehmer@seidata.com> wrote:
No, in the end the script will be checking VPI/VCI ports numbers for conflicts and additional sanity checks.
You can write most of those checks in "unlang". That's the policy language included with FreeRADIUS.
See the many examples in raddb/
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Paul Boehmer
On May 12, 2015, at 2:35 PM, Paul Boehmer <pboehmer@seidata.com> wrote:
It would be nice if we could do that within the configuration, but I'm trying to figure out how you would handle a scenario like:
Customer connected to specific VPI/VCI and gets locked out due to billing issue. Customer attempts to bypass by using a different account credentials, though they are still on the same VPI/VCI.
What does that mean? i.e. When you want a user rejected, what's in the Access-Request?
On the XtRadius system we are migrating from, we log which customers are on which VCI/VPI and if there is a User-Name conflict at some point, an email is sent to the administrators with notification of the conflict. Keep in mind that this configuration has been in use since early 2000 and has various other support programs that depend on the output of the exec scripts. Not pretty, but it worked. Ideally, we will be moving from flat text files to SQL, but this will be in baby steps.
This is typically what you should use databases for. Create a table of User-Name, and VPI / VCI. Then, check that the User-Name and VPI/VCI in the request match the User-Name and VPI/VCI in the database. Alan DeKok.
participants (4)
-
Alan DeKok -
Arran Cudbard-Bell -
Matthew Newton -
Paul Boehmer