CometVisu auf weiterer Hardware

[Sipple]

Hallo Lapheus

Super gemacht! Bist mir zuvor gekommen
Am eibd Startscript solls nicht scheitern, hätte ich eines was tadellos funktioniert. Siehe Anhang. Die DAEMON_ARGS Zeile muss halt für den eigenen Zweck angepasst werden und den Hinweis auf die Systemgruppe/Systemuser im Header beachten.
Persönlich finde ich Kapitel 1, Debian Installation, etwas kompliziert oder umständlich, ist aber reine Geschmacksache. Ich mache das mit einem bootfähigen Memorystick. Hat natürlich alles seine Vor- und Nachteile. Falls gewünscht, kann ich morgen die Anleitung zur Debian Installation per USB-Stick posten, ist schon fertig.

Auf jeden Fall danke für die klasse Anleitung!

Gute Nacht

Martin

[makki]

Ergänzend: ein .deb ohne funktionierendes Init-Script ist IMHO einfach keins, man sollte darauf hinarbeiten das zu beheben, mein "Vorschlag" (sicherlich sehr spezifisch, es muss hier funktionieren, fängt halt auch spezifische Probleme ab..) anbei..

Makki

[Lapheus]

Hallo zusammen,

Wie makki schon geschrieben hat reichen die beiden Module

cgi cgi-cometvisu

Doch nicht richtig!
Es muss auch fastcgi aktiviert werden, sonst kommen Fehler im Editormodus.

Gruss
Lapheus

[makki]

ähm, ich widerspreche ja nur ungern, aber bei mir (und vermutlich hundert anderen) läuft die CV ganz,ganz sicher ohne fastcgi (und dagegen wäre ich aus verschiedenen Gründen auch auf die Barrikaden, weil das etwas für Leute ist, die entweder Youtube betreiben (bei einer Million req/s mag das langsam sinnvoll werden..) oder ihr Programmier-unvermögen mit einem Quadcore kaschieren müssen )
Komplexe tricks braucht man hier nicht, geht auch so einfach..

Makki

[greentux]

fastcgi lohnt sich nicht erst bei YouTube, wo es vermutlich auch völlig überfordert wäre
Da das ganze ja eh kein wiregate werden soll, denke ich, stören tuts ja auch nicht.

[Lapheus]

Hallo makki,

ähm, ich widerspreche ja nur ungern, aber bei mir (und vermutlich hundert anderen) läuft die CV ganz,ganz sicher ohne fastcgi.
Makki

Wie kann ich dann diese Fehler hier vermeiden:

bekomme ich beim betätigen des "Edit" Buttons einen Fehler:
"Failed to get address-config. Error: 'error undefined'."
und beim speichern:
"Config not saved. Error: '%s'"

ohne fastcgi zu aktivieren? Fehlt evtl. eine Abhängigkeit?

Reproduzierbar taucht der Fehler ohne fastcgi auf und wenn ich es aktiviere kommt der Fehler nicht mehr. Jedes mal mit lighty-en/disable-mod und Neustart (force-reload) des Lighttpd.

Daher meine Aussage.

Gruss Lapheus

[Chris M.]

Das hängt mit PHP zusammen. Und bei dir wird PHP wohl über fastcgi eingebunden (so kenne ich es eigentlich auch als normal).

Wie das WireGate dagegen PHP einbindet, weiß ich nicht.

[Lapheus]

Hallo zusammen,

Das hängt mit PHP zusammen. Und bei dir wird PHP wohl über fastcgi eingebunden (so kenne ich es eigentlich auch als normal).

Wie das WireGate dagegen PHP einbindet, weiß ich nicht.

Ich auch nicht!
Aber:
Wenn man weis wonach man suchen muss, findet man was.
Als erstes muss fastcgi wieder deaktiviert werden (siehe oben).

Dann die Datei /etc/lighttpd/conf-available/10-cgi.conf editieren und ziemlich am Ende folgende Zeile auskommentieren ".php" => "/usr/bin/php-cgi".

## Warning this represents a security risk, as it allow to execute any file
## with a .pl/.php/.py even outside of /usr/lib/cgi-bin.
#
cgi.assign      = (
        ".pl"  => "/usr/bin/perl",
        ".php" => "/usr/bin/php-cgi",
#       ".py"  => "/usr/bin/python",
)

Dann noch ein:

/etc/init.d/lighttpd force-reload

und jetzt sollte es auch ohne fastcgi gehen.
Bei mir jedenfalls.

Ob das jetzt die beste Lösung ist weis ich nicht, siehe die Warnmeldung.

Gruss
Lapheus

[Chris M.]

Die Warnung ist für mich eher von der pauschalen Art um zu sagen, dass Du aufpassen sollst bei dem was Du machst.

