Issues with building Freeradius on CentOS 6.5: need rlm_cache

[Brandon Jozsa]

On Mon, Jun 16, 2014 at 9:37 AM, Arran Cudbard-Bell <
a.cudbardb at freeradius.org> wrote:

>
> On 16 Jun 2014, at 14:23, Brandon Jozsa <bjozsa at gmail.com> wrote:
>
> > I'm using v.2.2.5, not 3.0.x; I have no complaints with 3.0 at all.
>
> I know. I was saying the update {} style was adopted for most maps in
> v3.0.x.
>

makes better sense now, and i see what you're saying. coffee is starting to
do it's magic.


> > I definitely want to move towards it, I just fear that it will break too
> many things if I implement it on CentOS 6.5 right now. But, I'll look at
> http://wiki.freeradius.org/guide/Red-Hat-FAQ and build out from source,
> and/or try the updated .rpm's listed above.
> >
> > This is all my misunderstanding entirely, and respectfully I apologize.
> I was thinking since Freeradius already had the hooks in the * database,
> the cache module would use those hooks to create any unrecognized
> attributes/tables, but as I'm writing this I'm practically laughing at
> myself.
>
> Ah. No, that's not what the Cache module does. It uses an in memory tree
> to cache sets of attributes against a configurable key.
>
>
And this definitely makes sense by what I'm seeing in the debug. I see this
information pass and the cache module picking it up (thank you for making
this information useful and readable).


> > It's great it thought, but it would be a massive addition and it would
> require a lot of time to develop. This is basically what I'm after, so I'll
> have to get to it...there's a lot more work to be done.
>
> It's just a bunch of inserts, but i'm not sure how you're hoping to gather
> info from the *response* of the RSA server. I'd doubt
> it would include any useful information.
>
> If you're looking to populate the user db with passcodes then that's fine,
> just add some logic in post-proxy to detect when it's
> a passcode request (as opposed to pin code), and insert rows into
> radcheck...
>

Well, that's the thing. I'm not trying to capture any user authN. You're
right, that's not going to do very much good. What I am trying to do is
capture and build a authZ table. The RSA server is ready to die. I need to
pull authZ attributes and somehow capture/record them per user/device. I
don't know of a good way to do this, but the hope was to forklift the
solution into place and then just say "heck with the authN", rebuild that
part using OTP or some other solution, and retain the authZ backend
attributes. Big task? haha! :) I don't even know if it entirely makes
sense, but it does in my mind.

But if this can be done, I want to write a step-by-step article (online) so
that others can do the same once I'm able to figure this out. Am I going to
a road to no-where?


>
> -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/20140616/c7740fe4/attachment-0001.html>