HomeLab

[plang.pl]

Ich habe mir eine Subdomain bei DDNSS.de gesichert. Zuerst war ich bei FreeDNS unterwegs. Da scheint aber im kostenlosen Account kein WildCard DNS möglich zu sein. Das brauche ich zwar eigentlich nicht, da ich alles nur intern nutze. Aber falls ich später mal von extern zugreifen will, möchte ich mir diese Option offen halten. Außerdem schaut DDNSS deutlich moderner aus.
acme.sh ist auch eingerichtet und läuft. Erstes Zertifikat wurde bereits gezogen und liegt im Docker-Unterordner. Also alles gut. Das erste manuelle Abholen des Zertifikats schlug fehl. Das zweite klappte dann allerdings. Keine Ahnung, warum es das erste Mal nicht hingehauen hat. Is mir aber auch egal
NGINX Proxy Manager (jc21/nginx-proxy-manager:latest) läuft auch (auf der gleichen VM). Nun die Quizfrage: Wie bekomme ich das Zertifikat, das im acme-Ordner liegt, darin eingebunden?
Ich habe bereits versucht, den acme Ordner auch in NGINX zu mounten. Aber ich scheitere daran, manuell ein Zertifikat einzubinden. Der Proxy Manager will immer ein neues LE-Zertifikat anfordern. @EDvonSchleck hast du hier vielleicht eine Ahnung?? Oder ist es in dem Fall doch besser, das Zertifikat direkt über den Proxy Manager zu erneuern? Der unterstützt aber halt deutlich weniger Anbieter und mein DDNSS wäre da auch nicht dabei.

 

[EDvonSchleck]

Das mit dem Zertifikat hatten wir letzte Woche auch schon einmal. Lag einfach nur an LE. Mit einer späteren Aktualisierung hat es denn auch funktioniert. Scheinbar gibt es aktuell ein paar Probleme. Du kannst doch das Zertifikat über einen depoyhook in den Container importieren lassen. Was den Proxy Manager angeht, wird das eh auf acme.sh geändert. Beim Proxy Manager kann man halt gleich bei jedem Eintrag ein Zertifikat mit beantragen.

Eventuell schaust du dir den jc21/nginx-proxy-manager:v3 einmal an oder schaust hier einmal vorbei.

 

[plang.pl]

Also irgendwie steig ich ned so recht durch.
Mein Zertifikat, das von acme.sh erstellt wurde, ist zwar gültig. Aber nur explizit für "www.ddnss.de" und für keine Subdomains. Nicht mal für meine registrierte??

 

[EDvonSchleck]

Welche Domain hast du denn in acme angeben? Beispiel unter Punkt 5.b. Dort wird ein Zertifikat direkt auf die Domain und als Wildcard ausgestellt.

 

[plang.pl]

Hab ich eben noch mal nachgestellt. Egal, wie ich es mache, ich erhalte immer eins, das nur für www.ddnss.de gültig ist.

Folgendes habe ich gemacht:
acme.sh --issue --dns dns_ddnss -d meinsub.ddnss.de -d *.meinsub.ddnss.de --dnssleep 300

Im acme Ordner liegt noch die Account.conf:
export DDNSS_Token="MeinTokenVonDDNSS"

 

[plang.pl]

Also mittlerweile klappt es. Keine Ahnung, was ich nun anders gemacht habe. Hab alles noch mal neu eingerichtet und hab ein gültiges Wildcardzertifikat.
Das ganze manuell im Proxy-Manager importiert. Das mit dem Import hat vorhin wegen einem Berechtigungsproblem nicht hingehauen. Das Problem hier war/ist, dass acme.sh als root läuft und deshalb die Certs auch root gehören. Ein chown -R des acme Ordners hat das behoben.
Jetzt fehlt aktuell "nur noch" die Zusammenarbeit von acme und nginx Proxy Manager. Denn soweit ich das bis jetzt gesehen habe, gibt es nur einen deployhook für NGINX. Aber nicht für den Proxy Manager. Vielleicht steige ich aber eh demnächst mal um, um eine kürzere URL zu haben. Zum Beispiel auf Netcup. Der Anbieter wird außerdem nativ vom Proxy Manager unterstützt zur Zertifikatserstellung.

 

[plang.pl]

