I’ve pushed some changes to radmin, which will be in the 3.0.7 release. The changes make radmin work a little better, in that it now makes a distinction between STDOUT and STDERR. Also, when a command fails, radmin will exit with an error: $ radmin -e “help” … $ echo $? 0 Versus: $ radmin -e “no such command” … $ echo $? 1 These changes were made possible by updating the underlying framework used by radmin and the server. The result of these framework changes is that we can now exchange *anything* safely between the server and radmin. So… what would be useful to exchange? We can’t do configuration changes, as the server can’t write to /etc/raddb. But we could do test packets, for example. $ radmin “send packet X pretending to be from NAS 192.0.2.1” And get a response. This means it would be possible to perform better tests on live systems. Any other ideas? Alan DeKok.
Alan, I'd love to see flushing of SQL learned clients entries (per virtual server), so you can change the secret in SQL, issue a flush command and then relearn with a new secret without relying on timeouts. I had also played with enhancing radmin so when you do a show clients you can see which virtual server they are associated with and also show timeouts of SQL learned clients, but I didn't get the correct data and never worked out where I was going wrong. Basically anything around managing SQL learned dynamic clients and per virtual servers support would be great! Cheers Kev/.
-----Original Message----- From: freeradius-users-bounces+email.me=kevp.com@lists.freeradius.org [mailto:freeradius-users-bounces+email.me=kevp.com@lists.freeradius.org] On Behalf Of Alan DeKok Sent: 04 February 2015 15:36 To: FreeRadius users mailing list Subject: What else should radmin do?
I've pushed some changes to radmin, which will be in the 3.0.7 release. The changes make radmin work a little better, in that it now makes a distinction between STDOUT and STDERR. Also, when a command fails, radmin will exit with an error:
$ radmin -e "help" . $ echo $? 0
Versus:
$ radmin -e "no such command" . $ echo $? 1
These changes were made possible by updating the underlying framework used by radmin and the server. The result of these framework changes is that we can now exchange *anything* safely between the server and radmin.
So. what would be useful to exchange? We can't do configuration changes, as the server can't write to /etc/raddb.
But we could do test packets, for example.
$ radmin "send packet X pretending to be from NAS 192.0.2.1"
And get a response. This means it would be possible to perform better tests on live systems.
Any other ideas?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Feb 4, 2015, at 11:18 AM, Kev Pearce <email.me@kevp.com> wrote:
I'd love to see flushing of SQL learned clients entries (per virtual server), so you can change the secret in SQL, issue a flush command and then relearn with a new secret without relying on timeouts.
That’s there today, at least in v3.: $ radmin -e "del client help" del client ipaddr <ipaddr> - Delete a dynamically created client
I had also played with enhancing radmin so when you do a show clients you can see which virtual server they are associated with and also show timeouts of SQL learned clients, but I didn't get the correct data and never worked out where I was going wrong.
That’s useful, and a good idea.
Basically anything around managing SQL learned dynamic clients and per virtual servers support would be great!
Details help here. :) Alan DeKok.
Basically anything around managing SQL learned dynamic clients and per virtual servers support would be great!
Details help here. :)
I have two dynamic clients per virtual server: 0.0.0.0/1 and 128.0.0.0/1 and each of my virtual servers has these. So being able to delete client 0.0.0.0/1 from a specific virtual server would be good, i.e.: del client ipaddr <ipaddr> vs <name_of_vs> Kev/.
On Feb 4, 2015, at 11:43 AM, Kev Pearce <email.me@kevp.com> wrote:
I have two dynamic clients per virtual server: 0.0.0.0/1 and 128.0.0.0/1 and each of my virtual servers has these. So being able to delete client 0.0.0.0/1 from a specific virtual server would be good, i.e.:
del client ipaddr <ipaddr> vs <name_of_vs>
Hmm… good point. The radmin commands don’t deal well with virtual servers right now. That should be fixed. Alan DeKok.
On Feb 4, 2015, at 11:43 AM, Kev Pearce <email.me@kevp.com> wrote:
So being able to delete client 0.0.0.0/1 from a specific virtual server would be good, i.e.:
del client ipaddr <ipaddr> vs <name_of_vs>
Can you try the v3.0.x branch from git? $ radmin -e “del client help” del client ipaddr <ipaddr> [udp|tcp] [listen <ipaddr> <port>] - Delete a dynamically created client Alan DeKok.
On 4 Feb 2015, at 22:36, Alan DeKok <aland@deployingradius.com> wrote:
I’ve pushed some changes to radmin, which will be in the 3.0.7 release. The changes make radmin work a little better, in that it now makes a distinction between STDOUT and STDERR. Also, when a command fails, radmin will exit with an error:
$ radmin -e “help” … $ echo $? 0
Versus:
$ radmin -e “no such command” … $ echo $? 1
These changes were made possible by updating the underlying framework used by radmin and the server. The result of these framework changes is that we can now exchange *anything* safely between the server and radmin.
So… what would be useful to exchange? We can’t do configuration changes, as the server can’t write to /etc/raddb.
But we could do test packets, for example.
$ radmin “send packet X pretending to be from NAS 192.0.2.1”
And get a response. This means it would be possible to perform better tests on live systems.
Injecting packets good. It's hard to test policies with many different kinds of NAS. For this it'd be nice to accept piped input into radmin (like is currently possible with radclient), instead of introducing new command syntax. * Multiline input for certain commands (like packet injection) * Persistent command history via readline. * Connection pool status 'ping'. Time execution of the status callback. Probably want to do this asynchronously. * Injecting outbound packets (is this already there)? Start with CoA/DM. * Triggering home-server status checks as FreeRADIUS isn't allowed to do keepalives. * Connection pool stats. * Forcing rolling re-establishment of connection pool connections. * Forcing connection pools to return no connection available - now they're shared we need a way of disabling all modules which use a given pool. * Toggle whether listeners respond to new requests (graceful removal from proxy or load balance group) * Dynamic discard filters. Firewalls generally can't filter on RADIUS attributes.
Any other ideas?
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Kev Pearce