We are in feature freeze for 3.0. The configuration format and behaviour for 3.0 will be stable between now and the final release (as it was with release_3_0_0_rc0). If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behavior changes you notice. To provide a single point to test against, the release_3_0_0_rc1 tag has been created. Behaviour changes since release_3_0_0_rc0: * Fixed many more compiler warnings. * LDAP schemas to load dynamic clients from LDAP * the control socket is now marked "stable" * Added RFC 6929 dictionary, along with a few others * Clean up proxy ID allocation / re-allocation * pairbasicfree() has been replaced by talloc_free() * Added %{debug_attr:LIST} to print out at attributes in LIST * The PAP module can now configurably *not* normalize passwords * Remove support for %{#}, and add %{strlen:} expansion Bug fixes: * Corrected more documentation to match the new behavior and config * Corrected many minor typos and spelling mistakes in documentation and config files * If the installation directory exists, don't re-install files * add crlDistributionPoints to certificates for Windows phones. * Use documentation IP addresses everywhere (192.0.2/24) * Build fixes for clang related to the -rdynamic flag * Allow "update" sections to update outer.reply * Re-write module handler to work, the code is significantly cleaner, and priority overrides work correctly in all cases, #404, #424 * CUI SQL fixes, #412 * Don't die in RB tree re-allocation of proxy ID * Do a second pass over pre-compiled conditions, #421, #423 * Add "delete order" to rbtree, #416 Also used by the proxy ID re-allocation code * Fixed TCP socket close handlers to be simpler and more robust * Allow ${..} expansion in `strings` * moved EAP destructors to talloc, which wasn't done in -rc0 * Fix LDAP group comparisons, and other pair comparisons * NULL terminate strings copied between VALUE_PAIRs correctly * Fix !* when used with non-string attributes * Fix `` exec in update sections * Load libpython within rlm_python to ensure all required symbols are available * Don't SEGV printing IPv6 Interface ID * Don't SEGV evaluating dates in rlm_expiration * Fix ./configure --with-shared-libs=no * Fix crashes related to opaque request data and regular expressions * Fix heimdal krb5 build The tarball is available here: https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_rc1.ta... Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
I shall try a RHEL6/CentOS6 compatible build tomorrow or Monday. Shouldn't be a problem. John D, I'll update my tag, you guys will probably do the same. Regards Stefan ________________________________________ From: freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org [freeradius-users-bounces+stefan.paetow=diamond.ac.uk@lists.freeradius.org] on behalf of Arran Cudbard-Bell [a.cudbardb@freeradius.org] Sent: Friday, September 06, 2013 4:55 PM To: FreeRadius users mailing list Subject: [ANN] Version 3.0.0-rc1 We are in feature freeze for 3.0. The configuration format and behaviour for 3.0 will be stable between now and the final release (as it was with release_3_0_0_rc0). If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behavior changes you notice. To provide a single point to test against, the release_3_0_0_rc1 tag has been created. Behaviour changes since release_3_0_0_rc0: * Fixed many more compiler warnings. * LDAP schemas to load dynamic clients from LDAP * the control socket is now marked "stable" * Added RFC 6929 dictionary, along with a few others * Clean up proxy ID allocation / re-allocation * pairbasicfree() has been replaced by talloc_free() * Added %{debug_attr:LIST} to print out at attributes in LIST * The PAP module can now configurably *not* normalize passwords * Remove support for %{#}, and add %{strlen:} expansion Bug fixes: * Corrected more documentation to match the new behavior and config * Corrected many minor typos and spelling mistakes in documentation and config files * If the installation directory exists, don't re-install files * add crlDistributionPoints to certificates for Windows phones. * Use documentation IP addresses everywhere (192.0.2/24) * Build fixes for clang related to the -rdynamic flag * Allow "update" sections to update outer.reply * Re-write module handler to work, the code is significantly cleaner, and priority overrides work correctly in all cases, #404, #424 * CUI SQL fixes, #412 * Don't die in RB tree re-allocation of proxy ID * Do a second pass over pre-compiled conditions, #421, #423 * Add "delete order" to rbtree, #416 Also used by the proxy ID re-allocation code * Fixed TCP socket close handlers to be simpler and more robust * Allow ${..} expansion in `strings` * moved EAP destructors to talloc, which wasn't done in -rc0 * Fix LDAP group comparisons, and other pair comparisons * NULL terminate strings copied between VALUE_PAIRs correctly * Fix !* when used with non-string attributes * Fix `` exec in update sections * Load libpython within rlm_python to ensure all required symbols are available * Don't SEGV printing IPv6 Interface ID * Don't SEGV evaluating dates in rlm_expiration * Fix ./configure --with-shared-libs=no * Fix crashes related to opaque request data and regular expressions * Fix heimdal krb5 build The tarball is available here: https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_rc1.ta... Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html -- 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 09/06/2013 04:31 PM, stefan.paetow@diamond.ac.uk wrote:
I shall try a RHEL6/CentOS6 compatible build tomorrow or Monday.
Shouldn't be a problem. John D, I'll update my tag, you guys will probably do the same.
FYI: rc1 is packaged and built for Fedora in rawhide (unreleased latest). At the moment the Fedora spec file is identical to what is being used to prepare for RHEL-7. The Fedora rawhide build is freeradius-3.0.0-0.4.rc1.fc21 and can be found in Koji here: http://koji.fedoraproject.org/koji/buildinfo?buildID=462883 -- John
Hi,
We are in feature freeze for 3.0. The configuration format and behaviour for 3.0 will be stable between now and the final release (as it was with release_3_0_0_rc0).
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behavior changes you notice.
To provide a single point to test against, the release_3_0_0_rc1 tag has been created.
When trying to "make install" with the custom way of avoiding raddb as suggested on the list earlier (i.e. mv raddb raddb-noinst mkdir raddb touch raddb/all.mk make install I now encounter a Makefile error: radius-int-1-new:~/freeradius-server-release_3_0_0_rc1 # make install make: *** No rule to make target `/usr/local/freeradius/config/raddb/mods-config', needed by `/usr/local/freeradius/config/raddb/mods-config/perl'. Stop. As you see, I'm not inside /usr/local/freeradius at all ... I'm in /root/freeradius-server-release_3_0_0_rc1/. The raddb folder is empty except the 0-byte all.mk. Why would it think it needs to do something for /usr/local/freeradius/config/raddb/mods-config/perl ? This is an otherwise fresh rc1. The directory above is the place where the config resides in; but it should leave that one alone, right? configure runs with the following options: ./configure --prefix=/usr/local/freeradius/3.0.0-tagged-rc1 \ --with-raddbdir=/usr/local/freeradius/config/raddb \ --with-openssl \ --with-openssl-includes=/usr/local/freeradius/openssl-1.0.1c/include \ --with-openssl-libraries=/usr/local/freeradius/openssl-1.0.1c/lib (and that's the reason it knows about /usr/local/freeradius/config/raddb at all) I believe that way to make "make install" ignore raddb used to work with rc0 and numerous GIT snapshots. Greetings, Stefan Winter
Behaviour changes since release_3_0_0_rc0: * Fixed many more compiler warnings. * LDAP schemas to load dynamic clients from LDAP * the control socket is now marked "stable" * Added RFC 6929 dictionary, along with a few others * Clean up proxy ID allocation / re-allocation * pairbasicfree() has been replaced by talloc_free() * Added %{debug_attr:LIST} to print out at attributes in LIST * The PAP module can now configurably *not* normalize passwords * Remove support for %{#}, and add %{strlen:} expansion
Bug fixes: * Corrected more documentation to match the new behavior and config * Corrected many minor typos and spelling mistakes in documentation and config files * If the installation directory exists, don't re-install files * add crlDistributionPoints to certificates for Windows phones. * Use documentation IP addresses everywhere (192.0.2/24) * Build fixes for clang related to the -rdynamic flag * Allow "update" sections to update outer.reply * Re-write module handler to work, the code is significantly cleaner, and priority overrides work correctly in all cases, #404, #424 * CUI SQL fixes, #412 * Don't die in RB tree re-allocation of proxy ID * Do a second pass over pre-compiled conditions, #421, #423 * Add "delete order" to rbtree, #416 Also used by the proxy ID re-allocation code * Fixed TCP socket close handlers to be simpler and more robust * Allow ${..} expansion in `strings` * moved EAP destructors to talloc, which wasn't done in -rc0 * Fix LDAP group comparisons, and other pair comparisons * NULL terminate strings copied between VALUE_PAIRs correctly * Fix !* when used with non-string attributes * Fix `` exec in update sections * Load libpython within rlm_python to ensure all required symbols are available * Don't SEGV printing IPv6 Interface ID * Don't SEGV evaluating dates in rlm_expiration * Fix ./configure --with-shared-libs=no * Fix crashes related to opaque request data and regular expressions * Fix heimdal krb5 build
The tarball is available here: https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_0_rc1.ta...
Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On 9 Sep 2013, at 08:44, Stefan Winter <stefan.winter@restena.lu> wrote:
Hi,
We are in feature freeze for 3.0. The configuration format and behaviour for 3.0 will be stable between now and the final release (as it was with release_3_0_0_rc0).
If you are planning on deploying 3.0 and have an existing 2.x.x configuration you were planning to migrate when the 3.0 is released, now would be a good time to try that, and to report any issues or problematic behavior changes you notice.
To provide a single point to test against, the release_3_0_0_rc1 tag has been created.
When trying to "make install" with the custom way of avoiding raddb as suggested on the list earlier (i.e.
mv raddb raddb-noinst mkdir raddb touch raddb/all.mk make install
I now encounter a Makefile error:
radius-int-1-new:~/freeradius-server-release_3_0_0_rc1 # make install make: *** No rule to make target `/usr/local/freeradius/config/raddb/mods-config', needed by `/usr/local/freeradius/config/raddb/mods-config/perl'. Stop.
Right, but this is installation so your targets will be inside the installation directory. It's missing the target to create the mods-config directory which is usually in raddb/all.mk, which in this case has been removed.
As you see, I'm not inside /usr/local/freeradius at all ... I'm in /root/freeradius-server-release_3_0_0_rc1/.
The raddb folder is empty except the 0-byte all.mk.
Why would it think it needs to do something for /usr/local/freeradius/config/raddb/mods-config/perl ?
Because that all.mk file for the rlm_perl module installs example perl scripts in mod-config, the same with rlm_python and rlm_ruby.
This is an otherwise fresh rc1. The directory above is the place where the config resides in; but it should leave that one alone, right?
configure runs with the following options:
./configure --prefix=/usr/local/freeradius/3.0.0-tagged-rc1 \ --with-raddbdir=/usr/local/freeradius/config/raddb \ --with-openssl \
--with-openssl-includes=/usr/local/freeradius/openssl-1.0.1c/include \
--with-openssl-libraries=/usr/local/freeradius/openssl-1.0.1c/lib
(and that's the reason it knows about /usr/local/freeradius/config/raddb at all)
I believe that way to make "make install" ignore raddb used to work with rc0 and numerous GIT snapshots.
I guess we'll have to come up with a proper fix. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Hi,
mv raddb raddb-noinst mkdir raddb touch raddb/all.mk make install
do 'mkdir raddb/mods-config'
you've 'messed around' with the configuration directory which assumes that mods-config exists... i guess that could be fixed to make dir directory first if it doesnt exist.
The idea is that make install is not supposed to touch my production config in any way. I don't want it to generously add directories without me knowing. It was easy to tell it to back off earlier (even easier in v2 - just mv source/raddb/ out of the way), but now for some reason the old v3-style mechanism doesn't work any more. I guess I could create the mods-config/ dir in my production config dir and it would make the symptom go away. I still found it worth reporting that some messing-around with the config dir is going on/attempted even when the source dir is told not to do that. I think I udnerstand from the earlier post that the "make install" target of rlm_perl wants to "do something" in raddb/mods-config/ on its own; and bails out when it can't. It's not nice if one module makes assumptions about a part of the directory structure it doesn't control. Nothing stops me from deploying a raddb with the configs lying in "raddb/modules-configuration-information/ and it would be very undue if the stock build process bails out on failure then during a subsequent installation. Greetings, Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
On 09/09/13 14:04, Stefan Winter wrote:
Hi,
mv raddb raddb-noinst mkdir raddb touch raddb/all.mk make install
do 'mkdir raddb/mods-config'
you've 'messed around' with the configuration directory which assumes that mods-config exists... i guess that could be fixed to make dir directory first if it doesnt exist.
The idea is that make install is not supposed to touch my production config in any way. I don't want it to generously add directories without me knowing.
I would tend to agree. Really, anything that touches raddb should only run if the top-level raddb directory doesn't exist or is completely empty.
Stefan Winter wrote:
The idea is that make install is not supposed to touch my production config in any way. I don't want it to generously add directories without me knowing.
Honestly, the simplest might be to edit Make.inc, at the top where it defines raddbdir and modconfdir: ifeq "$(raddbdir)" "" raddbdir = ${sysconfdir}/raddb modconfdir = ${sysconfdir}/raddb/mods-config endif Then, do: $ ./configure ... $ make $ make -Draddbdir=/tmp/garbage install All of the raddbdir stuff will get installed to the /tmp/garbage directory. The binaries will be built with the correct paths, and installed in the correct locations.
It was easy to tell it to back off earlier (even easier in v2 - just mv source/raddb/ out of the way), but now for some reason the old v3-style mechanism doesn't work any more.
Well... the build system has changed *completely*.
I guess I could create the mods-config/ dir in my production config dir and it would make the symptom go away.
I still found it worth reporting that some messing-around with the config dir is going on/attempted even when the source dir is told not to do that.
Because the rules for "install to config dir" are scattered through the source, and not all in raddb. So when you nuke raddb, you don't delete all of the rules.
It's not nice if one module makes assumptions about a part of the directory structure it doesn't control. Nothing stops me from deploying a raddb with the configs lying in "raddb/modules-configuration-information/ and it would be very undue if the stock build process bails out on failure then during a subsequent installation.
Well... if you want to create a non-standard configuration, it's up to you to do the work. The default install process assumes that the installation is... a default one. The customization is done via the paths at the top of the Make.inc file. If you want to change *internal* paths, then all bets are off. My only answer is "Good luck!" Alan DeKok.
On 9 Sep 2013, at 14:24, Alan DeKok <aland@deployingradius.com> wrote:
Stefan Winter wrote:
The idea is that make install is not supposed to touch my production config in any way. I don't want it to generously add directories without me knowing.
There's also: #!/bin/sh make clean if ! git pull; then exit 1; fi hash=`git log -n 1 --pretty=format:%h` ./configure -C --prefix="/usr/local/freeradius-$hash" --enable-developer make -j8 if ! sudo make install; then exit 1; fi sudo rm /usr/local/freeradius sudo ln -s "/usr/local/freeradius-$hash" /usr/local/freeradius # Bootstrap configuration directory if [ ! -d "/usr/local/etc/raddb" ]; then if [ ! -d /usr/local/etc ]; then sudo mkdir /usr/local/etc/ fi sudo cp -ra /usr/local/freeradius-$hash/etc/raddb /usr/local/etc/ fi sudo rm -rf /usr/local/freeradius/etc/raddb sudo ln -s /usr/local/etc/raddb /usr/local/freeradius/etc/raddb sudo service radiusd restart Which is what I use to deploy GIT versions on production servers. It allows you to quickly fail back to a previous version if there are issues. This negates problems caused by installing over the top of a previous installation, which IMHO is always an extremely bad idea with any unpackaged software. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
On Mon, Sep 09, 2013 at 03:18:06PM +0100, Arran Cudbard-Bell wrote:
This negates problems caused by installing over the top of a previous installation, which IMHO is always an extremely bad idea with any unpackaged software.
...or even packaged software. FWIW, I put all freeradius config in /srv/radius, and then /etc/default/freeradius sets the daemon option '-d /srv/radius'. Even with Debian's pretty good system of not overwriting config files, I want to a) guarantee that my config never gets touched, and b) not have to be asked about changed config files at package upgrade time. Moving my config to a different location solves that entirely. It also means that I have a reference raddb in the standard location, so I can refer to it. My config is mostly stripped of comments for brevity (and my sanity). The reference config has them all in. I can't personally see why anyone would 'make install' on top of a working config on a server and trust the install to not touch any local changes. Even if I'm 99.99% sure it won't, I'd be too worried to do it when there's an easy alternative. But I guess some are just more adventurous than me! :) Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Hi,
Because that all.mk file for the rlm_perl module installs example perl scripts in mod-config, the same with rlm_python and rlm_ruby.
I guess we'll have to come up with a proper fix.
Does the file need to be created by the rlm's "make install"? The example scripts could be put into source/raddb/mods-config, and installed from raddb's own part of "make install". That way, if I move raddb out of the way, nothing bad will happen; both the current content of raddb and all the script examples will be ignored. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
participants (8)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
John Dennis -
Matthew Newton -
Phil Mayers -
Stefan Winter -
stefan.paetow＠diamond.ac.uk