Andrei Koulik wrote:
> BN> When RADIUS checks the users, it first attempts to expand Group-Name via.
> BN> the groups file, and uses the check items (if any) returned from the ex-
> BN> pansion.
>
> I had the same problem some time ago. It was the reason of writing the
> rml_dbm module.
>
> The main idea is group support as the specificity of associative database
> ('key - values' structure) doesn't allow us to use several entities with same
> username. The second - allow more then one checklist-replylist pairs in a
> user record.
But what is the key in the DBM if you allow multiple entities with
the same username? We have a solution similiar to yours, but with
some horrible hacks (I didn't do it) to support this.
> Now I have db database with about 120 thousands user records and 18 user's
> groups. I use perl script to manage database but you can use rlm_dbm_cat,
> dbm_parser to do it. There is no need to restart radius server after
> changing user database. Fragments of group file (groups.uft) and user
> entries follow:
The database has to be updated real time from the customer handling
system anyway, so I'll have to do it in Perl anyway. However changing
the existing code to support DBM instead of GDBM should be trivial com-
pared to implementing LDAP-support in it..
Anyway, this is more or less exactly what I was looking for. Thanks a
lot for writing it!
> I can't write good manual for rlm_dbm, due low English experience
> But if any body may do it please do not hesitate contact me.
If I ever get comfortable with rlm_dbm, I can do it (though my english
is no better than yours.. :)
--
We tend to meet any new situation by reorganising; and a wonderful method
it can be for creating the illusion of progress while producing confusion,
inefficiency and demoralisation. -- Gaius Petronius, 60 AD
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
