1 Projektorganisation und Aufgabenstellung

1.1 Personen und Adressen

1.2 Thematik

Titel: Serverraum-Monitoring

Beschreibung: Im Serverraum der Rafisa Informatik GmbH soll mit Hilfe eines Embedded-Linux-Gerätes und entsprechenden Sensoren ein Raum-Monitoring eingerichtet werden.

1.2.1Fachgebiete

Arbeitsgebiet: Netzwerkinfrastruktur / WLAN

Plattform: PDA-Betriebssystem / Embedded OS

Programmiersprache: andere Programmiersprache

1.3 Mittel und Methoden

- RaspberryPi + GrovePi HW
- Server-HW
- Firewall + Switch
- Kamera
- LAMP-System
- Debian Linux
- Programmieren (PHP, HTML, CSS, evtl. Python)

1.4Durchführungsblock

1.5Aufgabenstellung

1.5.1Titel der Arbeit

Serverraum-Monitoring

1.5.2Ausgangslage

Die Rafisa Informatik GmbH ist ein Ausbildungsbetrieb für InformatikerInnen EFZ der Abteilungen ICT, Applikationsentwicklung, Betriebsinformatik und Systemtechnik. Die Firma beschäftigt zur Zeit 50 Lernende sowie 16 MitarbeiterInnen. Die produktiven Server sowie die kritischen Elemente des Netzwerkbackbones befinden sich in einem Serverraum im UG der Firma. Dieser Raum wird bisher nicht überwacht.
Gemäss Beschluss der Geschäftsleitung sollen mit Hilfe geeigneter Sensoren neu folgende physikalische Grössen erfasst werden:
- Temperatur
- Luftfeuchtigkeit
Zusätzlich wird eine Kameraüberwachung des Raumes installiert, die bei Wartungsarbeiten durch die Lernenden im Notfall ein schnelles Eingreifen ermöglichen soll. 
Alle im Serverraum erfassten Werte werden an einen zentralen Monitoring-Server übermittelt und dort für die Anzeige auf dem Kiosk-System des Helpdesks aufbereitet. Auf dem Monitoring-Server ist zusätzlich ein Alarmsystem einzurichten, das im Fall kritischer Werte die verantwortlichen Stellen informiert.

1.5.3Detaillierte Aufgabenstellung

Realisieren Sie für die Rafisa Informatik GmbH einen Prototyp für ein Serverraum-Monitoring mit Alarmsystem. Alle Komponenten des Monitoring-Systems sind in einer Testumgebung aufzubauen. Die Implementierung in das Produktivsystem erfolgt nach der IPA. Vorschläge für die endgültige Anbringung der Komponenten sind unter Teilaufgabe 1 zu machen.

Die für die Aufgabe zur Verfügung stehenden Mittel sind: 
1x GrovePi+ Starter-Kit für den Raspberry Pi
1x Dexter Industries GrovePi Case (Gehäuse)
1x Grove - Temperatur- & Feuchtigkeitssensor
1x Ubiquiti UVC-G3-AF Kamera
1x Server-HW: Zentraler Monitoring-Server mit Linux
1x Arbeitsplatzrechner: für Tests
1x Firewall + Switch: für Aufbau Testumgebung

Die Aufgabe beinhaltet folgende Teilaufgaben:
1. Erheben Sie folgende IST-Informationen [I1]:
- Raumplan/Grundriss Serverraum
- Layer3-Plan des Netzwerkes der Rafisa Informatik GmbH (VLANs, Netzwerkadressen und Netzmasken, Layer3 Geräte wie Router, Firewalls od. Switches mit L3-Funktionalität, Server + Dienste, keine PCs, keine Drucker, Stockwerkinformationen)
- HW-Infos des zur Verfügung gestellten Materials: GrovePi+, Kamera, Linux-Server, Arbeitsplatzrechner, Firewall und Switch

2. Betten Sie Ihr System mit Hilfe folgender SOLL-Dokumentationen in den Aufgabenkontext ein:
- Vorschlag für die Anbringung des GrovePi (Sensoren) und der Kamera im Serverraum → Einzeichnen in Grundriss Serverraum
- Vorschlag für den Standort aller Monitoring-Komponenten im Layer3-Plan
- Netzplan der geplanten Testumgebung [I3]

3. Finden Sie mit Hilfe einer Literaturrecherche Empfehlungen für optimale Temperatur und Luftfeuchtigkeit in einem Serverraum. Bestimmen Sie für die Grössen Temperatur und Luftfeuchtigkeit die Schwellenwerte für die Statusanzeigen „Normal, Warnung, Kritisch“. Begründen Sie Ihre Entscheidungen. [I2]

4. Bauen Sie folgende Testumgebung auf:
- Subnetz: 192.168.78.0/24, GW 192.168.78.1, DHCP-Server: 192.168.78.1, DNS: 8.8.8.8 
- Firewall (WAN: 192.168.77.222, LAN: 192.168.78.1, DHCP-Server mit Range 192.168.78-100-150, WAN-GW: 192.168.77.1)
- GrovePi (OS: DexterOS, LAN: 192.168.78.20)
- Kamera (LAN: 192.168.78.21)
- Monitoring-Server (OS: Debian Linux 9 Stretch, LAMP-System, 2 Partitionen: Root + Swap, LAN: 192.168.78.30)
- Arbeitsplatzrechner (OS: Windows 10 Enterprise, LAN: DHCP) → bereits vor IPA erstellt

5. Programmierung des Monitoring-Systems. Entwickeln von Skripte , die folgende Anforderungen erfüllen [I4]:
- Ablesen der Sensor-Informationen sowie des Kamera-Outputs
- Weiterleiten der Sensor-Informationen an zentralen Monitoring-Server
- Speichern der Sensor-Informationen in einer MySQL-Datenbank auf dem zentralen Monitoring-Server
- Mail-Benachrichtigungen an helpdesk@rafisa.ch bei Status-Änderungen, Eskalation bei Warnungen nach 1h, bei kritischen Zuständen nach 10min. [I5]

6. Aufbereitung der Monitoring-Daten auf einer HTML-Seite in Echtzeit [I6]
- Anzeige aller Sensor-Werte
- gängige Design-Grundlagen (Schriftgrösse, Farbe)
- übersichtlich strukturiert (Anordnung der Felder)
- Farbliche Kodierung der Sensor-Werte nach Status „Normal, Warnung, Kritisch“
- Anzeige des Kamera-Inputs
- Automatisches Seitenreload

