Liebe Leute,
ich kann es weder erklären noch genau beschreiben, aber ich habe ein Problem mit meinem Gitea-Server: Ich kann ihn weder im Browser noch über wget kontaktieren. Der Browser meldet einfach "konnte keine Verbindung aufbauen", wget ist etwas konkreter und sagt entweder "Verbindungsaufbau zu XYZ(xyz)|85.25.3.15|:443... fehlgeschlagen: Verbindungsaufbau abgelehnt." oder "Auflösen des Hostnamens fehlgeschlagen ... der Name oder Dienst ist nicht bekannt." Ich unterstelle, dass die DNS-Einträge korrekt sind, denn mit ping (oder Verbinden mit ssh) geht es wie es soll.
nun weiß ich nicht, ob ich Gitea "einfach"neu installieren soll (v.a. inkl. Integration mit nginx) oder ob ich ein ernsteres Problem mit dem Server insgesamt habe.
ankbar für jeden Tipp oder Vorschlag Urs
Am 17.11.21 um 12:38 schrieb Urs Liska:
Liebe Leute,
ich kann es weder erklären noch genau beschreiben, aber ich habe ein Problem mit meinem Gitea-Server: Ich kann ihn weder im Browser noch über wget kontaktieren. Der Browser meldet einfach "konnte keine Verbindung aufbauen", wget ist etwas konkreter und sagt entweder "Verbindungsaufbau zu XYZ(xyz)|85.25.3.15|:443... fehlgeschlagen: Verbindungsaufbau abgelehnt." oder "Auflösen des Hostnamens fehlgeschlagen ... der Name oder Dienst ist nicht bekannt." Ich unterstelle, dass die DNS-Einträge korrekt sind, denn mit ping (oder Verbinden mit ssh) geht es wie es soll.
nun weiß ich nicht, ob ich Gitea "einfach"neu installieren soll (v.a. inkl. Integration mit nginx) oder ob ich ein ernsteres Problem mit dem Server insgesamt habe.
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Dankbar für jeden Tipp oder Vorschlag Urs
On Wed, Nov 17, 2021 at 12:52:41PM +0100, Urs Liska wrote:
Am 17.11.21 um 12:38 schrieb Urs Liska:
Liebe Leute,
[...]
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Wie in der anderen Mail: ich lese das "connection refused" [1] so, dass nginx entweder nicht "oben" ist, oder nicht dazu konfiguriert, auf welchen Port auch immer (vermutlich 443, https) Du mit Deinem Browser/wget klopfst.
lg
[1] Warum muss mensch "Standardfehlermeldungen" internationalisieren? So ein Steckenpferd von mir ;-)
-- t
Am Mittwoch, 17. November 2021 13:05 CET, tomas@tuxteam.de schrieb:
On Wed, Nov 17, 2021 at 12:52:41PM +0100, Urs Liska wrote:
Am 17.11.21 um 12:38 schrieb Urs Liska:
Liebe Leute,
[...]
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Wie in der anderen Mail: ich lese das "connection refused" [1] so, dass nginx entweder nicht "oben" ist, oder nicht dazu konfiguriert, auf welchen Port auch immer (vermutlich 443, https) Du mit Deinem Browser/wget klopfst.
Das lässt sich ja leicht testen:
ss -t -a | grep https
und:
journalctl -u nginx
BTW, 'dig' und 'nslookup' sind problematische Debugging-Tools für die Namensauflösung weil sie _nicht_ Einträge in /etc/hosts berücksichtigen. Also zur Sicherheit noch ein:
getent hosts
Gruss RalfD
lg
[1] Warum muss mensch "Standardfehlermeldungen" internationalisieren? So ein Steckenpferd von mir ;-)
-- t
On Wed, Nov 17, 2021 at 02:24:34PM +0100, Ralf Mattes wrote:
BTW, 'dig' und 'nslookup' sind problematische Debugging-Tools für die Namensauflösung weil sie _nicht_ Einträge in /etc/hosts berücksichtigen. Also zur Sicherheit noch ein:
Hätte ich dazu sagen sollen (lag mir auf der Zunge, aber das hätte die Mail noch länger gemacht).
getent hosts
Dafür benutze ich, faul wie ich bin, tatsächlich `ping': der murmelt nämlich mit, ob er den Host aufgelöst bekommt (dazu stützt er sich auf den Resolver, d.h. geht denselben Weg, den die anderen auf der Maschine gehen, d.h. in der Regel erst /etc/hosts).
Wenn die Gegenseite auf ein echo request antwortet, Bonus :)
lg -- t
Am 17.11.21 um 14:24 schrieb Ralf Mattes:
Am Mittwoch, 17. November 2021 13:05 CET, tomas@tuxteam.de schrieb:
On Wed, Nov 17, 2021 at 12:52:41PM +0100, Urs Liska wrote:
Am 17.11.21 um 12:38 schrieb Urs Liska:
Liebe Leute,
[...]
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Wie in der anderen Mail: ich lese das "connection refused" [1] so, dass nginx entweder nicht "oben" ist, oder nicht dazu konfiguriert, auf welchen Port auch immer (vermutlich 443, https) Du mit Deinem Browser/wget klopfst.
Das lässt sich ja leicht testen:
ss -t -a | grep https
und:
journalctl -u nginx
journalctl -u nginx delta systemd[1]: nginx.service: Unit cannot be reloaded because it is inactive. Und nu?
BTW, 'dig' und 'nslookup' sind problematische Debugging-Tools für die Namensauflösung weil sie _nicht_ Einträge in /etc/hosts berücksichtigen. Also zur Sicherheit noch ein:
getent hosts
Gruss RalfD
lg
[1] Warum muss mensch "Standardfehlermeldungen" internationalisieren? So ein Steckenpferd von mir ;-)
-- t
Am 17.11.21 um 17:21 schrieb Urs Liska:
Am 17.11.21 um 14:24 schrieb Ralf Mattes:
Am Mittwoch, 17. November 2021 13:05 CET, tomas@tuxteam.de schrieb:
On Wed, Nov 17, 2021 at 12:52:41PM +0100, Urs Liska wrote:
Am 17.11.21 um 12:38 schrieb Urs Liska:
Liebe Leute,
[...]
Gitea neu zu installieren scheitert im Moment noch hier:
|wget -O https://dl.gitea.io/gitea/1.2.0-rc2/gitea-1.2.0-rc2-linux-amd64,%7C
|was einen 403-Fehler zurückgibt ... |
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Wie in der anderen Mail: ich lese das "connection refused" [1] so, dass nginx entweder nicht "oben" ist, oder nicht dazu konfiguriert, auf welchen Port auch immer (vermutlich 443, https) Du mit Deinem Browser/wget klopfst.
Das lässt sich ja leicht testen:
ss -t -a | grep https
und:
journalctl -u nginx
journalctl -u nginx delta systemd[1]: nginx.service: Unit cannot be reloaded because it is inactive. Und nu?
BTW, 'dig' und 'nslookup' sind problematische Debugging-Tools für die Namensauflösung weil sie _nicht_ Einträge in /etc/hosts berücksichtigen. Also zur Sicherheit noch ein:
getent hosts
Gruss RalfD
lg
[1] Warum muss mensch "Standardfehlermeldungen" internationalisieren? So ein Steckenpferd von mir ;-)
-- t
Am 17.11.21 um 12:52 schrieb Urs Liska:
Am 17.11.21 um 12:38 schrieb Urs Liska:
Liebe Leute,
ich kann es weder erklären noch genau beschreiben, aber ich habe ein Problem mit meinem Gitea-Server: Ich kann ihn weder im Browser noch über wget kontaktieren. Der Browser meldet einfach "konnte keine Verbindung aufbauen", wget ist etwas konkreter und sagt entweder "Verbindungsaufbau zu XYZ(xyz)|85.25.3.15|:443... fehlgeschlagen: Verbindungsaufbau abgelehnt." oder "Auflösen des Hostnamens fehlgeschlagen ... der Name oder Dienst ist nicht bekannt." Ich unterstelle, dass die DNS-Einträge korrekt sind, denn mit ping (oder Verbinden mit ssh) geht es wie es soll.
nun weiß ich nicht, ob ich Gitea "einfach"neu installieren soll (v.a. inkl. Integration mit nginx) oder ob ich ein ernsteres Problem mit dem Server insgesamt habe.
So einfach ist das doch nicht, wie ich es in Erinnerung habe. Momentan scheitere ich schon beim Download des Gitea-Binaries, der entweder mit 403 oder mit "FEHLER: Dem Zertifikat von »storage.gitea.io« wird nicht vertraut. FEHLER: Das Zertifikat von »storage.gitea.io« ist abgelaufen." abbricht. Das ist nicht mein Fehler, aber die Konsequenzen muss ich aussitzen ...
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Dankbar für jeden Tipp oder Vorschlag Urs
Hi Urs,
was für ein Betriebssystem läuft auf dem Server? Hast Du mal in den nginx Logs (/var/log/nginx) nachgeschaut, ob da das Problem genauer spezifiziert ist? Wenn es kein Log gibt, dann baue mal eins ein in der nginx.conf
Also falls Debian, dann:
Unter /etc/nginx/sites-enabled die entsprechende Config-Datei finden, dann dort im Bereich für :443
server { listen 443; listen [::]:443;
access_log /var/log/nginx/deineseite.de.access.log combined; error_log /var/log/nginx/deineseite.de.error.log info;
die zwei Zeilen für die Logs einfügen, danach dann nginx neu laden via nginx -s reload
dann den Zugriff erneut probieren und danach mit
less /var/log/nginx/deineseite.de.access.log less /var/log/nginx/deineseite.de.error.log
schauen, ob was in den Logs steht. Mit Shift + G kommst Du schnell an das Ende der Logdatei.
Gruß, Marc
Am 17.11.21 um 18:30 schrieb Urs Liska:
Am 17.11.21 um 12:52 schrieb Urs Liska:
Am 17.11.21 um 12:38 schrieb Urs Liska:
Liebe Leute,
ich kann es weder erklären noch genau beschreiben, aber ich habe ein Problem mit meinem Gitea-Server: Ich kann ihn weder im Browser noch über wget kontaktieren. Der Browser meldet einfach "konnte keine Verbindung aufbauen", wget ist etwas konkreter und sagt entweder "Verbindungsaufbau zu XYZ(xyz)|85.25.3.15|:443... fehlgeschlagen: Verbindungsaufbau abgelehnt." oder "Auflösen des Hostnamens fehlgeschlagen ... der Name oder Dienst ist nicht bekannt." Ich unterstelle, dass die DNS-Einträge korrekt sind, denn mit ping (oder Verbinden mit ssh) geht es wie es soll.
nun weiß ich nicht, ob ich Gitea "einfach"neu installieren soll (v.a. inkl. Integration mit nginx) oder ob ich ein ernsteres Problem mit dem Server insgesamt habe.
So einfach ist das doch nicht, wie ich es in Erinnerung habe. Momentan scheitere ich schon beim Download des Gitea-Binaries, der entweder mit 403 oder mit "FEHLER: Dem Zertifikat von »storage.gitea.io« wird nicht vertraut. FEHLER: Das Zertifikat von »storage.gitea.io« ist abgelaufen." abbricht. Das ist nicht mein Fehler, aber die Konsequenzen muss ich aussitzen ...
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Dankbar für jeden Tipp oder Vorschlag Urs
Am Mittwoch, 17. November 2021 20:00 CET, Marc Schwarz info@shopmage.de schrieb:
Hi Urs,
was für ein Betriebssystem läuft auf dem Server?
Na, Linux. Das ist ja immerhin die Linux-Mailingliste :-)
Hast Du mal in den nginx Logs (/var/log/nginx) nachgeschaut, ob da das Problem genauer
Laut Urs:
delta systemd[1]: nginx.service: Unit cannot be reloaded because it is inactive.
Da ist schon der Service nicht aktiviert. Leider verät er uns nicht was ' ss -t -a | grep https' ergibt. Warscheinlich lauscht da gar nichts auf Port 443.
FEHLER: Das Zertifikat von »storage.gitea.io« ist abgelaufen." abbricht. Das ist nicht mein Fehler, aber die Konsequenzen muss ich aussitzen ...
@urs: nur so nebenbei - warum willst Du eine veraltete Version von Gitea installieren? Ältere Versionen haben Vulnerabilities.
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Glaube ich eher nicht - wenn nur die Weiterleitung an den Gitea-Server nicht funktionieren sollte müsstest Du ein Connect bekommen (und dann eher einen 500er Fehler).
Gruss RalfD
On Thu, Nov 18, 2021 at 12:17:28AM +0100, Ralf Mattes wrote:
Am Mittwoch, 17. November 2021 20:00 CET, Marc Schwarz info@shopmage.de schrieb:
Hi Urs,
was für ein Betriebssystem läuft auf dem Server?
Na, Linux. Das ist ja immerhin die Linux-Mailingliste :-)
Hast Du mal in den nginx Logs (/var/log/nginx) nachgeschaut, ob da das Problem genauer
Laut Urs:
delta systemd[1]: nginx.service: Unit cannot be reloaded because it is inactive.
Da ist schon der Service nicht aktiviert. Leider verät er uns nicht was ' ss -t -a | grep https' ergibt. Warscheinlich lauscht da gar nichts auf Port 443.
Meine Rede: erst den Web-Server ans laufen kriegen :-)
Connection refused ist da ein klares Indiz.
[...]
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Glaube ich eher nicht - wenn nur die Weiterleitung an den Gitea-Server nicht funktionieren sollte müsstest Du ein Connect bekommen (und dann eher einen 500er Fehler).
Genau. Wenn der Webserver läuft, aber nicht "sein" backend ansprechen kann, dann erwarte ich schon eine HTTP-Antwort mit anständigem Fehlercode (ein 5xx, vielleicht auch ein 4xx, was zwar falsch, aber anständig wäre. In der Microsoft-Welt auch mal ein 2xx [1] -- aber jedenfalls immer eine connection (=> kein "connection refused").
lg
[1] Nicht lachen: hatte ich bei einem MS SOAP Server (der eigentlich XML ausliefert). Im Fehlerfall hat der ein "200 OK" geliefert, und *eine HTML-Seite* in der der Fehler menschenlesbar beschrieben war. Dazu muss mensch wissen: SOAP richtet sich nicht an Menschen, sondern an Maschinen. Der XML-Parser auf "meiner" Client-Seite war "less than amused". Gotta love Microsoft.
-- t
Am 18.11.21 um 08:36 schrieb tomas@tuxteam.de:
On Thu, Nov 18, 2021 at 12:17:28AM +0100, Ralf Mattes wrote:
Am Mittwoch, 17. November 2021 20:00 CET, Marc Schwarz info@shopmage.de schrieb:
Hi Urs,
was für ein Betriebssystem läuft auf dem Server?
Na, Linux. Das ist ja immerhin die Linux-Mailingliste :-)
Hast Du mal in den nginx Logs (/var/log/nginx) nachgeschaut, ob da das Problem genauer
Laut Urs:
delta systemd[1]: nginx.service: Unit cannot be reloaded because it is inactive.
Da ist schon der Service nicht aktiviert. Leider verät er uns nicht was ' ss -t -a | grep https' ergibt. Warscheinlich lauscht da gar nichts auf Port 443.
Da der Befehl gar nichts zurückgibt, stimmt das wohl.
sudo nginx -t beschwert sich übrigens über Fehler in nginx.conf- obwohl sich das Paket nginx mit apt oder dpkg gar nicht installieren lässt (wg. "Abhängigkeitsproblemen").
Meine Rede: erst den Web-Server ans laufen kriegen :-)
Connection refused ist da ein klares Indiz.
[...]
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Glaube ich eher nicht - wenn nur die Weiterleitung an den Gitea-Server nicht funktionieren sollte müsstest Du ein Connect bekommen (und dann eher einen 500er Fehler).
Genau. Wenn der Webserver läuft, aber nicht "sein" backend ansprechen kann, dann erwarte ich schon eine HTTP-Antwort mit anständigem Fehlercode (ein 5xx, vielleicht auch ein 4xx, was zwar falsch, aber anständig wäre. In der Microsoft-Welt auch mal ein 2xx [1] -- aber jedenfalls immer eine connection (=> kein "connection refused").
lg
[1] Nicht lachen: hatte ich bei einem MS SOAP Server (der eigentlich XML ausliefert). Im Fehlerfall hat der ein "200 OK" geliefert, und *eine HTML-Seite* in der der Fehler menschenlesbar beschrieben war. Dazu muss mensch wissen: SOAP richtet sich nicht an Menschen, sondern an Maschinen. Der XML-Parser auf "meiner" Client-Seite war "less than amused". Gotta love Microsoft.
-- t
Am 21.11.21 um 12:26 schrieb Urs Liska:
Am 18.11.21 um 08:36 schrieb tomas@tuxteam.de:
On Thu, Nov 18, 2021 at 12:17:28AM +0100, Ralf Mattes wrote:
Am Mittwoch, 17. November 2021 20:00 CET, Marc Schwarz info@shopmage.de schrieb:
Hi Urs,
was für ein Betriebssystem läuft auf dem Server?
Na, Linux. Das ist ja immerhin die Linux-Mailingliste :-)
Hast Du mal in den nginx Logs (/var/log/nginx) nachgeschaut, ob da das Problem genauer
Laut Urs:
delta systemd[1]: nginx.service: Unit cannot be reloaded because it is inactive.
Da ist schon der Service nicht aktiviert. Leider verät er uns nicht was ' ss -t -a | grep https' ergibt. Warscheinlich lauscht da gar nichts auf Port 443.
Da der Befehl gar nichts zurückgibt, stimmt das wohl.
sudo nginx -t beschwert sich übrigens über Fehler in nginx.conf- obwohl sich das Paket nginx mit apt oder dpkg gar nicht installieren lässt (wg. "Abhängigkeitsproblemen").
Meine Rede: erst den Web-Server ans laufen kriegen :-)
Erst mal installiert kriegen :-(
Connection refused ist da ein klares Indiz.
[...]
Die Meldung mit dem "Verbindungsaufbau abgelehnt" könnte ich mir als Reaktion auf eine falsche nginx-Konfiguration denken, in der die Anfrage nicht an den gitea-Dienst weitergeleitet wird.
Glaube ich eher nicht - wenn nur die Weiterleitung an den Gitea-Server nicht funktionieren sollte müsstest Du ein Connect bekommen (und dann eher einen 500er Fehler).
Genau. Wenn der Webserver läuft, aber nicht "sein" backend ansprechen kann, dann erwarte ich schon eine HTTP-Antwort mit anständigem Fehlercode (ein 5xx, vielleicht auch ein 4xx, was zwar falsch, aber anständig wäre. In der Microsoft-Welt auch mal ein 2xx [1] -- aber jedenfalls immer eine connection (=> kein "connection refused").
lg
[1] Nicht lachen: hatte ich bei einem MS SOAP Server (der eigentlich XML ausliefert). Im Fehlerfall hat der ein "200 OK" geliefert, und *eine HTML-Seite* in der der Fehler menschenlesbar beschrieben war. Dazu muss mensch wissen: SOAP richtet sich nicht an Menschen, sondern an Maschinen. Der XML-Parser auf "meiner" Client-Seite war "less than amused". Gotta love Microsoft.
-- t
Am Sonntag, 21. November 2021 13:16 CET, Urs Liska mail@ursliska.de schrieb:
Meine Rede: erst den Web-Server ans laufen kriegen :-)
Erst mal installiert kriegen :-(
sudo apt-get install --reinstall nginx
Die Fehlermeldungen sollten uns zeigen _wo_ der Paketkonflikt liegt. Soetwas sollte eig. überhaupt nicht passieren, es sei denn Du hast unterschiedliche Paketquellen gemischt (was man _tunlichst_ nie machen sollte).
Gruss RalfD
Am 21.11.21 um 15:53 schrieb Ralf Mattes:
Am Sonntag, 21. November 2021 13:16 CET, Urs Liska mail@ursliska.de schrieb:
Meine Rede: erst den Web-Server ans laufen kriegen :-)
Erst mal installiert kriegen :-(
sudo apt-get install --reinstall nginx
Die Fehlermeldungen sollten uns zeigen _wo_ der Paketkonflikt liegt.
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 156 nicht aktualisiert.
2 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
E: Internal Error, No file name for nginx:amd64
Hilft das irgendwas?
Soetwas sollte eig. überhaupt nicht passieren, es sei denn Du hast unterschiedliche Paketquellen gemischt (was man _tunlichst_ nie machen sollte).
Natürlich hab ich das nicht: Ich habe ganz einfach vom Installationsmedium installiert und dabei Name und Zeitzone angegeben - sonst habe ich nirgends "Hand angelegt".
Gruss RalfD
Am Montag, 22. November 2021 11:55 CET, Urs Liska mail@ursliska.de schrieb:
Am 21.11.21 um 15:53 schrieb Ralf Mattes:
Am Sonntag, 21. November 2021 13:16 CET, Urs Liska mail@ursliska.de schrieb:
Meine Rede: erst den Web-Server ans laufen kriegen :-)
Erst mal installiert kriegen :-(
sudo apt-get install --reinstall nginx
Die Fehlermeldungen sollten uns zeigen _wo_ der Paketkonflikt liegt.
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 156 nicht aktualisiert.
2 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
E: Internal Error, No file name for nginx:amd64
Hilft das irgendwas?
Was sagt denn:
apt-cache policy nginx:amd64
Gruss RalfD
Am 22.11.21 um 12:49 schrieb Ralf Mattes:
Am Montag, 22. November 2021 11:55 CET, Urs Liska mail@ursliska.de schrieb:
Am 21.11.21 um 15:53 schrieb Ralf Mattes:
Am Sonntag, 21. November 2021 13:16 CET, Urs Liska mail@ursliska.de schrieb:
nginx: Installiert: 1.10.3-1+deb9u7 Installationskandidat: 1.10.3-1+deb9u7 Versionstabelle: *** 1.10.3-1+deb9u7 500 500 http://debian.intergenia.de/debian-security stretch/updates/main amd64 Packages 100 /var/lib/dpkg/status 1.10.3-1+deb9u4 500 500 http://debian.intergenia.de/debian stretch/main amd64 Packages Meine Rede: erst den Web-Server ans laufen kriegen :-)
Erst mal installiert kriegen :-(
sudo apt-get install --reinstall nginx
Die Fehlermeldungen sollten uns zeigen _wo_ der Paketkonflikt liegt.
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 156 nicht aktualisiert.
2 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
E: Internal Error, No file name for nginx:amd64
Hilft das irgendwas?
Was sagt denn:
apt-cache policy nginx:amd64
nginx: Installiert: 1.10.3-1+deb9u7 Installationskandidat: 1.10.3-1+deb9u7 Versionstabelle: *** 1.10.3-1+deb9u7 500 500 http://debian.intergenia.de/debian-security stretch/updates/main amd64 Packages 100 /var/lib/dpkg/status 1.10.3-1+deb9u4 500 500 http://debian.intergenia.de/debian stretch/main amd64 Packages
Gruss RalfD
Am 22.11.21 um 16:23 schrieb Urs Liska:
Am 22.11.21 um 12:49 schrieb Ralf Mattes:
Am Montag, 22. November 2021 11:55 CET, Urs Liskamail@ursliska.de schrieb:
Am 21.11.21 um 15:53 schrieb Ralf Mattes:
Am Sonntag, 21. November 2021 13:16 CET, Urs Liskamail@ursliska.de schrieb:
> nginx: > Installiert: 1.10.3-1+deb9u7 > Installationskandidat: 1.10.3-1+deb9u7 > Versionstabelle: > *** 1.10.3-1+deb9u7 500 > 500http://debian.intergenia.de/debian-security stretch/updates/main amd64 Packages > 100 /var/lib/dpkg/status > 1.10.3-1+deb9u4 500 > 500http://debian.intergenia.de/debian stretch/main amd64 Packages > Meine Rede: erst den Web-Server ans laufen kriegen :-)
Erst mal installiert kriegen :-(
sudo apt-get install --reinstall nginx
Die Fehlermeldungen sollten uns zeigen _wo_ der Paketkonflikt liegt.
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 156 nicht aktualisiert.
2 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
E: Internal Error, No file name for nginx:amd64
Hilft das irgendwas?
Was sagt denn:
apt-cache policy nginx:amd64
nginx: Installiert: 1.10.3-1+deb9u7 Installationskandidat: 1.10.3-1+deb9u7 Versionstabelle: *** 1.10.3-1+deb9u7 500 500http://debian.intergenia.de/debian-security stretch/updates/main amd64 Packages 100 /var/lib/dpkg/status 1.10.3-1+deb9u4 500 500http://debian.intergenia.de/debian stretch/main amd64 Packages
Gruss RalfD
Ich glaube, ich muss allmählich mal fragen, ob irgendjemand es auf sich nehmen würde, sich das einmal gemeinsam mit mir anzusehen (in einer Örtlichkeit wie dem CCC-Souterrain hinter den Westarkaden oder auch bei mir zuhause - ich habe diesem Monat die Drittimpfung hinter mich gebracht). So etwas wie reguläre IT-Stundensätze sind jenseits meiner Reichweite, ich würde mich aber zumindest um eine sehr gute Flasche Wein bemühen wollen. Es geht darum, nginx wieder an den Start zu bekommen, meine Zertifikate zu reanimieren und Gitea (wieder) zu installieren. An dem Punkt würde mich dann interessieren, ob die Repositories noch da und (über git) anzusprechen sind. Das ist deswegen keine absurde Frage, weil der Ausfall meines Mailservers Anfang Oktober zumindest bedingt mit einem Festplattencrash im Rechenzentrum meines Providers zusammenhing. Die Tatsache, dass ich mich seit einem Monat übers Terminal auf dem Server einloggen kann und keine Auffälligkeiten mehr gesehen habe, beruhigt mich hier, wenn auch nur halbwegs.
HG Urs
Hallo Urs,
wenn Du mir die SSH (root) Zugangsdaten zukommen lässt, dann würde ich einen Blick drauf werfen. Vielleicht ist es einfach zu lösen. Kann Dir aber nichts versprechen. In dem Fall bitte per PM mit mir abstimmen und auf keinen Fall das Passwort per Mail schicken, sondern getrennt von Infos zum Server per Signal oder SMS.
Viele Grüße, Marc
Am 27.11.21 um 15:43 schrieb Urs Liska:
Am 22.11.21 um 16:23 schrieb Urs Liska:
Am 22.11.21 um 12:49 schrieb Ralf Mattes:
Am Montag, 22. November 2021 11:55 CET, Urs Liskamail@ursliska.de schrieb:
Am 21.11.21 um 15:53 schrieb Ralf Mattes:
Am Sonntag, 21. November 2021 13:16 CET, Urs Liskamail@ursliska.de schrieb:
>> nginx: >> Installiert: 1.10.3-1+deb9u7 >> Installationskandidat: 1.10.3-1+deb9u7 >> Versionstabelle: >> *** 1.10.3-1+deb9u7 500 >> 500http://debian.intergenia.de/debian-security stretch/updates/main amd64 Packages >> 100 /var/lib/dpkg/status >> 1.10.3-1+deb9u4 500 >> 500http://debian.intergenia.de/debian stretch/main amd64 Packages >> Meine Rede: erst den Web-Server ans laufen kriegen :-) Erst mal installiert kriegen :-(
sudo apt-get install --reinstall nginx
Die Fehlermeldungen sollten uns zeigen _wo_ der Paketkonflikt liegt.
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 156 nicht aktualisiert.
2 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
E: Internal Error, No file name for nginx:amd64
Hilft das irgendwas?
Was sagt denn:
apt-cache policy nginx:amd64
nginx: Installiert: 1.10.3-1+deb9u7 Installationskandidat: 1.10.3-1+deb9u7 Versionstabelle: *** 1.10.3-1+deb9u7 500 500http://debian.intergenia.de/debian-security stretch/updates/main amd64 Packages 100 /var/lib/dpkg/status 1.10.3-1+deb9u4 500 500http://debian.intergenia.de/debian stretch/main amd64 Packages
Gruss RalfD
Ich glaube, ich muss allmählich mal fragen, ob irgendjemand es auf sich nehmen würde, sich das einmal gemeinsam mit mir anzusehen (in einer Örtlichkeit wie dem CCC-Souterrain hinter den Westarkaden oder auch bei mir zuhause - ich habe diesem Monat die Drittimpfung hinter mich gebracht). So etwas wie reguläre IT-Stundensätze sind jenseits meiner Reichweite, ich würde mich aber zumindest um eine sehr gute Flasche Wein bemühen wollen. Es geht darum, nginx wieder an den Start zu bekommen, meine Zertifikate zu reanimieren und Gitea (wieder) zu installieren. An dem Punkt würde mich dann interessieren, ob die Repositories noch da und (über git) anzusprechen sind. Das ist deswegen keine absurde Frage, weil der Ausfall meines Mailservers Anfang Oktober zumindest bedingt mit einem Festplattencrash im Rechenzentrum meines Providers zusammenhing. Die Tatsache, dass ich mich seit einem Monat übers Terminal auf dem Server einloggen kann und keine Auffälligkeiten mehr gesehen habe, beruhigt mich hier, wenn auch nur halbwegs.
HG Urs
Am 27.11.21 um 22:35 schrieb Marc Schwarz:
Hallo Urs,
wenn Du mir die SSH (root) Zugangsdaten zukommen lässt, dann würde ich einen Blick drauf werfen. Vielleicht ist es einfach zu lösen.
Das wäre sehr nett und würde mich zu Dank verpflichten.
Kann Dir aber nichts versprechen.
Das st mir natürlich klar. /So /viel weiß ich auch von der Materie
In dem Fall bitte per PM mit mir abstimmen und auf keinen Fall das Passwort per Mail schicken (am besten gleich über die öffentliche Liste ..., sondern getrennt von Infos zum Server per Signal oder SMS.
Wenn du die Handynummer (die vielleicht über die Liste?) teilst, schicke ich dir das Nötige per SMS.
HG Urs
Viele Grüße, Marc
Am 27.11.21 um 15:43 schrieb Urs Liska:
Am 22.11.21 um 16:23 schrieb Urs Liska:
Am 22.11.21 um 12:49 schrieb Ralf Mattes:
Am Montag, 22. November 2021 11:55 CET, Urs Liskamail@ursliska.de schrieb:
Am 21.11.21 um 15:53 schrieb Ralf Mattes:
Am Sonntag, 21. November 2021 13:16 CET, Urs Liskamail@ursliska.de schrieb:
>>> nginx: >>> Installiert: 1.10.3-1+deb9u7 >>> Installationskandidat: 1.10.3-1+deb9u7 >>> Versionstabelle: >>> *** 1.10.3-1+deb9u7 500 >>> 500http://debian.intergenia.de/debian-security stretch/updates/main amd64 Packages >>> 100 /var/lib/dpkg/status >>> 1.10.3-1+deb9u4 500 >>> 500http://debian.intergenia.de/debian stretch/main amd64 Packages >>> Meine Rede: erst den Web-Server ans laufen kriegen :-) > Erst mal installiert kriegen :-( sudo apt-get install --reinstall nginx
Die Fehlermeldungen sollten uns zeigen _wo_ der Paketkonflikt liegt.
0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 156 nicht aktualisiert.
2 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
E: Internal Error, No file name for nginx:amd64
Hilft das irgendwas?
Was sagt denn:
apt-cache policy nginx:amd64
nginx: Installiert: 1.10.3-1+deb9u7 Installationskandidat: 1.10.3-1+deb9u7 Versionstabelle: *** 1.10.3-1+deb9u7 500 500http://debian.intergenia.de/debian-security stretch/updates/main amd64 Packages 100 /var/lib/dpkg/status 1.10.3-1+deb9u4 500 500http://debian.intergenia.de/debian stretch/main amd64 Packages
Gruss RalfD
Ich glaube, ich muss allmählich mal fragen, ob irgendjemand es auf sich nehmen würde, sich das einmal gemeinsam mit mir anzusehen (in einer Örtlichkeit wie dem CCC-Souterrain hinter den Westarkaden oder auch bei mir zuhause - ich habe diesem Monat die Drittimpfung hinter mich gebracht). So etwas wie reguläre IT-Stundensätze sind jenseits meiner Reichweite, ich würde mich aber zumindest um eine sehr gute Flasche Wein bemühen wollen. Es geht darum, nginx wieder an den Start zu bekommen, meine Zertifikate zu reanimieren und Gitea (wieder) zu installieren. An dem Punkt würde mich dann interessieren, ob die Repositories noch da und (über git) anzusprechen sind. Das ist deswegen keine absurde Frage, weil der Ausfall meines Mailservers Anfang Oktober zumindest bedingt mit einem Festplattencrash im Rechenzentrum meines Providers zusammenhing. Die Tatsache, dass ich mich seit einem Monat übers Terminal auf dem Server einloggen kann und keine Auffälligkeiten mehr gesehen habe, beruhigt mich hier, wenn auch nur halbwegs.
HG Urs
-- Mit freundlichen Grüßen / with kind regards Marc Schwarz
Schwarz IT Consulting RA Marc Schwarz Goethestr. 25 79100 Freiburg Germany T. ++49 (0) 171 3696847 F. ++49 (0) 761 75856
Softwareentwicklung - E Commerce Systeme - IT-Consulting. IT-Sicherheit - Datenschutz - Sichere Datenübertragung. Ihr Partner für Webseiten, Blogs, Social Media und Shops, Magento 2, Magento 1.9 Portierung.
Softwaredevelopment - E Commerce Systems - IT Consulting. IT-Security - Dataprotection - Secure Datatransfer. Your Partner for Magento 2, Magento 1.9 Migration.
Am 28.11.21 um 13:50 schrieb Urs Liska:
Am 27.11.21 um 22:35 schrieb Marc Schwarz:
Hallo Urs,
wenn Du mir die SSH (root) Zugangsdaten zukommen lässt, dann würde ich einen Blick drauf werfen. Vielleicht ist es einfach zu lösen.
Das wäre sehr nett und würde mich zu Dank verpflichten.
Kann Dir aber nichts versprechen.
Das ist mir natürlich klar. /So /viel weiß ich auch von der Materie.
In dem Fall bitte per PM mit mir abstimmen und auf keinen Fall das Passwort per Mail schicken
(ja, am besten gleich über die öffentliche Liste ...)
getrennt von Infos zum Server per Signal oder SMS.
Wenn du die Handynummer teilst (die vielleicht doch über die Liste?), schicke ich dir das Nötige per SMS.
HG Urs
Viele Grüße, Marc
Am 27.11.21 um 15:43 schrieb Urs Liska:
Am 22.11.21 um 16:23 schrieb Urs Liska:
Am 22.11.21 um 12:49 schrieb Ralf Mattes:
Am Montag, 22. November 2021 11:55 CET, Urs Liskamail@ursliska.de schrieb:
Am 21.11.21 um 15:53 schrieb Ralf Mattes: > > Am Sonntag, 21. November 2021 13:16 CET, Urs Liskamail@ursliska.de schrieb: > > >>>> nginx: >>>> Installiert: 1.10.3-1+deb9u7 >>>> Installationskandidat: 1.10.3-1+deb9u7 >>>> Versionstabelle: >>>> *** 1.10.3-1+deb9u7 500 >>>> 500http://debian.intergenia.de/debian-security stretch/updates/main amd64 Packages >>>> 100 /var/lib/dpkg/status >>>> 1.10.3-1+deb9u4 500 >>>> 500http://debian.intergenia.de/debian stretch/main amd64 Packages >>>> Meine Rede: erst den Web-Server ans laufen kriegen :-) >> Erst mal installiert kriegen :-( > sudo apt-get install --reinstall nginx > > Die Fehlermeldungen sollten uns zeigen _wo_ der Paketkonflikt liegt. 0 aktualisiert, 0 neu installiert, 1 erneut installiert, 0 zu entfernen und 156 nicht aktualisiert.
2 nicht vollständig installiert oder entfernt.
Nach dieser Operation werden 0 B Plattenplatz zusätzlich benutzt.
E: Internal Error, No file name for nginx:amd64
Hilft das irgendwas?
Was sagt denn:
apt-cache policy nginx:amd64
nginx: Installiert: 1.10.3-1+deb9u7 Installationskandidat: 1.10.3-1+deb9u7 Versionstabelle: *** 1.10.3-1+deb9u7 500 500http://debian.intergenia.de/debian-security stretch/updates/main amd64 Packages 100 /var/lib/dpkg/status 1.10.3-1+deb9u4 500 500http://debian.intergenia.de/debian stretch/main amd64 Packages
Gruss RalfD
Ich glaube, ich muss allmählich mal fragen, ob irgendjemand es auf sich nehmen würde, sich das einmal gemeinsam mit mir anzusehen (in einer Örtlichkeit wie dem CCC-Souterrain hinter den Westarkaden oder auch bei mir zuhause - ich habe diesem Monat die Drittimpfung hinter mich gebracht). So etwas wie reguläre IT-Stundensätze sind jenseits meiner Reichweite, ich würde mich aber zumindest um eine sehr gute Flasche Wein bemühen wollen. Es geht darum, nginx wieder an den Start zu bekommen, meine Zertifikate zu reanimieren und Gitea (wieder) zu installieren. An dem Punkt würde mich dann interessieren, ob die Repositories noch da und (über git) anzusprechen sind. Das ist deswegen keine absurde Frage, weil der Ausfall meines Mailservers Anfang Oktober zumindest bedingt mit einem Festplattencrash im Rechenzentrum meines Providers zusammenhing. Die Tatsache, dass ich mich seit einem Monat übers Terminal auf dem Server einloggen kann und keine Auffälligkeiten mehr gesehen habe, beruhigt mich hier, wenn auch nur halbwegs.
HG Urs
-- Mit freundlichen Grüßen / with kind regards Marc Schwarz
Schwarz IT Consulting RA Marc Schwarz Goethestr. 25 79100 Freiburg Germany T. ++49 (0) 171 3696847 F. ++49 (0) 761 75856
Softwareentwicklung - E Commerce Systeme - IT-Consulting. IT-Sicherheit - Datenschutz - Sichere Datenübertragung. Ihr Partner für Webseiten, Blogs, Social Media und Shops, Magento 2, Magento 1.9 Portierung.
Softwaredevelopment - E Commerce Systems - IT Consulting. IT-Security - Dataprotection - Secure Datatransfer. Your Partner for Magento 2, Magento 1.9 Migration.
On Wed, Nov 17, 2021 at 12:38:30PM +0100, Urs Liska wrote:
Liebe Leute,
ich kann es weder erklären noch genau beschreiben, aber ich habe ein Problem mit meinem Gitea-Server: Ich kann ihn weder im Browser noch über wget kontaktieren. Der Browser meldet einfach "konnte keine Verbindung aufbauen",
Browser sind nicht mehr das, was sie mal waren...
wget ist etwas konkreter und sagt entweder"Verbindungsaufbau zu XYZ(xyz)|85.25.3.15|:443... fehlgeschlagen: Verbindungsaufbau abgelehnt."
(a)
...das würde ich mal als "connection refused" interpretieren. Das würde bedeuten: Namensauflösung hat geklappt (auch oben an der IP-Adresse zu sehen), spricht für ein funktionierendes DNS (oder aber auf einen Eintrag in Deiner /etc/hosts, so etwas kann einen auch mal ein Bein stellen [1] ;-)
oder "Auflösen des Hostnamensfehlgeschlagen ... der Name oder Dienst ist nicht bekannt."
(b)
...das wiederum deutet auf ein Fehlschlagen der DNS-Auflösung hin, was sich mit (a) nicht verträgt. Hmm...
Passiert mal (a), mal (b)? Oder ändern sich irgendwelche Bedingungen?
Um die Namensauflösung alleine zu testen kannst Du immer `host' oder `dig' und konsorten benutzen.
Ich unterstelle, dass die DNS-Einträge korrekt sind, denn mit ping (oder Verbinden mit ssh) geht es wie es soll.
Aha. Also eher (a). Aber (b) verunsichert mich noch ein wenig.
nun weiß ich nicht, ob ich Gitea "einfach"neu installieren soll (v.a. inkl. Integration mit nginx) oder ob ich ein ernsteres Problem mit dem Server insgesamt habe.
Wenn (a) würde ich als erstes darauf tippen, dass der Webserver (nginx) runtergefallen ist. "Connection refused" ist ganz klarer Indiz "die Maschine finde ich zwar, aber an Port 443 ist niemand" (eine Firewall davor könnte auch diesen Effekt "produzieren").
Wäre nginx oben, dann würde es antworten und vielleicht sagen "sorry, mein Backend liefert gerade nicht". Aber auf TCP-Ebene hätte die Verbindung geklappt -> andere Fehlermeldung.
ankbar für jeden Tipp oder Vorschlag
HTH :)
lg -- t
-
Marc Schwarz -
Ralf Mattes -
Ralf Mattes -
tomas＠tuxteam.de -
Urs Liska