Instantiating modules

Matthew Newton mcn4 at
Thu Mar 14 17:25:51 CET 2013

On Thu, Mar 14, 2013 at 03:04:08PM +0000, Jonathan Gazeley wrote:
> On 14/03/13 14:26, Matthew Newton wrote:
> >Just put it in the global instantiate section, as above, then use
> >it in the virtual server.
> The point of my exercise is to make my FreeRADIUS config fully
> modular in preparation for my suite of RADIUS servers being managed
> by a config management tool, and therefore edits to a global file
> are not helpful.
> I suppose I could set up an includes.d/ arrangement so snippets of
> file can be dropped into place in the global config, but really I
> would rather solve the problem "properly" by loading only the needed
> modules in virtual servers.
> Any suggestions?

A "virtual server" is essentially a collection of config blocks
for authorize/authenticate/accounting, etc, that call modules in
the main server. You can configure the server to send particular
packets (using listen statements, or options in clients.conf, or,
e.g. EAP virtual server settings) through a particular "virtual
server" - i.e. a particular config.

That's it - it's a configuration. The modules are global to the
server, so what you did first was right.

For config management, if you really don't want it instantiated on
some servers, I guess you could $INCLUDE a file instead of the
instantiate{} block, and move this to a separate file dependent on
the server. We do this sort of thing with cfengine, often using a
symlink with the hostname in it, and the $INCLUDE is to the
symlink. Then have one file per server with the required config.



Matthew Newton, Ph.D. <mcn4 at>

Systems Specialist, Infrastructure Services,
I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom

For IT help contact helpdesk extn. 2253, <ithelp at>

More information about the Freeradius-Users mailing list