7. Backup der Datenbank des Monitoring-Servers [I7]
Für die Monitoring Daten soll ein Backup-Konzept entwickelt werden. Die Sensor-Daten sind für mindestens 2 Jahre möglichst lückenlos zu speichern. Zur Speicherung der Daten steht eine CIFS-Freigabe auf einem NAS zur Verfügung.

1.6Vorkenntnisse

- Programmieren von Python, PHP, HTML, CSS
- Linux Server

1.7Vorarbeiten

- Aufsetzen Arbeitsplatz-PC mit Windows 10
- Bestellung Material
- Aufsetzen und Üben mit RaspberryPi

2Vorgehen

2.1Projektmethode IPERKA

IPERKA ist eine Projektmanagement-Methode und steht für:

• Informieren
• Planen
• Entscheiden
• Realisieren
• Kontrollieren
• Auswerten

2.1.1Informieren

Im Informieren-Teil von IPERKA werden folgende Themen geklärt

• Auftrag klären
• Informationen beschaffen
• Informationen sortieren, ordnen, werten
• Wesentliches erkennen

2.1.2Planen

Im Planen-Teil von IPERKA werden folgende Dinge definiert

• Ziel definieren
• Lösungsweg bestimmen
• Arbeitsplan erstellen
• Zeitplanung vornehmen

2.1.3Entscheiden

Beim Entscheiden werden die verschiedenen Lösungswege zusammengefasst und man entscheidet sich für eine Lösung

• Vorgehen festlegen
• Verbindliches absprechen und festlegen
• Argumente auflisten und prüfen

2.1.4Realisieren

Beim Realisieren werden die Pläne in die Tat umgesetzt

• Ziel-Ausrichtung überprüfen
• Probleme beheben
• Zwischenziele überprüfen
• Irrwege erkennen
• Evtl. Entschied für oder gegen Abbruch

2.1.5Kontrollieren

Beim Kontrollieren überprüfen wir nochmals, ob alles erledigt wurde und ob es auch funktioniert

• Meilensteine überprüfen
• Vergleich von Planung und Umsetzung
• Checkliste, eigene und Fremdkontrolle
• Qualitätskontrolle
• Abnahmekriterien überprüfen

2.1.6Auswerten

Zum Schluss werten wir noch aus, welche Optimierungen noch hätten vorgenommen werden können Zudem werden die Erkenntnisse der Arbeit und Reflexion werden zusammengefasst.

• Reflexion über das Produkt (Ziel/Resultat)
• Reflexion über die Zusammenarbeit
• Optimierung formulieren (Produkt und Prozess)
• Erkenntnisse zusammenfassen

2.1.7Wieso habe ich mich für IPERKA entschieden.

Ich habe mich entschieden, IPERKA in meiner IPA zu verwenden, da ich mit IPERKA schon bekannt bin und wir dies in der Schule angewendet haben.

2.2Dokumentation

2.2.1Backup & Versionierung

Meine Daten werden über GitHub gesichert. Ich werde folgende Daten sichern:

• Dokumentation
• Arbeitsjournal
• Zeitplan
• Skripte

Um die Daten im GitHub abzuspeichern, verwende ich PHPStorm, ein Programm, mit welchem ich meine Skripte und meine Webseite bearbeiten und im GitHub sichern kann.

Nach der Basisinstallation des Monitor-Servers wurde mit «dd» ein Image auf eine externe Festplatte gemacht.

Das obige Bild zeigt PHPStorm. Unter dem Tab Doku werden die Dokumente zu der IPA gesichert. Man kann mit PHPStorm auf das Rafisa GitHub zugreifen und Daten dort sichern. Mittels Commitwerden alle Änderungen in einer neuen Version übernommen und lokal gesichert. Mit Push werden die Dateien auf den Rafisa GitHub Server gesendet und gesichert.

Zudem hat die verantwortliche Fachkraft Zugriff auf GitHub und kann den momentanen Stand der Doku und der Skripte überprüfen.

Um die Daten zu sichern, kann man im PHPStorm mit Commit alle Daten und Änderungen suchen. Hiezu muss man auf VCS(Version Control System) und dann auf Commit klicken. Danach öffnet sich ein neues Fenster, wo im Feld Commit Message eingetragen wird, welche Änderungen vorgenommen worden sind.

Zuletzt geht man auf VCS → Git → Push klicken, um die Daten auf Rafisa GitHub zu schicken.

2.2.2Fullbackup des Monitoring-Servers

Nach Abschluss der Basisinstallation des Monitoring-Servers wurde der Server mit der Bootdisk GRML, einem Toolkit für Systemadministratoren, gestartet. Mit dem Befehl dd wurde ein Image der gesamten Festplatte erstellt:

dd if=/dev/sda of=/mnt/backup/MonitoringServer.20190502.bak

Auf meine Anregung wurde für die IPA ein zweiter vollständiger Satz der Sensoren bestellt, um bei einem Sensorenausfall Ersatz zu haben.

3Projektaufbau Organisation

3.1Personen

• Ausbildner: Herr Egil Ruefli
• Lernender: Herr Thomy-Pau Imbach

3.2Rollen

• Projektleiter: Herr Thomy-Pau Imbach
• Auftraggeber: Herr Egil Ruefli

3.3Aufgaben

Der Projektleiter ist für die komplette Realisierung und Dokumentation der IPA zuständig.
Der Auftraggeber ist für die Formulierung des Auftrages zuständig.

3.4Verantwortung

Die Realisierung der IPA liegt allein in der Verantwortung des Projektleiters.

4Risiken

4.1Externe Einflüsse

Die IPA könnte von externen Einflüssen abhängig sein, welche die planmässige Durchführung beeinflussen könnten.

4.2Datenverlust

Um Datenverlust zu verhindern, wird die IPA Dokumentation auf dem Rafisa GitLab gesichert und versioniert, d.h. es kann auf ältere Versionen der Dokumentation zugegriffen werden.

4.3Falsche Zeiteinschätzung

Um mögliche zeitliche Engpässe zu vermeiden, wurde in der Zeitplanung Zeit für Überstunden und zusätzlich Pufferzeit eingeplant.

4.4Krankheit / Unfall

Bei Arbeitsverhinderung wegen Krankheit / Unfall ist am selben Tag ein ärztliches Zeugnis dem Hauptexperten vorzuweisen, damit die verlorene Zeit gutgeschrieben werden kann.

5 Zeitplan

6Arbeitsprotokoll

| TAG 1 ||

| TAG 2 ||

| TAG 3 ||

| TAG 4 ||

| TAG 5 ||

| TAG 6 ||

| TAG 7 ||

| TAG 8 ||

| TAG 9 ||

| TAG 10 ||

