On 13.3.2017 16.54, a.l.m.bu...@lboro.ac.uk wrote:

There's -c option for radiusd. It will read the configuration and
checks what it can. It does not, for example, attempt to connect to
SQL databases, so it will not catch those types of problems.

it does appear to do RADSEC connections though. maybe SQL connectivity should
be part of the test (or an option with another flag?)

Correct, it seems that RADSEC hosts are activated and try to connect. Good catch, I'll see if this should be changed for config check.

A flag for testing external connections is probably needed since, for example, what we do in some cases is to run tests in a separate environment where connection attempts would not work. But I can see that in some cases the connectivity testing would be a better option.

We'll need to think about this.

There's actually work ongoing to enhance configuration checking.
Currently the output from -c is more for human consumption, so the
exit code, for example, does not reflect the check results. We are
looking at returning different exit codes depending of level of
problem (warning, error) from -c run.

yes, interesting timing on this query since I've been recently in contact
with OSC over this feature :)

Indeed :) What we have used is the wrapper that checks logs, but exit codes would be a useful addition too.

What you could do now is to wrap radiusd -c invocation with a script
that greps errors and warnings and then returns non-zero exit code.

...if you get output ;-)

To clarify this a bit for the list members, a couple of cases, such as badly formatted <Handler ...> selector is not logged during -c run yet. So this is under work too.


Heikki Vatiainen <h...@open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS, NetWare etc.
radiator mailing list

Reply via email to