We are happy to announce the release of Version 2.1.0 of the FreeRADIUS server, with some major new features. Highlights include improved SNMP support, dynamically-defined clients, much more flexible (and readable) debugging mode, WiMAX support, fast reauthentication for PEAP and TTLS, and a command-line tool to administer a running server. The administration tool can stop the server, HUP it, or in limited cases, change the configuration of a running server, and cause just one module to reload it's configuration. Alan DeKok. Detailed change log: FreeRADIUS 2.1.0 Fri Sep 5 13:20:01 CEST 2008; , urgency=medium Feature improvements * Clients may now be defined dynamically, based on IP address. See raddb/sites-available/dynamic-clients. * SNMP support is now available through an experimental Perl script. See scripts/snmp-proxy/README * SNMP statistics are available through Status-Server packets. See raddb/sites-available/status * Added more Microsoft attributes from bug #568. * The "linelog" module has more functionality and flexibility. See raddb/modules/linelog. * The debugging output has been sanitized. It should be much more readable. * Debug logs can now be turned on/off while the server is running, for a user, group, realm, etc. See the "log" section of radiusd.conf. * Added support for WiMAX Forum attributes. The dynamic keys are not yet calculated. See share/dictionary.wimax * Added session resumption for PEAP and TTLS. See raddb/eap.conf, "cache" sub-section. * Added "radmin" command-line tool for administering a running server. See "man radmin" and raddb/sites-available/control-socket. Bug fixes * Double escaping of '\\' in the "users" (and some other) files has been fixed. If you have '\\' in the "users" file, your configuration WILL NEED TO BE CHECKED, AND FIXED! * Parse "security" section in radiusd.conf. This was accidentally deleted in 2.0.5. Closes bug #566. * Bind to interface before IP, which allows DHCP sockets to listen on "*" for multiple interfaces. * Fix handling of giaddr in DHCP responses. * Corrected parsing of status_check in home_server so that it works. * Fix hints so that "Puser" works again. * Removed length restrictions on attribute names in the dictionaries. * Update socket code to avoid C compiler optimizations.
Hi, I'm getting an error when trying to build debian packages. lab1:~/freeradius-server-2.1.0# dpkg-buildpackage -b -uc parsechangelog/debian: error: badly formatted trailer line, at file debian/changelog line 22 dpkg-buildpackage: unable to determine source package is Roberto Alan DeKok wrote:
We are happy to announce the release of Version 2.1.0 of the FreeRADIUS server, with some major new features.
Highlights include improved SNMP support, dynamically-defined clients, much more flexible (and readable) debugging mode, WiMAX support, fast reauthentication for PEAP and TTLS, and a command-line tool to administer a running server.
The administration tool can stop the server, HUP it, or in limited cases, change the configuration of a running server, and cause just one module to reload it's configuration.
Alan DeKok.
-- ----------------------------------------------------- Marcos Roberto Greiner Os otimistas acham que estamos no melhor dos mundos Os pessimistas tem medo de que isto seja verdade Murphy -----------------------------------------------------
rgreiner wrote:
I'm getting an error when trying to build debian packages.
Debian is just to nit-picky for my liking.
lab1:~/freeradius-server-2.1.0# dpkg-buildpackage -b -uc parsechangelog/debian: error: badly formatted trailer line, at file debian/changelog line 22
It doesn't like the date format. Ugh. I'm thinking for future releases, we can just use the same content in debian/changelong, and change only the version number. My suggestion is to edit the date to something debian likes. Why it's so picky, and can't parse what's obviously a valid date, is beyond me. Alan DeKok.
The new /usr/sbin/radmin is missing in %files section of the suse specfile. When added the packages will be build correctly. Norbert Wegener
Alan DeKok wrote:
.. * Debug logs can now be turned on/off while the server is running, for a user, group, realm, etc. See the "log" section of radiusd.conf.
It seems to me, the log section contains the same items as in 2.0.5. So I am not sure how to turn logging on for a specific user when the server is running: log { destination = files file = ${logdir}/radius.log # #requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m%d.log syslog_facility = daemon stripped_names = no auth = no auth_badpass = no auth_goodpass = no } Maybe I missed something? Norbert Wegener
Norbert Wegener wrote:
It seems to me, the log section contains the same items as in 2.0.5.
The "requests" entry is new. It can send logs to different destinations based on dynamic expansions.
So I am not sure how to turn logging on for a specific user when the server is running:
Yes, that isn't documented there. I've added some text for 2.1.1. In short, you can do: ... update control { Tmp-String-0 = "%{debug:2}" } ... to set the debug level to 2 for *this* request. That "update" section can be wrapped in an "if", to check for users, groups, realms, etc. 2.1.1 will also have the ability to change the global debug level from radmin. 2.1.2 will have the ability to change the debug level for requests coming from a particular client. Alan DeKok.
Yes, that isn't documented there. I've added some text for 2.1.1.
In short, you can do:
... update control { Tmp-String-0 = "%{debug:2}" } ...
Didn't you alter the parser slightly to allow just: ... %{debug:2} ... Or did you remove it before 2.1.0 ? -- 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
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Didn't you alter the parser slightly to allow just:
... %{debug:2} ...
Err, yes. But that's horrible syntax, and I don't think it will stay.
if (condition) { call debug 2 } Might also be useful for: post-auth { call sql "insert into blah ..." }
Phil Mayers wrote:
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
Didn't you alter the parser slightly to allow just:
... %{debug:2} ...
Err, yes. But that's horrible syntax, and I don't think it will stay.
It's not a horrible syntax it's useful syntax, especially when being used with horrible hacks such as this... makes them less horrible. It's also good for making arbitrary calls to modules when you don't care about the return value, such as sql insert and update statements (if the SQL module supported xlated insert and update statements). Having to wrap the whole thing in an update stanza and having to assign the return value to a temporary string, now that's horrible syntax.
if (condition) { call debug 2 }
Might also be useful for:
post-auth { call sql "insert into blah ..." }
I don't see that extra syntax is required... -- 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
I'm seeing lots of Wed Aug 5 10:40:28 2009 : Error: TLS_accept:error in SSLv3 read client certificate A Wed Aug 5 10:40:28 2009 : Error: rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0) In my radius logs. I'm fairly certain I've done this research before but I don't have any notes to show management. I suspect the answer was that this is an openssl error and it doesn't stop radius from accepting authentications. However could someone point me to some details of the problem? We're running freeradius v1.1.4 on RHEL4. Thanks, Jim Jim Heivilin, System Administrator, Combined Server Group, Division of IT (formerly IAT Services), University of Missouri at Columbia mailto:banzai@missouri.edu, (573) 884-3898
Heivilin, Jim wrote:
I'm seeing lots of
Wed Aug 5 10:40:28 2009 : Error: TLS_accept:error in SSLv3 read client certificate A Wed Aug 5 10:40:28 2009 : Error: rlm_eap: SSL error error:00000000:lib(0):func(0):reason(0)
That was fixed some time *way* back in the 1.1 versions.
In my radius logs.
I'm fairly certain I've done this research before but I don't have any notes to show management. I suspect the answer was that this is an openssl error and it doesn't stop radius from accepting authentications. However could someone point me to some details of the problem?
OpenSSL returns "error!". Then when you ask it what the error was, it says "no error!" We fixed our code to not complain when OpenSSL returns "error, but really no error".
We're running freeradius v1.1.4 on RHEL4.
Upgrade to 1.1.7. Alan DeKok.
participants (6)
-
Alan DeKok -
Arran Cudbard-Bell -
Heivilin, Jim -
Norbert Wegener -
Phil Mayers -
rgreiner