Bareos Problem bei Upgrade auf PostgreSQL 9.1

Auf meinem Server (DC-Master) läuft seit etwas über einem Jahr Bareos sehr zufriedenstellend.
Beim Upgrade von PostgreSQL 8.4 auf PostgreSQL 9.1 nach Anleitung http://sdb.univention.de/1292 scheint jetzt etwas schiefgelaufen zu sein. Bareos bekommt nun keine Verbindung mehr zur Datenbank.

Laut ps auxw | grep postgres läuft z.Z. weder 8.4 noch 9.1 trotz vorhergehendem

root@server1:~# service postgresql restart [ ok ] Restarting PostgreSQL 8.4 database server:.

Eine Prüfung ergibt

root@server1:~# bareos-dir -t bareos-dir: dird.c:1087-0 Could not open Catalog "MyCatalog", database "bareos". bareos-dir: dird.c:1092-0 postgresql.c:238 Unable to connect to PostgreSQL server. Database=bareos User=bareos Possible causes: SQL server not running; password incorrect; max_connections exceeded. 06-Nov 10:32 bareos-dir ERROR TERMINATION Please correct configuration file: bareos-dir.conf

An diesem Punkt möchte ich nun nicht weiter ohne Hilfe herumprobieren und hoffe daher auf Tipps zur Wiederherstellung.
Uwe

Hallo Uwe,

[quote=“UweP”]
An diesem Punkt möchte ich nun nicht weiter ohne Hilfe herumprobieren und hoffe daher auf Tipps zur Wiederherstellung.
Uwe[/quote]
Was sagen DB Logs unter /var/log/postgresql/ wenn scheinbar die alte 8.4er Instanz auch nicht mehr korrekt startet?

Ich hatte beim Bareos/UCS (von 3.2 auf 4.0) Update auch Probleme (mit Lösung), aber sdb.univention.de/1292 hat zusammen mit Hinweisen aus dem Thread geholfen.

Ich musste noch /var/lib/postgresql/9.1 vor dem UCS PostgreSQL Update HowTo leeren, weil das UCS Update und Ausführung des adaptierten alten HowTos (hier nicht verwenden, damals gab es das neue noch nicht! sdb.univention.de/1220) hier schon Files ablegte, welche aber ‘pg_ugpradecluster’ störten.

VG
Robert

Hallo Robert,

die letzten Einträge der Logfiles sehen so aus:

/var/log/postgresql/postgresql-8.4-main.log

2015-11-05 17:45:10 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:45:15 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:45:20 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:45:25 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:45:30 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:45:35 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:45:40 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:45:45 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:45:50 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:45:55 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:46:00 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:46:05 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:46:10 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:46:15 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:46:20 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:46:25 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:46:30 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:46:35 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:48:27 CET LOG: schnelles Herunterfahren verlangt 2015-11-05 17:48:27 CET LOG: etwaige aktive Transaktionen werden abgebrochen 2015-11-05 17:48:27 CET LOG: Autovacuum-Launcher f?hrt herunter 2015-11-05 17:48:27 CET LOG: fahre herunter 2015-11-05 17:48:27 CET LOG: Datenbanksystem ist heruntergefahren 2015-11-05 17:51:07 CET LOG: Datenbanksystem wurde am 2015-11-05 17:48:27 CET heruntergefahren 2015-11-05 17:51:07 CET LOG: unvollst?ndiges Startpaket 2015-11-05 17:51:07 CET LOG: Autovacuum-Launcher startet 2015-11-05 17:51:07 CET LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen 2015-11-05 17:51:17 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:51:22 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:51:27 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:51:32 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:51:37 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 17:51:42 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 18:20:30 CET LOG: intelligentes Herunterfahren verlangt 2015-11-05 18:20:30 CET LOG: Autovacuum-Launcher f?hrt herunter 2015-11-05 18:20:30 CET LOG: fahre herunter 2015-11-05 18:20:30 CET LOG: Datenbanksystem ist heruntergefahren 2015-11-05 18:20:33 CET LOG: Datenbanksystem wurde am 2015-11-05 18:20:30 CET heruntergefahren 2015-11-05 18:20:33 CET LOG: Autovacuum-Launcher startet 2015-11-05 18:20:33 CET LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen 2015-11-05 18:20:33 CET LOG: unvollst?ndiges Startpaket 2015-11-05 18:27:51 CET LOG: intelligentes Herunterfahren verlangt 2015-11-05 18:27:51 CET LOG: Autovacuum-Launcher f?hrt herunter 2015-11-05 18:27:51 CET LOG: fahre herunter 2015-11-05 18:27:51 CET LOG: Datenbanksystem ist heruntergefahren

/var/log/postgresql/postgresql-9.1-main.log

