Hallo an alle, die sich mit diesem Thema auskennen: ich möchte Grafana und InfluxDB auf einem Webserver installieren, wo schon eine WebSeite mit Apache drauf läuft. Die WebSeite ist mit letsencrypt https-verschlüsselt. Ich hatte dazu den bot von letzencrypt benutzt, alles aktualisiert sich und ist prima. So wie ich es verstanden habe, benutzt Grafana und InfluxDB den Apache gar nicht, ist das richtig? Aber beide sollen bei mir mit https abgesichert sein (also sowohl das Daten schicken an die InfluxDB als auch das Anschauen der Ergebnisse mit Grafana Muss ich dann 2 neue Zertifikate bei Letsencrypt erzeugen mit "-certonly", oder kann ich das vorhandene von der Webseite benutzen? Für alle beide? Und falls ich die neuen erzeugen muss, wie teste ich die ohne Webseite/Apache und wie erneuern sich die automatisch? Lieder sind alle Beispiele bei Letsencrypt, die ich gefunden habe, irgendwie immer auf Webseiten bezogen?
Lass den Apache&Letsencrypt weiter laufen, Starte Grafana ohne direktem Zugriff von Außen, richte im apache Pfade als "reverse Proxy" ein, z.B "/grafana" als Reverse-Proxy auf "http://127.0.0.1:3000/"; HTTPS-Verschlüsselung, Logging und ggfs. Vorab-Zugriffskontrolle macht dann weiterhin dein Apache. https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html (Nur die ersten Abschnitte, Load-Balancing/Fail-Over etc wäre da overkill) Und es kann sein, dass Grafana wissen muss über welchen Pfad es von extern aufgerufen wird, damit es keine URLs generiert die aus dem Proxy rausfallen. https://grafana.com/docs/grafana/latest/administration/configuration/#root_url per Environment (docker container) oder config-datei setzbar (GF_SERVER_DOMAIN="mein.dyn.dns.xyz" ; GF_SERVER_ROOT_URL=https://mein.dyn.dns.xyz/proxy_path_grafana"; ) Für InfluxDB (wenn das auch von ausserhalb erreichbar sein muss) geht das analog
1 | ProxyPass /influx http://127.0.0.1:8086/ |
:
Bearbeitet durch User
danke, muss ich alles durcharbeiten, aber sieht sehr geeignet aus!
Ich hab jetzt beides erstmal installiert. Docker benutze ich nicht. Wo gehören diese Zeilen s.o. hin? Ich habe hier ein Beispiel gefunden - soll ich auch so eine /etc/apache2/sites-enabled/grafana1.conf anlegen? Und welche der Zeilen brauche ich ? alle: https://administrator.de/forum/reverse-proxy-portfreigabe-567998.html Außerdem: muss ich die ports 8086 und 3000 auch "nach außen" in meinem Router öffnen, oder reicht der vorhandene offene 443 und der Proxy setzt dann die Portnummern um? Sorry ich hab da mit Apache config bisher kaum zu tun gehabt..
Rudi schrieb: > Außerdem: muss ich die ports 8086 und 3000 auch "nach außen" in meinem Die Port brauchst du nicht öffnen.
Also es gibt irgendwie 1000 verschiedene Beispiele für diesen reverse proxy.. Mal beim Beispiel Grafana - also was ich glaube zu wissen: - ich muss a2enmod proxy proxy_http ausführen - ich muss einen virtuelle host erzeugen und dafür eine Datei /etc/apache2/sites-enabled/grafana.conf erzeugen mit diesen Inhalt:
1 | VirtualHost *:443> |
2 | DocumentRoot /var/www/html/ |
3 | ServerName meinServer.no-ip.biz |
4 | RewriteEngine on |
5 | ProxyPass "/grafana" "http://localhost:3000/" |
6 | ProxyPassReverse "/grafana" "http://localhost:3000/" |
7 | </VirtualHost> |
danach apache neu starten und ich sollte unter https://meinServer.no-ip-biz/grafana das Grafana-dashboard sehen? Stimmt das soweit?
Rudi schrieb: > Hallo an alle, die sich mit diesem Thema auskennen: > > ich möchte Grafana und InfluxDB auf einem Webserver installieren, wo > schon eine WebSeite mit Apache drauf läuft. Die WebSeite ist mit > letsencrypt https-verschlüsselt. Ich hatte dazu den bot von letzencrypt > benutzt, alles aktualisiert sich und ist prima. > > So wie ich es verstanden habe, benutzt Grafana und InfluxDB den Apache > gar nicht, ist das richtig? Aber beide sollen bei mir mit https > abgesichert sein (also sowohl das Daten schicken an die InfluxDB als > auch das Anschauen der Ergebnisse mit Grafana Du kannst, wie es auch andere hier schon empfohlen haben, Deinen Apachen als Reverse Proxy einrichten. Leider ist das nicht immer ganz einfach, wenn man andere als die Default-Pfade der Applikationen benutzt, also zum Beispiel eine Software, die erwartet, unter dem Webroot-Kontext / (zB. https://example.com/) betrieben zu werden, plötzlich unter einem Kontext ruebennase (also zB unter https://example.com/ruebennase/) anzusprechen. So etwas kann leider hie und da zu mehr oder minder großen Problemen mit hartgecodeten URLs führen, vor allem in Verbindung mit Redirects und JavaScript. Eine andere, langfristig komfortablere Alternative wäre, Deine Applikationen in Docker-Containern zu betreiben und über docker-compose zu steuern. Das erfordert natürlich zunächst einen gewissen Aufwand zur Einarbeitung, je nach Deiner Linux-Erfahrung kann das durchaus einige Tage oder sogar Wochen dauern. Als Reverse Proxy kannst Du dann einfach letsencrypt-nginx-proxy-companion (https://github.com/nginx-proxy/docker-letsencrypt-nginx-proxy-companion) benutzen; das erfordert nur drei Umgebungsvariablen für Deine jeweiligen Container, um den Rest wie die Letsencrypt-Zertifikate und deren Reneval kümmern sich die Container von Jason Wilder, dem Autor der Software. Das ist, den Einarbeitungsaufwand mal weggelassen, aus meiner heutigen Sicht einer der mit Abstand komfortabelsten Wege, Webseiten zu betreiben. Wenn Du mehr darüber wissen möchtest, frag' einfach. Vermutlich kommen aber jetzt wieder die bekannten "Freunde", die zwar keine Ahnung von Docker und niemals damit gearbeitet haben, aber ganz genau wissen, daß das unglaublich aufwändig und natürlich ohnehin schreckliches Teufelswerk ist. ;-)
Du hast ja letsencrypt schon eingerichtet. Schau mal, wo der VirtualHost davon ist, und füge das ProxyPass zeugs dort hinzu.
Jemand schrieb: > Eine andere, langfristig komfortablere Alternative wäre, Deine > Applikationen in Docker-Containern zu betreiben und über docker-compose > zu steuern. Das erfordert natürlich zunächst einen gewissen Aufwand zur > Einarbeitung, je nach Deiner Linux-Erfahrung kann das durchaus einige > Tage oder sogar Wochen dauern. Super, denn Teufel mit dem Beelzebub auszutreiben, eine Abstraktionsebene hat immer einen Preis, im Fall von Docker ist, dass vor allen ein gewissen Performanceverlust und als Datastore (influxdb) eignet sich das Teil auch nicht so gut wie man aus für gewöhnlich gut informierten Kreisen hört. Außerdem hat Docker ein inhärentes Sicherheitsproblem, jeder Container hat seinen eigen Softwarestack mit wer weiß was für Libary Versionen. Für Hacker kann das ein schöner neuer Attackvector sein, um in das System zu kommen und da Docker meistens mit allen Capabilities und Rechten läuft, oftmals reicht ein gammliger Container, um den kompletten Server zu übernehmen. Persönlich halte ich Docker für ein Offenbarungseid der Ingenieure, anstatt sich mit der Software zu befassen und Probleme zu lösen einfach eine Glueschicht drüber wird schon passen. Das ist modern das ist Agile und wir haben eine Super time to Market, nur keinen mehr er das System wirklich kennt und versteht.
Ich bin jetzt ein bisschen weiter, aber noch nicht am Ziel mit dem Grafana reverse proxy: Unter "https://meinserver.no-ip.biz/grafana"; antwortet jetzt etwas, und in der Browser-Adresszeile steht dann "https://meinserver.no-ip.biz/grafana/login"; Aber ich bekomme einen Umleitungsfehler, noch nicth die Grafana-Seite angezeigt. Wie kann ich das debuggen? Wenn ich im Firefox F12 drücke um zu sehen was passiert, zeigt er ganz oft "302 get..." an, Chrome meldet "ERR-TOO_MANY_REDIRECTS" Mühsam..
Hier ist noch der Inhalt von meiner Datei
/etc/apache2/sites-available/000-default-le-ssl.conf - stimmt das so?:
[code]
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
ServerName **********.no-ip.biz
SSLCertificateFile
/etc/letsencrypt/live/**********.no-ip.biz/fullchain.pem
SSLCertificateKeyFile
/etc/letsencrypt/live/**********.no-ip.biz/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf
Header always set X-XSS-Protection "1; mode=block"
Header always set x-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Strict-Transport-Security "max-age=31536000;
includeSubDomains"
# next line caused owncloud login refresh every 5 sec, so changed to
overnext
#Header always set Content-Security-Policy "default-src 'none';
img-src 'self'; script-src 'self'; style-src 'self'"
Header always set Content-Security-Policy "default-src 'self';
script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline';
frame-src *; img-src * data: blob:; font-src 's$
Header always set Referrer-Policy "strict-origin"
# for grafana
ProxyRequests Off
ProxyPass "/grafana" "http://localhost:3000/";
ProxyPassReverse "/grafana" "http://localhost:3000/";
</VirtualHost>
</IfModule>
[\code]
Hi Rudi,
bin gerade auf dem Sprung ... ich meine mal , ich habe das mal so
RewriteEngine on
RewriteRule ^/?$ grafana [R=permanent,L]
<Location "/grafana">
ProxyPass http://localhost:3000
</Location>
ProxyPassReverse /grafana http://localhost:3000
</VirtualHost>
gemacht.
Gruß Ingo
Danke, jetzt geht es, der Slash hinter der 3000 bei mir war zu viel, wenn man den weglässt, dann geht es auch mit dem Beispiel oben.
Imonbln schrieb: > Jemand schrieb: >> Eine andere, langfristig komfortablere Alternative wäre, Deine >> Applikationen in Docker-Containern zu betreiben und über docker-compose >> zu steuern. Das erfordert natürlich zunächst einen gewissen Aufwand zur >> Einarbeitung, je nach Deiner Linux-Erfahrung kann das durchaus einige >> Tage oder sogar Wochen dauern. > > Super, denn Teufel mit dem Beelzebub auszutreiben, Als ich seinen Vorschlag gelesen habe, wußte ich schon, warum "Jemand" schrieb: Jemand schrieb: > Vermutlich kommen > aber jetzt wieder die bekannten "Freunde", die zwar keine Ahnung von > Docker und niemals damit gearbeitet haben, aber ganz genau wissen, daß > das unglaublich aufwändig und natürlich ohnehin schreckliches > Teufelswerk ist. ;-) Schau, Du kannst gerne mitreden, wenn Du Dir ein bisschen Ahnung und Erfahrung mit derlei Technologien (kann auch LXC, Podman oder etwas anderes in der Richtung sein) zugelegt hast. Bis dahin sind Beiträge wie Deiner einfach nur peinlich. Wie kann einer in einem Forum, das sich immerhin mit Mikrocontrollern, Elektronik und Programmierung befaßt, so fortschritts- und technologiefeindlich eingestellt sein?
Rudi schrieb: > Ich bin jetzt ein bisschen weiter, aber noch nicht am Ziel mit dem > Grafana reverse proxy: > > Unter "https://meinserver.no-ip.biz/grafana"; antwortet jetzt etwas, und > in der Browser-Adresszeile steht dann > > "https://meinserver.no-ip.biz/grafana/login"; > > Aber ich bekomme einen Umleitungsfehler, noch nicth die Grafana-Seite > angezeigt. Wie kann ich das debuggen? Wenn ich im Firefox F12 drücke um > zu sehen was passiert, zeigt er ganz oft "302 get..." an, Chrome meldet > "ERR-TOO_MANY_REDIRECTS" Du scheinst genau in den Fehler hineingelaufen zu sein, den "Jemand" schon erwähnt hat: Grafana ist per default nicht darauf ausgelegt, in einem anderen Kontext als dem Root-Kontext / zu laufen, kommt mit Deinem "/grafana" also anscheinend nicht zurecht. Hier [1] steht eine Möglichkeit zur Lösung; eine andere, wie "Jemand" vorgeschlagen hatte, wäre die Nutzung eines eigenen Virtual Host. [1] https://grafana.com/tutorials/run-grafana-behind-a-proxy/#1
Sheeva P. schrieb: > Schau, Du kannst gerne mitreden, wenn Du Dir ein bisschen Ahnung und > Erfahrung mit derlei Technologien (kann auch LXC, Podman oder etwas > anderes in der Richtung sein) zugelegt hast. Bis dahin sind Beiträge wie > Deiner einfach nur peinlich. Wie kann einer in einem Forum, das sich > immerhin mit Mikrocontrollern, Elektronik und Programmierung befaßt, so > fortschritts- und technologiefeindlich eingestellt sein? Na Klar bin ich Technologie feindlich und hab mit Container Technologien noch nie angesehen, warum denn auch? Es ist Ja auch viel einfacher zu sagen, dass jemand einfach nur Peinlich ist, als sich mit der inhaltlichen Kritik auseinander zu setzen. Aber Hey, besser sich denn Gefahren bewusst sein und als Rückgewand gelten als der nächste, Robert Oppenheimer zu werden, die Ehre überlasse ich gerne Dir. Und nur Deine Behauptung zu entkräften, ich kenne Docker,LXC und nspawn, ziemlich gut sogar und ich weiß, dass es durchaus Einsatzszenarien für diese Technologien gibt, aber im Gegensatz zu Dir scheine ich mich auch mit den Downsides dieser Technologien zu befassen.
Ich war wohl etwas zu optimistisch.. jetzt wollte ich Grafana auch mal benutzen. Ich komme bis zu der Stelle, wo man sich angemeldet hat und das Standard-Admin-Kennwort geändert hat. Danach sind nur wenige Symbole auf der Serite und ich kann nichts machen.. es kommen immer Fehlermeldungen. Evtl. liegt es wirklich an dem Unterverzeichnis /grafana, wo es ausgeliefert wird. Jetzt kann ich die anderen Dinge auf dem Server wegbauen oder docker probieren.. - oder hat jemand noch eine andere Idee zum debuggen?
Weitere Tests: auch wenn ich Grafana direkt unter / ausliefere (ohne sub-path), kommen diese Fehler auf. Dann brauche ich docker wohl gar nicht erst zu testen, oder?
Läufts denn wenn du es ganz normal im LAN von dem System aufrufst auf dem es installiert ist? Sascha
Sascha W. schrieb: > Läufts denn wenn du es ganz normal im LAN von dem System aufrufst auf > dem es installiert ist? Ja, dann ist alles schick.
Konfiguriere mal grafana, das es unter http://localhost:3000/grafana/ läuft, und dann passe apache an, dass es /grafana nach http://localhost:3000/grafana weiterleitet (statt nach http://localhost:3000). Dann ist zumindest der Pfad in beiden fällen identisch. Falls das nicht hilft, schau mal im apache access log, und eventuell mit wireshark oder "tcpdump -i lo port 3000" nach, was sich versucht wohin zu verbinden.
ich bekomme jetzt andere Fehler. Ich habe also in der grafana.ini root_url = %(protocol)s://%(domain)s:%(http_port)s/grafana serve_from_sub_path = true und in der apache-Host-Datei (virtualhost 443) ProxyPass "/grafana" "http://localhost:3000/grafana"; ProxyPassReverse "/grafana" "http://localhost:3000/grafana"; Ich sehe die Grafana Oberfläche und 3 leere panel. Wenn ich suche, bietet er mir mein lokal generiertes dashboard an, findet es dann aber nicht (404 page not found), unter sucht unter https://********.no-ip.biz/grafana/grafana/d/vGmwDAoMk/prima-dashboard also einmal sub-Path zuviel.. Echt zum Verzweifeln.. :-(
Vielleicht kann man als ein Workaround etwas mit einem redirect machen:
1 | RewriteEngine on |
2 | RewriteRule "^(/grafana){2,}/(.+)" "/grafana/$2" [R,L] |
Bringt leider nichts. Ich glaube, ich muss doch den Docker-Ansatz versuchen.
Dies sagt die offizielle Doku: https://grafana.com/tutorials/run-grafana-behind-a-proxy/#1 Es ist zwar kein Apache-Beispiel dabei, aber sollte adaptierbar sein. Mit Nginx funzt das jedenfalls.
Grafana schrieb: > Mit Nginx funzt das jedenfalls. aber ich hab nunmal apache.. aber auch da gibt es eine "location"-Anweisung. Macht die etwas anderes als "ProxyPass" / wäre die verwendbar ? Mal angenommen, ich setze docker auf mit NGINX und aus dem docker heraus (lokal) funktioniert alles - hilft mir das? Denn ich habe ja zu Hause, wo der Server läuft, nur eine öffentliche IP, wo der dynDNS drauf zeigt und der port 443 ja schon für den Apachen genutzt wird. Also muss ich ja wieder Reverse Proxy mit Apache machen - warum soll das dann besser funktionieren als siehe oben?
Rudi schrieb: > Grafana schrieb: >> Mit Nginx funzt das jedenfalls. > > aber ich hab nunmal apache.. aber auch da gibt es eine > "location"-Anweisung. Macht die etwas anderes als "ProxyPass" / wäre die > verwendbar ? Nicht das ich wüsste. Vermutlich ist das Problem irgend was komplett unscheinbares/blödes. Versuche mal, bei grafana am Ende von root_url noch den slash hin zu setzen:
1 | root_url = %(protocol)s://%(domain)s:%(http_port)s/grafana/ |
🐧 DPA 🐧 schrieb: > Vermutlich ist das Problem irgend was komplett unscheinbares/blödes. wahrscheinlich. 🐧 DPA 🐧 schrieb: > root_url = %(protocol)s://%(domain)s:%(http_port)s/grafana/ hab ich probiert, ändert nix.
Ich hab mal für Grafama/docker einen extra Thread in "PC hard- und Software" aufgemacht, hat ja nicht direkt mit Programmierung zu tun: Beitrag "Grafana mit docker und Reverse Proxy verstehen"
Grafana schrieb: > Mit Nginx funzt das jedenfalls. Mit Apache sicher auch, wenn man es richtig macht.
Rudi schrieb: > ProxyPass "/grafana" "http://localhost:3000/grafana"; > ProxyPassReverse "/grafana" "http://localhost:3000/grafana"; > > Ich sehe die Grafana Oberfläche und 3 leere panel. Wenn ich suche, > bietet er mir mein lokal generiertes dashboard an, findet es dann aber > nicht (404 page not found), unter sucht unter > > https://********.no-ip.biz/grafana/grafana/d/vGmwDAoMk/prima-dashboard > > also einmal sub-Path zuviel.. Versuch doch mal:
1 | <Location /grafana/> |
2 | ProxyPass "/grafana" "http://localhost:3000/" upgrade=WebSocket retry=20 |
3 | ProxyPassReverse "/grafana" "http://localhost:3000/" |
4 | [...] |
5 | </Location> |
Außerdem Deinen Grafana-Container starten mit "-p 127.0.0.1:3000:3000". Wenn das nicht klappt: könntest Du dann bitte mal den ganzen VirtualHost, Deinen Startbefehl für den Container, und die Logdateien zeigen? Und, ach so: es wäre schön, wenn Du nicht ständig neue Threads starten und bei einem bleiben würdest, den Du gestartet hast. Man weiß gar nicht, wo man antworten soll, und am Ende geht es ja immer um ein und dasselbe Problem.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.