[EXT] Integration GO language into Freeradius

[Brian Julin]

Arran wrote:
> Especially with async in v4.  Doing blocking I/O in a dynamic language becomes the quickest way to kill the performance of the server.

> If people really wanted to avoid REST it'd be fairly easy to make rlm_exec execute long running processes, especially since all the exec code in v4 is fully async (what a complete PITA that was).  That'd avoid the overhead of starting up and shutting down processes every time a request came through. But then you need some awful hacked together pipe based FFI/CGI thing... and just... why... Every language has a lease one HTTP framework.  Go probably has several hundred by this point.

> The REST support in v4 is much better.  It's got one of the new style argument based xlats that allows custom bodies to be sent, and a JSON module that allows custom encoding of request, and parsing of responses.

Sounds good.  I last looked at rlm_rest several years ago and it was tied in primarily to the auth/autx/etc stage model and not very useful for generic stuff.

Primarily when I have used either rlm_exec or rlm_perl, it has been integration with other services like MFA or feeding data into security appliances.  Mostly it has been no-wait stuff where we just need timely data to leave FreeRADIUS and kick off a sequence of events which involve interacting with rather complicated APIs.

Something worth mentioning on the relative merits of unlang versus external scripts, is what happens on a HUP... IIRC for unlang and other configuration directives, only syntax/config nodes that change actually get touched, whereas an external script needs to be reread in its entirety and if it is carrying state, it will need to restore that somehow.