Frage zu influxDB, Grafana und https/letsencrypt

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..

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]

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.

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?

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"