Horton

Thread

  1. BUG #18707: Installation issue

    PG Bug reporting form <noreply@postgresql.org> — 2024-11-14T08:41:36Z

    The following bug has been logged on the website:

Bug reference:      18707
Logged by:          Gursh Panesar
Email address:      gursharan.panesar@bnpparibas.com
PostgreSQL version: 15.8
Operating system:   Windows 10
Description:        

We have an issue installing version 15.8 using file
postgresql-15.8-1-windows-x64.exe.
The installation in our environment is run in the system context.
When the installation is run in the system context it writes to
C:\Windows\Temp folder and fails.
If the installation is run as admin, it writes to %LocalAppData%\Temp.
The previous version of the installer was able to run in system context and
install the application without any issue.

Each time the installation is run in system context, it generates a folder
with a different name so we cannot change the permission. If the temp folder
can have a fixed name, then it may be possible to change the permissions.

  2. Re: BUG #18707: Installation issue

    Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> — 2024-11-18T09:21:44Z

    Hi,

Could you share the installation log? It must be present in the temp. By
previous version, do you mean 15.7?

On Thu, Nov 14, 2024 at 7:51 PM PG Bug reporting form <
noreply@postgresql.org> wrote:

> The following bug has been logged on the website:
>
> Bug reference:      18707
> Logged by:          Gursh Panesar
> Email address:      gursharan.panesar@bnpparibas.com
> PostgreSQL version: 15.8
> Operating system:   Windows 10
> Description:
>
> We have an issue installing version 15.8 using file
> postgresql-15.8-1-windows-x64.exe.
> The installation in our environment is run in the system context.
> When the installation is run in the system context it writes to
> C:\Windows\Temp folder and fails.
> If the installation is run as admin, it writes to %LocalAppData%\Temp.
> The previous version of the installer was able to run in system context and
> install the application without any issue.
>
> Each time the installation is run in system context, it generates a folder
> with a different name so we cannot change the permission. If the temp
> folder
> can have a fixed name, then it may be possible to change the permissions.
>
>

-- 
Sandeep Thakkar

  3. RE: [EXTERNAL] Re: BUG #18707: Installation issue

    PANESAR Gursharan <gursharan.panesar@bnpparibas.com> — 2024-11-18T10:30:08Z

    Hi Sandeep

Please find installation log attached.

When I refer to the older version, I’m speaking about version 14.9.

Regards

Gursh

From: Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
Sent: 18 November 2024 09:22
To: PANESAR Gursharan <gursharan.panesar@bnpparibas.com>; pgsql-bugs@lists.postgresql.org
Subject: [EXTERNAL] Re: BUG #18707: Installation issue

EXTERNAL SENDER - EMETTEUR EXTERNE
Be cautious before opening attachments or clicking on any links. If in doubt, use 'Report Email/ReportPhishing' button or contact your CSIRT.
Soyez vigilants avant d'ouvrir les pièces jointes ou de cliquer sur les liens. En cas de doute, signalez le message via le bouton 'Report Email/ReportPhishing' ou contactez votre CSIRT.
Hi,

Could you share the installation log? It must be present in the temp. By previous version, do you mean 15.7?

On Thu, Nov 14, 2024 at 7:51 PM PG Bug reporting form <noreply@postgresql.org<mailto:noreply@postgresql.org>> wrote:
The following bug has been logged on the website:

Bug reference:      18707
Logged by:          Gursh Panesar
Email address:      gursharan.panesar@bnpparibas.com<mailto:gursharan.panesar@bnpparibas.com>
PostgreSQL version: 15.8
Operating system:   Windows 10
Description:

We have an issue installing version 15.8 using file
postgresql-15.8-1-windows-x64.exe.
The installation in our environment is run in the system context.
When the installation is run in the system context it writes to
C:\Windows\Temp folder and fails.
If the installation is run as admin, it writes to %LocalAppData%\Temp.
The previous version of the installer was able to run in system context and
install the application without any issue.

Each time the installation is run in system context, it generates a folder
with a different name so we cannot change the permission. If the temp folder
can have a fixed name, then it may be possible to change the permissions.


--
Sandeep Thakkar

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential. 
If you receive this message in error,or are not the intended recipient(s), 
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose, 
dissemination or disclosure, either whole or partial, is prohibited. Since the internet 
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS 
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified. 
Do not print this message unless it is necessary, consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message") 
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de 
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute 
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas 
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie. 
N'imprimez ce message que si necessaire, pensez a l'environnement.

  4. Re: [EXTERNAL] Re: BUG #18707: Installation issue

    Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> — 2024-11-18T11:06:13Z

    Thanks for sharing the installation log. Could you once try
installing postgresql-15.8-2-windows-x64.exe as I see a commit in
the Git around that bug?

On Mon, Nov 18, 2024 at 4:03 PM PANESAR Gursharan <
gursharan.panesar@bnpparibas.com> wrote:

> Hi Sandeep
>
>
>
> Please find installation log attached.
>
>
>
> When I refer to the older version, I’m speaking about version 14.9.
>
>
>
> Regards
>
>
>
> Gursh
>
>
>
> *From:* Sandeep Thakkar <sandeep.thakkar@enterprisedb.com>
> *Sent:* 18 November 2024 09:22
> *To:* PANESAR Gursharan <gursharan.panesar@bnpparibas.com>;
> pgsql-bugs@lists.postgresql.org
> *Subject:* [EXTERNAL] Re: BUG #18707: Installation issue
>
>
>
> *EXTERNAL SENDER - EMETTEUR EXTERNE*
> Be cautious before opening attachments or clicking on any links. If in
> doubt, use *'Report Email/ReportPhishing'* button or contact your *CSIRT.*
> Soyez vigilants avant d'ouvrir les pièces jointes ou de cliquer sur les
> liens. En cas de doute, signalez le message via le bouton *'Report
> Email/ReportPhishing'* ou contactez votre *CSIRT.*
>
> Hi,
>
> Could you share the installation log? It must be present in the temp. By
> previous version, do you mean 15.7?
>
>
>
> On Thu, Nov 14, 2024 at 7:51 PM PG Bug reporting form <
> noreply@postgresql.org> wrote:
>
> The following bug has been logged on the website:
>
> Bug reference:      18707
> Logged by:          Gursh Panesar
> Email address:      gursharan.panesar@bnpparibas.com
> PostgreSQL version: 15.8
> Operating system:   Windows 10
> Description:
>
> We have an issue installing version 15.8 using file
> postgresql-15.8-1-windows-x64.exe.
> The installation in our environment is run in the system context.
> When the installation is run in the system context it writes to
> C:\Windows\Temp folder and fails.
> If the installation is run as admin, it writes to %LocalAppData%\Temp.
> The previous version of the installer was able to run in system context and
> install the application without any issue.
>
> Each time the installation is run in system context, it generates a folder
> with a different name so we cannot change the permission. If the temp
> folder
> can have a fixed name, then it may be possible to change the permissions.
>
>
>
>
> --
>
> Sandeep Thakkar
>
>
>
> This message and any attachments (the "message") is
> intended solely for the intended addressees and is confidential.
> If you receive this message in error,or are not the intended recipient(s),
> please delete it and any copies from your systems and immediately notify
> the sender. Any unauthorized view, use that does not comply with its
> purpose,
> dissemination or disclosure, either whole or partial, is prohibited. Since
> the internet
> cannot guarantee the integrity of this message which may not be reliable,
> BNP PARIBAS
> (and its subsidiaries) shall not be liable for the message if modified,
> changed or falsified.
> Do not print this message unless it is necessary, consider the environment.
>
>
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Ce message et toutes les pieces jointes (ci-apres le "message")
> sont etablis a l'intention exclusive de ses destinataires et sont
> confidentiels.
> Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
> merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
> immediatement l'expediteur. Toute lecture non autorisee, toute utilisation
> de
> ce message qui n'est pas conforme a sa destination, toute diffusion ou
> toute
> publication, totale ou partielle, est interdite. L'Internet ne permettant
> pas d'assurer
> l'integrite de ce message electronique susceptible d'alteration, BNP
> Paribas
> (et ses filiales) decline(nt) toute responsabilite au titre de ce message
> dans l'hypothese
> ou il aurait ete modifie, deforme ou falsifie.
> N'imprimez ce message que si necessaire, pensez a l'environnement.
>


