VK28.01

Hallo, nachdem ich eine Reihe von Containern auf Host bzw. Bridge umgestellt habe, ist der letzte verbliebe Docker, der NPM. NPM ist für mich ein one trick pony und ist für das Vaultwarden Zertifikat zuständig. Ich bin mir unsicher, ob es grundsätzlich geht und wie der Weg ist. Aktuell läuft der NPM auf br0 und hat die IP 192.168.02. Entsprechend verweist meine Domain auf eben jene 192.168.0.02. Da ich lediglich lokal bzw. via VPN auf Vaultwarden zugreife, braucht es keine Weiterleitungen im Router. Dns challenge funktioniert. Im NPM wird dann auf den Vaultwarden Docker weiter geleitet. Vaultwarden läuft im Bridge Mode und hat, wie auch der Unraid Server, die 192.168.0.125. Fragestellungen: Host oder Bridge für NPM? Umstellung des Server Ports, weg von der 80 und(?) 443 Umstellung der Verweises der Domain auf die Sever IP (192.168.0.125)? Geht das, habe ich etwas übersehen? Geht das so? Einen sonnigen Sonntag!

Danke, ich hab es schon befürchtet. 6.11 wird der einfachere Weg sein. Hoffentlich löst ein baldiges Update das Problem. Auf Dauer ohne aktuelle Patches, erzeugt ein massives Störgefühl.

Hallo, ich habe seit ein paar Tagen das Thema, dass der Unraid Server (6.12.2) in unregelmäßigen Abständen einfriert und nicht mehr zu erreichen ist; weder über die GUI erreichbar, noch via Terminal gepingt werden kann. Resette ich ihn, moppert er beim ersten Start beim Start von Container herum; insbesondere Nginx meldet beim Aufruf von Vaultwarden "bad Gateway". Ein weiterer Reset löst das Docker-Problem bis zum nächsten Absturz. Da ich eine Fritz!Box habe (die ich nicht tauschen kann), läuft Docker auf macvlan. Vor den Wechsel auf 6.12 hatte ich keine derartigen Probleme. Ich habe im Log folgende Warnungen bzw. Fehler gefunden: gestern: Jul 4 18:14:07 Tower kernel: BTRFS info (device loop2): using crc32c (crc32c-intel) checksum algorithm Jul 4 18:14:07 Tower kernel: BTRFS info (device loop2): using free space tree Jul 4 18:14:07 Tower root: mount: /var/lib/docker: can't read superblock on /dev/loop2. Jul 4 18:14:07 Tower root: dmesg(1) may have more information after failed mount system call. Jul 4 18:14:07 Tower root: mount error Jul 4 18:14:07 Tower kernel: BTRFS info (device loop2): enabling ssd optimizations Jul 4 18:14:07 Tower kernel: BTRFS info (device loop2): start tree-log replay Jul 4 18:14:07 Tower kernel: BTRFS warning (device loop2): log replay required on RO media Jul 4 18:14:07 Tower kernel: BTRFS error (device loop2): open_ctree failed Jul 4 18:14:07 Tower emhttpd: shcmd (52854): exit status: 1 heute: Jul 5 17:17:27 Tower kernel: docker0: port 5(veth49b268b) entered blocking state Jul 5 17:17:27 Tower kernel: docker0: port 5(veth49b268b) entered forwarding state Jul 5 17:17:40 Tower kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4 Jul 5 17:17:40 Tower kernel: pcieport 0000:00:1c.4: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Jul 5 17:17:40 Tower kernel: pcieport 0000:00:1c.4: device [8086:a394] error status/mask=00000001/00002000 Jul 5 17:17:40 Tower kernel: pcieport 0000:00:1c.4: [ 0] RxErr Jul 5 17:21:15 Tower ool www[26466]: /usr/local/emhttp/plugins/dynamix/scripts/rsyslog_config Jul 5 17:21:17 Tower rsyslogd: [origin software="rsyslogd" swVersion="8.2102.0" x-pid="26575" x-info="https://www.rsyslog.com"] start Jul 5 17:21:38 Tower kernel: pcieport 0000:00:1c.4: AER: Corrected error received: 0000:00:1c.4 Jul 5 17:21:38 Tower kernel: pcieport 0000:00:1c.4: PCIe Bus Error: severity=Corrected, type=Physical Layer, (Receiver ID) Jul 5 17:21:38 Tower kernel: pcieport 0000:00:1c.4: device [8086:a394] error status/mask=00000001/00002000 Jul 5 17:21:38 Tower kernel: pcieport 0000:00:1c.4: [ 0] RxErr Anbei auch noch ein Sylog, indem ich aber nichts relevantes sehe. Ich habe derweil das Dockimage neu angelegt und den USB Port auf einen 2.0 Port gewechselt. Ohne Erfolg. Der PCI-Bus Fehler oben gibt mir zu denken, da ich vor ein paar Wochen einen 2.5Ethernet-PCI Karte eingebaut habe....aber das ist auch nur stochern im Neben syslog-20230705-172532.txt

