[HOWTO]Linux-VServer ispcp-daemon legt User nicht an

[beugel01]

Hallo,
ich hoffe, dass ich jetzt nicht doppelt Poste hab aber nichts darüber gefunden.

Ich verwende Debian Lenny und den Linux-VServer http://linux-vserver.org/.

Seit einiger Zeit können meine Gast-Systeme keine neuen User mehr anlegen bzw. löschen.

Grund ist dafür ist dass der ispcp-daemon die Verbindung abbricht. Warum das früher ging und jetzt nicht mehr, keine Ahnung. Ich vermute, dass sich irgend etwas in php geändert hat. So dass socket_connect nicht mehr funktioniert.

genauer die do while Schleife in /var/www/ispcp/gui/include/ispcp-functions.php function read_line(&$socket) läuft sich tot ...

Wie auch immer. Wenn ich in tools/daemon/take_connection.c Zeile 14 meine IP eintrage geht es wieder.

PHP Code:

if (strcmp(client_ip,"[hier meine IP]")) { 


Dann make und den ispcp-daemon nach /var/www/ispcp/daemon/ kopieren.

Testen kann man das relativ einfach.
telnet [meine ip] 9876:
250 OK ispCP Daemon v1.1 Welcomes You!

Kommt diese Meldung "250 OK ..." nicht und man fliegt direkt wieder raus. Könnte dass der Grund sein.

Ich hoffe jemand kann damit etwas anfangen. Das betrifft im übrigen alle ispcp Versionen da die Zeile if (strcmp(client_ip,"127.0.0.1")) { schon in 1.0.0 RC1 drin ist.

[BeNe]

Quote:Wenn ich in tools/daemon/take_connection.c Zeile 14 meine IP eintrage geht es wieder.

Und welche IP trägst Du da ein ? Die vom Gastsystem ?
Gingen denn alle Gasysteme mit ispCP auf einmal nicht mehr oder erst nach einem Update von ispCP selber ?

Greez BeNe

[beugel01]

Hi BeNe,

Quote:Gingen denn alle Gasysteme mit ispCP auf einmal nicht mehr oder erst nach einem Update von ispCP selber ?

keine Ahnung ich lege nicht jede Woche neue "Domains/Kunden" an.
ispCP habe ich aber nicht geupdatet. Nur Debian selbst.
Ich habe drei Gast-Systeme eins war noch auf RC7 die anderen auf 1.0.3 und alle gingen "auf einmal nicht mehr ;-)" OK einige Debian Sicherheitsupdates liegen da schon dazwischen.

Ich habe dann auf meinem lokalen Rechner noch einen weiteren Vserver aufgesetzt und dem hab ich die ip 10.1.1.1 gegeben. Ging auch nicht (Kunden anlegen/löschen).
Fehlermeldung:
Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/ispcp/gui/include/ispcp-functions.php on line 55

Die do-while schleife in der ispcp-functions.php wird halt nie beendet.

PHP Code:

function read_line(&$socket) {
        $ch = '';
        $line = '';
        do {
                $ch = socket_read($socket, 1);
                $line = $line . $ch;
        } while ($ch != "\r" && $ch != "\n");
        return $line;
} 


Dann mit "telnet localhost 9876". Verbindung funktioniert allerdings fliegt man ohne Kommentar wieder raus.

Dann die IP 10.1.1.1 in die take_connection.c und ich bekomme die Meldung:
telnet localhost 9876
250 OK ispCP Daemon v1.1 Welcomes You!

Es kann also am Kernel/Vserver-Netzwerkeinstellung, php, oder sonst wo liegen ich weiß nicht genau woran es liegt ...

Debian Kernel 2.6.26-2-vserver-686 / vserver 0.30.216-pre2772

Grüße
Beugel

[BeNe]

Ich habe so ein ähnliches phenomen unter FreeBSD in einer Jail.
Liegt hier aber sicher an eine fehlenden Funktion die nicht erlaubt ist.
Denke da ebenfalls in die Richtung das kein Socket erstell werden darf.

Leider kenne ich mich mit vserver dirket garnicht aus.
Gibt es hier Restriktionen ?

Greez BeNe

[beugel01]

(04-05-2010 08:30 AM)BeNe Wrote:  Leider kenne ich mich mit vserver dirket garnicht aus.
Gibt es hier Restriktionen ?

Ja, der Linux-Vserver benutzt den Kernel des Hosts. Das Gastsystem hat also keinen eigenen Kernel. Die Hardware wird also nicht simuliert wie bei z.B. Virtual-Box, VM-Ware ...
Daher muss man die Serverdienste die auf dem Hostsystem laufen auch an ein eine IP binden die von keinem anderen Vserver genutzt wird. Da sonst der Port im Vserver z.B. bei ssh belegt ist und der Dienst nicht gestartet wird.

Ich bin mir inzwischen auch sicher, dass sich irgend etwas am Vserver geändert hat und das ich mir die Vserkonfiguration nochmal genau ansehen muss.

Wie auch immer. Inzwischen bin ich mir auch sicher, dass in der function read_line in der ispcp-functions.php einen Bug hat und zwar wenn der Connect nicht von 127.0.0.1 kommt, der Daemon also die Verbindung ablehnt, dann sollte die Funktion read_line nicht aufgerufen werden.

Grüße
Beugel

[Jones007]

(04-05-2010 05:42 PM)beugel01 Wrote:  Wie auch immer. Inzwischen bin ich mir auch sicher, dass in der function read_line in der ispcp-functions.php einen Bug hat und zwar wenn der Connect nicht von 127.0.0.1 kommt, der Daemon also die Verbindung ablehnt, dann sollte die Funktion read_line nicht aufgerufen werden.

Grüße
Beugel

Das ist eigentlich ja kein Bug sondern eher (aus meiner sicht) eine Sicherheitsmassnahme.

Würde es dir z.B. gefallen wenn jeder X-Beliebige Client auf den Daemon zugreifen könnte ?

Man könnte für zukünftige Versionen den Daemon Dynamischer Aufbauen so das man nicht direkt am Code mehr was ändern müsste sondern seine IP halt wärend des Setups angeben kann.

[beugel01]

Quote:Das ist eigentlich ja kein Bug sondern eher (aus meiner sicht) eine Sicherheitsmassnahme.

Das ist richtig und auch gut so!!!!
Nur die funktion read_line läuft sich halt tot. Also sollte das mit einer Fehlermeldung abgefangen werden. Irgend was wie "couldn't connect to daemon ... 127.0.0.1!= [client-IP]".

Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/ispcp/gui/include/ispcp-functions.php on line 55

ist halt nicht sehr aussagekräftig. Ohne in die ispcp-functions.php und die take_connection.c kommt man halt nicht dahinter warum es nicht funktioniert.

Grüße
Beugel

[Jones007]

(04-05-2010 07:40 PM)beugel01 Wrote:  Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/ispcp/gui/include/ispcp-functions.php on line 55

ist halt nicht sehr aussagekräftig.

Grüße
Beugel

Da gebe ich dir teilweise recht, zum Testen würde ich aber z.B. die PHP Ausführungszeit erhöhen diese ist ja momentan auf 30 Sekunden begrenzt, Wenn es dann immernoch abbrechen würde, würde ich darauf schliessen das es sich totläuft, aber wäre die Ausführzeit etwas höher und das Script könnte
evtl. zum Ende (weil viel zu tun) durchlaufen, käme sicher auch eine Aussagekräftigere Ausgabe.

Immerhin gibts ja Scripts die halt mehr Zeit brauchen eben weil viel zu tun ist. Viele Scripts verlangen als minimum schon 60+

[beugel01]

Quote:Immerhin gibts ja Scripts die halt mehr Zeit brauchen eben weil viel zu tun ist. Viele Scripts verlangen als minimum schon 60+

Alles schon gemacht ;-) Wird nicht besser.
Dann kommt dann beim löschen:
Error 500!
/admin/user_delete.php
Internal Server Error!

In den logs steht dann auch nichts was einem weiter hilft.

Wie gesagt die Funktion read_line wird nie beendet da hilft es auch nicht die max_execution_time zu erhöhen.

Grüße
Beugel

[dorni-net]

Kannst du mir mal sagen was bei Copyright deiner OpenVCP konsole steht? ich geh da grad einer Vermutung nach.

Hmm hab Grad mal das Datum des Posts nachgesehn Vergiss meine Frage erkenne es selbst hast die Version 0.4 von OpenVCP da 0.5 erst 2010 rauskam.

Damit bestätigt sich aber mein Verdacht das ISPCP probleme mit OpenVCP 0.4 hat.