2015-11-05 18:20:43 CET LOG: Datenbanksystem wurde am 2015-11-05 18:20:41 CET heruntergefahren 2015-11-05 18:20:43 CET LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen 2015-11-05 18:20:43 CET LOG: Autovacuum-Launcher startet 2015-11-05 18:20:43 CET LOG: unvollst?ndiges Startpaket 2015-11-05 18:21:11 CET LOG: Checkpoints passieren zu oft (alle 17 Sekunden) 2015-11-05 18:21:11 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:21:22 CET LOG: Checkpoints passieren zu oft (alle 11 Sekunden) 2015-11-05 18:21:22 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:21:31 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:21:31 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:21:40 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:21:40 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:21:50 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:21:50 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:21:59 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:21:59 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:22:10 CET LOG: Checkpoints passieren zu oft (alle 11 Sekunden) 2015-11-05 18:22:10 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:22:19 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:22:19 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:22:29 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:22:29 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:22:38 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:22:38 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:22:48 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:22:48 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:22:57 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:22:57 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:23:07 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:23:07 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:23:16 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:23:16 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:23:25 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:23:25 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:23:34 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:23:34 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:23:44 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:23:44 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:23:54 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:23:54 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:24:04 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:24:04 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:24:13 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:24:13 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:24:23 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:24:23 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:24:32 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:24:32 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:24:43 CET LOG: Checkpoints passieren zu oft (alle 11 Sekunden) 2015-11-05 18:24:43 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:24:52 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:24:52 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:25:02 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:25:02 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:25:12 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:25:12 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:25:22 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:25:22 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:25:31 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:25:31 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:25:41 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:25:41 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:25:51 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:25:51 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:26:01 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:26:01 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:26:11 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:26:11 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:26:22 CET LOG: Checkpoints passieren zu oft (alle 11 Sekunden) 2015-11-05 18:26:22 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:26:32 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:26:32 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:26:41 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:26:41 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:26:51 CET LOG: Checkpoints passieren zu oft (alle 10 Sekunden) 2015-11-05 18:26:51 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:27:00 CET LOG: Checkpoints passieren zu oft (alle 9 Sekunden) 2015-11-05 18:27:00 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:27:11 CET LOG: Checkpoints passieren zu oft (alle 11 Sekunden) 2015-11-05 18:27:11 CET TIPP: Erh?hen Sie eventuell den Konfigurationsparameter >>checkpoint_segments<<. 2015-11-05 18:27:26 CET LOG: sende Stornierung an blockierende Autovacuum-PID 7669 2015-11-05 18:27:26 CET DETAIL: Prozess 7671 wartet auf ShareUpdateExclusiveLock-Sperre auf Relation 16432 der Datenbank 16385. 2015-11-05 18:27:26 CET ANWEISUNG: ANALYZE 2015-11-05 18:27:26 CET FEHLER: storniere Autovacuum-Aufgabe 2015-11-05 18:27:26 CET ZUSAMMENHANG: automatisches Analysieren der Tabelle »bareos.public.file« 2015-11-05 18:27:30 CET LOG: sende Stornierung an blockierende Autovacuum-PID 7669 2015-11-05 18:27:30 CET DETAIL: Prozess 7671 wartet auf ShareUpdateExclusiveLock-Sperre auf Relation 16443 der Datenbank 16385. 2015-11-05 18:27:30 CET ANWEISUNG: ANALYZE 2015-11-05 18:27:30 CET FEHLER: storniere Autovacuum-Aufgabe 2015-11-05 18:27:30 CET ZUSAMMENHANG: automatisches Analysieren der Tabelle »bareos.public.filename« 2015-11-05 18:27:46 CET LOG: intelligentes Herunterfahren verlangt 2015-11-05 18:27:46 CET LOG: Autovacuum-Launcher f?hrt herunter 2015-11-05 18:27:46 CET LOG: fahre herunter 2015-11-05 18:27:49 CET LOG: Datenbanksystem ist heruntergefahren 2015-11-05 18:27:54 CET LOG: Datenbanksystem wurde am 2015-11-05 18:27:49 CET heruntergefahren 2015-11-05 18:27:54 CET LOG: Autovacuum-Launcher startet 2015-11-05 18:27:54 CET LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen 2015-11-05 18:27:54 CET LOG: unvollst?ndiges Startpaket 2015-11-05 18:29:57 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 18:30:02 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 18:30:07 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 18:30:12 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 18:30:17 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 18:30:22 CET FATAL: kein pg_hba.conf-Eintrag f?r Host >>[local]<<, Benutzer >>bareos<<, Datenbank >>bareos<<, SSL aus 2015-11-05 18:33:13 CET LOG: schnelles Herunterfahren verlangt 2015-11-05 18:33:13 CET LOG: etwaige aktive Transaktionen werden abgebrochen 2015-11-05 18:33:13 CET LOG: Autovacuum-Launcher f?hrt herunter 2015-11-05 18:33:14 CET LOG: fahre herunter 2015-11-05 18:33:14 CET LOG: Datenbanksystem ist heruntergefahren 2015-11-05 18:33:23 CET LOG: Datenbanksystem wurde am 2015-11-05 18:33:14 CET heruntergefahren 2015-11-05 18:33:23 CET LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen 2015-11-05 18:33:23 CET LOG: Autovacuum-Launcher startet 2015-11-05 18:33:23 CET LOG: unvollst?ndiges Startpaket 2015-11-05 18:36:20 CET LOG: schnelles Herunterfahren verlangt 2015-11-05 18:36:20 CET LOG: etwaige aktive Transaktionen werden abgebrochen 2015-11-05 18:36:20 CET LOG: Autovacuum-Launcher f?hrt herunter 2015-11-05 18:36:20 CET LOG: fahre herunter 2015-11-05 18:36:20 CET LOG: Datenbanksystem ist heruntergefahren 2015-11-05 18:36:23 CET LOG: Datenbanksystem wurde am 2015-11-05 18:36:20 CET heruntergefahren 2015-11-05 18:36:23 CET LOG: Autovacuum-Launcher startet 2015-11-05 18:36:23 CET LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen 2015-11-05 18:36:23 CET LOG: unvollst?ndiges Startpaket 2015-11-05 18:39:52 CET LOG: schnelles Herunterfahren verlangt 2015-11-05 18:39:52 CET LOG: etwaige aktive Transaktionen werden abgebrochen 2015-11-05 18:39:52 CET LOG: Autovacuum-Launcher f?hrt herunter 2015-11-05 18:39:52 CET LOG: fahre herunter 2015-11-05 18:39:52 CET LOG: Datenbanksystem ist heruntergefahren

[quote]pro4567 hat geschrieben:
Ich hatte beim Bareos/UCS (von 3.2 auf 4.0) Update auch Probleme (mit Lösung), aber sdb.univention.de/1292 hat zusammen mit Hinweisen aus dem Thread geholfen.

Ich musste noch

/var/lib/postgresql/9.1

vor dem UCS PostgreSQL Update HowTo leeren, weil das UCS Update und Ausführung des adaptierten alten HowTos (hier nicht verwenden, damals gab es das neue noch nicht! sdb.univention.de/1220) hier schon Files ablegte, welche aber ‘pg_ugpradecluster’ störten.[/quote]

Diesen Beitrag hatte ich dann ebenfalls gefunden und auch beim zweiten Versuch entsprechend umgesetzt, d.h. /var/lib/postgresql/9.1 zuvor gelöscht.
Nach »pg_upgradecluster 8.4 main« hatte der Rechner auch eine ganze Weile gearbeitet (ca. 10 Minuten), wobei ich dachte die Datenbank würde auf die neue Version umgeschrieben. Danach jedoch starteten beide Versionen nicht mehr.

Gruß
Uwe

[quote=“UweP”] Danach jedoch starteten beide Versionen nicht mehr.
[/quote]
Sicher, dass DB-Service wirklich down ist? So sieht es bei mir aus, wenn er läuft:

root@XXXXX /etc/postgresql/9.1/main # netstat -tulpe | grep postgres tcp 0 0 *:postgresql *:* LISTEN postgres 2335245314 27223/postgres tcp6 0 0 [::]:postgresql [::]:* LISTEN postgres 2335245315 27223/postgres
Wie sehen die letzten 20 Zeilen der beanstandeten pg_hba.conf aus? Bei mir so

[code]root@XXXXXXX /etc/postgresql/9.1/main # tail -n 20 /etc/postgresql/9.1/main/pg_hba.conf

DO NOT DISABLE!

If you change this first entry you will need to make sure that the