Teil 2 – Projekt

7Kurzfassung IPA-Bericht

7.1Kurze Ausgangssituation

In der Rafisa Informatik GmbH werden zurzeit rund 50 Lernende in verschiedenen Fachrichtungen ausgebildet, unter anderem Applikationsentwickler, Systemtechniker und Betriebsinformatiker. Neben dem regulären Ausbildungsbetrieb bietet die Rafisa Informatik GmbH auch Eignungsabklärungen, Arbeitstrainings, Vorbereitungen für eine Informatikausbildung sowie Bewerbungs- und Job-Coaching an.

Die Rafis Informatik GmbH hat vor kurzem ihre Server im UG stationiert, und diese müssen jetzt überwacht werden. Nun muss evaluiert werden, wie dies umgesetzt werden kann, um die Sicherheit der Server zu garantieren und zu überwachen.

7.2Umsetzung

Es wurde entschieden, dass folgende Kriterien bei der Überwachung des Servers erfüllt sein müssen:

• Temperatur
• Luftfeuchtigkeit
• Kamera Überwachung

Um dies zu erreichen, wird ein Raspberry Pi im Serverraum platziert. Das Gerät verfügt über Sensoren, welche die Temperatur und die Luftfeuchtigkeit im Serverraum konstant überwachen. Zudem wird ein Alarmsystem eingebaut, welches den zuständigen Administrator informiert, sollten diese Werte einen kritischen Bereich erreichen.

Ebenfalls wird eine Kamera eingerichtet, welche den Serverraum konstant aufnimmt und an einen Webserver weitergibt. Im Helpdesk wird der Kamera-Stream auf einer in dieser Arbeit entwickelten Website angezeigt.

7.3Ergebnis

Das Aufbauen des Überwachungssystems war erfolgreich und es wurde ein umfangreiches Testkonzept erstellt. Jegliche darin beschriebenen Tests wurden durchgeführt und waren erfolgreich. Zudem gab es keine grossen Komplikationen bei der Ausführung. Nun kann das komplette System nach der IPA von der Testumgebung auf den Serverraum migriert werden.

8Informieren

8.1Grundriss Serverraum

Der Serverraum wurde vermessen und dann mittels https://planner.roomsketcher.com ein 2D Raumplan erstellt. Beim grösseren der beiden Räume handelt es sich um den Lagerraum, beim kleineren um den eigentlichen Serverraum. Im Serverraum sind zusätzlich die beiden Serverracks eingezeichnet.

Die Höhe des Serverraumes beträgt 264 cm.

Nach der Erstellung des 2D-Raumplanes wurde ein 3D-Raumplan erstellt, welcher später bei der Platzierung der Kamera und des Raspberry Pi helfen wird. Ebenso werden mit dem 3D Raum Plan Simulationen der Kameraposition erstellt, so dass eine gute Vorschau ermöglicht zu sehen, wie es mit der richtigen Kamera später aussehen wird.

8.2Layer 3 Plan des Rafisa-Netzwerkes

Untenstehendes Bild zeigt das Rafisa-Netzwerk im Layer 3 Plan. Das Rafisa-Netzwerk erstreckt sich über vier Stockwerke. Die für die vorliegende Arbeit wichtigen Stockwerke sind zum einen das UG mit dem Serverraum, zum anderen der zweite Stock mit dem Helpdesk Office und dem Grossbildschirm für das Serverraum-Monitoring.

Im Kapitel Planen wird ein Vorschlag für die Platzierung aller relevanten Geräte gemacht.

Netzwerk Layer 3 Plan:

8.3Hardware-Info der Testgeräte

Die Hardwarespezifikationen der Linux Geräte wurden mit folgenden Befehlen ermittelt:

dmidecode –t processor

Gibt Prozessor-Informationen aus

dmidecode –t memory

Gibt Memory-Informationen aus

lcpci

Gibt Informationen zu PCI-Geräten, u.a. zu Netzwerkgeräten aus

Die Hardwarespezifikationen des Windows Rechners wurden über die Systeminformation ermittelt.

Die Information zur Kamera und zu Firewall wurden mit Hilfe der Hersteller-Dokumentationen ermittelt, welche hier zu finden sind:

https://cdn.competec.ch/documents/7/2/722397/EN_Quick-Start-Guide_UVC-G3-AF_QSG.pdf

| Monitoring server |||||

| Firewall ||

| Raspberry Pi |||||

| Grove Pi |||

| Kamera |||||

8.4Recherche zu Temperatur und Luftfeuchtigkeit

In einer Internet-Recherche habe ich verschiedene Artikel zur empfohlenen Temperatur und Luftfeuchtigkeit in Server-Räumen gefunden.

| Temperatur rechersche |||

Im URL Artikel 1 werden die möglichen Auswirkungen einer falschen Temperatur oder Luftfeuchtigkeit im Serverraum diskutiert. Kalte Luft schadet den Geräten nicht, zu warme kann zu Überhitzung und schlimmstenfalls zum Ausfall von Geräten führen. Während eine zu hohe Luftfeuchtigkeit zu Kondensation führen kann, kann eine zu tiefe Temperatur statische Aufladung und Kurzschlüsse verursachen. Empfohlen werden in Artikel 1 eine Temperatur von 18-27°C bei einer Luftfeuchtigkeit von 40%-50%. In Artikel 2 werden die Maximalschwellen von 10°-28°C und der optimale Bereich von 20°-22°C angegeben. In Artikel 3 wird gesagt, dass in internationalen Studien herausgefunden worden ist, dass man bei 26°C gegenüber 22°C den Stromverbrauch von 35% (Anteil Klimatisierung) auf unter 20% senken kann. Die Fachgruppe Green IT hat eine Umfrage bei grossen Hardware-Herstellern gemacht (Artikel 4). Die Geräte der befragten Hersteller können ohne Einschränkung mit 27°C Einlass leben. Die obere Temperaturgrenze ist heute bei 35°C und bei einigen bei 32°C.

Nach der Internetrecherche wurden folgende Werte als Warnung und kritisch festgelegt:

• Temperatur
  • Normal: bis 29°C
  • Warnung: ab 30°C
  • Kritisch: über 34°C
• Luftfeuchtigkeit
  • Normal: bis 40%
  • Warnung: ab 41%
  • Kritisch: über 50%

Sollte die Temperatur 30°C überschreiten, sendet der Raspberry pi eine Warnung an das Monitoring System im Helpdesk. Wird die Temperatur von 34°C überschritten, erhalten der Helpdesk und der Teamleiter je eine Email, damit weitere Massnahmen in die Wege geleitet werden können.

