Thread: 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"

On Mon, 2022-10-31 at 22:03 -0700, Bryn Llewellyn wrote:
> I followed Peter's recommendation NOT to put my "clstr_mgr" O/S user in the "postgres"
> group—having earlier had it there. But doing so brought this content-free error message
> on an attempt to authorize using the intended method:
> 
> Error: Invalid data directory for cluster 11 main

That*s a message from the *server*, which always runs under the same OS user.

> A bit of Googling got me to this on the pgsql-general list (from the Peter, in fact):
> 
> https://www.postgresql.org/message-id/20190909171519.GA7858%40hjp.at
> 
> on that very topic.
> 
> It seems that the error message is simply misleading and that it should read "Cannot read
> the config_file, hba_file, or ident_file" — as they are named in this query's output":
> 
> select name, setting
> from pg_settings
> where category = 'File Locations';
> 
> Sure enough, neither my hba_file nor my ident_file were readable by "all" (but they were
> readable by "group"). However, the config_file was readable by "all". I've no idea what
> the history of those permissions is. Maybe I changed something along the way. I s'pose
> that I'd better regard my present installation as a dress rehearsal and simply redo it
> starting by restoring my "bare" Linux VM from file backup.
> 
> Anyway, just to prove the point, I chmod'd my hba_file and my ident_file to make them
> readable by all. And the silly error message went away.
> 
> However, that feels wrong to me. It would seem proper to put any user who you want to
> set up for "local", "peer" authentication into the "postgres" group.
> 
> What do you (all) think?

I think that you are doing something very weird, but I have no idea what it is.
Please tell us the exact commands you ran.

The client user should *never* read the PostgreSQL configuration files, so if changing
the permissions (which you should *never* do) has an effect, you must be doing something
very strange, like trying to start the database server with the wrong user.

Yours,
Laurenz Albe
-- 
Cybertec | https://www.cybertec-postgresql.com

> The client user should *never* read the PostgreSQL configuration files, so if changing
> the permissions (which you should *never* do) has an effect, you must be doing something
> very strange, like trying to start the database server with the wrong user.

It smells of trying to *embed* PostgreSQL ?

But that would not go with the account of multi-tenancy that's been presented.

Karsten

david.g.johnston@gmail.com wrote:

bryn@yugabyte.com wrote:

It would seem proper to put any user who you want to set up for "local", "peer" authentication into the "postgres" group

Did you really mean to write that?

The postgres o/s user should be able to login using peer.  It is a one-way idea though.  Wanting to login using peer says nothing about whether the user getting that capability should be allowed to mess with the running server in the operating system.

As for the rest, all I see is that you are using an opinionated package manager to install software whose opinions you don't agree with.  Maybe there is some buggy behavior with respect to shared o/s db administration among users in a common group...you haven't demonstrated that one way or the other here.  I think it is pointless to have the o/s admin and postgres bootstrap user be anything but postgres and this whole thing is counter-productive.  But if you are going down to first principles maybe you should install from source and build your own "package" from that.

On 11/1/22 13:20, Bryn Llewellyn wrote:
>> david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com> wrote:
>>

> 

