Beiträge von PythonGame

    Also mein VPS 500 ARM G11 OST24 ist da. Irgendwie hatte ich erwartet, dass irgendwas dabei aus der normalen "Leistungs-Reihe der ARM" tanzt. Und dann ist es auch noch "Erweiterbar mit Local Block Storage: NEIN". Wobei aber der Local Blockstorage Tab von dem Server mir anbietet, auf buchen klicken zu können.


    Wenn er das könnte, wäre das mit der Anbindung der ARM Server natürlich der perfekte Server um sperrige Daten dort ablegen zu können.

    Das kann Hypervisor Schluckauf sein, meistens findest du in der Konsole Kernelnachrichten dazu.

    Hier hilft ein forcierter Neustart.

    Zumindest mein kern.log und syslog haben in dem fragwürdigen Zeitraum leider keine einzige Zeile geloggt. Daher kann ich sowas leider nicht zurückverfolgen.

    Ein Prozess ist Amok gelaufen und/oder der Swap war voll. So ziemlich gegen Mitternacht könnte ein Cronjob gewesen sein.


    Du schriebst Ausfall - Wurdest du von Netcup informiert das es technische Probleme gegeben habe?

    Da fällt mir gerade auf, dass ich nicht mal Swap eingerichtet habe o_O.

    Der kann also schon mal nicht voll gewesen sein. Und im Normalfall (bzw. Notfall) sollte ja auch der Processreaper seinem Namen alle Ehre machen. Zumal ich eigentlich immer gut 16G/32G !Available! hatte (16G inkludieren SHMEM).


    Ich habe nur einen Cronjob, der um 02:00 Uhr ein paar Ordner für ein Backup "auf Fordermann" bringt.


    Und nope. Ich wurde von Netcup nicht informiert. Wieso auch ? Nach deren Daten lief der Server ja. (Zwar nur Singlethreaded, aber er lief. :D)

    Guten Morgen,

    heute gegen 00:30 Uhr ist einer meiner Server unvermittelt unerreichbar geworden.

    Die CPU-Statistiken zeigen für den Zeitraum eine CPU-Verwendung des Kerns 4 von Konstant 953mOP/s und 0 für die restlichen.

    Für diesen Zeitraum wurden auch keine Logs mehr geschrieben.

    Zuletzt stieg die Auslastung (von Kern 4) ab 00:10 - 00:30.


    Der Rückgang ist durch einen erzwungenen Shutdown entstanden.

    Alle anderen Statistiken weisen in dem Zeitraum einen Wert von 0 auf.


    Ich kann mir da gerade kein pasendes Szenario vorstellen, was derartige Resultate provoziert... Hat jemand hier eine Idee, was passiert sein könnte ?load.JPG

    Hey, wenn du von der dockerized-Version sprichst, ja, es funktioniert.

    Ich habe das Setup aktuell selber auch so.


    Es gibt da aber ein Problem mit Netfilter (sowas wie fail2ban). Den muss man entweder deaktivieren via docker-compose.yml oder man gibt dem Container erweiterte Rechte, was aber den Sinn von lxc in stücken hinfällig macht ;)


    Wenn du netfilter deaktivieren willst, wirst du in der docker-compose.yml den Block mit netfilter und wahrscheinlich auch den Block mit ipv6 auskommentieren müssen.


    Wenn du letzteres tun willst, hast du hier noch eine Seite, auf der du nachsehen kannst, was du tun müsstest, damit du es in vollem Umfang hinbekommst: https://github.com/lxc/lxc/issues/2407 (Hier wird im allegmeinen ein Problem zwischen Docker und LXC dargestellt.)


    Bei der alten, Nicht-Docker-Version würde ich das verwenden gar nicht mehr empfehlen, da das ganze aktuell nicht mehr geupdated wird. Und die letzte unterstützte Debian-Version davon ist "8", welche jetzt auch nur noch im LTS ist.


    Es würde wahrscheinlich auch in LXC funktionieren, aber nur auf Debian 8. (Für andere Betriebsysteme schau am besten mal in den jeweiligen GitHub Repos nach.)


    (Ich nutze Debian 10.)


    ~ PythonGame

    Hat mit der Netzmaske nichts zu tun. Du hattest nur die to Parameter falsch.

    Sorry, ich hatte das falsche reinkopiert. Fakt ist, dass wenn ich die Netzmaske hinzufüge, der Container kein Internet mehr sieht. (Ein-und ausgehend.)



    Funktioniert:

    Code
    up iptables -t nat -A POSTROUTING -s 10.10.10.1 -j SNAT --to-source 185.243.10.81
    up iptables -t nat -A PREROUTING  -d 185.243.10.81 -j DNAT --to-destination 10.10.10.1


    Funktioniert nicht:


    Code
    up iptables -t nat -A POSTROUTING -s 10.10.10.1 -j SNAT --to-source 185.243.10.81/32
    up iptables -t nat -A PREROUTING  -d 185.243.10.81/32 -j DNAT --to-destination 10.10.10.1


    Wie auch immer. Das müssen wir jetzt ja nicht Ewigkeiten ausdiskutieren. Danke allen.

    Hey,

    du meinst

    Code
    up iptables -t nat -F POSTROUTING
    
    up iptables -t nat -A POSTROUTING -s 2.2.2.2/32 -o eth0 -j SNAT --to 10.10.10.1
    #up iptables -t nat -A PREROUTING  -d 2.2.2.2/32 -j DNAT --to-destination 10.10.10.1
    
    up iptables -t nat -A POSTROUTING -s 10.10.10.0/24 -o eth0 -j MASQUERADE

    ?


    Weil das funktioniert gar nicht. Also in keine Richtung.

    Hallo,

    aktuell versuche ich, mein internes Netzwerk auf einem LXC-Host zum laufen zu bekommen.

    I habe zwei IP´s:

    Code
    eine die mit meinem Server mitgeliefert wurde - sagen wir: 1.1.1.1 ("IP-1")
    und eine welche zu dem gleichen Interface gerouted wird - sagen wir: 2.2.2.2 ("IP-2")

    Ich benutze IP-1 um ein NAT zu erstellen, womit ich die meisten LXC-Container anbinde.

    Ich möchte IP-2 vollständig für einen LXC-Container verwenden. Aber die Zuweisung klappt nur in eine Richtung.


    Wenn ich IP-2 mit meinem Browser aufrufe, lande ich auf dem gewünschten Container, wenn ich aber zum Beispiel curl http://ifconfig.me/ip auf dem Container aufrufe, erhalte ich IP-1 zurück.


    Langsam gehen mir die Ideen aus, wie man das fixxen könnte. Hat hier ggf. jemand ne Ahnung ?


    Ich hänge mal hier mein Networking an:

    (Das Gateway ist für beide IPs gleich)

    (LXC-Config + Networking im Container ist auf 10.10.10.1 gesetzt)

    /etc/network/interfaces (HOST):