Alles Warten half nicht. Schlussendlich ein neues Zertifikat erstellt.

Die 9h waren wohl zu wenig. Werde nun mal versuchen, Nginx 24h deaktiviert zu lassen. Mal schauen, ob ich dann nicht mehr in die Sperre laufe.

Alles klar, danke, das werde ich versuchen und mal nen Bug-Report schreiben!

1. Jupp 2. Jupp, Port 80 ist im Router zu gewesen. 3. So, wie ich das verstehe, siehe 2 "customer service to find out if the limitation of requests can be increased". Ist das nicht die Fehlermeldung meines Providers? Kann ja eigentlich nicht sein, dass da eine Anfrage für das Zertifikat kommt, weil Port 80 zu ist? Nach dem Öffnen des Ports 80 im Router laufe ich anscheinend aufgrund der "limitation of requests" in den gleichen Fehler. "ailed to renew certificate npm-10 with error: Unexpected error determining zone identifier for bit.meinedom.de: More than 180 requests per minute. Please wait and retry later. Please contact our customer service to find out if the limitation of requests can be increased. (4013) All renewals failed. The following certificates could not be renewed: /etc/letsencrypt/live/npm-10/fullchain.pem (failure) 1 renew failure(s), 0 parse failure(s) Wo liegt mein Fehler, klär mich auf

Was ich dann aber nicht verstehe: "error: Command failed: certbot renew --non-interactive --quiet --config "/etc/letsencrypt.ini" --preferred-challenges "dns,http" --disable-hook-validation Failed to renew certificate npm-10 with error: Unexpected error determining zone identifier for meine.domain.de More than 180 requests per minute. Please wait and retry later. Please contact our customer service to find out if the limitation of requests can be increased. (4013)" Wie kommt es dann zu den Requesten? kommen die nicht via http?

Hallo, nachdem Vaultwarden nun seit ein paar Monaten stabil und zur vollsten Zufriedenheit läuft, steht nun eine Aktualisierung des Letsencrypt Zertifikats an. Ich habe versucht, nachdem ich per eMail benachrichtigt wurde, über die Nginx Maske zu erneuern, habe aber einen "internal error" innerhalb Nginx gemeldet bekommen. Initial hat es also nicht funktioniert und derweil moppert anscheinend Netcup, wegen zu vieler Anfragen. Ich habe Vaultwarden ohne eine routenseitige Freigabe von Port 80/443 laufen, was problemlos funktioniert Kann es sein, dass ich diese Ports zum aktualisieren des Zertifikates öffnen muß?

Du hast recht, CPUs gehen nicht mehr schlafen! Danke für den Tipp. Schade, aber für das "onetrickpony" passen dann Kosten-Nutzen nicht mehr. Thx

Hallo, ich bin verwundert und frage mich, ob das normal ist und nur meine Erwartung schief. Ausgangssituation: i3, 16gb, 2xSSD cache, 4xHdd, usb-card reader, docker (pi-hole, syncthing, ocrmypdf, oscam, TVH, jellyfin, vaultwarden, etc.) Das Stundenmittel über den Tag liegt bei ca. 13 Watt. Ziemlich prima, wie ich finde. Da ich meinen Dokumentenscanner gerne über eine VM mit Win10 "SMB" fähig machen will, habe ich das entsprechend eingerichtet (2CPUs zugewiesen) Für Stirnrunzeln sorgt aber, dass der Verbrauch, wenn Win10 auf dem Anmeldeschirm vor sich hin idelt, um 15 Watt hoch geht. Die VM liegt dabei auf dem Cache SSD und irgendwelche Indexierungen von Win10 sind auch abgeschlossen. Ist das normal?

Die „Hugedomain-Nummer“ ist nach wie vor da, wenn ich den Curl mache Die Domain ist mir vollkommen unbekannt und taucht im übrigen natürlich nirgendwo im PiHole auf….