database

super user can access the database using some other method.

Noninteractive

access to all databases is required during automatic maintenance

(custom daily cronjobs, replication, and similar tasks).

Database administrative login by UNIX sockets

local all postgres ident

TYPE DATABASE USER CIDR-ADDRESS METHOD

“local” is for Unix domain socket connections only

local all all ident

IPv4 local connections:

host all all 127.0.0.1/32 md5

IPv6 local connections:

host all all ::1/128 md5[/code]

Wie sieht der Paket-Status mit dpkg --audit aus, hier sollte keine Ausgabe bzw. leer erfolgen?

Postgresql sollte so aussehen, wobei bei dir 'postgresql-8.4 ’ noch installiert sein sollte, wenn die Migration noch nicht ganz klappte und du das alte 8.4er Paket deswegen noch nicht gelöscht hast:

root@xxxxx /etc/postgresql/9.1/main # dpkg -l '*postgres*'
Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                                                  Version                         Architektur                     Beschreibung
+++-=====================================================-===============================-===============================-===============================================================================================================
un  akonadi-backend-postgresql                            <keine>                                                         (keine Beschreibung vorhanden)
ii  bareos-database-postgresql                            13.2.2-16.1                     amd64                           Backup Archiving Recovery Open Sourced - director catalog for PostgreSQL
un  librdf-storage-postgresql                             <keine>                                                         (keine Beschreibung vorhanden)
un  odbc-postgresql                                       <keine>                                                         (keine Beschreibung vorhanden)
ii  postgresql                                            9.1+134.23.201409242249         all                             object-relational SQL database (supported version)
un  postgresql-7.4                                        <keine>                                                         (keine Beschreibung vorhanden)
un  postgresql-8.0                                        <keine>                                                         (keine Beschreibung vorhanden)
un  postgresql-8.3                                        <keine>                                                         (keine Beschreibung vorhanden)
un  postgresql-8.4                                        <keine>                                                         (keine Beschreibung vorhanden)
ii  postgresql-9.1                                        9.1.16-0.9.201509171755         amd64                           object-relational SQL database, version 9.1 server
un  postgresql-client                                     <keine>                                                         (keine Beschreibung vorhanden)
ii  postgresql-client-9.1                                 9.1.16-0.9.201509171755         amd64                           front-end programs for PostgreSQL 9.1
ii  postgresql-client-common                              134.23.201409242249             all                             manager for multiple PostgreSQL client versions
ii  postgresql-common                                     134.23.201409242249             all                             PostgreSQL database-cluster manager
un  postgresql-contrib-9.1                                <keine>                                                         (keine Beschreibung vorhanden)
un  postgresql-doc-9.1                                    <keine>                                                         (keine Beschreibung vorhanden)
un  postgresql-plpython-9.1                               <keine>                                                         (keine Beschreibung vorhanden)
ii  univention-postgresql       

VG Robert

netstat -tulpe | grep postgresliefert keine Ausgabe

root@xxx:/etc/postgresql# ls -la /etc/postgresql/ insgesamt 32 drwxr-xr-x 5 root root 4096 Nov 5 18:40 . drwxr-xr-x 159 root root 12288 Nov 9 20:08 .. drwxr-xr-x 3 root root 4096 Dez 22 2013 7.4 drwxr-xr-x 3 root root 4096 Dez 22 2013 8.3 drwxr-xr-x 3 postgres postgres 4096 Dez 22 2013 8.4 -rw-r----- 1 postgres postgres 638 Okt 30 01:09 pam_ldap.conf

root@xxx:/etc/postgresql/8.4/main# tail -n 20 /etc/postgresql/8.4/main/pg_hba.conf local all postgres identroot

ls -la /etc/postgresql/9.1/main/pg_hba.conf -r-------- 1 postgres root 24 Nov 5 17:41 /etc/postgresql/8.4/main/pg_hba.conf

dpkg --auditliefert keine Ausgabe

root@xxx:/etc/postgresql# dpkg -l '*postgres*' Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten | Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/ Halb installiert/Trigger erWartet/Trigger anhängig |/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht) ||/ Name Version Architektur Beschreibung +++-=========================-=================-=================-======================================================= ii bareos-database-postgresq 13.2.2-16.1 amd64 Backup Archiving Recovery Open Sourced - director catal un librdf-storage-postgresql <keine> (keine Beschreibung vorhanden) un odbc-postgresql <keine> (keine Beschreibung vorhanden) ii postgresql 9.1+134.23.201409 all object-relational SQL database (supported version) un postgresql-7.4 <keine> (keine Beschreibung vorhanden) un postgresql-8.0 <keine> (keine Beschreibung vorhanden) un postgresql-8.3 <keine> (keine Beschreibung vorhanden) ii postgresql-8.4 8.4.20-0.19.20140 amd64 object-relational SQL database, version 8.4 server ii postgresql-9.1 9.1.16-0.9.201509 amd64 object-relational SQL database, version 9.1 server ii postgresql-client 9.1+134.23.201409 all front-end programs for PostgreSQL (supported version) ii postgresql-client-8.4 8.4.20-0.19.20140 amd64 front-end programs for PostgreSQL 8.4 ii postgresql-client-9.1 9.1.16-0.9.201509 amd64 front-end programs for PostgreSQL 9.1 ii postgresql-client-common 134.23.2014092422 all manager for multiple PostgreSQL client versions ii postgresql-common 134.23.2014092422 all PostgreSQL database-cluster manager un postgresql-contrib-9.1 <keine> (keine Beschreibung vorhanden) un postgresql-doc-8.4 <keine> (keine Beschreibung vorhanden) un postgresql-doc-9.1 <keine> (keine Beschreibung vorhanden) un postgresql-plpython-9.1 <keine> (keine Beschreibung vorhanden) ii univention-postgresql 7.0.0-4.74.201407 all UCS - postgresql configuration
Gelöscht habe ich die 8.4 noch nicht, der Test war ja noch nicht erfolgreich.

Die Datei /etc/postgresql/8.4/main/pg_hba.conf sieht halt schon seltsam aus, ebenso deren Berechtigungen.

Gruß
Uwe

Ja, diese Config wird auch von UCS Templates abgeleitet und diese sehen bei mir für 8.4 so aus:

root@XXXX / # la /etc/univention/templates/files/etc/postgresql/8.4/main/pg_hba.conf.d/ insgesamt 16 drwxr-xr-x 2 root root 4096 Jul 11 04:28 . drwxr-xr-x 4 root root 4096 Jul 11 02:12 .. -rw-r--r-- 1 root root 3081 Mai 16 2011 00-pg_hba.conf -rw-r--r-- 1 root root 757 Mai 16 2011 99-pg_hba.conf

