Qlik Sense server upgrade fails

[awhitfield]

Hi folks,

we have a client who is attempting to upgrade from 3.1.4 (synch) to February 2018, we have tried allsorts but are getting nowhere fast.

Can someone who a look at the attached log file to see if there's some thing obvious please?

Thanks in advance

[awhitfield]

ltu‌

[Levi_Turner]

I don't have a ton of specific thoughts. The key lines are as follows:

MSI (s) (94:9C) [14:15:26:363]: Executing op: ActionStart(Name=CA_DumpDatabase,Description=Preparing database upgrade, this may take several minutes,Template=Preparing database upgrade, this may take several minutes)

Action 14:15:26 35 After finished impersonation: NT AUTHORITY\SYSTEM

MSI (s) (94:9C) [14:15:26:365]: Executing op: CustomActionSchedule(Action=CA_DumpDatabase,ActionType=11265,Source=BinaryData,Target=**********,CustomActionData=**********)

MSI (s) (94:E4) [14:15:26:368]: Invoking remote custom action. DLL: C:\Windows\Installer\MSI9DEF.tmp, Entrypoint: DumpDatabase

SFXCA: Extracting custom action to temporary directory: C:\Windows\Installer\MSI9DEF.tmp-\

SFXCA: Binding to CLR version v4.0.30319

Calling custom action Qlik.QustomActions64!Qlik.QustomActions64.DatabaseInitializer.DumpDatabase

Action 14:15:27 20 POSTGRESQL_PORT: 4432

Action 14:15:27 21 The property POSTGRESQL_DIR is empty.

Action 14:15:27 21 POSTGRESQL_SUPERUSER: postgres

Action 14:15:27 21 The property RANDOMPASSWORD is empty.

Action 14:15:27 21 POSTGRESQL_DB_DIR: C:\ProgramData\Qlik\Sense\Repository\PostgreSQL\9.6

Action 14:15:27 21 The property DBLIMITEDUSERNAME is empty.

Action 14:15:27 21 DBDUMPFILEPATH: C:\Users\xxxx\AppData\Local\Temp\10\tmp6352.tmp

Action 14:15:27 21 INSTALLDIR: C:\Program Files\Qlik\Sense\

Action 14:15:27 68 Error in DumpDatabase custom action: could not dump database.

CustomAction CA_DumpDatabase returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

The meaning here is that the installer is having issues performing a dump of the database. This can come from a number of sources that I am aware of:

• The postgreSQL superuser account password is incorrect
  • C:\"Program Files"\Qlik\Sense\Repository\PostgreSQL\9.x\bin\psql.exe -h localhost -p 4432 -U postgres -d QSR -e where x is the build of PostgreSQL being used (likely 9.3 but maybe 9.6) and with an adjustment to the install path if needed will confirm the superuser password
• Exclusive SSL is on (rare configuration, but worth checking): https://help.qlik.com/en-US/sense/June2018/Subsystems/PlanningQlikSenseDeployments/Content/Deploymen...
• The password being passed is being over-ridden with a bad password in the .pgpass file in %USERPROFILE%\AppData\Roaming\postgresql for the user running the upgrade
• For some reason the password for the postgres account isn't being passed as expected. Reset it to something known: Change/add password to repository database

[awhitfield]

Hi Levi,

I think this get us on the right track, as it appears that the postgres password was originally omitted and one was added via pgadmin.

If I understand the link correctly:

It is important that you disable the Store password option for your user in PostgreSQL. If this option is enabled, the password is stored in a file, and incoming connections without a password will be able to connect to the database.

Do not change password in the PostgreSQL user interface for the same reasons as above.

Then using pgadmin to change the password was the wrong thing to do and the we should have done:

Change password by executing this query in the PostgreSQL database:ALTER USER <user> WITH PASSWORD '<newpassword>';  ALTER ROLE is displayed after successfully changing the password.

Have I understood this correctly?

Thanks for the guidance.

BR

Andy

[Levi_Turner]

It is important that you disable the Store password option for your user in PostgreSQL. If this option is enabled, the password is stored in a file, and incoming connections without a password will be able to connect to the database.

So yes, pgAdmin does store the password into the .pgpass file. This is fine so long as the password is correct. Otherwise any terminal sessions (cmd, PowerShell) in Windows will inherit this password

Do not change password in the PostgreSQL user interface for the same reasons as above.

I an not following this aspect of things. It is perfectly fine to use pgAdmin to change the PostgreSQL user password but it's usually not possible since the reason for changing is usually that the password is not known. If the password is known then using pgAdmin is fine.

[awhitfield]

Sorry I meant the user should change the password in pgadmin using the alter role command rather than changing it and saving via the properties option on the user \ role

Andy

[monaali602]

hi I have the same issue

how to disable store password?

[Levi_Turner]

I am unaware of how to disable that on the pgAdmin side but the file is located in %USERPROFILE%\AppData\Roaming\postgresql so you can rename the file as needed.