Pending release of 2.1.9
I've put pre releases of 2.1.9 on the web: http://git.freeradius.org/pre/ Please try them, and note any issues. If there aren't problems, we can release 2.1.9 real soon now. Alan DeKok.
On 05/13/2010 06:57 AM, Alan DeKok wrote:
I've put pre releases of 2.1.9 on the web:
http://git.freeradius.org/pre/
Please try them, and note any issues. If there aren't problems, we can release 2.1.9 real soon now.
Thank you for your hard work Alan! I'd like to thank you and everyone who worked on this for their contributions to the open source community. We all owe you a debt of gratitude. As to 2.1.9 ... It passes basic sanity checking. It builds, installs, and runs. I have tested with radtest and with each of the eapol_test scripts. I do not have a stress testing environment, I think others do and it would be good to hear from them. The Changelog notes several feature additions. I thought this was a bug fix update only. In fairness some of the feature additions were in the area of documentation, that's great and I don't have a problem with features which do not change code and make it easier for users to use. But shouldn't the other features have been reserved for the 2.2.x branch and limit 2.1.9 to only bug fixes? The one bug I was most concerned about I don't see specifically called out and I'm wondering what the disposition of that was. Sorry, but I'm going to be a little vague rather than citing a bug number. There was a problem reported by several people that resulted in a server crash and only seemed to appear under high load conditions after the server was up for a while. Alan said he was having a hard time reproducing it, that logically it seemed impossible from static code inspection, but acknowledged it was real because it had been reported often enough. Does that ring a bell? Does this update address that issue? -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
It passes basic sanity checking. It builds, installs, and runs. I have tested with radtest and with each of the eapol_test scripts. I do not have a stress testing environment, I think others do and it would be good to hear from them.
OK.
The Changelog notes several feature additions. I thought this was a bug fix update only. In fairness some of the feature additions were in the area of documentation, that's great and I don't have a problem with features which do not change code and make it easier for users to use. But shouldn't the other features have been reserved for the 2.2.x branch and limit 2.1.9 to only bug fixes?
The features are: - show stats for detail files Arguably a bug that it wasn't there originally. Added because people ran into problems where they couldn't see what was going on with a detail file The control socket isn't enabled in the default install, either. - documentation - better DHCP Option 82 support Arguably a bug: DHCP servers need Option 82 support. This affects only people who use DHCP. (i.e. not many) - enabled "server" in NAS table arguably a bug that it wasn't there a year ago. Only affects *new* installations who use SQL. For me, all of these fall into the "arguably a bug fix" area. There are no major code changes, and will not affect existing systems.
The one bug I was most concerned about I don't see specifically called out and I'm wondering what the disposition of that was. Sorry, but I'm going to be a little vague rather than citing a bug number. There was a problem reported by several people that resulted in a server crash and only seemed to appear under high load conditions after the server was up for a while. Alan said he was having a hard time reproducing it, that logically it seemed impossible from static code inspection, but acknowledged it was real because it had been reported often enough. Does that ring a bell? Does this update address that issue?
Yes. Bug #35. There's a work-around which should help. I've run *billions* of packets through the server on the same machine as people who claim to have problems. I've been unable to reproduce the issue. Alan DeKok.
On 2010/05/13 12:57 PM, Alan DeKok wrote:
I've put pre releases of 2.1.9 on the web:
http://git.freeradius.org/pre/
Please try them, and note any issues. If there aren't problems, we can release 2.1.9 real soon now.
Builds fine on debian lenny using dpkg-buildpackage There is a log of warnings though. Small subset says this..... ----------------------------------------------------- dpkg-shlibdeps: warning: symbol radlog used by debian/freeradius/usr/lib/freeradius/rlm_checkval-2.1.9.so found in none of the libraries. dpkg-shlibdeps: warning: symbol cf_section_parse used by debian/freeradius/usr/lib/freeradius/rlm_checkval-2.1.9.so found in none of the libraries. dpkg-shlibdeps: warning: symbol debug_flag used by debian/freeradius/usr/lib/freeradius/rlm_checkval-2.1.9.so found in none of the libraries. dpkg-shlibdeps: warning: symbol rad_malloc used by debian/freeradius/usr/lib/freeradius/rlm_checkval-2.1.9.so found in none of the libraries. dpkg-shlibdeps: warning: symbol log_debug used by debian/freeradius/usr/lib/freeradius/rlm_checkval-2.1.9.so found in none of the libraries. ----------------------------------------------------- The warnings above also happen for other modules. rlm_mysql rlm_pam rlm_dbm etc...... After building I end up with various packages. freeradius-common freeradius-mysql etc.... When building previous versions (tried 2.1.7), the "packages" were different. freeradius (note - no "-common") freeradius-mysql etc.... I realise the official debian packages has a "freeradius" and a "freeradius-common", but the debian packages built from source never had a "-common". When installing 2.1.9, I installed the "-common" instead of the non "-common" one. When trying to install freeradius-mysql afterwards, it complained about not finding dependency "freeradius" (without -common). There is something "wrong" with the package names. Also, the version in debian/changelog still contains "git". Hope that helps. -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
On Thu, May 13, 2010 at 06:52:28PM +0200, Johan Meiring wrote:
After building I end up with various packages.
freeradius-common freeradius-mysql etc....
When building previous versions (tried 2.1.7), the "packages" were different. freeradius (note - no "-common") freeradius-mysql etc....
I realise the official debian packages has a "freeradius" and a "freeradius-common", but the debian packages built from source never had a "-common".
When installing 2.1.9, I installed the "-common" instead of the non "-common" one. When trying to install freeradius-mysql afterwards, it complained about not finding dependency "freeradius" (without -common).
There is something "wrong" with the package names.
This was already changed in 2.1.8, actually. Simply install *both* packages, like the dependencies tell you to... -- 2. That which causes joy or happiness.
On 2010/05/13 07:16 PM, Josip Rodin wrote:
Simply install *both* packages, like the dependencies tell you to...
OOPS... Idiot mode. I didn't look properly. The one without "-common" *does* exist. Apologies for time wasting...... -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
Johan Meiring wrote:
There is a log of warnings though. Small subset says this..... ----------------------------------------------------- dpkg-shlibdeps: warning: symbol radlog used by debian/freeradius/usr/lib/freeradius/rlm_checkval-2.1.9.so found in none of the libraries.
It's in the server core. There's no "libfreeradius-server.so", though perhaps there could be. In any case, the warnings are minor. Alan DeKok.
On 2010/05/14 07:46 AM, Alan DeKok wrote:
Johan Meiring wrote:
There is a log of warnings though. Small subset says this..... ----------------------------------------------------- dpkg-shlibdeps: warning: symbol radlog used by debian/freeradius/usr/lib/freeradius/rlm_checkval-2.1.9.so found in none of the libraries.
It's in the server core. There's no "libfreeradius-server.so", though perhaps there could be.
In any case, the warnings are minor.
Cool. I compiled the server and can confirm it runs ok on my develepment machine. On another note, every time a new release comes out, I manually add rlm_raw and recompile. I updated rlm_raw to work with FR2 a while ago and have been running it successfully in production for about a year. Any chance of getting it into the 2_1_0 branch? Patch attached. -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
Johan Meiring wrote:
I compiled the server and can confirm it runs ok on my develepment machine.
OK.
On another note, every time a new release comes out, I manually add rlm_raw and recompile.
I updated rlm_raw to work with FR2 a while ago and have been running it successfully in production for about a year.
Any chance of getting it into the 2_1_0 branch?
I have no idea what the module does. The modules are run *only* after the packet has been received, and decoded. Any dynamic expansion is done *only* when the packet has been received and decoded. So the module does nothing more than what the server already does: decode attributes. The "dynamic clients' code runs modules before the packet is decoded... but that's only because it doesn't *receive* the packet. So any "raw" access to the packet will return nothing. What are you doing with the module? I can't for the life of me see why it would be useful in *any* situation. Alan DeKok.
On 2010/05/14 10:35 AM, Alan DeKok wrote:
Johan Meiring wrote:
The "dynamic clients' code runs modules before the packet is decoded... but that's only because it doesn't *receive* the packet. So any "raw" access to the packet will return nothing.
What are you doing with the module? I can't for the life of me see why it would be useful in *any* situation.
Its dynamic clients. I use it inside dynamic clients to look up the client via the Nas-Identifier. My clients don't have fixed IPs. The only way to give different Nas's different shared secrets is by doing this. You made a modification to dynamic clients a while ago where you could get hold of the whole packet inside dynamic clients. Dont know if you remember this. You sent a mail to me about it on Wed, 27 May 2009 14:05:31 +0200 ============================SNIP=================================== I've made some changes in revision control that should help you. The "dynamic client" virtual server will now receive the *full* RADIUS packet. Before, it was impossible to look at the contents. You will *still* need to use the "rlm_raw" module to look at the raw packet contents. The contents are *not* decoded into attributes, as happens when receiving normal packets. See http://git.freeradius.org/pre for a tar file that contains the code changes. You will need to add rlm_raw to the build. But after that, something like the following should work: authorize { ... if ("%{raw:NAS-Identifier}" == "foo") { ... } ... } ============================SNIP=================================== It is definately usefull to me! -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
On 2010/05/14 11:08 AM, Johan Meiring wrote:
Its dynamic clients.
Alan, I just saw you were cc-ed on the mail sent to this list. Not intentional. I know you hate it. I always use "reply-to-all" as a habit. It then replied to you as well. Apologies.... -- Johan Meiring Cape PC Services CC Tel: (021) 883-8271 Fax: (021) 886-7782
Johan Meiring wrote:
You made a modification to dynamic clients a while ago where you could get hold of the whole packet inside dynamic clients.
Ah... yes. The rlm_raw won't go into 2.1.x. It's a new feature, and doesn't belong there. I'm not sure it will go into 2.2.x, either. It's only use is to work around some limitations in the server core. It would be better to fix the server core. I've been hesitant to do that for 2.1.x, because it's a stable series. For 2.2.0, there's more possibility for changes. Alan DeKok.
participants (4)
-
Alan DeKok -
Johan Meiring -
John Dennis -
Josip Rodin