00-pg_hba.conf:

[code]@%@UCRWARNING=# @%@

PostgreSQL Client Authentication Configuration File

===================================================

Refer to the “Client Authentication” section in the

PostgreSQL documentation for a complete description

of this file. A short synopsis follows.

This file controls: which hosts are allowed to connect, how clients

are authenticated, which PostgreSQL user names they can use, which

databases they can access. Records take one of these forms:

local DATABASE USER METHOD [OPTIONS]

host DATABASE USER CIDR-ADDRESS METHOD [OPTIONS]

hostssl DATABASE USER CIDR-ADDRESS METHOD [OPTIONS]

hostnossl DATABASE USER CIDR-ADDRESS METHOD [OPTIONS]

(The uppercase items must be replaced by actual values.)

The first field is the connection type: “local” is a Unix-domain socket,

“host” is either a plain or SSL-encrypted TCP/IP socket, “hostssl” is an

SSL-encrypted TCP/IP socket, and “hostnossl” is a plain TCP/IP socket.

DATABASE can be “all”, “sameuser”, “samerole”, a database name, or

a comma-separated list thereof.

USER can be “all”, a user name, a group name prefixed with “+”, or

a comma-separated list thereof. In both the DATABASE and USER fields

you can also write a file name prefixed with “@” to include names from

a separate file.

CIDR-ADDRESS specifies the set of hosts the record matches.

It is made up of an IP address and a CIDR mask that is an integer

(between 0 and 32 (IPv4) or 128 (IPv6) inclusive) that specifies

the number of significant bits in the mask. Alternatively, you can write

an IP address and netmask in separate columns to specify the set of hosts.

METHOD can be “trust”, “reject”, “md5”, “password”, “gss”, “sspi”, “krb5”,

“ident”, “pam”, “ldap” or “cert”. Note that “password” sends passwords

in clear text; “md5” is preferred since it sends encrypted passwords.

OPTIONS are a set of options for the authentication in the format

NAME=VALUE. The available options depend on the different authentication

methods - refer to the “Client Authentication” section in the documentation

for a list of which options are available for which authentication methods.

Database and user names containing spaces, commas, quotes and other special

characters must be quoted. Quoting one of the keywords “all”, “sameuser” or

“samerole” makes the name lose its special character, and just match a

database or username with that name.

This file is read on server startup and when the postmaster receives

a SIGHUP signal. If you edit the file on a running system, you have

to SIGHUP the postmaster for the changes to take effect. You can use

“pg_ctl reload” to do that.

Put your actual configuration here

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

If you want to allow non-local connections, you need to add more

“host” records. In that case you will also need to make PostgreSQL listen

on a non-local interface via the listen_addresses configuration parameter,

or via the -i or -h command line switches.

#[/code]

99-pg_hba.conf:

[code]# DO NOT DISABLE!

If you change this first entry you will need to make sure that the

database

super user can access the database using some other method.

Noninteractive

access to all databases is required during automatic maintenance

(custom daily cronjobs, replication, and similar tasks).

Database administrative login by UNIX sockets

local all postgres ident

TYPE DATABASE USER CIDR-ADDRESS METHOD

“local” is for Unix domain socket connections only

local all all ident

IPv4 local connections:

host all all 127.0.0.1/32 md5

IPv6 local connections:

host all all ::1/128 md5[/code]

Mit ucr commit /etc/postgresql/8.4/main/pg_hba.conf und analog für 9.1 könnte man diese Generation nochmals anstoßen, sofern die Templates unter obigen Pfaden korrekt vorhanden sind. Wenn das zu einer volllständigen /etc/postgresql/8.4/main/pg_hba.conf verhilft, müsste der pg-Server im Anschluss natürlich nochmals restartet werden.

Wenn diese Templates (auch die der 9.1er Version ab Installation dieser) nicht korrekt da sind, würde ich versuchen, dass Paket “univention-postgresql” erneut zu installieren, denn dort sind diese PG Templates drinnen.

dpkg --configure -a sollte übrigens auch ohne Ausgabe durchlaufen, sofern alle Pakete vollständig konfiguriert sind, ev. kommt bei dir etwas anderes, denn irgendwo muss der Murks herkommen.

apt-get -f install gibt zwar etwas aus, aber sollte bei fehlerfreiem Paketstatus keine Install/Update/etc-Aktion einfordern.

In der (grafischen) UMC ist unter Domäne -> Domänenbeitritt beim Join-Status überall ‘erfolgreich’ besonders bei ‘40univention-postgresql’ ?

VG Robert

Die Templates sind alle so vorhanden, wie von dir dargestellt, und zwar die zu 8.4 und auch zu 9.1

dpkg --configure -aläuft wie vermutet ohne Ausgabe durch.

apt-get -f installzeigt lediglich 5 neue, heute noch nicht aktualisierte erratas an.

Unter Domänenbeitritt sind alle Skripte als erfolgreich gekennzeichnet, auch ‘40univention-postgresql’.

ucr commit /etc/postgresql/8.4/main/pg_hba.conferstellt die /etc/postgresql/8.4/main/pg_hba.conf neu:

root@xxx:/etc/postgresql# ls -la /etc/postgresql/8.4/main/ insgesamt 80 drwxr-xr-x 2 postgres postgres 4096 Nov 9 22:00 . drwxr-xr-x 3 postgres postgres 4096 Dez 22 2013 .. -rw-r--r-- 1 postgres postgres 316 Dez 22 2013 environment -rw-r--r-- 1 postgres postgres 143 Dez 22 2013 pg_ctl.conf -rw-r----- 1 postgres postgres 4363 Nov 9 22:00 pg_hba.conf -rw-r----- 1 postgres postgres 3822 Dez 22 2013 pg_hba.conf.debian -rw-r----- 1 postgres postgres 2092 Feb 14 2015 pg_ident.conf -rw-r----- 1 postgres postgres 1631 Dez 22 2013 pg_ident.conf.debian -rw-r--r-- 1 postgres postgres 17426 Nov 6 10:26 postgresql.conf -rw-r--r-- 1 postgres postgres 16997 Dez 22 2013 postgresql.conf.debian -rw-r--r-- 1 postgres postgres 155 Nov 5 18:27 start.conf

[code]root@xxx:/etc/postgresql# tail -n 20 /etc/postgresql/8.4/main/pg_hba.conf

DO NOT DISABLE!

If you change this first entry you will need to make sure that the

database

super user can access the database using some other method.

Noninteractive

access to all databases is required during automatic maintenance

(custom daily cronjobs, replication, and similar tasks).

