Posts by gunnarh

  • Wechsel der IP-Adresse des Glue-Record bei .at Domain wirkt nicht

    Nur zwecks Dokumentation.... das von mir hier vor fast zwei Jahren beschriebene Problem vom Oktober 2020 ist weiterhin in identischer Form vorhanden.


    Wurde also in den letzten zwei Jahren leider NICHT gelöst.

    Ich habe abermals ein Support-Ticket eingebracht, bislang keine Antwort - rechne auch mit keiner da ich inzwischen einen Workaround gefunden habe.


    Da ich diese Woche abermals 2x meine GLUE-Records der .at Domain anpassen musste (Übersiedelung auf neue Server) konnte ich folgenden Workaround "erarbeiten" und als funktionstüchtig validieren. So entgeht man diesem Bug:


    Vorbereitung: Nachschauen wann die NIC.at Reload-Zeiten sind, sich einen Zeitpunkt suchen zu dem kein Reload stattfindet (Die Reloads finden zu festgelegten Zeiten zur vollen Stunde statt, wenn man den Vorgang also um xx:20 durchführt dann hat man jedenfalls 40 Minuten Zeit bis zum nächsten potentiellen Reload der .at Zonen). Derzeit findet der Reload laut nic.at zu folgenden Zeiten statt: Unsere Reload-Zeiten sind um 1:00, 3:00, 5:00, 7:00, 9:00, 11:00, 13:00, 15:00, 17:00, 19:00, 21:00 und 23:00 Uhr (MEZ) [Anmerkung: Jetzt im Sommer ist es getesteter Weise MESZ und nicht MEZ, oder einfacher ausgedrückt: Zeitzone Vienna].


    Weiters Vorbereitung: Wer DNSSEC benutzt notiert sich vor dem Umschalten die hierfür nötigen Parameter, damit man diese nicht erst nach dem Zurückschalten auf eigene Nameserver dann erst mühsam neu recherchieren werden müssen. Die DNSSEC-Parameter lassen sich nach dem Zurückschalten auf eigene Nameserver erst nach dem Speichern wieder eingeben.


    1. Im CCP bei der .at Domain von eigenen Nameservern auf die Netcup Nameserver umschalten und speichern (man muss dazu nichts befüllen, einfach umschalten und ohne zu befüllen auf speichern drücken reicht aus).

    2. Whois der eigenen .at Domain prüfen - nun sind die Netcup-Nameserver eingetragen, technisch wirksam würde das erst zum nächsten nic.at Reload-Zeitpunkt

    3. Nun wieder auf eigene Nameserver im CCP umstellen und die Daten vollständig neu eintippen, speichern

    3b. Optional: Falls DNSSEC benutzt wird, nun auch diese Daten eingeben und speichern (ist erst nach Speichern der eigenen Namserver-Namen + GlueRecords möglich)

    4. Whois prüfen ... voila - sofort übernommen. Die eigenen Nameserver mit den nun hinterlegten GLUE-Records scheinen im WHOIS auf.

    5. Abwarten bis zum nic.at Reload, dann werden die glue-Records in die .at Zone übernommen.

  • DKIM wird von mail testern moniert

    Quote from mainziman

    seltsame Probleme ...

    (-2 points) Your "from" domain does not match your DKIM "from" domain or does not have DKIM signing.

    (-1 points) The DKIM signature is not from the author's or envelope-from domain.

    (ist doch logisch, wenn man f. alle Domains das selbe verwendet ...)

    Warum verwendest du für alle Domains "das selbe"?

    Wenn du OpenDKIM einsetzt ist "SigningTable" und "KeyTable" das Stichwort dies zu lösen. Selbst wenn du für alle das gleiche Schlüsselpaar verwendest, die Config hierfür sollte schon "pro Domain" erfolgen. Kann man für alle Postfix "local-host-names" (das können in einem Multi-Domain-Setup ja auch sehr viele sein) freilich auch automatisiert generieren.

  • Das längste Thema

    Notiz an mich selbst: Server Upgrade / Produkt-Wechsel ... auf größere Disk: LVM und Filesysteme nicht vergrößern


    Nachdem ich nun zwei meiner Server Upgegraded habe (was auch eine größere virtuelle Disk mit sich bringt) wollte ich mich eigentlich gerade daran machen die Partitionen zu vergrößern und den zusätzlichen Speicher nutzbar zu machen.


    ABER: Ich habe davon jetzt doch Abstand genommen.


    GRUND: Ich betreibe meine Server fast immer mit Snapshot. Das hat bei Netcup ja bekanntlich zur Folge, dass ich ohnehin nur 50% der Disk belegen darf, sonst kann ich im SCP keinen Snapshot mehr anlegen.


    Somit kann ich aber im Filesystem von bisher 240GB ohnehin nur 120GB belegen. Der neue Produkttyp hat 320GB Disk, also 80GB die ich vergrößern könnte. Da ich aber ohnehin nicht mehr als 160GB belegen darf um einen Snapshot zu erzeugen und mein aktuelles Filesystem 240GB bietet ergibt sich aus einer Vergrößerung der Partition / LV / FileSystem kein Mehrwert ... somit: Aktion nicht durchführen.

  • Das längste Thema

    Ich antworte mir nochmals selbst:


    Nachdem ich vorhin schon einen VPS per Upgrade testweise über das CCP umgestellt habe und dies tatsächlich nur 1min gedauert hat, habe ich nun auch meinen angesprochenen "RS 500 SAS G7SEa1" aus dem Jahr 2016 auf den nächstgrößeren "RS 1000 SAS G7SEa1" upgedatet.


    Der Vorgang war in unter 30 Sekunden Downtime erledigt. Ich hab parallel dazu im SCP auf den Server geklickt, da war er auch schon runtergefahren und für ca. 10sek nicht mehr steuerbar ("Die Server Einstellungen werden geändert") ... und dann war er auch schon wieder gestartet und hat gebootet.


    Somit haben ziemlich sicher alle 6 von mir gestellten Annahmen zugetroffen. Ein Verschieben dieser mehr als 100GB großen VM ohne Vorbereitung auf einen anderen Host ist in 30 Sekunden nicht machbar, dazu müsste - sofern das überhaupt möglich wäre - das Disk-Image auf einem Storagesystem liegen (was soweit wir wissen ja eher nicht der Fall sein dürfte).


    Und noch ein weiters Indiz dafür, dass der Host gleich blieb: Die SCP-Statistiken sind durchgängig vorhanden. Wenn die VM auf einen anderen Host verschoben wird sind diese grafischen Statistiken erfahrungsgemäß dann gelöscht und beginnen neu.


    Vermutung: Das ging mit ca. 30 Sek Durchführungszeit ja gar schnell, könnte damit Zusammenhängen, dass ich unmittelbar davor noch eine "Storage Optimierung" durchgeführt habe.

  • Das längste Thema

    Quote from m_ueberall

    Ich habe nie ein Downgrade vorgenommen, würde aber meinen, es gibt nur drei Möglichkeiten:

    1. Wenn der genutzte Plattenplatz größer ist als die neue virtuelle Größe des Speichermediums, wird das Downgrade blockiert, bis der Nutzer eine entsprechende Verkleinerung vorgenommen hat
    2. Wenn der genutzte Plattenplatz kleiner ist als die neue virtuelle Größe des Speichermediums, wird bei Erkennen des Dateisystems automatisch eine Verkleinerung durchgeführt (halte ich für weniger wahrscheinlich, da das immer mit einem Restrisiko verbunden ist)
    3. Der in der Zielkonfiguration nicht mehr "unterbringbare" Speicherplatz wird tatsächlich verworfen (würde ich auch als eher unwahrscheinlich ansehen, auch wenn im Falle einer automatischen Anpassung mit Sicherheit ein explizites Einverständnis eingefordert wird)

    Gibt es hierzu noch keine Erläuterung im Wiki (habe nicht nachgesehen)? Das wäre ggf. einmal eine Ergänzung wert.

    Im Wiki ist keine meiner Fragen zum Upgrade erläutert.

    Und die Frage nach einem Dowgrade wie das bei der Disk technisch umgesetzt ist schon gar nicht.


    Die "Zustimmen" Häkchen sehen genauso aus, also keinerlei Hinweis auf Disk-Shrinking mit Datenverlust.

    Ein automatisches-Disk-Shrinking "bei erkennen des Filesystems" würde ich als Anbieter niemals durchführen, das hat hohes Potential schief zu gehen und wäre in meinem Fall (LVM) vermutlich zum Scheitern verurteilt.

  • Das längste Thema


    Ich beantworte mir meine Fragen mal selbst.

    Nachdem ich neben dem Server der mir heilig ist, und den ich upzugraden gedenke noch einen zweiten im Portfolio habe um den es mir nicht ganz so schade ist, habe ich so einen CCP Produkt-Upgrade-Vorgang soeben mit diesem Zweitserver "geübt" und kann berichten:


    Nach Betätigung des Buttons "Upgrade durchführen" wird der Server sofort heruntergefahren.

    Im SCP wird dann für ca. 1min bei Auswahl dieses Servers nur "Die Server Einstellungen werden geändert" angezeigt.

    Danach starte der Server wieder.


    Ich kann 1 + 4 + 5 + 6 somit bestätigen.

    Und ich vermute auch 2 + 3 treffen zu, da ein verschieben des Disk-Image in der kurzen Zeit von nur ca. 1min sicherlich nicht auf einen anderen physischen Host durchgeführt werden kann.


    Nun da das Upgrade durchgeführt wurde habe ich aber eine neue Frage: Mir wird nun im CCP bei eben diesem Server unter Verwaltung weiterhin der Wechsel des Produktes angeboten, und ich könnte zu meiner Überraschung nun auch downgraden auf mein bisheriges Produkt. Wie geht das bei so einem Downgrade, Netcup kann mir ja nicht einfach einen Teil des Disk-Images wegschneiden - vergrößern klar, aber verkleinern?

  • Das längste Thema

    Quote from aRaphael

    Der Host, auf dem ein Server liegt, bleibt auch ohne Upgrade nicht notwendigerweise beständig gleich.

    Das ist mir bewusst. In den vergangenen 6 Lebensjahren dieses Servers wurde dieser meinen Notizen zufolge aber nur 2x umgezogen. Das weiß ich deshalb, da ich immer einen Snapshot eingerichtet habe und ich daher eine Ankündigungsmail für so einen Umzug erhalte und auch den Restart im Zuge des Umzuges bemerke (Live-Migration mit Snapshot ist nicht möglich).


    Und ja, der Hintergrund meiner Frage ist tatsächlich der, dass ich am aktuellen Host SEHR zufrieden bin und das zuvor nicht so war.

  • Das längste Thema

    Im Thread nebenan wird ja das Ende der Verfügbarkeit von "alten" Server-Varianten diskutiert. Meine dort gestellte Frage, ob das auch die "Upgrade-Möglichkeit" eines bestehenden Produktes betrifft ist bislang unbeantwortet. Ich spiele daher mit dem Gedanken noch heute Abend sicherheitshalber einen "RS 500 SAS G7SEa1" aus dem Jahr 2016 auf den nächstgrößeren "RS 1000 SAS G7SEa1" upzudaten.


    An die Profis mit Erfahrungen was so ein Upgrade im CCP angeht: Ist meine Annahme richtig, dass hierbei (erfahrungsgemäß):


    1. Die IP-Adresse bei diesem Vorgang gleich bleibt

    2. Der Serverstandort gleich bleibt

    3. Der physische Host auf dem ich liege gleich bleibt

    4. Ich außer einem Neustart des Servers davon erst mal nichts bemerke

    5. Ich außer dem Vorhandensein von mehr RAM und einer größeren virtuellen Disk hiervon nichts bemerke

    6. Im Nachgang muss ich dann also nichts tun, außer das LVM zu erweitern um den zusätzlichen Disk-Speicherplatz auch tatsächlich nutzen zu können.


    Ist diese Annahme korrekt?

    Ich vermute 1, 2, 4, 5, 6 kann mir jemand bestätigen und zu 3 zumindest eine Vermutungen äußern?


  • Preisanpassung der internationalen VPS Produkte

    Hat die Abkündigung der alten Produkte auch eine Auswirkung auf die Upgrade-Fähigkeit bestehender Produkte?


    Beispiel: Ich habe einen alten "RS 500 SAS G7SEa1" aus dem Jahr 2016.

    Den könnte ich aktuell mittels Upgrade im CCP auf den nächstgrößeren "RS 1000 SAS G7SEa1" upgraden um mehr Disk und RAM zu erhalten. Ich überlege tatsächlich das zu tun - aber akut bauche ich es noch nicht. Bleibt diese Möglichkeit erhalten, oder muss ich das jetzt noch rasch tun weil diese Möglichkeit dann nicht mehr besteht?

  • Postfix Benachrichtigung bei unbekannter E-Mail-Adresse

    Wenn die Mail erst mal abgewiesen ist weißt Du nicht mehr, ob das sinnloser Spam an $random@domain war oder tatsächlich was relevantes. Insofern hilft so ein Log-Eintrag und/oder eine Notify-Mail wenig.


    Ich würde ein separates Postfach anlegen und den Catch-All vorübergehend wieder damit versehen. Das was dort ankommt schaut man halt hin und wieder mal durch, ist es nur noch Spam kann man den Catch-All dann schließlich irgendwann stillegen.

  • Das längste Thema

    Ich habe seit Dezember 2016 (also fast 5,5 Jahren) unter anderem einen kleinen aber feinen RS 500 SAS G7SEa1. Der wurde nun gestern Nacht (nach Vorankündigung per E-Mail) seitens Netcup auf ein neues Hostsystem migriert.


    Bisher war die VM mit zwei dedizierten CPUs vom Typ Intel Xeon CPU E5-2660 v3 @ 2.60GHz konfiguriert.

    Nun läuft sie mit 2x AMD EPYC Processor (with IBPB) mit 2.00GHz ... was das jetzt genau für eine CPU ist konnte ich noch nicht in Erfahrung bringen. Die PassMark Single-Thread Performance liegt bei 1755, was etwas unterhalb jener der ursprünglichen Intel E5-2660 v3 (die hatte ca. 1786) liegt.


    mein Best-Guess: Ich wurde auf ein Hostsystem der RS 1000 G9 a1 Produkte migriert, das wären dann somit AMD EPYC 7702 Kerne. Die sollten allerdings über 2000 PassMark SingleThread-Punkte schaffen. Aber vielleicht schluckt das ja die Virtualisierung.


    Wie gesagt, CPU-mäßig auf gleichem Level.


    IO fühlt sich allerdings nun um Welten besser an. Mein nächtlicher Backup-Job braucht nun nur noch 30min statt bislang 90-100min ... ein dd schreibt statt mit 20-80MB/Sec je nach Tagesverfassung zumindest derzeit auch mal bis zu 300MB/Sec.


    Bin daher bislang sehr positiv überrascht. Downtime des Vorgangs war exakt die Dauer eines Boots. Einziger Wehrmutstropen: Wäre nett, wenn man den Zeitpunkt seitens Netcup noch etwas konkreter hätte angeben können ("in den nächsten 24 Stunden ..." ist dann doch etwas unpräzise, man traut sich den ganzen Tag lang keine Modifikationen mehr vornehmen weil man ja jederzeit mit einem Shutdown rechnen muss).

  • restriktionen bei domain-handle auf gewerbe

    Gar nichts spricht gegen einen anderen Anbieter.

    Ist ja auch meine aktuell praktizierte Lösung. Preislich wäre Netcup bei manchen TLDs allerdings nicht uninteressant und ich hätte die Verträge gerne - wenn möglich - auf einen Anbieter konsolidiert. Netcup nimmt sich damit halt leider selbst aus dem Rennen.

  • restriktionen bei domain-handle auf gewerbe

    Ich denke die Frage von hoedlmoser war anderes gemeint.


    Es geht nicht darum whois zu verstecken, sondern Domains "auf fremde Namen" zu registrieren.

    Auch ich habe mir das schon mehrfach gewünscht.

    Ich möchte die Domain über meinen Account bezahlen (Rechnungsempfänger also ich).

    Ich steh auch gern im tech-c, aber der registrant soll schon der sein dürfen für den ich die Domain tatsächlich registriere.


    Geht aber nicht bei Netcup ohne Domain-Reseller zu sein (wozu den allermeisten aber die Voraussetzungen fehlen, und ich möchte ja auch gar nichts "resellen").


    Bei anderen Registraren kein Problem.

    Wirtschaftliches Risiko für NetCup besteht daraus keines.


    Alternativ-Szenario: Neuen Netcup-Account im Namen der fremden Person registrieren. => Problem: NetCup validiert neue Accounts, da muss man dann also Telefon-Kontaktdaten angeben. Gibt man die eigenen an und erklärt dem Netcup-Validierungs-Personal die Situation erfährt man eine Abfuhr, man möchte mit der Person für die man den Account registriert persönlich sprechen. Gut - müsste man halt "lügen". Aber das ist einem als ehrlicher Mensch dann auch zu blöd und man lässt es bleiben. Registriere Domains für Dritte daher bei anderen Registraren da de-fakto hier nicht sinnvoll möglich.

  • Client Zertifikat Authentisierung

    Wenn das WebHosting keinen Zugriff auf die vHost-Config des Apache zulässt, und man somit weder SSLCACertificatePath noch SSLCACertificateFile konfigurieren kann, dann kann der Server im "client certificate request" des TLS-Handshakes dem Client keine CAs vorschlagen denen er vertrauen würde.


    Das führt wiederum dazu, dass die mir bekannten Web-Browser den Benutzer weder dazu auffordern ein Zertifikat zu wählen, noch wählen sie selbst eines (AutoSelection).


    Da hier ja gewünscht ist einen Browser als TLS-Client zu verwenden, wird ein Aktivieren von SSLVerifyClient mit "optional_no_ca" also nicht zum Ziel führen - der Client wird kein TLSClientAuth-Zertifikat benutzen.


    Möglicherweise bekommt man so ein Szenario hin, indem man OpenSSL s_client als Client benutzt und mit den entsprechenden CmdLine-Argumenten diesen dazu "hinprügelt" dennoch ein Client-Zertifikat zu benutzen. Aber das ist hier ja wohl nicht der gefragte UseCase.


    Und TLS-Client-Auth ohne Validierung des Zertifikates ist schlicht nur Security-by-Obscurity, da ist ein HTTP-Basic-Auth mit ausreichend langem Secret (das man im Kennwortspeicher des Webbrowsers oder wo auch immer hinterlegt) sicherlich zu bevorzugen.

  • Wiener Server kein lokaler DNS resolver

    Ob das "ungünstig" oder "vorteilhaft" ist liegt im Auge des Betrachters.


    Viel wichtiger ob der Server nun mit 3ms oder 9ms Latenz auf ICMP antwortet ist doch, wie rasch er tatsächlich auf DNS-Requests antwortet. Und hier ist nun mal der maßgebliche Faktor ob er einen prall gefüllten und aktuellen Cache aufweist aus dem er antworten kann, oder jeden Request erst selbst iterativ auflösen muss. Insofern ist ein von vielen Kunden genutzter Resolver (der somit eine höhere Cache-Hit-Rate aufweisen kann) und der 9ms weit weg in Nürnberg steht durchschnittlich vermutlich sogar schneller mit seinen Antworten als ein nur von wenigen Kunden genutzter Resolver der 3ms weit weg steht.

  • Auto DNSSEC BIND

    @Georg Deine Frage scheint mir DNS over TLS zu betreffen. Das ist ein Protokoll zwischen Stub-Resolver am Endgerät (Client, Webbrowser) zum interativ arbeitenden DNS-Resolver ("DNS-Server"). Da ein Stub-Resolver am Client aber gar kein DNSSec validiert (das erledigt der iterative Resolver am DNS-Server) sehe ich hier keinen Konex - also nein, wüsste nicht was da zusätzlich zu konfigurieren wäre.

  • Kann ein Anbieter auf die Daten des Kunden mit einem (v)Server zugreifen?

    KB19 und tab haben zwar schon fast alles gesagt, aber je nach Interpretation der Ausgangsfrage gibt es denke ich auch andere Betrachtungen die man hierbei noch in Erwägung ziehen kann:


    Die bereits gegebenen Antworten zielen darauf ab, was ein Anbieter technisch tun könnte. Und ja, hier sind wir uns einig - bei Zugriff auf die physische Hardware ist es nur eine Frage des Aufwandes und der Zeit bis der Hoster zumindest Zugriff auf das laufende OS erhält. Denn selbst wenn dieses vollverschlüsselt mit Entschlüsselungs-Abfrage beim Systemstart läuft, so ist es mittels Evil-Maid-Angriff ja trotzdem möglich das benötigte Kennwort abzufangen (z.b. bei KVM-Virtualisierung indem die Eingaben über die virtuelle Konsole protokolliert werden könnten).


    Und wenn man Zugriff auf das OS hat, so ist jegliche Verschlüsselung die im OS-Kernel oder von Userspace-Prozessen am System durchgeführt werden als gebrochen zu betrachten, eine Auswertung eines Memory-Dumps/Snapshots genügt in der Regel - fertige Tools die Schlüssel aus dem Hauptspeicher extrahieren gibt es für die meisten Anwendungsfälle, sodass der technische Aufwand und Zeitaufwand hierfür überschaubar bleibt.


    Um dem Anbieter also die technische Möglichkeit zu nehmen auf Klartext-Daten zuzugreifen muss die Verschlüsselung schon erfolgen bevor die Daten auf den Server gelangen, also wenn am Server z.B. eine Owncloud läuft muss die Verschlüsselung der Files direkt auf den Clients (z.b. BoxCryptor etc...) erfolgen. Wenn der Server als Mailserver genutzt wird müssen Mails Ende-zu-Ende (PGP, SMIME, ...) auf den Mailclients verschlüsselt werden, ...


    Nun könnte man die Frage also zusammenfassend mit "Verschlüsselung am Server lohnt sich nicht, kann ohnehin gebrochen werden" für sich beantworten. Aber ich rege an das dennoch etwas differenzierter zu betrachten. Für zahlreiche Szenarien in denen einfach ein "Missgeschick" passiert oder zur Abwehr von "neugierigen Mitarbeitern beim Hoster" macht es nämlich durchaus einen Unterschied. Ich kann und möchte hier nicht den Anspruch erheben umfassend Beispiele aufzuzählen, aber auf ein, zwei Beispiele worauf ich hinaus möchte gehe ich kurz ein:


    Annahme: Dem Hoster passiert ein Missgeschick. Er sichert zwar vertraglich zu, dass das Rechenzentrum ISO27000-zertifiziert betrieben und Kundendaten sicher gelöscht werden bevor gebrauchte Hardware einem anderen Kunden zugeteilt oder gar ausgeschieden wird - aber wo Menschen arbeiten passieren Fehler. So könnte es also vorkommen, dass eine Disk (physisch) oder ein Disk-Image (virtuell, oder einfach Teile eines virtuellen Image) nicht sauber gelöscht an einen neuen Ziel-Kunden zugeteilt werden. In diesem Fall sind Klartext-Daten auf der Disk freilich der Worst-Case. Verschlüsselte Daten hingegen könnten in zahlreichen Fällen hier halbwegs wirksam verhindern, dass der neue Kunde bzw. der Käufer einer Gebraucht-Disk mit vertretbarem Aufwand an die Klartext-Daten herankommt.


    Annahme: Beim Hoster arbeitet ein Malicious-Mitarbeiter, z.b. ein Praktikant mit zu viel Freizeit und Neugierde: Auch gegen diesen sind Schutzmaßnahmen vielfach ausreichend wirksam. Man kann davon ausgehen, dass dieser sich z.B. zwar Zugriff auf eine (virtuelle) Disk verschaffen kann, aber vielleicht doch nicht ganz unauffällig ohne dabei den Kollegen aufzufallen einen Memory-Snapshop der Maschine erzeugen kann.


    Annahme: Es ist Container-Virtualisierung (z.B. LXC, openVZ o.ä.) im Einsatz. Hier kann der Anbieter ja völlig transparent einfach im laufenden Betrieb über alle Files des Kunden "drüber-greppen" und/oder auf seine Prozesse Einfluss nehmen. Diesen Usecase mit Verschlüsselung direkt im Container wirkungsvoll abzusichern halte ich zwar für besonders aussichtslos - aber auch hier ist Verschlüsselung besser als gar nichts, denn ein einfaches "grep" oder "copy" im Filesystem beschert auch dann noch keinen Klartext. Ein Minimum an (krimineller) Energie beim Root des Hosts ist auch dann erforderlich.

  • Fiber Bridge

    Da wir hier im Smalltalk-Bereich sind, nun zum lustigen Abschluss noch ein altbekannter Netzwerktechniker-Witz:


    Preisfrage: Wie oft kann man in eine mit Laser bespielte Glasfaser schauen?