Taking over maintainence of dialupadmin
Hi All, Are there any volunteers interested in taking up maintanence of dialupadmin? I'm pretty sure it's no longer compatible with rlm_ldap, and compatibility will probably decline as more of the FR3 configuration is normalised. If no one steps forward I vote for removing it from the master branch. It's very old (PHP3), hard to maintain, and i'm honestly not sure if that many people use it. Hopefully by removing it we could encourage someone to start another GUI project. -Arran
Hi,
Are there any volunteers interested in taking up maintanence of dialupadmin?
I'm pretty sure it's no longer compatible with rlm_ldap, and compatibility will probably decline as more of the FR3 configuration is normalised.
If no one steps forward I vote for removing it from the master branch. It's very old (PHP3), hard to maintain, and i'm honestly not sure if that many people use it. Hopefully by removing it we could encourage someone to start another GUI project.
The file extension is .php3 but was originally intended to be changed to .php for FR3 - it meanwhile is valid php5 inside. I know it because at one point I ported the old PHP3 code to PHP5, and the fixes got included in the source at some point. I'm one of those using it (but only for scanning through accounting records, no actual user manip). That said, I still wouldn't be too sad if it goes away. The whole approach is not exactly contemporary, and a new tool from scratch would be nice. However: I won't be the one writing it :-/ Stefan -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
On Tue, 15 Jan 2013 15:50:35 -0800, Arran Cudbard-Bell <a.cudbardb@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.
and compatibility will probably decline as more of the FR3 configuration is normalised.
What do you mean by that? As far as I've seen, dialupadmin is not bound or dependent on the configuration files, so you must mean something else. Cheers. -- Octavio.
On 16 Jan 2013, at 21:46, Octavio Alvarez <alvarezp@alvarezp.ods.org> wrote:
On Tue, 15 Jan 2013 15:50:35 -0800, Arran Cudbard-Bell <a.cudbardb@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-avail... It's specified there and parsed at various bits in the code. https://github.com/FreeRADIUS/freeradius-server/blob/master/dialup_admin/con...
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.
participants (3)
-
Arran Cudbard-Bell -
Octavio Alvarez -
Stefan Winter