Automated upgrade fails on Nextcloud instance that uses Postgres with sslmode=require

[davidfrickert]

This issue only occurs on upgrade, normal nextcloud operation works fine.
My setup is that i use Postgres sslmode=require, which means that SSL needs to be used, but the certificate is not verified.
The upgrade script seems to try to verify the certificate, which it shouldn't do pg docs.

config.php snippet:

  'dbtype' => 'pgsql',
  'dbname' => 'nextcloud',
  'dbhost' => 'tools-pg-pooler:5432;sslmode=require',
  'dbport' => '',
  'dbtableprefix' => 'oc_',

Logs of failure:

Defaulted container "nextcloud" out of: nextcloud, nextcloud-cron
Configuring Redis as session handler
Initializing nextcloud 30.0.1.2 ...
Upgrading nextcloud from 29.0.7.1 ...
=> Searching for scripts (*.sh) to run, located in the folder: /docker-entrypoint-hooks.d/pre-upgrade
An unhandled exception has been thrown:
Doctrine\DBAL\Exception: Failed to connect to the database: An exception occurred in the driver: SQLSTATE[08006] [7] connection to server at "tools-pg-pooler" (10.43.28.253), port 5432 failed: could not open certificate file "/root/.postgresql/postgresql.crt": Permission denied
connection to server at "tools-pg-pooler" (10.43.28.253), port 5432 failed: FATAL:  SSL required in /var/www/html/lib/private/DB/Connection.php:233
Stack trace:
#0 /var/www/html/3rdparty/doctrine/dbal/src/Connection.php(453): OC\DB\Connection->connect()
#1 /var/www/html/3rdparty/doctrine/dbal/src/Connection.php(411): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
#2 /var/www/html/3rdparty/doctrine/dbal/src/Connection.php(318): Doctrine\DBAL\Connection->detectDatabasePlatform()
#3 /var/www/html/lib/private/DB/Connection.php(899): Doctrine\DBAL\Connection->getDatabasePlatform()
#4 /var/www/html/lib/private/DB/ConnectionAdapter.php(235): OC\DB\Connection->getDatabaseProvider()
#5 /var/www/html/lib/private/DB/QueryBuilder/QueryBuilder.php(96): OC\DB\ConnectionAdapter->getDatabaseProvider()
#6 /var/www/html/lib/private/AppConfig.php(1211): OC\DB\QueryBuilder\QueryBuilder->expr()
#7 /var/www/html/lib/private/AppConfig.php(237): OC\AppConfig->loadConfig(false)
#8 /var/www/html/lib/private/AppConfig.php(1351): OC\AppConfig->searchValues('enabled', false, 2)
#9 /var/www/html/lib/private/App/AppManager.php(126): OC\AppConfig->getValues(false, 'enabled')
#10 /var/www/html/lib/private/App/AppManager.php(147): OC\App\AppManager->getInstalledAppsValues()
#11 /var/www/html/lib/private/legacy/OC_App.php(191): OC\App\AppManager->getInstalledApps()
#12 /var/www/html/lib/private/AppFramework/Bootstrap/Coordinator.php(48): OC_App::getEnabledApps()
#13 /var/www/html/lib/base.php(657): OC\AppFramework\Bootstrap\Coordinator->runInitialRegistration()
#14 /var/www/html/lib/base.php(1132): OC::init()
#15 /var/www/html/console.php(28): require_once('/var/www/html/l...')
#16 /var/www/html/occ(11): require_once('/var/www/html/c...')
#17 {main}⏎                                                                                                                                                                                                                                                                      4m36s ••     

[davidfrickert]

Note: I am still able to upgrade via Web interface, which I assume does not run the /docker-entrypoint-hooks.d/pre-upgrade scripts.

[StrikerRUS]

@davidfrickert Try to unset HOME env variable: #2053 (comment), #2053 (comment). This trick helped me.

[davidfrickert]

@davidfrickert Try to unset HOME env variable: #2053 (comment), #2053 (comment). This trick helped me.

Thanks for the suggestion, will try it out on the next upgrade

[joshtrichards]

Postgres, even when using sslmode=require, behaves as if it's set to verify-ca (sort of). See https://www.postgresql.org/docs/current/libpq-ssl.html#LIBQ-SSL-CERTIFICATES (the second note). It looks for the cert (that it doesn't actually need) in a directory it doesn't have access to (which fails).

There are multiple ways of dealing with it: See #2053 and #1288 (as @StrikerRUS mentioned).

Since this has come up now a few times, we can probably handle this a bit better. It's kind of our fault that $HOME doesn't have a reasonable value. We may be able to remedy it once and for all via #2318.