FHEM Forum

FHEM - Hausautomations-Systeme => Sonstige Systeme => Thema gestartet von: CoolTux am 11 Mai 2018, 14:24:16

Titel: Neues Modul apt-get Infos
Beitrag von: CoolTux am 11 Mai 2018, 14:24:16
Lasst das Bild mal auf Euch wirken und schreibt mir ein Kommentar wenn es Euer Interesse geweckt hat.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: betateilchen am 11 Mai 2018, 15:26:11
Braucht kein Mensch und hat nix mit FHEM zu tun. apt ist für die Betriebssystemebene wichtig und man muss nicht jeden Scheiß in FHEM abbilden.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: the ratman am 11 Mai 2018, 15:36:26
also so ein kleiner hinweis, mal wieder auf meinem ungeliebten Linux aufzuschlagen und das ding upzudaten wäre eventuell gar ned so blöd ... könnte ich dann ja sogar automatisieren ... cooltux's modul sagt mir, dass es was neues gibt und schon wird upgedatet per fhem.
und betateilchen: sag jetzt nix. ich würde sowieso nicht wissen, was nun an welchen updates wichtig/unwichtig/lieber nicht zu installieren wäre. so gesehen würde mir Linux-noob also nur der Handgriff zur fernwartung erspart bleiben und sich an dem rest der situation nix ändern.

die ganzen anderen Infos sind mir aber egal - wo das zeug gesaugt wird oder so - who (ausser natürlich pinguine) cares?
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 11 Mai 2018, 16:32:15
Zitat von: betateilchen am 11 Mai 2018, 15:26:11
Braucht kein Mensch und hat nix mit FHEM zu tun. apt ist für die Betriebssystemebene wichtig und man muss nicht jeden Scheiß in FHEM abbilden.

Das Modul entstand aus eigenem Bedarf heraus. Also einer brauchte es schon mal.
Ich hatte keine Lust täglich zu schauen ob updates anliegen und wenn ja welche. Das Modul soll mir eine Übersicht über meine Pi's geben. Später können Updates auch über FHEM raus angeschupst werden. Ich habe nur FHEM als Übersicht und für Eventhandling, daher bietet es sich, zu mindest bei mir, an.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: Frank_Huber am 11 Mai 2018, 16:56:59
Zitat von: betateilchen am 11 Mai 2018, 15:26:11
Braucht kein Mensch und hat nix mit FHEM zu tun. apt ist für die Betriebssystemebene wichtig und man muss nicht jeden Scheiß in FHEM abbilden.
IMHO:
Wenn das so ist könnte man auch über das viel genutzte SYSMON Modul diskuttieren. Das hat ja mit FHEM auch nichts zu tun.
So wie mich Sysmon informieren kann wenn die SD Karte voll wird kann das neue modul von Leon über Updates informieren.

Braucht vielleicht nicht jeder, ich finds aber aber auch praktisch. :-)
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: rischbiter123 am 11 Mai 2018, 19:59:06
Sieht für mich auch interessant aus. Und wenn mich nicht alles täuscht, wird bei Problemen auch schon mal nach der Pi-Konfiguration gefragt.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 12 Mai 2018, 19:03:39
Habe mal einen neuen Screenshot im ersten Post rangehangen. Man sieht schon mal wo es hingehen soll.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: Helmi55 am 12 Mai 2018, 22:00:07
Ich finde es sehr gut
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 12 Mai 2018, 22:32:46
Ich habe 3+1 Rpi sowie 4 RPi-Zero. Hinzu kommen 3 APU. Ich bin gerade an der konzeptionellen Vorüberlegung, was jedes System nach außen darstellen soll (wie viele Updates vorhanden, Name, BS-Version, Speicher). Dabei gehe ich davon aus, dass der Abruf von einer zentralen Instanz (FHEM) nur selten (1x täglich) erfolgen sollte.

Was Du da treibst, verstehe ich leider nicht genau: Überwachst Du mehrere entfernte RPi? Die müssten ja eigentlich aktiv etwas dazu beitragen - wie löst Du das?

Vor allem: Kann man sich das Modul denn mal ansehen, testen, ...?
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 12 Mai 2018, 23:11:12
Zitat von: curt am 12 Mai 2018, 22:32:46
Ich habe 3+1 Rpi sowie 4 RPi-Zero. Hinzu kommen 3 APU. Ich bin gerade an der konzeptionellen Vorüberlegung, was jedes System nach außen darstellen soll (wie viele Updates vorhanden, Name, BS-Version, Speicher). Dabei gehe ich davon aus, dass der Abruf von einer zentralen Instanz (FHEM) nur selten (1x täglich) erfolgen sollte.

Was Du da treibst, verstehe ich leider nicht genau: Überwachst Du mehrere entfernte RPi? Die müssten ja eigentlich aktiv etwas dazu beitragen - wie löst Du das?

Vor allem: Kann man sich das Modul denn mal ansehen, testen, ...?

Das Modul ist noch pre alpha, aktuell wird alle 4 Stunden ein apt-get update ausgeführt und somit die Repositorylist aktualisiert. Danach wird ein simuliertes apt-get upgrade gemacht um die update Packetliste zu erhalten.
Das ganze geht momentan nur mit dem lokalen System, soll aber später per passwortlosen SSH Zugang auch entfernte Systeme abrufen können. Ohne aktiven Eingriff der Systeme selbst.
Das 4 Stunden Interval wird dann noch auf täglich geändert.

Das Modul selber muss erst noch ein paar Wochen laufen und ich muss noch viel Fehlertests durchführen damit mögliche Fehler vernünftig abgefangen werden können. Es dauert also noch etwas.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: gbomacfly am 12 Mai 2018, 23:35:34
Coole Sache, gefällt mir gut!  :)
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 12 Mai 2018, 23:40:15
Zitat von: CoolTux am 12 Mai 2018, 23:11:12
Das ganze geht momentan nur mit dem lokalen System, soll aber später per passwortlosen SSH Zugang auch entfernte Systeme abrufen können. Ohne aktiven Eingriff der Systeme selbst.
Ich habe für entfernte Systeme einen anderen Ansatz. In einigen Tagen kann ich den gern hier zur Diskussion stellen. Vielleicht ist das sinnvoll integrierbar.

Weiterhin wäre zu überlegen, ob die Devices selbst - über das nmap-Modul erzeugt werden - wir waren dort so weit, dass bei aktiv erkannter IP ein Device zur IP erzeugt wird. Auch das könnte ich liefern.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 13 Mai 2018, 07:31:32
Zitat von: curt am 12 Mai 2018, 23:40:15
Ich habe für entfernte Systeme einen anderen Ansatz. In einigen Tagen kann ich den gern hier zur Diskussion stellen. Vielleicht ist das sinnvoll integrierbar.

Weiterhin wäre zu überlegen, ob die Devices selbst - über das nmap-Modul erzeugt werden - wir waren dort so weit, dass bei aktiv erkannter IP ein Device zur IP erzeugt wird. Auch das könnte ich liefern.

Klingt interessant. Bin gespannt drauf.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: Spezialtrick am 13 Mai 2018, 11:34:32
Ich finde das Modul super! Gerade, wenn man mehrere Raspberrys im Haushalt bereit, kann diese Modul viel Zeit bei regelmäßigen Updates sparen. :)
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 14 Mai 2018, 00:23:50
Zitat von: CoolTux am 13 Mai 2018, 07:31:32
Zitat
Ich habe für entfernte Systeme einen anderen Ansatz. In einigen Tagen kann ich den gern hier zur Diskussion stellen. Vielleicht ist das sinnvoll integrierbar.

Weiterhin wäre zu überlegen, ob die Devices selbst - über das nmap-Modul erzeugt werden - wir waren dort so weit, dass bei aktiv erkannter IP ein Device zur IP erzeugt wird. Auch das könnte ich liefern.

Klingt interessant. Bin gespannt drauf.

Wie gesagt - in einigen Tagen: Ich muss noch mehrere Sachen testen. Und ich habe auch gewisse Sorge, mich zu blamieren, meine Erfahrungen mit Modul-Entwicklern sind nicht uneingeschränkt gut.

Vielleicht könnten wir die Ansätze aber schon jetzt theoretisch diskutieren. Daher vorab eine Erklärung:
Ich suche, möchte ein kleines Überwachungssystem für meinen Zoo von Servern. Nagios, Sysmon usw. sind zu groß, zu mächtig. Das ist hier kein Hochsicherheitsrechenzentrum mit Spiegel und Neun-Neuner Verfügbarkeit. Sondern Hobby.

