Beiträge von m_ueberall

    […] APC Back-UPS Pro […]

    Das ist ein sehr gutes Stichwort… :)

    Ich suche nach einer gescheiten UPS, welche mindestens für 1–2 NUC (à 120W max.) und 2–3 SBC (à 10W max.), ggf. auch noch für einen Monitor (ca. 40W) ausgelegt ist, dabei aber zumindest bei funktionierender Stromversorgung absolut geräuschfrei ist (kein Dauerbrummen), weil die im Arbeitszimmer unter dem Tisch platziert werden müsste. Gibt es da Erfahrungen/Empfehlungen?

    Kann mir jemand jetzt erklären, was die Meldung bedeutet? Wenn ich Attack lese und Botnetz impliziert das für mich, dass ich an meinem Server nen Problem habe oder nicht?

    Ich nutze derzeit externe Nameserver, dann deinstalliere ich einfach BIND DNS server im Plesk und dann sollte mich das Problem doch nicht interessieren oder?

    tabhat die Frage im ersten Satz bereits beantwortet (siehe hier) :

    DNS Amplification Attack (nicht auf deinen Server, das Opfer ist jemand anders) ... Die IPs sind über den ganzen Globus verstreut. […]

    Nutzung alternativer/eigener Nameserver nur für den eigenen Gebrauch und ggf. unter Einbindung entsprechender blacklists sollten einer unfreiwilligen Beteiligung des eigenen VServers einen Riegel vorschieben, ja. Ich selbst bin sehr zufrieden mit DNSCrypt-Proxy als "Uplink".

    Genau diese Meldungen sehe ich auch in den zwei Servern, die ich hier bei netcup habe. Gute Frage, was man dagegen tun könnte. Die Requests kommen ja von verschiedensten IP Adressen.

    Ich interpretiere das "denied" am Ende einfach mal so, dass die Anfragen von meinen Nameservern nicht beantwortet wurden und sich der Schaden darauf beschränkt, dass die Logdatei durch die Anfragen vollgemüllt wird (ca 20.000 Zeilen pro Tag, jeweils ca 200 Anfragen pro IP).

    Die obengenannte Domäne ist (noch?) nicht darunter, aber meine unbound-Logs zeigen derartige Einträge nicht; das könnte mit an der Verwendung von

    The Big Blocklist Collection liegen, was derzeit akkumuliert Anfragen zu mehr als 113.000 Domänen blockiert ("redirect"/"A 0.0.0.0"/"AAAA ::").

    Brauchst du das nicht in jedem Fall, wenn du Erreichbarkeit von außerhalb garantieren willst?

    Man könnte sich überlegen, mehrere verschiedene "what-is-my-external-ip"-Dienste von innen (=VServer des Kubernetes-Clusters) abzufragen – unter der Annahme, dass eine enthaltene Rückantwort mit korrekter Information ein Nachweis der IP-Erreichbarkeit darstellt, wenngleich in der Regel nur für einen Port. Oder man verwendet TOR und erzwingt die Nutzung von Exitknoten aus verschiedenen Ländern.

    Die Frage ist hierbei, wie beispielsweise bei Nichterreichung des gesamten einzelnen Rechenzentrums verfahren werden soll, da ja in diesem Fall keine Nachricht über fehlgeschlagene Tests nach außen dringen können. Wenn man davon ausgeht, dass der Nutzer regelmäßig über erfolgreiche Tests benachrichtigt wird, benötigt es auf der Empfänger/-Clientseite eine Art "Totmannschaltung". Klingt nach "von hinten durch die Brust ins Auge" und ist de facto nur als "Notlösung" anzusehen, hat aber den Vorteil, dass man Ressourcen (Server/Monitoring-Dienste) einspart und zusätzliche Abhängigkeiten vermeidet (Monitoring-Lösungen sollten natürlich auch redundant sein).

    Um die Komplexität zu reduzieren, könnte man sich überlegen, den erstgenannten Ansatz mit dem Anmieten des kleinstmöglichen Serverpakets auf dem Markt zu kombinieren, welches nicht im selben Rechenzentrum angesiedelt ist wie alle anderen VServer; dies erspart obengenannte "Not-/Bastellösung"[*] und sollte eine gegenseitige Kontrolle des Monitoring-Systems und VServern des Kubernetes-Cluster ermöglichen – über den Daumen kann/muss man hierfür ca. einen EUR/Monat ansetzen, was IMHO nicht zu teuer ist. (Die Ausnutzung wechselnder Freikontingente bei verschiedenen Anbietern rechnet sich für diesen Einsatzzweck eigentlich nicht.)

    Daneben gibt es für eine begrenzte Anzahl von Tests auf dem Markt auch ein paar kostenlose/kostengünstige dedizierte "Monitoring-Pläne", welche sich ggf. einbinden lassen.

    Für eine wirklich garantierte Erreichbarkeit des Clusters muss sich dieses aber logischerweise über mehrere unabhängige Rechenzentren erstrecken.

    [*] hier primär auf die "Totmannschaltung" bezogen, weniger auf den TOR-Ansatz

    Das deutet jedenfalls mal darauf hin, dass ein automatischer Wechsel möglich ist.

    Den Automatismus hat jedoch der Kunde unter Verwendung der API (Methode changeIPRouting) selbst bereitzustellen; es gibt meines Wissens keine Möglichkeit, über die API eine Liste von Servern zu definieren, welche sich eine IP derart "teilen", dass bei einem definierten Ausfall des Servers, dem die IP zu diesem Zeitpunkt zugeordnet wurde, eine Übertragung seitens eines Netcup-Systems erfolgt. (Das würde ein eigenes Monitoring überflüssig machen.)

    Fänd ich auch gut. Also, eine dauerhafte Bearbeitungsmöglichkeit brauche ich nicht unbedingt, sowas macht eigentlich nur bei angepinnten Guides oder so Sinn, die eben auch Monate später noch aktualisiert werden. Aber fürs allgemeine sind die gegenwärtigen 10 Minuten dennoch arg kurz. Stattdessen 24h (oder 42h :/) würde ich als völlig ausreichend ansehen.

    Ich würde mir in diesem Zusammenhang (im Falle einer Bearbeitungsmöglichkeit über mehrere Stunden/Tage hinweg) allerdings wünschen, dass dann zumindest der Zeitpunkt der letzten Änderung festgehalten wird, und optimalerweise auch der Zeitpunkt der "Likes" wie bei phpBB, da es in diesem Fall wesentlich einfacher/öfter zu ungewollten Überlappungen (d.h. Bezugnahme auf später geänderte Inhalte) kommen kann:

    phpBB_beispiel.png

    (Wahrscheinlich müsste Netcup hierzu allerdings eine Erweiterung/Modifikation der WSF-Software installieren.)
    Vielleicht könnte man in einem ersten Schritt die Bearbeitungszeit jedoch auf 15–30 Minuten erhöhen?

    Das schreit förmlich nach einer weiteren Umfrage. ^^

    +1 :D

    Danke, dass schaue ich mir mal an. Was nutzt ihr den als OS? Standard Ubuntu oder gibt es noch OS welche auf Docker speziallsiert sind?

    Es gibt zwar spezialisierte OS (siehe beispielsweise hier und hier), aber ich rate entschieden dazu, die Finger davon zu lassen, wenn es keinen zwingenden Grund für deren Einsatz gibt (und weder "Langeweile" noch "Neugierde" sind zwingende Gründe).

    Daumenregel: Je größer die Nutzerbasis – und hiermit meine ich diejenigen Personen/Gruppen, welche das Ganze einmal aufsetzen und quasi selbst verwalten, keine indirekte Nutzung aufgrund Verwendung von Diensten wie GMail oder ähnlichen –, desto größer die Wahrscheinlichkeit, dass es potentielle Ansprechpartner und/oder Tutorials im Falle von Problemen/Fragen gibt. Das spart in der Regel Zeit und Geld.

    Was die nicht-weggekürzten Zeilen betrifft: Höchstwahrscheinlich ja. Diesen könnte man beispielsweise mit fail2ban begegnen.

    Das habe ich gemacht, aber ich komme nicht mit root > pw rein über die ubuntu Anmeldemaske.

    Welche Abmeldemaske meinst du genau? Bzw. wie verbindest du dich generell mit deinem Server?

    Von der Beschreibung her scheint frdrk davon auszugehen, dass auch beim Booten über eine LiveCD bzw. das Rettungssystem ein "normales Login" in die Umgebung möglich sei, wie es beim "normalen" Booten über das installierte System auf der virtuellen Festplatte der Fall ist.

    Wenn es darum geht, als "root" in die eigene Umgebung "einzutauchen", funktioniert das in diesem Fall tatsächlich mittels chroot /mnt/platte /bin/bash. Danach ist ein Nutzerkontenwechsel auch ganz normal via login möglich (jede Aktion erfordert zum Abschluss ein zugehöriges exit, um wieder "herauszukommen"); mittels passwd [nutzer] lässt sich somit unter anderem ein vergessenes Login-Password ändern.

    Wenn ich Webmin als erstes installiere, kann ich dann noch Cloudmin nachinstallieren oder wie läuft das ab? Ist die Reihenfolge der Installation egal? Es sind alles Module, welche sich nachinstallieren lassen?

    Auch auf die Gefahr hin, dass ich mich wiederhole:

    Wenn man sich die Texte in den vorgenannten Reitern bzw. die verlinkten Inhalte durchliest, bleiben doch keine Fragen offen? Beispiel:

    cloudmin_gpl_install_script.png

    Was hält so ein Rootserver eigentlich aus? […] Das mit 7z gepackte Backupfile war bei den erfolgreichen Backups so ca 400 MB und es hat keine 10 Minuten gebraucht, also nichts weltbewegendes eigentlich, großartig viele neue Daten sind seitdem auch nicht dazugekommen. Auf dem Server sind auch noch einige Hundert GB frei, eigentlich ist er noch fast leer, keine 10% belegt. […]

    Das geschilderte Nutzungsverhalten entspricht ja fast dem Profil eines Wunschmitnutzers auf den selbst "teil-gemieteten" Hostrechnern – da bleibt mehr Luft für die eigenen 24/7-Überlasttests marginal stärker fordernderen Abläufe auf den RS. :D

    Wenn ich die daten mit dd in ein per WebDAV gemounteten Cloud Speicher ziehe bin ich Tagelang am laden. i.d.R. gibts Probleme wenn über einen langen Zeitraum mehr wie 4-5 connections hochladen, und selbst mit 10 habe ich dann Übertragungsraten von vielleicht 500kb/s.

    Eine Möglichkeit, sich eine zweite Platte zu besorgen, wäre, stundenbasiert einen zweiten, ausreichend dimensionierten VPS zu mieten, welcher mit einer Basis­installa­tion/-partitionierung versehen wird. Das würde zumindest das Geschwindigkeitsproblem lösen, wenn btrfs restore (analog zu zfs send) via nc/netcat über das Netzwerk auf eine andere Festplatte schreiben kann. Wenn es eine lokale Festplatte sein muss, hilft das Buchen eines doppelt so großen VPS – sofern verfügbar –, das Einrichten einer zusätzlichen Partition und die Duplikation der ursprünglichen Partitionen via dd. (Tausch Zeit gegen Geld)

    […]

    Hab die Partition überprüfen lassen und versucht zu reparieren, ebenfalls nicht möglich.

    Mit btrfs restore kann ich aber Daten von der Platte nach draußen kopieren, Problem natürlich, dass ich ne zweite Platte bräuchte um die Daten wirklich rauskopieren zu können.

    Habe mit rclone einen Cloudspeicher gemountet, jedoch lässt er mir die Daten nicht in die Cloud schieben, zumindest nicht so einfach.

    […]

    Wurde die Reparatur über ein Bootimage derselben Distribution versucht oder nach "normalem" Start der KVM (sollte keinen Unterschied machen, würde Ersteres aber zur Not immer einmal probieren)?

    Wenn die Reparatur nicht möglich ist, und neben der Datenspeicherung ggf. eine Analyse auf einem anderen System angedacht ist, wäre meiner Meinung nach der Neustart über ein Bootimage gefolgt von einer Kopie des gesamten virtuellen Speichermediums mit dd das Naheliegendste (hilfsweise aus dem laufenden System heraus), was selbst mit Cloudspeicher funktionieren sollte, welcher via WebDAV (dem "einfachsten" Protokoll) eingehängt ist. Durch Verwendung von gzip o. Ä. (mit niedriger/mittlerer Kompressionsstufe) sollte eine gewisse Komprimierung möglich sein, ohne den Kopiervorgang zu stark zu verlangsamen. Alternativ wäre wohl ein Export des KVM-Speicherabbilds möglich (allerdings ggf. kostenpflichtig, sofern der Support hier nicht Kulanz walten lässt).

    Nach Sicherung der Daten bleibt im Falle eines erneuten Fehlschlags bei der Strukturreparierung durch btrfs scrub nur die Neuformatierung. Bei einer Neu­installa­tion könnte – sofern bislang nicht geschehen – der Qemu-Guest-Agent als zusätzliche Absicherung gegen das beschriebene Problem Sinn machen (reine Vermutung, aber bei dem Verschieben einer VM zwischen Hostsystemen kann der Agent anlagemäßig Dateisysteme innerhalb der KVM "kooperativ" einfrieren und wieder auftauen sowie analog bspw. die Konsistenz von Datenbanken sicherstellen; siehe hier für ein Beispiel – ohne Agent kann das Hostsystem hier insbesondere auf Anwendungs­(logik)­ebene "wenig" (=gar nichts) ausrichten).