Posts by m_ueberall

    Aber trotzdem sehe ich keinen großen unerschied ich meine laufen die root server dann auf anderen servern welche eine bessere veerfügbarkeit haben oder wieso gibt es bei denen eine zufriedenheitsgarantie?

    Laut Aussagen des Geschäftsführers unterscheidet sich die eingesetzte Hardware(zusammenstellung); einige VPS-Sonderangebote dienen – nach internen Tests – bisweilen als "Testballons" (vgl. Optane-Cache), bevor vergleichbare RS-Angebote geschnürt werden. Ein anderes Beispiel ist der bessere/konstantere Festplattendurchsatz bei Rootserver- verglichen mit VPS-Angeboten (Thread).

    Ich frage mich nur, wieso DMARC -3 Punkte auf der Seite https://www.mail-tester.com/?lang=de gibt.

    Ich habe den o.g. Test einmal angestoßen (Ergebnis: 10/10), aber auch wenn ich das Ergebnis vollständig anzeigen lasse (d.h. alle Unterpunkte aufgeklappt), sehe ich nur einen Unterabschnitt "[-] Ihre Nachricht bestand den DMARC Test" – da gibt es keine Punktevergabe? Oder ist damit das Endergebnis gemeint?

    Der Tester hat kein Problem mit dem DMARC... Allerdings hat er mich darauf aufmerksam gemacht, das DKIM auf dieser Domain nicht verfügbar ist (obwohl DNS-Eintrag vorhanden und auf Mailserver auch "aktiv")...

    Dann würde ich aber genau da ansetzen, und mehrere unabhängige DKIM-Tests laufen lassen; ggf. DKIM-Definitionen auffrischen. DMARC hat auch Nutzen ohne DKIM und sogar ohne SPF – es kann jedoch sein, dass einige Tester (kenne den erstgenannten nicht) davon ausgehen, dass "alles stimmen muss" und dann "an falscher Stelle meckern". (EDIT: Habe den MECSA-Test mit eigener Domäne gerade noch einmal nachvollzogen und hier wird nichts angemeckert.)

    Ich habe da mal eine Frage. Mail-tester.com heult rum, das meine Mail den DMARC-Test verfehlt […] Ich habe sämtliche DMARC-Kombinationen ausprobiert (und sämtliche Generatoren; überall das gleiche Ergebnis)

    Auf die Schnelle – meckern andere DMARC-Tester auch? Was ist beispielsweise mit MECSA?

    Allerdings. noch ein alter "volksserver", in Betrieb seit 2011 oder so...

    Hier würde ich anregen, gerade aufgrund der o.g. Erfahrungen doch einmal gelegentlich über einen Wechsel auf ein aktuelles SCP-basiertes Angebot nachzudenken, ggf. mit zeitlicher Überlappung (d.h. Parallelbetrieb beider Server für eine kurze Zeit), um einen Vergleichstest machen zu können (ggf. kann man eine Kündigung des alten Produkts, falls alle Stricke reißen sollten, noch zurücknehmen).

    Wir arbeiten aktuell daran das VPS nach Bedarf auch via API gebucht und gekündigt werden können. Zusammen mit Cloudinit, dass wir ebenfalls unterstützen werden, kann dann Infrastruktur bei uns auch rein nach Bedarf automatisiert gebucht und gekündigt werden.

    Gibt es hierzu (ggf. zunächst in der nclabs-Umgebung) mittlerweile konkretere Planungen/erste testbare Funktionen?

    So nach paar Resets läuft er wieder. Komisch. Was könnte das gewesen sein?

    Schlechtes Karma. Haben wir hier in konzertierter Aktion aus der Ferne korrigiert. :D

    Gegebenenfalls mal innen nachsehen, wieviel Staub sich angesammelt hat und was die Temperatursensoren sagen (allerdings sind das nur Anhaltspunkte) …

    [...] jail.conf kopiert zur jail.local [...]

    Code
    1. [...]
    2. Sep 30 17:58:04 lunge fail2ban-server[7990]: Failed during configuration: While reading from '/etc/fail2ban/jail.local' [line 94]: option 'bantime' in section 'DEFAULT' already exists
    3. [...]

    Jemand eine Idee?

    Falls es ein Trost ist: Bei mir geht das Überschreiben, aber ich habe mir das Paket seinerzeit noch selbst bauen müssen, weil ich nicht mehr auf v0.10 warten konnte.

    Ich habe nicht jail.local modifiziert, indem ich sie zunächst zu einer Kopie von jail.conf gemacht habe, sondern nur die zu ändernden Einträge in einer separaten jail.d/my-defaults.conf unter "[DEFAULT]" usw. eingetragen.

    Fürs Protokoll: Die nachfolgende Zeile im obigen "Minimalbeispiel"

    PHP
    1. $responsemessage = $soapclient->logout($customernumber, $apikey, $apipassword, $clientrequestid);

    ist eigentlich falsch und sollte wie folgt aussehen:

    PHP
    1. $responsemessage = $soapclient->logout($customernumber, $apikey, $apisessionid, $clientrequestid);

    Im Test funktionierte das dennoch (der JSON-Endpoint wirft bei Verwendung des falschen Parameters in diesem Fall jedoch korrekterweise eine Fehlermeldung aus) …

    API Operationen, die ich gegen die Netcup DNS API abschicke, bleiben bei mir im Status "Gestartet". Der HTTP Response kommt mit dem Status 200 zurück - der Response Body ist allerdings leer.

    Ein paar Informationen darüber, wie die DNS API angesteuert wird, wären ggf. hilfreich. Ich habe das einmal mit dem im Netcup-Wiki referenzierten DomainWebserviceSoapClient.php (mit PHP 7.4b4 unter Ubuntu 18.04 LTS) nachvollzogen und bekomme damit immer eine Antwort. Die Reihenfolge der Funktionen im Bild unten ist etwas seltsam (wäre durch eine zeitliche Verzögerung bei der Ausführung ggf. aufzulösen), kann aber ignoriert werden.

    Ich sehe den Status "Gestartet" für DNS-Reseller-Funktionen, auf welche ich über das verwendete Konto keinen Zugriff habe; dies ist ggf. ein Fehlerchen in der CCP-Anzeige, denn es wird ja eine Fehlermeldung zurückgeliefert:

    ccp_log_test01.png


    Zum Nachvollziehen hier ein "Minimalbeispiel" (in der Datei access_codes.php finden sich $customernumber, $apikey, $apipassword):

    ["Poor man's" Failover-IPv4-Ersatz durch VPS 200 G8 und dynamisches Portforwarding]

    Grundsätzlich eine mögliche Alternative. (Das gibt es auf Applikationsebene etwa für den Apache2 auch "eingebaut" – man kann transparent für den Nutzer ein Load-Balancing zwischen mehreren Backends einrichten, welches dann natürlich auch gegen den Ausfall einer Instanz schützt.)

    Allerdings sollte man beachten, dass hierdurch bei Verwendung nur eines Servers wieder ein Single-Point-of-Failure (SPOF) entsteht. Deswegen werden in der Praxis auch Load-Balancer redundant betrieben...

    Würde es nicht den Zielen der Kundenzufriedenheit […] entgegenkommen, wenn man auf das Produkt „Zusätzliche IP“ gänzlich verzichtet, und stattdessen überhaupt nur noch Failover-IPs anbietet?

    Angesichts eines deutlichen Preisunterschieds kann ich diese Frage aus meiner Sicht mit einem klaren Nein! beantworten. Zusätzliche IPs werden in der Regel eben nicht als Failover-IPs eingesetzt; ich selbst bin ein Anhänger des Multi-Master-Betriebs (Kopplung mehrerer gleichberechtigter aktiver Server, welche parallel denselben Dienst bereitstellen). Insofern sind "einfache" zusätzliche IPs aus meiner Sicht eine wichtige Ergänzung des Portfolios.

    (In der Vergangenheit funktionierte die gleichzeitige Kündigung von Zusatz-IP-Adressen und eines älteren Root-Server-Produkts nach vorheriger Buchung eines neueren Root-Servers mit neuen zusätzlichen IPs auch reibungslos ohne nennenswerten Zeitaufwand.)

    […] Auch der Zugriff von einem anderen webhosting Paket aus ist möglich. […]

    OK. Die nächste Idee wäre, dass irgendwo "auf dem Weg zum genannten Verzeichnis" eine AllowOverride None-Direktive liegt, welche die gesamte .htaccess-Ausführung deaktivieren würde. (Im Falle von WordPress würde ich dann aber irgendwelche weiteren Seiteneffekte erwarten, das hängt jedoch von der Konfiguration ab.)

    (Sicherheitshalber auch nochmals die Ausgabe von a2enmod rewrite überprüfen?)

    Ich vermute, die Überprüfung wurde durch Direktaufruf des Bildes vorgenommen (entweder im Browser oder via curl/wget auf der Kommandozeile)?

    In diesem Fall ist HTTP_REFERER leer, und damit wird die Regel durch die überflüssige/schädliche Zusatzbedingung RewriteCond %{HTTP_REFERER} !^$ ausgehebelt. (Gegenprobe: Das Bild wirklich von einer anderen Domäne MYWEBSITE2 verlinken – dies sollte zur gewünschten Zugriffsverweigerung führen.)