-- 
Sandeep Thakkar

  5. Re: [EXTERNAL] Re: BUG #18707: Installation issue

    Thomas Munro <thomas.munro@gmail.com> — 2024-11-19T01:09:12Z

    On Tue, Nov 19, 2024 at 12:06 AM Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com> wrote:
> Thanks for sharing the installation log. Could you once try installing postgresql-15.8-2-windows-x64.exe as I see a commit in the Git around that bug?

I wonder why the log shows "entr‚e" (instead of "entrée") in one
place, but apparently OK encoding elsewhere...  makes me pretty
suspicious of the account name "autorite nt\système", and I see there
is also an open issue in the github about "nt-autorität\system".  Just
a wild guess: would it help to use numerical SIDs instead of account
names when invoking shell commands like icacls?

  6. Re: [EXTERNAL] Re: BUG #18707: Installation issue

    Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> — 2024-11-19T07:01:53Z

    On Tue, Nov 19, 2024 at 6:39 AM Thomas Munro <thomas.munro@gmail.com> wrote:

> On Tue, Nov 19, 2024 at 12:06 AM Sandeep Thakkar
> <sandeep.thakkar@enterprisedb.com> wrote:
> > Thanks for sharing the installation log. Could you once try installing
> postgresql-15.8-2-windows-x64.exe as I see a commit in the Git around that
> bug?
>
> I wonder why the log shows "entr‚e" (instead of "entrée") in one
> place, but apparently OK encoding elsewhere...  makes me pretty
> suspicious of the account name "autorite nt\système", and I see there
> is also an open issue in the github about "nt-autorität\system".  Just
> a wild guess: would it help to use numerical SIDs instead of account
> names when invoking shell commands like icacls?
>

Yes, I tried that recently. It works well for init cluster, but pg_ctl
fails to register the service:

> Executing C:\Windows\System32\cmd.exe /c "C:\Program
> Files\PostgreSQL\17\bin\pg_ctl.exe" register -N "postgresql-x64-17" -U
> "*S-1-5-20" -D "C:\Program Files\PostgreSQL\17\data" -w
> Script exit code: 1 Script output:
> Script stderr:
> pg_ctl: could not register service "postgresql-x64-17": error code 1057



-- 
Sandeep Thakkar

  7. Re: [EXTERNAL] Re: BUG #18707: Installation issue

    Thomas Munro <thomas.munro@gmail.com> — 2024-11-19T23:15:59Z

    On Tue, Nov 19, 2024 at 8:02 PM Sandeep Thakkar
<sandeep.thakkar@enterprisedb.com> wrote:
> On Tue, Nov 19, 2024 at 6:39 AM Thomas Munro <thomas.munro@gmail.com> wrote:
>> a wild guess: would it help to use numerical SIDs instead of account
>> names when invoking shell commands like icacls?
>
> Yes, I tried that recently. It works well for init cluster, but pg_ctl fails to register the service:

I suppose the SID-vs-username thing is just one case anyway, and even
if we taught pg_ctl -U to accept SIDs (looks doable), I bet you could
have the same problem with paths with funky characters in them.

Let's see... so you pass shell commands to DoCmd[1] which injects them
into a wrapper batch file, after setting the codepage to match the
ACP[2].  After reading lots of horrible details on the internet, that
looks like the right idea to me, as it means that the rest of the
batch file should match what the Visual Basic program is using when it
writes out the command line, instead of the old MS-DOS OEM codepage
assumed by cmd.exe batch files.  I assume that is working OK for
some/most people and must have worked OK for some non-ASCII stuff on
some configurations as that's why you added it, many years ago.  So
what is different in these cases?

