Jüngstes LLM-Anwendungsbeispiel meinerseits: eine mittels ollama lokal laufende llama3.2:3b-Instanz führt für mich wiederkehrende Kommandos auf meinem „Lass-mich-Dinge-ausprobieren“-Rechner im lokalen Netzwerk aus. Im Video sieht man eine Sequenz, wo gerade Updates eingespielt werden:
LLM verbindet sich via SSH zu Remote-PC zum Update-Tango
Was man im Video sieht:
Prompt -> Update the packages on the PC. It's a Fedora 43 Workstation.
Im rechten Fenster läuft im Terminal das Update via dnf.
Links sieht man die Spikes auf meiner GPU, die via Vulkan bei der Inferenz unterstützt.
Was man im Video nicht sieht:
llama3.2 durfte sich aus einem Satz Werkzeuge selbst aussuchen, was am besten für den Prompt funktioniert. Die Entscheidung fiel aufs Terminal. In der Konfiguration hatte ich vorgegeben, dass die Verwendung des Terminals immer eine SSH-Verbindung zu meinem lokalen „Lass-mich-Dinge-ausprobieren“-Rechner einschließt (=fixe Vorgabe der Ziel-IP-Adresse, aber ohne Aushändigen der Credentials an llama3.2).
Die Credentials habe ich SSH manuell übergeben. Deswegen sieht man auch mehrere Prompts, die davor abgeschickt wurden, das läuft noch nicht ganz stabil.
Nach Abschluss des Updates hat llama3.2 die Terminal-Response ausgewertet und mir als Zusammenfassung präsentiert, was wie passiert ist.
Was ist das Ergebnis für mich:
Ein Proof-of-Concept, den ich mal selbst durchspielen wollte.
Lokale LLM(s) verwende ich schon länger für verschiedene Aufgaben, aber die Automatisierungsmöglichkeiten auf einem Rechner will ich noch mehr ausloten.
Lessons Learned:
Trennung von lokaler Automatisierung und lokalem Berechtigungskonzept klappt gut, für mich wichtig, weil „meine“ Credentials auch einer lokalen LLM nicht anvertrauen möchte. Credentials, die der LLM zugeordnet sind, natürlich schon (z.B. eigener Benutzer mit eigener Berechtigungsstufe).
Die LLM auf die GPU zu bekommen, war wenig Aufwand.
Die LLM-Laufzeit für stupide Update-Tasks steht natürlich in keinem Verhältnis, aber das direkte Deployment eines gerade erst Vibe-gecodeten Web Services auf meinen „Lass-mich-Dinge-ausprobieren“-Rechner, etc. schon viel mehr. 😉
Die Anforderungen ans hauseigene WLAN steigen, also war es wieder an der Zeit nachzuschauen, was mit der bestehenden Infrastruktur (noch) möglich ist. Folgende Ansatzpunkte hatte ich vorab identifiziert:
Festhalten des Status Quo
Optimieren des WiFi-Channels
Festlegen der relevanten IEEE 802.11-Standards
Hinzufügen des 5 GHz-Frequenzbandes
Kontrollieren der Sicherheitsmechanismen
Da ich gerne mit dem arbeite, was schon da ist, bevor etwas Neues bei der Tür hereinkommt und motiviert durch einen Bekannten, der ein ähnliches Problem hat, findet sich hier eine kurze Mitschrift zum Vorgehen und der Erkenntnisse unterwegs.
Festhalten des Status Quo
Der WLAN-Router kommt von meinem ISP und gestattet erstaunlich viele Einstellmöglichkeiten im Admin-Panel. In den letzten Monaten hatte ich das „Gefühl“, dass der Datendurchsatz durch den WLAN-Router begrenzt ist. Mehr Endgeräte tummeln sich im Netz und einige datenintensiven Dienste werden konsumiert, sodass sich parallel stattfindende, beruflich bedingte Video-/Online-Konferenzen des Öfteren gestört fühlten. Hier ein paar Eckpunkte:
OEM-WLAN-Router vom ISP
IEEE 802.11b/g/n auf 2,4 GHz inkl. Channel-Optimierung konfiguriert
Keine Repeater installiert
Alle Endgeräte sind zumindest IEEE 802.11n-fähig.
Mehrparteiengebäude in der Stadt
Optimieren des WiFi-Channels
In den letzten Jahren gingen mehr und mehr WLAN im Umfeld online. Der erste Verdacht lag auf der Überbelegung des WiFi-Channels. Der vorliegende Router gibt vor eine Kanaloptimierung zu beherrschen , welche auch aktiviert war.
Sichtlich machte die Kanaloptimierung nicht all zu viel, weil der vor Jahren ermittelte Kanal 11 war noch immer ausgewählt, aber heillos überfrachtet. Da mein ISP mehrere Parteien in unserem Haus ausstattet, ist der Kanal 11 wohl der Default und somit in meinem Fall ein faulty default.
Um zu ermitteln, welche WLAN in der Nähe sind und auf welchen Kanälen sie funken, habe ich auf nmcli, das Command-Line-Interface von NetworkManager, zurückgegriffen. Der folgende Aufruf (in Anlehnung an user278801) hat mir die Grunddaten für die WLAN-Analyse geliefert:
~$ watch "nmcli -f "CHAN,BARS,SIGNAL,SSID,MODE,RATE,SECURITY,IN-USE" d wifi list | sort -n"
Das Ergebnis im Terminal:
nmcli mit den umliegenden WLAN sortiert nach Channel nach der Optimierung im Essbereich
Um ein möglichst gutes Gesamtbild zu bekommen, habe ich diese Analyse in allen Zimmern durchgeführt. Bei der Auswahl des neuen Kanals wählte ich unter Berücksichtigung dieser Quelle den Kanal 9 für das 2,4 GHz-WLAN.
Festlegen der relevanten IEEE 802.11-Standards
Der WLAN-Router wurde im Jahr 2018 eingerichtet. Damals gab es noch Überlegungen, Geräte mit dem schon damals veralteten Standard IEEE 802.11g einzubinden. Dementsprechend wurde die Kompatibilitätseinstellung für den Mischbetrieb nach IEEE 802.11b/g/n gewählt. Mittlerweile unterstützt jedes Endgerät in unserem Haushalt zumindest IEEE 802.11n, was somit auch die neue Festlegung geworden ist.
Hinzufügen des 5 GHz-Frequenzbandes
Ähnlich war es damals mit des 5 GHz-Frequenzbandes. 2018 konnten nicht alle Endgeräte davon profitieren, die Performance im 2,4 GHz-Frequenzband ausreichend. Auch dieses wurde aktiviert, womit nun die meisten Endgeräte selbst entscheiden, in welchem Frequenzband sie bessere Bedingungen vorfinden.
Kontrollieren der Sicherheitsmechanismen
Auch hier gab es eine Veränderung: Alle unsere Endgeräte unterstützen zumindest WPA2, das unsichere WPA ist nicht mehr notwendig und WPA3 wird vom WLAN-Router nicht unterstützt. Somit wurde WPA2-only als Verschlüsselungsmechanismus gesetzt.
Erkenntnisse aus der Aktivität
Linux-Distros bringen immer alles mit, was man so braucht. 😉
nmcli tut das Notwendige, wenn man tiefer in die WLAN-Analyse einsteigen möchte, gibt es spezielle Tools wie sparrow-wifi, kismet, …
Die Performance und Stabilität des eigenen WLAN ist deutlich besser geworden und das ohne neue oder zusätzliche Hardware angeschafft haben zu müssen.
Update, 2024-07-16: BSSID
Eines der Geräte hat Probleme sich mit dem 5 GHz-WLAN zu verbinden und bringt wiederholt die Aufforderung zur Passworteingabe ohne einen Anmeldeerfolg zu verbuchen. Ich vermute einen Hardware- oder Firmware-Defekt rund um das WiFi-Modul. Um dem Gerät den Versuch des ständigen Wechselns zum stärkeren Netzes auszutreiben habe ich in den WLAN-Einstellungen die BSSID fix vorgegeben.
Ermitteln kann man die BSSID z.B. mit nmcli durch Hinzufügen des gleichnamigen Parameters:
