NFS, Samba, chrony, Unbound und Kea per Kommandozeile prüfen: eine Checkliste

Ziel

Aus einer Shell bestätigen, dass jeder in dieser Serie behandelte Infrastrukturdienst tatsächlich läuft, erreichbar ist und sich im erwarteten Zustand befindet – als Fünf-Minuten-Check nach einem Deployment, nach einem Neustart oder vor der Eskalation einer Störungsmeldung.

Voraussetzungen

Shell-Zugriff auf den Server (und für einige Prüfungen ein Client, der den Server erreichen kann); die jeweiligen Client-Werkzeuge sind installiert (rpcbind/nfs-utils, samba-common-bin, chrony, unbound, kea-*).

Schritte

1. NFS: Bei einem Server, der noch NFSv3 anbietet, zeigt showmount -e <server> auf einem Client die Export-Liste des NFS-Servers an, und rpcinfo -p <server> kann eine Liste aller registrierten RPC-Programme (nfs, mountd, nlockmgr) ausgeben. Auf einem reinen NFSv4-Server schlagen beide Befehle konstruktionsbedingt fehl (kein MOUNT-Protokoll, rpcbind oft maskiert); stattdessen auf dem Server exportfs -v und ss -tn state established '( sport = :2049 )' für verbundene Clients prüfen.
2. Samba, auf dem Server als root: smbstatus ist ein sehr einfaches Programm, das die aktuellen Samba-Verbindungen auflistet – ohne Argumente aufgerufen liefert es eine Live-Ansicht der verbundenen Clients, geöffneten Dateien und Sperren. Ein leeres, fehlerfreies Ergebnis auf einem Server, den gerade niemand nutzt, ist ein korrektes Ergebnis und kein Problem.
3. Zeit, auf dem Server und auf beliebigen Clients: chronyc tracking ist der Befehl, der Kennwerte zur Leistung der Systemuhr anzeigt – Reference ID, Stratum, Offset. Ein über wiederholte Prüfungen wachsender Offset bei System time oder ein Leap status von Not synchronised sollte untersucht werden. Auf einem NTP-Server zeigt chronyc clients (als root), welche Hosts ihn abfragen.
4. DNS-Auflösung, auf dem Resolver als root: unbound-control status zeigt den Serverstatus an und beendet sich mit einem Wert ungleich null, wenn der Daemon nicht auf seinem Control-Port lauscht. So lässt sich schnell unterscheiden, ob «Unbound ausgefallen ist» oder «Unbound läuft, aber fehlerhaft antwortet»; im zweiten Fall ist stattdessen ein dig-Test dagegen nötig.
5. DHCP, auf dem Server: Änderungszeitpunkt der Lease-Datei prüfen und ihre letzten Einträge anzeigen (den Standardspeicherort nennt der Kea-Artikel dieser Serie). kea-shell, das einen REST-Client für die Kea-Server bereitstellt, kann zusätzlich Befehle wie status-get an den laufenden Daemon senden, sofern ein HTTP-Control-Endpunkt konfiguriert ist (der Control Agent oder ab Kea 3.0 der daemoneigene HTTP-Control-Socket); für Lease-Abfragen ist ausserdem der Hook lease_cmds erforderlich.
6. Das Ergebnis jeder Prüfung mit Zeitstempel an einer Stelle festhalten, die eine zweite Person einsehen kann, bevor aus einem einzelnen Durchlauf auf einen gesunden oder gestörten Dienst geschlossen wird.

Erwartetes Ergebnis

Jeder Befehl antwortet zügig, und die Ausgabe entspricht dem aktuellen, bekannten Zustand des Dienstes. Ein gestoppter Daemon lässt seine lokale Prüfung meist sofort fehlschlagen (connection refused), während eine hängende Prüfung eher auf ein Firewall- oder Routingproblem hindeutet.

Grenzen und Prüfbasis

Ein sauberer Status eines dieser Werkzeuge bestätigt nur, dass der Daemon läuft und über seine eigene Control-Schnittstelle antwortet, nicht dass jeder Zugriffspfad für Clients funktioniert – showmount -e beweist beispielsweise nicht, dass ein echtes Mounten gelingt, sondern nur, dass die Export-Liste ausgeliefert wird. Wenn eine Meldung besagt, ein Dienst sei nicht erreichbar, sollten die Prüfungen von mehr als einem Standpunkt aus erfolgen (lokal und von einem Client), da eine serverlokale Prüfung gelingen kann, während ein Firewall- oder Routingproblem echte Clients weiterhin blockiert.