This is a "stable" release, which is intended to fix outstanding bugs. We suggest reading the changelog below, to see if any issues you have encountered are fixed in this release. Feature improvements * Add radmin command "stats detail <file>" to see what is going on inside of a detail file reader. * Added documentation for CoA. See raddb/sites-available/coa * Add sub-option support for Option 82. See dictionary.dhcp * Add "server" field to default SQL NAS table, and documented it. Bug fixes * Reset "received ping" counter for Status-Server checks. In some corner cases it was not getting reset. * Handle large VMPS attributes. * Count accounting responses from a home server in SNMP / statistics code. * Set EAP-Session-Resumed = Yes, not "No" when session is resumed. * radmin packet counter statistics are now unsigned, for numbers 2^31..2^32. After that they roll over to zero. * Be more careful about expanding data in PAP and MS-CHAP modules. This prevents login failures when passwords contain '{'. * Clean up zombie children if there were many "exec" modules being run for one packet, all with "wait = no". * re-open log file after HUP. Closes bug #63. * Fix "no response to proxied packet" complaint for Coa / Disconnect packets. It shouldn't ignore replies to packets it sent. * Calculate IPv6 netmasks correctly. Closes bug #69. * Fix SQL module to re-open sockets if they unexpectedly close. * Track scope for IPv6 addresses. This lets us use link-local addresses properly. Closes bug #70. * Updated Makefiles to no longer use the shell for recursing into subdirs. "make -j 2" should now work. * Updated raddb/sql/mysql/ippool.conf to use "= NULL". Closes bug #75. * Updated Makefiles so that "make reconfig" no longer uses the shell for recursing into subdirs, and re-builds all "configure" files. * Used above method to regenerate all configure scripts. Closes bug #34. * Updated SQL module to allow "server" field of "nas" table to be blank: "". This means the same as it being NULL. * Fixed regex realm example. Create Realm attribute with value of realm from User-Name, not from regex. Closes bug #40. * If processing a DHCP Discover returns "fail / reject", ignore the packet rather than sending a NAK. * Allow '%' to be escaped in sqlcounter module. * Fix typo internal hash table. * For PEAP and TTLS, the tunneled reply is added to the reply, rather than integrated via the operators. This allows multiple VSAs to be added, where they would previously be discarded. * Make request number unsigned. This changes nothing other than the debug output when the server receives more than 2^31 packets. * Don't block when reading child output in 'exec wait'. This means that blocked children get killed, instead of blocking the server. * Enabled building without any proxy functionality * radclient now prefers IPv4, to match the default server config. * Print useful error when a realm regex is invalid * relaxed rules for preprocess module "with_cisco_vsa_hack". The attributes can now be integer, ipaddr, etc. (i.e. non-string) * Allow rlm_ldap to build if ldap_set_rebind_proc() has only 2 arguments. * Update configure script for rlm_python to avoid dynamic linking problems on some platforms. * Work-around for bug #35 * Do suid to "user" when running in debug mode as root * Make "allow_core_dumps" work in more situations. * In detail file reader, treat bad records as EOF. This allows it to continue working when the disk is full. * Fix Oracle default accounting queries to work when there are no gigawords attributes. Other databases already had the fix. * Fix rlm_sql to show when it opens and closes sockets. It already says when it cannot connect, so it should say when it can connect. * "chmod -x" for a few C source files. * Pull update spec files, etc. from RedHat into the redhat/ directory. * Allow spaces when parsing integer values. This helps people who put "too much" into an SQL value field.
On 2010/05/24 12:28 PM, Alan DeKok wrote:
This is a "stable" release, which is intended to fix outstanding bugs. We suggest reading the changelog below, to see if any issues you have encountered are fixed in this release.
debian/changelog still contains "+git"...... Dont know if it is supposed to be fixed. -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
FreeRADIUS version 2.1.9 has been built for the following versions of Fedora * devel (aka rawhide) * Fedora 13 * Fedora 12 The packages for Fedora 12 and Fedora 13 have been submitted to the *testing* distribution channel (you will need to have the testing repo enabled in your yum configuration to pick these up). It may take a day for the packages to hit the yum mirrors. If there are no reported problems within a week I will move the packages from testing to stable at which point a normal yum update will pick them up. If you do not want to wait for the packages to hit the mirrors or appear in your designated channel they you may immediately download the packages from koji: https://koji.fedoraproject.org/koji/packageinfo?packageID=298 Enjoy! -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
The HTTPS link below did not work, however this HTTP link does. http://koji.fedoraproject.org/koji/packageinfo?packageID=298
-----Original Message----- From: freeradius-users-bounces+dale=top.net.nz@lists.freeradius.org [mailto:freeradius-users-bounces+dale=top.net.nz@lists.freeradius.org] On Behalf Of John Dennis Sent: Tuesday, 25 May 2010 5:27 a.m. To: FreeRadius users mailing list Cc: Alan DeKok Subject: Re: Version 2.1.9 has been released
FreeRADIUS version 2.1.9 has been built for the following versions of Fedora
* devel (aka rawhide) * Fedora 13 * Fedora 12
The packages for Fedora 12 and Fedora 13 have been submitted to the *testing* distribution channel (you will need to have the testing repo enabled in your yum configuration to pick these up). It may take a day for the packages to hit the yum mirrors. If there are no reported problems within a week I will move the packages from testing to stable at which point a normal yum update will pick them up.
If you do not want to wait for the packages to hit the mirrors or appear in your designated channel they you may immediately download the packages from koji:
https://koji.fedoraproject.org/koji/packageinfo?packageID=298
Enjoy!
-- John Dennis <jdennis@redhat.com>
Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hmm, this release doesn't seem to be tagged in the v2.1.x branch on git://git.freeradius.org/freeradius-server.git Am I looking at the wrong repository (again)? Bjørn
ftp://ftp.freeradius.org/pub/radius/ Le mardi 25 mai 2010 à 10:43 +0200, Bjørn Mork a écrit :
Hmm, this release doesn't seem to be tagged in the v2.1.x branch on git://git.freeradius.org/freeradius-server.git
Am I looking at the wrong repository (again)?
Bjørn
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, Alan DeKok, 2010-05-24 12:28:
* re-open log file after HUP. Closes bug #63.
Since the update to 2.1.9 a new log file is _only_ opened on HUP. Is this behaviour intended? Previously we just let logrotate rename the old logfile and freeradius created a new radius.log. I'm aware that it is not very efficient to do open/write/close all the time, but it just worked [tm]. Is the only possibility to reopen the log file now to send HUP to the server? I don't feel very comfortable with this. The server reloads the config, modules and whatnot. I think this is not something that one wants to do in a daily, unattended process. Isn't there any other, less intrusive method to tell freeradius to reopen the log file? (besides a restart, of course) Regards, Jakob
Jakob Hirsch <jh@plonk.de> writes:
Hi,
Alan DeKok, 2010-05-24 12:28:
* re-open log file after HUP. Closes bug #63.
Since the update to 2.1.9 a new log file is _only_ opened on HUP. Is this behaviour intended? Previously we just let logrotate rename the old logfile and freeradius created a new radius.log. I'm aware that it is not very efficient to do open/write/close all the time, but it just worked [tm].
Is the only possibility to reopen the log file now to send HUP to the server? I don't feel very comfortable with this. The server reloads the config, modules and whatnot. I think this is not something that one wants to do in a daily, unattended process. Isn't there any other, less intrusive method to tell freeradius to reopen the log file? (besides a restart, of course)
FWIW we have been HUPing the server from a daily, unattended process with FR 2.1.8 since it was released (we need it to rotate log files written by a private accounting module we are using). The server will only reload the modules that are explicitly marked as OK with that. And it all works very well. Bjørn
Bjørn Mork, 2010-06-17 18:28:
* re-open log file after HUP. Closes bug #63. FWIW we have been HUPing the server from a daily, unattended process with FR 2.1.8 since it was released (we need it to rotate log files
Ok. That's what we are doing now, too. After all, other daemons (apache, rsyslogd etc.) are doing the same all the time. I just wonder why there is such a change in a patch level update. And what the above mentioned bug was about...
Jakob Hirsch wrote:
I just wonder why there is such a change in a patch level update. And what the above mentioned bug was about...
The bug was that it *wasn't* re-opening the log file on HUP. Since this is expected behavior, it needed to be fixed. Alan DeKok.
On 18.06.2010 17:48, Alan DeKok wrote:
I just wonder why there is such a change in a patch level update. And what the above mentioned bug was about... The bug was that it *wasn't* re-opening the log file on HUP. Since this is expected behavior, it needed to be fixed.
But it was already re-opening the log file for every log write, obviously, so I don't see, why that was necessary.
Jakob Hirsch wrote:
But it was already re-opening the log file for every log write, obviously, so I don't see, why that was necessary.
The bug was that it wasn't re-opening the log file on HUP. That needed to be fixed. Alan DeKok.
Jakob Hirsch wrote:
Since the update to 2.1.9 a new log file is _only_ opened on HUP. Is this behaviour intended?
Yes. It's the way most daemons work.
Is the only possibility to reopen the log file now to send HUP to the server? I don't feel very comfortable with this. The server reloads the config, modules and whatnot. I think this is not something that one wants to do in a daily, unattended process. Isn't there any other, less intrusive method to tell freeradius to reopen the log file? (besides a restart, of course)
Source code patches. Alan DeKok.
participants (7)
-
Alan DeKok -
Bjørn Mork -
Dale Spittle -
Fred MAISON -
Jakob Hirsch -
Johan Meiring -
John Dennis