Taking over maintainence of dialupadmin

[Arran Cudbard-Bell]

On 16 Jan 2013, at 21:46, Octavio Alvarez <alvarezp at alvarezp.ods.org> wrote:

> On Tue, 15 Jan 2013 15:50:35 -0800, Arran Cudbard-Bell
> <a.cudbardb at freeradius.org> wrote:
> 
>> Are there any volunteers interested in taking up maintanence of dialupadmin?
>> 
>> I'm pretty sure it's no longer compatible with rlm_ldap
> 
> Why is it not compatible with rlm_ldap? Please excuse the question, as I'm
> really new to FreeRADIUS.

That'd be because the external attrmap file doesn't exist anymore, it got converted into a section in the ldap module.

https://github.com/FreeRADIUS/freeradius-server/blob/master/raddb/mods-available/ldap#L53

It's specified there and parsed at various bits in the code.

https://github.com/FreeRADIUS/freeradius-server/blob/master/dialup_admin/conf/admin.conf#L67


>> and compatibility will probably decline as more of the FR3 configuration is normalised.
> 
> What do you mean by that?

That as the specification of things like clients and realms are made more flexible, and are no longer directly dependent on actual configuration files.

For example if you want to get the list of clients in 1.x.x you could just parse clients.conf. Now the clients can be specified dynamically using perl/python/sql/ldap whatever. Even the static clients definitions aren't always specified in an external file anymore.

The only viable solution for this is to finish the work in radmin, and convert it into a proper API, that can dispatch queries to the thread pool. Then the cannonical source of information about the server is the server... Or write a script to duplicate all the data.

> As far as I've seen, dialupadmin is not bound or
> dependent on the configuration files,
> so you must mean something else.

It depends on attrmap and clients.conf and the structure of the SQL database*. I'm ok with dumping it in its own repo if people really still want to use it. But I don't see the point of including something in the server that's not fully compatible with the current version of the server.

-Arran

* Which to be fair probably isn't going to change, though support for REDIS as a sql driver is being developed, and I want to add Cassandra at some point.