Release 1.1.0 this week?
I was planning on releasing it Monday, but now Tuesday or Wednesday is looking better for me. Comments? Also, here's a list of what could be in later releases 1.1.1 - libeap fixes - netsnmp fixes 1.1.2 - upgraded libtool & autoconf?? Once that's done, the CVS head is starting to look a little anemic... Alan DeKok.
Alan DeKok wrote:
I was planning on releasing it Monday, but now Tuesday or Wednesday is looking better for me.
Comments?
Sounds good to me. The pre-release has been available for 3 weeks, so I think any major problem would have been reported already.
Also, here's a list of what could be in later releases
1.1.1 - libeap fixes - netsnmp fixes
If you look at CVS log reports, I've been playing with rlm_eap makefiles recently, and manage somehow to fix the esoteric libtool warnings for libeap. Now CVS head is building fine without RLM_EAP_LINK_MODE=-static. It'd be nice if other people can test these changes, though. For 1.1.1 we could also make a sweep over all the modules to back-port more fixes to be found in CVS head. We could also make a sweep over the bugzilla, too. And finally, if someone has a setup with ldap backend, and is volunteering to test the patch under bug #261 (ldap_pairget fixes), perhaps it could be added to 1.1.1, too. I'm not using LDAP on my site, therefore I can't test it myself easily.
1.1.2 - upgraded libtool & autoconf??
That isn't pleasant work at all, but I think it should be done. Our current autotools are the worst, and they are not supported anymore by their authors.
Once that's done, the CVS head is starting to look a little anemic...
I don't think so: there's still a lot of cool new features in the server core (IPv6 support, new radrelay, hash tables implementation to name a few of them) and a lot of new modules: rlm_policy, rlm_sqlippool, rlm_expiration, rlm_caching... -- Nicolas Baradakis
Zitat von Nicolas Baradakis <nbk@sitadelle.com>:
And finally, if someone has a setup with ldap backend, and is volunteering to test the patch under bug #261 (ldap_pairget fixes), perhaps it could be added to 1.1.1, too. I'm not using LDAP on my site, therefore I can't test it myself easily.
i have a testing installation with freeradius using ldap on which i could do some tests if necessary. unfortunatly i am not a freeradius expert, but if you tell me what i should test/try i would be glad to help! regards markus -- Markus Krause email: krause@biochem.mpg.de Computing Center Tel.: 089 - 89 40 85 99 Group Lottspeich / Proteomics Fax.: 089 - 89 40 85 98 --------------------------------------------------------------------- This message was sent using https://webmail.biochem.mpg.de If you encounter any problems please report to rz-linux@biochem.mpg.de
Markus Krause wrote:
Zitat von Nicolas Baradakis <nbk@sitadelle.com>:
And finally, if someone has a setup with ldap backend, and is volunteering to test the patch under bug #261 (ldap_pairget fixes), perhaps it could be added to 1.1.1, too. I'm not using LDAP on my site, therefore I can't test it myself easily.
i have a testing installation with freeradius using ldap on which i could do some tests if necessary. unfortunatly i am not a freeradius expert, but if you tell me what i should test/try i would be glad to help!
Thanks, that'd be useful. Here you are the detailed instructions: $ cvs -d :pserver:anoncvs@cvs.freeradius.org:/source login CVS password: anoncvs $ cvs -d :pserver:anoncvs@cvs.freeradius.org:/source checkout -r branch_1_1 radiusd $ cd radiusd $ wget 'http://bugs.freeradius.org/showattachment.cgi?attach_id=113' -O ldap_pairget.patch $ patch -p0 < ldap_pairget.patch Then recompile FreeRADIUS like usual and test with a user from your LDAP directory. If that works, the next step is to enter the test values from the bugzilla into LDAP, and verify if the RADIUS values are correct in the reply packet. See http://bugs.freeradius.org/show_bug.cgi?id=261 -- Nicolas Baradakis
Hello There are some problems building 1.1.0 on Mac OS X. I am working through the build issues and should have diffs soon. -- Steven Simon -- Senior Software Engineer -- Directory Services Group -- Apple Computer On Jan 9, 2006, at 8:30 AM, Nicolas Baradakis wrote:
Markus Krause wrote:
Zitat von Nicolas Baradakis <nbk@sitadelle.com>:
And finally, if someone has a setup with ldap backend, and is volunteering to test the patch under bug #261 (ldap_pairget fixes), perhaps it could be added to 1.1.1, too. I'm not using LDAP on my site, therefore I can't test it myself easily.
i have a testing installation with freeradius using ldap on which i could do some tests if necessary. unfortunatly i am not a freeradius expert, but if you tell me what i should test/try i would be glad to help!
Thanks, that'd be useful. Here you are the detailed instructions:
$ cvs -d :pserver:anoncvs@cvs.freeradius.org:/source login CVS password: anoncvs $ cvs -d :pserver:anoncvs@cvs.freeradius.org:/source checkout -r branch_1_1 radiusd $ cd radiusd $ wget 'http://bugs.freeradius.org/showattachment.cgi? attach_id=113' -O ldap_pairget.patch $ patch -p0 < ldap_pairget.patch
Then recompile FreeRADIUS like usual and test with a user from your LDAP directory. If that works, the next step is to enter the test values from the bugzilla into LDAP, and verify if the RADIUS values are correct in the reply packet.
See http://bugs.freeradius.org/show_bug.cgi?id=261
-- Nicolas Baradakis
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/ devel.html
Nicolas Baradakis <nbk@sitadelle.com> wrote:
If you look at CVS log reports, I've been playing with rlm_eap makefiles recently, and manage somehow to fix the esoteric libtool warnings for libeap. Now CVS head is building fine without RLM_EAP_LINK_MODE=-static. It'd be nice if other people can test these changes, though.
I had fixed *most* of that by moving the TLS stuff to libeap. But your changes fix the rest.
For 1.1.1 we could also make a sweep over all the modules to back-port more fixes to be found in CVS head. We could also make a sweep over the bugzilla, too.
I'd rather do a 1.1.x every month. That way we get lots of changes moving out the door quickly, and we don't run into the 2.0 problem of waiting forever.
I don't think so: there's still a lot of cool new features in the server core (IPv6 support, new radrelay, hash tables implementation to name a few of them) and a lot of new modules: rlm_policy, rlm_sqlippool, rlm_expiration, rlm_caching...
I know... it's just that there are a few things in the CVS head I've been avoiding that desperately need fixing. Alan DeKok.
Alan DeKok wrote:
Nicolas Baradakis <nbk@sitadelle.com> wrote:
If you look at CVS log reports, I've been playing with rlm_eap makefiles recently, and manage somehow to fix the esoteric libtool warnings for libeap. Now CVS head is building fine without RLM_EAP_LINK_MODE=-static. It'd be nice if other people can test these changes, though.
I had fixed *most* of that by moving the TLS stuff to libeap. But your changes fix the rest.
Sorry, I didn't say it correctly. You actually did all the work to fix the problem. I deleted the remaining libtool warnings and cleaned up some unused stuff. (and now the CVS head is building fine)
For 1.1.1 we could also make a sweep over all the modules to back-port more fixes to be found in CVS head. We could also make a sweep over the bugzilla, too.
I'd rather do a 1.1.x every month. That way we get lots of changes moving out the door quickly, and we don't run into the 2.0 problem of waiting forever.
Sure. That's a good idea.
I don't think so: there's still a lot of cool new features in the server core (IPv6 support, new radrelay, hash tables implementation to name a few of them) and a lot of new modules: rlm_policy, rlm_sqlippool, rlm_expiration, rlm_caching...
I know... it's just that there are a few things in the CVS head I've been avoiding that desperately need fixing.
Sorry, I misunderstood what you were saying in the first place. On other news, the last minute report for the build issues on Mac OS X (bug #310) have just been fixed. I hope this is really the *last* patch before release 1.1.0. http://bugs.freeradius.org/show_bug.cgi?id=310 -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Sorry, I didn't say it correctly. You actually did all the work to fix the problem. I deleted the remaining libtool warnings and cleaned up some unused stuff. (and now the CVS head is building fine)
Deleting crap is always a good idea.
On other news, the last minute report for the build issues on Mac OS X (bug #310) have just been fixed. I hope this is really the *last* patch before release 1.1.0.
Sounds good to me. Let's say Thursday for 1.1.0. Alan DeKok.
On Mon 09 Jan 2006 13:22, Nicolas Baradakis wrote:
Alan DeKok wrote:
I was planning on releasing it Monday, but now Tuesday or Wednesday is looking better for me.
Comments?
Sounds good to me. The pre-release has been available for 3 weeks, so I think any major problem would have been reported already.
Also, here's a list of what could be in later releases
1.1.1 - libeap fixes - netsnmp fixes
If you look at CVS log reports, I've been playing with rlm_eap makefiles recently, and manage somehow to fix the esoteric libtool warnings for libeap. Now CVS head is building fine without RLM_EAP_LINK_MODE=-static. It'd be nice if other people can test these changes, though.
For 1.1.1 we could also make a sweep over all the modules to back-port more fixes to be found in CVS head. We could also make a sweep over the bugzilla, too.
And finally, if someone has a setup with ldap backend, and is volunteering to test the patch under bug #261 (ldap_pairget fixes), perhaps it could be added to 1.1.1, too. I'm not using LDAP on my site, therefore I can't test it myself easily.
I know I have been mia for the last few months, so I can probably spare some time to test it... :-)
1.1.2 - upgraded libtool & autoconf??
That isn't pleasant work at all, but I think it should be done. Our current autotools are the worst, and they are not supported anymore by their authors.
Once that's done, the CVS head is starting to look a little anemic...
I don't think so: there's still a lot of cool new features in the server core (IPv6 support, new radrelay, hash tables implementation to name a few of them) and a lot of new modules: rlm_policy, rlm_sqlippool, rlm_expiration, rlm_caching...
What is holding up the new radrelay code from going in? It is a very cool feature for high volume deployments.. Regards -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (5)
-
Alan DeKok -
Markus Krause -
Nicolas Baradakis -
Peter Nixon -
Steven Simon