Beiträge von Hecke29

    Das der DHCP von netcup hier eine Search Domain ausliefert ist auch suboptimal.

    Die könnte man eigentlich auch einfach weglassen.

    Ich nehme mal an du meintest DNS-Server.

    Aber davon ab passiert das nur, weil er nachdem er für x.yy.120.37.score.senderscore.com nichts findet, nochmal nach x.yy.120.37.score.senderscore.com.quicksrv.de sucht (glaube ich; so verstehe ich das) und da hat netcup halt ein "fallback" für die Domain hinterlegt. Finde ich in Ordnung. Ist ja quasi "mein Problem", dass die Domäne in der resolv.conf steht (wobei ich das da nie bewusst hinterlegt habe)

    Mein Fix war jetzt einen voll qualifizierten DNS-Lookup zu machen:

    Statt

    dnslookup='%s.score.senderscore.com'%(reverseIp)

    nun

    dnslookup='%s.score.senderscore.com.'%(reverseIp).

    Funktioniert nun so gut wie nie zuvor :)

    Moin,

    Edit: Es liegt natürlich an der Such-Domäne... :wacko: Danke, gelbe Quietscheente! Schönen Abend euch

    ich benötige Hilfe bei folgendem seltsamen Verhalten.

    Ich habe eine Python-Phase und schreibe grade statt shell-Scripten oft python-Schnippsel. Heute hab ich mir was zusammengebastelt, das mir für meine Server den Senderscore-Wert abfragen soll. Das soll in icinga als Check (alle X Stunden) reinkommen.

    Meine Server haben keinen Senderscore.com-Wert, aufgrund fehlenden Mail-Volumens (was nicht ist, kann ja noch werden). Im Original-Script ist dafür eine entsprechende Behandlung vorgesehen. Jetzt habe ich das Script deployt und bekomme nicht wie erwartet eine NXDOMAIN-Exception, aber auch keine "korrekte" Antwort mit Score, sondern die IP 46.38.243.234. Keine Ahnung was das für eine IP ist, aber sie ist sehr mysteriös, denn sie taucht mehrmals in den Tiefen des Kundenforums auf - in Verbindung mit DNS-Resolvs.

    Zum eingrenzen des Problems habe ich ein minimal verifyable python3 example gebaut:

    Ich möchte bitte - wie lokal auch - dass das Python-Script an der Stelle seine Exception wirft, aber scheinbar kommt irgendwo diese IP her.

    Es ist ein Ubuntu-System und als DNS-Server habe ich folgendes hinterlegt:

    Code: resolv.conf
    # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
    #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
    nameserver 46.38.225.230
    nameserver 46.38.252.230
    nameserver 8.8.8.8
    search quicksrv.de

    Es liegt bestimmt an der Standard-Domain quicksrv.de, die da drin steht; aber aus Prinzip sende ich den Beitrag jetzt erstmal ab und prüfe es erst danach :cursing:

    Edit: Ist natürlich das gewesen...

    Kann mir jemand auf die Sprünge helfen?

    Wie sieht es mit Dingen wie dem World Community Grid [...] aus? Hier wird halt ein anderer Zweck [...] verfolgt, wobei die Auslastung ja auch permanent hoch ist.

    Zitat von AGB
    • Betreiben von Serverdiensten , die eine besonders starke Rechnerlast verursachen; dies gilt nicht bei dedizierten und virtuellen Server

    Ist also gestattet.

    Das heißt: Passwort auf jeden Fall aktivieren? Ist es damit halbwegs sicher?

    Ne, also das Passwort setzen bewirkt nur, dass Plesk-Zugangsdaten verschlüsselt werden. Die Webseitendaten und DB-Dumps sind trotzdem unverschlüsselt. Deshalb ist "passwortgeschützt" eine relativ irreführende Bezeichnung: Die Hauptdaten sind halt trotz "Passwortgeschütztem Backup" nicht geschützt. Meiner Meinung nach ist es relativ sinnbefreit ein Passwort für die Plesk-Backups zu setzen. Es schadet aber auch nicht.

    Ich versuche dir mal nach bestem Wissen und Gewissen zu antworten:

    Zitat

    - "Domain sperren, bis Backup-Aufgabe abgeschlossen wurde": Diese Einstellmöglichkeit hat mich stutzig gemacht. Ist das notwendig? Wie ist die Last auf das System? Sollte ein Backup in die Nacht terminiert werden?

    Um einen in sich konsistenten Stand zu sichern (Web-Dateien und Datenbanken "passen zusammen"), kann man das machen. In der Praxis wahrscheinlich unnötig. Zu einer Zeit in der die Webseite wenig verwendet wird, ergibt Sinn.

    Zitat

    - "Einstellungen zur Backupsicherheit": Wie werden Passwörter hier genutzt? Muss man sich das wie eine Art Passwort für ein ZIP-Archiv vorstellen, das vertrauliche Informationen verschlüsselt? Das habe ich noch nicht genau verstanden: "Beachten Sie, dass beim Wiederherstellen eines passwortgeschützten Backups ohne die Angabe des Passworts Benutzerpasswörter in Plesk zufällig generiert werden"

    Hier war ich selbst etwas stutzig als ich sah, dass bei einem "Passwortgeschützten" Backup alle Daten (.sql-Backupdateien, Webdateien) in Plain ohne Passwort vorliegen. Lediglich einige wenige (Zugangs-)Daten von Plesk (XML-Values) werden verschlüsselt. Sinnhaftigkeit darf bezweifelt werden.

    Zitat

    - Sind dann Backups nur über Plesk einspielbar oder werden die Dateien auf dem anderen FTP in Reinform gespeichert, sodass man sie auch von dort speichern und wiederherstellen kann?

    Es ist soweit ich es weiß ein Ordner (könnte auch ein Archiv sein) in dem zum einen ein paar XML-Datei(en) liegen, dort sind Meta-Informationen und Plesk-Einstellungen drin. Dann gibt es noch eigene Ordner für Webroots, Logs und SQL-Dumps.

    Edit: Habe selbst kein Webhosting bei netcup. Administriere einige Plesk-Instanzen

    Viele Grüße aus Hamburg

    Soweit ich es richtig verstehe, ist nicht die IP des Webhosting in der Blacklist gelistet, sondern die Empfänger IP (GMX Server) und die Blacklist wird von einigen Webhosting Nodes zur Filterung genutzt und bei anderen findet eine Filterung nicht statt.

    8bit Verstehe ich es so richtig?

    Ah, beim erneuten Lesen habe ich es jetzt auch verstanden. Manche (netcup-)Nodes filtern E-Mails von Sendern, die auf der BL stehen, andere (netcup-)Nodes tun dies nicht.

    Dann passt die Antwort vom Netcup-Support ja aber gar nicht (da geht es ja um den Versand vom Webhosting irgendwo hin).

    Eine Frage habe ich jedoch:

    Was ist mit den Storage-Servern? Kommen die später? Das ist bei uns der Einzige welcher noch nicht "behandelt" wurde.

    Alle anderen Server, bzw. halt die entsprechenden Nodes, wurden in der Reihenfolge der ehemaligen Bestellung gepatched - was mich vermuten lässt, dass so auch das System war, also von alt zu neu.

    Meine Storage Nodes wurden auch erst nach dem 95% Status behandelt (11:38 Uhr). Leider beide gleichzeitig :( 3. Node des Ceph-Clusters steht gottseidank bei einem anderen Anbieter :wacko:

    Bitte dazu eine kurze Meldung an den Support. Unsere Script prüfen ob ein node bereits neu gestartet wurde. Das verhalten sollte also so nie auftreten. Haben Sie hier auch 2 Reboot Ankündigungen erhalten?

    Zitat von Supportmitarbeiter (NC#2018011010021217)

    Leider kommt es in vereinzelten Fällen vor, dass ein Wirtsystem nach Patch und Neustart nicht auf Anhieb sauber läuft und nochmals neu gestartet werden muss. Seien Sie versichert, dass unsere Techniker bemüht sind, die Unterbrechungen der Verfügbarkeit auf das absolut unumgängliche Minimum zu beschränken.

    Ich würde dem Support nochmal explizit schreiben, dass dein Server vom netcup-DHCP keine IP zugewiesen bekommt und dass dies kein Konfigurationsproblem auf deiner Seite sein kann.

    Netcup hat ja irgendwo hinterlegt, welches Interface (MAC-Adresse) welche IPs binden darf, damit nicht irgendwer bei netcup deine IP binden kann. Wenn du selbst beim manuellen, statischem Konfigurieren der IP, keine Konnektivität herstellen kannst, ist dort wohl etwas falsch. Bis du das dem Support erklärt hast, vergehen aber vermutlich Tage.

    Deshalb mache ich es mittlerweile auch so, dass ich möglichst wenig in die "Eröffnungsanfrage" reinschreibe, weil ich als erstes eh eine Standard-Antwort bekomme. In deinem Fall also: "Hallo, mein Server v201Xxxxxxxx bekommt vom netcup-DHCP-Server keine IP zugewiesen".

    Ich nehme mal an rein geht auch nichts (also von zu Hause deinen Server anpingen).

    Wenn du die IP per DHCP konfigurieren lässt meintest du im anderen Thread siehst du in der VNC-Konsole, dass der if.up-Task sehr lange läuft und irgendwann mit [FAILED] quittiert, richtig?

    Ich würde mich mal an den Support wenden (wegen des DHCP-IP Umstandes)

    Das ist völlig normal. Ich habe schon viele IP(-Ranges) komplett geblacklisted auf all meinen Systemen (vor allem die, die auf SMTP, FTP etc. gehen und "klug" agieren, also Domain-Namen als Usernamen probieren, die auch auf die IP matchen).

    Just for the lulz mal aus den letzten sieben Tagen die TOP10 ausprobierten Usernamen (und Services) auf meinen Systemen:

    Bildschirmfoto 2018-01-09 um 13.09.56.png

    (MySQL ist schon viel raus, da seit auch ca. 1 Woche Whitelist)

    Mir wurde am Telefon (Notfallsupport) soeben die Auskunft erteilt, dass die 15 Minuten Downtime (die ich hier jetzt grade pinge) mit dem internen Monitoring übereinstimmen und das System bald wieder erreichbar sein müsste, was während des Telefonats, etwa nach 16,5 Minuten (von mir gemessener) Gesamt-Nichterreichbarkeit auch der Fall war (es dürften aber über 30 gewesen sein, denn die letzte Mail von dem System kam um 18:09, aber da es die Monitoring VM war, kann ich das nicht genauer sagen). Es sei auch normal, dass das so ist. Auch mit Verweis auf die 25 Minuten der anderen VM wurde mir gesagt, dass das normal ist.

    Ich muss sagen, dass ich richtig enttäuscht bin. Es wurde gesagt die VMs werden neugestartet.

    Bisher wurde lt. uptime eine VM neugestartet; alle anderen haben noch mehrere Tage uptime, aber ein paar VMs waren über den Tag bis zu 25 Minuten einfach gar nicht erreichbar über Netzwerk. Da ist mir der Reboot echt lieber. Jetzt grade seit 18:04 Uhr eine VM, seit 18:09 Uhr noch eine weitere (die Monitoring-VM, jetzt bekomme ich erstmal nichts mehr mit :D) nicht erreichbar; eine andere von 17:39 Uhr bis 18:02...

    Ich muss grade hoffen, dass es nicht zwei/drei VMs aus dem gleichen Datenbank-Cluster trifft...