Database administrative login by UNIX sockets

local all postgres ident

TYPE DATABASE USER CIDR-ADDRESS METHOD

“local” is for Unix domain socket connections only

local all all ident

IPv4 local connections:

host all all 127.0.0.1/32 md5

IPv6 local connections:

host all all ::1/128 md5[/code]
Beim restart sieht es für 8.4 und 9.1 gut aus, keine Fehlermeldung:

root@xxx:/etc/postgresql# service postgresql restart [ ok ] Restarting PostgreSQL 8.4 database server:. [ ok ] Restarting PostgreSQL 9.1 database server:.
Dennoch bleibt es bei root@xxx:/etc/postgresql# netstat -tulpe | grep postgres root@xxx:/etc/postgresql# ps auxw | grep postgres root 16009 0.0 0.0 11308 2032 pts/0 S+ 22:05 0:00 grep postgres
Bei 9.1 fehlt auch noch eine ganze Menge im Vergleich zum Verzeichnis 8.4:root@xxx:/etc/postgresql# ls -la /etc/postgresql/9.1/main/ insgesamt 16 drwxr-xr-x 2 root root 4096 Nov 9 22:03 . drwxr-xr-x 3 root root 4096 Nov 9 22:03 .. -rw-r----- 1 postgres postgres 4363 Nov 9 22:03 pg_hba.conf wäre hierfür eine Reinstallation richtig?

Gruß
Uwe

