August 2006 - Freeradius-Devel - lists.freeradius.org

sql_log
by Peter Nixon 04 Sep '06

04 Sep '06

Forgive me if this has been asked before, but shouldn't the sql_log module use the same SQL queries from as the normal sql module? Why does it have it's own set of queries in radiusd.conf? As far as I can tell it should simply ignore connection info and non accounting queries otherwise do exactly the same thing! -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

3 12

RFC compliance in sanitizing Access-Reject responses
by Mike 02 Sep '06

02 Sep '06

All, First, thank you for an excellent server. Within a few hours we went from google-ing for a radius server to having a proxy up which does (almost) everything we needed to make a third party device/server learn many cool new tricks. Unfortunately last night I had to spend 3 hours (maybe "only" 3 hours, attesting to high code quality) in trying to figure out why Access-Reject messages were loosing all but the Reply-Message attribute. Eventually I did find, first a hint on the mailing lists, then the RFC, and then finally after quite a bit of digging, the code in util.c : case PW_AUTHENTICATION_REJECT: pairmove2(&vps, &(packet->vps), PW_EAP_MESSAGE); pairmove2(&vps, &(packet->vps), PW_MESSAGE_AUTHENTICATOR); pairmove2(&vps, &(packet->vps), PW_REPLY_MESSAGE); break; I would like to suggest at least two small changes to make freeradius an even better tool than it already is. The first is really simple and would take practically no work at all: can we please have a log message here that notifies the user of this operation when running with -X? This would have saved me most of the time I've spent digging through mailing lists and the rlm_attr_filter code, and allowed me to quickly find the above culprit. This is actually quite necessary, since any "detail" logs that can be inserted on the proxy reply path happily show all attributes - the attributes magically disappear right before packet is sent. The second request is also trivial to implement: make the above code configurable/optional. Yes, there is a great deal of strength and respect in supporting the RFC to the dot - and without a doubt, that should be the default out-of-the-box configuration. But not all devices are created equal - and in my case, as I'm sure in some others, useful information is passed in the Access-Reject message in attributes other than Reply-Message. Obviously this is not compliant - but all the devices I have are quite happy accepting those "extra" arguments, and a third party server is certainly very happy to send them. Making this code "optional" with a config file switch saves me from hacking the sources. Code change can be achieved simply by moving up case PW_AUTHENTICATION_REJECT: above the default: case and wrapping the 4 line body (including break;) inside of an if statement, so this change is also quite triviail. The third "request" or "option" perhaps, is a bit more complex. I would propose that the above code is actually a hack to comply with RFC, and that the appropriate mechanism of accomplishing this effect is through an appropriate set of attribute filters (enabled by default). This would require extending the attr_filters module to consider the request/response type being filtered. The default configuration can point out the RFC in the comments and filter out everything with the three exceptions. This of course allows for maximal flexibility, while still respecting the standard in the default configuration. I think this one is quite a bit more work, so I do not put too many hopes into it, but I figured I would throw it out on the table. Again, thanks for a great server. The above "hickup" is hardly worth mentioning when compared to the overall experience we've had in setting up the proxy and getting it to do what we want.

3 7

RE: RPM packaging (was: Last set of changes for 1.1.3)
by Sandworm 01 Sep '06

01 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 29 August 2006 7:01 PM, Nicolas Baradakis wrote: > > Thanks for the explanation: I never used rpmbuild myself, so I didn't > know the detailed mechanisms. Then it appears deletion is not really > a problem. The only thing that is strange, is that you redo with > rpmbuild what the Makefile has already done. > The RPM build process does use the Makefile. It does a complete build and install, but does the install in the environment of the "build root", which has a usr, etc, bin, and so on. The built directory is then used to construct the packaged binary RPM (and source RPM, if requested). However, it needs to distinguish between different types of files. This is why files are tagged as "%doc", because these need to be located in what is designated as the documentation directory. So, regardless of the original directory that the Makefile installed them in, they get moved into the documentation directory, sort of relative to the way they are specified in the %doc directives. If you're interested, see "The %doc Directive" at http://www.rpm.org/max-rpm/s1-rpm-inside-files-list- directives.html. Regards SW -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkT1SdEACgkQmw4BJyaatJ0eVgCgoM2ZJElpezgs821HUu6lfa1YUFgA oKWP1VLiIBUuZ3CXU3aiCZwQK74S =i+p9 -----END PGP SIGNATURE-----

3 3

Re: Duplicate requests in a session
by Peter Nixon 01 Sep '06

01 Sep '06

