Am 08.09.2017 um 10:54 schrieb Mathias Behrle:
- Urs Liska: " [Flug] Abhängigkeitsproblem (postgresql) bei Update" (Fri, 8 Sep 2017 10:02:20 +0200):
Hallo Urs,
Liebe Kollegen,
nach Längerem habe ich mal wieder ein Update auf meinem Server gewagt. Im Unterschied zum lokalen Rechner scheint das aber tatsächlich jedesmal Probleme zu geben, diesmal mit PostgreSQL.
Es wäre informationshalber noch gut, wenn du sagst, was das für ein Update war. Debian? Ubuntu? jessie -> stretch?
# cat /etc/lsb-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04.5 LTS"
Es war kein Distro-Sprung, sondern "nur" das normale apt-get upgrade.
Falls das von Belang ist, ist das Log des ursprünglichen "apt upgrade" angehängt. Dabei verblieben einige fehlerhafte Pakete, die auf Abhängigkeitsprobleme zwischen den verschiedenen Versionen hinweisen.
Warum überhaupt drei Versionen von PostgreSQL installiert sind, kann ich ehrlich gesagt nicht sagen, sicher hängt das mit den Anwendungen zusammen, die ich installiert habe (z.B. Gitlab, ownCloud, Roundcube etc.). Wenn ich das aktuelle Problem gelöst habe, sollte ich wohl versuchen, das auf eine Version zu reduzieren ...
Die drei Versionen von postgresql kommen daher, dass sich postgresql nicht anmasst, deine Datenbank-Cluster ohne Nachfrage zu akualisieren. Das muss immer manuell durch den admin erfolgen, die Anleitung hierfür findest z.B. in /usr/share/doc/postgresql-common/README.Debian.gz
Da siehst du auch, dass die Upgrade-Prozedur den alten Cluster immer in Ruhe lässt und die neuen Versionen jeweils auf anderen Ports laufen.
Ich würde dir folgendes vorschlagen:
- Zuerst den u.g. Fehler beseitigen und die Installation abschließen
OK, das habe ich (s.u.)
- Dann den gegenwärtig genutzten Cluster (das ist vermutlich der, der auf Port 5432 läuft) auf die neueste Version migrieren, d.h. den gegenwärtigen 9.6 Cluster löschen wie in der README beschrieben und migrieren.
- Anschließend alle Cluster herunterfahren und den 9.6 probehalber auf Port 5432 laufen lassen (nur diesen starten mit z.B. # service postgresql start 9.6 )
Ich muss sagen, das klingt mir jetzt erstmal zu heikel (zu viele Unbekannte auf einmal). Und nach Ralfs Kommentar (und letztlich auch deinem) macht es erstmal auch nichts aus, dreimal psql zu haben, oder?
- Wenn alle deine Applikationen, die auf die Postgres zugreifen, zur Zufriedenheit funktionieren, kannst du die alten Postgres-Versionen purgen. Bei Fehlern kannst du einfach den 9.6-Cluster stoppen und den/die anderen wieder hochfahren.
Ehrlich gesagt, bin ich mir nicht mehr sicher, welche Anwendungen Postgres verwenden. Und um mich noch mehr zu outen: Ich habe tatsächlich etwas den Überblick verloren, was ich auf dem Server alles installiert hatte. Was über die als Subdomains sichtbaren Einträge hinaus geht, ist irgendwie recht verschwommen in meinem Bewusstsein ...
Unten steht das Log beim Versuch, die verbleibenden fehlerhaften Pakete zu aktualisieren. Offensichtlich kann eines der Pakete nicht konfiguriert werden, anschließend können abhängige Pakete nicht aktualisiert werden. Was hier aber der Ursprung ist und was ich in welcher Reihenfolge untersuchen und lösen muss, kann ich nicht wirklich sagen. Es wäre toll, wenn ihr mir dabei auf die Sprünge helfen könntet!
Interessanterweise gibt "psql -V" aus: "psql (PostgreSQL) 9.6.5"
*Natürlich* funktioniert nun Gitlab nicht (wie eigentlich nach jedem Update, obwohl ich schon die Variante installiert habe, die per apt verwaltet wird ... Ich halte es aber für möglich, dass das an dem Upgrade-Problem von PostgreSQL liegt. (ownCloud und roundcube funktionieren aber nach wie vor, immerhin ...)
Fehlerbehebung siehe weiter unten...
Viele Grüße, Mathias
Herzliche Grüße Urs
###
orion2208:/home/uliska# apt upgrade Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Paketaktualisierung (Upgrade) wird berechnet... Fertig 0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert. 9 nicht vollständig installiert oder entfernt. Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt. Möchten Sie fortfahren? [J/n] postgresql-common (184.pgdg14.04+1) wird eingerichtet ...
- Starting PostgreSQL 9.4 database server
[ OK ]
- Starting PostgreSQL 9.5 database server
[ OK ]
- Starting PostgreSQL 9.6 database
server * The PostgreSQL server failed to start. Please check the log output: 2017-09-08 09:39:00 CEST [28701-1] LOG: ungültige IP-Maske »md5«: Name or service not known 2017-09-08 09:39:00 CEST [28701-2] ZUSAMMENHANG: Zeile 93 in Konfigurationsdatei »/etc/postgresql/9.6/main/pg_hba.conf«
Hier ist der Fehler geschildert: in deiner pga_hba.conf ist ein ungültiger IP-Bereich eingetragen in Zeile 93.
Am 08.09.2017 um 10:45 schrieb Ralf Mattes:
Wenn ich das Log richtig interpretiere echauffiert sich Pg9.6 über eine Zeile in Deiner Postgres Host-Based Authentication Konfiuration (pg_hba.conf) Da erartet der Server eine Netmask und findet etwas das für mich nach einem Password-Hash Algorythmus aussieht. Hmm, hast Du da vieleicht den Zugriff von einem Host mit einer IP-Adresse versucht zu konfigurieren? Postgres erwartet aber ein Netz, also Basisadresse plus Netmask, entweder als 'nnn.nnn.nnn.nnn nn' oder als 'nnn.nnn.nnn.nnn/nn' Wenn da also eine einzelne IP-Adresse steht dann versucht der Server die nächste Spalte als Netmask zu interpretieren.
Der entsprechende Abschnitt in pg_hba.conf sieht in der Tat so aus:
91 # IPv4 local connections: 92 host all all 127.0.0.1/32 md5 93 host all all 85.25.93.165 md5
Die IP in Zeile 93 ist die IP des Servers, ich weiß aber nicht, wann und warum die da reingekommen ist (ich muss wirklich mal damit anfangen, /etc gleich nach der Installation und dann auch konsequent mit Git zu tracken ...). Die entsprechenden Dateien für 9.4 und 9.5 haben diese zweite Zeile nicht, und ...
Nach Korrektur oder Auskommentieren(?) die Installation abschließen mit nochmals apt-get upgrade
... nach Auskommentieren funktionierte das upgrade tatsächlich ohne Schwierigkeiten.
Offensichtlich hatte ich bei der Konfiguration eines Programms die Server-IP eingetragen, keine Ahnung, weshalb. Andererseits habe ich auch keine Ahnung, weshalb es *bisher* keine Probleme gab ...
Die Gitlab-Frage werde ich separat nochmal aufgreifen, die dürfte nichst mit Postgre zu tun haben. Ich habe nämlich festgestellt, dass Gitlab durchaus läuft und nur beim Einloggen einen Fehler produziert. Per URL auf öffentliche Projekte zuzugreifen, funktioniert nämlich problemlos ...
Vielen Dank euch beiden und erstmal herzliche Grüße Urs