Es ist vollbracht! 🥳 Nachdem ich mich nach vielen weiteren erfolglosen Versuchen komplett in der Sackgasse wähnte, habe ich das ganze nochmals komplett neu, inkl. neuer Subdomain auf anderer Domain auf dem Reserveserver gemacht, auch erfolglos. Einziger offener Punkt war, den PiHole komplett aus dem Spiel zu nehmen und es nochmals auf dem Hauptserver zu probieren. Ging sofort!! Wenn ich meine Malereien so im Nachgang betrachte, habe ich mir eine Reihe von (überflüssigen)Schleifen eingebaut, was den DNS angeht. Da das leicht willen- und kenntnisslose initiale einrichten von PiHole den gewünschten Effekt hatte, die Werbung war weg, hab ich nicht weiter ins Detail geschaut. Ich habe das ganze dann nochmal mit sauber gemacht und siehe da, es läuft alles perfekt. @Archonw&@mgutt ganz herzlichen Dank für die Hilfe und Denkanstöße! Ne Menge gelernt. Nochmals Danke!

Connected to bit.meinedomain.com (3.x.x.x) port 80 (#0) > GET / HTTP/1.1 > Host: bit.meinedomain.com > User-Agent: curl/7.84.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 302 Found < content-length: 0 < date: Sat, 17 Dec 2022 09:08:09 GMT < location: https://www.hugedomains.com/domain_profile.cfm?d=meindomain.com < * Connection #0 to host bit.meindomain.com left intact * Clear auth, redirects to port from 80 to 443 * Issue another request to this URL: 'https://www.hugedomains.com/domain_profile.cfm?d=meindomain.com' * Trying 0.0.0.0:443... * connect to 0.0.0.0 port 443 failed: Connection refused * Failed to connect to www.hugedomains.com port 443 after 8 ms: Connection refused * Closing connection 1 curl: (7) Failed to connect to www.hugedomains.com port 443 after 8 ms: Connection refused

Guten Morgen!

Diverse Male nach Vertippern geschaut. Keine Dreher…

Ne, leider nicht: List of local DNS domains DomainIPAction bit.meinedomain.de. -> 192.168.0.2 CNAME records nochmal bit.meinedomain.de. -> 192.168.0.2

So, habe die Fritz!Box neu gestartet. Nun stellt es sich so dar: % dig bit.meinedomain.de +short 192.168.0.2. Zertifikat ist neu und Host ebenso: Puh, geht aber nix. Heißt, klicke ich auf die Source in den Proxy Hosts gibt es folgende URL im Browser: und das Ergebnis: *rolleyes* Ein Hauch von kompletter Ratlosigkeit macht sich breit....

Aktuell bekomme ich die 192.168.0.125 zurück. Die lokale IP des Unraid bzw. Vaulwarden.

Erledigt. Dann warte ich mal, bis "dig bit.deinedomain.de +short" die lokale IP des NPM ausgibt. Ich hoffe, es läuft dann. Schon mal vorab: Danke für den geduldigen Support! 1A!

Wie gesagt reicht die Domain Okay, korrigiert! Welche URL? Sorry, die IP 192.168.0.2. Hier kommt noch die 192.168.0.125 (IP des UNRAID) zurück. Die hatte ich bei Netcup eingetragen, bevor ich auf die 192.168.0.2 des NPM gewechselt habe. Problem ist: die www-Variante ist die EINZIGE, die gerade funktioniert. Weder die nackte "bit.meinedomain.de" noch die "https" Variante funktionieren. Mir war nicht bewußt, dass das nutzen von "www." als eigene Domain behandelt wird. Verstanden.

Ja, danke! Zwischenzeitlich löst sich auch der Bodennebel auf. Wald, Bäume und so....

Vielleicht von Interesse. Die Extension muß auf die selbstgehostete Umgebung eingestellt werden. In meinem Fall muß dort "www.bit.meinedomain.de" eingetragen werden ->Zahnrad oben links bei ausgeklappter Bitwarden Extension.

Da ist wohl noch irgendwo der Wurm drin. Wenn ich nun die Safari-Erweiterung nutzen und mich anmelden will, werde ich trotz korrekter email-Adresse und Masterpasswort abgelehnt, weil angeblich nicht korrekt. Versuche ich eine andere email Adresse, lande ich ganz einfach in der Erweiterung über den offiziellen bitwarden-Account. Würde meinem Sohn sagen: "du bist auf einem guten Weg"...aber irgendwie noch nicht da und so recht verstanden hab ich das verhalten immer noch nicht.

Ja, vielleicht schon. Irgendwie traue ich dem Braten nicht so recht. Ich habe am die "www.bit.meinedomain.de" in Chrome gehauen und der moppest, das Zertifikat sei ungültig 😬