Zielbeschreibung also:
Für einen Zoo von 8..10 (später vermutlich mehr) Linux-like Systemen möchte ich wenige Dinge wissen: Muss ich updaten? Ist es zu heiß? Läuft eine "Platte" voll? Das Ganze soll nicht Echtzeit sein, einmal täglich ist fast schon zu viel.

Im Einzelnen:
2) Das nmap-Modul haben wir (der Modul-Coder und zwei Leute) soweit aufgebohrt, dass für alle in definierten private-Subnetzen auftauchende IP ein device (derzeit als dummy) angelegt wird. Damit wurde das erstmal abgebrochen. Das ist vorhanden und kann ich Dir gern zeigen.

Dazu folgende Probleme:
* Mir ist momentan nicht klar, ob das auch schon die Möglichkeit hergibt, Attribute gleich mit zu erzeugen.
* IP können auch wieder verschwinden - keine Lösung für dieses Teilproblem.
* Ich arbeite bei Servern (RPi als Server!) mit statischen IP. Bei Servern mit dynamischen IP geht der Ansatz schief. Bzw: Dafür habe ich keine Lösung.
* im Heimnetz auftauchende IP können aber auch iPhone oder Android sein. Da würde die Kopplung nmap->device->Infos natürlich schief gehen. Das nmap-Modul gibt zwar die grundsätzliche Möglichkeit, Betriebssysteme zu erkennen, diese Info könnte man als Weiche nutzen. Leider geht das sofort schief, wenn da ein Switch mit mehreren Class-C-Netzen im Spiel ist: Die Betriebssysteme in weiteren Subnetzen werden definitionsgemäß nicht erkannt.

1) Wie Informationen von entfernten Systemen holen?
Dein Ansatz ist, via passwordlosem SSH die Infos von den entfernten Systemen zu holen. Ja, kann man natürlich machen.

Ich selbst möchte das ablehnen, ich sehe da zwei Schwachstellen/Probleme:
a) Da ich aus der Sicherheitsecke komme: Ich halte automatisiertes SSH mit Certs für Teufelszeug. Wenn der Host (FHEM) komprimiert wird, sind sofort auch alle Sub-Systeme komprimiert.
b) Du läufst, egal wie Du das anstellst, in ein FHEM-blocking-Problem: apt update dauert halt.

Mein Ansatz setzt anders an, mit allerdings genau den gleichen Befehlen:
Alle Infos eines entfernten Servers werden von diesem automatisiert als CSV-Datei bereitgestellt. Das hat den Vorteil, dass kein Fremder auf die Maschine muss. Nachteile hat es auch:
a) mindestens zwei Dateien auf jedem entfernten System
b) Webserver auf jedem entfernten System

Dein sowie mein Ansatz wären in Deinem angedachten Modul durchaus kombinierbar. Klar.

Das war meine theoretische Vorbetrachtung - gern zur Diskussion.

(nmap-Beispiel sowie Beispiel für Scripts auf externen Maschinen würde ich in einigen Tagen liefern wollen, wie gesagt.)
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: knopf_piano am 14 Mai 2018, 06:43:49
Da fällt mir folgendes ein: Bei Verwendung von Modulen müssen einige libs mit [... wer weiß es?...richtig apt] installiert werden. Kann man damit irgendwlche deps auflösen?

Da würde dann aus dem im obigen post abfällig betitelten "Scheiß" ein usecase.

Ich finde jede Idee gut,  diese auch. Der eine hat Verwendung, der andere nicht.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 14 Mai 2018, 07:11:20
Zitat von: knopf_piano am 14 Mai 2018, 06:43:49
Da fällt mir folgendes ein: Bei Verwendung von Modulen müssen einige libs mit [... wer weiß es?...richtig apt] installiert werden. Kann man damit irgendwlche deps auflösen?

Da würde dann aus dem im obigen post abfällig betitelten "Scheiß" ein usecase.

Ich finde jede Idee gut,  diese auch. Der eine hat Verwendung, der andere nicht.

Prinzipiell wäre es möglich. Aber nicht so gedacht.
Die Idee kam mir eher bei dem Gedanken an ein sauberes Patchmanagement. Nun gibt es unter Debian kein wirkliches patchen und selbst bei Ubuntu ist das eher ein Gedanke. Da kann man nach Security filtern. Aber einfach mal zu wissen ob Updates anstehen und wenn ja welche finde ich selbst schon Interessant. Ich habe 5 Raspberry Pis und da ist bisschen Übersicht ohne viel Aufwand schon eine Erleichterung.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: ToM_ToM am 14 Mai 2018, 07:20:58
Also ich bräuchte es nicht zwangsläufig, finde es aber dennoch sehr interessant. Und wer es nicht braucht, muss es ja nicht einbinden und somit wird es auch nicht geladen.
Wenn man mit etwas bestimmtem Problem hat, könnte man sich so ein notify basteln dass man eine Nachricht bekommt, sobald es eine neue Version gibt. Von dem Aspekt her irgendwie cool. :)
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: Ranseyer am 14 Mai 2018, 07:40:00
90% aller Module sind unnötig. Aber das ist nur meine Meinung in Bezug auf meine Umgebung. Trotzdem habe ich nicht das Recht diese nieder zu machen.

Dieses Modul sichert nicht mein Überleben. Trotzdem werde ich es einsetzen.


Danke an jeden der etwas teilt.
(selbst an die Macher des hässlichen Grafikprogramms GIMP)

Gesendet von meinem VTR-L09 mit Tapatalk

Titel: Antw:Neues Modul apt-get Infos
Beitrag von: the ratman am 14 Mai 2018, 09:04:45
hihi,
ich wollts am anfang schon schreiben, was knopf_piano andeutet.
nämlich ein noob-gerechtes "installieren" von modulen. der dümmste hund hätte - würde sich dieses modul dann drum kümmern - alles installiert, was installiert sein muß, damit ein anderes modul auch 100% sicher alles nötige an der hand hat zum funzen. man müßte ja nur - nen z.b. txt mitliefern mit seinem modul, dass dieses modul dann auslesen könnte, indem drinnen steht, was zu installieren wäre.
das gäbe in folge dann sicherlich wiederum nen haufen anfänger/dumme fragen weniger im forum, über die sich manch linuxpro ja so gerne beschwert *bg*

@Ranseyer
confirm - würde sogar sagen, dass es gar keine dummen module gibt. irgendeiner hats ja gebraucht, sonst hätte er sichs nicht gebastelt. wenns sonst keiner braucht, dann ists eben sehr speziell ...
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 14 Mai 2018, 10:05:13
Zitat von: curt am 14 Mai 2018, 00:23:50
Zielbeschreibung also:
Für einen Zoo von 8..10 (später vermutlich mehr) Linux-like Systemen möchte ich wenige Dinge wissen: Muss ich updaten? Ist es zu heiß? Läuft eine "Platte" voll? Das Ganze soll nicht Echtzeit sein, einmal täglich ist fast schon zu viel.

Selbige Ansprüche woraus sich meine Arbeit an dem Modul ergab  :)



Zitat von: curt am 14 Mai 2018, 00:23:50
Im Einzelnen:
2) Das nmap-Modul haben wir (der Modul-Coder und zwei Leute) soweit aufgebohrt, dass für alle in definierten private-Subnetzen auftauchende IP ein device (derzeit als dummy) angelegt wird. Damit wurde das erstmal abgebrochen. Das ist vorhanden und kann ich Dir gern zeigen.

Dazu folgende Probleme:
* Mir ist momentan nicht klar, ob das auch schon die Möglichkeit hergibt, Attribute gleich mit zu erzeugen.
* IP können auch wieder verschwinden - keine Lösung für dieses Teilproblem.
* Ich arbeite bei Servern (RPi als Server!) mit statischen IP. Bei Servern mit dynamischen IP geht der Ansatz schief. Bzw: Dafür habe ich keine Lösung.
* im Heimnetz auftauchende IP können aber auch iPhone oder Android sein. Da würde die Kopplung nmap->device->Infos natürlich schief gehen. Das nmap-Modul gibt zwar die grundsätzliche Möglichkeit, Betriebssysteme zu erkennen, diese Info könnte man als Weiche nutzen. Leider geht das sofort schief, wenn da ein Switch mit mehreren Class-C-Netzen im Spiel ist: Die Betriebssysteme in weiteren Subnetzen werden definitionsgemäß nicht erkannt.

