Hallo Community,
Zuerst einmal Gratulation zu dem guten Projekt.
ich habe eine Erstinstallation auf einem Debian 11 x64 Server durchgeführt und bin jetzt bei der Einrichtung.
Dabei sind mir verschiedene Probleme aufgefallen, die eventuell zusammenhängen.
1.) wenn ich im Portal den SSL Einrichtungsassistent starte, kommt die Meldung „Voraussetzungen werden überprüft“, im Hintergrund sehe ich „Port 80 ist blockiert durch einen anderen Dienst“ - dann friert der Assistent ein.
2.) ich kann in den Grundeinstellungen keine Parameter mehr verändern - initial ging das mal
Wenn ich etwas ändere und auf Speichern klicke, sind die alten Einstellungen zurück.
3.) Habe versucht, einen Mitglieder - Import durchzuführen - ich wähle eine Excel Datei aus (Beispiel aus der Doku) und klicke auf „Schritt 2“, jetzt erscheint eine Fehlermeldung „502 Bad Gateway - openresty“
4.) das goaccess-npm-dashboard auf port 7880 läuft zwar, zeigt aber über all 0
Ich habe zwar etwas Erfahrung mit Linux Systemen aller Art, konnte hier aber nichts genaueres finden.
Hallo das mit dem ändern der Grundeinstellung wurde hier in einem Beitrag schon mal erklärt, schau bitte mal im Ordner Store dort die Datenbank Dateien schreib recht geben, dann sollte es wieder klappen.
Das mit dem Assistent habe ich auch das Problem, habe das dann aber über die Konsole direkt gemacht wie in der Doku beschrieben.
Zu der letzten Frage kann ich dir leider nichts sagen.
hatte gerade ein sehr produktives Telefonat
meine Probleme lagen an dem File Watching des pm2 Prozesses.
Dadurch wurde meine Alarmiator Instanz immer wieder neu gestartet
„pm2 status“ zeigte watching=enabled
„pm2 stop 0 --watch“ stellt watching auf disabled
„pm2 start 0“ startet die Instanz danach wieder.
Jetzt sind die Probleme gelöst - Danke an den guten Support
Dem SSL-Wizard werden wir in einer der kommenden Versionen komplett entfernen. Wir haben uns dazu entschlossen, einen Reverse Proxy zu nutzen. Das hat mehrere Vorteile:
Die SSL-Zertifikate werden automatisch erstellt und erneuert. Der Admin muss sich nicht mehr darum kümmern
Aus dem Internet müssen keine unterschiedlichen Ports mehr genutzt und über ein Port-Forwarding konfiguriert werden. Gerade in öffentlichen WLANs ist es gängige Praxis, dass eingebuchte Smartphones nur über die Ports 80 und 443 (SSL) kommunizieren dürfen.
Die Installation des Reverse Proxy (NGINX) ist im Handbuch bereits beschrieben und auch schon vielfach mit ALARMiator stabil im Einsatz.
Bei Fragen zur Einrichtung sowie Umstellung auf NGINX gerne hier im Forum in einem eigenen Topic stellen.
bei der Installationsanleitung des SSL in der Dokumentation komme ich ab dem Befehl: docker volume create portainer_data
nicht mehr weiter. Hier erhalte ich die Meldung: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post „http://%2Fvar%2Frun%2Fdocker.sock/v1.24/volumes/create“: dial unix /var/run/docker.sock: connect: permission denied"
gehe ich dann einfwach zum nächsten Befehl bekomme ich als Rückmeldung: docker: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post „http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/create?name=portainer“: dial unix /var/run/docker.sock: connect: permission denied. See ‚docker run --help‘.
hast du den Raspberry oder das System mal neu gestartet? Ich glaube mich zu erinnern, dass ich beim ersten Mal ebenfalls das Problem hatte und da Docker aus irgendeinem Grund nicht gelaufen ist und ich einmal neustarten musste und danach funktioniert hat.
Bei weiteren Installationsversuchen hatte ich jedoch keine Probleme bzw. konnte es nicht reproduzieren.
Probier das nochmal und wenn nicht gerne nochmal melden.
ich nehm mal lieber diesen Beitrag als einen neuen zu erstellen
Ich hab die Installation wie im Handbuch beschrieben, allerdings auf einem Dedicated Server, habe dafür natürlich im Portainer dementsprechend wie im Handbuch beschrieben umgestellt.
Soweit so gut, allerdings kann ich mit nginx kein SSL Zertifikat erstellen
Error: Command failed: certbot certonly --config „/etc/letsencrypt.ini“ --cert-name „npm-16“ --agree-tos --authenticator webroot --email „“ --preferred-challenges „dns,http“ --domains „“
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
at ChildProcess.exithandler (node:child_process:402:12)
at ChildProcess.emit (node:events:513:28)
at maybeClose (node:internal/child_process:1100:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:304:5)
Um den Nginx Proxy Manager mit SSL zum laufen zu kriegen muss die Portweiterleitung für Port 80 und Port 443 eingerichtet sein. Die SSL Verschlüsselung wird nachher über Port 443 laufen. Ist das bereits der Fall? Wenn ich es richtig sehe hast du bereits einen Reverse Proxy eingerichtet ohne SSL Verschlüsselung?
Aber dann bekomm ich wieder kein Zertifikat, OHNE diese Befehle und einem erstellen Zertifikat bekomm ich diese Meldung:
Fehler: Gesicherte Verbindung fehlgeschlagen
Beim Verbinden mit domain-xyz.de trat ein Fehler auf.
Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren
Zusätzlich hab ich jetzt noch eine Sperrzeit erhalten zum erstellen von Zertifikaten … -.-
Hab übersehen, dass du einen eigenen Server hast. Da brauchst du keine Portweiterleitung, da du nicht hinter einem Router bist (zum Beispiel Fritzbox o.ä) Also mit iptables solltest du nicht hantieren müssen. Das steht auch nirgends im Handbuch
Ich würde dich Bitten einfach nochmal anzufangen. Da du keinen Router hast fällt die Portweiterleitung für dich weg. Du kannst direkt hier starten Erster Schritt für dich . Als du Portainer installiert hast war dieser ja direkt über Port 9000 unter deiner URL erreichbar so wird es auch mit Nginx und ALARMiator auf deren Ports sein. Also hangel dich einfach mal durch und ignoriere die Portweiterleitung.
Meist gibt man einen Quellport (das ist der aus dem Internet ankommende, hier Port 80), eine IP-Adress des Zielsystems (in unserem Fall Dein ALARMiator Server) und einen Zielport an (in unserem Fall auch wiederum Port 80)
Das irritiert mich, wie soll ich den Port 80 zu Port 80 weiterleiten Oo… das Ergibt für mich keinen Sinn
Richtig Portainer und Nginx sind direkt auf ihre Ports angesprungen, ebenso auch ALARMiator selbst auf 5000… Aber das Zertifikat selbst testet ja die Dateien die auf Port 80 liegen (Hier in meinem Fall liegt ja nichts, wäre ja ansonsten der Port von Apache2)
Meine Idee wäre jetzt nur noch den Port von Alarmiator von 5000 auf 80 zu ändern, so das NGINX direkt auf die Daten kommt grübel
Gibt es hier die Möglichkeit den Port zu ändern?
Das einzige was mich jetzt noch zum Überlegen bringt, sind die Einstellungen in Portainer.io dort soll ich ja die Portweiterleitungen einstellen 80 zu 80; 81 zu 81 ; 443 zu 443…
Okay ich weiß nicht, ob ich dir in allem Folgen konnte aber ich versuche mal.
Nginx ist bei uns nur nur der Fluglotse. Der hört auf Port 80 und auf Port 443 auf Anfragen und leitet die einfach ganz frech an ALARMiator weiter, ohne dass es der Endnutzer mitbekommt. Nginx ist auch für die SSL Verschlüsselung verantwortlich. Deshalb darfst du zum Beispiel nicht versuchen selber irgendwelche Ports mit Iptables umzuleiten. Das macht nginx dann schon selber.
Du musst also Regeln, die du selbstständig in die Iptables eingefügt hast wieder rückgängig machen.
Nginx greift also selber gar nicht auf die Daten vom Alarmiator zu sondern leitet den Nutzer einfach an ALARMiator weiter.
Und die Portangaben im Portainer bitte so lassen. Da du einen dedicated Server hast muss der Nginx auch auf Network Mode Host im Portainer gestellt werden wie es im Handbuch steht, damit er den ALARMiator erreichen kann.
Gut, ich versuch es mal verständlicher zu formulieren
Ich habe alle IPTables rückgänging gemacht. Portainer.io Container hat ebenfalls die Ports noch im Container. Der Container steht auf Host im Network Mode. Nginx lebt damit also wie beschrieben in seinem Container.
Der Server kann wie im Handbuch beschrieben mit domain:5000 aufgerufen, nur domain.de funktioniert nicht OHNE Portangabe.
Nginx erstellt die Zertifikate für Dateien bzw Serverdateien die auf Port 80 liegen. Der Alarmiatorserver liegt aber wie bekannt auf Port 5000, weswegen ich die Meldung von NGINX bekomme das keine Daten ausgelesen werden konnten. Sprich NGINX leitet nicht von Port 80 auf 5000 um.
Ich frage mich aber gerade warum den erst den Port umleiten. Wenn es doch nur daran liegt das Certbot auf Port 80 lauscht, lass ich doch einfach Alarmiator auf Port 80 laufen. Dadurch erreiche ich das ich den Server anstatt mit domain.de:5000 nur mit domain.de aufrufen kann, sprich Certbot hat auf Port80 nun seine Daten die er Auslesen will und kann anhand dieser dann das Zertifkat erstellen?
Der Knick ist, dass die Verbindung von Nginx zu Alarmiator via http läuft und das so auch in Ordnung ist. Das SSL Zertifikat liegt beim Nginx und da dieser auf dem gleichen Rechner liegt wie ALARMiator ist das auch alles nur intern. Die Verbindung von ALARMiator zu deinem Handy oder Browser ist also vollständig verschlüsselt.
Was hast du denn im Nginx alles eingestellt? Da du ja im Network Mode „Host“ bist solltest du bei der Domain direkt auf localhost 5000 umleiten. Schick gerne mal einen Screenshot von deiner Reverse Proxy Konfiguration und übermale die Domain bitte im Bild.
Wir reden gerade ein wenig aneinander vorbei oder?
Nginx und ALARMiator liegen auf dem selben Dedicated Root Server in einem Rechenzentrum in Düsseldorf. Somit würde hier das Intern greifen! Keine Frage. Das Problem ist aber das ich ja überhaupt kein Zertifikat erstellen kann, und wenn er eines erstellt auf die Einstellungen wie im Handbuch bekomm ich diese Fehlermeldung:
Fehler: Gesicherte Verbindung fehlgeschlagen
Beim Verbinden mit domain-xyz.de 1 trat ein Fehler auf.
Die Website kann nicht angezeigt werden, da die Authentizität der erhaltenen Daten nicht verifiziert werden konnte.
Kontaktieren Sie bitte den Inhaber der Website, um ihn über dieses Problem zu informieren
Es wäre sinnvoll sich an die Anleitung zu halten. In unserer Anleitung kommt nirgends ein Apache / iptables vor, diese blockiern offenbar den 80er Port und dadurch kann Nginx keine Zertifikate verifizieren. Was Sinn macht, da jeder Port nur einmal belegt werden kann.
Gibt 2 Möglichkeiten:
a) Du frimmelst das raus wie du die Zertifikat Generierung hinbekommst wenn ein Apache / Certbot neben einem Nginx läuft (anderer Port) oder stellst es eigenständig auf Apache um und machst dort die Weiterleitung von SSL auf ALARMiator. Beides ist kein Standard Use Case. Port 80 muss laut unserer Anleitung frei sein für Nginx
b) Du löst es über einen Server wo keine anderen Dienste laufen bzw. Raspberry PI
Der Nginx ist rein als Reverse Proxy gedacht, man muss diesen nicht nutzen, wenn man genügend Kenntnisse besitzt.
Allerdings gibts keine Schritt für Schritt Anleitung für jede Serverkonstellation, wenn man zusätzliche Dienste laufen hat.
Habe mir deinen Server kurz angeschaut gehabt und bei dir Antwortet auf Port 80 nicht das was antworten sollte, deshalb musst du irgendetwas anders machen als in der Anleitung steht und dann kann es auch nicht so funktionieren.
auf dem Server läuft nichts anderes ;-/
Das ist eine frische Debian 11 Minimal Installation.
Ich hab jetzt nochmal den Server komplett neu aufgesetzt und fang von vorne an.
Apache war nicht und wir nicht installiert, da dort ganz andere Projekte draufziehen. Aber keiner dieser benötigt den Port 80.
Deswegen hatte ich ja die Idee Alarmiator ansich auf Port 80 zu setzen, und hinterfragte ja ob dies so möglich ist oder ob es eine Grund gibt warum dieser Dienst auf 5000 läuft.
Wie hast du was geprüft und was sollte die Antwort sein?
Als ich geschaut hatte, kam die Oberfläche von ALARMiator auf dem Port. Ergo war der Port durch irgendeine Konfiguration sei es IPTABLES / Apache / sonstige Umleitung belegt.
Nginx ist rein dafür da die SSL Verschlüsselung zu übernehmen und die Requests intern über HTTP weiterzugeben.
Probier es jetzt nochmal, weil jetzt antwortet nichts mehr und dann wirds zu 95% gehen
