Neues Modul apt-get Infos

[knopf_piano]

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.

[CoolTux]

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.

[ToM_ToM]

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.

[Ranseyer]

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

[the ratman]

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

[CoolTux]

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 

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.

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

[curt]

Ich möchte im Moment nur auf einige angesprochenen Punkte eingehen.

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.

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.

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.

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>

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.

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

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.

[curt]

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.

[supernova1963]

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

[curt]

@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".

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.

[Eisix]

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

[CoolTux]

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?

[Eisix]

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

[CoolTux]

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

[Eisix]

Habe gerade mal nach Perl-snmp auf den repos geschaut.

Code Auswählen Erweitern


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