Ich flipp aus. Ich hab tatsächlich dem Peer und dem Server die gleiche interne IP gegeben 
Danke dir GTAzoccer
Die einzige Möglichkeit einen Tunnel über IPv4 und IPv6 aufzubauen ist ein hostname mit A und AAAA -Records, oder?
Edit:
Meine wg0.conf ändert AllowedIPs = 10.0.1.21/32, fd10:10:10::21/128 automatisch zu AllowedIPs = 10.0.1.0/24, fd10:10:10::/64. Warum ist dem so, und soll ich dann gleich letzteres bei jedem Peer angeben?
Edit:
Meine wg0.conf ändert AllowedIPs = 10.0.1.21/32, fd10:10:10::21/128 automatisch zu AllowedIPs = 10.0.1.0/24, fd10:10:10::/64. Warum ist dem so, und soll ich dann gleich letzteres bei jedem Peer angeben?
Das liegt daran weil du "saveconfig = true" gesetzt hast. Ich würde das rausnehmen aus deiner Config.
SaveConfig — if set to `true', the configuration is saved from the current state of the interface upon shutdown. Any changes made to the configuration file before the interface is removed will therefore be overwritten.
Also bei jedem shutdown vom wireguard wird die config überschrieben.
aber welchen usecase hat das wirklich?
Für mich keinen.
Mir genügt es dass ich erfahre DASS was faul ist. Was genau, schau ich mir dann ja eh "vor Ort" an.
Sowas ist m.E. nur für Firmen relevant, die getrennte Technikabteilungen für verschiedene Serverfunktionen haben.
Welche wirklichen Vorteile bringen mir Monitoring-Tools wie checkmk und Netdata gegenüber solchen Leichtgewichten wie munin und Beszel?
Also, mir ist schon bewusst WAS genau sie mehr können, aber welchen usecase hat das wirklich? Wenn wirklich mal live-Daten relevant sind, mache ich das meistens schmerzlos über htop
Für mich im privaten eher keinen. Ich hatte die letzten Jahre Netdata im Einsatz und bin jetzt zu Beszel gewechselt. Netdata hatte jede Menge schöne Diagramme, die man kaum zuordnen konnte 
Beszel läuft auf einem Piko und überwacht alle meine Server. Die wichtigsten Daten sind dabei und reichen mir.
Was mir etwas fehlt ist ein Dashboard, dass alle Server kumuliert anzeigt. Das hatte Netdata und ich fand's immer ganz gut. Kann natürlich jetzt auch an der Gewohnheit liegen. Zudem ist bei Beszel aktuell nur eine Aufzeichnung von max. 30 Tagen möglich.
Was mir etwas fehlt ist ein Dashboard, dass alle Server kumuliert anzeigt. Das hatte Netdata und ich fand's immer ganz gut.
Aber genau das kann doch Beszel super easy und bietet einem für andere Server extra ein fertiges Docker Compose File oder einen einzigen binären Befehl, den man schlicht Copy & Pasten muss.
Aber genau das kann doch Beszel super easy und bietet einem für andere Server extra ein fertiges Docker Compose File oder einen einzigen binären Befehl, den man schlicht Copy & Pasten muss.
Nur ein Dashboard mit den Echtzeitdaten der Server.
Nicht aber, wie bei Netdata, dass du alle Server in den Diagrammen vereint hast. Hierzu musst du jeden einzelnen anwählen und siehst dann die Serverdaten von dem einen Server.
Nicht aber, wie bei Netdata, dass du alle Server in den Diagrammen vereint hast.
Ah ok. Das meinst Du.
Welche wirklichen Vorteile bringen mir Monitoring-Tools wie checkmk und Netdata gegenüber solchen Leichtgewichten wie munin und Beszel?
Also, mir ist schon bewusst WAS genau sie mehr können, aber welchen usecase hat das wirklich? Wenn wirklich mal live-Daten relevant sind, mache ich das meistens schmerzlos über htop
Im Privatbereich bin ich da relativ stumpf, da interessiert mich nur "geht" oder "geht nicht(mehr)"....und da langen mir persönlich die Funktionalitäten von Uptime Kuma.
Und wenn was ist, dann gehe ich auf die Kiste und schaue warum und wieso und weshalb.
Beruflich wäre das eher semi-geil...
Das sind zu viele Clients, zu viele Server, zu viele Services, zu viele Kommunikationsbeziehungen, zu viele Verzahnungen, zu viele dislozierte Standorte, zu viel Blech, zu viele Cluster, zu viel VMs/Container...und und und.
Da will man dann bspw. schon rechtzeitig wissen, wenn irgendwo in Deutschland bei einem Server die Platte anfängt vollzulaufen (aus welchen Gründen auch immer)....oder irgendein Systemdienst meint, er hat jetzt einfach mal keine Lust mehr zu funktionieren.
Natürlich variieren die Relevanzen "WAS" gemonitored wird je nach Fachbereich.
Wer für die Infra verantwortlich ist, hat natürlich andere Interessen am Monitoring als Verantwortlichkeiten für die Funktionalität von Services,etc.
Wir haben auch große Fernseher in den Büros, mit entsprechenden Dashboards um zumindest direkt sehen zu können, ob alles Grün ist oder irgendwas das Mucken anfängt.
Aber der Usecase ergibt sich aus den Anforderungen....privat würde ich mir das nicht mal im Ansatz vorstellen.
Da langt mir eine Mail mit "ACHTUNG! nginx-service nicht mehr erreichbar!"
Der Rest ist dann "IT-Handwerker-Elektrobäcker-Style" am Server wegen dem "Wieso?"
Welche wirklichen Vorteile bringen mir Monitoring-Tools wie checkmk und Netdata gegenüber solchen Leichtgewichten wie munin und Beszel?
Also, mir ist schon bewusst WAS genau sie mehr können, aber welchen usecase hat das wirklich? Wenn wirklich mal live-Daten relevant sind, mache ich das meistens schmerzlos über htop
Ich setze checkmk ein da ich das auch in der Firma betreue.
Und so bei mir im privaten die Updates schon mal vorprüfen kann.
Für mich ist ein Vorteil das checkmk gut und zuverlässig läuft. Und mit der Agent Backery muss ich mich auch 0 um das Updaten, pflegen und Konfigurieren der Agents kümmern.
Das macht alles der checkmk Server. Agent wird installiert, Registriert, Updater registriert und schon kümmert sich der Server drum.
Das acht Spaß.
Aber ja: Eigentlich ist es auch Oversized.
Sollte ich den Arbeitgeber wechseln und dort ist ein z.B. Zabbix im Einsatz, dann würde ich vermutlich auch zu Zabbix wechseln.
Am Ende ist es im Hobbybereich auch immer die Frage: Was will ich damit bezwecken? Und was will ich alles sehen?
Wenn mir ein "Server ist da" reicht: Dan reicht theoretisch ein externer HTTPS Check auf einen Webserver
Ich will und mag mit dem Monitoring aber rumspielen und somit hab ich es halt auch bisschen "komplexer"
Wenn jemanden das reine "Server/service on/Off" reicht, könnt ihr euch auch HetrixTool anschauen. Da braucht ihr selbst nichts hosten. Da ist auch z.b. ein Telegramm Bot vorhanden.
Wenn‘s etwas aus der EU (Frankreich) sein darf, kann ich https://updown.io empfehlen.
Dann bleibe ich bei meinem Munin/Beszel/UptimeKuma - Setup 
Ist wohl ein bekanntes Problem:
https://github.com/invoiceninja/dockerfiles/issues/846
https://github.com/invoiceninja/dockerfiles/issues/842
Um es zu lösen, musst du wie in diesem Kommentar:
https://github.com/invoiceninja/dockerfiles/issues/846#issuecomment-3680878419
die php.ini des Docker-Containers durch eine Custom-php.ini ersetzen, indem du das wie da angegeben, in der docker-compose.yml aktivierst (die "#" entfernst, damit es nicht mehr auskommentiert ist) und die php.ini (mindestens) mit folgendem Inhalt befüllst:
In der .yaml habe ich bereits das php_memory_limit manuell erhöht
Ich kenne zwar Invoice Ninja nicht aber wie kommst Du darauf, dass die environment Variable PHP_MEMORY_LIMIT: 1024M das memory limit automatisch erhöht?
Ich vermute eigentlich verwendet das Image das hier https://github.com/invoiceninj…/debian/debian/Dockerfile
=> würde es mal so angepasst probieren
services:
invoiceninja:
image: invoiceninja/invoiceninja:latest
container_name: invoiceninja
restart: unless-stopped
environment:
APP_URL: https://ninja.netcup.de
DB_TYPE: mysql
DB_HOST: db
DB_PORT: 3306
DB_DATABASE: invoiceninja
DB_USERNAME: ninja
DB_PASSWORD: 123456
volumes:
- ./php-memory.ini:/usr/local/etc/php/conf.d/99-memory-limit.ini
- ninja_data:/var/www/app/public
networks:
- nginx-proxy-networkphp-memory.ini
memory_limit = 1024MErstmal danke euch zweien nitram Das habe ich beim versuch der Problemlösung in einem reddit-post aufgenschnappt.
Ich habe es wie nitram gelöst, es scheint zu funktionieren, allerdings kann sich IN nun wohl nicht in der DB einloggen, obwohl DB, PW, User und network stimmen. Ich schau morgen nochmal genauer hin, eventuell baue ich die gesamte composer noch mal neu. Jetzt erstmal ab in die arbeit.
Aber vielen Dank euch beiden! Guten Rutsch
nitram sudo
Da ich vor meinem VPS 500 G11s leider noch keine netcup-Firewall habe, versuche den Zugriff mit folgendem Setup ausschließlich über meinen wireguard Server (144.208.243.2) zu beschränken:
Auf dem 500 G11s läuft Docker, und alle Dienste werden von Nginx Proxy Manager mithilfe von Proxy Hosts über ein eigenes network durchgeschleust, was für mich bedeutet, dass ich in keiner docker-compose.yml irgendwelche ports öffne. Einzige Ausnahme: In der docker-compose.yml von nginx-proxy-manager gebe ich natürlich die Ports 80 und 443 frei, sonst würde das ganze Setup ja nicht funktionieren:
ports:
- "80:80"
- "443:443"In der ufw habe ich den Zugriff via SSH, HTTP und HTTPS nur für den wireguard Server gestattet. Alle anderen eingehenden Anfragen sollten blockiert werden.
bud@docker:~$ sudo ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), deny (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp ALLOW IN 144.208.243.2
80/tcp ALLOW IN 144.208.243.2
443/tcp ALLOW IN 144.208.243.2
bud@docker:~$ Wenn ich jetzt keinen Denk- oder Wissensfehler habe, sollte der Server und alle darauf laufenden Dienste nur über meinen wireguard Server erreichbar sein - ist das so korrekt? Ich frage so dumm, da docker mich mehr als nur einmal ausgetrickst hat
Edit: Fast vergessen, zusätzlich habe in in Nginx Proxy Manager eine Zugriffsliste angelegt, welche auch ausschließlich nur die IP des wireguard Servers zulässt. Diese ist natürlich für alle Proxy Host aktiv.
ist das hier relevant?
Screenshot 2026-01-01 at 20.33.40.png
