• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

vhcs 2.8. RC1 - Fehler im Adminpanel (/dev/shm)

hempelr

New Member
vhcs ist ja (noch) nicht tot, und es sind wohl auch keine Lecks bekannt geworden.
Nun hab ich zum Glück noch eine Downloadadresse für die 2.8. RC1 gefunden und auch ein Tut, welches funktioniert hat (DL unter VHCS 2.4.8 RC1 Debian Etch (PHP5 & MySQL5) | live|blog und Tut unter abmatten.de Forum &bull; Thema anzeigen - [HOWTO] VHCS 2.4.8 RC1 auf Etch mit PHP5 und MySQL5 >UPDATE 2< )
Leider hat ja serverforum.info seine Pforten geschlossen und ist nicht hierher migriert.
Frau Google bietet eine Lösung für das Problem an, die aber nicht mehr erreichbar ist:
Das Serverforum !
Vielleicht hat das ja jemand archiviert oder auch ne Lösung fur folgendes Problem im gesamten Teil der Serverinfos im Adminpanel:
Notice: Undefined index: /dev/shm in /var/www/vhcs2/gui/include/class.Linux.inc.php on line 525
Notice: Undefined index: /dev/shm in /var/www/vhcs2/gui/include/class.Linux.inc.php on line 533
Notice: Undefined index: /dev/shm in /var/www/vhcs2/gui/include/class.Linux.inc.php on line 534

Möchte gern vhcs2 weiterverwenden auch unter Debian Etch mit php5x und MySQL5x, meine Erfahrungen mit vhcs sind bisher ziemlich positiv.
Schade nur, dass die zwei wichtigsten Foren, die eine wahre Fundgrube für VHCSler waren, nicht mehr offen sind (serverforum.info und sysop-forum.de), da hat man so zu ziemlich allen ProbProblemen eine Lösung gefunden bzw. bekommen.
Wäre ganz toll, wen da irgendwie angeknüpft werden kann...das tut echt not ;-)
 
Was steht denn in Zeile 525 - 534? Leider finde ich bei meinem VHCS nicht einmal die Datei, wahrscheinlich weil es nicht 2.8 RC1 ist. Aber der Fehler kommt mir noch bekannt vor also wäre nett wenn du den Ausschnitt posten könntest.
 
fraglicher Block aus der php-datei

hier der "fragliche" Block: (ab Zeile 525 der Datei class.linux.inc.php)
PHP:
            if ($show_bind || !stristr($fsoptions[$ar_buf[5]], "bind")) {
              $results[$j] = array();
              $results[$j]['disk'] = $ar_buf[0];
              $results[$j]['size'] = $ar_buf[1];
              $results[$j]['used'] = $ar_buf[2];
              $results[$j]['free'] = $ar_buf[3];
              $results[$j]['percent'] = round(($results[$j]['used'] * 100) / $results[$j]['size']);
              $results[$j]['mount'] = $ar_buf[5];
              ($fstype[$ar_buf[5]]) ? $results[$j]['fstype'] = $fstype[$ar_buf[5]] : $results[$j]['fstype'] = $fsdev[$ar_buf[0]];
              $results[$j]['options'] = $fsoptions[$ar_buf[5]];
              $j++;
            }
MOD: Bitte entsprechende Tags benutzen!

Hoffe, dass das vielleicht die Lösung näher bringt.
Übrigens kommt der Fehler "Nur" bei Menüpunkt Systemtools-Übersicht

Für nen Tipp wäre ich echt dankbar
 
Last edited by a moderator:
Ich kann mich noch genau an den Fehler erinnern aber irgendwie finde ich den nicht mehr obwohl alle Beiträge vom Serverforum.info hier her importiert wurden. Ich glaube wir hatten sogar ein Workaround gecodet.
 
shit happens - das ist echt schade....

mhm - das ist echt schade...
hier nochmal die Adresse die Google findet, vielleicht kannnst dus ja doch noch rekonstruieren