9Planen

9.1Netzplan der geplanten Testumgebung

Die nachstehende Abbildung zeigt den Netzplan der Testumgebung. Die Detailinformationen zu den Geräten sind in Tabellenform wiedergegeben.

| Gerät  | HW/FW  | Schnittstellen  | Adressierung  | Örtlichkeit  | Zugang  | Ansprechpartner  |

9.2Layer3-Plan für die Monitoring-Komponenten

F ür die drei Monitoring-Komponenten - Monitoring Server, Raspberry Pi und Kamera - wird vorgeschlagen, ein eigenes Vlan einzurichten. Im untenstehenden Layer 3 Plan ist diese Vlanmit den drei Komponenten eingezeichnet.

9.3Anbringung des Raspberry Pi und der Kamera

9.3.1Kamera Platzierung

Der Serverraum wurde mit Blender nachgestellt, um eine gute Kamera Platzierung zu finden. Drei mögliche Kamera Platzierungen kamen infrage. Es wurde mit Blender eine virtuelle Kamera platziert sowie eine kurze Simulation erstellt, um festzustellen, ob sich diese Kamera Platzierung eignet.

Hier sind die drei Kamera Platzierungen:

Sicht Kamera_01 (linke vordere Ecke)

Sicht Kamera_02 (rechte hintere Ecke)

Sicht Kamera_03 (rechte Wand mittig)

Die Entscheidung fällt auf Kamera Platzierung 03, da bei dieser Platzierung der Raum bestmöglich abgedeckt ist und diese Platzierung auch einen guten Blick auf die Türe bietet.

9.3.2Raspberry Pi Platzierung

Der Raspberry Pi mit den Sensoren wird im Serverraum zwischen den beiden Server Racks auf Höhe des höchsten Servers platziert, da dieser so die Temperatur auf der höchstmöglichen Stelle misst. Dies wurde so entschieden, da die Wärme nach oben steigt und es oben wärmer ist als unten und da wir die Sicherheit aller Server gewährleisten wollen.

Das rote Rechteck ist die Position des Raspberry Pi

9.4Backup Konzept

9.4.1Backup

Für das Backup müssen folgende Rahmenbedingungen abgeklärt werden: Datenmenge, Transferzeiten, Aufbewahrungsfrist, Sicherungsperiodizitäten und applikatorische Vorgaben.

• Datenmenge: 1MB pro Tag / nach 2 Jahren ist der Datenbank Dump 730MB gross
• Platzbedarf auf dem Backup Share nach 2 Jahren:
  • monatlich: 9GB
  • wöchentlich: 3GB
  • täglich: 8GB
• Transferzeiten: Nach 2 Jahren dauert der Transfer eines 730MB grossen Datenbank Dumps rund 4 Sekunden (über 1Gbit Lan).
• Aufbewahrungsfristen: Tagesbackup: 7 Tage, Wochenbackup: 4 Wochen, Monatsbackup: 2 Jahre
• Sicherungsperiodizitäten: daily, weekly, monthly
• Applikatorische Vorgaben: Das Backup wird mittels Bash-Skript und Cronjobs realisiert

9.4.2Restore

Für den Restore werden die entsprechenden Files vom CIFS-Share auf den Debian-Server kopiert. Das MySQL-Dump-File wird zunächst ausgepackt:

9.5Datenfluss Konzept

Der Raspberry Pi misst die Raumtemperatur und Luftfeuchtigkeit im Serverraum und baut die Verbindung mit dem Monitoring-Server auf, um danach die Messdaten diesem weiterzusenden. Der Monitoring-Server Empfängt die Daten und legt diese in einer Datenbank ab. Zusätzlich ist auf dem Monitoring-Server ein Webserver mit einer Webseite eingerichtet.

Will nun ein User die Daten im Serverraum ablesen, so kann der User auf die Webseite zugreifen und diese wird nun mittels PHP Script die Daten aus der Datenbank holen und dem User anzeigen. Dieser kann dann auch ältere Einträge aus der Datenbank holen.

9.6Meilensteine

In der untenstehenden Tabelle finden sich die Meilensteine mit den zugehörigen Planungsdaten:

| Meilenstein | Datum |

Die Meilensteine orientieren sich an der Projektmanagementmethode IPERKA.

9.7Erstellen der Arbeitspakete

In der unten stehenden Tabelle befinden sich die geplanten Arbeitsschritte nach dem IPERKA Prinzip geordnet.

10Entscheiden

10.1Programmiersprache wählen

Die Entscheidung, mit welches Sprache die Scripte geschrieben werden sollen, fiel auf Pyhton, da der Lernaufwand nicht für den Projektleiter nicht besonders gross ist und sich gut für das Umsetzen eignet. Zudem hat Dexter Industries bereits einen Editor für Python installiert, welcher gute Vorlagen für das Auslesen der Sensoren hat.

Entscheidungsmatrizen:

Sprache: benennt die Sprache

Erfahrung: Erfahrung im Umgang mit dieser Sprache. Je mehr, desto höher der Wert. Der Wert skaliert von 1 bis 10.

Firmenstandard: Wird die Sprache für andere Projekte in der Firma verwendet? Regelmässig = 10 Punkte, gelegentlich = 5 Punkte, nie = 1 Punkt.

Lernaufwand: Der Wert wird ähnlich eruiert wie der Erfahrungswert, wird aber auch davon beeinflusst, wieviel Unterstützung durch Tutorials oder Mitarbeiter gegeben ist. Dieser Wert wurde mit der Formel (10-Wert) eingetragen, um eine einheitliche numerische Auswertung zu gewährleisten.

Eignung für Aufgabe: Wie geeignet ist die Sprache, um diesen Arbeitsschritt zu bewältigen.

| Auslesen der Sensordaten |||||

| Übertragung Raspberry Pi auf DB |||||

| Darstellung der Daten |||||

11Realisieren

11.1Aufbau Testumgebung

11.1.1Konfiguration Firewall

In der untenstehenden Abbildung sieht man den gewählten IP-Range des DHCP-Dienstes auf der Firewall (192.168.78.1).

11.1.2 Zusammensetzen Raspberry Pi

Der Raspberry Pi besteht aus zwei Teilen: dem Raspberry Pi 3 model B (Bild oben rechts) und dem GrovePI (Bild oben links). Beide werden wie auf dem rechten Bild dargestellt und so zusammengesteckt.

Danach wurde der Raspberry Pi in das für ihn zugeschnittene Gehäuse verschraubt.

