Automatisches Scaling bei Diagrammen...

[makki]

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

Im realen Leben bin ich eher der Spielverderber, also der sysadmin (siehe siriproxy/ruby, da bekommt man Magengeschwüre, wenn sich der nichtsahnende Anwender im Home-Verzeichnis mal ein komplettes ruby vom Source baut, nur weil er keine Ahnung hat, wie es richtig gemacht wäre..)

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.

Na dann erzähl doch mal im Detail, das klingt interessant (entspricht zwar dem Sicherheitsniveau von Hanni aber..)

und dafür sollten wir irgendwann mal ein globales config-file einführen...

Hmm den Punkt hast Du IMHO noch nicht ganz erfasst, das ist nicht Job der Visu sondern der Webserver-config. Das "globale config-file" gibt es schon, das heisst z.B. /etc/lighttpd/conf-enabled/05-auth.conf
Das bekomm ich halt nur nicht supported, weil man wissen muss was man tut. Und naja, das ist auch schon gut dokumentiert..
Mei das ist halt harter Stoff aber kannst du einem Anwender die Apache-config erklären ?
Sollte man auch nicht, weil entweder man weiss wirklich was man da tut oder es ist eben gefährlich.
Vermeintliche Sicherheit vorzugauckeln ("ist alles ganz easy") ist nicht meine Art, gescheit oder garnicht. Gescheit, auf Sicht von Jahren, geht nicht für 357.- EUR.. Security is a process, not a product (Bruce Schneier)

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

Weil man das in 100J keinem Endanwender erklärt bekommt.. Es gibt auf dieser Erde wissentlich >50 WG die einen Reverse-SSL Proxy mit Client-Auth per Zertifikat machen; das kann ich einrichten, aber mir nicht den Schuh anziehen, das für Hanni zu supporten oder zu erklären
Das geht technisch, problemlos, man muss aber dann halt wissen was man tut, was ein Zertifikat ist, warum es CRL's gibt - und all den Kram..

Das macht PHP bewusst anders. Und dafür gibt es auch den Strict Mode, um schlimmes zu verhindern.

Naja, das ist trotzdem Schrott.. Eigentlich.. Aber wir müssen die Kirche im Dorf lassen, deswegen ists so einfacher und praktisch richtig


-> Die einzige Möglichkeit, die ich einem Endanwender guten Gewissens an die Hand geben kann ist nunmal das VPN, es geht natürlich (technisch) auch anders, aber dann muss man wissen was man tut und das auch 24x7x365 verfolgen, pflegen, ...
Das im Nachtrag (wie lange?) in hunderten Varianten zu betreuen ist schlicht nicht drin..
Das geht mit einem OpenVPN, wo ich eh die devel-Liste mitlese aber nicht für hunderte veschiedene configs eines Webservers.
Gescheit oder garnicht, man weiss was man da tut oder betet, Security im Internet ist eben kein "Nebenjob"..
Und ich werde einen Teufel tun und das Gefühl vermitteln, das dem so wäre, indem man sich eine magische Box 1x reinstellt, weil das schlicht eine Lüge ist. In den letzten paar Monaten hat man "mal eben" ein paar gravierende Lücken im ewig alten SSL/TLS festgestellt.
Security per "Einmal-aktion" ist Augenwischerei, denn das kann schon morgen ganz anders aussehen.. Sorry, das ist nicht mein Versäumniss sondern die Realität, ich möchte nur so ehrlich sein, das auch zu sagen, das man im kleinen Umfeld eigentlich keine Chance hat, da überhaupt mitzukommen..

Für den VPN-Server können wir Updates gewährleisten.

Makki

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

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

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

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

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

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]

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]

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

[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

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

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

[JNK]

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

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]

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