Good question. Does anyone have anything against changing this? -Peter On Thu 31 Aug 2006 10:11, Santiago Balaguer García wrote: > Thanks James, I don't figure out to use primary key solves the problem of > duplicate keys. > I had in radacct as primary key <<radacctid>> but now I am going to have > <<acctuniqueid>>. > > This proble cause a new thread: why radacctid is the primary key of radacct > table instead od acctuniqueid? > > >From: James Wakefield <jamesw(a)deakin.edu.au> > >Reply-To: FreeRadius users mailing list > ><freeradius-users(a)lists.freeradius.org> > >To: FreeRadius users mailing list <freeradius-users(a)lists.freeradius.org> > >Subject: Re: Duplicate requests in a session > >Date: Wed, 30 Aug 2006 22:07:09 +1000 > > > >Santiago Balaguer García wrote: > >>Hi people, > >> > >>1) > >> In my activity I realize that when the conexion to Internet of a NAS is > >>NOT good (there are some reday in the DSL), the NAS send several Start > >>requests. My problen is my RADIUS server ask for all these requests and > >>they are inserted in my DB. So, when the user or the NAS finalize the > >>session and NAS sends Stop Request, the credit associates to the user > >>account is decremented several times. It happens so because I put a > >> trgger in my DB to decrement the user credit atomatically. > >> > >> Can I avoid the problem of inserting several times the start request? > >> If it is so, how?? > >> > >>2) Is it supposed that the value of acctsessionid and acctuniqueid in > >>radacct table are UNIQUE and they can not be duplicated ? > >> > >>Thanks, > >> Santiago > > > >Hi Santiago, > > > >Does your DBMS enforce primary key constraints? Do you have a primary key > >defined for your radacct table? If I recall correctly, MySQL by default > >doesn't, are you using MySQL? > > > >Cheers, > >-- > >James Wakefield, > >Unix Administrator, Information Technology Services Division > >Deakin University, Geelong, Victoria 3217 Australia. > > > >Phone: 03 5227 8690 International: +61 3 5227 8690 > >Fax: 03 5227 8866 International: +61 3 5227 8866 > >E-mail: james.wakefield(a)deakin.edu.au > >Website: http://www.deakin.edu.au > >- List info/subscribe/unsubscribe? See > >http://www.freeradius.org/list/users.html > > _________________________________________________________________ > Acepta el reto MSN Premium: Protección para tus hijos en internet. > Descárgalo y pruébalo 2 meses gratis. > http://join.msn.com?XAPID=1697&DI=1055&HL=Footer_mailsenviados_proteccionin >fantil > > - > List info/subscribe/unsubscribe? See > http://www.freeradius.org/list/users.html -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

3 4

SQL Cleanups (Was: Duplicate requests in a session)
by Peter Nixon 31 Aug '06

31 Aug '06