Heute tagsüber, als ich an der Abstellkammer vorbeiging, hörte ich mehrmals, dass der Tiny sehr laut und auch warm ist. Auch im Proxmox war die Auslastung fast durchgehend bei ca 70%. Die gute Nachricht: ich habe herausgefunden, was es war:
Erster Indiz, den ich gefunden habe: Wenn man sich via RDP auf die Server geschalten hat und dann einfach die Sitzung geschlossen hat, ohne sich abzumelden, hat die VM nach einiger Zeit die CPU stark beansprucht. Also habe ich mich immer brav überall abgemeldet und das Phänomen trat nicht mehr auf. Damit wollte ich aber nicht "weiterleben" und habe gesucht. Das Ergebnis ist echt eine dämliche Sache. Standardmäßig aktiviert lubuntu bei angemeldeter, aber inaktiver Sitzung einen Screensaver. Das Rendering dabei läuft offensichtlich nicht über die iGPU. Den habe ich auf allen Maschinen deaktiviert und jetzt summt der ganz leise vor sich hin.
Das Dumme war: Finde das mal. Sobald du dich draufschaltest via RDP, hört ja der Screensaver auf. Mir ist das nur aufgefallen, weil ich mich zufällig mal via Konsole über Proxmox aufgeschalten hab und da war der Bildschirmschoner zu sehen.
Aktuell laufen alle Container, die vorher auf dem NAS waren, auf dem Proxmox Server, bzw. dessen VMs. Alles im Testbetrieb, allerdings mit gleichem Datenbestand wie auf dem NAS.
In Summe laufen da also nun in 4 VMs insgesamt 25 Container. Alle sind mittlerweile über den zentralen Reverse-Proxy ansprechbar.
Ich bin zufrieden, vor allem, mit dem was ich dazu gelernt habe. Und die Auslastung sagt, dass da noch mehr geht:

 

[EDvonSchleck]

Hast du nicht einmal den Proxy Manager in Version v3 ausprobiert? Dort ist acme schon incl.

 

[plang.pl]

Achja danke für die Erinnerung. Das ist aber ein extra Contaiener zusätzlich zum Proxy Manager, so wie ich das verstehe. Schaue ich mir aber definitiv mal an und teste das durch

 

[EDvonSchleck]

Nutzt du es jetzt nicht in Docker? Das ist doch ein geschossenes System,

 

[plang.pl]

Ach sorry, ich hatte mich auf den Link bezogen, den du oben gepostet hattest.
Ich verwenden den NGINX PM von jc21 in der latest. So wie ich das sehe, zeigt der latest-Tag aber noch auf die v2.
Werde ich mir definitiv mal anschauen. So wie das aktuell mit den Zertifikaten läuft, möchte ich das nicht auf Dauer haben

 

[EDvonSchleck]

News und Features siehst du hier
Dockerimage hier

 

[plang.pl]

Der Container crasht bei mir immer wieder mit [cont-init.d] 10-nginx: exited 127.
Die WebUI ist nicht erreichbar und im Filesystem werden auch keine Daten abgelegt.
Danke für die Tipps. Für heute reichts mir aber. Mache wahrscheinlich mit dem "Projekt" erst nächste Woche weiter.
Bin jetzt erstmal auf der sicheren Seite. Proxmox Backup läuft.

 

[plang.pl]

Moin.
Seit Tagen habe ich Probleme, meine Backup-DS zu erreichen. Sie steht am zweiten Standort, verbunden mit Fritz S2S IPSec VPN. Vor meiner ganzen Proxmox Geschichte hat das immer funktioniert. Dabei tritt folgendes auf: Ich erreiche die Backup-DS nicht von meiner DS aus, egal wie:
-angemeldet über ssh an meiner DS: ping geht nicht durch zur Remote-DS
->der ping scheint nicht mal abgesetzt zu werden, denn ich erhalte auch keine Meldung, dass der ping nicht durchgeht, ich starte also den ping Befehl und es passiert nichts. Daher vermute ich ein Gateway-Problem
-Drive ShareSync verbindet sich auch nicht
-Hyper Backup meldet "Prüfung des Serverstatus"

Jetzt wird es komisch:
-alle anderen Geräte in meinem Netz erreichen die Backup-DS ganz normal, über alle Protokolle
-auch die Backup-DS selbst kann die bei mir stehende DS erreichen
-von meiner DS erreiche ich ebenfalls die vDSM Instanz, die auf der Backup-DS läuft
-wenn ich die Backup-DS neu starte, dann klappt die Verbindung von der Haupt-DS aus wieder, aber nur für ein paar Stunden

Testweise habe ich bereits alle Firewalls deaktiviert und alle Geräte zur Nutzung des VPN-Tunnels berechtigt. Ändert nix an dem Phänomen.
Also gestern Abend: Backup-DS ist nicht mehr von der Haupt-DS aus erreichbar -> Neustart Backup-DS -> geht wieder. Dann bin ich direkt ins Bett. Heute aufgestanden: Backup-DS wieder nicht erreichbar. Das Protokoll der Backup-DS und Haupt-DS melden keine Fehler.

Ich denke, dass es damit zusammenhängt:
Damals hatte ich ein MACVLAN eingerichtet für AdGuard und mir mittels "ip link add" eine Bridge gebaut, sodass meine DS auch den AdGuard erreichen kann. Das MACVLAN gibt es jetzt natürlich nicht mehr. Auf der Bridge-IP, die damals der MACVLAN Adapter hatte, läuft jetzt der Proxmox. Alle paar Stunden meldet meine Haupt-DS, dass es einen IP Konflikt auf dem Interface "MACVLAN" gibt. Ich habe schon alles versucht: "ip link del" -> dann ist der Adapter auch weg, aber nur für ein paar Stunden, dann taucht er wieder auf. Ich habe keine Ahnung, wie das kommt. Vor allem weiß ich nicht, wie das erklärt, dass die Backup-DS nach dem Neustart wieder erreichbar ist.
Hat hier jemand noch einen Idee? Wenn nicht, mache ich deshalb ggfs. einen extra Thread mit mehr Infos auf, falls ich die Ursache nicht sebst finde.

 

[plang.pl]

Ich bin da etwas auf der Spur.
Es hat irgendwas mit dem IP-Routing auf der entfernten DS zu tun. Ich weiß noch nicht genau, wie das zusammenhängt.
Hier ein Auszug vom Backup-Server:


Und hier nach dem Neustart:



10.1.1.2 ist meine Hauptstation. Also findet die Backup-DS den Rückweg nicht. Deshalb bekomm ich auch keine Antwort auf meinen Ping. Muss noch klären, wo genau der Eintrag herkommt und wann der nach dem Neustart erneut gesetzt wird.

 

[plang.pl]

Oh Mann. Ich habs gefunden. Waren 2 Fehler.
1.) Ich hatte das Script mit der Erstellung der IP-Route aus dem Autostart der Haupt-DS genommen. Allerdings lief nachts um 4 ein Script, welches den Docker-Dienst restarted. Da man danach auch die IP-Route neu setzen muss, war das auch in dieser Aufgabe hinterlegt.
Deshalb erstellte sich auf der Haupt-DS das Interface "wie von Zauberhand" neu.
2.) Auf der Backup-DS waren in dem nächtlichen Script fälschlicherweise die Befehle der Haupt-DS für das MACVLAN hinterlegt. Also die 10.1.1.2 statt die 10.2.2.2. Das war mir vorher nie aufgefallen, da anscheinend das MACVLAN Interface mit dem MACVLAN Interface der anderen DS kommunizieren kann, aber nicht mit dem eth1 Interface. Jetzt, da an der Haupt-DS dieses Interface nicht mehr da, war diese nicht mehr erreichbar.

 

[Jim_OS]

In Summe laufen da also nun in 4 VMs insgesamt 25 Container.

Respekt dafür was Du in so kurzer Zeit bereits alles umgesetzt hast. Ich schiebe schon seit Wochen die Umsetzung von OPNSense auf dem Proxmox und die entsprechende Segmentierung des LANs, vor mir her. Entweder fehlt mir dafür die Zeit oder die Lust.

VG Jim

 

[plang.pl]

Ja, da bin ich auch selbst von mir beeindruckt. Normalerweise fange ich so ein Projekt an und dann wird es nie richtig fertig.
Aber auf diese Sache hatte ich richtig Bock.
Aktuell bin ich dabei, SMB-Freigaben auf den VMs bereit zu stellen, sodass ich diese mit AB4B einfach 1:1 sichern kann.
Das hat soweit funktioniert. Allerdings erstellen die Docker-Container ihre Dateien immer mit dem Besitzer "root". Wohl weil diese als root laufen. D.h. ich kann dann als normaler User (der AB4B ist), diese Daten nicht wegsichern, da ich keinen Lesezugriff habe. Mein aktueller Workaraound: Eine Minute vor dem Backup "chown -R" auf dem Server über den Docker-Share laufen lassen. Is aber keine Dauerlösung.

 

[Jim_OS]

Zu den Docker-Containern und den Freigaben kann ich Dir leider nichts sagen. Ich nutze bei Proxmox bisher nur VMs.

Da Du die Docker ja wahrscheinlich alle in den Ubuntu VM laufen hast: Falls Du Dich auch noch/mal mit LXC befassen willst dann ruf einfach mal die Templates unter Proxmox auf: local (pve) --> Container Templates --> Button "Templates" oben

Da stehen Dir rund 100 Container Templates zur Verfügung.


Du kannst auch noch hier schauen: https://www.turnkeylinux.org/all

VG Jim

 

[plang.pl]

Ja, habe alles in den VMs laufen. Aber das mit den Templates kannte ich schon, danke