Gut, dann ist Dein Problem gelöst;
und wir wissen, dass Let's Encrypt auch f. Hosts funktioniert, welche auf RFC1918-Adressen auflösen;
Beiträge von mainziman
-
-
mit der Key-Generierung ist es freigeschalten - hatte das anders in Erinnerung;
müsste menes Wissens gehen; die Frage die sich mir gerade stellt,
Du meinst doch mit 'lokaler Adresse' eine IP nach RFC1918 - unterstützt Lets Encrypt das überhaupt?
-
Gibt hier der Log mehr Hinweise?
hast Du die DNS-API freigeschalten? und die Domain ist bei netcup?
-
Der Vorteil von Netboot.xyz ist dass das Image nur ein paar MB groß ist und aus dem Bootbaren Image heraus lassen sich alle bekannten Linux-Versionen installieren
meint hier Version nur 'Version' od. eventuell 'Distribution'?
-
die Frage 'Was ist das?" würde ich um die Frage "Wozu soll das gut sein?" ergänzen;
ist ja nicht so dass die Kenntnis von etwas automatisch den Sinn erkennen läßt;
-
CentOS 7 ist ja noch ein 3.10er Kernel, oder?
irgnorier das, des war auch schon vor 7 Jahren ein 3.10er Kernel, aber enthält backported Features und Patches;
das muss man bei CentOS einfach wissen, was es denn mit der Versionsausgabe f. eine Bewandtnis hat;
- Es können maximal 10 Regeln gesetzt werden
MaDa schmeiss den Krempel auf die Halde
-
wenn ma des so liest da: https://www.reddit.com/r/SolusProject…as_shown_under/
fragt ma sich schon wie einfälltig da wer war des so strange zu benamsen ...
ich hab des von meiner Fedora VM deinstalliert,
und siehe da, da kommt noch so a stranges Paket zum Vorschein: cdparanoia-libs-10.2-38.fc35.x86_64
des hats auch gleich mitentfernt ...
-
Warum?
frag netcup, warum das weder im CCP noch im SCP möglich ist;
-
wenn jemand seinen Server tatsächlich z.B. mailverkehr.de nennt, weil er der Besitzer der Domain mailverkehr.de ist,
kann er das ohne Probleme machen, er würde nicht mal einen MX-Record im DNS benötigen; dieser ist auch grundsätzlich nur dann erforderlich,
wenn der Host-Teil der E-mailadressen nicht als A/AAAA-Record vorliegt; was es aber in dem Fall tut;
seht euch mal den rDNS von der IP 62.218.34.10 an; wer meint dass das nicht geht wird eines besseren belehrt;
er kann es nur nicht z.B. bei den DNS-Servern von netcup konfigurieren;
-
Bin mal gespannt, was noch so für Hürden auftauchen, bei einem ipv6-only Server.
127.0.0.1 das immer noch da ist und nicht abgedreht werden kann
-
H6G schau mal hier: https://www.schutzschalter-online.de/cms/was-sind-b…tzschalter.html
unter 122 meldet sich die Feuerwehr
-
Wenn ich einen fehlerhaften Server nun in das Rack anschließe, fliegen mir beide Feeds um die Ohren
andernfalls schmorrt dir im Worst case irgendwo eine Leitung durch und dann Puff,
122 wird dann nicht mehr viel tun können;
des hat schon seinen Sinn
-
P.Se das Ergebnis von sowas haben wir ja in Straßbourg gesehen
H6G ja Fehlerstromschutzschalter; wobei mittlerweile gibts da auch was integriertes
an Stelle einer einfachen Absicherung macht man einen Brandschutzschalter, der einen FI integriert hat
des Teil sieht bei mir im Sicherungskasten der Wohnung so aus:
Brandschutzschalter
welchen Sinn hat es, wenn was ist einfach den Krempel weiter unter Strom zu lassen;
ist ja wie bei Aufleuchten der Motorkontrollleuchte mit Vollgas weiter
-
Wenn man in einem Datacenter für die Server ein FI hat läuft sowiso was falsch.
Aber nur wenn a Meute an Feldhamster im Keller a bissi Dauermarathon läuft und Generatoren antreibt
Du weißt schon was ein Fehlerstromschalter ist, und dass der gesetzlich vorgeschrieben ist.
-
ich will ja nix sagen, aber irgendwie sollt jemand nach Bulgarien und dort bei einem Datacenter
den FI testen;
wenn die folgenden Ports offen sind:
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
3389/tcp open ms-term-serv
und das bei einigen des /24-IPv4-Subnets hier Gefahr in Verzug ist;
-
interessant wäre hier balt, was folgendes ergibt
cat /proc/cpuinfo |grep 'model name'
ist da dann sowas wie z.B. QEMU Virtual CPU version 2.5+
od. vlt. doch sowas wie z.B. Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz
ersteres als dedizierte CPU zu beeichnen wäre dann nicht ok
-
Gunah dann ist es doch realtiv einfach; IPv6 connectivity ausschließlich über einen 6in4 Tunnel, welcher bei einem Wechsel einfach mit der anderen WAN-IP Verbunden wird; (ein HE-Tunnel unterstützt das, Du darfst auch einen eigenen 6in4-Tunnel machen)
Warum? der IPv6-Prefix welcher im LAN verwendet wird, darf sich aus diesem Grund nicht ändern;
und IPv4 hast ohnehin nur RFC1918-Adressen, welche korrekt mit dem richtigen WAN-Interface 'verdrahtet' sind;
d.h. es immer nur eine Leitung aktiv; und wenn diese ausfällt wird auf die 2te geschalten;
sind die Bandbreiten bei beiden gleich? od. gibts hier gröbere Unterschiede?
-
Gunah haben die 2 Leitungen den Sinn der Bandbreitenbündelung od. den Sinn der Ausfallssicherheit?
vermeide NAT66, NAT64, ... od. ähnliche Krücken;
-
hoedlmoser 'ne Europa-Tournee gefällig?
ein Ticket von Wien nach Wien über Zürich bitte
-
https://safe-surf.ru/upload/ALRT/referer_http_header.txt --> cyberwar.ctb-it.de
Uff... Da ist hier einer aber sehr Risikofreudig.
Ja in Zeiten wie diesen, .ru-Seiten zu öffnen