Ich muss gestehen das das noch eine Menge Probleme sind und ob es wirklich Sinn macht alle gefundenen an zu legen wage ich zu bezweifeln. ( Wie Du ja schon selber festgestellt hast)
Hier sollte man lieber eine Liste der gefundenen zur Auswahl an anbieten .
Bleibt noch die Sache mit den wechselnen IP Adressen. Hier kann man sich einen Eindeutigen Marker ins Device setzen. Also nicht die IP, sondern die MAC Adresse. Man wertet dann die MAC Adresse aus worauf das FHEM Device identifizieren werden kann und schaut ob die IP noch stimmt, wenn nicht wird die IP einfach geändert.



Zitat von: curt am 14 Mai 2018, 00:23:50
1) Wie Informationen von entfernten Systemen holen?
Dein Ansatz ist, via passwordlosem SSH die Infos von den entfernten Systemen zu holen. Ja, kann man natürlich machen.

Ich selbst möchte das ablehnen, ich sehe da zwei Schwachstellen/Probleme:
a) Da ich aus der Sicherheitsecke komme: Ich halte automatisiertes SSH mit Certs für Teufelszeug. Wenn der Host (FHEM) komprimiert wird, sind sofort auch alle Sub-Systeme komprimiert.
b) Du läufst, egal wie Du das anstellst, in ein FHEM-blocking-Problem: apt update dauert halt.

Mein Ansatz setzt anders an, mit allerdings genau den gleichen Befehlen:
Alle Infos eines entfernten Servers werden von diesem automatisiert als CSV-Datei bereitgestellt. Das hat den Vorteil, dass kein Fremder auf die Maschine muss. Nachteile hat es auch:
a) mindestens zwei Dateien auf jedem entfernten System
b) Webserver auf jedem entfernten System

Das Problem zum Thema "selbst ablehnen" ist das man nicht nur an sich sondern auch an die anderen Denken muss. Es gibt sehr sehr viele hier im Forum die einen Raspi und somit Linux nur haben weil die FHEM Installationsanweisung in einem Blog es mal so geschrieben hat, naja und weil FHEM eigentlich auch unter Linux entstand.
Die Leute wollen es also "Einfach". Ich selbst sträube mich weitere Perl Module zu installieren solange es nicht für eine Funktionalität nötig ist. Ich mag es aber nicht. Andere wollen es nicht weil sie immer wieder dabei auf Probleme stoßen.
Genau so ist es mit irgendwelchen anderen Konfigurationen. Eine CSV Datei anlegen lassen (welcher Prozess soll das tun) dann noch einen Webservice bereit stellen. Das ist für sehr viele Leute schon zu viel Aufwand.
Die SSH Verbindung gibt es bereits, man muss sie nur noch Passwortlos machen. Und was Thema Sicherheit an geht, nun ja es sollte jeden der Ahnung hat von Debian oder Ubuntu klar sein das FHEM nicht ohne weiteres ein atp-get machen kann. Hierzu muss man dem User fhem explizit über sudo root Rechte für apt-get geben und zwar ohne Passwort Eingabe. Es ist also schon sehr sehr aufgeweicht und ich würde niemanden mit externen Zugriff auf die FHEM Instanz empfehlen das Modul zu benutzen es sei denn er weiß was er tut.

Noch kurz zum blocking von FHEM. Jede Funktion welche Ausführung etwas länger dauert blockiert FHEM, dafür wurden schon vor Ewigkeiten entsprechende Hilfsmittel geschaffen. Ich gehe davon aus das selbst das nmap Modul nonBlocking arbeitet. Kann mich jedenfalls erinnern das am Anfang der Entwicklung des Modules es recht schnell umgebaut wurde auf nonBlocking.

Im großen und ganzen, Du merkst es sicherlich, bin ich aktuell nicht positiv geneigt zu Deinen SSH Ersatzgedanken.
Die Ideen rund um das nmap Modul finde ich aber gut und habe große Hochachtung vor Eurer gemeinschaftlichen Arbeit.




Grüße
Leon
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 15 Mai 2018, 00:20:09
Ich möchte im Moment nur auf einige angesprochenen Punkte eingehen.

Zitat von: CoolTux am 14 Mai 2018, 10:05:13
Bleibt noch die Sache mit den wechselnen IP Adressen. Hier kann man sich einen Eindeutigen Marker ins Device setzen. Also nicht die IP, sondern die MAC Adresse.

Das ist leider auch nicht die Lösung. Wenn (wie bei mir) verschiedene Subnetze im Spiel sind, kommt die MAC nicht mit.

Zitat von: CoolTux am 14 Mai 2018, 10:05:13
Das Problem zum Thema "selbst ablehnen" ist das man nicht nur an sich sondern auch an die anderen Denken muss. Es gibt sehr sehr viele hier im Forum die einen Raspi und somit Linux nur haben weil die FHEM Installationsanweisung in einem Blog es mal so geschrieben hat, naja und weil FHEM eigentlich auch unter Linux entstand. Die Leute wollen es also "Einfach".

Das ist mir völlig klar. Es wird auch einfach - nur: Gib mir bitte noch einige Tage.

Zitat von: CoolTux am 14 Mai 2018, 10:05:13
Eine CSV Datei anlegen lassen (welcher Prozess soll das tun) dann noch einen Webservice bereit stellen. Das ist für sehr viele Leute schon zu viel Aufwand.

Es wird ganz einfach. Es werden nur zwei Dateien - dann tut es selbst.

Zitat von: CoolTux am 14 Mai 2018, 10:05:13
Die SSH Verbindung gibt es bereits, man muss sie nur noch Passwortlos machen.

Hatte ich nicht grad im Ohr, dass viele Nutzer nur "ganz einfach" können? <lacht>

Zitat von: CoolTux am 14 Mai 2018, 10:05:13
Es ist also schon sehr sehr aufgeweicht und ich würde niemanden mit externen Zugriff auf die FHEM Instanz empfehlen das Modul zu benutzen es sei denn er weiß was er tut.

Wie gesagt: ich halte ssh in dieser Konstellation für Teufelszeug. Ich bestehe andererseits gar nicht auf Webserver - fest steht lediglich, dass die Daten auf den Zielsystemen zu ermitteln sind und irgendwie zu FHEM müssen. Und für "irgendwie" gibt es viele denkbare Wege.

Zitat von: CoolTux am 14 Mai 2018, 10:05:13
Im großen und ganzen, Du merkst es sicherlich, bin ich aktuell nicht positiv geneigt zu Deinen SSH Ersatzgedanken.

Wenn ich fertig bin, habe ich lediglich die Bitte, dass Du Dir das Ganze neutral ansiehst. Und dann mit mir (ggf weiteren) darüber diskutiert. (Auf alle Fälle fallen bei der Gelegenheit Code-Vorschläge ab, die Du auch nutzen kannst.)

Zitat von: CoolTux am 14 Mai 2018, 10:05:13
Die Ideen rund um das nmap Modul finde ich aber gut und habe große Hochachtung vor Eurer gemeinschaftlichen Arbeit.

Auch das würde ich in einigen Tagen vorstellen. Das war im Grunde eine gedankliche Vorarbeit - für genau das, was Du grad angehst. - Die offene Frage ist, ob wirklich so viele Leute Server mit dynamischen Intranet-Adressen nutzen. Oder ob wir die Leute nur für zu doof halten in unserer Überheblichkeit. Und ob Leute mit Servern mit dynamischen Adressen überhaupt Zielgruppe für das Modul sind.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 15 Mai 2018, 01:37:19
Zitat von: knopf_piano am 14 Mai 2018, 06:43:49
Da fällt mir folgendes ein: Bei Verwendung von Modulen müssen einige libs mit [... wer weiß es?...richtig apt] installiert werden. Kann man damit irgendwlche deps auflösen?

Ich habe erstmal überlegt, was Du überhaupt sagen willst. Ich glaube, ich habe nun verstanden.

Nein, das ist ein unrealistischer Ansatz für das angedachte neue Modul. Das Modul soll UPDATES für bisher installierte Linux-Pakete zeigen. Darüber hinaus soll das angedachte Modul einige grundlegende Fakten über den jeweiligen entfernten Server mitteilen.

