UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[BananaJoe]

@manfredhi Was willst du erreichen, Nextcloud wie bisher und /grafana dann für grafana?
Oder hast du 2 verschiedene xxx.dnshome.de DNS-Namen?

Wenn beides unter einen Namen:

Deaktiviere die Webseite für Grafana wieder.

a2dissite namegrafana.vhost

Die Konfigurationsdatei kopierst du dir dann in das Apache-Conf Verzeichnis, bei mir wäre das

/etc/apache2/conf-available/grafana.conf

bzw. erstellst diese Datei dort dort
Bei der Grafana-Konfiguration fehlt das Alias /grafana im https Teil, den ServerName lässt du dafür weg.
Inhalt müsste so sein:

Alias /grafana /var/www
ProxyPreserveHost On
ProxyPass / http://192.168.0.23:3000/
ProxyPassReverse / http://192.168.0.23:3000/

Speichern und mit

a2enconf grafana

Aktieren.

Nextcloud: da nimmst du die Alias-Zeile wieder raus bzw. machst alles wieder so wie vorher wie es ging.

Und den Apache neu starten / reloaden.
Die notwendigen Module hast du aktiviert nehme ich an (sonst würde SSL und rewrite ja nicht gehen)

Dann sollte Nextcloud funktionieren wie vorher, wenn du an die Domäne direkt ein /grafana anhängst sollte Grafana kommen.

Bei mir habe ich das gerade getestet und das klappt.

Über die .conf Variante gilt das global, du kannst 20 verschiedenen Webseiten auf deinem Server hosten und überall ein /grafana anhängen und die Seite kommt.

Zufällig habe ich heute an meinem Webserver gearbeitet und da war mir aufgefallen das /phpmyadmin auch auf jeder Webseite funktionierte, da habe ich mir das gerade abgeschaut.
Das der Alias nach /var/www zeigt ist nur ein Hilfskonstrukt, der Proxy-Aufruf leitet ja alles nach dem / um. Und der / gilt nach dem Alias /grafana, deshlab muss/darf das da nicht noch einmal stehen.

[ManfredHi]

@bananajoe sagte in Grafana von extern erreichbar machen:

Die Konfigurationsdatei kopierst du dir dann in das Apache-Conf Verzeichnis, bei mir wäre das

bei mir war die bestehende nextcloud.conf unter /etc/apache2/sites-available
dort habe ich auch die grafana.conf angelegt.

Soll ich diese dort nun löschen und unter /etc/apache2/conf-available anlegen? Dort sind bei mir derzeit ganz andere conf dateien.

[ManfredHi]

@bananajoe

ok nextcloud funktioniert wieder wie vorher.

allerdings mit grafana klappt es nicht, da dürfte ich noch irgendwas falsch machen.
es kommt beim aufruf immer der hinweis von nextcloud dass diese seite nicht vorhanden ist.

[BananaJoe]

@manfredhi sagte in Grafana von extern erreichbar machen:
vergiss es, das klappt nicht, mein Browsercache hat mich auf das Glatteis geführt

[BananaJoe]

es könnte sein das es nicht funktioniert mit Nextcloud wegen dessen .htaccess-Dateien
2 verschiedene Domänennamen können es nicht sein? Falls du eine Domäne hast würden auch CNAME-Einträge gehen

[ManfredHi]

@bananajoe sagte in Grafana von extern erreichbar machen:

es könnte sein das es nicht funktioniert mit Nextcloud wegen dessen .htaccess-Dateien
2 verschiedene Domänennamen können es nicht sein? Falls du eine Domäne hast würden auch CNAME-Einträge gehen

du meinst eine zweite dyndns adresse ? soll ich dazu einen eigene LXC-Container im Proxmox erstellen der nur für das reverse proxy ist oder gehen zwei adressen mit letsencrypt auch auf dem nextcloud-server ?

oder soll ich den zweiten dyndns gleich direkt am grafana-server einrichten? und dort dann auch letsenrypt installieren?

[BananaJoe]

@manfredhi also, zum Verständnis

Ich habe eine VM (aka LXC-Container) mit dem Apache Reverse Proxy.
Port 80 und 443 der FritzBox sind auf diesen weitergleitet.

Darauf läuft bei mir eine Apache-vHost Konfiguration https://httpd.apache.org/docs/2.4/vhosts/examples.html
Also jede Webseite hat bei mir eine eigene .vhost Datei unterhalb von

/etc/apache2/sites-available/

Die sehen immer so aus:

<VirtualHost *:80>
               ServerName zabbix.znil.net
               ServerAdmin webmaster@zabbix.znil.net
               RewriteEngine On
               RewriteCond %{HTTPS} !=on
               RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]
</VirtualHost>
 
<VirtualHost *:443>
               ServerName zabbix.znil.net
               ServerAdmin webmaster@zabbix.znil.net

               SSLEngine on
               SSLCertificateFile /var/www/clients/client0/web7/ssl/zabbix.znil.net.crt
               SSLCertificateKeyFile /var/www/clients/client0/web7/ssl/zabbix.znil.net.key

               ProxyPass / http://192.168.200.15/
               ProxyPassReverse / http://192.168.200.15/
</VirtualHost>

In jeder Datei steht ein anderer ServerName.
Je nachdem mit welchen DNS-Namen ich ankomme, weis der Apache welche Datei/Konfiguration gilt.

Nun habe ich bei IONOS ein paar Domänen, eine würde reichen, und habe für alles was ich hinter dem Proxy verstecken will jeweils eine Subdomäne erstellt:

nextcloud.znilz.net
seafile.znilz.net
zabbix.znilz.net
grafana.znilz.net
...

