I think that the basic server functionality is looking pretty good. I'd like to release 2.0-pre0 this week, with the following TO-DO's: - fix HUP handling - fix detail file handling - minor changes to proxying for even more stability - some more documentation - add magic feature 1 - add magic feature 2 - Coverity scan before final release Comments? And no, I'm not talking about what the 2 magic features are. :) Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Sun 13 May 2007, Alan DeKok wrote:
I think that the basic server functionality is looking pretty good. I'd like to release 2.0-pre0 this week, with the following TO-DO's:
- fix HUP handling - fix detail file handling - minor changes to proxying for even more stability - some more documentation - add magic feature 1 - add magic feature 2 - Coverity scan before final release
Comments? And no, I'm not talking about what the 2 magic features are. :)
Sounds like a plan to me. My testing shows that cvs head it pretty close to stable, and it certainly has a LOT of new features compared with the current release branch. Lets get it out into the world as soon as possible :-) Note: I just applied Novell's patch to add Vasco OTP support via eDirectory also... Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon wrote:
Sounds like a plan to me. My testing shows that cvs head it pretty close to stable, and it certainly has a LOT of new features compared with the current release branch. Lets get it out into the world as soon as possible :-)
OK. Re: proxying, it currently keeps track of number of outstanding packets to each home server (i.e. sent but not responded to). It can limit the number of outstanding packets to a maximum, but it doesn't use that counter for anything else. With a few lines of code changed, the "load-balance" method will be: 1. choose home server with lowest number of outstanding packets. 2. if multiple are found with that number, randomly choose among them. This means that when a home server goes down, any requests it hasn't responded to will count against it. Almost all traffic will go to the live home servers for that load-balanced pool. And the minimum number of packets possible will be lost. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi,
Re: proxying, it currently keeps track of number of outstanding packets to each home server (i.e. sent but not responded to). It can limit the number of outstanding packets to a maximum, but it doesn't use that counter for anything else.
will it handle the load balancing of EAP to remote sites now? alan
A.L.M.Buxey@lboro.ac.uk wrote:
will it handle the load balancing of EAP to remote sites now?
Yes. See "client-balance". I'm about to add "client-port-balance", which does load-balancing by hashing source IP *and* port. It means that authentication && accounting won't go to the same home server, but the load will be spread much more evenly across home servers. If I get time, I'll add a module to track proxied requests. The idea is that you can just use "load-balance" to spread the load evenly across home servers. When a response with "state" is seen, it's put into a list for tracking. When the next request comes in with the same "state", it gets proxied to the same home server that sent the response with that "state". For various reasons, this code should probably not go into the server core. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Hi, back some time ago I was told to remind you of bug #335 for inclusion into 2.0 (it was rejected for branch_1_1 because it slightly modifies existing behaviour). So: Mind bug #335 :-) Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter wrote:
Hi,
back some time ago I was told to remind you of bug #335 for inclusion into 2.0 (it was rejected for branch_1_1 because it slightly modifies existing behaviour). So:
Mind bug #335
:-)
Stefan
And in that vein, there were patches proposed to fix handling of operaters in pair_comapare that were also pushed off. For example these are the patches I currently use to modify the operator's behavior. #! /bin/sh /usr/share/dpatch/dpatch-run ## 200-cmp-operators-fix.dpatch by <joe@nameserver3.ttec.com> ## ## All lines beginning with `## DP:' are a description of the patch. ## DP: No description. @DPATCH@ diff -urNad freeradius-1.1.0~/src/main/valuepair.c freeradius-1.1.0/src/main/valuepair.c --- freeradius-1.1.0~/src/main/valuepair.c 2005-11-06 00:40:42.000000000 -0500 +++ freeradius-1.1.0/src/main/valuepair.c 2005-11-06 00:40:46.000000000 -0500 @@ -298,8 +298,13 @@ * Didn't find it. If we were *trying* * to not find it, then we succeeded. */ - if (check_item->operator == T_OP_CMP_FALSE) - return 0; + if (check_item->operator == T_OP_CMP_FALSE || +#ifdef HAVE_REGEX_H + check_item->operator == T_OP_REG_NE || +#endif + check_item->operator == T_OP_NE + ) + continue; else return -1; } @@ -310,7 +315,10 @@ */ if (check_item->operator == T_OP_CMP_FALSE) return -1; - + + /* no comparison needed if it exists */ + if (check_item->operator == T_OP_CMP_TRUE) + continue; /* * We've got to xlat the string before doing @@ -342,14 +350,14 @@ radlog(L_INFO, "Invalid operator for item %s: " "reverting to '=='", check_item->name); /*FALLTHRU*/ - case T_OP_CMP_TRUE: /* compare always == 0 */ - case T_OP_CMP_FALSE: /* compare always == 1 */ case T_OP_CMP_EQ: if (compare != 0) result = -1; break; case T_OP_NE: - if (compare == 0) result = -1; + /* != only succeeds if NO reply values match*/ + if (compare == 0) return -1; + result = -1; /*check the rest for no match */ break; case T_OP_LT: @@ -457,7 +465,9 @@ compare = regexec(®, (char *)auth_item->vp_strvalue, 0, NULL, 0); regfree(®); - if (compare == 0) result = -1; + /* !~ only succeeds if NO matches are found in reply pair */ + if (compare == 0) return -1; + result = -1; /*check the rest for no match */ break; #endif
Stefan Winter wrote:
back some time ago I was told to remind you of bug #335 for inclusion into 2.0 (it was rejected for branch_1_1 because it slightly modifies existing behaviour). So:
We'll get it into -pre2. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
I think that the basic server functionality is looking pretty good. I'd like to release 2.0-pre0 this week, with the following TO-DO's:
- fix HUP handling - fix detail file handling - minor changes to proxying for even more stability - some more documentation - add magic feature 1 - add magic feature 2 - Coverity scan before final release
Comments? And no, I'm not talking about what the 2 magic features are. :)
I've also seen a problem with MySQL and stored procedures on the -users mailing list. I'll try to look at this when I'll have some time. (likely at the end of the week) I remember a discussion a long time ago about renaming "radiusd" to "freeradius". If we want to do it, we have a good opportunity to do it now. (before releasing a beta version) I'd also suggest to take this opportunity to clean up things a little and remove all the trailing whitespaces in the sources like done already in 2004. If you agree with this idea I can take care of it. Finally I also need to update the files under the debian/ folder. A new Debian stable version was released last month, so I can drop support for "Sarge" now. -- Nicolas Baradakis
Nicolas Baradakis wrote:
I've also seen a problem with MySQL and stored procedures on the -users mailing list. I'll try to look at this when I'll have some time. (likely at the end of the week)
Ok. Let's release 2.0-pre0, and add that patch in for -pre1.
I remember a discussion a long time ago about renaming "radiusd" to "freeradius". If we want to do it, we have a good opportunity to do it now. (before releasing a beta version)
Hmm... This means updating all of the "man" pages and documentation, including "radiusd.conf". Let's leave this for a little bit, as changing it will be a lot of work.
I'd also suggest to take this opportunity to clean up things a little and remove all the trailing whitespaces in the sources like done already in 2004. If you agree with this idea I can take care of it.
Thanks. See the Perl script in revision 1.310 of src/main/radiusd.c
Finally I also need to update the files under the debian/ folder. A new Debian stable version was released last month, so I can drop support for "Sarge" now.
OK. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
participants (8)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Alan Dekok
-
Garber, Neal -
Joe Maimon -
Nicolas Baradakis -
Peter Nixon -
Stefan Winter