Für Deinen Denkansatz (fehlende Pakete für FHEM-Module automatisiert installieren) sehe ich leider keinen technisch möglichen Weg.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: supernova1963 am 15 Mai 2018, 06:14:30
Hallo CoolTux,

meiner Ansicht nach für mich interessante Informationen.

@curt: Dein Ansatz, dass der Server die Informationen zur Verfügung stellt, und nicht per telnet, ssh, usw. zugegriffen wird, finde ich gut. Besser als csv per http/ftp fände ich persönlich json an MQTT Server.

Ich bin gespannt, wie es sich weiterentwickelt,

Gernot
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 15 Mai 2018, 06:28:54
Zitat von: supernova1963 am 15 Mai 2018, 06:14:30
@curt: Dein Ansatz, dass der Server die Informationen zur Verfügung stellt, und nicht per telnet, ssh, usw. zugegriffen wird, finde ich gut.

Ich kann da immer wieder nur um Geduld bitten:
Ich habe meine aktuelle (unfertige) Version jetzt auf sieben Servern. Ich will erstmal sehen, wie das "in the wild" funktioniert - aber das passiert dort konzeptgemäß nur einmal am Tag. Ist ja "in the wild".

Zitat von: supernova1963 am 15 Mai 2018, 06:14:30
Besser als csv per http/ftp fände ich persönlich json an MQTT Server.

Wir müssen das gedanklich völlig trennen. Sonst verrennen wir uns. Dann wird das nie.

Aus meiner Sicht
No 1 ist: Jeder Server hat (in einer lokalen Datei bei sich) zu liefern. Da bin ich dran.

No 2 ist: Die Daten der verschiedenen Server müssen halt irgendwie zum FHEM-Server. Wie das passiert, ist im Moment völlig offen. @CoolTux findet ssh wunderfein, ich finde das Teufelsezug. Mir schwebt http vor, das findet CoolTux Teufelszeug. Du schlägst nun MQTT vor - von dem ich nur ansatzweise hörte. - Ok, das stellen wir zurück.

No 3 ist: Bezogen auf FHEM ist das völlig automatisierbar - unter der Nebenbedingung, dass die zu überwachenden Server respektive "Server" statische IPv4-Adressen haben. Dafür gibt es eine Vorarbeit: Eine neu auftauchende IP wird automatisiert sofort zu einer device.

Ja, wir stehen völlig am Anfang.
Ich hoffe, dass alle (die ja alle verschiedene Ziele haben) zu einem Konsens finden. Sicher ist das aber nicht.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: Eisix am 15 Mai 2018, 08:18:03
Hallo,

bin  so frei und werfe auch mal meine Gedanken hier rein.

Habe das ganze verfolgt und wollte erst ein paar Tips schreiben wie man es realisieren könnte dann ist mir aber aufgefallen das hier gerade das Rad wieder neu erfunden wird (nicht das ich was gegen neue Räder hätte).

Ich denke das SNMP alle euere Anforderungen erfüllt. Außerdem deckt es alle Betriebsysteme und Netzwerkkomponenten ab. Es gibt verschiedene Zugriffsrechte über Communitys und User.
Das Modul SYSSTAT nutzt auch teilweise SNMP. Denke aber ein generisches Modul das SNMP abfragt ist der bessere Ansatz oder ein aufgebohrtes SYSSTAT.

http://lab4.org/wiki/SNMP-Daemon_einrichten
https://wiki.fhem.de/wiki/Raspberry_Pi_/_Rasbian_und_SNMP

Gruß
Eisix

Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 15 Mai 2018, 09:51:20
Zitat von: Eisix am 15 Mai 2018, 08:18:03
Hallo,

bin  so frei und werfe auch mal meine Gedanken hier rein.

Habe das ganze verfolgt und wollte erst ein paar Tips schreiben wie man es realisieren könnte dann ist mir aber aufgefallen das hier gerade das Rad wieder neu erfunden wird (nicht das ich was gegen neue Räder hätte).

Ich denke das SNMP alle euere Anforderungen erfüllt. Außerdem deckt es alle Betriebsysteme und Netzwerkkomponenten ab. Es gibt verschiedene Zugriffsrechte über Communitys und User.
Das Modul SYSSTAT nutzt auch teilweise SNMP. Denke aber ein generisches Modul das SNMP abfragt ist der bessere Ansatz oder ein aufgebohrtes SYSSTAT.

http://lab4.org/wiki/SNMP-Daemon_einrichten
https://wiki.fhem.de/wiki/Raspberry_Pi_/_Rasbian_und_SNMP

Gruß
Eisix

Habe mal auf die schnelle gesucht aber so richtig will ich nicht finden wie SNMP mir Update Status geben kann und informationen zu den Packete welche upgedatet werden sollen. Sorry
Hast Du da einen Link für mich?
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: Eisix am 15 Mai 2018, 10:02:40
Hallo,

der eigentliche update Status ist in den MIBs für Linux nicht drin
http://www.mibdepot.com/cgi-bin/vendor_index.cgi?r=linux

Aber du kannst eigene OIDs über Scripte füllen
http://www.net-snmp.org/docs/man/snmpd.conf.html

Dort würde dann eventuell dein Code den du schon geschrieben hast passen.

Gruß
Eisix
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 15 Mai 2018, 10:07:06
Zitat von: Eisix am 15 Mai 2018, 10:02:40
Hallo,

der eigentliche update Status ist in den MIBs für Linux nicht drin
http://www.mibdepot.com/cgi-bin/vendor_index.cgi?r=linux

Aber du kannst eigene OIDs über Scripte füllen
http://www.net-snmp.org/docs/man/snmpd.conf.html

Dort würde dann eventuell dein Code den du schon geschrieben hast passen.

Gruß
Eisix

Schau ich mir gerne mal an.

Danke
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: Eisix am 15 Mai 2018, 10:07:48
Habe gerade mal nach Perl-snmp auf den repos geschaut.


libsnmp-extension-passpersist-perl - Generic pass/pass_persist extension framework for Net-SNMP
libsnmp-info-perl - Object Oriented Perl5 Interface to Network devices and MIBs through SNMP
libsnmp-mib-compiler-perl - a MIB Compiler supporting SMIv1 and SMIv2
libsnmp-multi-perl - Perform SNMP operations on multiple hosts simultaneously
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 15 Mai 2018, 19:38:37
Hab noch einen letzten Screenshot im ersten Post ran gehangen.
Ich habe erfolgreich ein Upgrade von 75 Paketen über FHEM gemacht. Danach erhält man eine Liste welche Pakete von welcher Version auf welche Version upgegradet wurden. (siehe Screenshot 3)

Damit wäre ich nun erstmal durch. Ich teste noch etwas und stelle es dann für erste mutige Tester zur Verfügung
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 16 Mai 2018, 04:42:52
Das geht mir jetzt alles etwas schnell.

Ich würde Dich bitten, für diesen Beitrag (und es wird morgen noch einer folgen, der mit den Befehlen auf der remote-Seite) gedanklich auf NULL zurückzufahren und Dir das anzusehen und bei Dir selbst zu testen: Möglicherweise  ergibt das weitere Ansätze.

In diesem Beitrag geht es darum, das nmap-Modul dafür zu nutzen, aus im eigenen Netz gefundenen IP Devices automatisiert zu bauen. Die Devices haben derzeit keinen praktischen Zweck - außer den, da zu sein. Meine (unsere) Idee war genau der Anwendungsfall, den Du Dir gerade vornimmst, quasi eine Vorarbeit. (Hinzuzufügen ist, dass das nicht mein Werk ist, dass ist das Werk von drei Leuten, meine Aufgabe war dabei die geringste.)

Alle 15 Minuten (wir wollen kein Hochverfügbarkeitsrechenzentrum überwachen) läuft nmap via FHEM. Das bringt zwei Ergebnisse:

Erstens entsteht im Raum 92 eine Übersichtstabelle aller im Netz erreichbaren IP, dabei sind mehrere Subnetze möglich. In der Tabelle ist jede IP anklickbar, beispielhaft geht die URL auf Port 80 (http) der jeweiligen IP. Ich betone "beispielhaft".  Weiterhin kann man via attr jeder IP einen Alias-Namen geben. Das ist sinnvoll, da ich davon ausgehe, dass die Zielgruppe ihre Server und Serverchen mit statischen IP betreibt.

