Hi Guys Does anyone know why "--prefix=/" not longer works as expected when fed to configure in the 1.1.x cvs branch? No matter what I do radiusd keeps looking for /usr/local/etc/raddb and I have been forced to symlink it to /etc/raddb is my latest rpms.. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
Does anyone know why "--prefix=3D/" not longer works as expected when fed to configure in the 1.1.x cvs branch?
Nope. That makes me happy that I've been holding off on 1.1.3. I'll take a look. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Thu 10 Aug 2006 20:51, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Does anyone know why "--prefix=3D/" not longer works as expected when fed to configure in the 1.1.x cvs branch?
Nope. That makes me happy that I've been holding off on 1.1.3.
I'll take a look.
OK. As this thread has continued on quite a bit, I am going to summarise it for everyone. --prefix does appear to work as expected and for most people should be specified as --prefix=/usr However, raddb does NOT end up in the expected location, and even adding "--with-raddbdir=/etc/raddb" to configure (which in any case was previously not necessary) does not make it end up where it should. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Wed, Aug 16, 2006 at 06:46:39PM +0300, Peter Nixon said:
On Thu 10 Aug 2006 20:51, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Does anyone know why "--prefix=3D/" not longer works as expected when fed to configure in the 1.1.x cvs branch?
Nope. That makes me happy that I've been holding off on 1.1.3.
I'll take a look.
OK. As this thread has continued on quite a bit, I am going to summarise it for everyone.
--prefix does appear to work as expected and for most people should be specified as --prefix=/usr
However, raddb does NOT end up in the expected location, and even adding "--with-raddbdir=/etc/raddb" to configure (which in any case was previously not necessary) does not make it end up where it should.
Odd, it does here. No, wait - I think I see a problem. If I run ./configure --prefix='/usr' --with-raddbdir=/etc/raddb make make install R=`pwd`foo I get everything working as normal (well, I get an error that it can't find /etc/raddb/radiusd.conf, but that's what I was looking for) If I then run ./configure --prefix='/usr' --with-raddbdir=/etc/freeradius make make install R=`pwd`foo Nothing gets rebuilt, and it still looks for radiusd.conf in the old location. I am not sure what to do about this, besides making sure I run clean in between rebuilds. I think that the right way would be #define RADDBDIR '/etc/raddb' (and other configure arguments like this) in acconfig.h, and then set make file targets accordingly. That way make will know to rebuild radiusd if this file changes. I understand the problem of expansions with #define'ing these sorts of things (you end up with ${prefix}/${argument} and so on), but I think I may have an autoconf macro around that does a couple of expansions, so that you should end up wioh a real path at the end, if people are interested. -- -------------------------------------------------------------------------- | Stephen Gran | Time as he grows old teaches all | | steve@lobefin.net | things. -- Aeschylus | | http://www.lobefin.net/~steve | | --------------------------------------------------------------------------
Stephen Gran wrote:
No, wait - I think I see a problem. If I run ./configure --prefix='/usr' --with-raddbdir=/etc/raddb make make install R=`pwd`foo
I get everything working as normal (well, I get an error that it can't find /etc/raddb/radiusd.conf, but that's what I was looking for)
If I then run ./configure --prefix='/usr' --with-raddbdir=/etc/freeradius make make install R=`pwd`foo
Nothing gets rebuilt, and it still looks for radiusd.conf in the old location. I am not sure what to do about this, besides making sure I run clean in between rebuilds.
Thanks for the report. I see indeed a bug when you don't run "make distclean" between two builds with different configure options. The file src/include/radpaths.h contains the pathnames of the previous build. The following patch should fix the problem: Index: src/include/Makefile =================================================================== RCS file: /source/radiusd/src/include/Makefile,v retrieving revision 1.2 diff -u -r1.2 Makefile --- src/include/Makefile 15 Jul 2003 12:34:51 -0000 1.2 +++ src/include/Makefile 16 Aug 2006 18:09:37 -0000 @@ -10,7 +10,7 @@ all: radpaths.h -radpaths.h: +radpaths.h: build-radpaths-h @/bin/sh ./build-radpaths-h -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Thanks for the report. I see indeed a bug when you don't run "make distclean" between two builds with different configure options. The file src/include/radpaths.h contains the pathnames of the previous build.
The following patch should fix the problem:
Looks good to me. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Peter Nixon wrote:
As this thread has continued on quite a bit, I am going to summarise it for everyone.
--prefix does appear to work as expected and for most people should be specified as --prefix=/usr
However, raddb does NOT end up in the expected location, and even adding "--with-raddbdir=/etc/raddb" to configure (which in any case was previously not necessary) does not make it end up where it should.
Peter, if you happen to have some time, please do a "cvs update" and test again. (you shouldn't need the option --with-raddbdir anymore in the spec file) -- Nicolas Baradakis
On Thu 17 Aug 2006 15:59, Nicolas Baradakis wrote:
Peter Nixon wrote:
As this thread has continued on quite a bit, I am going to summarise it for everyone.
--prefix does appear to work as expected and for most people should be specified as --prefix=/usr
However, raddb does NOT end up in the expected location, and even adding "--with-raddbdir=/etc/raddb" to configure (which in any case was previously not necessary) does not make it end up where it should.
Peter, if you happen to have some time, please do a "cvs update" and test again. (you shouldn't need the option --with-raddbdir anymore in the spec file)
Thanks. It appears to be fixed now. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
Thanks. It appears to be fixed now.
Any objections to 1.1.3? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Fri 18 Aug 2006 00:11, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Thanks. It appears to be fixed now.
Any objections to 1.1.3?
Seems good to go. A snapshot from last night has been running in production for about 8 hours and no problems so far. I say go ahead. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Thanks. It appears to be fixed now.
Any objections to 1.1.3?
I've seen so far 2 cases where 1.1.2 has build errors, and where the autotools upgrade in 1.1.3 fixes the problem: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380204 http://lists.freeradius.org/pipermail/freeradius-users/2006-August/055320.ht... However, I didn't heard any report whether the changes to redhat/freeradius.spec fix the errors in rpmbuild. (this is something I can't test on a Debian system) -- Nicolas Baradakis
On Fri 18 Aug 2006 11:58, Nicolas Baradakis wrote:
Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Thanks. It appears to be fixed now.
Any objections to 1.1.3?
I've seen so far 2 cases where 1.1.2 has build errors, and where the autotools upgrade in 1.1.3 fixes the problem:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380204
http://lists.freeradius.org/pipermail/freeradius-users/2006-August/055320.h tml
However, I didn't heard any report whether the changes to redhat/freeradius.spec fix the errors in rpmbuild. (this is something I can't test on a Debian system)
Also, building 1.1.2 on the opensuse build service (fakeroot etc) generated no modules at all. It works perfectly with 1.1.x cvs branch however. I would like to see 1.1.3 out the door asap as I don't think it's any worse than 1.1.2 and does fix a number of problems. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
Also, building 1.1.2 on the opensuse build service (fakeroot etc) generated no modules at all. It works perfectly with 1.1.x cvs branch however. I would like to see 1.1.3 out the door asap as I don't think it's any worse than 1.1.2 and does fix a number of problems.
Ok. Monday. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
"Gabriel L. Somlo" <somlo@cmu.edu> wrote:
How about the one-liner fix for rlm_dbm_parser (bugzilla #380) ?
Probably a good idea, too. I'll look at it. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Sat 19 Aug 2006 01:14, Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Also, building 1.1.2 on the opensuse build service (fakeroot etc) generated no modules at all. It works perfectly with 1.1.x cvs branch however. I would like to see 1.1.3 out the door asap as I don't think it's any worse than 1.1.2 and does fix a number of problems.
Ok. Monday.
Any chance of releasing a tar.bz2 as well/instead of the tar.gz bzip2 seems to be ubiquitous these days and is the recommended format to use when building rpms for most distros. Regards -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Peter Nixon <listuser@peternixon.net> wrote:
Any chance of releasing a tar.bz2 as well/instead of the tar.gz bzip2 seems to be ubiquitous these days and is the recommended format to use when building rpms for most distros.
Sure. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Any chance of releasing a tar.bz2 as well/instead of the tar.gz bzip2 seems to be ubiquitous these days and is the recommended format to use when building rpms for most distros.http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/
On other issues for 1.1.3: 1) Browsing the CVS tree doesn't work anymore: Internal Server Error http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/ 2) The last days I looked at EAP/TLS and the cert_issuer_check, there is a corresponding free() call missing in rlm_eap_tls.c:eaptls_detach(). Hmmm. On a closer look, actually many of the module's module_config string or file name options are missing. Correct or bug? I think I patched most of them for my certificate "dissection" patch, shall I make a quick interim patch of only the eap_detach() part against CVS? 3) It would be nice to apply my patch against the miscalculated EAP/TLS packet size (bug 383) 8-) Regards, Michael Joosten
Michael Joosten wrote:
2) The last days I looked at EAP/TLS and the cert_issuer_check, there is a corresponding free() call missing in rlm_eap_tls.c:eaptls_detach(). Hmmm. On a closer look, actually many of the module's module_config string or file name options are missing. Correct or bug? I think I patched most of them for my certificate "dissection" patch, shall I make a quick interim patch of only the eap_detach() part against CVS?
Done. Bug 385
3) It would be nice to apply my patch against the miscalculated EAP/TLS packet size (bug 383) 8-)
Regards, Michael Joosten
Also attached. Made against 1.1.1, but I don't that matters. Michael --- radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c- 2006-04-28 20:21:49.000000000 +0200 +++ radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c 2006-08-22 16:53:29.000000000 +0200 @@ -449,15 +449,27 @@ if (conf) { if (conf->dh_file) free(conf->dh_file); conf->dh_file = NULL; + if (conf->CA_path) free(conf->CA_path); + conf->CA_path = NULL; if (conf->certificate_file) free(conf->certificate_file); conf->certificate_file = NULL; if (conf->private_key_file) free(conf->private_key_file); conf->private_key_file = NULL; if (conf->private_key_password) free(conf->private_key_password); conf->private_key_password = NULL; + if (conf->CA_file) free(conf->CA_file); + conf->CA_file = NULL; if (conf->random_file) free(conf->random_file); conf->random_file = NULL; + if (conf->check_cert_cn) free(conf->check_cert_cn); + conf->check_cert_cn = NULL; + if (conf->use_as_cert_cn) free(conf->use_as_cert_cn); + conf->check_cipher_list = NULL; + if (conf->check_cipher_list) free(conf->check_cipher_list); + conf->check_cipher_list = NULL; + if (conf->check_cert_issuer) free(conf->check_cert_issuer); + conf->check_cert_issuer = NULL; free(inst->conf); inst->conf = NULL; } diff -ru ../orig/freeradius-1.1.1/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c ./src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c --- ../orig/freeradius-1.1.1/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c 2006-02-06 10:37:03.000000000 -0500 +++ ./src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c 2006-04-21 19:45:47.000000000 -0400 @@ -443,11 +459,25 @@ * tells us it's too big. */ ssn->offset = inst->conf->fragment_size; + + /* + * Framed-MTU is the whole packet, so we cut off the + * EAPOW header (4 bytes) to be prepended by the NAS. + * NOTE: This does not account for other protocols and + * purposes like wired PPP, which has 8 bytes overhead. + */ vp = pairfind(handler->request->packet->vps, PW_FRAMED_MTU); if (vp && ((vp->lvalue - 4) < ssn->offset)) { ssn->offset = vp->lvalue - 4; } + /* + * And even more for the EAP TLS header: + * code + id + length + type + flags + TLS len + * 1 + 1 + 2 + 1 + 1 + 4 = 10 + */ + ssn->offset -= 10; + handler->opaque = ((void *)ssn); handler->free_opaque = session_free;
Michael Joosten <michael.joosten@c-lab.de> wrote:
Done. Bug 385 ... Also attached. Made against 1.1.1, but I don't that matters.
Did you try compiling it? There are a bunch of typos, e.g. ca_path, not CA_PATH. I've edited it, and committed the fixes. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Michael Joosten <michael.joosten@c-lab.de> wrote:
Done. Bug 385
...
Also attached. Made against 1.1.1, but I don't that matters.
Did you try compiling it? There are a bunch of typos, e.g. ca_path, not CA_PATH.
I've edited it, and committed the fixes.
Sorry, looked just at the labels, not the struct field names. Just made my own correction, if you want to compare: Michael --- radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c- 2006-04-28 20:21:49.000000000 +0200 +++ radiusd/src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c 2006-08-22 18:20:08.000000000 +0200 @@ -449,15 +449,25 @@ if (conf) { if (conf->dh_file) free(conf->dh_file); conf->dh_file = NULL; + if (conf->ca_path) free(conf->ca_path); + conf->ca_path = NULL; if (conf->certificate_file) free(conf->certificate_file); conf->certificate_file = NULL; if (conf->private_key_file) free(conf->private_key_file); conf->private_key_file = NULL; if (conf->private_key_password) free(conf->private_key_password); conf->private_key_password = NULL; + if (conf->ca_file) free(conf->ca_file); + conf->ca_file = NULL; if (conf->random_file) free(conf->random_file); conf->random_file = NULL; + if (conf->check_cert_cn) free(conf->check_cert_cn); + conf->check_cert_cn = NULL; + if (conf->cipher_list) free(conf->cipher_list); + conf->cipher_list = NULL; + if (conf->check_cert_issuer) free(conf->check_cert_issuer); + conf->check_cert_issuer = NULL; free(inst->conf); inst->conf = NULL; }
Michael Joosten <michael.joosten@c-lab.de> wrote:
1) Browsing the CVS tree doesn't work anymore: Internal Server Error http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/
Too many stupid robots attacking it.
2) The last days I looked at EAP/TLS and the cert_issuer_check, there is a corresponding free() call missing in rlm_eap_tls.c:eaptls_detach().
Fixed.
3) It would be nice to apply my patch against the miscalculated EAP/TLS packet size (bug 383) 8-)
Fixed. In the CVS head, the "fragment_size" should be re-named to "mtu", because it's not reasonable to expect that the local administrator knows enough about the internals of EAP & EAP-TLS in order to properly calculate the TLS fragment size. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Tue, 2006-08-22 at 12:20 -0400, Alan DeKok wrote:
Michael Joosten <michael.joosten@c-lab.de> wrote:
1) Browsing the CVS tree doesn't work anymore: Internal Server Error http://www.freeradius.org/cgi-bin/cvsweb.cgi/radiusd/
Too many stupid robots attacking it.
Maybe it would be reasonable to set up authorization based on subscription e-mail/password? Then at least subscribed users could use it... -- Fduch M. Pravking
"Alexander M. Pravking" <fduch@antar.bryansk.ru> wrote:
Maybe it would be reasonable to set up authorization based on subscription e-mail/password? Then at least subscribed users could use it...
The lists aren't tied to the rest of the systems. It's easier just to turn cvsweb off. There's very little value in it, given that we have anonymous cvs access. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
It's easier just to turn cvsweb off. There's very little value in it, given that we have anonymous cvs access.
Sometimes I was using it... Perhaps we could protect the cvsweb directory with a simple .htaccess asking the user to enter "cvs/cvs" as username and password. It's easy to set up and it should be enough to block the robots. -- Nicolas Baradakis
Nicolas Baradakis <nbk@sitadelle.com> wrote:
Perhaps we could protect the cvsweb directory with a simple .htaccess asking the user to enter "cvs/cvs" as username and password. It's easy to set up and it should be enough to block the robots.
Sure. I'm in the process of moving the main www page to another machine, and we can do more then. Including giving people email accounts @freeradius.org, if that's cool. :) Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
Alan DeKok wrote:
Peter Nixon <listuser@peternixon.net> wrote:
Thanks. It appears to be fixed now.
Any objections to 1.1.3?
Alan, I'm sure this is way low on your list, but I would love to see the patch in bug 381 make it into this release or perhaps the next one. It passes though the Nas-Identifier attribute when doing session_zap which is great for people that make logging decisions on this attribute. Thanks, schu
On August 10, 2006 1:51:56 PM +0300 Peter Nixon <listuser@peternixon.net> wrote:
Hi Guys
Does anyone know why "--prefix=/" not longer works as expected when fed to configure in the 1.1.x cvs branch?
Shouldn't that be --prefix=/usr ? Maybe '/' is discarded as an invalid prefix. -frank
On Thu 10 Aug 2006 23:19, Frank Cusack wrote:
On August 10, 2006 1:51:56 PM +0300 Peter Nixon <listuser@peternixon.net> wrote:
Hi Guys
Does anyone know why "--prefix=/" not longer works as expected when fed to configure in the 1.1.x cvs branch?
Shouldn't that be --prefix=/usr ? Maybe '/' is discarded as an invalid prefix.
OK. After some more testing it is not --prefix which is broken. It works as expected. However it is now required to pass "--with-raddbdir=/etc/raddb" which was not necessary previously to get things to go in the expected place. There does appear to be something still a bit broken on 64bit though. I am using "--libdir=%{_libdir}/freeradius" which as expected builds and installs into /usr/lib64/freeradius/ on 64bit platforms and /usr/lib/freeradius/ on 32bit platforms. However when running radiusd -X on a 64bit install the following happens: Module: Library search path is /usr/lib/freeradius radiusd.conf[1538] Failed to link to module 'rlm_exec': rlm_exec.so: cannot open shared object file: No such file or directory Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On August 15, 2006 7:12:39 PM +0300 Peter Nixon <listuser@peternixon.net> wrote:
On Thu 10 Aug 2006 23:19, Frank Cusack wrote:
On August 10, 2006 1:51:56 PM +0300 Peter Nixon <listuser@peternixon.net> wrote:
Hi Guys
Does anyone know why "--prefix=/" not longer works as expected when fed to configure in the 1.1.x cvs branch?
Shouldn't that be --prefix=/usr ? Maybe '/' is discarded as an invalid prefix.
OK. After some more testing it is not --prefix which is broken. It works as expected. However it is now required to pass "--with-raddbdir=/etc/raddb" which was not necessary previously to get things to go in the expected place.
Is that acceptable?
There does appear to be something still a bit broken on 64bit though. I am using "--libdir=%{_libdir}/freeradius" which as expected builds and installs into /usr/lib64/freeradius/ on 64bit platforms and /usr/lib/freeradius/ on 32bit platforms. However when running radiusd -X on a 64bit install the following happens:
Module: Library search path is /usr/lib/freeradius radiusd.conf[1538] Failed to link to module 'rlm_exec': rlm_exec.so: cannot open shared object file: No such file or directory
Can you verify this with a "manual" build instead of rpm? It works correctly here. I hate to ask, but are you sure you are running the radiusd you just built and installed? If all that checks out, it would be interesting to see one of the installed .la files. -frank
On Wed 16 Aug 2006 05:16, Frank Cusack wrote:
On August 15, 2006 7:12:39 PM +0300 Peter Nixon <listuser@peternixon.net> wrote:
On Thu 10 Aug 2006 23:19, Frank Cusack wrote:
On August 10, 2006 1:51:56 PM +0300 Peter Nixon <listuser@peternixon.net>
wrote:
Hi Guys
Does anyone know why "--prefix=/" not longer works as expected when fed to configure in the 1.1.x cvs branch?
Shouldn't that be --prefix=/usr ? Maybe '/' is discarded as an invalid prefix.
OK. After some more testing it is not --prefix which is broken. It works as expected. However it is now required to pass "--with-raddbdir=/etc/raddb" which was not necessary previously to get things to go in the expected place.
Is that acceptable?
There does appear to be something still a bit broken on 64bit though. I am using "--libdir=%{_libdir}/freeradius" which as expected builds and installs into /usr/lib64/freeradius/ on 64bit platforms and /usr/lib/freeradius/ on 32bit platforms. However when running radiusd -X on a 64bit install the following happens:
Module: Library search path is /usr/lib/freeradius radiusd.conf[1538] Failed to link to module 'rlm_exec': rlm_exec.so: cannot open shared object file: No such file or directory
Can you verify this with a "manual" build instead of rpm?
OK. I will setup a sacrificial VM later today to test it.
It works correctly here. I hate to ask, but are you sure you are running the radiusd you just built and installed?
Yep. Very sure. Our policy is to only ever install from rpm. We have no machine running "compiled from source" freeradius, and the rpms themselves are built on the opensuse buildservice. It is precisely so I don't have problems with old libs/binaries that I enforce this policy. (That and I can always easily roll back to an older version if I have problems)
If all that checks out, it would be interesting to see one of the installed .la files.
http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10.0/x86_6... http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10.0/x86_6... -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On August 16, 2006 9:51:36 AM +0300 Peter Nixon <listuser@peternixon.net> wrote:
http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10.0/x86_6... -20060808-14.1.x86_64.rpm http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10.0/x86_6... -devel-20060808-14.1.x86_64.rpm
Is a build log available?
On Wed 16 Aug 2006 09:55, Frank Cusack wrote:
On August 16, 2006 9:51:36 AM +0300 Peter Nixon <listuser@peternixon.net> wrote:
http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10.0/x8 6_64/freeradius-snapshot -20060808-14.1.x86_64.rpm http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10.0/x8 6_64/freeradius-snapshot -devel-20060808-14.1.x86_64.rpm
Is a build log available?
I have already clobbered it by attempting new builds, but I will reset my spec file and do it again. Give me 45min (The buildservice is a bit slow during business hours) Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
Hi,
On Wed 16 Aug 2006 09:55, Frank Cusack wrote:
On August 16, 2006 9:51:36 AM +0300 Peter Nixon <listuser@peternixon.net> wrote:
http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10.0/x8 6_64/freeradius-snapshot -20060808-14.1.x86_64.rpm http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10.0/x8 6_64/freeradius-snapshot -devel-20060808-14.1.x86_64.rpm
Is a build log available?
I have already clobbered it by attempting new builds, but I will reset my spec file and do it again. Give me 45min (The buildservice is a bit slow during business hours)
Cheers
do the dictionary files go where you expect? I recall having a small battle with ./configure myself a short time back 1.1.2, eg with ./configure --prefix=/ --exec-prefix=/usr --enable-ltdl-install --with-experimental-modules --with-large-files I can demonstrate the result with the first few lines of make -n install /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 /usr/sbin /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 /usr/bin /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 //etc/raddb /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 //man /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 //var/run/radiusd /usr/src/freeradius-1.1.2/install-sh -c -d -m 700 //var/log/radius /usr/src/freeradius-1.1.2/install-sh -c -d -m 700 //var/log/radius/radacct /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 //share /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 //share/freeradius note the munging of the path - of course, its only doing what I'm telling it but istr that evrything used to go into /usr/share originally alan
On Wed 16 Aug 2006 10:49, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
On Wed 16 Aug 2006 09:55, Frank Cusack wrote:
On August 16, 2006 9:51:36 AM +0300 Peter Nixon <listuser@peternixon.net>
wrote:
http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10. 0/x8 6_64/freeradius-snapshot -20060808-14.1.x86_64.rpm http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10. 0/x8 6_64/freeradius-snapshot -devel-20060808-14.1.x86_64.rpm
Is a build log available?
I have already clobbered it by attempting new builds, but I will reset my spec file and do it again. Give me 45min (The buildservice is a bit slow during business hours)
Cheers
do the dictionary files go where you expect? I recall having a small battle with ./configure myself a short time back 1.1.2, eg with
./configure --prefix=/ --exec-prefix=/usr --enable-ltdl-install --with-experimental-modules --with-large-files
I can demonstrate the result with the first few lines of make -n install
/usr/src/freeradius-1.1.2/install-sh -c -d -m 755 /usr/sbin /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 /usr/bin /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 //etc/raddb /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 //man /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 //var/run/radiusd /usr/src/freeradius-1.1.2/install-sh -c -d -m 700 //var/log/radius /usr/src/freeradius-1.1.2/install-sh -c -d -m 700 //var/log/radius/radacct /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 //share /usr/src/freeradius-1.1.2/install-sh -c -d -m 755 //share/freeradius
note the munging of the path - of course, its only doing what I'm telling it but istr that evrything used to go into /usr/share originally
Yeah. The are going to /usr/share/freeradius The configure line I am using is the following: ./configure --prefix=%{_prefix} \ --sysconfdir=%{_sysconfdir} \ --with-raddbdir=/etc/raddb \ --infodir=%{_infodir} \ --mandir=%{_mandir} \ --localstatedir=/var \ --libdir=%{_libdir}/freeradius \ --with-threads \ --with-snmp \ --with-large-files \ %if 0%{?suse_version} <= 920 --without-rlm_sql_mysql \ %endif %if %{?suse_version:1}0 %if %suse_version > 910 %if %suse_version <= 920 --enable-heimdal-krb5 \ --with-rlm-krb5-include-dir=/usr/include/heimdal/ \ %endif --with-rlm-krb5-lib-dir=%{_libdir} \ %else --without-rlm_krb5 \ %endif %endif %if %_oracle_support == 1 --with-rlm_sql_oracle \ --with-oracle-lib-dir=%{_libdir}/oracle/10.1.0.3/client/lib/ \ %else --without-rlm_sql_oracle \ %endif --enable-strict-dependencies \ --with-edir \ --with-modules="rlm_sqlippool" \ --with-udpfromto -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
A.L.M.Buxey@lboro.ac.uk wrote:
do the dictionary files go where you expect? I recall having a small battle with ./configure myself a short time back 1.1.2, eg with
./configure --prefix=/ --exec-prefix=/usr --enable-ltdl-install --with-experimental-modules --with-large-files
prefix=/ means that the dictionaries go into /share. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
There is an issue within freeradius, that when you set: log_destination = files and start the server, the server logs things to stdout until it finally gets around to parsing the log_destination. for some reason, this is not an issue when log_destination is set to syslog Could someone suggest a fix/patch ? :) Sorry for the rant! Duane Cox
"Duane Cox" <duanec@mail.illicom.net> wrote:
and start the server, the server logs things to stdout until it finally gets around to parsing the log_destination. for some reason, this is not an issue when log_destination is set to syslog
I think I have a patch for the CVS head... I'll commit it shortly. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
"Duane Cox" <duanec@mail.illicom.net> wrote:
and start the server, the server logs things to stdout until it finally gets around to parsing the log_destination. for some reason, this is not an issue when log_destination is set to syslog
I think I have a patch for the CVS head... I'll commit it shortly.
Thank you sir!
Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
very small cosmetic change, more consistent with startup. CVS-HEAD --- freeradius-2.0.0-pre0.orig/src/main/mainconfig.c 2006-08-23 15:37:14.000000000 -0500 +++ freeradius-2.0.0-pre0/src/main/mainconfig.c 2006-08-24 11:34:55.000000000 -0500 @@ -937,7 +937,7 @@ if (!reload) { radlog(L_INFO, "Starting - reading configuration files ..."); } else { - radlog(L_INFO, "Reloading configuration files."); + radlog(L_INFO, "Reloading - reading configuration files ..."); } /* Initialize the dictionary */
"Duane Cox" <duanec@mail.illicom.net> wrote:
very small cosmetic change, more consistent with startup.
Added, and it now prints out the version number on startup, too. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog
On Wed 16 Aug 2006 09:51, Peter Nixon wrote:
On Wed 16 Aug 2006 05:16, Frank Cusack wrote:
On August 15, 2006 7:12:39 PM +0300 Peter Nixon <listuser@peternixon.net>
wrote:
On Thu 10 Aug 2006 23:19, Frank Cusack wrote:
On August 10, 2006 1:51:56 PM +0300 Peter Nixon <listuser@peternixon.net>
wrote:
Hi Guys
Does anyone know why "--prefix=/" not longer works as expected when fed to configure in the 1.1.x cvs branch?
Shouldn't that be --prefix=/usr ? Maybe '/' is discarded as an invalid prefix.
OK. After some more testing it is not --prefix which is broken. It works as expected. However it is now required to pass "--with-raddbdir=/etc/raddb" which was not necessary previously to get things to go in the expected place.
Is that acceptable?
There does appear to be something still a bit broken on 64bit though. I am using "--libdir=%{_libdir}/freeradius" which as expected builds and installs into /usr/lib64/freeradius/ on 64bit platforms and /usr/lib/freeradius/ on 32bit platforms. However when running radiusd -X on a 64bit install the following happens:
Module: Library search path is /usr/lib/freeradius radiusd.conf[1538] Failed to link to module 'rlm_exec': rlm_exec.so: cannot open shared object file: No such file or directory
Can you verify this with a "manual" build instead of rpm?
OK. I will setup a sacrificial VM later today to test it.
It works correctly here. I hate to ask, but are you sure you are running the radiusd you just built and installed?
Yep. Very sure. Our policy is to only ever install from rpm. We have no machine running "compiled from source" freeradius, and the rpms themselves are built on the opensuse buildservice. It is precisely so I don't have problems with old libs/binaries that I enforce this policy. (That and I can always easily roll back to an older version if I have problems)
If all that checks out, it would be interesting to see one of the installed .la files.
http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10.0/x86_ 64/freeradius-snapshot-20060808-14.1.x86_64.rpm http://software.opensuse.org/download/home:/peternixon/SUSE_Linux_10.0/x86_ 64/freeradius-snapshot-devel-20060808-14.1.x86_64.rpm
Hmm. It turns out that this is actually a false alarm. When installed on a clean system the rpm works as expected, however on a currently working system the rpm does not overwrite radiusd.conf and of course the existing radiusd.conf has "libdir = /usr/lib/freeradius" not "libdir = /usr/lib64/freeradius" I am not quite sure how to handle this change cleanly as it is definitely impolite to replace people's radiusd.conf but this will bite anyone upgrading on 64bit platforms. (At least using the SUSE rpms, I dont know about other platforms). Sorry for the false alarm. I not have one of my production 64bit servers running 20060808-snapshot with about 50 requests per second on a postgres backend. I will report anymore strangeness, but things appear to be fine at present. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On August 16, 2006 12:22:01 PM +0300 Peter Nixon <listuser@peternixon.net> wrote:
Hmm. It turns out that this is actually a false alarm. When installed on a clean system the rpm works as expected, however on a currently working system the rpm does not overwrite radiusd.conf and of course the existing radiusd.conf has "libdir = /usr/lib/freeradius" not "libdir = /usr/lib64/freeradius"
But you should get a radiusd.conf.rpmnew, yes? Not that this helps.
I am not quite sure how to handle this change cleanly as it is definitely impolite to replace people's radiusd.conf but this will bite anyone upgrading on 64bit platforms. (At least using the SUSE rpms, I dont know about other platforms).
You could write a %post script that changes libdir (perl -i -pe) on the existing radiusd.conf if the current value differs only in 32/64 bitness. %post %ifarch x86_64 [ other 64-bit arches you want to support ] libdir32=${%{_libdir}%%64}/freeradius /usr/bin/perl -i -pe "s:$libdir32:%{_libdir}/freeradius:" /etc/raddb/radiusd.conf %endif And you'd need a 'PreReq: perl' as well unless you have one of the very latest rpm versions that automatically figures out scriptlet deps. Probably not the cleanest solution but maybe it's good enough. -frank
On Wed 16 Aug 2006 13:03, Frank Cusack wrote:
On August 16, 2006 12:22:01 PM +0300 Peter Nixon <listuser@peternixon.net> wrote:
Hmm. It turns out that this is actually a false alarm. When installed on a clean system the rpm works as expected, however on a currently working system the rpm does not overwrite radiusd.conf and of course the existing radiusd.conf has "libdir = /usr/lib/freeradius" not "libdir = /usr/lib64/freeradius"
But you should get a radiusd.conf.rpmnew, yes? Not that this helps.
Yes. It creates that of course.
I am not quite sure how to handle this change cleanly as it is definitely impolite to replace people's radiusd.conf but this will bite anyone upgrading on 64bit platforms. (At least using the SUSE rpms, I dont know about other platforms).
You could write a %post script that changes libdir (perl -i -pe) on the existing radiusd.conf if the current value differs only in 32/64 bitness.
%post
%ifarch x86_64 [ other 64-bit arches you want to support ] libdir32=${%{_libdir}%%64}/freeradius /usr/bin/perl -i -pe "s:$libdir32:%{_libdir}/freeradius:" /etc/raddb/radiusd.conf %endif
And you'd need a 'PreReq: perl' as well unless you have one of the very latest rpm versions that automatically figures out scriptlet deps.
Probably not the cleanest solution but maybe it's good enough.
Thanks. Nice solution. I have added it to the spec. -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Wed 16 Aug 2006 05:16, Frank Cusack wrote:
OK. After some more testing it is not --prefix which is broken. It works as expected. However it is now required to pass "--with-raddbdir=/etc/raddb" which was not necessary previously to get things to go in the expected place.
Is that acceptable?
Personally I dont really care. Now that I have found the problem I have updated the spec file to match and it won't bother me again, however it is quite likely that we will get more than one question about it on the list once we release 1.1.3 as it is a change in build behaviour that people wont expect. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Wed 16 Aug 2006 09:54, Peter Nixon wrote:
On Wed 16 Aug 2006 05:16, Frank Cusack wrote:
OK. After some more testing it is not --prefix which is broken. It works as expected. However it is now required to pass "--with-raddbdir=/etc/raddb" which was not necessary previously to get things to go in the expected place.
Is that acceptable?
Personally I dont really care. Now that I have found the problem I have updated the spec file to match and it won't bother me again, however it is quite likely that we will get more than one question about it on the list once we release 1.1.3 as it is a change in build behaviour that people wont expect.
ok. It turns out that this is STILL not working as expected. This rpm is built with "--with-raddbdir=/etc/raddb". obiwan:~ # rpm -e freeradius-snapshot obiwan:~ # rm -rf /etc/raddb obiwan:~ # rpm -Uvh freeradius-snapshot-20060808-19.1.x86_64.rpm warning: freeradius-snapshot-20060808-19.1.x86_64.rpm: V3 DSA signature: NOKEY, key ID 6b9d6523 Preparing... ########################################### [100%] 1:freeradius-snapshot warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root%) warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root%) warning: user abuild does not exist - using root warning: user abuild does not exist - using root warning: user abuild does not exist - using root ########################################### [100%] obiwan:~ # radiusd -X Starting - reading configuration files ... reread_config: reading radiusd.conf Unable to open file "/usr/local/etc/raddb/radiusd.conf": No such file or directory Errors reading radiusd.conf So there is definitely something wrong with radiusd looking in the wrong place for its configs :-( -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
On Wed 16 Aug 2006 05:16, Frank Cusack wrote:
Module: Library search path is /usr/lib/freeradius radiusd.conf[1538] Failed to link to module 'rlm_exec': rlm_exec.so: cannot open shared object file: No such file or directory
Can you verify this with a "manual" build instead of rpm? It works correctly here. I hate to ask, but are you sure you are running the radiusd you just built and installed? If all that checks out, it would be interesting to see one of the installed .la files.
Hmm.. Even more interesting behaviour. If I use "--libdir=/usr/lib/freeradius" which was what I "used" to use with FreeRADIUS due to is ancient build system it does not appear to generate any *.la files on 64 OR 32bit (at least rpmbuild doesn't find them). If I use "--libdir=%{_libdir}/freeradius" it does! Now "--libdir=%{_libdir}/freeradius" should evaluate to "--libdir=/usr/lib/freeradius" on 32bit systems anyway so I am at a loss to explain this behaviour. I will trigger another build now just to test. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (11)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Alexander M. Pravking -
Duane Cox -
Frank Cusack -
Gabriel L. Somlo -
Matthew Schumacher -
Michael Joosten -
Nicolas Baradakis -
Peter Nixon -
Stephen Gran