Zuletzt wurde der Luftfeuchtigkeits- und Temperatursensor und noch ein LED Screen am Raspberry Pi angebracht, um auch im Serverraum die momentane Temperatur ablesen zu können.

Der Luftfeuchtigkeit- und Temperatursensor wurde an Slot D2 angebracht und der LED Screen an Slot 12C-3.

11.1.3Raspberry Pi Installation

Um ein Betriebssystem auf dem Raspberry Pi zu installieren, wurde die SD Karte aus dem Raspberry Pi entfernt und mittels eines USB Adapters in den Arbeits PC eingesteckt. Danach wurde das Betriebssystem «Raspbian_For_Robots_by_Dexter_Industries-stretch» direkt von der Homepage des Herstellers heruntergeladen und mit dem Programm Rufus auf die SD Karte installiert.

11.1.4Konfiguration Installation Kamera

Die Kamera wurde mit einem Powerover Ethernet Adapter ans Netz angeschlossen. Über einen Portscan wurde ermittelt, auf welcher IP der DHCP die Kamera platziert hat. Mit der IP kann über das Weblogininterface auf die Kamera zugegriffen werden.

Der Default Username und das Password lautet ubnt.
Benutzeranleitung: https://dl.ubnt.com/guides/unifivideo/UVC-G3_QSG.pdf

Das Passwort wurde auf Password1gesetzt.

Im Anschluss ist die UniFi Video® Software installiert worden.
Download Link: https://www.ui.com/download/unifi-video/unifi-video-camera-g3

Das untenstehende Bild zeigt das UniFi Video® Weblogin Interface an:

Mit dem Wizard wir die Installation durchgeführt und dann die Software gestartet. Mit Rechtsklick open in Browser auf das Symbolleisten Icon kann auf die Software zugegriffen werden. Alternativ kann dies auch über https://127.0.0.1:7443/camerasin einem Browser aufgerufen werden.

Nun muss noch ein Account erstellt werden. Dazu werden die folgenden Daten verwendet:

• Name: admin
• Username: admin
• Passwort: Password1

Nach dem Erstellen des Kontos gibt die Software ein Camera Recovery Password aus:

Kamera recovery Passwort: ZJDPTw46OD

Nun wird die Kamera erkannt, aber es gibt noch keinen Zugriff auf die Kamera. Um diesen zu erhalten, muss man sich unter dem Tab Kameras auf der Kamera mit dem auf der Kamera eingestellten Passwort und Username anmelden («Username: ubnt», Passwort: «Password1»).

11.1.5Basiseinrichtung des Monitoring-Servers

Für das Aufsetzen und Einrichten des Monitoring-Servers wurde das debian-9.6 benutzt. Mittels dem Programm rufus wurde ein USB Stick bootbar gemacht und das debian darauf geladen.

Bei der Installation des debian auf dem Server wurden folgende Daten verwendet:

• Servername: MonitoringServer
• Domänenname: rafisa.local
• Root Passwort: Password1
• Vollständiger Name: Helpdesk
• Benutzername: helpdesk
• Benutzer Passwort: Password1

11.1.6Einrichtung LAMP auf Monitoring-Server

Die Einrichtung und die Konfiguration des LAMP Systems wurden mit folgender Anleitung erreicht:

https://www.howtoforge.com/tutorial/install-apache-with-PHP-and-mysql-lamp-on-debian-stretch/

11.1.6.1Installation MariaDB

Um mit der Einrichtung des LAMP Systems zu starten, wurden im Terminal folgende Befehle eingegeben:

apt-get -y install MariaDB-server MariaDB-client

Es wird nachgefragt, ob ein root Passwort einrichten werden soll:

Set root password? [Y/n]

Mit Ybestätigen.

Danach wird nach einem Passwort gefragt. Es wurde Password1benutzt.

Remove anonymous users? [Y/n]

Mit Ybestätigen, um den anonymous user zu entfernen.

Disallow root login remotely?

Mit Ybestätigen, um das remote root login zu verweigern.

Remove test database and access to it?

Mit Ybestätigen, um die Test DB zu entfernen.

All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!

Sobald obiger Text erscheint, ist die Installation von MariaDB abgeschlossen.

11.1.6.2Installation des Apache web Servers

Mit folgendem Befehl wird Apache2 auf dem Monitoring-Server installiert:

apt-get -y install apache2

Um zu überprüfen, ob die Installation erfolgreich war, wurde im Webbrowser folgender Link eingegeben: «http://192.168.78.30».Erscheint die untenstehende Seite, war die Installation erfolgreich.

11.1.6.3Installation PHP

Jetzt wird PHP, beziehungsweise das Apache PHP Modul installiert.

apt-get -y install PHP7.0 libapache2-mod-PHP7.0

Apache2 muss nach der Installation neu gestartet werden.

service apache2 restart

Um zu testen, ob die Installation erfolgreich war, wird im Verzeichnis /var/www/htmleine neue Datei erstellt.

nano /var/www/html/info.php

In die soeben erstellte Datei wird folgendes geschrieben:

<?PHP

PHPinfo() ;

?>

Mit PHPinfo();wird unter dem Link: http://192.168.78.30/info.php
die PHP info Seite geladen, die dann Informationen über die momentane PHP Installation ausgibt. Das nebenstehende Bild zeigt, wie es aussehen sollte, wenn diese Seite geöffnet wird.

11.1.6.4MySQL und MariaDB im PHP einrichten

Mit nachstehendem Befehl werden alle Pakete im PHP7 angezeigt.

apt-cache search PHP7.0

Es werden folgende Pakete installiert:

apt-get -y install PHP7.0-mysql PHP7.0-curl PHP7.0-gd PHP7.0-intl PHP-pear PHP-imagick PHP7.0-imap PHP7.0-mcrypt PHP-memcache PHP7.0-pspell PHP7.0-recode PHP7.0-sqlite3 PHP7.0-tidy PHP7.0-xmlrpc PHP7.0-xsl

Nun muss Apache wieder neu gestartet werden.

11.1.6.5PHP Cache installieren

PHP –version

Mit obigem Befehl wird die momentane PHP Version ausgegeben. Wenn in der Beschreibung with zend OPcache steht, kann man den nächsten Schritt überspringen und gleich zu 11.1.7 gehen.

Sollte das OPcache Modul nicht angezeigt werden, wird folgender Befehl ausgeführt:

apt-get -y install PHP7.0-opcache

gefolgt von:

apt-get -y install PHP-apcu

Nun muss Apache2 wieder neu gestartet werden.

Wenn man nun auf http://192.168.78.30/info.phpdie Seite neu lädt, sollte man die neuen Module sehen.

