Ein Cloud Access Security Broker, kurz CASB, schützt Anwendungen, die in eine Cloud verlagerte wurden. Er befindet sich als Schnittstelle zwischen dem Nutzer und der Cloud, protokolliert die Kommunikation und gibt bei verdächtigen Aktionen Alarm. Warum ist das sinnvoll?
Allein das Wort ist schon ein Zungenbrecher. Auch wenn so klingen mag, als sei ein neuer amerikanischer Geheimdienst gegründet worden, führt diese Fährte in die falsche Richtung. Ein CASB ist ein Cloud Access Security Broker. Und um die Abkürzung ohne Schwierigkeiten über die Lippen zu bringen, redet man bevorzugt von einem CAS B. Heinz Becker würde es wahrscheinlich als „Käs-Bie“ bezeichnen, was dem Englischen recht nahekommt.
Allerdings ist damit noch nicht geklärt was ein solcher Cloud Access Security Broker (CASB) macht. Laut Definition sorgt er sich darum, dass die Kommunikation zwischen Ihrem Unternehmen und den Cloud-Anwendungen nur so erfolgt, wie es die Sicherheitsrichtlinie des Unternehmens vorsieht.
Warum brauche ich einen CASB?
Jetzt mag es viele Unternehmen geben, die Cloud-Anwendungen aus Prinzip und aus Sicherheitsbedenken ablehnen. Und davon gibt es in Deutschland nach wie vor sehr viele. Trotzdem sagt Gartner, dass bis ins Jahr 2020 etwa 85% der Firmenkunden einen CASB einsetzen werden. Das liegt auch daran, dass nahezu jedes Unternehmen mit einer Schatten-IT zu kämpfen hat.
Mitarbeiter werden kreativer und damit sind nicht nur die sog. Digital Natives gemeint, die immer stärker in den Unternehmen tätig werden. Schnell wird mal ein privater Dropbox-Account verwendet, um Daten mit Kunden oder Lieferanten auszutauschen, oder vielleicht gar Amazon Drive, was gar nicht so unwahrscheinlich ist bei 100 Mio. Amazon Prime Kunden weltweit. Und somit werden quasi durch die Hintertür immer mehr Cloud-Dienste genutzt, ohne dass die interne IT davon Kenntnis hat.
Was macht ein CASB genau?
Dies ist bereits der erste Ansatzpunkt eines CASB. Durch die Auswertung unterschiedlicher Log-Quellen ist er in der Lage, Transparenz zu schaffen. Welche Cloud-Dienste werden wie und von wem aktiv genutzt? Und alleine diese Information sorgt bei vielen Unternehmen für eine große Überraschung.
Mit der Transparenz ist damit schon einmal die Basis geschaffen. Darüber hinaus bietet der CASB die Möglichkeit, die Nutzung von Cloud-Anwendungen zu kontrollieren, gemäß der Richtlinie des eigenen Unternehmens. Private Dienste können geblockt werden. Bei den geschäftlich freigegebenen Services wird eine Mehr-Faktor-Authentifizierung eingefordert.
Und es ergeben sich noch weitere Möglichkeiten der Steuerung. So können Downloads auf firmeneigene Hardware gewünscht sein. Auf private oder nicht registrierte Endgeräte wird der Datentransfer jedoch unterbunden.
Ohne Frage eines der interessantesten Merkmale eines CASB ist jedoch deren Fähigkeit die Daten in den freigegebenen Cloud-Diensten zu verschlüsseln und zwar mit dem Key des Unternehmens und nicht mit dem des Cloud-Anbieters. Somit könnte man überspitzt gesagt sogar Cloud-Dienste in Anspruch nehmen, die nicht innerhalb der EU gehostet werden. Dem Cloud-Provider liegen nur verschlüsselte Daten vor, die weder er noch eine höhere Instanz ohne großen Aufwände dechiffrieren könnten.
Was sich so kryptisch anhört, kann somit ein wichtiger Baustein in einer Infrastruktur werden, die bereit ist für die Anforderungen von Industrie 4.0, ohne jedoch auf die nötigen Sicherheitsvorkehrungen zu verzichten.
Fazit
Cloud-Dienste werden von uns allen täglich genutzt. Oftmals merken wir dies als Nutzer gar nicht mehr wirklich. Das beste Beispiel hierfür ist Office365 von Microsoft. Daher hätte fast jedes Unternehmen einen Einsatzfall für einen CASB.
Alternativ kann eine Steuerung von Cloud-Diensten auch über eine NG-Firewall oder über Application Whitelisting stattfinden. Allerdings würde dies einen erhöhten Administrationsaufwand mit sich ziehen.
Zum Autor
Stefan Körner Körner Beratung
Automatisierte Softwareverteilung und Patch-Management für Windows-Clients
Die Verteilung von Software und Software-Updates ist eine der wichtigsten Hauptaufgaben einer IT-Abteilung, beinahe täglich erscheinen neue Updates, Patches und Aktualisierungen, die die Programme verbessern oder kritische Sicherheitslücken schließen. Um die Administratoren hierbei zu unterstützen, gibt es zahlreiche Client Management Tools, die diese Aufgaben übernehmen und vor allem automatisieren können.
Im Rahmen meines Praxissemesters bei der Thinking Objects GmbH war es meine Aufgabe, die verschiedenen Tools am Markt in einem Proof of Concept in einer Testumgebung auf Tauglichkeit zu prüfen und die beiden am besten passenden Lösungen zu präsentieren. Das Projekt sollte als Entscheidungshilfe dienen, welches System in Frage kommt und ob die Einführung überhaupt sinnvoll ist.
Projekt Teil 1: Evaluierung
Vorbereitung: Testumgebung
Mit Hilfe der Virtualisierungssoftware VMWare erstellte ich eine Testumgebung mit folgenden Komponenten:
1x Windows Server 12 R2
1x Windows Server 16
3x Windows 10 Enterprise Edition
Um mit diesen virtuellen Maschinen eine möglichst realitätsnahe Testumgebung zu schaffen, habe ich eine Active Directory mit der Domäne „To.test.com“ angelegt. Zu diesem Zweck habe ich den Server 12 R2 als Domain-Controller konfiguriert und anschließend die anderen virtuellen Maschinen in die Domäne eingebunden (Abb.1).
Abbildung 1: Testumgebung
Microsofts Group Policy Objects
Nach dem Einrichten der Domäne habe ich mir zunächst die Group Policy Objects (GPO, Deutsch: Gruppenrichtlinien) genauer angeschaut, ein Feature von Microsoft, mit dem sich Software in einem Domänennetzwerk installieren, updaten und patchen lässt. Dies geschieht über die Verteilung von Installationspaketen (.msi), Transformationsdateien (.mst) und Patch-Dateien (.msp) entweder an User oder an Computer im Netzwerk. Der Administrator kann die Software entweder zuweisen (Push-Verfahren), hier greift die Gruppenrichtlinie beim Einloggen des Users und installiert die Software automatisch, oder nur veröffentlichen (Pull-Verfahren), hier kann der User die Software selbstständig über die Systemsteuerung hinzufügen.
Der Verteilerkreis der Software lässt sich einschränken. Dies geschieht über sogenannte WMI-Filter (Windows Management Instrumentation), diese enthalten SQL-ähnliche Abfragen, die die Wirkung der Gruppenrichtlinien einschränken. Eine typische Abfrage ist z.B. ob es sich beim Zielrechner um ein 32-Bit oder 64-Bit System handelt.
Es besteht auch die Möglichkeit, Software zu deinstallieren, diese muss allerdings vorher auch über die Gruppenrichtlinien verteilt worden sein.
Abbildung 2: Softwareverteilung per GPO
Die Softwareverteilung über Gruppenrichtlinien hat leider einige entscheidende Nachteile:
Es findet keine Inventarisierung statt, der Administrator hat keinen Überblick über bereits installierte Software auf den Zielrechnern.
Es gibt keinerlei Feedback über erfolgreiche oder fehlgeschlagene Installationen.
Es gibt kein Monitoring oder Reporting, es bleibt verborgen, welche Rechner gerade mit der Installation beschäftigt sind, oder ob dabei Fehler auftreten.
Der Installationszeitpunkt ist nicht festlegbar, die Installation erfolgt nur, wenn die User ihre Rechner neu starten, darauf hat der Administrator keinen Einfluss.
Die WMI-Filter sind fehleranfällig, es wird nicht geprüft, ob die Abfrage überhaupt sinnvolle Ergebnisse liefert, bei komplexen Abfragen wird die Fehlersuche schwierig.
Fazit: Um eine transparent organisierte Softwareverteilung zu etablieren, sind Microsofts Group Policy Objects nicht ausreichend.
Übersicht der Softwarelösungen am Markt
Ich habe mir einen Überblick über den Markt der Client-Managementlösungen verschafft und von den jeweiligen Herstellern nach und nach Testversionen angefragt und Angebote eingeholt. Es sind dies im Einzelnen:
SCCM von Microsoft
ca
Ivanti
Kace
BMC Client Management
Accelerite Radia
ZENWorks Configuration Manager
Kaseya Virtual System Administrator
ManageEngine Desktop Central
Baramundi
Aagon ACMP
DeskCenter Management Suite
Asset.Desk FCS Desk Suite
Das Testen
Ich ging bei den verschiedenen Angeboten nach Möglichkeit immer nach dem gleichen Muster vor: Nach dem Einrichten der Serversoftware versuchte ich, die Maschinen im Netzwerk mit dem Server zu verbinden. Dies geschah in der Regel über sogenannte „Agenten“, die per IP-Scan oder über die AD-Konfiguration auf die Rechner verteilt werden konnten. Anschließend startete ich die Inventarisierung und testete die Verteilung der Software Notepad++ mit Hilfe eines msi-Pakets, um es bei Erfolg direkt wieder zu deinstallieren. Einige Anbieter hatten einen Softwarekatalog, über den man die gewünschten Programme auch direkt installieren konnte.
Danach testete ich das Patch-Management, indem ich mir die installierten Microsoft-Patches anzeigen ließ und versuchte, einen Patch zu installieren und einen Patch zu deinstallieren.
Als nächstes versuchte ich, mir verschiedene Reports anzeigen zu lassen und am Schluss versuchte ich mich am OS-Deployment.
Meine Erfahrungen waren sehr unterschiedlich, das Einrichten ging zum Teil ohne Probleme, es gab aber auch Software, die ich nicht ohne Hilfe des jeweiligen Supports ans Laufen bekam (Ivanti, Kace, ZENWorks und Accelerite).
Die Bedienung der Programme ging teilweise intuitiv und selbsterklärend, es gab aber auch Programme, bei denen ich auf die mehrere hundert Seiten starken Handbücher der Hersteller angewiesen war (Ivanti, Kace, Accelerite, DeskCenter, SCCM). Von den Firmen Kaseya und Aagon gab es sehr gelungene Lehrvideos, die Firma Aagon hat diesbezüglich sogar einen eigenen YouTube-Kanal. Rund die Hälfte der Anbieter bot entweder Webcasts oder Online-Demos an, um mir die Benutzung der Software näher zu bringen (ca, Kace, BMC, Kaseya, Aagon und DeskCenter), die Firma Baramundi kam sogar ins Haus und präsentierte ihr Programm vor Ort.
Testsoftware bekam ich fast von jeder Firma, lediglich die Firma Maxxys, die die Software „ca“ vertreibt, wollte drei Manntage in Rechnung stellen, um eine Testumgebung aufzubauen.
Das Testen des OS-Deployments erwies sich in der VM-Ware-Umgebung als schwierig, da das Ausrollen auf Virtuelle Maschinen teilweise nicht unterstützt wurde oder schlicht nicht funktionierte.
Ich bekam jedoch die Möglichkeit, bei den von mir ausgesuchten Testsiegern die Betriebssystemverteilung in einer Testumgebung mit physischen Maschinen zu testen.
Wer kann was?
Um aus der Vielzahl an Angeboten zwei geeignete herauszufiltern, habe ich während des Testens tabellarisch erfasst, welche der notwendigen Anforderungen die jeweilige Software abdeckt. Am Ende stellte sich heraus, dass fast alle die benötigten Anforderungen erfüllen, lediglich bei Kaseya fehlt das Feature der Betriebssystemverteilung (s. Abb. 3).
Kosten
Ein weiterer Aspekt bei der Auswahl von geeigneter Software ist natürlich die betriebswirtschaftliche Seite, aus diesem Grund habe ich mir von allen Anbietern Angebote erstellen lassen und die Kosten für einen Zeitraum von 5 Jahren verglichen (Abb. 4).
Abbildung 4: Kostenübersicht alle Firmen
Es springen dem Betrachter sofort die beiden teuersten Anbieter ins Auge: Microsoft und Accelerite Radia. Die hohen Preise lassen sich leicht erklären: Beide Software-Lösungen zielen auf Unternehmen ab, die Strukturen mit mehreren Tausend Clients haben, die jährliche Pauschale für Support und Wartung fallen dementsprechend hoch aus.
Wenn man die nicht in Frage kommenden teuren Lösungen weglässt, ergibt sich ein freundlicheres Bild (Abb. 5):
Hier ist die Kurve von Kaseya auffällig, die Firma bietet ein Lizenzmodell an, bei dem die Software nicht gekauft, sondern gemietet wird. Das ermöglicht einen günstigen Einstieg, ist aber auf lange Sicht teurer als die Kaufmodelle der Konkurrenz. Das beste Angebot kommt von der Firma ManageEngine, die mit einem Anschaffungspreis von rund 3000 Euro die Konkurrenten deutlich unterbietet.
Die Präsentation der Testsieger
„Meine“ beiden Testsieger sind ACMP von Aagon und Desktop Central von ManageEngine.
ACMP hat mir von allen Software-Lösungen am besten gefallen, es ließ sich leicht einrichten, ist benutzerfreundlich, durch das übersichtliche Dashboard intuitiv zu bedienen und bietet eine Vielzahl an Automatisierungsmöglichkeiten. Es ist mit seiner Abfrageverwaltung sehr SQL-nah und läuft zudem sehr stabil. Preislich liegt die Lösung im Mittelfeld.
Desktop Central von ManageEngine ist mit großem Abstand Preis-Leistungssieger und überzeugt mit einer übersichtlichen Weboberfläche, umfangreichen Report- und Monitoringmöglichkeiten und ist bezüglich Usability, Einrichtung und Funktionsumfang mindestens gleichwertig mit den teuren Konkurrenzprodukten.
Projekt Teil 2: Einführung des Client-Management-Systems Desktop Central bei der Thinking Objects GmbH
Nach der Präsentation der beiden besten Testkandidaten wurde die Entscheidung getroffen, die Client-Management Software Desktop Central der Firma ManageEngine einzuführen, allerdings ohne das Modul der Betriebssystemverteilung, da sich dies bei durchschnittlich 10 neuen Mitarbeitern pro Jahr nicht rechnet.
Da ich das ursprünglich auf 6 Monate angelegte Evaluierungsprojekt bereits nach 3 Monaten erfolgreich abschließen konnte, und aufgrund meiner bereits erworbenen Kenntnisse der Software, wurde mir nun die Umsetzung des Projekts, also die Einführung von Desktop Central anvertraut.
Zeitplan
Zuerst erstellte ich einen Zeitplan mit den für die Umsetzung des Projekts wichtigen Punkten.
Der Plan sah vor, im Dezember 2017 alle Vorbereitungen zu treffen, um im Januar 2018 ein Pilotprojekt mit 20 Clients starten zu können. Nach erfolgreicher Pilotphase sollte das Projekt am 1. Februar 2018 für alle Clients live gehen.
Abbildung 6: Zeitplan 1
Abbildung 7: Zeitplan 2
Datenschutz
Da mit der Client-Management Software viele Daten gesammelt werden, die auch Aufschluss über das Nutzerverhalten geben, erstellte ich einen Bericht mit allen datenschutzrelevanten Informationen zur Prüfung für unseren Datenschutzbeauftragten.
Netzwerkplan mit Firewall-Freischaltungen
Um die benötigten Firewall-Freischaltungen zu beantragen, erstellte ich einen Netzwerkplan:
Beide Lösungen habe ich in einer Live-Präsentation den Entscheidungsträgern von TOsupport vorgestellt.
Abbildung 8: Netzwerkplan
VM erstellen, Windows Server 16 installieren
Nachdem mein Betreuer und Service Desk Supervisor Raffaele Lupo eine Virtuelle Maschine für das Projekt erstellt hatte, installierte ich als erstes Windows Server 16. Zu diesem Zeitpunkt begann ich auch, jeden meiner Schritte zu dokumentieren (Abb. 9).
Abbildung 9: Dokumentation der Windows Server 2016 Installation
Desktop Central installieren und konfigurieren
Nach der Installation von Windows Server 16 inklusive aller Updates, begann ich mit der Installation von Desktop Central. Nach dem Hinzufügen der Domäne und den am Pilotprojekt beteiligten Computern, installierte ich darauf die Agenten, die mit dem Server kommunizieren.
Daraufhin erstellte ich die benötigten Software-Pakete, teilweise über die Templates von Desktop Central, teilweise über eigene -.msi und -.exe Installationsdateien.
Besondere Aufmerksamkeit erforderte hier das Erstellen eines deploymentfähigen Paketes von Microsoft Office mit Hilfe des Office-Anpassungstools. Mit diesem Tool kann man einen Multiple Activation Key (MAK) eingeben und es lassen sich Setup-Eigenschaften wie z.B. AUTO_ACTIVATE anpassen (Abb. 10)
Abbildung 10: Doku – Erstellen der Softwarepakete
Pilotprojekt mit 20 Clients
Nach Abschluss aller Vorbereitungen starteten wir am 2. Januar 2018 wie geplant mit dem Pilotprojekt. Nach und nach wurden auf den Clients der Pilotgruppe die Agenten ausgerollt.
Nach zwei Wochen waren insgesamt 20 Clients in das System eingebunden, Desktop Central funktionierte weitgehend wie geplant.
Schulung der Mitarbeiter und Abschluss des Projekts
Mitte Januar gab es noch eine Präsentation für das Management über das geplante Vorhaben mit Zeitplan.
Für die zukünftigen Administratoren von Desktop Central hielt ich eine interne Schulung ab und erstellte ein Wiki mit der Dokumentation.
Abbildung 11: Admin-Wiki
Ab Februar 2018 wurden die restlichen Clients in das System eingebunden und ich verbrachte die verbleibende Zeit meines Praktikums mit dem Feintuning des Systems, wie z.B. der Patch-Automatisierung oder dem Scheduling von Berichten.
Mit dem Ende meines Praktikums konnte ich ein zuverlässiges, effizientes Client-Managementsystem übergeben, das durch den Grad der Automatisierung zudem sehr wartungsfreundlich ist.
Über mich und mein Praxissemester bei der Thinking Objects GmbH
Als „Spätzünder“ beschloss ich 2015 – nach über 20 Jahren in der Hotellerie und Gastronomie – einen Neuanfang zu wagen und an der Hochschule Heilbronn Angewandte Informatik zu studieren. Ein Entschluss, den ich bis jetzt nicht bereut habe. Auf einer Firmenmesse unserer Hochschule lernte ich die Thinking Objects GmbH kennen; aufgrund meiner ausgeprägten Service-Orientierung wurde mir eine Praxisstelle im Support angeboten, die ich gerne annahm.
Die Stelle entpuppte sich als Glücksgriff: sowohl fachlich als auch persönlich hat mich dieses halbe Jahr nach vorne gebracht und mir innerlich bestätigt, dass meine Entscheidung, Informatik zu studieren, richtig war.
Das Arbeitsumfeld empfand ich als sehr angenehm, es wird hier eine Kultur der offenen Türen gepflegt und die Mitarbeiter sind untereinander alle per Du. Es gibt regelmäßige Feedbackgespräche und die Ausstattung des Arbeitsplatzes ist vorbildlich.
Das Team von TOsupport präsentierte sich als fachlich hochkompetent und jederzeit offen für alle erdenklichen – auch vermeintlich „dummen“ – Fragen, auch im größten Stress fand ich bei meinen Kollegen immer ein offenes Ohr.
Die Arbeit an meinem Projekt hat mir gut gefallen, ich hatte genügend Freiräume, mich in die verschiedenen Gebiete einzuarbeiten und hatte zudem auch Gelegenheit, Einblick in projektfremde Themen zu nehmen.
Die Tatsache, dass mir nach der Evaluierungsphase auch die Umsetzung des Projekts anvertraut und zugetraut wurde, empfand ich als sehr motivierend.
Die Erfahrungen, die ich hier sammeln durfte, werden mir für mein Studium und meinem späteren Berufsleben von großem Nutzen sein. Dafür bedanke ich mich herzlich bei der Thinking Objects GmbH, dem Team von TOsupport und meinem Betreuer Raffaele Lupo.
—
Du möchtest einen kleinen Einblick in die Arbeit als Student bei TO bekommen? Dann schau dir unser Video an:
Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube. Mehr erfahren
Gira- oder Jung-Homeserver zu teuer? Kein Ding! – Raspberry Pi als Helferchen #4
Man baut oder kauft? Klar, im Moment ist das Geld gerade günstig. Dann entscheidet man sich anstatt einer konventionellen Elektroinstallation auf KNX zu setzen. Glückwunsch! Das ist die halbe Miete zum eigenen „Smarthome“.
Was fehlt uns denn noch am Ende? Achja! Ich möchte natürlich meine Lichter, Jalousien, Haustüre, Kameras und vieles mehr auch noch vom Smartphone aus steuern. Also muss ich mir einen Homeserver kaufen, oder? Schnell mal die Jung und Gira Preise gecheckt und dann erkannt, dass das nicht mehr im Budget liegt. Aber nicht verzagen! So ein Homeserver muss nicht teuer sein!
In diesem Artikel der Reihe „Raspberry Pi als Helferchen“ geht es darum, wie mit einfachsten OpenSource Mitteln ein vollwertiger Homeserver-Ersatz geschaffen werden kann, sodass ich meine KNX Installation auch vom Tablet oder dem Smartphone aus steuern kann. Und das alles mit relativ wenig Geldeinsatz. Dieser Artikel richtet sich an diejenigen, die schon Erfahrung mit KNX, Linux und deren Konfiguration haben.
Die Teileliste
Raspberry Pi 3 – ca. 35 €
Micro SDHC Karte mit ~ 8 GB – ca. 15 €
Netzteil 5V, 2,5A – ca. 8 €
KNX IP Schnittstelle (wenn nicht schon ohnehin vorhanden) – Je nach Hersteller zwischen 140 und 200 €, meine Empfehlung Weinzierl IP Interface 730
Optional ein Case für den Raspberry Pi, je nachdem wo er zum Einsatz kommen wird. Es empfiehlt sich ein Case mit Hutschienenhalterung zum Einsatz im Schaltschrank.
Das Werkzeug
Dieses mal benötigen wir keinerlei Werkzeug. Es entfällt somit auch der Abschnitt „Das Handwerk“
Die Vorbereitungen
Es empfiehlt sich für unseren Raspberry Pi Homeserver die aktuellste Version von Debian auf der Herstellerseite herunterzuladen. Da wir keine GUI benötigen werden, wählen wir hier am besten die Lite (Server) Version. Dieses Image übertragen wir auf die SD Karte. Ich nehme unter Windows dazu den Win32 Disk Imager. Nun schließen wir unseren Homeserver an einen Monitor und eine Tastatur an und booten das System. Ich melde mich zunächst als User Pi an und setze ein root Kennwort. Dann melde ich mich als root an und entferne den User Pi und sein Homeverzeichnis. Außerdem hinterlege ich meist meinen SSH Key, damit ich mich nicht mit Kennwörtern rumschlagen muss.
Als nächstes vergebe ich eine statische IP Adresse in meinem Heimnetzwerk, zusammen mit einem Gateway und einem DNS Server. Die Standard Einstellungen am System werden hier als grundlegende Kenntnis vorausgesetzt. Wir machen ein Update & Upgrade des Systems, damit wir auf dem aktuellsten Stand sind. Dann installieren wir Apache2 mit PHP5 und Samba:
Als nächstes legen wir den Benutzer „smarthome“ an und fügen ihn der www-data und der sudo Gruppe hinzu:
adduser smarthome usermod -G www-data,sudo -a smarthome
Dann melden wir uns als Benutzer „smarthome“ an:
su smarthome
knxd – die Kommunikation auf dem Bus
Damit unser Homeserver überhaupt schalten kann, muss er mit dem Bus kommunizieren. Dafür installieren wir einen Treiber, der sich „knxd“ nennt. Grundsätzlich ist die Installation in der git Repository von knxd beschrieben. Diese Zusammenfassung hat für mich funktioniert. Sollten andere Pakete fehlen, müssen diese nachinstalliert werden. Folgende Schritte sind notwendig, um die Abhängigkeiten für die Installation von knxd zu schaffen und die entsprechenden Pakete zu schnüren und zu installieren.
Abschließend muss man die Konfiguration von knxd noch auf die eigene Schnittstelle anpassen. Für mich hat folgendes in der /etc/knxd.conf gut funktioniert (die IP der KNX Schnittstelle muss natürlich angepasst werden):
KNXD_OPTS="-c -b ipt:192.168.1.2"
Nun stoppen wir den Service, tragen einen Autostart ein und starten dann den Service, damit wir testen können, ob unser Homeserver erfolgreich mit dem Bus kommunizieren kann:
sudo systemctl status knxd.socket sudo systemctl status knxd.service
Das Ergebnis sollte so aussehen, wenn alles geklappt hat:
$ sudo systemctl status knxd.service
● knxd.service - KNX Daemon
Loaded: loaded (/lib/systemd/system/knxd.service; enabled) Active: active (running) since Sa 2016-08-13 10:03:27 CEST; 5 days ago Main PID: 30769 (knxd) CGroup: /system.slice/knxd.service └─30769 /usr/bin/knxd -c -b ipt:192.168.10.38
$ sudo systemctl status knxd.socket
● knxd.socket - KNX Daemon (socket)
Loaded: loaded (/lib/systemd/system/knxd.socket; enabled) Active: active (running) since Sa 2016-08-13 10:03:23 CEST; 5 days ago Listen: /var/run/knx (Stream) [::]:6720 (Stream)
Und jetzt zum spaßigen Teil. Wir testen, ob unser Homeserver ein Licht an- und ausschalten kann. Dazu benötigen wir eine Gruppenadresse einer Lampe, hier 0/0/1: knxtool groupswrite ip:localhost 0/0/1 1
Die Lampe sollte angehen.
knxtool groupswrite ip:localhost 0/0/1 0
Die Lampe sollte ausgehen.
Wenn das funktioniert, können wir mit der Installation von SmartHomeNG fortfahren.
Installation von SmartHomeNG
SmartHomeNG ist ein System, das als Metagateway zwischen verschiedenen „Dingen“ fungiert und der Verbindung unterschiedlicher Geräte-Schnittstellen dient. Die Standard-Schnittstelle eines Gerätes wird durch das Metagateway so um viele zusätzliche Schnittstellen erweitert. So ist es möglich, dass die Klingel mit der Musikanlage und dem TV spricht, und deren Wiedergabe unterbricht oder bei Abwesenheit eine Nachricht per Email verschickt.
SmartHomeNG basiert auf Smarthome.py, einem tollen System für Heimautomation von Marcus Popp.
Wir benötigen SmartHomeNG für unterschiedliche Dinge. Am hilfreichsten ist SmartHomeNG aber zum Abbilden von Logiken und zum Anbinden unserer Gruppenadressen (Kommunikationsobjekte) an unsere Visualisierung.
Für die Installation decken wir weitere Abhängigkeiten ab:
Die plugin.conf regelt alle Schnittstellen zu allen Geräten/Plugins, die wir einsetzen wollen. Unter anderem zu der SmartVISU, die wir nachher noch installieren wollen:
# Bis SmartHomeNG 1.1 sind Autogenerierung von Webseiten und Websocket Schnittstelle # in einem Plugin vereint # diese Plugin wird ab SmartHomeNG 1.3 entfernt [visu] class_name = WebSocket class_path = plugins.visu smartvisu_dir = /var/www/html/smartVISU
# ab SmartHomeNG 1.2 # sind Autogenerierung von webseiten für SmartVISU und Bereitstellung # des Websockets zur Kommunikation zwischen SmartVISU und SmartHomeNG getrennt [visu] class_name = WebSocket class_path = plugins.visu_websocket # ip = 0.0.0.0 # port = 2424 # tls = no # wsproto = 4 acl = rw
# Command Line Interface # wichtig für Funktionsprüfungen solange keine Visu zur Verfügung steht [cli] class_name = CLI class_path = plugins.cli ip = 0.0.0.0 update = True
Zuletzt noch den Autostart aktiveren und SmartHomeNG ist fertig:
sudo systemctl enable smarthome.service
Jetzt kommen wir zu unserer Visualisierung.
Installation der SmartVISU
Die SmartVISU ist ein Webfrontend, über das wir mit SmartHomeNG und knxd interagieren können. Das heißt, wir können im Browser eines jeden Gerätes die Seite der Visualisierung aufrufen und unser Haus steuern. Die SmartVISU besteht aus verschiedenen Widgets. Hierbei muss sich der Anwender normalerweise nicht darum kümmern, wie sie funktionieren, sondern bindet sie einfach in eine HTML Struktur ein.
Wir starten mit der Installation, indem wir die letzten Abhängigkeiten installieren:
Jetzt können wir auch schon auf die IP unseres Homeservers navigieren, ins Unterverzeichnis http://IP-Homeserver/smartVISU
Hier erwartet uns ein kleiner QuickCheck der Parameter. Wenn alles passt, haben wir 6 Haken, wie hier abgebildet:
Mit einem Klick auf Config können wir unsere Rahmenparameter setzen:
Die wichtigsten Parameter in der Übersicht:
Interface: Hier wählt man später sein eigenes Projekt unter Pages aus. Außerdem kann man das Design wählen und, ob man Animationen und Page Cache verwenden möchte. Zum Page Cache sei gesagt, dass man während des Erstellens des Projektes den Cache besser aus lässt. Ist das Projekt beendet, kann man diesen aus Performancegründen wieder anschalten. Unter /var/www/html/smartVISU/temp/ wird der Cache angelegt. Nimmt man Änderungen an der Page vor, während der Cache aktiv ist, werden diese erst sichtbar, wenn man den Inhalt des Temp Ordners löscht und die Seite neu lädt.
Unter I/O Connection wählen wir den Treiber smarthome.py (SmartHomeNG) aus und tragen die IP Adresse unseres Homeserver Pi ein. Wichtig ist, dass wir die IP verwenden und nicht etwa localhost oder den DNS Namen. Realtime sollte an sein.
Unter Weather können wir für die Übersichtsseite noch unseren Standort angeben. Ich nutze dazu Yr.no und nicht Wunderground.
Es gibt im Moment noch einen Bug, der es notwendig macht, dass wir unsere Änderungen an dieser Seite zweimal eintragen und auch zweimal speichern müssen. Wir müssen diese Einstellungen aber in der Regel sowieso nur einmal machen.
Jetzt wo wir das geschafft haben, können wir endlich unser eigenes Projekt anlegen. Und wer glaubt, dass es bis hier her aufwendig war, wird sich jetzt besonders freuen, denn ab hier beginnt die Fleißarbeit.
Anlegen des eigenen Projektes
Damit wir besser auf die notwendigen Dateien zugreifen können, sollten wir uns den Samba einrichten. Dazu habe ich meine Konfiguration (/etc/samba/smb.conf) wie folgt gewählt:
[global] workgroup = WORKGROUP server string = SmartHome domain master = no syslog only = no syslog = 10 panic action = /usr/share/samba/panic-action %d encrypt passwords = true passdb backend = tdbsam obey pam restrictions = yes unix password sync = yes unix extensions = no passwd program = /usr/bin/passwd %u passwd chat = Enter\snew\s\spassword:* %n\n Retype\snew\s\spassword:* %n\n password\supdated\ssuccessfully . pam password change = yes map to guest = bad user invalid users = root guest ok = no usershare allow guests = no # disable printing load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes
[SmartHome.py] path = /usr/local/smarthome comment = SmartHome.py Directories available = yes browseable = yes writable = yes public = yes
[smartVISU] path = /var/www/html/smartVISU comment = smartVISU Directories available = yes browseable = yes writable = yes public = yes
Es sei erwähnt, dass ich bewusst auf Zugriffsbeschränkungen verzichte, da meine Systeme hinter einer Sophos UTM Firewall stehen. Es ist jedem selbst überlassen, wie er seine Sambaverzeichnisse absichert.
Nun können wir im Windows Explorer auf die IP unseres Homeservers navigieren und finden zwei Freigaben.
Zuerst legen wir unsere Items an. Dazu navigieren wir zu „SmartHome.py“ in den Ordner „items“ und legen eine neue Datei an. Meine heißt „hener.conf“. Die Datei muss auf .conf enden.
Die Itemsdatei verknüpft die Gruppenadresse unseres Kommunikationsobjektes auf dem Bus mit einer Struktur, die die SmartVISU ansprechen kann. Das funktioniert vom Aufbau her wie folgt:
Die unterschiedlichen Attribute, wie type, knx_dpt, knx_send, .. sind in der Dokumentation zur SmartVISU erklärt. Hierauf einzugehen würde den Rahmen dieses Blogbeitrages sprengen.
Nun, wo wir die Items fertig haben, müssen wir noch unsere HTML Struktur anlegen. Dazu erstellen wir einen Ordner in unserer Homeserver Freigabe unter: „smartvisu/pages/Projektname“. Mein Projektname lautet: „Hener“
Dort erstellen wir wie gewohnt eine index.html und unsere einzelnen HTML Seiten für die Räume. Hier mal ein Beispiel des Raumes, der oben verwendet wird:
Man kann hier schön sehen, wie das Widget die Item Struktur „OG.Kind1.X.X“ anspricht, um mit dem Objekt im knx zu interagieren.
Im Ordner „pages“ befinden sich schon einige Beispielprojekte, an denen man sich ganz gut orientieren kann. Diese kann man in der Konfigurationsseite auch auswählen und dann anschauen.
Schauen wir uns an, wie das Ergebnis aussieht.
Das Ergebnis
Und hier noch ein Video mit einer Jalousie:
Und noch eines mit geschaltenem Licht, gedimmten Licht und dem Türsummer, den man vielleicht ein bisschen hören kann, wenn man laut genug macht:
Quellen
Und? Neugierig geworden? Dann habe ich hier nochmal die wichtigsten Links zu den einzelnen Komponenten:
