Archiv der Kategorie: Memo

Shrink VM

Was tut man nicht alles? Ich hab hier eine VM mit W10Edu 20H2, die gelegentlich gestartet wird, um damit z.B. Wireshark zu testen, Updates zu installieren, eine einzelne Datei in MSO anzusehen oder mit W10 Privacy nachzusehen, was ich alles unter Arch nicht erdulden muss.

Trotzdem wuchert das Ding über die Zeit vor sich hin und will gelegentlich geschrumpft werden. Das geschieht hier so:

Erst einmal aus W10 heraus mit sdelete Platz schaffen:

sdelete -z "C:"

Dann die VM runterfahren und mit VBoxManage die VDI komprimieren:

vboxmanage list hdds
vboxmanage modifymedium disk /pfad/zur/vm/w10edu.vdi --compact

Am Schluss nach Geschmack wegsichern mit tar – oder auch nicht.

webm2mp3

Falls ich es erneut vergesse: Die Konvertierung von webm Dateien im aktuellen Verzeichnis nach mp3 mit ffmpeg:

for i in $(ls *.webm) ; do ffmpeg -i "$i" -vn -ab 192k -ar 44100 -y "${i%.*}.mp3"; done

Grubgefummel

Weil wireguard mit dem heute gekommenen Kernel für Ubuntu 18.04 nicht durch den Compiler ging

Unpacking wireguard-dkms (1.0.20200520-0ppa1~18.04) over (1.0.20200520-0ppa1~18.04) ...
Setting up wireguard-dkms (1.0.20200520-0ppa1~18.04) ...
Loading new wireguard-1.0.20200520 DKMS files...
Building for 4.15.0-106-generic
Building initial module for 4.15.0-106-generic
Error! Bad return status for module build on kernel: 4.15.0-106-generic (x86_64)
Consult /var/lib/dkms/wireguard/1.0.20200520/build/make.log for more information.
Setting up wireguard (1.0.20200513-1~18.04) ...

und dann in /var/lib/dkms/wireguard/1.0.20200520/build/make.log Derartiges hinterließ

DKMS make.log for wireguard-1.0.20200520 for kernel 4.15.0-106-generic (x86_64)
Wed Jun 10 07:49:21 CEST 2020
make: Entering directory '/usr/src/linux-headers-4.15.0-106-generic'
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/main.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/noise.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/device.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/peer.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/timers.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/queueing.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/send.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/receive.o
  CC [M]  /var/lib/dkms/wireguard/1.0.20200520/build/socket.o
In file included from <command-line>:0:0:
/var/lib/dkms/wireguard/1.0.20200520/build/socket.c: In function ‘send6’:
/var/lib/dkms/wireguard/1.0.20200520/build/compat/compat.h:102:42: error: ‘const struct ipv6_stub’ has no member named ‘ipv6_dst_lookup’; did you mean ‘ipv6_dst_lookup_flow’?
 #define ipv6_dst_lookup_flow(a, b, c, d) ipv6_dst_lookup(a, b, &dst, c) + (void *)0 ?: dst
                                          ^
