Maintaining a (very) dynamic user list with freeradius
Hi, What is the best way to maintain a very dynamic user list for freeradius (on a Linux platform)? I'm talking about a setup where every few minutes (sometimes every minute) a user has to be added and/or removed, with in total up to about 200 users in the user base at the same moment. Ideally, I'd like to just regenerate the users file with a script whenever a change is needed and let radiusd reload it, but I saw in the docs that reloading the config (and the users file) is "expensive", so this will probably not be very suitable for this situation. If anyhow possible I'd like to minimize any extra overhead, and avoid running PostgreSQL or MySQL servers, for example. Maybe use DBM? What is recommended for this purpose? Thanks for all suggestions. -- -- Jos Vos <jos@xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
On Fri 02 Nov 2007, Jos Vos wrote:
Hi,
What is the best way to maintain a very dynamic user list for freeradius (on a Linux platform)?
I'm talking about a setup where every few minutes (sometimes every minute) a user has to be added and/or removed, with in total up to about 200 users in the user base at the same moment.
Ideally, I'd like to just regenerate the users file with a script whenever a change is needed and let radiusd reload it, but I saw in the docs that reloading the config (and the users file) is "expensive", so this will probably not be very suitable for this situation.
If anyhow possible I'd like to minimize any extra overhead, and avoid running PostgreSQL or MySQL servers, for example. Maybe use DBM?
What is recommended for this purpose?
Use either SQL or LDAP... -- Peter Nixon http://peternixon.net/
On Fri, 2007-11-02 at 09:00 +0100, Jos Vos wrote:
Hi,
What is the best way to maintain a very dynamic user list for freeradius (on a Linux platform)?
I'm talking about a setup where every few minutes (sometimes every minute) a user has to be added and/or removed, with in total up to about 200 users in the user base at the same moment.
Ideally, I'd like to just regenerate the users file with a script whenever a change is needed and let radiusd reload it, but I saw in the docs that reloading the config (and the users file) is "expensive", so this will probably not be very suitable for this situation.
If anyhow possible I'd like to minimize any extra overhead, and avoid running PostgreSQL or MySQL servers, for example. Maybe use DBM?
The DBMs cannot be concurrently updated. Use SQL or LDAP. Running a postgresql server for ~200 row table is very little effort.
On Fri, Nov 02, 2007 at 11:11:17AM +0000, Phil Mayers wrote:
Use SQL or LDAP. Running a postgresql server for ~200 row table is very little effort.
Is <http://wiki.freeradius.org/SQL_HOWTO> the best documentation on how to populate / change the DB? Does this also apply to freeradius 1.0.1. As the systems I'll be using for freeradius are currently running RHEL4, I'm more or less forced to using freeradius 1.0.1 for now. If there are any caveats, please let me know. -- -- Jos Vos <jos@xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
Jos Vos wrote:
As the systems I'll be using for freeradius are currently running RHEL4, I'm more or less forced to using freeradius 1.0.1 for now. If there are any caveats, please let me know.
http://freeradius.org/security.html You *can* manually upgrade to 1.1.7. It's not hard. Alan DeKok.
On Sat, Nov 03, 2007 at 12:36:01AM +0100, Alan DeKok wrote:
http://freeradius.org/security.html
You *can* manually upgrade to 1.1.7. It's not hard.
RH always backports security patches. From their 1.0.1 changelog: * Wed Apr 25 2007 Thomas Woerner <twoerner@redhat.com> 1.0.1-3.RHEL4.5 - fixed CVE-2007-2028: EAP-TTLS denial of service Resolves: rhbz#236247 * Fri Mar 24 2006 Thomas Woerner <twoerner@redhat.com> 1.0.1-3.RHEL4.3 - added two lost fixes from (#167676) * Fri Mar 24 2006 Thomas Woerner <twoerner@redhat.com> 1.0.1-3.RHEL4.2 - CVE-2006-1354: security fixes for EAP-MSCHAPv2 (#186083) - other security related fixes (#167676) * Tue Jun 14 2005 Thomas Woerner <twoerner@redhat.com> 1.0.1-3.RHEL4 - Fixed buffer overflow and possible SQL injection attacks in rlm_sql CAN-2005-1454, CAN-2005-1455 (#156941) [...] Deviating from the standard RHEL packages and maintaining your own RPM (this is for a large number of systems) is probably doable (often you encounter incompatibiities with older compilers and libraries, but freeradius is a relatively isolated piece of software, I think), but it also means I have to take care of security problems etc. myself, while RH does that for me now. That's why I only tend to maintain my own version if really necessary. -- -- Jos Vos <jos@xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
Jos Vos wrote:
RH always backports security patches. From their 1.0.1 changelog:
Forgive me for not following how all of the vendors operate.
Deviating from the standard RHEL packages and maintaining your own RPM (this is for a large number of systems) is probably doable (often you encounter incompatibiities with older compilers and libraries, but freeradius is a relatively isolated piece of software, I think), but it also means I have to take care of security problems etc. myself, while RH does that for me now. That's why I only tend to maintain my own version if really necessary.
Given the large difference in functionality between 1.0.x and 1.1.x, it's almost not worth asking for help on this list. Almost everyone is using a *recent* version (i.e. one that's less than a year old). Once 2.0 has been out for a while, I suspect that the answer to questions about 1.0.x will be one word: Upgrade. In other words, it's nice that your preferred vendor supports a product that is many years old. Perhaps they should be supporting it *completely*. i.e. Answering questions about it. If you're not willing to upgrade, understand that no one here is getting paid to go back to a 3-year-old version, and try to figure out how to solve your problem using functionality that they're no longer familiar with. You made a choice to stick with an unsupported version. Upgrade to a supported version, or buy support. Alan DeKok.
Jos Vos <jos@xos.nl> writes:
Deviating from the standard RHEL packages and maintaining your own RPM (this is for a large number of systems) is probably doable (often you encounter incompatibiities with older compilers and libraries, but freeradius is a relatively isolated piece of software, I think), but it also means I have to take care of security problems etc. myself, while RH does that for me now. That's why I only tend to maintain my own version if really necessary.
This is most likely a case where, although not strictly necessary, an upgrade will save you lots of work and frustrations. But if RH and you still feel FreeRadius 1.0.1 is the way to go, then I assume that RH provides the proper documentation and support for this out-dated version. But you are of course right: Using RHEL4 compilers and libraries is probably going to cause a number of problems too. Or to be more precise: Using RHEL4 is probably going to cause a number of problems. I would strongly suggest to read this bug report and try to understand the implications: https://bugzilla.redhat.com/show_bug.cgi?id=166873 Short summary for the impatient: RHEL4 includes a random CVS snapshot of mod_perl2, which is neither compatible with mod_perl1 nor mod_perl2, since there were major API changes between this CVS snapshot and the mod_perl2 release. This makes it completely unusable in the real world. This is not considered a bug. You can expect the FreeRadius version in RHEL4 to be in the same state: A random snapshot taken at the time of RHEL4 release, and not really something the developers of FreeRadius would recommend using. Not now, anyway. Which you've probably learned now Bjørn
On Sat, Nov 03, 2007 at 02:00:15PM +0100, Bjørn Mork wrote:
But if RH and you still feel FreeRadius 1.0.1 is the way to go, then I assume that RH provides the proper documentation and support for this out-dated version.
RHEL4 has freeradius 1.0.1, RHEL5 has 1.1.3.
But you are of course right: Using RHEL4 compilers and libraries is probably going to cause a number of problems too. Or to be more precise: Using RHEL4 is probably going to cause a number of problems.
I would strongly suggest to read this bug report and try to understand the implications: https://bugzilla.redhat.com/show_bug.cgi?id=166873
Short summary for the impatient: RHEL4 includes a random CVS snapshot of mod_perl2, which is neither compatible with mod_perl1 nor mod_perl2, since there were major API changes between this CVS snapshot and the mod_perl2 release. This makes it completely unusable in the real world. This is not considered a bug.
I agree that some of RH's decisions are arguable, but, in general, having the policy to release a stable version of a Linux distro every 2 years and maintain that for 7 years *without interface changes* (in principle) is a good thing and really needed in many production environments. Thus (in general -- there are exceptions) packages are not upgraded, but only patched. In general, RHELx releases are *much* more stable and better integrated than bleeding-edge distros. Although it also has shortcomings, I'ld not want to maintain large installations using some bleeding-edge distro... Just to clarify my situation: In my case, we're talking about an installed base of RHEL4 systems in a mission-critical environment, using non-standard PC-hardware, installed at many remote locations throughout the country, so ideally this should stay working for 5+ years without reinstallation. But your message is clear and I'll see if I can generate a more recent version of freeradius on RHEL4. -- -- Jos Vos <jos@xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
Jos Vos wrote:
I agree that some of RH's decisions are arguable, but, in general, having the policy to release a stable version of a Linux distro every 2 years and maintain that for 7 years *without interface changes* (in principle) is a good thing and really needed in many production environments.
Agreed. But that is *Redhat's* problem, not ours. *Redhat* should provide support for 3-year-old versions of FreeRADIUS.
Just to clarify my situation: In my case, we're talking about an installed base of RHEL4 systems in a mission-critical environment, using non-standard PC-hardware, installed at many remote locations throughout the country, so ideally this should stay working for 5+ years without reinstallation.
And you're *not* willing to purchase support? Wow...
But your message is clear and I'll see if I can generate a more recent version of freeradius on RHEL4.
Or, purchase support from someone for the version that you are willing to run. Alan DeKok.
On Mon, Nov 05, 2007 at 08:04:02AM +0100, Alan DeKok wrote:
Agreed. But that is *Redhat's* problem, not ours. *Redhat* should provide support for 3-year-old versions of FreeRADIUS.
I never suggested that someone *should* support the old version. I posted a message to a public mailing list (i.e. freeradius-users) and hoped for people to answer it (which actually happened), just like a lot of people do on most other public mailing lists. You *almost* suggest that I shouldn't dare to do that, as long as I don't run the latest version. Of course, I fully understand the advice to run the latest version and I appreciate that, but there are many reasons to run a certain version (and I tried to explain a few of them). And of course, you and others on the list are completely free to ignore my questions, whatever version I'm running, so I hope you don't feel offended by it, especially in case I mention that I'm running 1.0.1.
Just to clarify my situation: In my case, we're talking about an installed base of RHEL4 systems in a mission-critical environment, using non-standard PC-hardware, installed at many remote locations throughout the country, so ideally this should stay working for 5+ years without reinstallation.
And you're *not* willing to purchase support? Wow...
Note that RHEL4 is actually X/OS Linux 4, our own rebuild of RHEL4 (that we provide for free for everyone, b.t.w., see www.xoslinux.org). Adding a FreeRADIUS server to those devices for access control on a wireless access point is just a small extra feature. If we would have to buy support contracts, upgrade the OS, or whatever, we would never do that project. We also know some companies running our X/OS Linux, asking us questions (which we're also free to answer or ignore, of course), and not willing (or able?) to buy support contracts. But that's the way it works in the Open Source world. -- -- Jos Vos <jos@xos.nl> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
participants (5)
-
Alan DeKok -
Bjørn Mork -
Jos Vos -
Peter Nixon -
Phil Mayers