CometVisu - (interner) Beta-Test

[Chris M.]

Jch weiß jetzt nicht genau was du mit "CometVisu Stil mäßig" meinst - ich dachte jetzt an eine einfache Objektstruktur als JSON.

Damit meine ich, dass die HTTP Datenübertragung per JSON passiert (und z.B. nicht als XML) - also genau so wie von Dir angedacht

Ist mit 2D eine Grundriss-Draufsicht gemeint? Dann würden die bisherigen Element ja praktisch nur um zwei Koordinaten erweitert werden brauchen - das bekommt man dann auch per Javascript wieder in die Config.

Die Frage ist dann auch wie der "Grundriss" dargestellt werden soll - background-image vom User, oder brauchts da noch ein CAD-Plugin für den Config-Editor?

Ja, ist gemeint. Und dabei gehe ich davon aus, dass der Anwender einfach ein Hintergrund Bild nimmt - fertig. Und wenn wir ganz toll sein wollen, bieten wir mehrere Bilder für verschiedene Auflösungen an und interpolieren die Widget-Position, oder so.

Das CAD Plugin darfst Du dann für die 3D Visu schreiben. Falls noch nicht geschehen, schau Dir mal den "JavaScript 3D Floorplan" auf der Open Automation Homepage an. Da ist die Config auch nur ein extrem simples XML...

Mit meiner Arbeit bin ich fertig, wenn Text, 2D und 3D beliebig gemischt werden können und die Seitenübergänge dazwischen schön funktionieren. Aber da fehlt auf der 3D Seite noch das Animierte Stockwerk-Wechseln und in-den-Raum-zoomen... (und davor ggf. eine reimplementierung mit Canvas oder WebGL, wobei das SVG schon erstaunlich schnell ist - aber es kann ja noch schneller und weicher gehen )
Außerdem ist da der Code noch nicht Live-Update fähig, d.h. die Wände (also der Offset auf beiden Seiten der Mittellinie und deren Schnittpunkte mit den anderen Wänden) werden nur 1x zur Laufzeit berechnet. Wenn man das nun beim interaktiven Punkte-Verschieben macht, dürfte die Performance im Knie sein...

Ich meinte integrierte Authentifizierung.

Die kommt noch zur allgemeinen Visu dazu (das Protokoll hat dazu ja schon einen gewissen Teil enthalten).
Ist aber erst ein Theme zur öffentlichen Beta oder kurz drauf.

[netzkind]

Was da nicht fehlen sollte (mittelfristig) ist das Auswerten der /etc/wiregate/eibga.conf damit man die GAs nicht per Hand übertragen muss.

Jo, das hab ich mir beim Testen auch schon ein paarmal gewünscht - hier in der Auflistung dann aber einfach vergessen
Die Idee mit dem serverseitigen Skript zum Parsen finde ich richtig. Ich weiß jetzt nicht genau was du mit "CometVisu Stil mäßig" meinst - ich dachte jetzt an eine einfache Objektstruktur als JSON.

Dann sollte man auch gleich /etc/wiregate/eibga_hg.conf und /etc/wiregate/eibga_mg.conf mit integrieren, um die KNX-Adressen hierarchisch darstellen zu können - unterhalb der Connectoren dann

Bitte bei dem ganzen beachten: die CometVisu-Visualisierung ist aktuell nur Text basierend. Die Erweiterung auf 2D und sogar 3D Grafik ist aber schon fest eingeplant (d.h. Widgets so wie jetzt, nur mit Angabe der Position und meist ohne Label).
=> Alles was man jetzt macht, sollte sich darauf erweitern lassen.

Ich hoffe eigentlich den datenverarbeitenden Teil des Javascripts relativ gut erweiterbar gestaltet zu haben.

Ist mit 2D eine Grundriss-Draufsicht gemeint? Dann würden die bisherigen Element ja praktisch nur um zwei Koordinaten erweitert werden brauchen - das bekommt man dann auch per Javascript wieder in die Config.

Die Frage ist dann auch wie der "Grundriss" dargestellt werden soll - background-image vom User, oder brauchts da noch ein CAD-Plugin für den Config-Editor?