> <aside>
> I know that I've been told off for allowing "sudo" for "postgres". I'm 
> only experimenting on my laptop. But I want to be able to stop the 
> server, delete the datafiles, create a new cluster, and then start that 
> using a single script. I can't use "pg_ctl stop/start" because it 
> expects to find its config files on the data directory. (That's a 
> different story. And I'm not ready to ask about that yet.) So I use 
> "sudo systemctl stop/start postgresql" because this method looks in the 
> right place for the config files.

If you are going to use the Debian/Ubuntu packaging then you will need 
to follow its "rules".

See here:

https://wiki.debian.org/PostgreSql

https://ubuntu.com/server/docs/databases-postgresql

Also do:

man pg_wrapper

Your best bet is to systemctl to start stop Postgres, but if you want to 
use pg_ctl then you need to use the wrapped version. As example:

pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
14  main    5432 online postgres /var/lib/postgresql/14/main 
/var/log/postgresql/postgresql-14-main.log
15  main    5434 down   postgres /var/lib/postgresql/15/main 
/var/log/postgresql/postgresql-15-main.log

sudo pg_ctlcluster stop 14/main

pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
14  main    5432 down   postgres /var/lib/postgresql/14/main 
/var/log/postgresql/postgresql-14-main.log
15  main    5434 down   postgres /var/lib/postgresql/15/main 
/var/log/postgresql/postgresql-15-main.log

sudo pg_ctlcluster start 14/main

  pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
14  main    5432 online postgres /var/lib/postgresql/14/main 
/var/log/postgresql/postgresql-14-main.log
15  main    5434 down   postgres /var/lib/postgresql/15/main 
/var/log/postgresql/postgresql-15-main.log


There are more pg_*cluster* wrapped commands:

pg_archivecleanup  pg_buildext        pg_createcluster   pg_dump 
    pg_lsclusters      pg_recvlogical     pg_restorecluster 
pg_virtualenv
pg_backupcluster   pg_config          pg_ctlcluster      pg_dumpall 
    pg_receivewal      pg_renamecluster   pg_updatedicts
pg_basebackup      pg_conftool        pg_dropcluster     pg_isready 
    pg_receivexlog     pg_restore         pg_upgradecluster


> </aside>
> 
> Here's what my "pg_hba.conf" has:
> 
> *  local   all   bob   peer*
> 
> My experiment shows that my attempt to authorize  as "bob" using 
> "local", "peer" authorization fails when every config file is readable 
> only by "owner" and "group". And it shows that a sufficient fix is to 
> make just "postgresql.conf" readable by "all" (as I believe is the 
> intention). Of course, an alternative fix (in the sesne that it would 
> work) would be to have "postgresql.conf" not readable by all but to put 
> "bob" in the "postgres" group.
> 
> All this leads to an obvious question:
> 
> *«*
> *Given that all of the config files have been made readable by "group" 
> (in contrast to the regime for the data files), what is the intention of 
> this design? In other words, when is it proper to put an O/S user in the 
> "postgres" group? After all, if the answer is "never" than no privileges 
> on "postgres/postgres" files would ever have been granted to "group".*
> *»*
> 
> 
> 
> 
> 
> 
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com

On 11/2/22 15:31, Bryn Llewellyn wrote:
>> david.g.johnston@gmail.com <mailto:david.g.johnston@gmail.com> EARLIER 
>> wrote:
>>

> A strange mutual misunderstanding has arisen here. I suppose that it 
> must be my fault. I have no interest whatsoever in "going down to first 
> principles". And I most certainly never said that I want to "have the 
> o/s admin and postgres bootstrap user be anything but postgres". On the 
> contrary: I want just that. Saying this more abstractly, I want to 
> install PG (admittedly the old version 11) in a freshly created Ubuntu 
> 20.04 LTS VM. And I want to follow the reigning notions of proper 
> practice. As far as possible, I'd like to find that I simply get such an 
> outcome without explicit intervention—or at least by accepting all the 
> defaults.
> 

> I did exactly that. And I selected "Linux" and under that "Ubuntu". 
> Notice that I did NOT select "Debian", though it was on offer, because 
> that's not what I have. If Ubuntu and Debian were effectively the same, 
> then there wouldn't be two distinct choices. My choice took me here:

They use the same basic packaging and wrapper mechanism. They are 
separated out because, very simple explanation, Ubuntu is downstream of 
Debian and the version releases are not the same.



> In summary, then, I followed a link from the PG doc to a site whose URL 
> makes it sound "official", selected my environment, and followed some 
> simple steps as specified. That doesn't sound like "opinionated" to me. 
> Nor does it sound like stubbornly insisting on doing things my own way.

It is official as these are the community released packages.

The opinionated reference was to what the Debian/Ubuntu packaging does, 
not you.

> 
> Adrian gave me this link:
> 
> https://ubuntu.com/server/docs/databases-postgresql 
> <https://ubuntu.com/server/docs/databases-postgresql>
> 
> Of course I'd read that right at the outset. The subtext is loud and 
> clear. You need to do some things as the "postgres" user and some things 
> as "root". That's why I enabled "sudo" for "postgres" (just as the code 
> examples on that page imply).

