We plan on releasing 2.1.6 this week. Please test the pre release at: http://git.freeradius.org/pre/ If there are any concerns, problems, errors, etc., please let us know before we release the final version. Alan DeKok.
On 12/5/09 14:33, Alan DeKok wrote:
We plan on releasing 2.1.6 this week.
Please test the pre release at: http://git.freeradius.org/pre/
If there are any concerns, problems, errors, etc., please let us know before we release the final version.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
/usr/local/tmp-src/freeradius-server-2.1.6/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.l /usr/local/tmp-src/freeradius-server-2.1.6/src/lib/libfreeradius-radius.la -framework DirectoryService -lresolv -lpthread \ -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 /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols: _lt__PROGRAM__LTX_preloaded_symbols collect2: ld returned 1 exit status make[4]: *** [radiusd] Error 1 make[3]: *** [common] Error 2 make[2]: *** [all] Error 2 make[1]: *** [common] Error 2 make: *** [all] Error 2 Hmm maybe the directory services stuff only compiles correctly in 10.5 -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, 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
Arran Cudbard-Bell wrote:
/usr/local/tmp-src/freeradius-server-2.1.6/libtool --mode=link gcc ... .libs/client.o .libs/conffile.o .libs/crypt.o .libs/exec.o .libs/files.o /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols: _lt__PROGRAM__LTX_preloaded_symbols
Libtool and libltld need to be taken out back and put out of my misery. If it would be possible, their developers should be re-educated into something useful... like basket weaving. There were reports on multiple systems of the same error. Apparently doing "autoreconf" fixes those problems. Which it did, for those systems. And now it has broken other systems. I'm inclined to look seriously at removing libltdl entirely, and therefore libtool. They are disgusting arcane complex fragile, and picky as all get out. I'm not sure what to do here... it works on my Mac, on the Ubuntu systems I have access to, and on Solaris. Anyone else see the same issue? Alan DeKok.
On 12/5/09 19:49, Alan DeKok wrote:
Arran Cudbard-Bell wrote:
/usr/local/tmp-src/freeradius-server-2.1.6/libtool --mode=link gcc ... .libs/client.o .libs/conffile.o .libs/crypt.o .libs/exec.o .libs/files.o /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols: _lt__PROGRAM__LTX_preloaded_symbols
Libtool and libltld need to be taken out back and put out of my misery. If it would be possible, their developers should be re-educated into something useful... like basket weaving.
There were reports on multiple systems of the same error. Apparently doing "autoreconf" fixes those problems. Which it did, for those systems.
And now it has broken other systems.
I'm inclined to look seriously at removing libltdl entirely, and therefore libtool. They are disgusting arcane complex fragile, and picky as all get out.
I'm not sure what to do here... it works on my Mac, on the Ubuntu systems I have access to, and on Solaris.
You're on OSX 10.5 though aren't you. These are old PPC OSX 10.4 servers. I'll have a go at building on arc and circumference (the new 10.5 RADIUS servers) when they're online (hopefully some time this week). I'm also having issues getting the 10.4 servers to link in the rlm_sql module. So have to build it all statically *sigh*.
Anyone else see the same issue?
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, 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
Arran Cudbard-Bell wrote:
/usr/local/tmp-src/freeradius-server-2.1.6/libtool --mode=link gcc ... .libs/client.o .libs/conffile.o .libs/crypt.o .libs/exec.o .libs/files.o /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols: _lt__PROGRAM__LTX_preloaded_symbols
Libtool and libltld need to be taken out back and put out of my misery. If it would be possible, their developers should be re-educated into something useful... like basket weaving.
There were reports on multiple systems of the same error. Apparently doing "autoreconf" fixes those problems. Which it did, for those systems.
And now it has broken other systems.
I'm inclined to look seriously at removing libltdl entirely, and therefore libtool. They are disgusting arcane complex fragile, and picky as all get out.
I'm not sure what to do here... it works on my Mac, on the Ubuntu systems I have access to, and on Solaris.
Works on Slackware as well. Ivan Kalik Kalik Informatika ISP
Dear Alan Same issue as 2.1.5 (debian OS), $INCLUDE sql.conf is commented by default. Hope you can take look on this. Thanks ----- Original Message ---- From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Sent: Tuesday, May 12, 2009 9:33:04 PM Subject: Proposed release of 2.1.6 We plan on releasing 2.1.6 this week. Please test the pre release at: http://git.freeradius.org/pre/ If there are any concerns, problems, errors, etc., please let us know before we release the final version. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
piston wrote:
Dear Alan
Same issue as 2.1.5 (debian OS), $INCLUDE sql.conf is commented by default.
Hope you can take look on this.
I think there is a good argument for not including sql.conf by default. You can't use sql until you've configured and set up a sql backend which requires active participatory configuration by the admin on multiple levels. In addition some users may not wish to install FreeRADIUS with any SQL support whatsoever, they might be using flat files or LDAP. Packagers may wish to offer user's "lite" versions which do not pull in any external dependencies on SQL. The default sql.conf defaults to MySQL. All of a sudden you now have to have MySQL installed and configured. But what if MySQL isn't installed and configured? Then the first time you run FreeRADIUS it fails. Then the clueless admin thinks he has to install MySQL because he doesn't understand SQL support is optional, and in particular MySQL is optional. I think we should leave SQL support turned off by default, those which need it will have the knowledge to enable it and those which don't will be spared headaches and package bloat. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
True... And not only SQL support... Good idea is just like it is now. Simple with basic options and good comments in config files... If you need something, uncomment it :) John Dennis wrote:
piston wrote:
Dear Alan
Same issue as 2.1.5 (debian OS), $INCLUDE sql.conf is commented by default.
Hope you can take look on this.
...... I think we should leave SQL support turned off by default, those which need it will have the knowledge to enable it and those which don't will be spared headaches and package bloat.
piston wrote:
Dear Alan
Same issue as 2.1.5 (debian OS), $INCLUDE sql.conf is commented by default.
Hope you can take look on this.
Perhaps you could explain why this is a problem, and what you would like me to do about it. Again... it's only a *DEFAULT* configuration. It is not meant to use used when you upgrade from one version to another. If you want to enable SQL, you already have to un-comment the various "sql" entries in raddb/sites-enabled/default, and raddb/sites-enabled/inner-tunnel. Is uncommenting one more in radiusd.conf that much of an issue? Alan DeKok.
Hi, It's not a major concern, just happen it is ucommented for previous version (from 1.x to 2.1.3), and the change log wasn't mention this changes. So for those less experiance freeradius users might have some issue, if you guys think it is fine as it is just ignore it, or atleast put a line on the change log. Thanks ----- Original Message ---- From: Alan DeKok <aland@deployingradius.com> To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Sent: Wednesday, May 13, 2009 2:17:50 AM Subject: Re: Proposed release of 2.1.6 piston wrote:
Dear Alan
Same issue as 2.1.5 (debian OS), $INCLUDE sql.conf is commented by default.
Hope you can take look on this.
Perhaps you could explain why this is a problem, and what you would like me to do about it. Again... it's only a *DEFAULT* configuration. It is not meant to use used when you upgrade from one version to another. If you want to enable SQL, you already have to un-comment the various "sql" entries in raddb/sites-enabled/default, and raddb/sites-enabled/inner-tunnel. Is uncommenting one more in radiusd.conf that much of an issue? Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
We plan on releasing 2.1.6 this week.
Please test the pre release at: http://git.freeradius.org/pre/
If there are any concerns, problems, errors, etc., please let us know before we release the final version.
no showstopper just yet... however, noted error in Makefile (spotted when doing the install) sed: can't read pool.h: No such file or directory sed: can't read smodule.h: No such file or directory indeed, Makefile mentions pool.h and smodule.h but they dont seem to exist anymore alan
A.L.M.Buxey@lboro.ac.uk wrote:
no showstopper just yet... however, noted error in Makefile (spotted when doing the install)
sed: can't read pool.h: No such file or directory sed: can't read smodule.h: No such file or directory
indeed, Makefile mentions pool.h and smodule.h but they dont seem to exist anymore
They're in the "master" branch, not in "stable". I'll go fix that, thanks. Alan DeKok.
Hi, crash bang boom. after a successful auth, things go wonky in SQL logging land +- entering group post-auth {...} [reply_log] expand: /var/log/radius/radacct/%{Client-IP-Address}/reply-detail-%Y%m%d -> /var/log/radius/radacct/192.168.5.13/reply-detail-20090512 [reply_log] /var/log/radius/radacct/%{Client-IP-Address}/reply-detail-%Y%m%d expands to /var/log/radius/radacct/192.168.5.13/reply-detail-20090512 [reply_log] expand: %t -> Tue May 12 19:52:39 2009 ++[reply_log] returns ok radiusd: symbol lookup error: /usr/lib/rlm_sql_log-2.1.6.so: undefined symbol: rad_assert the daemon crashes out alan
A.L.M.Buxey@lboro.ac.uk wrote:
crash bang boom. after a successful auth, things go wonky in SQL logging land
radiusd: symbol lookup error: /usr/lib/rlm_sql_log-2.1.6.so: undefined symbol: rad_assert
the daemon crashes out
Hah! I already caught that and committed a fix before you sent your message. Alan DeKok.
Hi,
A.L.M.Buxey@lboro.ac.uk wrote:
crash bang boom. after a successful auth, things go wonky in SQL logging land
radiusd: symbol lookup error: /usr/lib/rlm_sql_log-2.1.6.so: undefined symbol: rad_assert
the daemon crashes out
Hah! I already caught that and committed a fix before you sent your message.
damn and drat! I'll refresh sources and try again! ;-) alan
Hi,
We plan on releasing 2.1.6 this week.
Please test the pre release at: http://git.freeradius.org/pre/
If there are any concerns, problems, errors, etc., please let us know before we release the final version.
a quick request....the mschap module comes with example ntlm_auth line which now uses deprecated method - as the complaints when you try using it will testify...can this: #ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{Stripped-User-Name:-%{User-Name:-None}} --challen ge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" be changed to #ntlm_auth = "/path/to/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{User-Name:-None}} --challenge=%{mschap:Challenge:-00} --nt-response=%{mschap:NT-Response:-00}" thanks alan
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
We plan on releasing 2.1.6 this week.
Please test the pre release at: http://git.freeradius.org/pre/
If there are any concerns, problems, errors, etc., please let us know before we release the final version.
a quick request....the mschap module comes with example ntlm_auth line which now uses deprecated method - as the complaints when you try using it will testify...can this:
Ok... that's small enough that I think it can wait for the next version. Alan DeKok.
A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
Ok... that's small enough that I think it can wait for the next version.
okay - by the way, the download link on deployingradius.com is for 2.1.1 - any reason for love of this old version rather than eg 2.1.3 ? :-)
Lack of updates... I'll got fix that once 2.1.6 is released. Alan DeKok.
hi, something is stripping the "\n" string formfactor from requests... ie if User-Name = LUNET\netsec-1 then it all works fine - authentication etc etc but right at the end, something b0rks - heres the final bits of log Sending Access-Accept of id 215 to 192.168.8.198 port 1645 User-Name = "LUNET\netsec-1\000" User-Name = "LUNET\netsec-1" MS-MPPE-Recv-Key = 0xb7dc0bca3dd592c0754d68544e8daa2584af32869ab180941ab15628077c874f MS-MPPE-Send-Key = 0x6d0853823df58acf447488e8d4956985a78cb1ff503682f47616a7beef2e54f9 EAP-Message = 0x03090004 Message-Authenticator = 0x00000000000000000000000000000000 Finished request 21. Going to the next request Waking up in 4.8 seconds. rad_recv: Accounting-Request packet from host 192.168.8.198 port 1646, id=96, length=142 Acct-Session-Id = "0000004E" User-Name = "LUNET\netsec-1" Acct-Authentic = RADIUS Acct-Status-Type = Start NAS-Port-Type = Ethernet NAS-Port = 50002 NAS-Port-Id = "FastEthernet0/2" Called-Station-Id = "00-10-FF-52-DA-02" Calling-Station-Id = "00-1E-7B-DF-EC-66" Service-Type = Framed-User NAS-IP-Address = 192.168.8.198 Acct-Delay-Time = 0 +- entering group preacct {...} ++[preprocess] returns ok [acct_unique] Hashing 'NAS-Port = 50002,Client-IP-Address = 192.168.8.198,NAS-IP-Address = 192.168.8.198,Acct-Session-Id = "0000004E",User-Name = "LUNET\netsec-1"' [acct_unique] Acct-Unique-Session-ID = "856473d000a76781". ++[acct_unique] returns ok [suffix] No '@' in User-Name = "LUNET etsec-1", looking up realm NULL [suffix] Found realm "DEFAULT" [suffix] Adding Stripped-User-Name = "LUNET etsec-1" [suffix] Adding Realm = "DEFAULT" [suffix] Accounting realm is LOCAL. ++[suffix] returns ok ++[files] returns noop +- entering group accounting {...} [detail] expand: /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d -> /var/log/radius/radacct/192.168.8.198/detail-20090514 [detail] /var/log/radius/radacct/%{Client-IP-Address}/detail-%Y%m%d expands to /var/log/radius/radacct/192.168.8.198/detail-20090514 [detail] expand: %t -> Thu May 14 14:47:27 2009 ++[detail] returns ok [attr_filter.accounting_response] expand: %{User-Name} -> LUNET etsec-1 attr_filter: Matched entry DEFAULT at line 12 ++[attr_filter.accounting_response] returns updated Sending Accounting-Response of id 96 to 192.168.8.198 port 1646 Finished request 22. Cleaning up request 22 ID 96 with timestamp +230 Going to the next request Waking up in 3.8 seconds. Cleaning up request 14 ID 208 with timestamp +229 as you can see, all the access-accept stuff is fine - LUNET\netsec-1 = great however, after this has happened, the accouting stuff kicks in and its all turned into "LUNET etsec-1" - is this a debug cosmetic issue or is something internal getting twisted? PS cached EAP credentials - fantastic! alan
A.L.M.Buxey@lboro.ac.uk wrote:
something is stripping the "\n" string formfactor from requests... ie
if User-Name = LUNET\netsec-1 then it all works fine - authentication etc etc but right at the end, something b0rks - heres the final bits of log
\n is interpreted as a LF.
Sending Access-Accept of id 215 to 192.168.8.198 port 1645 User-Name = "LUNET\netsec-1\000" User-Name = "LUNET\netsec-1"
Hmm... that doesn't look right. Two User-Names, one of which has a trailing zero?
as you can see, all the access-accept stuff is fine - LUNET\netsec-1 = great
Nope. It SHOULD be printing out: User-Name = "LUNET\\netsec-1" See what it prints out in the Access-Request. It ONLY prints out "LUNET\netsec-1" if there is an embedded CR. If there really is a backslash followed by an 'n', then it escapes the backslash, as above.
however, after this has happened, the accouting stuff kicks in and its all turned into "LUNET etsec-1" - is this a debug cosmetic issue or is something internal getting twisted?
It's always behaved like that...
PS cached EAP credentials - fantastic!
That's been there for a bit, IIRC. Alan DeKok.
PS cached EAP credentials - fantastic!
That's been there for a bit, IIRC.
Yep, works perfectly in 2.1.4. Tis awesome though :) Vista and XP supplicants default to fast reconnect, so it just works for them. Arran -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk), Authentication, Authorisation and Accounting Officer, 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
Hi,
That's been there for a bit, IIRC.
Yep, works perfectly in 2.1.4. Tis awesome though :)
Vista and XP supplicants default to fast reconnect, so it just works for them.
- as our servers have had migrations a few little options have not been enabled on them (new features!! danger will robinson!) - i note the usual dire warnings - eg at top of radmin control-socket code ;-) so i tend to keep away from production for a while. however, after today I'm very happy to be using *that* feature - as Arran says - its on by default in a lot of clients..and boy! does it speed up the cycles on the server! alan
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Ivan Kalik -
John Dennis -
Marinko Tarlac -
piston