im moment ist der vserver (hoffentlich nur für kurze zeit) nicht erreichbar. ich musste ihn per webinterface rebooten, da ich nicht mehr auf die shell gekommen bin.
die letzten informationen, die ich noch kriegen konnte, waren:
die cpus waren alle zu 100% ausgelastet, der ram fast leer. die apache-prozesse liefen in etwa 10-facher ausführung. something's wrong...

wenn da nicht irgendein witzbold mit RST-packeten rumfunkt, muss ich mal die installation prüfen.

btw: eine zeitlang wurde mein root-pw nicht anerkannt. entweder hat jemand etwas kindisches getan oder - was wahrscheinliches ist - der server war sogar zu sehr ausgelastet, um die login-prozedur korrekt durchzuführen.

update:
ok, inzwischen bin ich wieder "reingekommen". allerdings ist das problem nicht verschwunden. folglich liegt es wahrscheinlich nicht an uns.
ich kann keine befehle ausführen, da sie immer mit einem "cannot allocate memory" quittiert werden. das bedeutet, dass der ram zu knapp ist, um irgendwas zu machen.
folglich hat vermutlich irgendein penner, der auf derselben maschine seinen vserver laufen hat, den ram sinnlos verbraten.
wir können wohl nur abwarten und cola trinken.
wenn morgen aber immer noch nix läuft sollten wir vielleicht server4free kontaktieren.

ich mein ja nur um uns abzusichern. nicht dass unser vserver gerade abschmiert und wir plötzlich ohne gelegenheit zum backup leer vor einer erzwungenen neuinstallation dastehen.
im moment klappts wieder. allerdings überläuft der httpd nach kurzer zeit stets wieder. komisch...

a propos backup:
was haltet ihr davon, wenn ich, sagen wir: einmal pro monat, alle konfigurationsfiles, scripte und html-dateien auf einen lokalen datenträger sichere?
(die videos und die bilder gehen natürlich auch, nur verbraten wir dabei natürlich mehr traffic)

weil: die ganzen scripte habe ich hier nicht. die wurden direkt auf dem vserver erstellt und existieren nur dort...

ok. ich habe gerade ein kleines backup-script geschrieben. das wird automatisch jeden sonntag um 1 uhr morgens gestartet, archiviert sämtliche relevanten konfigurationsdateien sowie alles im webbereich (wobei es alle dateien, die mit "avi", "mov" oder
"wmv" enden, ignoriert) in eine komprimierte datei und verschickt dann diese an einen meiner heimrechner.

es scheint schonwieder probleme zu geben. ich schlage daher folgendes optimierungspacket vor:
1) javascriptfähige browser werden auf eine javascript-variante der index.html weitergeleitet. dadurch wird das twoframes-cgi nicht so stark beansprucht.
2) alle nicht-interaktiven cgis werden nur noch 2 mal pro tag per cron ausgeführt und erzeugen statische seiten (ev. mit "last update"- und "next-update"-angaben). so verursacht nicht jeder einzelne seitenaufruf eine reihe von scriptaufrufen.

wenn alle damit einverstanden sind versuche ich das heute abend umzusetzen. hat wohl die höchste priorität im moment, da alles andere nix nützt, wenn die seite nicht erreichbar ist.

kann den vserver auch nicht erreichen. gestern abend meldete er wieder ramknappheit.
was heute genau los ist kann ich nicht sagen, logischerweise

der server wurde offenbar kürzlich rebootet. vielleicht im zuge eines vollen reboots (also nicht nur des v-servers).
ich glaube, deshalb war er vor 2-3 tagen mal nicht erreichbar...denn die aktuelle uptime beträgt, wie ich gerade erstaunt festgestellt habe, nichtmal 3 tage.

was soll der scheiss?
der vserver wurde vor etwa 14 stunden schon wieder rebootet...

