Automatisches Scaling bei Diagrammen...

[netsrac]

Moin Jungs,

gibt es irgendeine Chance, das automatische Scaling bei den Diagrammen zu unterbinden, bzw. Fix zu definieren in welchem Bereich die Y-Achse liegen soll?!

Hintergrund ist der, dass ich gerne die Innentemperatur verschiedener Räume visuell vergleichen will und da ist es einfach doof, dass die Skalierung bei den Diagrammen nicht gleich ist. So wäre es für die Innentemperatur schön, die Werte z.B. zwischen 16 und 25 Grad fix skalieren könnte.

Habe mal im Plugin-Source geschaut, aber so direkt nix gefunden. Denke mal, dass man das via Parameter an das "rrdfetch" machen muss, oder?!


Danke wie immer für Eure Hilfe...Netsrac

[JNK]

Nein, das geht im Augenblick nicht. Das ist allerdings in meiner lokalen Kopie implementiert als yaxismin="value" und yaxismax="value".

Ich werd edas dann mal ins SVN committen.

Gruss,

der Jan

[netsrac]

Ja, jetzt habe ich es auch geschafft. Habe einfach zwei neue Parameter für min und max hinzugefügt. Funzt super.

Gebe ich nix an, dann nimmt er das automatische Scaling, gebe ich einen min und max Wert an, dann wird nur in diesem Bereich skaliert.


Danke...Netsrac

[JNK]

Für alle anderen auch: Die SVN-Version kann yaxismin/yaximax jetzt auch (ab Rev. 679).

Gruss,

der Jan

[netsrac]

Hab heute das erste Mal den Editor bei den Diagrammen genutzt und dannach ging das Diagramm nicht mehr, weil er einen anderen Wert für das RRD eingesetzt hat.

Mit dem min/max hat sich hier auch ein Dropdown eingeschlichen, womit ich die RRDs auswählen kann.

Das funkt aber bei mir nicht (okay, gebe zu, ist kein Wiregate).

Ist das so gewollt? Wie werden die RRDs ermittelt? Oder kann man ein Textfeld machen womit man das Dropdown überschreiben kann?


Danke...Netsrac

[makki]

Das steht als "FIXME:" drin, das zugehörige PHP liefert *.rrd unter /var/www/rrd/, da müssen die halt denn nun erstmal liegen (also entweder im PHP den Pfad ändern oder nen symlink setzen)

Edit: oder noch besser: fixen das bei einer Null-Antwort vom PHP wieder ein Textfeld kommt und das commiten

Makki

[netsrac]

Das steht als "FIXME:" drin, das zugehörige PHP liefert *.rrd unter /var/www/rrd/, da müssen die halt denn nun erstmal liegen (also entweder im PHP den Pfad ändern oder nen symlink setzen)

Die erste Gemeinheit war ja, das Ding nicht im Plugin-Verzeichnis zu verstecken, sondern in's edit. Da hätte ich im Leben nie gesucht :-)

Edit: oder noch besser: fixen das bei einer Null-Antwort vom PHP wieder ein Textfeld kommt und das commiten
Makki

Ich werde mir das mal anschauen, zumal das PHP einen Sack voll Warnings ins Log schreibt. Da ich meine Temperaturen via einem EZControl über Funk bekomme, habe ich hier auch nicht die gewohnte Wiregate Notation im Dateinamen.

Melde mich, sobald ich was habe...mal schauen, was die Mittagspause bringt :-)

Gruß, Netsrac

[netsrac]

Okay, hier ein update des "get_widget_diagram.php" was mit nicht-ow-sensor konformen Dateiname besser umgehen kann und das Logfile auch nicht mehr mit warnings vollmüllt:

<?php
define('FILE_GA', "/etc/wiregate/eibga.conf");
define('FILE_OW', "/etc/wiregate/owsensors.conf");
define('DIR_RRD', "/var/www/rrd/*.rrd");


$arrOW = array();
if (true === file_exists(FILE_OW)) {
    $arrOW = parse_ini_file(FILE_OW, true);
}

$arrGA = array();
if (true === file_exists(FILE_GA)) {
    $arrGA = parse_ini_file(FILE_GA, true);
}

$arrAdresses = array();