Die DNS-Einträge dieser Subdomänen zeigen auf meine externe IP-Adresse der FritzBox.
Also ein A-Record bei IPv4 und/oder ein AAAA-Record bei IPv6.
Das geht natürlich nur wenn man entweder

• eine feste IP-Adresse hat
• oder den DNS-Eintrag bei jeder Änderung beim Hoster aktualisiert, z.B. per Skript.

Die Alternative:

• Du hast eine DynDNS-Eintrag. Ob nun xxx.dnshome.de oder cxsuahcuasbcuasbc.myfritz.net ist egal
• Für die Subdomänen erstellst du statt eine A-Records einen CNAME-Eintrag der auf den DynDNS-Namen zeigt.
  Dann wird bei einem Aufruf zwar auf die DynDNS-Adresse umgeleitet, aber der DNS-Name bleibt erhalten und wird auch so dem Apache gemeldet.

Eigentlich müsste es auch mit den Alias gehen, aber Nextcloud nutzt massiv die .htaccess-Dateien und ich vermute es liegt daran. Bei einer harmlosen Webseite funktioniert das jedenfalls

[ManfredHi]

@bananajoe

ok, danke für die ausführliche Erklärung. Ich hab mir jetzt mal eine zweite adresse bei dnshome registriert. Dort habe ich die IP-Adresse der FritzBox als A-Record und als AAAA-Record eingetragen.
die bisherige: xxxxx.dnshome.de
die neue: xxxxx.dnshome.at
bei beiden geht der ping nun auf die externe IP-Adresse meiner FritzBox (hat ne fixe IP)

Den Rest muss ich mir morgen bzw. am Wochenende dann mal genau anschauen, was du da geschrieben hast. Mir ist das mit den .vhost Dateien nicht klar. Bisher hatte ich immer .conf Dateien. Heißen diese nun z.B.

/etc/apache2/sites-available/nextcloud.vhost
/etc/apache2/sites-available/grafana.vhost

die ionos-Domänen brauch ich dann ja nicht oder?

Danke vorerst mal für Deine Hilfe. Werd mich dann wieder melden wenn ich wo nicht weiterkomme.

Ergänzung:
Hab gerade gesehen, dass ich ja eh einen IONOS-Account mit einer Domain habe. Habe dort jetzt A-Records und AAAA-Records eingetragen für nextcloud und grafana. Diese zeigen nun auf die externe IP-meiner FritzBox.

[OliverIO]

@manfredhi

und das hier bitte auch lesen
https://grafana.com/docs/grafana/latest/setup-grafana/configure-security/
trotz anmeldung ist deine installation angreifbar
daher dafür sorgen, das man vom grafana server nicht weiter ins netz kommt und diesen rechner am besten über firewall regeln abschotten.
möglichst alle komfort tools zur rechner und netzwerk analyse entfernen.
daher bietet sich da immer auch ein docker container an, da das im image enthaltene betriebssystem so minimal ist, das gerade zum betreiben der applikation ausreicht.
falls da mal ein ungebetener gast drin ist, kommt er nicht mehr weiter

[ManfredHi]

@oliverio sagte in Grafana von extern erreichbar machen:

daher bietet sich da immer auch ein docker container an, da das im image enthaltene betriebssystem so minimal ist, das gerade zum betreiben der applikation ausreicht.
falls da mal ein ungebetener gast drin ist, kommt er nicht mehr weiter

meinst du ich soll unter proxmox eine vm mit einem docker container einrichten und darin grafana installieren? wo dann den reverse proxy? hab ich dann zugriff vom internen netz so wie bisher oder funktioniert dann da auch etwas nicht mehr?

sorry, aber momentan versteh ich bei dem ganzen nur bahnhof.

[OliverIO]

@manfredhi
Ja, aber wenn du sonst keine Anwendung für docker hast, reicht auch nur die vm. Dann aber wirklich nur eine minimalinstallation
Und ggfs unnötige Tools entfernen.
Docker hat halt den Vorteil, das man dort unabhängig von ssh eine console öffnen kann. Gegenüber ssh ist der Vorteil das man ssh auch aus dem Container heraus nicht nutzen kann.

Hier mal eine Meinung dazu aus dem Internet.
Alpine kommt mittlerweile sehr oft in den docker Container vor, kann aber auch direkt installiert werden. Hat glaube ich nur 85MB. Super minimal. Alles was man benötigt muss dazu installiert werden.

As of my last knowledge update in September 2021, there are several Linux distributions known for their focus on security and suitability for web servers. Here are some popular hardened Linux distributions that are often recommended for web servers with a high priority on security:

Qubes OS: While not a typical choice for web servers, Qubes OS is a security-focused operating system that uses virtualization to compartmentalize applications. This can provide a high level of security, but it may not be as straightforward to set up and maintain as other options.
Alpine Linux: Alpine Linux is known for its small size, simplicity, and security focus. It is commonly used in containerized environments, making it a good choice for hosting web applications in lightweight, secure containers.
OpenBSD: OpenBSD is a Unix-like operating system known for its security features and proactive approach to security auditing. While it may not be as widely used as some other Linux distributions, it has a strong reputation for security.
Hardened Gentoo: Gentoo Linux is a source-based distribution that allows for a high degree of customization. Hardened Gentoo includes additional security features and hardening options that can help improve the security of the system.
Tails: Tails is a privacy-focused Linux distribution that is designed to be booted as a live system from a USB stick. While it is not typically used for web servers, it can be a good choice for accessing the web anonymously and securely.
It's important to note that the best Linux distribution for a web server with a high priority on security can depend on various factors, including your specific security requirements, familiarity with the distribution, and the level of support available. It's a good idea to thoroughly research and test any distribution before deploying it in a production environment. Additionally, staying up to date with the latest security patches and best practices is crucial for maintaining a secure web server.