und offenbar ist per default das logrotate falsch konfiguriert, weshalb fast alles in /var/log/* leer ist...

ein reboot hat zur folge, dass alle services resettet werden und alles neu initialisiert wird. (nichts anderes als wenn man einen heimcomputer neustartet halt).
da ich kein reboot durchgeführt habe, gehe ich davon aus, dass das ganze hostsystem neugsestartet wurde. der vorgang kann durchaus 2 oder mehr stunden dauern, wenn 100 gastsysteme drauf sind...

ich vermute mal stark, dass server4free ihr system nicht wirklich im griff haben und daher des öfteren mal mit kernel panics zu kämpfen haben. wenn man sich das vorinstallierte system anschaut, zeugt das jedenfalls nicht von langjähriger linux-erfahrung...

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>
ab sofort erhalten Sie bei einer Neuinstallation Ihres vSERVER folgende

Software:



- RedHat 9,<hr></blockquote></p>
hab bisher nix wirklich negatives darüber gehört. nur dass es für privatkunden nicht mehr redhat, sondern jetzt fedora heisst.
wir müssen wohl die vor- und nachteile abwägen. gerade bei systemen mit knappen ressourcen ist es oft die bessere lösung, alte software zu verwenden.
allerdings weid der kernel eh upgradet worden sein, da dieser ja auf dem ganzen hostsystem genutzt wird...
<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>

- Apache 2.0.48,<hr></blockquote></p>
soll effizienter sein als die vorgängerversion. da die konfiguration aber auch umgekrempelt wrude, müsste ich diese fast komplett neu schreiben. mal sehen...

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>
- PHP 4.3.4,<hr></blockquote></p>
php ist mir ziemlich egal. ich mag lieber vollwertige scriptsprachen *indeckunggeh*
<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>
- phpMyAdmin 2.5.4,

- Confixx Light 1.7.0,
<hr></blockquote></p>
brauche ich beides nicht.

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>
- und proftpd 1.2.8<hr></blockquote></p>
das ist allerdings vom sicherheitsaspekt her sehr gut. könnte ich natürlich auch manuell upgraden...


<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>
Auch in punkto Hardware gibt es einige, neue Änderungen:

- 50% mehr Kernel Speicher,

- 33% mehr private Speicher,

- 25% mehr shared Speicher,

- und 250 TCP Sockets anstatt 80.
<hr></blockquote></p>
na das ist mal wirklich positiv.

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>
Einen Reboot Ihres vSERVERS können Sie jetzt auch mit dem Befehl/Kommando \'reboot\' ausführen.<hr></blockquote></p>
wow. geniales feature. extra für vserver entwickelt, was?
btw: it's better to use 'shutdown -r' than 'reboot' (softreboot)


<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>
Um all diese Erweiterungen - für Sie als vSERVER-Kunde natürlich kostenlos -

zu erhalten, müssen Sie eine Neuinstallation in Ihrem Kunden-Interface

beantragen.<hr></blockquote></p>
webinterfaces sucken

<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>
Bitte beachten Sie zudem, dass wir auch aus Sicherheitsgründen eine

Neuinstallation dringend empfehlen. Da RedHat den Support für die Version

7.3 eingestellt hat, werden keine Sicherheits-Updates mehr veröffentlicht,
<hr></blockquote></p>
naja, das ist gut gemeint, aber nur weil es keine offizellen bequemen redhat-sicherheitsupdates mehr gibt, heisst das nicht, dass keine bugfixes und securitspatches mehr entwickelt werden. den kernel kann man beim vserver ja eh nicht anrühren und überhaupt ist ein admin, der sich nur um die von der distribution ausgestellten/erwähnten sicherheitslücken kümmert (und nicht service-/programmspezifisch informiert bleibt) kein guter admin.
<p><blockquote><font size="1" face="Verdana, Arial">Quote:</font><hr>
was Ihren vSERVER gegenüber Hackern zu einem leichten Ziel macht.


<hr></blockquote></p>
argh. warum muss jeder trottel die bezeichnung "hacker" völlig aus dem zusammenhang reissen und und dessen wahre bedeutung unterwandern?


fazit:
auf der einen seite gibts definitive vorteile einer neuinstallation - auf der anderen heisst es nicht umsonst: "never change a running system". bei einer neuinstallation müsste ich die gesamte konfiguration neu schreiben, sämtliche zusatzsoftware neu installieren und ausserdem ein backup aller daten zurückspielen. letzteres habe ich allerdings nicht, nur von den scripts und html-dateien.

wir sollten das besprechen. zumindest die, die dafür bezahlen.

noch keine meinung?

ich persönlich bin für die neuinstallation. erfordert zwar dann ein paar stunden zeit, bis alles wieder so läuft wie es soll, aber die neuen ressourcen lohnen sich imho.
ausserdem wird dann vielleicht endlich dieser komische bug mit den logfiles (seit einiger zeit bleiben sämtliche logfiles in /var/log leer...keine ahnung warum) behoben.