11.1.6.6PHPMyAdmin Installation

Mit:

apt-get -y install PHPmyadmin

wird die PHPmyadmin Installation gestartet.

Nun wird gefragt, ob Apache2 oder Lighttbd installiert werden soll. Gewählt wird apache2.

Bei:

Configure database for PHPmyadmin with dbconfig-common?

wird Yesausgewählt.

Bei der Passwortabfrage wird das Passwort Password1benutzt. Um nun noch das root login im PHPMyAdmin zu aktivieren, wird folgender Befehl ausgeführt:

echo „UPDATE mysql.user SET plugin = 'mysql_native_password' WHERE user = 'root' AND plugin = 'unix_socket';FLUSH PRIVILEGES;“ | mysql -u root -p

Nun kann man sich auf http://192.168.78.30/PHPmyadmin/ mit dem Benutzernamen rootund dem Passwort Password1anmelden.

11.2Einrichtung Datenbank

Bevor mit dem Schreiben des Scriptes gestartet werden kann, muss die Datenbank für die Sensor Datenablage erstellt werden.

Mit dem nachstehenden Befehl kann man auf das mysql Kommandointerface zugreifen.

mysql –u root -p

Wird das Passwort verlangt, Password1 eingeben

Die Datenbank sensors wird wie folgt erstellt:

CREATE DATABASE sensors;

Um nun in der Datenbank sensors zu arbeiten, muss diese ausgewählt werden. Dazu benutzt man folgenden Befehl:

USE sensors;

Um die Tabelle zu erstellen, wurde folgender Befehl eingegeben:

CREATE TABLE sensordatas(

ID int auto_increment,

primary key(id),

timestamp varchar(255),

temp varchar(255),

hum varchar(255)

);

Es wird eine Tabelle mit dem Namen sensordatas und den folgenden colums erstellt:

• Primary key
  • Wird automatisch von der Tabelle generiert
• Timestamp
  • Wird für das Datum benutzt
• Temp
  • Hier wird die Temperatur abgespeichert
• Hum
  • Hier wird die Luftfeuchtigkeit abgespeichert

Nun wird der User helpdeskmit dem Passwort Password1erstellt, damit später die Scripte diese Login Daten für den Zugriff auf die Datenbank benutzen können.

Hierzu werden folgende Befehle ausgeführt:

CREATE USER 'helpdesk'@'localhost' IDENTIFIED BY 'Password1';

Die Zugriffsrechte werden dem Benutzer helpdesk zugeteilt.

GRANT ALL PRIVILEGES ON * . * TO 'helpdesk'@'localhost';

Mit:

select Host,User from mysql.user;

kann sichergestellt werden, dass der Benutzer auch erstellt worden ist.

Mit:

exit

wird das mysql interface verlassen.

11.3Programmierung des Monitoring-Systems

11.3.1Sender-Script

Das Sender-Script auf dem Raspberry Pi muss folgende Kriterien erfüllen:

• Messung der Temperatur
• Messung der Luftfeuchtigkeit
• Ausgabe auf LED Screen
• Farbcodierung des LED Screen
• Zusammenfassung der Messresultate in einem Paket
• Verbindungsaufbau mit Receiver-Script
• Senden der Daten

Wird das Sender-Script gestartet, baut dieses eine Verbindung zum Server auf. Kann keine Verbindung aufgebaut werden, wird eine Fehlermeldung ausgegeben und das Script beendet.

W ird die Verbindung erfolgreich aufgebaut, so misst das Script die Temperatur und die Luftfeuchtigkeit im Serverraum. Anschliessend überprüft es, ob die Angaben überhaupt stimmen oder ob eine Fehlermeldung bei dem Sensor entstanden ist. Sollte letzteres der Fall sein, so wird der Fehler ausgegeben und das Script gestoppt. Sollte der Sensor keinen Fehler ausgeben und stattdessen die Temperatur und Luftfeuchtigkeit ausgeben, wird das Sender-Script mit den Angaben den Farbcode des LED Displays, welches sich im Serverraum befindet, berechnen. Wie das Script diesen ausrechnet, ist im Kapitel 11.3.4beschrieben. Das LED zeigt dadurch den Zustand des Servers an. Nun wird überprüft, ob der User einen Keyboard-Input gibt, um das Script manuell zu stoppen. Sollte dies nicht der Fall sein, wird die Temperatur und Luftfeuchtigkeit als String an den Monitoring-Server gesendet.

Entlang der ursprünglichen Planung soll das Script nach einer Wartezeit von 5 Sekunden an die Stelle springen, an der die Daten gemessen werden. Nach dem Langzeittest wurde beschlossen, dass 5 Sekunden Intervall zu hoch sind und es wurde entschieden, dass 60 Sekunden besser sind. Der Grund dafür ist, dass die Informationsdichte zu hoch ist, um das Verhalten über eine Stunde übersichtlich zu bewerten.

11.3.2Receiver-Script

Das Receiver-Script auf dem Monitoring-Server muss folgende Kriterien erfüllen:

• Empfang der Daten vom Sender-Script
• Trennung des Pakets in Temperatur und Feuchtigkeit
• Verbindung mit DB erstellen
• Eintragen der Daten mit Timestamp
• Mail Warnung an System Administrator

Sobald das Script gestartet wird, wartet es auf den Verbindungsaufbau mit dem Raspberry Pi. Daher sollte das Receiver-Script immer als Erstes gestartet werden. Sobald der Raspberry Pi mit dem Monitoring-Server die Verbindung aufgebaut hat, empfängt das Reveicer Script die Daten, die zu diesem Zeitpunkt ein einzelner String sind,undtrennt diese in temp und hum auf, damit er diese in die Datenbank einfügen kann. Beim Einfügen in die Datenbank erstellt das Receiver-Script noch einen Timestamp mit dem Zeitpunkt, an dem die Einfügeoperation ausgeführt wird. Zudem gibt er dem Eintrag eine ID, die später helfen wird, den neusten Eintrag aus der Datenbank zu holen.

11.3.3Mail-Benachrichtigungen

Zudem wird bei kritischen Werten eine Email an den Helpdesk gesendet, worin der Helpdesk auf die kritischen Werte aufmerksam gemacht wird. Diese Email enthält einen Link zu einer Webseite mit den Statuswerten. Dies wird mit folgenden Zeilen im Code erreicht:

11.3.4Farbcode des LED Displays berechnen

