Forum: PC Hard- und Software Grafana mit docker und Reverse Proxy verstehen


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
guten Montag,

ich möchte einen neuen Versuch starten, Grafana mit als Reverse Proxy 
auf meinem existierenden Webserver (apache2, letsencrypt) korrekt zum 
Laufen zu bekommen.

Dazu möchte ich der Empfehlung folgen hier aus dem Forum, Grafana in 
einem Docker-Image zu betreiben und dazu dieses vorbereitete Image zu 
benutzen:

https://github.com/nginx-proxy/docker-letsencrypt-nginx-proxy-companion

Ich habe also docker installiert und getestet wie hier beschrieben:

https://www.codeflow.site/de/article/how-to-install-and-use-docker-on-debian-10

Jetzt zu den Fragen: Mein Webserver läuft ja und verwendet Port 80 und 
443.
Wenn ich jetzt den Container laufen lasse, um die Lets 
encrypt-Zertifikate zu erzeugen, brauche ich die gleichen Ports. Ich 
habe aber nur einen externen dynDNS-Namen, und für letsencrypt muss der 
DNS sauber auflösen.

? wird da letsEncrypt nicht merken, dass es da schon ein Zertifikat 
gibt, und durcheinanderkommen ?

? Muss ich also solange, wie ich die Zertifikate für den Container 
mache,  meinen Webserver runterfahren?

? wenn ich die Zertifikate dann habe und nur noch Port 3000 für Grafana 
aus dem Container brauche, wird die automatisch Erneuerung ohne Port 80 
und 443 funktionieren?

? brauche ich für Grafana überhaupt ein extra Zertifikat, wenn es doch 
später auf meinem Webserver als reverse Proxy eingerichtet werden soll 
und der schon ein Zertifikat hat?

von Andreas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rudi schrieb:
> ? brauche ich für Grafana überhaupt ein extra Zertifikat, wenn es doch
> später auf meinem Webserver als reverse Proxy eingerichtet werden soll

Nein, brauchst du nicht, falls du nicht die Verbindung zwischen Proxy 
und Grafana auch verschluesseln und authentifizieren willst (unnoetig 
wenn das auf dem selben Rechner laeuft). Also musst du dich nur um das 
Zertifikat fuer nginx kuemmern.

von Rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Also Grafana braucht kein Zertifikat, danke. Apache/NGINX habe ich nicht 
gut erklärt, mein Setup sähe so aus:
1
(Internet)
2
   v ^
3
(Apache Webserver mit Domainnamen und gültigen Zertifikat)
4
   v ^          v ^         v ^
5
/Wordpress    /Owncloud    /docker als reverse proxy
6
                            v ^
7
                            Grafana (localhost:3000)

Somit reicht das (vorhandene) apache-Zertifikat, habe ich verstanden, 
richtig?

von reverse proxy (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
Junge, stell dich auf ein Abenteuer bereit. Durch dieses Tal bin ich 
schon gelaufen - ist wirklich tricky. Ist leider schon ein wenig her, 
sonst würde ich dir mehr sagen können. Ich weiß nur noch, ohne reverse 
proxy geht es nicht. Und du brauchst eine Portweiterleitung. Und ein 
selbsterstelltes Zertifikat bringt auch Probleme (apache). Ich versuch 
mich mal an mehr zu errrinern :)

von Rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
reverse proxy schrieb:
> Und ein
> selbsterstelltes Zertifikat bringt auch Probleme (apache). Ich versuch
> mich mal an mehr zu errrinern :)

Ja versuch mal :) Das Zertifikat ist aber nicht selbst erstellt, sondern 
von Let's encrypt.

