CometVisu - (interner) Beta-Test

[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]

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]

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.

[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?

[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.]

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.

[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.]

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.

[Chris M.]

Slider:
Min/Max werte um z.B. Warmwassertemp von 25-55°C regeln zu können.

Style und Mappings evaluiren.
also nicht statisch value="1" sondern value="0-19"

Ist jetzt drinnen (die Doku im Wiki muss noch aktualisiert werden...)

@all: wenn man im SVN mehr als kosmetische Korrekturen macht, bitte neben den SVN Kommentaren (was sehr gut läuft!) auch die ChangeLog-Datei auf Stand bringen. Sonst wird's später einfach unnötig mühsam beim Release.

[netzkind]

Hi Chris,

@all: wenn man im SVN mehr als kosmetische Korrekturen macht, bitte neben den SVN Kommentaren (was sehr gut läuft!) auch die ChangeLog-Datei auf Stand bringen. Sonst wird's später einfach unnötig mühsam beim Release.

Haben wir die Möglichkeit fürs Packaging das Changelog automatisch aus den SVN-Kommentaren zu erzeugen?

Grüße,
Julian

[makki]

@all: wenn man im SVN mehr als kosmetische Korrekturen macht, bitte neben den SVN Kommentaren (was sehr gut läuft!) auch die ChangeLog-Datei auf Stand bringen.

!

Featurewunsch: eMail an die Devel-Liste bei commits (hier? so in der Art geht das wohl auch bei SF)
solange täglich was passiert ja kein Thema, aber ich denke es ist sowohl für die Entwickler als auch die "Consumer" einfacher wenn man "bepushed" wird; ich monitore ja so einige Projekte und würde mir das bei manch anderen wünschen! (statt alle 1-10 Wochen mal zufällig zu schauen..)

Zu den Releases hab ich dann übrigens auch schon konkrete Ideen: man kann quasi vollautomtisch neue Releases (also nicht svn sondern .tar.gz als File) per crontab von dpkg "watchen" lassen und builden - das wäre der optimalzustand (ich bin ja ansich ein sehr fauler Mensch )

FHS les ich mir nochmal durch, auch aktuell ist natürlich bei weitem nicht alles optimal und ich bin auch kein Packaging-Gott, aber ein paar Sachen glaub ich weiss ich schon darüber (warum es sicher nicht in /usr/local landet z.B. )
Ich will ja, das sowas ganz wirklich "upstream" in die IMHO beste und verbreitetste Distribution gehen kann!
Sooo unrealistisch ist das mittelfristig auch nicht, es muss sich halt jemand drum kümmern..

Makki

[makki]

Haben wir die Möglichkeit fürs Packaging das Changelog automatisch aus den SVN-Kommentaren zu erzeugen?

Klingt nach guter Idee, schau ich mir mal an!
Problem allerdings: ins SVN commited man mal gerne und schnell (ich zumindest ins eigene), von einem changelog erwarte ich eher "Feature/Fix xy" als "Feature XY, Fix Z, Fix A, Fix B"

Ich versuch mir mal was auszudenken, das Changelog fürs .deb ist ja eh (eigentlich) separat, wenn man nach einem festen Prefix parsen kann..? Aber ich schau mir mal an wie die grossen Jungs das machen.

Makki

[netzkind]

[...] auch die ChangeLog-Datei auf Stand bringen. Sonst wird's später einfach unnötig mühsam beim Release.

Jetzt weiß ich auch wieso ich das Changelog immer übersehe: Changelog, AUTHORS, README etc. sind nicht unterhalb von visu, wie ich es eigentlich erwarten würde (gekapselt, alles an einem Ort) - sondern eine Ebene drüber.

Wenn ich das direkt in /var/www so auschecken würde so dass die visu unter "/var/www/visu/" liegt, hätte ich so Changelog, Readme etc. in /var/www - und damit in einem ganz anderen Kontext.

Ein Fehler meines Betrachtungswinkels?

Grüße,
Julian

PS:
echte neue Features trag ich trotzdem gerne ab sofort ins Changelog ein!

[makki]

Wenn ich das direkt in /var/www so auschecken würde so dass die visu unter "/var/www/visu/" liegt, hätte ich so Changelog, Readme etc. in /var/www - und damit in einem ganz anderen Kontext.

Naja, ich glaub das machen die meisten auf SVN-Basis wie sie lustig sind, fürs .deb schiebe ich das alles momentan manuell um (von ./ in /var/www/) - ist aber glaube ich normal

Das SVN/CometVisu/changelog gehört ja in /usr/share/doc/cometvisu/changelog, aber mein Gott, das wurschtelt man 1x in debian/rules..
Was ich sagen will: das ist mein (packaging)-Problem, legt das wohin es passt, was hier "richtig" ist weiss ich ned, solange es sich selten ändert - egal

Makki

[Chris M.]

Jetzt weiß ich auch wieso ich das Changelog immer übersehe: Changelog, AUTHORS, README etc. sind nicht unterhalb von visu, wie ich es eigentlich erwarten würde (gekapselt, alles an einem Ort) - sondern eine Ebene drüber.

Die sind schon richtig (s.u.) gekapselt - im trunk unter CometVisu

Wenn ich das direkt in /var/www so auschecken würde so dass die visu unter "/var/www/visu/" liegt, hätte ich so Changelog, Readme etc. in /var/www - und damit in einem ganz anderen Kontext.

Ein Fehler meines Betrachtungswinkels?

Dabei hatte ich mir gedacht, dass man .../trunk/CometVisu/visu in sein Web-Server-Verzeichnis (bzw. ggf. ein Unterverzeichnis) auscheckt und so nur das auf dem Server hat, was auf den Server gehört.
So hab ich's zumindest auf meinem WireGate und bin eigentlich ganz glücklich diesbezüglich damit.

Das Problem (und das hatte ich bei dieser Entscheidung absolut übersehen) ist, dass nun das ChangeLog "weg" ist. D.h. wenn ich was entwickle und in's SVN hochlade, muss ich immer getrennt das ChangeLog anfassen und das getrennt hochladen. So geht da auch die SVN interne Referenzzählung diesbezüglich kaputt (nicht schlimm, aber auch nicht schön).

Hat jemand einen guten Vorschlag wie wir damit umgehen sollen?
So lassen? (Aber wie dann mit ChangeLog umgehen?)
Alles in ein Verzeichnis (d.h. visu aufgeben und nach .. verschieben)? Aber wie geht man dann am besten mit der Live-Entwicklung um? Und ist das Verzeichnis nicht dann arg unaufgeräumt (d.h. Meta-Infos nicht sauber getrennt)?