/var/lib/dkms/wireguard/1.0.20200520/build/socket.c:139:20: note: in expansion of macro ‘ipv6_dst_lookup_flow’
   dst = ipv6_stub->ipv6_dst_lookup_flow(sock_net(sock), sock, &fl,
                    ^~~~~~~~~~~~~~~~~~~~
scripts/Makefile.build:330: recipe for target '/var/lib/dkms/wireguard/1.0.20200520/build/socket.o' failed
make[1]: *** [/var/lib/dkms/wireguard/1.0.20200520/build/socket.o] Error 1
Makefile:1577: recipe for target '_module_/var/lib/dkms/wireguard/1.0.20200520/build' failed
make: *** [_module_/var/lib/dkms/wireguard/1.0.20200520/build] Error 2
make: Leaving directory '/usr/src/linux-headers-4.15.0-106-generic'

wollte ich prüfen, ob ich um den Bug herumkomme, wenn ich den Server mit dem alten Kernel starte.

Ich dachte, das geht so:

Ein

grub-mkconfig | grep -E 'submenu |menuentry '

liefert den Menüeintrag für den älteren Kernel

menuentry 'Ubuntu' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
submenu 'Advanced options for Ubuntu' $menuentry_id_option 'gnulinux-advanced-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
        menuentry 'Ubuntu, with Linux 4.15.0-106-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-106-generic-advanced-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
        menuentry 'Ubuntu, with Linux 4.15.0-106-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-106-generic-recovery-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
Found linux image: /boot/vmlinuz-4.15.0-101-generic
Found initrd image: /boot/initrd.img-4.15.0-101-generic
        menuentry 'Ubuntu, with Linux 4.15.0-101-generic' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-101-generic-advanced-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {
        menuentry 'Ubuntu, with Linux 4.15.0-101-generic (recovery mode)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.15.0-101-generic-recovery-18a21bc3-6dd4-4d7a-a538-c7d935a00a63' {

der dann beim Boot via /etc/default/grub (vorher wegsichern!) ausgewählt wird

GRUB_DEFAULT="Advanced options for Ubuntu>Ubuntu, with Linux 4.15.0-101-generic"

nachdem ein

update-grub

fehlerfrei durchläuft.

Doof gedacht: wireguard-dkms baut natürlich trotzdem für den neueren Kernel. Weil? Weil er da ist. So simpel.

Das Ergebnis ist also das gleiche wie oben: wireguard-dkms fällt beim Modulbau auf die Nase – obwohl der Server mit dem älteren Kernel läuft.

Eigentlich total klar – aber die Finger auf den Tasten sind manchmal schneller als das Hirn dazu.

Einfacher – und dazu noch fehlerfreier bei den Nacharbeiten mit DKMS zu handhaben – ist ein simpler apt-get purge auf den neueren Kernel.

apt-get purge linux-image-4.15.0-106-generic
apt-get clean ; apt-get autoremove

Dann evtl. noch die alten /etc/default/grub Inhalte wiederherstellen (falls mensch so blöd wie ich war), ein update-grub und nach einem Neustart ist wireguard wieder brav am Start.

Update

Was hier bezüglich Wireguard wunderbar funktioniert hat:

apt-get install --install-recommends linux-generic-hwe-18.04
apt-get install --reinstall wireguard-dkms wireguard-tools linux-headers-$(uname -r)

Ich hoffe, das hält nun eine Weile.

LiSCrypt

Irgendein Mensch auf dem Amt der in Weisheit klug Erschlauten kam auf die Idee, dass man doch weiterhin VeraCrypt ignorieren könnte – und beschloss, dass man nun in den Kommissionen LiSCrypt zu nutzen habe. Naja. Wenigstens ist es quelloffen zu haben, auch wenn die Idee, lauter Einzeldateien zu verschlüsseln, statt einen Container zu nutzen, davon zeugt, dass dieser Mensch mit der konkreten Arbeit in Kommissionen wenig zu tun hat.

Und was ein Audit ist, weiß er wohl auch nicht.

Aber es hilft ja alles nix. Also ran an das Ding.

Unter Kubuntu 18.04 kommt LiSCrypt wie folgt an Bord:

wget https://github.com/MaWe2019/LiSCrypt_public/archive/v0.9.7.zip
unzip v0.9.7.zip

Das oben geht natürlich auch händisch. Downloads hat es hier: https://github.com/MaWe2019/LiSCrypt_public/releases

Dann pip3 updaten

pip3 install --upgrade pip

Noch die Abhängigkeiten installieren

pip3 install psutil
pip3 install base91

Und dann geht es im entpackten Quelltextverzeichnis an die Arbeit mit

python3 -m Steuerung.LiSCrypt

Sieht dann so aus:

 

Wer kein KDE hat, muss evtl. noch die Qt Abhängigkeiten installieren. Aber wer die Ausgaben beim Start des Programms liest, findet die passenden Pakete, die man sich per pip an Bord holen kann. Vermutlich ist das dann sowas wie

pip3 install PyQt5

Hat man die defaults in der GUI gelassen, dann ist mit der Verschlüsselung des Originals dasselbe auch gleich weggelöscht. Hübsch, wenn man sich bei der Eingabe des Kennwortes zwei mal vertippt haben sollte. Dann sind die Dateien richtig sicher 😉

Ich tippe mal, das führt im Kommissionsalltag dann dazu, dass alle das Häkchen dort wegmachen und die unverschlüsselten Dateien im Dateisystem liegen lassen.

Notizen zum build von LOS für Flo / Mako

Damit ich es nicht vergesse, was hier Schritt für Schritt abzuarbeiten ist bei der Erstellung von neuen Images für Flo und Mako:

## Note for Mako and Flo LOS builds
## Flo
## See https://wiki.lineageos.org/devices/flo/build
## repo init -u https://github.com/LineageOS/android.git -b cm-14.1
## Mako 
## https://wiki.lineageos.org/devices/mako/build
## repo init -u https://github.com/LineageOS/android.git -b lineage-15.1
##
## Keep buildenv up to date
## in this case in two sub-dirs in ~/android:
## ~/android/flo and ~/android/mako
##

cd ~/android/flo ; repo sync
# or
cd ~/android/mako ; repo sync

# if we run into problems with repo sync this might help:
# repo sync --force-broken --force-sync

##
## Source and export what we need for build
##

source build/envsetup.sh  

export LC_ALL=C
export USE_CCACHE=1
export ANDROID_JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"

##
## Start build process
##

breakfast flo
# or
breakfast mako

# change dir to pull in proprietary blobs from device
cd ~/android/flo/device/asus/flo
# or
cd ~/android/mako/device/lge/mako

# Connect device via USB
# Check your path: 
# ~/android/flo/device/asus/flo
# ~/android/mako/device/lge/mako
# Check that USB debugging is ON on device
# Can we see the device?

adb devices

# pull the proprietary blobs in
./extract-files.sh 

# prepare compile
ccache -M 50G
croot

# compile
brunch flo
# or
brunch mako

## 
## Install the image
##

cd $OUT
adb reboot sideload
adb sideload lineage [TAB]
# return to sideload mode
adb sideload addonsu [TAB]

Mit je einem Image ist hier der Ordner für Flo ca. 85G und der Ordner für Mako rund 122G groß.

getmyfreetraffic redirect

Wer, wie ich, ein wenig zu lang (in meinem Fall: 2 Tage) wartete, um das Update für Easy WP SMTP einzuspielen, deswegen gehackt wurde und nun vor lauter Redirects sein Blog nicht mehr sieht: hier mein Weg zu einer wieder funktionierenden Multiblog-Installation inklusive der Schilderung meiner Stolpersteine:

  1. Das Firefox Addon noscript verhinderte zuverlässig, dass ich bei der Begutachtung des eigenen Blogs dauernd von der eigenen Site weggeschubst wurde und im Orkus landete.
  2. Die eigentliche Reparatur erfolgte nach dieser Anleitung auf Stackoverflow. Ich wählte für meine Reparatur Option 2 – also den Weg über die functions.php im Theme-Ordner.
  3. Jedoch: Bei mir war ein Subblog gehackt worden, das das gleiche Theme verwendete wie das Hauptblog. Trägt man nun die geforderten Zeilen im Theme ein, muss man sich entscheiden, welches Blog man zuerst retten will, denn hieraus ergibt sich der einzutragende URL
    update_option( 'siteurl', 'https://bdjl.de' );
    update_option( 'home', 'https://bdjl.de' );

    Wie oben zu sehen, war das in meinem Fall die Hauptdomain (und das konkrete Theme: twentytwelve).

  4. Das beschriebenen Vorgehen über die functions.php von twentytwelve für das Hauptblog führte dazu, dass die Posts im Subblog mit dem gleichen Theme nicht mehr zu erreichen waren, weil für die nun die URLs des Hauptblogs galten … also lauter leere Seiten.
  5. Immerhin funktionierte ab diesem Punkt das Backend des Hauptblogs wieder. Hier stellte ich dann die Themes aller meiner Blogs in der Multisite Installation um auf twentyten. Nur das gehackte Subblog behielt twentytwelve.
  6. Jetzt wurde im Theme twentytwelve
    update_option( 'siteurl', 'https://bdjl.de/subblog' );
    update_option( 'home', 'https://bdjl.de/subblog' );

    die Haupt-URL des Subblogs eingetragen, die Seite einmal aktualisiert und: die Posts waren alle wieder da.

Dringend angeraten ist eine Passwortänderung für a) den Mail-Account und b) die Datenbank (MariaDB, MySQL). Weiter würde ich dazu raten, die Datenbank von WordPress nach der Reparatur zu dumpen und dann im Dump nach allen möglichen Strings zu suchen, die im Kontext dieses Überfalls irgendwie Sinn machen könnten. Weitere Schritte sind auch hier beschrieben:

https://codex.wordpress.org/FAQ_My_site_was_hacked

https://wordpress.org/support/plugin/easy-wp-smtp/

TC und EDS-Lite

Als Notiz für die, die es brauchen: Für EDS-Lite können TrueCrypt-Container (ja – auch VeraCrypt geht, aber das Schutzniveau muss ja nicht in und für jeden Fall so gesetzt werden) mit den Einstellungen oben schneller auf dem Rechner, als auf dem Tablet angelegt werden:

Encryption Algorithm: Twofish
Hash-Algorithm: SHA-512

Die Standardvorgaben von TrueCrypt scheinen für EDS-Lite nicht zu funktionieren.

Proxmox mit LXC bei Hetzner

Xen? KVM? LXC? Oder gar systemd-nspawn? In der Schule drehen wir uns bezüglich der Virtualisierungsbasis für unsere Cloud hübsch im Kreis. Aktuell neige ich LXC zu, musste aber bei meinen ersten Gehversuchen einige Schläge einstecken: Restricted Container zickten, Debian Jessie Container auf Ubuntu 16.04 als Wirt ebenfalls, das Netzwerk-Setup war fummelig und die Namensauflösung in den Containern selbst immer wieder „einfach weg“ …

Also das schlechte Wetter heute mal sinnvoll genutzt und einen ganz anderen Weg beschritten: nicht wie sonst per Shell gearbeitet, sondern heute mal per Oberfläche gefummelt und mir Proxmox näher angesehen. Geht flott und funktioniert zügig. Hier eine kurze Doku.

Im Hetzner installimage das aktuelle Debian auswählen – hier: Jessie. Setup durchführen, Updates installieren, neu booten und dann an die Arbeit.

Hinweis für die Partitionierung: Die LXC-VMs werden später unter /var – genauer: /var/lib/vz/images – liegen.

echo "deb http://download.proxmox.com/debian jessie pve-no-subscription" >> /etc/apt/sources.list
wget -O - http://download.proxmox.com/debian/key.asc | apt-key add -
apt-get update
apt-get upgrade
apt-get dist-upgrade
uname -a
reboot

Ich habe mir dann „die volle Packung Proxmox“ installiert:

apt-get install proxmox-ve ssh postfix ksm-control-daemon open-iscsi systemd-sysv mailutils

Nach einem erneuten Reboot zeigte ein uname -a nun

Linux hostname 4.4.59-1-pve #1 SMP PVE 4.4.59-87 (Tue, 25 Apr 2017 09:01:58 +0200) x86_64 GNU/Linux

Also frisch in Proxmox unter https://server.domain:8006 mit dem PAM Account für root angemeldet und dort eine neue VMBR0 angelegt, die erst einmal unkonfiguriert blieb.

Reboot. Proxmox übernimmt sonst die Änderungen nicht.

Dann das restlichen Netzwerk-Setup von Hand erledigt.

Die Basis-IP des Server war

78.78.78.82

Dazu kamen zwei über den Robot zusätzlich bestellte IPs

78.78.78.86
78.78.78.90

Es ergab sich damit für /etc/network/interfaces diese Konfiguration:

auto lo
iface lo inet loopback
iface lo inet6 loopback

# ETH0
auto eth0
iface eth0 inet static
  address 78.78.78.82 # Server Basis IP
  netmask 255.255.255.255 # Netzmaske neu gesetzt
  gateway  78.78.78.65 # wird von Hetzner mitgeteilt
  pointopoint 78.78.78.65 # PTP auf das Gateway

# VMBR0

auto vmbr0
iface vmbr0 inet static
  address 78.78.78.82 # Server Basis IP
  netmask 255.255.255.255 # Netzmaske neu gesetzt
  bridge_ports none
  bridge_stp off
  bridge_fd 0
    up ip route add 78.78.78.86/32 dev vmbr0 # erste VM mit erster Zusatz-IP
    up ip route add 78.78.78.90/32 dev vmbr0 # zweite VM mit zweiter Zusatz-IP

# IPv6 Config 

iface eth0 inet6 static
        address  121:121:121:121::2
        netmask  128
        gateway  fe80::1
        up ip -6 route add default via fe80::1 dev eth0
        up sysctl -p

iface vmbr0 inet6 static
        address 121:121:121:121::2
        netmask 64

Für jede weitere IP, die im vorliegenden Fall noch kommen mag, muss man für die VMBR0 eine Zeile ergänzen. Ich denke, das Schema ist nachvollziehbar. Die restliche IP-Konfiguration läuft über Proxmox direkt (siehe unten).

Es folgt die Anpassung von /etc/sysctl.conf

# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
net.ipv6.conf.all.forwarding=1

Reboot.

Und ab jetzt geht es klickend in Proxmox weiter. Zuerst zieht man sich die benötigten Templates (hier: für Ubuntu und Debian). Dann legt ein Klick auf das entsprechende Icon die erste VM als LXC an. Der erste Container erhält als IP im hier vorliegenden Fall

78.78.78.86/32

und für seine Gateway-Adresse die Basis-IP des Servers:

78.78.78.82

Der Rest – also die Ressourcenzuteilung usw – war für die Testmaschinen dann eine Geschmacksfrage.

Die Verwaltung (Softwareinstallation etc.) der einzelnen VMs nahm ich lieber direkt auf dem Wirt vor. Da reagiert die Shell einfach zügiger als jedes Frontend. Ein

lxc-attach -n 100

bindet den zuerst erzeugten LXC an die Rootshell.

Ein internes Netzwerk, über das die VMs untereinander sprechen können, ist auch schnell eingerichtet: Auf dem Host oder auch über Proxmox in die /etc/network/interfaces

auto vmbr1
iface vmbr1 inet static
        address  10.16.1.0
        netmask  255.255.0.0
        bridge_ports none
        bridge_stp off
        bridge_fd 0

Reboot und in Proxmox dann der jeweiligen Maschine eine neue Netzwerkkarte (eth1) geben, die an die vmbr1 gebunden wird, passende IP und Netzmaske setzen – voila.

Erste Messungen mit iperf geben so um die 55 Gbit/sec.

Erstes Ergebnis:

  • Netzwerksetup, Einrichtung, Verwaltung laufen rund und zügig ab
  • Die Templates für Proxmox kommen ziemlich „dick“ mit Software ausgestattet daher. So würde ich diese ungern als Basis für eigene VMs nutzen

OMD auf Ubuntu 16.04 quick setup

Mein hausinterner Monitoring- und Nameserver wollte sich nicht ohne Zicken von 14.04 auf 16.04 schubsen lassen. Also setzte ich diesen neu auf und durfte dann OMD neu installieren. Meine Notizen:

wget https://mathias-kettner.de/support/1.2.8p15/check-mk-raw-1.2.8p15_0.xenial_amd64.deb
dpkg -i check-mk-raw-1.2.8p15_0.xenial_amd64.deb
apt-get install -f
service apache2 restart
omd create bdjlhome
su - bdjlhome

In /omd/sites/bdjlhome ist dessen Homeverzeichnis gelandet. Dort dann ausführen:

omd config
omd start
exit

Das OMD Config stellte ich auf Web GUI sowie Multisite und übernahm dort im Wesentlichen die vorhandenen Einstellungen:

Um den Monitoring-Server ebenfalls überwachen zu können folgte die Installation und Konfiguration (die dann auf allen zu überwachenden Clients ebenfalls durchgeführt werden muss):

apt-get install check-mk-agent xinetd nagios-plugins-basic
apt-get install -f

Die /etc/xinetd.d/check_mk sieht nach den nötigen Anpassungen wie folgt aus:

service check_mk
{
        type           = UNLISTED
        port           = 6556
        socket_type    = stream
        protocol       = tcp
        wait           = no
        user           = root
        server         = /usr/bin/check_mk_agent

        # If you use fully redundant monitoring and poll the client
        # from more then one monitoring servers in parallel you might
        # want to use the agent cache wrapper:
        # server         = /usr/bin/check_mk_caching_agent

        # configure the IP address(es) of your Nagios server here:
        only_from      = 127.0.0.1

        # Don't be too verbose. Don't log every check. This might be
        # commented out for debugging. If this option is commented out
        # the default options will be used for this service.
        log_on_success =

        disable        = no
}

Für die Clients muss dann bei only_from die IP des Monitoring-Servers eingetragen werden.

Weiter geht es für die mrpe.cfg:

mkdir /etc/check_mk
vi /etc/check_mk/mrpe.cfg

Hier schaltete ich APT und SSH Checks frei:

# APT Check
APT_CHECK /usr/lib/nagios/plugins/check_apt
# SSH Check
SSH_CHECK /usr/lib/nagios/plugins/check_ssh localhost

Fail2ban soll ebenfalls überwacht werden:

vi /opt/omd/sites/bdjlhome/local/share/check_mk/agents/plugins/fail2ban

In der Config für diesen Agent steht

#!/bin/sh
echo '<<<fail2ban>>>'
if [ -x /usr/bin/fail2ban-client ]; then
JAILS=`/usr/bin/fail2ban-client status | grep "Jail list" | tr -s [:blank:] | cut -f2- -d':' | sed -e 's/,/ /g'`
        echo "Detected jails: $JAILS"
        for jail in $JAILS
        do
                /usr/bin/fail2ban-client status $jail
        done
fi

und dann muss diese noch ausführbar sein:

chmod 755 /opt/omd/sites/bdjlhome/local/share/check_mk/agents/plugins/fail2ban

755 ist etwas arg dick aufgetragen, tut es aber für’s Heimnetz.

Dann den xinetd und den Apache neu starten:

service xinetd restart
service apache2 restart

Ob überhaupt Daten ankommen ist zu prüfen:

telnet localhost 6556

Die Anmeldung an OMD erfolgt im Browser an der lokalen IP (bei mir an dieser Stelle noch ohne Namensauflösung: https://10.16.X.X/bdjlhome) als omdadmin mit omd als Passwort, das nach dem ersten erfolgreichen Login geändert wird.

Im Main Menü unter Hosts wird dann der lokale Monitoring-Server eingerichtet. Rechts oben gibt es den Schalter New host. Diesem einen Namen und die passende IP (in diesem Fall 127.0.01) geben und über Save & go to Services speichern. Wenn alles klappt lässt sich hier gleich eine Service discovery durchführen und für diesen Host abspeichern.

Zurück im Main Menu: Wie üblich bei OMD müssen die Änderungen durch eine Reihe von Klicks auf farblich hervorgehobene Schalterchen erst aktiviert werden.

Ein Klick auf Hosts zeigt die Liste der schon eingetragenen Server an. Zur nachträglichen Service Discovery folgt der Klick auf das Icon „Notizbrett mit grünem Haken“ das im Overlay „Edit the services of this hosts, do a service discovery“ anzeigt.

… und nach ein wenig mehr Geklicke sind die lokalen Hosts eingetragen. Praktisch ist die Notification Funktion. Die warnt mich per Mail, wenn auf einem der Rechner etwas aus dem Lot gerät. In Ermangelung einer statischen IP verwende ich hierzu einen Postfix als Satellitensystem – aber das ist eine andere Geschichte.