I've commited some code (~1K LoC) to CVS head that will go into 2.0.6. In short, there's no point in using SNMP any more. The good news is that the Status-Server packet is overloaded to get all sorts of statistics that weren't available in SNMP. For more information, see: share/dictionary.freeradius Some comments: - the statistics can ONLY be queried from localhost. This will not be changed. - You can ask for ALL auth statistics (across all "listen" sockets) - Or, specify a socket IP/port, and it will return the stats for that socket. - You can do this for auth/acct sockets independently - you can query statistics for one client, and optionally specify the server IP/port (if the "listen" section has it's own clients) - you can ask for total auth/acct packets that are proxied to home servers - you can ask for total auth/acct packets that are sent to individual home servers. - you can tell when a home server was marked dead / alive, and how many requests have been sent, but not responded to. - you can ask for stats on the internal queues in the server (e.g. if it's busy, there will be many packets waiting, and all of the child threads will be doing work) The end result is that it's simpler to implement than SNMP, has fewer issues, and returns more data than the SNMP statistics would return. Enjoy. Alan DeKok.
hi, this is very cool - i guess it would be handy to let remote authorised machiens query it (trivial to have one central stats store then) but still..... I hope to see a lot of useful tools/widgets using this. bit of RRDTool is calling..... alan
A.L.M.Buxey@lboro.ac.uk wrote:
this is very cool - i guess it would be handy to let remote authorised machiens query it
Yes. But... it is a potential security issue to expose those statistics to anyone who asks. I could see external sites querying these statistics if: - the connection is encrypted - the client is querying a socket dedicated to Status-Server messages.
(trivial to have one central stats store then) but still..... I hope to see a lot of useful tools/widgets using this. bit of RRDTool is calling.....
Yes. There are a LOT of statistics available now. Almost every counter that you could track inside the server is exposed via this method. Alan DeKok.
Alan DeKok wrote:
A.L.M.Buxey@lboro.ac.uk wrote:
this is very cool - i guess it would be handy to let remote authorised machiens query it
Seconded.
Yes. But... it is a potential security issue to expose those statistics to anyone who asks.
I could see external sites querying these statistics if:
- the connection is encrypted - the client is querying a socket dedicated to Status-Server messages.
But it also kinda limits the usefulness of the feature. Couldn't you place it in the hands of the server admins to decide which hosts can query and which can't? Another configuration item in clients?
(trivial to have one central stats store then) but still..... I hope to see a lot of useful tools/widgets using this. bit of RRDTool is calling.....
Yes. There are a LOT of statistics available now. Almost every counter that you could track inside the server is exposed via this method.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
But it also kinda limits the usefulness of the feature. Couldn't you place it in the hands of the server admins to decide which hosts can query and which can't? Another configuration item in clients?
<grumble> It's possible. I guess. I think the safest thing to do is to have a socket that's *only* for these statistics. That way it's clear that no authentication can be done using it. and "real" clients have no business querying it. Alan DeKok.
Arran Cudbard-Bell wrote:
But it also kinda limits the usefulness of the feature. Couldn't you place it in the hands of the server admins to decide which hosts can query and which can't? Another configuration item in clients?
<grumble>
It's possible. I guess.
I think the safest thing to do is to have a socket that's *only* for these statistics. That way it's clear that no authentication can be done using it. and "real" clients have no business querying it.
Maybe a quicker solution would be to enable libwrap for it? I understand the changes to the code to support libwrap aren't too much, and it can even be made optional via the ./configure . Tuc
Tuc at T-B-O-H.NET wrote:
Maybe a quicker solution would be to enable libwrap for it? I understand the changes to the code to support libwrap aren't too much, and it can even be made optional via the ./configure .
Ugh. The IP configuration / filter in the server already does as much, if not more, than libwrap. Alan DeKok.
Tuc at T-B-O-H.NET wrote:
Maybe a quicker solution would be to enable libwrap for it? I understand the changes to the code to support libwrap aren't too much, and it can even be made optional via the ./configure .
Ugh. The IP configuration / filter in the server already does as much, if not more, than libwrap.
Ok. It was just a suggestion, sorta like the one from 2004 with code : http://lists.cistron.nl/pipermail/freeradius-devel/2004-October/007608.html (Oddly, I think I saw that in the bug database and wondered why it didn't make it, and then when looking for an example to show how little it takes to integrate I happened on that email.) Thought maybe adding more configuration options or hooking into the current system was less to your liking. Tuc
Hi,
Yes. But... it is a potential security issue to expose those statistics to anyone who asks.
obviously.
I could see external sites querying these statistics if:
- the connection is encrypted - the client is querying a socket dedicated to Status-Server messages.
yep. now...although I'm thinking RADSEC could be involved...just a new port that is properly firewalled would do..... i guess a 'statistics virtual server' would be the ideal thing.
Yes. There are a LOT of statistics available now. Almost every counter that you could track inside the server is exposed via this method.
i noted! grabbed the CVS to just have a look at the dictionary file. nice. however, it didnt compile... but i see a new change in auth.c as i write this...nope. still dead auth.c: In function 'rad_authlog': auth.c:119: error: expected expression before '<<' token auth.c:828: error: expected declaration or statement at end of input alan
A.L.M.Buxey@lboro.ac.uk wrote:
yep. now...although I'm thinking RADSEC could be involved...just a new port that is properly firewalled would do..... i guess a 'statistics virtual server' would be the ideal thing.
Done. Listen "type = status". In CVS.
i noted! grabbed the CVS to just have a look at the dictionary file. nice. however, it didnt compile... but i see a new change in auth.c as i write this...nope. still dead
auth.c: In function 'rad_authlog': auth.c:119: error: expected expression before '<<' token
You have local modifications, and the CVS update didn't do a merge, because it didn't know how. Grab a fresh copy of CVS, apply your patches, and see raddb/sites-available/status. Alan DeKok.
Exciting stuff! On Fri, Jun 20, 2008 at 2:48 PM, Alan DeKok <aland@deployingradius.com> wrote:
I've commited some code (~1K LoC) to CVS head that will go into 2.0.6. In short, there's no point in using SNMP any more. The good news is that the Status-Server packet is overloaded to get all sorts of statistics that weren't available in SNMP. For more information, see:
share/dictionary.freeradius
Some comments:
- the statistics can ONLY be queried from localhost. This will not be changed.
- You can ask for ALL auth statistics (across all "listen" sockets)
- Or, specify a socket IP/port, and it will return the stats for that socket.
- You can do this for auth/acct sockets independently
- you can query statistics for one client, and optionally specify the server IP/port (if the "listen" section has it's own clients)
- you can ask for total auth/acct packets that are proxied to home servers
- you can ask for total auth/acct packets that are sent to individual home servers.
- you can tell when a home server was marked dead / alive, and how many requests have been sent, but not responded to.
- you can ask for stats on the internal queues in the server (e.g. if it's busy, there will be many packets waiting, and all of the child threads will be doing work)
The end result is that it's simpler to implement than SNMP, has fewer issues, and returns more data than the SNMP statistics would return.
Enjoy.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Friday 20 June 2008 09:48:53 Alan DeKok wrote:
I've commited some code (~1K LoC) to CVS head that will go into 2.0.6. In short, there's no point in using SNMP any more. The good news is that the Status-Server packet is overloaded to get all sorts of statistics that weren't available in SNMP. For more information, see:
share/dictionary.freeradius
The changes sound great! I'd cutover to this if I were still at the company that used FR and SNMP monitoring stuff... Kevin Bonner
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Kevin Bonner -
Matt Causey -
Tuc at T-B-O-H.NET