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

FreeRADIUS wiki
by Kevin Bonner 19 Jun '06

19 Jun '06

I'm trying to login to the FR wiki to cleanup the spam and continue receiving the following error: Fatal error: Call to undefined function: getuser() in /srv/www/vhosts/wiki-freeradius/includes/Skin.php on line 546 I've reset my password and still receive that message. Is anyone else running into this, or am I just lucky? Kevin Bonner

3 4

Using radius to determine a users group membership.
by Matthew Grooms 18 Jun '06

18 Jun '06

All, I am not that familiar with radius so I was hoping a guru could help me out. Using a radius client library, I would like to be able to determine if a given user is a member of a given group. It would be preferable to use a method to somehow query this information ad-hock. As an alternative, if the server could be coaxed into returning the users membership information ( maybe during user authentication? ), that would work as well. I noticed that there are several keywords in the standard dictionary file that have to do with groups but am not sure what they are used for. If someone knows how to accomplish this, could they kindly point me to some documentation that describes the method? I tried sifting through the RFC's, the freeradius FAQ and the freeradius mailing list archives but had no luck. The client library I am using is radlib which is bundled with FreeBSD 6.x. The freeradius server I have configured is using the unix authentication module to query the system password and group databases. Thanks in advance, -Matthew

2 1

Automatic report from sources (radiusd) between 16.06.2006 - 17.06.2006 GMT
by Automatic cvs log generator 17 Jun '06

17 Jun '06

CVS log entries from 16.06.2006 (Fri) 08:00:03 - 17.06.2006 (Sat) 08:00:02 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/lib/packet.c; Revisions: 1.2 File: radiusd/share/dictionary.walabi; Revisions: 1.1 File: radiusd/src/include/libradius.h; Revisions: 1.119 File: radiusd/src/include/packet.h; Revisions: 1.2 File: radiusd/share/dictionary; Revisions: 1.130 File: radiusd/src/main/radclient.c; Revisions: 1.101 ===================================================== Combined list of identical log entries ===================================================== Description: As found on the net Modified files: File: radiusd/share/dictionary; Revision: 1.130; Date: 2006/06/16 19:09:49; Author: aland; Lines: (+2 -1) File: radiusd/share/dictionary.walabi; Revision: 1.1; Date: 2006/06/16 19:09:49; Author: aland; ------------------------------- Description: Added "hash" back to RADIUS_PACKET, for speed. Added new "packet list" implementation, which keeps track of RADIUS_PACKET's across multiple sockets. Update radclient to use it, which simplifies much of the radclient code. The idea is that eventually the server, or any implementation that needs to keep track of incoming/outgoing packets will use the packet list code, which is simple, fast, and extensible. With luck, we should be able to replace the horrid code in request_list.c, which does all sorts of evil things on proxying. We can also replace the bloated nightmare that listen.c has become. Modified files: File: radiusd/src/include/libradius.h; Revision: 1.119; Date: 2006/06/16 23:39:31; Author: aland; Lines: (+2 -1) File: radiusd/src/include/packet.h; Revision: 1.2; Date: 2006/06/16 23:39:31; Author: aland; Lines: (+42 -1) File: radiusd/src/lib/packet.c; Revision: 1.2; Date: 2006/06/16 23:39:32; Author: aland; Lines: (+607 -10) File: radiusd/src/main/radclient.c; Revision: 1.101; Date: 2006/06/16 23:39:31; Author: aland; Lines: (+78 -123) ===================================================== Log entries ===================================================== ===================================================== Summary of modified files ===================================================== File: radiusd/share/dictionary Revisions: 1.130 Authors: aland (+2 -1) ------------------------------- File: radiusd/share/dictionary.walabi Revisions: 1.1 Authors: aland ------------------------------- File: radiusd/src/include/libradius.h Revisions: 1.119 Authors: aland (+2 -1) ------------------------------- File: radiusd/src/include/packet.h Revisions: 1.2 Authors: aland (+42 -1) ------------------------------- File: radiusd/src/lib/packet.c Revisions: 1.2 Authors: aland (+607 -10) ------------------------------- File: radiusd/src/main/radclient.c Revisions: 1.101 Authors: aland (+78 -123) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

There appear to be another radius server on port...
by Laurent LOINGEVILLE 16 Jun '06

16 Jun '06

Hi! I've install a radius server as a proxy radius server and when i want to start this one, i have the message "there appear to have another radius server on port 1818".But it is the only machine where radius is running... How is it due? how can i resolve this problem? Thanks a lot in advance for your help!

2 1

Re: 1.1.2 is broken if you have closefrom()
by Frank Cusack 16 Jun '06

16 Jun '06

