Re: [HACKERS] RADIUS fallback servers
От | Adam Brightwell |
---|---|
Тема | Re: [HACKERS] RADIUS fallback servers |
Дата | |
Msg-id | CAE_9P=iQCLtB0T=YL-pmCsQ=AQ5KTM21fpYJOs+k2ohZBa017w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] RADIUS fallback servers (Adam Brightwell <adam.brightwell@crunchydata.com>) |
Ответы |
Re: [HACKERS] RADIUS fallback servers
|
Список | pgsql-hackers |
On Mon, Mar 6, 2017 at 10:24 AM, Adam Brightwell <adam.brightwell@crunchydata.com> 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'? If no port is specified, then simply use the default >>> for that specific host. Therefore, we would not have to worry about >>> keeping the two lists in sync. Thoughts? >> >> >> If we do that we should do it for all the parameters, no? So not just >> host:port, but something like host:port:secret:identifier? Mixing the two >> ways of doing it would be quite confusing I think. >> >> And I wonder if that format wouldn't get even more confusing if you for >> example want to use default ports, but non-default secrets. > > Yes, I agree. Such a format would be more confusing and I certainly > wouldn't be in favor of it. > >> I can see how it would probably be easier in some of the simple cases, but I >> wonder if it wouldn't make it worse in a lot of other cases. > > Ultimately, I think that it would be better off in a separate > configuration file. Something to the effect of each line representing > a server, something like: > > '<server> <port> <secret> <identifier>' > > With 'radiusservers' simply being the path to that file and > 'radiusserver', etc. would remain as is. Where only one or the other > could be provided, but not both. Though, that's perhaps would be > beyond the scope of this patch. > > At any rate, I'm going to continue moving forward with testing this patch as is. I have run through testing this patch against a small set of RADIUS servers. This testing included both single server and multiple server configurations. All seems to work as expected. -Adam
В списке pgsql-hackers по дате отправления: