Neues Modul apt-get Infos

[CoolTux]

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

[curt]

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.

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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.

[CoolTux]

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.

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[Benni]

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.

[curt]

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.

[curt]

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

[CoolTux]

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.

[CoolTux]

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

[curt]

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.

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.

[curt]

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

Code Auswählen Erweitern


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

Code Auswählen Erweitern


#!/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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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.

[curt]

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.

[CoolTux]

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.

[curt]

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.

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

Der Gedanke mit den Attributen ist für FHEM FALSCH.

Ja doch. Readings. <seufzt>

[CoolTux]

Wird das ganze in dem oben verlinkten nmap Threads weiter diskutiert? Dann trage ich mich da mal ein um das weiter zu verfolgen.

[curt]

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