4.1 -> 4.2 postgresql update fails and blocks update

UCS - Univention Corporate Server
,
#1

Hi guys,

I’m trying to update my current (vm) install to the latest version and it miserably fails:

Configuring postgresql-common
-----------------------------

Obsolete major version 9.1

The PostgreSQL version 9.1 is obsolete, but the server or client packages
are still installed. Please install the latest packages (postgresql-9.4 and
postgresql-client-9.4) and upgrade the existing  clusters with
pg_upgradecluster (see manpage).

Please be aware that the installation of postgresql-9.4 will automatically
create a default cluster 9.4/main. If you want to upgrade the 9.1/main
cluster, you need to remove the already existing 9.4 cluster (pg_dropcluster
--stop 9.4 main, see manpage for details).

The old server and client packages are no longer supported. After the
existing clusters are upgraded, the postgresql-9.1 and postgresql-client-9.1
packages should be removed.

Please see /usr/share/doc/postgresql-common/README.Debian.gz for details.

Creating config file /etc/postgresql-common/createcluster.conf with new version
insserv: warning: script 'K01univention-system-setup-boot' missing LSB tags and overrides
insserv: warning: script 'K01univention-saml' missing LSB tags and overrides
insserv: warning: script 'K01univention-s4-connector' missing LSB tags and overrides
insserv: warning: script 'K02bind9' missing LSB tags and overrides
insserv: warning: script 'K01univention-management-console-web-server' missing LSB tags and overrides
insserv: warning: script 'univention-system-setup-boot' missing LSB tags and overrides
insserv: warning: script 'univention-s4-connector' missing LSB tags and overrides
insserv: warning: script 'univention-management-console-web-server' missing LSB tags and overrides
insserv: warning: script 'univention-system-setup-boot-prepare' missing LSB tags and overrides
insserv: warning: script 'bind9' missing LSB tags and overrides
insserv: warning: script 'univention-saml' missing LSB tags and overrides
Starting PostgreSQL 9.1 database server: mainThe PostgreSQL server failed to start. Please check the log output: 2017-04-28 12:59:05 CEST LOG: could not open configuration file "/etc/postgresql/9.1/main/pg_hba.conf": No such file or directory 2017-04-28 12:59:05 CEST FATAL: could not load pg_hba.conf ... failed!
 failed!

invoke-rc.d: initscript postgresql, action "start" failed.
dpkg: error processing package postgresql-common (--configure):
 subprocess installed post-installation script returned error exit status 1
Setting up postgresql-client-9.1 (9.1.24-0.A~4.2.0.201703301214) ...
dpkg: dependency problems prevent configuration of postgresql-9.1:
 postgresql-9.1 depends on postgresql-common (>= 115~); however:
  Package postgresql-common is not configured yet.

dpkg: error processing package postgresql-9.1 (--configure):
 dependency problems - leaving unconfigured


#### Some stuff still running until:

Errors were encountered while processing:
 postgresql-common
 postgresql-9.1
E: Sub-process /usr/bin/dpkg returned an error code (1)
Error: Failed to execute "apt-get -o DPkg::Options::=--force-confold -o DPkg::Options::=--force-overwrite -o DPkg::Options::=--force-overwrite-dir --trivial-only=no --assume-yes --quiet=1 -u dist-upgrade"

while the DHCP mocks about the config file:

dhcpd self-test failed. Please fix /etc/dhcp/dhcpd.conf.
The error was:
Internet Systems Consortium DHCP Server 4.3.1
Copyright 2004-2014 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Config file: /etc/dhcp/dhcpd.conf
Database file: /var/lib/dhcp/dhcpd.leases
PID file: /var/run/dhcpd.pid
Configuration file errors encountered -- exiting

I don’t see a big problem in the DHCP failing as I could just overwrite the configuration. But the PostgreSQL is really a showstopper. Any ideas on how to work around that?

btw - looks like I hit a known bug: http://forge.univention.org/bugzilla/show_bug.cgi?id=44160

#2

Hello and welcome to Univention Help! :balloon: :wave:

The entry in our issue tracker you mentioned aims at adding a requirement to migrate postgres from 9.1 to 9.4 before upgrading to the upcoming patch level release UCS 4.2-1. Although the issue tracker is Bugzilla and the issues are named Bugs, we also use it to track issues for upcoming features, requirements and roadmap planning. So, not every entry is about something being broken :wink:
Long story short: postgres 9.1 should work fine with UCS 4.2-0 - but it obviously doesn’t in your case.

The issue didn’t occur to me so far, so I think the best would be if we try to reproduce this. It would be great if you could provide more details on your installation:

  • Please run univention-app info and post the output here (should list UCS version and the installed Apps)
  • Do you use any software that depends on postgres besides those installed via the Univention App Center?
  • How did you upgrade? Via the webinterface, on the commandline via univention-upgrade or maybe plain apt-get?