Das LED Display, welches am Raspberry Pi angebracht ist, verwendet RGB Werte von 0 – 255, um die Farbe des Displays zu bestimmen. Daher muss das Script eine Farbskala erstellen, welche von grün auf gelb auf rot wechselt, je nachdem wie nahe die Temperatur im Serverraum sich der kritischen Temperatur nähert. Um dies zu erreichen, werden wir eine Variable erstellen, welche colortemp genannt wird und zwischen 0 und 510 liegt, wobei 0 eine grüne Farbe und 510 eine rote Farbe anzeigen soll.

Um die Temperatur im Serverraum auf die Variable colortemp anzupassen, müssen wir diese mit einem Faktor multiplizieren. Um diesen Faktor berechnen zu können, müssen wir die maximale Temperatur im Serverraum angeben, welche wir noch tolerieren. Danach rechnen wir 510 / (maximale Temperatur im Serverraum). Diesen Faktor multiplizieren wir mit der momentanen Temperatur im Serverraum. Sollte die Temperatur im Serverraum höher sein als die Temperatur, welche wir tolerieren, so wird die Zahl, welche aus dieser Rechnung erfolgt, 510 überschreiten.

11.4Webseite

Die Webseite dient dazu, dem Helpdesk immer einen Überblick über den Serverraum zu gewährleisten. So kann dieses reagieren, wenn im Serverraum die Temperatur und die Luftfeuchtigkeit problematische Werte erreichen.

Die Webseite wird im Helpdesk auf einem Bildschirm angezeigt. Es muss schnell ersichtlich werden, sollten die Sensoren unerwünschte Messungen aufzeigen.

11.4.1Seitendesign

Auf der Webseite sollte folgendes ersichtlich sein:

• Kamerasicht
• Momentane Temperatur im Serverraum
• Momentane Luftfeuchtigkeit im Serverraum
• Ältere Einträge der Luftfeuchtigkeit / Temperatur

Wie das obige Bild zeigt, ist die Webseite dreiteilig aufgebaut. Dazu wurde ein CSS Grid verwendet. In Fläche (1) befindet sich die Kamerasicht, die das letzte gemachte Bild anzeigt.

Fläche (2) zeigt die aktuelle Temperatur und Luftfeuchtigkeit an. Die Anzeigen sind so programmiert, dass die Schriftfarbe rot erscheint, sollte die Temperatur über 35°Cund die Luftfeuchtigkeit über 50% steigen, und am Ende des Schriftzuges das Wort «Alarm» ausgegeben wird. Die Temperatur- und die Luftfeuchtigkeitswerte, welche in Fläche (2) angezeigt werden, werden aus der Datenbank sensorsauf dem Monitoring-Server geholt. Der Eintrag mit der grössten ID ist der aktuellste Stand der Daten. Im Nachhinein wurde ein Zeitstempel implementiert, der anzeigt, wann diese Daten gemessen worden sind (Jahr-Monat-Tag; Stunde-Minute-Sekunde).

Fläche (3) dient dazu, ältere Einträge aus der Datenbank zu holen. Hierzu kann eine bestimmte Anzahl an erfolgten Einträgen im dafür vorgesehen Fortschrittsbalken eingegeben werden, worauf die Werte in Fläche (3) erscheinen.

Um das Bild von der Kamera auf der Webseite anzeigen zu lasse, wurde folgender Code in der Webseite eingebettet:

Das Bild links zeigt, wie der Datensatz formatiert ist, wenn sich die Werte im Normalbereich befinden.

Das Bild rechts zeigt einen Warnungszustand an, bei welchem der Helpdesk genauer hinschauen aber noch nicht handelt muss.

Das Bild links zeigt die Formatierung der Anzeige bei kritischen Werten. Gleichzeitig erhält nun der Helpdesk eine Alarm Email, nach deren Empfang er sofort handeln muss.

11.4.2Bild der Webseite

11.4.3PHP Daten auslesen aus DB

Um die Daten aus der Datenbank auszulesen und auf der Seite anzeigen zu können, muss erst eine Verbindung mit der Datenbank hergestellt werden.

$servername = „127.0.0.1“;

$username = „helpdesk“;

$password = „Password1“;

$dbname = „sensors“;

// verbindung herstellen

$conn = new mysqli($servername, $username, $password, $dbname);

// verbindung überprüfen

