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)
Am Freitag, 08. September 2017 10:02 CEST, Urs Liska ul@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
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
Am Samstag, 09. September 2017 12:58 CEST, Urs Liska ul@openlilylib.org schrieb:
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). 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@openlilylib.org https://openlilylib.org http://lilypondblog.org
Freiburger Linux User Group Mail an die Liste: flug@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
9. September 2017 13:37, "Ralf Mattes" rm@mh-freiburg.de schrieb:
Am Samstag, 09. September 2017 12:58 CEST, Urs Liska ul@openlilylib.org schrieb:
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.
OK, das erklärt Einiges ...
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@openlilylib.org https://openlilylib.org http://lilypondblog.org
Freiburger Linux User Group Mail an die Liste: flug@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
Freiburger Linux User Group Mail an die Liste: flug@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
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
Am Dienstag, 12. September 2017 14:57 CEST, Urs Liska ul@openlilylib.org schrieb:
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.
Die Mailfunktion nutze ich im Agenblick gar nicht.
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.
Ach ja, das ist ja FummelBuntu ;-) Da war doch was ...
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
* 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:
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.
Eine gute Lösung zur schlichten Verwaltung von git Repos bietet auch gitolite und das ist bereits gepackt. https://packages.debian.org/sid/gitolite3
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
Am Samstag, 09. September 2017 13:38 CEST, Mathias Behrle mathiasb@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?
https://gist.github.com/Nitya-Sattva/75e69de05218c14ecf8e7d97edcd48aa
Wenn ich lese dass man seine sshd-Conf verändert und dann Rebooten muss (sic!) dann möchte ich eigentlich erst einmal laut aufschreien.
ansonsten
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
9. September 2017 18:36, "Ralf Mattes" rm@mh-freiburg.de schrieb:
Am Samstag, 09. September 2017 13:38 CEST, Mathias Behrle mathiasb@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.
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.
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?
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.
https://gist.github.com/Nitya-Sattva/75e69de05218c14ecf8e7d97edcd48aa
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.
ansonsten
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@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
Am Montag, 11. September 2017 17:56 CEST, ul@openlilylib.org schrieb:
... 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.
Ja, das ist aber ein trivialer Proxy.
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' :-)
https://gist.github.com/Nitya-Sattva/75e69de05218c14ecf8e7d97edcd48aa
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.
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.
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
Am 11.09.2017 um 18:14 schrieb Ralf Mattes:
Am Montag, 11. September 2017 17:56 CEST, ul@openlilylib.org schrieb:
... 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.
Ja, das ist aber ein trivialer Proxy.
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.
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"
https://gist.github.com/Nitya-Sattva/75e69de05218c14ecf8e7d97edcd48aa
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.
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 ...
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 :-)
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
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@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
Am Montag, 11. September 2017 21:47 CEST, Urs Liska ul@openlilylib.org schrieb:
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 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.
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"
Wie gesagt, /srv/ ist neuer (und Debian-spezifisch).
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.
Gut, melde Dich einfach.
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
Am 11.09.2017 um 23:00 schrieb Ralf Mattes:
Am Montag, 11. September 2017 21:47 CEST, Urs Liska ul@openlilylib.org schrieb:
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 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 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.
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"
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.
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'
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.
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.
Gut, melde Dich einfach.
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.
Ja, es geht ja irgendwo auch ums Prinzip ;-)
<...> 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.
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.
Gruss RalfD
Hallo Urs,
On 09/11/2017 05:56 PM, ul@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
Am Montag, 11. September 2017 19:54 CEST, Uwe Kleine-König uwe@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
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@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 ;-/
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
Am 12.09.2017 um 09:08 schrieb Uwe Kleine-König:
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@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 ;-/
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 :-)
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
Uwe
Freiburger Linux User Group Mail an die Liste: flug@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
Am Dienstag, 12. September 2017 09:10 CEST, Urs Liska ul@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
Am 12.09.2017 um 11:17 schrieb Ralf Mattes:
Am Dienstag, 12. September 2017 09:10 CEST, Urs Liska ul@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 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?
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
* 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)
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
Am Freitag, 08. September 2017 18:25 CEST, Urs Liska ul@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@openlilylib.org https://openlilylib.org http://lilypondblog.org
Freiburger Linux User Group Mail an die Liste: flug@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
Sorry, mein Emacs war etwas zu übereifrig ...
Am Freitag, 08. September 2017 18:25 CEST, Urs Liska ul@openlilylib.org schrieb:
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
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 :-)
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
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@openlilylib.org schrieb:
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
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 :-)
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.
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 ...
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
Am Samstag, 09. September 2017 12:48 CEST, Urs Liska ul@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 ...
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.
Mach's gleich. 'sudo aptitude install etckeeper'
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@openlilylib.org https://openlilylib.org http://lilypondblog.org
Freiburger Linux User Group Mail an die Liste: flug@lug-freiburg.de Mailingliste verwalten (u.a. abbestellen): https://lug-freiburg.de/mailman/listinfo/flug
Am 08.09.2017 um 18:25 schrieb Urs Liska:
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"
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
Am 09.09.2017 um 13:21 schrieb Urs Liska:
Am 08.09.2017 um 18:25 schrieb Urs Liska:
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"
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
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
15. September 2017 10:42, "Simon Albrecht" simon.albrecht@mail.de schrieb:
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…
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
-
Mathias Behrle -
Ralf Mattes -
Ralf Mattes -
Simon Albrecht -
ul＠openlilylib.org -
Urs Liska
-
Uwe Kleine-König