Обсуждение: BUG #17940: PostgreSQL Installer For Windows Cannot Initialize Cluster When BeyondTrust Installed

Поиск
Список
Период
Сортировка

BUG #17940: PostgreSQL Installer For Windows Cannot Initialize Cluster When BeyondTrust Installed

От
PG Bug reporting form
Дата:
The following bug has been logged on the website:

Bug reference:      17940
Logged by:          Joel Rabinovitch
Email address:      joel.rabinovitch@tecsys.com
PostgreSQL version: 13.4
Operating system:   Microsoft Windows 10
Description:

Our developers do their work using a local PostgreSQL database server and
local schemas.

This is typically done by installing the Windows version of the PostgreSQL
installer from EnterpriseDB. Currently, version 13.4 (64-bit) of the
installer is being used.

Recently, our organization has installed BeyondTrust Privilege Management
software on our developer’s PCs. The software forces the developer to
authenticate when doing administrative tasks such as installing software and
adjusting environment variables.

When a developer attempts to install the PostgreSQL 13.4 database server,
the developer is authenticated and the software runs as an administrator.

The issue occurs when the installer initializes the database cluster. When
it attempts to do this, these are the following messages we see in the
installation logs:

[09:51:29] Running the post-installation/upgrade actions:
[09:51:29] Write the base directory to the ini file...
[09:51:29] Write the version number to the ini file...
Initialising the database cluster (this may take a few minutes)...
Executing C:\Windows\System32\cscript //NoLogo "C:\Program
Files\PostgreSQL\13/installer/server/initcluster.vbs" "NT
AUTHORITY\NetworkService" "postgres" "****"
"C:\Users\joelr\AppData\Local\Temp/postgresql_installer_7e15a7cf72"
"C:\Program Files\PostgreSQL\13" "C:\Data\PostgreSQL" 5432 "DEFAULT" 0
Script exit code: 1

Script output:
 WScript.Shell Initialized...
Scripting.FileSystemObject initialized...

Called CreateDirectory(C:\Data\PostgreSQL)...
Called CreateDirectory(C:\Data)...
Called ClearAcl (C:\Data\PostgreSQL)...
    Executing batch file 'rad58C94.bat'...
    C:\Data\PostgreSQL BUILTIN\Administrators:(I)(OI)(CI)(F)
                   NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
                   BUILTIN\Users:(I)(OI)(CI)(RX)
                   NT AUTHORITY\Authenticated Users:(I)(M)
                   NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)

Successfully processed 1 files; Failed processing 0 files

Removing inherited ACLs on (C:\Data\PostgreSQL)
    Executing batch file 'rad58C94.bat'...
    processed file: C:\Data\PostgreSQL
Successfully processed 1 files; Failed processing 0 files

WScript.Network initialized...
strParentOfDataDirC:\Data
logged in userTECSYS\joelr
Called AclCheck(C:\Data\PostgreSQL)
Called IsVistaOrNewer()...
    'winmgmts' object initialized...
    Version:10.
    MajorVersion:10
Executing icacls to ensure the TECSYS\joelr account can read the path
C:\Data\PostgreSQL
    Executing batch file 'rad58C94.bat'...
    processed file: C:\Data\PostgreSQL
Successfully processed 1 files; Failed processing 0 files

Called IsVistaOrNewer()...
    'winmgmts' object initialized...
    Version:10.
    MajorVersion:10
Ensuring we can write to the data directory (using icacls) to
TECSYS\joelr:
    Executing batch file 'rad58C94.bat'...
    processed file: C:\Data\PostgreSQL
Successfully processed 1 files; Failed processing 0 files

Called IsVistaOrNewer()...
    'winmgmts' object initialized...
    Version:10.
    MajorVersion:10
Granting full access to (NT AUTHORITY\NetworkService) on
(C:\Data\PostgreSQL)
    Executing batch file 'rad58C94.bat'...
    processed file: C:\Data\PostgreSQL
Successfully processed 1 files; Failed processing 0 files

Called IsVistaOrNewer()...
    'winmgmts' object initialized...
    Version:10.
    MajorVersion:10
Granting full access to CREATOR OWNER on (C:\Data\PostgreSQL)
    Executing batch file 'rad58C94.bat'...
    processed file: C:\Data\PostgreSQL
Successfully processed 1 files; Failed processing 0 files

Called IsVistaOrNewer()...
    'winmgmts' object initialized...
    Version:10.
    MajorVersion:10
Granting full access to SYSTEM on (C:\Data\PostgreSQL)
    Executing batch file 'rad58C94.bat'...
    processed file: C:\Data\PostgreSQL
