nicht angemeldet
Probleme bei Installation fastcgi
0 0 0 0
Probleme bei Installation fastcgi
Kurtz gegrüßt
Vorweg... Linux/Debian zu administrieren hat mir noch nie Spass gemacht...
heute habe ich versucht mod_fastcgi auf meinem Testserver zu installieren:
meine recherche ergab ich müsse
deb http://ftp.de.debian.org/debian/ sid main non-free
in meine sources.list eintragen.
dann fängt das maleur an:
apt-get update
OK http://ftp.ch.debian.org sid/main Packages
OK http://ftp.ch.debian.org sid/main Release
OK http://ftp.ch.debian.org sid/non-free Packages
OK http://ftp.ch.debian.org sid/non-free Release
Paketlisten werden gelesen... Fehler!
E: Dynamic MMap ran out of room
E: Ein Fehler trat beim Bearbeiten von kdvi auf (NewVersion1)
E: Problem with MergeList /var/lib/apt/lists/Debian%20GNU_Linux%203.1%20r0a%20%5fSarge%5f%20-%20Official%20i386%20Binary-1%20(20050607)_dists_unstable_main_binary-i386_Packages
E: Die Paketliste oder die Statusdatei konnte nicht geparst oder geöffnet werden.
die tips auf
http://www.debianforum.de/forum/viewtopic.php?t=4588
haben mir nicht weitergeholfen, deinstallation von kdvi auch nicht ...
kommentiere ich "#deb http://ftp.de.debian.org/debian/ sid main non-free" aus habe ich keine probleme mehr aber fast-cgi lässt sich so nicht installieren...
Ich will ungern das Packet manuell installieren, gibt es vielleicht eine anderes Verfahren...
Grüße
Kurt
PS: Scheiße Sa-Abend 22:35 ...
-
hallo,
meine recherche ergab ich müsse
deb http://ftp.de.debian.org/debian/ sid main non-free
in meine sources.list eintragen.Wiederhole bitte deine Recherche, bis sie dir etwas Relevantes anbietet. Du rufst damit Sourcen ab, die zu Debian "Sid" zählen. Sid ist "unstable", aber du hast "Sarge" in Benutzung. Sarge ist "stable", wenn auch schon etwas ältlich - du solltest also unbedingt, bevor du irgendwas anderes machst, ein
apt-get dist-upgrade
fahren. Danach (kann ein paar Stunden dauern), solltest du ein Etch vorfinden können. Richte deine sources.list auf Etch aus, und wenns dann immer noch nicht klappt, melde dich bitte wieder.Ich will ungern das Packet manuell installieren
Wenn du mit einer solchen Paketinstallation schon Probleme bekommst, muß man natürlich fragen, was du gerne mit mod_fastcgi anstellen möchtest. Im Grunde genommen handelt es sich um ein veraltetes Modul, dessen Fähigkeiten in aktuellen Apache-Versionen von anderen Modulen, vor allem mod_cgi übernommen wurden.
Grüße aus Berlin
Christoph S.
-
Kurtz gegrüßt
danke hab gerade meinen Fehler selbstmbemerkt und die sarge fastcgi version problemlos installieren können.
Im Grunde genommen handelt es sich um ein veraltetes Modul, dessen Fähigkeiten in aktuellen Apache-Versionen von anderen Modulen, vor allem mod_cgi übernommen wurden.
Oh, danke für den Hinweis!
Grüße
Kurt-
hallo,
hab gerade meinen Fehler selbstmbemerkt und die sarge fastcgi version problemlos installieren können.
Glückwunsch.
Aber ich sähe es gern, wenn du meine Rückfrage, wozu du denn mod_fastcgi einsetzen möchtest, noch beantworten könntest.
Grüße aus Berlin
Christoph S.
-
Hi
Aber ich sähe es gern, wenn du meine Rückfrage, wozu du denn mod_fastcgi einsetzen möchtest, noch beantworten könntest.
Ich spiel mit Ruby on Rails rum und die Verzögerung nervt (meine Quelle behandelt nur Apache 1.3)
Das mit dem sid hätte mir auffallen sollen, aber ehrlich gesagt sind mir die "Charaktere" aus Toy Story nicht wirklich geläufig genug.
Grüße
Kurt
-
-
-
Moin Moin!
Wenn du mit einer solchen Paketinstallation schon Probleme bekommst, muß man natürlich fragen, was du gerne mit mod_fastcgi anstellen möchtest. Im Grunde genommen handelt es sich um ein veraltetes Modul, dessen Fähigkeiten in aktuellen Apache-Versionen von anderen Modulen, vor allem mod_cgi übernommen wurden.
Äh, übersehe ich da gerade was in der Doku? Weder mod_cgi noch mod_cgid implementieren die FastCGI-Schnittstelle, bei der ein externer Prozess mehrere Requests abarbeitet, auch parallel. mod_cgid (als Workaround für den Overhead bei einem multithreaded Apache) kommt dem nahe, indem für CGIs ein separater Management-Prozess läuft, aber der fork()t nur für jeden Request einen neuen CGI-Prozess ab, dar nach dem Request stirbt.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
hallo,
Im Grunde genommen handelt es sich um ein veraltetes Modul
Äh, übersehe ich da gerade was in der Doku?Das kann ich nicht beurteilen. Es hängt doch _sehr_ von der installierten Apache-Version ab.
Weder mod_cgi noch mod_cgid implementieren die FastCGI-Schnittstelle
Das ist richtig.
bei der ein externer Prozess mehrere Requests abarbeitet, auch parallel.
Möglich - aber dazu muß man schon nachschauen, wie das (theoretisch) funktionieren soll, und wie es praktisch damit aussieht. Kurt hat meine Nachfrage, wozu er mod_fastcgi einsetzen möchte, noch nicht beantwortet.
Grüße aus Berlin
Christoph S.
-
Moin Moin!
Im Grunde genommen handelt es sich um ein veraltetes Modul
Äh, übersehe ich da gerade was in der Doku?Das kann ich nicht beurteilen. Es hängt doch _sehr_ von der installierten Apache-Version ab.
1.3, 2.0 und 2.2 haben alle KEINE FastCGI-Schnittstelle "out of the box". 1.3 und 2.0 können definitiv mit dem mod_fastcgi von http://www.fastcgi.com/ nachgerüstet werden; für 2.2 habe ich das noch nicht ausprobiert.
Weder mod_cgi noch mod_cgid implementieren die FastCGI-Schnittstelle
Das ist richtig.
Genau deshalb halte ich den Link auf die beiden CGI-Module hier für nur sehr bedingt hilfreich. Zugegeben, ein unerfahrener Fragesteller könnte -- ohne sich weiter zu informieren -- hoffen, FastCGI wäre "CGI in schnell", ohne Änderungen zu erfordern. Dann wäre aber erstmal ein kleiner Hinweis für den Fragesteller besser, das FastCGI doch deutlich anders funktioniert als "normale" CGIs.
Um die Verwirrung komplett zu machen, kann man FastCGI-Anwendungen durchaus so schreiben, dass sie auch als normale CGIs laufen können. Das erfordert eine gewisse, zusätzliche Sorgfalt bei der Entwicklung, denn man kann sich weder darauf verlassen, dass nach Request-Ende der Prozess beendet wird, noch darauf dass der Prozess "ewig" oder bis zu seinem selbst gewählten Ende läuft. Globale Variablen können zwischen Requests erhalten bleiben (FastCGI) oder auch nicht (CGI); ebenso angeforderte Resourcen. (Was wieder einmal beweist, dass man globale Variablen besser vermeidet.)
Kurt hat meine Nachfrage, wozu er mod_fastcgi einsetzen möchte, noch nicht beantwortet.
Ich habe vermutet, um eine "fremde" FastCGI-Anwendung laufen zu lassen. Das hat sich ja mit dem Posting von heute nacht auch bewahrheitet.
Das Entwickeln einer eigenen FastCGI-Anwendung habe ich mal fröhlich ausgeschlossen; ein typischer Software-Entwickler sollte durchaus in der Lage sein, Apache und mod_fastcgi aus dem Quelltext zu compilieren, wenn der Paketmanager der "eigenen" Distribution nicht will.
Viele Grüße,
Alexander <-- verdient sein Geld gerade mit dem Entwickeln einer CGI/FastCGI-Anwendung--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Kurtz gegrüßt
ein typischer Software-Entwickler sollte durchaus in der Lage sein, Apache und mod_fastcgi aus dem Quelltext zu compilieren, wenn der Paketmanager der "eigenen" Distribution nicht will.
Zugegeben ich verdiene mein Geld nicht in diesem Bereich sondern bin im Web einzelkämpferischer Hobbyista, aber zw. typischen Entwicklern und typischen SysAdmins liegen IMHO Welten und ich dränge mich am äußeren Rand des Planeten.
Ich hasse es wie die *Pest* an ner bestehenden Linux-Installation rumzufummeln (leider hasse ich Klicki-Windows aber noch mehr). Eventuell entscheide ich mich demnächst für MacOS, da solls einfacher und monolithischer sein und man muss sich anfangs nicht gleich zw. x Packetmanagern entscheiden.
Ich will kreativ proggen (scripting) und mich nicht durch hunderte (veraltete) Mailinglisten googeln müssen um z.B. einen beschissenen Font/Fontserver zu installieren damit emacs beim fonthighlighting von HTML keine Löcher produziert.
Das überlasse ich gerne anderen Jungs, meine Frustschwelle ist da zu niedrig.
Grüße
Kurt-
Moin Moin!
ein typischer Software-Entwickler sollte durchaus in der Lage sein, Apache und mod_fastcgi aus dem Quelltext zu compilieren, wenn der Paketmanager der "eigenen" Distribution nicht will.
Zugegeben ich verdiene mein Geld nicht in diesem Bereich sondern bin im Web einzelkämpferischer Hobbyista, aber zw. typischen Entwicklern und typischen SysAdmins liegen IMHO Welten und ich dränge mich am äußeren Rand des Planeten.
Ein Entwickler sollte aber IMHO in der Lage sein, zweimal das altbewährte configure / make / make install durchzuziehen, einmal für den Apachen, einmal für mod_fastcgi. Und wenn ihm das noch nicht flüssig von den Fingern geht, sollte er wenigstens in der Lage sein, der Doku zu folgen. Die ist bei diesen beiden Produkten sogar überdurchschnittlich gut. Dokus schnell und effizient lesen zu können halte ich für eine Grundqualifikation eines Entwicklers.
Ein Sysadmin dagegen nimmt das Ergebnis jahrelanger Entwicklung von Hard- und Software bringt beides dazu, unter allen Bedingungen möglichst störungsfrei zu laufen. Dann bleiben nur noch Wartungsarbeiten, die ein Sysadmin idealerweise so weit automatisiert, dass er den ganzen Tag in Ruhe Solitair und Mine Sweeper auf seiner Windows-Kiste spielen kann, während sich die wirklich wichtigen Unix-Systeme quasi selbst warten.
Ich hasse es wie die *Pest* an ner bestehenden Linux-Installation rumzufummeln (leider hasse ich Klicki-Windows aber noch mehr). Eventuell entscheide ich mich demnächst für MacOS, da solls einfacher und monolithischer sein und man muss sich anfangs nicht gleich zw. x Packetmanagern entscheiden.
Ich will kreativ proggen (scripting) und mich nicht durch hunderte (veraltete) Mailinglisten googeln müssen um z.B. einen beschissenen Font/Fontserver zu installieren damit emacs beim fonthighlighting von HTML keine Löcher produziert.
http://www.tldp.org/ ist schonmal ein guter Start, eine gut gepflegte Distribution wäre auch hilfreich.
Apple ist nicht das Paradies, da hat ein gewisser Steve J. nur den angebissenen Apfel gemopst! Auch MacOS X hat einige häßliche Ecken, es löst nicht alle Probleme durch fröhliches Winken mit dem Mauscursor, und für Dinge, für die Apples Designer und Entwickler keinen mausschubsbaren Weg vorgesehen haben, wirst Du auch wieder suchen und lesen müssen. Und auch da wirst Du Dich u.U. mit dem einen oder anderen Package Manager herumschlagen müssen.
Das überlasse ich gerne anderen Jungs, meine Frustschwelle ist da zu niedrig.
So eine niedrige Frustrationsschwelle ist nicht wirklich hilfreich, wenn Du Software entwickeln willst.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".-
Kurtz gegrüßt
Ein Entwickler sollte aber IMHO in der Lage sein, zweimal das altbewährte configure / make / make install durchzuziehen, einmal für den Apachen, einmal für mod_fastcgi.
ich dachte das Credo wäre PacketManager zu nutzen um das System wartbar zu halten ?!?
Dann bleiben nur noch Wartungsarbeiten, die ein Sysadmin idealerweise so weit automatisiert, dass er den ganzen Tag in Ruhe Solitair und Mine Sweeper auf seiner Windows-Kiste spielen kann, während sich die wirklich wichtigen Unix-Systeme quasi selbst warten.
Du, die solitairspielenden Sysadmins die ich kennen gelernt habe, weigerten sich jahrelang neben NN4 auch mal ein neueres Mozilla zu installieren.
http://www.tldp.org/ ist schonmal ein guter Start,
Merci! schau ich mir an.
eine gut gepflegte Distribution wäre auch hilfreich.
Ja, z.B.? (für Vorschläge offen)
Apple ist nicht das Paradies,
what else?
- Ubuntu?
- XP + CygWin?
So eine niedrige Frustrationsschwelle ist nicht wirklich hilfreich, wenn Du Software entwickeln willst.
naja, dass ist nur der eigene Scheiß, der stinkt ganz anders als der anderer Leute ;-)
Grüße
Kurt-
Moin Moin!
Ein Entwickler sollte aber IMHO in der Lage sein, zweimal das altbewährte configure / make / make install durchzuziehen, einmal für den Apachen, einmal für mod_fastcgi.
ich dachte das Credo wäre PacketManager zu nutzen um das System wartbar zu halten ?!?
Nur, so lange der Paketmanager dabei nicht im Weg steht. ;-)
Du, die solitairspielenden Sysadmins die ich kennen gelernt habe, weigerten sich jahrelang neben NN4 auch mal ein neueres Mozilla zu installieren.
Tja, Macht der Gewohnheit. Neue Software ist selten von Anfang an fehlerfrei, ganz im Gegenteil hat sie Macken, manche Software sogar so üble Macken, dass sie das halbe System in den Abgrund reißt. Wer stabile Systeme haben will, setzt bewährte Software ein und nicht die brandneuesten Entwicklungen. Sehr schön z.B. bei Debian "stable" zu sehen, wo bis vor kurzem z.B. der Apache 1.3 Stand der Technik war. Natürlich ist auch der nicht fehlerfrei, aber die Fehler und Macken sind bekannt, ebenso wie die notwendigen Workarounds.
http://www.tldp.org/ ist schonmal ein guter Start,
Merci! schau ich mir an.
eine gut gepflegte Distribution wäre auch hilfreich.
Ja, z.B.? (für Vorschläge offen)
Ich nehme die Slackware, seit zwei oder drei Jahren ist die durchaus aus der Server-Ecke herausgewachsen und Desktop-fähig geworden. Die Slackware ist eher konservativ ausgelegt, aber nicht so extrem wie Debian stable. Paket-Management ist extrem einfach und robust, dafür muß man Abhängigkeiten selbst auflösen. Konfigurationsmonster wie YaST gibt es nicht, man editiert Textdateien unter /etc, wie seit Urzeiten üblich. Die Installation läuft komplett im Textmodus, danach bootet das System ebenfalls in den Textmodus. Das ist definitiv nicht sehr anfängerfreundlich, aber das ist auch nicht das Ziel der Slackware.
Apple ist nicht das Paradies,
what else?
- Ubuntu?
Was auch immer Dir gefällt. Die Wikipedia hat eine lange Liste von Linux-Distributionen samt Vergleich. Schonmal FreeBSD probiert?
- XP + CygWin?
Eine Bruchbude wird mit einem freundlichen Schild an der Tür auch nicht besser. Windows schleppt so viele faule Kompromisse und Kompatibilitäten zu Denkverweigerungen alter Versionen mit sich herum, dass man darauf besser nicht mehr aufbaut. Cygwin ist eine Notlösung, wenn man aus irgendwelchen Gründen Unix-Befehle ausführen muß, aber kein Unix einsetzen darf.
So eine niedrige Frustrationsschwelle ist nicht wirklich hilfreich, wenn Du Software entwickeln willst.
naja, dass ist nur der eigene Scheiß, der stinkt ganz anders als der anderer Leute ;-)
Freunde Dich mit der Idee an, das Code anderer Leute auch selten fehlerfrei ist, sobald er die Komplexität von "Hello World" überschreitet.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so".
-
-
-
Hallo Alexander,
1.3, 2.0 und 2.2 haben alle KEINE FastCGI-Schnittstelle "out of the box". 1.3 und 2.0 können definitiv mit dem mod_fastcgi von http://www.fastcgi.com/ nachgerüstet werden; für 2.2 habe ich das noch nicht ausprobiert.
Für 2.2 funktioniert's auch. Genauso gibt es auch noch mod_fcgid als mögliche Alternative. Allerdings ist die Entwicklung beider Module ziemlich eingeschlafen.
Viele Grüße,
Christian-
Hi Christian
Allerdings ist die Entwicklung beider Module ziemlich eingeschlafen.
hast du ne Präferenz?
Grüße
Kurt-
Hallo Kurt,
Allerdings ist die Entwicklung beider Module ziemlich eingeschlafen.
hast du ne Präferenz?
Nicht wirklich, ich mag beide nicht, was die Konfiguration angeht. ;-)
Du kannst Dir auch mal statt dem Apache den Lighttpd ansehen, der kann FastCGI von Haus aus.
Viele Grüße,
Christian
-
-
-
-
-
-