ww_w.serverforum.info/archive/index.php/t-83.htm
ww_w.serverforum.info/showthread.php?p=1471

freu mich auf ne Lösung ;-)
 
Such doch bitte mal in der class.Linux nach folgenden Variablen wo die gesetzt werden:
Code:
$ar_buf[5]
$ar_buf[0]
 
leider etwas php-"spast"

mhm, nicht ganz easy, aber auf alle fälle hängt es mit dem Rückgabewert des Mount-Befehls zusammen.

Bin eher ein php-dilletant, perl ist mir lieber ;-)
Aber es hängt mit dem Zähler zusammen, mount gibt unter dem neuen System 9 Zeilen zurück, unter dem "alten" System 8 Zeilen, hier mal die Ergebnisse:
----Server mit "altem" Etch und php4/mysql4 wo Fehler nicht auftritt:
Code:
s561:~# mount
/dev/hda1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
/dev/hda6 on /zz_rescue type ext3 (rw)
/dev/hda7 on /var/www type ext3 (rw)
usbfs on /proc/bus/usb type usbfs (rw)
----und "neuer" Server
Code:
s701:~# mount
/dev/hda1 on / type ext3 (rw,noatime)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/hda2 on /var/www type ext3 (rw,noatime)

Mit den Tags komm ich bestimmt nicht klar, find diese bb-codes einfach nur doof, es sei denn, da wäre ein Editor, der das vereinfacht. (sorry, dass ich das so unverfroren feststelle, soviel wie es Bulletin-Boards gibt, soviel Tags gibt es - html mit css oder Perl oder irgendwas anderes klar standardisiertes bin ich willens einzusetzen bzw. zu lernen;-)

Hoffe, dass das jetzt der Problemlösung keinen Abbruch tut und doch noch was gefunden wird bzw. eine Idee auftaucht....
 
Such einfach per grep in dem Script nach den oben genannten Variablen du musst das Script nur dazu bekommen dass es /dev/shm ignoriert.
 
Hi,
ich kann jetzt nicht wirklich viel zum Thema VHCS beisteuern, da ich es nie benutzt habe, aber zu eurem Threads..
Den google-Cache kennt ihr?
Error im Admin menue - Seite 2 - Das Serverforum !

Ok, Kommando zurück. Ignoriert das einfach und akzeptiert es. Es sollte niemandem weh tun, das is halt nen kleiner Bug der 2.4.8rc1, der nie behoben wurde, weil er auf eine virtuelle Partition zugreifen will, die gar keine is. Danach fliegt er dann bei der Ausgabe eines Arrays auf die Schnauze, daher die Fehlermeldungen. Sollte aber im Prinzip völlig ungefährlich sein.

Mit freundlichen Grüßen
Flobbie
 
Ja kenne ich ;) aber wir hatten mal eine Loesung dafuer das sind nur ein paar Zeilen code die veraendert werden muessen. Vielleicht kannst du die Datei mal hochladen dann scau ichs mir nochma an.
 
so, quick and dirty-Workaround

Für alle dies betrifft und interessiert ein quick and dirty-Workaround, der allerdings wirklich nur diesen einen Fehler "kaschiert", aber so funktionieren müsste:

