Beiträge von vmk

    Bezügliches des Users vmk, dem TO (ThreadOpener) haben wir das nun nochmal geprüft. Das RAM bzw. SWAP Problem wurde soeben behoben, leider war hierzu ein kurzfristiger Neustart des vServers unumgänglich.


    Wie lange dauert das, bis sich diese Änderung (Neustart, SWAP-Anpassung, RAM-Anpassung) auf meinen Server auswirkt? Lese ja hier mal öfters, dass z.B. MX-Einträge 48h brauchen bis man dort eine Änderung bemerkt.

    Gestern, Fri Jun 29 16:00:01 CEST 2012

    Code
    itai-otakus ~ # uname -va
    Linux 3.0.27-vs2.3.2.3-nc #1 SMP Wed Apr 4 15:08:34 UTC 2012
    itai-otakus ~ # free -m
                 total       used       free     shared    buffers     cached
    Mem:          1024       512          256          0          0       256
    -/+ buffers/cache:          1       1022
    Swap:         1024          0       1024


    Heute, Sat Jun 30 08:00:01 CEST 2012

    Code
    itai-otakus ~ # uname -va
    Linux 2.6.33.1-vs2.3.0.36.30.3-netcup #1 SMP Mon Mar 15 19:25:25 UTC 2010
    itai-otakus ~ # free -m
                 total       used       free     shared    buffers     cached
    Mem:          2048       1553        494          0          0       1028
    -/+ buffers/cache:        524       1523
    Swap:       137431          0     137431


    Wenn ich mich recht erinnere, so sollten nur dringende Sicherheitsupdates am Host-System ohne Vorwarnung an die Kunden geschehen.

    • Wieso dieses extreme Downgrade? Welche Sicherheitslücke betrifft das konkret?
    • Welche Auswirkungen hat die neue Berechnung des RAM?
    • Da ist ja jetzt wohl RAM + Swap gemischt worden. Darf ich die 134GB Swap auch voll ausnutzen?


    update: frage nach grund des downgrade+sicherheit /nummerierung

    r.neumann, nein. Du weißt ja nicht, welche anderen Prozesse noch laufen. Du müsstest Wissen, wieviele Cores ingesamt dir zur Verfügung stehen. Dann könntest du $cores_exklusiv-1 einstellen, wenn auf dem vServer sonst absolut nichts anderes läuft.


    Doch natürlich Die vServer sind nicht "per Core" limitiert sondern in der Leistungsaufnahme der verfügbaren Cores.


    Das merkt man sehr gut wenn man mal -j12 beim Kompilieren setzt. Kurzzeitig gibt es 12 Prozesse, dann aber schon nach wenigen Sekunden bekommen nur noch 1 oder 2 Prozesse CPU-Zeit zugewiesen und die restlichen 10 Dümpeln in der Warteschlange rum. Und damit würde, r.neumann, dein Minecraft-Server ganz komischen Schluckauf haben und sicherlich sporadisch Ruckeln, weil einige Threads dann quasi verhungern.


    Alex, kann man das Core-Limit in Erfahrung bringen?

    Hat zufällig jemand Einsteiger Tipps oder App Empfehlungen? :)



    update:


    Glatt vergessen

    • MX Player - Für besseres Video und nur damit läuft bei mir Zattoo überhaupt.

    Danke!


    3.) Ich glaub die Frage müsste korrekt lauten: Welches Linux kann man standardmäßig per RDP administrieren? :D
    4.) Backup - Das ist dann auch noch immer zu 100% vollständig, sprich es wird *jede* Datei ins das Backup mit aufgenommen? (+Server ist so lange offline?). Anderer Anbieter mit 2 Buchstaben war der Meinung, es reiche ein Delta zum Basis-Image bzw. zum aktuellem Stand von Debian zu machen und hat gleich mal pauschal ein paar Ordner wie /var/run ausgenommen. Gab natürlich ein tolles Restore nachdem der RAID-Controller bei deinen gestorben war. Irgendwie hatte ich dann Teile von exim & co in der passwd und sonstwo im System verstreut drin, obwohl ich weder Debian noch Exim auf dem vServer drauf hatte.


    PS: In der Liste fehlt immer noch 'nen Gentoo ;)

    Ein paar Fragen zu den kostenlosen vServern
    - Wird da anders virtualisiert als jetzt?
    - Wie sieht es mit VPN-Support aus? Genauso mau wie jetzt?
    - Gibt es standardmäßig RDP-Support und kann man ein alternatives OS installieren? (Die Frage ist von mydealz geklaut) :rolleyes:

    Debian setzt auf Kontinuität und Stabilität und das primäre Ziel von Debian ist der Firmenserver. Dort kann man nicht jeden Tag die Schnittstellen neu anpassen. Setups werden intern ja erstmal getestet und dann ausgerollt, nachdem sichergestellt ist dass alle Anforderungen erfüllt sind. So was macht man nicht mal eben. Daher sagt Debian, dass man dort Sicherheitspatches auf das aktuelle Release zurückportiert. Leider sind die Debian-Leute auch nicht immer die schnellsten, weil hierbei oft viel Arbeit anfällt. Meist wird ja nur empfohlen, auf die aktuelle Version zu wechseln. Eine Lücke im Webserver (wenn es nicht der Apache ist!) bleibt mal gerne über 6 Monate offen (lighttpd). Der Virenscanner für den Mailserver (clamav) kann dann eben halt nicht mehr die aktuellen Signaturen verarbeiten, weil es bei Debian keine aktuellen Libraries (glibc) gibt. Das Konzept von Debian kann man mit z.B. RedHat vergleichen, nur das man dort als zahlender Kunde noch länger ältere Versionen einsetzen kann und zugleich schneller die Sicherheitsupdates bekommt.


    Einfach auf unstable zu setzen, wie sim ja anmerkt, kann auch schnell böse enden. Nur für stable wird garantiert, dass alles so läuft wie geplant.