WCM Forum - cgi mit c/c++

WCM Forum (http://www.wcm.at/forum/index.php)

- Programmierung (http://www.wcm.at/forum/forumdisplay.php?f=17)

- - cgi mit c/c++ (http://www.wcm.at/forum/showthread.php?t=29156)

hi leute!

da ich zur zeit nix zu tun hab, wollt ich mal erfragen ob jemand ein online-tutorial oder buch zum thema cgi scripts mit c kennt bzw weiss wo ich sowas finde

cu
pong

weiss das denn keiner :heul:

auf http://www.jmarshall.com/easy/cgi/german/ gibts ein kleines Tutorial

http://www.tutorialsuche.de/

hier findest fast für jedes thema was.

danke leute aber kanns sein, dass es wirklcih fast keine cgi scripts in c gibt nur in perl?

Perl ist weitaus schneller, da man eigene Module (mod_cgi oder noch besser mod_perl) in den Apache integrieren kann.

Compilen fällt auch weg, so kann das Script schneller geändert und getestet werden.

Meistens läßt der Server gar keine C-Scripten zu, ist ein kleines Sicherheitsproblem.

Sloter

mod_perl ist aber auch ein Sicherheitsrisiko und wird daher auf 99,99% der virtuellen Accounts nicht angeboten. Nebenbei müssen die Perl Scripte speziell an mod_perl angepasst werden.

Wenn es speziell nur für Websites gebraucht wird, würde ich PHP nehmen da das fast immer als Servermodul installiert ist und daher wesentlich schneller als Perl ausgeführt wird.

Mit suexec kombinieren, dann sinkt das Sicherheitsproblem fast auf null.

Sloter

Wieso macht das dann keiner? Vielleicht weil es doch nicht so einfach ist :). Die 1-2 Provider die das Anbieten erlauben auch nicht das jedes x-beliebige Script installiert wird.

mod_perl ist im Vergleich zu Perl als CGI unkontrolierbar. Es kann nicht wie PHP konfiguriert werden (z.b. Safemode) und der Ram Verbrauch bei schlechten Scripts ist sehr hoch. Beispielsweise UBB 6.0 kann manchmal bis zu 400MB :eek: unter mod_perl belegen.

Bei Mandrake wird beispielsweise deshalb mod_perl nicht am normalen Webserver installiert sondern es wird ein zweiten httpd-perl (Apache mit mod_perl) installiert der nur für mod_perl zuständig ist. So ist gewährleistet das selbst wenn der mod_perl Server crasht bzw. überlastet ist die Website noch funktioniert.

1, Mod_Cgi ist halt einfach zu installieren, und ich kenne eine Menge Server wo mod_perl istalliert ist. Ist einfach weitaus schneller als mod_cgi (200-300% bei manchen Scripten).
Jeder vernünftige Dienstleister darf bei den Kundenscripten keine Auswahl treffen. Das währe ja selbstmord, Kunde bezahlt für den Account und der Provider schmeißt die Scripten wieder runter, wenn sie ihm nicht gefallen. Das kommt nur bei Wohnzimmerprovider vor, die einen schwachen Rechner haben, und keiner eine Serverlast erzeugen darf. Sonst geht der Compi mit 128 Ram gleich in die Knie ;)
Ausserdem ist es egal was die Kunden raufladen, du kannst mit Apachemodule die Prozessorzeit und den Ramverbrauch steuern, so kann keiner den Server mit einem Prozess abschießen.
ZB. Ein Script darf maximal 10 Sec. und nicht mehr als 5 MB Ram verbrauchen ;)

2, Für das gibt es Suexec: Das steuert den Zugriff auf Scripten und ist gnadenlos beim Überwachen und ausführen (siehe meinen Thread über Suexec)

3, Hä, 2 Apachen am selben Port :confused:

Sloter

Zitat:

Jeder vernünftige Dienstleister darf bei den Kundenscripten keine Auswahl treffen. Das währe ja selbstmord, Kunde bezahlt für den Account und der Provider schmeißt die Scripten wieder runter, wenn sie ihm nicht gefallen.

Bei mod_perl schon :). Keiner der grossen Provider bietet es an ausser natürlich auf dedizierten Servern. Provider die es doch anbieten werden auf Boards wie www.webhostingtalk.com meistens verrissen. Dabei handelt es sich meistens um kleine 1 Mann Provider die mit wenig Erfahrung einen Server z.b. um $99 Mieten und dann ihren Kunden tolle Features wie mod_perl bieten.

Übrigens bei vielen Servern ist mod_perl zwar installiert wird aber nicht verwendet z.b. bei Cobalt RaQ Servern. Das normale Verzeichnis für mod_perl Scripte ist perl-bin

