storagespace wurde von netcup ausgehängt

  • Hallo


    Ich habe letzten Monat wieder mal den storagespace ausprobiert, zum zweiten Mal jetzt.
    Zuerst lief alles gut, also habe ich meinen Backup Ordner dort hin verschoben.
    Nach ein paar Tagen habe ich es nicht mehr weiter verfolgt und erst jetzt habe ich bemerkt, dass das gemountete Laufwerk seit dem 2. Februar wieder verschwunden ist.
    Es wurde erst wieder verwendbar, nachdem ich das mount-Verzeichnis gelöscht, neu erstellt und wieder gemountet hatte.


    Das hatte ich dann dem Support geschrieben, der ("Julian Duß") antwortete leider nicht ganz verständlich:


    Zitat

    Wenn Sie die Daten vom Storagespace, wenn Sie diese nicht mehr benötigen. Die Daten sind aktuell noch bei uns hinterlegt, da die Daten nicht gelöscht wurde.


    Das Storagespace ist aktuell nicht gemountet, da wir an besagtem Datum ein manuellen Reboot Ihres Server durchführen mussten. Weitere Informationen hierzu haben Sie am Tag davor von uns in einer E-Mail erhalten.


    Leider habe ich eine solche Meldung nie erhalten (auch nicht im Spam). Es gab nur die Meldung am 9.2.2016, aber da steht nichts von storagespace umount und außerdem war das erst eine Woche später.


    Ich frage mich nun ernsthaft, ob dieser storagespace doch vielleicht derart unzuverlässig ist, dass ich ihn für professionelle Zwecke besser nicht nutze.


    Weiß jemand was da war, dass der storagespace einfach mal so ausgehängt wird?


    franc


  • Weiß jemand was da war, dass der storagespace einfach mal so ausgehängt wird?


    Ja, ein normaler Reboot/Shutdown.
    Hierbei werden alle Deviced unmounted, ergo auch dein NFS-Share.
    Wenn du dieses beim Bootvorgang nicht automatisch wieder mountest, wird da seitens Linux auch brav nichts gemountet. (Entsprechender Eintrag in der Datei /etc/fstab setzen)


    Ich kann hier kein Fehler seitens Netcup feststellen.

  • Tatasächlich, das war mir nicht aufgefallen, ich hatte den Server am 2.2. ja selbst neu gebootet.
    Ich dachte der mount überlebt einen Neustart. Au weh, Anfängerfehler.
    In der netcup Anleitung steht nichts von einem fstab Eintrag, das setzen die wohl voraus das man das weiß.
    Wäre aber doch ziemlich sinnvoll das zu erwähnen.


    Habe jetzt also einen weiteren Eintrag in der /etc/fstab gemacht:

    Code
    41.58.243.129:/vol-61252-2      /mnt/storagespace       nfs     defaults        0       0


    Nach einem Neustart ist der mount noch da, also OK.


    Was ich aber immer noch nicht verstehe ist, warum das normale Einbinden mit mount nicht mehr funktioniert hatte, ich musste ja erst den Mountpoint (Ordner) löschen und wieder anlegen.


    franc


    PS.: die IP und Nummer ist geändert.

  • Kleiner Tipp: Lieber per GlusterFS mouten


    Ich hatte beim mounten per NFS immer wieder Probleme. Mein Storage war ständig voll ohne dass ich den Platz wirklich verbraucht hatte. Der Support hat behauptet das läge an Hardlinks oder temporären Dateien, kann ich aber beides ausschließen, hat ja 8 Monate ohne Probleme funktioniert. Seit ich das Volume per GlusterFS mounte geht das jetzt ohne Probleme. Anscheinend gab es da Ende Oktober eine Änderung die bei mir zu dem Fehler führte.

  • Ein Hinweis zu Backup-Speicher:
    Dieser sollte eigentlich nie dauerhaft gemountet sein. Dadurch verliert er seinen eigentlichen Zweck. Aktuelles Beispiel, dieser Crypto-Trojaner. Wenn euer Backup dauerhaft gemountet ist, dann wären auch die Backups kompromittiert worden. Auch vor einem "rm -rf /" ist man dann nicht mehr geschützt.


    Backups sollten von entsprechenden Scripten erstellt und im Zuge der der Erstellung dann auch temporär der Storage gemountet werden..

  • Wobei das einem guten Angreifer oder Trojaner auch egal ist. Der mountet sich zur Not halt alles, was er in einem Script oder der Bash-History finden kann.


    Wenn man wirklich auf Nummer sicher gehen möchte, sollte man Backups von extern anstoßen, damit das zu sichernde System gar keinen Zugriff auf die Backuplocation hat. Macht im Falle des Storagespace natürlich wenig(er) Sinn.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Wenn man wirklich auf Nummer sicher gehen möchte, sollte man Backups von extern anstoßen, damit das zu sichernde System gar keinen Zugriff auf die Backuplocation hat. Macht im Falle des Storagespace natürlich wenig(er) Sinn.

    Gab es schon mal Überlegungen, die Snapshotbackups automatisiert auf Drittserver zu sichern.
    Sowohl beim Anbieter im Rechenzentrum als auch mit der Option auf Drittserver.


    Ich hätte da gegen Aufpreis durchaus Interesse ein tägliches, wöchentliches und zweiwöchentliches Snapshot fernab vom Node gespeichert zu wissen.
    Die manuell Snapshots werden ja direkt auf den Host gespeichert.

  • Guten Tag,



    da Snapshots kein vollwertiges Backup ersetzen, gibt es von unserer Seite aus derzeit keine Überlegungen so etwas anzubieten. Das könnte sonst schnell als vollwertiges Backup missbraucht werden.


    Backups müssen sollten immer auf Integrität geprüft werden und das ist in so einem Fall ja nur schwer möglich.



    Mit freundlichen Grüßen


    Felix Preuß

  • Backups müssen sollten immer auf Integrität geprüft werden und das ist in so einem Fall ja nur schwer möglich.

    Mit lokalem Script für diverse Dumps sehe ich da weniger Probleme. Andere Anbieter bekommen das ja auch mit den Vor- und Nachteilen kommuniziert hin.
    Ich sehe hier eher das Problem, das die Zahlungsbereitschaft bei kritischer Masse nicht immer verfügbar ist.


    Da Sie Integrität erwähnen, frage ich mich, wie die Backups bei den Webhostingtarifen von Odin/Plesk auf Integrität geprüft werden.
    Odin/Parallels hat da ja auch nicht gerade Ruhm angesammelt.

  • Kleiner Tipp: Lieber per GlusterFS mouten


    Ich hatte beim mounten per NFS immer wieder Probleme. Mein Storage war ständig voll ohne dass ich den Platz wirklich verbraucht hatte. Der Support hat behauptet das läge an Hardlinks oder temporären Dateien, kann ich aber beides ausschließen, hat ja 8 Monate ohne Probleme funktioniert. Seit ich das Volume per GlusterFS mounte geht das jetzt ohne Probleme. Anscheinend gab es da Ende Oktober eine Änderung die bei mir zu dem Fehler führte.

    Hallo, ich habe das gleiche Problem wie du - kannst du vielleicht ein paar Hinweise geben wie du es gelöst hast? Das wär super! Vielen Dank!

  • Da Sie Integrität erwähnen, frage ich mich, wie die Backups bei den Webhostingtarifen von Odin/Plesk auf Integrität geprüft werden.


    Wenn man sich darauf verlässt, ist man sehr schnell verlassen. Im Webhostingtarif muss ich mir diese Option teuer hinzukaufen. Das habe ich gelassen und kopier den entsprechenden Webspace inkl. Datenbanken mittels SCP auf einen externen Speicher bei einem anderen Anbieter.

  • Ich habe von netcup eine automatische Warnung bekommen:


    dabei geht es im rpcbind, das man mit nfs-common mit installiert, was man für den storagespace braucht.

    Ich habe bisher keine Möglichkeit gefunden, die Erreichbarkeit von außen zu stoppen ohne rpcbind zu deinstallieren, was ja vermutich den storagespace unerreichbar macht, was ich gar nicht ausprobieren will.


    Jemand eine Idee?

  • franc I just quote myself :D thats how i roll. Schau mal bei Abusemeldung erhalten


    Ich hab bei mir auf der Firewall die Regel in der Form eingetragen:

    Für IPv6 mit:

    Code
    ip6tables -I INPUT -p tcp -s ::1 --dport 111 -j ACCEPT
        ip6tables -A INPUT -p tcp -m tcp --dport 111 -j REJECT
        ip6tables -A INPUT -p udp --dport 111 -j DROP

    Für IPv4 mit:

    Code
    iptables -I INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
    iptables -A INPUT -p tcp -m tcp --dport 111 -j REJECT
    iptables -A INPUT -p udp --dport 111 -j DROP

    Um eine NFS Share hinzuzufügen müsste die Adresse dann jeweils mit ihrer ipv4 / ipv6 Adresse freigeschaltet werden.

    Code
    iptables -I INPUT -p tcp  -s aaa.bbb.ccc.ddd —dport 111 -j ACCEPT
    ip6tables -I INPUT -p tcp  -s ::xyz —dport 111 -j ACCEPT

    Wichtig ist dabei nur das die Regel mit -I eingetragen wird damit das Packet nicht frühzeitig verworfen wird.

  • iptables -I INPUT -p tcp -s 46.38.248.199 --dport 111 -j ACCEPT


    Bei dieser Regel war ein winziger Fehler vor dem "dport", da war ein langer Bindestrich, statt zwei Minuszeichen.

    Aber damit geht es jetzt :)

    Danke!!!


    Code
    root@FRANC-MACBOOK:/# rpcinfo -T udp -p 1.2.3.4
    rpcinfo: can't contact portmapper: rpcinfo: RPC: Timed out


    root@FRANC-MACBOOK:/# rpcinfo -T udp -p 1.2.3.4

    rpcinfo: can't contact portmapper: rpcinfo: RPC: Timed out


    vorher war es aber:


    scheint also zu gehen :) :)

  • Ich hatte mich wohl zu wenig über iptables eingelesen, die Regeln sind ja flüchtig und überleben keinen Reboot lese ich im Ubuntuforum:


    Zitat

    ...

    Die mit iptables erstellten Regeln sind flüchtig, d.h. sie bleiben nur bis zum Ausschalten des Computers erhalten! Will man dauerhaft Regeln einrichten, so sollten diese in einem entsprechenden Skript hinterlegt werden, das bei Systemstart automatisch gestartet wird (siehe hierzu rc.local und / oder Upstart bzw iptables-persistent).

    ...

    Habe daher das iptables-persistent installiert und dort in der Datei:


    /etc/iptables/rules.v4


    eingetragen:


    Code
    iptables -I INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT
    iptables -A INPUT -p tcp -m tcp --dport 111 -j REJECT
    iptables -A INPUT -p udp --dport 111 -j DROP
    iptables -I INPUT -p tcp -s 1.2.3.4 --dport 111 -j ACCEPT

    (1.2.3.4 steht für die IP vom Storagespace Server)

    Ich hoffe jetzt bleibt es.

  • So geht es nicht, sondern mit:


    Code
    *filter
    -A INPUT -s 1.2.3.4/32 -p tcp -m tcp --dport 111 -j ACCEPT
    -A INPUT -s 127.0.0.1/32 -p tcp -m tcp --dport 111 -j ACCEPT
    -A INPUT -p tcp -m tcp --dport 111 -j REJECT
    -A INPUT -p udp -m udp --dport 111 -j DROP
    COMMIT


    in der Datei /etc/iptables/rules.v4



    PS.: ich hätte das ja in meinem vorigen Post korrigiert, aber in diesem Forum kann man den nach sehr kurzer Zeit nicht mehr bearbeiten, warum auch immer :(