On Mon, Mar 6, 2017 at 8:14 PM, Adam Brightwell <
adam.brightw...@crunchydata.com> wrote:
> On Mon, Mar 6, 2017 at 10:24 AM, Adam Brightwell
> wrote:
> >>> I wonder if removing the complexity of maintaining two separate lists
> >>> for the server and port would be a better/less complex approach.
On Mon, Mar 6, 2017 at 10:24 AM, Adam Brightwell
wrote:
>>> I wonder if removing the complexity of maintaining two separate lists
>>> for the server and port would be a better/less complex approach. For
>>> instance, why not go with a list of typical 'host:port' strings for
>>> 'radiusservers'?
>> I wonder if removing the complexity of maintaining two separate lists
>> for the server and port would be a better/less complex approach. For
>> instance, why not go with a list of typical 'host:port' strings for
>> 'radiusservers'? If no port is specified, then simply use the default
>> for t
On Friday, March 3, 2017, Adam Brightwell
wrote:
> I've given an initial review of this patch. It applies cleanly and
> compiles without issue as of 6da9759. I'm going to continue with
> testing it against a set of RADIUS servers in the next few days. But
> in the meantime, I have a few question
I've given an initial review of this patch. It applies cleanly and
compiles without issue as of 6da9759. I'm going to continue with
testing it against a set of RADIUS servers in the next few days. But
in the meantime, I have a few questions (below).
> It supports multiple RADIUS servers. For all
In a discussion at
https://www.postgresql.org/message-id/55d51b54.4050...@joh.to we talked
about adding RADIUS fallback servers. It never got to the point of it being
done.
PFA a patch that implements this.
It supports multiple RADIUS servers. For all other parameters (secret,
port, identifier) o
