On 7/22/19 12:25 PM, Tom Lane wrote:
> I wrote:
>> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>>> Pushed with that note. Thanks.
>> This has completely broken the buildfarm.
> On inspection, it seems the reason for that is that the buildfarm
> script runs initdb with '-U buildfarm', so that peer-auth connections
> will only work if the buildfarm is being run by an OS user named
> exactly "buildfarm". That happens to be true on my macOS animals,
> which is why they're not broken ... but apparently, nobody else
> does it that way.
>
> I'm afraid we're going to have to revert this, at least till
> such time as a fixed buildfarm client is in universal use.
>
> As for the nature of that fix, I don't quite understand why
> the forced -U is there --- maybe we could just remove it?
> But there are multiple places in the buildfarm client that
> have hard-wired references to "buildfarm".
This goes back quite a way:
commit 7528701abb88ab84f6775448c59b392ca7f33a07
Author: Andrew Dunstan <andrew@dunslane.net>
Date: Tue Nov 27 13:47:38 2012 -0500
Run everything as buildfarm rather than local user name.
This will help if we ever want to do things like comparing dump
diffs.
Done by setting PGUSER and using initdb's -U option.
The pg_upgrade test (not the cross-version one) doesn't use this - it
explicitly unsets PGUSER.
There are a few things we could do. We could force trust auth, or we
could add an ident map that allowed $USER to login as buildfarm. Finding
all the places we would need to fix that could be a fun project ...
We could also maybe teach initdb to honor an environment setting
INTDB_DEFAULT_AUTH or some such.
I agree this should be reverted for now until we work out what we want
to do.
cheers
andrew
--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
