Mit zuhause eingesetzten IP-Cams Haus, Wohnung, Hof und Eigentum überwachen
Auch das ist mal wieder ein schwieriges Thema... hier allerdings weniger IT-Technisch, dafür umso mehr bezogen auf die Realitäten des Lebensalltags. Natürlich ist dieses Projekt auch hinsichtlich der IT-Technik in einem gewissen Umfang herausfordernd, nur nicht so sehr durch den Schwierigkeitsgrad der technischen Umsetzung, dafür eher mehr durch Logistik und Komplexität ... letztendlich läuft es hier nämlich fast durchweg auf eine Daten-Transport-Logistik hinaus, die ordentlich gesteuert logisch und in definierter Reihenfolge ablaufen muss, so das sich alles zum richtigen Zeitpunkt an seinem richtigen Ort befindet. Aber hinsichtlich unseres Lebensalltags ist eher das Fazit relevant, dass man ab einem gewissen Punkt des erworbenen Wissens auch bei solchen Sicherungsmaßnahmen immer irgendwann vor der Erkenntnis steht, dass man Einbruchsprofis nur mit IP-Cams sowieso nicht abhalten kann. Vielleicht wirken Außen-Kameras bei den eher gering-cleveren Amateuren abschreckend, aber erfahrene Leute wissen ganz sicher damit umzugehen, davon bin ich überzeugt. Mittlerweile und nach mehreren Jahren Betrieb unserer IP-Cams habe ich heute auch gar nicht mehr die Absicht einen Einbruch zu verhindern. Bei uns ist eh nix zu holen - aber ich empfinde es auf Reisen dennoch als sehr beruhigend, wenn ich mich morgens kurz davon überzeugen kann, dass gartenseitige Fenster und Türen nach der Nacht noch völlig intakt sind.
Einmal -daran erinnere ich mich immer wieder- haben wir noch abends aus dem Urlaub nachhause angerufen und unsere etwas betagte Blumengießerin darüber informiert, dass die Terrassen-Rollladen hoch sind. Ihr Schreck war groß „Oh, ich war draußen und habe die Blumen gegossen... habe ich die Rollladen wirklich vergessen?“ ... „jau, haste“. In diesem Fall empfand ich die Cam als sehr hilfreich. Aber auch wenn es wirklich im Fall der Fälle mal gelingen sollte, wegen der SMS-Benachrichtigung frühzeitig die Polizei hinzuziehen, um darüber vielleicht dafür sorgen, dass irgendwelche Amateure aus der Wut heraus, nichts brauchbares mitnehmen zu können, einfach nur unsere Wohnung verwüsten, würde ich im Nachgang sagen, die IP-Camera war hilfreich. Der für mich wichtigste Aspekt ist jedoch unzweifelhaft, falls wirklich einmal ein Einbruch durch Gewaltanwendung an Tür oder Fenster erkennbar ist, sofort jemand aus der Familie hinschicken zu können, der dafür sorgt, dass Eingänge oder Fenster bis zu unserer Rückkehr nicht offen bleiben.
Um ganz am Ende kommt auch noch wieder ein persönlicher Aspekt hinzu, ich habe nämlich durchaus auch ein wenig Spaß an solchen technischen Spielereien, gerade auch und am meisten an der Software-Entwicklung und ich mach's halt, weil ich's kann.
Inhaltsübersicht über die Kapitel dieses Artikels:
> Festlegen von Rahmenbedingungen und Beschreibung der Teilprozesse
> Erstellen der Binaries für telegram-cli
> Installation der benötigten Services
> Abschluss-Test der neuen Services
> Ein paar Überlegungen zur Sicherheit
|
Mein heutiges Setup unterscheidet sich vollkommen von der Ausgestaltung meines ersten Cam-Setups, das mittlerweile ca. 8 Jahre zurückliegt. Es sind dabei weniger technische Unterschiede bemerkbar, dafür haben aber die sicherheitsrelevanten Parameter eine deutlich größere Beachtung erfahren. Damals hatte ich mir absolut keine Gedanken über den möglichen Missbrauch von IP-Camera-Daten oder Datenschutz allgemein gemacht. Das lag garantiert zum Teil auch an meiner Sorglosigkeit und meiner Gutgläubigkeit, dass sich niemand für mich interessieren wird ... und vermutlich auch daran, dass digitale Übergriffe im großen Stil, wie man sie heute immer wieder in den Medien liest, wohl eher nicht die Regel waren. Da gab es Viren und Daten-Zerstörung durch Viren, aber die Aspekte staatliche Überwachung, Entmündigung der digitalen Privatsphäre und Enteignung der Verfügungshoheit auf die eigenen Daten durch unsere Gesetzgebung und Staatstrojaner (Danke all dafür!), dann die Daten-Kraken wie Google, Amazon und heute auch Microsoft, dazu spezielle Software in spezieller Hardware (IOT, Alexa, etc.), die darauf ausgerichtet ist, dass alltägliche private Leben kontinuierlich zu beobachten ... das gab es damals in der Form nicht. Deswegen mache ich mir heute deutlich mehr Gedanken über die von mir eingesetzte Hardware. Sicherheit und die Bewahrung meiner Privatsphäre ist eines meiner primären Interessen. Aus diesen Überlegungen sind dann die folgenden Anforderungen für unsere Hausüberwachung entstanden.
Primäre Hardware- und sicherheitstechnische Anforderungen: | |
| Ein Zugriff von außerhalb des lokalen Netzwerks (also aus dem Internet) auf die IP-Cams ist untersagt, um zu verhindern, dass eine Fremdkontrolle der Kameras erfolgen kann (also unter gar keinen Umständen geöffnete Ports im DSL-Router). |
| Den IP-Cams selber wird der Zugang zum Internet vollständig untersagt, um sicherzustellen, dass sich ein Cam-Interner proprietärer Web-Server nicht über eine Reverse-Connection als unkontrollierbare Schadsoftware im eigenen Netzwerk erweist. |
| Eine möglicherweise vorhandene WLAN-Funktion muss deaktiviert werden können (was bautechnisch natürlich nur dann möglich ist, wenn eine Netzwerkanbindung via Patchkabel möglich ist, ansonsten ist das ein Ausschlusskriterium). |
| Die IP-Cams bekommen keine Erlaubnis, selber Nachrichten (z.B. via Email zu versenden) |
| Die Aufnahmen der IP-Cams dürfen das lokale Netzwerk nicht unverschlüsselt verlassen. |
| Die IP-Cams müssen über ein Web-Interface/GUI für das Setup verfügen, welches auf beliebigen Endgeräten mit einem normal-üblichen Internet-Browser für das Customizing geöffnet werden kann (Admin-Zugang, adressiert über eine Static-Custom-IP). |
| Die Cams müssen einen View-Mode auf beliebigen Endgeräten via normal-üblichen Internet-Browser ermöglichen (Client-Zugang). |
| Der Cams müssen einen View-Mode von beliebigen Betriebssystemen (Windows, Linux, Android) ohne proprietäre Client-Software ermöglichen. |
| Die IP-Cams müssen über einen integrierten Infrarot-Strahler mit automatischer Umschaltung (IR-Cut-Filter) verfügen. |
| Die Cams müssen über 2 bis 4 skalierbare und separierbare Area-Settings verfügen und zudem Einstellungen über Sensitive-Settings ermöglichen. Area-Settings sind ausgewählte Teilbereiche im gesamten Bild-Bereich, so dass z.B. explizit eine Tür oder ein Fenster als primärer Alarm-Sektor innerhalb des Gesamt-Bildes deklariert werden können. Das heißt, nur Motion-Detects in den definierten Areas lösen die Alarm-Prozesskette aus. Sensitive-Settings verhindern, dass Regen, Schneefall, Motten, ein Spinnennetz vor dem Objektiv oder eine Katze für Daueralarm sorgt. |
| Die Cams müssen vollständige Funktionalität auch ohne OEM-Cloud-Verpflichtung ermöglichen (z.B. bei Verwendung einer lokalen Cloud oder eigenem FTP-Server). |
| Die Anbindung an jegliche andere kommerziell betriebene Cloud, wie z.B. Google-Drive, MS OneDrive, Dropbox, etc., wo private Daten durch Verwendung und Vermarktung die Grundlage deren Geschäftsprozesse zur Gewinnerwirtschaftung darstellen, wird als datenschutz-technische Katastrophe wegen gravierender Missachtung der digitalen Privatsphäre konsequent ausgeschlossen. |
| Die Cams müssen einen frei einstellbaren FTP-Server verwenden können, auf dem zu speichernde Aufnahmen abgelegt werden. |
| Die übliche DirectX- und Windows-Explorer-Abhängigkeit chinesischer Billig-IP-Cams ist ein Ausschlusskriterium für eine IP-Cam. |
| Jegliche zusätzliche proprietäre Pflichtanbindung resp. für den Betrieb notwendige zusätzliche Client-Software ist ebenfalls ein Ausschlusskriterium. |
Weitere sekundäre Anforderungen: | |
| Der spätere Betrieb muss wartungsarm und für mich weitestgehend aufwandsneutral erfolgen (ich will mich nicht ständig drum kümmern müssen). |
| Der Zugriff auf die IP-Cams erfolgt nur LAN-Intern |
| Sofern ein Zugriff über das Internet notwendig ist, erfolgt dieser über eine OpenVPN-Verbindung (... also trotzdem nur LAN-Intern.) |
Jetzt habe ich solche umfassenden Anforderungen formuliert.... welche IP-Cams können das denn alles leisten? Das ist leider nicht so einfach pauschal zu beantworten. Vermutlich wird es auch IP-Kameras aus der chinesischen Billig-Massen-Produktion geben, die diese Anforderungen erfüllen. Ist halt immer ein bisschen auch Glücksache, weil man erst sieht, was die IP-Cam kann, wenn man sie angeschlossen hat. Ich habe jedenfalls keine guten Erfahrungen mit diesem chinesischen Elektronikschrott gemacht, sie zurückgeschickt und würde heute immer davon abraten. Ganz besonders bei den Cams mit der teilweise noch obligatorischen DirectX-Abhängigkeit. Ich habe mich vor einiger Zeit für zwei Instar IN-6001HD und eine IN-9020FHD entschieden, die rückblickend betrachtet alle meine Anforderungen erfüllen. Alle Kameras beobachten während unserer Abwesenheit nur Eingangstüren und Fenster, von innen und von außen. Ich spreche jetzt hier keine Kaufempfehlung aus, und natürlich mache ich auch keine Werbung für Instar... ich sag nur, dass diese IP-Cams sich perfekt in unsere Debian-System-Umgebung eingefügt haben und genau das tun, was ich von ihnen erwarte.
|
Festlegen von Rahmenbedingungen und Beschreibung der Teilprozesse
Ich halte es immer für eine gute Idee, ein mehr oder weniger kompliziertes Projekt in einzelne Teilschritte zu zerlegen, bei dem ich mich dann mit der Lösung eines jeden Einzelschritts exklusiv befasse, ohne mich dabei von anderen und noch kommenden Belangen oder Problemen ablenken zu lassen. Deswegen werde ich die jeweilige Installation für jeden Teilprozess einzeln beschreiben. Natürlich habe ich zu Beginn schon eine genaue Vorstellung davon, was ganz am Ende dabei rauskommen soll. Und genau dafür gibt es ein kleines Pflichtenheft
» Cam-Daten sollen nur nach einem Motion-Detect innerhalb eines vorgegebenen Areas gespeichert werden
» Aus Gründen des immens hohen Speicherbedarfs sollen keine Streams gespeichert werden
» Es soll pro Motion-Detect-Alarm nur eine vordefinierte Anzahl Bilder als Bildfolge gespeichert werden, z.B. 6 Sekunden lang 1 Bild pro Sekunde)
» Die Speicherung der jpeg-Dateien muss auf meinem lokalen FTP-Server erfolgen
» Es muss berücksichtigt werden, dass im Familien-Normal-Alltag die Familie selber über den ganzen Tag Fehlalarm-Aufnahmen erzeugt
» Weil täglich mehrere tausend Bilder im Familien-Normal-Alltag gespeichert werden, müssen alte Dateien kurzfristig automatisch gelöscht werden
» Wegen des extrem hohen Datenaufkommens für Bildspeicherung soll die Speicherung auf dem FTP-Server nur in einem tmpfs-Speicher (RAM-Disk) erfolgen
» Der FTP-Server soll als 'isolierte Funktion' in einer VM laufen
» Zur Sicherung aktueller Daten muss zyklisch und zeitnah eine Übertragung aktueller Bildaufnahmen nach außerhalb (Web-Space) erfolgen
» Alle nach außen übertragenen Daten werden nur verschlüsselt übertragen
» Wegen des hohen Speicherbedarfs muss auch der Web-Space täglich bereinigt werden
» Für die permanent geschriebenen Logs muss ein Log-Rotate implementiert werden
» Es muss eine einfache Anwender-Schnittstelle für primäre Einstellungen von Client-Seite implementiert werden
» Einstellungen müssen möglichst Client- bzw. OS-neutral ohne explizit entwickelte Software vorgenommen werden können
Bevor es an die tatsächliche Implementierung geht, verschaffen wir uns anhand der folgenden Grafiken einen Überblick darüber, welche Aufgabe jeder Teilprozess quasi als gekapselter Prozess hat. Das bedeutet, jeder Teilprozess erfüllt eine Aufgabe, ohne dass er sich darum kümmert, welche anderen Aufgaben andere Prozesse haben. Natürlich spielt das alles irgendwie ineinander, aber es gibt keine Abhängigkeiten dergestalt, dass ein Prozess abstürzen würde, nur weil ein anderer Prozess nicht arbeitet.
Im Teilprozess 1 ist eingerichtet, dass die IP-Kameras Bilddaten auf einen per IP-Adresse adressierten FTP-Server in einem je Cam vorgegebenen Zielverzeichnis speichern können. Die Zugangsdaten zum FTP-Server sind in den IP-Cams eingestellt.
Die Cams speichern nach einem motion-detect innerhalb eines oder mehrerer vorgegebenen Areas eine Bildfolge auf einen lokalen FTP-Server. Der FTP-Server ist in einer VM auf unserem lokalen und durchgängig verfügbaren LAN-Server eingerichtet.
Aufgrund des sehr hohen Datenaufkommens mit mehreren 1000 Aufnahmen pro Tag soll die Speicherung der Bilddaten zur Entlastung der SSD nur im Hauptspeicher erfolgen. Die Freigaben für FTP und Samba zur Speicherung der Bilddaten sind in einer 1 GB-Ram-Disk eingerichtet. Alle gespeicherten Aufnahmen sind somit flüchtig und der Speicherplatz ist begrenzt. Diesem Umstand wird in TP 3 Rechnung getragen.
|  |
Die Speicherung der Bilddaten erfolgt in je einem eigenen Unterverzeichnis für jede Web-Cam.
Die Entscheidung, die jeweilige IP-Adresse der Web-Cam als Verzeichnisnamen zugrunde zu legen, ist eine willkürliche Entscheidung von mir, mit der Absicht, die Verarbeitungswege offensichtlich zu machen.
Was bedeutet das IP-Netz 10.0.1.0/24? Ganz einfach, das ist eine für meine Dokumentationen verwendete Netzwerk-Adresse. Siehe dazu auch Security und OpenVPN. Gleichbleibende Adressen vereinfachen das Verständnis über das Zusammenwirken dieser 3 Lösungen. |  |
Der Teilprozess 2 ist der Alarm-Prozess. Losgelöst vom durch die IP-Cams erzeugten Datenstrom aus TP1 überprüft dieser lokale Job im 5-Minuten Rhythmus den ganzen Tag über und rund um die Uhr in den oberhalb bezeichneten Verzeichnissen, ob in den letzten 5 Minuten neue Bilddateien angelegt wurden. Wenn festgestellt wurde, dass neue Bilddateien vorhanden sind, müssen in diesem Teilprozess 2 primäre Dinge erledigt werden.
1. Weil die Speicherung hier auf einem flüchtigen Speicher erfolgt, und zwar einer RAM-Disk, auf der die Bilder ein Ausschalten des Systems nicht überleben würden, müssen die neuen Bilder der letzten 5 Minuten unverzüglich nach extern gesichert werden. Extern bedeutet hier Web-Space bei meinem Internet-Homepage-Provider. Und gerade auch die Tatsache, dass Bilddateien umgehend nach außerhalb gesichert werden, ermöglicht es überhaupt, die initiale Speicherung hier nur auf einer 1-GB-RAM-Disk durchzuführen. Die Übertragung ist auch deswegen ungemein wichtig, weil ich damit immer von außerhalb Zugriff auf die Daten habe, selbst wenn mein Home-Server durch Sabotage vom Strom getrennt werden würde. Die betroffenen Bilddateien werden zunächst in ein Tar-File gepackt, dann mit GNUPG verschlüsselt und schließlich via FTP-Client versendet. Damit sind sie vor Fremdzugriff absolut sicher aufbewahrt.
Bei jedem versendeten Paket wird zusätzlich eine lokale Paketliste gepflegt, in der der Name des aktuellen Pakets angefügt wird. Die Paketliste ist später wichtig, um darüber nicht mehr benötigte Alt-Pakete zu löschen. Ohne Löschung würde der Web-Space irgendwann wegen der kontinuierlichen Anhäufung von Alt-Daten überlaufen.
2. Als zweites will ich über das von einer IP-Cam festgestellte Motion-Detect-Ereignis eine Benachrichtigung erhalten. Wir sind ja schließlich nicht zuhause, also wer war das?
Ist die Benachrichtigung nicht generell deaktiviert, wird spätestens 5 Minuten nach dem Ereignis eine Benachrichtigung versendet. Hier sind es sogar 2, eine SMS, einmal via Telegram-CLI. Bei diesem Prozessschritt handelt es sich um eine nachgeschaltete Ereigniserkennung auf Datei-Ebene. Wenn in den letzten 5 Minuten Aufnahmen angelegt wurden, ist irgendwas passiert, die Cams haben auf irgendwas reagiert. Die Benachrichtigung kann sowohl flexibel generell aktiviert oder deaktiviert werden, als auch via Viertelstunden-Einstellungen über den Tag verteilt zeitweise aktiviert werden. |  |
|
|
Der Teilprozess 3 wird täglich zu 6 festen vorgegebenen Zeiten gestartet, bei einem 24-Stunden-Tag also im 4-Stunden-Rhythmus, für die Uhrzeiten siehe Grafik. TP3 erfüllt ebenfalls 2 Aufgaben. 1. Zunächst packt er alle Bilddateien der letzten 4 Stunden in ein Tar-File-Archiv, verschlüsselt das Archiv zum Zugriffsschutz wieder mit GNUPG und versendet das Paket als redundantes 4-Stunden-Backup ebenfalls auf meinen Web-Space. Diese Backup-Pakete benötigten keine weitere Pflege oder Beachtung, ich kümmere mich gar nicht mehr darum, denn weil die Pakete gemäß ihrer Erstellungszeit immer den gleichen Namen bekommen, wird jedes Paket am nächsten Tag automatisch durch ein neues Paket mit dem gleichen Namen überschrieben. Auch hierbei ist der Hintergrund wieder einfach erklärt. Bis zum Überschreiben eines Paketes durch eine neuere Version enthält ein solches Paket einen vollständigen 4-Stunden-Datensatz. | |
Zum Beispiel sind darin heute um kurz vor 13:55 Uhr also noch alle Dateien des Vortages von 10:00 bis 14:00 Uhr gesichert. Das bedeutet, nach einem echten Alarm habe ich immer 24 Stunden Zeit, um die Aufnahmen entweder vor dem Löschen zu sichern oder sie kurzerhand auf meinen Reise-Laptop runter zuladen. 2. Weil der lokale Speicher nur eine ziemlich limitierte RAM-Disk ist, werden im 4-Stunden-Rhythmus einfach alle Dateien gelöscht, die älter als 12 Stunden sind. Warum aufbewahren? Wenn nichts vorgefallen ist, sind sie eh unnütz, darüber hinaus sind sie ja noch in Tar-File-Archiven auf dem Web-Space gespeichert. |  |
|
|
Die Aufgabe des Teilprozesses 4 ist es, den aufgelaufenen Datenmüll aufzuräumen und zu beseitigen. Und zwar ist damit gemeint, die sich auf dem Web-Space täglich rund um die Uhr anhäufenden Tar-File-Archive (die im Normalalltag zwangsläufig schon vom Vortag zu uninteressanten Alt-Daten geworden sind), dann wieder zu löschen, wenn sicher ist, dass sie nicht benötigt werden. Man sollte sich durchaus darüber im Klaren sein, dass das 7/24 laufende System mit 2-3 Web-Cams fluktuierend täglich bis zu mehreren tausend Aufnahmen speichern will und das an einem Samstag oder Sonntage mit viel familiärer Bewegungshektik schnell mal ein halbes Gigabyte an Daten zusammenkommt. Das System kann nicht unterscheiden, ob ein Familienmitglied oder eine fremde unberechtigte Person einen Motion-Detect-Alarm ausgelöst hat, also wird erst mal alles gespeichert. Das Cam-System läuft jedenfalls kontinuierlich durch, ohne Abschaltung, also erzeugt es auch kontinuierlich Daten, die sich dementsprechend unendlich vermehren würden und immer mehr und mehr und mehr Speicherplatz beanspruchen würden. Um das zu verhindern, müssen irrelevante Altdaten auch täglich und zeitnah wieder gelöscht werden. Wie ich oben schon sagte, das Zeitfenster beträgt 24 Stunden, in der ich bei einem tatsächlichen Vorfall Zeit habe, die Daten vor dem Löschen zu sichern. Und weil ich auf Reisen sowieso täglich obligatorisch einmal nachschaue oder auch sofort, wenn ich eine Benachrichtigung vom System erhalten habe, habe ich auch immer genügend Zeit, die Dateien zu sichern. Ich muss sie nicht mal runter laden, es reicht völlig aus, sie auf dem Web-Space einfach in einen anderen Ordner zu kopieren. Um also dieses Problem eines quasi explodierenden Speicherbedarfs zu beheben wird täglich um 01:02 Uhr ein Joblauf gestartet, der die entsprechende lokal gespeicherte Paketliste von vorgestern einliest und auf dem Web-Space alle dort eingetragenen Pakete löscht. Ganz am Ende wird natürlich dann auch die Paketliste selber gelöscht. Warum diese merkwürdige Uhrzeit 01:02 Uhr? Aus zwei technischen Überlegungen. Erfahrungsgemäß erzeugen die Cams um diese Zeit bei uns keine Daten mehr, das ist Nachtzeit und somit ja auch Schlafenszeit. Das bedeutet, der um 1 Uhr startende 5-Minuten-Alarm-Job aus TP 2 wird im Regelfall nichts zu tun haben. Dennoch sind aber bis 01:02 Uhr also noch 2 Minuten Toleranzzeit eingetragen, falls wirklich mal einer unserer familiären Schlafwandler durchs Cam-Bild tappert. In der Zeit von 01:02 bis 01:05, bevor der nächste TP-2-Job startet, besteht dann immer noch ein genügend großes Zeitfenster, um die Löschungen vorzunehmen. Wenn es sich um sehr viele Archive handelt, hier können es schon mal an einem 'belebten' Wochenende so um die 100-120 Archive sein, dauert das Löschen dann trotzdem weniger als 15 Sekunden. | |
Dem entgegengesetzt sind es bei unserer Abwesenheit und den deswegen fehlenden von der Familie selbst erzeugten Dateien täglich nur eine Handvoll erzeugte Archive. Eine Stunde hat 12 * 5 Minuten, bei 24 Stunden eines Tages wären also maximal 24 * 12 = 288 Tar-File-Archive möglich. Drei Minuten Löschzeit sind also allemal ausreichend. Speziell zu TP 4 und den anscheinend hohen Arbeitsaufwänden durch den teilweise hohen Speicherbedarf könnte man nun hinterfragen, warum das Cam-System nicht einfach nur bei Bedarf aktiviert wird und |  |
ansonsten bei Nichtbedarf deaktiviert wird. Nun ja, zumindest das mit dem hohen Arbeitsaufwand kann ich relativieren.... ich selber kümmere mich praktisch ja gar nicht darum, wenn wir zuhause sind, das ist ein völlig autark laufender Prozess, seit etwa 2 Jahren ein absolut wartungsfreier Selbstläufer. Und wenn mein Server ein bisschen was zu tun hat, empfinde ich auch das nicht unbedingt als schlimm. Natürlich habe ich auch eine (bzw. sogar mehrere) eigene Begründung(en) dafür, warum ich das System nicht zeitweise deaktiviere. Über die Zeitfenstereinstellungen einer speziellen Conf (wenn wir zuhause sind) bekomme ich derzeit z.B. einmal die Woche eine Funktions-Bestätigungs-Alarm-SMS und zwei- oder dreimal die Woche eine Telegram-Nachricht mit folgenden Inhalt: "Maschinelles Lebenszeichen von Bewegungsalarm. Bitte über Telegram mit OK als Antwort bestätigen." Daran erkenne ich, dass die beiden SMS-Systeme fehlerlos arbeiten, die Kommunikationswege 'frei' sind und infolgedessen auch der eigentliche Job aus TP2 funktioniert. Ich will nämlich nicht kurz vorher -wenn wir uns bei schönem Wetter kurzentschlossen einen Ausflug vorgenommen haben- feststellen, dass das System momentan gar nicht funktioniert. Und ich will auch nicht kurz vor dem Urlaub feststellen, dass das abgeschaltete System wegen fehlender Upgrades überaltert ist und das es nach dem Einschalten und der Aktualisierung aus welchen Gründen auch immer nicht funktioniert. Debian als Betriebssystem sowie die entsprechenden Services auf der FTP- und IP-Cam-VM wird genau so zuverlässig gewartet und aktuell gehalten, wie jedes andere installierte Debian auf allen anderen bei uns laufenden PC's. Dadurch, dass es durchgängig läuft und bei Kontrollen fehlerfrei seinen Job tut, habe ich zunächst die Gewissheit, dass es bei Problemen nicht an meiner Nachlässigkeit liegt, wenn wirklich mal Störungen passieren. Und ich erkenne Probleme relativ frühzeitig, wenn ich die Lebenszeichen-Benachrichtigungen vermisse. Und zuletzt ist es ja auch so, dass der FTP-Server für die Cams nicht auf eigener dedizierter Hardware läuft und damit z.B. eigene Energie-Kosten erzeugt, sondern in einer VM auf dem sowieso laufenden LAN-Server. Der Server läuft sowieso, der FTP-Server ist also nur ein zur Verfügung gestellter Service. | |
Auch der Teilprozess 5 kümmert sich wieder ums Aufräumen und der Beseitigung von Datenmüll. Hierbei geht es um die Logs, die von den 3 primären Prozessen angelegt werden: alarm.log (TP2), backup.log (TP3) und ispdelold.log (TP4). | |
Die Logs sind dafür da, um Fehlern auf die Schliche zu kommen, um mal eben nachzulesen, dass alles plan-gemäß funktioniert. Ältere Logs sind bei fehlenden Vorfällen schlichtweg Datenmüll. Das Regelwerk für ein Log-Rotate ist relativ einfach und kann wegen fehlender Notwendigkeit auch nicht weiter eingestellt werden. Das aktuelle Log wird 8 Tage geführt, dann für weitere 8 Tage archiviert und schließlich einfach gelöscht.
|  |
|
Bevor es gleich ans Einrichten der späteren Services auf dem Server geht, sind noch einige Vorbereitungs-Arbeiten zu erledigen. Insbesondere der geplante Einsatz von telegram-cli erfordert die Lösung einer spannenden Aufgabe, denn leider kann dieses Programm nicht einfach aus dem Repository mit 'apt' installiert werden. Deshalb nicht, weil es im Debian-Repository schlichtweg nicht enthalten ist. Das bedeutet, wir müssen es uns für unsere Server-Hardware selber erstellen. Das ist kein großes Problem, es muss halt nur gemacht werden. Aber weil ich meinen Server grundsätzlich nach der Devise betreibe, auf dieser Maschine nur die für den laufenden Betrieb zwingend notwendigen Pakete zu installieren, mit dem Ziel, die Installationsbasis so klein wie möglich zu halten und infolgedessen natürlich auch die Menge der im Laufe seiner Betriebszeit zu betreuenden Pakete, will ich natürlich auf meinem Server keine Entwicklungsumgebung einrichten, die ich dort im Normalbetrieb gar nicht benötige. Also nutze ich für die Erstellung der später auf dem Server eingesetzten Programme eine vom Server unabhängige Umgebung.
In der früheren Betriebszeit, als das Cam-System noch auf einem Banana PI lief, habe ich für die Erstellung der telegram-cli-Binaries eine eigene SD-Card mit eigenem Raspbian erstellt, damit eben das produktive OS des Servers möglichst unberührt bleibt. Heute läuft das Cam-System auf meinem Server in einer VM auf einer Intel-Hardware, und zwar auf einer ganz normalen x86_64 -Architektur. Das heißt, ich kann heute das Paket ganz einfach auf meinem eigenen PC erstellen, der die gleiche Architektur hat und ich kann es hinterher gleichermaßen einfach via SSH auf den Server transportieren. Aber selbst auf meinem eigenen PC vermeide ich es nach Möglichkeit, Pakete zu installieren, die ich anschließend nie wieder brauche ... gerade auch vor dem Hintergrund: Wenn ich sie mal wieder brauche, kann ich sie ja eben schnell erneut installieren. Warum soll ich mir also meinen eigenen Rechner zumüllen, was mich dann bis zum Ende seiner Betriebszeit durchgehend durch länger dauernde Upgrades nerven würde, wenn ich das auch völlig System-Neutral durchführen kann? Ich ziehe es dann doch lieber vor, so etwas ohne anschließenden Ballast zu tun... und für solche Aufgaben kann man heute als perfekte Unterstützung systemd-nspawn verwenden.
An dieser Stelle wird es nun ein wenig herausfordernd... denn wie schon erwähnt, das telegram-cli ist nicht einfach nur ein Paket, was man sich mal schnell installiert, nee, es muss zuerst als Source-Code runter geladen werden, um darüber dann auf einer lokalen Maschine die Binaries zu erstellen. Und diese Binaries müssen natürlich zu der Server-Hardware passen, auf der sie am Ende installiert werden sollen. Soll das telegram-cli später auf einer ARM-Hardware laufen, muss es auch auf einer ARM-Hardware erstellt werden. Soll es auf einer 64-Bit-Hardware laufen, muss es auf einer passenden 64-Bit-Architektur erzeugt werden. Mein Server enthält ebenso wie mein eigener PC eine 64-Bit-Intel-Hardware, also kann ich es mir einfach machen und das Paket einfach auf meinem eigenem PC mit gleicher Architektur erstellen.
Herausfordernd an dieser Stelle ist meine Entscheidung, für ein 6-MB-Installationspaket nicht 500 MB an Müll auf meinen Rechner zu laden, der nur für die einmalige Erstellung benötigt wird. Fakt ist, die 500 MB sind in meiner Umgebung nach der Erstellung für nichts anderes mehr gut, außer den Umfang permanent aktuell zu haltender installierter Software völlig unnötig aufzublähen. Wer also kein Python-Programmierer ist und deswegen damit in der übrigen Zeit nichts am Hut hat, kann meiner Empfehlung folgen und die Erstellung einmalig in einer VM durchzuführen und anschließend alles unnötige einfach zu löschen. Für diese spezielle und eher kleine Aufgabe eignet sich perfekt ein temporärer systemd-nspawn-Container, dessen Einrichtung ich hier beschrieben haben.
Erstellen der Binaries für telegram-cli
Um die Binaries für das telegram-cli-Paket erfolgreich erstellen zu können, sind zuvor einige Grundlagen zwingend herzustellen. Das bedeutet, es gibt Abhängigkeiten, ohne deren Vorhandensein die nächsten Schritte gar nicht möglich sind. In meinem systemd-nspawn-Container ist natürlich gar nichts von diesen Grundlagen enthalten, also muss ich das alles erst installieren. Wenn jemand das Programm allerdings auf seinem regulären Desktop-PC erstellt, kann es durchaus sein, dass einiges oder vielleicht sogar schon fast alles bereits enthalten ist. Deswegen führen wir vor jedem Install-Befehl eine kurze Prüfung durch, ob die benötigten Pakete nicht vielleicht schon längst installiert sind. Und das bedeutet weiterhin, wir schauen uns jedes Ergebnis der einzelnen dpkg -l - Anweisungen genau an und installieren anschließend nur die fehlenden Pakete. Die Namen aller bereits jetzt schon installierten Pakete werden also aus dem Install-Befehl entfernt. Bitte dabei sehr sorgfältig arbeiten und die Namen auf wirklich zeichengenaue Schreibweise überprüfen.
Unter Debian Stretch und auch zuvor unter Debian Jessie hatte ich das von 'vysheng' unter github (https://github.com/vysheng/tg) veröffentlichte Paket für telegram verwendet. Das hat bisher tatsächlich völlig störungsfrei funktioniert. Allerdings scheint dieses Projekt tot zu sein, denn es wird offensichtlich seit Jahren nicht mehr gepflegt, alle Pakete sind scheinbar seit Jahren unverändert, selbst Fehler (bekannte Assertion-Errors) werden nicht mehr behoben. Nun ja, unter Stretch habe ich davon nichts bemerkt, es lief trotzdem. Aber jetzt unter Debian Buster musste ich feststellen, dass ich es noch nicht mal mehr kompilieren konnte. Der aktuelle Compiler stellt jetzt Fehler fest, mit denen das Erzeugen des Binaries in diesem Zustand des Source-Codes leider nicht mehr möglich ist.
Die Lösung dieses für mich eigentlich unlösbaren Problems, ich hätte den alten Code nämlich nicht anpassen können, lag Gottseidank auch wieder bei github, und zwar in dem folgenden Fork des vysheng-Repos: https://github.com/kenorb-contrib/tg. Ich habe den Code beider Repos im Groben Modulweise verglichen und bin am Ende zu dem Schluss gekommen, dass der Fork tatsächlich nur Wartungs- und Pflegeänderungen enthält. Aber, und darauf kommt es dann letztlich an, der kenorb-Fork lässt sich fehlerfrei kompilieren und Binaries und Libs werden erstellt.
Wie bei all meinen anderen Projekten verschwende ich keinen Gedanken an die Verwendung eines sicherheitskritischen "sudo" und gehe stattdessen davon aus, dass für die Einrichtung der root-Account direkt verwendet werden kann.
$ su - # dpkg -l zlib1g-dev libreadline-dev libconfig-dev lua5.2 liblua5.2-dev # apt install zlib1g-dev libreadline-dev libconfig-dev lua5.2 liblua5.2-dev | Jedes Mal vorher prüfen, welche Pakete bereits auf dem Rechner vorhanden sind und welche installiert werden müssen. Nur die fehlenden sind zu installieren. |
# dpkg -l libssl-dev libpython-dev libevent-dev libjansson-dev make # apt install libssl-dev libpython-dev libevent-dev libjansson-dev make | dto. |
# dpkg -l git # apt install git | Installation des Git-Repos |
# mkdir /home/git # cd /home/git # git clone --recursive https://github.com/kenorb-contrib/tg.git git clone --recursive https://github.com/vysheng/tg.git | Anlegen des lokalen Zielverzeichnisses und clonen des Projektes in das Zielverzeichnis. Das Verzeichnis /home/git ist keine zwingende Vorgabe, sondern von mir willkürlich festgelegt. Eine Änderung hier beinhaltet natürlich die entsprechende Änderung bei allen relevanten Folgepunkten. Hier ist der Vollständigkeit halber nur noch mal die frühere Alternative genannt, die hier aber nicht verwendet wird. Sofern dieses Repo trotzdem verwendet werden soll, müssen bei Einrichtung unter Debian-Stretch zuvor die Assert-Errors im File mtproto-utils.c behoben werden. |
# cd /home/git/tg # ./configure # make # cd /home/git/tg/tgl # ./configure # make | Erzeugen der Binaries |
# mkdir -p /tmp/telegram/root/opt/telegram # mkdir -p /tmp/telegram/root/DEBIAN # mkdir -p /tmp/telegram/root/usr/local/share/man/man8 # mkdir -p /tmp/telegram/root/usr/local/bin | Ein temporäres Installationsverzeichnis erstellen, in das später die benötigten Files kopiert bzw. erstellt werden. |
# ne /tmp/telegram/root/DEBIAN/control Package: telegramcli Version: 1.0.0 Section: misc Priority: extra Architecture: amd64 Depends: Installed-Size: 22 mb Maintainer: toml <toml@thlu.de> Homepage: www.thlu.de Description: telegram-cli | Die markierten Werte sind auf eigene Parameter anzupassen
Achtung: Unterhalb des Feldes „Description“ muss als letzte Zeile eine Leerzeile angefügt werden. |
# cp /home/git/tg/bin/telegram-cli /tmp/telegram/root/opt/telegram # cp /home/git/tg/bin/tl-parser /tmp/telegram/root/opt/telegram # cp /home/git/tg/tgl/libs/libtgl.so /tmp/telegram/root/opt/telegram # cd /tmp/telegram/root/opt/telegram # ./telegram-cli -h >/tmp/telegram/root/usr/local/share/man/man8/telegram-cli.8 # cd /tmp/telegram/root/usr/local/bin # ln -s ../../../opt/telegram/telegram-cli telegram-cli | Zur Vorbereitung die Dateien kopieren bzw. anlegen... |
# cd /tmp/telegram # dpkg -b /tmp/telegram/root telegram-cli_buster_amd64.deb | ... und abschließend wird das deb-Package erzeugt. |
# cp telegram-cli_buster_amd64.deb /home/thomas # scp "telegram-cli_buster_amd64.deb" thomas@10.0.1.42:/home/thomas oder # scp -P 55551 "telegram-cli_buster_amd64.deb" thomas@10.0.1.42:/home/thomas | Entweder das Deb-Package aus dem flüchtigen /tmp in einen nichtflüchtigen Speicher kopieren oder via SSH direkt auf das Zielsystem übertragen. |
# systemctl poweroff | Wenn für die Erstellung unseres Installations-Archivs ein systemd-nspawn-Container vewendet wurde, kann dieser nun heruntergefahren werden. |
Achtung, nachdem der Container jetzt gerade geschlossen wurde, müssen wir uns unbedingt daran erinnern, dass der Container ebenfalls in einer RAM-Disk erzeugt wurde und somit auch alle im Container liegenden Dateien der Flüchtigkeit einer RAM-Disk unterliegen. Das bedeutet, beim nächsten Ausschalten unseres Rechners wird unser neu erstelltes Archiv automatisch gelöscht, also müssen wir das Archiv unbedingt noch sichern. Das geht einfach mit dem folgenden Befehl, mit dem wir das Tar-Archiv aus dem Verzeichnis des geschlossenen Containers direkt auf das nichtflüchtige Verzeichnis /home unseres PCs kopieren:
# cp /tmp/D10/home/thomas/telegram-cli_buster_amd64.deb /home/thomas
Jetzt haben wir zwar das Setup-Paket auf unserem lokalen PC gesichert, aber sofern noch nicht geschehen, muss es ja auch noch auf den künftigen FTP-Server übertragen werden, um es schließlich dann dort zu installieren. Ich übertrage also das Deb-Package zunächst einfach via SSH in mein auf dem FTP-Server liegendes dortiges Homedir. Wenn ich mich dann später auf dem Server selber (via SSH) anmelde, kann ich es dann von dort direkt installieren. Die IP-Adresse 10.0.1.42 ist derzeit noch die, die der PC vom DHCP-Server (DSL-Router) zugewiesen bekommen hat. Wenn diese auf dem DSL-Router damit gleichzeitig auch automatisch reserviert wurde, kann das durchaus auch so bleiben. Wer allerdings hier lieber eine auf dem Server selber gesetzte Static-IP verwenden möchte, muss natürlich hier noch mal Hand anlegen. Weil das aber eine andere Baustelle ist und im wesentlichen nicht viel mit diesem Konzept an sich zu tun hat, gehe ich auf dieses Problem nicht ein. An der Stelle ist die reservierte und vom DHCP vergebene Adresse funktional völlig ausreichend.
$ cd /home/thomas
$ scp "telegram-cli_buster_amd64.deb" thomas@10.0.1.42:/home/thomas
Das mag jetzt alles auf den ersten Blick geradezu konfus aussehen, aber in Wirklichkeit ist es das gar nicht. Eigentlich ist das sogar sehr einfach. Ich arbeite schlichtweg an oder verwende gleichzeitig 3 Systeme. Dabei sitze ich jedoch an meinem PC und an meiner Tastatur. Auf allen 3 System bin ich selber als User eingerichtet und habe dementsprechend dort auch ein Homedir. Und je nachdem, wo ich das Deb-Package benötige, oder wo es derzeit gespeichert ist, schiebe es via scp ganz nach Bedarf hin und her.
System | Hostname | lokale IP | bestehendes Homedir | Anmeldung |
1. mein eigener PC | thomaspc | 10.0.1.25 | /home/thomas | lokal |
2. temporäre systemd-nspawn-VM in /tmp | d10snvm | ^ | /home/thomas | lokal virtuell |
3. der Cam-FTP-Server via SSH | ftps | 10.0.1.42 | /home/thomas | SSH |
An dieser Stelle noch ein kurz ergänzender Hinweis: Auf dem künftigen FTP-Server bin ich natürlich auch selber mit eigenem Namen und eigenem Password angelegt. Mit meinem Linux-Account kann ich mich lokal und auch via SSH auf dem FTP-Server für Wartungsarbeiten anmelden. Für den späteren FTP-Server-Betrieb wird im Verlauf dieser Dokumentation aber noch ein weiterer (virtueller und weitestgehend unberechtigter) Benutzer angelegt. Bei mir ist das der virtuelle Benutzer ftpd, der nicht für eine reale Person steht und auch nicht von einer realen Person verwendet wird. Dieser Name kann natürlich beliebig geändert werden, aber hier in dieser Dokumentation ist eben ftpd der von den IP-Cams verwendete Anmeldename zum FTP-Server, damit die Cams ihre Aufnahmen unter Verwendung dieses Accounts speichern können. Das ist zwar im Moment noch nicht von Bedeutung, aber wir sollten uns das für später merken. Warum nicht alles unter einem Account? Na ganz einfach, weil ich höhere Berechtigungen habe, z.B. Samba-Berechtigungen und weil ich nicht will, dass diese missbraucht werden können. Und einfach auch deshalb, weil für diese einfache FTP-Speicherung wirklich die einfachsten Berechtigungen ausreichend sind. Jeder User bekommt nicht mehr Rechte, als er zur Erfüllung seine Aufgabe unbedingt benötigt.
|
Installation der benötigten Services
Nachdem nun der große Rahmen und die einzelnen Inhalte detailliert beschrieben sind und auch die Vorarbeiten für Telegram-Cli erledigt sind, und ich hoffe, es wurde die eigentliche Zielsetzung und die Vorgehensweise auch verstanden, geht es nun an die Einrichtung der benötigten Services auf unserem neuen CAM-FTP-Server. Es sind 3 Services einzurichten, und zwar der FTP-Server, SMS-Tools und Telegram-CLI. Ich hatte das zwar schon erwähnt, dass das bei mir in einer libvirt-VM läuft, aber an dieser Stelle lass ich das außer acht. Die Einrichtung in einer VM ist identisch mit der Einrichtung auf einem physisch vorhandenen echten Rechner. Ich mach das einfach per SSH-Anmeldung.
Je nach Dauer, wie lange der letzte Upgrade zurückliegt, wird das System zunächst einmal auf einen aktuellen Stand gebracht. Wenn alle Pakete aktuell sind, kann full-upgrade und reboot natürlich auch übersprungen werden.
$ ssh thomas@10.0.1.42
$ su -
# apt update
Statusinformationen werden eingelesen.... Fertig
Alle Pakete sind aktuell.
# apt full-upgrade
# systemctl reboot
Danach werden weitere und zusätzlich notwendige Pakete überprüft. Überprüfen bedeutet nachzusehen, ob die entsprechenden Pakete nicht schon auf dem Rechner installiert sind, um dann nur die noch fehlenden zu installieren. Bitte also nicht einfach blind die Befehlszeilen kopieren und übernehmen und ausführen... es ist jedes mal sicherzustellen, dass nur die jetzt noch fehlenden Pakete installiert werden.... alles andere lassen wir unberührt! Wir installieren also zuerst alle notwendigen Pakete und wenn das erfolgt ist, befassen wir uns mit der Inbetriebnahme bzw. den jeweiligen Einstellungen.
Auf meinem FTP-Server ist auch Samba installiert. Das ist dann notwendig, wenn man die zusätzliche Möglichkeit haben will, die gespeicherten Bilder direkt im Quellverzeichnis zu öffnen, ohne sie erst via FTP-Client-Software runter laden zu müssen. Wenn Samba noch nicht installiert ist, kann die Abfrage des Paketmanagers beim Installieren des Paketes zum Thema Netzwerk und DHCP einfach mit der Default vorgegebenen Antwort "nein" beantwortet werden.
# dpkg -l samba dpkg-query: Kein Paket gefunden, das auf samba passt # apt install samba |
Und schließlich soll auch noch das Telegram-Cli installiert werden. Warum eigentlich 2 Benachrichtigungssysteme gleichzeitig? Würde nicht eins völlig ausreichen? Ich glaube, das ist eine Frage, die man schlichtweg nicht allgemeingültig beantworten kann. Ich glaube, man muss hierbei einfach eine Entscheidung treffen. Als leidenschaftlicher Camper habe ich immer wieder mal die unschöne Situation erlebt, dass ich zeitweise gar kein WLAN verfügbar hatte. In solchen Zeiten bin ich dann für die telegram-Nachrichten nicht erreichbar. Und selbst wenn ich vor der Reise noch hier in DE eine EU-Internet-Flat gebucht habe, meistens ein für uns völlig ausreichendes 5 GB-Paket, so habe ich in Frankreich mehr als nur einmal die Erfahrung gemacht, dass man als Ausländer schlichtweg keine Bandbreite bekommt oder das die Anmeldung an den Dienst gar nicht erst angenommen wird. Selbst das Wechseln der Anbieter hatte keine Erfolg. In anderen EU-Ländern habe ich das so noch nicht erlebt, nur in Frankreich. Und es war dort weder von der Tageszeit, noch Regional zu bestimmen, wann es mal bei welchem Provider geht und wann nicht.
Im Endeffekt würde es also hierbei im Ernstfall darauf hinauslaufen, dass ich die Telegram-Benachrichtigung möglicherweise viel zu spät bekomme und schlimmstenfalls sind die Daten auf dem Web-Space dann sogar schon wieder gelöscht. Dieses Problem behebt die SMS-Benachrichtigung, denn die funktioniert eigentlich immer, solange ich mich nicht komplett außerhalb eines Handy-Netzes aufhalte. Um hier also zu einem Fazit zu kommen, muss man eigentlich nur gründlich die eigenen Umstände abwägen. Wenn man sich sicher sein kann, an seinem Urlaubsort immer WLAN zur Verfügung zu haben, oder alternativ eine konstant funktionierende Auslands-Internet-Flat, oder man hält sich sowieso nur in Deutschland auf und hat eine laufende Inlands-Flat.... dann ist wahrscheinlich die Telegram-Cli-Alternative eine ausreichende Lösung.
Außerdem empfinde ich es aber auch noch als Vorteil, etwas verschwenderischer mit den Telegram-Nachrichten umgehen zu können, weil die halt kostenlos sind. Ich lass mir ja das ganze Jahr über diese Statusnachrichten zusenden, damit ich sehe, dass das System als solches noch ordentlich seinen Job tut. Ich empfehle, das Telegram-Cli immer zu installieren, die SMS-Funktionalität aber nur dann, wenn man zu dem Schluss kommt, dass das auch wirklich notwendig ist, weil man vorhersagbar immer auch mal vom Internet-Zugang abgeschnitten sein kann.
Der letzte Schritt zur Software-Installation ist nur noch das fehlende Telegram-Cli:
# cd /home/thomas # dpkg -i telegram-cli_buster_amd64.deb # dpkg -l telegramcli :::: ||/ Name Version Architektur Beschreibung +++-==============-============-============-================================= ii telegramcli 1.0.0 amd64 telegram-cli # ls /opt/telegram insgesamt 26M drwxr-xr-x 2 root root 4,0K 2019-05-05 10:15 . drwxr-xr-x 3 root root 4,0K 2019-05-05 11:26 .. -rwxr-xr-x 1 root root 15M 2019-05-05 10:15 libtgl.so -rwxr-xr-x 1 root root 11M 2019-05-05 10:14 telegram-cli -rwxr-xr-x 1 root root 268K 2019-05-05 10:14 tl-parser |
|
 | Alle weiteren hier in dieser Beschreibung angelegten bzw. anzulegenden Dateien können mit dem dieser Beschreibung entsprechenden Inhalt unter der folgenden Adresse runter geladen werden. http://www.thlu.de/Public/cameventctl.tar Wenn die im Tar-File enthaltenen Dateien in die späteren Original-Verzeichnisse kopiert werden, um sie dort manuell anzupassen, müssen unbedingt die Rechte-Einstellungen gemäß dieser Anleitung nachbearbeitet werden! Im Übrigen ist es möglich, dass die Beispiele hier in der Anleitung weniger aktuell sind, als die im Tar-File enthaltenen Dateien. Deswegen empfehle ich unbedingt, nur die Beispieldateien aus dem Tar-File zu verwenden und jeweils von dort direkt in die jeweiligen Zielverzeichnisse zu entpacken. |
Um die folgenden Dateien müssen wir uns nun zuerst kümmern bzw. diese aus dem Tar-File heraus ins jeweilige Zielverzeichnis kopieren. Die Tabelle soll einen kurzen Überblick verschaffen, welche Aufgabe die einzelnen Dateien erfüllen. Nach dem Kopieren bitte die Rechte gemäß dieser Tabelle korrigieren: | |||
Speicherort | Name | Rechte | Bemerkung |
 /etc/systemd/system/ | serverctl.service | root:root 644 | Startet die Prüfung zur Verfügbarkeit des Netzwerks und ob das Default-Gateway (im Regelfall der DSL-Router) erreichbar ist |
| netfilter.service | root:root 644 | Setzt einen Paketfilter, um den Datentransfer aus Sicherheits-erwägungen heraus zu kontrollieren und zu regulieren |
setup-proftpd.service | root:root 644 | Startet den FTP-Server | |
setup-smstools.service | root:root 644 | Startet den SMS-Service, zum Senden und Empfangen von SMS-Nachrichten | |
setup-telegramd.service | root:root 644 | Startet den Telegram-Service, zum Senden und Empfangen von Telegram-Nachrichten | |
send-startup-msg.service | root:root 644 | Sendet eine Start-Up-Message an die eingetragenen Empfänger, zur Information, dass der Server neu gestartet wurde und nun betriebsbereit ist | |
backup-ftp-dirs@.service | root:root 644 | Weil die eigentliche Daten-Speicherung in einer RAM-Disk erfolgt, werden alle Daten (jedoch keine Bilder) vor einem Shutdown gesichert, damit sie nicht durch den Shutdown verloren gehen. Der Restore zurück ins Arbeitsverzeichnis erfolgt nach dem Systemstart automatisch. | |
| media-FTP.mount | root:root 644 | Erstellen einer RAM-Disk in /media/FTP, welches das primäre Arbeitsverzeichnis des FTP-Servers ist |
/usr/local/bin/ | serverctl | root:root 755 | Das Script, welches die Erreichbarkeit des Default-Gateways überprüft |
| netfilter | root:root 755 | Das Script, welches einen dynamisch aktualisierten Paketfilter setzt |
cam-event-ctl | root:root 755 | Das Programm-Script zum Handling der IP-Cam-Events | |
| cam-event-ctl.conf | root:root 600 | Die Konfigurations-Datei für das Programm |
Ich verwende in dieser Dokumentation auf dem Linux-System, auf dem die notwendigen Programme und Dienste installiert sind, die folgenden User-Namen, teilweise als reale User, teilweise als virtuelle User. Der Wirkungsort eines Users ist entweder das Linux-System, ein FTP-Server (lokal o. ISP) oder Telegram ISP. Die Unterscheidung ist zur Rechtebeschränkung im System und zur Abgrenzung untereinander notwendig.
Name | Password | Typ | Ort | Bemerkung |
root | {geheim} | System-Admin | Linux | Pwd ist notwendig, um Arbeiten mit Root-Rechten durchzuführen |
thomas | {geheim} | realer User | Linux | Ich selber bin als einziger echter Linux-User in der VM angelegt |
proftpd | - | virtueller User | Linux | Automatisch angelegt, proftp-Daemon läuft im Linux unter dieser UID |
ftpd | toms_ftp_pwd | virtueller FTP-User | Linux | Anmeldedaten für die IP-Cams zum FTP-Server |
toml | toms_isp_pwd | virtueller User | ISP | Anmeldedaten für FTP-Server beim Webspace/HomePage-Provider |
smsd | - | virtueller User | Linux | Automatisch angelegt, smstools-Daemon läuft unter dieser UID |
telegramd | tcli_msg_pwd | virtueller User | Linux | telegram-cli-Daemon läuft im Linux unter dieser UID. Daten im Home-Dir |
IPCamSrv | - | virtuell | telegram ISP | Account-Name für telegram-Client (Tel.-No->Surfstick) |
tom alarm | - | Reale Person | telegram ISP | Pseudonym (Alias) für reale Telegram-Empfänger mit eigenem Handy. Ich habe hier "alarm" als Alias für den realen Namen verwendet. Telegram unterscheidet nach Tel.-No's, nicht nach Alias-Namen, die ich einer Telefon-Nr. zuweise. |
silvia alarm | - | Reale Person | telegram ISP | |
manuel alarm | - | Reale Person | telegram ISP |
Hinweis zu den von mir verwendeten Namen Tom, Silvia und Manuel: Es sind zwar fiktive Namen, aber immer gleichbleibend, die ich auch schon in den anderen Dokumentationen verwendet habe, um auch im Überblick über alles die Zusammenhänge einfacher nachvollziehen und verstehen zu können. Im Grunde genommen ist alles zusammen ein einziges großes privates IT-Projekt, von dem natürlich auch alle Familienmitglieder betroffen sind, egal ob es sich um den Mailserver handelt, oder die Security-Settings, oder der externe Zugang via OpenVPN. |  |
|
Nach dem nun alle Dateien in das jeweilige Zielverzeichnis kopiert wurden, geht es weiter mit der Einrichtung des FTP-Servers. Weil dieser FT-Server ja kein öffentlicher Server ist und lediglich in einer isolierten VM nur als Ziel für die IP-Cams eingerichtet wird, ist es mit der Userverwaltung auch sehr einfach. Der User ftpd wird als einziger ftp-User angelegt, die IP-Cams verwenden diesen Anmeldenamen und das Password, um sich auf dem FTP-Server anzumelden. | |||
# adduser -shell /bin/false ftpd | Anlegen des einzigen FTP-Users ftpd mit dem Password toms_ftp_pwd. Der Benutzer-Name sowie das Password sind natürlich frei wählbar. Der FTP-User muss nur als Linux-User angelegt sein. Mit dieser Einstellung kann er sich zwar nicht lokal als Linux-User anmelden, es wird aber ein Homedir erstellt. Das Homedir wird wiederum von der Service-Unit backup-ftp-dirs.service beim Shutdown des Systems zum Anlegen der Sicherungskopieren aus der RAM-Disk vervendet. Das bedeutet, diese Service-Unit bekommt später den User-Namen ftpd als Instanz-Parameter übergeben. | ||
# ls -lah /home/ftpd insgesamt 20K drwxr-xr-x 2 ftpd ftpd 4,0K 2019-05-05 14:21 . drwxr-xr-x 4 root root 4,0K 2019-05-05 14:21 .. -rw-r--r-- 1 ftpd ftpd 220 2019-05-05 14:21 .bash_logout -rw-r--r-- 1 ftpd ftpd 3,5K 2019-05-05 14:21 .bashrc -rw-r--r-- 1 ftpd ftpd 807 2019-05-05 14:21 .profile find /home/ftpd -type f -exec rm '{}' \; | Weil sich der User ftpd sowieso nicht als lokaler Linux-User anmelden kann, werden die durch adduser im Verzeichnis angelegten Shell-Dateien auch nicht benötigt. Wir löschen sie deshalb einfach, damit sie im späteren Betrieb nicht für irgendwas missbraucht werden können. | ||
# mkdir /media/FTP # ls -lah /media | grep FTP drwxr-xr-x 3 root root 4,0K 2019-05-05 15:48 FTP | Anlegen des FTP-Verzeichnisses mit den Rechten 755 und root:root! Das ist das FTP-Zielverzeichnis, in dem die IP-Cams ihre Aufnahmen ablegen, bzw. der spätere Mount-Point für die RAM-Disk | ||
|
| ||
cp /etc/proftpd/proftpd.conf /etc/proftpd/proftpd.conf.org | Die originale Konfigurations-Datei für das Programm mit allen Default-Einstellungen wird einmal gesichert, bevor wir Änderungen daran durchführen. | ||
ne /etc/proftpd/proftpd.conf | Es sind hinsichtlich der Default-Einstellungen nur einige wenige Änderungen notwendig: | ||
UseIPv6 off | (aktivieren) | IPv6 wird verboten, weil die IP-Cams allesamt nur IPv4 unterstützen | |
DefaultRoot /media/FTP | (einfügen) | Das Default-Root-Dir für FTP-Zugriffe ist /media/FTP | |
<Limit LOGIN> DenyGroup !ftpd </Limit> | (Block einfügen) | Es sind nur Anmeldungen durch User erlaubt, die in der Group ftpd enthalten sind. Hier bin ich natürlich der einzige enthaltene User. | |
RequireValidShell off | (aktivieren) | Ermöglicht die Anmeldung virtueller User ohne Shell-Files | |
|
| ||
# ne /etc/hosts # cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 ftps | Mit einem Editor wird die folgende Zeile in die Datei hosts eingefügt: 127.0.1.1 ftps | ||
# hostnamectl set-hostname ftps # cat /etc/hostname ftps |
| ||
# find /etc -iname "*proftpd" | sort -bg /etc/init.d/proftpd /etc/rc0.d/K01proftpd /etc/rc1.d/K01proftpd /etc/rc2.d/S01proftpd /etc/rc3.d/S01proftpd /etc/rc4.d/S01proftpd /etc/rc5.d/S01proftpd /etc/rc6.d/K01proftpd | Der Service proftpd wird derzeit noch über die init.d-Runlevels gestartet, was bei Debian eigentlich seit dem Release von Jessie im April 2015 obsolet ist. Tatsache ist, die Runlevels werden derzeit nicht mehr von Debian direkt unterstützt, sondern es wird eine Service-Unit autogenerated erzeugt.
Ich halte das für keine gute Lösung und verwende stattdessen lieber eine explizite Service-Unit, die nicht nach irgendwelchen mehr oder weniger gut passenden Standards maschinell erzeugt wurde, sondern ausdrücklich dem Ziel angepasst ist. | ||
# systemctl status proftpd.service # systemctl stop proftpd.service # systemctl disable proftpd.service # systemctl status proftpd.service # update-rc.d proftpd remove # find /etc -iname "*proftpd" | sort -bg /etc/init.d/proftpd | Dazu wird zunächst der laufende Service gestoppt ...
...und für den nächsten Systemstart deaktiviert
Die Dateien aus den Runlevel-Dirs sind nun entfernt | ||
# systemctl reboot | Der Rechner wird neu gestartet, um alle Änderungen produktiv zu setzen. Nach dem Reboot sind noch alle Services inaktiv: | ||
# systemctl status serverctl.service setup-proftpd.service backup-ftp-dirs@ftpd.service media-FTP.mount ● serverctl.service - thlu:serverctl.service: Waiting for Network or Server to be up Loaded: loaded (/etc/systemd/system/serverctl.service; disabled; vendor preset: enabled) Active: inactive (dead) ● setup-proftpd.service - thlu:setup-proftpd.service: Starts ProFTPD daemon Loaded: loaded (/etc/init.d/proftpd; disabled; vendor preset: enabled) Active: inactive (dead) ● backup-ftp-dirs@ftpd.service - thlu:backup-ftp-dirs.service Backup + Restore tmpfs->/media/FTP to /home/ftpd/FTP Loaded: loaded (/etc/systemd/system/backup-ftp-dirs@ftpd.service; disabled; vendor preset: enabled) Active: inactive (dead) ● media-FTP.mount - thlu: Mount Local /tmp to tmpfs Loaded: loaded (/etc/systemd/system/media-FTP.mount; disabled; vendor preset: enabled) Active: inactive (dead) Where: /media/FTP What: tmpfs | |||
# ne /etc/systemd/system/media-FTP.mount [Unit] Description=thlu: Mount Local /tmp to tmpfs DefaultDependencies=no Conflicts=umount.target Before=local-fs.target umount.target
[Mount] What=tmpfs Where=/media/FTP Options=mode=777,strictatime Type=tmpfs
[Install] WantedBy=local-fs.target # systemctl start media-FTP.mount # df Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf tmpfs tmpfs 1003M 0M 1003M 0% /media/FTP # systemctl enable media-FTP.mount | Wie oben in den Anforderungen schon erwähnt, will ich meine Festspeicher entlasten. Das heißt, ich will den Festplatten die Möglichkeit geben, aus Stromspargründen einen Spindown durchzuführen und somit bei Nichtverwendung in den Sleep-Mode zu wechseln. Mit der enormen Datenmenge durch täglich 1000'e Bilddateien wäre aber genau das nicht möglich, die permanenten Motion-Ereignisse verhindern das. Darüber hinaus würde permanentes Aufwecken und erneutes Anlaufen der Mechanik den schnellen Tod jeder Festplatte begünstigen. Der Spindown müsste also im Interesse der Harddisk ausgesetzt werden, was aber wieder dem Stromspargedanken widerspricht. Ähnliche Gedanken betreffen meine SSDs, die ich vor der extrem hohen Anzahl Program- and Erase-Zyklen bewahren möchte. Ich will sie ja nicht unnötig forciert vorzeitig altern lassen. Die Lösung ist, die vielen Bewegungsdaten in einer RAM-Disk zu speichern. Wer das nicht will, muss diesen Punkt überspringen. Sofern die Standardgröße der angelegten RAM-Disk nicht ausreichen sollte und genügend RAM-Speicher im System vorhanden ist, kann der Platz mit diesem Austausch-Statement in der Service-Unit vergrößert werden: Options=mode=777,strictatime,size=2G Achtung: Die Vewendung dieser Unit erfordert zwingend auch die Aktivierung der Service-Unit backup-ftp-dirs.service (siehe unterhalb). | ||
# cd /media/FTP # mkdir 10_0_1_20 # mkdir 10_0_1_21 # mkdir 10_0_1_22
# chown ftpd:root /media/FTP/* # chmod 770 /media/FTP/* | Pro IP-Cam wird ein eigenes Unterverzeichnis angelegt, angelehnt an die statische IP-Adresse der Kamera. Die Rechte für die neuen Verzeichnisse müssen noch gesetzt werden, damit ftpd überhaupt einen Zugriff auf diese Verzeichnisse hat. Später wird noch die Gruppe sambausers hinzugefügt. Die gibt es aber jetzt noch nicht, weil Samba selber erst in einem noch folgenden Kapitel angelegt wird. | ||
Mit dem nächsten Schritt starten wir nun den FTP-Server manuell und prüfen unmittelbar darauf den Service-Status auf Fehler. Sofern keine (!) Fehler berichtet werden, kann der Service nun mit dem letzten Befehl auch für den Systemstart aktiviert werden. Die Start des Services erfolgt selbstverständlich über eine eigene Service-Unit: | |||
/etc/systemd/system/setup-proftpd.service | Die Rechte-Einstellung für die Unit: root:root 644 | ||
[Unit] Description=thlu:setup-proftpd.service: Starts ProFTPD daemon SourcePath=/etc/init.d/proftpd After=remote-fs.target nss-lookup.target serverctl.service Requires=serverctl.service
[Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SuccessExitStatus=5 6 ExecStart=/etc/init.d/proftpd start ExecStop=/etc/init.d/proftpd stop ExecReload=/etc/init.d/proftpd reload
[Install] WantedBy=multi-user.target | |||
| |||
# ne /etc/systemd/system/serverctl.service ExecStartPre=/usr/local/bin/serverctl 10.0.1.1 | Die Adresse 10.0.1.1 steht hier für die IP-Adresse des Default-Gateways. Es ist also die Adresse des DSL-Routers im lokalen Netzwerk, die zwingend auf die örtlichen Gegebenheiten angepasst werden muss. Hier muss also die IPv4 des lokalen DSL-Routers eingetragen werden. | ||
# dpkg -l rsync # apt install rsync | Bei Verwendung von tmpfs über media-FTP.mount muss das Paket rsync installiert sein. | ||
# systemctl start backup-ftp-dirs@ftpd.service # systemctl stop backup-ftp-dirs@ftpd.service # ls /home/ftpd/FTP drwxrwx--- 2 ftpd root 4,0K 2019-08-13 15:05 10_0_1_20 drwxrwx--- 2 ftpd root 4,0K 2019-08-13 15:05 10_0_1_21 drwxrwx--- 2 ftpd root 4,0K 2019-08-13 15:05 10_0_1_22 # systemctl start backup-ftp-dirs@ftpd.service | Achtung: Diese Service-Unit sichert nur die Dateien aus dem Verzeichnis /media/FTP/run. Die Service-Unit wird nur bei Verwendung der RAM-Disk in Verbindung mit der Mount-Unit media-FTP.mount aktiviert! |  | |
Ich halte es im Rahmen eines Wartungs-Shutdown überhaupt nicht für notwendig, auch die Bilddateien zu sichern, weil das ja eh nur flüchtige Dateien mit kurzer Lebensdauer sind. Je nach Umfang der Datenmenge ist es evtl. wegen des bestehenden Timeout-Limits auch gar nicht möglich, die Vollsicherung durch die Service-Unit vornehmen zu lassen. Bitte unbedingt beachten!!! Weil es sich hierbei um eine instantiierte Service-Unit handelt, muss beim Start der Unit das korrekte Homedir des FTP-Users übergeben werden, damit aus der RAM-Disk die betroffenen Dateien vor dem Shutdown in das richtige Homedir gesichert werden können. | |||
| |||
# systemctl start setup-proftpd.service # systemctl status serverctl.service setup-proftpd.service ● serverctl.service - thlu:serverctl.service: Waiting for Network or Server to be up Loaded: loaded (/etc/systemd/system/serverctl.service; disabled; vendor preset: enabled) Active: active (exited) since Sun 2019-05-05 14:37:57 CEST; 1h 4min ago Main PID: 443 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 4493) Memory: 0B CGroup: /system.slice/serverctl.service
Mai 05 14:37:57 ftps systemd[1]: Starting thlu:serverctl.service: Waiting for Network or Server to be up... Mai 05 14:37:57 ftps thlu:serverctl[441]: Successful terminated with exitcode=0 Mai 05 14:37:57 ftps systemd[1]: Started thlu:serverctl.service: Waiting for Network or Server to be up.
● proftpd.service - thlu:proftpd.service: Starts ProFTPD daemon Loaded: loaded (/etc/init.d/proftpd; static; vendor preset: enabled) Active: active (running) since Sun 2019-05-05 14:37:58 CEST; 4s ago Process: 445 ExecStart=/etc/init.d/proftpd start (code=exited, status=0/SUCCESS) Tasks: 1 (limit: 4493) Memory: 10.6M CGroup: /system.slice/proftpd.service └─454 proftpd: (accepting connections)
Mai 05 14:37:57 ftps systemd[1]: Starting thlu:proftpd.service: Starts ProFTPD daemon... Mai 05 14:37:57 ftps proftpd[445]: Starting ftp server: proftpd ...ftps proftpd[453]: processing config. dir... '/etc/proftpd/conf.d/' Mai 05 14:37:58 ftps proftpd[445]: . Mai 05 14:37:58 ftps systemd[1]: Started thlu:proftpd.service: Starts ProFTPD daemon | |||
# cd /etc/systemd/system # systemctl enable setup-proftpd.service # systemctl enable serverctl.service | Wenn in der Status-Ausgabe keine Fehler berichtet werden und der Service ordentlich gestartet wurde, kann nun auch der Start des Daemon für den Systemstart aktiviert werden. Waren allerdings Fehler enthalten, bitte die weiteren Schritte abbrechen und zuerst die Fehler korrigieren. | ||
# systemctl enable backup-ftp-dirs@ftpd.service # systemctl reboot | Nur bei Verwendung der RAM-Disk! Und abschließend ein Neustart um sicher zu sein, dass auch nach einem Reboot dieser Service läuft, einschließlich der Wiederherstellung der Dateien und Verzeichnisse in der RAM-Disk. | ||
|
| ||
ftp://ftpd:toms_ftp_pwd@10.0.1.42:21 | Nun ist es einfach zu testen, ob eine Verbindung zum Cam-Server hergestellt werden kann und ob die Verbindung funktioniert. Ich nutze dafür den MidnightCommander, dessen Menü ich über F9 öffne, um dann entweder "links" oder "rechts" im Untermenü "FTP-Verbindung" den angezeigten Befehl abzusenden.
Für die Anmeldedaten wird der zuvor eingerichtete FTP-User ftpd und dessen eingerichtetes Password, sowie die lokale IP meines FTP-Cam-Servers verwendet. Die rot markierten Felder müssen also auf die lokalen Gegebenheiten angepasst werden. | ||
Wenn der letzte Test auch erfolgreich war und alles fehlerfrei funktioniert hat, sollte es den IP-Cams jetzt möglich sein, sich ebenfalls auf diesem FTP-Cam-Server anzumelden und bei einem Motion-Detect die Aufnahmen entsprechend den Kamera-Einstellungen zu speichern. | |||
|
Der nächste einzurichtende Service ist die SMS-Benachrichtigung via Surf-Stick. An die Reihenfolge beim Einrichten der Dienste <SMS-Tools vor Telegramd> sollte wir uns unbedingt halten. Bei der anschließend folgenden Einrichtung von Telegram kann es nämlich sein, dass eine SMS mit einem Freischalt-Code gesendet wird. Und dann sollte der Surf-Stick natürlich auch soweit in Betrieb genommen sein, dass er die SMS überhaupt annehmen kann. | |||
# systemctl status smstools.service ● smstools.service - LSB: starts smstools Loaded: loaded (/etc/init.d/smstools; generated) Active: active (running) since Sat 2019-05-25 11:08....53min ago Docs: man:systemd-sysv-generator(8) Process: 330 ExecStart=/etc/init.d/smstools start ....SUCCESS) Mai 25 11:08:28 ftps smstools[330]: Starting SMS Daemon: smsd.
# find /etc -iname "*smstools" | sort -bg /etc/init.d/smstools /etc/rc0.d/K01smstools /etc/rc1.d/K01smstools /etc/rc2.d/S01smstools /etc/rc3.d/S01smstools /etc/rc4.d/S01smstools /etc/rc5.d/S01smstools /etc/rc6.d/K01smstools # systemctl stop smstools.service # systemctl disable smstools.service # systemctl status smstools.service # update-rc.d smstools remove # find /etc -iname "*smstools" | sort -bg /etc/init.d/smstools | Wie zuvor beim FTP-Service wird auch hier dieser Service zunächst wieder "traditionell" über die Runlevels gemäß dem alten sysvinit-System gestartet. Ich will das allerdings nicht mehr und löse das Problem wie zuvor auch hier wieder über eine individuelle Service-Unit, die angepasst an die eigentliche Aufgabe und an meine Anforderungen den Service startet. Der erste Schritt ist also die Ausplanung der alten Steuerung zum Start des Dienstes. | ||
|
| ||
# cp /etc/smsd.conf /etc/smsd.conf.org # ne /etc/smsd.conf delaytime = 30
#[GSM1] ##init = #device = /dev/ttyS0 #incoming = yes ##pin = #baudrate = 19200 | Mit der Anpassung der smsd.conf ist ein weiterer Schritt zur Einrichtung des Services getan. Obligatorisch sichern wir zunächst wieder die vom Paketmanager installierte Originalversion und fügen dann ans Ende der Conf unsere Settings ein. Sofern es für die betroffenen Parameter schon vorhandene Einstellungen gibt, werden diese mit '#' einkommentiert. Ich habe damit einfach den ganzen Block deaktiviert .... | ||
[GSM1] init = AT^CURC=0 device = /dev/ttyUSB0 incoming = yes baudrate = 115200 | ... und direkt unterhalb meinen eigenen am Ende angefügt. Damit wäre der Dienst fertig eingerichtet und könnte sogar gestartet werden. Aber damit warten wir noch, wir kümmern uns zunächst um unseren Surf-Stick, von dem wir ja noch gar nicht wissen, ob er überhaupt als Modem erkannt wird. Achtung: Ganz am Ende muss als letzte Zeile eine Leerzeile angefügt werden oder bereits enthalten sein. | ||
Und genau das ist möglicherweise noch ein großes Problem.... und zwar die Frage: Wie wird der Surfstick überhaupt vom Kernel erkannt? Mit lsusb (List USB-Devices) lassen wir uns also gleich anzeigen, wie unser Surfstick erkannt wird. Ich möchte speziell wegen dieser Problematik noch einmal auf einen wichtigen Umstand hinweisen: Die hier folgenden Angaben beziehen sich auf meinen Surfstick. Das bedeutet, wenn der eigene Surfstick nicht als Modem erkannt wird und Maßnahmen zur Umstellung erforderlich sind, so können die Befehle hier bei einem anderen Modell möglicherweise erfolgreich sein, aber ebenso wahrscheinlich auch vielleicht gar keine Auswirkung haben oder schlimmstenfalls sogar Fehler verursachen. Das bedeutet weiterhin, dass man die folgenden Beispielbefehle zur Umstellung des Sticks nicht einfach ungeprüft kopieren und anwenden darf... Nein! Stop!... wenn es sich um ein anderes Modell handelt und die Variante 1 mit angepasster VendorID:ProductID nicht funktioniert, musst Du im Internet nach einer passenden Lösung für Deinen Surfstick suchen. Ein leichtfertiger Versuch mit dem zum eigenen Modell nicht abgesicherten Befehl aus Variante 2 erfolgt auf eigenes Risiko! |  | ||
Und ich wiederhole auch noch einmal meinen Hinweis von oben, ich mache hier keine Werbung für Huawei oder für meinen speziellen Surfstick, das ist einfach nur das Modell, welches mir jetzt hier zur Verfügung steht und mit dem ich Erfahrungen sammeln konnte. Die folgenden Customizing-Befehle sind die, die genau für meinen Stick passen. Deshalb erfordert jedes andere Modell Sorgfalt und ggf. sogar eigene Recherche im Internet, um korrekte Angaben für den Modeswitch zu ermitteln. Eigentlich (und auch nach meinem Verständnis) sollte es so sein, dass Surfsticks quasi out-of-the-box funktionieren, und zwar ohne manuell eingreifen zu müssen. Dafür verantwortlich wäre das zuvor installierte Paket usb-modeswitch-data, welches den Stick mithilfe einer UDEV-Regel automatisch auf Modem-Funktionalität umstellt. Das ist aber bei meinem Stick leider nicht erfolgt. Aus Neugier habe ich dann mal die im Paket enthaltenen Regeln mit Angabe der Vendor-ID durchsucht, konnte dann aber weitergehend die passende Product-ID meines Sticks nicht finden. Das war wohl der Grund, warum er nicht umgestellt wurde.... mein Stick unterstützt diese Funktion nicht. | |||
# lsusb Bus 001 Device 007: ID 12d1:14c9 Huawei Techn.....(3G Modem) Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub | Wenn der Surfstick direkt als Modem erkannt wird, wie die folgende Ausgabe zeigt, sollten wir erleichtert durchatmen...
| ||
# lsusb Bus 001 Device 006: ID 12d1:14d1 Huawei Techn..... (Mass storage mode) Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub | Wenn er allerdings -wie bei mir und hier im Beispiel angezeigt- als Mass-Storage erkannt wird, haben wir ein Problem. Denn in diesem Fall ist Linux der Meinung, es handelt sich nicht um ein 3G-Modem, sondern um einen normalen Speicher-Stick. Bedauerlicherweise wurde mein Stick als Storage erkannt.
Die Hersteller-ID 12d1 ist in beiden Beispielen identisch, die Produkt-ID unterscheidet sich jedoch. Im Web habe ich dann die folgenden unterschiedlichen Lösungen zu Huawei-Surfsticks gefunden, um ihn von Storage auf Modem umzustellen. | ||
Variante 1: # usb_modeswitch -J -v 0x12d1 -p 0x14d1 | Dieser Versuch ist bei meinem Stick fehlgeschlagen - ich vermute, aus gleichem Grund, weswegen er auch nicht im Paket usb-modeswitch-data enthalten ist. Diese Funktionalität wird nur von neueren Huawei-Sticks unterstützt, von meinem anscheinend älteren Modell offensichtlich nicht. | ||
Der zweite Versuch war hingegen erfolgreich, und zwar die explizite Anweisung zur Umstellung als direkter einmalig ausgeführter Shell-Befehl mit Angabe eines Message-Contents. Bei der Suche nach einer Lösung im Internet habe ich auf einer Linux-Seite (ich glaube, es war gentoo oder arch (?)) den folgenden Message-Inhalt für die genannten Produkt-IDs gefunden, mit dem ich dann meinen Stick auf Modem umstellen konnte. Es handelt sich dabei um eine Bulk-Message, die einen Schaltbefehl sendet: TargetVendor=0x12d1 TargetProductList="1001,1406,140b,140c,1412,141b,1432,1433,1436,14ac,14d1,1506,1511" MessageContent="55534243123456780000000000000011062000000100000000000000000000" Interessant ist hier noch die Feststellung, dass die Umstellung im Stick erfolgt ist und nicht im Kernel. Das bedeutet, der Stick blieb auch "3G-Modem", wenn ich ihn in an andere Debian-Rechner eingesteckt habe. | |||
Variante 2: # usb_modeswitch -v 12d1 -p 14d1 -M '55534243123456780000000000000011062000000100000000000000000000' | |||
Ein ergänzender Hinweis: Sowohl für die Variante 1 als auch 2 kann es notwendig sein, den PC nach dem manuell durchgeführten Modeswitch einmal zu rebooten, damit die entsprechende Firmware geladen wird. Möglicherweise wurde der Stick selber durch den Befehl zwar umgestellt, aber der Kernel sieht ihn immer noch als Storage. Dieses Problem sollte mit dem Reboot behoben sein. Eine 3. Variante als Conf-Datei mit mehreren Message-Alternativen würde mit meinem Surfstick ebenfalls funktionieren. Diese Variante war aber nicht mehr notwendig, weil der Stick mit Variante 2 erfolgreich umgestellt war. Ich hatte diese Lösung ursprünglich gedacht, um den Modeswitch beim Systemstart via systemd-Service-Unit automatisch zu aktivieren. Aber wie schon oben festgestellt, ein einmaliger Modeswitch des Sticks ist offensichtlich persistent ... man braucht das also nicht mehr. | |||
Variante 3: # cat /etc/usb_modeswitch.d/huawei TargetVendor= 12d1 TargetProductList="14d1"
MessageContent="55534243123456780000000000000011062000000100000000000000000000" MessageContent1="5553424312345678000000000000061e000000000000000000000000000000" MessageContent2="5553424312345679000000000000061b000000020000000000000000000000" NeedResponse=1
# usb_modeswitch -v 12d1 -p 14d1 -c /etc/usb_modeswitch.d/huawei | |||
Nun ist der Zeitpunkt gekommen, den SMS-Service mit der neuen Service-Unit in Betrieb zu nehmen und die Funktion zu testen. Wir starten die Service-Unit und kontrollieren anschließend sofort den Status auf Fehler. Sofern kein Fehler berichtet wird, senden wir an unser Smartphone eine Testnachricht. Wird die SMS versendet und zugestellt, senden wir eine Antwort SMS, die ein paar Sekunden später im Zielverzeichnis des SMS-Services geöffnet werden kann: | |||
/etc/systemd/system/setup-smstools.service | Die Rechte-Einstellung für die Unit: root:root 644 | ||
[Unit] Description=thlu:setup-smstools.service: Starts smstools-Daemon
SourcePath=/etc/init.d/smstools Before=multi-user.target Before=graphical.target After=remote-fs.target
[Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SuccessExitStatus=5 6
ExecStartPre=/bin/mkdir -p /var/log/smstools/smsd_stats ExecStartPre=/bin/chown -R smsd:smsd /var/log/smstools ExecStart=/etc/init.d/smstools start ExecStop=/etc/init.d/smstools stop
[Install] WantedBy=multi-user.target | |||
| |||
# systemctl start setup-smstools.service # systemctl status setup-smstools.service ● setup-smstools.service - thlu:smstools.service: Starts smstools-Daemon Loaded: loaded (/etc/init.d/smstools; disabled; vendor preset: enabled) Active: active (running) since Sat 2019-05-25 12:10:10 CEST; 10s ago Process: 873 ExecStartPre=/bin/mkdir -p /var/log/smstools/smsd_stats (code=exited, status=0/SUCCESS) Process: 874 ExecStartPre=/bin/chown -R smsd:smsd /var/log/smstools (code=exited, status=0/SUCCESS) Process: 875 ExecStart=/etc/init.d/smstools start (code=exited, status=0/SUCCESS)
echo -e "To: 00491710000001\n\nTestnachricht vom $(date +%d.%m.%Y_%H:%M:%S)\n" >/var/spool/sms/outgoing/smsout_$(date +%Y%m%d_%H%M%S) | |||
| |||
# ls /var/spool/sms/sent insgesamt 12K drwxrwsr-t 2 smsd smsd 4,0K 2019-05-26 14:56 . drwxrwsr-t 7 smsd smsd 4,0K 2019-05-05 11:24 .. -rw-r--r-- 1 smsd smsd 154 2019-05-26 14:56 smsout_20190526_145532
# cat /var/spool/sms/sent/smsout_20190526_145532 To: 00491710000001 Modem: GSM1 Sent: 19-05-26 14:56:03 Sending_time: 2 IMSI: 200000000000000 IMEI: 800000000000000 Testnachricht vom 26.05.2019_14:55:32
# ls /var/spool/sms/incoming insgesamt 12K drwxrwsr-t 2 smsd smsd 4,0K 2019-05-26 15:22 . drwxrwsr-t 7 smsd smsd 4,0K 2019-05-05 11:24 .. -rw-r--r-- 1 smsd smsd 267 2019-05-26 15:20 GSM1.8X0mc2
# cat /var/spool/sms/incoming/GSM1.8X0mc2 From: 491710000001 From_TOA: 91 international, ISDN/telephone From_SMSC: 490000000000 Sent: 19-05-26 15:20:06 Received: 19-05-26 15:20:51 Subject: GSM1 Modem: GSM1 IMSI: 200000000000000 IMEI: 800000000000000 Report: no Alphabet: ISO Length: 22 Hier ist die Antwort-SMS! | Ein paar Sekunden später sollte die gesendete SMS im Sent-Ordner zu finden sein, und gleichzeitig sollte das Smartphone einen Benachrichtigungs-Ton ausgeben. Der Ablauf bei der Verarbeitung ist wie folgt: 1. Via echo-Command wird im Zielordner /var/spool/sms/outgoing/ eine SMS anlegt 2. Gemäß der Einstellung Delaytime=30 in der Conf wird dieser Ordner alle 30 Sekunden vom SMS-Daemon auf vorhandene neue SMS geprüft. 3. Wird eine neue SMS gefunden und sie ist nach Prüfung durch den Daemon syntaktisch fehlerfrei, wird sie zum Ordner /var/spool/sms/checked/ verschoben 4. Ist die SMS fehlerhaft wird sie hingegen zum Ordner /var/spool/sms/failed/ verschoben 5. Im Ordner /var/spool/sms/checked/ vorhandene SMS werden gesendet und zum Ordner /var/spool/sms/sent/ verschoben 6. Eingehende SMS werden im /var/spool/sms/incomming/ gespeichert. Der als Test von meinem Smartphone gesendete Antwort-Text für die empfangene SMS lautete: Hier ist die Antwort-SMS!
| ||
|
| ||
# systemctl enable setup-smstools.service | Ganz zum Schluss, wenn bei den vorherigen Schritten keine Fehler berichtet wurden und die Senden- und Empfangstests ebenfalls fehlerfrei waren, wird der Service einmalig für den Systemstart aktiviert. | ||
Das wars.... SMS senden und empfangen funktioniert perfekt und fehlerfrei, der Service wurde erfolgreich eingerichtet!
|
Die erstmalige Einrichtung des Telegram-Cli's hat mir wirklich viel Kopfzerbrechen bereitet.... deshalb, weil die vom PC aus durchgeführte Anmeldung an den Telegram-Server im Internet schlichtweg nicht funktioniert hat. Das ärgerliche bei allen fehlgeschlagenen Anmeldeversuchen war, dass meine Sim-Card resp. deren Telefon-Nummer bei der Wiederholung einer zuvor fehlgeschlagenen Anmeldung und bei erneutem Fehler sofort für 24 Stunden gesperrt war. Das heißt, ein Versuch, dann noch ein Versuch und jede weitere Anmeldung war für 24 Stunden gesperrt. Das Problem dabei war, ich konnte nicht mal ermitteln, was überhaupt den Anmelde-Fehler verursacht hat, um ihn darüber dann zu vermeiden. Mittlerweile glaube ich, dass es sich speziell hierbei vielleicht auch um eine Schwäche der Programms an sich handeln könnte. Die zuerst von mir verwendete Version von git->vysheng wurde ja offensichtlich über Jahre nicht gepflegt, bekannte Fehler wurden nicht beseitigt.
Bedauerlich ist, dass ich nun nach einmal erfolgreich durchgeführter Anmeldung dieser Telefon-Nr. das Problem nicht mehr reproduzieren kann.... auch nicht mit der Version git->kenorb-contrib, denn angemeldet ist angemeldet, die Sim-Card und die Telefonnummer sind auf dem Telegram-Server aktiviert. Deshalb kann ich auch nicht vorhersagen, ob es mit diesem neueren Fork auf Anhieb vom PC aus funktionieren wird. Aber zur Vermeidung jeglicher unerklärlicher Probleme gebe ich hier den Rat, steck einfach die neue Sim-Card, die anschließend in einen Surfstick eingesetzt werden soll, zunächst mal in ein passendes Smartphone, lade Dir dort die Telegram-App runter, mach die Erst-Anmeldung und fertig ist's. Ich hatte das Glück noch ein altes S2 zu haben, welches noch das ältere Simcard-Format Mini-SIM (UICC) aufnehmen konnte, das bedeutet, Surfstick und S2 hatten das gleiche Simcard-Format. Die Erst-Anmeldung via Smartphone war auf jeden Fall nervenschonender, als das Gefummel am PC und war gleich im ersten Versuch erfolgreich.
Wenn dann die Simcard mit dem erfolgreich angemeldeten Telegram-Account wieder in den Surfstick umgesetzt wurde, kann nun auch der Telegram-Service auf unserem Cam-Server in Betrieb genommen werden.
# systemctl reboot # journalctl -b -p err # systemctl status setup-smstools.service # echo -e "To: 00491710000001\n\nTestnachricht ....." | Wurde der Rechner in der Zwischenzeit ausgeschaltet? Wurde vielleicht der Surfstick "Hotplug" entfernt und erneut eingesteckt? Ich weiss es nicht, deshalb beginnen wir zur Sicherheit mit einem Reboot und einigen Basis-Checks. Wenn der sms-Service läuft, senden wir uns noch mal eine Testnachricht, die ankommen muss. Wenn Fehler berichtet werden oder der SMS-Test fehlschlägt... STOP! ... nicht weiter machen, zuerst die Fehler beheben! Wenn die SMS übertragen wurde, kann die Einrichtung telegram-cli fortgesetzt werden. |
# dpkg -l libjansson4 libconfig9 liblua5.2-0 # apt install libjansson4 libconfig9 liblua5.2-0 | Für das telegram-cli gibt es keinen 'Installer', alle notwendigen Vorbereitungen müssen also manuell durchgeführt werden. Für telegram sind bestimmte Libs notwendig, die, sofern sie noch nicht vorhanden sind, installiert werden müssen. Wie gehabt, nicht einfach den Befehl nur kopieren und ausführen, sondern nur die fehlenden installieren! |
# adduser telegramd | Telegram soll natürlich unter den Rechten eines weitestgehend unberechtigten Users laufen, der also zunächst manuell angelegt werden muss. Password = tcli_msg_pwd Das Password kann natürlich beliebig gewählt werden, und ich empfehle auch, das zu ändern... aber bitte so notieren, dass es nicht vergessen werden kann. |
# su telegramd $ telegram-cli -k tg-server.pub Telegram-cli version 1.4.1, Copyright (C) 2013-2015 Vitaly Valtman Telegram-cli comes with ABS...WARRANTY; for details type `show_license'. This is free software, and you are welcome to redistribute it under certain conditions; type `show_license' for details. Telegram-cli uses libtgl version 2.1.0 Telegram-cli includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) I: config dir=[/home/telegramd/.telegram-cli] | Erster Aufruf zur Registrierung des Users im System. Das telegram-cli legt für jeden User Auth-Files im jeweiligen Homedir an. Um missbräuchlicher Verwendung vorzubeugen, empfehle ich also immer vorher den User zu wechseln und alle Telegram-Cli-Aktionen immer nur unter dem User telegramd durchzuführen. Diese Form der Identifikation mit Bestätigungs-SMS ist nur ein einziges Mal notwendig. Wenn die Erst-Anmeldung auf dem Linux-System erfolgreich war, wurden im Homedir des Users telegramd Keyfiles angelegt, mit denen die Authentifizierung des telegram-cli's ab jetzt jedesmal automatisch abgeschlossen wird. |
phone number: +491780005555 | Nach einigen Sekunden erfolgt die Telefon-Nr-Abfrage vom Surf-Stick. Hier ist die Handy-Nummer der Simcard des Surfsticks einzutragen. |
code ('CALL' for phone code): 12345 User IPCamSrv online (was online [2019/05/17 18:20:54]) | Der zur Legitimierung der Anmeldung benötigte SMS-Verify-Code wird per SMS im Verzeichnis /var/spool/sms/incoming empfangen und muss hier auf diese Abfrage eingegeben werden. Weil die telegram-Shell allerdings das geöffnete Terminal exklusiv verwendet, muss nun ein zweites Terminal geöffnet werden, um den SMS-Verify-Code auszulesen. Die SMS lag keine 10 Sekunden später nach Eingabe der Tel-Nr. im Eingangsordner vor. Den Username IPCamSrv hatte ich bereits zuvor bei der grundsätzlichen Einrichtung des telegram-Accounts über das Smartphone (wie oben begründet) vorgegeben. Die Anmeldung auf diesem 'neuen' System (es ist ja nicht das Handy) wurde mit dieser Meldung jetzt nur bestätigt. Sofern auf diesem System schon ein anderer t-cli-User erfolgreich eingerichtet wurde, kommt keine SMS, sondern der Code wird via Telegram-Nachricht an den ersten User gesendet. |
> add_contact +491710000001 tom alarm tom alarm > add_contact +491720000022 silvia alarm silvia alarm > add_contact +491730000333 manuel alarm manuel alarm > msg tom_alarm "hey, kommt die nachricht an? bitte anworten!" [18:17] tom alarm <hey, kommt die nachricht an? bitte anworten! User tom alarm online (was online [2019/05/29 11:12:50]) User tom alarm marked read 1 outbox and 0 inbox messages User tom alarm is typing [11:08] tom alarm >>> Jau, is da :-) | Jetzt müssen nur noch die Kontakte mit Name und Telefon-Nr. angelegt werden, die später bei einem Motion-Detect-Alarm benachrichtigt werden sollen. add_contact <phone> <first name> <last name> Hier in diesem Beispiel ist tom alarm also mein Vor- und Nachname. Das gleiche gilt für die beiden anderen Empfänger - alarm ist der (hierfür von mir frei erfundene) Nachname. Die Handhabung irritiert ein wenig, weil die Kontakte zunächst mit Telefonnr{Blank}Vorname{Blank}Name angelegt werden müssen, aber später beim Senden wird das {blank} im Namen durch einen Unterstrich ersetzt. |
> help | Listet die im telegram-Cli verfügbaren Befehle |
> contact_list silvia alarm tom alarm manuel alarm | Listet die eingerichteten Kontakte |
> dialog_list User manuel alarm: 10 unread User silvia alarm: 5 unread User Telegram: 1 unread User tom alarm: 69 unread > mark_read tom_alarm |
|
> del_contact tom_alarm | Entfernt einen bereits eingerichteten Kontakt |
> quit | Beendet die interaktive Telegram-Shell |
Das Telegram-Cli ist im Grunde genommen jetzt funktionsfähig eingerichtet. Mit dem oben im Beispiel beschriebenen Befehl können wir eine interaktive Telegram-Shell öffnen, um Nachrichten zu senden und zu empfangen. Wir können nun aber auch eine Nachricht direkt senden, ohne zuvor die Shell zu öffnen. Aber ganz wichtig, alle Aktionen müssen unter der UID des Users telegramd erfolgen, weil in dessen Homedir die Auth-Files liegen. Der folgende Befehl ist somit also auch Bash-Script-tauglich, er sendet die Nachricht und würde hinterher einfach mit dem nächsten Script-Befehl fortfahren:
$ telegram-cli --help $ telegram-cli -k tg-server.pub -W -e "msg tom_alarm Zweite Testnachricht vom $(date +%d.%m.%Y_%H:%M:%S)" Telegram-cli version 1.4.1, Copyright (C) 2013-2015 Telegram-cli comes with ABSOLUTELY NO WARRANTY; for details type `show_license'. This is free software, and you are welcome to redistribute it under certain conditions; type `show_license' for details. Telegram-cli uses libtgl version 2.1.0 Telegram-cli includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit. (http://www.openssl.org/) I: config dir=[/home/telegramd/.telegram-cli] [11:40] tom alarm <<< Testnachricht vom 29.05.2019_11:40:06 > All done. Exit halt $ _ oder ohne Ausgaben (stdout): $ telegram-cli -k tg-server.pub -W -e "msg tom_alarm Dritte Testnachricht vom $(date +%d.%m.%Y_%H:%M:%S)" >/dev/null 2>&1 |
Alternativ zur direkten und unmittelbaren Verwendung des Telegram-Cli oder zur Verwendung innerhalb einer interaktiven Shell ist auch die Einrichtung eines Port-Gebundenen Telegram-Daemons möglich. Der Daemon kann dann wie unter systemd üblich mit einer Service-Unit beim Systemstart gestartet werden. Welche Vorteile hat das zur One-Shot-Technik im Terminal oder zur TCli-Shell? Das ist mit einem pauschalen Statement schwer bis gar nicht zu beantworten... ob der Service als Daemon einen Vorteil bietet hängt allein von den eigenen Anforderungen ab.
Ein primärer Unterschied ist, dass im Non-Daemon-Modus und insbesondere bei One-Shot-Shell-Statements keine eingehenden Nachrichten abgerufen und angezeigt werden. Lediglich bei einer konstant im aktiven Terminal laufenden Telegram-Cli-Shell würden alle ungelesenen Dialoge kontinuierlich aktualisiert angezeigt werden. Das bedeutet aber auch, dass sich zunächst ein User anmelden muss, das das aktive Terminal vor Abmeldung des Users (z.B. bei einer SSH-Sitzung) über einen Terminal-Multiplexer (z.B. Screen oder Tmux) in den Hintergrund verschoben werden muss, weil sonst bei Abmeldung des Users der SSH-Sitzung auf dem Cam-Server alle offenen Terminalsitzungen einschließlich der TCli-Shell geschlossen werden. Das Lesen von ankommenden oder ausgehenden Messages wäre bei einer solchen SSH-Sitzung nur nach einem Re-Login möglich, nachdem man einen Re-Attach der in den Hintergrund verschobenen Terminal-Sitzung durchgeführt hat. Das ist meiner Meinung nach die dümmste Vorgehensweise zur Lösung dieses speziellen Problems.
Oder man entscheidet sich alternativ dafür, die TCli-Shell bei Sitzungsende ganz einfach zu schließen und man ist zufrieden damit, wenn alle neuen Dialoge erst bei der nächsten Anmeldung abgerufen und angezeigt werden. Das kann man durchaus mit einem Smartphone vergleichen, welches ja auch nur sporadisch eine Internet-Verbindung herstellen kann. Hier ist jetzt als Entscheidungshilfe anzumerken, wenn man vielleicht gar nicht mit eingehenden Nachrichten rechnet, z.B. ist das ja bei einem solchen Cam-Even-Alarm-System eigentlich auch gar nicht notwendig, weil ja nur Alarm-Benachrichtigungen rausgehen müssen, kann man durchaus mit dieser Variante zurecht kommen.
Im Daemon-Modus läuft der Telegram-Daemon hingegen kontinuierlich und sorgt dafür, dass alle Dialoge in einer Log-Datei permanent aktualisiert und sichtbar sind. Den Inhalt der Log-Datei sieht man sich bei Bedarf via cat tg.log an oder auch via tail -f tg.log an. Das betrachte ich durchaus als Vorteil, denn ich kontrolliere sporadisch das Log über vergangene Aktivitäten. Mit dem immer aktuellen Chat-Log ist es natürlich einfacher getan, sich eben via SSH auf der VM einzuloggen und mit 'cat' einen Blick auf die Log-Datei zu werfen. Es wäre sogar problemlos möglich, das Log z.B. auch in einer Samba-Freigabe zu speichern, dann kann man es quasi direkt von seinem Client-PC öffnen.
Ausgehende Nachrichten werden an Localhost und den freigegebenen Port gesendet (Bsp. s.u.). In Fortführung der von mir verwendeten unkonventionellen Port-Nummern (siehe Artikel security)
55551 = SSH
55552 = VNC/RDT
55553 = OVPN/UDP
55554 = OVPN/TCP
verwende ich in dieser Dokumentation den Port
55555 = Telegram-Cli-Daemon
Leider ist es nicht ohne zusätzliche Handgriffe möglich, von anderen Systemen aus dem lokalen Netzwerk Telegram-Nachrichten über diesen Daemon zu versenden. Eine Eigenart des Daemons ist es nämlich, nur auf Loopback zu lauschen. Und für Martians (also 'Besucher' von außerhalb = fremde Pakete) ist loopback eben nur ein loophole... das bedeutet, fremde Pakete mit der Zieladresse localhost werden vom Kernel einfach verworfen. Mit einem auf einem 2. Port lauschenden Wrapper wäre es allerdings recht einfach möglich, Nachrichten von anderen PCs aus dem LAN zu senden. Man braucht dazu nur diesen erwähnten kleinen zusätzlichen Wrapper, der fremde Pakete annimmt und sie an localhost weitersendet. Obwohl das eigentlich nur eine kleine Spielerei ist, habe ich selber keinen Bedarf an einer solchen Funktion, deswegen habe ich das bisher nicht umgesetzt. Man darf dabei nicht vergessen, dass man ja auch evtl. eingehende Rückantworten nicht so einfach lesen kann, denn die stehen ja in der Datei tg.log auf einem anderen System, welche auf meinem PC eben auch nicht ohne weitere Handgriffe einsehbar ist.
Zunächst also hier folgend die Service-Unit, um Telegram als Daemon zu starten, der dann unter der unberechtigten UID des virtuellen Users "telegramd" läuft.
/etc/systemd/system/setup-telegramd.service | Die Rechte-Einstellung für die Unit: root:root 644 |
[Unit] Description=thlu:setup-telegramd.service Start Telegram-Interface as service After=serverctl.service Requires=serverctl.service
[Service] Type=simple RemainAfterExit=yes ExecStart=/opt/telegram/telegram-cli -d -P 55555 -L /home/telegramd/tg.log -W ExecStop=/usr/bin/pkill -9 -e telegram-cli User=telegramd Group=telegramd
[Install] WantedBy=multi-user.target | |
| |
$ su - | Wenn der vorherige Wechsel des User-Kontext mit su telegramd durchgeführt wurde, dann nur mit Eingabe von exit zurück wechseln, ansonsten wie angegeben zur root-Shell wechseln. |
# systemctl start setup-telegramd.service # systemctl status setup-telegramd.service ● setup-telegramd.service - thlu:setup-telegramd.service Start Telegram-Interface as service Loaded: loaded (/etc/systemd/system/setup-telegramd.service; disabled; vendor preset: enabled) Active: active (running) since Thu 2019-05-30 11:57:33 CEST; 6s ago Main PID: 921 (telegram-cli) Tasks: 1 (limit: 4493) Memory: 18.0M CGroup: /system.slice/setup-telegramd.service └─921 /opt/telegram/telegram-cli -d -P 55555 -L /home/telegramd/tg.log -W
Mai 30 11:57:33 ftps systemd[1]: Started thlu:setup-telegramd.service Start Telegram-Interface as service. # ss -tulpen | grep telegram Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port tcp LISTEN 0 5 127.0.0.1:55555 *:* users:(("telegram-cli"))
# systemctl enable setup-telegramd.service | |
Wie in der ss-Ausgabe oberhalb zu sehen ist, lauscht Telegram nur auf localhost. TCP-Pakete, die von anderen Rechnern an das reguläre Netwerk-Interface gesendet wurden, können von Telegram leider nicht bearbeitet werden, weil sie -wie oben schon erwähnt- vorher schon vom Kernel verworfen wurden. Mit dem Start als Daemon haben wir nun jedoch 2 weitere lokale Alternativen bekommen, neue Nachrichten zu versenden. Die vorher schon verwendete erste Variante funktioniert weiterhin: | |
# su telegramd $ telegram-cli -k tg-server.pub -W -e "msg tom_alarm Vierte Testnachricht vom $(date +%d.%m.%Y_%H:%M:%S)" $ echo "msg tom_alarm Fünfte Testnachricht vom $(date +%d.%m.%Y_%H:%M:%S)" >/dev/tcp/127.0.0.1/55555 $ echo "msg tom_alarm Sechste Testnachricht vom $(date +%d.%m.%Y-%H:%M:%S)" | nc -q 1 127.0.0.1 55555 | |
Um nun mal auf die Schnelle das Log zu prüfen, verwende ich diesen Zweizeiler im Homedir:
$ cat /home/telegramd/catlog #!/bin/bash tail -n 200 tg.log | grep "\[[0-9][0-9]:" |
|
Ich empfinde es als ausgesprochen komfortabel, von meinem PC aus direkt auf die Verzeichnisstruktur des Systems zuzugreifen, in dem über den FTP-Service die von den IP-Cams übertragenen Bilder abgelegt werden. Und selbstverständlich müssen auch die Familienmitglieder im Fall der Fälle Zugriff auf die Daten haben, sowohl die verreisten, als auch die daheimgebliebenen. Das funktioniert perfekt, wenn auf dem System auch noch ein Samba-Server eingerichtet wird, der die Verzeichnisse als Freigaben im Netzwerk zur Verfügung stellt. Mit der Einrichtung des Samba-Servers will ich mich aber trotzdem gar nicht lange aufhalten, das ist eine einfache Angelegenheit und Details können 100fach im Web nachgelesen werden.
Zuerst erfolgt die obligatorische Sicherung der Original-Conf des Maintainers, dann wird ein komplett neuer Inhalt angelegt. Hier ist nur zu beachten, dass der Parameter hosts allow auf das richtige Netzwerk angepasst werden muss. Ich verwende ja in meinen Dokumentationen (auch hier) durchgängig die genannten Netzwerke, und zwar immer die gleichen, damit das Zusammenwirken verschiedener Lösungen beim Überblick leichter verständlicher ist. Ebenso müssen weiter unten in der Conf die beiden Parameter write list und valid users angepasst werden, wenn ein andere Gruppenname verwendet wird.
# cd /etc/samba # mv smb.conf smb.conf.org # touch smb .conf # ne smb.conf # smb.conf # Date : 08.08.2019 # Version: 3 # #==================================================================================================================
[global] hosts allow = 10.0.1.0/24 localhost workgroup = WORKGROUP server string = %h server server role = standalone server dns proxy = no log file = /var/log/samba/log.%m max log size = 1000 panic action = /usr/share/samba/panic-action %d security = user encrypt passwords = true passdb backend = tdbsam obey pam restrictions = no unix password sync = yes 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 = no map to guest = bad user usershare allow guests = no invalid users = root
#================================================================================================================== # Shares
[FTP] path=/media/FTP writeable = yes browseable = yes guest ok = no write list = @sambauser valid users = @sambauser force group = sambauser create mask = 0660 force create mode = 0660 directory mask = 0770 force directory mode = 0770 | |
| |
# addgroup sambauser # adduser thomas sambauser # adduser silvia sambauser # adduser manuel sambauser # smbpasswd -a thomas # smbpasswd -a silvia # smbpasswd -a manuel # pdbedit -L | Jetzt ist nur noch die Gruppe 'sambauser' zu erstellen, einen oder mehrere Samba-User anzulegen und diese der neu erstellten Gruppe zuzuweisen. |
# systemctl restart smbd nmbd # systemctl status smbd nmbd | Als letzter Schritt ist noch einmal ein Neustart der Services durchzuführen. Beide Samba-Services müssen fehlerfrei im Status sein! |
# testparm rlimit_max: increasing rlimit_max (1024) to .... Registered MSG_REQ_POOL_USAGE Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED Load smb config files from /etc/samba/smb.conf rlimit_max: increasing rlimit_max (1024) to ..... Processing section "[FTP]" Loaded services file OK. Server role: ROLE_STANDALONE
Press enter to see a dump of your service definitions
# Global parameters [global] dns proxy = No log file = /var/log/samba/log.%m map to guest = Bad User max log size = 1000 panic action = /usr/share/samba/panic-action %d passwd chat = *Enter\snew\s*\spassword:*...... passwd program = /usr/bin/passwd %u security = USER server role = standalone server server string = %h server unix password sync = Yes idmap config * : backend = tdb hosts allow = 10.0.1.0/24 localhost invalid users = root
[FTP] create mask = 0660 directory mask = 0770 force create mode = 0660 force directory mode = 0770 path = /media/FTP read only = No valid users = @sambauser write list = @sambauser | Die letzte Prüfung: Ist unsere neue smb.conf fehlerfrei und werden die eingerichteten Shares (hier ist es nur "FTP") korrekt angezeigt? |
# chown ftpd:sambauser /media/FTP/* | Weiter oben bei der Einrichtung des FTP-Servers wurde schon auf diesen noch fehlenden Schritt hingewiesen. Denn damit auch alle Sambauser Zugriffsrechte auf die angelegten Bilder haben, wird den in dieser Gruppe eingetragenen Mitgliedern hiermit das Recht erteilt |
An dieser Stelle sollte es jetzt möglich sein, vom eigenen PC aus über einen Mount-Befehl auf das durch Samba freigegebene FTP-Datenverzeichnis des Cam-Servers zuzugreifen (/media/FTP). Das ist das Verzeichnis, in dem künftig die Bilder der IP-Cams angelegt werden. Ich gebe also auf meinem PC den folgenden verkürzten Mount-Befehl (als root) ein: # /bin/mount //10.0.1.42/FTP /mnt -t cifs -o username=thomas,uid=thomas,gid=thomas,defaults und müsste dann sofort nach der Eingabe des Samba-Passwords im lokalen Verzeichnis /mnt den Verzeichnisinhalt der Freigabe ansehen und ggf. auch verändern können. Sofern allerdings auf einem Client-PC ein permanenter Mount zum FTP-Server eingerichtet werden soll, der direkt beim Start erstellt wird, empfehle ich die Verwendung der im tar-File beigefügten Mount-Unit media-FTP@.service, anstatt des nicht mehr ganz zeitgemäßen Eintrags in die fstab. Die Aktivierung für den Systemstart auf meinem Rechner und mit meinen Samba-Berechtigungen würde dann mit folgendem Statement erfolgen: | |
# systemctl enable serverctl.service # systemctl enable media-FTP@thomas.service |
|
Ausführliche Informationen zur Handhabung von Remote-Mounts über das Netzwerk mit anwenderbezogenen Rechten sind in meiner Dokumentation < mountctl > enthalten. |
|
|
Wenn der Cam-Server neu gestartet wird, möchte ich darüber informiert werden. Und zwar jedes Mal. Natürlich, wenn ich das selber veranlasst habe, weiß ich das ja und kann es direkt beobachten und kontrollieren, keine Frage... aber was ist während meiner Abwesenheit, wenn das System z.B. nach einem Stromausfall durch irgendwen neu gestartet werden muss? Die initiale Benachrichtigung via SMS und Telegram ist dann für mich die Bestätigung, dass der Server, sein Netzwerk und diese Funktionen wieder einwandfrei arbeiten. Es werden alle in der cam-event-ctl.conf eingetragenen Empfänger über den Neustart benachrichtigt. | |
# ne /etc/systemd/system/send-startup-sms.service [Unit] Description=thlu:send-startup-sms.service: Send SMS after System is booted After=setup-smstools.service setup-telegramd.service
[Service] Type=oneshot ExecStartPre=/bin/sleep 3 ExecStart=/usr/local/bin/cam-event-ctl smsbootinfo
[Install] WantedBy=multi-user.target | |
# systemctl start send-startup-sms.service # systemctl enable send-startup-sms.service | Wenn nach dem manuellen Start der Service-Unit die Empfänger gemäß der Einstellungen in der cam-event-ctl.conf durch diesen Test über den vermeintlichen Neustarts des Systems benachrichtigt wurden, kann dieser Service nun für den Systemstart aktiviert werden. |
|
Abschluss-Test der neuen Services
Nachdem jetzt alle für uns wichtigen Services eingerichtet sind, sollten wir einmal einen Systemstart durchführen, um dann zu prüfen, ob die Services auch wirklich fehlerfrei starten und aktiv sind. Im wesentlichen sollte die Ausgabe dann wie die folgende aussehen, die ich allerdings der Übersichtlichkeit wegen ein klein wenig eingekürzt habe. Nach dem Neustart sollte jetzt folgendes möglich sein, sowohl auf dem Cam-Server als auch von anderen Client-PC im LAN.
1. Über einen FTP-Client von einem beliebigen PC im LAN die FTP-Verzeichnisses des Cam-Servers zu öffnen
2. Auf dem Cam-Server via SMSTools eine SMS zu senden und auch wieder zum empfangen
3. Auf dem Cam-Server via telegram-cli Nachrichten zu senden und zu empfangen
4. Von einem beliebigen Client-PC im LAN die Samba-Freigaben des Cam-Servers zu öffnen
# systemctl reboot # systemctl status setup-proftpd setup-smstools setup-telegramd smbd nmbd ● setup-proftpd.service - thlu:setup-proftpd.service: Starts ProFTPD daemon Loaded: loaded (/etc/init.d/proftpd; enabled; vendor preset: enabled) Active: active (running) since Fri 2019-05-31 10:46:17 CEST; 47s ago Process: 491 ExecStart=/etc/init.d/proftpd start (code=exited, status=0/SUCCESS) Tasks: 1 (limit: 4493) Memory: 10.0M CGroup: /system.slice/setup-proftpd.service
Mai 31 10:46:15 ftps systemd[1]: Starting thlu:setup-proftpd.service: Starts ProFTPD daemon... Mai 31 10:46:16 ftps proftpd[491]: Starting ftp server: proftpd2019-05-31 10:46:16,876 ftps proftpd[501]: processing .... Mai 31 10:46:17 ftps proftpd[491]: . Mai 31 10:46:17 ftps systemd[1]: Started thlu:setup-proftpd.service: Starts ProFTPD daemon.
● setup-smstools.service - thlu:setup-smstools.service: Starts smstools-Daemon Loaded: loaded (/etc/init.d/smstools; enabled; vendor preset: enabled) Active: active (running) since Fri 2019-05-31 10:46:10 CEST; 54s ago Process: 339 ExecStartPre=/bin/mkdir -p /var/log/smstools/smsd_stats (code=exited, status=0/SUCCESS) Process: 356 ExecStartPre=/bin/chown -R smsd:smsd /var/log/smstools (code=exited, status=0/SUCCESS) Process: 361 ExecStart=/etc/init.d/smstools start (code=exited, status=0/SUCCESS) Tasks: 2 (limit: 4493) Memory: 8.3M CGroup: /system.slice/setup-smstools.service
Mai 31 10:46:08 ftps systemd[1]: Starting thlu:setup-smstools.service: Starts smstools-Daemon... Mai 31 10:46:09 ftps smstools[361]: Starting SMS Daemon: smsd. Mai 31 10:46:10 ftps systemd[1]: Started thlu:setup-smstools.service: Starts smstools-Daemon.
● setup-telegramd.service - thlu:setup-telegramd.service Start Telegram-Interface as service Loaded: loaded (/etc/systemd/system/setup-telegramd.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2019-05-31 10:46:15 CEST; 49s ago Main PID: 492 (telegram-cli) Tasks: 1 (limit: 4493) Memory: 18.2M CGroup: /system.slice/setup-telegramd.service
Mai 31 10:46:15 ftps systemd[1]: Started thlu:setup-telegramd.service Start Telegram-Interface as service.
● smbd.service - Samba SMB Daemon Loaded: loaded (/lib/systemd/system/smbd.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2019-05-31 10:46:17 CEST; 48s ago Process: 461 ExecStartPre=/usr/share/samba/update-apparmor-samba-profile (code=exited, status=0/SUCCESS) Main PID: 502 (smbd) Status: "smbd: ready to serve connections..."
Mai 31 10:46:15 ftps systemd[1]: Starting Samba SMB Daemon... Mai 31 10:46:17 ftps systemd[1]: Started Samba SMB Daemon. Mai 31 10:46:17 ftps smbd[502]: daemon_ready: STATUS=daemon 'smbd' finished starting up and ready to serve connections
● nmbd.service - Samba NMB Daemon Loaded: loaded (/lib/systemd/system/nmbd.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2019-05-31 10:46:15 CEST; 50s ago Main PID: 330 (nmbd) Status: "nmbd: ready to serve connections..." Tasks: 1 (limit: 4493)
Mai 31 10:46:08 ftps systemd[1]: Starting Samba NMB Daemon... Mai 31 10:46:15 ftps systemd[1]: Started Samba NMB Daemon. Mai 31 10:46:15 ftps nmbd[330]: daemon_ready: STATUS=daemon 'nmbd' finished starting up and ready to serve connections |
|
cam-event-ctl ist das Programm, welches die oben in der Einleitung beschriebenen Teilprozesse durchführt. Neben der durch die root-cron-Tab aufgerufenen Jobs kann cam-event-ctl auf Linux-Client-PCs (!) auch im Dialog-Modus gestartet werden, um einige primäre Funktionen ein- oder auszuschalten. Dabei war es aber eindeutig kein Ziel, eine komfortable grafische Bedienoberfläche zu erhalten, um z.B. alle möglichen Settings in netten grafischen Dialogen eines Web-GUIs durchzuführen. Stattdessen ging es darum, ein rudimentäres Tool zu schaffen, mit dem elementare Aktionen aktiviert oder deaktiviert werden können. Die eigentlichen Settings zur Steuerung der Prozesse müssen via Terminal und Editor direkt auf dem Cam-Server durchgeführt werden. Und gerade was das aktivieren und deaktivieren einzelner besonderer Aktionen angeht, wie Alarm ein- oder ausschalten, oder Benachrichtigungen ein- oder ausschalten oder auch nur vorübergehend pausieren, bin ich bei der Umsetzung für diese einfachen Dialog-Funktionen einen äußerst unkonventionellen Weg gegangen.... und zwar verwende ich Dateien, die über ihren Datei-Namen eine Switch-Funktion erfüllen. Der Vorteil ist, ich kann somit Anweisungen über FTP-Statements erteilen und darüber dann solcherart primären Funktionen ein- oder ausschalten.
Für alle Funktionen bzw. für die Verarbeitung als ganzes ist die folgende Verzeichnisstruktur zugrunde gelegt:
 |
Das Programm und die derzeit aktive Conf. Alternative Confs, die sich nur durch das Alarmverhalten unterscheiden: - Heartbeat = Keine ständig verfügbaren Alarm-Messages, sondern nur periodische Benachrichtigungen als Lebenszeichen des Systems - 3 unterschiedliche Zeiteinstellungen - Stiller Modus = Alarm-Benachrichtigungen ausgeschaltet - Abwesenheitsmodus= volle Benachrichtigung, SMS und TCli-Msg an alle Empfänger Aktiver Paketfilter (ist ein Sicherheitsfeature, aber nicht zwingend notwendig). Prüft die Verfügbarkeit eines Servers oder des Netzes über Default-Gateway. Zielverzeichnisse für die von den IP-Cams angelegten Aufnahmen, je IP-Cam ein eigenes Verzeichnis. Der leichteren Zuordnung wegen bei Wartungsarbeiten habe ich die Verzeichnisnamen jeweils aus der IP-Adresse der IP-Cam abgeleitet. On-Off-Settings einzelner primärer Funktionen (siehe unten folgende Erläuterungen). Diese Dateien erfüllen über ihren Namen quasi Umschalt-Aktionen für primäre Funktionen, die darüber aktiviert oder deaktiviert werden können.
Die von den Prozessen angelegten Log-Dateien, die durch das implementierte Log-Rotate jedoch nur begrenzt (ca. 2 Wochen) verfügbar sind. |
Der Vorteil dieses oben schon erwähnten und eher unkonventionellen Vorgehens ist, dass das Programmverhalten mit beliebigen Werkzeugen von außerhalb des Systems beeinflusst werden kann. Es sind hier einfache leere Dateien im FTP-Verzeichnis, wie z.B. für die SMS-Benachrichtigung, die entweder sms.on oder sms.off heißen kann und die mit ihrer aktuellen Extension eine Schaltfunktion erfüllt. Es gibt keine Regeln dafür, mit welchem Werkzeug man den Zustand von .on. nach .off ändert, was geht ist auch erlaubt. Zum Beispiel über den Dialog-Modus des Programms auf einem Linux-Client-PC, oder durch Umbenennen in der Samba-Freigabe, oder via SSH-Zugriff im Terminal, oder via Browser + FTP-Plugin, oder einem beliebigen FTP-Client.
Im Dialog-Modus des Programms wird über FTP-Statements der aktuelle Status ermittelt und bei Änderung im Menü wird die Datei bezogen auf Ihre Switch-Bedeutung einfach via FTP-Kommandos auf die neue Extension umbenannt. Aber wie gesagt, die Umbenennung kann man auch mit beliebigen anderen Werkzeugen veranlassen. Beim nächsten Programmlauf wird der jetzt vorhandene Zustand berücksichtigt.
Ist mit dieser Flexibilität ein Sicherheitsrisiko verbunden? Nö, wieso? Wer Samba-Berechtigungen hat, hat doch sowieso Password-Autorisierte Zugriffsrechte. Das gleiche gilt für SSH, oder für den Zugriff als FTP-Client. Außerdem ist es hier eh nur eine streng limitierte VM, die sowieso keine Rechte auf irgendwas im LAN hat, sondern nur auf das, was für diesen Job notwendig ist. Und drittens vergibt diese VM natürlich auch keine Rechte für Zugriffe aus dem Internet.
Default-Einstellung für Dateien mit Switch-Bedeutung jeweils bezogen auf eine Funktion:
alarm.{on|off} | on = aktiviert die Alarmverarbeitung, aktuelle 5-Min-Pakete werden zum ISP-FTP übertragen, sms oder msg werden gemäß der Einstellungen gesendet off = deaktiviert den Prozess |
backup.{on|off} | on = aktiviert das Erstellen von 4h-Backups zum ISP-FTP-Speicher, löscht lokale Daten älter als 12 Stunden off = deaktiviert den Prozess |
upload.{on|off} | on = aktiviert den Upload für alle Prozesse auf den angegebenen FTP-Web-Space. Zugangsdaten sind erforderlich: Hostname, Username, Password. off = deaktiviert den Upload, alle Daten verbleiben lokal auf dem Server. In diesem Fall rate ich davon ab, die lokalen FTP-Verzeichnisse -wie in dieser Dokumentation beschrieben- in einer RAM-Disk (tmpfs) anzulegen. |
sms.{on|off} | on = aktiviert das Senden von SMS bei Alarm-Events off = deaktiviert das Senden |
msg.{on|off} | on = aktiviert das Senden von TCli-Msg bei Alarm-Events off = deaktiviert das Senden |
smspause.{on|off} | on = aktiviert eine 12h-Pause für Benachrichtigungen bei ansonsten "aktiven" Einstellungen. Alle Prozesse laufen normal durch, es wird nur für 12 Stunden keine Benachrichtigungen versendet. off = keine aktive Pause |
ispdelold.{on|off} | on = aktiviert das Löschen alter Pakete auf dem ISP-FTP-Speicher entsprechend der vorliegenden '"Paketlisten" off = deaktiviert den Prozess |
Welchen Zweck erfüllt die Funktion smspause.on? Nun, das ist einfach erklärt. Es gibt durchaus Situationen, in denen das Benachrichtigungs-System zwar grundsätzlich dauerhaft aktiv sein soll, aber man will es vielleicht aufgrund besonderer privater Umstände vorübergehend 'pausieren'. Pausieren bedeutet, man muss hinterher nicht daran denken, es wieder zu aktivieren.... das passiert nach Ablauf von 12 Stunden automatisch.
Schauen wir uns als nächstes die Basic-Conf des Programms an, die weitere maßgebliche Einstellungen enthält. Alle roten Parameter müssen selbstverständlich auf die eigenen lokalen Gegebenheiten angepasst werden. Ja, ich weiß, da stehen Zugangsdaten und Verschlüsselungspassworte in Reinschrift in der Datei. Ja und? wen interessiert's? Erstens, dieser Cam-Server hat keinen interaktiven User-Verkehr, da meldet sich niemand an, um das zu lesen. Zweitens, der Server läuft isoliert in einer VM, also nicht auf einer Hardware, an die man mal aus Neugier einen Bildschirm und eine Tastatur anschließen kann. Drittens, die Zugangsdaten zum FTP-Server sollen doch gar nicht geheim sein. Wenn sie es wären, wie kämen denn dann die Familienmitglieder im Fall der Fälle an die Daten dran? Viertens, es geht nur um äußerst kurzlebige und sehr langweilige Tür- und Fenster-Fotos, wo Leute durchs Bild laufen, die nur deshalb vor der Übertragung verschlüsselt werden, damit ein fremder Admin (ISP) nicht schnüffeln kann, was ihn nichts angeht. All diese so wichtigen Daten müssen hier in der Familie allerdings ganz sicher nicht geheim sein... wozu auch? Im Gegenteil, die Conf ist sogar notwendigerweise mit allen Inhalten auf verschiedenen Clients gespeichert.
/usr/local/bin/cam-event-ctl.conf | Die Rechte-Einstellung für die Unit: root:root 644 |
remoteftps = www.toms_ftps.de # ISP-FTP-Account remoteuser = toml remotepassword = toms_isp_pwd remotepath = CamEvents
localftps = 10.0.1.42 # lokaler FTP-Account localuser = ftpd localgroup = sambauser localpassword = toms_ftp_pwd localpath = /media/FTP
EncryptPwd = cam_tarfile_pwd # AES-Tarfiles -> ISP-FTP tcliport = 55555 # Optionaler Port für Telegram-CLI-Daemon
MinDelSMSLock=60 # Nächste SMS frühestens nach ? Minuten MinDelMSGLock=60 # Nächste MSG frühestens nach ? Minuten
sms2telno = 00491710000001 # Sende SMS an... wenn Zeitfenster-KZ 1 oder 3 sms2telno = 00491720000022 sms2telno = 00491730000333
msgto = tom_alarm # Sende Telegram-Message an... wenn KZ 2 oder 3 msgto = silvia_alarm msgto = manuel_alarm
smstxt = "Bewegungsalarm! Festgestellt am $(date +%d.%m.%Y-%H:%M)" msgtxt = "Bewegungsalarm! Festgestellt am $(date +%d.%m.%Y-%H:%M)"
# Vorgegebene Zeitfenster, in denen Benachrichtungen (SMS und MSG) versandt werden: # 1 1 1 1 1 1 1 1 1 1 2 2 2 2 # 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 # 123412341234123412341234123412341234123412341234123412341234123412341234123412341234123412341234
sun = 333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 mon = 333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 tue = 333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 wed = 333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 thu = 333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 fri = 333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333 sat = 333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333333
# 1 2 3 4 5 6 7 8 9 # 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456 | |
Die Abschnitte bei remoteftps und localftps bezeichnen die beiden vom Programm verwendeten FTP-Server. Vom Cam-Server, auf dem auch der lokale FTP-Server läuft, werden natürlich nur die Zugangsdaten zum ISP-FTP-Server - also dem Web-Space- verwendet. Sofern das Programm aber auch auf einem normalen Linux-Client gestartet werden soll, um eben von dort z.B. die Switch-Dateien umzuschalten, sind natürlich auch dort die Zugangsdaten notwendig, und zwar für beide FTP-Server. Die zwei Pfad-Angaben remotepath und localpath bezeichnen die Speicherorte aus Sicht des Servers, das lokale Arbeits-Verzeichnis ist hier /media/FTP, das Remote-Dir liegt im Root-Verzeichnis des FTP-Servers und hat den Namen CamEvents.
Das EncryptPwd sollte ebenfalls auch in einer reinen Client-Conf bestehen bleiben, weil es dann auf diesem Client via Dialog auch zur Entschlüsselung eines vom ISP-Web-Space heruntergeladenen Tar-Archivs verwendet werden kann.
Gerade was meine hier verwendeten Passwörter angeht, halte ich es sowieso nicht für notwendig, Hochsicherheitsmaßnahmen einzurichten. Es sind schließlich nur verschlüsselte und kurzlebige Cam-Archive betroffen. Der lokale FTP-Server ist eh nur LAN-Intern erreichbar. Auf alle in irgendwelchen Dateien gespeicherten Einstellungen des Cam-Servers ist außer über einen gesicherten Zugang via SSH mit Pubkey-Authority überhaupt kein Zugang möglich. Lokale Anmeldungen durch User sind nicht möglich. Der externe FTP-Server verwendet einen eher unberechtigten FTP-Zugang, der außer den Verzeichnissen für verschlüsselte Daten nichts anderes enthält oder ermöglicht. Unbestritten ist hingegen, es müssen immer alle betroffenen resp. für diese Daten berechtigten Familienmitglieder auch alle Zugangsberechtigungen zu allen Systemen haben, zum lokalen FTP-Server, via Cifs-Mount, zum ISP-FTP-Server und natürlich zur Entschlüsselung. Wie sollen sie denn sonst im Fall der Fälle an möglicherweise relevante "Beweis"-Bilder kommen?
Die Einstellung tcliport definiert den Port auf dem telegram-cli lauscht, wenn das Programm als Daemon betrieben wird.
Nach jeder versendeten Benachrichtigung wird eine eigene Sperr-Datei (Lock-File) für jeden Messenger angelegt. Der von mir voreingestellte Lifecycle-Wert dieses Lock-Files ist 60 Minuten. Der Hintergrund ist, dass nach der ersten Benachrichtigung nicht im Sekundentakt wie Maschinengewehrfeuer weitere Benachrichtigungen gesendet werden sollen. So etwas würde das Prepaid-Guthaben einer SimCard binnen kürzester Zeit aufbrauchen. Die zwei Parameter MinDelSMSLock und MinDelMSGLock legen die Anzahl Minuten fest, wann ein Lock-File nach dem Senden der Benachrichtigung wieder gelöscht wird. Beim nächsten festgestellten Cam-Motion-Detect-Event würden dann erneut Benachrichtigungen gesendet werden ... und erneut dann wieder mit einer neuen 60-Minuten-Sperre vesehen.
Mit den beiden Parametern sms2telno und msgto werden die Empfänger festgelegt.
Über die Parameter smstxt und msgtxt können für jeden Nachrichtentyp individuelle Texte festgelegt werden.
Über den Abschnitt Zeitfenster kann definiert werden, welcher Nachrichten-Typ zu welcher Tageszeit versendet werden soll. Eine Woche hat 7 Tage, 1 Tag hat 24 Stunden mit jeweils 4 Viertelstunden, als insgesamt 7 Tage x 96 Viertelstunden pro Tag ... 1 Viertelstunde ist also die kleinste Einheit für Zeitvorgaben für einen Tag. Der Viertelstunden-Wert des zeitlich zum IP-Cam-Bewegungs-Ereignis passende Zeitfenster-Feldes steuert das weitere Programm-Verhalten. Enthält der Viertelstunden-Wert die Kennziffer...
0, wird keine Benachrichtigung gesendet.
1, wird eine SMS gesendet
2, wird eine TCli-Nachricht gesendet
3, werden beide Nachrichten-Typen gesendet, zuerst eine SMS und dann die TCli-Nachricht
Wenn jetzt die Programm-Konfiguration eingerichtet ist, sind nur noch wenige Schritte erforderlich:
# cam-event-ctl debug | Zeigt uns unsere Einstellungen an und wir prüfen sorgfältig, ob alle Werte vom Programm auch richtig gelesen wurden. Dabei bitte auf Sonderzeichen, unerwünschte Zeichen oder Leerzeichen an unerwünschten Stellen achten. |
# cam-event-ctl init | Wenn alle Einstellungen nach der Prüfung als korrekt beurteilt sind, werden mit diesem Befehl einmalig im lokalen Verzeichnis /media/FTP/run die notwendigen State-Files erzeugt und die Rechte auf diese internen Verzeichnisse und Dateien angepasst. |
# ftp ftp> open www.toms_ftps.de Connected www.toms_ftps.de. 220-FTP server ready. 220 This is a private system - No anonymous login Name (www.toms_ftps.de): toml 331 User toml OK. Password required Password: toms_isp_pwd 230 OK. Current restricted directory is / Remote system type is UNIX. Using binary mode to transfer files. ftp> ls 200 PORT command successful drwxr-xr-x 5 toml 2048 Aug 10 14:38 . drwxr-xr-x 5 toml 2048 Aug 10 14:38 .. ftp> mkdir CamEvents 257 "CamEvents" : The directory was successfully created ftp> ls 200 PORT command successful drwxr-xr-x 6 toml 2048 Aug 11 13:58 . drwxr-xr-x 6 toml 2048 Aug 11 13:58 .. drwxr-xr-x 2 toml 4096 Aug 11 13:58 CamEvents ftp> bye 221-Goodbye. You uploaded 0 and downloaded 0 kb. 221 Logout. | Wenn ein Remote-FTP-Server (ISP, Homepage, Web-Space, etc.) eingetragen wurde: Conf-Wert remoteftps = www.toms_ftps.de und ein Zielverzeichnis definiert wurde: Conf-Wert remotepath = CamEvents bedeutet das, dass dieses Verzeichnis auf dem entfernten FTP-Server natürlich auch vorher eingerichtet sein muss. Mit einer manuellen Anmeldung prüfen wir unsere in der Conf eingetragenen Anmelde-Daten und dann in der angemeldeten Sitzung gleichzeitig auch den Remote-Path. Sofern der Pfad noch nicht existiert, wird er sofort erstellt. Wenn der Vorgang fehlschlägt, aus welchen Gründen auch immer, bitte die Inbetriebnahme des Programms sofort abbrechen, auf gar keinen Fall einfach mit dem nächsten Punkt weitermachen. Wenn hier ein Fehler vorliegt, muss dieser zuerst behoben werden. |
# cam-event-ctl testrftps 12.08.2019-19:10:04 Upload=off # mv /media/FTP/run/upload.off /media/FTP/run/upload.on | Wenn später die Sicherungskopien des Servers automatisch auf den Web-Space überragen werden sollen, prüfen wir mit diesem Befehl, ob das Programm eine Test-Datei erfolgreich senden kann. Der erste Versuch wird fehlschlagen, weil der Default-Zustand Off ist. Um den Sendevorgang zu erlauben, kann das State-File einfach umbenannt werden. |
# cam-event-ctl testrftps 10.08.2019-16:39:21 Start senden /media/FTP/run/Testupload Passive mode on. Connected to www.toms_ftps.de. 220-FTP server ready. 220 This is a private system - No anonymous login 331 User toml OK. Password required 230 OK. Current restricted directory is / Remote system type is UNIX. Using binary mode to transfer files. Local directory now /media/FTP/run 250 OK. Current directory is /Cam local: Testupload remote: Testupload 227 Entering Passive Mode (178,254,10,134,255,136) 150 Accepted data connection 226-File successfully transferred 226 0.034 seconds (measured here), 1.49 Kbytes per second 52 bytes sent in 0.00 secs (130.5431 kB/s) 221-Goodbye. You uploaded 1 and downloaded 0 kbytes. 221 Logout. | Wenn auch dieser Sendevorgang fehlschlägt, bitte abbrechen und auf gar keinen Fall einfach mit dem nächsten Punkt weitermachen. Wenn hier ein Fehler vorliegt, muss dieser zuerst behoben werden. Die erste Maßnahme wäre, noch einmal die Zugangsdaten in der Conf zu vergleichen. Sind Schreibfehler enthalten? Eine Notlösung wäre auch, um erst mal weitermachen zu können, den Upload generell solange zu deaktivieren, bis der Fehler behoben ist. Dazu bitte prüfen, ob die Datei /media/FTP/run/upload.on existiert, wenn ja, diese dann nach upload.off umbennen. |
Sofern alle Tests erfolgreich verlaufen sind und keine offenkundigen Probleme oder Fehlermeldungen erkennbar waren, kann das Programm nun auf dem Cam-Server via root-Crontab gestartet werden. Die root-Crontab deshalb, damit es für alle Teil-Prozesse auch über entsprechende Berechtigungen verfügt. Ja, es ist durchaus auch denkbar, das Programm unter der UID eines unberechtigten virtuellen Users laufen zu lassen und die für alle Teilprozesse notwendigen Berechtigungen manuell anzupassen, damit das auch funktioniert. Aber wozu soll das gut sein? Auf meiner Cam-Server-VM gibts keine lokalen User-Anmeldungen, also auch keine User-Interaktionen, keine durch Anwender gestarteten Anwendungsprogramme, keine Zugriffe auf im LAN gespeicherte Dateien bzw. auf anwendereigene Dateien, kein Zugriff auf das System von außerhalb des LANs. Das System fungiert LAN-intern als dedizierter Server mit stark reduzierter Funktionalität... es laufen genau die Prozesse darauf, die für die Erfüllung seiner Aufgaben notwendig sind. Eigentlich ist es hier meiner Meinung nach also völlig egal, ob diese Prozesse mit root-Rechten oder unter der UID eines virtuellen Noname-Users laufen. Ich will's hingegen einfach haben, also verwende ich die root-Crontab:
# crontab -e
2 1 * * * /usr/local/bin/cam-event-ctl delete >/media/FTP/run/ispdelold.log
12 1 * * * /usr/local/bin/cam-event-ctl logrotate >>/media/FTP/run/backup.log
1 2 * * * /usr/local/bin/cam-event-ctl backup >>/media/FTP/run/backup.log
1 6 * * * /usr/local/bin/cam-event-ctl backup >>/media/FTP/run/backup.log
1 10 * * * /usr/local/bin/cam-event-ctl backup >>/media/FTP/run/backup.log
1 14 * * * /usr/local/bin/cam-event-ctl backup >>/media/FTP/run/backup.log
1 18 * * * /usr/local/bin/cam-event-ctl backup >>/media/FTP/run/backup.log
1 22 * * * /usr/local/bin/cam-event-ctl backup >>/media/FTP/run/backup.log
*/5 * * * * /usr/local/bin/cam-event-ctl alarm >>/media/FTP/run/alarm.log
Betrachten wir als nächstes kurz die Aufrufe und deren jeweilige Funktion:
TP 2 = alarm | Das Programm wird rund um die Uhr im 5-Minuten-Rhythmus gestartet und überprüft die FTP-Verzeichnisse darauf, ob in den letzten 5 Minuten neue Bilder angelegt wurden. Wenn ja, erfolgt die in TP 2 beschriebene Verarbeitung. |
TP 3 = backup | Das Programm legt im 4-Stunden-Rhythmus Backups an, in denen die Bilder der letzten 4 Stunden enthalten sind. Das Backup wird gemäß der Beschreibung in TP 3 mit einem sich täglich selbst überschreibenden Dateiname zum ISP-Web-Space hochgeladen. Die Startzeit ist 1 Minute nach der vollen Stunde festgelegt. Damit möchte ich sicherstellen, dass es keine Konflikte mit dem 5-Min-Alarm-Job gibt, der hier nie mehr als 15-20 Sekunden benötigt. |
TP 4 = delete | Löscht die veralteten Aufnahmen auf dem ISP-Web-Space gemäß der Paketliste von vorgestern. Job startet 1 Minute nach der vollen Stunde, um 01:01 Uhr ist das der einzige Prozess |
TP 5 = logrotate | Prüft ob die Frist für einen Log-Rotate abgelaufen ist. Die Startzeit ist wieder mit 1 Toleranz-Minute nach der vollen Stunde angelegt, um 03:01 Uhr ist das der einzige Prozess |
Jetzt fehlt nur noch eins, und zwar im Menüsystem (Web-GUI) der vorhandenen IP-Cams die LAN-interne IP-Adresse (in dieser Doku 10.0.1.42) unseres lokalen FTP-Servers einzutragen, dazu die Zugangsdaten mit Anmeldename (ftpd) und Password (toms_ftp_pwd) und das jeweilige Zielverzeichnis (z.B. 10_0_1_21), welches die Cam für ihre eigene IP-Adresse verwenden soll. Das wars.... Projekt beendet und alles in Betrieb genommen.
|
Die hier in den Beispielen der Dokumentation verwendeten IP-Adressen:
10.0.1.0 | IPv4 |
| Lokales LAN |
10.0.1.1 | IPv4 |
| Default-Gateway (DSL-Router) |
10.0.1.20, 10.0.1.21 und 10.0.1.22 | IPv4 |
| 3 IP-Kameras |
10.0.1.25 | IPv4 |
| Entwickler- bzw. Arbeits-PC |
10.0.1.42 | IPv4 |
| IP-Cam-FTP-Server |
|
Der Aufruf des Programms im Menü-Modus mit Dialog und die erlaubten Parameter im Work-Mode:
Aufruf: cam-event-ctl { alarm | backup | delete | smsbootinfo | logrotate | { ? | -help }
Mehrere Parameter bei Programmstart sind grundsätzlich nicht erlaubt. Für jeden Job-Lauf ist genau 1 Parameter zur Übergabe erlaubt, mehrere unterschiedliche Jobs werden jeweils einzeln und explizit mit dem passenden Parameter aufgerufen. Bei Aufruf ohne Parameter wird das Programm im Menü-Mode gestartet. Der Aufruf im Menü-Mode ist nicht für den Server selber vorgesehen, sondern nur zur Unterstützung für einfache Customizing-Zugriffe über das Netz.
Bei den von den IP-Cams innerhalb der vorgegebenen Bild-Prüfbereiche festgestellten Bewegungsalarmen werden pro Alarm die eingestellte Anzahl an Aufnahmen auf dem lokalen FTP-Server gespeichert. Weil der lokale FTP-Server die von den Cams übernommenen Aufnahmen jedoch nur auf einer virtuellen Fesplatte (also nur im RAM) speichert, sind die Aufnahmen deshalb flüchtig. Aus diesem Grund werden die Aufnahmen bei aktiven Alarm im 5-Min.-Rhythmus zusätzlich als AES-verschlüsseltes Tarfile auf einem externen FTP-Server gesichert.
Folgende Einstellung für den Alarm, zum Speichern und Löschen bereits hochgelandener Dateien sind möglich. Der „Schalter“ aktiviert oder deaktiviert die jeweilige Funktion: | |
 | Alarm-Aktiv = Prüft alle 5 Minuten auf neue, durch Bewegung ausgelöste Aufnahmen und überträgt die Bilder der letzten 6 Minuten als AES-verschlüsseltes Tar-File zum ISP-FTP-Server. SMS-Benachrichtigungen sind per Default immer aktiv!
Upload = Führt zur Sicherung von Dateien Uploads auf den angegebenen FTP-Web-Space durch, siehe Teilprozesse 2, 3 und 4. Zugangsdaten sind erforderlich: Hostname, Username, Password.
Send SMS = SMS-Benachrichtigung bei bzw. nach einem Bewegungsalaram.
SMS 12h Pause = SMS-Benachrichtigung bei aktiven Alarm vorübergehend (für max. 12 Stunden) deaktivieren. Nach 12 Stunden wird das SMS-Senden bei Bewegungsalarm automatisch wieder aufgenommen.
Send Nachricht = Telegram-Cli-Benachrichtigung bei bzw. nach einem Bewegungsalaram.
4h-Backups = Sichert im 4-Stunden-Rhythmus die Ereignisaufnahmen der letzten 4 Stunden zum ISP-FTP-Server, weiterhin lokale Dateien löschen, die im Moment älter als 12h sind.
ISP Delete = Alte Tar-File-Archive auf dem ISP-FTP-Server automatisch morgens um 1 Uhr löschen |
Datei entschlüsseln = Entschlüsselt und entpackt eine Archiv-Datei, die zuvor mit Hilfe eines FTP-Clients (z.B. Midnight Commander oder FileZilla) vom ISP-FTP-Server auf den lokalen PC runtergeladen werden muss. Die Bedienung des File-Dialogs ist ein wenig unkonventionell, aber dennoch hilfreich: Tab-Taste: Wechseln zwischen den Bereichen Leer-Taste: Datei oder Verzeichnis auswählen Enter-Taste: Auswahl bestätigen bzw. ausführen | |
|
Ein paar Überlegungen zur Sicherheit
Sicherheit...?... was kann man denn hier sichern? Tja, im Wesentlichen die Zugriffe auf die Server-Dienste und den Daten-Traffic über das Netzwerk-Interface. Insbesondere auch dann, wenn auch noch zum Internet geöffnete Ports betrieben werden und Weiterleitungen von Anfragen aus dem Internet an einen Server resp. dessen Services im eigenen Netzwerk eingestellt sind. Aber um die Frage wenigstens halbwegs sinnvoll zu beantworten, muss man sich zunächst ein paar Fakten bewusst machen, die dann vielleicht auch Einfluss auf die eigene Entscheidung haben können, Security-Features für notwendig oder für unnötig zu erachten.
Die Fakten:
1. Wir haben vier auf Anfragen über das Netz oder auf Events wartende Services eingerichtet, und zwar einen FTP-Server, einen Samba-Server, einen SMS-Server und einen Telegram-Server. Der Telegram-Server kommuniziert sogar direkt und permanent nach eigenem Ermessen mit dem Internet.
2. Bei einem DSL-Account mit Dual-Stack hat das System auch einen IPv6-Stack und somit (vermutlich) zwei öffentliche IPv6-Adressen.
3. Alle mir bekannten IP-Cams aus dem Consumer-Sektor haben bisher nur IPv4 unterstützt. Ob es bezahlbare IPv6-Cams gibt ist mir momentan nicht bekannt.
4. Das Mobil-Netz für Handys und Smartphones ist derzeit ebenfalls ein reines IPv4-Netz.
Das Fazit:
Meine abschließende Überlegung war, dass ich das ganze System ja primär nur für meine Abwesenheit von zuhause eingerichtet habe, also wenn ich von unterwegs und via Mobil-Netz nachsehen will, was die IP-Cams zuhause sehen oder gesehen haben. Und vor dem Hintergrund ist festzustellen: IPv4-Cams + IPv4-Mobilnetz + wenn-zuhause-anwesend-nur-Heartbeat-Funktionen = kein wirklicher Vorteil durch IPv6. Und weil die IPv6-Adressen auch noch Adressen mit dem Scope 'Global Unicast' sind, mit der der Client-PC resp. eine lokale Software direkt mit dem Internet kommunizieren könnte und vielleicht durch Ausnutzung eines Exploits sogar einen Reverse-Connect zu einem der lauschenden Services etablieren könnte, habe ich mich hier entschieden, IPv6 zu deaktivieren.
Außerdem habe ich mich entschlossen, mit dem Script /usr/local/bin/netfilter, welches über die Service-Unit netfilter.service gestartet wird, einen Paketfilter (so wie fast obligatorisch auf all unseren Systemen) zu installieren. Das hat nicht wirklich was mit der Prozess-Verarbeitung des Cam-Systems zu tun, sondern ist mit dem im Linux-Kernel integrierten Paketfilter ein reines Sicherheitsfeature, um den Datenverkehr über das Network-Interface rein und raus ein wenig zu regulieren. Über das Script "netfilter" wird bei Systemstart ein Paketfilter als Stateful Firewall mit bestimmten Eigenschaften eingerichtet. Wer sich für weitergehende Infos zum Thema Firewall resp. Paketfilter interessiert, findest das in meinem Artikel < security > umfassend beschrieben.
Ich denke, in einem gut konfigurierten Netzwerk, mit einem ordentlich eingestellten DSL-Router und weil der Cam-Server hier eh nur als LAN-Client in einer dedizierten VM läuft und keine Zugriffe aus dem Internet erlaubt, ist das durchaus auch verzichtbar. Ich hab's trotzdem gemacht, weil's geht.... weil‘s nicht stört.... und wenn es hilft, ist's auch gut... aber den Sinn hierbei wirklich beweisen kann ich eben auch nicht.
Wer den Paketfilter zur Verbesserung der Systemsicherheit aktivieren möchte, kann das natürlich gerne tun. Dazu sind im Script nur die Ports auf die eigenen Gegebenheiten mit den lokal verwendeten eigenen Ports anzupassen:
# dpkg -l nftables # apt install nftables # ne /usr/local/bin/netfilter nft add rule ip filter input tcp dport 55551 ip saddr $ipv4_prefix accept nft add rule ip filter input tcp dport 55555 ip saddr 127.0.0.0/8 accept nft add rule ip filter output tcp dport 55555 accept # systemctl start netfilter.service # systemctl enable netfilter.service | Zuerst kontrollieren, ob das Paket für das Frontend im Userspace installiert ist, wenn nicht, bitte installieren. Hier in dieser Dokumentation ist der Port 55551 für den SSH-Zugang 55555 für das Telegram-Cli vorgesehen. Aber bitte nicht vergessen: Wer das Telegram-Cli nicht im Daemon-Modus laufen lässt, muss auch keinen Port Port freigeben. |
Ausführliche Informationen über Sicherheit und Möglichkeiten, wenn man sich ggf. von außerhalb über das Internet ins heimische Netzwerk verbinden möchte, ist in den Artikeln < security > und < openvpn > enthalten.
Nachtrag:
Speziell diesen Punkt "Sicherheit" angehend habe ich am 11. und 12. August 2019 äußerst unangenehme neue Erkenntnisse gewonnen. Obwohl mein Netzwerk nur ein kleines privates Netzwerk ist, obwohl ich keine öffentlichen Dienste anbiete und im DSL-Router den TCP-Port 443 ausschließlich zur privaten Nutzung geöffnet habe und obwohl mein DSL-Account täglich noch zwangsgetrennt wird und ich täglich eine neue öffentliche IPv4 erhalte, war mein Server trotzdem Opfer einer massiven Attacke über mehr als 29 Stunden lang.
Weil meine Logs einem mengenbasierten Log-Rotate unterliegen, muss ich sogar davon ausgehen, dass die tatsächliche Dauer der Attacke noch länger war und das frühere Sätze jetzt nicht mehr sichtbar sind... aber das jetzt noch sichtbare reicht völlig aus, um erst mal geschockt zu reagieren. Dabei will ich gerne glauben, dass mein Netz nur ein zufälliges Ziel war und nicht explizit ausgewählt wurde. Allerdings war das eine geradezu konzertierte Aktion, gleichzeitig ausgehend von mehreren unterschiedlichen IP-Adressen. Also jeder, der leichtfertig darüber nachdenkt, irgendwelche Ports in sein Heimnetzwerk zu öffnen, um komfortabel aus dem Internet heraus auf seine Hausautomatisierung zuzugreifen, sollte sich das besser dreimal überlegen. Mittlerweile sage ich sogar ganz unverblümt, nur Dummheit öffnet ungesicherte und nicht-überwachte Ports in das private Netzwerk und verwendet gleichzeitig auch noch Client- oder Server-Software aus anonymen Quellen, oder betreibt Netzwerkslösungen, die er nicht versteht und kontrollieren kann, oder lädt unverschlüsselte Daten auf proprietäre Clouds hoch, aus denen dann Rückschlüsse auf private Lebensumstände gewonnen werden können. Das sind meine Logs aus dem Zeitraum: 11.08.2019 und 12.08.2019... die allemal Anlass sein sollten, alle eigenen Aktionen sorgfältig zu hinterfragen und auf einen Security-Prüfstand zu stellen. |  |
|
Die von mir geschriebenen Programme im Paket cam-event-ctl sind als Bash-Scripte immer nur Wrapper für verschiedene Linux-Programme. Die Programme selber verändern nicht das installierte Betriebssystem an sich, schreiben aber journald-Einträge, eigene Log-Dateien und erstellen ggf. temporäre Dateien in /tmp und dem run-Dir im FTP-Pfad des Hauptprogramms.
Ich erhebe keinen Anspruch darauf, dass die Programme im Paket cam-event-ctl vollständig fehlerfrei programmiert sind und ich behaupte das auch nicht. Sowohl durch Programmierfehler in meinen Code, wie auch durch vorhandene Fehler in den von den Programmen verwendeten Linux-Programmen, sowie durch ggf. zeitgleich auftretende äußere mechanische Einflüsse, wie auch durch den Anwender selber verursacht durch Änderungen am Programm oder durch unsachgemäße oder fehlerhafte Bedienung eines Programms oder falsche Parameterübergaben beim Aufruf des Programms ist Datenverlust möglich, wenn das laufende Programm wegen solcherart unsachgemäßer Manipulation nicht mehr Bestimmungsgemäß arbeitet.
Deshalb schließe ich jede Haftung für Schäden an Software oder Hardware oder Vermögensschäden oder für Datenverlust aus, die durch die Benutzung der Programme im Paket cam-event-ctl enstehen. Die Benutzung der Programme erfolgt auf eigenes Risiko.
|
Datum Änderung
22.08.2019 | Harmonisierung der in den Beispielen verwendeten IP-Adressen in den Artikeln security, openvpn, cameventctl zur Verbesserung der Zusammenhang-Darstellung. |
26.12.2019 | /usr/local/bin/cam-event-ctl - Verschlüsselung von openssl aes-128-cbc/md5 auf gpg aes256/sha256 geändert - Debug-Ausgabe für Parameter (conf-file-parser) in Funktion verlegt - Bugfixes - Redaktionelle Änderungen im Code |
| /usr/local/bin/netfilter überarbeitet |
| /etc/systemd/system/netfilter.service überarbeitet |
| /etc/sysctl.d/sysctl_ipv6_ftps.conf in Download-Archiv übernommen |
29.06.2020 | Bugfix: Parameterfehler (find) in Funktion logrotate behoben |