Idea: could the Visual Basic program actually be using a different
ACP, not the one in the registry, due to some explicit locale setting
or environment variable somewhere?  Would it be better to call
GetACP() instead of that registry lookup[2]?

Some assumptions: I think VBA works entirely with wchar_t strings, and
I think objBatchFile.WriteLine must be the point of implicit
transcoding to char if the file wasn't opened in "Unicode mode"
(Unicode here meaning wchar_t, which sounds potentially useful for
sidestepping all this stuff but apparently it wouldn't work for batch
files), and surely that transcoding is done with the value from
GetACP().  I couldn't find where that is written down, though.

[1] https://github.com/EnterpriseDB/edb-installers/blob/5721b7804676fe1b74f5a4287692f56bd52e8b8f/server/scripts/windows/initcluster.vbs#L173
[2] https://github.com/EnterpriseDB/edb-installers/blob/5721b7804676fe1b74f5a4287692f56bd52e8b8f/server/scripts/windows/initcluster.vbs#L75

  8. Re: [EXTERNAL] Re: BUG #18707: Installation issue

    Thomas Munro <thomas.munro@gmail.com> — 2024-11-20T22:41:29Z

    On Wed, Nov 20, 2024 at 12:15 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Idea: could the Visual Basic program actually be using a different
> ACP, not the one in the registry, due to some explicit locale setting
> or environment variable somewhere?  Would it be better to call
> GetACP() instead of that registry lookup[2]?

Guessing harder, in more actionable form: something like
LANG="fr-FR.UTF-8" might be enough to break your script, if VB itself
or something in your VB code calls setlocale(LC_ALL, "").  I have no
idea if it does, but if so, that could change the ACP for the process,
I think.  Perhaps Gursharan might like to check whether LANG or any of
the LC_ is set in the environment where the installer runs, and if so
whether the value implies a codepage that doesn't match
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\CodePage\ACP.
If so, just as an experiment, changing the variable to something with
a matching codepage (I think for example "fr-FR" without suffix
implies 1252, traditional encoding used for French) might work, just
to confirm what's happening, or kill this theory :-)  And if that's
it, and if GetACP() is the solution, then: the intergoogles told me
that you should be able to 'Declare Function GetACP Lib "kernel32" ()
As Long' to access it.

  9. Re: BUG #18707: Installation issue

    Sandeep Thakkar <sandeep.thakkar@enterprisedb.com> — 2024-12-03T06:03:20Z

    Hi Gurusharan,

PostgreSQL 17.2-2, 16.6-2, 15.10-2 are available for download. These
installers include a fix when the local system is a non-English name
containing non-ASCII characters. Please have a look. Hopefully, it should
resolve the issue for you.

Thank you for your patience.

On Thu, Nov 14, 2024 at 7:51 PM PG Bug reporting form <
noreply@postgresql.org> wrote:

> The following bug has been logged on the website:
>
> Bug reference:      18707
> Logged by:          Gursh Panesar
> Email address:      gursharan.panesar@bnpparibas.com
> PostgreSQL version: 15.8
> Operating system:   Windows 10
> Description:
>
> We have an issue installing version 15.8 using file
> postgresql-15.8-1-windows-x64.exe.
> The installation in our environment is run in the system context.
> When the installation is run in the system context it writes to
> C:\Windows\Temp folder and fails.
> If the installation is run as admin, it writes to %LocalAppData%\Temp.
> The previous version of the installer was able to run in system context and
> install the application without any issue.
>
> Each time the installation is run in system context, it generates a folder
> with a different name so we cannot change the permission. If the temp
> folder
> can have a fixed name, then it may be possible to change the permissions.
>
>

-- 
Sandeep Thakkar