Regarding the dhcpd: /etc/dhcp/dhcpd.conf is managed by UCR, so re-commiting the file would be the first step:

ucr commit /etc/dhcp/dhcpd.conf

If this doesn’t help, we should have a look at the file and its includes :slight_smile:

Best regards,
Michael Grandjean

#3

Hi Michael,

Thank you for your reply. First things first:

root@ucs:~# univention-app info
UCS: 4.1-4 errata410
App Center compatibility: 4
Installed: adtakeover=3.0.0 dhcp-server=10.0.1 radius=3.0 samba4=4.5
Upgradable:
root@ucs:~#

I did not install any additional stuff manually as I didn’t want to break things on my primary DC.
Upgrade was tried via webinterface and univention-upgrade giving the same results.

Thank you
Rei

#4

Hello Rei,

thanks! I did install a UCS 4.1 with all the Apps you mentioned and was able to upgrade to UCS 4.2 without any problems. So, the issue is not that generic :confused:. Let’s try to unravel this a bit:

  • UCS 4.1 comes with postgres 9.1. Upgrading to UCS 4.2 leaves postgres at version 9.1 (but will install newer packages for 9.1)
  • UCS 4.2 comes with postgres 9.4. Newly installed UCS 4.2 systems will use 9.4.
  • PostgreSQL databases are not upgraded automatically to a new postgres version during a UCS upgrade. This has to be done manually and Univention provides how-to guides in the SDB. However, the article for upgrading from 9.1 to 9.4 is still pending.
  • Upgrading to 9.4 will become mandatory when UCS 4.2-1 gets released (probably beginning of Q3/2017)
  • By default, UCS comes with the client packages of postgres (postgresql-client-*) installed
  • The server components of postgres (univention-postgresql*, postgresql-9.x, postgresql-common) are optional and not installed by default. univention-postgresql is the meta-package.
  • There a some packages and Apps that depend on the postgresql server (univention-postgresql), so it gets installed automatically when installing those Apps.
  • However, none of the listed apps above actually depends on postgresql :thinking:

The main problem in your case seems to be that upgrading the package postgresql-common needs to (re)start the postgresql daemon and this fails because the file /etc/postgresql/9.1/main/pg_hba.conf does not exist.

Can you please check:

  • Is /etc/postgresql/9.1/main/pg_hba.conf present before the upgrade?
  • Can you (re)start the postgresql daemon without failures before the upgrade? (service postgresql restart)
  • From the current information we have, it looks like we don’t really need the postgresql server packages, so removing them before the upgrade could be a solution. But before doing so, we need to check what databases there are:
# login via ssh or on the console
# switch to user posgres:
root@ucs29:~$ su postgres
postgres@ucs29:/root$

# change to the homedir and start the postgresql commandline tool 'psql'
postgres@ucs29:/root$ cd && psql
psql (9.1.24)
Type "help" for help.

postgres=#

Now list all databases:

postgres=# \list

This should give you a list of all databases. Here is an example:

                                    List of databases
    Name     |    Owner    | Encoding |   Collate   |    Ctype    |   Access privileges
-------------+-------------+----------+-------------+-------------+-----------------------
 hordedb     | horde       | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 |
 postgres    | postgres    | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 |
 selfservice | selfservice | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 |
 template0   | postgres    | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | =c/postgres          +
             |             |          |             |             | postgres=CTc/postgres
 template1   | postgres    | UTF8     | de_DE.UTF-8 | de_DE.UTF-8 | =c/postgres          +
             |             |          |             |             | postgres=CTc/postgres
(5 rows)

In this case, we have one for Horde and one for the Self Service (besides the built-in ones).

#5

The file does not exist on my old installation.ls: cannot access /etc/postgresql/9.1/main/pg_hba.conf: No such file or directory

Due to the file above missing we’re unable to restart…

I did hack me some pg_hba.conf file and I was at least able to get the restarting issue under control.
I’ll retry the upgrade now…

aaaaaand:

****************************************************
*    THE UPDATE HAS BEEN FINISHED SUCCESSFULLY.    *
* Please make a page reload of UMC and login again *
****************************************************

Thanks a ton. I didn’t really think on that issue. Shame on me.

#6

You’re welcome :slight_smile:

Just for the record:
/etc/postgresql/9.1/main/pg_hba.conf is also handled by UCR. So, as long as the template files are fine and the UCR variables are okay, re-commiting the file(s) should also help:

ucr commit /etc/postgresql/9.1/main/*

Is your dhcpd also working again?

Best regards,
Michael

#7

Hi Michaek,

I could fix the outstanding issues with ease. The only thing I’m wondering about is how the postgres config file could vanish. But I guess that’s one of those things we’d never know.

#8

Glad to hear that :slight_smile:

Yes, unfortunately. As long as there is no change mointoring solution like auditd or similiar, that’s only guesswork.

If no question are left, would you mind marking this topic als solved? (every answer has a little checkbox with a checkmark to do so)

Mastodon