No. acct_users file. Ivan Kalik Kalik Informatika ISP Dana 14/6/2008, "Pete Kay" <petedao@gmail.com> piše:

Hi Ivan,

Sorry to have to ask again. I think you have explain clear enough, but I am just too new to freeradius. I tried modifying in /sites-enable/default:

accounting { detail radutmp sql sql_log DEFAULT Acct-Status-Type = Stop Exec-Program="/home/anne/bill %{Acct-Session-Id}" attr_filter.accounting_response }

But I am getting: /usr/local/etc/raddb/sites-enabled/default[349]: Expecting section start brace '{' after "DEFAULT Acc-Status-Type"

Is this not the right place to add the code?

Thanks alot for all your help.

Pete

2008/6/14 Ivan Kalik <tnt@kalik.net>:

...

acct_users file:

DEFAULT Acct-Status-Type = Stop Exec-Program = "/home/billing/bill %{Acct-Session-Id}"

You can't use radacctid as that is autogenerated by the database server and is not part of the accouning request.

Ivan Kalik Kalik Informatika ISP

Dana 14/6/2008, "Pete Kay" <petedao@gmail.com> piše:

...

Hi,

I tried to execute a billing script as follows:

accounting{

sql

exec /etc/billing/bill }

But, I am getting:

/usr/local/etc/raddb/sites-enabled/default[350]: Expecting section start brace '{' after "exec /home/billing/bill" Errors reading /usr/local/etc/raddb/radiusd.conf

What is wrong with my syntax? Is there any sample that I can refer to?

I checked the unlan, but I could not find anything that mentions the variable that I can use to pass to the script. What I like to do is to call the script: exec /etc/billing/bill <radacctid>

That way, I can know which line to process.

Thanks for any suggestion.

Regards, Pete

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

Pete Kay wrote:

I have been trying to setup freeradius to kick off a billing script when after accounting log is stored in DB, but I still can't get it to work and I don't know why. ... Could someone please help me out?

Don't use the 'acct_users' file. You can run scripts directly from the config files. See "man unlang". Alan DeKok.

Pete Kay wrote:

I have tried the following: accounting{

sql

exec /etc/billing/bill }

That don't work. The entries are module names, not lists of parameters. Read the example for the "exec" module to see how to execute a specific program. See the "echo" example.

But it still does not work. I checked the unlang, but it does not give me much hint....

It tells you how you can run shell scripts. Use back-ticks. Alan DeKok.

Yeah, you need to define the instance as: exec execbill { } See Also "exec echo" just below "exec". As I understand it, that's how you say, "I'm defining an exec module called 'execbill'." (IMHO, the default config could eliminate some of this frequent confusion if it were changed to, say, "ldap ldap-module" instead of just "ldap", "sql sql-module" instead of just "sql". Unless there's a reason for not doing so because of the codebase.) On Jun 21, 2008, at 7:24 PM, Pete Kay wrote:

Hi,

I don't know this is right or not, here is what I did:

1. Add the following cluase to the module section of radiusd.conf:

execbill {

program = "lua /home/anne/billing.lua %{Acct-Session-Id}"

input_pairs = request output_pairs = reply

}

2. Add execbill under the accounting section of sites-available/ default accounting { detail radutmp sql sql_log attr_filter.accounting_response execbill

}

When I started radiux-X, I am getting the following error:

/usr/local/etc/raddb/radiusd.conf[604]: Failed to link to module 'rlm_execbill': rlm_execbill.so: cannot open shared object file: No such file or directory /usr/local/etc/raddb/sites-enabled/default[355]: Failed to find module "execbill". /usr/local/etc/raddb/sites-enabled/default[314]: Errors parsing accounting section. } } Errors initializing modules

What did I do wrong?

Thanks alot for all your help.

Regards, Pete

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

On Jun 21, 2008, at 10:50 PM, Alan DeKok wrote:

Chris wrote:

...

See Also "exec echo" just below "exec". As I understand it, that's how you say, "I'm defining an exec module called 'execbill'."

Which is documented in the "modules" section of "radiusd.conf". Which is shown in the "echo" example, which he was told to read.

...

(IMHO, the default config could eliminate some of this frequent confusion if it were changed to, say, "ldap ldap-module" instead of just "ldap", "sql sql-module" instead of just "sql".

Maybe. But no amount of documentation will help people who get told to read it... and then don't.

Perhaps users should be expected to go read source code comments to figure out what's going on, too. FreeRADIUS is a gem, to be sure, and it continues to help me make money, but I've configured a lot of services over the years and the FreeRADIUS "documentation," frankly, sucks. This fact is "documented" by the lack of a "Documentation" tab or link on www.freeradius.org. Chris

Hi,

FreeRADIUS is a gem, to be sure, and it continues to help me make money, but I've configured a lot of services over the years and the FreeRADIUS "documentation," frankly, sucks.

hmm, FreeRADIUS makes you money....and you get all the support from us, this list, and the free wiki etc for free. and yet you are happy to complain about the documentation without contributing to your source of income? nice. alan

Arran Cudbard-Bell wrote:

No, the man pages are just fine. The problem here is the documentation often assumes a knowledge of the protocol / supporting RFCs. Either people are too stupid/ lazy to go out and find the information themselves, or they've lost the basic ability to learn things without being spoon-fed.

I don't expect people to understand every RADIUS detail. I *do* expect people to be able to read things... when told what to read. I've given up expecting the complainers to contribute anything. There's a *strong* correlation between people who complain, and people who don't contribute. The people who *do* contribute say things like "this thing annoyed me, so here's the fix." I'll take that any day over empty complaints.

This guys crappy attitude aside, the wiki could use a bit of an overhaul. All the 1.* stuff needs stripping out or marking as such, because it's getting confusing.

Ubuntu managed to ship 8.04 (LTS) with 1.1.7. This means that 1.1.7 will be included in Ubuntu 8.04 for the next 3 years.

Could each take a few sections? It's a bit much for one person to tackle by themselves.

I'm going to put the ~200 pages of my book up on deployingradius.com. I'll post an announcement later this week. Alan DeKok.

Chris wrote:

So if possibly improving inherent clarity in the default config nets a "why bother, nobody'll read it anyway" from you, why should anyone else care?

Nice try. The module configuration is documented in radiusd.conf, in the "modules" section. It explains clearly the syntax and behavior of the module configuration. It is further documented in the files in the "doc" directory, and in the example module configurations (modules/ directory in 2.0.5, or radiusd.conf in other versions.) Your suggestion to duplicate the documentation in *more* places is not helpful. Especially since your original complaint was in response to someone who was told *what* to read, and *where* to read it... and still had issues. Please demonstrate how adding *more* documentation will help people who don't read the existing documentation that they're told to read. Use examples. Please. The real issue is you got caught. You have vocal complaints about a product that until now, you've refused to contribute to... despite profiting from it. When this was pointed out, you searched desperate for some justifaction to "prove" that any contribution wouldn't be accepted.... and got caught again. Submit a *useful* patch, and it will go in. Until then, please continue to profit from a project that "sucks". A project to which you've contributed nothing. The sheer hypocrisy of that position should be evident to everyone. Alan DeKok.

Have a look at CVS. If it's there, it will be in 2.0.6. Ivan Kalik Kalik Informatika ISP Dana 22/6/2008, "Tuc at T-B-O-H.NET" <ml@t-b-o-h.net> piše:

...

Submit a *useful* patch, and it will go in. Until then, please continue to profit from a project that "sucks". A project to which you've contributed nothing. The sheer hypocrisy of that position should be evident to everyone.

So does this mean that bug 517, which includes code which looks reasonable, and has been tested in my setup (For what thats worth) submitted on Feb 8, 2008... And missed the 2.0.2 version (Not sure when freeze was for that, since it was less than a week later)... And missed :

17 March 2008 - Version 2.0.3

30 April 2008 - Version 2.0.4

7 June 2008 - Version 2.0.5

will definitely make a 2.0.6 release?

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

On Jun 22, 2008, at 9:53 AM, Alan DeKok wrote:

Chris wrote:

...

So if possibly improving inherent clarity in the default config nets a "why bother, nobody'll read it anyway" from you, why should anyone else care?

Nice try.

The module configuration is documented in radiusd.conf, in the "modules" section. It explains clearly the syntax and behavior of the module configuration. It is further documented in the files in the "doc" directory, and in the example module configurations (modules/ directory in 2.0.5, or radiusd.conf in other versions.)

Your suggestion to duplicate the documentation in *more* places is not helpful. Especially since your original complaint was in response to someone who was told *what* to read, and *where* to read it... and still had issues.

Please demonstrate how adding *more* documentation will help people who don't read the existing documentation that they're told to read. Use examples. Please.

I'm not suggesting more documentation. I'm suggesting modules in the default config be defined in a consistent manner for, well, consistency and clarity. Thus making that segment of the documentation less necessary. Instead of: modules { sql { } sql another-sql-module { } } It would be more clear to eliminate the dual syntax of defining modules with something like this: modules { sql sql-module { } sql another-sql-module { } } Then when someone cuts and pastes a default config module to modify, they just might key into the fact that they need to define an sql module named x-sql-module without having to go to the documentation at all.

The real issue is you got caught. You have vocal complaints about a product that until now, you've refused to contribute to... despite profiting from it. When this was pointed out, you searched desperate for some justifaction to "prove" that any contribution wouldn't be accepted.... and got caught again.

You know, before deploying this time around I searched for a way to make a monetary contribution and came up empty. I then decided I would wait for the book and buy that but there isn't one.

Submit a *useful* patch, and it will go in. Until then, please continue to profit from a project that "sucks". A project to which you've contributed nothing. The sheer hypocrisy of that position should be evident to everyone.

I might very well take the time to make these changes to the default config and submit patches, but it'd obviously be a waste of time because you've already determined such changes are useless, or at least not *useful*. Actually, I said the software was a "gem". It's the "config file comments as a substitute for documentation" that sucks.