VK28.01
-
Posts
89 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by VK28.01
-
-
So, nachdem ich nun entsprechend der Release Notes die Einstellungen gerade gemacht habe, zeigt sich im Syslog folgende Warnung; und dies mehrfach.
Quote*** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. ***
Googlet man danach, findet man mein ursprüngliches Fehlerbild, die Nichterreichbarkeit des Servers. 🤷♂️
-
3 minutes ago, alturismo said:
wie @cz13 bereits anmerkte, bitte release notes lesen und entsprechend umstellen, dann sollte das erledigt sein ...
mit etwas Suche wärst du auch selbst darauf gekommen ...
Wenn man weiß, was man sucht, sicherlich. Ist nicht mein Hometurf...
Wäre ja schön, wenn es das wäre.
-
1
-
-
43 minutes ago, cz13 said:
Fix Common Problems: Error: macvlan call traces found
Steht Docker Network auf macvlan und hast du Container mit eigener ip im br0 laufen?
falls ja, sind die empfohlenen Einstellungen aus den Release notes von 6.12.4 gemacht?Hm, ja, der AdGuard läuft auf einer eigenen IP. Eigentlich dachte ich, ich hätte die Einstellungen korrekt gemacht, aber gerade gesehen, dass ich das "Settings > Network Settings > eth0 > Enable Bridging = No (this will automatically enable macvlan)" nicht gesetzt hatte. Ich habe das mal korrigiert.
Da ich die Fritz!Box ersetzt habe, wäre nun auch ein Wechsel zu IPvlan eine Option.
-
53 minutes ago, DataCollector said:
Ich erkenne den Grund aktuell auch nicht, aber wenn ich richtig sehe nutzt Du das ASUS PRIME B460M-A (Rev.1) mit BIOS 1605.
Wenn ich richtig geschaut habe ist seit 2 Jahren die Version 1620 draussen.
https://dlcdnets.asus.com/pub/ASUS/mb/BIOS/PRIME-B460M-A-ASUS-1620.ZIP?model=PRIME B460M-A
Vielleicht behebt die Version schon Dein Problem?
Zusätzlich: hast Du schon mal den RAM mit memtest86 oder so mindestens 24h getestet?
Hast Du am System einen Monitor+Tastatur und mal geschaut ob er sich lokal aufwecken läßt?
Danke für die Punkte. Memtest hatte ich schon mal durchlaufen lassen. Ohne Befund.
Bios werde ich mal updaten, das hatte ich nicht auf dem Radar.
Tastatur&co hatte ich nicht probiert, weil der Server ziemlich "eingebaut" ist.
Was mir noch aufgefallen ist, dass der Stromverbrauch während der "nicht Erreichbarkeit" hoch war und das konstant. Üblicherweise idelt der Server bei 11 Watt rum, während der "nicht Erreichbarkeit" lag der Verbrauch bei 26 Watt; und das über die ganze Zeit und das obwohl die Platten, gehörmäßig, nicht gedreht haben.
-
Ich brauche mal Hilfe. Ich habe hier ein 6.12.4 Unraid laufen. Vor einer Woche ist er das erste mal nicht mehr erreichbar gewesen. Der Server war nicht mehr zu pingen, die Ethernet-Schnittstelle war tot. Geholfen hat dann nur ein Reset. Nun ist es gerade ein weiteres Mal passiert. Der Server hat mehr oder weniger vor sich hin geidelt und ist dann eingefroren.
Ich habe mir den Syslog angeschaut, aber nichts gesehen, was ich mit dem Absturz in Verbindung bringen kann.
Vielleicht kann mal bitte jemand schauen, ob etwas auffälliges vorliegt.
Das erste Mal war im Urlaub und ich hatte keine Zugriff auf die Daten von extern...wenn ich das System nicht zuverlässig bekomme, muß es raus. Das geht nicht.
-
On 7/16/2023 at 12:20 PM, pille said:
Hey there,
I have som issues with the Auto Fan Plugin. I can not find any PWM Controllers. Drop down only says "none". System Temp Plugin works fine. Anyone has an idea how to fix the Fan error?
I do use PWM Fans all attached directly to the mainboard.
M/B:ASUSTeK COMPUTER INC. PRIME H370-A Version Rev 1.xx -
BIOS:American Megatrends Inc. Version 1901. Dated: 02/20/2020
CPU:Intel® Core™ i5-8500 CPU @ 3.00GHz
Best regards
Same here with:
ASUSTeK COMPUTER INC. PRIME B460M-A , Version Rev 1.xx
American Megatrends Inc., Version 1605Intel® Core™ i3-10105 CPU @ 3.70GHz
Sensor-Detect:
Intel digital thermal sensor... Success!
(driver `coretemp')Found `Nuvoton NCT6798D Super IO Sensors' Success!
(address 0x290, driver `nct6775')Processor&Mainboard Sonsors are working like a charm...Fan array Sensor is displayed "none" within the System-Temp-Plugin. Consequently the Auto-Fan-Plugin does not work either.
-
Nach einem Neustart hat sich die rote Fahne verändert:
Aug 13 00:36:54 Tower nginx: 2023/08/13 00:36:54 [error] 14199#14199: *115 limiting requests, excess: 20.344 by zone "authlimit", client: 192.168.0.68, server: , request: "GET /login HTTP/1.1", host: "192.168.0.125:5000", referrer: "http://192.168.0.125:5000/Dashboard"
der Eintrag ist x-fach vorhanden.
Der erstgenannte Eintrag/Fehler ist nicht mehr vorhanden.
-
Nachdem ich heute meine Cache-Pool auf ZFS umgestellt habe, zickt der Server. Nach der Umstellung liefen einige Container nicht mehr und ich mußte aus dem Backup wiederherstellen. Bei der Suche nach dem Fehler bin ich über eine rote Fahne im Log gestolpert.
Im Log habe ich das Folgende gefunden:
Aug 13 00:02:30 Tower kernel: traps: node[19556] trap int3 ip:1c044d2 sp:7ffd51a85e90 error:0 in node[400000+4579000]
Aug 13 00:02:33 Tower kernel: traps: node[19738] trap int3 ip:1c044d2 sp:7ffd038494e0 error:0 in node[400000+4579000]
Aug 13 00:02:36 Tower kernel: traps: node[19937] trap int3 ip:1c044d2 sp:7ffc798da770 error:0 in node[400000+4579000]
Aug 13 00:02:39 Tower kernel: traps: node[20153] trap int3 ip:1c044d2 sp:7fff6d2f52c0 error:0 in node[400000+4579000]
Aug 13 00:02:42 Tower kernel: traps: node[20399] trap int3 ip:1c044d2 sp:7ffe067e5b70 error:0 in node[400000+4579000]
Aug 13 00:02:45 Tower kernel: traps: node[20519] trap int3 ip:1c044d2 sp:7fff211af690 error:0 in node[400000+4579000]
Aug 13 00:02:48 Tower kernel: traps: node[20696] trap int3 ip:1c044d2 sp:7ffd6f2b73a0 error:0 in node[400000+4579000]
Aug 13 00:02:50 Tower kernel: traps: node[20876] trap int3 ip:1c044d2 sp:7ffca9c26a70 error:0 in node[400000+4579000]
Aug 13 00:02:53 Tower kernel: traps: node[21057] trap int3 ip:1c044d2 sp:7fffaeb94e50 error:0 in node[400000+4579000]
Aug 13 00:02:56 Tower kernel: traps: node[21192] trap int3 ip:1c044d2 sp:7ffd2f07ff60 error:0 in node[400000+4579000]
Aug 13 00:02:59 Tower kernel: traps: node[21381] trap int3 ip:1c044d2 sp:7ffcb8b13ef0 error:0 in node[400000+4579000]
Aug 13 00:03:02 Tower kernel: traps: node[21559] trap int3 ip:1c044d2 sp:7ffe2c3afd10 error:0 in node[400000+4579000]
Aug 13 00:03:05 Tower kernel: traps: node[21768] trap int3 ip:1c044d2 sp:7ffc78b70000 error:0 in node[400000+4579000]
Aug 13 00:03:08 Tower kernel: traps: node[21990] trap int3 ip:1c044d2 sp:7ffd389ed140 error:0 in node[400000+4579000]
Aug 13 00:03:11 Tower kernel: traps: node[22127] trap int3 ip:1c044d2 sp:7ffecc5ff1a0 error:0 in node[400000+4579000]
Aug 13 00:03:14 Tower kernel: traps: node[22312] trap int3 ip:1c044d2 sp:7ffc42b94ce0 error:0 in node[400000+4579000]
Aug 13 00:03:17 Tower kernel: traps: node[22454] trap int3 ip:1c044d2 sp:7fffe571ad20 error:0 in node[400000+4579000]
Aug 13 00:03:20 Tower kernel: traps: node[22688] trap int3 ip:1c044d2 sp:7ffc4c1357d0 error:0 in node[400000+4579000]
Aug 13 00:03:22 Tower kernel: traps: node[22807] trap int3 ip:1c044d2 sp:7ffdf42d1fc0 error:0 in node[400000+4579000]
Aug 13 00:03:25 Tower kernel: traps: node[23004] trap int3 ip:1c044d2 sp:7ffc0413dcb0 error:0 in node[400000+4579000]
Aug 13 00:03:28 Tower kernel: traps: node[23190] trap int3 ip:1c044d2 sp:7ffde779fab0 error:0 in node[400000+4579000]
Aug 13 00:03:31 Tower kernel: traps: node[23325] trap int3 ip:1c044d2 sp:7ffc895b0480 error:0 in node[400000+4579000]
Aug 13 00:03:34 Tower kernel: traps: node[23650] trap int3 ip:1c044d2 sp:7ffcf00927b0 error:0 in node[400000+4579000]
Aug 13 00:03:37 Tower kernel: traps: node[23765] trap int3 ip:1c044d2 sp:7ffdecf35e10 error:0 in node[400000+4579000]
Aug 13 00:03:40 Tower kernel: traps: node[23970] trap int3 ip:1c044d2 sp:7ffc08fd0400 error:0 in node[400000+4579000]
Aug 13 00:03:43 Tower kernel: traps: node[24090] trap int3 ip:1c044d2 sp:7ffc3f6382d0 error:0 in node[400000+4579000]
Aug 13 00:03:46 Tower kernel: traps: node[24294] trap int3 ip:1c044d2 sp:7ffc8e26d800 error:0 in node[400000+4579000]
Aug 13 00:03:49 Tower kernel: traps: node[24448] trap int3 ip:1c044d2 sp:7ffd81900150 error:0 in node[400000+4579000]
Aug 13 00:03:52 Tower kernel: traps: node[24671] trap int3 ip:1c044d2 sp:7ffe50e5e4b0 error:0 in node[400000+4579000]
Aug 13 00:03:55 Tower kernel: traps: node[24880] trap int3 ip:1c044d2 sp:7fff56f06960 error:0 in node[400000+4579000]
Aug 13 00:03:57 Tower kernel: traps: node[24989] trap int3 ip:1c044d2 sp:7fff4b5b7660 error:0 in node[400000+4579000]
Aug 13 00:04:00 Tower kernel: traps: node[25185] trap int3 ip:1c044d2 sp:7fff17226a40 error:0 in node[400000+4579000]
Aug 13 00:04:03 Tower kernel: traps: node[25372] trap int3 ip:1c044d2 sp:7fff40981100 error:0 in node[400000+4579000]
Aug 13 00:04:06 Tower kernel: traps: node[25587] trap int3 ip:1c044d2 sp:7ffe36ca9880 error:0 in node[400000+4579000]
Aug 13 00:04:09 Tower kernel: traps: node[25728] trap int3 ip:1c044d2 sp:7ffcd832c940 error:0 in node[400000+4579000]
Aug 13 00:04:12 Tower kernel: traps: node[25941] trap int3 ip:1c044d2 sp:7ffccc666b60 error:0 in node[400000+4579000]
Aug 13 00:04:15 Tower kernel: traps: node[26121] trap int3 ip:1c044d2 sp:7ffdc7c81240 error:0 in node[400000+4579000]
Aug 13 00:04:18 Tower kernel: traps: node[26239] trap int3 ip:1c044d2 sp:7fffe3c00770 error:0 in node[400000+4579000]
Aug 13 00:04:21 Tower kernel: traps: node[26482] trap int3 ip:1c044d2 sp:7ffcdedd06d0 error:0 in node[400000+4579000]
Aug 13 00:04:24 Tower kernel: traps: node[26596] trap int3 ip:1c044d2 sp:7ffd4435e560 error:0 in node[400000+4579000]
Aug 13 00:04:27 Tower kernel: traps: node[26799] trap int3 ip:1c044d2 sp:7fff119611c0 error:0 in node[400000+4579000]
Aug 13 00:04:30 Tower kernel: traps: node[26921] trap int3 ip:1c044d2 sp:7ffede4990a0 error:0 in node[400000+4579000]
Aug 13 00:04:33 Tower kernel: traps: node[27103] trap int3 ip:1c044d2 sp:7fff29704a10 error:0 in node[400000+4579000]
Aug 13 00:04:36 Tower kernel: traps: node[27343] trap int3 ip:1c044d2 sp:7ffe03360020 error:0 in node[400000+4579000]
Aug 13 00:04:39 Tower kernel: traps: node[27464] trap int3 ip:1c044d2 sp:7ffd291dac00 error:0 in node[400000+4579000]
Aug 13 00:04:42 Tower kernel: traps: node[27664] trap int3 ip:1c044d2 sp:7ffd90afe7d0 error:0 in node[400000+4579000]
Aug 13 00:04:45 Tower kernel: traps: node[27807] trap int3 ip:1c044d2 sp:7fff46720f80 error:0 in node[400000+4579000]
Aug 13 00:04:48 Tower kernel: traps: node[27992] trap int3 ip:1c044d2 sp:7fff16058f10 error:0 in node[400000+4579000]
Aug 13 00:04:51 Tower kernel: traps: node[28226] trap int3 ip:1c044d2 sp:7fff45d27d00 error:0 in node[400000+4579000]
Aug 13 00:04:54 Tower kernel: traps: node[28335] trap int3 ip:1c044d2 sp:7ffce2279ac0 error:0 in node[400000+4579000]
Aug 13 00:04:57 Tower kernel: traps: node[28548] trap int3 ip:1c044d2 sp:7ffe5f89d4a0 error:0 in node[400000+4579000]
Aug 13 00:05:00 Tower kernel: traps: node[28685] trap int3 ip:1c044d2 sp:7ffd1101a9c0 error:0 in node[400000+4579000]
Aug 13 00:05:03 Tower kernel: traps: node[28897] trap int3 ip:1c044d2 sp:7fff87ce2230 error:0 in node[400000+4579000]
Aug 13 00:05:06 Tower kernel: traps: node[29082] trap int3 ip:1c044d2 sp:7ffcb525fda0 error:0 in node[400000+4579000]
Aug 13 00:05:09 Tower kernel: traps: node[29306] trap int3 ip:1c044d2 sp:7ffda7933d30 error:0 in node[400000+4579000]
Aug 13 00:05:12 Tower kernel: traps: node[29489] trap int3 ip:1c044d2 sp:7ffff1f686a0 error:0 in node[400000+4579000]
Aug 13 00:05:15 Tower kernel: traps: node[29608] trap int3 ip:1c044d2 sp:7fffa2d6fd90 error:0 in node[400000+4579000]
Aug 13 00:05:18 Tower kernel: traps: node[29847] trap int3 ip:1c044d2 sp:7fff444a9a20 error:0 in node[400000+4579000]
Aug 13 00:05:21 Tower kernel: traps: node[30031] trap int3 ip:1c044d2 sp:7ffe370553c0 error:0 in node[400000+4579000]
Aug 13 00:05:24 Tower kernel: traps: node[30226] trap int3 ip:1c044d2 sp:7ffd97870250 error:0 in node[400000+4579000]
Aug 13 00:05:27 Tower kernel: traps: node[30360] trap int3 ip:1c044d2 sp:7ffe35cbce10 error:0 in node[400000+4579000]
Aug 13 00:05:30 Tower kernel: traps: node[30542] trap int3 ip:1c044d2 sp:7fffc65f71b0 error:0 in node[400000+4579000]
Aug 13 00:05:33 Tower kernel: traps: node[30719] trap int3 ip:1c044d2 sp:7ffe6e59be50 error:0 in node[400000+4579000]
Aug 13 00:05:35 Tower kernel: traps: node[30895] trap int3 ip:1c044d2 sp:7ffe3cd21340 error:0 in node[400000+4579000]
Aug 13 00:05:38 Tower kernel: traps: node[31077] trap int3 ip:1c044d2 sp:7ffd46763ff0 error:0 in node[400000+4579000]
Aug 13 00:05:41 Tower kernel: traps: node[31202] trap int3 ip:1c044d2 sp:7ffc3e40bbf0 error:0 in node[400000+4579000]
Aug 13 00:05:44 Tower kernel: traps: node[31391] trap int3 ip:1c044d2 sp:7ffc0a24a420 error:0 in node[400000+4579000]
Aug 13 00:05:47 Tower kernel: traps: node[31523] trap int3 ip:1c044d2 sp:7ffc8e5a96d0 error:0 in node[400000+4579000]
Aug 13 00:05:50 Tower kernel: traps: node[31766] trap int3 ip:1c044d2 sp:7fff2662a0b0 error:0 in node[400000+4579000]
Aug 13 00:05:53 Tower kernel: traps: node[31930] trap int3 ip:1c044d2 sp:7ffdb55d2fb0 error:0 in node[400000+4579000]
Aug 13 00:05:56 Tower kernel: traps: node[32066] trap int3 ip:1c044d2 sp:7ffd30ddd4f0 error:0 in node[400000+4579000]
Aug 13 00:05:59 Tower kernel: traps: node[32236] trap int3 ip:1c044d2 sp:7fff7c1d3790 error:0 in node[400000+4579000]
Aug 13 00:06:02 Tower kernel: traps: node[32352] trap int3 ip:1c044d2 sp:7ffe76f5e300 error:0 in node[400000+4579000]
Aug 13 00:06:05 Tower kernel: traps: node[32613] trap int3 ip:1c044d2 sp:7ffd9ab62580 error:0 in node[400000+4579000]Abgesehen von der Cache-Umstellung habe ich nichts geändert.
-
ich möchte lösen: geht vollumfänglich
-
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
-
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.
Quote[3/1/2023] [8:00:45 AM] [Migrate ] › ℹ info Current database version: none
[3/1/2023] [8:00:46 AM] [Setup ] › ℹ info Added Certbot plugins certbot-dns-netcup~=1.0.0
[3/1/2023] [8:00:46 AM] [Setup ] › ℹ info Logrotate Timer initialized
[3/1/2023] [8:00:46 AM] [Setup ] › ℹ info Logrotate completed.
[3/1/2023] [8:00:46 AM] [IP Ranges] › ℹ info Fetching IP Ranges from online services...
[3/1/2023] [8:00:46 AM] [IP Ranges] › ℹ info Fetching https://ip-ranges.amazonaws.com/ip-ranges.json
[3/1/2023] [8:00:46 AM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v4
[3/1/2023] [8:00:46 AM] [IP Ranges] › ℹ info Fetching https://www.cloudflare.com/ips-v6
[3/1/2023] [8:00:46 AM] [SSL ] › ℹ info Let's Encrypt Renewal Timer initialized
[3/1/2023] [8:00:46 AM] [SSL ] › ℹ info Renewing SSL certs close to expiry...
[3/1/2023] [8:00:46 AM] [IP Ranges] › ℹ info IP Ranges Renewal Timer initialized
[3/1/2023] [8:00:46 AM] [Global ] › ℹ info Backend PID 247 listening on port 3000 ...
[3/1/2023] [8:03:22 AM] [SSL ] › ✖ error 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 meinedomain.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) -
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ß?
Quote[2/28/2023] [10:17:35 AM] [SSL ] › ✖ error 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 meinedomain.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)at ChildProcess.exithandler (node:child_process:402:12)
at ChildProcess.emit (node:events:513:28)
at maybeClose (node:internal/child_process:1100:16)
at Socket.<anonymous> (node:internal/child_process:458:11)
at Socket.emit (node:events:513:28)
at Pipe.<anonymous> (node:net:301:12)
[2/28/2023] [11:14:36 AM] [SSL ] › ℹ info Renewing SSL certs close to expiry...
[2/28/2023] [11:17:39 AM] [SSL ] › ✖ error 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 meinedomain.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) -
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!
8 hours ago, mgutt said:Was gibt das zurück:
curl -sL -o /dev/null -w "%{http_code}" http://192.168.0.2/
200%
curl -sL -o /dev/null -w "%{http_code}" http://bit.example.com/
000%
curl -sL -o /dev/null -w "%{http_code}" https://bit.example.com/
000%
Außerdem die Konsole von NPM öffnen und das ausführen:
curl -sS http://192.168.0.125:4743/ >/dev/null && echo "Container is reachable"
Container is reachable
Unraid friert ein. Server qualifiziert sich für Parabelflug.
in Deutsch
Posted
So, das war es.
Nach einem Reboot kommt nun das: