Beiträge von m_ueberall

Zitat von Telly

ich habe für meine Domain erfolgreich SPF & DKIM eingerichtet, nun fehlt nur noch DMARC. Zu letzterem habe ich mich schon ein wenig eingelesen, habe aber noch ein paar kurze Fragen. […] Freue mich über Feedback!

1. Ja, es ist keine gute Idee. Insbesondere, wenn man auf größeren Mailinglisten aktiv ist.
2. Es kann eine beliebige E-Mail-Adresse sein. Ich verwende gerne "dmarc@". "postmaster@" wird wahrscheinlich häufig verwendet, weil sie laut RFC vorgeschrieben ist. (Filtern kann man ja immer, vgl. 4)
3. Das ist durchaus sinnvoll für erste Tests. Bei Unternehmensdomänen würde ich mit der Umstellung ggf. allerdings nicht lange warten.
4. Genau so handhabe ich das auch.

noone1 : Please remember that this is a customer forum, we (fellow customers) cannot help you with the above. You need to directly contact the customer support (either by email or phone).

Zitat von friend_of_root

Das ist eine tolle Antwort, die mich noch eine Weile beschäftigen wird

Lets encrypt SSL Challenge würde mit 2 A Records funktionieren?

Natürlich, wenn die Antwort stimmt. Vgl. etwa Will Let’s Encrypt work for me? (Multiple servers serving one domain). Alternativ kann man auch entsprechende Schlüssel für die DNS-Challenge hinterlegen, wie es für Wildcard-Zertifikate sowieso unabdingbar ist, die ich beispielsweise im Intranet einsetze (funktioniert einwandfrei bei deSEC).

Zitat von friend_of_root

Das finde ich spitze.. aber was genau meinst du.. wie kann das mit 2 redundanten VPS-KVM-Instanzen klappen?

Ich hatte schon so ein Setup bei dem der 1. RS die IP für das A Record der verweisenden Domains stellte, sowie die Let's Encrypt SSL Zertifikate ermöglichte. Darauf lief ein Nginx als Reverse Proxy, der alle Anfragen auf einen 2. RS dahinter weiterleitet... umgesetzt war das mit Nginx Proxy Manager.
Das hat mir sehr gut gefallen, allerdings dachte ich dann, dass man mit der Abhängigkeit von noch einem Server weit mehr als die doppelte Ausfallwahrscheinlichkeit hat.

Und diesem vorgenannten "1. RS" kann man einfach einen Zwilling an die Seite stellen, wobei alle Domänen im einfachsten Fall eben zwei öffentliche IP-Adressen erhalten (genau die der Gateways). Fällt einer aus, werden Clients heutzutage in der Regel einfach die andere IP-Adresse probieren (gerade beim https-Protokoll). Eine Sitzungsverwaltung sollte sicherstellen, dass einmal aufgebaute Sessions bei einem Gateway bleiben ("sticky sessions"), alternativ können sich diese auch gegenseitig über die gültigen Sitzungen austauschen. "Round Robin DNS" sorgt hier schon einmal für eine initiale Lastverteilung zwischen den Gateways. Einschlägige mächtigere/komplexere Softwarelösungen wie HAProxy sind eigentlich auch gut dokumentiert.

Sofern man Dienste im "Multi-Master-Betrieb" in einem Cluster installiert, kann man auf zusätzliche Gateways mbMn ggf. aber auch einfach verzichten – denn wenn die Clients immer mehrere IP-Adressen zur Auswahl haben, ist es nicht sonderlich schlimm, wenn sich einmal ab und zu eine ändert.

(Der Vorteil aller vorgenannter Ansätze gegenüber Failover-IPs liegt bzgl. Dienstleister-Unabhängigkeit auf der Hand.)

Zitat von friend_of_root

Viel, viel besser wäre, wenn man eine bestehende Server IP mit Aufzahlung zur Failover-IP machen könnte!
Oder mit zB 30 Euro Einmalgebühr 1xmal umsiedeln.

Wenn es darum geht, eine IP-Adresse langfristig beizubehalten – warum dann nicht zwei kleine VPS-KVM-Instanzen (Redundanz!) als Gateways davorhängen? Solange das Transfervolumen überschaubar ist, hat man hiermit eine relativ günstige, flexible Alternative (die hinreichend ausfallsicher sein sollte – ggf. rechnen sich hier auch kleine RS, welche von dem zubuchbaren "Root-Server Service Level A+" abgedeckt wären). Als Seiteneffekt hätte man damit auch die Möglichkeit, (später) ein transparentes Load-Balancing einzuführen.

Während sich Geerling an Red Hat abarbeitet, spuckt Rossmann Gift und Galle gegen Reddit. Die Wahrheit liegt dabei wie immer irgendwo in der Mitte.

Der heutige "RS Surfboard" eignet sich theoretisch schon für einen Wechsel von einem "RS 2000 SAS Plus G8" – wenn denn die "Automatische Standort Auswahl" bedeuten würde, dass sich der RS zu allen anderen Produkten in DE gesellt –, auch wenn das einen recht großen Preissprung bedeutet; leider aber war der "RS 2000 G9.5 SE TT23" letzten Monat nicht für einen Wechsel von einem "RS 2000 SAS G8" geeignet, da ihm 160 GB Plattenplatz fehlten. Also heißt es "weiter warten". Der Nachteil bei einer Übernahme von Altverträgen (auch neuer Angebote) ist, dass man ohne Nachfrage nicht davon ausgehen kann, dass alle Rechner auf unterschiedlichen Hosts liegen/automatisch umgezogen werden, wie es bei einem Neuvertragsabschluss der Fall ist. (Und der parallele Wechsel von mehreren "RS 2000 SAS G8" auf neue "RS Surfboard"-Modelle rechnet sich hier noch nicht.)

#Lesenswert: "I'm done with Red Hat (Enterprise Linux)" [http­://www­.­jeffgeerling­.­com] – zugehöriges Video: "Huge Open Source Drama" [http­://www­.­youtube­.­com]

Er erwähnt es nur am Rande, aber mal sehen, ob IBM/RH irgendwann auch Ansible entsprechend … umpositioniert.

EDIT: Inzwischen gab es einen Red Had-Blogeintrag von Mike McGrath (Vice President of Core Platforms Engineering): "Red Hat’s commitment to open source: A response to the git.centos.org changes", auf welchen Geerling mit einem Tweet reagierte ("I might have to actually stop promoting [ansible] too").

Zitat von michaeleifel

cat /sys/devices/virtual/dmi/id/bios_date

dmidecode|grep -iE 'Vendor:' -A2

Zitat von friend_of_root

Leider ist der Upgradetab meist leer und mit keinen Angeboten hinterlegt.

Upgrades, wie sie im CCP angeboten wurden, gehören bislang ja immer derselben Generation an. Das muss mbMn auch nicht zwingend geändert werden, Hauptsache wäre, dass es entsprechende Angebote gäbe, sodass Nutzer Neuverträge abschließen und Altverträge später abkündigen/weiterreichen könnten.

Nicht mehr allokierte Hostrechner können dann durch eine neue Generation (wesentlich kompakter/leistungsfähiger/energiesparender) ersetzt werden, was auch dem Anbieter entgegenkommen könnte/sollte – es bedarf dazu aber einer entsprechenden Kalkulation. Alternativ ziehen Altkunden irgendwann zum Mitbewerber, wenn der Wechseldruck zu groß/die Zusatzkosten angesichts Zusatzleistung akzeptabel sind.

Root-Server, deren Eckdaten gewählt sind, damit sie Nutzern von G8-RS einen reellen "Upgrade-Pfad" bieten (ohne, dass sie mindestens doppelt so teuer sind, wenn man keine Einbußen bzgl. RAM oder Partitionsgröße hinnehmen kann, weil sie in dieser "Ausbaustufe" gleich mindestens das Doppelte an Speicherplatz/CPU-Kernen mitbringen), wären einmal eine erfreuliche Abwechslung.

Wer braucht denn diese Spielkonsolen, wenn es https://alt.org/nethack/ gibt?

(Klar kann man NetHack auch lokal installieren, aber hier kann man anderen über die Schulter schauen, wenn man selbst nicht so viel Zeit hat …)

Ich persönlich halte nicht viel von Cross-Compiling, zumal es mittlerweile dank binfmt-support, den qemu-Paketen, debootstrap und schroot gerade unter Debian/Ubuntu sehr einfach ist, eine "native" Build-Umgebung zu erstellen, welche jegliche Modifikation von Build-Scripts überflüssig macht (mittlerweile erfolgreich getestet für amd64/x86_64, arm64/aarch64 und riscv64 – für die letztgenannte Architektur noch nicht auf einem Host mit entsprechender Hardware).

Mit etwas Glück könnte man mithilfe der vorgenannten Pakete (unter Verwendung der Alpine-eigenen Bootstrapping-Methode anstelle von debootstrap) ggf. Alpine Linux für alle gewünschten Architekturen jeweils in einem Chroot installieren; das habe ich selbst bislang allerdings noch nicht ausprobiert.

Ja, genau so steht es in dem oben verlinkten Diskussionsfaden (hier übertragen auf die Unterdomäne).

Moderatoren : Ich erinnere mich dunkel, dass es einmal ein Vorhaben gab, derartige Informationen auch einmal in das Netcup-eigene Wiki einfließen zu lassen (hier insbesondere ein explizite(re)s Beispiel, was das Weglassen der Domäne betrifft) – wurde dieses ad acta gelegt?

Wenn die Tests jetzt einmal erfolgreich durch sind, kann ich die bonnie++-Cronjobs ja wieder reaktivieren …

Der eigene Webserver kann grundsätzlich alle HTTP-Response-Header manipulieren, und damit natürlich auch "Location:" modifizieren. Mit Apache2 geht das in etwa wie hier beschrieben: How to conditionally modify Apache response header 'Location' – innerhalb einer VirtualHost-Umgebung könnte man dies in <Location /hauptunterseite/unterunterseite> […] </Location> packen und ggf. davon abhängig machen, wo der Aufruf herkommt (etwa eine spezifische anderedomain.de), wobei der Client diese Information aber natürlich unterdrücken kann; somit wäre das Letztere nicht wasserdicht, wenn man dem Nutzer nicht mit dessen Erlaubnis Cookies unterjubelt, die diese Information transportieren (aber auch diese kann ein Client filtern, wenn sich der Nutzer entsprechend auskennt).

(Das obige Szenario könnte man ggf. auch mit einem "Reverse Proxy" realisieren, das ist für einzelne "landing pages" aber eigentlich zu viel des Guten.)

Zitat von Interessent

Das war ja die Frage wo und wie im DNS es angelegt gehört

Suche nach "acme-challenge" im Forum liefert ziemlich schnell die Lösung: Domänennamen weglassen und richtige Feldauswahl ("Host") beachten – vgl. hier bzw. den Foreneintrag direkt darüber.

Zitat von [netcup] Christina R.

cltrmx Das tut mir sehr leid! Wir schicken dir nochmal eine neue zu.

cltrmx : Hebe die kaputte auf und wenn die neue Tasse angekommen ist (wahrscheinlich ganz), hau' nochmal mit dem Hammer drauf, damit Du Dich beschweren kannst, dass die zweite noch viel kaputter angekommen sei. Das erhöht die Chancen, dass Dich Netcup daraufhin mit weiteren Tassen (n>1) versorgt.

vbsbart : Unfortunately, the 30 days refund guarantee should also only apply to "Root Servers", not "Virtual Servers (VPS)" in the first place. Your best bet now is to offer one of your contracts to other clients in the "swap shop" subforum (along with a rebate) in order to cut your losses.

Passt thematisch gut zu diesem Diskussionsfaden und hat einige gute Anmerkungen in den Kommentaren: Can you run 10Gbit Ethernet over Cat5e?