Many of the modules use inconsistent names for the internal variables. We're going through and re-naming them for consistency. This may break third-party modules. Arran also fixed a number of issues in the EAP module, to remove duplicate code. This means that the dictionaries have been updated to match. Please ensure that the dictionaries you're using match the source, otherwise it won't work. I've also updated the server core to load all of the modules in raddb/mods-enabled. This means that the "instantiate" section of radiusd.conf becomes less relevant. You just need to list a module for it to be loaded. There is a side-effect. The build enabled some modules which won't always work (counter and inner-eap). Just delete those from raddb/mods-enabled/ if there's an issue. The "instantiate" section is still run first, as some modules depend on others. Using "instantiate" allows you to force loading order for some modules. After the "instantiate" section is run, all of the modules in the "mods-enabled" directory are loaded. After that, the virtual servers are loaded. This ordering makes the debug output a little easier to read. It would previously load the modules as it parsed the virtual servers. That meant the debug messages for the module config would be interspersed with the virtual server config. Now, they're all together in the "modules" section. The debug output should now be much easier to read. Alan DeKok.
Hi,
There is a side-effect. The build enabled some modules which won't always work (counter and inner-eap). Just delete those from raddb/mods-enabled/ if there's an issue.
'cui' is another - which requires configured SQL stuff to operate. not sure why counter doesnt work out of the box as its quick a simple thing comes up with rlm_counter: Counter attribute Daily-Session-Time is number 11273 rlm_counter: Failed to create check attribute Daily-Session-Time /etc/raddb/mods-enabled/counter[71]: Instantiation failed for module "daily"
This ordering makes the debug output a little easier to read. It
it does. everything gets exposed nicely rather than mixed in between the virtual servers... how I wished it was like this a long time ago! :-) alan
A.L.M.Buxey@lboro.ac.uk wrote:
'cui' is another - which requires configured SQL stuff to operate.
I've removed that from the default list of enabled modules. Arran had already updated it to use the rlm_sql_null driver, which meant (at least) that it worked.
not sure why counter doesnt work out of the box as its quick a simple thing comes up with
rlm_counter: Counter attribute Daily-Session-Time is number 11273 rlm_counter: Failed to create check attribute Daily-Session-Time /etc/raddb/mods-enabled/counter[71]: Instantiation failed for module "daily"
It was an argument order issue. I've pushed a fix.
This ordering makes the debug output a little easier to read. It
it does. everything gets exposed nicely rather than mixed in between the virtual servers... how I wished it was like this a long time ago! :-)
It depended on the move to mods-enabled / mods-available. Alan DeKok.
A.L.M.Buxey@lboro.ac.uk wrote:
'cui' is another - which requires configured SQL stuff to operate.
I've removed that from the default list of enabled modules. Arran had already updated it to use the rlm_sql_null driver, which meant (at least) that it worked.
not sure why counter doesnt work out of the box as its quick a simple thing comes up with
rlm_counter: Counter attribute Daily-Session-Time is number 11273 rlm_counter: Failed to create check attribute Daily-Session-Time /etc/raddb/mods-enabled/counter[71]: Instantiation failed for module "daily"
It was an argument order issue. I've pushed a fix.
This ordering makes the debug output a little easier to read. It
it does. everything gets exposed nicely rather than mixed in between the virtual servers... how I wished it was like this a long time ago! :-)
It depended on the move to mods-enabled / mods-available. Alan DeKok.
participants (2)
-
A.L.M.Buxey@lboro.ac.uk -
Alan DeKok