Issues with building Freeradius on CentOS 6.5: need rlm_cache

Brandon Jozsa bjozsa at gmail.com
Fri Jun 13 11:14:20 CEST 2014


In line (same as you).


On Fri, Jun 13, 2014 at 4:47 AM, Arran Cudbard-Bell <
a.cudbardb at freeradius.org> wrote:

>
> On 13 Jun 2014, at 09:32, Brandon Jozsa <bjozsa at gmail.com> wrote:
>
> > Hello,
> >
> > I've been trying to work through the issues and by searching high and
> low for solutions before turning to this users list. I'm sorry if this is a
> stupid question (I've seen worse though, so maybe I shouldn't feel bad).
> >
> > I have a very high need to use the rlm_cache module with Freeradius on
> CentOS 6.5. I'm trying to first us the statement:
> >
> > ----- snipped -----
> >
> > authorize {
> >         if (!notfound) {
> >                 update control {
> >                 Proxy-To-Realm := "SOME_REALM"
> >                 }
> >         }
> > ----- snipped -----
> >
> > which works GREAT alone...but I also want to use the cache function like
> so:
> >
> > ----- snipped -----
> >         update control {
> >                 Cache-Status-Only = 'yes'
> >         }
> >         cache
> >         if (notfound) {
> >                 sql
> >         }
> >         update control {
> >                 Cache-Status-Only := 'no'
> >         }
> >         cache
>
> In 3.0.4 that will be.
>
> update control {
>         Cache-Read-Only = 'yes'
> }
> cache
> if (notfound) {
>         sql
>         cache
> }
>
> Much nicer :)
>

I like it! Can't wait to play around with the new version...when CentOS
finally catches up!


>
>
> > which doesn't work (obviously) because rlm_cache isn't included with
> 2.1.12, or so it seems anyway.
>
> Yep.
>
> > My hope is (it is a hope anyway) that I can collect authN/authZ replies
> from an upstream radius server and cache them locally; thus building a
> mysql database of users access/privileges and let this run on an
> environment before cutting completely over to our new Freeradius setup.
> Again, I'm hoping it can work like this...getting rid of RSA and using
> LinOTP or MOTP would be so nice;
>
> Yubikey FTW.
>

Good suggestion, I will check it out. Thanks for the tip.


>
> > it would be more flexible and user friendly, but I really need to
> collect authN and authZ in order to rebuild our massive user-base.
> >
> > My issue...CentOS, which is our "approved platform" (I'm rolling my eyes
> and giving air quotes), doesn't have a newer version of Freeradius other
> than 2.1.12. I think the rlm_cache modules are only included in 3.0.0 and
> higher, is that right?
>
> No, a cut down version is also present 2.2.x from 2.2.0, and working since
> 2.2.1.
>

So, I'm not crazy...and what I want to do can actually be done? Reading
through a lot of the documentation, that seemed to be an appropriate way to
forklift a Freeradius solution into our environment...a TRUE forklift, if
it can be done this way.


>
> > So, I started looking on how to build from source...and I found one;
> great news I thought!! Enter:
> http://confluence.diamond.ac.uk/display/PAAUTH/FreeRADIUS+specs+and+sources+for+CentOS+6.
> I thought this would save the day, but there are broken links for 3.0.0 and
> I am running into major issues;
>
> There are spec files for RHEL bundled with the source, chances are you can
> just use those...
>

Didn't seem to work, like I mentioned below. Wasted a lot of time trying to
go down that route.


>
> > it just doesn't seem to work at all. I also tried to build it out, take
> the rlm_cache.so lib over to my 2.1.12 installation, but Freeradius barfed
> all over that little trick.
>
> In FreeRADIUS 3.0.x we added explicit validation checks to stop people
> trying to do stuff like that. There's no guarantee the ABI of libfreeradius
> will be compatible between versions, and given how frequently the internal
> API changes, there's a good chance it won't be.
>

Makes sense, and I can understand why...it's a way to control things. I
think some of the suggestions to use version 2.2.5 may be an option, and
not really break anything. That's even something that would compile
easier...worst case scenario. Thanks for the tips everyone! Really glad to
be part of the group and even help contribute!


-Arran
>
> Arran Cudbard-Bell <a.cudbardb at freeradius.org>
> FreeRADIUS Development Team
>
> FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
>
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>



-- 
Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20140613/fe4efa4b/attachment.html>


More information about the Freeradius-Users mailing list