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"

[Bryn Llewellyn <bryn@xxxxxxxxxxxx>]

adrian.klaver@xxxxxxxxxxx wrote:

bryn@xxxxxxxxxxxx wrote:

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

That is not true.... [sudo vi some-file] which opens [it for editing].

By all means. I didn't bother to spell that out;

It isn't you where using pg_ctl and in the Debian/Ubuntu packaging the better option for that is pg_ctlcluster. I generally use the systemd scripts to start/stop Postgres instances, though when I do pg_lsclusters I tend to fall into using pg_ctlcluster as the cluster info is right there.

Can't parse this. Sorry.

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?

Yes and since that is basically coloring outside the lines, then that leads to ... blowing up ... Per the saying, "In a ham and eggs breakfast the chicken is involved but the pig is committed", right now you are involved in the Debian/Ubuntu process but not committed. Until you commit you will not get the results you want.

Fair enough. I started again from the state where my "config_file", my "hba_file", and my "ident_file" are all customized as I want them to be but where I hadn't yet tried to trash my cluster and re-create it. Then I tried with "pg_dropcluster --stop" and "pg_createcluster". I discovered immediately that this approach (in contrast to the "initdb" approach) blows away all the *.conf files and recreates them in canonical form—just as the "man" page says. This is a bit of a nuisance. But it's negotiable. I installed my files as I want them in a safe place, outside of the entire PG world, and then used this script:

sudo pg_dropcluster --stop 11 main

sudo pg_createcluster 11 main \

  -e UTF8 --locale=C --lc-collate=C --lc-ctype=en_US.UTF-8 \

  -d /var/lib/postgresql/11/main \

  > /dev/null

sudo cp /etc/ybmt-code/pg-and-yb-config-files/*.conf \

                    /etc/postgresql/11/main

sudo chown postgres /etc/postgresql/11/main/*.conf

sudo chgrp postgres /etc/postgresql/11/main/*.conf

sudo chmod 644      /etc/postgresql/11/main/*.conf

sudo chmod 640      /etc/postgresql/11/main/pg_hba.conf

sudo chmod 640      /etc/postgresql/11/main/pg_ident.conf

sudo pg_ctlcluster start 11/main

sudo -u postgres psql -c " select name, setting from pg_settings where category = 'File Locations'; "

sudo -u postgres psql -f /etc/ybmt-code/cluster-mgmt/01-initialize-brand-new-YB-or-PG-clstr/00.sql

It worked without error and had the intended effect. My old approach with the uncommitted chicken used to take ~3 sec. This new approach takes ~5 sec. The difference is completely unimportant.

For various reasons, I need the non-standard "--lc-collate=C" choice. I could doubtless leave all the other options unspecified. But that's the style discussion we had the other day—and I prefer, here, to self-doc my choices.

I discovered that using, say, the "initdb" approach, then the "kosher" approach, and then the "initdb" approach brought all sorts of errors. That's the beauty of using a VM and file backups (or snapshots). I suppose this is to be expected.

Can I declare victory, now, with the approach that I showed above?

I'm impatient to get back to my real project.

p.s. Is my pessimism justified—that there simply exists no plain English user guide for this whole Debian/Ubuntu apparatus—correct. Or is it, rather, that my search skills are just too feeble?