Zitat:

Das kommt nur bei Wohnzimmerprovider vor, die einen schwachen Rechner haben, und keiner eine Serverlast erzeugen darf. Sonst geht der Compi mit 128 Ram gleich in die Knie
Ausserdem ist es egal was die Kunden raufladen, du kannst mit Apachemodule die Prozessorzeit und den Ramverbrauch steuern, so kann keiner den Server mit einem Prozess abschießen.

Ich würde Tera-Byte nicht unbedingt bei 1 Mio Kunden und 22000 TB/Transfer als Wohnzimmerprovider bezeichnen. Das gleiche gilt für Ventures Online die vor 2 Monaten YaBB/UBB von ihren Servern gebannt haben.

Zitat:

2, Für das gibt es Suexec: Das steuert den Zugriff auf Scripten und ist gnadenlos beim Überwachen und ausführen (siehe meinen Thread über Suexec)

Vielleicht hilft das bei den Resourcen aber was ist mit den Root Privilegen von mod_perl? Da es nicht als CGI läuft und daher nicht an User und deren Verzeichnisse gebunden ist öffnet es eigentlich ein relativ grosses Sicherheitsloch.

Zitat:

3, Hä, 2 Apachen am selben Port

Ich kann ja dann nachschauen aber soviel ich mich erinnern kann werden alle Scripte im /perl-bin Verzeichnis am zweiten Server ausgeführt :)

mod_perl ist, wenn der Apache mit Suexec übersetzt wurde, an den User und die Gruppe gebunden.
Mußte leider diese Erfahrung erst vor kurzem machen.

Also laut mehreren Fachbüchern (zb.Lars Eilebrecht, der Apache Webserver) besteht null Risiko, wenn man Suexec dazu einsetzt.
Ganz im Gegenteil, bei mir wollte es durch Suexec überhaupt nicht laufen, da das Script von mehreren Accounts (Unterschiedliche UID) genutzt werden sollte.

Mußte mich ein wenig mit den Programmierern von ("Kaffee&Kuchen", http://java.seite.net), Javascript ("Kakao&Kekse", http://javascript.seite.net) und Dynamic HTML ("Milch&Zucker", http://dhtml.seite.net)
herumschlagen, da die auf mod_perl schwören, und wir gemeinsam für eine dritte Firma Dienstleistungen erbrachten.
Auf den Server laufen mehrere Accounts, Sicherheit wird da mächtig groß geschrieben (gehört einer Bank).

Fazit: Apache-Suexec-mod_perl= Script wird wesentlich schneller abgearbeitet, und eine externe Agentur konnte keine Sicherheitsrisiken finden.

Nocheinmal, nur in Verbindung mit Suexec, ohne dem Wachhund können Aussenstehende auch mit mod_cgi machen was sie wollen (Scripte aufrufen ohne Berechtigung).

Kleine Auswahl von Provider die mod_perl einsetzen, sind auch große Amis dabei ;)

http://perl.apache.org/isp.html

http://perl.apache.org/

Sloter

Jetzt habe ich auf Webhostingtalk nachgesehen. Laut Matt Freeman (einen Moderator dort) funktioniert SuExec nicht mit mod_perl und mod_php:

Zitat:

There are one or two disadvantages to using SuExec. All php, perl and other scripts have to be executed in CGI mode, meaning you can't use mod_php and mod_perl since these run in-process and don't support username switching, hence creating an extra burden on server resources.

http://www.webhostingtalk.com/showth...threadid=11391

Vergewissere dich daher ob die Scripte wirklich unter mod_perl laufen und wenn ja dann poste die Einstellungen auf WHT da es sicher viele interessieren würde.

Hier ein kleiner mod_perl tester:

Code:

#!usr/bin/perl -w

use strict; 



print "Content-type: text/html\n\n";



if ($ENV{'MOD_PERL'}) {

    print "Mod_perl is installed on this server: $ENV{'MOD_PERL'}



\n";

} else {

    print "Mod_perl is not installed on this server



\n";

}

Zitat:

Kleine Auswahl von Provider die mod_perl einsetzen, sind auch große Amis dabei

Die Liste kenne ich schon :). Dort bieten die Provider es entweder nur wenn man einen eigenen Server nimmt bzw. wenn das Script vorher vom Provider angeschaut und genehmigt wird. Einzig HostPro scheint konseqent zu sein und bietet ihren Kunden auf den Freedom 400x/500x vollen Root Zugang :eek: und daher wahrscheinlich auch mod_perl auf diesen Accounts.

Ich glaube da könnten wir stundenlang Diskutieren.

Ich gebe mich geschlagen :)

Im Grunde kann man viel hacken, sicher ist leider kein System :(

Sloter