von Andreas (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rudi schrieb:
> Somit reicht das (vorhandene) apache-Zertifikat, habe ich verstanden,
> richtig?

Richtig.

nginx sehe ich da nirgendwo, ist aber auch nicht noetig wenn du Apache 
als reverse proxy verwenden moechtest.

Wenn du einen funktionierenden Apache mit SSL hast ist alles was du 
brauchst nun also Grafana in einem Docker-Container, wo du den internen 
Grafana-Port des Containers (z.B. 3000) an einen beliebigen Port von 
localhost (z.B. 1234) bindest (`-p 127.0.0.1:1234:3000`). Dann richtest 
du in Apache einen reverse proxy von `/foobar/*` auf 
`http://127.0.0.1:1234/` ein (damit kenne ich mich nicht aus, bei nginx 
koennte ich helfen).

von hört sich gut an (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Andreas ist auf ner guten Spur, wenn du keinen docker swarm oder anderes 
load-balancing hast - passt das, ansonsten musst du irgendwie die ports 
hochzählen (odern Bereich angeben). Man wenn mein Hirn nicht so löchrig 
wäre...

von Rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ah gut, dann werde ich mir also einen Container suchen mit einem 
mini-headless-debian, und mal schauen, wie sich da Grafana so macht.

von hört sich gut an (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Klingt nach einem Plan, aber den reverse proxy brauchst du definitiv - 
ansonsten gibt es cross-domain errors im Browser. Auch wird da dein 
selbsterstelltes Zertifikat als nicht sicher angezeigt werden...

von hört sich gut an (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Und dokumentiere jeden Schritt (am besten bau die ein Buildskript, das 
deine Anwendung ausrollen kann [Also docker container neu bauen, starten 
etc.].
Ich denke den Entwickler-Modus im Browser kennst du? ;)

Viel Erfolg!

von Rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
So, jetzt hab ich ein debian image heruntergladen und die 
Grafana-Installationsschritte ausgeführt. Jetzt muss ich lesen, wie ich 
im Docker den Grafana-Service starte und am Leben erhalte. Das brauche 
ich ja noch nicht zu dokumentieren, oder?

von Andreas (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Wieso verwendest du nicht das existierende Grafana Docker-Image? 
https://grafana.com/docs/grafana/latest/installation/docker/
Nutzdaten/Konfiguration kannst du mit einem Volume (`-v`) ausserhalb des 
Containers speichern.

von hört sich gut an (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Doch! Wenn du es richtig professionell machen willst - ist der erste 
Schritt eine frische virtuelle Maschine zu booten und nur hier deine 
Entwicklung stattfinden zu lassen. Damit umgehst du mögliche 
Nebeneffekte, die jetzt oder später auftretten können und die sehr viel 
Zeit beim Debuggen kosten.
Somit bist du isoliert. Dann schreibst du dir ein script, das dir die 
Docker-Umgebung in der VM installiert (Docker ist meistens schon da). 
Das Host-Netzwerk musst du unbedingt mit der VM teilen, ansonsten baust 
du dir eine weitere Hürde ein. Jetzt nehm am besten einen fertigen 
grafana docker container (erspart einiges) und bau dir (damit) ein 
Docker-Build script. Dann grafana docker container starten (mit 
"run"..."). Jetzt sollte sich der Dockercontainer aus dem Cache bauen 
lassen. Dann vom Host prüfen ob erreichbar (http und https). Wenn du 
soweit bist, kannst du deinen "Startpunkt" für die weitere Entwicklung 
jederzeit wiederherstellen und zwar ganz frisch. Wenn du soweit bist, 
meld dich nochmal. Viel Erfolg.

von hört sich gut an (Gast)


Bewertung
0 lesenswert
nicht lesenswert
PS. Was für einen Internetprovider hast du? Bei vodafone und unitymedia 
wirst du von "außen" keine Verbindung aufbauen können -> shared ip v6...

von hört sich gut an (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
P.P.S: Ach, obacht mit Datenbanken und Docker. Beendest du den 
Dockercontainer ist die Datenbank futsch. Das zu umgehen, muss die 
Datenbankdatei im Dateisystem der virtuellen Maschine leben (wie oben 
erwähnt) und beim Starten des Containers mit -v der Pfad zum Ordner mit 
der DB angegeben werden.

von Rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
hört sich gut an schrieb:
> Bei vodafone und unitymedia
> wirst du von "außen" keine Verbindung aufbauen können

Mein Webserver s.o. ist ja schon von außen erreichbar..

hört sich gut an schrieb:
> Beendest du den
> Dockercontainer ist die Datenbank futsch.

ist ja seltsam. Aber das Problem stellt sich nicht, DB ist influx und 
läuft direkt auf dem Server (uns sammelt nebenbei fleißig weiter 
Sensordaten)

Andreas schrieb:
> Wieso verwendest du nicht das existierende Grafana Docker-Image?

Weil ich nicht wusste, dass es das gibt. Ich hab noch nicht mal 
rausbekommen, wir ich nur ein ganz kleines Debian (slim) ziehen kann.. 
Und da sind auch sicher E-Nummern drin :)

von Rudi (Gast)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Also das "fertige" Grafana-Image "aus der Dose" geht schneller. Habe es 
heruntergeladen und gestartet wie hier beschrieben, und dann 2 kleine 
Namen verändert, damit man sieht dass es dieses ist.

https://grafana.com/docs/grafana/latest/installation/docker/

Wenn ich jetzt im LAN auf <Server-IP>:3000 gucke, sehe ich die 
Grafana-Instanz. (siehe Anlage) So weit so gut.

Jetzt versuche ich es wieder mit reverse proxy. Wenn es funktioniert, 
müsste es ja dann unter der URL https://********.no-ip.biz/grafana 
genauso aussehen, oder?

von hört sich gut an (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>Jetzt versuche ich es wieder mit reverse proxy. Wenn es funktioniert,
>müsste es ja dann unter der URL https://********.no-ip.biz/grafana
>genauso aussehen, oder?

So ist es. htaccess bzw. die apache config kennst du? Da wirst du 
mindestens zwei Einträge hinzufügen müssen. Einmal für http (80) und 
einmal für https(443). Weiterleitung von www. nicht vergessen. Du willst 
das alle anfragen die mit "www." beginnen beschnitten werden -> damit du 
die weitere Konfiguration nur für eine Konstellation machen musst. Und 
du willst das alle http anfragen nach https "weitergeleitet werden".

VG JOnas

von hört sich gut an (Gast)


Bewertung
0 lesenswert
nicht lesenswert
>> Beendest du den
>> Dockercontainer ist die Datenbank futsch.

>ist ja seltsam.

Eigentlich nicht, überleg mal, wenn du die Datenbank im gleichen 
Container laufen lässt - hast du gegenüber eines klassischen Webservers 
keinen Vorteil. Der kommt ja gerade dadurch, das du Frontend und 
Datenbank trennst. Hat den Vorteil, das du nach Bedarf Frontend 
Instanzen erzeugen und beenden lassen kannst (load balancing -> docker 
swarm bzw. kubernetes) und das auf verschiedenen Maschinen. Heißt du 
hast nicht mehr das Problem, wenn deine klassische Webanwendung selbst 
auf dem größten besten Server nur noch bescheiden läuft, du nichts mehr 
über bessere Hardware verbessern kannst. Also eine monolithische 
Anwendung auf Anschlag, geht schneller als man glaubt ->gerade wenn der 
User größere Datenmengen verarbeiten lassen kann.

Noch was, git kennst du? Wenn nicht, musst du dir auf jeden Fall 
anschauen.

Schau mal, hier alles erklärt:

https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Rudi schrieb:
> Jetzt zu den Fragen: Mein Webserver läuft ja und verwendet Port 80 und
> 443.

Nunja, wenn Dein Webserver nicht in einem Docker-Container läuft, den Du 
ebenfalls hinter den Nginx Reverse Proxy vom Letsencrypt-Companion 
klemmen kannst, wird das so leider nicht gehen -- es sei denn, Du hast 
eine zweite IP-Adresse auf dem System, an die Du die Ports 80/http und 
443/https des Letsencrypt-Companion binden kannst.

Andernfalls kannst Du den Letsencrypt-Companion weglassen, den 
vorhandenen Webserver als Reverse Proxy einrichten und Grafana dennoch 
in einem Docker-Container betreiben.  Dazu kannst Du Port 3000 (den 
Grafana standardmäßig benutzt) des Grafana-Containers auf localhost 
(127.0.0.1) publizieren, und Deinen vorhandenen Webserver als Reverse 
Proxy auf http://localhost:3000 konfigurieren.

Vielleicht ist es allerdings einfacher, den vorhandenen Webserver in 
einen eigenen Container zu packen und ihn ebenfalls hinter 
Letsencrypt-Companion zu betreiben. Das Schöne am Letsencrypt-Companion 
ist, daß er sich vollautomatisch um die Zertifikate kümmert, sobald ein 
Container mit den richtigen Umgebungsvariablen (VIRTUAL_HOST und 
LETSENCRYPT_HOST) gestartet wird.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Rudi schrieb:
> Ah gut, dann werde ich mir also einen Container suchen mit einem
> mini-headless-debian, und mal schauen, wie sich da Grafana so macht.

Grafana selbst stellt zwei offizielle Docker-Images bereit, einen auf 
Basis von Alpine Linux und einen auf Basis von Ubuntu. Einfach
1
docker run --name grafana --detach --publish 127.0.0.1:3000:3000 grafana/grafana

eingeben, das wird: das offizielle Grafana-Alpine-Image 
(grafana/grafana) aus dem Docker-Hub laden, in den lokalen Docker-Daemon 
importieren, dann einen Container namens grafana aus dem Image erstellen 
und den Container starten, und dabei Port 3000 an die IP-Adresse 
127.0.0.1 (localhost) binden. Wenn Du dann in die Adreßzeile Deines 
Browsers "http://localhost:3000/"; eingibst und Dich mit admin:admin 
einloggst, wirst Du nach einem neuen Paßwort gefragt und kannst dann 
sofort loslegen.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
hört sich gut an schrieb:
> P.P.S: Ach, obacht mit Datenbanken und Docker. Beendest du den
> Dockercontainer ist die Datenbank futsch.

Nein. Die Datenbank bleibt bestehen, wenn Du den Container nur beendest 
und wieder startest. Die Datenbank ist nur dann "futsch", wenn Du den 
Container zerstörst und neubaust, ohne ihr Datenverzeichnis auf ein 
Volume oder einen Mount gelegt zu haben.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Rudi schrieb:
> hört sich gut an schrieb:
>> Beendest du den
>> Dockercontainer ist die Datenbank futsch.
>
> ist ja seltsam. Aber das Problem stellt sich nicht, DB ist influx und
> läuft direkt auf dem Server (uns sammelt nebenbei fleißig weiter
> Sensordaten)

Tu' Dir bitte den Gefallen und hör' nicht auf das, was "hört sich gut 
an" sagt. Er scheint nicht sonderlich tief in der Materie zu sein, 
vorsichtig gesagt.

> Weil ich nicht wusste, dass es das gibt.

Es gibt heute ziemlich wenig, das es nicht als fertiges Docker-Image 
gibt.

> Ich hab noch nicht mal
> rausbekommen, wir ich nur ein ganz kleines Debian (slim) ziehen kann..
1
docker pull debian:10-slim

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Rudi schrieb:
> Jetzt versuche ich es wieder mit reverse proxy. Wenn es funktioniert,
> müsste es ja dann unter der URL https://********.no-ip.biz/grafana
> genauso aussehen, oder?

Das... kommt darauf an. Ich weiß nicht, wie das bei Grafana ist, aber 
vermutlich mußt Du Grafana noch mitteilen, daß es unter dem URL /grafana 
anstatt unter / laufen soll,  sonst können Redirects und das Nachladen 
von Assets (Grafiken, CSS, JS) fehlschlagen. Du kannst dem 
Docker-Container aber die Umgebungsvariable GF_SERVER_ROOT_URL mit dem 
Inhalt "https://********.no-ip.biz/grafana"; setzen, dann sollte das 
klappen.

von hört sich nicht mehr so gut an (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
>Tu' Dir bitte den Gefallen und hör' nicht auf das, was "hört sich gut
>an" sagt. Er scheint nicht sonderlich tief in der Materie zu sein,
>vorsichtig gesagt.

Ich wollt nur helfen und hab sofort klar gemacht, dass das nur 
gefährliches Halbwissen ist, weil schon ne ganze Weile her und ich 
tatsächlich lange was ganz anderes entwickel. Und nur weil ich mal Image 
schreibe wenn ich Container meine.

>Es gibt heute ziemlich wenig, das es nicht als fertiges Docker-Image
>gibt.

Da wäre ich allerdings tatsächlich vorsichtig. Denn ein offizielles 
Image z.B. von Ubuntu ist relativ sicher frei von Schadsoftware, ein 
Docker Image das irgendwer irgendwo zusammmengebaut hat und rekursiv 
weitere Images von sonstwo lädt...hm. Aber wer benutzt schon docker 
Images, die nicht vom Hersteller kommen. "Achso, eh was fürn Ocker? Nee 
Container machen wir hier nicht". Aber hey, da die Container ja isoliert 
laufen... oh wobei da ist ja noch die persistente Datenbank und der 
Process der Docker ausführt hat (alte docker version musste sogar als 
sudo ausgeführt werden) hat auch noch Schreibrechte...

Sowas würde man ja nie produktiv einsetzen, ne? Da wird jede 
Abhängigkeit geprüft, klar natürlich auch im Frontend-Code der fleißig 
npm einsetzt.
Also immer Obacht, Glotzen uff und Attenzione.
Bleibt gesund, ich hoffe eure sämtliche Hardware überhitzt.

von Sheeva P. (sheevaplug)


Bewertung
1 lesenswert
nicht lesenswert
hört sich nicht mehr so gut an schrieb:
>>Es gibt heute ziemlich wenig, das es nicht als fertiges Docker-Image
>>gibt.
>
> Da wäre ich allerdings tatsächlich vorsichtig. Denn ein offizielles
> Image z.B. von Ubuntu ist relativ sicher frei von Schadsoftware, ein
> Docker Image das irgendwer irgendwo zusammmengebaut hat und rekursiv
> weitere Images von sonstwo lädt...hm.

Ach, immer diese Unkenrufe. Ja, wer IT-Infrastrukturen betreibt, braucht 
Umsicht und Sorgfalt, ganz unabhängig davon, ob der Betrieb klassisch 
auf dem Blech, in VMs oder in Containern stattfindet. Aber bei Blech und 
VMs kommen die Unkenrufe nie.

Warum eigentlich nicht? Containerisierte Anwendungen sind viel 
einfacher, schneller, und risikoloser zu aktualisieren als manuell 
installierte. Aktualisierungen sind so einfach, daß es mit Watchtower 
[1] sogar eine automatisierte Lösung dafür gibt. Und wo die Anwendung 
geschäftskritisch ist und nach der Inbetriebnahme einen Schluckauf 
bekommt? Kein Problem, das alte Image ist ja noch vorhanden und wird 
dann einfach benutzt, bis der Fehler behoben ist. Yay!

Andererseits gibt es bis heute eine Vielzahl von Servern und VMs, auf 
denen auf ganz klassische Weise veraltete Software betrieben wird. Zwei 
Monate, bevor Ende 2018 der Support für PHP in der Version 5 eingestellt 
wurde, liefen laut W3Techs immer noch knappe 62% der PHP-Seiten auf, 
genau, PHP5. Sogar heute, fast zwei Jahre nach Ende des Supports, sind 
es immer noch über 32% [2]. Darüber redet aber niemand, genau wie über 
die Massen an veralteten Installationen von Typo3, Wordpress, Drupal, 
Magento, OS-Commerce, XT-Commerce, und wie sie alle heißen.

Aber immer, wenn die Rede auf Containertechnologien kommt, poppen sie 
jedesmal auf, die Unken, und rufen "aber die Sicherheit, aber die 
Sicherheit". Es ist super, daß ich nicht der Einzige bin, der sich 
Gedanken über Sicherheit macht. Aber das ist nicht auf Container 
beschränkt, und so frage ich mich: was soll der Quatsch?

Zumal für etwa 90% der mir bekannten Webserver-Installationen weder ein 
sauberes Staging noch ein automatisiertes Deployment vorhanden sind, 
erst Recht keines mit einer vernünftigen Möglichkeit für ein Rollback. 
Genau deswegen trauen sich viele Betreiber nicht, ihre Software zu 
aktualisieren: "never change a running system", sie haben Angst, daß 
etwas kaputt geht. "Meine Software läuft ja", höre ich dann, und, sowas 
wurde mir letztens sogar hier im Forum erklärt: "in meinen Server ist 
noch niemals jemand eingebrochen". Ich denk' dann immer "bis jetzt"...


[1] https://github.com/containrrr/watchtower
[2] https://w3techs.com/technologies/details/pl-php/5

von Rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jetzt bin ich mit Docker soweit - Grafana läuft als Container auf meinem 
Webserver, der heißt bei mir intern "h2server". Lokal ist alles schick, 
ich kann also in meinem Lan aufrufen:

h2server:3001/grafana

und er fragt nach dem login und liefert mir dann mein test-dashboard 
unter dieser URL:

h2server:3001/grafana/d/ZiTcVOAMz/plopp?orgId=1

Für den Container habe ich ein storage-volume erstellt, und ich starte 
ihn so:
1
docker run -d \
2
  -p 3001:3000 \
3
   --name=grafana5 \
4
  -e "GF_SERVER_ROOT_URL=https://********.no-ip.biz/grafana" \
5
  -e "GF_SERVER_SERVE_FROM_SUB_PATH=true" \
6
  -v grafana-storage:/var/lib/grafana \
7
  grafana/grafana

**************
Nun wieder zum Reverse Proxy mit apache: Es funktioniert mit Chrome, 
aber nicht mit Firefox (evtl. war das mein ursprüngliches Problem auch). 
Es erscheinen in der Addresszeile 2 unterschiedliche URLs nach dem login 
- warum / woran kann das nun wieder liegen?


chrome:
https://********.no-ip.biz/grafana/?orgId=1
firefox:
https://********.no-ip.biz/grafana/?orgId=

meine 000-default-ssl-le.conf sieht so aus;
1
<IfModule mod_ssl.c>
2
<VirtualHost *:443>
3
4
  ServerAdmin webmaster@localhost
5
  DocumentRoot /var/www/html
6
7
  ErrorLog ${APACHE_LOG_DIR}/error.log
8
  CustomLog ${APACHE_LOG_DIR}/access.log combined
9
10
  #LogLevel debug
11
12
  ServerName ********.no-ip.biz
13
  SSLCertificateFile /etc/letsencrypt/live/********.no-ip.biz/fullchain.pem
14
  SSLCertificateKeyFile /etc/letsencrypt/live/********.no-ip.biz/privkey.pem
15
  Include /etc/letsencrypt/options-ssl-apache.conf
16
17
  Header always set X-XSS-Protection "1; mode=block"
18
  Header always set x-Frame-Options "SAMEORIGIN"
19
  Header always set X-Content-Type-Options "nosniff"
20
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
21
  # next line caused login refresh every 5 sec, so changed to overnext
22
  #Header always set Content-Security-Policy "default-src 'none'; img-src 'self'; script-src 'self'; style-src 'self'"
23
  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 'self' data:; media-src *; connect-src *"
24
  Header always set Referrer-Policy "strict-origin"
25
26
27
  #grafana
28
        ProxyRequests Off
29
        ProxyPass "/grafana" "http://127.0.0.1:3001"
30
        ProxyPassReverse "/grafana" "http://127.0.0.1:3001"
31
32
  #influx
33
  ProxyPass "/influx" "http://localhost:8086"
34
        ProxyPassReverse "/influx" "http://localhost:8086"
35
36
37
</VirtualHost>
38
</IfModule>

von Rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Kommando zurück - der reverse Proxy funktioniert nicht außerhalb von 
meinem LAN. Gibt es noch etwas anderes in der Apache-Konfiguration, was 
ich beachten müsste? Oder wie kann ich noch debuggen?

Ich hab im Pfad, den der Browser anzeigt nach Aufruf der URL, immer 
einmal /grafana zuviel, also

aufgerufen wird
https://********.no-ip.biz/grafana

und angezeigt wird daraufhin

https://********.no-ip.biz/grafana/grafana/d/DpRVfdAGk/plopp
Page not found (404 error)

Aber das Zertifikat wird als sicher angezeigt und das Grafana meldet 
sich, also so ein bisschen Reverse Proxy funktioniert schon..?

von Rudi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke, ich habe es herausgefunden: Diese Header-Zeile (für die 
owncloud-Sicherheit) war das Problem:
1
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 'self' data:; media-src *; connect-src *"

kann ich die für Owncloud weiter gelten lassen, aber für den Grafana 
Reverse Proxy nicht? (Datei komplett siehe oben)

von Johannes S. (jojos)


Bewertung
0 lesenswert
nicht lesenswert
Benutzt hier auch jemand Proxmox VE? Habe ich dieses WE installiert und 
das  scheint auch eine Lösung für die Wünsche des TO zu sein. Man kann 
sehr einfach Container oder VM für getrennte Server auf einem Rechner 
anlegen, für so Standard Software gibt es turnkey templates die mit 
wenigen Klicks und Einstellungen zum Server werden. Alles über ein 
Webinterface zu administrieren.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.