Successfully processed 1 files; Failed processing 0 files

Called IsVistaOrNewer()...
    'winmgmts' object initialized...
    Version:10.
    MajorVersion:10
Granting full access to Administrators on (C:\Data\PostgreSQL)
    Executing batch file 'rad58C94.bat'...
    processed file: C:\Data\PostgreSQL
Successfully processed 1 files; Failed processing 0 files

    Executing batch file 'rad58C94.bat'...
    The files belonging to this database system will be owned by user
"joelr".
This user must also own the server process.

The database cluster will be initialized with locale
"English_Canada.1252".
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory C:/Data/PostgreSQL ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... windows
selecting default max_connections ... 20
selecting default shared_buffers ... 400kB
selecting default time zone ... US/Eastern
creating configuration files ... ok
running bootstrap script ... Execution of PostgreSQL by a user with
administrative permissions is not
permitted.
The server must be started under an unprivileged user ID to prevent
possible system security compromises.  See the documentation for
more information on how to properly start the server.
child process exited with exit code 1
initdb: removing contents of data directory "C:/Data/PostgreSQL"

Called Die(Failed to initialise the database cluster with initdb)...
Failed to initialise the database cluster with initdb

Script stderr:
 Program ended with an error exit code

Error running C:\Windows\System32\cscript //NoLogo "C:\Program
Files\PostgreSQL\13/installer/server/initcluster.vbs" "NT
AUTHORITY\NetworkService" "postgres" "****"
"C:\Users\joelr\AppData\Local\Temp/postgresql_installer_7e15a7cf72"
"C:\Program Files\PostgreSQL\13" "C:\Data\PostgreSQL" 5432 "DEFAULT" 0:
Program ended with an error exit code
Problem running post-install step. Installation may not complete correctly
 The database cluster initialisation failed.
Setting variable whoami from C:\Windows\System32\whoami 
Script exit code: 0

From what we can see, the initialization fails because the installer
executes as an administrator. However, the initialization of a database
cluster requires you to be a non-administrator.

We have a manual procedure to follow when this occurs, which involves the
following:

- Manually initializing the database cluster as a non-administrator using
the command in the logs.
- Installing the Windows service as an administrator using the command in
the logs.
- Reinstalling some of the PostgreSQL components.

The process works, but it is quite cumbersome.

Is there a way to work around this.  I checked to see if there is a
command-line option to bypass the initialization of the database cluster
and/or the service when running the Windows installer, but I did not see an
option to this,

Has anyone had a similar issue when using the PostgreSQL installer for
Windows when the BeyondTrust Privilege Management (or similar software) is
installed on their PC. If so, what have you done to resolve this.

We have been in contact with the company that develops the BeyondTrust
software, but they have not been able to help us correct the problem as of
yet.


Re: BUG #17940: PostgreSQL Installer For Windows Cannot Initialize Cluster When BeyondTrust Installed

От
"David G. Johnston"
Дата:
On Tue, May 23, 2023 at 2:24 PM PG Bug reporting form <noreply@postgresql.org> wrote:
The following bug has been logged on the website:

Bug reference:      17940
Logged by:          Joel Rabinovitch
Email address:      joel.rabinovitch@tecsys.com
PostgreSQL version: 13.4
Operating system:   Microsoft Windows 10
Description:       

Our developers do their work using a local PostgreSQL database server and
local schemas.

This is typically done by installing the Windows version of the PostgreSQL
installer from EnterpriseDB. Currently, version 13.4 (64-bit) of the
installer is being used.

This isn't a PostgreSQL bug.  Your original posting of this to the -general list is the most appropriate place on the official lists to ask for such help.  That said, the core community on these lists does not maintain the EDB installer and you may wish to use their support channels to get further assistance.

That all said, I'm not expecting the PostgreSQL side of this to be of much help.  The software installation and usage works just fine in typical environments.  As your special security restricted environment is the outlier you probably will either need to simply move along with your workaround or hope that vendor can figure out how to let the installer work in the manner it is designed to work.

David J.

Hi,

I realize it’s not a PostgreSQL database engine bug, but more of an EDB Installer bug.

I did contact Enterprise DB (EDB) and they suggested to log it in the pgsql-bugs mailing list, as I am using the “community” version of the Windows installer (i.e. no paid support).

Hopefully, someone from EDB will look at it and eventually address it.

 

In the end, the problem should be addressed by BeyondTrust as it is their software that is causing the problems. The issue has been that the vendor has been unable to resolve the issue to date. This is why I have been trying this “alternative” route instead.

 

Thanks,

 

Joel

 