-Moved to devel list from user list- On Thu 31 Aug 2006 13:12, Alan DeKok wrote: > Peter Nixon <listuser(a)peternixon.net> wrote: > > Good question. Does anyone have anything against changing this? > > They primary key should be a synthetic field, and not something > derived directly from the packet. Calling it 'acctuniqueid' is > awkward, maybe renaming it to 'radiuskey'? > > It can then be used in the SQL queries as > %{Acct-Unique-ID:-%{Acct-Session-id}}, which should be safe for all > configuration. This makes sense to me. I think it should be for 2.0 though as changing the name of fields in a DB schema will break compatibility. I have also been considering a number of other cleanups for 2.0 One of my pet peeves is that the mysql config file is called "sql.conf" which tends to confuse non-mysql users the first time around. This should be renamed to mysql.conf (oraclesql.conf should be renamed to oracle.conf also) I think it may even be a good idea to make a raddb/sql/*.conf structure, either that or maybe we should name the files sql.mysql.conf, sql.postgresl.conf etc. This then allows sqlippool.mysql.conf also. (Alternatively the sqlipool config should go inside the existing sql config files.) Also, before a 2.0 release I would like to sit down and bring the queries for the different SQL variants as close together as possible as they have gradually diverged over the last few years. (Much of it my fault as I have been continually adding new features to the postgresql schema :-) Thoughts? -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

3 7

Automatic report from sources (radiusd) between 30.08.2006 - 31.08.2006 GMT
by Automatic cvs log generator 31 Aug '06

31 Aug '06

CVS log entries from 30.08.2006 (Wed) 08:00:01 - 31.08.2006 (Thu) 08:00:01 GMT ===================================================== Summary by authors ===================================================== Author: bjordanov File: radiusd/src/modules/rlm_perl/rlm_perl.c; Revisions: 1.38 ===================================================== Log entries ===================================================== Description: New Future: Modify the operator for VP For example to change Operator for Framed-MTU use code like that. $hash{'Framed-MTU'} = "100"; $hash{'Operator'} = "=="; $RAD_REPLY{'Framed-MTU'} = \%hash; Modified files: File: radiusd/src/modules/rlm_perl/rlm_perl.c; Revision: 1.38; Date: 2006/08/30 11:00:05; Author: bjordanov; Lines: (+46 -9) ===================================================== Summary of modified files ===================================================== File: radiusd/src/modules/rlm_perl/rlm_perl.c Revisions: 1.38 Authors: bjordanov (+46 -9) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

FreeRADIUS Wiki
by Peter Nixon 30 Aug '06

30 Aug '06

Hi Guys I am making a concerted attempt to get the FAQ and rest of the wiki up to date and add new FAQs as they occur on the mailing list. The FAQ is now at: http://wiki.freeradius.org/index.php/FAQ It would help if other developers would instead of directly answering FAQs on the list, add them to the wiki and reply with the link. Cheers -- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc

2 2

mac os x build of v1.1.3: "Symbol not found: _debug_flag"
by Markus Krause 30 Aug '06

30 Aug '06

Hi all! some days ago (22.8.) i reported success on compiling and running freeradius with mac os x (10.4.7). as i read of someone habving problems to do so in the past few days i just downloaded the release version 1.1.3 and ran into to following problem: just typing "./configure", "make" and "make install" showed no errors, but on trying to start the freeradius server with "freeradius -XAs" i get: radiusd: entering modules setup Module: Library search path is /usr/local/lib radiusd.conf[1585] Failed to link to module 'rlm_exec': dlopen(/usr/local/lib/rlm_exec-1.1.3.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_exec-1.1.3.so Expected in: flat namespace i am just using the standard config files with no change at all except a line for a testuser in "users". exactly the same configuration on exactly the same machine with the (also just fresh) compiled cvs-version of 21.8.2006 works without any problems. it is not only related to the rlm_exec module, if i am commenting this out in "instantination" of radiusd.conf i get the error: radiusd: entering modules setup Module: Library search path is /usr/local/lib radiusd.conf[1555] Failed to link to module 'rlm_expr': dlopen(/usr/local/lib/rlm_expr-1.1.3.so, 9): Symbol not found: _debug_flag Referenced from: /usr/local/lib/rlm_expr-1.1.3.so Expected in: flat namespace and if i comment out "expr", the same with the next used module (i assume) "pap". any hints? what changed in the meantime? regards markus -- Markus Krause email: krause(a)biochem.mpg.de Mogli-Soft: Support for Mac OS X, Webmail/Horde, LDAP, RADIUS by order of the Computing Center of the Max-Planck-Institute of Biochemistry Tel.: 089 - 89 40 85 99 Fax.: 089 - 89 40 85 98 --------------------------------------------------------------------- This message was sent using https://webmail.biochem.mpg.de If you encounter any problems please report to rz-linux(a)biochem.mpg.de

3 6

Re: RPM packaging (was: Last set of changes for 1.1.3)
by Sandworm 29 Aug '06

29 Aug '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday, 25 August 2006 8:17 PM Nicolas Baradakis wrote: > Is it impossible to force rpmbuild to package the files installed by > the Makefile in /usr/share/doc/... with a line the %files section ? > > %files > ... > %{_datadir}/doc/%{name}-%{version}/*/* I don't know what this is supposed to do, but having it generates an error: RPM build errors: create archive failed on file /var/tmp/freeradius- root/usr/share/doc/freeradius-1.1.3/examples/iplanet.ldif: cpio: open failed - Bad file descriptor > I've seen something similar in suse/freeradius.spec, but I think this > is a violation of the packaging rules: files in the *source* directory > should not be deleted while building a package. I don't know if this deletion is so much of a problem. While building via rpmbuild, the source tarball is (normally) in /usr/src/redhat/SOURCES, the tarball is expanded into /usr/src/redhat/BUILD, and the (temporary) build root (which is what the spec variable $RPM_BUILD_ROOT points to) is in /var/tmp/freeradius-root. The deletion happens in this directory, which is supposed to be deleted anyway after the build. The *source* directory then does not get affected by the packaging. SW -----BEGIN PGP SIGNATURE----- Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 2.5 wkYEARECAAYFAkTyZfAACgkQmw4BJyaatJ2eFACfWBunR4gch9vAt8cYONvRYpnOn0MA n0xIo7akUBqU01aSKS8Na50ZR250 =HMgG -----END PGP SIGNATURE-----

2 1

Automatic report from sources (radiusd) between 28.08.2006 - 29.08.2006 GMT
by Automatic cvs log generator 29 Aug '06

29 Aug '06

CVS log entries from 28.08.2006 (Mon) 08:00:02 - 29.08.2006 (Tue) 08:00:01 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/modules/rlm_perl/rlm_perl.c; Revisions: 1.37 ===================================================== Log entries ===================================================== Description: Over-write existing vp's with new ones. This means that the Perl module works more like the other modules, which have absolute power over the VP's, and less like the "users" file, which updates the VP's via operators, etc Modified files: File: radiusd/src/modules/rlm_perl/rlm_perl.c; Revision: 1.37; Date: 2006/08/28 17:13:00; Author: aland; Lines: (+26 -15) ===================================================== Summary of modified files ===================================================== File: radiusd/src/modules/rlm_perl/rlm_perl.c Revisions: 1.37 Authors: aland (+26 -15) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0