Zweitens erzeugt das Codefragment für jede neue IP eine Device - derzeit beispielhaft als dummy ohne jede Funktion. Der Streit, ob da define oder defmod in Anwendung zu bringen ist, wurde nie ausgetragen.


define Netzwerk Nmap 192.168.127.0/24 192.168.128.0/24 192.168.1.0/24
attr Netzwerk absenceThreshold 1
attr Netzwerk deleteOldReadings 1800
# folgende Zeile alle Alias
attr Netzwerk devAlias 192.168.127.1:Router_eth0 192.168.127.11:APU_S
attr Netzwerk keepReadings 1
attr Netzwerk leadingZeros 0
attr Netzwerk room 92 Intranet
attr Netzwerk sudo 1
attr Netzwerk webCmd statusRequest

define NetzwerkListe readingsGroup <>,<IP-Adresse>,<Status>,<Name> \
Netzwerk:@3,#1_ip,#1_state,(.*)_alias
attr NetzwerkListe cellStyle { "c:1" => 'style="text-align:right"',"c:2" => 'style="text-align:center"'}
attr NetzwerkListe icon it_network
attr NetzwerkListe room 92 Intranet
attr NetzwerkListe sortFn rgSortIP
attr NetzwerkListe valueFormat { my $ipAddr = substr($READING,0,index($READING,"_"));;\
  #Icon für #1_state.absent Spalte 'onl' \
  return("<img src='./fhem/images/default/10px-kreis-rot.png' alt='absent'>") if($VALUE eq "absent");;\
  #Icon für #1_state.present Spalte 'onl' \
  return("<img src='./fhem/images/default/10px-kreis-gruen.png' alt='present'>") if($VALUE eq "present");;\
  #Spalte 'IP' mit Link "http://<IP>" \
  return("<a url=\"http://$ipAddr\" onclick='window.open(\"http://$ipAddr\")')>$ipAddr</a>") if(substr($READING,rindex($READING,"_")) eq "_ip");;\
  return("");;\
}
attr NetzwerkListe valueStyle {$READING =~ m/(.+)_/;;\
my $state = ReadingsVal($DEVICE, $1."_state", "NA");;\
my $style = "";;\
\
return('style="text-align: right;; '.$style.'"') if($state eq "present" && $READING =~ m/_uptime/);;\
return('style="color: #bfbfbf;; text-align: right;; '.$style.'"') if($state eq "absent" && $READING =~ m/_uptime/);;\
\
return('style="'.$style.'"') if($state eq "present");;\
return('style="color: #bfbfbf;; '.$style.'"') if($state eq "absent");;\
}

define FileLog_NetzwerkListe FileLog ./log/NetzwerkListe-%Y.log NetzwerkListe
attr FileLog_NetzwerkListe logtype text
attr FileLog_NetzwerkListe room Alle_Logs

define new_host_notify notify Netzwerk:new.host:..+ {\
my $newDeviceName = "";;\
my $ip = "";;\
my $regex = qr/host: (.*)? \(/p;;\
if ( $EVENT =~ /$regex/g )\
  {\
  $ip = $1;;\
  }\
$regex = qr/\./p;;\
my $subst = '_';;\
$newDeviceName = $ip =~ s/$regex/$subst/rg;;\
fhem("defmod $newDeviceName dummy");;\
fhem("setreading $newDeviceName IP $ip");;\
fhem("set $newDeviceName ".ReadingsVal("Netzwerk",$ip.'_state','unknown'));;\
}
attr new_host_notify room 99_System

define FileLog_new_host_notify FileLog ./log/new_host_notify-%Y.log new_host_notify
attr FileLog_new_host_notify logtype text
attr FileLog_new_host_notify room Alle_Logs


Die von mir erwähnte Tabelle in Raum 92 ist im Screenshot.

In fhem.cfg damit automatisiert neu erzeuge Devices sehen beispielhaft so aus:

define 192_168_128_1 dummy
define 192_168_1_1 dummy
define 192_168_127_1 dummy


Dort gibt es die Spitzfindigkeit, dass händisches Löschen aus fhem.cfg dafür sorgt, dass diese konkrete IP nie wieder erkannt wird. Es sei denn, man löscht im Webinterface alle readings und stößt danach dort einen neuen nmap-Scan an.

Schaue es Dir bitte ganz in Ruhe bei Dir an, ganz neutral. Ich denke, dass dieser Ansatz dem langfristigen Automatisierungsgedanken entgegen kommt.

P.S: Initial war der Thread https://forum.fhem.de/index.php/topic,70041.60.html - von daher möchte ich @igami sowie @supernova1963 von dieser Diskussion sowie Deinem Projekt informieren. Done.

PP.S: Meine gedanklich davon getrennten Überlegungen, was man WIE überwachen will, dann in einem späteren, getrennten Beitrag.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 16 Mai 2018, 06:49:05
Zitat von: curt am 16 Mai 2018, 04:42:52
Das geht mir jetzt alles etwas schnell.

Ich würde Dich bitten, für diesen Beitrag (und es wird morgen noch einer folgen, der mit den Befehlen auf der remote-Seite) gedanklich auf NULL zurückzufahren und Dir das anzusehen und bei Dir selbst zu testen: Möglicherweise  ergibt das weitere Ansätze.

In diesem Beitrag geht es darum, das nmap-Modul dafür zu nutzen, aus im eigenen Netz gefundenen IP Devices automatisiert zu bauen. Die Devices haben derzeit keinen praktischen Zweck - außer den, da zu sein. Meine (unsere) Idee war genau der Anwendungsfall, den Du Dir gerade vornimmst, quasi eine Vorarbeit. (Hinzuzufügen ist, dass das nicht mein Werk ist, dass ist das Werk von drei Leuten, meine Aufgabe war dabei die geringste.)

Alle 15 Minuten (wir wollen kein Hochverfügbarkeitsrechenzentrum überwachen) läuft nmap via FHEM. Das bringt zwei Ergebnisse:

Erstens entsteht im Raum 92 eine Übersichtstabelle aller im Netz erreichbaren IP, dabei sind mehrere Subnetze möglich. In der Tabelle ist jede IP anklickbar, beispielhaft geht die URL auf Port 80 (http) der jeweiligen IP. Ich betone "beispielhaft".  Weiterhin kann man via attr jeder IP einen Alias-Namen geben. Das ist sinnvoll, da ich davon ausgehe, dass die Zielgruppe ihre Server und Serverchen mit statischen IP betreibt.

Zweitens erzeugt das Codefragment für jede neue IP eine Device - derzeit beispielhaft als dummy ohne jede Funktion. Der Streit, ob da define oder defmod in Anwendung zu bringen ist, wurde nie ausgetragen.


define Netzwerk Nmap 192.168.127.0/24 192.168.128.0/24 192.168.1.0/24
attr Netzwerk absenceThreshold 1
attr Netzwerk deleteOldReadings 1800
# folgende Zeile alle Alias
attr Netzwerk devAlias 192.168.127.1:Router_eth0 192.168.127.11:APU_S
attr Netzwerk keepReadings 1
attr Netzwerk leadingZeros 0
attr Netzwerk room 92 Intranet
attr Netzwerk sudo 1
attr Netzwerk webCmd statusRequest

define NetzwerkListe readingsGroup <>,<IP-Adresse>,<Status>,<Name> \
Netzwerk:@3,#1_ip,#1_state,(.*)_alias
attr NetzwerkListe cellStyle { "c:1" => 'style="text-align:right"',"c:2" => 'style="text-align:center"'}
attr NetzwerkListe icon it_network
attr NetzwerkListe room 92 Intranet
attr NetzwerkListe sortFn rgSortIP
attr NetzwerkListe valueFormat { my $ipAddr = substr($READING,0,index($READING,"_"));;\
  #Icon für #1_state.absent Spalte 'onl' \
  return("<img src='./fhem/images/default/10px-kreis-rot.png' alt='absent'>") if($VALUE eq "absent");;\
  #Icon für #1_state.present Spalte 'onl' \
  return("<img src='./fhem/images/default/10px-kreis-gruen.png' alt='present'>") if($VALUE eq "present");;\
  #Spalte 'IP' mit Link "http://<IP>" \
  return("<a url=\"http://$ipAddr\" onclick='window.open(\"http://$ipAddr\")')>$ipAddr</a>") if(substr($READING,rindex($READING,"_")) eq "_ip");;\
  return("");;\
}
attr NetzwerkListe valueStyle {$READING =~ m/(.+)_/;;\
my $state = ReadingsVal($DEVICE, $1."_state", "NA");;\
my $style = "";;\
\
return('style="text-align: right;; '.$style.'"') if($state eq "present" && $READING =~ m/_uptime/);;\
return('style="color: #bfbfbf;; text-align: right;; '.$style.'"') if($state eq "absent" && $READING =~ m/_uptime/);;\
\
return('style="'.$style.'"') if($state eq "present");;\
return('style="color: #bfbfbf;; '.$style.'"') if($state eq "absent");;\
}

define FileLog_NetzwerkListe FileLog ./log/NetzwerkListe-%Y.log NetzwerkListe
attr FileLog_NetzwerkListe logtype text
attr FileLog_NetzwerkListe room Alle_Logs

define new_host_notify notify Netzwerk:new.host:..+ {\
my $newDeviceName = "";;\
my $ip = "";;\
my $regex = qr/host: (.*)? \(/p;;\
if ( $EVENT =~ /$regex/g )\
  {\
  $ip = $1;;\
  }\
$regex = qr/\./p;;\
my $subst = '_';;\
$newDeviceName = $ip =~ s/$regex/$subst/rg;;\
fhem("defmod $newDeviceName dummy");;\
fhem("setreading $newDeviceName IP $ip");;\
fhem("set $newDeviceName ".ReadingsVal("Netzwerk",$ip.'_state','unknown'));;\
}
attr new_host_notify room 99_System

define FileLog_new_host_notify FileLog ./log/new_host_notify-%Y.log new_host_notify
attr FileLog_new_host_notify logtype text
attr FileLog_new_host_notify room Alle_Logs


Die von mir erwähnte Tabelle in Raum 92 ist im Screenshot.

In fhem.cfg damit automatisiert neu erzeuge Devices sehen beispielhaft so aus:

define 192_168_128_1 dummy
define 192_168_1_1 dummy
define 192_168_127_1 dummy


Dort gibt es die Spitzfindigkeit, dass händisches Löschen aus fhem.cfg dafür sorgt, dass diese konkrete IP nie wieder erkannt wird. Es sei denn, man löscht im Webinterface alle readings und stößt danach dort einen neuen nmap-Scan an.

Schaue es Dir bitte ganz in Ruhe bei Dir an, ganz neutral. Ich denke, dass dieser Ansatz dem langfristigen Automatisierungsgedanken entgegen kommt.

P.S: Initial war der Thread https://forum.fhem.de/index.php/topic,70041.60.html - von daher möchte ich @igami sowie @supernova1963 von dieser Diskussion sowie Deinem Projekt informieren. Done.

PP.S: Meine gedanklich davon getrennten Überlegungen, was man WIE überwachen will, dann in einem späteren, getrennten Beitrag.






Ganz entspannt, lass Dich nicht verrückt machen. Nur weil ich sage das es soweit fertig ist heißt es noch lange nicht das nicht neue Sachen eingebaut werden können. Also immer mit der Ruhe.
Ich muss aber noch mal kurz erwähnen, das dieses Modul lediglich aktuelle Repository Informationen holt und dann schaut ob Updates von vorhandenen Paketen zur Verfügung stehen. Danach kann man noch das Update anwerfen.
Wüsste jetzt nicht wie nmap, ausser anlegen der Devices was ja schon cool ist, da Updateinformationen liefern kann. Aber ich lass mich da gerne überraschen.



Grüße
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: Benni am 16 Mai 2018, 06:53:04
Zitat von: curt am 15 Mai 2018, 06:28:54
No 2 ist: Die Daten der verschiedenen Server müssen halt irgendwie zum FHEM-Server. Wie das passiert, ist im Moment völlig offen. @CoolTux findet ssh wunderfein, ich finde das Teufelsezug. Mir schwebt http vor, das findet CoolTux Teufelszeug. Du schlägst nun MQTT vor - von dem ich nur ansatzweise hörte. - Ok, das stellen wir zurück.

Warum die Daten/Dateien nicht von FHEM selbst ausliefern lassen (vorausgesetzt, und so habe ich es verstanden, es geht lediglich um Server, die auch FHEM hosten)?
FHEM bringt schließlich sowohl telnet, als auch eine Webserver in form von FHEMWEB ja direkt mit.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 16 Mai 2018, 06:55:37
Zitat von: CoolTux am 16 Mai 2018, 06:49:05
Wüsste jetzt nicht wie nmap, ausser anlegen der Devices was ja schon cool ist, da Updateinformationen liefern kann. Aber ich lass mich da gerne überraschen.

Es sind mehrere getrennte Überlegungen - alle irgendwie auch unfertig.

Zu meinem letzten Beitrag:
Wenn ich mir die Screenschots im Deinem ersten Beitrag dieses Threads ansehe - dann muss die Information, welche IP denn nun überhaupt zu bearbeiten (also als Devices darzustellen) ja irgendwo her kommen. Ich liebe Automation. Das in meinem letzten Beitrag Dargestellte - ist ein möglicher Ansatz dazu.

P.S: Du hast recht: Zu updates liefert das genau nichts. Meine Überlegungen dazu will ich in einem weiteren Beitrag darstellen. Und ich wollte/will alle Überlegungen deutlich trennen. Daher verschiedene Beiträge. Mit zeitlichem Abstand. Denn vielleicht fällt anderen auch noch etwas ein.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 16 Mai 2018, 07:02:12
Zitat von: Benni am 16 Mai 2018, 06:53:04
Warum die Daten/Dateien nicht von FHEM selbst ausliefern lassen

Das ist ein Problem bei Forum-Diskussionen: Jeder liest was - und baut ein geistiges Bild. Das stimmt selten mit den Überlegungen der Proponenten überein.

Benni,
es geht NICHT um Überwachung des FHEM-Servers. Es geht um Überwachung von Clients, die auf Basis Raspberry bzw Debian laufen. Diese Überwachung soll AUSDRÜCKLiCH keine Echtzeitüberwachung sein - sondern es geht um eine vielelicht tägliche Aktualisierung zu den Themen:

* Liegen Updates an?
* Wie sieht es mit Plattenplatz aus, alles noch gut?
* Hast Du ein langfristiges Hitzeproblem?

Benny, ich habe hier nebst einem anderen Zoo vier RPI sowie derzeit nochmal vier RPi-Zero. Sich auf jedem einzuloggen und zu gucken ob Updates anliegen oder Platte voll läuft, ist eine Veranstaltung, die ich mir im Hobby nicht antun will. (Ja, ich weiß, dass es vollautomatisierte Update-Strategien gibt ...)
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 16 Mai 2018, 08:03:00
Zitat von: curt am 16 Mai 2018, 07:02:12
Das ist ein Problem bei Forum-Diskussionen: Jeder liest was - und baut ein geistiges Bild. Das stimmt selten mit den Überlegungen der Proponenten überein.

Benni,
es geht NICHT um Überwachung des FHEM-Servers. Es geht um Überwachung von Clients, die auf Basis Raspberry bzw Debian laufen. Diese Überwachung soll AUSDRÜCKLiCH keine Echtzeitüberwachung sein - sondern es geht um eine vielelicht tägliche Aktualisierung zu den Themen:

* Liegen Updates an?
* Wie sieht es mit Plattenplatz aus, alles noch gut?
* Hast Du ein langfristiges Hitzeproblem?

Benny, ich habe hier nebst einem anderen Zoo vier RPI sowie derzeit nochmal vier RPi-Zero. Sich auf jedem einzuloggen und zu gucken ob Updates anliegen oder Platte voll läuft, ist eine Veranstaltung, die ich mir im Hobby nicht antun will. (Ja, ich weiß, dass es vollautomatisierte Update-Strategien gibt ...)

Das mit der Hitze und dem Platten macht SYSMON soweit mir bekannt. Das passt also schon mal. Das mit den Updates macht AptToDate nun.
Der Rest ist eigentlich simpel. Das NMAP Modul scannt und stellt die erhaltenen Daten in einer Übersicht zur Verfügung. Als Get Kommando. Darin enthalten ist ein Link zum anlegen des Devices als SYSMON oder als AptToDate.
Einzig was übrig bleibt ist die Art und Weise wie FHEM an die Daten auf den entfernten Systemen kommt.
Man kann da auch eine separate Socketverbindung mit einem Dienst entwickeln und den auf den Clients verteilen. Ähnlich lepresenced. Aber wie gesagt, SSH oder telnet gibt es ja bereits.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 16 Mai 2018, 15:27:04
Hier geht es nun ans testen

https://forum.fhem.de/index.php/topic,87835.0.html

Wer will, bitte genau den ersten Post lesen. Danke
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 17 Mai 2018, 02:46:20
Zitat von: CoolTux am 16 Mai 2018, 08:03:00
Das mit der Hitze und dem Platten macht SYSMON soweit mir bekannt. Das passt also schon mal.

Nein, das passt nicht - jedenfalls nicht bei meinem Denkansatz. Leider war ich offensichtlich nicht in der Lage, verständlich zu schreiben.

Aus meiner Sicht geht es darum, von entfernten Servern einmal täglich zu erfahren, ob updates anliegen. Die Zahl der Updates soll dann ein reading der jeweiligen Device werden. Es ist (in meinem Denkmodell) gar nicht erforderlich, dass die updates dann entfernt angestoßen werden - da gibt es elegantere Wege.

Aber wenn pro Device einmal täglich Werte eingesammelt werden, kann es auch gleich noch Plattenplatz und Temperatur sein. Das reicht einmal täglich, ich betreibe kein Hochverfügbarkeitsrechenzentrum. Aber solche täglichen Parameter sollen auch readings der jeweiligen Device werden.

sysmon und nagios und wie der ganze Kram heißt - machen etwas anderes: Da läuft es auf live-Überwachung hinaus. Und die produzieren erst das Problem, das sie überwachen sollen: Wärme.

Zitat von: CoolTux am 16 Mai 2018, 08:03:00
Das mit den Updates macht AptToDate nun.

Ich bin -wie gesagt- nicht auf dem Punkt, die updates von Ferne anzustoßen. Aber das kann ich dann erklären - ich denke, dass ich morgen das vorstellen kann, was ich inzwischen auf mehreren Servern testweise laufen habe. (Das wird, wie besprochen, nur ein Fragment einer größeren Lösung.) Ich will das so im Forum schreiben, dass verständlich nachvollziebar wird, was mein Ziel ist und was ich treibe.

P.S: Dein Alpha-Modul habe ich noch nicht installiert, ich will erstmal diesen Teil abschließen, zeigen.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 17 Mai 2018, 23:36:09
Es geht darum, auf entfernten Systemen einmal täglich bestimmte Informationen einzusammeln und vorrätig zu halten. Eine mögliche Lösung für nur diese Aufgabe beschreibe ich. Die Übertragung zu einem Zielsystem (FHEM) ist nicht Bestandteil.

Bei mir laufen alle Raspberry und APU auf Raspian-9 bzw. Debian-9 (Stretch). Auf mehreren läuft das unten vorgestellte seit Tagen.

Wir müssen jedes System einmal anfassen. Alles was wir da tun, machen wir als root. Wir machen nicht viel, es sind nur zwei zu erstellende Dateien. Eine ist Konfiguration für apt, die andere ist ein bash-script.

Zunächst passen wir apt an. Das Ganze ist bei der Ubuntu-Konkurrenz abgeschaut, siehe https://wiki.ubuntuusers.de/Aktualisierungen/Konfiguration/ . Allerdings wollen wir keine wirklich automatischen Updates. Wir erzeugen also die folgende Datei, die quasi schon mal die Flinte spannt: Automatisiert wird die Liste der Updates geholt und schon mal vorgeladen.

cat /etc/apt/apt.conf.d/10-periodic

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
#APT::Periodic::Unattended-Upgrade "1";


Nun kommen wir zum Bash-Script. Da gibt es mehrere Tricks bzw. zu beachtende Dinge: Wir legen das Script (wie gesagt als root) in das Verzeichnis /etc/cron.daily . Der Name deutet an, dass Cron ab sofort täglich einmal das Script aufruft. Weiterhin wichtig ist, dass der Name des Scripts keine Extension haben darf, cron ist da feinfühlig. Zudem habe ich im Script mit absoluten Dateinamen für die Befehle gearbeitet: Nach meiner Erfahrung zickt Cron teilweise herum, wenn man allein mit dem Befehlsnamen arbeitet. Und den Stress, später solche Fehler zu suchen, tun wir uns nicht an. Los geht es:

cat /etc/cron.daily/status-pruefen

#!/bin/bash

# Aufbau:
#
# Typbeschreibung;Wert
# date;2018-05-12
# updates;0
#

# Diese Datei muss in /etc/cron.daily
#  Die Datei darf keine Extension haben!

#
# allgemeine Definitionen
#

ZIEL=/var/www/html/status2fhem.txt

# nicht anfassen!
VERS="V0.1"

DATE=`date +%Y-%m-%d`

HOSTNAME=`/bin/hostname`

SYS1=`/bin/cat /etc/issue`

SYS2=`/bin/uname -a`

IP1=`/bin/hostname -I`

IPwlan0=`/sbin/ip addr show wlan0 | /bin/grep -vw "inet6" | /bin/grep "global" | /bin/grep -w "inet" | /usr/bin/cut -d/ -f1 | /usr/bin/awk '{ print $2 }'`

UPDATE=`/usr/bin/apt-get dist-upgrade -qq -y -s | /bin/grep '^Inst ' | /usr/bin/wc -l`

# gilt nur für RPi. Hier fehlt eine Weiche (weil es auch noch Debian und Ubuntu gibt)!
# Konvention unklar: Punkt oder Komma?
if [ -x /usr/bin/vcgencmd ]
  then RPitemp=`/usr/bin/vcgencmd measure_temp |/bin/sed -e s/temp=// |/bin/sed -e s/\'C//`
fi

# für Linux-like Systeme wie Debian muss es der Befehl "sensors" sein. Hier für APU, da ist die Ausgabe von sensors anders
if [ -x /usr/bin/sensors ]
  then APUtemp=$( /usr/bin/sensors | awk '/temp1/ {print $2}' )
fi

# hier ist es unfertig:
#PLATTE=`/bin/df -h --output=source,fstype,ipcent,size,used,avail,pcent,file,target | /bin/grep "^/dev"`
PLATTE=`/bin/df -Ph | sort -k 5,5 | /usr/bin/awk '{printf "%-35s %10s %4s %s\n",$1,$2,$5,$6}' | /bin/grep "^/dev"`

# Ende der Befehle

# testweise: Wann wird das Script eigentlich aufgerufen?
/bin/cp /dev/null /tmp/timestamp

# das CSV bauen:

echo version\;$VERS > $ZIEL
echo date\;$DATE >> $ZIEL
echo sys-state\;$SYS1 >> $ZIEL
echo sys-detail\;$SYS2 >> $ZIEL
echo HOSTNAME\;$HOSTNAME >> $ZIEL
echo IP\;$IP1 >> $ZIEL
echo IPwlan0\;$IPwlan0 >> $ZIEL
echo update\;$UPDATE >> $ZIEL
if [ $RPitemp ]
  then echo RPitemp\;$RPitemp >> $ZIEL
fi
if [ $APUtemp ]
  then echo APUtemp\;$APUtemp >> $ZIEL
fi
echo Platten\;$PLATTE >> $ZIEL


Diese Datei muss ausführbar sein: "chmod u+x /etc/cron.daily/status-pruefen" muss man als root noch ausführen.

So - eigentlich ist alles fertig. Nun heißt es warten, mindestens einen Tag warten. In der Zeit schauen wir uns die ersten Zeilen an, da wird alles definiert:

* ZIEL - In diese Datei schreiben wir die Ergebnisse, sie wird täglich überschrieben. Wo die Datei liegt, ist im Grunde egal, ich habe sie bei den meisten Systemen Im Apache-Verzeichnis.

* VERS - das ist die Version DIESES Scriptes. Das ist vorausschauend angelegt - vielleicht brauchen wir das in einem halben Jahr.

* DATE - an welchem Tag ist das Script gelaufen? Wir wollen wissen, ob irgend ein update so dazwischen grätschte, dass das Script gar nicht mehr läuft.

* SYS1 und SYS2 erzählt etwas über das System selbst: Name, Debian-Version, Kernelversion.

* HOSTNAME ist klar.

* IP sind die IP-Adressen kabelgebunden. IPwlan0 ist die IP-Adresse Wlan-Schnittstelle.

* UPDATE - die Anzahl der vorliegenden Updates. Nur die Anzahl. Ich stelle mir alles ja gedanklich als reading einer device bei FHEM vor ...

* *temp - da läuft es auseinander: Bei Debian (Ubuntu) geht das anders als bei Raspberry. Man kann streiten, ob man da nicht doch den gleichen Namen verwendet. Auch ist unklar, ob wir lieber Punkt oder Komma für die Nachkommastelle der Temperatur nehmen.

* Platte: Kurzinfos über alle verfügbaren Platten, da geht es um Auslastungsüberblick.

Die erzeugte Datei heißt *.txt, weil ich mir das Ergebnis über Webbrowser ansehen will. Richtiger wäre csv, es ist eine CSV-Datei (aber dann wollen Browser nicht anzeigen sondern speichern ...). Der Spaltentrenner in der CSV-Datei ist das Semokolon.

So, schauen wir uns Ergebnisse an:

APU-Debian, Router, drei eth-Schnittstellen: 2 interne Subnetze, 1 zum VDSL-Modem. Kein Wlan. Zwei Platten: Eine intern, eine USB, hart gemountet. 4 updates offen:

version;V0.1
date;2018-05-17
sys-state;Debian GNU/Linux 9 \n \l
sys-detail;Linux debian 4.9.0-6-686-pae #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) i686 GNU/Linux
HOSTNAME;debian
IP;192.168.127.1 192.168.128.1 21[censored].3
IPwlan0;
update;4
APUtemp;+58.6°C
Platten;/dev/sda1 16G 47% / /dev/sdd1 296G 55% /usr/[censored]


Und nun ein Raspberry, Verbindung via Wlan:

version;V0.1
date;2018-05-16
sys-state;Raspbian GNU/Linux 9 \n \l
sys-detail;Linux rpi-kamera-5 4.14.30+ #1102 Mon Mar 26 16:20:05 BST 2018 armv6l GNU/Linux
HOSTNAME;rpi-kamera-5
IP;192.168.1.25
IPwlan0;192.168.1.25
update;15
RPitemp;59.5
Platten;/dev/root 15G 23% / /dev/mmcblk0p1 41M 53% /boot


Das kann man sicher alles schöner, eleganter, ganz anders, viel sicherer machen. Klar, ich weiß. Aber es soll in der Diskussion weiter gehen. Und wenn ich das jetzt nicht zeige, wird es tatsächlich via ssh ...

Falls wir das Script so oder ähnlich nutzen wollen um im FHEM-Devices mit Attributen zu füllen, muss man vermutlich einiges anders machen: Als erstes würde ich dann wohl bei sys-state "\n \l" wegfiltern.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 18 Mai 2018, 03:52:17
Zitat von: CoolTux am 16 Mai 2018, 06:49:05
Wüsste jetzt nicht wie nmap, ausser anlegen der Devices was ja schon cool ist, da Updateinformationen liefern kann. Aber ich lass mich da gerne überraschen.

Ich beschreibe meine Vorstellung - quasi wie ein Pflichtenheft. Nur netter natürlich ;)

Alle Klienten (also alle Raspberry und wie sie alle heißen mögen) fahren automatisiert täglich genau das, was ich im vorhergehenden Beitrag vorstellte. Jeder einzelne Klient hat also täglich eine Datei mit seinem "Zustandsbericht".

Wir sind uns derzeit nicht einig, wie diese ganzen Zustandsberichte der einzelnen -jetzt kommt es- FHEM-Devices zu FHEM kommen. Ob über ssh oder über http oder über snmp oder über weißderGeier. Ist erstmal egal.

In meiner Vorstellung bohren wir die bisherige nmap-Arbeit so auf, dass da für jede IP nicht nur ein Device entsteht. Sondern ein Device mit Attributen. Ja genau - alles, was die entfernten Server über sich selbst wissen, muss zu Attributen der jeweiligen FHEM-Device werden.

Und ich kann dann entweder auf jede Device klicken und sehe alle Attribute. Oder ich kann eine Tabelle über alle Devices bauen "wem fehlen Updates?". Oder ich kann eine Tabelle über alle Devices bauen "Wer von euch hat weniger als 85% Speicherplatz frei?".

Nein, kann ich natürlich nicht. Sonst wäre das ja schon längst da.
Ich bin der mit der Konzept-Idee.

Die ich hoffentlich nun gut darstellen konnte.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 18 Mai 2018, 08:17:16
Meine persönliche Meinung.
Ich denke das dies für den normalen Anwender zu viel ist. Die meisten wollen nichts mit Scripten oder Programmieren am Hut haben. Das müssen sie aber bei Deiner Überlegung.

Der Gedanke mit den Attributen ist für FHEM FALSCH. Der Status einen Gerätes wird in FHEM IMMER in einem Reading da gestellt, Attribute gehören dem User und helfen lediglich beim erweiterten steuern eines FHEM Devices.
Hier empfehle ich wirklich Readings an zu legen.


Für mich persönlich hat Deine Idee keinen Mehrwert in meiner Umgebung. Aber lass Dich davon auf keinen Fall entmutigen, es gibt sicherlich User die Interesse haben.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 19 Mai 2018, 00:30:10
Zitat von: CoolTux am 18 Mai 2018, 08:17:16
Ich denke das dies für den normalen Anwender zu viel ist. Die meisten wollen nichts mit Scripten oder Programmieren am Hut haben.

Wer drei oder mehr RPi hat, ist nicht mehr der von Dir postulierte normale Anwender. Und wer updates überwachen will - gleich gar nicht.

Zitat von: CoolTux am 18 Mai 2018, 08:17:16
Das müssen sie aber bei Deiner Überlegung.

Nein, müssen sie gerade nicht. Der Nutzer muss zwei Dateien an eine bestimmte Stelle kopieren, je entfernten Server. Verändern oder gar programmieren muss da niemand was. Das habe ja ich schon erledigt. Und veröffentlicht, siehe oben. Alles schon da. (VIELLEICHT den Ablageort der Ergebnisdatei ändern, das ist ja abhängig davon, wie wir weiter vorgehen.)

Zitat von: CoolTux am 18 Mai 2018, 08:17:16
Der Gedanke mit den Attributen ist für FHEM FALSCH.
Ja doch. Readings. <seufzt>
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 19 Mai 2018, 06:42:25
Wird das ganze in dem oben verlinkten nmap Threads weiter diskutiert? Dann trage ich mich da mal ein um das weiter zu verfolgen.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 19 Mai 2018, 06:46:08
Zitat von: CoolTux am 19 Mai 2018, 06:42:25
Wird das ganze in dem oben verlinkten nmap Threads weiter diskutiert?

Meines Wissens nach nicht.

Der Autor des Moduls hatte andere Intensionen und nutzt sein eigenes Modul nicht mehr.
Ein weiterer Diskutant lag eher auf meiner Wellenlänge, wenn ich recht erinnere, hat er sogar mal einen sehr frühen weiteren Modulentwurf (dort?) veröffentlicht. Den habe ich mir aber nie angesehen. (Von diesem weiteren Autoren stammen wohl alle Vorschläge, wie man ein Device automatisiert erzeugt.)
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 19 Mai 2018, 06:48:12
Dann solltest Du Deine Ideen in einem eigenen Threads mit sprechender Überschrift wählen, damit Interessierte daran teilhaben können. Gibt bestimmt welche.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: curt am 19 Mai 2018, 06:52:04
Zitat von: CoolTux am 19 Mai 2018, 06:48:12
Dann solltest Du Deine Ideen in einem eigenen Threads mit sprechender Überschrift wählen, damit Interessierte daran teilhaben können. Gibt bestimmt welche.

Keine Lust. Reicht mir grad wieder.

Siehe auch https://forum.fhem.de/index.php?topic=83097.msg803651#msg803651
Dort ab Beitrag #196 - vielleicht hast Du zu viel Zeit und liest mal wirklich. Du bist Adressat.

Was war ich blöd, mir tagelang Gedanken zu machen, zu testen, zu .. egal. Alles gut.
Titel: Antw:Neues Modul apt-get Infos
Beitrag von: CoolTux am 19 Mai 2018, 07:07:40
Ich verstehe Dich nicht. Wieso willst Du jetzt schon aufgeben.
Du hast ja noch nicht mal Angefangen. Wie weit bist Du konkret mit der Umsetzung Deiner Idee?

nmap scannt, legt automatisch alle gefundenen Devices an? Und dann? Auf alle gefundenen müssen nun die Scripte installiert werden. Und dann werden die Daten welche die Scripte einsammeln abgelegt. Und dann?