Re: Putting the O/S user for "local" "peer" authentication in the "postgres" group vs chmod'ing the "pg*.conf" files to be readable by "all" - Mailing list pgsql-general

I should make it clear that my VM has four "ordinary" users. Two are present on first use when VM creation finishes: the system administrator (called "parallels") and, of course, "root". The "parallels" user is enabled for "sudo". Installing PG brings "postgres". (I created mine before hand, and it was unperturbed by the PG installation. This is my private laptop. And it suits me to give it a home directory and to customize its ".bashrc". But that's so that I can look around with the minimum of fuss.) Finally, there's my "clstr_mgr" O/S user that acts as the authorization vehicle for my "clstr$mgr" cluster-role. Each of "postgres" and "clstr_mgr" is in its own singleton group—and in no other groups. And neither is set up for "sudo".)

The doc explains how to edit (at least) these: the "config_file", the "hba_file", and the "ident_file". You edit them to achieve certain supported outcomes. I mentioned that, during my "for real" installation (from a re-established freshly created Ubuntu VM) I noted how the config files were set up:

So only "postgres" can edit the files that must be so edited.

Apparently, an unwritten rule says that one must never end up so that "whoami" shows "postgres". I see that I can, then, always do, for example, this (from "parallels"):

And, given that one major theme in our recent mutual, extended, exchanges is that I want to use "local", "peer" authentication for the cluster-role "postgres" via the O/S user with the same name, I see that I can always run all the SQL scripts that I want, using this authentication, like this:

With this in mind, I re-wrote my "clean start" script thus:

It certainly works. And when it's finished, this:

shows that my files are where they ought to be. Then, further tests show that "local", "peer" authorization works as intended for my "clstr$mgr" role and that I can connect from client machines. So all is good. 

Why, though, is "pg_ctlcluster stop/start... " preferred over "systemctl stop/start postgresql?". Both are quick enough. And I can't see any difference in effect. Moreover, the latter is what https://ubuntu.com/server/docs/databases-postgresql recommends.

Notice that I'm still using the off-limits "initdb" here. (I wired it up with a link on "/usr/bin".) Is there any reason to change that and to try to work out how to use what David (in an email soon after Adrian's) suggested?

I tried it. But it "did not work". I don't have the energy to describe the errors that were reported and the nasty outcomes that I got when I tried to use the new cluster. There's no useful doc for that approach and I've already established that Internet search gets me nowhere. So I'm inclined not to use it.

Rather, I want, now, simply to declare victory with the script that I showed and return to ordinary productive work.