Das Einrichten geht viel einfacher, die Beschreibung ist im Housekeepingartikel
Das ist streng genommen kein NetBox Thema, ich lasse es aber in der Kategorie NetBox, weil es zum vorherigen Beitrag gehört. Das Senden von Logfiles sollte bei Anwendungen, die nicht in Python geschrieben sind bzw. nicht den Python SysLogHandler verwenden, wesentlich einfacher einzurichten sein.
Nochmal der Hinweis vorab, ich präsentiere hier keine ausführlich getesteten fertigen Lösungen. Das Blog ist eher ein “live Mitschnitt” meiner Aktivitäten, damit ich weiß, was ich wann und warum getan habe (um es ggf. später wieder Schritt für Schritt rückgängig machen zu können). Ich werde im Verlauf sicherlich noch diverse Dinge umbauen, daher sollte man das, was ich hier so tue, keinesfalls auf einem Produktivsystem 1:1 übernehmen! Ich lasse mir zur Zeitersparnis exzessiv von KIs helfen, sei es bei Zusammenfassungen von Anleitungen oder beim Debuggen von Code. Ich versuche so gut es geht nachzuvollziehen, was die KI vorschlägt, und übernehme nur Code, den ich auch selbst, zumindest meine, verstanden zu haben. Jeder muss/sollte das Gleiche tun und sich keinesfalls blind auf meine Lösungen verlassen.
Zuerst werde ich Technitium einbinden. Da ich die Einbindung der einzelnen Dienste, wie oben erwähnt, im Verlauf sicher noch anpassen werde, bekommt jeder Dienst einen eigenen Beitrag. Aktualisierungen werde ich zukünftig immer in der ersten Zeile des jeweiligen Artikels mit Datum kennzeichnen. Ich hoffe, dass die Übersicht so erhalten bleibt.
Zunächst rsyslog in Technitium installieren. Ich brauche rsyslog auch bei Technitium, um die Logs für Loki zu “normalisieren”:
apt update
apt install -y rsyslog
In der Shell von Technitium legen wir ein neues Template für die Normalisierung der Logs an:
Das Template ignoriert bewusst den in der Logzeile enthaltenen Text-Timestamp und setzt stattdessen die tatsächliche UTC-Empfangszeit von rsyslog ein, unabhängig davon, ob die Quelle selbst schon in UTC loggt oder nicht. Das Template muss auf jedem Host, der an Loki sendet, separat existieren (Templates werden pro rsyslog-Instanz definiert, nicht global geteilt).
Nun noch die eigentliche Config-Datei für das Logging:
cat > /etc/rsyslog.d/97-technitium-corelog.conf << 'EOF'
module(load="imfile" mode="inotify")
input(type="imfile"
File="/etc/dns/logs/*.log"
Tag="technitium-core:"
Severity="info"
Facility="local0"
ruleset="forwardCoreLog"
freshStartTail="on"
startmsg.regex="^[0-9]{4}-[0-9]{2}-[0-9]{2} [0-9]{2}:[0-9]{2}:[0-9]{2}")
ruleset(name="forwardCoreLog") {
if tolower(msg) contains "xception" or tolower( msg) contains "rror" or tolower(msg) contains "ailed" or tolower( msg) contains "imeout" then {
action(type="omfwd" target="<LOKI-LXC-IP>" port="1514" protocol="tcp"
template="RFC5424_UTC")
}
}
EOF
Hier muss man die passende IP-Adresse von Alloy/Loki entsprechend eintragen/anpassen. Anschließend die Syntax der Config-Datei prüfen und, wenn es ohne Fehler durchläuft, gleich starten:
Das Einrichten geht viel einfacher, die Beschreibung ist im Housekeepingartikel
Das Aktualisieren der IPAM-Einträge funktioniert weiterhin gut, und ich war eigentlich gerade dabei, das erste Ansible-Playbook auszuarbeiten, als ich gedanklich auf ein weiteres Problem gestoßen bin.
Beim Zusammenspiel von NetBox, Ansible und Technitium ist es notwendig, dass alle drei Beteiligten mit der gleichen Uhrzeit arbeiten. Soweit ich aktuell weiß, ist bei allen dreien intern UTC die gültige Zeit. Mir ist schon vor ein paar Tagen aufgefallen, dass die NetBox-Logs ebenfalls mit UTC-Zeit angezeigt werden. In Technitium habe ich bereits bei der Installation vor mehr als zwei Jahren die Logs auf Lokalzeit, also UTC+2h (wegen der besseren Lesbarkeit), umgestellt. Ich persönlich glaube jedoch inzwischen, dass es besser wäre, wenn alle Dienste die Ereignisse mit UTC-Timestamps loggen würden. Die Services/Programme, mit denen man später die Logs darstellt (z. B. Grafana), können dann die Umrechnung in die jeweilige Lokalzeit übernehmen. Das ist auch von großem Vorteil, wenn man Geräte in einer anderen Zeitzone hat (in dem Fall oft auch ohne Sommerzeit). Das Logging habe ich daher in Technitium wieder auf UTC zurückgestellt.
Als zentrale Datenbank für die Logs wird oft Loki/Alloy empfohlen oder der sogenannte ELK-Stack. Der ELK-Stack ist scheinbar deutlich komplexer einzurichten, wohl auch eher so ein Docker-Ding (Nachtrag: hier lag ich falsch, kann man genauso leicht installieren wie NetBox) (ich mag Docker einfach nicht), und da ich eigentlich viel lieber bei NetBox/Ansible weitermachen will, wähle ich den einfacheren Weg über Loki. Loki und Grafana gibt es bei den Community-Scripts als LXC, also muss ich mir hier wegen zukünftiger Updates keine allzu großen Sorgen machen. Ein sauberes zentrales Logging ist von größtem Vorteil zur geräteübergreifenden Fehlersuche und spätestens dann extrem zeitsparend, sobald ich anfange, andere Geräte via Ansible zu steuern. Von daher werde ich das Thema zentrales Logging hiermit vorziehen.
Ich installiere zunächst Loki und Grafana auf PVE und gebe ihnen, wie inzwischen auch dem NetBox-LXC, feste IPs. Die IPs dieser Dienste sollten sich nicht ändern können, sonst funktioniert das Zusammenspiel der einzelnen Dienste nicht mehr.
In Grafana verbinde ich zunächst das Loki-LXC als neue Datenquelle.
Es reicht bereits, die IP-Adresse und den Port des LXC mit Loki anzugeben, um eine Verbindung herstellen zu können.
Das muss ich natürlich später noch weiter absichern, aber zum Testen reicht es zunächst. Damit die Logs aber erst mal irgendwie in Loki “reinkommen”, brauche ich noch das Tool Alloy. Alloy empfängt Logs und/oder sammelt diese aktiv bei den hinterlegten Geräten ein und leitet sie anschließend an Loki weiter. Loki indexiert und komprimiert die Logs und regelt wohl auch das Aussortieren alter Logs. Alle drei Teile kommen vom gleichen Entwicklerteam, das sollte also gut zusammenarbeiten. Alloy ist weder Teil des Grafana-LXCs noch bei Loki dabei. Scheinbar hatten andere Leute bereits ähnliche Gedankengänge wie ich. MickLesk ist einer der Maintainer der Community-Scripts, und deswegen werde ich mich an seine Empfehlung halten. Ich hatte bereits überlegt, ob Alloy ein eigenes LXC benötigt. Erfreulicherweise ist das Nachrüsten von Alloy gar “nicht so deep”, wie man heute sagen würde. Es lässt sich mit einem simplen
apt install alloy
in dem LXC mit Loki nachinstallieren.
Bei der Installation des Loki-LXCs sind mir noch zwei weitere Punkte ins Auge gefallen. Man kann das Auswahlmenü mit
update
in der Shell des Loki-LXCs jederzeit erneut aufrufen.
Ich wähle beim zweiten Durchlauf auch noch Option 2, damit alle ankommenden Adressen ihre Logs bei Alloy/Loki loswerden können. Das werde ich in Zukunft vermutlich noch einschränken - als kleiner Reminder für mich selbst.
Bis hierher war die Einrichtung noch trivial, und ich wollte das Thema eigentlich in ein bis zwei Stunden abhaken. Ich musste dann aber doch fast zwei Tage meiner Freizeit aufwenden, um die Logs von NetBox in Loki zu bekommen. Ich stelle hier meine Konfiguration vor; sie lässt sich aber bestimmt besser einrichten als in meinem Beispiel. Für mich passt es aktuell, und ich kann das Logging im Verlauf sukzessive noch weiter verbessern.
In der /etc/alloy/config.alloy des Alloy/Loki-LXCs habe ich am Ende folgenden Codeblock angehängt:
.
Wie oben schon erwähnt, habe ich es zunächst nicht geschafft, die Logs von NetBox selbst über Alloy an Loki zu senden. Nach zwei Tagen des Herumprobierens meine ich, das Problem lokalisiert zu haben. NetBox ist eine Python/Django-Anwendung, und scheinbar sendet der SysLogHandler von Python keine RFC5424-konformen Logmeldungen. Alloy erwartet aber genau dieses Format und verwirft alle nicht RFC5424-konformen Nachrichten einfach. Das Problem sollte bei meinen anderen LXCs nicht auftreten, denn kein anderer meiner laufenden Services ist meines Wissens in Python geschrieben. Werde ich im Verlauf noch merken…
Jedenfalls musste ich in dem NetBox-LXC noch rsyslog nachinstallieren. rsyslog fungiert hier als Übersetzer: Es nimmt die minimale Nachricht von NetBox lokal entgegen (über /dev/log), reichert sie mit allen fehlenden Feldern an (Timestamp, Hostname, App-Name, Version) und schickt erst dann ein vollständiges, korrektes Paket weiter.
Das Anhängsel ;RSYSLOG_SyslogProtocol23Format war dabei der Kern meines zweitägigen Problems: Ohne dieses Template sendet rsyslog standardmäßig im älteren RFC3164-Format, das Alloy nicht akzeptiert.
Nun muss man in dem NetBox-LXC noch die Config bezüglich des Loggings etwas anpassen. Bei mir war der Logging-Teil in der Config initial leer.
Um sicherzugehen, dass NetBox nicht das interne Logging zugunsten der neuen externen Lösung ganz deaktiviert, habe ich sicherheitshalber beide Handler
['console', 'syslog']
in meiner Config eingetragen. Danach NetBox neu starten mit
systemctl restart netbox netbox-rq
Ich hoffe, das passt so… es scheint jedenfalls zu funktionieren. Hier noch der Screenshot einer Abfrage von Loki via Grafana.
Man sieht schön die Aktivität des Dynamic IP Script aus dem vorherigen Beitrag, das momentan noch alle 30 Minuten ausgeführt wird. Grafana hat dabei auch die UTC Timestamps automatisch in die Lokalzeit umgerechnet.
Wie man auf dem letzten Bild sieht läuft das Logging in NetBox intern weiterhin auf UTC.
So, wie das Hofbräuhaus, kennt ein jeder Münchner Radio 2Day, den Sender aus „Valley Churchen” (Thalkirchen). Seit über 30 Jahren läuft der beste Radiosender der Welt während meiner (Computer-)Aktivitäten im Hintergrund. Man muss Peter Bertelshofer, die „Stimme aus Sendling”, und sein restliches Team nach ein paar gemeinsamen Stunden einfach ins Herz schließen. 😎
Das DHCP-Plugin ist zwar noch als Beta markiert, ich probiere es aber natürlich trotzdem aus 😎 Da es aktuell (noch) keine Dokumentation für das Plugin gibt, habe ich Claude den Sourcecode des Plugins auf GitHub analysieren lassen. Man kann über KIs denken, wie man will, aber als Werkzeuge zur Code- und/oder Fehleranalyse sind sie ausgezeichnet geeignet.
Da das Plugin noch in aktiver Entwicklung ist, könnten sich einige Einstellungspunkte in Zukunft ändern, daher erwähne ich die einzelnen Schritte der Einrichtung hier nicht. Claude und die meisten anderen KIs leiten einen hier aktuell gut durch, wenn man irgendwo nicht weiterkommt. Ich werde daher nur ein paar Screenshots von der Einrichtung zeigen und den Textteil irgendwann später ergänzen, wenn das Plugin nicht mehr in der Betaphase ist.
Das Anlegen der IP-Reservierungen muss man von Hand erledigen.
Es bleibt in Bezug auf DHCP aber noch eine Sache abzudecken, und zwar den Fall, dass sich Geräte (Handys etc.) im LAN anmelden, eine dynamische IP von Technitium bekommen und später wieder (manchmal für immer) verschwinden. Das wäre z. B. in einem WLAN-Gastnetz der Fall oder wenn Endgeräte ihre MAC-Adressen rotieren (iPhones z. B.). Die entsprechenden Geräte bekommen von Technitium dynamisch per DHCP eine Adresse zugewiesen, und diese Adressen sollten irgendwie auch in NetBox auftauchen. Wenn das Lease solcher Geräte abgelaufen ist und sie wieder aus dem WLAN-Netz verschwunden sind, sollen auch die IPAM-Einträge wieder entfernt werden. Solche Geräte kann ich in NetBox nicht als Devices abbilden, denn dann müsste ich u. U. dynamisch neue Hersteller, Geräteklassen, Geräte und Schnittstellen in NetBox erzeugen lassen. Es reicht mir vollkommen, in NetBox den Hostnamen und die korrespondierende IP-Adresse des Geräts sehen zu können. Die Technitium-API bietet zum Glück die Möglichkeit, eine Liste mit allen aktuellen Leases abzufragen. Ich lege hierfür in Technitium einen neuen User mit eingeschränkten Rechten an. Für den neuen User kann man in der GUI von Technitium auch gleich noch ein API-Token erzeugen. Der API-Token wird nur einmalig angezeigt; ich lege ihn daher in meinem Passwortmanager (KeePassXC/KeePassium) ab.
Man kann die API-Abfrage nun im Browser testen mit
und bekommt alle aktuellen Leases angezeigt. Dabei sind vor allem die Leases mit dem Zusatz Dynamic von Interesse. Dies sind die Adressen, für die keine Reservierung vorhanden ist.
Als nächsten Schritt habe ich mit dem guten Claude ein kleines Script erstellt, das man genauso in NetBox einbinden kann wie die Scripte von Peter Eckel. Man findet es in einem GitHub-Repository, das ich in meinem Account neu angelegt habe. Evtl. werde ich dort (bei Bedarf) in Zukunft noch weitere Scripte ergänzen. Claude hat auch noch ein README erstellt, das die Einrichtung bereits sehr gut beschreibt. Damit das Script funktioniert, muss man zusätzlich ein neues Custom Field einrichten
Das Script ruft bei jedem Durchlauf über die Technitium-API die Liste mit den Leases ab, filtert nur die mit “Dynamic” heraus, prüft, ob es bereits einen IPAM-Eintrag gibt, ergänzt einen fehlenden IPAM-Eintrag (inklusive Tag) und entfernt IPAM-Einträge, für die es kein korrespondierendes Lease mehr gibt. Ich habe als Intervall aktuell 30 Minuten eingestellt, werde aber vermutlich auf 15 Minuten umstellen. Das Script befindet sich noch in der Testphase, scheint aber bisher gut zu funktionieren.
Technitium
IPAM in NetBox
Ich lasse es mal ein paar Tage laufen und nehme noch ein paar der IP-Reservierungen bei Technitium raus, um eine schöne Rotation zu simulieren. Wenn das Script die nächsten Tage ohne Probleme sauber durchläuft und meine IPAM nicht vollmüllt, werde ich als nächsten Schritt die Steuerung von Technitium via NetBox/Semaphore (Ansible) in Angriff nehmen. Proxmox lässt sich wohl auch sehr gut über NetBox steuern, das wird dann vermutlich als nächstes Thema drankommen.
Ich habe inzwischen fast alle Geräte von beiden Subnetzen in Netbox erfasst. Zusätzlich habe ich in IPAM den Schnittstellen der Geräte die aktuell gültigen IP-Adressen zugeordnet. Die beiden DNS-Zonen (inkl. der aktuell verwendeten DNS-Namen) habe ich ja bereits im Vorfeld von den beiden Technitium-Servern in Netbox abgerufen. Peter Eckel hat noch ein weiteres praktisches Script geschrieben, das man genauso in Netbox einbindet, wie das bereits zuvor erwähnte Script. Es erscheinen nun zwei neue Auswahlmöglichkeiten
Mit IPAM Hostname Updater kann man die Hostnamen aus der zuvor importierten Zone(n) in die einzelnen manuell angelegten IPAM-Einträge importieren. Die Hostnamen werden nur in IPAM übernommen, wenn man zusätzlich den Haken bei Overwrite setzt, andernfalls wird nur ein „dry run” durchgeführt. Das Script kann man beliebig oft ausführen.
Sind nur wenige Geräte im Netzwerk, geht es vermutlich schneller, die Hostnamen von Hand einzutragen. In meinem Fall waren es aber so viele Hostnamen, dass sich der Aufwand mit den Scripten von Peter Eckel gelohnt hat. Sobald alle IPAM-Einträge (mithilfe des Scripts) einen Eintrag für den Hostnamen bekommen haben, kann man in Netbox-DNS alle importierten A-Records (SOA und NS nicht löschen) in den DNS-Zonen wieder löschen (ergibt Sinn… s.u.).
In Zukunft möchte ich, um z. B. die IP für ein Gerät zu ändern, nur noch eine Änderung im Bereich IPAM bei Netbox vornehmen müssen. Die Einträge in der DNS-Zone (inkl. PTR) sollen dann von dem DNS-Plugin in Netbox automatisch mit angepasst werden. Für die PTR-Einträge meiner beiden Zonen brauche ich vorher noch jeweils eine passende Reverse-Zone. Die beiden Reverse-Zonen lege ich manuell an. Im Screenshot habe ich eine Reverse-Zone für den Adressbereich 192.168.1.0/24 angelegt. Die Screenshots in meinen Beiträgen passen leider nicht immer 100 % zum Text.
Damit das Netbox-DNS-Plugin diese Änderungen vornehmen kann, muss man im Reiter des DNS-Plugins unter Ansichten (Views) noch die gewünschten IPAM-Prefixe angeben, sonst erfolgen keine dynamischen Updates der DNS-/PTR-Einträge. Ich habe hier die Prefixe meiner beider Zone angegeben.
Eine Änderung der IP Adresse eines Geräts in IPAM, führt nun auch zu einer sofortigen Änderungen bei den DNS Einträgen (inkl. PTR). Als nächstes muss der DHCP Teil in Netbox erldigt werden, danach kann ich mich mit der Übertragung an die beiden Technitium Server via Semaphore/Ansible kümmern.