On June 15, 2006 12:42:34 PM +0200 Nicolas Baradakis <nbk(a)sitadelle.com> wrote: > Frank Cusack wrote: > >> On June 9, 2006 1:56:16 PM +0200 Nicolas Baradakis <nbk(a)sitadelle.com> wrote: >> >> > I also note the autotools versions have to be compatible: libtool 1.4 >> > comes with autoconf 2.13, and libtool 1.5 comes with autoconf 2.50. >> > Upgrade one but not the other may lead to unpredictable results. >> >> Well, even 1.1 as-is actually requires autoconf-2.50. I was going to put >> add that to configure.in as part of the patch. > > I don't understand: the current branch 1.1 with libtool 1.4 has always > used autoconf 2.13. My mistake; autoconf-2.13 merely generates a warning about AC_TRY_RUN with branch 1.1. It was only after I updated libtool that it required 2.50. BTW, creating "test" branches to try stuff out, then merging them back, is trivial with p4. There wouldn't be any question about submitting. (And this is where p4 beats svn also, so I've read.) -frank

2 2

Automatic report from sources (radiusd) between 15.06.2006 - 16.06.2006 GMT
by Automatic cvs log generator 16 Jun '06

16 Jun '06

CVS log entries from 15.06.2006 (Thu) 08:00:03 - 16.06.2006 (Fri) 08:00:03 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/src/include/libradius.h; Revisions: 1.76.2.2.2.9 File: radiusd/src/lib/hash.c; Revisions: 1.9.2.7 File: radiusd/src/lib/dict.c; Revisions: 1.50.2.4.2.10 ===================================================== Combined list of identical log entries ===================================================== Description: Port update hash code (using hash && compare callbacks) from the head. Modified files: File: radiusd/src/include/libradius.h; Revision: 1.76.2.2.2.9; Date: 2006/06/15 21:47:14; Author: aland; Lines: (+11 -7) File: radiusd/src/lib/dict.c; Revision: 1.50.2.4.2.10; Date: 2006/06/15 21:47:15; Author: aland; Lines: (+190 -115) File: radiusd/src/lib/hash.c; Revision: 1.9.2.7; Date: 2006/06/15 21:47:14; Author: aland; Lines: (+82 -47) ===================================================== Log entries ===================================================== ===================================================== Summary of modified files ===================================================== File: radiusd/src/include/libradius.h Revisions: 1.76.2.2.2.9 Authors: aland (+11 -7) ------------------------------- File: radiusd/src/lib/dict.c Revisions: 1.50.2.4.2.10 Authors: aland (+190 -115) ------------------------------- File: radiusd/src/lib/hash.c Revisions: 1.9.2.7 Authors: aland (+82 -47) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

Re: 1.1.2 is broken if you have closefrom()
by Frank Cusack 15 Jun '06

15 Jun '06

On June 8, 2006 6:02:44 PM -0400 Alan DeKok <aland(a)nitros9.org> wrote: > Frank Cusack <fcusack(a)fcusack.com> wrote: > The libltdl retards would allocate a data structure, partially fill > it in, and then RETURN IT to the caller if ltdl_open() didn't work. > Since ltdl_open() is documented as returning PTR on success and NULL > on fail, it would look like the dlopen succeeded. The code would then > call ltdl_sym(), using the previous bullshit structure, and the > retarded ltdl_sym() code would de-reference a NULL pointer. It > doesn't need to check, apparently, because that field is supposed to > be initialized if ltdl_open() worked. Your patch is actually in lt_dlopenext(), not lt_dlopen(). On inspection, I don't see a code path that leaves handle non-NULL on an error return. I'm also unable to reproduce the problem, and none of the bugs referencing this problem has an adequate description. Can you give me a formula to demonstrate this problem? I don't have mysql, which a lot of the cases seem to revolve around. -frank

2 9

Re: 1.1.2 is broken if you have closefrom()
by Frank Cusack 15 Jun '06

15 Jun '06

On June 8, 2006 6:02:44 PM -0400 Alan DeKok <aland(a)nitros9.org> wrote: > Frank Cusack <fcusack(a)fcusack.com> wrote: >> 1. Can I just check this into the 1.1.0 branch and then upintegrate >> to HEAD (later)? > > Ok. I'm not sure the fix is required for head, as that is already > using a newer libtool, which should work. It should be in head also (read on). > I'd like to see the diff, or have a description of it first, though. > Working with libtool & autoconf is pretty insane. Yeah. So what I did is upgrade to libtool and ltdl 1.5.22. The current libtool and ltdl is GNU + changes. This is difficult. I rearranged our autoconf stuff (ever so slightly :-)) to allow drop-in of the untouched originals. That's why I asked about the change the ltdl.c -- it'd be better to change our code than to require changes in ltdl.c each time we upgrade. I doubt upgrading libtool and ltdl has any real software effect, other than allowing R= to work. But being able to use unmodified sources does have a good maintenance effect. >> 3. CVS and branching is pitiful. CVS is also otherwise not very good. >> I suggest p4 (it's free for open source use), but barring that, svn. > > Hmm... subversion doesn't do multiple repositories, and it requires > everyting but the kitchen sink to build. I'm using perforce at work, > and it's fine (if a little odd). For open source VCS's, I'd prefer > mercurial. Don't know mercurial, and don't know svn well enough to argue for it (except vs CVS). I will say that I'm surprised that a long list of dependencies is an issue -- what system today (that we care about) doesn't have either binary svn or an easy way (yum, apt-get, etc) to get dependencies? I'd be willing to host a p4 server on a trial basis, and possibly even long term. -frank

2 3

Automatic report from sources (radiusd) between 14.06.2006 - 15.06.2006 GMT
by Automatic cvs log generator 15 Jun '06

15 Jun '06

CVS log entries from 14.06.2006 (Wed) 08:00:02 - 15.06.2006 (Thu) 08:00:03 GMT ===================================================== Summary by authors ===================================================== Author: aland File: radiusd/doc/configurable_failover; Revisions: 1.10 File: radiusd/doc/load-balance.txt; Revisions: 1.5 File: radiusd/src/main/modcall.c; Revisions: 1.51, 1.50, 1.49 Author: pnixon File: radiusd/raddb/users; Revisions: 1.13 ===================================================== Combined list of identical log entries ===================================================== Description: Document "if", "else", and "elsif" in modules sections. Modified files: File: radiusd/doc/configurable_failover; Revision: 1.10; Date: 2006/06/14 23:31:30; Author: aland; Lines: (+120 -8) File: radiusd/doc/load-balance.txt; Revision: 1.5; Date: 2006/06/14 23:31:30; Author: aland; Lines: (+55 -2) ===================================================== Log entries ===================================================== Description: Shell-User should be Administrative-User these days Modified files: File: radiusd/raddb/users; Revision: 1.13; Date: 2006/06/14 15:16:39; Author: pnixon; Lines: (+1 -1) ------------------------------- Description: else and elsif can't be used in load-balance sections, as we would pick the "else" without the "if".. Modified files: File: radiusd/src/main/modcall.c; Revision: 1.51; Date: 2006/06/14 23:30:58; Author: aland; Lines: (+19 -1) ------------------------------- Description: Bump the stack max to 32 Modified files: File: radiusd/src/main/modcall.c; Revision: 1.50; Date: 2006/06/14 22:12:07; Author: aland; Lines: (+2 -2) ------------------------------- Description: Indent lines in debug mode after "modcall:", so we can see what's going on. Add lineno to modcallable struct, it may be useful later. Add group name to dump_tree stuff. Add support for "if", "elsif", and "else" to modules! We can now do things like: users if notfound { ldap } elsif updated { foo } else { eap } This allows multiple branches in the module calling code, where previously it allowed only "next module", or "return". Modified files: File: radiusd/src/main/modcall.c; Revision: 1.49; Date: 2006/06/14 17:40:54; Author: aland; Lines: (+227 -33) ===================================================== Summary of modified files ===================================================== File: radiusd/doc/configurable_failover Revisions: 1.10 Authors: aland (+120 -8) ------------------------------- File: radiusd/doc/load-balance.txt Revisions: 1.5 Authors: aland (+55 -2) ------------------------------- File: radiusd/raddb/users Revisions: 1.13 Authors: pnixon (+1 -1) ------------------------------- File: radiusd/src/main/modcall.c Revisions: 1.51, 1.50, 1.49 Authors: aland (+19 -1), aland (+2 -2), aland (+227 -33) -- Automatic cron job from /web/pages/us.freeradius.org/bin/new_makelog.pl

1 0

proxy_fail_type attribute
by Geoffroy Arnoud 14 Jun '06

14 Jun '06

Hi, I just get the last CVS update, and I discovered a "hidden" attribute in mainconfig.c, name "proxy_fail_type". By reading the source code, my understanding is that setting this attribute to "fail" (for example) in proxy.conf, and setting the value "fail" for Post-Proxy-Type in dictionary.freeradius.internal, will allow FreeRADIUS to execute a module when the proxy of a request failed (no response from server or other cases). My 1st question: - Am I right (or near to the truth)? I saw that this was not shipped into 1.1.2. But this feature appeared by the end of 2004. So my 2nd and 3rd questions are: - Has anyone used or is anyone using this feature on production deployement? - Is this feature planned to be shipped in 1.2.x? If I'm right about the behaviour, we may plan to deploy this feature (and therefore test it). So this leads me to another question: what is the best to do? Take last stable release and patch it to get the functionnality or take a CVS snapshot? Thank you in advance. Geof.

2 1