Die gezeigte Config bindet halt PHP als normales CGI und nicht als FastCGI ein. Technisch kein Problem, aber halt von der Performance nicht optimal.

(So wie ich das Verstanden habe heißt CGI, dass jedes mal ein Prozess gestartet werden muss, der insb. bei PHP nicht wirklich schlank ist. Bei FastCGI kann der parallel mitlaufen und kommuniziert halt bei Seitenaufruf)

[makki]

Exakt, man muss dem lighty nur erlauben per shebang die PHP's auch auszuführen (eigentlich tut das aber schon das packerl dachte ich..)

Bzgl. fastcgi, wie schon angedeutet, die Medaille hat immer zwei Seiten: fcgi gibts nicht umsonst: das kostet auch was (hier vor allem unnötige Komplexität, RAM und die Notwendigkeit für noch mehr Interpreter-Stoff); wir sprechen hier nur vom Editor! und dort auch nur von 5-50 Zeilern, der Hauptsächliche Part steckt im JS - was IMHO gut ist - die handvoll PHPs erledigen nur ein paar banale "Hilfsarbeiten"

Also, z.B. 5 vorkompilierte Prozesse permanent vorzuhalten um im Schnitt zweimal in der Woche die Adressen abzurufen ->
Ich glaube aber deswegen funktioniert heute keine Webseite mehr ohne Octacore++, weil keiner mehr drüber nachdenkt, wie es effizienter ginge!
Zugegeben, da hab ich die letzten Jahre auch viel dazugelernt, im Beruf Webserver in gross, nur sprechen wir hier im Smarthome nicht von "gross", das ist alles eigentlich pillepalle,lasst uns doch nicht den Gedanken aufkommen, das man dafür nen Dualcore bräuchte, nur weil man nicht nachgedacht hat
Deswegen war ich so vehement, das eigentliche CV-Backend als C-CGI zu haben (wenn vielleicht auch schlecht programmiert und leaky, aber performant ist es ) und die Datenhaltung da wo sie hingehört (hier eibd) nicht doppelt&dreifach in irgendwelchen workarounds (fastcgi ist - sorry - für mich erstmal ein Workaround von Scriptern, die es nicht besser/anders konnten..)
Was ist der Hintergrund? Ganz einfach: ich will das die CV auch mal auf einer Fritzbox, OpenWRT (tut sie schon) etc. mit 32MB RAM und 4MB Flash laufen kann, da hat so ein Plempel wie P* aber einfach keinen Platz

P.S.: 1997 ging das aber komischerweise auch schon mit Millionen zugriffen, ohne fastcgi mitm Apache (wir mussten damals politisch vorspielen, es wäre ein IIS! ist denke ich verjährt, es war in echt ein Apache ) da wurden auch nur banale Textfiles gelesen.. Ging, war ein grosses Sport-Event.. Ich vermute für sowas werden heute 3 Racks mit 50 statt 2 Servern aufgestellt, nur damit die sich alle Entwickler toll-OO in XML austauschen können und der Programmierer nur ja nicht nachdenken muss, was das für nen impact hat

Nur meine generellen 5ct, auf diesen Zug (ich meine hier fastcgi zu benötigen - für nichts!) muss man IMHO nicht ohne Not aufspringen.

Makki

[greentux]

Wahrscheinlich sollten wir aber auch noch alle Nokia 2110 nutzen. Alles was danach kam, war definitiv schlechter.

Ich weiß nicht, warum wir hier um jedes Byte im Speicher diskutieren. Da gibts auf meinem Wiregate n Stück Software, das sich nen kompletten Interpreter gönnt...

[makki]

Ich weiß nicht, warum wir hier um jedes Byte im Speicher diskutieren.

Ganz einfach: weil ich auch noch dazulerne
Da würde ich Stand 12/2011 einiges anders machen, als 07/2009.. Vor allem: vorher mehr darüber nachdenken was die endgültigen Auswirkungen sind bevor mans "betriebsblind" irgendwie macht und sich so knüller wie fcgi oder gar nochmal Perl einfängt

Makki

[greentux]

Aber dann wärs doch Zeit, den Code mal zu refaktorieren?
Habt ihr eure Stelle schon besetzen können?

[makki]

Mach mal gerne, die 24h eines tages sind grad mal wieder rum
Aber der Threadtitel war aber (s.o.) -> ergo darf man IMHO schon auch sagen was genau eben nicht so zieführend dafür wäre; die CV läuft unter OpenWRT mit 32MB RAM/4MB Flash nämlich aktuell

Wenn die Stellen alle besetzt wären, würde der Thread wohl kaum mehr sticky sein? Immer her damit, Bayern ist schön, aber stehlen kann man sie auch nicht

Makki

[greentux]

Sorry, ich muss schon die Produkte meines AG pflegen. Sonst mosern unsere Kunden
Auch 3 Stellen offen, aber immerhin Bewerber.