Ja, nun nochmals von vorne, aber wenn du das Migrations-HowTo unter sdb.univention.de/1292 ausgeführt hast, wurde dort auch ‘/etc/postgresql/9.1’ gelöscht und ansch. nicht wieder korrekt angelegt, es sieht so aus, als ob es schon beim Paket-Update vorher Probleme gab.

  1. mit fehlerfreiem Durchlauf von apt-get install --reinstall univention-postgresql sollte gewährleistet sein, dass UCS-PG-Templates etc. vollständig sind.

  2. Mit ucr commit /etc/postgresql/8.4/main/* und service postgresql restart sollte 8.4er Instanz (im Gegensatz zu vorher, da war pg_hba.conf seltsam anders) funktionsfähig sein, falls 8.4er Instanz dabei nicht läuft (ev. weil voriges pg_upgradecluster schon Startscripte verändert hat, denn migrierte alte Instanzen werden laut manpage nicht mehr mittels Boot-Script automatisch gestartet) versuche noch mit pg_ctlcluster 8.4 main start direkt zu starten, bitte kontrolliere dann auch den Port mit netstat -tulpe | grep postgres ev. läuft diese Instanz noch auf Alternativ-Ports vom vorigen Migrationsversuch, es sollte aber der Default Port sein.

  3. nun ggfs. /var/lib/postgresql/9.1 löschen und nochmals den 1. Block (bis ausschließlich ‘Once the new database / data inventory has been verified …’) von sdb.univention.de/1292 umsetzen, danach sollte beiden Versions-Instanzen (8.4 auf einem alternativ-Port) laufen und Bareos eigentlich laufen.

btw: ‘pg_dropcluster’ für 8.4er hast du hoffentlich vorher noch nie ausgeführt, oder? :wink: Das bitte erst, wenn du sicher bist, dass bareos mit 9.1 läuft, dazu kannst du 8.4 dann zur Kontrolle mit pg_ctlcluster 8.4 main stop stoppen und mit ‘netstat’ und auch bareos checken.

VG Robert

Hallo Robert,

zwischenzeitlich habe ich nun einmal die Aufgabenliste abgearbeitet:

root@xxx:~# apt-get install --reinstall univention-postgresql Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig 0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 5 nicht aktualisiert. Es müssen 26,7 kB an Archiven heruntergeladen werden. Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt. Holen: 1 http://updates.software-univention.de/4.0/maintained/ 4.0-0/all/ univention-postgresql 7.0.0-4.74.201407211112 [26,7 kB] Es wurden 26,7 kB in 0 s geholt (176 kB/s). (Lese Datenbank ... 151765 Dateien und Verzeichnisse sind derzeit installiert.) Vorbereitung zum Ersetzen von univention-postgresql 7.0.0-4.74.201407211112 (durch .../univention-postgresql_7.0.0-4.74.201407211112_all.deb) ... Ersatz für univention-postgresql wird entpackt ... Trigger für univention-config werden verarbeitet ... dpkg-query: Kein Paket gefunden, das auf ldapacl_66univention-appcenter_app.acl passt univention-postgresql (7.0.0-4.74.201407211112) wird eingerichtet ... Setting security/packetfilter/package/univention-postgresql/tcp/5432/all Setting security/packetfilter/package/univention-postgresql/tcp/5432/all/en File: /etc/security/packetfilter.d/10_univention-firewall_start.sh Module: zarafa-cfg File: /etc/security/packetfilter.d/80_univention-firewall_policy.sh [ ok ] Stopping Univention iptables configuration::. [ ok ] Starting Univention iptables configuration::. Failed to process Subfile /etc/univention/templates/files/var/www/ucs-overview/de.html.d/45zarafa-webapp.html Failed to process Subfile /etc/univention/templates/files/var/www/ucs-overview/en.html.d/45zarafa-webapp.html Multifile: /etc/postgresql/8.3/main/pg_ident.conf Multifile: /etc/postgresql/8.3/main/pg_hba.conf File: /etc/postgresql/8.3/main/postgresql.conf Multifile: /etc/postgresql/7.4/main/pg_hba.conf Multifile: /etc/postgresql/9.1/main/pg_ident.conf File: /etc/postgresql/8.4/main/postgresql.conf Multifile: /etc/postgresql/7.4/main/pg_ident.conf File: /etc/postgresql/9.1/main/postgresql.conf File: /etc/pam.d/postgresql Multifile: /etc/postgresql/9.1/main/pg_hba.conf File: /etc/cron.d/postgresql Multifile: /etc/postgresql/8.4/main/pg_hba.conf File: /etc/postgresql/7.4/main/postgresql.conf Multifile: /etc/postgresql/8.4/main/pg_ident.conf File: /etc/postgresql/pam_ldap.conf Calling joinscript 40univention-postgresql.inst ... 2015-11-10 18:22:33.184914240+01:00 (in joinscript_init) Joinscript 40univention-postgresql.inst finished with exitcode 1 [ ok ] Restarting PostgreSQL 8.4 database server:. [FAIL] Restarting PostgreSQL 9.1 database server: main[....] Error: /var/lib/postgresql/9.1/main is not accessible or does not exist ... failed! failed! invoke-rc.d: initscript postgresql, action "restart" failed.Den Fehler beim restart von 9.1 habe ich an dieser Stelle ignoriert und weiter gemacht:

root@xxx:~# ucr commit /etc/postgresql/8.4/main/* Multifile: /etc/postgresql/8.4/main/pg_ident.conf Multifile: /etc/postgresql/8.4/main/pg_hba.conf File: /etc/postgresql/8.4/main/postgresql.conf root@xxx:~# service postgresql restart [ ok ] Restarting PostgreSQL 8.4 database server:. [FAIL] Restarting PostgreSQL 9.1 database server: main[....] Error: /var/lib/postgresql/9.1/main is not accessible or does not exist ... failed! failed! root@xxx:~# ps auxw | grep postgres root 17939 0.0 0.0 11308 2040 pts/0 S+ 18:35 0:00 grep postgres root@xxx:~# netstat -tulpe | grep postgres root@xxx:~# pg_ctlcluster 8.4 main start root@xxx:~# netstat -tulpe | grep postgres tcp 0 0 *:postgresql *:* LISTEN postgres 2111186 17972/postgres tcp6 0 0 [::]:postgresql [::]:* LISTEN postgres 2111187 17972/postgres An dieser Stelle ist mir unklar, ob die Ports korrekt sind.

Ein Löschen von /var/lib/postgresql/9.1 war nicht nötig:

root@xxx:~# ls -la /var/lib/postgresql/9.1 ls: Zugriff auf /var/lib/postgresql/9.1 nicht möglich: Datei oder Verzeichnis nicht gefunden

[code]root@xxx:~# [ -f /usr/sbin/univention-pkgdb-scan ] &&

chmod -x /usr/sbin/univention-pkgdb-scan
root@xxx:~# service postgresql stop
[ ok ] Stopping PostgreSQL 8.4 database server:.
[FAIL] Stopping PostgreSQL 9.1 database server: main[…] Error: /var/lib/postgresql/9.1/main is not accessible or does not exist … failed!
failed!
root@xxx:~# rm -rf /etc/postgresql/9.1
root@xxx:~# apt-get install --reinstall postgresql-9.1
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen… Fertig
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 5 nicht aktualisiert.
Es müssen noch 0 B von 3.275 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
(Lese Datenbank … 151765 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Ersetzen von postgresql-9.1 9.1.16-0.9.201509171755 (durch …/postgresql-9.1_9.1.16-0.9.201509171755_amd64.deb) …
update-alternatives: /usr/share/postgresql/8.4/man/man1/postmaster.1.gz wird verwendet, um /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) im Auto-Modus bereitzustellen
Ersatz für postgresql-9.1 wird entpackt …
postgresql-9.1 (9.1.16-0.9.201509171755) wird eingerichtet …
update-alternatives: /usr/share/postgresql/9.1/man/man1/postmaster.1.gz wird verwendet, um /usr/share/man/man1/postmaster.1.gz (postmaster.1.gz) im Auto-Modus bereitzustellen
root@xxx:~# pg_dropcluster 9.1 main --stop
Error: specified cluster does not exist
root@xxx:~# service postgresql start
[ ok ] Starting PostgreSQL 8.4 database server:.
[/code]Bis hierher läuft alles gut durch und auch der folgende upgrade scheint zu funktionieren:

[code]root@xxx:~# pg_upgradecluster 8.4 main
Stopping old cluster…
Disabling connections to the old cluster during upgrade…
Restarting old cluster with restricted connections…
Creating new cluster (configuration: /etc/postgresql/9.1/main, data: /var/lib/postgresql/9.1/main)…
Moving configuration file /var/lib/postgresql/9.1/main/postgresql.conf to /etc/postgresql/9.1/main…
Moving configuration file /var/lib/postgresql/9.1/main/pg_hba.conf to /etc/postgresql/9.1/main…
Moving configuration file /var/lib/postgresql/9.1/main/pg_ident.conf to /etc/postgresql/9.1/main…
Configuring postgresql.conf to use port 5433…
Disabling connections to the new cluster during upgrade…
Roles, databases, schemas, ACLs…
Fixing hardcoded library paths for stored procedures…
Upgrading database bareos…
Analyzing database bareos…
Fixing hardcoded library paths for stored procedures…
Upgrading database postgres…
Analyzing database postgres…
Fixing hardcoded library paths for stored procedures…
Upgrading database template1…
Analyzing database template1…
Re-enabling connections to the old cluster…
Re-enabling connections to the new cluster…
Copying old configuration files…
Copying old start.conf…
Copying old pg_ctl.conf…
Stopping target cluster…
Stopping old cluster…
Disabling automatic startup of old cluster…
Configuring old cluster to use a different port (5433)…
Starting target cluster on the original port…
Success. Please check that the upgraded cluster works. If it does,
you can remove the old cluster with pg_dropcluster 8.4 main
root@xxx:~# ucr commit /etc/postgresql/9.1/main/*
Multifile: /etc/postgresql/9.1/main/pg_ident.conf
Multifile: /etc/postgresql/9.1/main/pg_hba.conf
File: /etc/postgresql/9.1/main/postgresql.conf
root@xxx:~# chown -R postgres:postgres /var/lib/postgresql/9.1
root@xxx:~# service postgresql restart
[ ok ] Restarting PostgreSQL 8.4 database server:.
[ ok ] Restarting PostgreSQL 9.1 database server:.
root@xxx:~# [ -f /usr/sbin/univention-pkgdb-scan ] &&

chmod +x /usr/sbin/univention-pkgdb-scan
[/code]
Danach sieht es dann so aus:

root@xxx:~# netstat -tulpe | grep postgres tcp 0 0 *:postgresql *:* LISTEN postgres 2123262 19788/postgres tcp6 0 0 [::]:postgresql [::]:* LISTEN postgres 2123263 19788/postgres root@xxx:~# service bareos-sd restart [ ok ] Restarting Bareos Storage Daemon: bareos-sd. root@xxx:~# service bareos-fd restart [ ok ] Restarting Bareos File Daemon: bareos-fd. root@xxx:~# service bareos-dir restart [ ok ] Restarting Bareos Director: bareos-dir. root@xxx:~# bareos-dir -t bareos-dir: dird.c:1087-0 Could not open Catalog "MyCatalog", database "bareos". bareos-dir: dird.c:1092-0 postgresql.c:238 Unable to connect to PostgreSQL server. Database=bareos User=bareos Possible causes: SQL server not running; password incorrect; max_connections exceeded. 10-Nov 19:14 bareos-dir ERROR TERMINATION Please correct configuration file: bareos-dir.conf
Über bconsole kann ich nun meine vorhandenen jobs und volumes wieder sehen, die Daten scheinen also noch da zu sein, puh!
Nun würde ich noch gerne wissen, ob die angezeigten Ports stimmen, und was die Fehlermeldung bei ‘bareos-dir -t’ hervorruft.

Achja: Nein, ‘pg_dropcluster’ für 8.4 habe ich noch nicht ausgeführt!
‘pg_ctlcluster 8.4 main stop’ habe ich bislang noch nicht getestet. Ich wollte erst einmal die Meinung zu den vorstehenden beiden Fragen abwarten.

Gruß
Uwe

Sieht alles wieder gut aus :slight_smile: Mit

rob@xxxxx ~ % grep postgres /etc/services postgresql 5432/tcp postgres # PostgreSQL Database postgresql 5432/udp postgres
kannst du die Bezeichnungen für die Default Ports bei PostgreSQL sehen, netstat -tulpe gab dir in 4. Spalte hinter dem ‘:’ also den Std-Port aus, was mit obiger Ausgabe bei der Migration Configuring old cluster to use a different port (5433)... bedeudet, dass hier 9.1er läuft, den 8.4 er müsste man manuell mit pg_ctlcluster 8.4 main start starten, danach würde netstat 2 zusätzliche Zeilen mit dem different port (5433) zeigen.

bareos-dir -t müsste man als SystemUser bareos ausführen, weil nur dieser in der Form Zugriffs-Rechte auf Bareos DB hat,

root@xxxx ~ # ps -ef | grep bareos-dir bareos 3859 1 0 Aug09 ? 00:05:32 /usr/sbin/bareos-dir
Der Service läuft auch mit diesem User :wink:

VG Robert

Hallo Robert,

grep postgres /etc/services liefert genau wie bei dir:

postgresql 5432/tcp postgres # PostgreSQL Database postgresql 5432/udp postgres
mit netstat -tulpe | grep postgres sehe ich lediglich

tcp 0 0 *:postgresql *:* LISTEN postgres 2123262 19788/postgres tcp6 0 0 [::]:postgresql [::]:* LISTEN postgres 2123263 19788/postgresda ich die 8.4 nicht manuell gestartet habe. Das scheint ja alles ok.

Die Fehlermeldung bei ‘bareos-dir -t’ ist mir dann auch klar. Vielen Dank schon mal bis hierhin!

Die täglichen Backupjobs heute Nacht sind auch durchgelaufen (der Server selbst und 2 weitere Rechner im Netz werden gesichert).
Eine Fehlermeldung gab es jedoch noch bei der Erstellung des Catalogs:

11-Nov 01:10 xxx-dir JobId 1643: shell command: run BeforeJob "/usr/lib/bareos/scripts/make_catalog_backup.pl MyCatalog" 11-Nov 01:10 xxx-dir JobId 1643: BeforeJob: pg_dump: Version des Servers: 9.1.16; Version von pg_dump: 8.4.20 11-Nov 01:10 xxx-dir JobId 1643: BeforeJob: pg_dump: Abbruch wegen unpassender Serverversion 11-Nov 01:10 xxx-dir JobId 1643: Error: Runscript: BeforeJob returned non-zero status=1. ERR=Child exited with code 1 11-Nov 01:10 xxx-dir JobId 1643: Error: Bareos xxx-dir 13.2.2 (12Nov13): Build OS: x86_64-pc-linux-gnu univention Debian GNU/Linux 6.0.6 (squeeze) JobId: 1643 Job: BackupCatalog.2015-11-11_01.10.00_06 Backup Level: Full Client: "xxx-fd" 13.2.2 (12Nov13) x86_64-pc-linux-gnu,univention,Debian GNU/Linux 6.0.6 (squeeze) FileSet: "Catalog" 2013-12-23 01:10:00 Pool: "Full" (From Job FullPool override) Catalog: "MyCatalog" (From Client resource) Storage: "File" (From Job resource) Scheduled time: 11-Nov-2015 01:10:00 Start time: 11-Nov-2015 01:10:03 End time: 11-Nov-2015 01:10:03 Elapsed time: 0 secs Priority: 11 FD Files Written: 0 SD Files Written: 0 FD Bytes Written: 0 (0 B) SD Bytes Written: 0 (0 B) Rate: 0.0 KB/s Software Compression: None VSS: no Encryption: no Accurate: no Volume name(s): Volume Session Id: 0 Volume Session Time: 0 Last Volume Bytes: 0 (0 B) Non-fatal FD errors: 1 SD Errors: 0 FD termination status: SD termination status: Termination: *** Backup Error ***
Laut dieser Ausgabe passt die Version von ‘pg_dump’ noch nicht.
Wie kann man die auf die 9.1-Version updaten? Sollte das nicht schon mit dem Paketupdate geschehen sein?

Gruß
Uwe

Ich hatte (neben der Entfernung vom 8.4er PG-Server) dazu auch Paket ‘postgresql-client-8.4’ entfernt, da catalog-Backup-Skript sonst auch diese alten Binaries (!= v9.1 am Server) verwendet.

VG Robert

[quote=“pro4567”]
Ich hatte (neben der Entfernung vom 8.4er PG-Server) dazu auch Paket ‘postgresql-client-8.4’ entfernt, da catalog-Backup-Skript sonst auch diese alten Binaries (!= v9.1 am Server) verwendet.

VG Robert[/quote]

Also bedeutet dies, das nach

pg_dropcluster 8.4 main --stop dpkg -P postgresql-8.4 dpkg -P postgresql-client-8.4
dann die neuen Binaries der 9.1 verwendet werden (auch von pg_dump), oder muss danach zusätzlich noch etwas konfiguriert werden?

Gruß
Uwe

Ja, denn ‘pg_dump’ wird mWn vom Paket postgresql-client-8.4 gestellt.

VG Robert

Hallo Robert,

nun habe ichpg_dropcluster 8.4 main --stop dpkg -P postgresql-8.4 dpkg -P postgresql-client-8.4ausgeführt.

Das Backup des Catalogs der vorangegangenen Nacht habe ich jetzt manuell ohne Fehlermeldung nachholen können. Damit dürfte ab heute Nacht das Backup wieder fehlerfrei durchlaufen. Somit sollte die Migration auf postgreSQL 9.1 erfolgreich abgeschlossen sein (wenn es beim nächsten Serverneustart keine Probleme gibt).

Ich möchte mich noch einmal bei dir für die geduldige, ausführliche und vor Allem kompetente Hilfe bedanken!

Gruß
Uwe

Nun melde ich mich doch noch einmal. Das Backup der vergangenen Nacht lief problemlos durch und auch der Catalog wurde korrekt erstellt und gesichert.

Nach einem vorhin durchgeführten Neustart des Servers startet jedoch bareos-dir nicht mehr.
‘service bareos restart’ erzeugt diese Meldungen in /var/log/bareos/bareos.log:13-Nov 19:14 bareos-dir JobId 0: Fatal error: Could not open Catalog "MyCatalog", database "bareos". 13-Nov 19:14 bareos-dir JobId 0: Fatal error: postgresql.c:238 Unable to connect to PostgreSQL server. Database=bareos User=bareos Possible causes: SQL server not running; password incorrect; max_connections exceeded. 13-Nov 19:14 bareos-dir ERROR TERMINATION Please correct configuration file: bareos-dir.conf
Diese Fehlermeldungen sehen ja aus wie bei dem Aufruf von ‘bareos-dir -t’ als root. Was ist an dieser Stelle noch zu tun?

Gruß
Uwe

Eine weitere Untersuchung zeigt, das PostgreSQL beim Serverneustart nicht automatisch gestartet wurde.

Durchpg_ctlcluster 9.1 main startkann ich es manuell starten.

Mitservice bareos-dir restartläuft dann auch der Bareos-Director wieder an.

Nach einem erneuten Serverneustart aber wieder das gleiche Bild. PostgreSQL wird nicht automatisch gestartet (und dadurch auch bareos-dir). In der UMC taucht postgres auch nicht unter Systemdienste auf, selbst nach dem manuellen Starten.

Wie bekomme ich PostgreSQL dazu, wieder automatisch zu starten?

Gruß
Uwe

Hm … was passiert bei dir, wenn du System-Startskript ausführst?
Beim Versuch damit zu starten, aber ev. bitte vorher PG (notfalls manuell mit ‘pg_ctlcluster’) stoppen und Ergebnis jeweils kontrollieren:

root@xxxx ~ # service postgresql restart [ ok ] Restarting PostgreSQL 9.1 database server: main. root@xxxxx ~ # netstat -tulpe | grep postgres tcp 0 0 *:postgresql *:* LISTEN postgres 3694918149 29223/postgres tcp6 0 0 [::]:postgresql [::]:* LISTEN postgres 3694918150 29223/postgres
Und wie sieht dein Log dabei aus? Hier:

root@xxxxx ~ # tail ~log/postgresql/postgresql-9.1-main.log 2015-11-17 11:07:20 CET LOG: schnelles Herunterfahren verlangt 2015-11-17 11:07:20 CET LOG: etwaige aktive Transaktionen werden abgebrochen 2015-11-17 11:07:20 CET LOG: Autovacuum-Launcher f?hrt herunter 2015-11-17 11:07:20 CET LOG: fahre herunter 2015-11-17 11:07:20 CET LOG: Datenbanksystem ist heruntergefahren 2015-11-17 11:07:27 CET LOG: Datenbanksystem wurde am 2015-11-17 11:07:20 CET heruntergefahren 2015-11-17 11:07:27 CET LOG: Datenbanksystem ist bereit, um Verbindungen anzunehmen 2015-11-17 11:07:27 CET LOG: Autovacuum-Launcher startet 2015-11-17 11:07:27 CET LOG: unvollst?ndiges Startpaket
Unter UMC/Systemdienste habe ich PG ebenfalls nicht, ob das ein Bug ist, könnte nur Univention beantworten.

Wie sehen

root@xxxxxx ~ # ucr search postgres/autostart postgres/autostart: <empty>
und

root@xxxxx ~ # ucr search postgres8/autostart postgres8/autostart: <empty>
bei dir aus? ‘postgres9/autostart’ gibt es bei mir interessanterweise auch nicht.

Wie sieht dein Startscript aus? Hier:

[code]root@xxxxx ~ # cat /etc/init.d/postgresql
#!/bin/sh
set -e

BEGIN INIT INFO

Provides: postgresql

Required-Start: $local_fs $remote_fs $network $time

Required-Stop: $local_fs $remote_fs $network $time

Should-Start: $syslog

Should-Stop: $syslog

Default-Start: 2 3 4 5

Default-Stop: 0 1 6

Short-Description: PostgreSQL RDBMS server

END INIT INFO

Setting environment variables for the postmaster here does not work; please

set them in /etc/postgresql///environment instead.

[ -r /usr/share/postgresql-common/init.d-functions ] || exit 0

. /usr/share/postgresql-common/init.d-functions

versions can be specified explicitly

if [ -n “$2” ]; then
versions="$2 $3 $4 $5 $6 $7 $8 $9"
else
get_versions
fi

case “$1” in
start|stop|restart|reload)
# check ucr autostart setting
if [ -f “/usr/share/univention-config-registry/init-autostart.lib” ]; then
. “/usr/share/univention-config-registry/init-autostart.lib”
check_autostart postgres8 postgres8/autostart
fi
for v in $versions; do
$1 $v
done
;;
status)
set +e
for v in $versions; do
($1 $v)
done
;;
force-reload)
for v in $versions; do
reload $v
done
;;
*)
echo “Usage: $0 {start|stop|restart|reload|force-reload|status} [version …]”
exit 1
;;
esac

exit 0[/code]

VG Robert

Hallo,
Eventuell noch ein kurzer Hinweis:
In der Vergangenheit wurden ähnliche Probleme (Dienst startet nicht automatisch, kann aber manuell gestartet werden) durch den Befehl “insserv” ausgelöst. Insserv aktiviert die installierten init-scripte, indem die passenden Links in den Runlevel-Verzeichnissen gesetzt werden. Da in einigen Paketen die LSB-Header fehlen, kann die richtige Reihenfolge durcheinander geraten, dann stimmen die rc-Startnummern nicht mehr. Das Problem tritt dann nicht im normalen Betrieb auf sondern wird erst bei einem Neustart entdeckt.

Mit freundlichem Gruß,
Jens Thorp-Hansen

Danke für den Tipp Herr Thorp-Hansen,

Auf unserem Bareos Kundensystem sehen nötige Links bzw. Reihenfolge so aus, ev. hilft das dem OP:

root@xxxx / # la /etc/rc2.d | grep -E "postgre|bareos" lrwxrwxrwx 1 root root 20 Nov 5 2014 S19postgresql -> ../init.d/postgresql lrwxrwxrwx 1 root root 20 Nov 5 2014 S20bareos-dir -> ../init.d/bareos-dir lrwxrwxrwx 1 root root 19 Nov 5 2014 S20bareos-fd -> ../init.d/bareos-fd lrwxrwxrwx 1 root root 19 Nov 5 2014 S20bareos-sd -> ../init.d/bareos-sd
VG Robert

Mastodon