[Flug] ?==?utf-8?q? Abhängigkeitsproblem?==?utf-8?q? (postgresql) bei Update

Ralf Mattes rm at mh-freiburg.de
Fr Sep 8 19:00:37 CEST 2017


 
Am Freitag, 08. September 2017 18:25 CEST, Urs Liska <ul at openlilylib.org> schrieb: 
 
> 
> 
> 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
> 
> -- 
> ul at openlilylib.org
> https://openlilylib.org
> http://lilypondblog.org
> 
> _______________________________________________
> Freiburger Linux User Group
> Mail an die Liste: flug at lug-freiburg.de
> Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug 
 
 
 




Mehr Informationen über die Mailingliste Flug