The server now builds without warnings on Ubuntu and Mac OSX. Our Ubuntu build server is a VM loaded with all of the libraries we can find. This means that it builds all of the modules. So the build is *really* clean. Fewer modules are build on OSX. But it's nice to know that the build is clean on multiple platforms. Alan DeKok.
On 24.06.2013 04:36, Alan DeKok wrote:
The server now builds without warnings on Ubuntu and Mac OSX.
Good news. Does this mean you'll release the first official 3.0 version ? Or do you wait some more inputs and testing ? On my side, I'll test the latest git on my dev environnement, and then I'll deploy it to our central and branch radius servers if it ran without issues on the dev. I'll report any issue encountered. Thx again for your work. Olivier -- Olivier Beytrison Network & Security Engineer, HES-SO Fribourg Mail: olivier@heliosnet.org
Hi,
Or do you wait some more inputs and testing ?
well, theres a difference between a tool compiling cleanly and it running without errors. the main issue being that a lot of people who might run it have basic configs...its only those people using a lot of the functions that will uncover more...so more people need to be running the 3.x in a more 'rigorous' environment BEFORE its released (if its released and has a hitherto unknown show stopper then confidence in 3.x will drop...it'll suffer from the same issue as other large software jumps and people will stick with 2.x alan
A.L.M.Buxey@lboro.ac.uk wrote:
well, theres a difference between a tool compiling cleanly and it running without errors.
Sure, but: - the build is clean - daily coverity scans show it's clean (barring some Coverity issues) - it has a large number of test cases which run on every push to github - many people are running v3 in production.
the main issue being that a lot of people who might run it have basic configs...its only those people using a lot of the functions that will uncover more...so more people need to be running the 3.x in a more 'rigorous' environment BEFORE its released (if its released and has a hitherto unknown show stopper then confidence in 3.x will drop...it'll suffer from the same issue as other large software jumps and people will stick with 2.x
There are a number of incompatible config changes between v2 and v3. More than there were between v1 and v2. There are more changes coming, too. But we want to release v3 now, so that the upgrade path is one of least pain. But... the similarities between v3 and v2 are more than the differences. All of the proxy config is the same. As is the virtual servers, listeners, and 75% of the module configurations. The changes are to simplify it, and make it better. i.e. v3 has less code than v2, and does more. Alan DeKok.
Hi,
- it has a large number of test cases which run on every push to github
..I was wondering how the recent 'doesnt compile' got through - and thinking about it, its because the test system has all the required libraries installed. maybe would be good to have a test system that is a basic install - and thus will fail to build things that have required libraries?
- many people are running v3 in production.
I'd like the definition of many ;-) - how many of those are doing proxying, RADSEC, using SQL with dynamic-clients and buffered-sql, decoupled-accounting etc. this is where the historic bugs appear to lurk
i.e. v3 has less code than v2, and does more.
:-) I agree...but those with established 2.x servers and not much knowledge of how things work arent going to have a nice smooth upgrade - there is no 'upgrade tool' to help make the move. What is RedHst et als view of the new major release? will we see FR3 in RHEL 7 - or in 8 or 9? (look at the slow 1.x -> 2.x transitions in most distros) certainly, in my view, FR 3.0 will be far more 'eduroam ready' out of the box than it ever was with 2.x - that'll help those admins who want to reploy this superior RADIUS solution....those that already run 2.x will have to be sold the advantages.. alan
On 24 Jun 2013, at 14:00, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
- it has a large number of test cases which run on every push to github
..I was wondering how the recent 'doesnt compile' got through - and thinking about it, its because the test system has all the required libraries installed. maybe would be good to have a test system that is a basic install - and thus will fail to build things that have required libraries?
the build matrix can't be extended to dependencies unfortunately. You have one set of dependencies for all builds.
- many people are running v3 in production.
I'd like the definition of many ;-) - how many of those are doing proxying, RADSEC, using SQL with dynamic-clients
and now LDAP with dynamic-clients :)
and buffered-sql, decoupled-accounting etc. this is where the historic bugs appear to lurk
i.e. v3 has less code than v2, and does more.
:-) I agree...but those with established 2.x servers and not much knowledge of how things work arent going to have a nice smooth upgrade - there is no 'upgrade tool' to help make the move. What is RedHst et als view of the new major release? will we see FR3 in RHEL 7 - or in 8 or 9? (look at the slow 1.x -> 2.x transitions in most distros)
certainly, in my view, FR 3.0 will be far more 'eduroam ready' out of the box than it ever was with 2.x - that'll help those admins who want to reploy this superior RADIUS solution....those that already run 2.x will have to be sold the advantages..
If they want to use RADSEC they have two options, use a gateway, or upgrade. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hi,
the build matrix can't be extended to dependencies unfortunately. You have one set of dependencies for all builds.
could you not 'fake it' by pointing the 'break?' build to random/non existant include directories so that the configure stage cant find them?
and now LDAP with dynamic-clients :)
yes...well, point made! ;-)
If they want to use RADSEC they have two options, use a gateway, or upgrade.
..and to stimulate a reply.. I'd say its currently easier to configure a 2.x system to use a gateway/proxy than it is to upgrade from 2.x to 3 to use the native capability 8-) alan
the build matrix can't be extended to dependencies unfortunately. You have one set of dependencies for all builds.
could you not 'fake it' by pointing the 'break?' build to random/non existant include directories so that the configure stage cant find them?
The problem is you can't run multiple test sets. You have one .travis.yml file it lets you specify one set of dependencies, one configure/make, and one set of test scripts. If you were allowed multiple .travis.yml files it'd be fine, but you're not.
and now LDAP with dynamic-clients :)
yes...well, point made! ;-)
Yeah, all that code needs consolidating so there's only one code path for creating new clients. Or tests... tests would be nice.
If they want to use RADSEC they have two options, use a gateway, or upgrade.
..and to stimulate a reply.. I'd say its currently easier to configure a 2.x system to use a gateway/proxy than it is to upgrade from 2.x to 3 to use the native capability 8-)
Probably. Oh well. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
A.L.M.Buxey@lboro.ac.uk wrote:
..and to stimulate a reply.. I'd say its currently easier to configure a 2.x system to use a gateway/proxy than it is to upgrade from 2.x to 3 to use the native capability 8-)
Feel free to write an automated upgrade script. :) And the rest of the functionality in 3.0 is wonderful. Colored debug output. Boot-time parsing of xlat && conditionals. Descriptive error messages. It's all very nice. Alan DeKok.
On 06/24/2013 09:00 AM, A.L.M.Buxey@lboro.ac.uk wrote:
:-) I agree...but those with established 2.x servers and not much knowledge of how things work arent going to have a nice smooth upgrade - there is no 'upgrade tool' to help make the move. What is RedHst et als view of the new major release? will we see FR3 in RHEL 7 - or in 8 or 9? (look at the slow 1.x -> 2.x transitions in most distros)
FR 3.0 in RHEL 7 depends on when FR 3.0 is officially released. Obviously we won't package a non-released version. The cut off point for RHEL 7 packages is close (sorry I can't post internal milestones). If FR 3.0 is released soon we'll work to see it gets in RHEL 7. If it doesn't meet the deadline we'll probably have 2.2 in RHEL 7 initially as the freeradius package and then add freeradius3 packages during some future RHEL 7 update, but we really would prefer not having two freeradius packages in the same RHEL release like with did with RHEL 5. Also the hurdle to get a entire new set of packages (i.e. freeradius3) into RHEL is significant which may delay which update it appears in. The short story is getting FR 3.0 in RHEL 7 to start with is the path of least resistance. The downside of rushing it with a "not ready for prime time new version" is if it's really buggy we may have to drop it from the release altogether if it seem like there will be significant support costs due to immaturity. I'll have a conversation with management concerning this and try to follow up with more specifics. Have a proposed release date would be immensely helpful. John
John Dennis wrote:
FR 3.0 in RHEL 7 depends on when FR 3.0 is officially released. Obviously we won't package a non-released version. The cut off point for RHEL 7 packages is close (sorry I can't post internal milestones). If FR 3.0 is released soon we'll work to see it gets in RHEL 7.
We'll release 3.0 next week. I don't think there any blocking issues. Alan DeKok.
FR 3.0 in RHEL 7 depends on when FR 3.0 is officially released. Obviously we won't package a non-released version. The cut off point for RHEL 7 packages is close (sorry I can't post internal milestones).
John, When FR 3.0 goes into RHEL 7, will you also make packages available for FR 3 for RHEL6/CentOS 6.x, or is that up to the CentOS maintainers? I noticed that in your FR 2.2 spec (for Fedora 17) you used a version of systemd that is not available on CentOS, so I hacked your spec back to the FR 2.1.12 version (sorry! *cringe*) for my FR 2.2 RPMs to build properly. Regards Stefan -- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
On 06/25/2013 05:06 AM, stefan.paetow@diamond.ac.uk wrote:
FR 3.0 in RHEL 7 depends on when FR 3.0 is officially released. Obviously we won't package a non-released version. The cut off point for RHEL 7 packages is close (sorry I can't post internal milestones).
John,
When FR 3.0 goes into RHEL 7, will you also make packages available for FR 3 for RHEL6/CentOS 6.x, or is that up to the CentOS maintainers?
There is no guarantee that RHEL 7 will get FR 3.0, it's a scheduling issue and the timing is very close, it's still an open question. We'll only provide FR 3.0 for RHEL 6 if there is strong customer demand. I don't follow the CentOS packages but to the best of my knowledge they've never packaged stuff which did not originate from Red Hat.
I noticed that in your FR 2.2 spec (for Fedora 17) you used a version of systemd that is not available on CentOS, so I hacked your spec back to the FR 2.1.12 version (sorry! *cringe*) for my FR 2.2 RPMs to build properly.
There are differences between our distributions which results in differences in the spec files. One either parameterizes the spec file with conditionals and share the spec file between distributions or you maintain independent spec files per distribution, there are pros and cons to both. I've moved to keeping independent spec files and merging the changes between the spec files with each FR release.
I suppose updating the Wiki would be a useful start for those changes between FR 2.x and FR 3.0 (for example, eap.conf no longer exists, its functionality has moved to the eap module). Little things that newbies (I'm one) would miss out on, would be very helpful... I was also wondering whether RHEL 7 will have FR 3 in it or whether it'll be 2.2.0 (that's what Fedora 17 has and that's where I got my FR 2.2 source from for my own FR 2.2.0 RPM spin). I definitely need to get myself a Github account so I can help more. S.
i.e. v3 has less code than v2, and does more.
:-) I agree...but those with established 2.x servers and not much knowledge of how things work arent going to have a nice smooth upgrade - there is no 'upgrade tool' to help make the move. What is RedHst et als view of the new major release? will we see FR3 in RHEL 7 - or in 8 or 9? (look at the slow 1.x -> 2.x transitions in most distros)
-- This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message. Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
On 25 Jun 2013, at 10:00, stefan.paetow@diamond.ac.uk wrote:
I suppose updating the Wiki would be a useful start for those changes between FR 2.x and FR 3.0 (for example, eap.conf no longer exists, its functionality has moved to the eap module). Little things that newbies (I'm one) would miss out on, would be very helpful...
I was also wondering whether RHEL 7 will have FR 3 in it or whether it'll be 2.2.0 (that's what Fedora 17 has and that's where I got my FR 2.2 source from for my own FR 2.2.0 RPM spin).
I definitely need to get myself a Github account so I can help more.
Well you're going to need one to push back the patches. I've applied the certs patch, seems like more sensible defaults anyway. But when you're fixing up the spec file could you add a post-install hook to cd to 'raddb/certs' and 'make'. We've removed the auto cert generation stuff from the server because it took too long, but it'd still be nice to have so EAP just works out of the box... at least for the first 60 days :) I know the debian package is OK, because it gets built as part of the travis tests. That leaves the suse package. Anyone want to have a go at that? -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On 25 Jun 2013, at 13:53, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 25 Jun 2013, at 10:00, stefan.paetow@diamond.ac.uk wrote:
I suppose updating the Wiki would be a useful start for those changes between FR 2.x and FR 3.0 (for example, eap.conf no longer exists, its functionality has moved to the eap module). Little things that newbies (I'm one) would miss out on, would be very helpful...
I was also wondering whether RHEL 7 will have FR 3 in it or whether it'll be 2.2.0 (that's what Fedora 17 has and that's where I got my FR 2.2 source from for my own FR 2.2.0 RPM spin).
I definitely need to get myself a Github account so I can help more.
Well you're going to need one to push back the patches.
I've applied the certs patch, seems like more sensible defaults anyway. But when you're fixing up the spec file could you add a post-install hook to cd to 'raddb/certs' and 'make'.
or make -C raddb/certs No volunteers for suse? :( Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On Thu, Jun 27, 2013 at 5:09 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I definitely need to get myself a Github account so I can help more.
Well you're going to need one to push back the patches.
I've applied the certs patch, seems like more sensible defaults anyway. But when you're fixing up the spec file could you add a post-install hook to cd to 'raddb/certs' and 'make'.
or make -C raddb/certs
redhat spec already calls /etc/raddb/certs/bootstrap on %post. I assume that should be enough?
No volunteers for suse? :(
I should be able to do it this weekend, so you'd probably get a pull request on monday, if that's not too late. Of course if anybody has time to spare to do it faster, feel free to jump in. -- Fajar
On 26 Jun 2013, at 23:30, Fajar A. Nugraha <list@fajar.net> wrote:
On Thu, Jun 27, 2013 at 5:09 AM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
I definitely need to get myself a Github account so I can help more.
Well you're going to need one to push back the patches.
I've applied the certs patch, seems like more sensible defaults anyway. But when you're fixing up the spec file could you add a post-install hook to cd to 'raddb/certs' and 'make'.
or make -C raddb/certs
redhat spec already calls /etc/raddb/certs/bootstrap on %post. I assume that should be enough?
I think bootstrap was duplicative of the Makefile so was removed.
No volunteers for suse? :(
I should be able to do it this weekend, so you'd probably get a pull request on monday, if that's not too late. Of course if anybody has time to spare to do it faster, feel free to jump in.
Thanks for volunteering. We'll seen when Alan wants to release. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Fajar A. Nugraha -
John Dennis -
Olivier Beytrison -
stefan.paetow＠diamond.ac.uk