8 Sep
2017
8 Sep
'17
10:02 a.m.
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.
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 ...
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 ...)
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«
2017-09-08 09:39:00 CEST [28701-3] FATAL: konnte pg_hba.conf nicht laden
2017-09-08 09:39:00 CEST [28701-4] LOG: Datenbanksystem ist
heruntergefahren
[fail]
invoke-rc.d: initscript postgresql, action "start" failed.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-common (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert
1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von postgresql-9.6:
postgresql-9.6 hängt ab von postgresql-common (>= 171~); aber:
Paket postgresql-common ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-9.6 (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von postgresql:
postgresql hängt ab von postgresql-9.6; aber:
Paket postgresql-9.6 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von postgresql-9.4:
postgresql-9.4 hängt ab von postgresql-common (>= 142~); aber:
Paket postgresql-common ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-9.4 (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von postgresql-9.5:
postgresql-9.5 hängt ab von postgresql-common (>= 158~); aber:
Paket postgresql-common ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-9.5 (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von
postgresql-contrib-9.6:
postgresql-contrib-9.6 hängt ab von postgresql-9.6 (=
9.6.5-1.pgdg14.04+1); aber:
Paket postgresql-9.6 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-contrib-9.6
(--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von postgresql-contrib:
postgresql-contrib hängt ab von postgresql-contrib-9.6; aber:
Paket postgresql-contrib-9.6 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-contrib (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von
postgresql-contrib-9.4:
postgresql-contrib-9.4 hängt ab von postgresql-9.4 (=
9.4.14-1.pgdg14.04+1); aber:
Paket postgresql-9.4 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-contrib-9.4
(--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von
postgresql-contrib-9.5:
postgresql-contrib-9.5 hängt ab von postgresql-9.5 (=
9.5.9-1.pgdg14.04+1); aber:
Paket postgresql-9.5 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-contrib-9.5
(--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
postgresql-common
postgresql-9.6
postgresql
postgresql-9.4
postgresql-9.5
postgresql-contrib-9.6
postgresql-contrib
postgresql-contrib-9.4
postgresql-contrib-9.5
E: Sub-process /usr/bin/dpkg returned an error code (1)
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
8 Sep
8 Sep
10:45 a.m.
New subject: [Flug] ?==?utf-8?q? Abhängigkeitsproblem?==?utf-8?q? (postgresql) bei Update
Am Freitag, 08. September 2017 10:02 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Liebe Kollegen,
Hallo Urs,
<....>
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 ...
Ist das eine (Bastard)Debian? Dann ist das normal. Datenbanken sind so kritisch
dass man das lieber nicht einfach mal so mit einem Updatescript in situ verändern will.
Und bei einer Serveranwendung kann man nie sicher sein dass Client-Anwendungen auch
mit einer neuen Version noch zusammenarbeiten. Die (automatische) Migration von
MySQL auf MariaDB hat bei meinem Debian-Server so richtig hefftig geknallt.
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!
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.
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 ...)
Schau' mal auf welchen Ports die einz. Programme konfiguriert sind. Unter
Debian zumindest werden per default _alle_ Versionen gestartet, alle auf
unterschiedlichen Ports. Wahrscheinlich ist es sinnvoll nach vollzogener
Migration die alten Versionen zu deinstallieren und den Port auf 5432
anzupassen.
Bez. Gitlab: mir persönlich reicht gitea vollkommen aus. Scheint mir
viel einfacher zu warten ... ;-)
Gruss RalfD
9 Sep
9 Sep
12:58 p.m.
New subject: [Flug] Gitlab/Gitea (war: Abhängigkeitsproblem (postgresql) bei Update)
Hallo Ralf,
Am 08.09.2017 um 10:45 schrieb Ralf Mattes:
Bez. Gitlab: mir persönlich reicht gitea vollkommen
aus. Scheint mir
viel einfacher zu warten ... ;-)
Hm, als ich nach einer Github-Ergänzung recherchiert hatte, ist mir das
nicht untergekommen. Damals war es wohl noch weit von einer 1.0
entfernt, vielleicht lag es daran.
https://try.gitea.io/ sieht aus, als ob es mir auch reichen könnte, und
wenn die Wartung leichter ist, bin ich gerne bereit, es auszuprobieren.
Was mir allerdings gar nicht passt, sind die doch recht spartanischen
Installationsanleitungen. V.a.
https://docs.gitea.io/en-us/install-from-binary/ (was mir die richtige
Seite zu sein scheint), sagt doch eigentlich recht wenig. Ich brauche ja
nicht eine gestartete ausführbare Datei, sondern eine Einrichtung, dass
Gitea a) als Dienst permanent läuft, b) richtig mit der Datenbank
zusammenarbeitet und c) korrekt von nginx angesprochen wird.
Hättest du da etwas wie einen Link oder eine sonstige Ressource, wo ich
nachhaltigere Infos finden kann?
HG
Urs
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
1:37 p.m.
New subject: [Flug] ?==?utf-8?q? ?==?utf-8?q? Gitlab/Gitea (war:?==?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)
Am Samstag, 09. September 2017 12:58 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Hallo Ralf,
Am 08.09.2017 um 10:45 schrieb Ralf Mattes:
Das ist auch ein Fork von Gogs, dem ursprünglichen Go-Projekt als GitLab-Alternative.
Bez. Gitlab: mir persönlich reicht gitea
vollkommen aus. Scheint mir
viel einfacher zu warten ... ;-)
Hm, als ich nach einer Github-Ergänzung recherchiert hatte, ist mir das
nicht untergekommen. Damals war es wohl noch weit von einer 1.0
entfernt, vielleicht lag es daran. https://try.gitea.io/ sieht aus, als ob es mir auch
reichen könnte, und
wenn die Wartung leichter ist, bin ich gerne bereit, es auszuprobieren.
Es ist einfach schön minimal.
Was mir allerdings gar nicht passt, sind die doch
recht spartanischen
Installationsanleitungen. V.a.
https://docs.gitea.io/en-us/install-from-binary/ (was mir die richtige
Seite zu sein scheint), sagt doch eigentlich recht wenig. Ich brauche ja
nicht eine gestartete ausführbare Datei, sondern eine Einrichtung, dass
Gitea a) als Dienst permanent läuft, b) richtig mit der Datenbank
zusammenarbeitet und c) korrekt von nginx angesprochen wird.
Die gehen (fälschlicherweise) oft davon aus dass man die Gogs-Doku kennt.
Es ist allerdings wirklich unheimlich trivial. Ein Verzeichnis für das Teil
anlegen, ein Conf-Verzeichnis mit einer Conf-Datei (das ist schon die Luxus-
variante von mir weil Gitea standardmässig die Conf-Datei im Server-Verzeichnis
sucht, ich möchte die aber (s.o.) gerne unter /etc haben).
Du solltest am besten noch einen eigenen User für den Dienst haben (den braucht's
wenn man Git über ssh mit Zertifikaten will).
Meine Instanz ist so popelig dass ich das mit der eingebauten SQLite3 Datenbankmache.
Ich denke das wird bei Dir nicht viel anderst sein.
Start/Stop mache ich über systemd, für soetwas ist der eig. recht brauchbar.
Das Unit-File sieht bei mir so aus:
/-------------------- /etc/systemd/system/gitea.service
-----------------------------------------------/
[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
[Service]
Type=simple
User=gitea
Group=gitea
WorkingDirectory=/srv/gitea
ExecStart=/srv/gitea/gitea web
Restart=always
Environment=USER=gitea HOME=/srv/gitea GITEA_CUSTOM=/etc/gitea GITEA_WORK_DIR=/srv/gitea
[Install]
WantedBy=multi-user.target
/-----------------------------------------------------------------------------------------------------------------/
Hättest du da etwas wie einen Link oder eine sonstige Ressource, wo ich
nachhaltigere Infos finden kann?
Falls Dir das oben nicht reicht - melde Dich.
Gruss RalfD
HG
Urs
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug(a)lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
11 Sep
11 Sep
5:59 p.m.
New subject: [Flug] ?==?utf-8?q? ?==?utf-8?q? Gitlab/Gitea (war:?==?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)
9. September 2017 13:37, "Ralf Mattes" <rm(a)mh-freiburg.de> schrieb:
Am Samstag, 09. September 2017 12:58 CEST, Urs Liska
<ul(a)openlilylib.org> schrieb:
OK, das erklärt Einiges ...
Hallo Ralf,
Am 08.09.2017 um 10:45 schrieb Ralf Mattes:
Bez. Gitlab: mir persönlich reicht gitea vollkommen aus. Scheint mir
viel einfacher zu warten ... ;-)
Hm, als ich nach einer Github-Ergänzung recherchiert hatte, ist mir das
nicht untergekommen. Damals war es wohl noch weit von einer 1.0
entfernt, vielleicht lag es daran.
Das ist auch ein Fork von Gogs, dem ursprünglichen Go-Projekt als GitLab-Alternative.
https://try.gitea.io sieht aus, als ob es mir
auch reichen könnte, und
wenn die Wartung leichter ist, bin ich gerne bereit, es auszuprobieren.
Es ist einfach schön minimal.
Was mir allerdings gar nicht passt, sind die doch
recht spartanischen
Installationsanleitungen. V.a.
https://docs.gitea.io/en-us/install-from-binary (was mir die richtige
Seite zu sein scheint), sagt doch eigentlich recht wenig. Ich brauche ja
nicht eine gestartete ausführbare Datei, sondern eine Einrichtung, dass
Gitea a) als Dienst permanent läuft, b) richtig mit der Datenbank
zusammenarbeitet und c) korrekt von nginx angesprochen wird.
Die gehen (fälschlicherweise) oft davon aus dass man die Gogs-Doku kennt. Es ist allerdings wirklich unheimlich trivial. Ein
Verzeichnis für das Teil
anlegen, ein Conf-Verzeichnis mit einer Conf-Datei (das ist schon die Luxus-
variante von mir weil Gitea standardmässig die Conf-Datei im Server-Verzeichnis
sucht, ich möchte die aber (s.o.) gerne unter /etc haben).
Du solltest am besten noch einen eigenen User für den Dienst haben (den braucht's
wenn man Git über ssh mit Zertifikaten will).
Ja, das will ich, und es sollte ja auch machbar sein ...
Meine Instanz ist so popelig dass ich das mit der
eingebauten SQLite3 Datenbankmache.
Ich denke das wird bei Dir nicht viel anderst sein.
Start/Stop mache ich über systemd, für soetwas ist der eig. recht brauchbar.
Das Unit-File sieht bei mir so aus:
/-------------------- /etc/systemd/system/gitea.service
-----------------------------------------------/
[Unit]
Description=Gitea (Git with a cup of tea)
After=syslog.target
After=network.target
[Service]
Type=simple
User=gitea
Group=gitea
WorkingDirectory=/srv/gitea
ExecStart=/srv/gitea/gitea web
Restart=always
Environment=USER=gitea HOME=/srv/gitea GITEA_CUSTOM=/etc/gitea GITEA_WORK_DIR=/srv/gitea
[Install]
WantedBy=multi-user.target
/---------------------------------------------------------------------------------------------------
-------------/
OK, danke. Das habe ich noch nie gemacht, aber mit diesem Beispiel und den manpages sollte
ich das ja wohl hinbekommen ...
Gruß
Urs
Hättest du da etwas wie einen Link oder eine
sonstige Ressource, wo ich
nachhaltigere Infos finden kann?
Falls Dir das oben nicht reicht - melde Dich.
Gruss RalfD
HG
Urs
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug(a)lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug(a)lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
12 Sep
12 Sep
2:57 p.m.
New subject: [Flug] ?= Gitlab/Gitea (war:=?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)
Am 09.09.2017 um 13:37 schrieb Ralf Mattes:
Die gehen (fälschlicherweise) oft davon aus dass man
die Gogs-Doku kennt.
Es ist allerdings wirklich unheimlich trivial. Ein Verzeichnis für das Teil
anlegen, ein Conf-Verzeichnis mit einer Conf-Datei (das ist schon die Luxus-
variante von mir weil Gitea standardmässig die Conf-Datei im Server-Verzeichnis
sucht, ich möchte die aber (s.o.) gerne unter /etc haben).
Du solltest am besten noch einen eigenen User für den Dienst haben (den braucht's
wenn man Git über ssh mit Zertifikaten will).
Meine Instanz ist so popelig dass ich das mit der eingebauten SQLite3 Datenbankmache.
Ich denke das wird bei Dir nicht viel anderst sein.
Ich habe es tatsächlich so weit gebracht, dass die Installationsseite
durchgeht. Zunächst noch mit einem von Hand gestarteten Server, aber
hinter nginx als Proxy. Die Mail-Funktion habe ich noch nicht getestet,
da ich nicht weiß, wie man sie manuall anstoßen kann.
Start/Stop mache ich über systemd, für soetwas ist der eig. recht brauchbar.
Das Unit-File sieht bei mir so aus:
Das wollte ich auch so machen, stellte dann aber fest, dass systemd
*nicht* installiert ist. Das kam bei Ubuntu erst in 15.04 als
vorinstalliert dazu.
Bevor ich damit weitermache: lohnt es sich, systemd nun extra zu
installieren oder sollte ich einen anderen Weg einschlagen, um gitea
"diensttauglich" zu machen?
Gruß
Urs
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
3:07 p.m.
New subject: [Flug] ?==?utf-8?q? ?==?utf-8?q? ?= Gitlab/Gitea?==?utf-8?q? (war:=?utf-8?q? Abhängigkeitsproblem?==?utf-8?q? (postgresql) bei Update)
Am Dienstag, 12. September 2017 14:57 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Die Mailfunktion nutze ich im Agenblick gar nicht.
Ach ja, das ist ja FummelBuntu ;-) Da war doch was ...
Am 09.09.2017 um 13:37 schrieb Ralf Mattes:
<...>
Meine Instanz
ist so popelig dass ich das mit der eingebauten SQLite3 Datenbankmache.
Ich denke das wird bei Dir nicht viel anderst sein.
Ich habe es tatsächlich so weit gebracht, dass die Installationsseite
durchgeht. Zunächst noch mit einem von Hand gestarteten Server, aber
hinter nginx als Proxy. Die Mail-Funktion habe ich noch nicht getestet,
da ich nicht weiß, wie man sie manuall anstoßen kann.
Start/Stop mache ich über systemd, für soetwas ist der eig. recht brauchbar.
Das Unit-File sieht bei mir so aus:
Das wollte ich auch so machen, stellte dann aber fest, dass systemd
*nicht* installiert ist. Das kam bei Ubuntu erst in 15.04 als
vorinstalliert dazu. Bevor ich damit weitermache: lohnt es sich, systemd
nun extra zu
installieren oder sollte ich einen anderen Weg einschlagen, um gitea
"diensttauglich" zu machen?
Ich bin sicherlich der Allerletzte der sagt "nutze Systemd". Ich mache das bei
meinen Servern nur weil es eben (leider) das Standard-Initsystem bei Debian ist.
Der "andere" Weg für Ubuntu: das nutzt das selbstgepfriemelte Upstart dass
allerdings
inzwischen beerdigt wurde. Da musst Du wohl ein Upstart-Script schreiben (was aber nicht
alzu aufwändig sein sollte).
Gruss RalfD
9 Sep
9 Sep
1:38 p.m.
New subject: [Flug] Gitlab/Gitea (war: Abhängigkeitsproblem (postgresql) bei Update)
* Urs Liska: " [Flug] Gitlab/Gitea (war: Abhängigkeitsproblem (postgresql) bei
Update)" (Sat, 9 Sep 2017 12:58:39 +0200):
Hallo Ralf,
Am 08.09.2017 um 10:45 schrieb Ralf Mattes:
Eine gute Lösung zur schlichten Verwaltung von git Repos bietet auch gitolite
und das ist bereits gepackt.
https://packages.debian.org/sid/gitolite3
Bez. Gitlab: mir persönlich reicht gitea
vollkommen aus. Scheint mir
viel einfacher zu warten ... ;-)
Hm, als ich nach einer Github-Ergänzung recherchiert hatte, ist mir das
nicht untergekommen. Damals war es wohl noch weit von einer 1.0
entfernt, vielleicht lag es daran. https://try.gitea.io/ sieht aus, als ob es mir auch
reichen könnte, und
wenn die Wartung leichter ist, bin ich gerne bereit, es auszuprobieren.
Was mir allerdings gar nicht passt, sind die doch recht spartanischen
Installationsanleitungen. V.a.
https://docs.gitea.io/en-us/install-from-binary/ (was mir die richtige
Seite zu sein scheint), sagt doch eigentlich recht wenig. Ich brauche ja
nicht eine gestartete ausführbare Datei, sondern eine Einrichtung, dass
Gitea a) als Dienst permanent läuft, b) richtig mit der Datenbank
zusammenarbeitet und c) korrekt von nginx angesprochen wird.
Das Teil wird gerade für Debian gepackt, es fehlen noch die JS Dependencies.
Vielleicht hast du Lust, da mitzuhelfen?
https://github.com/MTecknology/gitea-wip/blob/master/work_in_progress
Hättest du da etwas wie einen Link oder eine sonstige
Ressource, wo ich
nachhaltigere Infos finden kann?
https://duckduckgo.com/?q=gitea+nginx&t=ffsb&ia=web
Die ersten Treffer sollten dir weiterhelfen:
https://blog.yumdap.net/gitea-oder-gogs-statt-github-und-gitlab/
https://gist.github.com/Nitya-Sattva/75e69de05218c14ecf8e7d97edcd48aa
ansonsten
https://docs.gitea.io/en-us/config-cheat-sheet/
Viel Erfolg,
Mathias
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
6:36 p.m.
New subject: [Flug] ?==?utf-8?q? ?==?utf-8?q? Gitlab/Gitea (war:?==?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)
Am Samstag, 09. September 2017 13:38 CEST, Mathias Behrle <mathiasb(a)m9s.biz>
schrieb:
Eine gute Lösung zur schlichten Verwaltung von git
Repos bietet auch gitolite
und das ist bereits gepackt.
https://packages.debian.org/sid/gitolite3
Das ist aber schon deutlich anderst als Github/GitLab. Gitolite ist ein
Programmpaket um einen Remote Gitserver der SSH-Zugriff erlaubt zu
managen - also kein Anonymous Zugriff, kein Zugriff über http(s) und
kein WebGUI. Auch kein Projekt-Wiki und kein Issue-Tracker.
Nur um klar zu sein: ich selbst nutze das um meine privaten Repositories zu hosten,
und für einen "richtigen" Entwickler hat es ein paar tolle Features (z.Bsp.
einen
beeindruckend präzise konfigurierbaren Zugriffsschutz). Für Leute die Github
kennen/nutzen eher nichts.
Das Teil wird gerade für Debian gepackt, es fehlen
noch die JS Dependencies.
Vielleicht hast du Lust, da mitzuhelfen?
https://github.com/MTecknology/gitea-wip/blob/master/work_in_progress
Das Teil ist so trivial dass sich mir der Nutzen eines Debian-Pakets nicht ganz
erschliesst.
Wenn ich das recht sehe dann besteht die (Haupt)Arbeit daraus nicht
Debian-Lizenzkonmpatible
CSS Dateien zu ersetzen und die mit Gitea ausgelieferten JavaScript-Dateien als eigene
Debian-Pakete
bereitzustellen. Da habe ich ehrlich gesagt besseres zu tun ...
Die ersten Treffer sollten dir weiterhelfen:
https://blog.yumdap.net/gitea-oder-gogs-statt-github-und-gitlab/
... hmm. Serverdaten gehören aber eher nicht unter /opt ...
Und warum muss man den um Himmels willen 'supervisor' installieren wenn sowieso
schon der systemd
läuft?
Wenn ich lese dass man seine sshd-Conf verändert und dann Rebooten muss (sic!) dann möchte
ich
eigentlich erst einmal laut aufschreien.
Das sollte vollkommen ausreichen.
Gruss RalfD
Viel Erfolg,
Mathias
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
11 Sep
11 Sep
5:56 p.m.
New subject: [Flug] ?==?utf-8?q? ?==?utf-8?q? Gitlab/Gitea (war:?==?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)
9. September 2017 18:36, "Ralf Mattes" <rm(a)mh-freiburg.de> schrieb:
Am Samstag, 09. September 2017 13:38 CEST, Mathias
Behrle <mathiasb(a)m9s.biz> schrieb:
Das stimmt (beides), und das ist auf jeden Fall *nicht* das, was ich brauche. Ich brauche
schon die
"größere Kiste" mit Web-Interface, Issues, Pull Requests, Wikis etc., um
gemeinschaftliche und
teils auch öffentliche Projekte zu hosten.
Eine gute Lösung zur schlichten Verwaltung von
git Repos bietet auch gitolite
und das ist bereits gepackt.
https://packages.debian.org/sid/gitolite3
Das ist aber schon deutlich anderst als Github/GitLab. Gitolite ist ein
Programmpaket um einen Remote Gitserver der SSH-Zugriff erlaubt zu
managen - also kein Anonymous Zugriff, kein Zugriff über http(s) und
kein WebGUI. Auch kein Projekt-Wiki und kein Issue-Tracker. Nur um klar zu sein: ich selbst nutze das um meine
privaten Repositories zu hosten,
und für einen "richtigen" Entwickler hat es ein paar tolle Features (z.Bsp.
einen
beeindruckend präzise konfigurierbaren Zugriffsschutz). Für Leute die Github
kennen/nutzen eher nichts.
Ich werde das im Kopf behalten. Ansonsten scheint mir diese Anleitung sehr nützlich zu
sein, insbesondere hinsichtlich der Integration mit nginx.
Ich bin grade nicht sicher, aber ich glaube, Gitlab nistet sich auch in /opt ein. Ich
werde aber wohl eher einen Unterordner im Home-Verzeichnis des gitea-Users nehmen.
Das Teil wird gerade für Debian gepackt, es
fehlen noch die JS Dependencies.
Vielleicht hast du Lust, da mitzuhelfen?
https://github.com/MTecknology/gitea-wip/blob/master/work_in_progress
Das Teil ist so trivial dass sich mir der Nutzen eines Debian-Pakets nicht ganz
erschliesst.
Wenn ich das recht sehe dann besteht die (Haupt)Arbeit daraus nicht
Debian-Lizenzkonmpatible
CSS Dateien zu ersetzen und die mit Gitea ausgelieferten JavaScript-Dateien als eigene
Debian-Pakete
bereitzustellen. Da habe ich ehrlich gesagt besseres zu tun ...
Die ersten Treffer sollten dir weiterhelfen:
https://blog.yumdap.net/gitea-oder-gogs-statt-github-und-gitlab
... hmm. Serverdaten gehören aber eher nicht unter /opt ...
Und warum muss man den um Himmels willen 'supervisor' installieren wenn sowieso
schon der systemd
läuft?
Wenn ich lese dass man seine sshd-Conf verändert und dann Rebooten muss (sic!) dann
möchte ich
eigentlich erst einmal laut aufschreien.
Wenn ich es recht sehe, brauche ich diese Infos auch gar nicht zusätzlich zu den anderen.
Das sollte vollkommen ausreichen.
Ich schaue es mir ASAP an.
Vielleicht bekomme ich ja so einen Koloss von meinem Server geschafft :-)
In dem Zusammenhang kann ich vermelden, dass ich heute einen neuen Webmailer gefunden
habe, der mich aus ähnlichen Gründen auf den ersten Blick überzeugt hat: RainLoop
(https://www.rainloop.net/) statt Roundcube (https://roundcube.net/). Läuft schneller,
sieht besser aus (und funktioniert v.a. gut auf dem Mobil-Bildschirm), ich kann mehrere
Email-Konten mit *einer* Anmeldung verwalten (und sogar mein web.de-Konto).
Und schließlich verwendet die Anwendung erstmal gar keine Datenbank, kann aber optional
das Adressbuch in einer Sqlite-DB speichern (und es sogar mit meinem CalDAV-Server
synchronisieren) :-)
Ein weiterer Koloss, der weg kann (Roundcube).
Als nächstes werde ich mir wohl ownCloud vornehmen. Ich habe festgestellt, dass ich davon
eigentlich nur die Datei-Synchronisierung verwende, und dafür braucht es auch nicht so
eine Riesenanwendung. Seafile (https://www.seafile.com/en/features/) scheint mir nett
auszusehen, aber vielleicht hat ja jemand noch andere Vorschläge (Mindestanforderungen:
Automatische Synchronisation mit Linux und Windows, Zugriff über Android-App, Teilen von
Dateien/Ordnern per Link. Medien-Betrachter im Browser ist nett, aber nicht Voraussetzung,
gemeinsames Bearbeiten brauche ich nicht).
HG
Urs
Gruss RalfD
Viel Erfolg,
Mathias
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug(a)lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
6:14 p.m.
New subject: [Flug] ?==?utf-8?q? ?= Gitlab/Gitea (war:=?utf-8?q? Abhängigkeitsproblem?==?utf-8?q? (postgresql) bei Update)
Am Montag, 11. September 2017 17:56 CEST, ul(a)openlilylib.org schrieb:
Ja, das ist aber ein trivialer Proxy.
Siehtst Du richtig. Wenn Du mit über's ssh-Protokoll und Schlüsseln zugreifen willst
dann brauchst
Du einen Nutzer (bei mir gitea:gitea) dessen HOME dort liegt wo auch Deine Installation
ist
(bei mir '/srv/gitea'). Mehr nicht.
Wenn Du viele bestehende Nuter mit Schlüsseln hast dann melde Dich wegen der Migration.
... hmm.
Serverdaten gehören aber eher nicht unter /opt ...
Und warum muss man den um Himmels willen 'supervisor' installieren wenn sowieso
schon der systemd
läuft?
Ich werde das im Kopf behalten. Ansonsten scheint mir diese Anleitung sehr nützlich zu
sein, insbesondere hinsichtlich der Integration mit nginx. Ich bin grade nicht sicher, aber ich glaube, Gitlab
nistet sich auch in /opt ein. Ich werde aber wohl eher einen Unterordner im
Home-Verzeichnis des gitea-Users nehmen.
Das nistet sich hoffentlich dort ein wo Du es hinlegst. Unter Debianoiden sollten Server
inzwischen unter '/srv' liegen
(gaaanz früher gab's da das '/var/www' :-)
Wenn ich lese dass man seine sshd-Conf verändert und dann Rebooten muss (sic!) dann
möchte ich
eigentlich erst einmal laut aufschreien.
Wenn ich es recht sehe, brauche ich diese Infos auch gar nicht zusätzlich zu den anderen.
Ich schaue es mir ASAP an.
Vielleicht bekomme ich ja so einen Koloss von meinem Server geschafft :-)
Ich war so entsetzt über Gitlab dass ich das gar nicht erst installiert habe :-)
In dem Zusammenhang kann ich vermelden, dass ich heute einen neuen Webmailer gefunden
habe, der mich aus ähnlichen Gründen auf den ersten Blick überzeugt hat: RainLoop
(https://www.rainloop.net/) statt Roundcube (https://roundcube.net/). Läuft schneller,
sieht besser aus (und funktioniert v.a. gut auf dem Mobil-Bildschirm), ich kann mehrere
Email-Konten mit *einer* Anmeldung verwalten (und sogar mein web.de-Konto).
Und schließlich verwendet die Anwendung erstmal gar keine Datenbank, kann aber optional
das Adressbuch in einer Sqlite-DB speichern (und es sogar mit meinem CalDAV-Server
synchronisieren) :-)
Ein weiterer Koloss, der weg kann (Roundcube).
Sieht ja ganz nett aus.
Als nächstes werde ich mir wohl ownCloud vornehmen.
Ich habe
festgestellt, dass ich davon eigentlich nur die
Datei-Synchronisierung verwende, und dafür braucht es auch nicht so
eine Riesenanwendung. Seafile (https://www.seafile.com/en/features/)
scheint mir nett auszusehen, aber vielleicht hat ja jemand noch
andere Vorschläge (Mindestanforderungen: Automatische
Synchronisation mit Linux und Windows, Zugriff über Android-App,
Teilen von Dateien/Ordnern per Link. Medien-Betrachter im Browser
ist nett, aber nicht Voraussetzung, gemeinsames Bearbeiten brauche
ich nicht).
Also "ich" benutze da in der Tat SeaFile (metaphorisch - ich setzte das
bei den Neutönern der HFMDK-Frankfurt ein und habe auch hier eine Guerilla-
Instanz). Ist recht brauchbar. Für mich ein grosser Vorteil: ich kann sowohl
Gitea als auch SeaFile an einen LDAP-Server anflanschen, dasmacht die Account-
verwaltung recht einfach.
Gruss RalfD
9:47 p.m.
New subject: [Flug] Gitlab/Gitea (war: Abhängigkeitsproblem (postgresql) bei Update)
Am 11.09.2017 um 18:14 schrieb Ralf Mattes:
Siehtst Du richtig. Wenn Du mit
über's ssh-Protokoll und Schlüsseln zugreifen willst dann brauchst
Du einen Nutzer (bei mir gitea:gitea) dessen HOME dort liegt wo auch Deine Installation
ist
(bei mir '/srv/gitea'). Mehr nicht.
Das habe ich vor. Ich überlege noch, ob ich bei der Gelegenheit die
Daten von /var/www/vhosts auch nach /srv verschieben soll. Ich muss nur
sehen, dass das auch tatsächlich funktioniert. nginx kann ich das leicht
beibringen, ich weiß aber nicht, ob vielleicht in irgendwelchen Apps
absolute Pfade hinterlegt sind. Na ja, ich muss das wohl erstmal als
*Kopie* machen und dann alle Subdomains testen ...
Nun ja, über die Omnibus-Packages ist die Installation eigentlich nicht
wirklich aufwendig gewesen. Problematisch wurde es nur bei Updates, die
i.d.R. nicht reibungslos abliefen. Dann gibt es keine verlässliche
Dokumentation, sondern nur zahllose Tipps und Tricks, die für
unterschiedliche Versionen total unterschiedlich sind, so dass man
nichts damit anfangen kann.
Komischerweise hat es bis jetzt *jedesmal* nach ein paar Tagen von
selbst wieder funktioniert (obwohl ich testhalber gleich zu Beginn den
Browsercache geleert hatte).
HG
Urs
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
Am Montag, 11. September 2017 17:56 CEST,
ul(a)openlilylib.org schrieb:
Ja, das ist
aber ein trivialer Proxy.
Nicht, wenn ich es per apt über das Package installiert habe.
Tatsächlich liegt das Home-Verzeichnis und die Installation in
/var/opt/gitlab :-O
... hmm.
Serverdaten gehören aber eher nicht unter /opt ...
Und warum muss man den um Himmels willen 'supervisor' installieren wenn sowieso
schon der systemd
läuft?
Ich werde das im Kopf behalten. Ansonsten scheint mir diese Anleitung sehr
nützlich zu sein, insbesondere hinsichtlich der Integration mit nginx. Ich bin grade nicht sicher, aber ich glaube,
Gitlab nistet sich auch in /opt ein. Ich werde aber wohl eher einen Unterordner im
Home-Verzeichnis des gitea-Users nehmen.
Das nistet sich hoffentlich dort ein wo Du
es hinlegst. Unter Debianoiden sollten Server inzwischen unter
'/srv' liegen
(gaaanz früher gab's da das '/var/www' :-)
Hm:
https://wiki.debian.org/FilesystemHierarchyStandard sagt einerseits:
/srv/ => "Site-specific data which is *s*e*rv*ed by the system (Not
part of FHS)."
andererseits:
/var/ => "*Var*iable data, such as logs, databases, *websites*, and
temporary spool (e-mail..) files"
Wenn ich lese
dass man seine sshd-Conf verändert und dann Rebooten muss (sic!) dann möchte ich
eigentlich erst einmal laut aufschreien.
Wenn ich es recht sehe, brauche ich diese
Infos auch gar nicht zusätzlich zu den anderen.
Wenn Du viele bestehende Nuter mit Schlüsseln hast dann melde Dich wegen der Migration.
Darauf werde ich vielleicht zurückkommen. Es sind brutto 63 User, von
denen aber sicher etliche bei der Gelegenheit rausfallen. Die andere
Frage ist, ob man auch Issues bzw. Projekte von Gitlab importieren kann.
Von den etwas mehr als 100 offenen Issues können sicher auch ein paar
verloren gehen, aber eigentlich will man das ja auch nicht ...
Ich schaue es mir ASAP an.
Vielleicht bekomme ich ja so einen Koloss von meinem Server geschafft :-)
Ich war
so entsetzt über Gitlab dass ich das gar nicht erst installiert habe :-) In dem Zusammenhang kann ich vermelden, dass ich
heute einen neuen Webmailer gefunden habe, der mich aus ähnlichen Gründen auf den ersten
Blick überzeugt hat: RainLoop (https://www.rainloop.net/) statt Roundcube
(https://roundcube.net/). Läuft schneller, sieht besser aus (und funktioniert v.a. gut auf
dem Mobil-Bildschirm), ich kann mehrere Email-Konten mit *einer* Anmeldung verwalten (und
sogar mein web.de-Konto).
Und schließlich verwendet die Anwendung erstmal gar keine Datenbank, kann aber optional
das Adressbuch in einer Sqlite-DB speichern (und es sogar mit meinem CalDAV-Server
synchronisieren) :-)
Ein weiterer Koloss, der weg kann (Roundcube).
Sieht ja ganz nett aus.
Als nächstes werde ich mir wohl ownCloud
vornehmen. Ich habe
festgestellt, dass ich davon eigentlich nur die
Datei-Synchronisierung verwende, und dafür braucht es auch nicht so
eine Riesenanwendung. Seafile (https://www.seafile.com/en/features/)
scheint mir nett auszusehen, aber vielleicht hat ja jemand noch
andere Vorschläge (Mindestanforderungen: Automatische
Synchronisation mit Linux und Windows, Zugriff über Android-App,
Teilen von Dateien/Ordnern per Link. Medien-Betrachter im Browser
ist nett, aber nicht Voraussetzung, gemeinsames Bearbeiten brauche
ich nicht).
Also "ich" benutze da in der Tat SeaFile (metaphorisch - ich setzte das
bei den Neutönern der HFMDK-Frankfurt ein und habe auch hier eine Guerilla-
Instanz). Ist recht brauchbar. Für mich ein grosser Vorteil: ich kann sowohl
Gitea als auch SeaFile an einen LDAP-Server anflanschen, dasmacht die Account-
verwaltung recht einfach.
Gruss RalfD
_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug(a)lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
11 p.m.
New subject: [Flug] ?==?utf-8?q? ?==?utf-8?q? Gitlab/Gitea (war:?==?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)
Am Montag, 11. September 2017 21:47 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Das ist dann aber kein offizielles Debian-Paket, oder? Das fände ich
dann aber schon eher unschön. Ursprünglich war '/opt' mal ein Bereich in
den der Admin unter kommerziellen Unixen Software hinlegen konnte ohne
dass die Installation des Herstellers berührten. Unter Linux war das
eigentlich (dank GNUs configure & make & make install) eher unüblich,
da liegt so was unter /usr/local. Der Unterschied: beim GNU-Modell liegt
ein Softwarepaket vertreut über /usr/local/lib, /usr/local/bin, /usr/local/include,
im Vendor-Model gibt's für jede Software _ein_ Verzeichnis unter /opt.
Wie gesagt, /srv/ ist neuer (und Debian-spezifisch).
Gut, melde Dich einfach.
Das nistet
sich hoffentlich dort ein wo Du es hinlegst.
Nicht, wenn ich es per apt über das Package installiert habe.
Tatsächlich liegt das Home-Verzeichnis und die Installation in
/var/opt/gitlab :-O Unter
Debianoiden sollten Server inzwischen unter '/srv' liegen
(gaaanz früher gab's da das '/var/www' :-)
Hm:
https://wiki.debian.org/FilesystemHierarchyStandard sagt einerseits:
/srv/ => "Site-specific data which is *s*e*rv*ed by the system (Not
part of FHS)."
andererseits:
/var/ => "*Var*iable data, such as logs, databases, *websites*, and
temporary spool (e-mail..) files" Das habe ich vor. Ich überlege noch, ob ich bei der
Gelegenheit die
Daten von /var/www/vhosts auch nach /srv verschieben soll. Ich muss nur
sehen, dass das auch tatsächlich funktioniert. nginx kann ich das leicht
beibringen, ich weiß aber nicht, ob vielleicht in irgendwelchen Apps
absolute Pfade hinterlegt sind. Na ja, ich muss das wohl erstmal als
*Kopie* machen und dann alle Subdomains testen ...
Da das ja alles inzwischen Scripte sind reicht meist ein 'find -type f | xargs grep
'/var/www'
Wenn Du viele bestehende Nuter mit Schlüsseln hast dann melde Dich wegen der Migration.
Darauf werde ich vielleicht zurückkommen. Es sind brutto 63 User, von
denen aber sicher etliche bei der Gelegenheit rausfallen. Die andere
Frage ist, ob man auch Issues bzw. Projekte von Gitlab importieren kann.
Von den etwas mehr als 100 offenen Issues können sicher auch ein paar
verloren gehen, aber eigentlich will man das ja auch nicht ...
Urgs, kniffelig. Aber ohne würde ich das nicht migrieren.
<...>
Nun ja, über die Omnibus-Packages ist die Installation eigentlich nicht
wirklich aufwendig gewesen. Problematisch wurde es nur bei Updates, die
i.d.R. nicht reibungslos abliefen. Dann gibt es keine verlässliche
Dokumentation, sondern nur zahllose Tipps und Tricks, die für
unterschiedliche Versionen total unterschiedlich sind, so dass man
nichts damit anfangen kann.
Was mich an solchen Installationsmonstern eher schreckt ist nicht die eigentliche
Installation (da halte ich mich für recht fit) sondern der Administrationsoverhead.
Es ist ja inzwischen schreckliche Mode geworden dass so ziemlich jede Scriptsprache
und oft sogar die einzelnen Frameworks ihre eigenen Dependency Managers mitbringen
(npm für Node, composer für php, maven etc.)
Als Resultat hat man dann auf einem Server oft zig Versionen der gleichen Software.
Das ist bei Fulnerabilities ein echtes Problem. Die meisten Admins _wissen_ inzwischen
gar nicht mehr was sie in welchen Versionen am Laufen haben. Grausig.
Gruss RalfD
12 Sep
12 Sep
12:25 a.m.
New subject: [Flug] Gitlab/Gitea (war: Abhängigkeitsproblem (postgresql) bei Update)
Am 11.09.2017 um 23:00 schrieb Ralf Mattes:
Ich habe es schon probiert, den gesamten Ordner mit "cp -a" kopiert und
dann die base-Adresse per sed nur in den nginx-Dateien geändert. Nach
meinem ersten Test haben alle Domains und Anwendungen anstandslos
funktioniert, d.h. sie hatten wohl alle ausschließlich das
Wurzelverzeichnis und ggfs. Datenbankanbindungen. Ich werde das eine
Weile beobachten und erst dann die ursprünglichen Daten löschen, aber
soweit ich sehe, sollte alles reibungslos funktioniert haben.
Gut, melde Dich
einfach.
Ja, es geht ja irgendwo auch ums Prinzip ;-)
Was du nicht sagst. Ich erinnere da nur an einen Debug-Nachmittag, der
genau aus diesem Grund sehr lang geworden ist ... [1]
Herzliche Grüße
Urs
[1]
Ich hatte einen Git hook, der nicht funktionierte. Nachdem wir alle
Möglichkeiten ausgereizt hatten, die Umgebungsvariablen in den Griff zu
bekommen, stellte sich heraus, dass auf dem Server zwei unterschiedliche
Node.js-Versionen installiert waren, und der Hook eine Funktion aufrief,
die in der tatsächlich verwendeten Node-Version noch nicht vorhanden war.
Am Montag, 11. September 2017 21:47 CEST, Urs Liska
<ul(a)openlilylib.org> schrieb:
Das ist dann aber kein offizielles Debian-Paket, oder?
Nein, Omnibus ist ein System, um Ruby-Anwendungen in Pakete zu pressen.
Nach der Installation wird das aber per apt upgrade (und vorher update)
verwaltet.
Das
nistet sich hoffentlich dort ein wo Du es hinlegst.
Nicht, wenn ich es per apt über
das Package installiert habe.
Tatsächlich liegt das Home-Verzeichnis und die Installation in
/var/opt/gitlab :-O Das fände ich
dann aber schon eher unschön. Ursprünglich war '/opt' mal ein Bereich in
den der Admin unter kommerziellen Unixen Software hinlegen konnte ohne
dass die Installation des Herstellers berührten. Unter Linux war das
eigentlich (dank GNUs configure & make & make install) eher unüblich,
da liegt so was unter /usr/local. Der Unterschied: beim GNU-Modell liegt
ein Softwarepaket vertreut über /usr/local/lib, /usr/local/bin, /usr/local/include,
im Vendor-Model gibt's für jede Software _ein_ Verzeichnis unter /opt.
Wie gesagt, /srv/ ist neuer (und
Debian-spezifisch).
Mein Link war auch Debian-spezifisch, und es war eben unter /var
ebenfalls noch "Websites" gelistet. Aber ich werde hier nicht auf den
alten Zöpfen beharren - das /var/www/vhosts passte mir sowieso irgendwie
nicht, zumal die "vhosts" AFAICS auch sehr nach Apache riecht und daher
sowieso nicht mehr so richtig passt.
Unter
Debianoiden sollten Server inzwischen unter '/srv' liegen
(gaaanz früher gab's da das '/var/www' :-)
Hm:
https://wiki.debian.org/FilesystemHierarchyStandard sagt einerseits:
/srv/ => "Site-specific data which is *s*e*rv*ed by the system (Not
part of FHS)."
andererseits:
/var/ => "*Var*iable data, such as logs, databases, *websites*, and
temporary spool (e-mail..) files" Das habe ich vor. Ich überlege noch, ob ich bei
der Gelegenheit die
Daten von /var/www/vhosts auch nach /srv verschieben soll. Ich muss nur
sehen, dass das auch tatsächlich funktioniert. nginx kann ich das leicht
beibringen, ich weiß aber nicht, ob vielleicht in irgendwelchen Apps
absolute Pfade hinterlegt sind. Na ja, ich muss das wohl erstmal als
*Kopie* machen und dann alle Subdomains testen ...
Da das ja alles inzwischen
Scripte sind reicht meist ein 'find -type f | xargs grep '/var/www' Wenn Du
viele bestehende Nuter mit Schlüsseln hast dann melde Dich wegen der Migration.
Darauf werde ich vielleicht zurückkommen. Es sind brutto 63 User, von
denen aber sicher etliche bei der Gelegenheit rausfallen. Die andere
Frage ist, ob man auch Issues bzw. Projekte von Gitlab importieren kann.
Von den etwas mehr als 100 offenen Issues können sicher auch ein paar
verloren gehen, aber eigentlich will man das ja auch nicht ...
Urgs, kniffelig.
Aber ohne würde ich das nicht migrieren. <...>
Nun ja, über die Omnibus-Packages ist die Installation eigentlich nicht
wirklich aufwendig gewesen. Problematisch wurde es nur bei Updates, die
i.d.R. nicht reibungslos abliefen. Dann gibt es keine verlässliche
Dokumentation, sondern nur zahllose Tipps und Tricks, die für
unterschiedliche Versionen total unterschiedlich sind, so dass man
nichts damit anfangen kann.
Was mich an solchen Installationsmonstern eher
schreckt ist nicht die eigentliche
Installation (da halte ich mich für recht fit) sondern der Administrationsoverhead.
Es ist ja inzwischen schreckliche Mode geworden dass so ziemlich jede Scriptsprache
und oft sogar die einzelnen Frameworks ihre eigenen Dependency Managers mitbringen
(npm für Node, composer für php, maven etc.)
Als Resultat hat man dann auf einem Server oft zig Versionen der gleichen Software.
Das ist bei Fulnerabilities ein echtes Problem. Die meisten Admins _wissen_ inzwischen
gar nicht mehr was sie in welchen Versionen am Laufen haben. Grausig.
Gruss RalfD
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
11 Sep
11 Sep
7:54 p.m.
New subject: [Flug] Gitlab/Gitea (war: Abhängigkeitsproblem (postgresql) bei Update)
Hallo Urs,
On 09/11/2017 05:56 PM, ul(a)openlilylib.org wrote:
Als nächstes werde ich mir wohl ownCloud vornehmen.
Ich habe festgestellt, dass ich davon eigentlich nur die Datei-Synchronisierung verwende,
und dafür braucht es auch nicht so eine Riesenanwendung. Seafile
(https://www.seafile.com/en/features/) scheint mir nett auszusehen, aber vielleicht hat ja
jemand noch andere Vorschläge (Mindestanforderungen: Automatische Synchronisation mit
Linux und Windows, Zugriff über Android-App, Teilen von Dateien/Ordnern per Link.
Medien-Betrachter im Browser ist nett, aber nicht Voraussetzung, gemeinsames Bearbeiten
brauche ich nicht).
Ich habe aufgehört mir Seafile anzuschauen, als ich die Lizenz gelesen
hatte. Da steht zwar Open Source dran, aber das, was man (äh, ich) dann
erwarte(t), hält das nicht. ("The inclusion of source code with the
License is explicitly not for your use to customize a solution or re-use
in your own projects or products. The benefit of including the source
code is for purposes of security auditing.") Ja, ist besser als es sein
könnte, aber ich setzte trotzdem lieber auf "richtig" Open Source.
Liebe Grüße
Uwe
11:03 p.m.
New subject: [Flug] ?==?utf-8?q? ?==?utf-8?q? Gitlab/Gitea (war:?==?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)
Am Montag, 11. September 2017 19:54 CEST, Uwe Kleine-König <uwe(a)kleine-koenig.org>
schrieb:
Ich habe aufgehört mir Seafile anzuschauen, als ich
die Lizenz gelesen
hatte. Da steht zwar Open Source dran, aber das, was man (äh, ich) dann
erwarte(t), hält das nicht. ("The inclusion of source code with the
License is explicitly not for your use to customize a solution or re-use
in your own projects or products. The benefit of including the source
code is for purposes of security auditing.") Ja, ist besser als es sein
könnte, aber ich setzte trotzdem lieber auf "richtig" Open Source.
Da gebe ich Dir vollkommen Recht. Für meine Kunden war das aber eher nebensächlich.
Das was pragmatisch gesehen die naheliegenste Lösung. Was würdest Du als wirklich
offene Alternative vorschlagen? So was wie Dropbox war mir zu gross (und, eherlich
gesagt,
zu PHPisch ;-/
Gruss RalfD
12 Sep
12 Sep
9:08 a.m.
New subject: [Flug] ?= Gitlab/Gitea (war:=?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)
Hallo Ralf,
On 09/11/2017 11:03 PM, Ralf Mattes wrote:
Am Montag, 11. September 2017 19:54 CEST, Uwe Kleine-König <uwe(a)kleine-koenig.org>
schrieb:
Vermutlich würde ich zu nextcloud greifen, aber ich bin auch in der
glücklichen Lage, (an dieser Stelle) keine Kunden glücklich machen zu
müssen :-)
Uwe
Ich habe aufgehört mir Seafile anzuschauen, als
ich die Lizenz gelesen
hatte. Da steht zwar Open Source dran, aber das, was man (äh, ich) dann
erwarte(t), hält das nicht. ("The inclusion of source code with the
License is explicitly not for your use to customize a solution or re-use
in your own projects or products. The benefit of including the source
code is for purposes of security auditing.") Ja, ist besser als es sein
könnte, aber ich setzte trotzdem lieber auf "richtig" Open Source.
Da gebe ich Dir vollkommen Recht. Für meine Kunden war das aber eher nebensächlich.
Das was pragmatisch gesehen die naheliegenste Lösung. Was würdest Du als wirklich
offene Alternative vorschlagen? So was wie Dropbox war mir zu gross (und, eherlich
gesagt,
zu PHPisch ;-/
9:10 a.m.
New subject: [Flug] ?= Gitlab/Gitea (war:=?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)
Am 12.09.2017 um 09:08 schrieb Uwe Kleine-König:
Hallo Ralf,
On 09/11/2017 11:03 PM, Ralf Mattes wrote:
Lohnt sich der Aufwand, von ownCloud zu nextCloud zu wechseln?
Ein weiteres Projekt, das wohl in dem Zusammenhang oft genannt wird, ist
minio (https://minio.io/). Das scheint mir auch sehr interessant, aber
ich habe ehrlich gesagt noch nicht wirklich herausgefunden, ob es dafür
einen automatisch synchronisierenden Client gibt. Wenn ich es recht
sehe, wäre es sicher möglich, zumindest eine halbautomatische Lösung
über den CLI-Client einzurichten, aber ich bin doch überrascht, dass die
Webseite zu diesem Thema keine Auskunft gibt.
Kennt das jemand?
Urs
Am Montag, 11. September 2017 19:54 CEST, Uwe Kleine-König <uwe(a)kleine-koenig.org>
schrieb:
Vermutlich würde ich zu nextcloud greifen, aber ich bin auch in
der
glücklichen Lage, (an dieser Stelle) keine Kunden glücklich machen zu
müssen :-) Ich habe aufgehört mir Seafile anzuschauen, als
ich die Lizenz gelesen
hatte. Da steht zwar Open Source dran, aber das, was man (äh, ich) dann
erwarte(t), hält das nicht. ("The inclusion of source code with the
License is explicitly not for your use to customize a solution or re-use
in your own projects or products. The benefit of including the source
code is for purposes of security auditing.") Ja, ist besser als es sein
könnte, aber ich setzte trotzdem lieber auf "richtig" Open Source.
Da
gebe ich Dir vollkommen Recht. Für meine Kunden war das aber eher nebensächlich.
Das was pragmatisch gesehen die naheliegenste Lösung. Was würdest Du als wirklich
offene Alternative vorschlagen? So was wie Dropbox war mir zu gross (und, eherlich
gesagt,
zu PHPisch ;-/ Uwe
_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug(a)lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
11:17 a.m.
New subject: [Flug] ?==?utf-8?q? ?==?utf-8?q? ?= Gitlab/Gitea?==?utf-8?q? (war:=?utf-8?q? Abhängigkeitsproblem?==?utf-8?q? (postgresql) bei Update)
Am Dienstag, 12. September 2017 09:10 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Ein weiteres Projekt, das wohl in dem Zusammenhang oft
genannt wird, ist
minio (https://minio.io/). Das scheint mir auch sehr interessant, aber
ich habe ehrlich gesagt noch nicht wirklich herausgefunden, ob es dafür
einen automatisch synchronisierenden Client gibt. Wenn ich es recht
sehe, wäre es sicher möglich, zumindest eine halbautomatische Lösung
über den CLI-Client einzurichten, aber ich bin doch überrascht, dass die
Webseite zu diesem Thema keine Auskunft gibt.
Wenn ich das recht verstehe dann sollte das so gehen:
$ mc mirror --force --remove --watch ... ...
Das sieht in der Tat recht interessant aus - danke für den Hinweis.
Allerdings kann man das nicht wirklich mit SeaFile vergleichen.
Minio ist eher die Basis um solche Dienste zu implementieren, es kann
einerseits viel mehr (verteilter Storage mit Redundanz), andereseits
aber viel weniger. Mir fehlen da z.Bsp. die Benutzer- und Gruppenkonfiguration.
Gruss RalfD
11:32 a.m.
New subject: [Flug] ?= Gitlab/Gitea (war:=?utf-8?q? Abhängigkeitsproblem (postgresql) bei Update)
Am 12.09.2017 um 11:17 schrieb Ralf Mattes:
Am Dienstag, 12. September 2017 09:10 CEST, Urs Liska
<ul(a)openlilylib.org> schrieb:
Das heißt, dass ich diesen Befehl oder eine Abwandlung davon so
einrichten müsste, dass er beim Login automatisch startet und nicht an
ein Terminal gebunden ist?
Ein weiteres Projekt, das wohl in dem
Zusammenhang oft genannt wird, ist
minio (https://minio.io/). Das scheint mir auch sehr interessant, aber
ich habe ehrlich gesagt noch nicht wirklich herausgefunden, ob es dafür
einen automatisch synchronisierenden Client gibt. Wenn ich es recht
sehe, wäre es sicher möglich, zumindest eine halbautomatische Lösung
über den CLI-Client einzurichten, aber ich bin doch überrascht, dass die
Webseite zu diesem Thema keine Auskunft gibt.
Wenn ich das recht verstehe dann
sollte das so gehen:
$ mc mirror --force --remove --watch ... ...
Das sieht in der Tat recht interessant aus - danke für den Hinweis.
Allerdings kann man das nicht wirklich mit SeaFile vergleichen.
Minio ist eher die Basis um solche Dienste zu implementieren, es kann
einerseits viel mehr (verteilter Storage mit Redundanz), andereseits
aber viel weniger. Mir fehlen da z.Bsp. die Benutzer- und Gruppenkonfiguration.
Gut, ich suche ja kein Seafile-Äquivalent, sondern eine Lösung für
meinen Bedarf. Im Prinzip reicht für mich ein Benutzer, automatische
Synchronisierung und die Möglichkeit, Dateien oder Ordner per Link zu
teilen.
Spannend finde ich auch das API - aber auf diesen Time Sink will ich
mich gar nicht erst einlassen ;-)
Gruß
Urs
Gruss RalfD
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
8 Sep
8 Sep
10:54 a.m.
* 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?
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
- 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 )
- 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.
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.
Nach Korrektur oder Auskommentieren(?) die Installation abschließen mit nochmals
apt-get upgrade
2017-09-08 09:39:00 CEST [28701-3] FATAL: konnte
pg_hba.conf nicht laden
2017-09-08 09:39:00 CEST [28701-4] LOG: Datenbanksystem ist
heruntergefahren
[fail]
invoke-rc.d: initscript postgresql, action "start" failed.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-common (--configure):
Unterprozess installiertes post-installation-Skript gab den Fehlerwert
1 zurück
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von postgresql-9.6:
postgresql-9.6 hängt ab von postgresql-common (>= 171~); aber:
Paket postgresql-common ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-9.6 (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von postgresql:
postgresql hängt ab von postgresql-9.6; aber:
Paket postgresql-9.6 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von postgresql-9.4:
postgresql-9.4 hängt ab von postgresql-common (>= 142~); aber:
Paket postgresql-common ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-9.4 (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von postgresql-9.5:
postgresql-9.5 hängt ab von postgresql-common (>= 158~); aber:
Paket postgresql-common ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-9.5 (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von
postgresql-contrib-9.6:
postgresql-contrib-9.6 hängt ab von postgresql-9.6 (=
9.6.5-1.pgdg14.04+1); aber:
Paket postgresql-9.6 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-contrib-9.6
(--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von postgresql-contrib:
postgresql-contrib hängt ab von postgresql-contrib-9.6; aber:
Paket postgresql-contrib-9.6 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-contrib (--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von
postgresql-contrib-9.4:
postgresql-contrib-9.4 hängt ab von postgresql-9.4 (=
9.4.14-1.pgdg14.04+1); aber:
Paket postgresql-9.4 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-contrib-9.4
(--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von
postgresql-contrib-9.5:
postgresql-contrib-9.5 hängt ab von postgresql-9.5 (=
9.5.9-1.pgdg14.04+1); aber:
Paket postgresql-9.5 ist noch nicht konfiguriert.
dpkg: Fehler beim Bearbeiten des Paketes postgresql-contrib-9.5
(--configure):
Abhängigkeitsprobleme - verbleibt unkonfiguriert
Fehler traten auf beim Bearbeiten von:
postgresql-common
postgresql-9.6
postgresql
postgresql-9.4
postgresql-9.5
postgresql-contrib-9.6
postgresql-contrib
postgresql-contrib-9.4
postgresql-contrib-9.5
E: Sub-process /usr/bin/dpkg returned an error code (1)
--
Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
6:25 p.m.
Am 08.09.2017 um 10:54 schrieb Mathias Behrle:
OK, das habe ich (s.u.)
Am 08.09.2017 um 10:45 schrieb Ralf Mattes:
* Urs Liska: " [Flug] Abhängigkeitsproblem
(postgresql) bei Update" (Fri, 8 Sep
2017 10:02:20 +0200):
Hallo Urs,
# 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.
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? 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 - 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. 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(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
7 p.m.
New subject: [Flug] ?==?utf-8?q? Abhängigkeitsproblem?==?utf-8?q? (postgresql) bei Update
Am Freitag, 08. September 2017 18:25 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Am 08.09.2017 um 10:54 schrieb Mathias Behrle:
OK, das habe ich (s.u.)
Am 08.09.2017 um 10:45 schrieb Ralf Mattes:
* Urs Liska: " [Flug] Abhängigkeitsproblem
(postgresql) bei Update" (Fri, 8 Sep
2017 10:02:20 +0200):
Hallo Urs,
# 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.
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? 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 - 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. 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(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug(a)lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
7:10 p.m.
New subject: [Flug] ?==?utf-8?q? Abhängigkeitsproblem?==?utf-8?q? (postgresql) bei Update
Sorry, mein Emacs war etwas zu übereifrig ...
Am Freitag, 08. September 2017 18:25 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Am 08.09.2017 um 10:45 schrieb Ralf Mattes:
Da ist die Syntax deinitiv falsch - da sollte 85.25.93.165/32 stehen ...
Allerdings würde ich meine Datenbank nicht ohne Not so einfach in's Internet
stellen . Schade, hast Du auch nicht :-)
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 ...
Urgs, dann hat das irgendwer wärend des Updates gemacht? Gruselig.
Für soche Sachen empfehle ich dem angehenden Sysadmin unbedingt etckeeper
zu installieren. Dann könntest Du mit einem 'git blame pg_hba.conf' sofort sehen
wann das wer warum gemacht hat.
Gruss RalfD
9 Sep
9 Sep
12:48 p.m.
New subject: [Flug] ?= Abh�ngigkeitsproblem=?utf-8?q? (postgresql) bei Update
Am 08.09.2017 um 19:10 schrieb Ralf Mattes:
Sorry, mein Emacs war etwas zu übereifrig ...
Am Freitag, 08. September 2017 18:25 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Die Frage ist, was gruseliger ist, *dass* das gemacht wurde, dass es
*falsch* gemacht wurde oder dass ich nicht die geringste Erinnerung
daran habe. Denn dass *ich* das gemacht habe, scheint mir schon daraus
hervorzugehen, dass es so falsch ist ...
Am 08.09.2017 um 10:45 schrieb Ralf Mattes:
Da ist die
Syntax deinitiv falsch - da sollte 85.25.93.165/32 stehen ...
Allerdings würde ich meine Datenbank nicht ohne Not so einfach in's Internet
stellen . Schade, hast Du auch nicht :-)
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 ...
Urgs, dann hat das irgendwer wärend des Updates gemacht? Gruselig.
Für soche Sachen empfehle ich dem angehenden Sysadmin
unbedingt etckeeper
zu installieren. Dann könntest Du mit einem 'git blame pg_hba.conf' sofort sehen
wann das wer warum gemacht hat.
Das werde ich bei der nächsten Neuinstallation als erstes machen. Wenn
ich es richtig sehe, muss ich immer noch selber darauf schauen, es
regelmäßig zu verwenden und v.a. Commit Messages vernünftig zu schreiben
- aber um Längen besser als der derzeitige Zustand ist es auf jeden Fall.
HG
Urs
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
1:24 p.m.
New subject: [Flug] ?==?utf-8?q? ?==?utf-8?q? ?= Abh�ngigkeitsproblem=?utf-8?q? (postgresql) bei Update
Am Samstag, 09. September 2017 12:48 CEST, Urs Liska <ul(a)openlilylib.org> schrieb:
Mach's gleich. 'sudo aptitude install etckeeper'
Die Frage ist, was gruseliger ist, *dass* das gemacht wurde, dass es
*falsch* gemacht wurde oder dass ich nicht die geringste Erinnerung
daran habe. Denn dass *ich* das gemacht habe, scheint mir schon daraus
hervorzugehen, dass es so falsch ist ...
Da bin ich mir gar nicht so sicher. Du hast ja 9.6 wahrscheinlich erst durch Dein Update
bekommen, und das hat erst gar nicht funktioniert (wg. der falschen Eintrags).
Bei Ubuntu gehe ich inzwischen immer vom Schlimmsten aus - gut möglich dass das
ein überschlaues Installationsscript war.
Für soche Sachen empfehle ich dem angehenden
Sysadmin unbedingt etckeeper
zu installieren. Dann könntest Du mit einem 'git blame pg_hba.conf' sofort sehen
wann das wer warum gemacht hat.
Das werde ich bei der nächsten Neuinstallation als erstes machen. Wenn
ich es richtig sehe, muss ich immer noch selber darauf schauen, es
regelmäßig zu verwenden und v.a. Commit Messages vernünftig zu schreiben
- aber um Längen besser als der derzeitige Zustand ist es auf jeden Fall.
Jein. Wenn Du selbst Konfigurationen veränderst dann bietet es sich an ein
'etckeeper commit 'Apache Konfiguration für Gitea erweitert' zu machen.
Man kann dem Teil aber auch sagen dass es einmal am Tag sicherheitshalber
einen Commit macht (dank Git macht das ja nur was wenn sich wirklich etwas
verändert hat).
Ausserdem hängt sich das Programm an Dein apt, wenn Du also mit apt (oder
Aptitude, nicht aber mit dpkg!) Software installierst dann bekommst Du automatisch
einen Commit vor und einen nach der Installation.
Das alleine hilft oft schon viel.
Gruss RalfD
HG
Urs
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
_______________________________________________
Freiburger Linux User Group
Mail an die Liste: flug(a)lug-freiburg.de
Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
1:21 p.m.
New subject: [Flug] Risiko Versionssprung (war: Abhängigkeitsproblem (postgresql) bei Update)
Am 08.09.2017 um 18:25 schrieb Urs Liska:
Dieses Ubuntu ist doch nun schon ziemlich alt, und ich frage mich, ob
ich hier mal etwas aktualisieren sollte.
Allerdings kann ich mich nicht erinnern, dass es schon einmal problemlos
funktioniert hätte, eine Linuxinstallation per apt auf eine neuere
Version upzugraden. Jedesmal kommen zwischendurch Konfigurationsfragen,
die ich nicht beantworten kann (weil ich die fraglichen Programme nicht
selbst installiert hatte und oft noch nicht einmal weiß, wofür sie
jeweils gut sind), und am Ende stand dann erst ein nicht
funktionierendes System und dann eine Neuinstallation eines anderen
Systems. Und auf einem Remote-Server, auf den ich *überhaupt* nur per
SSH zugreifen kann, erscheint mir das noch erheblich riskanter zu sein.
Was meint ihr dazu?
Andererseits liebäugele ich damit, bei dieser Gelegenheit gleich sowieso
auf einen neuen Server zu wechseln, d.h. einen Server dazuzubestellen
und den bisherigen kurz darauf zu kündigen. Es spricht einiges dafür -
aber auch einiges dagegen:
* Ich könnte diesmal einiges richtig machen (Stichwort: etckeeper,
Mailserver-Konfiguration) und wäre automatisch etliche
Programmleichen los, die noch auf dem Server rumliegen
o Aber: Üblicherweise ist das doch eher ein frommer Wunsch ...
* Ich könnte bei der Gelegenheit das nervige Problem loswerden, dass
viele Mailserver die Annahme meiner Mails verweigern (da hatte ich
hier schon viele Hilfestellungen bekommen, es aber immer noch nicht
gelöst ...)
* Aber selbst wenn das alles reibungslos laufen würde, hätte ich doch
immer noch einen ganzen Haufen Arbeit, bis das alles wieder läuft,
vom Mail- über den Webserver bis zu ownCloud, Moodle und co. (Und es
wäre damit zu rechnen, das Einiges davon auch hier auf der Liste
aufschlägt ...)
Habt ihr eine Einschätzung zum Verhältnis von Aufwand/Risiko und Nutzen,
was würdet ihr machen?
Und: Sollte ich mich für die Variante entscheiden, was wären die
Kriterien, um zwischen Ubuntu und Debian zu entscheiden?
(Nicht-apt-basierte Distros kommen für mich auf einem Server nicht in
Frage, das fange ich erstmal lokal an).
Herzliche Grüße
Urs
--
ul(a)openlilylib.org
https://openlilylib.org
http://lilypondblog.org
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"
15 Sep
15 Sep
12:26 a.m.
New subject: [Flug] Risiko Versionssprung (war: Abhängigkeitsproblem (postgresql) bei Update)
Am 09.09.2017 um 13:21 schrieb Urs Liska:
Am 08.09.2017 um 18:25 schrieb Urs Liska:
Dieses Ubuntu ist doch nun schon ziemlich alt, und ich frage mich, ob
ich hier mal etwas aktualisieren sollte.
Allerdings kann ich mich nicht erinnern, dass es schon einmal
problemlos funktioniert hätte, eine Linuxinstallation per apt auf eine
neuere Version upzugraden. Jedesmal kommen zwischendurch
Konfigurationsfragen, die ich nicht beantworten kann (weil ich die
fraglichen Programme nicht selbst installiert hatte und oft noch nicht
einmal weiß, wofür sie jeweils gut sind), und am Ende stand dann erst
ein nicht funktionierendes System und dann eine Neuinstallation eines
anderen Systems. Und auf einem Remote-Server, auf den ich *überhaupt*
nur per SSH zugreifen kann, erscheint mir das noch erheblich riskanter
zu sein.
Was meint ihr dazu?
Ach ja, nun fällt mir erst auf, dass mir beim Login immer Folgendes
angezeigt wird:
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux 3.13.0-98-generic x86_64)
* Documentation: https://help.ubuntu.com/
New release '16.04.3 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
Was meint ihr, wie groß ist das Risiko, dass ich danach mit einem gar
nicht mehr funktionierenden System geschlagen bin?
Ich meine mich zu erinnern, dass das letzte Mal, dass ich so etwas
versucht hatte (ich glaube, das war Debian 7->8), zwischendurch
Konfigurationsfragen kamen, die ich nicht beantworten konnte, weil sie
z.B. mit der tatsächlichen Hardwarekonfiguration oder der
Netzwerkinfrastruktur zu tun hatten, die ich ja nicht kenne. Und ich
meine, dass ich damals nur noch mit einem Hard-Restore (also
Neuinstallation des OS-Templates des Providers) weiterkam, was ich nicht
nochmal erleben möchte ...
HG
Urs
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" 
10:42 a.m.
New subject: [Flug] Risiko Versionssprung (war: Abhängigkeitsproblem (postgresql) bei Update)
On 15.09.2017 00:26, Urs Liska wrote:
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux
3.13.0-98-generic x86_64)
* Documentation: https://help.ubuntu.com/
New release '16.04.3 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
Was meint ihr, wie groß ist das Risiko, dass ich danach mit einem gar
nicht mehr funktionierenden System geschlagen bin?
Ich hab’s ja beim normalen PC versucht, und nicht die allerbesten
Erfahrungen damit gemacht…
Viele Grüße,
Simon
2:27 p.m.
New subject: [Flug] Risiko Versionssprung (war: Abhängigkeitsproblem (postgresql) bei Update)
15. September 2017 10:42, "Simon Albrecht" <simon.albrecht(a)mail.de>
schrieb:
On 15.09.2017 00:26, Urs Liska wrote:
Hm.
Ich weiß auch nicht so recht. Auf der einen Seite sollte man ja - grade bei Servern -
nicht immer dem allerneusten Stand hinterherhecheln, und 14.04 ist ja immerhin LTS und
wird nach wie vor mit Sicherheitsupdates versorgt.
Andererseits muss ich feststellen, dass es anfängt, dass wichtige (oder zumindest
wünschenswerte) Funktionen nicht mehr funktionieren: So lässt mich Gitea nicht Git LFS
verwenden, weil Git nicht aktuell genug ist, und wie ich jetzt sehe, erfordert NextCloud
eine neuere PHP-Version als bei mir verfügbar.
Natürlich kann man immer versuchen, einzelne Tools wie Git oder PHP separat in neueren
Fassungen zu installieren, aber irgendwann ist das auch ausgereizt. Also vielleicht doch
ein neuer Server, mit dem (und nur mit dem) ich eine neue IP und einen neuen Servernamen
bekommen würde.
Ich glaube, da muss ich noch ein bisschen drüber schmoren ...
HG
Urs
Welcome to Ubuntu 14.04.5 LTS (GNU/Linux
3.13.0-98-generic x86_64)
* Documentation: https://help.ubuntu.com
New release '16.04.3 LTS' available.
Run 'do-release-upgrade' to upgrade to it.
Was meint ihr, wie groß ist das Risiko, dass ich danach mit einem gar
nicht mehr funktionierenden System geschlagen bin?
Ich hab’s ja beim normalen PC versucht, und nicht die allerbesten
Erfahrungen damit gemacht…
2408
days inactive
2415
days old
29 comments
7 participants
participants (7)
-
Mathias Behrle -
Ralf Mattes -
Ralf Mattes -
Simon Albrecht -
ul＠openlilylib.org -
Urs Liska
-
Uwe Kleine-König