You don't need to do that. Just use sudo as what ever user you log in 
as. For example:

aklaver@arkansas:~$ sudo pg_ctlcluster stop 14/main
[sudo] password for aklaver:

Again very simple explanation, the OS postgres user is just created to 
run the server. It does not even have a home directory.

> 
> However, I have no a priori requirement to use the root-needing 
> "systemctl" to stop and start my cluster. But I do want to be able to 
> use "initdb" so that I can simply trash an extant cluster and start 
> again from a well-defined, pristine state. (I want to do this to be 
> completely sure that my own scripts make no assumptions about 
> pre-existing objects.) This script works perfectly well:
> 
> *sudo systemctl stop postgresql
> 
> rm -Rf /var/lib/postgresql/11/main
> 
> initdb \
>    -U postgres --encoding UTF8 --locale=C --lc-collate=C 
> --lc-ctype=en_US.UTF-8 \
>    -A md5 --pwfile=/etc/ybmt-code/misc/.superuser-passwd-for-initdb \
>    -D /var/lib/postgresql/11/main
> 
> sudo systemctl start postgresql
> 
> psql -f <my_script.sql>
> *
> But it does require that my "postgres" O/S user is enabled for "sudo" — 
> which you all insist is a terrible crime, even on my personal laptop 
> that nobody else can access. Moreover, I'm using "initdb". This is 
> apparently verboten (it isn't exposed via a link on "/usr/bin")—in the 
> env produced by the installation procedure that the PG doc lead me to. 
> The same is true for "pg_ctl" and "postgres". A bit of Googling took me 
> here:

Again, when in Rome:

sudo pg_createcluster 15 test
Creating new PostgreSQL cluster 15/test ...
/usr/lib/postgresql/15/bin/initdb -D /var/lib/postgresql/15/test 
--auth-local peer --auth-host scram-sha-256 --no-instructions
The files belonging to this database system will be owned by user 
"postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /var/lib/postgresql/15/test ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... America/Los_Angeles
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Ver Cluster Port Status Owner    Data directory              Log file
15  test    5433 down   postgres /var/lib/postgresql/15/test 
/var/log/postgresql/postgresql-15-test.log

man pg_createcluster

for more options.


> So, apparently, Debian and Ubuntu are the same after all, even though 
> they have separate install pages from www.postgresql.org/download/linux 
> <http://www.postgresql.org/download/linux>.

The same as Debian and Ubuntu are.

> 
> Anyway, the examples show "sudo pg_ctlcluster ..." and that defeats the 
> aim of doing everything as the "postgres" user.

But as my example above shows you will be, in that the cluster will be 
owned by postgres.

> 
> This, I believe, is why Adrian wrote this:
> 
> «
> If you are going to use the Debian/Ubuntu packaging then you will need 
> to follow its "rules".

Which you have not been doing.

> But it seems that I'm now in a regime where critical PG utilities don't 
> work like the PG doc says, and where what you need, "pg_ctlcluster", 
> isn't even mentioned in the PG doc. (I do see that it's present in my 
> env and is properly wired up from "/usr/bin". (Actually, it's right 
> there on that directory as an executable file.)

Because they are package specific programs. You will find similar 
differences in the RH family packaging.

> 
> How can it be that the PG doc itself leads you by the hand to a regime 
> where you need to use undocumented features?

Because the docs are for the unpackaged version of Postgres, namely what 
you would get if you installed from source.

> 
> And, b.t.w., the debian.org site that Adrian linked me to is NOT 
> ordinary user-facing doc. Moreover, "pg_ctlcluster --help" fails with 
> "Unknown option: help". That's a terrible start. Of course I did "man 
> pg_ctlcluster". This doesn't give a single example of using the command. 
> It says that it "essentially wraps the pg_ctl(1) command". But what does 
> "essentially" mean—is that some flavor of "partially"? And it doesn't 
> hint at why wrapping is essential and why the bare command cannot be used.
> 
> Where is the ordinary, prose, account of what this is all about—and why 
> the ordinary documented PG executables cannot be used as intended. It's 
> the same story for "pg_createcluster" as a wrapper for "initdb".

They can be used as intended, though you may end up with Postgres 
clusters outside the place where the packaging expects them.


> 
> Yet, somehow, "systemctl start postgresql" happily manages to find my 
> customized config files in the location where I did the customization. 
> It's hard to imagine a more confusing design. What thinking underlies it?
> 

Don't customize, use the provided tools. The idea behind all this is to 
have the provided tools allow you to run multiple clusters of the same 
version or different versions of Postgres concurrently and have the 
tools take care of setting up the cluster data_dir and config_dir and 
assign ports.

-- 
Adrian Klaver
adrian.klaver@aklaver.com

 "Additionally, while reading the next chapter, Server Setup and Operation, is recommended if you are using a binary package the setup and operational environment it creates is likely to be somewhat different than what is described in this documentation.  Please read the documentation for the packages you install to learn how it behaves and what additional platform-specific features it provides."

adrian.klaver@aklaver.com wrote:

> david.g.johnston@gmail.com wrote:
>
> Some repetition of what Adrian just posted ahead...
>
>> bryn@yugabyte.com wrote:
>>
>> How can it be that the PG doc itself leads you by the hand to a regime where you need to use undocumented features?
>
> The documentation tries to make clear that if you use third-party packaging to install PostgreSQL (which most people
should)that the documentation for the packaging should describe this layer where PostgreSQL and the operating system
intersect. You even quoted it: "follow the instructions for the specific platform.", though reading that now I think
somethingalong the lines of: 
>
>  "Additionally, while reading the next chapter, Server Setup and Operation, is recommended if you are using a binary
packagethe setup and operational environment it creates is likely to be somewhat different than what is described in
thisdocumentation.  Please read the documentation for the packages you install to learn how it behaves and what
additionalplatform-specific features it provides." 
>
> Actually, not sure on the best approach here, since the Server Setup chapter already says:
>
> https://www.postgresql.org/docs/current/runtime.html
>
> "The directions in this chapter assume that you are working with plain PostgreSQL without any additional
infrastructure,for example a copy that you built from source according to the directions in the preceding chapters. If
youare working with a pre-packaged or vendor-supplied version of PostgreSQL, it is likely that the packager has made
specialprovisions for installing and starting the database server according to your system's conventions. Consult the
package-leveldocumentation for details." 
>
> However, that appears below-the-fold after a decent sized table of contents.
>
> Changing anything now feels like an over-reaction to a single incident, but I sympathize with the general confusion
allthis causes, and the fact it is only in the recent past that we've made this first attempt to rectify the situation
byadding these comments.  A second-pass based upon this encounter seems at least reasonable.  Whether I or others end
updeciding it is worth proposing a patch remains to be seen. 

Thanks for your explanations, David. I believe that my point about how all this seems to me is well taken. I might
concedethat the Debian/Ubuntu packaging provides adequate reference doc by implementing its "man" pages. But I haven't
foundanything like a user guide that explains *why* ordinarily documented PG features have been hidden from sight (but
notremoved) and how (if the Debian/Ubuntu alternatives are just wrappers for the native PG) one might do that wrapping
byhand. Doing this would demonstrate what benefits the wrapping brings. 

Anyway, I now have a working PG system and useful notes. When, presently, I make a second VM for PG 15 (I prefer
separateVMs over having both versions in the same VM) it should all go quickly and smoothly. 

I have no reason to describe to anybody else how to install and configure PG—and I certainly won't do this.

My interest in being able to re-establish the pristine cluster starting state reliably and quickly is to support my own
productivity.I'll presently have SQL scripts that establish the "multitenancy by self-imposed discipline" scheme that
I'vereferred to from any arbitrary state of population of a cluster. I don't intend my scheme to co-exist with other
schemes.And I don't expect there to be any real use cases for starting with an arbitrarily populated cluster and taking
itto a state that conforms with my scheme. Rather, all this is about demonstrating how to establish the scheme on the
assumption(but not requirement) that one starts with a brand-new cluster that will be dedicated to the approach that
I'vesketched. 

I'm looking forward to returning to that project and putting all that we've been discussing here behind me.

On 11/3/22 14:49, Bryn Llewellyn wrote:

> 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".)
> 

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

That is not true:

aklaver@arkansas:~$ whoami
aklaver


aklaver@arkansas:~$ sudo vi /etc/postgresql/14/main/pg_hba.conf
[sudo] password for aklaver:

which opens pg_hba.conf for editing.

> 
> 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"):
> 
> *sudo -u postgres vi pg_hba.conf*
> 
> 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:

You want to use local peer with OS user postgres, that is not a 
requirement. You could set up Postgres to log in the db user postgres by 
any of the other auth means and do the below without sudo(ing) to OS 
user postgres.

> 
> *sudo -u postgres psql -f my_script.sql*
> 
> With this in mind, I re-wrote my "clean start" script thus:
> 
> *#!/bin/bash
> 
> *
> *# do this as ANY user that can do "sudo" (and this includes "root" itself)
> 
> sudo pg_ctlcluster stop 11/main
> sudo rm -Rf /var/lib/postgresql/11/main
> 
> sudo -u postgres initdb \
>    -U postgres --encoding UTF8 --locale=C --lc-collate=C 
> --lc-ctype=en_US.UTF-8 \
>    -A md5 --pwfile=my_password_file \
>    -D /var/lib/postgresql/11/main
> 
> sudo pg_ctlcluster start 11/main
> 
> sudo -u postgres **psql -f my_script.sql**
> *
> It certainly works. And when it's finished, this:
> 
> *sudo -u postgres psql -c " select name, setting from pg_settings where 
> category = 'File Locations'; "
> *
> 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 
> <https://ubuntu.com/server/docs/databases-postgresql> recommends.

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.

> 
> 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 the below blowing up.

> 
> *sudo pg_dropcluster --stop 11 main
> sudo pg_createcluster 11 main
> sudo pg_ctlcluster start 11/main-
> *
> 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.

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 not committed. Until you commit you will not get the results you 
want.

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

-- 
Adrian Klaver
adrian.klaver@aklaver.com

On 2022-11-03 15:37:07 -0700, Adrian Klaver wrote:
> On 11/3/22 14:49, Bryn Llewellyn wrote:
> > So only "postgres" can edit the files that must be so edited.
>
> That is not true:
>
> aklaver@arkansas:~$ whoami
> aklaver
>
>
> aklaver@arkansas:~$ sudo vi /etc/postgresql/14/main/pg_hba.conf
> [sudo] password for aklaver:
>
> which opens pg_hba.conf for editing.

Well, yes. Root can edit the file, too. But root can edit anything[1].

        hp

[1] Except ... lots of stuff, actually.

--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

On 11/3/22 18:50, Bryn Llewellyn wrote:
>> adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com> wrote:


> 
>> 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.

Short version, use what works for you.


> 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" 

initdb will not work on an directory with existing files, so this:

sudo -u postgres initdb \
   -U postgres --encoding UTF8 --locale=C --lc-collate=C 
--lc-ctype=en_US.UTF-8 \
   -A md5 --pwfile=my_password_file \
   -D /var/lib/postgresql/11/main

Will only work if /var/lib/postgresql/11/main is empty, so none of your 
customized files will be there. You will have to copy them in just as 
you do below.

As example:

postgres@maura:/usr/local/pgsql15> bin/initdb -D data/
The files belonging to this database system will be owned by user 
"postgres".
This user must also own the server process.

The database cluster will be initialized with locale "en_US.UTF-8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

initdb: error: directory "data" exists but is not empty
initdb: hint: If you want to create a new database system, either remove 
or empty the directory "data" or run initdb with an argument other than 
"data".


FYI, you might want to take a look at the the includes mechanism:

https://www.postgresql.org/docs/15/config-setting.html#CONFIG-SETTING-CONFIGURATION-FILE


> 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.

Hence commitment instead of involvement.

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

You are setting the goals not us, that is your decision.

> 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?

Not that I know of.

-- 
Adrian Klaver
adrian.klaver@aklaver.com