Das macht nichts - Sicherheit gehört eh auf den Server und nicht auf den Client.
(Und falls Du die save_config.php damit gemeint hast, dann macht's auch nichts, die bekommen wir schon noch sicher[..])

Ich meinte integrierte Authentifizierung.
Die save_config.php ist in sich relativ starr was böswillige Manipulation von außen angeht. Der Dateiname ist hartkodiert, einzig ein Suffix lässt sich anhängen, wobei das per Regex (preg_replace, also binary-safe) gegen eine Whitelist geparsed wird. Eval und andere Schweinereien kommt nicht in meinen Code. Im schlimmsten Fall zerlegt jemand die Config, oder schießt den Prozess ab der die Config schreiben soll (memory_limit, max_execution_time) - was man für ein DoS nutzen könnte, wenn man es drauf anlegt.

Grüße,
Julian

[Chris M.]

Vorschlag: /etc/cometvisu/*.xml ? ins web wird das dann per symlink bzw. vom PHP direkt angesprochen.

webserver mit schreibzugriff auf irgendwas unter /etc

Ich fand den Vorschlag gut und da nur per Symlink eingeblendet eigentlich auch sicher.
Der einzige Angriff, den ich mir da vorstellen kann, wäre ein Prozess der ein Out-of-Diskspace provozieren möchte - doch ein /etc mit 0 Bytes left macht auch noch lange keinen DoS...

Letztendlich sollte sich mal jemand mit Admin-Erfahrung und der sich dafür zuständig fühlt (starkes schielen Richtung Makki...) die LSB zu Gemüte führen (oder was auch immer hier maßgeblich ist) und eine Standard konforme Lösung finden.

[Chris M.]

Ich hab grade eben mal einen browserbasierten Inline-Config-Editor ins SVN eingecheckt.

Wow! Du machst mich fertig...

Was ich noch auf der Ideenliste habe was eventuell implementiert werden könnte;
- Validierung für die Eingabefelder, speziell für Pflichtfelder; aktuell fliegt einem noch das Javascript um die Ohren wenn man DPT oder address weglässt oder falsch schreibt

Was da nicht fehlen sollte (mittelfristig) ist das Auswerten der /etc/wiregate/eibga.conf damit man die GAs nicht per Hand übertragen muss.
Schwierig wird dabei, dass die CometVisu natürlich nicht auf KNX beschränkt ist und daher dieses Feature universeller sein sollte.
Evtl. wäre ein Server seitiges PHP Script passend, dass die eibga.conf parst und (CometVisu Stil mäßig) als JSON übergibt. Diese Skript könnte dann auch noch xPL, ..., mit übergeben - oder von einem universelleren Backend, wie einer Logik-Engine , ersetzt werden, dass dann halt nur das selbe JSON Format sprechen müsste...

- die Liste der mappings, styles editieren
- Name der Hauptseite ändern
- kopieren/verschieben zwischen mehreren Seiten - über eine Art Zwischenablage
- die Editor-Elemente anhübschen

Wenn's nicht da stehen würde, hätte ich's fast vorgeschlagen

Bitte bei dem ganzen beachten: die CometVisu-Visualisierung ist aktuell nur Text basierend. Die Erweiterung auf 2D und sogar 3D Grafik ist aber schon fest eingeplant (d.h. Widgets so wie jetzt, nur mit Angabe der Position und meist ohne Label).
=> Alles was man jetzt macht, sollte sich darauf erweitern lassen.

Aber ich fürchte schon, dass ich mit 2D mal kurz Gas geben muss, dann wird's klar (3D ist dann nur noch eine Ableitung davon)

Der Editor hat NULL Sicherheitsbewusstsein

Das macht nichts - Sicherheit gehört eh auf den Server und nicht auf den Client.
(Und falls Du die save_config.php damit gemeint hast, dann macht's auch nichts, die bekommen wir schon noch sicher - wir sind hier ja nur in einer frühen Beta und jeder ist sich im klaren, dass ich einen geheimen Button eingebaut habe, der die Festplatte formatiert )

Da ich nur mein eigenes Szenario getestet habe empfehle ich DRINGEND vor dem Testen ein Backup der eigenen visu_config.xml zu machen.

Und ich empfehle, zum Entwickeln einfach parallel ein Verzeichnis aufzumachen (bei mir /var/www/visu_svn) - und das kann man sich sogar per SVN ziehen und ist damit immer am Puls der Zeit, ohne die reale Visu zu gefährden. Die würde dann immer schön per WireGate-Update aktualisiert werden.

[Chris M.]

Der pfad/Name zur visu_conf.xml sollte vielleicht vom /cgi-bin/l zurück gegeben werden

Hm, verstehe ich nicht ganz. Was willst Du genau? Bzw. was willst Du machen?

[NilsS]

Da ja nachher eigentlich nix mehr wohin muss.

tendiere ich für chroot nach /usr/local/CometVisu
mit /usr/local/CometVisu/htdoc/cgi-bin/.. für die C
und
/usr/local/CometVisu/tmp/wiregate socket
und den configs in
/usr/local/CometVisu/etc/CometVisu

btw. die security by umbenn ist ja nicht meine Welt.

aber lieber doch gleich jetzt nach best practice.

/var würde ich für nen schreibenden webserver auch nicht als docroot nehmen, da auf /var ja auch die logfiles sind die evtl. bei b...sh.. nicht mehr geschrieben werden können.

Auch wenn ne AUTH davor kommt. gibt bestimmt einige die das auch für public irgendwas nutzen wollen.

[makki]

webserver mit schreibzugriff auf irgendwas unter /etc

Naja, so unüblich ist das nicht.. Aus einer Welt kommend, wo die Sicherheit durch umbennen der startav.htm in etwas geheimes hergestellt wird
Wo sowas hingehört ist nun sicherlich eine Frage der sichtweise, der Webserver braucht aber nunmal Schreibrechte drauf, wenn es per Browser geändert werden soll..

Makki

[NilsS]

Die config hat da natürlich mittelfristig garnichts verloren, DB finde ich etwas überzogen, xml tuts doch IMHO..

in meinen Augen ist XML auch eine DB

Vorschlag: /etc/cometvisu/*.xml ? ins web wird das dann per symlink bzw. vom PHP direkt angesprochen.

webserver mit schreibzugriff auf irgendwas unter /etc

Security: kann man IMHO wirklich später nachrüsten, das hält glaube ich derzeit nur auf und es geht ja jederzeit.. cgi-bin/l ist ja nur ein Platzhalter..

Ja denke ich auch, da gehts auch glaube ich nicht um config sondern nur die Fähigkeit GAs zu sehen oder zu schalten

[makki]

coole Sache! Denke auch vom Ansatz die richtige Richtung.
Schön finde ich, das man das Ergebniss gleich sieht und bedienen kann..

Info: funzte auf Anhieb mit Ubuntu FF3.6, im chromium kann man die Felder nicht ändern.

zwecks GA's: kann ich auch beim import gleich irgendwie als json/xml rausschreiben? einfach bescheidsagen..

Die config hat da natürlich mittelfristig garnichts verloren, DB finde ich etwas überzogen, xml tuts doch IMHO..
Vorschlag: /etc/cometvisu/*.xml ? ins web wird das dann per symlink bzw. vom PHP direkt angesprochen.
Ich sollte/wollte das eigentlich schon im initialen package machen

Security: kann man IMHO wirklich später nachrüsten, das hält glaube ich derzeit nur auf und es geht ja jederzeit.. cgi-bin/l ist ja nur ein Platzhalter..

P.S.: Natürlich kann man das theoretisch auch gleich in pywiregate einwurschteln, mit der Gefahr viele voneinander abhängig Baustellen zu haben, denke es ist erstmal auch wichtig was eigenständiges "zum anfassen" zu haben..

Makki

[netzkind]

wenn es sich nachher dabei nicht um eine Datei, sondern eine Datenbank o.ä. handelt sicher noch einfacher

Richtig, und relativ leicht einflanschbar. Die Übersetzung vom JSON in das XML macht ein PHP-Skript - das könnte nun statt DOMDocument-Objekte zu erzeugen die Daten auch anders umsetzen, ohne dass man an die Datenpräsentation oder Verarbeitung im Javascript ranmüsste.
Man kann das Backend also beispielsweise auch serverseitig konfigurierbar machen.

Grüße,
Julian

[NilsS]

Vorraussetzung für die Funktionsfähigkeit des Editors ist, dass visu_config.xml für den Webserver-Prozess schreibbar ist.

wenn es sich nachher dabei nicht um eine Datei, sondern eine Datenbank o.ä. handelt sicher noch einfacher

[netzkind]

Ich hab grade eben mal einen browserbasierten Inline-Config-Editor ins SVN eingecheckt.
Bislang gibt es den Code noch nicht als Debian-Paket zum installieren sondern nur im Subversion-Repository.

Getestet bislang nur auf Windows XP (FF3.6 und IE8 - wobei letzterer sowieso grade Unsinn angezeigt hat, unerklärlicherweise).

Vorraussetzung für die Funktionsfähigkeit des Editors ist, dass visu_config.xml für den Webserver-Prozess schreibbar ist.

Was der Editor bislang kann:
- widgets und pages innerhalb einer Seite umsortieren
- widgets hinzufügen, löschen, bearbeiten
- pages hinzufügen, löschen, umbenennen
- die daraus resultierende Config direkt auf den Server speichern

Was ich noch auf der Ideenliste habe was eventuell implementiert werden könnte;
- Validierung für die Eingabefelder, speziell für Pflichtfelder; aktuell fliegt einem noch das Javascript um die Ohren wenn man DPT oder address weglässt oder falsch schreibt
- die Liste der mappings, styles editieren
- Name der Hauptseite ändern
- kopieren/verschieben zwischen mehreren Seiten - über eine Art Zwischenablage
- die Editor-Elemente anhübschen


Der Editor hat NULL Sicherheitsbewusstsein - die wichtigsten Dateien liegen aber in einem eigenen Ordner, so dass man mit .htaccess zumindest ein Grundgefühl von Sicherheit herstellen könnte. Das ist erst mal jedem selbst überlassen.

Der Editor erscheint im Default-Design der Visu - visudesign_custom.js wird nicht berücksichtigt. Technischer Hintergrund ist dass damit Position und Inhalte der "widgets" für den Editor nachvollziehbar sind. Abweichend vom Default-Design werden "line"-Elemente in einer Box dargestellt damit die Editorelemente hineinpassen.

Da ich nur mein eigenes Szenario getestet habe empfehle ich DRINGEND vor dem Testen ein Backup der eigenen visu_config.xml zu machen.

Grüße,
Julian

[NilsS]

Der pfad/Name zur visu_conf.xml sollte vielleicht vom /cgi-bin/l zurück gegeben werden

[makki]

Die UTF8-Nummer.. jaja
Am besten nicht lokal per ssh editieren (macht eh nicht so richtig Spass mit nano etc. ein XML..)
Keinesfalls aber die LANG= dauerhaft ändern, sonst rappelts richtig (ergo, visu_config ist dann gut, die restlichen Sachen geschr**)

Ein harter no-cache beim starten der Visu ist sicher kein Thema, das schafft der lighty hier auch 100x in der Sekunde..

Makki

[Chris M.]

Also nix mit vi :-)

Doch, doch. Vi geht - den nutze ich ja selbst... (auch wenn mir per sshfs dieser Punkt nicht mehr wichtig ist)
Der Trick ist, dass Du das Encoding für deine Konsole passend setzen musst:

export LANG=de_DE.utf8
vi visu_config.xml

(In Zukunft wird das hoffentlich Standard im WireGate)

Wenn das ein wiederkehrendes Problem ist kann man auch jQuery so einstellen dass es ein Umgehen des Caches erzwingt

Gute Idee!

Müsste man abwägen wie wichtig der Browser-Cache fürs XML ist wenn das System dauerhaft in Betrieb ist und sich am XML nicht mehr viel ändert.
Bei Interesse kann ich das ins SVN einchecken.

Ja, bitte einchecken.

Der Reload-Button ist eh noch ein Relikt meiner Entwicklungszeit - der da gar nicht so unpraktisch war. In eine finale Visu gehört der natürlich nicht. Daher sehe ich es auch absolut i.O. an, wenn die XML jedes mal neu geladen wird.