if ($conn→connect_errno) {

die(„Connection failed: “ . $conn→connect_error);
} else {
//echo „success“; }

Um nun die aktuellsten Daten aus der Datenbank zu holen, wird folgende query verwendet:

$sql = „SELECT * FROM sensordatas ORDER BY ID DESC LIMIT 1; “;

Mit dieser query wird der Eintrag mit der höchsten ID genommen, welche immer der aktuellste ist.

11.5Backup

11.5.1Einbinden des CIFS-Shares

Auf dem AD Server der Lernenden (192.168.77.31) wurde vor der IPA eine Freigabe für das Backup eingerichtet. Die Freigabe wird bei jedem Systemstart automatisch eingebunden. Diese Einbindung wird durch folgenden Eintrag in /etc/fstab erreicht:

//192.168.77.31/backup_monitor /mnt/backup CIFS username=backup_monitor,password=Password1,sec=ntlm 0 0

Auf dem System müssen die CIFS-utils vorhanden sein, ansonsten sie mit folgendem Befehl installiert werden müssen:

apt-get install CIFS-utils

11.5.2Backup Script

Für das Backup wurden drei bash-scripts angelegt, eines für die täglichen Backups, eines für die wöchentlichen Backups und eines für die monatlichen Backups.

Unten ist als Beispiel das Script für das tägliche Backup:

#!/bin/bash

/usr/bin/mysqldump –user=helpdesk –password=Password1 sensors | gzip > /mnt/backup/daily/sensors.$(date +„%Y%m%d_%H%M%S“).gzip

find /mnt/backup/daily/ -mtime +7 -type f -delete

In der Zeile 2 des obigen Scripts erfolgt der mysql dump der Datenbank sensors und wird als zip file im Verzeichnis /mnt/backup/daily mit dem aktuellen Datum als Name abgelegt.
In Zeile 4 werden sämtliche Dateien, die älter sind als sieben Tage, aus dem Verzeichnis /mnt/backup/daily gelöscht (geforderte Aufbewahrungszeit für das tägliche Backup).

Das wöchentliche und das monatliche Backup werden genau gleich ausgeführt, der einzige Unterschied liegt in der Aufbewahrungsfrist und dem Speicherort.

11.5.3Cronjobs

Die Scripts werden in das für sie zuständige Verzeichnis gespeichert:

• tägliches Backup: /ets/cron.daily
• wöchentliches Backup: /ets/cron.weekly
• monatliches Backup: /ets/cron.monthly

Die Skripte werden jeweils zu folgenden Zeiten ausgeführt.

• tägliches Backup: jeden Tag 06:25 Uhr
• wöchentliche Backup: jeden Sonntag um 06:47 Uhr
• monatliches Backup: jeden ersten Tag im Monat um 06:52 Uhr

Die Ausführungszeiten der cronjobs finden sich im file /etc/crontab.

11.5.4Restore

Für den Restore werden die entsprechenden Files vom CIFS-Share auf den Debian-Server kopiert. Das MySQL-Dump-File wird zunächst ausgepackt:

cat sensors .20190410_222828.gzip | gunzip > sensors .sql

Danach wird die Datenbank wiederhergestellt mit:

mysql –user=helpdesk –password=Password1 sensors < sensors .sql

12Kontrollieren

12.1Test-Konzept

Um das Testing gut und strukturiert durchführen zu können, werden die wichtigsten Funktionen in drei Bereiche aufgeteilt und getestet:

1. Testing der Scripte
   1. Sender-Script / Receiver-Script
   2. Backup / Restore-Script
   3. Email-Tests
2. Tests der Hardware
   1. Sensoren
   2. Display
   3. Kamera
3. Webseite
   1. Daten
   2. Funktionalität

Manche der durchgeführten Tests sind redundant aufgelistet, da diese mehrere Bereiche simultan testen und daher die gleiche Testnummer haben.

12.2Test der Scripte

12.2.1Sender Receiver-Script

12.2.1.1Test 1

12.2.1.2Test 2.1

12.2.1.3Test 3

12.2.1.4Test 4.1

12.2.1.5Test 5.1

12.2.1.6Test 6

12.2.1.7Test 7

12.2.2Backup Restore script

12.2.2.1Test 8

12.2.2.2Test 9

\\ \\ === ====== 12.2.2.3Test 10

12.2.3Email Test

12.2.3.1Test 11

12.2.3.2Test 12

12.3Test der Hardware

12.3.1LED Display

12.3.1.1Test 4.2

12.3.1.2Test 5.1

12.3.2Luftfeuchtigkeits- und Temperatursensor

12.3.2.1Test 2.2

12.3.3Kamera Tests

12.3.3.1Test 13

12.4Test der Webseite

12.4.1Daten

12.4.1.1Test 14

12.4.2Funktionalität der Webseite

12.4.2.1Test 15

12.4.2.2Test 16

12.4.2.3Test 17

12.4.2.4Test 18

12.4.2.5Test 19

13Auswerten

13.1Übersicht Testing

Insgesamt wurden in diesen Bereichen 19 Tests durchgeführt. Die Tests waren alle erfolgreich. Die technische Realisierung des Projektes kann deshalb als erfolgreich bezeichnet werden.

13.2Verbesserungsvorschläge für den Code

Bei einem Folgeprojekt würde ich im Code noch folgende Verbesserungen vornehmen:

Zur besseren Fehlererkennung und -behandlung kann in der Datenbank eine Tabelle für Fehlermeldungen angelegt werden. Je nach Art des Fehlers wird das Generieren der Nachricht im Receiver- oder Senderskript implementiert.

Mögliche Fehler, die abgefangen werden könnten, sind:

• Sensordefekte
• Verbindungsfehler

Die Fehlerauswertung wäre in «read.php» zu implementieren.

14Schlusswort

Ich bin grundsätzlich mit meiner IPA zufrieden, ich konnte viel dazulernen. Jedoch gibt es einige Punkte, bei denen ich nicht ganz zufrieden mit meiner Leistung bin und die hätten besser sein können. Ich konnte die Zeit der verschiedenen Teilpunkte nicht richtig einschätzen. So war ich an einigen Tagen mit allen Aufgaben früher fertig als erwartet und wiederum an anderen Tagen habe ich die Arbeit unterschätzt und es dauerte länger als erwartet. Zudem bin ich zwei Mal in Zeitnot gekommen wegen unerwarteter Probleme. Daher würde ich in Zukunft beim Realisieren immer etwas mehr Zeit einplanen als erwartet, damit solche Probleme gar nicht erst entstehen.

Der technische Teil meiner Arbeit hat mir wiederum seht gut gefallen. Oft habe ich mich dabei erwischt, noch kleine zusätzliche Dinge einbauen zu wollen, wie z.B. ein Thermometer aus ASCII Zeichen in der Konsolenausgabe. Jedoch wäre dies nicht nötig und würde viel Zeit in Anspruch nehmen. Daher habe ich diese Ideen gelassen und mich an den Plan gehalten.

Zudem war dies das erste Mal, wo ich an einer so grossen und komplizierten Aufgabe gearbeitet habe und dies war eine Erfahrung, welche mir in Zukunft sicher helfen wird.

15Quellenverzeichnis

15.1Temperatur Luftfeuchtigkeit Recherche

https://www.didactum-security.com/blog/optimale-temperatur-und-luftfeuchtigkeit-in-serverraum-und-rechenzentrum.html

http://www.aue.bs.ch/dam/jcr:67a86c67-b105-48d9-b4c4-9acb189c6840/26_Grad_in_EDV_Raeumen.pdf

http://www.itwatchdogs.com/environmental-monitoring-news/data-center/determining-the-best-server-room-temperature-546783

http://greenit.s-i.ch/de/dc/implementation

15.2Kamera

https://dl.ubnt.com/guides/unifivideo/UVC-G3_QSG.pdf

https://www.ui.com/download/unifi-video/unifi-video-camera-g3

15.3LAMP

https://www.howtoforge.com/tutorial/install-apache-with-PHP-and-mysql-lamp-on-debian-stretch/

15.4Mysql

https://www.w3schools.com/PHP/PHP_mysql_create_table.asp

https://www.w3schools.com/python/python_mysql_insert.asp

15.5Python

https://stackoverflow.com/questions/24272223/import-mysql-connector-python

https://pip.pypa.io/en/stable/installing/

https://stackoverflow.com/questions/19246103/socket-errorerrno-99-cannot-assign-requested-address-and-namespace-in-python

https://stackoverflow.com/questions/1841565/valueerror-invalid-literal-for-int-with-base-10

https://wiki.python.org/moin/TcpCommunication

15.6HTML

https://stackoverflow.com/questions/8711888/auto-refresh-code-in-html-using-meta-tags

15.7CSS

https://css-tricks.com/snippets/css/complete-guide-grid/

16Glossar

| bash | Bash ist eine Shell für Linux. Die dazugehörige Scriptsprache heisst auch Bash. |

Teil 3 – Anhang

Listing des Codes befindet sich in einem separaten Anhang.