CometVisu auf weiterer Hardware

[kolmatux]

64bit

Hallo makki und do13

ich habe nochmal alles mit synaptic alles vollständig entfernt.
dann die Pakete nach makkis anweisungen wieder Installiert.
beim start mit

"eibd -t 1023 -S -D -R -T -i --no-tunnel-client-queuing ipt:192.168.40"
kommt folgende Fehlermeldung.

eibd: invalid option -- 'S'
Try `eibd --help' or `eibd --usage' for more information.

die Dateien config.h und /tmp/eibd sind nicht vorhanden.


kolmatux

[Bodo]

Hoi

Das ist wie mit dem real existierenden Sozialismus gewesen, in der Theorie eigentlich keine schlechte Idee, aber die Umsetzung

Von der Idee her ist das mit den 64 bit ja nicht zu kompliziert oder?

[greentux]

Vielleicht mal bitte die Wikipedia Seite auch lesen!

Wenn ich einem VBox Gast mehr als sagen wir 2 GB geben möchte, geht das eben mit 32 Bit nix (VBox selber braucht einiges + die 2 GB für den Gast > 3 GB). Da ändert auch PAE nix dran, weil auch damit der einzelne Prozess nicht mehr RAM bekommen kann (in dem Falle der VBox Prozess). Man kann lediglich den größeren Speicher einblenden. Das ist nett, aber nur begrenzt brauchbar.

Ich kann teilweise verstehen, wenn man so neue Sachen wie 64 Bit (ist schon 20 Jahre alt) oder IPv6 (ähnlich alt) nicht sonderlich mag. Man sollte die Leute, die das trotzdem nutzen wollen, nur nicht immer in die Ecke stellen bitte. Es gibt zumeist gute Gründe, das zu nutzen, so dass man nicht schlecht beraten ist, als SW-Entwickler/Produktehersteller auch immer ein Auge drauf zu haben.

[makki]

Na dann mal los, das interessiert mich jetzt wirklich... Es ging um 3 GB RAM, nicht um 2 GB, das wäre einfach...

3 GB barrier - Wikipedia, the free encyclopedia
Mehr gibt es dazu nicht zu sagen, meine Rechner laufen von XP bis Windows 12.04 ganz herrlich mit 4GB RAM, einzig auf heftigen Servern für tausende Benutzer oder mit Millionen Datensätzen sollte man über 64Bit nachdenken - oder vielleicht ob die Software nicht doch einfach nur "knalltüte" ist - weil es die letzten 50 Jahre auch ohne ging

Zurück zum Thema..

Aber mein eibd kann nicht mehr mit
eibd -t 1023 -S -D -R -T -i --no-tunnel-client-queuing ipt:192.168.0.40gestartet werden, er kennt die Optionen -S -D -R -T und --no-tunnel-client-queuing
nicht mehr.

Verrate uns doch mal die genaue gestehungsgeschichte, sowohl in meinen als auch den packerln von mkögler ist KNXnet/IP aktiviert und geht aus der Box - und nochmal, man braucht nur die eibd-clients von mir, der eibd >= 0.4.16 kanns..

Muss ich der Comet Visu eigentlich mitteilen woher die Daten kommen und die Befehle hingehen?

Nein

Und muß eibd als Dämon laufen oder

Was ne Frage Also wenn kein eibd läuft versucht das CV-Backend intuitiv per Siemens-Lufthaken die Telegramme auf den Bus zu beamen Sorry schonmal..

Makki

[do13]

Aber mein eibd kann nicht mehr mit
eibd -t 1023 -S -D -R -T -i --no-tunnel-client-queuing ipt:192.168.0.40gestartet werden, er kennt die Optionen -S -D -R -T und --no-tunnel-client-queuing
nicht mehr.

Welche Fehlermeldung kommt hier? Ist HAVE_EIBNETIP* in der config.h enabled?

Muss ich der Comet Visu eigentlich mitteilen woher die Daten kommen und die Befehle hingehen?

Per default wird /tmp/eibd benutzt

Und muß eibd als Dämon laufen oder müssen nur die eibread-cgi und die eibwrite-cgi mit der libeibclint.so.0 nur vorhanden sein?

Es muss schon ein eibd laufen. Nur die libs alleine reichen nicht.

[do13]

Zum cgi-Problem:
Das hier sieht doch richtig aus, oder?

Alias alleine reicht nicht. Du brauchst noch:

