Also ja es macht es anhand einer mail die ich schicke, aber ich verstehe nicht wie ich es dann einstellen und testen müsste
Als einzige Testmöglichkeit ist die eigene E-Mail-Adresse anzugeben, da kann man kaum etwas falsch machen.
Der Report zeigt unter dem Reiter "Erweitert" genau an, was getestet wurde (alle Server-/Domain-Details) – wenn hier die oben erwähnte Netcup-eigene Domäne auftaucht (anstelle Deiner eigenen Einträge), könnte nur Netcup selbst "Abhilfe schaffen".
CodeIt seems there was an error. Please try again later. Something went Wrong, please try again.
Mit Google Chrome funktionierte da bei mir nichts (wahrscheinlich wg. einem oder mehreren "bösen" Plugin(s)?) – mit Firefox ging es dann.
Was ist denn genau unter dem "Maildienst direkt bei Netcup" zu verstehen? Von Netcup vorkonfigurierte/betreute Dienste zum Versand von Mails (ggf. in Verbindung mit Web-Hosting-Angeboten)?
Unter Verwendung der in Eigenregie aufgesetzten Root-Server/Domain-Einträge kann ich jedenfalls bestätigen, dass es grundsätzlich möglich ist. 
(Bei Durchführung der Tests sollte man beachten, dass es unter Umständen eine Weile dauert, bis "gerade getätigte Änderungen" bei Domain-Resource-Records nach außen sichtbar werden.)
Dabei stellt sich mir die Frage, wieso bei meinen (domainvalidieren) Zertifikaten sich die Informationen (Organization, Location) nicht abfragen lassen (beispielsweise über https://www.digicert.com/help/). Bei der Bestellung musste ich diese Infos ja eingeben.
Die genannten Beispielfelder sind auch bei domainvalidierten Zertifikaten grundsätzlich vorhanden (vgl. RFC5280 oder die Detailansicht in allen aktuellen Browsern/via openssl auf der Kommandozeile), werden aber meines Wissens von keinem Aussteller befüllt[*] – nicht zuletzt, um einen Anreiz zu schaffen, EV-Zertifikate mit ebendiesen/implizit zusätzlichen Informationen gegen (mehr) Geld zu kaufen, wenn/weil sich Käufer allein dadurch beim Nutzer ein höheres Vertrauen "verschaffen" können (oder dies glauben).
[*] gerade weil hier in der Regel ja keine weitergehende, die Feldinhalte betreffende (insbesondere: keine manuelle) Überprüfung stattfindet, d. h. mehr als die (temporäre) Verfügungsgewalt über die Domäne wird ja bei domainvalidierten Zertifikaten als Nachweis gar nicht gefordert; wäre "doof", wenn ein Zertifikatsherausgeber digital signiert, dass das Zertifikat laut Feldinhalt bspw. dem Bundesnachrichtendienst zuzuordnen ist…
Besteht keine Möglichkeit das Image aufn Server zu bearbeiten?
64GB Downloaden und dann wieder Hochzuladen dauert weit über 20h!
In der Zeit kann ich den Server wieder kpl. Neu einrichten was ich mir eigentlich ersparen wollte
Nico04 : Als Anregung: Wenn es ein Problem mit der verfügbaren lokalen Bandbreite gibt, könnte man entweder über ein Bootimage (wenn sonst noch genügend Platz ist auf dem Server) durchaus das Image auf demselben Server bearbeiten. Noch einfacher geht es aber ggf., wenn man für diesen Zweck ein entsprechend dimensioniertes VPS-Angebot mit stundengenauer Abrechnung ordert (ein paar Details zum Ablauf finden sich hier (Danke an nan0 für den Link)).
Ihr habt da wohl etwas überlesen…
In der Tat. Mit Umstieg auf ZFS bei den Servern habe ich diese Funktionalität im SCP völlig ausgeblendet, weil ich sie selbst nicht mehr brauche. Das heißt aber nicht, dass andere Kunden das genau so handhaben... 
Zum Thema ZFS: Ich bin auf den Maschinen bei netcup von ZFS auf BTRFS gewechselt. Bei ZFS fehlt mir die fstrim/discard-Unterstützung. Dadurch läuft die Platte des Servers im SCP immer weiter voll und man kann keine Snapshots mehr machen. Bei BTRFS funktioniert das ohne Probleme.
Hm... Fehlendes TRIM kann nicht dazu führen, dass die Platte vollläuft; es hat allenfalls Auswirkungen auf die Performanz (und indirekt ggf. auf die Lebenserwartung einer SSD).
Mir ist auch noch kein Fehlerbericht oder eine Situation untergekommen, in welcher es nicht mehr möglich war, Snapshots zu erstellen (die im Moment der Erstellung ja eigentlich "keinen" Platz wegnehmen – erst Änderungen führen dazu, dass ggf. Speicher nicht mehr freigegeben werden kann). Konzeptuell wüßte ich auch nicht, wie das bei BTRFS anders gelöst sein sollte, es sind ja beides CoW-Dateisysteme.
(Was man bei beiden Dateisystemen nicht machen darf, ist, den verfügbaren Speicherplatz fast vollständig zu belegen. Bei ZFS reserviere ich generell 15% des Pools vor Erstnutzung.)
Bei Ubuntu gab es damals ja Ärger als die ZFS und den Kernel in einem Repo als Binaries angeboten haben, weil die Lizenzen inkompatibel sind.
Also, der heute für Ubuntu 18.04LTS selbst-kompilierte Kernel 4.18.0-8-generic aus dem "(bald)18.10"-Repository hat im Paket auch ZFS/SPL v0.7.9 als Module 'drin. Sofern keine neueren externen ZFS/SPL-DKMS-Pakete installiert/gefunden werden, wird da beim Einspielen der Kernel-Pakete nichts rekompiliert/ersetzt. Mir gefällt das so. 
H6G: Was ist denn so schlimm an DKMS?
[netcup] Johannes B. : Auch beim Test der SSHFP-Einträge liefert "dig +vc sshfp example.org" nicht die Ergebnisse zurück, welche man erwarten würde und im CCP sieht. Ich habe die (anonymisierten) dig-Ausgaben einer im CCP verwalteten Domäne (.org) und einer Fremdomäne (.ch) angehängt. Zum Vergleich: RFC4255-Beispiel
wieso nicht gleich SHA2-224, der hat genau diese 28 bytes od. 224 bits?
Das ist nicht dasselbe! Die Kürzung des Bezeichners trägt in der Regel älteren Beschränkungen Rechnung, aber ein SHA2-224-Hash ist nun einmal weniger sicher als ein SHA2-256-Hash (sonst könnte man ja auch CRC32 nehmen und die Binärdarstellung als Bezeichner eintragen o.ä.). Dasselbe Prinzip (Kürzung des Bezeichners aus Restriktionsgründen/Bequemlichkeit, solange Eindeutigkeit gewahrt bleibt) findet man ja auch bei git o.ä.
[netcup] Johannes B. : Bei den OPENPGPKEY-Einträgen, bei welchen man die (öffentlichen!) Schlüssel im Base64-Format in das CCP hineinkopiert – wie es das Bildschirmfoto der heutigen Pressemitteilung suggeriert – erfolgt derzeit vor Abspeicherung wohl eine zweite Base64-Konvertierung? (Dies ist IMHO daran zu erkennen, dass die (um Füllzeichen gefilterte) "dig +vc openpgp [...]"-Ausgabe mittels "base64 -d" mit der Originaleingabe im CCP übereinstimmt.)
Infolgedessen schlägt ein "gpg --verbose --auto-key-locate clear,dane --locate-keys info@example.org" fehl.
Liebe Kundinnen und Kunden,
Hallo m_ueberall Saalbuerger thomas303,
Ihre Wünsche wurden wahr. Herzlichen Dank für Ihre Geduld.
Kurze Nachfrage: Wie lange dürfen entsprechende Einträge denn sein? Mein Test-Minimal-GPG-Schlüssel-Export hat (im Binärformat) 19268 Bytes[*], und in Hexadezimalformat gemäß RFC7929 wird's doppelt so lang. Via CCP läßt sich das so nicht hineinkopieren.
[*] Es gibt sicherlich kürzere, aber der Schlüssel wurde seinerzeit absichtlich zur Abdeckung mehrerer Domains erstellt, um die öffentlichen PGP-Schlüssel-Server nicht mit Schlüsseln/"redundanten Attributen" zu "fluten".
[netcup] Felix P. : https://www.netcup-news.de/2018/09/19/neu…ere-dns-servern ist ein toter Link. Wie lautet der korrekte? (Facebook)
Da war ein 'n' zuviel am Ende: https://www.netcup-news.de/2018/09/19/neu…ere-dns-server/
Das ist eigentlich nicht typisch Debian, so wie ich Debian vor paar Jahren kannte.
Seitdem die Meltdown/Spectre Sicherheitslücken bekannt wurden, bin ich mit Debian nur am Patchen und rebooten.
So habe ich das Gefühl, kann auch sein, dass es mir eingebildet habe.
Naja… man kann einer Linux-Distribution eigentlich nicht anlasten, dass sie sich aktiv um die Bereinigung von Fehlern kümmert; Pech, wenn es wiederholt den Kernel selbst betrifft. Niemand ist gezwungen, den Rechner neu zu booten.
Wenn die aktuelle Problematik dazu führt, dass die "Livepatch"-Funkionalität in allen Distributionen (stark) aufgewertet wird – diese schützt bei Ubuntu auch nicht immer vor Reboots –, mag das langfristig(!) sogar vorteilhaft sein. (Man-wird-ja-wohl-noch-träumen-dürfen…)
[…] da im Hauptrepo von acme.sh meine Pull Request noch offen ist. […]
Fürs Protokoll: Link zum kürzlich aktualisierten Pull-Request: https://github.com/Neilpang/acme.sh/pull/1605 (abwarten, Daumen drücken – und/oder "vor Ort" Zuspruch in Form eines Daumen-nach-oben-Emojis dalassen – und Tee trinken…)
leider nicht, das wäre mein absoluter Favorit. Erst vorgestern recherchiert für tinc 2.0 ist das geplant aber es entwickelt halt keiner dran
Ein sehr interessant aussehendes Projekt, welches auch aktuelle Commits "sieht", ist https://github.com/freelan-developers/freelan (http://www.freelan.org/) – bin erst heute darüber gestolpert, aber wenn's jemand ausprobieren möchte…
(https://github.com/freelan-developers/freelan/issues/34 diskutiert übrigens die "Nachteile" von X.509)
Gleiches Prinzip wie bei tinc: https://github.com/Kuebler-IT/MeshVPN (Fork von https://github.com/peervpn/peervpn)
Der Dienst nennt sich piri.
Sagt mir jetzt nichts (ein Link wär' praktisch!)
Grundsätzlich sind zwei Fragen zu klären:
@m_ueberall: Wie testest du bei einem Serverumzug ob deine Webseiten auf dem neuen Server auch sauber funktionieren?
Gerade, indem ich durch Kontrolle der/des DNS-Server(s) dafür sorge, dass bei (back-to-back-)Testläufen wie gewünscht entweder die alten oder die neuen Server von einer/mehreren Testmaschine(n) auf der Client-Seite angesprochen werden.
Im "einfachsten" Fall bei entsprechender vorhandener Konfiguration sind hierzu weder bei den neuen Servern noch bei den dedizierten Maschinen irgendwelche Änderungen vorzunehmen (sofern etwa BIND Views o.ä. zum Einsatz kommen, vgl. diese Diskussion) – d.h. man definiert Server-Zonen und/oder Gruppen von Clients zu Testzwecken, die von denselben im Einsatz befindlichen DNS-Servern bei identischen Anfragen zu unterschiedlichen Auflösungen führen (aber wirklich nur kontrolliert bei den Test-Clients); nachdem die Tests erfolgreich absolviert wurden, werden die Testeinträge die neuen global gültigen.
Alternativ kann man aber auch einfach auf Testmaschinen einen temporären, zusätzlichen DNS-Server ansprechen, welcher einfach die alten mit den zu testenden Einträgen überschreibt und alle anderen Anfragen einfach an bestehende DNS-Server weiterreicht. Das ist nicht wirklich komplexer in der Konfiguration, aber "robuster" (nicht alle Anwendungen scheren sich unbedingt um Einträge in der /etc/hosts) und IMHO weniger fehleranfällig, weil man hierbei nur den Eintrag des DNS-Servers oder die Suchdomäne (letztere Modifikation nur bei vereinfachter Umsetzung des o.g. Ansatzes; mit Einschränkungen verbunden, IMHO nicht zu empfehlen) o.ä. anpassen muss, je nach gewählter Strategie der Identifikation von Testmaschinen. (Wie gesagt, bei entsprechender Planung/Aufsetzung der Infrastruktur wie im vorherigen Absatz muss man Client-seitig gar nichts ändern.)
Eine weitere Alternative wäre das Vorsehen von "floating IPs" für die Dienste über welche man Back-to-back-Tests laufen lässt (oder man definiert grundsätzlich parallele Test-Präfixe, etwa "www-test" statt "www", welche von den Servern gleich behandelt werden, aber durch DNS-Eintragsänderung eben gesteuert bei den alten/neuen Servern landen und möglichst nicht von aussen zugänglich sind – also bspw. nur bei Zugriff über ein VPN bedient werden –, um Fehler zu vermeiden). Man muss wiederum nur sicherstellen, dass während der Testphase ausschließlich die internen Testmaschinen über diese "floating references" zugreifen.
