Re: CASE CLOSED... Re: "peer" authentication: cannot make "pg_ident.conf" work as I believe that the doc says that it should

Поиск
Список
Период
Сортировка
От Bryn Llewellyn
Тема Re: CASE CLOSED... Re: "peer" authentication: cannot make "pg_ident.conf" work as I believe that the doc says that it should
Дата
Msg-id 64378C11-EA7F-4975-9508-B534841F49D1@yugabyte.com
обсуждение исходный текст
Ответ на Re: CASE CLOSED... Re: "peer" authentication: cannot make "pg_ident.conf" work as I believe that the doc says that it should  (Adrian Klaver <adrian.klaver@aklaver.com>)
Ответы Re: CASE CLOSED... Re: "peer" authentication: cannot make "pg_ident.conf" work as I believe that the doc says that it should  (Adrian Klaver <adrian.klaver@aklaver.com>)
Список pgsql-general
adrian.klaver@aklaver.com wrote:

bryn@yugabyte.com wrote:

This, on the other hand:

psql -d postgres -U 'clstr$mgr'

calls for "local", "peer" authentication as so it does NOT require a password. That would be enough for me. But, naturally, and now that it's working. I prefer the Peter-inspired bare "psql".

Personally, I use longer forms like above as a form of explicit is better then implicit. There are no end of posts to this list where the issue was someone or something had changed a 'hidden' value in a env variable or conf file could not connect or connected to wrong cluster and/or database.

Yes. I think the same as you about being explicit (in programs and scripts). That's why the "create role" statement that I showed mentioned every settable attribute. It's relatively rare that my requirement is "use the reigning defaults, whatever they might be now and whatever they might be changed to later". (Having said this, that for me rare scenario is proper in certain cases.)

So when I write a script to connect as "clstr$mgr", I'll use the explicit form that calls for "local", "peer" authentication and that uses the "-d" and "-U" flags. And I'll add a comment to say that, because the script is run only on the cluster's host machine after logging in as the O/S user "clstr_mgr", the (only) required password challenge has already been met. I plan to stage all of my "PG multitenancy by imposed convention" code in a dedicated Yugabyte, Inc GitHub repo. This will allow the code comment that I mentioned to x-ref the README.md that explains how I set up "pg_hba.conf" and "pg_ident.conf" to define the mapping between the O/S principal and its partner within-cluster principal.

This thinking extends, of course, to:

psql -d postgres -U 'postgres'

having logged in as the O/S user "postgres". (And here, I can simply "set role" to "clstr$mgr" when I need to without exiting one session, logging in as a different O/S user, and then starting a new session.)

But when I'm working interactively, I might well allow myself to type the bare minimum, on the fly, that gets the result.

В списке pgsql-general по дате отправления:

Предыдущее
От: Adrian Klaver
Дата:
Сообщение: Re: CASE CLOSED... Re: "peer" authentication: cannot make "pg_ident.conf" work as I believe that the doc says that it should
Следующее
От: Adrian Klaver
Дата:
Сообщение: Re: CASE CLOSED... Re: "peer" authentication: cannot make "pg_ident.conf" work as I believe that the doc says that it should