Re: (RADIATOR) AcctSQLStatement ONLY AuthBy?
El 28 Jul 2001, a las 19:36, Hugh Irvine escribió: Hello Mariano - You can do what you describe too, by using the AccountingStartsOnly, AccountingStopsOnly and AccountingAlivesOnly tags in the AuthBy SQL clause. That was (and still is) my intention... the only thing that worried my was the following paragraph from section 6.26 of the 2.18.2 release manual (see underlines under a fixed text viewer): When AuthBy SQL receives an Accounting-Request message, it can store any number of the attributes from the request in an SQL table. You can control the table it stores in, and the names of the columns where the attributes are stored, and the attribute that is stored there. To enable SQL ^ accounting you must define AccountingTable and you must define at least ^^^ one AcctColumnDef. If you don't do both of these AuthBy SQL will acknowledge Accounting-Request message but will not store them anywhere. The example goodies/sql.cfg in the Radiator distribution shows a typical setup that will work with the table schemas in the goodies directory. Re-reading this, this is, in fact true since, in this specific AuthBy, I am not storing them anywhere, but I am doing something else besides aknowledging them. Have a look at section 6.26 in the Radiator manual. From doing this I got the original doubt :-) regards Thanx for your help... Hugh At 15:22 -0300 01/7/27, Mariano Absatz wrote: El 27 Jul 2001, a las 9:17, Hugh Irvine escribió: Hello Mariano - Yes you can certainly have any number of AcctSQLStatement's without an AccountingTable and AcctColumnDef's. You might want to think about using Handlers to process your requests. Something like this: # define Handler to process accounting stops Handler Acct-Status-Type = Stop . /Handler # define Handler to process other accounting requests Handler Request-Type = Accounting-Request . /Handler Yes... but nonetheless, I want to apply all of the processing of Handler Request- Type = Accounting-Request to the same packets that also match Handler Acct- Status-Type = Stop and it is cleaner (at least for my eye) if I have one AuthBy OnlyDoThisWithStops and one AuthBy DoThisWithEveryAcctPack and use both in the Handler Request-Type = Accounting-Request. # define Handlers for everything else Handler . . /Handler Handler . /Handler hth Hugh On Friday 27 July 2001 03:20, Mariano Absatz wrote: Hi, is it possible to have an AuthBy SQL that doesn't even have AccountingTable and AcctColumnDef, but only AcctSQLStatement? The manual seems to say no. Here's what I want to do: I already have my main accounting only AuthBy SQL that processes Start's Stop's and, if they are there, Alive's. Now I want to do a couple of AcctSQLStatement's but I want them only to be executed when I get a Stop packet (to do time-block and also byte-block) I want to use AccountingStopsOnly in my new AuthBy SQL especially trying to avoid Alive packets that would make accumulative substract time when I shouldn't. I don't want to ignore altogether alive packets because billing will use them if the Stop packet gets lost... Any ideas? -- Mariano Absatz El Baby -- Not the brightest crayon in the box now, are we? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) AcctSQLStatement ONLY AuthBy?
Hello Mariano - The lines in the manual that you highlight refer to the automatic generation of the default SQL query for handling accounting requests. The AccountingTable and the AcctColumnDef's are combined to produce the query. The AcctSQLQuery's are completely independent and can be used to do anything. This is from section 6.26.13 in the manual: This parameter allows you to execute arbitrary SQL statements each time an accounting request is received. Do you think we should make the manual clearer? regards Hugh At 11:27 -0300 01/7/31, Mariano Absatz wrote: El 28 Jul 2001, a las 19:36, Hugh Irvine escribió: Hello Mariano - You can do what you describe too, by using the AccountingStartsOnly, AccountingStopsOnly and AccountingAlivesOnly tags in the AuthBy SQL clause. That was (and still is) my intention... the only thing that worried my was the following paragraph from section 6.26 of the 2.18.2 release manual (see underlines under a fixed text viewer): When AuthBy SQL receives an Accounting-Request message, it can store any number of the attributes from the request in an SQL table. You can control the table it stores in, and the names of the columns where the attributes are stored, and the attribute that is stored there. To enable SQL ^ accounting you must define AccountingTable and you must define at least ^^^ one AcctColumnDef. If you don't do both of these AuthBy SQL will acknowledge Accounting-Request message but will not store them anywhere. The example goodies/sql.cfg in the Radiator distribution shows a typical setup that will work with the table schemas in the goodies directory. Re-reading this, this is, in fact true since, in this specific AuthBy, I am not storing them anywhere, but I am doing something else besides aknowledging them. Have a look at section 6.26 in the Radiator manual. From doing this I got the original doubt :-) regards Thanx for your help... Hugh At 15:22 -0300 01/7/27, Mariano Absatz wrote: El 27 Jul 2001, a las 9:17, Hugh Irvine escribió: Hello Mariano - Yes you can certainly have any number of AcctSQLStatement's without an AccountingTable and AcctColumnDef's. You might want to think about using Handlers to process your requests. Something like this: # define Handler to process accounting stops Handler Acct-Status-Type = Stop . /Handler # define Handler to process other accounting requests Handler Request-Type = Accounting-Request . /Handler Yes... but nonetheless, I want to apply all of the processing of Handler Request- Type = Accounting-Request to the same packets that also match Handler Acct- Status-Type = Stop and it is cleaner (at least for my eye) if I have one AuthBy OnlyDoThisWithStops and one AuthBy DoThisWithEveryAcctPack and use both in the Handler Request-Type = Accounting-Request. # define Handlers for everything else Handler . . /Handler Handler . /Handler hth Hugh On Friday 27 July 2001 03:20, Mariano Absatz wrote: Hi, is it possible to have an AuthBy SQL that doesn't even have AccountingTable and AcctColumnDef, but only AcctSQLStatement? The manual seems to say no. Here's what I want to do: I already have my main accounting only AuthBy SQL that processes Start's Stop's and, if they are there, Alive's. Now I want to do a couple of AcctSQLStatement's but I want them only to be executed when I get a Stop packet (to do time-block and also byte-block) I want to use AccountingStopsOnly in my new AuthBy SQL especially trying to avoid Alive packets that would make accumulative substract time when I shouldn't. I don't want to ignore altogether alive packets because billing will use them if the Stop packet gets lost... Any ideas? -- Mariano Absatz El Baby -- Not the brightest crayon in the box now, are we? === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- NB: I am travelling this week, so there may be delays in our correspondence. Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at
Re: (RADIATOR) AcctSQLStatement ONLY AuthBy?
Hello Mariano - You can do what you describe too, by using the AccountingStartsOnly, AccountingStopsOnly and AccountingAlivesOnly tags in the AuthBy SQL clause. Have a look at section 6.26 in the Radiator manual. regards Hugh At 15:22 -0300 01/7/27, Mariano Absatz wrote: El 27 Jul 2001, a las 9:17, Hugh Irvine escribió: Hello Mariano - Yes you can certainly have any number of AcctSQLStatement's without an AccountingTable and AcctColumnDef's. You might want to think about using Handlers to process your requests. Something like this: # define Handler to process accounting stops Handler Acct-Status-Type = Stop . /Handler # define Handler to process other accounting requests Handler Request-Type = Accounting-Request . /Handler Yes... but nonetheless, I want to apply all of the processing of Handler Request- Type = Accounting-Request to the same packets that also match Handler Acct- Status-Type = Stop and it is cleaner (at least for my eye) if I have one AuthBy OnlyDoThisWithStops and one AuthBy DoThisWithEveryAcctPack and use both in the Handler Request-Type = Accounting-Request. # define Handlers for everything else Handler . . /Handler Handler . /Handler hth Hugh On Friday 27 July 2001 03:20, Mariano Absatz wrote: Hi, is it possible to have an AuthBy SQL that doesn't even have AccountingTable and AcctColumnDef, but only AcctSQLStatement? The manual seems to say no. Here's what I want to do: I already have my main accounting only AuthBy SQL that processes Start's Stop's and, if they are there, Alive's. Now I want to do a couple of AcctSQLStatement's but I want them only to be executed when I get a Stop packet (to do time-block and also byte-block) I want to use AccountingStopsOnly in my new AuthBy SQL especially trying to avoid Alive packets that would make accumulative substract time when I shouldn't. I don't want to ignore altogether alive packets because billing will use them if the Stop packet gets lost... Any ideas? TIA -- Mariano Absatz El Baby -- The generation of random numbers is too important to be left to chance. -Robert R. Coveyou Oak Ridge National Laboratory === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. -- Mariano Absatz El Baby -- Error, no keyboard - press F1 to continue. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- NB: I am travelling this week, so there may be delays in our correspondence. Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, Interbiller, TACACS+, PAM, external, etc, etc. Available on Unix, Linux, FreeBSD, Windows 95/98/2000, NT, MacOS X. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) AcctSQLStatement ONLY AuthBy?
El 27 Jul 2001, a las 9:17, Hugh Irvine escribió: Hello Mariano - Yes you can certainly have any number of AcctSQLStatement's without an AccountingTable and AcctColumnDef's. You might want to think about using Handlers to process your requests. Something like this: # define Handler to process accounting stops Handler Acct-Status-Type = Stop . /Handler # define Handler to process other accounting requests Handler Request-Type = Accounting-Request . /Handler Yes... but nonetheless, I want to apply all of the processing of Handler Request- Type = Accounting-Request to the same packets that also match Handler Acct- Status-Type = Stop and it is cleaner (at least for my eye) if I have one AuthBy OnlyDoThisWithStops and one AuthBy DoThisWithEveryAcctPack and use both in the Handler Request-Type = Accounting-Request. # define Handlers for everything else Handler . . /Handler Handler . /Handler hth Hugh On Friday 27 July 2001 03:20, Mariano Absatz wrote: Hi, is it possible to have an AuthBy SQL that doesn't even have AccountingTable and AcctColumnDef, but only AcctSQLStatement? The manual seems to say no. Here's what I want to do: I already have my main accounting only AuthBy SQL that processes Start's Stop's and, if they are there, Alive's. Now I want to do a couple of AcctSQLStatement's but I want them only to be executed when I get a Stop packet (to do time-block and also byte-block) I want to use AccountingStopsOnly in my new AuthBy SQL especially trying to avoid Alive packets that would make accumulative substract time when I shouldn't. I don't want to ignore altogether alive packets because billing will use them if the Stop packet gets lost... Any ideas? TIA -- Mariano Absatz El Baby -- The generation of random numbers is too important to be left to chance. -Robert R. Coveyou Oak Ridge National Laboratory === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. -- Mariano Absatz El Baby -- Error, no keyboard - press F1 to continue. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) AcctSQLStatement ONLY AuthBy?
Hi, is it possible to have an AuthBy SQL that doesn't even have AccountingTable and AcctColumnDef, but only AcctSQLStatement? The manual seems to say no. Here's what I want to do: I already have my main accounting only AuthBy SQL that processes Start's Stop's and, if they are there, Alive's. Now I want to do a couple of AcctSQLStatement's but I want them only to be executed when I get a Stop packet (to do time-block and also byte-block) I want to use AccountingStopsOnly in my new AuthBy SQL especially trying to avoid Alive packets that would make accumulative substract time when I shouldn't. I don't want to ignore altogether alive packets because billing will use them if the Stop packet gets lost... Any ideas? TIA -- Mariano Absatz El Baby -- The generation of random numbers is too important to be left to chance. -Robert R. Coveyou Oak Ridge National Laboratory === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) AcctSQLStatement ONLY AuthBy?
Hello Mariano - Yes you can certainly have any number of AcctSQLStatement's without an AccountingTable and AcctColumnDef's. You might want to think about using Handlers to process your requests. Something like this: # define Handler to process accounting stops Handler Acct-Status-Type = Stop . /Handler # define Handler to process other accounting requests Handler Request-Type = Accounting-Request . /Handler # define Handlers for everything else Handler . . /Handler Handler . /Handler hth Hugh On Friday 27 July 2001 03:20, Mariano Absatz wrote: Hi, is it possible to have an AuthBy SQL that doesn't even have AccountingTable and AcctColumnDef, but only AcctSQLStatement? The manual seems to say no. Here's what I want to do: I already have my main accounting only AuthBy SQL that processes Start's Stop's and, if they are there, Alive's. Now I want to do a couple of AcctSQLStatement's but I want them only to be executed when I get a Stop packet (to do time-block and also byte-block) I want to use AccountingStopsOnly in my new AuthBy SQL especially trying to avoid Alive packets that would make accumulative substract time when I shouldn't. I don't want to ignore altogether alive packets because billing will use them if the Stop packet gets lost... Any ideas? TIA -- Mariano Absatz El Baby -- The generation of random numbers is too important to be left to chance. -Robert R. Coveyou Oak Ridge National Laboratory === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets: internetwork inventory and management - graphical, extensible, flexible with hardware, software, platform and database independence. === Archive at http://www.open.com.au/archives/radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
