Best Practices - maximum NAS entries in clients.conf
@ everyone We have about 100 NAS entries in our clients.conf file, it makes the file a bear to deal with but the server seems to handle it fine. We will be expanding our infrastructure soon and the number of NAS entries will increase significantly. At what point should we think about putting them into a database for FR to use? Also, I have seen some chatter on the list about dynamic NASs. Am I correct in assuming that if we are using a DB instead of the clients.conf file we can add or remove clients simply by making changes to the correct table, all without having to restart FR? Jake Sallee Godfather of Bandwidth Network Engineer University of Mary Hardin-Baylor 900 College St. Belton, Texas 76513 Fone: 254-295-4658 Phax: 254-295-4221
Sallee, Stephen (Jake) wrote:
We have about 100 NAS entries in our clients.conf file, it makes the file a bear to deal with but the server seems to handle it fine. We will be expanding our infrastructure soon and the number of NAS entries will increase significantly. At what point should we think about putting them into a database for FR to use?
Whenever you get tired of managing them in clients.conf. The server has been tested with 500K clients in clients.conf. It takes a few seconds to start, and a gig or so of RAM, but it works.
Also, I have seen some chatter on the list about dynamic NASs. Am I correct in assuming that if we are using a DB instead of the clients.conf file we can add or remove clients simply by making changes to the correct table, all without having to restart FR?
Yes. You can also do this with files. See raddb/dynamic_clients in 2.1.12. (When it comes out) Alan DeKok.
On 12 Sep 2011, at 16:04, Sallee, Stephen (Jake) wrote:
@ everyone
We have about 100 NAS entries in our clients.conf file, it makes the file a bear to deal with but the server seems to handle it fine. We will be expanding our infrastructure soon and the number of NAS entries will increase significantly. At what point should we think about putting them into a database for FR to use?
When it becomes a bear to deal with the clients.conf file :) - I guess memory might be a concern? But i'm sure there are sites out there with client.conf files holding thousands of entries... It's a hash table in C, it's going to be fast.
Also, I have seen some chatter on the list about dynamic NASs. Am I correct in assuming that if we are using a DB instead of the clients.conf file we can add or remove clients simply by making changes to the correct table, all without having to restart FR?
Indeed. You can also set them to expire as well, to clean up old unused entries. -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.
On 9/12/2011 07:21, Arran Cudbard-Bell wrote:
On 12 Sep 2011, at 16:04, Sallee, Stephen (Jake) wrote:
@ everyone
We have about 100 NAS entries in our clients.conf file, it makes the file a bear to deal with but the server seems to handle it fine. We will be expanding our infrastructure soon and the number of NAS entries will increase significantly. At what point should we think about putting them into a database for FR to use? When it becomes a bear to deal with the clients.conf file :) - I guess memory might be a concern? But i'm sure there are sites out there with client.conf files holding thousands of entries... It's a hash table in C, it's going to be fast.
Also, I have seen some chatter on the list about dynamic NASs. Am I correct in assuming that if we are using a DB instead of the clients.conf file we can add or remove clients simply by making changes to the correct table, all without having to restart FR? Indeed. You can also set them to expire as well, to clean up old unused entries.
-Arran
Arran Cudbard-Bell a.cudbardb@freeradius.org
RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html Last I heard, you could NOT dynamically add NASs without restarting clients.conf as NAS entries are only read once on startup. Has this changed? Even if this has not changed, the advantages of storing NASs in a table is pretty significant. make changes, call quick restart script, done.
Last I heard, you could NOT dynamically add NASs without restarting clients.conf as NAS entries are only read once on startup. Has this changed?
Yes, FreeRADIUS will now load clients dynamically from clients or from a database, or an LDAP directory, or off a 5 1/4 floppy, a usb key shaped like a humping dog, or just about any other storage medium.
Even if this has not changed, the advantages of storing NASs in a table is pretty significant. make changes, call quick restart script, done.
Well it has changed. In fact it changed in 08/09. It's now, add client to SQL database, wait client to send packet, wooo client automagically added. You can even remove them using the radiusd control socket without restarting the server. -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.
On 9/12/2011 12:41, Arran Cudbard-Bell wrote:
Last I heard, you could NOT dynamically add NASs without restarting clients.conf as NAS entries are only read once on startup. Has this changed? Yes, FreeRADIUS will now load clients dynamically from clients or from a database, or an LDAP directory, or off a 5 1/4 floppy, a usb key shaped like a humping dog, or just about any other storage medium.
Even if this has not changed, the advantages of storing NASs in a table is pretty significant. make changes, call quick restart script, done. Well it has changed. In fact it changed in 08/09. It's now, add client to SQL database, wait client to send packet, wooo client automagically added. You can even remove them using the radiusd control socket without restarting the server.
-Arran
Arran Cudbard-Bell a.cudbardb@freeradius.org
RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html I'm very glad to hear about these changes, and may be implementing them in the near future (note to alan DeKok: I'm not the OP. I only responded to this recently.) Also, I own the USB key shaped like a humping dog. It doesn't have any storage space and is just a decorative humping dog for your computer. Unless they've made a new version since I purchased mine.
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
I'm very glad to hear about these changes, and may be implementing them in the near future (note to alan DeKok: I'm not the OP. I only responded to this recently.) Also, I own the USB key shaped like a humping dog. It doesn't have any storage space and is just a decorative humping dog for your computer. Unless they've made a new version since I purchased mine.
http://www.everythingusb.com/usb_humping_dog_12105.html Apparently they got it to hump, only when there was IO :) -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.
Christ Schlacta wrote:
Last I heard, you could NOT dynamically add NASs without restarting clients.conf as NAS entries are only read once on startup. Has this changed?
I *did* respond to your message. Please read the messages on this list.
Even if this has not changed, the advantages of storing NASs in a table is pretty significant. make changes, call quick restart script, done.
Uh... no. My message (again) talked about adding clients dynamically. Alan DeKok.
On Tue, Sep 13, 2011 at 2:42 AM, Alan DeKok <aland@deployingradius.com> wrote:
Christ Schlacta wrote:
Even if this has not changed, the advantages of storing NASs in a table is pretty significant. make changes, call quick restart script, done.
Uh... no. My message (again) talked about adding clients dynamically.
If I understand raddb/sites-available/dynamic-clients correctly, the only way to store (well, to retrieve actualy) dynamic clients definition in SQL is to use "%{sql:" expansion. Is there a way to make it have some level of redundancy? Last time I check, "%{sql:" can't be used on "virtual" modules (from instantiate or policy section) which groups multiple sql instance together using "redundant". -- Fajar
On 09/12/2011 10:42 PM, Fajar A. Nugraha wrote:
On Tue, Sep 13, 2011 at 2:42 AM, Alan DeKok<aland@deployingradius.com> wrote:
Christ Schlacta wrote:
Even if this has not changed, the advantages of storing NASs in a table is pretty significant. make changes, call quick restart script, done.
Uh... no. My message (again) talked about adding clients dynamically.
If I understand raddb/sites-available/dynamic-clients correctly, the only way to store (well, to retrieve actualy) dynamic clients definition in SQL is to use "%{sql:" expansion. Is there a way to make it have some level of redundancy? Last time I check, "%{sql:" can't be used on "virtual" modules (from instantiate or policy section) which groups multiple sql instance together using "redundant".
You could also use "exec", rlm_perl/python or whatever, all of which can themselves call SQL. Or, perform an SQL query that MUST return some output, parse the results and call the individual SQL modules directly - like so: update control { Tmp-String-0 := "%{sql1:select name||','||secret ...}" } if (control:Tmp-String-0 == "") { update control { Tmp-String-0 := "%{sql2:...}" } } if (control:Tmp-String-0 =~ /(.+),(.+)/) { update control { FreeRADIUS-Client-Shortname := %{1}" FreeRADIUS-Client-Secret := "%{2}" } }
On 09/13/2011 08:43 AM, Phil Mayers wrote:
You could also use "exec", rlm_perl/python or whatever, all of which can themselves call SQL.
Or, perform an SQL query that MUST return some output, parse the results and call the individual SQL modules directly - like so:
I forgot to add; you should also consider running a read-only replica of the SQL database locally on the radius server. We do this, and it means the radius server can operate completely isolated, and solves the problem for every use of SQL. It's also got better performance isolation characteristics.
On Tue, Sep 13, 2011 at 2:43 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 09/12/2011 10:42 PM, Fajar A. Nugraha wrote:
If I understand raddb/sites-available/dynamic-clients correctly, the only way to store (well, to retrieve actualy) dynamic clients definition in SQL is to use "%{sql:" expansion. Is there a way to make it have some level of redundancy? Last time I check, "%{sql:" can't be used on "virtual" modules (from instantiate or policy section) which groups multiple sql instance together using "redundant".
You could also use "exec", rlm_perl/python or whatever, all of which can themselves call SQL.
possible, though not ideal.
Or, perform an SQL query that MUST return some output, parse the results and call the individual SQL modules directly - like so:
update control { Tmp-String-0 := "%{sql1:select name||','||secret ...}" } if (control:Tmp-String-0 == "") { update control { Tmp-String-0 := "%{sql2:...}" } }
That's what we currently do (for another purpose, not for dynamic client). However: - I lost load-balancing feature that comes with redundant-load-balance - imagine having to create 8 if-elsif block to properly catch error when working with 8 sql nodes, and write the same sql query 8 times in the configuration file. Works, but kinda messy. With current sql module (that only reads nas list from sql during startup/HUP) I can use one sql/mysql/*.conf to specify the query, and have each sql instance $INCLUDE it. If we can do similar thing with "%{sql:" expansion (e.g. store the query in some temporary internal variable/attribute) it'd be reduce the measiness greatly, but I haven't found out how to do it yet. -- Fajar
On 13/09/11 08:59, Fajar A. Nugraha wrote:
That's what we currently do (for another purpose, not for dynamic client). However: - I lost load-balancing feature that comes with redundant-load-balance - imagine having to create 8 if-elsif block to properly catch error when working with 8 sql nodes, and write the same sql query 8 times in the configuration file. Works, but kinda messy.
With current sql module (that only reads nas list from sql during startup/HUP) I can use one sql/mysql/*.conf to specify the query, and have each sql instance $INCLUDE it. If we can do similar thing with "%{sql:" expansion (e.g. store the query in some temporary internal variable/attribute) it'd be reduce the measiness greatly, but I haven't found out how to do it yet.
You can't. It's not currently possible, and would require changes to the source code. Basically, the internal functions that handle xlat in FreeRADIUS do not have a way to signal error status, e.g. "notfound", "updated" etc. because they have a single integer return value that is the "length" of the xlat once done. 0 might mean "failed" or it might mean "empty string". Changing this would involve a lot of (very small) source code changes. I'm sure a patch would be accepted if you would care to write one :o)
On 13/09/11 10:57, Phil Mayers wrote:
On 13/09/11 08:59, Fajar A. Nugraha wrote:
That's what we currently do (for another purpose, not for dynamic client). However: - I lost load-balancing feature that comes with redundant-load-balance - imagine having to create 8 if-elsif block to properly catch error when working with 8 sql nodes, and write the same sql query 8 times in the configuration file. Works, but kinda messy.
With current sql module (that only reads nas list from sql during startup/HUP) I can use one sql/mysql/*.conf to specify the query, and have each sql instance $INCLUDE it. If we can do similar thing with "%{sql:" expansion (e.g. store the query in some temporary internal variable/attribute) it'd be reduce the measiness greatly, but I haven't found out how to do it yet.
You can't. It's not currently possible, and would require changes to the source code.
Wait, I think I've misunderstood you. Do you mean something like this? update control { SQL-Query := "select * from foo where bar=1" } sql_redundant_xlat # output now in control:Tmp-String-0 ...then in policy.conf: policy { sql_redundant_xlat { update control { Tmp-String-0 := "%{sql1:%{control:SQL-Query}}" } if (control:Tmp-String-0 == "") { update control { Tmp-String-0 := "%{sql2:%{control:SQL-Query}}" } } } }
On Tue, Sep 13, 2011 at 5:04 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
With current sql module (that only reads nas list from sql during startup/HUP) I can use one sql/mysql/*.conf to specify the query, and have each sql instance $INCLUDE it. If we can do similar thing with "%{sql:" expansion (e.g. store the query in some temporary internal variable/attribute) it'd be reduce the measiness greatly, but I haven't found out how to do it yet.
You can't. It's not currently possible, and would require changes to the source code.
Wait, I think I've misunderstood you.
Do you mean something like this?
update control { SQL-Query := "select * from foo where bar=1" } sql_redundant_xlat # output now in control:Tmp-String-0
...then in policy.conf:
policy { sql_redundant_xlat { update control { Tmp-String-0 := "%{sql1:%{control:SQL-Query}}" } if (control:Tmp-String-0 == "") { update control { Tmp-String-0 := "%{sql2:%{control:SQL-Query}}" } } } }
Hmm .... now that you wrote it in example it looks pretty easy :) I have to do some testing later. I forgot whether in the past I used temporary radius attribute (SQL-Query in your example) or configuration variable (using ${section.subsection.variable}). At that time some characters on the query got escaped so the queries resulted in an error. I'll update the results later. Thanks. -- Fajar
On 9/13/2011 00:59, Fajar A. Nugraha wrote:
> On Tue, Sep 13, 2011 at 2:43 PM, Phil Mayers<p.mayers@imperial.ac.uk> wrote:
>> On 09/12/2011 10:42 PM, Fajar A. Nugraha wrote:
>>> If I understand raddb/sites-available/dynamic-clients correctly, the
>>> only way to store (well, to retrieve actualy) dynamic clients
>>> definition in SQL is to use "%{sql:" expansion. Is there a way to make
>>> it have some level of redundancy? Last time I check, "%{sql:" can't be
>>> used on "virtual" modules (from instantiate or policy section) which
>>> groups multiple sql instance together using "redundant".
>>>
>> You could also use "exec", rlm_perl/python or whatever, all of which can
>> themselves call SQL.
> possible, though not ideal.
>
>> Or, perform an SQL query that MUST return some output, parse the results and
>> call the individual SQL modules directly - like so:
>>
>> update control {
>> Tmp-String-0 := "%{sql1:select name||','||secret ...}"
>> }
>> if (control:Tmp-String-0 == "") {
>> update control {
>> Tmp-String-0 := "%{sql2:...}"
>> }
>> }
> That's what we currently do (for another purpose, not for dynamic
> client). However:
> - I lost load-balancing feature that comes with redundant-load-balance
> - imagine having to create 8 if-elsif block to properly catch error
> when working with 8 sql nodes, and write the same sql query 8 times in
> the configuration file. Works, but kinda messy.
>
> With current sql module (that only reads nas list from sql during
> startup/HUP) I can use one sql/mysql/*.conf to specify the query, and
> have each sql instance $INCLUDE it. If we can do similar thing with
> "%{sql:" expansion (e.g. store the query in some temporary internal
> variable/attribute) it'd be reduce the measiness greatly, but I
> haven't found out how to do it yet.
>
why not make an arbitrary program that takes the SQL statement as an
argument, and returns from the first successful connection. it can take
a random number between 0 and n-1 on the number of SQL servers you have,
and start connecting from there. you get failover and round-robin load
balancing with the convenience of only having to write your query and
your series of if-else-if statements once.
On 13 Sep 2011, at 19:39, Christ Schlacta wrote:
> On 9/13/2011 00:59, Fajar A. Nugraha wrote:
>> On Tue, Sep 13, 2011 at 2:43 PM, Phil Mayers<p.mayers@imperial.ac.uk> wrote:
>>> On 09/12/2011 10:42 PM, Fajar A. Nugraha wrote:
>>>> If I understand raddb/sites-available/dynamic-clients correctly, the
>>>> only way to store (well, to retrieve actualy) dynamic clients
>>>> definition in SQL is to use "%{sql:" expansion. Is there a way to make
>>>> it have some level of redundancy? Last time I check, "%{sql:" can't be
>>>> used on "virtual" modules (from instantiate or policy section) which
>>>> groups multiple sql instance together using "redundant".
>>>>
>>> You could also use "exec", rlm_perl/python or whatever, all of which can
>>> themselves call SQL.
>> possible, though not ideal.
>>
>>> Or, perform an SQL query that MUST return some output, parse the results and
>>> call the individual SQL modules directly - like so:
>>>
>>> update control {
>>> Tmp-String-0 := "%{sql1:select name||','||secret ...}"
>>> }
>>> if (control:Tmp-String-0 == "") {
>>> update control {
>>> Tmp-String-0 := "%{sql2:...}"
>>> }
>>> }
>> That's what we currently do (for another purpose, not for dynamic
>> client). However:
>> - I lost load-balancing feature that comes with redundant-load-balance
>> - imagine having to create 8 if-elsif block to properly catch error
>> when working with 8 sql nodes, and write the same sql query 8 times in
>> the configuration file. Works, but kinda messy.
>>
>> With current sql module (that only reads nas list from sql during
>> startup/HUP) I can use one sql/mysql/*.conf to specify the query, and
>> have each sql instance $INCLUDE it. If we can do similar thing with
>> "%{sql:" expansion (e.g. store the query in some temporary internal
>> variable/attribute) it'd be reduce the measiness greatly, but I
>> haven't found out how to do it yet.
>>
> why not make an arbitrary program that takes the SQL statement as an argument, and returns from the first successful connection. it can take a random number between 0 and n-1 on the number of SQL servers you have, and start connecting from there. you get failover and round-robin load balancing with the convenience of only having to write your query and your series of if-else-if statements once.
Calling out to anything outside of FreeRADIUS comes with a big performance penalty.
I do sometimes wonder whether 'update config' would be useful as an interim hack for some of this stuff.
-Arran
Arran Cudbard-Bell
a.cudbardb@freeradius.org
RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.
If the network your APs are on is physically secure, and you don't need accounting for individual APs, you can use netmasks to define clients in the clients.conf file. ----- Original Message ----- From: "Sallee, Stephen (Jake)" <Jake.Sallee@umhb.edu> To: freeradius-users <freeradius-users@lists.freeradius.org> Cc: Sent: Monday, September 12, 2011 9:04 AM Subject: Best Practices - maximum NAS entries in clients.conf @ everyone We have about 100 NAS entries in our clients.conf file, it makes the file a bear to deal with but the server seems to handle it fine. We will be expanding our infrastructure soon and the number of NAS entries will increase significantly. At what point should we think about putting them into a database for FR to use? Also, I have seen some chatter on the list about dynamic NASs. Am I correct in assuming that if we are using a DB instead of the clients.conf file we can add or remove clients simply by making changes to the correct table, all without having to restart FR?
Yup. One could create a management / auth VLAN of sorts. Set the source port for RADIUS/Auth/etc. to be said VLAN. In theory then you would need only a single network entry in clients conf, and if you wish, reject traffic from any other "unauthorized" nets / IP's. We do something similar as we also have a large number of switches and other NAS type devices. G -----Original Message----- From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Bruce Nunn Sent: Monday, September 12, 2011 9:41 AM To: FreeRadius users mailing list Subject: Re: Best Practices - maximum NAS entries in clients.conf If the network your APs are on is physically secure, and you don't need accounting for individual APs, you can use netmasks to define clients in the clients.conf file. ----- Original Message ----- From: "Sallee, Stephen (Jake)" <Jake.Sallee@umhb.edu> To: freeradius-users <freeradius-users@lists.freeradius.org> Cc: Sent: Monday, September 12, 2011 9:04 AM Subject: Best Practices - maximum NAS entries in clients.conf @ everyone We have about 100 NAS entries in our clients.conf file, it makes the file a bear to deal with but the server seems to handle it fine. We will be expanding our infrastructure soon and the number of NAS entries will increase significantly. At what point should we think about putting them into a database for FR to use? Also, I have seen some chatter on the list about dynamic NASs. Am I correct in assuming that if we are using a DB instead of the clients.conf file we can add or remove clients simply by making changes to the correct table, all without having to restart FR? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
On 12 Sep 2011, at 16:41, Bruce Nunn wrote:
If the network your APs are on is physically secure, and you don't need accounting for individual APs, you can use netmasks to define clients in the clients.conf file.
Why would using a shared, shared secrets or netmasks mess with accounting? But yes, honestly, MD5 has been broken for some time, the only reason to use individual shared secrets is if you're still running something like PAP for Terminal login to the Access Point itself. Using a shared, shared secret does reduce the security of the protocol and increase the probability that the secret could be obtained... and of course if you've got one you've got them all. But if you're just running EAP with a TLS layer, then the only thing it buys you is DDOS protection, and request/response Integrity and thats only useful if the attacker is in a position to play MITM, or flood your server with requests... -Arran Arran Cudbard-Bell a.cudbardb@freeradius.org RADIUS - Waging war on ignorance and apathy one Access-Challenge at a time.
participants (8)
-
Alan DeKok -
Arran Cudbard-Bell -
Bruce Nunn -
Christ Schlacta -
Fajar A. Nugraha -
Gary Gatten -
Phil Mayers -
Sallee, Stephen (Jake)