$HTTP["url"] =~ "^/cgi-bin/" {
       cgi.assign = ( "" => "" )
}

[Chris M.]

Resultat:
Die Meldung erscheint erstmalig in der letzten Zeile dieses Blocks:

[COLOR=#000000][FONT=Consolas][...][/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]    [COLOR=#AA0D91]for[/COLOR] ([COLOR=#AA0D91]var[/COLOR] [COLOR=black]i[/COLOR] = [COLOR=#1C00CF]0[/COLOR]; [COLOR=black]i[/COLOR] < [COLOR=#AA0D91]this[/COLOR].[COLOR=black]listeners_[/COLOR].[COLOR=black]length[/COLOR]; [COLOR=black]i[/COLOR]++) {[/FONT][/COLOR]

Dabei ist die Schleife aber schon zwei drei mal gelaufen.

Ich hab auch nen Screenshot angehängt.

OK, das ist eine Ebene zu tief. Das ist eine Chome interne Funktion. D.h. der Fehler muss weiter vorne sein.

Zum cgi-Problem:
Das hier sieht doch richtig aus, oder?

Das muss jemand anderes beantworten, da kenne ich mich so gut wie gar nicht aus.

[henfri]

Hi Chris,

danke für deine Tipps.
"Ersetze mal durch die nicht minimierte Version". Da verlangst du aber was von mir. Hab's aber geschafft.
Resultat:
Die Meldung erscheint erstmalig in der letzten Zeile dieses Blocks:

[COLOR=#000000][FONT=Consolas]  [COLOR=#007400]// Dispatches this event object to all listeners, passing all supplied[/COLOR][/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]  [COLOR=#007400]// arguments to this function each listener.[/COLOR][/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]  [COLOR=black]chrome[/COLOR].[COLOR=black]Event[/COLOR].[COLOR=black]prototype[/COLOR].[COLOR=black]dispatch[/COLOR] = [COLOR=#AA0D91]function[/COLOR]([COLOR=black]varargs[/COLOR]) {[/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]    [COLOR=#AA0D91]if[/COLOR] (![COLOR=#AA0D91]this[/COLOR].[COLOR=black]eventOptions_[/COLOR].[COLOR=black]supportsListeners[/COLOR])[/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]      [COLOR=#AA0D91]throw[/COLOR] [COLOR=#AA0D91]new[/COLOR] [COLOR=black]Error[/COLOR]([COLOR=#C41A16]"This event does not support listeners."[/COLOR]);[/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]    [COLOR=#AA0D91]var[/COLOR] [COLOR=black]args[/COLOR] = [COLOR=black]Array[/COLOR].[COLOR=black]prototype[/COLOR].[COLOR=black]slice[/COLOR].[COLOR=black]call[/COLOR]([COLOR=black]arguments[/COLOR]);[/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]    [COLOR=#AA0D91]var[/COLOR] [COLOR=black]validationErrors[/COLOR] = [COLOR=#AA0D91]this[/COLOR].[COLOR=black]validate_[/COLOR]([COLOR=black]args[/COLOR]);[/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]    [COLOR=#AA0D91]if[/COLOR] ([COLOR=black]validationErrors[/COLOR]) {[/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]      [COLOR=#AA0D91]return[/COLOR] {[COLOR=black]validationErrors[/COLOR]: [COLOR=black]validationErrors[/COLOR]};[/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]    }[/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]    [COLOR=#AA0D91]var[/COLOR] [COLOR=black]results[/COLOR] = [];[/FONT][/COLOR]
[COLOR=#000000][FONT=Consolas]    [COLOR=#AA0D91]for[/COLOR] ([COLOR=#AA0D91]var[/COLOR] [COLOR=black]i[/COLOR] = [COLOR=#1C00CF]0[/COLOR]; [COLOR=black]i[/COLOR] < [COLOR=#AA0D91]this[/COLOR].[COLOR=black]listeners_[/COLOR].[COLOR=black]length[/COLOR]; [COLOR=black]i[/COLOR]++) {[/FONT][/COLOR]

Dabei ist die Schleife aber schon zwei drei mal gelaufen.

Ich hab auch nen Screenshot angehängt.

Zum cgi-Problem:
Das hier sieht doch richtig aus, oder?

root@wiregate:/etc/lighttpd/conf-enabled# cat *
# /usr/share/doc/lighttpd-doc/cgi.txt

server.modules += ( "mod_cgi" )

#$HTTP["url"] =~ "^/cgi-bin/" {
#       cgi.assign = ( "" => "" )
#}

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

alias.url += ( "/cgi-bin/" => "/usr/lib/cgi-bin/" )

compress.filetype           += ("application/javascript", "application/xml", "application/octet-stream")

Gruß,
Hendrik

[Chris M.]

Die Seite baut sich nach Ausführung der Zeile (14 von templateengine.min.js)

Ui, bitte ersetze die mal durch die passende nicht minimized-Version, damit man sieht wo's knatscht.

Noch eine Frae zu den Voraussetzeungen:
Die Dateien in /usr/lib/cgi-bin existieren und
groupcacheread local:/tmp/eib 1/1/230
funktioniert an der Kommandozeile.

Allerdings führt ein
http://wiregate/cgi-bin/l
im Browser zum Download dieser Datei. Ist das richtig so?

Nein, das ist natürlich nicht richtig. Das heißt, dass der Web-Server falsch konfiguriert ist. Der soll das Ergebnis der Datei anbieten und nicht die Datei selbst.

[kolmatux]

64bit System

Hallo
diesmal hat es funktioniert, mit dem bauen der Pakete das installieren hat auch funktioniert. Nach der letzten Mail von makki habe ich es nochmal probiert.

Aber mein eibd kann nicht mehr mit
eibd -t 1023 -S -D -R -T -i --no-tunnel-client-queuing ipt:192.168.0.40gestartet werden, er kennt die Optionen -S -D -R -T und --no-tunnel-client-queuing
nicht mehr.

Muss ich der Comet Visu eigentlich mitteilen woher die Daten kommen und die Befehle hingehen?

Und muß eibd als Dämon laufen oder müssen nur die eibread-cgi und die eibwrite-cgi mit der libeibclint.so.0 nur vorhanden sein?

kolmatux

wandbilder.net

[henfri]

Hallo,

Leider kann ich bei dem Fehler selbst nicht helfen - aber evtl. wie man analysieren kann:

• Nimm einen gescheiten Browser wie Firefox (+Firebug Erweiterung) oder Chrome[ium]
• Öffne das Debug-Fenster (= Firebug, bzw. Strg+Shift+I im Chromeium)
• Führe erst mal alle Aktionen aus die zu diesem Fehlertext führen, ggf. dabei versuchen die unbedingt notwendigen Aktionen zu isolieren
• Mach alles bis auf den letzten Schritt
• Hänge im JavaScript an eine (oder ein paar) strategisch sinnvoller Stelle einen Breakpoint
• Führe die Aktion durch
  • Breakpoint schlägt nicht an, oder erst nach dem Text => Breakpoint sitzt falsch
  • Breakpoint schlägt an: Perfekt, dann lass die Intruktionen Schritt für Schritt ausführen
  
  
• Bei letzterem Lernst Du dann, was wo genau fehlt
• => Behebe den Fehler
• Dann einfach nochmal alle Schritte durchführen und der Fehler sollte nicht mehr kommen

Also bis zum drittletzten Punkt bin ich gekommen.
Die Seite baut sich nach Ausführung der Zeile (14 von templateengine.min.js)

[COLOR=#000000][FONT=Consolas][COLOR=black]$[/COLOR]([COLOR=black]document[/COLOR]).[COLOR=black]ready[/COLOR]([COLOR=#AA0D91]function[/COLOR](){[COLOR=black]$[/COLOR].[COLOR=black]ajaxSetup[/COLOR]({[COLOR=black]cache[/COLOR]:![COLOR=black]forceReload[/COLOR]});[COLOR=black]window[/COLOR].[COLOR=black]setTimeout[/COLOR]([COLOR=#C41A16]"$.get( 'visu_config"[/COLOR]+[COLOR=black]configSuffix[/COLOR]+[COLOR=#C41A16]".xml', parseXML );"[/COLOR],[COLOR=#1C00CF]200[/COLOR]);});[COLOR=black]$[/COLOR]([COLOR=black]window[/COLOR]).[COLOR=black]unload[/COLOR]([COLOR=#AA0D91]function[/COLOR](){[COLOR=black]visu[/COLOR].[COLOR=black]stop[/COLOR]();});[COLOR=#AA0D91]function[/COLOR] [COLOR=black]transformEncode[/COLOR]([COLOR=black]transformation[/COLOR],[COLOR=black]value[/COLOR])[/FONT][/COLOR]

Mit dem Fehler "unknown text" auf.
Aber ich fürchte, der Fehler tritt schon früher auf, oder? Wenn ich das richtig sehen, wird hier eben nur die Darstellung der Seite freigegeben, oder?

Noch eine Frae zu den Voraussetzeungen:

*** Important note on diagram-backend ***
It uses a modified version of rrdtool, adding a "fetchj" option.
You can find source and Debian-packages here:
http://repo.wiregate.de/wiregate/pool/main/r/
http://repo.wiregate.de/wiregate/pool/main/libr/

*** Notes on the KNX-backend ***
The KNX-backend uses
/usr/lib/cgi-bin/l : a dummy-login
/usr/lib/cgi-bin/r : a symlink to /usr/bin/eibread-cgi
/usr/lib/cgi-bin/w : a symlink to /usr/bin/eibwrite-cgi
eibread/write-cgi are part of a modified eibd-clients package here:
http://repo.wiregate.de/wiregate/pool/main/e/

Die Dateien in /usr/lib/cgi-bin existieren und
groupcacheread local:/tmp/eib 1/1/230
funktioniert an der Kommandozeile.

Allerdings führt ein
http://wiregate/cgi-bin/l
im Browser zum Download dieser Datei. Ist das richtig so?


Gruß,
Hendrik

[greentux]

Das ist nicht nicht lustig sondern die ebenso verbreitete wie falsche 64bit Lüge.
Man braucht dafür nicht den Overhead von 64Bit (alles ist doppelt so gross und braucht fast den deppelten RAM!) - nur wenn EINE Applikation mehr als 2GB wirklich braucht, das=true..

Na dann mal los, das interessiert mich jetzt wirklich... Es ging um 3 GB RAM, nicht um 2 GB, das wäre einfach...

[makki]

Z
Also spätestens, wenn ich in meiner VBox mehr als 3 GB RAM vergeben will, ist Schicht im 32 Bit-Schacht

Das ist nicht nicht lustig sondern die ebenso verbreitete wie falsche 64bit Lüge.
Man braucht dafür nicht den Overhead von 64Bit (alles ist doppelt so gross und braucht fast den deppelten RAM!) - nur wenn EINE Applikation mehr als 2GB wirklich braucht, das=true..

nach:
dpkg-buildpackage -b -uc -us

..warst du schon fertig, wusstest aber evtl. nicht

[FONT=monospace]habe ich mit dem dreisatz (.configure,make, sudo make install) weitergemacht

Fehler, sowas ist auf Debian/Ubuntu nicht notwendig bzw. führt ins Chaos..
Du warst schon am Ziel, o.g. kompiliert wissentlich auf 64bit auch durch, dpkg -i ../*eib*deb hätte gereicht..
(also ein paar depends fehlen, die bekommt man mit "apt-get build-dep bcusdk" - ausser man wills halt freaky )

Makki

[Sipple]

Nun, rein technisch braucht das cometvisu backend eigentlich nur eibread-cgi und eibwrite-cgi. Diese beiden Tools sind zusätzlich in Makki's eibd-clients Package mit dabei. Das ist der einzige Unterschied.
Die Tools nutzen dann die libeibclient.so um mit dem eibd zu kommunizieren. Theoretisch laufen diese auch mit einer libeibclient.so aus einem aktuellen eibd-clients Paket. Dies hat kolmatux ja auch versucht, nur leider kann man nicht 32Bit und 64Bit mischen.

Richtigerweise müsste man diese beiden Tools zu dem aktuellen 0.0.5 Sourcen hinzufügen und neu übersetzen, denn als fertiges .deb gibt es das nicht. Schon gar nicht für 64Bit.

Dirk

Danke, again what learned

[kolmatux]

[QUOTE=do13;242433]Ich habe mal den eibd mit den Änderungen von makki für amd64 unter Ubuntu 12.04 übersetzt.
Die Pakete liegen auf meinem Server unter Index of /eibd
Habe aber heute keine Zeit mehr zum testen. Also auf eigene Gefahr

/QUOTE]
Leider habe ich noch eine 10.04.3 Version von ubuntu im keller am werkeln und da bekomme ich das mit den Abhängikeiten nicht auf die reie.

Aber ein Upgrate wollte ich sowieso machen (mache schon eine Sicherung meines Servers)

Habe auch versucht selbst Pakete herzustellen aber irgendwie habe ich nicht die richtige Anleitung gefunden diese aus meinem Programmcode zu machen.

kolmatux