Datei /var/www/vhcs2/includeclass.Linux.inc.php ergänzen in um Zeile Zeile 524, (or der Anweisung if ($show_bind || !stristr($fsoptions[$ar_buf[5]], "bind")... wie folgt:
Code:
               if (!eregi("dev/shm",$ar_buf[5])){
                  if ($show_bind || !stristr($fsoptions[$ar_buf[5]], "bind") ) {
                    $results[$j] = array();
                    $results[$j]['disk'] = $ar_buf[0];
                    $results[$j]['size'] = $ar_buf[1];
                    $results[$j]['used'] = $ar_buf[2];
                    $results[$j]['free'] = $ar_buf[3];
                    $results[$j]['percent'] = round(($results[$j]['used'] * 100) / $results[$j]['size']);
                    $results[$j]['mount'] = $ar_buf[5];
                    ($fstype[$ar_buf[5]]) ? $results[$j]['fstype'] = $fstype[$ar_buf[5]] : $results[$j]['fstype'] = $fsdev[$ar_buf[0]];
                    $results[$j]['options'] = $fsoptions[$ar_buf[5]];
                    $j++;
                  }
               }
Also konkret heisst das, dass der Block mit der Generieurng der Arrays für die Ausgabe der Dateisysteme nur ausgeführt wird, wenn das Dateisystem nicht den String "dev/shm", der mittels der Bearbeitung der Rückgabewerte des Linux-Shellbefehls mount enthält.
Es wird also einfach eine zusätzliche Bedingung für die Ausgabe der Dateisysteme gestellt.
Den gesamten Code der Funktion so anzupassen, dass es egal ist, welches Filesystem da von mount angezeigt wird, ist imho nicht unbedingt notwendig, man kann aber "einfach" die super dokumentierten Funktionen von phpsysadmin dazu benutzen (was hier offenbar auch von den VHCS-Programmieren getan wurde, nur wurde es halt nicht weiter mit geupdatet)

Na dann, vielleicht hilft die Lösung ja noch anderen ausser mir ;-)
 
VHCS: tot oder nicht tot,...

... das ist hier die Frage.
Leider hat ja serverforum.info seine Pforten geschlossen und ist nicht hierher migriert.
Möchte gern vhcs2 weiterverwenden auch unter Debian Etch mit php5x und MySQL5x, meine Erfahrungen mit vhcs sind bisher ziemlich positiv.
Schade nur, dass die zwei wichtigsten Foren, die eine wahre Fundgrube für VHCSler waren, nicht mehr offen sind (serverforum.info und sysop-forum.de), da hat man so zu ziemlich allen ProbProblemen eine Lösung gefunden bzw. bekommen.
Wäre ganz toll, wen da irgendwie angeknüpft werden kann...das tut echt not ;-)

Nun, mein Beitrag tut zunächst nicht viel zur eigentlichen Sache. Aber die Leutz hier haben sich viel Arbeit gemacht und nahezu sämtliche sachlichen/fachlichen Beiträge von serverforum.info hierin migriert. :)
Nun gut, dass Google nicht auch den Sprung schafft, kann man nicht ändern.

Aber für alle ehemaligen serverforum.info user meine Info, hier sind nicht nur die alten Beiträge sondern auch noch die alten Hasen. Daher ist eben hier die neue Anlaufstelle für Fragen rund um VHCS. :D
 
Last edited by a moderator:
Das ist gut - und macht auch Mut...

danke für die Mitteilung.

Ich denke, VHCS ist noch nicht tot, ISPCP ist nach meinen Versuchen vom vergangenen Jahr eher einen Zacken problematischer, die "neuen" Dinge sind doch recht "wackelig", was ja auch das Forum von ISPCP verrät. Eine Final gibt es noch nicht. Die Oberfläche gefällt mir persönlich auch nicht so richtig und auf nem "schwachen" Server läuft es auch mehr als zäh...

Wenn man sein System auf dem Server mit den notwendigen Sicherheitsupdates versorgt und manuell einiges an der Sicherheit geschraubt wird (fail2ban, rootkithunter, SSH-Port verlegen etc.pp) dann ist auch kein direktes Risiko in Bezug auf Sicherheit in der 2.4.8 RC1 bekannt geworden. Flink ist es allemal, ziemlich gut dokumentiert war es mal.
Man findet gelegentlich noch einiges dazu (schade dass das Sysop-Forum geschlossen hat und auch nix davon irgendwohin migriert worden ist; der Zweig zu VHCS war echt ziemlich "allumfassend". Das geflügelte Wort "Wissen ist Wissen wos steht" verliert dadurch leider seinen Sinn...
Trotzdem oder gerade deshalb an alle, die sich immer wieder mit Ihrem Wissen und Können einbringen herzlichen Dank für das Engagement und die Hilfe.
 
Back
Top