foreach (glob(DIR_RRD) as $filename) {
    $filebase = basename($filename);
    $arrRRDParts = explode("_", $filebase, 2);

    if (count($arrRRDParts) > 1) {
      $arrRRDtype = explode(".", $arrRRDParts[1], 2);
    } else {
      $arrRRDtype = array();
      $arrRRDtype[0] = "unknown";
    }

    // Get address from filename if proper format
    $address = "unknown";
    $dpt     = "unknown";
    if (isset($arrOW[$arrRRDParts[0]]['eib_ga_'.$arrRRDtype[0]])) {
      $address = $arrOW[$arrRRDParts[0]]['eib_ga_'.$arrRRDtype[0]];
      if (isset($arrGA[$arrOW[$arrRRDParts[0]]['eib_ga_'.$arrRRDtype[0]]]['DPTSubId'])) {
        $dpt = $arrGA[$arrOW[$arrRRDParts[0]]['eib_ga_'.$arrRRDtype[0]]]['DPTSubId'];
      }
    }

    if (isset($arrOW[$arrRRDParts[0]]['name'])) {
      $name = $arrOW[$arrRRDParts[0]]['name'];
    } else {
      $name = preg_replace("/.rrd$/", "", $filebase);;
    }

    $arrAdresses[$filebase] = array("address" => $address, "name" => $name, "dpt" => $dpt);
}

Header("Content-type: application/json");
print json_encode($arrAdresses);
exit;

?>

Ich sehe hier zwei potentielle "Unschönheiten":

1. Jedes PHP Script unter visu/edit definiert die Pfade neu. Es wäre doch nett, hier mit einem globalen config-file zu arbeiten. Mir ist zwar klar, das die CV primär von einem Wiregate ausgeht, aber es wäre doch schön, wenn es auch für andere Nutzer funktioniert, ohne dass man hier durch 1.000 Files editieren muss.

2. Im Editor (bei mir aktuell die RRDs) wird trotz leerer Liste von Files halt ein leeres dropdown angezeigt. Es wäre natürlich schön wenn man stattdessen ein input-text Feld bekommt. Alternativ kann man einen Dummy-Eintrag im "get_widget_diagram.php" machen, der darauf hinweist, dass man gefälligst den Pfad ändern soll :-)

Gruß, Netsrac

[makki]

Danke, schaue ich mir an, wenns nichts kaputtmacht wirds commited..
Und ja: Das PHP gehört da nicht hin (eigentlich gehört das eh unter /usr/lib/cgi-bin/.. aber ...)

1) und 2): fühl dich frei, es ist freie Software, dieses PHP ist sicher nicht das glanzstück meiner lausigen Programmier-Karriere, irgendjemand muss es halt irgendwann,irgendwie machen und wenn es ein anderer danach verbessert: das ist Sinn&Zweck der ganzen Aktion

Zu 2) wäre ein leeres Textfeld dann sicher besser, eine Meldung per jqnotify aber einfacher.. Naja-> man muss es nur machen..

Makki

[netsrac]

Und ja: Das PHP gehört da nicht hin (eigentlich gehört das eh unter /usr/lib/cgi-bin/.. aber ...)

Naja, ein PHP Script ins CGI-Verzeichnis zu packen ist auch keine gute Idee, denn normalerweise liegt das CGI-Verzeichnis ja außerhalb des Webtrees und somit wird das PHP script dann via das PHP cli aufgerufen, statt dass PHP module vom Apache zu nehmen.

Also das mach bitte nicht...ist her contra-produktiv und frisst zusätzliche Resourcen. Ist doch gerade der Sinn von PHP, dass es neben Deinen HTML-Seiten existieren kann.

Zu 2) wäre ein leeres Textfeld dann sicher besser, eine Meldung per jqnotify aber einfacher.. Naja-> man muss es nur machen..

Ja, genau da liegt mein Problem...nicht unbedingt beim machen. Wenn ich was will, dann findet man schon Zeit. Ich habe eigentlich keine Ahnung von dem ganzen jQuery-Zeugs (sprich, keine Ahnung von jqnotify). Kenne Javascript zwar schon aus den Zeiten von Netscape 2.x wo man für jeden Browser noch andere Methoden brauchte, um ein Objekt zu finden, aber irgendwie ist dabei jQuery an mir vorbeigezogen...brauche dort wohl mal 'nen gutes Buch :-)

...bis jetzt hat mir jQuery mindestens schon 200 graue Haare gebraucht, wenn es darum geht, mit der Inkompatibilität von verschiedenen Versionsn klarzukommen :-(

[makki]

Da trifft der Webentwickler auf den Systemadministrator
irgendwas ausführbares ausserhalb /cgi-bin geht eigentlich garnicht, aber da habe ich jetzt schon so viele paradigmen über Bord geworfen, das es darauf nicht mehr ankommt

Ich wiederhole an dieser Stelle gerne nochmal den Hintergrund:
ich komme aus der Security-Welt..
Aber es ist IMHO völliger nonsens, sich in einem LAN wo der KNX eh by design "offenliegt", einen Kopf darüber zu machen, wer, wie, was Zugriff auf die Visu hat.

Also, das LAN muss dicht sein, sonst ist Polen eh offen, ob der eibd als root läuft oder nicht, oder das CGI im Webserver da buffer-overflows hat oder nicht finde ich da herzlich sekundär..
-> Man macht die Sache dicht, mit einem VPN oder "dichtem" Webserver, alles andere ist eh Käse..

Makki

[netsrac]

Da trifft der Webentwickler auf den Systemadministrator

Ach so...Du bist also Webentwickler?! :-)

Ich selbst sehe mich viel mehr auf der Administratorseite....

Aber es ist IMHO völliger nonsens, sich in einem LAN wo der KNX eh by design "offenliegt", einen Kopf darüber zu machen, wer, wie, was Zugriff auf die Visu hat.

Also, das LAN muss dicht sein, sonst ist Polen eh offen, ob der eibd als root läuft oder nicht, oder das CGI im Webserver da buffer-overflows hat oder nicht finde ich da herzlich sekundär..

Nunja, sehe ich nicht ganz so...

Bin kein großer Fan von VPN für "normale" Dinge. Und bei der Visu will ich mir keine Gedanken machen, ob er gerade über 3G oder WLAN im Netz ist. Das soll einfach funktionieren.

Jedes Mal das VPN "booten" nervt.

Ich habe an anderer Stelle etwas Anderes gebaut: Verbindung immer per SSL, das ist klar. Mittels eines Cookies im Browser wird der Zugriff gewährt (ohne VPN und schnick-schnack - mit Cookie funktioniert es einfach). Ist kein Cookie da, gibt es ein Fehler - kein Login Fenster um Bruteforce Angriffe zu verhindern.

Um den Cookie zu setzten muss ich mittelns VPN zugreifen, sprich die Anfragen müssen aus dem lokalen LAN kommen. Sobald der Cookie gesetzt ist, geht es wieder ohne VPN.

Wenn man Lust und Laune hat, dann könnte man auch noch eine Liste von "authorisierten" Maschinen pflegen und so auch remote einem Cookie die Berechtigung entziehen, aber da bin ich im Moment noch nicht.

Da der Webserver nun aber prinzipiell von Außen erreichbar ist, sollte man schon auf Sicherheit achten. Apache läuft bei mir generell in einer chroot Umgebung, so dass man auf nix außerhalb des Webtrees zugreifen kann. Fehlt eigentlich nur noch eine DMZ für den Server...aber das ist viel mehr ein zeitliches Problem....

Einziger wirklicher wunder Punk sind hier die CGIs...

Aber wir schweifen ab: Generell sollten wir schon ein bischen über Security nachdenken. Dazu gehört zumindetens die Möglichtkeit, Zugriffe auf die CGIs zu schützen and so on...und dafür sollten wir irgendwann mal ein globales config-file einführen...


Netsrac

[chriss1980]

bei der Visu will ich mir keine Gedanken machen, ob er gerade über 3G oder WLAN im Netz ist. Das soll einfach funktionieren.
...
Verbindung immer per SSL, das ist klar. Mittels eines Cookies im Browser

Warum so ein Cookie-Gebastel und nicht gleich Client-Zertifikat?

[netsrac]

Warum so ein Cookie-Gebastel und nicht gleich Client-Zertifikat?

Logisch würde das gehen...aber mit 'nem Cookie ist es einfacher.

Der Mechanismus kommt aus einem anderen Projekt, wo nix mit eigener zu installierender Software oder mit Zertifikaten war und statt VPN hat es gereicht, sich mit dem Laptop innerhalb des Firmennetztwerks anzumelden, damit der Cookie gesetzt wird und mit dem konnte man dann halt auch von Außerhalb zugreifen.

War damals die Kundenvorgabe...der wollte nämlich kein VPN in die Company...

[Chris M.]

irgendwas ausführbares ausserhalb /cgi-bin geht eigentlich garnicht

Das macht PHP bewusst anders. Und dafür gibt es auch den Strict Mode, um schlimmes zu verhindern.
(Und DB-Login Credentials gehören normalerweise nicht in's Web-Root)

Zu VPN / SSL: Da bin ich immernoch für gute und praxistaugliche Lösungen offen!
IPSec habe ich mir mal angesehen, gibt ja einige HowTos, aber 3x ineinander geschachtelt mit 3 Kennwörtern (oder so) ist tatsächlich etwas strange.