Beiträge von m_ueberall

    Auch fein wäre es, wenn es (gerne auch irgendwo versteckt nur für Bestandskunden), gegen kleinen Rabatt, Produkte OHNE jegliche externe NIC / IP Adressen gäbe.

    Sowas gab es früher wohl tatsächlich schon einmal (allerdings zum gleichen Preis wie äquivalente Produkte mit IPv4, lediglich die Einrichtungsgebühr entfiel – in der genannten Preiskategorie allerdings auch nicht sonderlich verwunderlich):

    Code
    % grep ">VPS 10 G7 IPv6<" * | sort -k1 | tail -1; grep ">VPS 20 G7 IPv6<" * | sort -k1 | tail -1
    netcup_produkte.xml.2017-05-26:         <ProduktName>VPS 10 G7 IPv6</ProduktName>
    netcup_produkte.xml.2019-03-02:         <ProduktName>VPS 20 G7 IPv6</ProduktName>

    Leider ist es so, dass bei den Servern welche sich im VLAN befinden die externe NIC nicht vom HOST aus deaktiviert werden kann. Hier könnte ich mir die vorgeschaltete Firewall durchaus vorstellen um ausschließlich Traffic über das VLAN zuzulassen. Ansonsten könnte es durch einen Konfigurationsfehler oder Upgrades dazu kommen, dass die NIC unerwünscht wieder aktiv wird.

    Schon einmal probiert, die Schnittstelle ens3/eth0 mittels udev-Regel auszublenden (siehe hier)? Die VLANs haben ja ihre eigene (wie von Doim1990 erwähnt):

    Code
    [2021-04-25T16:47:24+0200] root@vserver17<kvm>:~/bin# ls -l /sys/class/net
    total 0
    drwxr-xr-x  2 root root 0 2021-04-25 07:05:03 ./
    drwxr-xr-x 68 root root 0 2021-04-25 07:02:59 ../
    lrwxrwxrwx  1 root root 0 2021-04-25 07:05:05 ens3 -> ../../devices/pci0000:00/0000:00:03.0/virtio0/net/ens3/
    lrwxrwxrwx  1 root root 0 2021-04-25 07:05:04 ens4 -> ../../devices/pci0000:00/0000:00:04.0/virtio1/net/ens4/
    lrwxrwxrwx  1 root root 0 2021-04-25 07:05:07 ens6 -> ../../devices/pci0000:00/0000:00:06.0/virtio2/net/ens6/
    lrwxrwxrwx  1 root root 0 2021-04-25 16:47:30 lo -> ../../devices/virtual/net/lo/

    Die Datei, in welcher man die Regel ablegt, lässt sich ja mittels chattr +i vor Veränderungen schützen (kein normales Update-Script wird sich über dieses Attribut hinwegsetzen). Das ist zwar weniger narrensicher als eine Deaktivierung/Entfernung der Schnittstelle in der KVM-Definition (welche im SCP derzeit nicht unterstützt wird), aber kaum unabsichtlich umkehrbar.

    (Der obige udev-basierte Ansatz setzt natürlich die Nutzung von Linux voraus, aber bei anderen Betriebssystemen sollten sich Alternativen finden.)

    Kenne das von der Konkurrenz auch.

    Bevor hier eine mehrstellige Anzahl von Bestandskunden allerdings zu Supportanfragen bzgl. erneuter Freischaltung gedrängt wird, sollte man das aber besser ausschließlich als Buchungsoption (gegen entsprechenden Aufpreis) anbieten. Oder potenzielle Neukunden müssen eben zu besagter Konkurrenz wechseln (die das sicherlich auch entsprechend ein-/bepreist).

    Da die überwiegende Mehrheit der VPS-/RS-Nutzer sicherlich absichtlich Dienste auf verschiedenen Ports anbietet und eine regelmäßige (Selbst-)Kontrolle der laufenden Dienste implementiert haben sollte (entsprechende Standardhilfswerkzeuge/-dienste sind seit Jahren Bestandteil jeder Linux-Distribution), sehe ich persönlich keinen Nutzen einer externen Firewall und würde entsprechende Angebote explizit meiden. Wer sich einen zusätzlichen Schutz dadurch verspricht, der sollte zudem bedenken, dass viele/genügend Attacken (ein- und von infizierten Systemen insbesondere ausgehend) über Standardports abgewickelt werden.

    Die Funktion würde z.B. verhindern, dass Docker mal wieder ungefragt Ports öffnet.

    Und um genau solche Szenarien wie zb Docker gehts. Außerdem könnte man trotz aller Absicherung dann in der Provider Firewall seinen SSH Port sperren. Wenn man dann auf den Server will lockt man sich vorher im Provider Menü ein und macht die Regel auf.

    Wenn Docker mal wieder(!!!) ungefragt(!) Ports öffnen kann, die von außen ansprechbar sind, dann ist das ein grundlegendes Konfigurationsproblem, welches ich mit dem Betrieb eines offenen E-Mail-Relays gleichsetzen würde (deutlich formuliert: grobe Fahrlässigkeit des Betreibers). Solange ich Anwendungen nicht hinreichend vertrauen kann, gehören sie gar nicht installiert oder hilfsweise in einen unprivilegierten Container, dessen Ein- und Ausgaben überwacht werden. Und spätestens(!) sobald die Alternative Podman (weniger "Docker rootless") scheinbar(!) keine Option ist, gehört eine Docker-basierte Installation ihrerseits in einen wirklich unprivilegierten Container.

    Gerade einen SSH-Port würde man in der Praxis entweder nur via VPN (inklusive Zugriffsadressen-/Schlüsselkontrolle, -rotation, usw.) oder über knock o.ä. öffentlich verfügbar machen oder überhaupt erst "on demand" über die existierende virtuelle Konsole starten.

    Wenn $out wirklich das o.g. JSON-Konstrukt enthält, sollte var_dump($decoded) das Problem aufzeigen – die Ausgabe ist nämlich NULL.

    Code
    % cat test.json.org| jq .
    parse error: Invalid numeric literal at line 15, column 25

    Wenn man die Auslassungpunkte ... in Anführungszeichen setzt, geht's.

    Würde der gleiche Effekt beim Webhosting 2000 Produkt auftreten? Hier sind 4GB Ram garantiert, würde das helfen oder wäre hier gleiches zu beobachten?

    Die Frage ist, wo die 4GB garantiert werden. In der Regel würde man (ich) davon ausgehen, dass das gemietete Konto diesen Speicherbereich für eigene Scripts/Prozesse allokieren kann. Sofern der Webserver aber nicht unter vollständiger eigener Kontrolle läuft (wie bei einem VPS/RS, also ein oder mehrere individuelle Webserver-Instanzen pro Kunde), sondern nur vom Host aus auf den gemieteten Plattenplatz/RAM-Bereich zugreift, stellt sich die Frage, wie der Cache des Webservers dimensioniert ist, welcher immer zuerst kontaktiert und typischerweise in Abhängigkeit von Zugriffszeitpunkten/-häufigkeiten – aus Sicht der Webserver-Instanz, d.h. bezogen auf alle bedienten Kunden – befüllt/geleert wird.

    Die Produktbeschreibungen enthalten meines Wissens keinerlei Aussagen über eine Cache-Garantie (=zusätzlich benötigter Speicher, insbesondere aber angepasstes Cache-Verhalten, sofern sich mehrere Kunden den-/dieselben Webserver teilen).

    Aelenius : Wenn das Netzwerk momentan sowieso nicht funktioniert, sollten ggf. zwei zusätzliche Reboots nicht schaden – Sofern Du also nicht schon Erfolg bei der Anpassung der Netzwerkkonfiguration oder zuvor auf dem neuen VServer erfolgreich das vorinstallierte Betriebssystem diesbezüglich ausprobiert hattest, würde ich vorschlagen, temporär das Rettungssystem zu booten und zu schauen, ob dort eine öffentliche IP-Adresse zur Verfügung steht (was der Fall sein sollte!). Wenn das auch nicht funktioniert, ist das ein Fall für den Support und die Anpassung der vorgenannten Netzwerkkonfiguration wird Dich alleine wohl nicht ans Ziel bringen.

    Sofern eine Spezialkonfiguration den Einsatz des Netcup-Rettungssystems nicht verhindert, schadet ein initialer Test desselben grundsätzlich niemals.

    Ich würde preg_replace() verwenden, insbesondere, wenn <span class="table-cell-item language">...</span> im vorliegenden Fall nur einen/mehrere Ländercodes kapselt, also wirklich alles rückstandsfrei entfernt werden kann und darin keine weiteren <span>s mehr vorkommen können:

    PHP
    <?php
    $zeichenkette = '<span class="other">Hello.   <span class="table-cell-item language">LÄNDERCODE</span>  <em>Bye.</em></span>';
    $suchmuster = '/<span class="table-cell-item language">.*?<\/span>/';
    $ersetzung = '';
    echo preg_replace($suchmuster, $ersetzung, $zeichenkette);
    ?>

    Einfach und schlank? Schau dir mal Munin an. Manche stört halt, dass es immer noch aussieht wie aus dem letzten Jahrtausend (was es ja auch ist). Aber es tut halt auch seit damals seinen Job.

    Noch schlanker als Munin ist allenfalls Monit, wenn es auf die grafische historische Aufbereitung nicht ankommt, sondern eine Reaktion/Alarmierung im Vordergrund steht (über eine Zusatzdefinition lassen sich auch Dateisysteme überwachen):

    monit_ram.png

    Dann sollen Sie einfach die IP des Server ändern, auf eine wo alles passt... Solche IPs gibts bei Netcup... Wo ist das Problem? Keines, Sache wäre erledigt.

    Eben nicht! Das zugrundeliegende Problem ist, dass Netcup hierdurch Verwaltungsaufwand entstehen würde (ggf. sogar Vertragsänderung(en) bzgl. gemieteter IP-Adresse(n) – vielleicht nicht im vorliegenden Fall, aber u. U. bei einem anderen Kunden zwecks Gleichbehandlung), welcher durch Delegation an die richtige Stelle eben nicht anfällt. Dieser Aufwand ist einzupreisen (inkl. Mitarbeiter-/Zeitaufwandskosten, welche hier ganz schnell die Gewinne aus den betroffenen Mietverträgen auffressen können und/oder quersubventioniert werden müssten – worauf wiederum ich sehr gut verzichten kann!) und in dem Kontext zu bewerten, dass hier die temporären Seiteneffekte die Angebotsbeschreibung/die versprochene Leistung ebennicht tangieren, wie bereits mehrfach weiter oben in diesem Diskussionsfaden ausgeführt wurde:

    Fakt ist: du hast hier einen Server gemietet und nicht die Garantie dass irgendwelche Geo-geblockten Dienste die IP-Ranges dieses Servers annehmen. Und der Server an sich läuft ja anscheinend. Wenn ich dir ein "Designer T-Shirt" verkaufe / netcup dir einen in Deutschland gehosteten Server vermietet und irgendein Türsteher entscheidet dass du damit nicht reinkommst / irgendeine Website meint dass dir die IP/WHOIS-Eintrag nicht passt, ist das ja nicht mein / netcups Problem, dann beschwer dich beim Betreiber der Disko / bei dem Geo-geblockten Anbieter und nicht bei H&M / netcup ^^

    Sorry aber ich find solche Vergleiche immer treffend. Lies dir mal den Vertrag durch den du geschlossen hast. Da steht sicher nicht drin "wir garantieren Ihnen dass Sie mit diesem Server überall reinkommen".

    Dessen ungeachtet bleiben ja immer noch die Handlungsmöglichkeiten auf Nutzerseite (mir fallen da aus dem Stegreif zwei Ansätze ein; einen hatte ich bereits früher erwähnt) :

    Leider nach wie vor Standort Österreich. Der Support hat es nicht nötig auf das Ticket zu Antworten. Gut, dann gibts eben andere Möglichkeiten

    Yes, there will definitely be some kind of limit. There is no other way in such shared environments. The only question is whether these limits are communicated transparently or not. Probably not in this case. But given the prices, it's quite understandable.

    Maybe this (older) (machine translated) German discussion thread could be of interest? "Throttling of hard drive throughput"

    Leider nach wie vor Standort Österreich. Der Support hat es nicht nötig auf das Ticket zu Antworten. Gut, dann gibts eben andere Möglichkeiten

    Eine der Möglichkeiten wäre natürlich auch das temporäre Buchen einer zusätzlichen IP-Adresse. (Da man eine solche im SCP sieht, bevor sie einem Server fest zugeordnet wird, ist hier eine Vorabprüfung möglich.) Für einen Privatanwender je nach bereits gebuchten Leistungen sicherlich auf den ersten Blick ein ärgerlicher Kostenfaktor, im beruflichen Umfeld aber IMHO eine naheliegende Entscheidung – Zeit ist Geld und Nutzer-/Kundenzufriedenheit ist ebenfalls "einfach" einzupreisen.