on good manners and profitting from open source.... (was re: [Fwd: Re: (RADIATOR) Adding an attribute Post Handler])
Hi, FWIW, and not trying to start a flame war here, I'd like to comment on this message. Brian, I didn't read a book on good manners, although I think _I_ am not especially bad mannered. I _do_ know a lot about internet mailing lists, especially technical support mailing lists. Either for paid, unpaid, open, or close source software (and then some...). I _do_ know quite something about netiquette and e-mail... and know that it is considered unpolite (or bad manners) to send messages to a tech support mailing list without browsing the archives before, so as to know the standards of interaction in the list. I've been using Radiator, configuring it for large customers, developing systems that use it, and giving support about it for two and a half year. I am subscribed to the list since before we bought it, I just searched through my radiator list folder and found a couple dozens of messages from Hugh asking someone which company had paid for the copy of Radiator, so it's customary of the list and, hence, I wouldn't consider it bad manners. OTOH, regarding the way in which Radiator is sold, distributed and supported, I can only state that I envy OSC for being able to profit (or at least survive, I don't know a thing about how healthy the company is) in such a clever way from open software, and I envy Hugh and Mike for working there. Radiator is open source or free source (with free as in freedom, not for $0) since it's distributed with full source code, very well documented and the code is quite clean and understandable (I even fiddled with it and modified a couple of things, and I'm quite far from being a perl wizard). The price is quite reasonable and includes perpetual software updates and free mailing list support. The documentation is great and the free (as in for $0) support customers receive on the mailing list is way better than ANY customer support I'v ever seen in the industry, paid or unpaid, for paid or unpaid software or hadware... go find out how much big companies (Oracle, Informix, Microsoft) charge for support contracts, and then (if you have the resources), pay for it and see if it is half as good as the mailing list support Hugh and Mike provide. More than once I found a problem on the software, or asked for a feature and I had a patch with the bug-fix or the feature in my mailbox in less than a day (considering I'm in the other side of the world and Mike and Hugh sleep while I work and vice-versa). First time we bought Radiator, as we had to give personalized 7x24 support to a large ISP for it, we bought the unlimited e-mail support contract, just in case. Anyway, for any problem or doubt I had, I started (as usual) with the mailing list... the net result was that I never, ever, had to use the paid support, since the free support is top noch. Now, Radiator is distributed with FULL-SOURCE, no encrypted parts (except in the free demo), no serialization and no shit that would upset a legit customer. Nothing, except legality, ethics and shame, prevents me from downloaded my licensed unpersonalized copy and re-sell it, re-distribute it or pirate it in any way. Nothing but good faith prevents me from using my 2-7 servers copy in 2,000 servers. So what anti-piracy scheme does OSC use? they plain check that the domain for the e-mail address of someone asking questions who doesn't seem to be testing the free demo, corresponds to one of the copies the sold at one time in the past. If they can't match it, they simply ask the user... let's say Radiator's anti- piracy mechanism only disables the free e-mail list support. If the automatic check fails, you can enable it with a simple mail message (the software itself, however, is free from anti-piracy nonsense). El 24 Jan 2003 a las 5:08, [EMAIL PROTECTED] escribió: Hello Hugh - I will be happy to send you the name of our company, which has indeed purchased this copy of radiator. Can you please send me the name of the registered company who published the book you own on manners? If you can't find it, I'll be happy to send one of those too. bja Brian Acosta i-55 internet services -- Mariano Absatz El Baby -- This message transmitted on 100% recycled electrons. === 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) (Fwd) Last Call: Diameter Base Protocol to Proposed Standard
FYI, according to this message, the diameter protocol (the expected successor to radius) is being issued as a Proposed Standard RFC... The RFC should be available in a few days, anyway, it should't differ from the draft in http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-15.txt I've read a very early version of the draft (months ago) and it's a totally different beast... supposedly more flexible confiable, but time will tell... we also have to see what kind of support it gets from the NAS vendors... Regards --- Forwarded message follows --- To: IETF-Announce:; CC: [EMAIL PROTECTED] From: The IESG [EMAIL PROTECTED] Subject:Last Call: Diameter Base Protocol to Proposed Standard Reply-to: [EMAIL PROTECTED] Date: Tue, 22 Oct 2002 13:57:47 -0400 Sender: [EMAIL PROTECTED] The IESG has received a request from the Authentication, Authorization and Accounting Working Group to consider Diameter Base Protocol draft-ietf-aaa-diameter-15.txt as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by 2002-11-5. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-15.txt --- End of forwarded message --- -- Mariano Absatz El Baby -- I thought I wanted a career, turns out I just wanted pay checks. === 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) long regular expressions in Handler
Hi Hugh, Mike,
I have a bunch of Handlers that catch calls to different phone numbers
(Called-Station-Id) through a regular expression that is quite large ('bout
200 chars) of the form:
Handler Called-Station-Id=/$|$|^1234567$|...lots more...|^5556736$/
AuthBy something
/Handler
This works just fine, but it's a little hard to see and mantain...
I was wondering about a couple of things:
1) Can I use multiline Perl regular expressions with comments using /x?
2) Can I handle this somehow via an include?
1) could be something like:
Handler Called-Station-Id=/$ # calling to provider 1
|$ # calling to provider 2
|^1234567$ # calling to provider sortie
|...lots more...
|^5556736$ # calling to 555-OPEN
/
AuthBy something
/Handler
Could this work? Do I have to put the \ at the end of each line?
What about option 2)? It would be something similar but maybe written in a
file and assigned like:
Handler file:handler1.txt
AuthBy something
/Handler
or maybe:
DefineFormattedGlobalVar handler1DNIS file:handler1.txt
Handler Called-Station-Id=/{GlobalVar:handler1DNIS}/
AuthBy something
/Handler
or this is totally nuts :-(
TIA.
--
Mariano Absatz
El Baby
--
Beware of programmers with screwdrivers.
===
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: Fwd: (RADIATOR) Request feature: DictionaryFileList
Yess!!! I've said this before... but I'll say it again... you WON'T get anything even remotely close to this kind of customer support in any product at any price! Thanx once again Mike! El 18 Sep 2002 a las 10:06, Mike McCauley escribió: Hi All, Some good ideas here. We have now uploaded patches for radiusd, radpwtst and RDict.pm that allows you to specifiy multiple comma-separated dictionary files, like: radpwtst -dictionary dict1,dict2 radiusd -dictionary_file dict1,dict2 or in radiator config DictionaryFile %D/dictionary,%D/site.dictionary Hope that helps. Cheers. Begin forwarded message: From: Dave Kitabjian [EMAIL PROTECTED] Date: Wed Sep 18, 2002 5:32:19 AM Australia/Melbourne To: Mariano Absatz [EMAIL PROTECTED], Radiator Mailinglist [EMAIL PROTECTED] Cc: Fabian Salgado [EMAIL PROTECTED] Subject: RE: (RADIATOR) Request feature: DictionaryFileList I like this idea. I'd much rather have all my custom dictionary entries in a separate, concise file. Dave -Original Message- From: Mariano Absatz [mailto:[EMAIL PROTECTED]] Sent: Monday, September 16, 2002 4:34 PM To: Radiator Mailinglist Subject: (RADIATOR) Request feature: DictionaryFileList Hi Hugh, Mike, everytime I have a new Radiator setup, you get this awful bunch of requests and comments :-P Now to business... I normally use the standard latest dictionary file included in Radiator, but many times, I have to add a couple of attributes either from one of the other dictionaries or other vendor-specific that we develop for custom applications (yes we do have and use our own public vendor number). It'd be nice if I could specify more than one file in DictionaryFile and that the actual dictionary be made from the concatenation of those files like: DictionaryFileList ./dictionary ./dictionary.local ./dictionary.redback In fact, that would allow you to decouple all the specialized dictionaries erasing all the common attributes and values... I'll be bothering you more any time soon ;-) -- Mariano Absatz El Baby -- I'm not a complete idiot, some parts are missing! === 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. -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS, TTLS etc on Unix, Windows, MacOS etc. === 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. -- Mariano Absatz El Baby -- Friends help you move. Real friends help you move bodies. === 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) wrapping up on parametrizing AuthBy's
Hi Hugh,
I'd like to recap and see if this thing I did after your suggestions would
work:
### radius.cfg START #
AuthBy LOADBALANCE
Identifier ProxyStandard
NoDefault
# Para cada Faked-Attribute que se setea en los Handler
# se deberan crear archivos ParamXXX y HostsXXX en el directorio
# /usr/local/radiator/etc
include %D/Param%{Reply:Faked-Attribute}.cfg
include %D/Hosts%{Reply:Faked-Attribute}.cfg
AcctFailedLogFileName \
%L/ACCT-LOST/%{Reply:Faked-Attribute}/%Y-%m-%d.log
StripFromReply Faked-Attribute
/AuthBy
# Kind01 Handler
Handler Called-Station-Id=/$|^123456$/
Identifier Handler01
RewriteUsername s/^([^@]+).*/$1/
AddToReply Faked-Attribute=Kind01
AuthBy ProxyStandard
/Handler
# Kind02 Handler
Handler Called-Station-Id=/$|^654321$/
Identifier Handler02
RewriteUsername s/^([^@]+).*/$1/
AddToReply Faked-Attribute=Kind02
AuthBy ProxyStandard
/Handler
# Kind03
Handler Realm=/^whatever.com$/
Identifier Handler03
AddToReply Pert-Service-Code=Kind03
AuthBy ProxyStandard
/Handler
radius.cfg END ##
The idea is that I have separate files for specific parameters, for instance:
### ParamKind01.cfg START #
SessionDatabase ProxySession
AcctLogFileName %L/Accounting%{Reply:Faked-Attribute}.log
AuthLog FILE
FileName %L/Auth%{Reply:Faked-Attribute}.log
LogSuccess 1
LogFailure 1
SuccessFormat %l:POST:%U:%N:OK-%{Reply:Code}:%{Handler:Identifier}
FailureFormat %l:POST:%U:%N:FAIL-%{Reply:Code}:%{Handler:Identifier}
/AuthLog
ParamKind01.cfg END ##
### HostsKind01.cfg START #
Host 1.2.3.4
AuthPort 1645
AcctPort 1646
Secret
RetryTimeout 1
Retries 0
/Host
Host 1.2.3.4
AuthPort 1812
AcctPort 1813
Secret
RetryTimeout 1
Retries 0
/Host
Host 1.2.3.5
AuthPort 1645
AcctPort 1646
Secret
RetryTimeout 3
Retries 0
/Host
Host 1.2.3.5
AuthPort 1812
AcctPort 1813
Secret
RetryTimeout 3
Retries 0
/Host
HostsKind01.cfg END ##
Supposedly, HostsParam02.cfg may have different settings and HostsKind02.cfg
will have a different set of hosts.
And so on...
Will this kind of dynamic stuff work? Or can you think of another way to do
it?
TIA
--
Mariano Absatz
El Baby
--
Late one night in the middle of the day, two dead
soldiers got up to fight. Back to back they faced
each other, pulled out their swords and shot one
another. A deaf policeman heard the noise, got up
and shot the twice dead boys. If you don't believe
me, ask the blind man who saw it all, through a
knothole in a wooden brick wall.
===
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) %{Handler:name}
El 10 Sep 2002 a las 9:27, Hugh Irvine escribió:
Hello Mariano -
The way that Radiator is designed allows you to specify a single AuthBy
clause and call it from multiple Handlers, using special characters for
the parameters, rather than specifying many different AuthBy clauses.
The special characters most often used are GlobalVars that have been
defined in the configuration file itself, or passed in from the command
line.
But how could I parametrize them on a handler by handler basis within the
same config file...
As far as I see, the AuthBy Identifier-name doesn't allow any parameters
to be passed from the Handler to the AuthBy... or does it?
What else (besides Identifier) can I use in a %{Handler:name} within an
AuthBy?
What is the scope of GlobalVar and when are they set?
That is, if I have the following:
==
Handler
Identifier foo
DefineFormattedGlobalVar host abc
AuthBy MyAuthby
/Handler
Handler
Identifier bar
DefineFormattedGlobalVar host xyz
AuthBy MyAuthby
/Handler
AuthBy Radius
Identifier MyAuthby
Host %{GlobalVar:host}
/AuthBy
==
Will it proxy to host abc if it comes from handler and to host xyz if it
comes from handler ?
Note that for proxy radius targets, Radiator now supports the AuthBy
SQLRADIUS clause that allows you to maintain your target hosts in an SQL
database.
regards
Hugh
On Tuesday, September 10, 2002, at 06:16 AM, Mariano Absatz wrote:
El 6 Sep 2002 a las 9:42, Hugh Irvine escribió:
Hello Mariano -
I'm afraid I dont quite understand what you are wanting to do.
Could you give me a bit more detail?
Yup.
I'm trying to generalize the way I write very similar proxies where
maybe the only thing that
changes is the proxied hosts/ports and where I log accounting
failures...
Since this stuff goes in a different AuthBy Radius (or AuthBy
LOADBALANCE for that
matter), I want to name (via Identifier) each AuthBy and be able to
recall that name within
the AuthBy...
In the manual (http://www.open.com.au/radiator/ref.html#pgfId=291148) I
see that I can find
out which client triggered a clause (%{Client:name}) and which handler
did so
(%{Handler:name}), but I might have several clients and several
handlers going to the same
AuthBy and the AuthBy itself would be the selector.
Let's go by example...
Suppose I currently have the following in my config file:
===START OF (portion of)
RADIUS.CFG==
AuthBy LOADBALANCE
Identifier Kind01
Retries 1
Host 22.33.44.55
Secret
AuthPort
AcctPort
/Host
Host 22.33.44.66
Secret asdf
AuthPort 2321
AcctPort 1234
/Host
AcctFailedLogFileName %L/ACCT-LOST/Kind01/%Y-%m-%d.log
/AuthBy
AuthBy LOADBALANCE
Identifier Kind02
Retries 3
Host 22.33.44.55
Secret
AuthPort 2231
AcctPort 2311
/Host
Host 22.33.44.66
Secret qwert
AuthPort
AcctPort
/Host
AcctFailedLogFileName %L/ACCT-LOST/Kind02/%Y-%m-%d.log
/AuthBy
END OF (portion of)
RADIUS.CFG===
I would like to change this to:
==START OF (portion of)
NEWRADIUS.CFG
AuthBy LOADBALANCE
Identifier Kind01
include %D/Retries%{AuthName:Identifier}.cfg
include %D/Hosts%{AuthName:Identifier}.cfg
AcctFailedLogFileName %L/ACCT-LOST/%{AuthName:Identifier}/%Y-%m-%d.log
/AuthBy
AuthBy LOADBALANCE
Identifier Kind02
include %D/Retries%{AuthName:Identifier}.cfg
include %D/Hosts%{AuthName:Identifier}.cfg
AcctFailedLogFileName %L/ACCT-LOST/%{AuthName:Identifier}/%Y-%m-%d.log
/AuthBy
===END OF (portion of)
NEWRADIUS.CFG=
==START OF RetriesKind01.cfg
Retries 1
===END OF RetriesKind01.cfg=
==START OF HostsKind01.cfg
Host 22.33.44.55
Secret
AuthPort
AcctPort
/Host
Host 22.33.44.66
Secret asdf
AuthPort 2321
AcctPort 1234
/Host
===END OF HostsKind01.cfg=
==START OF RetriesKind02.cfg
Retries 3
===END OF RetriesKind02.cfg=
==START OF HostsKind02.cfg
Host 22.33.44.55
Secret
AuthPort 2231
AcctPort 2311
/Host
Re: (RADIATOR) Attribute number 39087 (vendor 429)
Those that state (vendor XXX) are vendor specific attributes and thus, are defined by each vendor... You have to go to http://www.iana.org/assignments/enterprise-numbers and find the vendor number, in this case, you'll see: 429 3Com Carrier Systems Group. Bill Vroman [EMAIL PROTECTED] This means that these are propietary 3com attributes and you should go to 3com to find the meaning of each of this attributes... if you find out, it's considered polite within the list, to share them so the next version of Radiator, includes them. El 9 Sep 2002 a las 12:19, William Hernandez escribió: Hello everyone, We've been seeing the following in radius.log since Friday afternoon: Mon Sep 9 12:04:18 2002: ERR: Attribute number 39087 (vendor 429) is not defined in your dictionary Mon Sep 9 12:04:18 2002: ERR: Attribute number 39079 (vendor 429) is not defined in your dictionary Mon Sep 9 12:04:18 2002: ERR: Attribute number 39080 (vendor 429) is not defined in your dictionary I haven't found any dictionary that has these attributes. Are these valid attributes? Thanks in advance, William running Radiator 2.18.2 === 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. -- Mariano Absatz El Baby -- Double your drive space - delete Windows! === 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) Version 3.3 install
El 6 Sep 2002 a las 9:29, Hugh Irvine escribió: Hello Mariano, Hello Charly - Yes, my method allows you to use specific, different versions of Perl as well. All I do is this: cd /the/radiator/distribution /usr/local/src/Perl/Perl-/bin/perl Makefile.PL; make; make test Thanx, Huhg... would cd /the/radiator/distribution ../bin/perl Makefile.PL; make; make test make the perl installation used relative path dependant? or it would resolve the absolute path in the making? i.e: would I get #!../bin/perl at the top of my radiusd? .. then when I run Radiator I use the fully qualified path for both the perl instance I want and for the Radiator instance I want. cd /the/radiator/distribution; /usr/local/src/Perl/Perl-/bin/perl radiusd -config_file . Of course I usually use constants in shell scripts to make it easier (and sometimes symbolic links). cheers Hugh On Friday, September 6, 2002, at 07:26 AM, Mariano Absatz wrote: FTR, I also think it's A Good Thing(TM) to be able to have a special perl instalation for some critical perl programs or for programs with quite specific requirements... El 5 Sep 2002 a las 11:34, Karl Gaissmaier escribió: Hi Hugh and Mike, Hello Charly - What I usually do is skip the make install step altogether, and just leave the various versions in seperate directories. sounds reasonable for your environment but without a make install for example the path to the perl interpreter doesn't gets adjusted to the local requirements. Not all perl interpreters stay in /usr/bin/perl and there exists good reasons (at least for me) to use a totally own perl interpreter installation to get the different needed packages handled. Sure, I have also a perl interpreter under /usr/bin/perl but this is the interpreter with the standard set of installed modules for all workstations here. Anyway, I don't think this could be solved generally, but it should be discussed in the FAQ or in the reference guide. Thanks for discussing and this wonderful support. Charly -- Mariano Absatz El Baby -- I like cats too. Let's exchange recipes. === 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) %{Handler:name}
El 6 Sep 2002 a las 9:42, Hugh Irvine escribió:
Hello Mariano -
I'm afraid I dont quite understand what you are wanting to do.
Could you give me a bit more detail?
Yup.
I'm trying to generalize the way I write very similar proxies where maybe the only
thing that
changes is the proxied hosts/ports and where I log accounting failures...
Since this stuff goes in a different AuthBy Radius (or AuthBy LOADBALANCE for that
matter), I want to name (via Identifier) each AuthBy and be able to recall that name
within
the AuthBy...
In the manual (http://www.open.com.au/radiator/ref.html#pgfId=291148) I see that I can
find
out which client triggered a clause (%{Client:name}) and which handler did so
(%{Handler:name}), but I might have several clients and several handlers going to the
same
AuthBy and the AuthBy itself would be the selector.
Let's go by example...
Suppose I currently have the following in my config file:
===START OF (portion of) RADIUS.CFG==
AuthBy LOADBALANCE
Identifier Kind01
Retries 1
Host 22.33.44.55
Secret
AuthPort
AcctPort
/Host
Host 22.33.44.66
Secret asdf
AuthPort 2321
AcctPort 1234
/Host
AcctFailedLogFileName %L/ACCT-LOST/Kind01/%Y-%m-%d.log
/AuthBy
AuthBy LOADBALANCE
Identifier Kind02
Retries 3
Host 22.33.44.55
Secret
AuthPort 2231
AcctPort 2311
/Host
Host 22.33.44.66
Secret qwert
AuthPort
AcctPort
/Host
AcctFailedLogFileName %L/ACCT-LOST/Kind02/%Y-%m-%d.log
/AuthBy
END OF (portion of) RADIUS.CFG===
I would like to change this to:
==START OF (portion of) NEWRADIUS.CFG
AuthBy LOADBALANCE
Identifier Kind01
include %D/Retries%{AuthName:Identifier}.cfg
include %D/Hosts%{AuthName:Identifier}.cfg
AcctFailedLogFileName %L/ACCT-LOST/%{AuthName:Identifier}/%Y-%m-%d.log
/AuthBy
AuthBy LOADBALANCE
Identifier Kind02
include %D/Retries%{AuthName:Identifier}.cfg
include %D/Hosts%{AuthName:Identifier}.cfg
AcctFailedLogFileName %L/ACCT-LOST/%{AuthName:Identifier}/%Y-%m-%d.log
/AuthBy
===END OF (portion of) NEWRADIUS.CFG=
==START OF RetriesKind01.cfg
Retries 1
===END OF RetriesKind01.cfg=
==START OF HostsKind01.cfg
Host 22.33.44.55
Secret
AuthPort
AcctPort
/Host
Host 22.33.44.66
Secret asdf
AuthPort 2321
AcctPort 1234
/Host
===END OF HostsKind01.cfg=
==START OF RetriesKind02.cfg
Retries 3
===END OF RetriesKind02.cfg=
==START OF HostsKind02.cfg
Host 22.33.44.55
Secret
AuthPort 2231
AcctPort 2311
/Host
Host 22.33.44.66
Secret qwert
AuthPort
AcctPort
/Host
===END OF HostsKind02.cfg=
Although this leads to a profussion of files, they are all parsed at startup and this
allows
me to modify things on a per AuthBy basis and keep it clean... Maybe give some people
the
possibility to edit some files and other people to edit other files...
I might be dumb or crazy... but this kind of things helped me a lot in the past for
keeping
config files clean and ordered...
thanks
Hugh
On Friday, September 6, 2002, at 07:26 AM, Mariano Absatz wrote:
Hi Hugh, long time no see...
I'm planning an installation with a bunch of front-end Radiator proxies
(using AuthBy LOADBALANCE) to an(other) bunch of Radiator back-end
servers
that do the actual authentication against SQL servers.
Now, the front-end farm has the dispatching intelligence and the
back-end,
the authentication intelligence...
By dispatching I mean:
if it comes from such and such a NAS authenticate using of these
back-end
servers
if the realm matches xxx authenticate against these bunch of back-ends
etc...
I'm trying to generalize as much as possible and want to have short and
easily manteinable config files, so I'm doing a bunch of identfied
AuthBy's
like this:
AuthBy LOADBALANCE
Identifier Kind01
include %{GlobalVar:ConfigDir}/RetriesKind01.cfg
include %{GlobalVar:ConfigDir}/HostsKind01.cfg
AcctFailedLogFileName %L/ACCT-LOST/Kind01/%Y-%m-%d.log
/AuthBy
This would be the AuthBy to use for the Kind01 kind of handlers
Re: (RADIATOR) Version 3.3 install
FTR, I also think it's A Good Thing(TM) to be able to have a special perl instalation for some critical perl programs or for programs with quite specific requirements... El 5 Sep 2002 a las 11:34, Karl Gaissmaier escribió: Hi Hugh and Mike, Hello Charly - What I usually do is skip the make install step altogether, and just leave the various versions in seperate directories. sounds reasonable for your environment but without a make install for example the path to the perl interpreter doesn't gets adjusted to the local requirements. Not all perl interpreters stay in /usr/bin/perl and there exists good reasons (at least for me) to use a totally own perl interpreter installation to get the different needed packages handled. Sure, I have also a perl interpreter under /usr/bin/perl but this is the interpreter with the standard set of installed modules for all workstations here. Anyway, I don't think this could be solved generally, but it should be discussed in the FAQ or in the reference guide. Thanks for discussing and this wonderful support. Charly -- Karl Gaissmaier Computing Center,University of Ulm,Germany Email:[EMAIL PROTECTED] Network Administration Tel.: ++49 731 50-22499 === 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. -- Mariano Absatz - El Baby mailto:[EMAIL PROTECTED] http://www.baby.com.ar/ PGP KEYS: http://www.baby.com.ar/datos/personales.html#claves_pgp |\ _ _\\/' Powered by Pegasus Mail /|__) http://www.pmail.com ) )\ === 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) %{Handler:name}
Hi Hugh, long time no see...
I'm planning an installation with a bunch of front-end Radiator proxies
(using AuthBy LOADBALANCE) to an(other) bunch of Radiator back-end servers
that do the actual authentication against SQL servers.
Now, the front-end farm has the dispatching intelligence and the back-end,
the authentication intelligence...
By dispatching I mean:
if it comes from such and such a NAS authenticate using of these back-end
servers
if the realm matches xxx authenticate against these bunch of back-ends
etc...
I'm trying to generalize as much as possible and want to have short and
easily manteinable config files, so I'm doing a bunch of identfied AuthBy's
like this:
AuthBy LOADBALANCE
Identifier Kind01
include %{GlobalVar:ConfigDir}/RetriesKind01.cfg
include %{GlobalVar:ConfigDir}/HostsKind01.cfg
AcctFailedLogFileName %L/ACCT-LOST/Kind01/%Y-%m-%d.log
/AuthBy
This would be the AuthBy to use for the Kind01 kind of handlers...
Is there a way to have a per AuthBy special that has the AuthBy
Identfier? That is... a kind of %{LocalVar:} where the locality is wrt
the AuthBy...
Would %{Handler:Identifier} do that? or that would give me the Identifier of
the Handler that called this AuthBy?
Otherwise, would something along the lines of this work?:
AuthBy LOADBALANCE
DefineFormattedGlobalVar KIND Kind01
Identifier %{GlobalVar:KIND}
include %{GlobalVar:ConfigDir}/Retries%{GlobalVar:KIND}.cfg
include %{GlobalVar:ConfigDir}/Hosts%{GlobalVar:KIND}.cfg
AcctFailedLogFileName %L/ACCT-LOST/%{GlobalVar:KIND}/%Y-%m-%d.log
/AuthBy
AuthBy LOADBALANCE
DefineFormattedGlobalVar KIND Kind02
Identifier %{GlobalVar:KIND}
include %{GlobalVar:ConfigDir}/Retries%{GlobalVar:KIND}.cfg
include %{GlobalVar:ConfigDir}/Hosts%{GlobalVar:KIND}.cfg
AcctFailedLogFileName %L/ACCT-LOST/%{GlobalVar:KIND}/%Y-%m-%d.log
/AuthBy
TIA.
--
Mariano Absatz
El Baby
--
It said, Insert disk #3, but only two will fit!
===
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) CERT Advisory CA-2002-03: Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)
Hi Mike, Hugh, I've been reading about the vulnerabilities found in most SNMP's implementations (see http://www.cert.org/advisories/CA-2002-03.html). Do you know if the SNMP_Session module used by Radiator is affected by this? If so, is there any recent version that is not affected? I've been browsing http://www.switch.ch/misc/leinen/snmp/perl/ but I didn't find any info about it (or even a mailing list, though I see Mike contributes to the package every now and then). TIA -- Mariano Absatz El Baby -- Computer analyst to programmer: 'You start coding. I'll go find out what they want.' === 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) Radiator going down after Oracle SQL Timeout
: SNMPAgent: received request from 192.168.1.2, 128, 261688663, snmp-community Wed Jan 30 01:41:44 2002: DEBUG: SNMPAgent: received request from 192.168.1.2, 128, 1050711131, snmp-community Wed Jan 30 01:46:44 2002: DEBUG: SNMPAgent: received request from 192.168.1.2, 128, 1153891048, snmp-community Wed Jan 30 01:46:46 2002: DEBUG: SNMPAgent: received request from 192.168.1.2, 128, 1153891048, snmp-community Wed Jan 30 01:47:16 2002: DEBUG: Packet dump: *** Received from 10.133.56.33 port 1645 Code: Access-Request Identifier: 149 Authentic: 164pc205217179130M169140204212046201248 Attributes: NAS-IP-Address = 10.133.56.33 NAS-Port = 24 NAS-Port-Type = Async User-Name = uncliente@pbm Called-Station-Id = 0380 Calling-Station-Id = 1141399338 User-Password = 31137188PI171b\%1851920713213149K Service-Type = Framed-User Framed-Protocol = PPP Wed Jan 30 01:47:16 2002: DEBUG: Rewrote user name to uncliente@pbm Wed Jan 30 01:47:16 2002: NOTICE: Request from unknown client 10.133.56.33: ignored ===END OF RADIATOR LOG=== And following, is the log of Radiator's stdout+stderr: 2002-01-29 18:24:07.040854500 DBD::Oracle::db do failed: ORA-01401: inserted value too large for column (DBD ERROR: OCIStmtExecute) at /usr/local/lib/perl5/site_perl/5.6.1/Radius/SqlDb.pm line 232. 2002-01-30 01:24:56.250600500 STARTING 2002-01-30 01:24:56.251088500 /app/Radiator/bin/radiusd rad_instance=auth BaseDir=/app/Radiator AuthPort=1812 AcctPort= SNMPPort=16112 -config_file /app/Radiator/etc/radius-main.cfg -foreground As you can see there is a DBD message for hours before (that's something else I'm reparing right now, but it's non-related), and the following message is an echo I send right before exec'ing Radiator with the following command. There's no message telling anything, I saved the core dump but I don't know how to extract any info from there... I'm using Radiator (2.18.4) and have all of my data on a remote Oracle (8.1.6) server. Both machines are Sun Netra with Solaris 8. Perl version is 5.6.1. Any clues? my client wants some good explanation of what's going on... TIA El 13 Dec 2001 a las 12:13, Hugh Irvine escribió: Hello Mariano - What you describe below sounds to me like a problem with the DBD-Oracle module. I would suggest that you try to use the restartWrapper program that we provide in the distribution (goodies/restartWrapper) instead of supervise (at least for debugging this problem). The restartWrapper program can be set up with a delay before restarting, and it can also be configured to email a designated email address with the exit status and any error messages that were written to stderr. We should then be able to see what is causing Radiator to die. regards Hugh On Thu, 13 Dec 2001 08:14, Mariano Absatz wrote: Hi, I'm having the following problem: I'm using Radiator (2.18.4) and have all of my data on a remote Oracle (8.1.6) server. Both machines are Sun Netra with Solaris 8. Perl version is 5.6.1. There are two instances of Radiator (one for authentication and the other for accounting). The problem is the following. If the Oracle server goes down, the queries time out (that's reasonable). The point is some times (not after every SQL timeout, but after some of them), Radiator goes down. It seems to be that this happens when the query in question is necessary as part of the authentication (e.g. during a username lookup or simultaneous use or port limit check), but not when it is nonessential (as a deletion from the radonline table for the nas/port recently received or an insertion in an AuthLog). On only one ocassion I saw the Could not connect to any SQL database. Request is ignored. Backing off for 600 second message, but even that time, Radiator went down. I'm using daemontool's supervise (http://cr.yp.to/daemontools.html) to keep the servers running so the server starts up again almost immediately. I see the messages when it is starting again in the log. The question is, why is Radiator silently shutting down rather than backing off? One of the main problems is that on the almost immediate restart, the first thing Radiator tries to do is to read the client list from the database. If Oracle is still down, it won't read it, it won't retry, and (since there are no hardwired Client's in the config file, it won't accept anything from any NAS. Regretfully, supervise's log is autorotated and autoerased on a size basis and I don't have the output to correlate with Radiator's log. I'm attaching parts of the logs showing the SQL Timeout error immediately followed by Radiator starting up again (via supervise). The DEBUG: Adding Clients from SQL database is the first message issued by a NEW Radiator starting. I'm also
Re: (RADIATOR) assign ip from radius to AS5300 NAS
Hi Manoj, usually, if you send Framed-IP-Address + Framed-IP-Netmask attributes in the Access-Accept packet, the NAS will use the IP address instead of assigning one of its own. In the authentication for e-mail users you should (after the standard user/password authentication) use an AuthBy DYNADDRESS (see http://www.open.com.au/radiator/ref.html#pgfId=406580) and use a SQL database for holding your IP address pools (or DHCP if you have a DHCP server available). Obviously, the IP addresses in the Radiator database should not conflict with the ones assigned by your NAS. A more simple arrangement would be possible if your NAS supports any kind of selection of IP address pool based on some Radius attribute. You should check your NAS documentation and/or provider and set that attribute in the Access- Accept packet. El 17 Dec 2001 a las 11:20, Manoj Agrawal escribió: Hi! We are an ISP. We have two types of account one for internet account and another one is for email only account. Both users dial the same number to access our network. I want to assign IPs address to email only users from Radiator radius to AS5300 NAS so that I can block those IPs only to our email servers. But, for Internet users I am assigning IPs from AS5300 NAS and it works fine. So, how can I assign IPs from radius to AS5300 NAS. Regards, manoj -- Best regards, Manoj mailto:[EMAIL PROTECTED] -- Mariano Absatz El Baby -- I thought I wanted a career, turns out I just wanted pay checks. === 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) Radiator going down after Oracle SQL Timeout
The point is when you add one more server to the back farm, why you do it? Because you can't process enough radius requests? or because the servers themselves are overloaded? The most important factor is, usually, the database. What are you using? SQL? DBM? LDAP? /etc/passwd? Where does it reside? A happy new year to you too! El 14 Dec 2001 a las 14:23, Harrison Ng escribió: Hello Mariano, Your radiator splitting method sounds interesting to us. We try to do it in test plant, and get experience from it. What we are doing here is using two radiator to proxy auth/acct request to a bunch of radiator server. We add more radiator server to the bunch for scaling. Eventually we have to manage too many linux boxes. This cost us much administrative overhead and money for maintenance. Merry Christmas and Happy New Year. Regards, Harrison -Original Message- From: Mariano Absatz [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] Sent: Thursday, December 13, 2001 9:28 PM To: Harrison Ng Cc: Radiator List Subject: RE: (RADIATOR) Radiator going down after Oracle SQL Timeout Well, I think this was discussed quite a few times in the list and was recommended by Hugh. The point is, precisely, the single-thread-ness of Radiator (inherited from the still unstablesness of Perl's multi-threading). While Radiator IS really fast, the data bases it interfaces are not necessarily fast (nor available, as the problem I had shows). In my case, I'm using an oracle database to authenticate users and also to store accounting records and on-line users. For now, these all reside in the same database in the same host (not the same host that is running Radiator), but I designed it so it can scale and functionally divide the databases. But even being in the same host, by splitting up Radiator authentication and accounting processes the database delays querying the tables to authenticate don't stop Radiator's accounting from receiving and storing account records and maintain the on-line users table and vice-versa. If I detected that the process is still to slow and the culprit was the database, I might even be tempted to leave 2 radiator instances listening on the standard ports for authentication and accounting records and load- balancing them among a bunch of authentication and accounting radiator processes all running on non-standard ports on the same host. El 13 Dec 2001 a las 10:48, Harrison Ng escribió: Hello Mariano, Do you mind telling me the purpose of running two instances of Radiator on the same unix box. I've heard that Radiator is a single thread perl appplication. So it can't fully utilize system resource effectively. Harrison SmarTone BroadBand Services Ltd. -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ]On Behalf Of Hugh Irvine Sent: Thursday, December 13, 2001 9:14 AM To: Mariano Absatz; Radiator List Subject: Re: (RADIATOR) Radiator going down after Oracle SQL Timeout Hello Mariano - What you describe below sounds to me like a problem with the DBD-Oracle module. I would suggest that you try to use the restartWrapper program that we provide in the distribution (goodies/restartWrapper) instead of supervise (at least for debugging this problem). The restartWrapper program can be set up with a delay before restarting, and it can also be configured to email a designated email address with the exit status and any error messages that were written to stderr. We should then be able to see what is causing Radiator to die. regards Hugh On Thu, 13 Dec 2001 08:14, Mariano Absatz wrote: Hi, I'm having the following problem: I'm using Radiator (2.18.4) and have all of my data on a remote Oracle (8.1.6) server. Both machines are Sun Netra with Solaris 8. Perl version is 5.6.1. There are two instances of Radiator (one for authentication and the other for accounting). The problem is the following. If the Oracle server goes down, the queries time out (that's reasonable). The point is some times (not after every SQL timeout, but after some of them), Radiator goes down. It seems to be that this happens when the query in question is necessary as part of the authentication (e.g. during a username lookup or simultaneous use or port limit check), but not when it is nonessential (as a deletion from the radonline table for the nas/port recently received or an insertion in an AuthLog). On only one ocassion I saw the Could not connect to any SQL database. Request is ignored. Backing off for 600 second message, but even that time, Radiator went
RE: (RADIATOR) Radiator going down after Oracle SQL Timeout
Well, I think this was discussed quite a few times in the list and was recommended by Hugh. The point is, precisely, the single-thread-ness of Radiator (inherited from the still unstablesness of Perl's multi-threading). While Radiator IS really fast, the data bases it interfaces are not necessarily fast (nor available, as the problem I had shows). In my case, I'm using an oracle database to authenticate users and also to store accounting records and on-line users. For now, these all reside in the same database in the same host (not the same host that is running Radiator), but I designed it so it can scale and functionally divide the databases. But even being in the same host, by splitting up Radiator authentication and accounting processes the database delays querying the tables to authenticate don't stop Radiator's accounting from receiving and storing account records and maintain the on-line users table and vice-versa. If I detected that the process is still to slow and the culprit was the database, I might even be tempted to leave 2 radiator instances listening on the standard ports for authentication and accounting records and load- balancing them among a bunch of authentication and accounting radiator processes all running on non-standard ports on the same host. El 13 Dec 2001 a las 10:48, Harrison Ng escribió: Hello Mariano, Do you mind telling me the purpose of running two instances of Radiator on the same unix box. I've heard that Radiator is a single thread perl appplication. So it can't fully utilize system resource effectively. Harrison SmarTone BroadBand Services Ltd. -Original Message- From: [EMAIL PROTECTED] [ mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ]On Behalf Of Hugh Irvine Sent: Thursday, December 13, 2001 9:14 AM To: Mariano Absatz; Radiator List Subject: Re: (RADIATOR) Radiator going down after Oracle SQL Timeout Hello Mariano - What you describe below sounds to me like a problem with the DBD-Oracle module. I would suggest that you try to use the restartWrapper program that we provide in the distribution (goodies/restartWrapper) instead of supervise (at least for debugging this problem). The restartWrapper program can be set up with a delay before restarting, and it can also be configured to email a designated email address with the exit status and any error messages that were written to stderr. We should then be able to see what is causing Radiator to die. regards Hugh On Thu, 13 Dec 2001 08:14, Mariano Absatz wrote: Hi, I'm having the following problem: I'm using Radiator (2.18.4) and have all of my data on a remote Oracle (8.1.6) server. Both machines are Sun Netra with Solaris 8. Perl version is 5.6.1. There are two instances of Radiator (one for authentication and the other for accounting). The problem is the following. If the Oracle server goes down, the queries time out (that's reasonable). The point is some times (not after every SQL timeout, but after some of them), Radiator goes down. It seems to be that this happens when the query in question is necessary as part of the authentication (e.g. during a username lookup or simultaneous use or port limit check), but not when it is nonessential (as a deletion from the radonline table for the nas/port recently received or an insertion in an AuthLog). On only one ocassion I saw the Could not connect to any SQL database. Request is ignored. Backing off for 600 second message, but even that time, Radiator went down. I'm using daemontool's supervise ( http://cr.yp.to/daemontools.html http://cr.yp.to/daemontools.html ) to keep the servers running so the server starts up again almost immediately. I see the messages when it is starting again in the log. The question is, why is Radiator silently shutting down rather than backing off? One of the main problems is that on the almost immediate restart, the first thing Radiator tries to do is to read the client list from the database. If Oracle is still down, it won't read it, it won't retry, and (since there are no hardwired Client's in the config file, it won't accept anything from any NAS. Regretfully, supervise's log is autorotated and autoerased on a size basis and I don't have the output to correlate with Radiator's log. I'm attaching parts of the logs showing the SQL Timeout error immediately followed by Radiator starting up again (via supervise). The DEBUG: Adding Clients from SQL database is the first message issued by a NEW Radiator starting. I'm also attaching the whole set of configuration files (the main one is radius-main.cfg) in a zip file. -- Radiator: the most portable, flexible and configurable RADIUS server anywhere. Available on *NIX, *BSD, Windows 95/98/2000, NT, MacOS X. - Nets
Re: (RADIATOR) %R
Hi,
I guess (but Hugh or Mike could prove me wrong) that the problem lies in
caching.
I didn't read the source, but I guess the file caching is done on an AuthBy
basis (and not on a different file basis).
The manual states (release 2.18.4):
For performance reasons, AuthBy FILE opens and reads the user database
at start-up, reinitialisation and whenever the file's modification
time changes, (i.e. the database is cached within Radiator). Since the
user database is cached in memory, large databases can require large
amounts of memory.
Since the actual file name is known when the first @dnnnk or
@K comes in, and that is the file checked for every access in that
realm.
You could do the following:
Handler Realm=/(^[d]\d{3}[k]\d{8}$)|(^[K]\d{8}$)/, Service-Type=Framed-User
AuthBy FILE
Filename /usr/local/lib/radiator/users/%R
Nocache
/AuthBy
/Handler
and that might work, alas, at the expense of performance. If one of those
files is too large, you would be in trouble (I think the searches in the file
are linear).
Proably keeping a copy of the files in a ram disk and pointing to them would
speed up the look-ups a bit... but they are still linear, if you can, order
the users inside a file by rate of use.
El 11 Dec 2001 a las 12:28, Bozkurt, Emin escribió:
hi,
i have a problem with the special character %R. the users of our network
have a lot of different user realms where the realm format is specified as:
dnnnk (for example d001k12345678) ore K (for example
K12345678).
for handeling all the requests with one handler we constructed this handler.
Handler Realm=/(^[d]\d{3}[k]\d{8}$)|(^[K]\d{8}$)/,
Service-Type=Framed-User
AuthBy FILE
Filename /usr/local/lib/radiator/users/%R
/AuthBy
/Handler
and now the problem:
it seems, that if there are many request with different realms, the pointer
( /usr/local/lib/radiator/users/%R) loks at the wrong file to match the
request.
we use radiator 2.18.
by debugging sometimes the file radiator try to match the request is shown
and somtimes not. by rejekt's this information is newer shown, so i can't
check, if radiator looks in the right file or not.
some debugs are attached.
hope you can help me.
best regards
emin
att-20011209.txt
Emin Bozkurt
System Technik
riodata GmbH
Hessenring 13 a
64546 Mörfelden
Fon +49 6105 2843 812
Mobile+49 163 2843 184
Fax +49 6105 2843 777
www.riodata.de
--
Mariano Absatz
El Baby
--
Gene Police!!! Get out of the pool!!
===
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) slightly OT: SMTP relay module
For a differente (and IMHO more elegant) solution, you might like to check
WHOSON:
http://whoson.sourceforge.net/
http://sourceforge.net/projects/whoson/
It's done by Eugene Crosser and consists of a very simple protocol that
allows you to have an on-line list of logged in IP addresses to which you
can log in, log out, tiemout and query.
It's used with ZMailer (http://zmailer.org) to provide POP-before-SMTP
authentication (by patching your POP/IMAP server to send a login). But it is
designed with radius in mind so you can log in and log out from a radius
server.
The API includes a Perl module, so you could call it directly from a hook in
Radiator.
Regretfully, I still didn't convince any customer to use it this way, only as
POP-before-SMTP, so we didn't still make such hooks.
In
http://sourceforge.net/project/showfiles.php?group_id=16839release_id=24410
you will see a bunch of 3rd party patches, including one for sendmail (we
designed the Courier-IMAP and the SolidPOP3d ones).
El 27 Nov 2001 a las 9:16, Mark - Orcon Support escribió:
Hi Charles -
Check out http://freshmeat.net/project/sendmailmysqlmap/. This enables a
mysql lookup for sendmail table types. We use this for replacing
virtusertable, but you could apply it to 'roamingips'. Then use Radiator to
simply insert data into the lookup table. Simply fudge a RADONLINE table or
use a hook to insert values in there, and then set a crontab to delete entries
over a certain age...
/Mark
From: Charles Sprickman [EMAIL PROTECTED]
Date: Mon, 26 Nov 2001 11:46:13 -0500 (EST)
To: [EMAIL PROTECTED]
Subject: (RADIATOR) slightly OT: SMTP relay module
Hi,
I started playing around with this idea some time ago, but dropped it
since I'm not a true perl hacker...
This is essentially the beginnings of a small module to allow roaming
users of any sort that are authenticated by radiator to relay mail for the
duration of their session. I settled on this method because it made more
sense to me than the numerous pop-before-smtp hacks. It's a bit more
straightforward: If you are an authenticated user, you can relay mail for
the duration of your session, end of story... No hacking of your pop or
smtp server is required.
The line in sendmail.cf is pretty easy:
Kpopauth hash -aOK /usr/local/etc/mail/popauth
and
SLocal_check_rcpt
R$* $: $(popauth ${client_addr} $: ? $)
R?$@ NoPopAuth
R$*OK $# OK
This is all stolen from the cf/hack/popauth.m4 distributed with sendmail.
Basically, it works. My problem is, it doesn't work well, and I have zero
experience in any kind of advanced perl work, specifically modules and the
like.
If there's anyone that would like to help polish this, it would be nice to
get it cleaned up and thrown in the radiator contrib dir. I could also work
out a version for qmail, and perhaps postfix with some help.
Any takers?
Thanks,
Charles
| Charles Sprickman | Internet Channel
| INCH System Administration Team| (212)243-5200
| [EMAIL PROTECTED] | [EMAIL PROTECTED]
===
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.
--
Mariano Absatz
El Baby
--
Stack Error: Lost on a cluttered desk...
===
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: Fwd: (RADIATOR) Bind Variables and Oracle
For the record:
I guess from this message (and another similar one you sent me after a
similar question), that implementing bound variable managing at a config
file level is not a simple task.
Anyway, if what's misssing is user request count mine as one :-)
Regretfully, I don't have the time (nor the knowledge) to try to do it by
myself and contribute it... I'm not exactly a Great (and fast) Perl Coder...
just a fancy hacker from the Perl 4.0.36 no-OO days...
...but I'll cheer for anyone doing this!!!
El 22 Nov 2001 a las 10:09, Mike McCauley escribió:
Hi Paul,
Radiator has low level support in the API for using bound variables (see the
trailing arguments to Radius::SqlDb::do and prepareAndExecute), so you can use
bound variables in hooks etc.
However, AuthBy SQL and SessionDatabase SQL do not support bound variables
with their various queries. That means that there is presently no way to use
bound variables just by tweaking the AuthBy SQL or SessionDatabase SQL
parameters. It could only be done through a hook.
Hope that helps.
Cheers.
On Thu, 22 Nov 2001 09:47, Hugh Irvine wrote:
Mikey -
-- Forwarded Message --
Subject: (RADIATOR) Bind Variables and Oracle
Date: Wed, 21 Nov 2001 17:20:59 -
From: Paul [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hi,
Wondering if anyone has had any experience with using bind variables with
Radiator / Oracle.
I am running Radiator 2.18.2 and Oracle 8.0.5 (both on Solaris) using DBD
1.12 and DBI 1.20.
We use a SessionDatabase SQL clause to perform IP vs. CLI writes to an
external Oracle database. We have found that the query we are currently
using is very inefficient as Oracle has to parse the whole query every time
and would like to modify the query to use bind variables as per below:
### WITHOUT BIND VARIABLE
$query = delete from radius_clid_tbl where .
IP_ADDR= '$framedipaddress' or .
MSISDN= '$callingstation';
my $sth = $sess_handle-prepareAndExecute($query);
### USING BIND VARIABLE
$query = delete from radius_clid_tbl where .
IP_ADDR= ? or .
MSISDN= ? ;
my $sth = $sess_handle-prepareAndExecute($query, $framedipaddress,
$callingstation);
The SessionDb SQL clause currently looks like this:
SessionDatabase SQL
DBSource dbi:Oracle:
DBUsername user/password@sid
AddQuery
DeleteQuery delete from radius_clid_tbl \
where (IP_ADDR='%{Framed-IP-Address}' \
or IP_ADDR='%{Framed-Address}' \
or MSISDN='%{Calling-Station-Id}')
ClearNasQuery
CountQuery
/SessionDatabase SQL
The delete needs to be performed when an access-request is recvd and when a
stop record is recvd, so I don't think I can use a hook. Also the DBA's
involved won't let me use a stored procedure :-(
If anyone has any experience with this, some help would be much appreciated
:-)
Thanks,
Paul
___
Paul O'Shea
Level9 Networks
___
===
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.
---
--
Mike McCauley [EMAIL PROTECTED]
Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW
24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au
Phone +61 3 9598-0985 Fax +61 3 9598-0955
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc
on Unix, Win95/8, 2000, NT, MacOS 9, 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.
--
Mariano Absatz
El Baby
--
Okay, okay, I take it back! Unfuck you!
===
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) after year 2037
El 14 Nov 2001 a las 9:37, [EMAIL PROTECTED] escribió: On Wed, 14 Nov 2001, ISMAIL,IRWAN (HP-Malaysia,ex1) wrote: Hi, I tried switching the date on my NT server (which is running radiator) to a date that is after year 2037 and I would get a no reply if I tried to authenticate. Is this a limitation of Radiator? The logfile would also be saved as 1900-MM-DD, instead of 20XX-MM-DD. How far after 2037 were you trying to go? 32-bit systems using signed 32-bit int's to store unix time as seconds since 1970 have a problem trying to deal with times after Jan 18, 2038. Hopefully, by that time, there won't be any 32-bit CPU's kicking around. 32 bits CPU is not your (only) problem here... the problem is a 32 bit PROTOCOL!!! The dates in RADIUS PROTOCOL PACKETS can ONLY be 32 bits, so, no matter that you get the new Pentium/Sextium/Septium/Bogopium 1024-bit CPU, if you want to do Radius and your clients (NASen) only speak Radius, you're dead, man... So, what you have to hope for is a PROTOCOL upgrade... so, rephrasing you: Hopefully, by that time, every NAS you have to deal with will be speaking DIAMETER (Radius probable succesor) and, of course, Radiator will... and, in fact, it will be easy to harness the complexity of Diameter with Radiator... won't it be, Hugh, Mike? :-) -- -- Jon Lewis *[EMAIL PROTECTED]*| I route System Administrator| therefore you are Atlantic Net| _ http://www.lewis.org/~jlewis/pgp for PGP public key_ === 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. -- Mariano Absatz El Baby -- Do they ever shut up on your planet? === 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) SNMP Agent
El 13 Nov 2001 a las 9:54, Andrew escribió: Hi All, I am a Radiator newbie and am wondering if somebody can provide me with some insight into the SNMP Agent. I have enabled the agent in my config file with a community other than 'public'. However, my 'logfile' keeps filling up with; WARNING: SNMPAgent: wrong community: 'public'. Request from 202.xxx.xxx.xxx ignored (that ip address is the localhost) I can't seem to figure out what's generating the request here. Are you on a windows system? I've seen really weird SNMP trafic on these... e.g. HP's network printers and other devices speak SNMP with agents on PC's and expect to see the public community everywhere... If that is your case, it might be better if you run Radiator's SNMP agent on a non-standard port so it doesn't interact with other SNMP processes... In fact, I even do this on Unix, since I use SNMP to monitor Radiator as well as other stuff provided by OS agents. I'm also using SNMP to restart Radiator and it works OK. Regards, Andrew. [EMAIL PROTECTED] === 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. -- Mariano Absatz El Baby -- #define QUESTION ((bb) || !(bb)) -Shakespeare. === 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) kill -1 vs. kill / restart
Hi Lin, El 13 Nov 2001 a las 9:44, Huaikun Lin escribió: Hi At 03:25 PM 11/8/01 -0300, you wrote: El 8 Nov 2001 a las 8:13, Todd Dokey escribió: killall -HUP radiusd Works for me. But the problem is not that radiusd is not receiving the SIGHUP, it's that although it sees it and it says it restarts, it's not processing all of the changed info in the config file... Radiator provide a restartWrapper script,this script will be running as a daemon. It is used to restart radiusd. If you use kill radiusprocessid or kill -9 radiusprocessid,the Wrapper script will automatically restart radiusd with the new config file. I get the same results with daemontools' supervise using svc -t (see my message from November 8th with Subject: HA Radiator under djb's daemontools about this). My point isn't about how to restart it, but why a kill -1 doesn't do all that it's intended to... Mike says it's solved as of 2.19, but I hasn't installed it yet. Lin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mariano Absatz Sent: Thursday, November 08, 2001 06:39 To: Radiator List Subject: (RADIATOR) kill -1 vs. kill / restart Hi, I once commented on this and I recall that at some point Hugh said this was solved. The point is, I make certain changes to the configuration file, I send the process a HUP signal (kill -1) and the changes are NOT taken into account. If I stop the process (kill -15) and then start Radiator again, then changes take effect. FTR: The problem was inside an AuthBy SQL and I had a syntax error in a query sent to Oracle: a missing AND in the WHERE clause, which gave me a ORA-00933: SQL command not properly ended (DBD ERROR: OCIStmtExecute/Describe) error. I'm using Radiator 2.18.4, on a Sun Netra with Solaris 8 and Perl 5.6.1. As a sidecomment: When Radiator starts, if you take a look at a Trace 4, it does a couple of things before actually entering the main radius loop. Apparently, it sends the message saying Server started when it is entering the main loop. It would be nice to have (at least at Trace 4) a Server starting right at the beginning. The first time I saw messages between the Server stopping or Server restarting and the Server started message, I didn't know if they where coming from the server shutting down or coming back up again. If you use your brain (as I often do not) you can actually see that the messages in the log are from the server starting up and not from the one that's going down, anyway, I think a log($LOG_DEBUG, Server starting... $ident); in radiusd right after the NGetOpt or that neighborhood would be informative... Thu Nov 8 11:07:44 2001: INFO: Server started: Radiator 2.18.4 on radius1-- Mariano Absatz El Baby -- CCITT - Can't Conceive Intelligent Thoughts Today === 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. -- Mariano Absatz El Baby -- Friends help you move. Real friends help you move bodies. === 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. -- Mariano Absatz El Baby -- \_ , \~-._ |\ \ ~\ ) \_ //' ,;;\___( (.-~~~-. ,;'' /~-- /._`\ ) /--.._, )_ `~ /~'`\`\~~\ ~' === 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) RV: HACKER ATTACK?
Hola Gabriela, this doesn't seem like a Hacker attack to me... The packet came from 200.16.169.56. Is that one of your NAS? I guess so... as Radiator didn't ignore the request, it must have come from one of your listed Clients. BTW, the reverse of that address points to h200-16-169-56.easymail.com.ar which I could guess is owned by same people that owns easymail.net.ar... At least both domains have the same registrant company and you seem to be the technical contact in both as far as nic.ar is concerned. Now, the completely mangled Username is more a sign of a bad modem to NAS connection than a hacker attack. As I remember, this has been discussed quite a few times in the list. You should discard everything you don't like from scratch in your config file. I use the following line in my config files: RewriteUsername s/.*['\x00-\x20\x7F-\xFF].*/username-has-invalid-chars/ But you could say: RewriteUsername s/.*['\x00-\x20\x7F-\xFF].*/el-modem-mando-fruta/ ;-) This is actually replacing any username that has at least one non-printable ASCII character with the string el-modem-mando-fruta (which you could easily find in your logs). You could actually be much more restrictive and only allow letters, digits and underscores, it's your call. Suerte!!! (y achicá el pánico). El 13 Nov 2001 a las 7:43, Mike McCauley escribió: Received: from bart.easymail.net.ar (h200-16-169-42.easymail.com.ar [200.16.169.42]) by server1.open.com.au (8.11.0/8.11.0) with ESMTP id fACCc4321374 for [EMAIL PROTECTED]; Mon, 12 Nov 2001 06:38:04 -0600 Received: by BART with Internet Mail Service (5.5.2653.19) id WL8VWRHV; Mon, 12 Nov 2001 11:24:33 -0300 Message-ID: 0071AA06E729D5118619000629757A57D3BF@BART From: Barsotti, Gabriela [EMAIL PROTECTED] To: '[EMAIL PROTECTED]' [EMAIL PROTECTED] Subject: RV: HACKER ATTACK? Date: Mon, 12 Nov 2001 11:24:25 -0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by server1.open.com.au id fACCc4321375 -Mensaje original- De: Barsotti, Gabriela Enviado el: Lunes, 12 de Noviembre de 2001 11:22 a.m. Para: '[EMAIL PROTECTED]' Asunto: HACKER ATTACK? The last Saturday our Radius server received an attack. I´m sending you the information I can found on my server in order to help all Radius Server from unspected attacks. Sat Nov 10 22:59:54 2001: DEBUG: Packet dump: *** Received from 200.16.169.56 port 1645 Code: Access-Request Identifier: 150 Authentic: Ei`!:i(:r(LC Attributes: User-Name = 'S R%H%G1\|g+%s8rEs3)o}p/G}/J?~o]F 4%7.+CBsg,'?j/?u User-Password = )162225251177o259\177o6:[J5va146145U173F819841 60249D179198239 NAS-IP-Address = 200.16.169.56 NAS-Port = 56 Called-Station-Id = 6200 Calling-Station-Id = 1145674048 USR-Connect-Speed = 24000_BPS USR-Modulation-Type = v32Terbo USR-Simplified-MNP-Levels = 0 USR-Simplified-V42bis-Usage = 0 USR-Chassis-Call-Slot = 7 USR-Chassis-Call-Span = 0 USR-Chassis-Call-Channel = 27 NAS-Identifier = access2 Acct-Session-Id = 071b05f8 NAS-Port-Type = Async Sat Nov 10 22:59:54 2001: DEBUG: Handling request with Handler 'Realm=DEFAULT' Sat Nov 10 22:59:54 2001: DEBUG: SessionDbSQL Deleting session for 'S R%H%G1\|g+%s8rEs3)o}p/G}/J?~o]F 4%7.+CBsg,'?j/?u, 200.16.169.56, 56 Sat Nov 10 22:59:54 2001: DEBUG: do query is: delete from RADONLINE where NASIDENTIFIER='200.16.169.56' and NASPORT=056 Sat Nov 10 22:59:54 2001: DEBUG: Query is: select NASIDENTIFIER, NASPORT, ACCTSESSIONID from RADONLINE where USERNAME=''S R%H%G1\|g+%s8rEs3)o} p/G}/J?~o]F 4%7.+CBsg,'?j/?u' Sat Nov 10 22:59:54 2001: ERR: Execute failed for 'select NASIDENTIFIER, NASPORT, ACCTSESSIONID from RADONLINE where USERNAME=''S R%H%G1\|g+%s 8rEs3)o}p/G}/J?~o]F 4%7.+CBsg,'?j/?u'': ERROR: parser: parse error at or near s Sat Nov 10 22:59:55 2001: ERR: Execute failed for 'select NASIDENTIFIER, NASPORT, ACCTSESSIONID from RADONLINE where USERNAME=''S R%H%G1\|g+%s 8rEs3)o}p/G}/J?~o]F 4%7.+CBsg,'?j/?u'': ERROR: parser: parse error at or near s Sat Nov 10 22:59:55 2001: DEBUG: Handling with Radius::AuthSQL Sat Nov 10 22:59:55 2001: DEBUG: Handling with Radius::AuthSQL Lic. Gabriela Barsotti Technology Manager EasyMail S.A. A VirtualCom Company 54-11-54590-8820 -- Mariano Absatz El Baby -- Daddy, why doesn't this magnet pick up this floppy disk? === 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) Re: (RADIATOR-ANNOUNCE) Version 2.19 released
El 28 Oct 2001 a las 13:08, Mike McCauley escribió: We are pleased to announce the release of Radiator version 2.19 This version provides native RSA SecurID certification, some significant new features for proxying, many minor new features and some bug fixes. New AuthBy SQLRADIUS provides proxying based on an SQL table. Looks up the target radius server from an SQL table that can depend on Realm, Called-Station-Id etc. Complictated indirect target mapping is also suported. Useful for managing large number of remotes servers, such as in a wholesale ISP. Example tables in goodies/*.sql, plus example config file in goodies/sqlradius.cfg. Obsoletes goodies/AuthSQLRadius.pm. Great idea! New AuthBy INTERNAL allows you to handle different types of requests in fixed, parameterised ways. Col Added MainLoopHook which is called once per second during the main dispatch loop. Nice to see my own proposals implemented :-) Fixed a problem with timers persisting through a HUP or reset. Identified by Mariano Absatz ([EMAIL PROTECTED]). THANX... BTW, to the rest of the list, the hot-fix for this, when reported, took EXACTLY 6 hours, including, probably, Mike sleep hours. YOU DON'T GET BETTER USER SUPPORT THAN THIS ANYWHERE AT ANY PRICE Test Oracle radius authentication: Oracle 8 can authenticate Oracle users through Radius. Note: Oracle always upper-cases user names. See the Radiator FAQ for more details. goodies/sybaseCreate.sql did not drop RADLOG. Nice... I hope I never have to use this ;-) Added StripFromRequest and AddToRequest parameters to Handler and Realm. Great! Added new SQL AcctColumnDef type 'literal' that lets you build columns literally. No quotes are applied. Also interesting... Added new global parameter DefineFormattedGlobalVar like DefineGlobalVar but which honours special formatting characters. DefineGlobalVar is now deprecated, and will be removed one day. Great! It even has the same name I used so I don't have to upgrade my config files So good to see my code in production... I might get to think I even remember how to code from when I was young... :-)) Added AddToRequestIfNotExist parameter to Handlers and Realms AuthBy RADIUS now also honours AccountingStartsOnly, AccountingStopsOnly and AccountingAlivesOnly. Great!... everything should be available at a Handler-level... Added new pseudo reply item Exec-Program which runs an external program only if the user successfully authenticates. Similar to Exec-Program in Cistron. Suggested by Klaas Koopman ([EMAIL PROTECTED]). Nice one. -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc on Unix, Win95/8, 2000, NT, MacOS 9, MacOS X === To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator-announce' in the body of the message. How good to see the best (only?) product in its class get better and better!! FYI, I have just developed a system based on Radiator/Oracle/Apache w/mod_perl of which the customer said I couldn't find anything close to this flexibility. And I KNOW they've reviewed a bunch of commercial radius server... -- Mariano Absatz El Baby -- Nostalgia: The good old days multiplied by a bad memory... === 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) signal to NAS
Well... Radius is (or used to be) a strict client/server protocol where the server is passively waiting for requests from the client and reacting (or not) to them as it sees apropriate. Now, the client is the NAS and the server (in our case) is Radiator. There should be no way for the server to asynchronously send anything to the client (the NAS). But if you want to disconnect a user who dialed-in to the NAS from the server, you have to do just that. RFC2822 (Extended RADIUS Practices) says: 6.4. Authorization Changes: To implement an active changes to a running session, such as filter changes or timeout and disconnect, at least one vendor has added a RADIUS server to his NAS. This server accepts messages sent from an application in the network, and upon matching some session information, will perform such operations. Messages sent from Server to NAS - Change Filter Request - Change Filter Ack / Nak - Disconnect Request - Disconnect Response Filters are used to limit the access the user has to the network by restricting the systems and protocols he can send packets to. Upon fulfilling some registration with an authorization server, the service provider may wish to remove those restrictions, or disconnect the user. So, in fact, the NAS should have a minimal radius server inside and you should have a radius client... but Radiator has radpwtst which is precisely, a radius client... Browsing a little bit among old docs, I found an Internet-Draft, draft- chiba-radius-dynamic-authorization-00.txt: Dynamic Authorization... browsing ftp.ietf.org I see it's expired and no longer on line... anyway, if you want it, I can send it by mail. This draft is written by a couple of guys from Cisco, so I suspect there is at least a Cisco box with this behaviour... anyway, you MUST see your NAS documentation to check that this is available and how it works... I think I once saw a whitepaper about the Nortel CVX supporting this. The draft says, the client's client (i.e. radpwtst) must send a Radius Disconnect Request packet with the username, or session-id, or IP address of the user to disconnect and the client turned into server (the NAS) should disconnect it and send a Disconnect ACK packet or not disconnect it and send a Disconnect NAK packet. Also, you should see when and why you do disconnect it... maybe from a radwho.cgi... it shouldn't be hard to add a link to every line saying disconnect this guy and launching radpwtst with the apropriate options... HTH. El 20 Oct 2001 a las 16:13, lloyd dagoc escribió: hello, just wondering if RADIATOR can send a signal to NAS to disconnect a particular usercan RADIATOR do that? if yes , how? = ) thanks lloyd inter.net philippines incorporated === 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. -- Mariano Absatz El Baby -- I wish for a world of peace, harmony, nakedness. === 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) AddToReply also in accounting?
Hi Wim, I guess your problem comes from doing accounting authentication in the same AuthBy ... clause. You should (correct me, Hugh if I'm wrong) AuthBy WhatEver Identifier auth-only all the stuff related with authentication including the AddToReply /AuthBy WhatEver AuthBy WhatEver Identifier acct-only all the stuff related with accounting NOT including the AddToReply /AuthBy WhatEver Handler Request-Type=Access-Request AuthBy auth-only /Handler Handler Request-Type=Accounting-Request AuthBy acct-only /Handler El 17 Oct 2001, a las 17:55, Wim Biemolt escribió: Hi, I'm using the AddToReply(IfNotExist) command to add certain attributes. Like a Framed-IP-Address to assign an IP-address if none was specified. According to the reference manual (2.18.4) AddToReply Adds attributes to Access-Accepts before replying to the originating client. However I noticed that the AddToReply(IfNotExist) command also seem to affect the Accounting-Response: *** Sending to 10.20.30.40 port 1813 Code: Accounting-Response Identifier: 156 Authentic: R187230238!25181i10n.n}Y Attributes: Framed-IP-Address = 192.168.192.168 Although everything is working fine, I don't need this attribute in the Accounting-Response and according to the reference manual this isn't the correct behavior. Is this a bug? Cheers, -Wim -/- SURFnet === 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. -- Mariano Absatz El Baby -- Computers are only human. === 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) Re: using Util::format_special() in setVariable
Alright... but I'm stubborn enough to keep messing around...
what about adding a keyword 'DefineFormattedGlobalVar' (or whatever is
appropriate) that allows me to do this without breaking existing config files?
I think it should suffice this change in ServerConfig.pm (now I'm working
over release 2.18.4):
# diff -C5 ServerConfig.pm.ORI ServerConfig.pm
*** ServerConfig.pm.ORI Tue Oct 9 09:09:35 2001
--- ServerConfig.pm Tue Oct 9 09:12:25 2001
***
*** 188,197
--- 188,203
{
my ($name, $v) = split(/\s+/, $value);
main::setVariable($name, $v);
return 1;
}
+ elsif ($keyword eq 'DefineFormattedGlobalVar')
+ {
+ my ($name, $v) = split(/\s+/, $value);
+ main::setVariable($name, Radius::Util::format_special($v));
+ return 1;
+ }
elsif ($keyword eq 'LogFile')
{
$self-{LogFile} = $value;
# Allow the default logger to be rejigged during startup
Radius::Log::setupDefaultLogger
El 6 Oct 2001, a las 15:18, Hugh Irvine escribió:
Hello Mariano -
Just one further point on this - Mike and I discussed it at some length,
however we were concerned that (1) it would only work for a single level of
nesting, and (2) that it would break any previously defined %n string
in a GlobalVar (such as SQL queries for example).
Note that in the current Radiator design philosophy you would probably be
much better off doing this sort of complex setup in a StartupHook.
As Mike says, we thank you for the suggestion and encourage you to keep
coming up with them.
regards
Hugh
On Saturday 06 October 2001 13:16, Mike McCauley wrote:
Hello Mariano,
Thank you for your contribution.
We have carefully considerd this, and we dont think its a good idea to add
this to the base code.We think that it is too likely to break other users
configurations.
But thanks for your suggestion: keep them coming.
Cheers.
On Sat, 6 Oct 2001 09:05, you wrote:
Hi people,
I added one more level of indirection in my config files and everything
went nuts... my %{GlobalVar:xxx}'s went crazy.
Then I noted that the problem was that I was setting %{GlobalVar:xxx}'s
whose contents included other %{GlobalVar:xxx}'s and this ones weren't
translated...
I made a really small change to radiusd and it started working (I
think)... Am I the first one to try to do this?
The idea is that now setVariable (in radiusd) sets the global variable to
the value of its argument, but first calls Util::format_special() so, for
my particular case, it can interpolate previously defined global
variables, but you might use it for any of the %XXX stuff that make sense
while parsing the config files...
Can this change have unwanted side-effects?
I think it's a really small and useful patch (well, if I'm the first,
maybe my concept of useful is completely insane)
:-D
So, FWIW, here's the patch (based on 2.18.2):
# diff -C5 radiusd.ORI radiusd
*** radiusd.ORIFri Oct 5 19:41:09 2001
--- radiusd Fri Oct 5 19:42:11 2001
***
*** 275,285
# as %{GlobalVar:name}
sub setVariable
{
my ($name, $value) = @_;
! $main::globals{$name} = $value;
}
sub getVariable
{
return $main::globals{$_[0]};
--- 275,285
# as %{GlobalVar:name}
sub setVariable
{
my ($name, $value) = @_;
! $main::globals{$name} = Radius::Util::format_special($value);
}
sub getVariable
{
return $main::globals{$_[0]};
--
Mariano Absatz
El Baby
--
God is REAL, unless explicitly declared INTEGER.
===
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) using Util::format_special() in setVariable
Hi people,
I added one more level of indirection in my config files and everything went
nuts... my %{GlobalVar:xxx}'s went crazy.
Then I noted that the problem was that I was setting %{GlobalVar:xxx}'s whose
contents included other %{GlobalVar:xxx}'s and this ones weren't translated...
I made a really small change to radiusd and it started working (I think)...
Am I the first one to try to do this?
The idea is that now setVariable (in radiusd) sets the global variable to the
value of its argument, but first calls Util::format_special() so, for my
particular case, it can interpolate previously defined global variables, but
you might use it for any of the %XXX stuff that make sense while parsing the
config files...
Can this change have unwanted side-effects?
I think it's a really small and useful patch (well, if I'm the first, maybe
my concept of useful is completely insane)
:-D
So, FWIW, here's the patch (based on 2.18.2):
# diff -C5 radiusd.ORI radiusd
*** radiusd.ORIFri Oct 5 19:41:09 2001
--- radiusd Fri Oct 5 19:42:11 2001
***
*** 275,285
# as %{GlobalVar:name}
sub setVariable
{
my ($name, $value) = @_;
! $main::globals{$name} = $value;
}
sub getVariable
{
return $main::globals{$_[0]};
--- 275,285
# as %{GlobalVar:name}
sub setVariable
{
my ($name, $value) = @_;
! $main::globals{$name} = Radius::Util::format_special($value);
}
sub getVariable
{
return $main::globals{$_[0]};
--
Mariano Absatz
El Baby
--
Sorry, I choose to date people higher on the food chain.
===
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) using stored procedures...
Hi there... I am wondering... is there any way to replace queries in the config file with calls to stored procedures _with_detached_parameters_? That is, I want to say, for instance, instead of: FailureQuery INSERT INTO AUTH_LOG \ (TIME_STAMP,USERNAME,PASSWORD,REASON) \ VALUES \ %t,'%n','%P','%1') FailureQuery BEGIN SP_INSERT_AUTH_LOG (:1,:2); END \ PARAMLIST %t,'%n','%P','%1' /PARAMLIST I don't know what syntax to use, but the parameters should be a Perl array passed (by reference) to prepare() as the second argument. Maybe even use prepare_cached()? TIA -- Mariano Absatz El Baby -- If at first you don't succeed, call it version 1.0 === 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) using stored procedures...
El 24 Sep 2001, a las 16:37, Mariano Absatz escribió: Hi there... I am wondering... is there any way to replace queries in the config file with calls to stored procedures _with_detached_parameters_? That is, I want to say, for instance, instead of: FailureQuery INSERT INTO AUTH_LOG \ (TIME_STAMP,USERNAME,PASSWORD,REASON) \ VALUES \ %t,'%n','%P','%1') FailureQuery BEGIN SP_INSERT_AUTH_LOG (:1,:2); END \ PARAMLIST %t,'%n','%P','%1' /PARAMLIST Sorry, I should've said, instead of: FailureQuery INSERT INTO AUTH_LOG \ (TIME_STAMP,USERNAME,PASSWORD,REASON) \ VALUES \ %t,'%n','%P','%1') use this: FailureQuery BEGIN SP_INSERT_AUTH_LOG (:1,:2,:3,:4); END \ PARAMLIST %t,'%n','%P','%1' /PARAMLIST I don't know what syntax to use, but the parameters should be a Perl array passed (by reference) to prepare() as the second argument. Maybe even use prepare_cached()? TIA -- Mariano Absatz El Baby -- We are born naked, wet and hungry. Then things get worse. === 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.
(Fwd) (RADIATOR) reloading Radiator AddressAllocator's Recla
--- Forwarded message follows --- From: Mariano Absatz [EMAIL PROTECTED] To: Radiator List [EMAIL PROTECTED] Date: Mon, 10 Sep 2001 12:46:20 -0300 Subject:(RADIATOR) reloading Radiator AddressAllocator's ReclaimQuery X-Mailer: Pegasus Mail for Win32 (v3.12c) Sender: [EMAIL PROTECTED] Hi, I have noticed a bug (or is it a feature? :-) by means of which I end up with lots of queries to my database. I'm using AuthBy DYNADDRESS with an AddressAllocator SQL. I defined my ReclaimQuery as follows: LeaseReclaimInterval 10800 ReclaimQuery UPDATE POOL_IP \ SET OCUPADA = 0, TIME_STAMP = %0 \ WHERE OCUPADA != 0 AND EXPIRA %0 (which is similar to the default with table fields names changed) The point is that I see this queries in my trace 4 every 3 hours... until I reload radiator (SIGHUP). After doing this, It keeps doing the query following the 3 hours period since I orininally started Radiator and adds ANOTHER cicle starting at the time I reloaded... As I've been fiddling with reloads through SNMP and the like, I've ended up with about 30 queries every 3 hours (see log below). I guess the reload process is Radius::Select::add_timeout()'ing the recently read ReclaimQuery, but isn't Radius::Select::remove_timeout()'ing the old one... Does this has a solution? TIA. Mon Sep 10 05:28:45 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:28:45 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110525 WHERE OCUPADA != 0 AND EXPIRA 1000110525 Mon Sep 10 05:28:51 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:28:51 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110531 WHERE OCUPADA != 0 AND EXPIRA 1000110531 Mon Sep 10 05:28:53 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:28:53 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110533 WHERE OCUPADA != 0 AND EXPIRA 1000110533 Mon Sep 10 05:28:53 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:28:53 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110533 WHERE OCUPADA != 0 AND EXPIRA 1000110533 Mon Sep 10 05:28:54 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:28:54 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110534 WHERE OCUPADA != 0 AND EXPIRA 1000110534 Mon Sep 10 05:28:55 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:28:55 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110535 WHERE OCUPADA != 0 AND EXPIRA 1000110535 Mon Sep 10 05:28:56 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:28:56 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110536 WHERE OCUPADA != 0 AND EXPIRA 1000110536 Mon Sep 10 05:29:49 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:29:49 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110589 WHERE OCUPADA != 0 AND EXPIRA 1000110589 Mon Sep 10 05:29:50 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:29:50 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110590 WHERE OCUPADA != 0 AND EXPIRA 1000110590 Mon Sep 10 05:29:51 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:29:51 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110591 WHERE OCUPADA != 0 AND EXPIRA 1000110591 Mon Sep 10 05:29:53 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:29:53 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110593 WHERE OCUPADA != 0 AND EXPIRA 1000110593 Mon Sep 10 05:29:53 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:29:53 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110593 WHERE OCUPADA != 0 AND EXPIRA 1000110593 Mon Sep 10 05:29:54 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:29:54 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110594 WHERE OCUPADA != 0 AND EXPIRA 1000110594 Mon Sep 10 05:30:23 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:30:23 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110623 WHERE OCUPADA != 0 AND EXPIRA 1000110623 Mon Sep 10 05:30:24 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:30:24 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110624 WHERE OCUPADA != 0 AND EXPIRA 1000110624 Mon Sep 10 05:30:25 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:30:25 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110625 WHERE OCUPADA != 0 AND EXPIRA 1000110625 Mon Sep 10 05:30:26 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:30:26 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000110626 WHERE OCUPADA != 0 AND EXPIRA 1000110626 Mon Sep 10 05:30:27 2001: DEBUG: Reclaiming expired leases Mon Sep 10 05:30:27 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0
Re: Fwd: (RADIATOR) remote radiator restart
El 9 Sep 2001, a las 9:43, Mike McCauley escribió: Hello Mariano, Thanks for reporting this. There was a b ug un Mib.pm that prevented the correct OID path bing sent back in the SNMP reply. This apparently causes some SNMP clients to think it got no reply at all. I have attached a new Mib.pm for you to test. If it is OK it wil appear in the next release. Right, now it works, but I see you already released it !!! on Sunday morning !!! (Saturday night for me) We apologise for this problem. Thank you for reporting it. You're definitively welcome... getting a bug fix in 6 hours, (counting the Australian early morning), and a new release 1.5 hours later, during a weekend is much more than I ever got from any other software company, including support contracts with big ones. BTW, we also bought a year ago (together with the Radiator license), one year of Radiator Support by mail... We haven't used it even once, since the support through this mailing list is really superb. Cheers. On Sun, 9 Sep 2001 03:44, Mariano Absatz wrote: Hi Mike, Now it (almost) works, the only point is that, apparently, it restarts and doesn't send back an acknowledge to the snmp console that sent the request: Here's the console: #snmpset -t 8 -r 1 -p 16146 192.168.19.1 rw-comm .1.3.6.1.2.1.67.1.1.1.1.4 i 2 Timeout: No Response from 192.168.19.1 Here's Radiator's log: Sat Sep 8 14:36:50 2001: DEBUG: SNMPAgent: received request from 192.168.1.7, 131, 189128152, rw-comm Sat Sep 8 14:36:52 2001: INFO: Server started: Radiator 2.18.2 on radius1 never mind how long the timeout I use (here's 8 secs, but the reset is almost immediate). Any idea? (I'm using 2.18.2) El 7 Sep 2001, a las 9:26, Mike McCauley escribió: Hi Mariano, On Thu, 6 Sep 2001 23:58, Mariano Absatz wrote: Well, the point is... it didn't work, Radiator receives the request, but doesn't do anything about it. I tried with the three sets of OID's (the draft ones, RFC2619 RFC2621), but to no avail. In the requesting machine, I send: snmpset -Ir -p 16146 192.168.19.1 rw-comm 1.3.6.1.3.79.1.1.1.4 i 2 snmpset -Ir -p 16146 192.168.19.1 rw-comm 1.3.6.1.2.1.67.1.1.1.1.4 i 2 snmpset -Ir -p 16146 192.168.19.1 rw-comm 1.3.6.1.2.1.67.2.1.1.1.4 i 2 Ooos, you need to have a . at the front of the OID, else your snmp interprets it as a relative OID. Try this: it works for me on 2.18.3: snmpset oscar public .1.3.6.1.3.79.1.1.1.4 i 2 and I allways get the following output: Error in packet. Reason: (noSuchName) There is no such variable name in this MIB. Failed object: The trace 4 in the Radiator server says: Thu Sep 6 09:56:42 2001: DEBUG: SNMPAgent: received request from 192.168.1.7, 131, 293287917, rw-comm Thu Sep 6 10:32:13 2001: DEBUG: SNMPAgent: received request from 200.x.y.z, 131, 60580895, rw-comm Thu Sep 6 10:32:13 2001: WARNING: SNMPAgent: requesting host not defined as manager. Request from 200.x.y.z ignored Thu Sep 6 10:32:14 2001: DEBUG: SNMPAgent: received request from 192.168.1.7, 131, 60580895, rw-comm Thu Sep 6 10:34:35 2001: DEBUG: SNMPAgent: received request from 192.168.1.7, 131, 1490955430, rw-comm Thu Sep 6 10:39:45 2001: DEBUG: SNMPAgent: received request from 192.168.1.7, 131, 267748177, rw-comm Thu Sep 6 10:41:56 2001: DEBUG: SNMPAgent: received request from 192.168.1.7, 131, 1188183886, rw-comm And it doesn't restart... What is going wrong? El 6 Sep 2001, a las 15:07, Mike McCauley escribió: Hi Mariano, On Thu, 6 Sep 2001 07:46, Hugh Irvine wrote: -- Forwarded Message -- Subject: (RADIATOR) remote radiator restart Date: Wed, 5 Sep 2001 14:22:45 -0300 From: Mariano Absatz [EMAIL PROTECTED] To: Radiator List [EMAIL PROTECTED] Hi, I am running Radiator 2.18.2 on a couple of Sun Netras (Solaris 8) authenticating against an Oracle database (on yet another Netra). We developed a web based front end for administration of the users in the Oracle database on a Sun Ultra 10 (also Solaris 8) with Apache and embedded Perl. The point is that, for instance, when I try to invoke a restart script through ssh, I get the following error: Doing it so through rsh, it works but it locks the connection (and anyway, I'd rather not have rshd running on the server. On the other hand, the manual states that through the SNMP agent I can restart Radiator, but I don't know how. Am I missing something? (I think this would be the cleanest method to do it). you need to set the SNMP variable 1.3.6.1.3.79.1.1.1.4 to the value 2, with something like: snmpset your.radius.server.address your_community
(RADIATOR) reloading Radiator AddressAllocator's ReclaimQuery
= 1000121424 WHERE OCUPADA != 0 AND EXPIRA 1000121424 Mon Sep 10 08:30:25 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:30:25 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121425 WHERE OCUPADA != 0 AND EXPIRA 1000121425 Mon Sep 10 08:30:26 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:30:26 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121426 WHERE OCUPADA != 0 AND EXPIRA 1000121426 Mon Sep 10 08:30:27 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:30:27 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121427 WHERE OCUPADA != 0 AND EXPIRA 1000121427 Mon Sep 10 08:31:49 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:31:49 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121509 WHERE OCUPADA != 0 AND EXPIRA 1000121509 Mon Sep 10 08:31:54 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:31:54 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121514 WHERE OCUPADA != 0 AND EXPIRA 1000121514 Mon Sep 10 08:31:59 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:31:59 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121519 WHERE OCUPADA != 0 AND EXPIRA 1000121519 Mon Sep 10 08:32:04 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:32:04 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121524 WHERE OCUPADA != 0 AND EXPIRA 1000121524 Mon Sep 10 08:32:09 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:32:09 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121529 WHERE OCUPADA != 0 AND EXPIRA 1000121529 Mon Sep 10 08:32:15 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:32:15 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121535 WHERE OCUPADA != 0 AND EXPIRA 1000121535 Mon Sep 10 08:32:32 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:32:32 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121552 WHERE OCUPADA != 0 AND EXPIRA 1000121552 Mon Sep 10 08:32:43 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:32:43 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121563 WHERE OCUPADA != 0 AND EXPIRA 1000121563 Mon Sep 10 08:36:10 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:36:10 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121770 WHERE OCUPADA != 0 AND EXPIRA 1000121770 Mon Sep 10 08:36:21 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:36:21 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121781 WHERE OCUPADA != 0 AND EXPIRA 1000121781 Mon Sep 10 08:36:51 2001: DEBUG: Reclaiming expired leases Mon Sep 10 08:36:51 2001: DEBUG: do query is: UPDATE POOL_IP SET OCUPADA = 0, TIME_STAMP = 1000121811 WHERE OCUPADA != 0 AND EXPIRA 1000121811 -- Mariano Absatz El Baby -- Ladies and gentlemen, I stand before you to stand behind you to tell you something I know nothing about. Thursday, which is Good Friday, we're having a Father's Day party for mothers only. Admission is free, pay at the door, pull out a chair and sit on the floor. === 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) event handler
Speaking of timed queries (in AddressAllocator SQL)... Is there a way of adding my own queries to be executed on a periodical or time-based way? That is, can I set a do this arbitrary query every 6 hours and a do this other arbitrary query every monday at 3:30 AM? TIA -- Mariano Absatz El Baby -- Time spent petting the cat is never wasted... signed, The Cat === 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) event handler
El 10 Sep 2001, a las 10:08, Todd Dokey escribió: Call the queries from a perl script with a cron? That's what I'm doing right now, but as I noticed there is a kind of internal event handler, I wanted to know how accesible it is... Whoops.. you might be using windoze.. so you could call a perl script from a Thanx god it's Unix... :-) batch file with WinAT. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mariano Absatz Sent: Monday, September 10, 2001 09:33 To: Radiator List Subject: (RADIATOR) event handler Speaking of timed queries (in AddressAllocator SQL)... Is there a way of adding my own queries to be executed on a periodical or time-based way? That is, can I set a do this arbitrary query every 6 hours and a do this other arbitrary query every monday at 3:30 AM? TIA -- Mariano Absatz El Baby -- Time spent petting the cat is never wasted... signed, The Cat === 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. -- Mariano Absatz El Baby -- I write all my critical routines in assembler, and my comedy routines in FORTRAN. -Anonymous === 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) remote radiator restart
Hi, I am running Radiator 2.18.2 on a couple of Sun Netras (Solaris 8) authenticating against an Oracle database (on yet another Netra). We developed a web based front end for administration of the users in the Oracle database on a Sun Ultra 10 (also Solaris 8) with Apache and embedded Perl. The point is that, for instance, when I try to invoke a restart script through ssh, I get the following error: Doing it so through rsh, it works but it locks the connection (and anyway, I'd rather not have rshd running on the server. On the other hand, the manual states that through the SNMP agent I can restart Radiator, but I don't know how. Am I missing something? (I think this would be the cleanest method to do it). -- Mariano Absatz El Baby -- Stack Error: Lost on a cluttered desk... === 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) 2.18.3: ORA-00911: invalid character
Hi,
I didn't download the new version... but looking at Pavel's message, what it
seems is that the %0 and %2 arguments have not been replaced by the correct
vaules... in runtime (i.e. when the log is generated), %0 should be replaced
by the NAS-Identifier and %2 with the NAS-Port attributes...
Mike?
It seems I'll wait a couple more days before installing it :-)
El 30 Aug 2001, a las 14:39, Colin D. Easton escribió:
Hi all,
Ok digging deeper into the code it appears it's not SqlDb.pm that is the
problem but rather SessSQL.pm:
SessSQL.pm:$self-{DeleteQuery} = delete from RADONLINE where
NASIDENTIFIER='%0' and NASPORT=0%2;
Note the missing tick ' where the zero is 0 above.
Hmm shouldn't this have been caught in the alpha or beta test cycle?
Come on guys.
Colin
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Colin D. Easton
Sent: Thursday, August 30, 2001 11:45 AM
To: 'Pavel A Crasotin'; Radiator
Subject: RE: (RADIATOR) 2.18.3: ORA-00911: invalid character
I have the same thing. Looks like there's a bug in the Sqldm.pm code
release for Radiator 2.8.3:
lab1.yml# ./radpwtst -user user-name -password password
sending Access-Request...
OK
sending Accounting-Request Start...
DBD::Oracle::db do failed: ORA-00911: invalid character (DBD ERROR:
OCIStmtExecute) at /usr/local/lib/perl5/site_perl/5.005/Radius/SqlDb.pm
line 232.
DBD::Oracle::db do failed: ORA-00911: invalid character (DBD ERROR:
OCIStmtExecute) at /usr/local/lib/perl5/site_perl/5.005/Radius/SqlDb.pm
line 232.
DBD::Oracle::db do failed: ORA-1: unique constraint
(RADIUS15.RADONLINE_PK) violated (DBD ERROR: OCIStmtExecute) at
/usr/local/lib/perl5/site_perl/5.005/Radius/SqlDb.pm line 232.
OK
sending Accounting-Request Stop...
OK
Please advise.
Colin
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On
Behalf Of Pavel A Crasotin
Sent: Thursday, August 30, 2001 4:28 AM
To: [EMAIL PROTECTED]
Subject: (RADIATOR) 2.18.3: ORA-00911: invalid character
Hi,
I've just installed Radiator 2.18.3.
In the logfile I see ERR message like this:
Thu Aug 30 12:12:37 2001: DEBUG: Handling request with Handler ''
Thu Aug 30 12:12:37 2001: DEBUG: SessDB Adding session for MARGO,
x.x.x.2, 4
Thu Aug 30 12:12:37 2001: DEBUG: do query is: delete from RADONLINE
where NASIDENTIFIER='%0' and NASPORT=0%2
Thu Aug 30 12:12:37 2001: ERR: do failed for 'delete from RADONLINE
where NASIDENTIFIER='%0' and NASPORT=0%2': ORA-00911: invalid character
(DBD ERROR: OCIStmtExecute)
Thu Aug 30 12:12:43 2001: ERR: do failed for 'delete from RADONLINE
where NASIDENTIFIER='%0' and NASPORT=0%2': ORA-00911: invalid character
(DBD ERROR: OCIStmtExecute)
Thu Aug 30 12:12:43 2001: DEBUG: do query is: insert into RADONLINE
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP,
FRAMEDIPADDRESS, NASPORTTYPE,SERVICETYPE) values ('MARGO', 'x.x.x.2',
04, '11C9', 999159157, '', 'Async', 'Framed-User')
Thu Aug 30 12:12:45 2001: ERR: do failed for 'insert into RADONLINE
(USERNAME, NASIDENTIFIER, NASPORT, ACCTSESSIONID, TIME_STAMP,
FRAMEDIPADDRESS, NASPORTTYPE,SERVICETYPE) values ('MARGO', 'x.x.x.2',
04, '11C9', 999159157, '', 'Async', 'Framed-User')': ORA-1:
unique constraint (RADIUS.RADONLINE_I) violated (DBD ERROR:
OCIStmtExecute)
Can you help me to correct this bug?
With respect,
Pavel A Crasotin
OJSC SeverTransCom
40/13 Sobinova, Yaroslavl, 15, Russia
Tel/Fax: +7 (0852) 47-71-70, 47-69-49
+7 (0852) 72-17-28, 72-17-38
--
Mariano Absatz
El Baby
--
This isn't an office. It's Hell with fluorescent lighting.
===
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) NAS-Identifier value
Thanx a lot, Hugh.
El 28 Aug 2001, a las 9:58, Hugh Irvine escribió:
Hello Mariano -
On Monday 27 August 2001 23:04, Mariano Absatz wrote:
Hi,
for what I understand of the standard (RFC2865 section 5.32) the NAS-
Identifier attribute is an arbitrary string used to identify the NAS.
Yes, although it is usually a fully qualified domain name, and that is what
Radiator expects it to be.
However, when I put a simple string in a ClientListSQL it complains that
it can´t resolve an address for it.
I had something like this:
==
ClientListSQL
# Client (NAS) info is in the database
include %{GlobalVar:ConfigDir}/DBUseData.cfg
GetClientQuery SELECT \
NAS_IDENTIFIER, NAS_SECRET, \
NAS_IGNOREACCTSIGNATURE, NAS_DUPINTERVAL, \
NAS_DEFAULTREALM, NAS_TYPE, NAS_SNMPCOMMUNITY, \
NAS_LIVINGSTONOFFS, NAS_LIVINGSTONHOLE, \
NAS_FRAMEDGROUPBASEADDRESS, NAS_FRAMEDGROUPMAXPORTSPERCLAS, \
NAS_REWRITEUSERNAME, NAS_NOIGNOREDUPLICATES, \
NAS_PREHANDLERHOOK \
FROM NAS
/ClientListSQL
==
The message in the log is:
==
Sat Aug 25 12:07:40 2001: ERR: Could not resolve an address for Client CPM1
Sat Aug 25 12:07:41 2001: INFO: Server started: Radiator 2.18.2 on radius1
==
However, in the database, NAS_IDENTIFIER is a common name (in fact, it's
the table's id field) and I have a NAS_IP_ADDRESS field.
Re-reading the manual, I see there is no place to hold the
NAS-IP-Address... should I use NAS_IP_ADDRESS as the first field in the
query?
All the fields ar taken in order? that is, it works as if it had an
implied ClientColumnDef or something like that?
Yes, the fields are taken in order.
From section 6.6.2 in the Radiator 2.18.2 reference manual:
Your database table must include at least the first and second fields (i.e.
the NAS name or IP address and the shared secret). All the other fields are
optional, but if they occur, they must occur in the same order. When they
occur, they are used to initialize the Client parameter of the same name as
shown above. The FRAMEDGROUPBASEADDRESS column may contain multiple
comma-separated base addresses.
# Our custom client table only has NAS identifier,
# shared secret and default realm in it:
GetClientQuery select NAME,SECRET,NULL,NULL,DREALM
hth
Hugh
--
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) NAS-Identifier value
Hi,
for what I understand of the standard (RFC2865 section 5.32) the NAS-
Identifier attribute is an arbitrary string used to identify the NAS.
However, when I put a simple string in a ClientListSQL it complains that it
can´t resolve an address for it.
I had something like this:
==
ClientListSQL
# Client (NAS) info is in the database
include %{GlobalVar:ConfigDir}/DBUseData.cfg
GetClientQuery SELECT \
NAS_IDENTIFIER, NAS_SECRET, \
NAS_IGNOREACCTSIGNATURE, NAS_DUPINTERVAL, \
NAS_DEFAULTREALM, NAS_TYPE, NAS_SNMPCOMMUNITY, \
NAS_LIVINGSTONOFFS, NAS_LIVINGSTONHOLE, \
NAS_FRAMEDGROUPBASEADDRESS, NAS_FRAMEDGROUPMAXPORTSPERCLAS, \
NAS_REWRITEUSERNAME, NAS_NOIGNOREDUPLICATES, \
NAS_PREHANDLERHOOK \
FROM NAS
/ClientListSQL
==
The message in the log is:
==
Sat Aug 25 12:07:40 2001: ERR: Could not resolve an address for Client CPM1
Sat Aug 25 12:07:41 2001: INFO: Server started: Radiator 2.18.2 on radius1
==
However, in the database, NAS_IDENTIFIER is a common name (in fact, it's the
table's id field) and I have a NAS_IP_ADDRESS field.
Re-reading the manual, I see there is no place to hold the NAS-IP-Address...
should I use NAS_IP_ADDRESS as the first field in the query?
All the fields ar taken in order? that is, it works as if it had an implied
ClientColumnDef or something like that?
TIA.
--
Mariano Absatz
El Baby
--
Your e-mail has been returned due to insufficient voltage.
===
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) ClientListSQL
Hi, we have a setup with radiator on one host, an Oracle database on another one with everything on it (users, services, NAS's, etc.) and a web application running on yet another host to modify the database. Now, one of the tables is equivalent to RADCLIENTLIST (see http://www.open.com.au/radiator/ref.html#pgfId=391059). The point is that the web application allows me to change stuff in this table (insert new NAS's, change the parameters of another one, etc.), but as far as I can see, this table is read at radiator startup and is not updated. Is there a way to trigger updates to the internal NAS list from the table (other than restartin Radiator)? The problem I have is that to restart radiator remotely I should use rsh or something dirty like that which I'm not quite eager to do... TIA. -- Mariano Absatz El Baby -- Late one night in the middle of the day, two dead soldiers got up to fight. Back to back they faced each other, pulled out their swords and shot one another. A deaf policeman heard the noise, got up and shot the twice dead boys. If you don't believe me, ask the blind man who saw it all, through a knothole in a wooden brick wall. === 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: Fwd: (RADIATOR) log files behavior
Hi Mike, Hugh... it's been more than a couple of months since this message... in fact, the Log.pm got into 2.18.2 in the meantime... the problem I have is that I still couldn't solve my first item: 1) As I noted in a message exchange with Hugh (cc: the list) a couple of weeks ago, AuthLog FILE is not working. The file isn't created at all (and Radiator has sufficient permissions since a Log FILE in the same directory IS created. Today I added an AuthLog SQL besides the AuthLog FILE to no avail... I also erased all of my Radiator installation (since I had used it to test some modules you sent me prior to release) and re-installed the plain 2.18.2 (without any patches, since none of them seem to be at all related with my problem). I still can't get it working... Whatever I do, the log files aren't created (there is no permissions problem, in fact, Radiator is running as root), the database table for authlogging is empty. I'm attaching all of my config files radius-*.cfg (one of them is for accounting only, other for authentication only and the larger one is included in both). The other files include an add-on for the dictionary (with faked attributes) and other files included from the config files. Do you have a clue on why it isn't working? Anything I can do to check here? Here's a small portion of an authentication seen from the authentication debug log ## Mon Aug 6 11:15:11 2001: DEBUG: Packet dump: *** Received from 127.0.0.1 port 33754 Code: Access-Request Identifier: 190 Authentic: 1234567890123456 Attributes: User-Name = baby@pert Service-Type = Framed-User NAS-IP-Address = 200.59.130.83 NAS-Port = 1234 Called-Station-Id = 123456789 Calling-Station-Id = 987654321 NAS-Port-Type = Async User-Password = A/225x%251233:238192220`17612\146 Mon Aug 6 11:15:11 2001: DEBUG: Rewrote user name to baby@pert Mon Aug 6 11:15:11 2001: DEBUG: Rewrote user name to baby@pert Mon Aug 6 11:15:11 2001: DEBUG: Check if Handler Request-Type = Access- Request should be used to handle this request Mon Aug 6 11:15:11 2001: DEBUG: Handling request with Handler 'Request-Type = Access-Request' Mon Aug 6 11:15:11 2001: DEBUG: SessDBUsers Deleting session for baby@pert, 200.59.130.83, 1234 Mon Aug 6 11:15:11 2001: DEBUG: do query is: DELETE FROM USUARIOS_EN_LINEA WHERE USUA_IP_NAS='200.59.130.83' AND USUA_PORT='12 34' Mon Aug 6 11:15:11 2001: DEBUG: Handling with Radius::AuthSQL Mon Aug 6 11:15:11 2001: DEBUG: Handling with Radius::AuthSQL Mon Aug 6 11:15:11 2001: DEBUG: Query is: SELECT U.USU_CLAVE, S.SER_CODIGO, S.SER_MAX_SESSION_CONCURRENTES, S.TIMEFRAMEID, S.S ER_GEN_CHECK, S.SER_GEN_REPLY, VS.VISP_SER_VALID_DNIS, U.USU_IP_NRO_FIJA, U.USU_IP_MASC_FIJA, U.USU_TIEMPO_RESTANTE, U.USU_BYTE S_RESTANTES, U.USU_SUSPENDIDO, U.USU_GEN_CHECK, U.USU_GEN_REPLY, NC.POOL_NAME FROM USUARIOS U, VISP V, SERVICIOS S, VISP_SERVIC IOS VS, NAS_CALIDAD NC WHERE U.VISP_CODIGO = V.VISP_CODIGO AND U.SER_CODIGO = S.SER_CODIGO AND VS.VISP_CODIGO = V.VISP_CODIGO A ND VS.SER_CODIGO = S.SER_CODIGO AND U.USU_CODIGO = 'baby' AND U.VISP_CODIGO = 'pert' AND S.CAL_CODIGO = NC.CAL_CODIGO AND NC.NA S_IDENTIFIER = '200.59.130.83' Mon Aug 6 11:15:11 2001: DEBUG: Radius::AuthSQL looks for match with baby@pert Mon Aug 6 11:15:11 2001: INFO: Access rejected for baby@pert: No such user Mon Aug 6 11:15:11 2001: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 33754 Code: Access-Reject Identifier: 190 Authentic: 1234567890123456 Attributes: Reply-Message = Request Denied ## El 10 May 2001, a las 11:31, Mike McCauley escribió: Hello Mariano, Thanks for raising item 2 below. It is indeed a bug, which we have now fixed. The problem was that global LogFile and Trace parameters would not be effected until after the configuration file had been completely read. I have attached new files of 3 files required to fix this problem. Perhaps you would like to test it? The new files are radiusd, Log.pm and ServerConfig.pm. We apologise for this problem. Please let me know how you go. Cheers. On May 10, 8:05am, Hugh Irvine wrote: Subject: Fwd: (RADIATOR) log files behavior Mikey - More on the logging problem. cheers Hugh -- Forwarded Message -- Subject: (RADIATOR) log files behavior Date: Wed, 9 May 2001 15:00:46 -0300 From: Mariano Absatz [EMAIL PROTECTED] To: Radiator List [EMAIL PROTECTED] Hi, wrapping up my messages of the last days, I see two (somehow) weird things happening with the logs. 1) As I noted in a message exchange with Hugh (cc: the list) a couple of weeks ago, AuthLog FILE is not working. The file isn't created at all (and Radiator has sufficient permissions since a Log FILE in the same directory
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?
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) Reliable accounting?
Hi Mike, Julio I guess I don't fully understand what's beeing discussed. Mike, how do you expect to do reliable UDP between Radiator and something- else, this being a NAS, or a proxying or proxied Radius server, when you can only change Radiator? Or is there something called reliable radius udp that I don't know of? In this case, do you have a reference I can glance on? (RFC, I-D, whatever on- line docs?) I have the same problem as Julio (and I guess, from the same source ;-). I'd really LOVE to have accounting records reliably delivered to my Radiator, but every time there is a problem with the NAS, I loose packets... (problems include partial failures, software patches and other oddities), and NO, I don't have access to the NAS. The network in question is wholly owned by my client and, although I have seen malformed packets on the wire (not specifically Radius), I guess the main culprit of packet loss is not the network per-se but the NAS... El 1 Jun 2001, a las 12:20, [EMAIL PROTECTED] escribió: Hello Mike, We have serious problems with acct. requests that are lost. Actually we use scripts made by us to check really-used ports and delete incorrect entries in RADONLINE table. The frequency of the executions of these scripts is high. And they use radpwtst to correct bad entries in RADONLINE. So extra traffic is generated to maintain a reliable information about accounting. We are the carrier and we're very interested in solving this problem. So if you want, we could collaborate in testing any development about this theme in our laboratory as a 'friendly customer'. regards, jules -Mensaje original- De: Mike McCauley [mailto:[EMAIL PROTECTED]] Enviado el: viernes 1 de junio de 2001 19:32 Para: [EMAIL PROTECTED] Asunto: (RADIATOR) Reliable accounting? Hello all, As we all know, the Radius protocol permits accounting records to be lost when network packet losses are serious. We are working with a third party on the possibility of reliable Radius UDP delivery for accounting. So I am wondering if there are people who are being badly affected by this? How bad a problem is it for you? Is the packet loss in carrier network you dont control, or in your own? Reply to me off-list if you prefer. Cheers. -- Mike McCauley [EMAIL PROTECTED] Open System Consultants Pty. LtdUnix, Perl, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia http://www.open.com.au Phone +61 3 9598-0985 Fax +61 3 9598-0955 Radiator: the most portable, flexible and configurable RADIUS server anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald, Platypus, Freeside, TACACS+, PAM, external, Active Directory etc etc on Unix, Win95/8, 2000, NT, MacOS 9, 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. ** Noticia legal Este mensaje electrónico contiene información de BT Telecomunicaciones S.A. que es privada y confidencial, siendo para el uso exclusivo de la persona (s) o entidades arriba mencionadas. Si usted no es el destinatario señalado, le informamos que cualquier divulgación, copia, distribución o uso de los contenidos está prohibida. Si usted ha recibido este mensaje por error, por favor borre su contenido y comuníquenoslo en la dirección [EMAIL PROTECTED] Gracias. === 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. Mariano Absatz El Baby -- Question: If someone with multiple personalities tries to commit suicide, do the police consider it a hostage situation? === 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) proxy impersonating many NASen :-(
of the message. Mariano Absatz El Baby -- Justify my text? I'm sorry but it has no excuse. === 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) inter-AuthBy's hook and other stuff
El 28 May 2001, a las 10:25, Hugh Irvine escribió: Hello Mariano - On Monday 28 May 2001 06:16, Mariano Absatz wrote: Hi, I'm reading the section 19.0 Execution sequence and Hook processing from the Radiator manual and the execution sequence reads like: I'm very pleased to see you reading the manual! :-) FTR, I DID read all of the manual when we bought Radiator (it was 2.16.3, then), but anyway, you allways do the reading with some short vision and some things you read either you forget or it goes somewhere in the bottom of your mind from where you get the feeling you know something, but not quite well... :-) 14. Accounting log files (AcctLogFileName and WtmpFileName) written 15. PreAuthHook called 16. AuthBy clauses invoked 17. PostAuthHook called 18. Reply sent to NAS (unless request was proxied) What I want is the possibility to have a PostTHISAuthByHook that executes AFTER a specific AuthBy but BEFORE the next one (inside an AuthByPolicy block). There is no provision for this in the standard code. :-( That is, I would like to check stuff returned by a specific AuthBy... and maybe decide I will change the result of that AuthBy (from accept to reject or something else). How can I do this? I would suggest that you use a PostAuthHook which itself will call one or more supplementary AuthBy clauses, check the result(s) and do whatever is required. There are examples of how to do this sort of thing in the file goodies/hooks.txt. I'm quick-browsing this file and can't find how to do this... how do I invoke an AuthBy XXX from inside a hook? Also, I would like to add certain stuff I'm SELECTing in an AuthSelect to the RequestPacket... can I do this? As far as I understand, if I put AuthColumnDef 3, Some-Attr, reply it will add the 4th column from my select to the ReplyPacket as the Some-Attr attribute. But, if I use AuthColumnDef 3, Some-Attr, check it will CHECK the 4th column from my select to the RequestPacket and FAIL if it doesn't match. I want to temporarly store this attribute to do some processing afterwards (e.g. because the checking is more complicated than a simple x=y). I remember Hugh said that it's better to store this temporary data in the RequestPacket (which will be deleted after its processing finishes) than in the ReplyPacket (from where I do have to manually delete them before I send it back to the NAS). In this particular case, I am getting a column that has a regexp against which to match the Calling-Station-Id and another against which to match the Called-Station-Id. The point is that, this stuff is not very reliable (depending on how the call is routed and a bunch of other things, the caller- ID might be different, at least the first few digits), and I want to give more flexibility (this user can call from a bunch of different number, e.g. all the out-dial numbers of a PABX). I intend to do a ~= in a hook after getting this data, but 1) don't want to manually delete it from the reply, and 2) don't want to wait 'till other AuthBy's are executed before rejecting an invalid call. Am I completely off-base with this? Has anyone done something like this? FYI, all my AuthBy's are SQL's against an Oracle DB. You should use this construct to put something into the request packet: AuthColumnDef 3, Some-Attr, request Great!! I didn't see THIS in the manual... now I'm searching for , request and only find it in 6.33.14 AuthAttrDef (in LDAP) and NOT in 6.26.7 AuthColumnDef (in SQL)... maybe a little comment/example in the next release of the manual? :-) I intend to: 1) check username/realm/password validity and, in the same AuthSelect, would get a propietary service-code, max # of ports for this realm AND this service- code AND this valid-DNIS-set, valid DNIS and Caller-ID, simultaneous-use (for this user), etc. Fine. 2) if that passes, I will PORTLIMITCHECK based on the realm/max # of ports/service-code/valid-DNIS-set Fine. 3) if that passes AND the user had not been assigned a fixed-IP address (in 1), I will select a DYNADDRESS based on service-code/NAS-Identifier (service- code's define, among other stuff, a QOS that will be applied differently to different IP address pools. You can quite happily call an AuthBy DYNADDRESS in this situation, as the first thing it does is check for the presence of a Framed-IP-Address in the reply packet, and if it finds one it simply returns. An AuthBy DYNADDRESS will only try to allocate an address if one is needed, ie. if there is no Framed-IP-Address present in the reply. OK hth Hugh -- 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
(RADIATOR) inter-AuthBy's hook and other stuff
Hi, I'm reading the section 19.0 Execution sequence and Hook processing from the Radiator manual and the execution sequence reads like: 14. Accounting log files (AcctLogFileName and WtmpFileName) written 15. PreAuthHook called 16. AuthBy clauses invoked 17. PostAuthHook called 18. Reply sent to NAS (unless request was proxied) What I want is the possibility to have a PostTHISAuthByHook that executes AFTER a specific AuthBy but BEFORE the next one (inside an AuthByPolicy block). That is, I would like to check stuff returned by a specific AuthBy... and maybe decide I will change the result of that AuthBy (from accept to reject or something else). How can I do this? Also, I would like to add certain stuff I'm SELECTing in an AuthSelect to the RequestPacket... can I do this? As far as I understand, if I put AuthColumnDef 3, Some-Attr, reply it will add the 4th column from my select to the ReplyPacket as the Some-Attr attribute. But, if I use AuthColumnDef 3, Some-Attr, check it will CHECK the 4th column from my select to the RequestPacket and FAIL if it doesn't match. I want to temporarly store this attribute to do some processing afterwards (e.g. because the checking is more complicated than a simple x=y). I remember Hugh said that it's better to store this temporary data in the RequestPacket (which will be deleted after its processing finishes) than in the ReplyPacket (from where I do have to manually delete them before I send it back to the NAS). In this particular case, I am getting a column that has a regexp against which to match the Calling-Station-Id and another against which to match the Called-Station-Id. The point is that, this stuff is not very reliable (depending on how the call is routed and a bunch of other things, the caller- ID might be different, at least the first few digits), and I want to give more flexibility (this user can call from a bunch of different number, e.g. all the out-dial numbers of a PABX). I intend to do a ~= in a hook after getting this data, but 1) don't want to manually delete it from the reply, and 2) don't want to wait 'till other AuthBy's are executed before rejecting an invalid call. Am I completely off-base with this? Has anyone done something like this? FYI, all my AuthBy's are SQL's against an Oracle DB. I intend to: 1) check username/realm/password validity and, in the same AuthSelect, would get a propietary service-code, max # of ports for this realm AND this service- code AND this valid-DNIS-set, valid DNIS and Caller-ID, simultaneous-use (for this user), etc. 2) if that passes, I will PORTLIMITCHECK based on the realm/max # of ports/service-code/valid-DNIS-set 3) if that passes AND the user had not been assigned a fixed-IP address (in 1), I will select a DYNADDRESS based on service-code/NAS-Identifier (service- code's define, among other stuff, a QOS that will be applied differently to different IP address pools. Mariano Absatz El Baby -- When there's a will, I want to be in it. === 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.
LOOKOUT - VIRUS (was:Re: Re: (RADIATOR) Radiator accouting on mysql Mexico)
Hi People, Hi Faez,
I know it's probably a little late... I'm setting high priority on this
message, but as every mailer uses different means to do that, I guess
many people won't notice that.
This morning (or whatever, depending on where in the world you are), I
received a direct reply to each of the messages I sent to the list in the
last days.
The format was the same ('My Name' wrote:, then the contents of my
message indented with '-'s and a Take a look to the attachment. note in
the end). The attachment had different names but all simulating being a
doc or zip file, having, in the end a .pif or .scr extension. I know
many mailers, depending on the OS configuration, don't show the extension
for known extensions, so you might not see it.
The attachment was, obviously, a virus, that my antivirus identified as
W32.Badtrans.13312@mm and the messages were apparently sent from a
Microsoft Outlook Express 5.00.2919.6700.
Moral is... don't open attachments that you don't know exactly what they
are EVEN if it seems a reply to a message of your AND it comes from a
know person... here I don't know Faez, but I guess all of his friends
received answers to real messages sent to him.
Faez, if you read this, please, clean up you computer.
El 23 May 2001, a las 13:56, Faez Itrat escribió:
'Mariano Absatz' wrote:
- El 9 May 2001, a las 10:02, Anton Krall escribió:
-
- Date: Wed, 9 May 2001 10:02:59 -0500
- From: Anton Krall [EMAIL PROTECTED]
- X-Mailer: The Bat! (v1.45) Personal
- Reply-to: Anton Krall [EMAIL PROTECTED]
- Organization: Dir. de Tecnologia - Inter.net Mexico
- To: [EMAIL PROTECTED]
- Subject: (RADIATOR) Radiator accouting on mysql Mexico
- JOKE¿mysql funciona distinto en Mexico que en ot ...'
Take a look to the attachment.
Mariano Absatz
El Baby
--
You look like shit. Is that the style now?
===
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) SessSQL.pm patch
-changeAttrByNum($Radius::Radius::ACCT_SESSION_ID, + $orig_session_id); + $p- changeAttrByNum($Radius::Radius::FRAMED_IP_ADDRESS, + $orig_framed_ip_address); $count--; last if $count $max; == == == Mariano Absatz El Baby -- Hex dump: Where witches put used curses... === 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) CHAP
El 16 May 2001, a las 9:08, Ingvar Berg (EIP) escribió: Or rather: you have to be able to decrypt them in Radiator, before using them. I'm not sure if you can do this with a hook, or if you need to hack the basic code in Radiator (i.e. persuade Mike or Hugh to do some fun coding...) or DIY :-)... but the point here is that most of the encryption schemes used for storing passwords are one way hash fucntions (one way beeing the key point here). You can't (without a considerable computational effort far beyond an authentication server) get the original password from the encrypted one. If you were to use a two way encryption scheme, it would have to encrypt and decrypt with the same key (if it uses a symmetric algorithm like DES, DES3, or the like) or encrypt with one key and decrypt with another, both generated as a pair (conventionally, one is supposed to be public and the other private). The point is that this way, you should put the (master) decryption key open in the radiator config file, so you just moved the weak point to another place. Now, if you, for instance, keep the passwords in a public open database (or LDAP tree or whatever) where anyone can see it and you can keep you radiator configuration file really secure (i.e. mode 400 root owned inside a mode 500 root owned directory and a really controlled set of trustable people knowing the root password), you (or Mike) could do it. -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: den 15 maj 2001 02:54 To: Anton Krall; [EMAIL PROTECTED] Subject: Re: (RADIATOR) CHAP Hello Anton - You cannot use CHAP authentication with with encrypted passwords in your database. If you want to use encrypted passwords in the database, you will have to use PAP authentication. If you want to use CHAP authentication you will have to use plaintext passwords in the database. hth Hugh On Tuesday 15 May 2001 08:51, Anton Krall wrote: Guys. Im getting this error when trying to autenticate with CHAP: Mon May 14 17:47:54 2001: DEBUG: Rewrote user name to [EMAIL PROTECTED] Mon May 14 17:47:54 2001: DEBUG: Rewrote user name to [EMAIL PROTECTED] Mon May 14 17:47:54 2001: DEBUG: Handling request with Handler 'Realm=mx.inter.net' Mon May 14 17:47:54 2001: DEBUG: Rewrote user name to akrall Mon May 14 17:47:54 2001: DEBUG: SDBSQLdialup Deleting session for [EMAIL PROTECTED], 10.0.0.0, 1234 Mon May 14 17:47:54 2001: DEBUG: do query is: delete from RADONLINE where NASIDENTIFIER='10.0.0.0' and NASPORT=01234 Mon May 14 17:47:54 2001: DEBUG: Handling with Radius::AuthSQL Mon May 14 17:47:54 2001: DEBUG: Handling with Radius::AuthDBFILE Mon May 14 17:47:54 2001: DEBUG: Radius::AuthDBFILE looks for match with akrall Mon May 14 17:47:54 2001: WARNING: Cant use encrypted passwords with CHAP Mon May 14 17:47:54 2001: DEBUG: Radius::AuthDBFILE REJECT: Bad Encrypted password Mon May 14 17:47:54 2001: DEBUG: Handling with Radius::AuthDBFILE Mon May 14 17:47:54 2001: DEBUG: Radius::AuthDBFILE looks for match with akrall Mon May 14 17:47:54 2001: INFO: Access rejected for akrall: No such user Mon May 14 17:47:54 2001: DEBUG: Packet dump: My password are like this: user [crypt]HAFJSGFD Whatst he matter? Saludos Anton Krall Director de Tecnologia Inter.net Mexico (www.mx.inter.net) Email: [EMAIL PROTECTED] Directo: 5-241-7609 Conmutador: 5-241-7600 Mobile: 044-5105-5160 Outside Mexico: Office: (525)241-7609 PBX: (525)241-7600 Mobile: (525)105-5160 === 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. Mariano Absatz El Baby -- Don't worry. I forgot your name, too! === 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) SessionDatabase SQL
El 15 May 2001, a las 10:50, Hugh Irvine escribió:
Hello Mariano -
Why don't you use this:
%d%H%M%S
Right, now it's:
AddQuery INSERT INTO USUARIOS_EN_LINEA \
(USU_CODIGO, VISP_CODIGO, USUA_SESION_ID, \
USUA_IP_NAS, POOL_NAME, USUA_PORT, USUA_BYTES, USUA_TIEMPO, \
USUA_HORA_CONEXION, USUA_CALL_ID, USUA_DNIS, USUA_IP_ASIGNADA) \
VALUES \
('%U', '%R', '%{Acct-Session-Id}', \
'%N', 'nombre del pool', %{NAS-Port}, 0, 0, \
TO_DATE('%Y-%m-%d %H:%M:%S', '-MM-DD HH24:MI:SS'), \
'%{Calling-Station-Id}', '%{Called-Station-Id}', '%{Framed-IP-Address}')
and it works but... where am I supposed to get things from?
Where does the timestamp in this sql statement coming from?
In the manual:
http://www.open.com.au/radiator/ref.html#25705 (TABLE 2. DateFormat
special characters)
is giving me characters to format an (arbitrary?) epoch and
http://www.open.com.au/radiator/ref.html#22600 (TABLE 1. Special string
formatting characters)
is giving me characters to insert either the current time or the current
packet timestamp (being the later what I wanted, but would settle for the
other)
As I had it configured before
TO_DATE('%f-%g-%i %j:%k:%p', '-MM-DD HH24:MI:SS')
I understood I was directly taking the current packet timestamp and
generating '-MM-DD HH:mm:SS' where (from the manual's Table 1)
: The Timestamp year (4 digits)
MM: The Timestamp month number (2 digits)
DD: The Timestamp day of the month (2 digits)
HH: The Timestamp hour (0-23)
mm: The Timestamp minute (0-59)
SS: the Timestamp second (0-59)
^BTW, the lowcase t in the manual is inconsistent :-)
The problem here was that at least %p doesn't add a leading 0.
In the current configuration, I am using the fields from Table 2
formatting an unknown date-time (I guess it's the current one).
TO_DATE('%Y-%m-%d %H:%M:%S', '-MM-DD HH24:MI:SS')
As the info in the manual wasn't all that clear about it, I changed the
date in the machine and confirmed that %m and %d also use a leading 0
(THAT isn't written in the manual).
So now I have it working, now for the theoretical part of the question,
if I had a radius attribute with an arbitrary date-time in it (say, the
birthday -and time- of the nas manufacturer's mother) and I would like to
put it in a column in my on-line users database, what would be the idiom
to do it so?. That is I understand (I think) how to put it in an
accounting database by means of a
AcctColumnDef DB_COLUMN,Radius-Attribute-Name,integer-date, \
TO_DATE('%Y-%m-%d %H:%M:%S', '-MM-DD HH24:MI:SS')
but in the AddQuery (or AnythingQuery) I don't know how to use Radius-
Attribute-Name here.
regards
Hugh
On Tuesday 15 May 2001 07:56, Mariano Absatz wrote:
Hi,
I'm having problems with a SessionDatabase SQL... I want to use the
timestamp in the AddQuery (with Oracle), but '%p' is yelding a 1 digit
second if the seconds in the timestamp is 10.
Following is the corresponding part in the config file and afterwards, a
trace 4.
Note, in the trace, that it says
TO_DATE('2001-05-14 18:38:2', '-MM-DD HH24:MI:SS')
instead of
TO_DATE('2001-05-14 18:38:02', '-MM-DD HH24:MI:SS')
SessionDatabase SQL
Identifier SessDBUsers
include %{GlobalVar:ConfigDir}/DBUseData.cfg
AddQuery INSERT INTO USUARIOS_EN_LINEA \
(USU_CODIGO, VISP_CODIGO, USUA_SESION_ID, \
USUA_IP_NAS, POOL_NAME, USUA_PORT, USUA_BYTES,
USUA_TIEMPO, \
USUA_HORA_CONEXION, USUA_CALL_ID, USUA_DNIS,
USUA_IP_ASIGNADA) \
VALUES \
('%U', '%R', '%{Acct-Session-Id}', \
'%N', 'nombre del pool', %{NAS-Port}, 0, 0, \
TO_DATE('%f-%g-%i %j:%k:%p', '-MM-DD HH24:MI:SS'), \
'%{Calling-Station-Id}', '%{Called-Station-Id}',
'%{Framed-IP-Address}')
DeleteQuery DELETE FROM USUARIOS_EN_LINEA \
WHERE USU_CODIGO='%U' AND VISP_CODIGO='%R' AND \
USUA_IP_NAS='%N' AND USUA_PORT='%{NAS-Port}'
ClearNasQuery DELETE FROM USUARIOS_EN_LINEA \
WHERE USUA_IP_NAS='%N'
CountQuery SELECT USUA_IP_NAS, USUA_PORT, USUA_SESION_ID \
FROM USUARIOS_EN_LINEA \
WHERE USU_CODIGO='%U' AND VISP_CODIGO='%R'
/SessionDatabase
Mon May 14 18:38:02 2001: INFO: Server started: Radiator 2.18.1 on mr-visp
Mon May 14 18:38:02 2001: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 41858
Code: Accounting-Request
Identifier: 198
Authentic: Gr16253197+2152219223`eSUK
Attributes:
User-Name = yaNi@pert
Service-Type = Framed-User
NAS-IP-Address = 200.59.130.83
NAS-Port = 1234
NAS-Port-Type = Async
Acct-Session-Id = hola001
Acct-Status-Type = Start
RE: (RADIATOR) Duplicate Logins
El 15 May 2001, a las 11:29, Ingvar Berg (EIP) escribió: [See inserted comment] -Original Message- From: Hugh Irvine [mailto:[EMAIL PROTECTED]] Sent: den 12 maj 2001 10:33 To: Anton Krall; [EMAIL PROTECTED] Subject: Re: (RADIATOR) Duplicate Logins Hello Anton - The reason Radiator does a delete when it receives an access request is because an accounting stop may have gone missing. Note that the delete is done on the NAS and NAS=Port combination reported in the request, because by definition there cannot already be a session there. IngBe But then again there are clients that don't have physical ports, how do you handle that case? I.e. the port number might be constant (0) or just some internal ref number used by the client. /IngBe In fact, you should check your NAS documentation or, if not available (as is my case), do a bunch of different authentications with radiator in trace 4. For instance, Nortel's Shasta (my dearly behated enemy) didn't have a NAS- Port... in a recent version they added NAS-Port-Id (it's a string, not a number) that, in fact, is unique (so it's no good for the automatic deletion of stale sessions), but does the job of not deleting any session 'cause NAS-Port is 0 or nonexistent. The Shasta also sends the Acct-Session-Id with the Access-Request packet, so you can also use it (in fact, it's the one I'm using). I guess any tunnel terminator is probably able to send you the Acct-Session-Id with the Access-Request packet besides sending it with every accounting packet. Notice that your second request is the same as the first, so the first record is deleted, hence the second request is accepted. If you want to test simultaneous use you will have to use different values in your requests. This topic has been discussed *many* times, so don't forget to check the mailing list archive at www.starport.net/~radiator and do a search. regards Hugh === 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. === 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) AuthyByPolicy
El 15 May 2001, a las 21:54, Chris Cronje - MWeb escribió: Hi There I was wondering if anyone has done this before ? I'm using Radiator to authenticate off another Radiator server, like a proxy. If the radius server fails, I want my proxy to mark the server dead for 10 minutes and then continue to the next Authby clause, which is AuthBy FILE. What happens in practise is that if my proxy receives a timeout, it retransmits once, marks the server dead for 10 minutes and then says: Tue May 15 21:53:41 2001: INFO: AuthRADIUS could not find a working host to forward to. Ignoring But, it never goes to the next AuthBy statement. Am I doing something wrong in my config here ? Realm DEFAULT AuthByPolicy ContinueUntilIgnore I never did this, but I think the above line should read AuthByPolicy ContinueWhileIgnore In fact, I guess that if your other radius server is actually working, this server would be trying the AuthBy FILE after the AuthBy RADIUS allways (since it wasn't ignored and that is the condition to stop the AuthByPolicy). AuthBy RADIUS Host x.x.x.x Retries 1 RetryTimeout 3 FailureBackoffTime 600 Secret M@x$3$$!0n$ /AuthBy AuthBy FILE Filename users AcceptIfMissing /AuthBy /Realm === 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) Time Session-Timeout
Hi, I would like to do the following. Suppose I have a dial-up product that allows a user to connect only in a certain block time AND also has a maximum hours per month. For instance, he can connect Mon-Fri 8-20 and Sat 8-13 but no more than 20 hours per month. I would have a TIMEBLOCK column in that user database with the following content: MoTuWeThFr0800-2000, Sa0800-2000 (btw, does the weekday support ranges also, like in Mo-Fr0800-2000, Sa0800-2000?) The TIMELEFT column would have the seconds remaining for this user. What I want is to set Session-Timeout to the minimum of until Time and TIMELEFT. But... :-) ... I also want to be able to have a value (in the db column) to ignore either or both: Example database: username,password,timeleft,timeblock john,secret,7200,MoTuWeThFr0800-2000, Sa0800-2000 paul,,-1,Wk0800-2000, Sa0800-2000 mary,abcd,-1,Al-2400 jane,wxyz,126000,Al-2400 being, -1, for instance, an indicator that the user has unlimited monthly connection time (but maybe subject to timeblock restrictions). In this example database john has 2 hours left and can only log on weekdays from 8 through 20 and saturdays from 8 through 13. paul can log in during the same periods but has no total time restrictions. mary has no restrictions at all jane can log in at any time, but she has only 35 hours left. Questions: 1) can I do this weird thing somehow simply? (I already read goodies/blocktime.txt, but this is way more complicated, is it?) (note: I could, if necessary, use a very large value to indicate timeleft=infinity, but I'd rather have a more visual and checkable value, like -1). 2) is the timeblock Al-2400 acceptable? 3) are overlapping timeblocks acceptable? (e.g. Wk0800-1700, MoWeFrSa1500-2000) TIA. Mariano Absatz El Baby -- To define recursion, we must first define recursion. === 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) SessionDatabase SQL
Hi,
I'm having problems with a SessionDatabase SQL... I want to use the
timestamp in the AddQuery (with Oracle), but '%p' is yelding a 1 digit
second if the seconds in the timestamp is 10.
Following is the corresponding part in the config file and afterwards, a
trace 4.
Note, in the trace, that it says
TO_DATE('2001-05-14 18:38:2', '-MM-DD HH24:MI:SS')
instead of
TO_DATE('2001-05-14 18:38:02', '-MM-DD HH24:MI:SS')
SessionDatabase SQL
Identifier SessDBUsers
include %{GlobalVar:ConfigDir}/DBUseData.cfg
AddQuery INSERT INTO USUARIOS_EN_LINEA \
(USU_CODIGO, VISP_CODIGO, USUA_SESION_ID, \
USUA_IP_NAS, POOL_NAME, USUA_PORT, USUA_BYTES,
USUA_TIEMPO, \
USUA_HORA_CONEXION, USUA_CALL_ID, USUA_DNIS,
USUA_IP_ASIGNADA) \
VALUES \
('%U', '%R', '%{Acct-Session-Id}', \
'%N', 'nombre del pool', %{NAS-Port}, 0, 0, \
TO_DATE('%f-%g-%i %j:%k:%p', '-MM-DD HH24:MI:SS'), \
'%{Calling-Station-Id}', '%{Called-Station-Id}',
'%{Framed-IP-Address}')
DeleteQuery DELETE FROM USUARIOS_EN_LINEA \
WHERE USU_CODIGO='%U' AND VISP_CODIGO='%R' AND \
USUA_IP_NAS='%N' AND USUA_PORT='%{NAS-Port}'
ClearNasQuery DELETE FROM USUARIOS_EN_LINEA \
WHERE USUA_IP_NAS='%N'
CountQuery SELECT USUA_IP_NAS, USUA_PORT, USUA_SESION_ID \
FROM USUARIOS_EN_LINEA \
WHERE USU_CODIGO='%U' AND VISP_CODIGO='%R'
/SessionDatabase
Mon May 14 18:38:02 2001: INFO: Server started: Radiator 2.18.1 on mr-visp
Mon May 14 18:38:02 2001: DEBUG: Packet dump:
*** Received from 127.0.0.1 port 41858
Code: Accounting-Request
Identifier: 198
Authentic: Gr16253197+2152219223`eSUK
Attributes:
User-Name = yaNi@pert
Service-Type = Framed-User
NAS-IP-Address = 200.59.130.83
NAS-Port = 1234
NAS-Port-Type = Async
Acct-Session-Id = hola001
Acct-Status-Type = Start
Called-Station-Id = 123456789
Calling-Station-Id = 987654321
Mon May 14 18:38:02 2001: DEBUG: Rewrote user name to yaNi@pert
Mon May 14 18:38:02 2001: DEBUG: Rewrote user name to yani@pert
Mon May 14 18:38:02 2001: DEBUG: Check if Handler should be used to
handle this request
Mon May 14 18:38:02 2001: DEBUG: Handling request with Handler ''
Mon May 14 18:38:02 2001: DEBUG: SessDBUsers Adding session for
yaNi@pert, 200.59.130.83, 1234
Mon May 14 18:38:02 2001: DEBUG: do query is: DELETE FROM
USUARIOS_EN_LINEA WHERE USU_CODIGO='yani' AND VISP_CODIGO='pert' AND
USUA_IP_NAS='200.59.130.83' AND USUA_PORT='1234'
Mon May 14 18:38:02 2001: DEBUG: do query is: INSERT INTO
USUARIOS_EN_LINEA (USU_CODIGO, VISP_CODIGO, USUA_SESION_ID, USUA_IP_NAS,
POOL_NAME, USUA_PORT, USUA_BYTES, USUA_TIEMPO, USUA_HORA_CONEXION,
USUA_CALL_ID, USUA_DNIS, USUA_IP_ASIGNADA) VALUES ('yani', 'pert',
'hola001', '200.59.130.83', 'nombre del pool', 1234, 0, 0, TO_DATE('2001-
05-14 18:38:2', '-MM-DD HH24:MI:SS'), '987654321', '123456789', '0')
Mon May 14 18:38:03 2001: ERR: do failed for 'INSERT INTO
USUARIOS_EN_LINEA (USU_CODIGO, VISP_CODIGO, USUA_SESION_ID, USUA_IP_NAS,
POOL_NAME, USUA_PORT, USUA_BYTES, USUA_TIEMPO, USUA_HORA_CONEXION,
USUA_CALL_ID, USUA_DNIS, USUA_IP_ASIGNADA) VALUES ('yani', 'pert',
'hola001', '200.59.130.83', 'nombre del pool', 1234, 0, 0, TO_DATE('2001-
05-14 18:38:2', '-MM-DD HH24:MI:SS'), '987654321', '123456789',
'0')': ORA-01722: invalid number (DBD ERROR: OCIStmtExecute)
Mon May 14 18:38:03 2001: ERR: do failed for 'INSERT INTO
USUARIOS_EN_LINEA (USU_CODIGO, VISP_CODIGO, USUA_SESION_ID, USUA_IP_NAS,
POOL_NAME, USUA_PORT, USUA_BYTES, USUA_TIEMPO, USUA_HORA_CONEXION,
USUA_CALL_ID, USUA_DNIS, USUA_IP_ASIGNADA) VALUES ('yani', 'pert',
'hola001', '200.59.130.83', 'nombre del pool', 1234, 0, 0, TO_DATE('2001-
05-14 18:38:2', '-MM-DD HH24:MI:SS'), '987654321', '123456789',
'0')': ORA-01722: invalid number (DBD ERROR: OCIStmtExecute)
Mon May 14 18:38:03 2001: DEBUG: Handling with Radius::AuthSQL
Mon May 14 18:38:03 2001: DEBUG: Handling accounting with Radius::AuthSQL
Mon May 14 18:38:03 2001: DEBUG: Accounting accepted
Mon May 14 18:38:03 2001: DEBUG: Packet dump:
*** Sending to 127.0.0.1 port 41858
Code: Accounting-Response
Identifier: 198
Authentic: Gr16253197+2152219223`eSUK
Attributes:
TIA.
===
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) log files behavior
El 10 May 2001, a las 10:25, Hugh Irvine escribió: Hello Mariano - Is the problem with AuthLog just because you are only logging failures (the default)? Nope... it's logging both (it is so set in the config file that I attached to the other message)... and besides, I'm also radpwtsting with wrong passwords... I get the rejections, but the file still isn't being created (what an awful construction in English... I have to stop using so many passive constructions :-) Mike is still looking at the Log FILE. Great! regards Hugh On Thursday 10 May 2001 04:00, Mariano Absatz wrote: Hi, wrapping up my messages of the last days, I see two (somehow) weird things happening with the logs. 1) As I noted in a message exchange with Hugh (cc: the list) a couple of weeks ago, AuthLog FILE is not working. The file isn't created at all (and Radiator has sufficient permissions since a Log FILE in the same directory IS created. 2) It seems there is a different behavior between the global LogFile and the Log FILE. I usually have Log FILE somehow fixed in the standard production logging level (usually 2 or 3, depending on our customer desires), and the global Trace set to 0. When I want to do some debugging, I change the global trace to 4 and check the global LogFile. However, when an error is produced while Radiator is starting (like, for instance the Oracle error I get when I do a kill -HUP, the global log goes to %L/logfile... (btw LogDir is not /var/log/radius, so it's not the default)... also, LogFile is set just below LogDir, so variable is already setup (since the log goes to $LogDir/logfile and not to /var/log/radius/logfile. === 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. === 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) ORA-03113: end-of-file on communication channel (DBD ERROR: OCIStmtExecute/Describe)
Hi, Daniel seems to be right... it only happens in the beginning, i.e. when you try to access de DB for the first time after Radiator starts... that explains my kill -HUP errors the other day, since I wasn't doing anything at all, the kill -HUP was the frist access to the DB. El 9 May 2001, a las 9:55, [EMAIL PROTECTED] escribió: Hello everybody, I've got the same error for ages. It happens when Radiator is (re)started and tries to query BD for the first-second time. For example: Thu May 3 19:46:50 2001: INFO: Server started: Radiator 2.17.1 on elektra.jazzlab.com Thu May 3 19:47:49 2001: DEBUG: Reclaiming expired leases Thu May 3 19:47:49 2001: DEBUG: do query is: update RADPOOL set STATE=0 where state!=0 and EXPIRY 988912069 Thu May 3 19:47:49 2001: ERR: do failed for 'update RADPOOL set STATE=0 where state!=0 and EXPIRY 988912069': ORA-03113: end-of-file on communication channel (DBD ERROR: OCIStmtExecute) Thu May 3 19:48:49 2001: DEBUG: Reclaiming expired leases Thu May 3 19:48:49 2001: DEBUG: do query is: update RADPOOL set STATE=0 where state!=0 and EXPIRY 988912129 Thu May 3 19:49:49 2001: DEBUG: Reclaiming expired leases Thu May 3 19:49:49 2001: DEBUG: do query is: update RADPOOL set STATE=0 where state!=0 and EXPIRY 988912189 Thu May 3 19:50:11 2001: DEBUG: Packet dump: *** Received from 10.9.10.200 port 49152 Code: Access-Request Identifier: 9 Authentic: 233174H101533%167]5C136236#3 Attributes: User-Name = usuario1isp@clienteisp CHAP-Password = 1241237ow189248KO127G5194mB244200 Acct-Session-Id = 4258 NAS-IP-Address = x.x.x.x Shasta-SGROUP = Shasta 5000: iSOS (tm), 2.1(14) Service-Type = Framed-User Framed-Protocol = PPP Calling-Station-Id = 9 Called-Station-Id = 9 Thu May 3 19:50:11 2001: DEBUG: Rewrote user name to usuario1isp@clienteisp Thu May 3 19:50:11 2001: DEBUG: Handling request with Handler 'Realm=DEFAULT' Thu May 3 19:50:11 2001: DEBUG: SDB1 Deleting session for usuario1isp@clienteisp, x.x.x.x, Thu May 3 19:50:11 2001: DEBUG: do query is: delete from RADONLINE where NASIDENTIFIER='x.x.x.x' and ACCTSESSIONID='4258' Thu May 3 19:50:11 2001: ERR: do failed for 'delete from RADONLINE where NASIDENTIFIER='x.x.x.x' and ACCTSESSIONID='4258'': ORA-03113: end-of-file on communication channel (DBD ERROR: OCIStmtExecute) ...-- My scenario: Radiator 2.17.1 in Linux (2.2.14 or 2.4.1) and Oracle 8.1.6 in Linux 2.4.1(PC) or Solaris 2.6 (Ultra-60). I think it's a problem related with SQL Oracle Libraries but it only happens at the beginning (not after) and it seems not to be serious. Bye, Daniel. === 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. === 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) Handlers
I've never done it, but it should be something like: AuthBy FILE Identifier FileAuthenticator ...(the stuff you need to authenticate from your file) /AuthBy Handler conditionA AuthBy FileAuthenticator /Handler Handler conditionB AuthBy FileAuthenticator /Handler Handler conditionC AuthBy FileAuthenticator /Handler ... Handler conditionX AuthBy FileAuthenticator /Handler El 8 May 2001, a las 10:07, Jared Reimer escribió: Hello.. Forgive my cluelessness; I am new to Radiator and am evaluating it for use in a production environment. I have found it useful to use regular expressions in handlers, and am now wondering: Is it possible to make arbitrarily complex handlers, e.g. handlers that do something like this: Handler (conditionA || conditionB || conditionC || ... || conditionX) ... /Handler I have tried doing this and have not had good luck thus far. The reason I am trying to do this is simple: I currently have two handlers that authenticate against the same massive users file, and am trying to eliminate the inefficiency of caching that file twice at startup. (Is Radiator smart enough to not do that? It doesn't appear so, based on the debug output I get when I fire the daemon up.) Thoughts?? -- Jared === 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) kill -1 radiator / logfile name
Mike,
coming back to a subject from a couple of weeks ago...
El 24 Apr 2001, a las 10:25, Mike McCauley escribió:
Hello Mariano,
Looks like the main problem left is that when you do a kill -1, some of the
loggers stop?
This problem was fixed recently. You need to ge the new Log.pm from the 2.18
patches area.
It wasn't this one... at least not only... it might have to do with the
ClientListSQL statement... the error now is coming from there... I
won't bother with the complete config file but, the relevant section is:
ClientListSQL
# Client (NAS) info is in the database
include %{GlobalVar:ConfigDir}/DBUseData.cfg
GetClientQuery SELECT \
NAS_IDENTIFIER, NAS_SECRET, \
NAS_IGNOREACCTSIGNATURE, NAS_DUPINTERVAL, \
NAS_DEFAULTREALM, NAS_TYPE, NAS_SNMPCOMMUNITY, \
NAS_LIVINGSTONOFFS, NAS_LIVINGSTONHOLE, \
NAS_FRAMEDGROUPBASEADDRESS, NAS_FRAMEDGROUPMAXPORTSPERCLAS, \
NAS_REWRITEUSERNAME, NAS_NOIGNOREDUPLICATES, \
NAS_PREHANDLERHOOK \
FROM NAS_SERVICIO_CALIDAD
/ClientListSQL
now, when I send a kill -HUP, I get the following in the logfile (and in
STDERR, I don't know why, maybe DBD sends it's output there? can that be
changed?)
Tue May 8 16:59:29 2001: NOTICE: SIGHUP received: restarting
Tue May 8 16:59:29 2001: ERR: Execute failed for 'SELECT
NAS_IDENTIFIER,
NAS_SECRET, NAS_IGNOREACCTSIGNATURE, NAS_DUPINTERVAL, NAS_DEFAULTREALM,
NAS_TYPE
, NAS_SNMPCOMMUNITY, NAS_LIVINGSTONOFFS, NAS_LIVINGSTONHOLE,
NAS_FRAMEDGROUPBASE
ADDRESS, NAS_FRAMEDGROUPMAXPORTSPERCLAS, NAS_REWRITEUSERNAME,
NAS_NOIGNOREDUPLIC
ATES, NAS_PREHANDLERHOOK FROM NAS_SERVICIO_CALIDAD': ORA-03113: end-of-
file on c
ommunication channel (DBD ERROR: OCIStmtExecute/Describe)
Tue May 8 16:59:30 2001: INFO: Server started: Radiator 2.18.1 on mr-visp
Tue May 8 16:59:36 2001: NOTICE: SIGTERM received: stopping
Tue May 8 16:59:39 2001: INFO: Server started: Radiator 2.18.1 on mr-visp
...
as you see, stopping and starting doesn't produce any errors...
BTW, if I have a ClientListSQL and I change that table contents, will
Radiator notice that at the following packet? that is, does Radiator do a
select when it starts or for every packet or what? if it is static
(i.e. it only reads it at startup) does a kill -HUP re-reads it? (is the
bug here, by chance? ;-)
===
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) ORA-03113: end-of-file on communication channel (DBD ERROR: OCIStmtExecute/Describe)
Mike, Hugh, I am getting the following error: ORA-03113: end-of-file on communication channel (DBD ERROR: OCIStmtExecute/Describe) and now that I see it, is the same after the kill -HUP I sent you 'bout an hour ago... So maybe the problem isn't with kill -HUP but with Oracle DBD or, most probably, my way of using it. Let's start over again, full scenario: Sun Netra T1 AC200, 1CPU 360MHz, 512Mb RAM, 2x18Gb HD, Solaris 8, Perl v5.6.1, Radiator 2.18.1, Oracle8i Release 8.1.6.0.0 - Production. I run two instances of Radiator, one for authentication and one for accounting. I'm using a bunch of config files: radius-auth.cfg (for authentication only settings) radius-acct.cfg (for accounting only settings) radius-common.cfg (for everything in common, included from both above) DBGlobalData.cfg (data base global data, included from radius-common.cfg) DBUseData.cfg (for including everytime I have to put DBSource/DBUsername/ DBAuth) clients.cfg (the clients section, a ClientListSQL, included from radius-common.cfg) I'm attaching all of the config files to this message. Now, apparently, what's happening is the following: the first oracle thing that ought to be done is to get the ClientListSQL by doing the corresponding SELECT. That is apparently working since the host where the radpwtst is being run and the NAS_Identifier that it provides are accepted (it rejected them before I inserted the records in the tables). Next time an oracle query is executed, it fails with the error: ORA-03113: end-of-file on communication channel (DBD ERROR: OCIStmtExecute/Describe) It's the same error, whether I kill -HUP the server (and the ClientListSQL statement is executed again) or if I try to execute the statement to authenticate a user... After failing the first time, then it works OK, or so it seems... but I don't know what's going on. I'm still not doing SQL accounting so I can't verify the same behavior in the other instance (but the kill -HUP behavior is the same). Here there is a trace 4: Tue May 8 18:30:22 2001: INFO: Server started: Radiator 2.18.1 on dummy- server Tue May 8 18:30:27 2001: DEBUG: Packet dump: *** Received from 127.0.0.1 port 39823 Code: Access-Request Identifier: 12 Authentic: 1234567890123456 Attributes: User-Name = a-user@some-realm Service-Type = Framed-User NAS-IP-Address = 200.59.130.83 NAS-Port = 1234 Called-Station-Id = 123456789 Calling-Station-Id = 987654321 NAS-Port-Type = Async User-Password = Z/237h%251233:238192220`17612\146 Tue May 8 18:30:27 2001: DEBUG: Rewrote user name to a-user@some-realm Tue May 8 18:30:27 2001: DEBUG: Rewrote user name to a-user@some-realm Tue May 8 18:30:27 2001: DEBUG: Check if Handler should be used to handle this request Tue May 8 18:30:27 2001: DEBUG: Handling request with Handler '' Tue May 8 18:30:27 2001: DEBUG: Deleting session for a-user@some-realm, 200.59.130.83, 1234 Tue May 8 18:30:27 2001: DEBUG: Handling with Radius::AuthSQL Tue May 8 18:30:27 2001: DEBUG: Handling with Radius::AuthSQL Tue May 8 18:30:27 2001: DEBUG: Query is: SELECT USU_CLAVE FROM USUARIOS WHERE USU_CODIGO = 'a-user' AND VISP_CODIGO = 'some-realm' Tue May 8 18:30:27 2001: ERR: Execute failed for 'SELECT USU_CLAVE FROM USUARIOS WHERE USU_CODIGO = 'a-user' AND VISP_CODIGO = 'some-realm'': ORA- 03113: end-of-file on communication channel (DBD ERROR: OCIStmtExecute/Describe) Tue May 8 18:30:27 2001: DEBUG: Radius::AuthSQL looks for match with a- user@some-realm Tue May 8 18:30:27 2001: DEBUG: Radius::AuthSQL ACCEPT: Tue May 8 18:30:27 2001: DEBUG: Access accepted for a-user@some-realm Tue May 8 18:30:27 2001: DEBUG: Packet dump: *** Sending to 127.0.0.1 port 39823 Code: Access-Accept Identifier: 12 Authentic: 1234567890123456 Attributes: Tue May 8 18:30:30 2001: DEBUG: Packet dump: *** Received from 127.0.0.1 port 39824 Code: Access-Request Identifier: 15 Authentic: 1234567890123456 Attributes: User-Name = a-user@some-realm Service-Type = Framed-User NAS-IP-Address = 200.59.130.83 NAS-Port = 1234 Called-Station-Id = 123456789 Calling-Station-Id = 987654321 NAS-Port-Type = Async User-Password = Z/237h%251233:238192220`17612\146 Tue May 8 18:30:30 2001: DEBUG: Rewrote user name to a-user@some-realm Tue May 8 18:30:30 2001: DEBUG: Rewrote user name to a-user@some-realm Tue May 8 18:30:30 2001: DEBUG: Check if Handler should be used to handle this request Tue May 8 18:30:30 2001: DEBUG: Handling request with Handler '' Tue May 8 18:30:30 2001: DEBUG: Deleting session for a-user@some-realm, 200.59.130.83, 1234 Tue May 8 18:30:30 2001: DEBUG: Handling with Radius::AuthSQL Tue May 8 18:30:30 2001: DEBUG: Handling with Radius::AuthSQL Tue May 8 18:30:30 2001: DEBUG: Query is: SELECT USU_CLAVE FROM USUARIOS WHERE USU_CODIGO = 'a-user' AND VISP_CODIGO =
Re: (RADIATOR) performance issue
El 3 May 2001, a las 11:07, Hugh Irvine escribió: Hello Mariano - On Thursday 03 May 2001 06:15, Mariano Absatz wrote: Hi... on my delayed reading of the list I found this: El 18 Apr 2001, a las 9:45, Hugh Irvine escribió: Hello Andy - The session database will be accessed by both authentication (to delete and to check limits) and accounting (to insert and delete). SNIP So... I have different instances of Radiator for accounting and authentication, then BOTH have to have the SessionDatabase clause? And should they be identical? Yes. This is the same situation as having multiple machines running Radiator - they all need to share the same session database (if coherency among them is an issue). On re-reading the Performance and Tunning section in the manual (http://www.open.com.au/radiator/ref.html#pgfId=406539), I find a good list of hints, but most of them are sometimes not very usefull when you DO have to do some strange things... anyway, since I saw it many times in the list, the separation between an Authentication server and an Accounting server in different instances even when it is in the same machine, seems to be a no-lose proposition, since you are losing no functionality at all (I think) and you don't have to buy extra hardware (it's easy to say see, boss, I need 4 or 5 more Sun Netras T1 to improve radius speed only to hear him say gee, why don't you do it with that Sparc I that no one is using now?). Since I see this so often said in the list, it might get a subsection with some configuration tips for this, like, you have to put this kind of sections on the auth config, those sections in the acct config and this bunch in both... maybe you should use Include common.cfg for these last ones... Put it in the wishlist for the next release (2.18.2? 2.19? please don't do anything like naming it Radiator 20 -à la Solaris- or Radiator 2001 or Radiator NE (Nonsense Edition) -à la MS- :-) I have been thinking about adding some more complex configuration files to the goodies section and I can see that the manual could contain some more detail. Thanks for the suggestion. On a general way, I would like to be as clean as possible when writing my config files and repeat as little as possible. I am writing 3 config files: 1)radius-auth.cfg 2)radius-acct.cfg 3)radius-common.cfg first thing 1) 2) do is include 3), which has the common configuration. 1) 2) obviously have the corresponding authport acctport, and SNMPAgent in different ports. From a maintainance point of view, I woul like to have as much as possible in 3), from what you say in your message, for instance SessionDatabase must be there. Now, if I put EVERYTHING except authport, acctport and SNMPAgent in 3), will that have a performance penalty? Obviously, it will be slower at startup, but that is not an issue, since, once it's working, I don't expect to shut it down except for programmed upgrades or the like... Otherwise, is there a rule of thumb as to what goes where? I could start putting everything in 3) and then migrating to the obvious choice where there is one and see how I'm doing, but I think that will take a lot of trial and error... For instance AuthLog FILE could go only in 1) (I think), but would it be bad if I put it in 3)? TIA === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) performance issue
El 3 May 2001, a las 11:07, Hugh Irvine escribió: Hello Mariano - On Thursday 03 May 2001 06:15, Mariano Absatz wrote: Hi... on my delayed reading of the list I found this: El 18 Apr 2001, a las 9:45, Hugh Irvine escribió: Hello Andy - The session database will be accessed by both authentication (to delete and to check limits) and accounting (to insert and delete). SNIP So... I have different instances of Radiator for accounting and authentication, then BOTH have to have the SessionDatabase clause? And should they be identical? Yes. This is the same situation as having multiple machines running Radiator - they all need to share the same session database (if coherency among them is an issue). OK... I'll put this in my include file, then... SNIP BTW - I think the next major release of Radiator will be Radiator-3.0, which will include support for the next generation Diameter protocol. http://www.ietf.org/html.charters/aaa-charter.html Good... I've been reading the diameter i-d's... it's kind of a little beast, it would be nice if you could configure Radiator 3.0 (please, don't call it Diameterator :-D ) without the diameter support, since I guess it will add really lots of code and (yet) I don't see a lot of market pressure (here in Argentina, at least) for most of it's features... === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) dictionary request
To find what vendor a vendor number refers to, you have to take a look at: ftp://ftp.isc.org/in-notes/iana/assignmets/enterprise-numbers These are the enterprise numbers assigned by IANA to use as private OID's in SNMP and LDAP/X.500. They are also used as Radius Vendor numbers. In SNMP and LDAP/X.500 you have to prefix them by 1.3.6.1.4.1. (iso.org.dod.internet.private.enterprise). In Radius, they are used by themselves. The table contains 3 columns: Number / Name / References. Name is the common name that identifies the vendor and References has the name and e- mail of the responsible person... I don't think this last info is usually updated, so you can't trust it a lot. The best way to find out about a Vendor attribute is to find the name and then you probably know which of your boxes is generating it... then you have to ask your NAS provider about it... otherwise you can start surfing the provider web pages, support addresses, etc... As allways, the guys of Open Systems ask you to contribute to the list the attributes you find out about so these are added to the next release of the dictionary... For your specifics questions, see below... El 3 May 2001, a las 16:16, Andy De Petter escribió: Hello, Is there someone, who has managed to get a grab on following attribute numbers, as an addition to the existing dictionaries provided with Radiator? I'm looking for the following ones: Vendor 429 (attribute 39051) 429 3Com Carrier Systems Group. Bill Vroman [EMAIL PROTECTED] You probably have a 3Com box, maybe you can find about it in 3Com's site. Vendor 1397446990 (attribute 69) Here you have a clear error of some sort, since, as of yesterday (May 2, 2001), te highest vendor number assigned was 9427... as Hugh says, a Trace 4 will probably help to find out what's going on, if that doesn't do, I guess Mike will ask you for a Trace 5 with the hexadecimal packet dumps in it... I'ld also like to know, whether there is something to do against Attribute number 0 (Vendor 0) errors? Some workaround in the dictionary file, or something? :) Vendor 0 is reserved... there is probably an error here too HTH === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) AuthLog not working
El 28 Apr 2001, a las 11:55, Hugh Irvine escribió:
Hello Mariano -
I have copied this to Mike also, so he can check.
Just one question - is the Log FILE created?
yup.
Ie - are you seeing permission problems on the directory?
This is Log FILE
Filename %L/%Y-%m/%{GlobalVar:rad_instance}/stdLog_%d-%q
and this is AuthLog FILE
Filename %L/%Y-%m/%{GlobalVar:rad_instance}/authLog_%d-%q
If neither one is created, it could be permissions, but if one is created and
not the other, then there may be something in Radiator.
The Log FILE (and the global LogFile if I uncomment it) are created OK,
in fact, the %Y-%m/%{GlobalVar:rad_instance} subdirectory is actually
created by Radiator... all the directories are owned by root (Radiator is
run as root also) and they are mode 755. The logfile itself is also owned
by root and is mode 644... I'm sorry, but it seems to be Radiator...
thanks
Hugh
On Saturday 28 April 2001 07:24, Mariano Absatz wrote:
Hi,
Netra T1 AC200, 1CPU 360MHz, 512Mb RAM, 2x18Gb HD, Solaris 8, Perl
v5.6.1, Radiator 2.18.1 (how easy is to be on the edge version when it's
not yet in production :-)
The AuthLog is not created. Period.
That is, I copied the config from another installation and the file
doesn't appear... there is no other new file under the %L hierarchy,
either.
Radiator is started with rad_instance=test to set the GlobalVar...
I enclose the full config file and a TRACE 4 after issuing radpwtst once
with a wrong password and once with the correct one... there is no
indication of an error while parsing the AuthLog FILE statement.
Any clues?
= /app/Radiator/etc/radius-test.cfg =
= /app/Radiator/etc/radius-test.cfg =
= /app/Radiator/etc/radius-test.cfg =
##
# TEST CONFIGURATION #
##
##
#FILES AND DIRECTORIES SECTION #
##
LogDir /logs/radius
DbDir /app/Radiator/db
DefineGlobalVar ScriptDir /app/Radiator/scripts
DefineGlobalVar ConfigDir /app/Radiator/etc
DefineGlobalVar TempDir /app/Radiator/tmp
DictionaryFile %{GlobalVar:ConfigDir}/dictionary
PidFile %{GlobalVar:TempDir}/rad-%{GlobalVar:rad_instance}.pid
##
# DATABASE DEFINITIONS SECTION #
##
DefineGlobalVar OracleHost localhost
DefineGlobalVar OracleSID radius
DefineGlobalVar MR_DBSource
dbi:Oracle:host=localhost;sid=radius
DefineGlobalVar MR_DBUsername radmin
DefineGlobalVar MR_DBAuth radius
##
#REWRITE SECTION #
##
# REWRITE USER NAME BEFORE ANYTHING ELSE
# Rewrite any Name without realm to our realm
# because defaultrealm does not match on HANDLER
RewriteUsername s/^([^@]+)$/$1\@metrored/
# change everything in the username to lowercase
RewriteUsername tr/[A-Z]/[a-z]/
##
#LOGGING SECTION #
##
# For debugging, uncomment the 2 following lines
Trace 4
LogFile %L/%Y-%m/%{GlobalVar:rad_instance}/debugLog_%d-%q
#Trace:
#0 ERR. Error conditions. Serious and unexpected failures
#1 WARNING. Warning conditions. Unexpected failures
#2 NOTICE. Normal but significant conditions.
#3 INFO. Informational messages.
#4 DEBUG. Debugging messages.
#5 Incoming raw packet dumps in hexadecimal.
Log FILE
Identifier fileLoggerMetroTest
Filename %L/%Y-%m/%{GlobalVar:rad_instance}/stdLog_%d-%q
Trace 3
/Log
#Log authentication success and failure to a file
AuthLog FILE
Identifier testLoggerMetroRED
Filename %L/%Y-%m/%{GlobalVar:rad_instance}/authLog_%d-%q
LogSuccess 1
LogFailure 1
SuccessFormat %l:%n::OK
FailureFormat %l:%n:%P:FAIL
/AuthLog
##
# PROTOCOL SECTION #
##
AuthPort1812
AcctPort1813
SNMPAgent
Port16111
Re: (RADIATOR) performance issue
Hi... on my delayed reading of the list I found this: El 18 Apr 2001, a las 9:45, Hugh Irvine escribió: Hello Andy - The session database will be accessed by both authentication (to delete and to check limits) and accounting (to insert and delete). SNIP So... I have different instances of Radiator for accounting and authentication, then BOTH have to have the SessionDatabase clause? And should they be identical? On re-reading the Performance and Tunning section in the manual (http://www.open.com.au/radiator/ref.html#pgfId=406539), I find a good list of hints, but most of them are sometimes not very usefull when you DO have to do some strange things... anyway, since I saw it many times in the list, the separation between an Authentication server and an Accounting server in different instances even when it is in the same machine, seems to be a no-lose proposition, since you are losing no functionality at all (I think) and you don't have to buy extra hardware (it's easy to say see, boss, I need 4 or 5 more Sun Netras T1 to improve radius speed only to hear him say gee, why don't you do it with that Sparc I that no one is using now?). Since I see this so often said in the list, it might get a subsection with some configuration tips for this, like, you have to put this kind of sections on the auth config, those sections in the acct config and this bunch in both... maybe you should use Include common.cfg for these last ones... Put it in the wishlist for the next release (2.18.2? 2.19? please don't do anything like naming it Radiator 20 -à la Solaris- or Radiator 2001 or Radiator NE (Nonsense Edition) -à la MS- :-) === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) AuthLog not working
Hi,
Netra T1 AC200, 1CPU 360MHz, 512Mb RAM, 2x18Gb HD, Solaris 8, Perl
v5.6.1, Radiator 2.18.1 (how easy is to be on the edge version when it's
not yet in production :-)
The AuthLog is not created. Period.
That is, I copied the config from another installation and the file
doesn't appear... there is no other new file under the %L hierarchy,
either.
Radiator is started with rad_instance=test to set the GlobalVar...
I enclose the full config file and a TRACE 4 after issuing radpwtst once
with a wrong password and once with the correct one... there is no
indication of an error while parsing the AuthLog FILE statement.
Any clues?
= /app/Radiator/etc/radius-test.cfg =
= /app/Radiator/etc/radius-test.cfg =
= /app/Radiator/etc/radius-test.cfg =
##
# TEST CONFIGURATION #
##
##
#FILES AND DIRECTORIES SECTION #
##
LogDir /logs/radius
DbDir /app/Radiator/db
DefineGlobalVar ScriptDir /app/Radiator/scripts
DefineGlobalVar ConfigDir /app/Radiator/etc
DefineGlobalVar TempDir /app/Radiator/tmp
DictionaryFile %{GlobalVar:ConfigDir}/dictionary
PidFile %{GlobalVar:TempDir}/rad-%{GlobalVar:rad_instance}.pid
##
# DATABASE DEFINITIONS SECTION #
##
DefineGlobalVar OracleHost localhost
DefineGlobalVar OracleSID radius
DefineGlobalVar MR_DBSource
dbi:Oracle:host=localhost;sid=radius
DefineGlobalVar MR_DBUsername radmin
DefineGlobalVar MR_DBAuth radius
##
#REWRITE SECTION #
##
# REWRITE USER NAME BEFORE ANYTHING ELSE
# Rewrite any Name without realm to our realm
# because defaultrealm does not match on HANDLER
RewriteUsername s/^([^@]+)$/$1\@metrored/
# change everything in the username to lowercase
RewriteUsername tr/[A-Z]/[a-z]/
##
#LOGGING SECTION #
##
# For debugging, uncomment the 2 following lines
Trace 4
LogFile %L/%Y-%m/%{GlobalVar:rad_instance}/debugLog_%d-%q
#Trace:
#0 ERR. Error conditions. Serious and unexpected failures
#1 WARNING. Warning conditions. Unexpected failures
#2 NOTICE. Normal but significant conditions.
#3 INFO. Informational messages.
#4 DEBUG. Debugging messages.
#5 Incoming raw packet dumps in hexadecimal.
Log FILE
Identifier fileLoggerMetroTest
Filename %L/%Y-%m/%{GlobalVar:rad_instance}/stdLog_%d-%q
Trace 3
/Log
#Log authentication success and failure to a file
AuthLog FILE
Identifier testLoggerMetroRED
Filename %L/%Y-%m/%{GlobalVar:rad_instance}/authLog_%d-%q
LogSuccess 1
LogFailure 1
SuccessFormat %l:%n::OK
FailureFormat %l:%n:%P:FAIL
/AuthLog
##
# PROTOCOL SECTION #
##
AuthPort1812
AcctPort1813
SNMPAgent
Port16111
ROCommunity CONFIGURAR-COMUNIDAD
/SNMPAgent
#
#CLIENTS SECTION #
##
# Test CPM
Client 1.2.3.4
Identifier testClient
Secret XX
IdenticalClientslocalhost
/Client
##
# AUTHENTICATION SECTION #
##
Realm DEFAULT
AuthBy FILE
Identifier testFileAuth
Filename%D/testusers
# para poder editar el archivo y no recargar el radius
# OJO que la busqueda es LINEAL!!!
Nocache
/AuthBy
/Realm
=== TRACE 4 ===
=== TRACE 4 ===
=== TRACE 4 ===
Fri Apr 27 17:39:24
Re: (RADIATOR) Radiator 2.18.1 Released
El 26 Apr 2001, a las 18:14, Mike McCauley escribió: We are pleased to announce the release of Radiator version 2.18.1 Version provides a number of bug fixes and some new features. Hi... it run ok in our test installation... the reload problems are aparently gone away (as Mike said, it must have been the logger bug). Found a typo in the manual (there might be more, I just happened to be reading this precise section): 6.40 AuthBy DYNADDRESS AuthBy DYNADDRESS can be used to dynamically allocate IP addresses for dilaup users, in conjunction with AddressAllocator xxx clauses. It is implemented in AuthDYNADDRESS.pm. At present, only one Address There are two address allocators now... :-) Allocation engine is provided. AddressAllocator SQL (See Section ) It's missing the Section number and the link is wrong (it points to #34248 which goes to a couple of lines below the start of Section 6.45- AuthLog SQL, and it should point to #412546) can allocate addresses out of an SQL database. Other address allocation engines will be available for Radiator soon. or are, in fact, available now :-D === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) accounting flat file to CSV ?
Hi Neale, It's an awful thing to do since the CSV "column names" are "embedded" in the original file and fields are non positional, and some records have more fields than others... I'm answering (late, since I haven't read the list for quite a few days), cause I made a perl script some time ago to handle something quite similar. I had to convert an LDIFF (LDAP Interchange File Format) file (with all objects of the same objectclass) to a table with the attribute names as column headings. I made a "quick and VERY dirty" perl script to handle it. It does a couple of very nasty things but gets the job done. It will need modifications to handle the radius accounting format... It doesn't handle the timestamp line, I don't think it handles whitespace before the attribute name and (this is the worst part) it builds the table in memory as an array of hashes... I had only 10,000 records so it wasn't a problem, but radius accounting logs can get really large... I did it this way to be able to construct the heading line on top, since I couldn't know all of the attribute names until I process all of the records... however it shouldn't be very hard to modify it to generate the records to a file on the fly while generating the column headings array, close that file, write that array to another file and append the first file to the second one. If you are interested, I can send you the script... with ABSOLUTELY NO GUARANTEES (other than it worked once for LDIF :-)... El 9 Apr 2001, a las 19:39, Hugh Irvine escribi: Hello Neale - Have you had a look in the goodies directory to see if there is anything there? Otherwise I am sure someone on the list has done this at lease once. regards Hugh At 13:45 +1000 01/4/9, Neale Banks wrote: G'day Hugh, On Fri, 6 Apr 2001, Hugh Irvine wrote: Hello Neale - On Thursday 05 April 2001 10:15, Neale Banks wrote: Greetings all, Not exclusively Radiator-relevant, but probably RADIUS+Perl relevant... Does anyone have any pointer to anything to convert flat-file accounting records to comma-separated format? You can use the AcctLogFileName and AcctLogFileFormat to specify any format you wish. Sections 6.15.4 and 6.15.5 in the Radiator 2.18 reference manual. Alternatively, any other solutions to the need to tabulate a user's STOP records to run some elementary stats over their sessions times and disconnect reasons? It would probably be simpler to write the data to an SQL database directly and use an SQL report externally. Whilst these would both be good solutions for new records, unfortunately my current "challenge" is to extract some statistics from historical data which is in traditional flat-file accounting records. I'd be grateful of any suggestions anyone has regarding this. Thanks, Neale. -- 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.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) kill -1 radiator / logfile name
El 17 Apr 2001, a las 19:45, Mariano Absatz escribi:
Hi all,
I had this problem a couple of times but not sistematically... I'm
starting a new installation and trying startup scripts (in fact before
preparing the config files) and now it is sistematic.
Every time I kill -1 Radiator, to re-read the configuration file, it
fails...
What I remember from my other installation was that if I made a minor
change to the config file (e.g. the trace level), it worked OK, but if I
edited something bigger, sometimes, it didn't liked it and it died... I
thought it had to do with the way Radiator generates perl code on the fly
while reading the config files.
Now I made a couple of almost empty config files and every time I kill -1
radiator it yields the following error:
Can't locate object method "new" via package "Radius::SNMPAgent"
(perhaps you forgot to load "Radius::SNMPAgent"?) at
/usr/local/lib/perl5/site_perl/5.6.1/Radius/ServerConfig.pm line 133,
FILE line 17.
Alright, alright... so I SHOULD have RTFM... I had not installed the
SNMP_Session package and that generated this particular error... anyway,
read below...
As I keep cheking it... it's not generating the correct filenames for the
logfiles.
There is only one logfile generated in /logs/radius and its name is
"logfile"... that is, it kinda processed the LogDir statement, but it
didn't process the LogFile nor the Log File...
It seems that sometimes, somehow, it starts generating messages before
processing LogFile and Log FILE, but AFTER processing LogDir... it's
alright, I prefer to have the logs someplace else rather than not having
them at all...
I'm including the contens of the /app/Radiator/etc/radius-acct.cfg (which
is invoked from the command line) and the contents of
/app/Radiator/etc/radius-common.cfg (which is included from the former).
I'll change them now... keep reading :-)
For completeness... I also include the startup/shutdown/reload script
(/etc/init.d/radius-acct). It's running on a Netra T1 AC200, 1CPU 360MHz,
512Mb RAM, 2x18Gb HD, Solaris 8, Perl v5.6.1, Radiator 2.18 with all the
patches up to 10-Apr-2001.
So, I installed SNMP_Session, cleaned up things a bit, but still, when I
kill -1, I get strange results...
I started one instance of Radiator (accounting only) and I can stop it
and start it again with no problem, however, if I kill -1 it I get the
following message on screen (and on the logfile too)... anyway, now it
keeps running...
# /etc/init.d/radius-acct reload
Reloading Radiator (acct) configuration:
DBD::Oracle::db prepare failed: ORA-03113: end-of-file on communication
channel (DBD ERROR: OCIStmtExecute/Describe) {SELECT
NAS_IDENTIFIER, NAS_SECRET, NAS_IGNOREACCTSIGNATURE, NAS_DUPINTERVAL,
NAS_DEFAULTREALM, NAS_TYPE, NAS_SNMPCOMMUNITY, NAS_LIVINGSTONOFFS,
NAS_LIVINGSTONHOLE, NAS_FRAMEDGROUPBASEADDRESS,
NAS_FRAMEDGROUPMAXPORTSPERCLAS, NAS_REWRITEUSERNAME,
NAS_NOIGNOREDUPLICATES, NAS_PREHANDLERHOOK FROM NAS_SERVICIO_CALIDAD}
at /usr/local/lib/perl5/site_perl/5.6.1/Radius/SqlDb.pm line 201,
FILE line 22.
-done
Stranger, still, is that the message appears on the Log FILE and on the
%L/logfile (default name), but NOT in the LogFile...
I use Log FILE for standard logging (trace level 2 or 3) and have a
commented global LogFile with Trace 4 for debugging, however, this file
only gets the "Radiator starting / Radiator stopping" (I'm not receiving
packets, just testing start/stop/reload).
Anyway, I put the trace level 4 in the Log FILE clause and got this
result: (keep reading after the trace 4)
==
Wed Apr 18 17:47:09 2001: NOTICE: SIGTERM received: stopping
Wed Apr 18 17:47:15 2001: DEBUG: Adding Clients from SQL database
Wed Apr 18 17:47:15 2001: DEBUG: Query is: SELECT NAS_IDENTIFIER,
NAS_SECRET, NAS_IGNOREACCTSIGNATURE, NAS_DUPINTERVAL, NAS_DEFAULTREALM,
NAS_TYPE, NAS_SNMPCOMMUNITY, NAS_LIVINGSTONOFFS, NAS_LIVINGSTONHOLE,
NAS_FRAMEDGROUPBASEADDRESS, NAS_FRAMEDGROUPMAXPORTSPERCLAS,
NAS_REWRITEUSERNAME, NAS_NOIGNOREDUPLICATES, NAS_PREHANDLERHOOK FROM
NAS_SERVICIO_CALIDAD
Wed Apr 18 17:47:16 2001: INFO: Server started: Radiator 2.18 on mr-radius
Wed Apr 18 17:47:23 2001: NOTICE: SIGHUP received: restarting
Wed Apr 18 17:47:23 2001: DEBUG: Adding Clients from SQL database
Wed Apr 18 17:47:23 2001: DEBUG: Query is: SELECT NAS_IDENTIFIER,
NAS_SECRET, NAS_IGNOREACCTSIGNATURE, NAS_DUPINTERVAL, NAS_DEFAULTREALM,
NAS_TYPE, NAS_SNMPCOMMUNITY, NAS_LIVINGSTONOFFS, NAS_LIVINGSTONHOLE,
NAS_FRAMEDGROUPBASEADDRESS, NAS_FRAMEDGROUPMAXPORTSPERCLAS,
NAS_REWRITEUSERNAME, NAS_NOIGNOREDUPLICATES, NAS_PREHANDLERHOOK FROM
NAS_SERVICIO_CALIDAD
Wed Apr 18 17:47:23 2001: ERR: Execute failed for 'SELECT
NAS_IDENTIFIER, NAS_SECRET, NAS_IGNOREACCTSIGNATURE, NAS_DUPINTERVAL,
NAS_DEFAULTREAL
(RADIATOR) kill -1 radiator / logfile name
Hi all,
I had this problem a couple of times but not sistematically... I'm
starting a new installation and trying startup scripts (in fact before
preparing the config files) and now it is sistematic.
Every time I kill -1 Radiator, to re-read the configuration file, it
fails...
What I remember from my other installation was that if I made a minor
change to the config file (e.g. the trace level), it worked OK, but if I
edited something bigger, sometimes, it didn't liked it and it died... I
thought it had to do with the way Radiator generates perl code on the fly
while reading the config files.
Now I made a couple of almost empty config files and every time I kill -1
radiator it yields the following error:
Can't locate object method new via package Radius::SNMPAgent
(perhaps you forgot to load Radius::SNMPAgent?) at
/usr/local/lib/perl5/site_perl/5.6.1/Radius/ServerConfig.pm line 133,
FILE line 17.
As I keep cheking it... it's not generating the correct filenames for the
logfiles.
There is only one logfile generated in /logs/radius and its name is
logfile... that is, it kinda processed the LogDir statement, but it
didn't process the LogFile nor the Log File...
I'm including the contens of the /app/Radiator/etc/radius-acct.cfg (which
is invoked from the command line) and the contents of
/app/Radiator/etc/radius-common.cfg (which is included from the former).
For completeness... I also include the startup/shutdown/reload script
(/etc/init.d/radius-acct). It's running on a Netra T1 AC200, 1CPU 360MHz,
512Mb RAM, 2x18Gb HD, Solaris 8, Perl v5.6.1, Radiator 2.18 with all the
patches up to 10-Apr-2001.
What is wrong?
= /app/Radiator/etc/radius-acct.cfg =
= /app/Radiator/etc/radius-acct.cfg =
= /app/Radiator/etc/radius-acct.cfg =
##
#ACCOUNTING CONFIGURATION#
##
#
# include common configuration and global definitions
include /app/Radiator/etc/radius-common.cfg
PidFile %{GlobalVar:TempDir}/rad-acct.pid
#
# We only do accounting in this instance of Radiator
#
AuthPort
AcctPort1813
SNMPAgent
Port16113
Community CONFIGURAR-COMUNIDAD
/SNMPAgent
##
#LOGGING SECTION #
##
# For debugging, uncomment the 2 following lines
Trace 4
LogFile %L/%Y-%m/debugAcctLog_%d-%q
#Trace:
#0 ERR. Error conditions. Serious and unexpected failures
#1 WARNING. Warning conditions. Unexpected failures
#2 NOTICE. Normal but significant conditions.
#3 INFO. Informational messages.
#4 DEBUG. Debugging messages.
#5 Incoming raw packet dumps in hexadecimal.
Log FILE
Identifier fileLoggerMetroAcct
Filename %L/%Y-%m/stdAcctLog_%d-%q
Trace 3
/Log
#
#Log authentication success and failure to a file
#AuthLog FILE
# Identifier acctLoggerMetroRED
# Filename %L/%Y-%m/acct_%d-%q
# LogSuccess 1
# LogFailure 1
# SuccessFormat %l:%n::OK:-
# FailureFormat %l:%n:%P:FAIL:%1
#/AuthLog
= /app/Radiator/etc/radius-common.cfg
= /app/Radiator/etc/radius-common.cfg
= /app/Radiator/etc/radius-common.cfg
##
# COMMON CONFIGURATION #
##
##
#FILES AND DIRECTORIES SECTION #
##
LogDir /logs/radius
DbDir /app/Radiator/db
DefineGlobalVar ScriptDir /app/Radiator/scripts
DefineGlobalVar ConfigDir /app/Radiator/etc
DefineGlobalVar TempDir /app/Radiator/tmp
DictionaryFile %{GlobalVar:ConfigDir}/dictionary
##
#REWRITE SECTION #
##
# REWRITE USER NAME BEFORE ANYTHING ELSE
# Rewrite any Name without realm to our realm
# because defaultrealm does not match on HANDLER
RewriteUsername s/^([^@]+)$/$1\@metrored/
# change everything in the username to lowercase
RewriteUsername tr/[A-Z]/[a-z]/
##
#CLIENTS SECTION #
##
#ClientListSQL
# Client (NAS) info is
Re: (RADIATOR) Multiple values with NAS-Port-Type
El 13 Mar 2001, a las 10:02, Hugh Irvine escribi: Hello Julio - On Monday 12 March 2001 23:47, [EMAIL PROTECTED] wrote: hi all, in our scenario, Radiator do Auth by LDAP. So we are provisioning to the LDAP the type of connections allowed per user. For example: user@domain typeofconnection: Async typeofconnection: Sync typeofconnection: ISDN-Async typeofconnection: ISDN-Sync In this way, the LDAP attribute "typeofconnection" contains all the types of connection allowed, and this attribute is multi-valued. In our config file (Radiator) we do an AuthLDAP2 and we check NAS-Port-Type and "typeofconnection". The problem appears because 'checking' seems to get only the first value of the multi-value-attribute "Async Sync ISDN-Async ..." and in this example, only Async connections will be allowed. Does exist any way to check NAS-Port-Type and a LDAP multi-value attribute in a blank-separated-basis-values ? No, there isn't anything like that currently, so the only thing I can suggest is a PreAuthHook or a custom AuthBy clause to do the required processing. I have also been trying to think of a way to do this in a generalised fashion, but I can't think of a solution. If anyone has any ideas I would be happy to hear them. Interesting thing... I might need it in the future... As Ingvar Berg noted in a recent message, there might be performance penalties when searching non-indexed attributes... OTOH, you can index also this particular attribute, just for performance sake (at least OpenLDAP lets me do it). But, as a "generalised" solution proposal: what about an extension to the AuthAttrDef syntax adding a "check- multiple" type?... the corresponding line in Julio's radius.cfg would be: AuthAttrDef typeofconnection,NAS-Port-Type,check-multiple I didn't read the source code, so I don't know if this is simple, complicated or definitively ridiculous, but it looks to me as a "general" approach to the problem. Just my 2c. regards Hugh -- Mariano Absatz El Baby === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Oracle on Sun or Linux?
We are running a smaller setup, about 10,000 subscriber in only one POP for 99% on-line wireless connections (not dial-up), meaning, mostly long connections (but when the NAS falls for some reason and comes back alive again, we have hundreds of requests all at once). We are using radiator on a netra t1, openldap 2.0.7 in another netra t1 for most authentications (there is also ipass, but it's very seldom used), and mysql for accounting on yet another netra t1 (the session database is on the same radiator host, also with mysql). The accounting database is not actually used for accounting (for now, they are selling flat fee connections), but only for debugging and incident tracking, and quering it sometimes bogged down the server. Radiator has been running for 4 months wihtout a hitch. It NEVER went down, we upgraded from 2.16.3 to 2.17.1 and changed the configurations several times (from enabling/disabling a trace 4 to changing the logic of the config file), and it NEVER failed. We do all the testing before going live on an intel box with RedHat 6.2 on it and that never went down, either, anyway, that box never had real load. Just my 2cents... El 7 Mar 2001, a las 17:09, Sudjiwo Husodo escribi: Hi all !! We are moving our Radiator on mysql/linux to Oracle due to our billing systems that is developed on Oracle. We are debating whether to use Oracle/Linux or Oracle/Sun. Can anybody comment as to which platform is better for Radiator? We currently have 27 pops (35,000 subscribers) and considering to have a copy of the local pops subscribers on each pop using Oracle replication (and of course a local pop radiator). The needs is due to bw savings more than infrastructure stability in Indonesia. Currently with mysql/linux a centralized radiator works just fine. Can anybody comment on this approach? Regards, Sudjiwo === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Off-base wish... ;-)
Hi, I know this is not your average user request but... We are configuring the scenario described in the attached message that I sent to the list about a month ago... I am implementing most of Hugh's suggestions to that message. I have an LDAP structure like this: o=our organization | +--ou=radiusWholesale | | | +--o=customer1 (customer1 data, including radius servers and secrets) | | | | | +--uid=profile1 (customer1, profile1 data, including port limits) | | | | | +--uid=profile2 (customer1, profile2 data, including port limits) | | | +--o=customer2 (customer2 data, including radius servers and secrets) | | | | | +--uid=profile1 (customer2, profile1 data, including port limits) | | | | | +--uid=profile2 (customer2, profile2 data, including port limits) | | | | | +--uid=profile3 (customer2, profile3 data, including port limits) | | ... ... | +--o=customerN (customerN data, including radius servers and secrets) | | | +--uid=profile1 (customerN, profile1 data, including port limits) | | | +--uid=profile2 (customerN, profile2 data, including port limits) | +--ou=otherStuffNonRelatedToThis... | ... For now on, I have a few "radius wholesale" customers, so I am configuring the handlers by hand. I decide who is the wholesale customer based on the realm of the request. This realm is part of the CustomerX data entry in the LDAP tree. It would be nice to be able to define the Handler's dinamically from the LDAP tree, so, adding a new customer is as simple as adding the corresponding subtree to the LDAP including the realm... I wouldn't care reloading Radiator in order to do this ;-), but it would be great not having to [copy, paste, edit] an old Handler and then reloading. What about something like this maybe for Radiator 3.0? (or 9.3?) :-) -- Mariano Absatz El Baby Hello, I want to do the following: We have our own customers authenticating through LDAP (AuthBy LDAP2) and we keep accounting and the on line users in a MySQL database. Now we want to sale access through our NAS to other ISP's (we sell on line wireless access, through a shasta tunneling box). The idea is as follows: we wholesale to the other ISP a bunch of simultaneous connections with different characteristics, for instance: 50 64kbps connections 30 128kbps connections 10 256kbps connections 10 512kbps connections 5 1mbps connections We don't care about the other ISP users and passwords or which kind of connection they give to each user as long as this ISP's users don't exceed the maximum simultaneous connections of each kind. The idea is that the kind of connection be not preconfigured on the user's name or realm, but that the other ISP radius server be able to send it to us in an attribute, so they are able to dynamically assign the connections. That is, if they bought the example above, but have 60 customers for the 64kb connections, they are able to evaluate when the 51st. user is trying to log in and if there is another kind of connection available, they assign that. When we receive the Access-Accept from their radius server we should check this attribute and recodify it into a suitable attribute to send to the shasta (Shasta-Service-Profile), according to a set of rules. The quantities of connections for each customer ISP (we expect to have more than one) should be changeable on line (I would rather use LDAP than SQL, since all our provisioning works with LDAP). Now for the questions: 1) How should I combine AuthBy Radius with AuthBy PORTLIMITCHECK so I can do the port limit check AFTER I get the Radius Access-Accept. 2) Can I check the limits against something found in an LDAP entry? How? Otherwise, is there other solution? (probably through SQL) 3) We would like to add the accounting packets to our accounting AND ALSO send them to the other ISP. Is it possible, how do we do it? 4) What would be the "correct" attribute to pass info from the other ISP to us saying "accept and use this specific kind of connection"? I've been browsing through the RFC's and Configuration-Token (78) (RFC2869, page 31) seems to be the right choice... am I right? (BTW, it could be added to the next release of the dictionary ;-) TIA. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) more on this world...
Now, this I have to do it now (can't wait for Radiator 9.3 :-). As I mentioned in my last cited message, I intend to forward (proxy) a request to another radius and this one will tell me which profile it wants in a Configuration-Token attribute. As I am limiting simultaneous use per profile, I can't do this until I have this info (this is no problem). The point is that, obviously, the record in the SessionDatabase MUST have the profile info. I insert this record when I receive the Acct-Start packet, but this packet DOESN'T have info about the profile (and the NAS can't send it). So, what do I do? The only idea I have is to use the Acct-Session-ID that is present in all the packets (Access-Request, Start Stop), but it seems I would need to use an auxiliary table where I insert a record with (Session-ID,profile) when I get back the Configuration-Token (in an Access-Accept from the final radius), and then, when I get the Start, I should check the Session-ID against this auxiliary table, get the apropriate profile, insert the record in the SessionDatabase and delete the record from the aux.table. This I don't like, 'cause it implies lots of inserts/queries/deletes in this aux.table and eventually, I should do some garbage collection 'cause there could be stale records there... probably, any record in the aux.table older than 5 minutes should be discarded? when/how do I do this? Do you have another idea? === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Proxy-State
Hi, I'm checking the Proxy-State attribute and RFC2865 says it's a string, however, the latest dictionary (with yesterday's date) says "binary"... what's the difference between "binary" and "string" in the dictionary? Is there a reference of the dictionary file format? TIA -- Mariano Absatz El Baby === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Log FILE Identifier clause
El 28 Feb 2001, a las 12:31, Hugh Irvine escribi: Hello Mariano - What version of Radiator are you running? I get the same error in Radiator 2.17.1. It is, indeed, 2.17.1. However, I have also tested this with Radiator 2.18 (alpha) and the problem has been fixed, so I would suggest you upgrade when 2.18 is released. Eagerly waiting for it... you also told me it would be able to handle the reason for rejections in the AuthLog, so I keep waiting. Anyway, this is just a minor nuissance, since I'm not using this Identifier right now and am only trying to be tidy just in case I need to use it in the future. regards Hugh On Wednesday 28 February 2001 05:38, Mariano Absatz wrote: Is it a bug? or is it a feature? :-D Some time ago, I let the "LogFile" statement from my radius.cfg commented out (along with Trace 4) pointing to a filename of "debug" and added a Log FILE clause pinting to another filename with trace 3, so I can enable and disable debugging without affecting (especially in size) my standard logging. I tried it and didn't notice anything strange, but now that I enabled debugging 'cause there was a problem (unrelated to radiator) I noticed this line whenever I restart radiator in a trace 4: Tue Feb 27 15:16:46 2001: ERR: Unknown keyword 'Identifier' in /app/Radiator/etc/radius.cfg line 29 I check the file and it's the Identifier inside the Log FILE that, according to section 6.10.3, should be allowed. snip === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Log FILE Identifier clause
Is it a bug? or is it a feature?
:-D
Some time ago, I let the "LogFile" statement from my radius.cfg commented
out (along with Trace 4) pointing to a filename of "debug" and added a
Log FILE clause pinting to another filename with trace 3, so I can
enable and disable debugging without affecting (especially in size) my
standard logging.
I tried it and didn't notice anything strange, but now that I enabled
debugging 'cause there was a problem (unrelated to radiator) I noticed
this line whenever I restart radiator in a trace 4:
Tue Feb 27 15:16:46 2001: ERR: Unknown keyword 'Identifier' in
/app/Radiator/etc/radius.cfg line 29
I check the file and it's the Identifier inside the Log FILE that,
according to section 6.10.3, should be allowed.
I attach the top of my radius.cfg
LogDir /D/logs/radius
DbDir /app/Radiator/db
DictionaryFile /app/Radiator/etc/dictionary
AuthPort 1812
AcctPort 1813
SNMPAgent
Port 50161
Community velo-com-isp
/SNMPAgent
##
#LOGGING SECTION #
##
# Para debugging, descomentar las dos lineas siguientes
Trace 4
LogFile %L/%Y-%m/debuglog_%d-%q
#Trace:
#0 ERR. Error conditions. Serious and unexpected failures
#1 WARNING. Warning conditions. Unexpected failures
#2 NOTICE. Normal but significant conditions.
#3 INFO. Informational messages.
#4 DEBUG. Debugging messages.
#5 Incoming raw packet dumps in hexadecimal.
Log FILE
Identifier fileLoggerVelocom# THIS IS LINE 29
Filename %L/%Y-%m/logfile_%d-%q
Trace 3
/Log
# Log authentication success and failure to a file
AuthLog FILE
Identifier authLoggerVelocom
Filename %L/%Y-%m/auth_%d-%q
LogSuccess 1
LogFailure 1
SuccessFormat %l:%n::OK
FailureFormat %l:%n:%P:FAIL
# FailureFormat %l:%n:%P:FAIL:(%{Reason})
/AuthLog
#SNIP
====
Any ideas?
--
Mariano Absatz
El Baby
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Acct-Interim-Update for keeping SessionDatabase current
Hello Hugh El 21 Feb 2001, a las 11:28, Hugh Irvine escribi: Hello Mariano - I think you are getting much too complicated. My suggestion is to create a Handler to catch the "Alive" packets from the NAS and either use an AuthBy SQL clause with AcctSQLStatements to do what you require in the the session database, or to write a hook that does the same thing. OK, I'll try with the AuthBy SQL... BTW - I don't think there is any way to send instructions to the NAS from Radiator to turn on the Alives. This will have to be configured directly in the NAS. There is, excerpt from RFC2869: 2.1. RADIUS support for Interim Accounting Updates When a user is authenticated, a RADIUS server issues an Access-Accept in response to a successful Access-Request. If the server wishes to receive interim accounting messages for the given user it must include the Acct-Interim-Interval RADIUS attribute in the message, which indicates the interval in seconds between interim messages. It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept. (...) Notably, the Shasta works as the first paragraph says... I could even use a different interval for every user (taking this from an LDAP reply item)... regards Hugh snip === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Acct-Interim-Update for keeping SessionDatabase current
Hi Hugh, Mike,
I didn't find anything specially fitting in goodies/hooks.txt, but I
kinda saw a way to do it.
I also browsed through the source and found that SessGeneric.pm has an
"update" function for "alive" (a.k.a. Interim-Update) packets.
Is there a "clean" way to generate an "UpdateQuery" and mayba also an
"ExceededQuery"?... in particular, I don't see this handled in SessSQL.pm
I would also need to change the "exceeded" function in SessSQL.pm. On the
other hand, I can (maybe this is "cleaner") add a new "InterimUpdate"
NasType and create an isOnlineInterimUpdate function in Nas.pm.
Is there a way to have an attribute "attached" to a Client clause? That
is, I need a way to specify the Interim-Update, first to send it to the
NAS so it starts sending Alive packets at the interval I want and then
for checking that the timestamp in the SessionDatabase is not to old. As
for what I read, I can set a global variable and use it everywhere, but
it would be cleaner if I can bind it to the client (where I think it
belongs, at least as much as the NasType).
The idea is that the UpdateQuery updates the Timestamp column and that
the ExceededQuery tests the current timestamp against the SessionDatabase
timestamp... say,
if (current_timestamp - sessDB_timestamp Interim-Update * 1.1) {
"I declare this entry of the SessionDatabase is stale and erase it";
}
If I add the "InterimUpdate" NasType, I would have to check for this
difference in isOnlineInterimUpdate (in Nas.pm), so I would need to have
this Interim-Update attached somewhere... there is allways the quick an
dirty GlobaVariable, but if there is a clean way, it might find it's way
into Radiator 2.19 or 2.20 maybe ;-) (I hate to diff original/modified
files and triple-checking before upgrading) :-(
Am I completely off-base?
El 15 Feb 2001, a las 12:59, Hugh Irvine escribi:
Hello Mariano -
I think you will need to use a hook in addition to your normal
session database. There are some example hooks in the file
"goodies/hooks.txt" in the Radiator 2.17.1 distribution.
regards
Hugh
At 16:48 -0300 01/2/14, Mariano Absatz wrote:
Hi people,
We are having trouble with stale records in our SessionDatabase.
The NAS is a Nortel Shasta that doesn't seem to have a reasonable means
of being queried about a particular Acct-Session-Id or Username/Framed-IP-
Address.
We started using Ping, but it seems to be giving addresses on a FIFO
basis, so they are almost immediatly re-used making this method useless.
The people at Nortel say that they can configure it so it sends Acct-
Interim-Update packets every N minutes.
What we could do is to catch every Acct-Interim-Update packet and make an
update on the SessionDatabase record's Timestamp.
Now, if we have a user trying to authenticate and according to our
SessionDatabase it would exceed it's Simultaneous-Use value, we could
check every record for this user and if the Timestamp is older than N
minutes + 10% (or something like that), we consider it invalid and allow
the user in again.
How would I do this?
That is, as there is an AddQuery for an Acct-Start and a DeleteQuery for
an Acct-Stop, I would need to use a kind of "UpdateQuery" for an Acct-
Interim-Update. How can I do this?
Where should I handle the Simultaneous-Use check? That is, now I simply
set a NasType in the Shasta's Client entry. How can I use an arbitrary
perl function for this?
Thanx.
--
Baby
--
PS: If one of the Shasta users out there is handling lost Acct-Stop
packets in some other way, I would very much like to know... as we are a
third party and not the ISP itself, we don't have direct access to the
Nortel people.
===
Archive at http://www.starport.net/~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.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) Acct-Interim-Update for keeping SessionDatabase current
Hi people, We are having trouble with stale records in our SessionDatabase. The NAS is a Nortel Shasta that doesn't seem to have a reasonable means of being queried about a particular Acct-Session-Id or Username/Framed-IP- Address. We started using Ping, but it seems to be giving addresses on a FIFO basis, so they are almost immediatly re-used making this method useless. The people at Nortel say that they can configure it so it sends Acct- Interim-Update packets every N minutes. What we could do is to catch every Acct-Interim-Update packet and make an update on the SessionDatabase record's Timestamp. Now, if we have a user trying to authenticate and according to our SessionDatabase it would exceed it's Simultaneous-Use value, we could check every record for this user and if the Timestamp is older than N minutes + 10% (or something like that), we consider it invalid and allow the user in again. How would I do this? That is, as there is an AddQuery for an Acct-Start and a DeleteQuery for an Acct-Stop, I would need to use a kind of "UpdateQuery" for an Acct- Interim-Update. How can I do this? Where should I handle the Simultaneous-Use check? That is, now I simply set a NasType in the Shasta's Client entry. How can I use an arbitrary perl function for this? Thanx. -- Baby -- PS: If one of the Shasta users out there is handling lost Acct-Stop packets in some other way, I would very much like to know... as we are a third party and not the ISP itself, we don't have direct access to the Nortel people. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) proxying + portlimitcheck scenario
Hello, I want to do the following: We have our own customers authenticating through LDAP (AuthBy LDAP2) and we keep accounting and the on line users in a MySQL database. Now we want to sale access through our NAS to other ISP's (we sell on line wireless access, through a shasta tunneling box). The idea is as follows: we wholesale to the other ISP a bunch of simultaneous connections with different characteristics, for instance: 50 64kbps connections 30 128kbps connections 10 256kbps connections 10 512kbps connections 5 1mbps connections We don't care about the other ISP users and passwords or which kind of connection they give to each user as long as this ISP's users don't exceed the maximum simultaneous connections of each kind. The idea is that the kind of connection be not preconfigured on the user's name or realm, but that the other ISP radius server be able to send it to us in an attribute, so they are able to dynamically assign the connections. That is, if they bought the example above, but have 60 customers for the 64kb connections, they are able to evaluate when the 51st. user is trying to log in and if there is another kind of connection available, they assign that. When we receive the Access-Accept from their radius server we should check this attribute and recodify it into a suitable attribute to send to the shasta (Shasta-Service-Profile), according to a set of rules. The quantities of connections for each customer ISP (we expect to have more than one) should be changeable on line (I would rather use LDAP than SQL, since all our provisioning works with LDAP). Now for the questions: 1) How should I combine AuthBy Radius with AuthBy PORTLIMITCHECK so I can do the port limit check AFTER I get the Radius Access-Accept. 2) Can I check the limits against something found in an LDAP entry? How? Otherwise, is there other solution? (probably through SQL) 3) We would like to add the accounting packets to our accounting AND ALSO send them to the other ISP. Is it possible, how do we do it? 4) What would be the "correct" attribute to pass info from the other ISP to us saying "accept and use this specific kind of connection"? I've been browsing through the RFC's and Configuration-Token (78) (RFC2869, page 31) seems to be the right choice... am I right? (BTW, it could be added to the next release of the dictionary ;-) TIA. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) AuthLog FILE - FailureFormat: REASON
Hi there,
I've been almost off this list for some time (I have a backlog of a month or so
in reading it) and I don't know if this has been discussed yet.
I'm using an AuthLog FILE to log both successes failures, and I want to
include the reason for the failure (not only the password).
I went to:
http://www.open.com.au/radiator/ref.html#22600
and didn't find anything that looked like that (since the reason for failure is
not a reply item)
I browsed through the sources (somehow lightly, yes) to see what the logger
did, but it seems to passing strings through objects in the logging modules and
is not even using global variables (so I can't use %{GlobalVar:name} either).
Is there a way to add the Authentication Failure Reason to the "FailureFormat"
string?
The relevant portion of my config file follows:
-
# Log authentication success and failure to a file
AuthLog FILE
Identifier authLogger
Filename %L/%Y-%m/auth_%d-%q
LogSuccess 1
LogFailure 1
SuccessFormat %l:%n::OK
FailureFormat %l:%n:%P:FAIL
/AuthLog
-
I would like to use something like:
AuthLog FILE
Identifier authLogger
Filename %L/%Y-%m/auth_%d-%q
LogSuccess 1
LogFailure 1
SuccessFormat %l:%n::OK
FailureFormat %l:%n:%P:FAIL:(%{Reason})
/AuthLog
Is it possible?
TIA.
===
Archive at http://www.starport.net/~radiator/
Announcements on [EMAIL PROTECTED]
To unsubscribe, email '[EMAIL PROTECTED]' with
'unsubscribe radiator' in the body of the message.
(RADIATOR) SNMPAgent sysUptime sysName
Hi there, we configured SNMPAgent so we can monitor our radius server with MRTG. Surprisingly MRTG wasn't working... after some debugging (on MRTG side, Radiator doesn't log anything but the request community received) we found out that Radiator doesn't understand "sysUptime" and "sysName" MIB2 OID's... so far, is the first snmp agent we found that doesn't recognize them. We changed the MRTG source so it doesn't ask it, but I think it would be nice if radiator did recognize them. or shouldn't it? thanx -- Mariano Absatz El Baby === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) Nortel Shasta dictionary
Hi Hugh, even though I asked a couple of times in the list, nobody seems to have used Radiator with a Nortel Shasta (or they've been silent about it). FWIW, I enclose the definitions I had to add to the dictionary to make it work: # Shasta Vendor Attributes VENDORATTR 3199 Shasta-User-Priv1 integer Shasta VENDORATTR 3199 Shasta-Service-Profile 2 string Shasta VENDORATTR 3199 Shasta-VPN 3 string Shasta VENDORATTR 3199 Shasta-SGROUP 4 string Shasta VENDORATTR 3199 Shasta-L2TP-Tunset 5 string Shasta VALUE Shasta-User-PrivUser0 VALUE Shasta-User-PrivSuper-User 1 VALUE Shasta-User-PrivSSuper-User 2 # (RFC 2869) ATTRIBUTE Event-Timestamp 55 integer So, for the record, Radiator works just fine with a Shasta. -- Mariano Absatz El Baby [EMAIL PROTECTED] === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) Disabling SessionDatabase on a per client level
El 14 Nov 2000, a las 8:40, Hugh Irvine escribió: Hello Chris - On Tue, 14 Nov 2000, Chris Given wrote: How can I disable the SessionDatabase on a per Client level? You can't disable the SessionDatabase in the Client clause, however you can do it on a per-Handler basis. Can I have a DIFFERENT Session-Database (e.g. based on handlers)? # configuration with multiple session databases SessionDatabase SQL Identifier SQL-SDB . /SessionDatabase SessionDatabase NULL Identifier NULL-SDB /SessionDatabase Handler .. SessionDatabase SQL-SDB . /Handler Handler . SessionDatabase NULL-SDB /Handler hth Hugh -- 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.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
Re: (RADIATOR) RE: radwho.cgi shows no logins
Hi Lisa, Do you have your SessionDatabase XXX? (didn't you commented it out?) Do you see " DEBUG: Adding session for userX, xx.xx.xx.xx, " and " DEBUG: Deleting session for userX, xx.xx.xx.xx, "? in a trace 4? El 14 Nov 2000, a las 17:16, Lisa Goulet escribió: Hello again, I noticed that while users are logged in there are entries in radusage table but not in radonline. Therefore the radwho script shows no logins. Again there are no errors, why are there no entries in radonline? Thanks again, Lisa -Original Message- From: Lisa Goulet Sent: Tuesday, November 14, 2000 4:35 PM To: [EMAIL PROTECTED] Subject:radwho.cgi shows no logins Hi colleagues, radwho was working fine. I hadn't used it in a couple of weeks and now it isn't working. There are no errors, it shows just the header but not the logins. The postgres database has the logins in the radusage table. Thanks for your help, Lisa === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message. -- Mariano Absatz El Baby [EMAIL PROTECTED] === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) wholesale proxy accounting
Hi, Our customer sells on-line internet access through wireless technology. The customers use a kind of "pseudo-dial-in", they tunnel through a shasta and the shasta authenticates users through our radius. We are in the process of migrating from cistron to Radiator. The point is the salespeople want to start wholesaling this connections to other ISP's for their users. That is, ISP's that only have dial-in capabilities will be able to offer on line connections to their users through our ISP. The point is that when we receive an Auth-Request from the shasta, we usually validate the user, and reply using a propietary vendor attribute (named Shasta-Profile) that tells the NAS (shasta) what QoS apply to that customer. Now, in this new wholesaling scenario, our ISP intends to sell to other ISPs different QoS like this: ispX is buying: 20 256Mbps connections 50 128Mbps connections 200 64Mbps connections Obviously, we'll be proxying the auth request to them as they own the user database. What we want is: 1) not allow over-use of connections on a per-ISP (not a per-user) basis. That is, that the other ISP is not able to over-sell the connections (or if they do, that WE reject the n+1th user of a kind). 2) that the other ISP has a mechanism not to allow a user of QoS x to use QoS y. Our idea is the following: if we are using 3 different QoS, to use 3 different realms for every customer ISP, that is, in the previous example: QoS256.ispX.com QoS128.ispX.com QoS64.ispX.com We proxy the three realms to the same server (ispX's radius), they receive the realm part so they are able to reject [EMAIL PROTECTED] if userY only payed THEM for QoS 64kbps. In each realm we should be able to handle a kind of "Simultaneous-Use" per realm (instead of "per user"). Is this possible? Is this reasonable? (anyway, it's difficult to get a salesperson to be reasonable). How do you recommend doing this? For our own users, we'll be using LDAP for user info authentication data (we could add a wholesale branch to the DIT and make "uid=customer isp id"), and we'll be using mySQL to hold the on-line users database. Comments? Insults? Flames? :-) === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
(RADIATOR) nwebie question: which AuthBy LDAP.*?
Hi, I want to know which AuthBy LDAP.* should I use. We're installing Radiator on a couple of Netras T1 with Solaris 7. We'll be authenticating through LDAP (with an OpenLDAP server) and we'll interface the LDAP server with PerLDAP. It's clear that AuthBy LDAP2 deprecated AuthBy LDAP, and the manual only speacks about PerLDAP in the AuthBy LDAPSDK (pg 79), but then, it says that about an NT server with ActiveState and SuiteSpot. Should I use AuthBy LDAPSDK or AuthBy LDAP2? If the answer is "both will do" which are the pros cons of each? TIA === Archive at http://www.starport.net/~radiator/ Announcements on [EMAIL PROTECTED] To unsubscribe, email '[EMAIL PROTECTED]' with 'unsubscribe radiator' in the body of the message.
