Thread: Location of pg_rewind/RewindTest.pm and ssl/ServerSetup.pm

Location of pg_rewind/RewindTest.pm and ssl/ServerSetup.pm

From
Andrew Dunstan
Date:
These two files are used by TAP test suites but fall foul of the
tightening of perl's searchpath rules. See for example
<https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=bowerbird&dt=2019-02-07%2000%3A10%3A31>

The obvious solution is to perform the same surgery for the ssl and
pg_rewind tests that we performed for genbki.pl and other scripts, but
in these cases the used modules are not in the same directory as the
using scripts, but in their parent directories. I can't think of a good
reason for this.They clearly relate to the TAP test suites, and nothing
else, so it seems to me that they should go into the same directory as
the TAP test scripts. There should be no danger that "prove" will try to
run them, as it is only set up to run files with a ".pl" extension.

While we're at it, I think ServerSetup.pm should possibly be renamed to
something like SSLServer.pm (and the perl code adjusted accordingly)

Does anyone object to me making these changes?

cheers

andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: Location of pg_rewind/RewindTest.pm and ssl/ServerSetup.pm

From
Michael Paquier
Date:
On Wed, Feb 06, 2019 at 08:34:11PM -0500, Andrew Dunstan wrote:
> The obvious solution is to perform the same surgery for the ssl and
> pg_rewind tests that we performed for genbki.pl and other scripts, but
> in these cases the used modules are not in the same directory as the
> using scripts, but in their parent directories. I can't think of a good
> reason for this.They clearly relate to the TAP test suites, and nothing
> else, so it seems to me that they should go into the same directory as
> the TAP test scripts. There should be no danger that "prove" will try to
> run them, as it is only set up to run files with a ".pl" extension.
>
> While we're at it, I think ServerSetup.pm should possibly be renamed to
> something like SSLServer.pm (and the perl code adjusted accordingly)
>
> Does anyone object to me making these changes?

Not really if this eases the buildfarm coverage.  At the same time, it
seems to me that it could be a good idea to install those sub-modules.
--
Michael

Attachment

Re: Location of pg_rewind/RewindTest.pm and ssl/ServerSetup.pm

From
Andrew Dunstan
Date:
On 2/6/19 8:44 PM, Michael Paquier wrote:
> On Wed, Feb 06, 2019 at 08:34:11PM -0500, Andrew Dunstan wrote:
>> The obvious solution is to perform the same surgery for the ssl and
>> pg_rewind tests that we performed for genbki.pl and other scripts, but
>> in these cases the used modules are not in the same directory as the
>> using scripts, but in their parent directories. I can't think of a good
>> reason for this.They clearly relate to the TAP test suites, and nothing
>> else, so it seems to me that they should go into the same directory as
>> the TAP test scripts. There should be no danger that "prove" will try to
>> run them, as it is only set up to run files with a ".pl" extension.
>>
>> While we're at it, I think ServerSetup.pm should possibly be renamed to
>> something like SSLServer.pm (and the perl code adjusted accordingly)
>>
>> Does anyone object to me making these changes?
> Not really if this eases the buildfarm coverage.  At the same time, it
> seems to me that it could be a good idea to install those sub-modules.



I have made the changes, and the last errors should be clearing up now.
I think installing them is a separate project, although doing so is
probably reasonable given that we install other TAP test packages. OTOH
these are rather more specialised.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: Location of pg_rewind/RewindTest.pm and ssl/ServerSetup.pm

From
Andrew Dunstan
Date:
On 2/7/19 4:01 PM, Andrew Dunstan wrote:
> On 2/6/19 8:44 PM, Michael Paquier wrote:
>> On Wed, Feb 06, 2019 at 08:34:11PM -0500, Andrew Dunstan wrote:
>>> The obvious solution is to perform the same surgery for the ssl and
>>> pg_rewind tests that we performed for genbki.pl and other scripts, but
>>> in these cases the used modules are not in the same directory as the
>>> using scripts, but in their parent directories. I can't think of a good
>>> reason for this.They clearly relate to the TAP test suites, and nothing
>>> else, so it seems to me that they should go into the same directory as
>>> the TAP test scripts. There should be no danger that "prove" will try to
>>> run them, as it is only set up to run files with a ".pl" extension.
>>>
>>> While we're at it, I think ServerSetup.pm should possibly be renamed to
>>> something like SSLServer.pm (and the perl code adjusted accordingly)
>>>
>>> Does anyone object to me making these changes?
>> Not really if this eases the buildfarm coverage.  At the same time, it
>> seems to me that it could be a good idea to install those sub-modules.
>
>
> I have made the changes, and the last errors should be clearing up now.
> I think installing them is a separate project, although doing so is
> probably reasonable given that we install other TAP test packages. OTOH
> these are rather more specialised.



Also, SSLServer.pm contains a bunch of lines like this:


       copy_files("ssl/server-*.crt", $pgdata);


I think if we're going to export it maybe we should have a method to set
up the ssl directory with the required certificates.


cheers


andrew


-- 
Andrew Dunstan                https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



Re: Location of pg_rewind/RewindTest.pm and ssl/ServerSetup.pm

From
Michael Paquier
Date:
On Thu, Feb 07, 2019 at 04:10:35PM -0500, Andrew Dunstan wrote:
> Also, SSLServer.pm contains a bunch of lines like this:
>        copy_files("ssl/server-*.crt", $pgdata);
>
> I think if we're going to export it maybe we should have a method to set
> up the ssl directory with the required certificates.

Very good point.  Let's see if there is an actual use case for
shipping them.  Personally I have no actual uses for them, but perhaps
somebody else can have an argument good enough to justify it..
--
Michael

Attachment