From: David G. Johnston <david.g.johnston@gmail.com>
Sent: Tuesday, May 23, 2023 5:47 PM
To: Joel Rabinovitch <Joel.Rabinovitch@tecsys.com>; pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17940: PostgreSQL Installer For Windows Cannot Initialize Cluster When BeyondTrust Installed

 

ATTENTION: This email originated from outside of Tecsys. Use caution when clicking links or opening attachments. | Ce courriel provient de l'extérieur de Tecsys. Soyez prudent lorsque vous cliquez sur des liens ou ouvrez des pièces jointes.

 

On Tue, May 23, 2023 at 2:24 PM PG Bug reporting form <noreply@postgresql.org> wrote:

The following bug has been logged on the website:

Bug reference:      17940
Logged by:          Joel Rabinovitch
Email address:      joel.rabinovitch@tecsys.com
PostgreSQL version: 13.4
Operating system:   Microsoft Windows 10
Description:       

Our developers do their work using a local PostgreSQL database server and
local schemas.

This is typically done by installing the Windows version of the PostgreSQL
installer from EnterpriseDB. Currently, version 13.4 (64-bit) of the
installer is being used.

 

This isn't a PostgreSQL bug.  Your original posting of this to the -general list is the most appropriate place on the official lists to ask for such help.  That said, the core community on these lists does not maintain the EDB installer and you may wish to use their support channels to get further assistance.

 

That all said, I'm not expecting the PostgreSQL side of this to be of much help.  The software installation and usage works just fine in typical environments.  As your special security restricted environment is the outlier you probably will either need to simply move along with your workaround or hope that vendor can figure out how to let the installer work in the manner it is designed to work.

 

David J.

 



On Tue, May 23, 2023, 17:20 Joel Rabinovitch <Joel.Rabinovitch@tecsys.com> wrote:

Hi,

I realize it’s not a PostgreSQL database engine bug, but more of an EDB Installer bug.

I did contact Enterprise DB (EDB) and they suggested to log it in the pgsql-bugs mailing list, as I am using the “community” version of the Windows installer (i.e. no paid support).


While edb do (AFAIK) publish the source to the installer, I don't believe there are any outside contributors and there is no public process for the development of it. If they're claiming there's a community version of the installer itself I'd say they're incorrect. It does install the community version of postgres though - but your issue seems related to the installer rather than postgres itself. So there is nothing the community can do to help you there. 



Hopefully, someone from EDB will look at it and eventually address it.

 

In the end, the problem should be addressed by BeyondTrust as it is their software that is causing the problems. The issue has been that the vendor has been unable to resolve the issue to date. This is why I have been trying this “alternative” route instead. 


Yes it definitely sounds like the program is in BeyondTrust here. And if they are unable to resolve it maybe they shouldn't be trusted (pun intended). 

The installer always runs with elevated privileges I believe, but drops them when initializing the database. It seems BeyondTrust somehow breaks this process.. 

Bottom line is, unfortunately, that if it works without that product installed and fails with it, then you're stuck with having them fix it. 

/Magnus 

Hi,

Sorry for the delayed response. We will check the details and get back to you

On Tue, May 30, 2023 at 6:34 AM Magnus Hagander <magnus@hagander.net> wrote:


On Tue, May 23, 2023, 17:20 Joel Rabinovitch <Joel.Rabinovitch@tecsys.com> wrote:

Hi,

I realize it’s not a PostgreSQL database engine bug, but more of an EDB Installer bug.

I did contact Enterprise DB (EDB) and they suggested to log it in the pgsql-bugs mailing list, as I am using the “community” version of the Windows installer (i.e. no paid support).


While edb do (AFAIK) publish the source to the installer, I don't believe there are any outside contributors and there is no public process for the development of it. If they're claiming there's a community version of the installer itself I'd say they're incorrect. It does install the community version of postgres though - but your issue seems related to the installer rather than postgres itself. So there is nothing the community can do to help you there. 



Hopefully, someone from EDB will look at it and eventually address it.

 

In the end, the problem should be addressed by BeyondTrust as it is their software that is causing the problems. The issue has been that the vendor has been unable to resolve the issue to date. This is why I have been trying this “alternative” route instead. 


Yes it definitely sounds like the program is in BeyondTrust here. And if they are unable to resolve it maybe they shouldn't be trusted (pun intended). 

The installer always runs with elevated privileges I believe, but drops them when initializing the database. It seems BeyondTrust somehow breaks this process.. 

Bottom line is, unfortunately, that if it works without that product installed and fails with it, then you're stuck with having them fix it. 

/Magnus 



--
Sandeep Thakkar