It's been a while since 2.1.6, and it's getting close to time for 2.1.7. In order to ensure the stability of the software, we need your help. Please download the "pre" release of 2.1.7 from: http://git.freeradius.org/pre/ Build it, install it, and see if there are issues. The directory also includes Debian packages for Ubuntu 8.0.4. If there are no issues, we can release 2.1.7 this week. Alan DeKok.
hi, quick initial feedback..if you do a straight upgrade over an existing installation then the daemon wont start because of missing config file Unable to open file "/etc/raddb/sql/mysql/cui.conf": No such file or directory this file is being called by the new modules/cui file which cannot be used properly until cui has been configured, cui.conf configured and the cui schema has been imported into the SQL - so I'm not sure why its active and on by default. alan
Alan Buxey wrote:
Unable to open file "/etc/raddb/sql/mysql/cui.conf": No such file or directory
this file is being called by the new modules/cui file which cannot be used properly until cui has been configured, cui.conf configured and the cui schema has been imported into the SQL - so I'm not sure why its active and on by default.
The intent was to add more CUI configuration, but there isn't time to finish that before 2.1.7. I've removed the $INCLUDE line that was causing the problem. Alan DeKok.
hi, yeh, that'll work - i just moved the module into modules-disabled (a local config option here) , so it, along with exec, expiration, and ldap arent loaded up upon server startup at all. alan
It's been a while since 2.1.6, and it's getting close to time for 2.1.7. In order to ensure the stability of the software, we need your help.
Please download the "pre" release of 2.1.7 from:
http://git.freeradius.org/pre/
Build it, install it, and see if there are issues. The directory also includes Debian packages for Ubuntu 8.0.4.
Would this packages work on Debian Lenny? -- damjan | дамјан This is my jabber ID --> damjan@bagra.net.mk -- not my mail address, it's a Jabber ID --^ :)
Alan DeKok wrote:
It's been a while since 2.1.6, and it's getting close to time for 2.1.7. In order to ensure the stability of the software, we need your help.
Please download the "pre" release of 2.1.7 from:
http://git.freeradius.org/pre/
Build it, install it, and see if there are issues. The directory also includes Debian packages for Ubuntu 8.0.4.
If there are no issues, we can release 2.1.7 this week.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Seems to build & run ok with out config. FYI we've been running with this patch: --- freeradius-server-2.1.4/share/dictionary.extreme.old 2009-04-29 14:16:30.000000000 +0100 +++ freeradius-server-2.1.4/share/dictionary.extreme 2009-04-29 14:18:40.000000000 +0100 @@ -17,6 +17,8 @@ ATTRIBUTE Extreme-Netlogin-Only 206 integer ATTRIBUTE Extreme-User-Location 208 string ATTRIBUTE Extreme-Netlogin-Vlan-Tag 209 integer +ATTRIBUTE Extreme-Netlogin-Extended-Vlan 211 string +ATTRIBUTE Extreme-Security-Profile 212 string VALUE Extreme-CLI-Authorization Disabled 0 VALUE Extreme-CLI-Authorization Enabled 1
The dictionary.airespace file should probably be updated. Airespace is now owned by Cisco and the VSAs that are published are different from those included with the FR distribution. See http://www.cisco.com/en/US/products/ps6366/products_configuration_example091... for additional details. I've included the copy of the dictionary.airespace file that I'm using. -r # -*- text -*- # # As found on the net. # # $Id$ # VENDOR Airespace 14179 BEGIN-VENDOR Airespace ATTRIBUTE Airespace-Wlan-Id 1 integer ATTRIBUTE Airespace-QOS-Level 2 integer ATTRIBUTE Airespace-DSCP 3 integer ATTRIBUTE Airespace-8021p-Tag 4 integer ATTRIBUTE Airespace-Interface-Name 5 string ATTRIBUTE Airespace-ACL-Name 6 string VALUE Airespace-QOS-Level Bronze 3 VALUE Airespace-QOS-Level Silver 0 VALUE Airespace-QOS-Level Gold 1 VALUE Airespace-QOS-Level Platinum 2 END-VENDOR Airespace On (09/02/09 10:46), Alan DeKok wrote:
It's been a while since 2.1.6, and it's getting close to time for 2.1.7. In order to ensure the stability of the software, we need your help.
Please download the "pre" release of 2.1.7 from:
http://git.freeradius.org/pre/
Build it, install it, and see if there are issues. The directory also includes Debian packages for Ubuntu 8.0.4.
If there are no issues, we can release 2.1.7 this week.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Ryan Steinmetz Lead Security/Systems Administrator Infrastructure Engineering Rochester Institute of Technology 585.475.5663 PGP: EF36 D45A 5CA9 28B1 A550 18CD A43C D111 7AD7 FAF2
Ryan Steinmetz wrote:
The dictionary.airespace file should probably be updated.
Airespace is now owned by Cisco and the VSAs that are published are different from those included with the FR distribution. See http://www.cisco.com/en/US/products/ps6366/products_configuration_example091... for additional details.
Added, thanks. Alan DeKok.
On 09/02/2009 04:46 AM, Alan DeKok wrote:
It's been a while since 2.1.6, and it's getting close to time for 2.1.7. In order to ensure the stability of the software, we need your help.
Build it, install it, and see if there are issues.
I've done a basic sanity check. * it builds * it installs * it runs * it can do pap sorry, but I don't have more time at the moment for further testing. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
John Dennis wrote:
On 09/02/2009 04:46 AM, Alan DeKok wrote:
It's been a while since 2.1.6, and it's getting close to time for 2.1.7. In order to ensure the stability of the software, we need your help.
Build it, install it, and see if there are issues.
I've done a basic sanity check.
* it builds * it installs * it runs * it can do pap
sorry, but I don't have more time at the moment for further testing.
Under RHEL5/x86_64 I can confirm it does PAP, PEAP/MSCHAP, ntlm_auth helper, SQL lookups via postgres & detail logging.
On Wednesday 02 September 2009 09:46:01 Alan DeKok wrote:
It's been a while since 2.1.6, and it's getting close to time for 2.1.7. In order to ensure the stability of the software, we need your help.
Please download the "pre" release of 2.1.7 from:
http://git.freeradius.org/pre/
Build it, install it, and see if there are issues. The directory also includes Debian packages for Ubuntu 8.0.4.
If there are no issues, we can release 2.1.7 this week.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Tested in Ubuntu 9.04 from sources and no problems found so far.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/09/2009 19:17, nf-vale wrote:
On Wednesday 02 September 2009 09:46:01 Alan DeKok wrote:
It's been a while since 2.1.6, and it's getting close to time for 2.1.7. In order to ensure the stability of the software, we need your help.
Please download the "pre" release of 2.1.7 from:
http://git.freeradius.org/pre/
Build it, install it, and see if there are issues. The directory also includes Debian packages for Ubuntu 8.0.4.
If there are no issues, we can release 2.1.7 this week.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Tested in Ubuntu 9.04 from sources and no problems found so far.
Attempting to compile on Ubuntu 8.10 event.c: In function 'radius_signal_self': event.c:3335: warning: ignoring return value of 'write', declared with attribute warn_unused_result gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/local/src/freeradius-server-2.1.7/src -DH /usr/local/src/freeradius-server-2.1.7/libtool --mode=compile gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SO gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/local/src/freeradius-server-2.1.7/src -DH gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/local/src/freeradius-server-2.1.7/src -DH /usr/local/src/freeradius-server-2.1.7/libtool --mode=compile gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SO gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/local/src/freeradius-server-2.1.7/src -DH gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/local/src/freeradius-server-2.1.7/src -DH /usr/local/src/freeradius-server-2.1.7/libtool --mode=compile gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SO gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/local/src/freeradius-server-2.1.7/src -DH gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/local/src/freeradius-server-2.1.7/src -DH /usr/local/src/freeradius-server-2.1.7/libtool --mode=compile gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SO gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/local/src/freeradius-server-2.1.7/src -DH detail.c: In function 'detail_send': detail.c:175: warning: label 'next' defined but not used gcc -g -O2 -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -Wall -D_GNU_SOURCE -DNDEBUG -I/usr/local/src/freeradius-server-2.1.7/src -DH /usr/local/src/freeradius-server-2.1.7/libtool --mode=link gcc -export-dynamic -dlopen self \ -o radiusd acct.lo auth.lo client.lo conffile.lo crypt.lo exec.lo files.lo listen.lo log.lo mainconfig.lo modul /usr/local/src/freeradius-server-2.1.7/src/lib/libfreeradius-radius.la -lnsl -lresolv -lpthread \ -lcrypt -lltdl -lcrypto -lssl -lcrypto rm -f .libs/radiusd.nm .libs/radiusd.nmS .libs/radiusd.nmT creating .libs/radiusdS.c (cd .libs && gcc -g -O2 -c -fno-builtin "radiusdS.c") rm -f .libs/radiusdS.c .libs/radiusd.nm .libs/radiusd.nmS .libs/radiusd.nmT gcc .libs/radiusdS.o -o .libs/radiusd .libs/acct.o .libs/auth.o .libs/client.o .libs/conffile.o .libs/crypt.o .libs/exec.o .libs/ .libs/modules.o: In function `setup_modules': /usr/local/src/freeradius-server-2.1.7/src/main/modules.c:1259: undefined reference to `lt__PROGRAM__LTX_preloaded_symbols' collect2: ld returned 1 exit status make[4]: *** [radiusd] Error 1 make[4]: Leaving directory `/usr/local/src/freeradius-server-2.1.7/src/main' make[3]: *** [common] Error 2 make[3]: Leaving directory `/usr/local/src/freeradius-server-2.1.7/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/freeradius-server-2.1.7/src' make[1]: *** [common] Error 2 make[1]: Leaving directory `/usr/local/src/freeradius-server-2.1.7' make: *** [all] Error 2 Will try OSX build shortly... Thanks, Arran - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqfvYwACgkQcaklux5oVKIBqQCgiFDAI6JrDII0G4ioTWOdHTYG aasAniQOb/MmwoDfwSVaftzPc8soUUp7 =240v -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Will try OSX build shortly...
Builds fine with OSX Server 10.5.7: ./configure --prefix=/usr/local/freeradius-2.1.7 --with-dhcp --with-vmps=no --with-openssl --without-rlm_perl --enable-ltdl-install=no - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqfwUcACgkQcaklux5oVKJftwCfdffGbpXgMNqVIWcOJY9/6b+R SpoAn3fIDZDTKXOA1ByhaXwHVGFRxZPw =aGGu -----END PGP SIGNATURE-----
Builds okay on Fedora 7 and Fedora 10: ./configure --with-system-libtool --prefix=/opt/radius --localstatedir=/var "make tests" also passes on both, FWIW. But I won't be able to actually install it for a week or two. Alan, thanks for all of your hard work on FreeRADIUS! -Matt
On Thu, Sep 03, 2009 at 12:02:08PM -0400, Matt Garretson wrote:
Builds okay on Fedora 7 and Fedora 10:
Also builds ok on CentOS 5.3 with the new RHEL/Fedora spec file for FreeRADIUS2 (modified to bump the version and add cui module) -- szymon roczniak simon@dischaos.com
Arran Cudbard-Bell wrote: ...
gcc .libs/radiusdS.o -o .libs/radiusd .libs/acct.o .libs/auth.o .libs/client.o .libs/conffile.o .libs/crypt.o .libs/exec.o .libs/ .libs/modules.o: In function `setup_modules': /usr/local/src/freeradius-server-2.1.7/src/main/modules.c:1259: undefined reference to `lt__PROGRAM__LTX_preloaded_symbols'
Did I mention I hate libltdl? Which version of libltdl is the compile line using? It's cut off, so I can't see it. My recent investigations lead me to believe that this error occurs when the *compile* uses the local libltdl, and the *link* stage uses the installed system libltdl. Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/09/2009 14:16, Alan DeKok wrote:
Arran Cudbard-Bell wrote: ...
gcc .libs/radiusdS.o -o .libs/radiusd .libs/acct.o .libs/auth.o .libs/client.o .libs/conffile.o .libs/crypt.o .libs/exec.o .libs/ .libs/modules.o: In function `setup_modules': /usr/local/src/freeradius-server-2.1.7/src/main/modules.c:1259: undefined reference to `lt__PROGRAM__LTX_preloaded_symbols'
Did I mention I hate libltdl?
Which version of libltdl is the compile line using? It's cut off, so I can't see it.
Here's the full output for those lines: make[6]: Entering directory `/usr/local/src/freeradius-server-2.1.7/src/modules/rlm_dynamic_clients' for x in .libs/* rlm_dynamic_clients.la; do \ rm -rf /usr/local/src/freeradius-server-2.1.7/src/modules/lib/$x; \ ln -s /usr/local/src/freeradius-server-2.1.7/src/modules/rlm_dynamic_clients/$x /usr/local/src/freeradius-server-2.1.7/src/modules/lib/$x; \ done make[6]: Leaving directory `/usr/local/src/freeradius-server-2.1.7/src/modules/rlm_dynamic_clients' make[5]: Leaving directory `/usr/local/src/freeradius-server-2.1.7/src/modules' make[4]: Leaving directory `/usr/local/src/freeradius-server-2.1.7/src/modules' Making all in main... make[4]: Entering directory `/usr/local/src/freeradius-server-2.1.7/src/main' /usr/local/src/freeradius-server-2.1.7/libtool --mode=link gcc -export-dynamic -dlopen self \ -o radiusd acct.lo auth.lo client.lo conffile.lo crypt.lo exec.lo files.lo listen.lo log.lo mainconfig.lo modules.lo modcall.lo radiusd.lo stats.lo session.lo threads.lo util.lo valuepair.lo version.lo xlat.lo event.lo realms.lo evaluate.lo vmps.lo detail.lo \ /usr/local/src/freeradius-server-2.1.7/src/lib/libfreeradius-radius.la -lnsl -lresolv -lpthread \ -lcrypt -lltdl -lcrypto -lssl -lcrypto rm -f .libs/radiusd.nm .libs/radiusd.nmS .libs/radiusd.nmT creating .libs/radiusdS.c (cd .libs && gcc -g -O2 -c -fno-builtin "radiusdS.c") rm -f .libs/radiusdS.c .libs/radiusd.nm .libs/radiusd.nmS .libs/radiusd.nmT gcc .libs/radiusdS.o -o .libs/radiusd .libs/acct.o .libs/auth.o .libs/client.o .libs/conffile.o .libs/crypt.o .libs/exec.o .libs/files.o .libs/listen.o .libs/log.o .libs/mainconfig.o .libs/modules.o .libs/modcall.o .libs/radiusd.o .libs/stats.o .libs/session.o .libs/threads.o .libs/util.o .libs/valuepair.o .libs/version.o .libs/xlat.o .libs/event.o .libs/realms.o .libs/evaluate.o .libs/vmps.o .libs/detail.o -Wl,--export-dynamic /usr/local/src/freeradius-server-2.1.7/src/lib/.libs/libfreeradius-radius.so -lnsl -lresolv -lpthread -lcrypt /usr/lib/libltdl.so -lssl -lcrypto -ldl -Wl,--rpath - -Wl,/usr/local/freeradius-2.1.7/lib .libs/modules.o: In function `setup_modules': /usr/local/src/freeradius-server-2.1.7/src/main/modules.c:1259: undefined reference to `lt__PROGRAM__LTX_preloaded_symbols' collect2: ld returned 1 exit status make[4]: *** [radiusd] Error 1 make[4]: Leaving directory `/usr/local/src/freeradius-server-2.1.7/src/main' make[3]: *** [common] Error 2 make[3]: Leaving directory `/usr/local/src/freeradius-server-2.1.7/src' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/freeradius-server-2.1.7/src' make[1]: *** [common] Error 2 make[1]: Leaving directory `/usr/local/src/freeradius-server-2.1.7' make: *** [all] Error 2
My recent investigations lead me to believe that this error occurs when the *compile* uses the local libltdl, and the *link* stage uses the installed system libltdl.
Yes icky icky. Arran - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqf4qoACgkQcaklux5oVKLigwCdFUw1nN/cS99ctI+Ch423//XA 1eIAn32yBB5LC2D0GnLMR55cjwLkYbz+ =W5ks -----END PGP SIGNATURE-----
Arran Cudbard-Bell wrote:
Here's the full output for those lines:
OK... so it's using the *system* libltdl. Ugh. How about this: - edit the top-level "Make.inc" - make it look like this: LIBLTDL = -lltdl INCLTDL = LTDL_SUBDIRS = Do a "make clean", and "rm -rf ./libltdl" Then "make". I suspect that will work, if you have libltdl-dev installed for the header files. If it does, then the problem is likely in libtool. It has this *magic* property where it will happily build things using the local libltdl include files... and then *link* to the system libltdl, EVEN THOUGH the link line points directly to the local libltl. Ugh. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote: ...
gcc .libs/radiusdS.o -o .libs/radiusd .libs/acct.o .libs/auth.o .libs/client.o .libs/conffile.o .libs/crypt.o .libs/exec.o .libs/ .libs/modules.o: In function `setup_modules': /usr/local/src/freeradius-server-2.1.7/src/main/modules.c:1259: undefined reference to `lt__PROGRAM__LTX_preloaded_symbols'
Did I mention I hate libltdl?
Which version of libltdl is the compile line using? It's cut off, so I can't see it.
My recent investigations lead me to believe that this error occurs when the *compile* uses the local libltdl, and the *link* stage uses the installed system libltdl.
Alan DeKok.
The last time I had a problem with libltdl, I has to execute a make manually in the source tree libltdl directory. After that everything worked, including rebuilds.
Joe Maimon wrote:
The last time I had a problem with libltdl, I has to execute a make manually in the source tree libltdl directory.
After that everything worked, including rebuilds.
Hmm... that means it was *trying* to use the system libltdl, and failed. That's annoying, and I'm not sure how to fix it. Alan DeKok.
Joe Maimon wrote:
The last time I had a problem with libltdl, I has to execute a make manually in the source tree libltdl directory.
After that everything worked, including rebuilds.
It turns out it's a problem with newer versions of libltdl. Warning: this message is long and complicated. To recap, when you see: ... undefined reference to `lt__PROGRAM__LTX_preloaded_symbols' it's a bug in libltdl / libtool. See: http://git.savannah.gnu.org/cgit/libtool.git/tree/libltdl/ltdl.h There's a line: #define lt_preloaded_symbols lt__PROGRAM__LTX_preloaded_symbols Which causes the problem. The apparent *intent* of the libtool crazies is to define this symbol inside of libtool. The source code they distribute contains this inside of their "libltdl/m4/libtool.m4": libtool.m4:lt__PROGRAM__LTX_preloaded_symbols[[]] = libtool.m4: return lt__PROGRAM__LTX_preloaded_symbols; Ok... that looks reasonable, right? Except that the *installed* version of libtool on the systems with this bug looks like: libtool:lt_${my_prefix}_LTX_preloaded_symbols[]; libtool:lt_${my_prefix}_LTX_preloaded_symbols[] = libtool: return lt_${my_prefix}_LTX_preloaded_symbols; And what is "my_prefix" set to? Nothing useful, that's for sure. But it gets better. There's *another* file distributed with the main libtool code. That file is intended to be used by projects like FreeRADIUS, in order to create the "right" version of libtool for each platform. FreeRADIUS has one (ltmain.sh, right beside the top-level configure and Makefile). The version of ltmain.sh distributed with the upstream libltdl source code has: ltmain.m4sh:lt_${my_prefix}_LTX_preloaded_symbols[]; ltmain.m4sh:lt_${my_prefix}_LTX_preloaded_symbols[] = ltmain.m4sh: return lt_${my_prefix}_LTX_preloaded_symbols; Aha! That's it. The ltmain.sh that everyone is supposed to use doesn't match the version of ltdl.h that they're also supposed to use. To recap, the version of libtool used to BUILD libltdl has the right symbols defined. But when libltdl is *installed*, that symbol disappears, and is replaced by lt_libltdl_LTX_preloaded_symbols. The version of libtool that the *suckers* like FreeRADIUS are supposed to use has references to t__PROGRAM__LTX_preloaded_symbols, but it does NOT have references to lt_libltdl_LTX_preloaded_symbols. It's like libtool and libltdl are some kind of sick joke. The solution *seems* to be simple. Update the FreeRADIUS source code to add: #define lt__PROGRAM__LTX_preloaded_symbols \ lt_libltdl_LTX_preloaded_symbols It then compiles and runs. Did I mention I hate libtool and libltdl? I hate them with a passion that (in contrast) makes a rabid dog look like a good babysitter for your children. Alan DeKok.
Build it, install it, and see if there are issues.
On FreeBSD 7.2 with libtool 2.2.6a: - Built - Installed - Tested EAP-PEAP/MSCHAPv2, rlm_perl with no issues so far No LD_PRELOAD needed for libperl.so with libtool 2.2.6. Do you think the MS-CHAP related patch I submitted will make 2.1.8? Should I submit a bug report for it?
Garber, Neal wrote:
Build it, install it, and see if there are issues.
On FreeBSD 7.2 with libtool 2.2.6a:
- Built - Installed - Tested EAP-PEAP/MSCHAPv2, rlm_perl with no issues so far
Thanks.
No LD_PRELOAD needed for libperl.so with libtool 2.2.6.
That's nice!
Do you think the MS-CHAP related patch I submitted will make 2.1.8? Should I submit a bug report for it?
It won't make 2.1.8. Please submit a bug report and attach the patch. My preference for the patch is to split it into 2-3 pieces. Messing with functionality in the MSCHAP module is a bit worrisome, as it's pretty core to a lot of systems. Alan DeKok.
It won't make 2.1.8. Please submit a bug report and attach the patch. My preference for the patch is to split it into 2-3 pieces.
Bug # 17 created with separate attachments for each file changed.
Messing with functionality in the MSCHAP module is a bit worrisome, as it's pretty core to a lot of systems.
I understand and share your concern. Perhaps some people would be willing to apply the patch and test it before it is included in a release to get additional confirmation that it doesn't break anything. Thanks for your continued support Alan..
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/09/2009 16:45, Garber, Neal wrote:
It won't make 2.1.8. Please submit a bug report and attach the patch. My preference for the patch is to split it into 2-3 pieces.
Bug # 17 created with separate attachments for each file changed.
Messing with functionality in the MSCHAP module is a bit worrisome, as it's pretty core to a lot of systems.
I understand and share your concern.
Perhaps some people would be willing to apply the patch and test it before it is included in a release to get additional confirmation that it doesn't break anything.
What functionality does the patch add? Thanks, Arran - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqmgkwACgkQcaklux5oVKKdLgCfQKj7Vwh4sBJ4bLAVEZQ8ijV7 vpYAniI/2qBGNM4+3C34dbGWwcLQViOS =t/h0 -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 08/09/2009 17:11, Arran Cudbard-Bell wrote:
On 08/09/2009 16:45, Garber, Neal wrote:
It won't make 2.1.8. Please submit a bug report and attach the patch. My preference for the patch is to split it into 2-3 pieces.
Bug # 17 created with separate attachments for each file changed.
Messing with functionality in the MSCHAP module is a bit worrisome, as it's pretty core to a lot of systems.
I understand and share your concern.
Perhaps some people would be willing to apply the patch and test it before it is included in a release to get additional confirmation that it doesn't break anything.
What functionality does the patch add?
Duh, look at the bug tracking case. Ok this is potentially useful, and might clean up User-Name handling a bit. Does it apply cleanly to the current git head? Thanks, Arran - -- Arran Cudbard-Bell <A.Cudbard-Bell@sussex.ac.uk>, Systems Administrator (AAA), Infrastructure Services (IT Services), E1-1-08, Engineering 1, University Of Sussex, Brighton, BN1 9QT DDI+FAX: +44 1273 873900 | INT: 3900 GPG: 86FF A285 1AA1 EE40 D228 7C2E 71A9 25BB 1E68 54A2 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqmgrYACgkQcaklux5oVKLuwQCfWtnpuSXSaJHLVUOSWouUZgf0 yZEAn10qVuP7db5ywQCIHEwlV5TV2TOt =yUJq -----END PGP SIGNATURE-----
Does it apply cleanly to the current git head?
I created it about 2 weeks ago against the then current git head. It changes rlm_eap_mschapv2.c, rlm_mschap.c & radius.h. I don't believe any of these have changed in the past 2 weeks, so it should still apply cleanly. I've been running with it applied for several weeks now without issues. If you have a chance to test it, that would be great Arran. Thanks..
Garber, Neal wrote:
Bug # 17 created with separate attachments for each file changed.
Thanks.
Messing with functionality in the MSCHAP module is a bit worrisome, as it's pretty core to a lot of systems.
I understand and share your concern.
Perhaps some people would be willing to apply the patch and test it before it is included in a release to get additional confirmation that it doesn't break anything.
Please! Feedback is a major way to get new features in. Alan DeKok.
participants (12)
-
Alan Buxey -
Alan DeKok -
Arran Cudbard-Bell -
Damjan -
Garber, Neal -
Joe Maimon -
John Dennis -
Matt Garretson -
nf-vale -
Phil Mayers -
Ryan Steinmetz -
Szymon Roczniak