© Andrei Dzemidzenka / 123RF.com

Richtig eingesetzt, können KI-Chatbots durchaus bei der Administration von Linux-Systemen helfen. Profunde Sachkenntnis bleibt dabei aber unersetzbar.

Mittlerweile gehört es zum Alltag, Assistenten wie Github Copilot oder webbasierte KI-Tools wie ChatGPT [1] zur Softwareentwicklung, zur Fehlersuche oder zum Verfassen von Unit-Tests einzusetzen. Dabei wird oft übersehen, dass KI-Programme auch den Alltag von Systemadministrator und Linux-Entwicklern vereinfachen können – ganz egal, ob man lediglich eine Befehlsoption sucht, komplexe administrative Aufgaben erledigt oder ein Bash-Skript schreibt. Dieser Artikel zeigt anhand mehrerer Beispiele die Möglichkeiten und Grenzen der künstlichen Intelligenz in diesem Bereich und gibt Tipps zum richtigen Prompting sowie zum Einsatz der Werkzeuge im Terminal.

Welches Tool wofür?

KI im IT-Alltag heißt keineswegs nur ChatGPT: Mittlerweile stehen eine Menge spannender Tools zur Auswahl. Für die Beispiele in diesem Artikel habe ich vorwiegend mit ChatGPT und Claude gearbeitet.

Mit ChatGPT hat OpenAI das erste praxistaugliche KI-Chat-Tool veröffentlicht. Der Bot ist seither Marktführer und liefert ausgezeichnete Ergebnisse. Für eine maßvolle Nutzung der Weboberfläche fallen keine Kosten ab. Stellen Sie jedoch binnen kurzer Zeit zu viele Fragen, drängt ChatGPT zur Umstellung auf ein bezahltes Abo. Dafür fällt eine monatliche Gebühr von rund 22 Euro an (Stand Dezember 2024).

Claude [2] ist aus meiner Sicht die spannendste Alternative zu ChatGPT. Es liefert bei technischen Fragen prägnantere, oft qualitativ zumindest gleichwertige, manchmal sogar eindeutig bessere Ergebnisse. Ich empfehle Ihnen, vor dem Abschluss eines ChatGPT-Abos unbedingt Claude auszuprobieren. Auch dieser Chatbot ködert Sie mit dem Freemium-Modell: Anfänglich ist Claude kostenlos, beantwortet aber viele Fragen in kurzer Zeit nur, wenn Sie ein Abo für 20 Euro monatlich abschließen (Stand Dezember 2024).

Daneben gibt es im Web eine Menge weiterer kostenloser KI-Chatbots, unter anderem Copilot (Microsoft), Gemini (Google) und Mistral (Mistral KI). Gerade Mistral [3] hat zuletzt in breit angelegten Vergleichstests viel Lob eingeheimst. Für Aufgaben im IT- oder Linux-Kontext konnte mich bei meinen Tests aber keines der drei Angebote überzeugen. Wenn dieser Artikel erscheint, liegen aber vielleicht schon die nächsten Versionen der Chatbots vor, womöglich mit besseren Modellen für den IT-Einsatz.

Wollen Sie kein Geld ausgeben, können Sie Sprachmodelle auch lokal auf Ihrem Rechner ausführen. Am einfachsten gelingt das mit dem Open-Source-Programm Ollama [4], auf das ich am Ende des Artikels noch näher eingehe.

Prompting als Kunst

Die Eingabe beziehungsweise Fragestellung bei KI-Chat-Systemen bezeichnet man üblicherweise als Prompt. Die Fragestellung hat einen entscheidenden Einfluss darauf, wie gut beziehungsweise zielführend die Ergebnisse ausfallen.

Große KI-Tools wie ChatGPT oder Claude verstehen zwar ausgezeichnet Deutsch. Doch jedes Sprachmodell ist nur so gut wie sein Trainingsmaterial, und davon gibt es in englischer Sprache ungleich mehr als in Deutsch. Ich habe die Erfahrung gemacht, dass englische Prompts häufig zu deutlich besseren Ergebnissen führen.

Die Bots benötigen zudem ausreichend Kontextinformation. Linux hat zwar einen großen gemeinsamen Nenner, aber die Unterschiede zwischen Distributionen und selbst zwischen verschiedenen Releases desselben Derivats fallen erheblich aus. Geben Sie deswegen im ersten Prompt unbedingt an, auf welche Linux-Version Sie sich beziehen. Bei Detailfragen sollten Sie zudem die verwendete Software nennen, zum Beispiel den Webserver oder die Versionsnummer des eingesetzten DBMS.

Auch der Detailgrad spielt eine Rolle. Benötigen Sie eine detaillierte Anleitung samt Hintergrundinformationen, weil Sie so etwas noch nie gemacht haben? Dann tippen Sie “Add background information!” Genügt eine Zusammenfassung beziehungsweise ein erster Überblick, hängen Sie “Provide an overview only!” an die Frage an.

Auf der Suche nach der richtigen Option für Curl, Find oder Grep wollen Sie vermutlich nur eine kurze Antwort. Zielführend ist hier die Ergänzung: “Be concise!”

Scheuen Sie sich nicht, eine Nachbesserung anzufordern. Entspricht das erste Ergebnis nicht exakt Ihren Wünschen, stellen Sie Folgefragen, und versuchen Sie, die Antworten in die für Sie relevante Richtung zu lenken.

Eine große Gefahr bei KI-Tools besteht darin, dass die Antworten zwar grundsätzlich korrekt ausfallen, aber nicht mehr ganz auf der Höhe der Zeit sind. Im Internet findet sich in der Regel mehr Trainingsmaterial zu alten Softwareversionen und überholten Arbeitstechniken als zu modernen Features. Oft hilft der Nachsatz: “Is there a better/more modern way to do this?”

Generell gilt das Prinzip “neues Thema, neuer Chat”. KI-Tools verwenden den Chat-Verlauf, also die Kombination aller bisherigen Fragen und Antworten, als Kontextinformation für jede weitere Frage. Haben Sie also das Gefühl, dass Ihre Konversation in einer Sackgasse gelandet ist, oder betreffen Ihre Fragen ein anderes Thema, starten Sie unbedingt einen neuen Chat.

Um das Ergebnis besser einordnen und nachprüfen zu können, sollten Sie das KI-Tool nach den verwendeten Quellen fragen: “Can you provide links to relevant pages in the documentation or other helpful sites?”

Beachten Sie, dass KI-Ergebnisse sich grundsätzlich nicht reproduzieren lassen. Wenn Sie die im Folgenden abgedruckten Prompts eingeben, werden Sie andere Antworten erhalten. Das gilt selbst dann, wenn Sie exakt dieselbe Version von ChatGPT, Claude oder einem anderen KI-Bot verwenden. Die aktuell gebräuchlichen Bots produzieren jedes Mal neuen Text respektive Code, das Ergebnis wird mal besser, mal schlechter ausfallen.

Insofern kann es sich durchaus lohnen, den Retry-Button anzuklicken beziehungsweise den Prompt “Do better!” einzutippen, wenn Sie mit dem ersten Ergebnis unzufrieden sind. Bessere Chancen auf eine gute Antwort haben Sie allerdings, wenn Sie explizit angeben, warum ein Resultat Ihren Ansprüchen nicht genügt und in welcher Hinsicht das KI-Tool die Antwort verbessern soll.

Beispiel: Wget-Script

Als Ausgangspunkt für ein erstes Beispiel dient das kommerzielle Tool Prince [5], das aus einer HTML-Datei ein PDF-Dokument macht. Die von mir verwendete, schon recht alte Version dieses Tools ist aber inkompatibel mit modernen HTTPS-Protokollen. Ein Update kam aus diversen Gründen nicht infrage.

Daher verfiel ich auf die Idee, mit Wget zuerst die HTML-Datei samt allen dort referenzierten Zusatzdateien (CSS, Bilder etc.) in ein temporäres Verzeichnis herunterzuladen. Der Konverter kann dann ohne Netzwerkprobleme die lokalen Dateien verarbeiten. Allerdings bin ich kein Wget-Experte und beherrsche die unzähligen Optionen dieses Kommandos nicht. Mein erster Prompt für ChatGPT sah so aus wie in Abbildung 1.

Abbildung 1: ChatGPT produziert ein Wget-Script.

Die erste Version des von ChatGPT gelieferten Skripts sah vielversprechend aus. Zum Ausprobieren übernahm ich den Code nahezu unverändert und ersetzte lediglich »your_command« durch den absoluten Pfad zum HTML-PDF-Konverter. Beim Testen tauchten allerdings einige Probleme auf, die ich zum Teil selbst und zum Teil mit KI-Unterstützung beheben musste. Die folgenden beiden Prompts dokumentieren diesen iterativen Prozess.

Prompt: I need to pass ‘$URL’ to ‘your_command’. However, ‘$URL’ needs to be modified to refer to the local start point generated by ‘wget’.

Prompt: ‘$URL’ can contain all sort of special characters. Can I get ‘wget’ to use ‘index.html’ as a starting point to the local file tree?

ChatGPT fand keine geeignete Option – soweit mir bekannt ist, gibt es auch keine. Es schlug vor, im temporären Verzeichnis mit Find nach HTML-Dateien zu suchen und die erste gefundene Datei zu verwenden. Diese Strategie erscheint aber fehleranfällig, wonach ich ChatGPT im folgenden Prompt fragte:

Prompt: Is it safe to simply take the first result? Perhaps there are other ‘*.html’ files within in the directory. Would it make sense to extract the base name from ‘$URL’ and use it as a search pattern with ‘find’?

ChatGPT lieferte nun Code, der meinen Wünschen entsprach. Im weiteren Verlauf stellte sich aber heraus, dass Wget die HTML-Datei zu umfassend verändert. Das Kommando »wget –mirror« lädt nicht nur die zur Darstellung der HTML-Seite erforderlichen Dateien herunter, sondern verarbeitet alle in der HTML-Seite enthaltenen Links. Das führt dazu, dass externe Links im später weitergegebenen PDF-Dokument nicht wie beabsichtigt funktionieren. Ich versuchte deshalb, ChatGPT noch einmal zu erklären, was ich eigentlich wollte:

Prompt: I want ‘wget’ to locally download all files needed to correctly display the document (i.e. CSS**+ images) *and* to change these links within the document (one document only). But I do *not* want ‘wget’ to change links to everything else. Links to external files not directly displayed within the document should stay as is. Can you help?

Aus der Antwort ging hervor, dass die ursprünglich von ChatGPT vorgeschlagene Wget-Option »–mirror« ungeeignet war. Es ist müßig, darüber zu streiten, ob ich anfänglich die Aufgabenstellung zu wenig präzise beschrieben habe oder ob die Schuld bei ChatGPT zu suchen ist. Auf jeden Fall war ein relativ langer interaktiver Prozess erforderlich, bis das in Zusammenarbeit mit ChatGPT produzierte Skript wie beabsichtigt funktionierte. Das finale Skript sehen Sie in Listing 1.

#!/bin/bash
URL=$1
shift   # shift the arguments to remove the URL
TMP_DIR=$(mktemp -d /tmp/html2pdf-tmp.XXXXXXXX)
trap 'rm -rf "$TMPDIR"' EXIT
cd "$TMP_DIR"
wget --page-requisites --convert-links --no-parent "$URL"
# if $URL contains a long query string, wget shortens the file
# name; therefore, find the newest file in the result list
# with the same base name; this should be reasonably safe
URL_NO_QUERY=${URL%%\?*}
BASE_NAME=$(basename "$URL_NO_QUERY")
MAIN_FILE=$(find . -type f -name "${BASE_NAME}*" -print0 | xargs -0 ls -t | head -n 1)
# run html2pdf
/usr/local/bin/html2pdf "$MAIN_FILE" "$@"

Wie Sie sehen, war der Weg vom ersten Versuch bis zum endgültigen Skript mit geeigneten Wget-Optionen recht lang. Die Alternative hätte darin bestanden, die Optionen in der Wget-Manpage zu suchen. Ganz einfach ist das auch nicht, weil »man wget« einen recht unübersichtlichen Text liefert, dessen Länge rund 40 Buchseiten entspricht. Schwer zu sagen, ob ich damit schneller zum Ziel gekommen wäre. Alles in allem erwies sich ChatGPT als durchaus hilfreich, aber die Ergebnisse konnten nicht vollständig überzeugen.

Beispiel: MariaDB tunen

Kürzlich habe ich einen LAMP-Server mit MariaDB eingerichtet. Die Datenbank hat großen Einfluss auf die Gesamt-Performance der dort laufenden Webapplikation. Dementsprechend habe ich mir einige Mühe beim Tuning des Datenbankservers gegeben. Hätten mich ChatGPT und Claude auch zum Ziel gebracht?

Prompt: I have installed a LAMP server running Ubuntu 24.04. The server has 64**GB of RAM. It will run as a web server (Apache), mail server (Postfix) and database server (MariaDB**10.11). I need help tuning MariaDB. MariaDB may use up to 50% of the RAM. There are many databases (about**200) with about 20**tables each. Read performance is critical. (The ratio between SELECT and INSERT/UPDATE/DELETE is about 100:1). Please give me five concise recommendations for MariaDB or Linux settings to achieve good performance.

Ich habe diese Fragestellung sowohl an ChatGPT als auch an Claude übergeben und bekam interessanterweise recht unterschiedliche Antworten. ChatGPT machte (von mir hier stark verkürzt) die folgenden fünf Vorschläge:

• Adjust the InnoDB Buffer Pool Size

[mysqld]
innodb_buffer_pool_size = 32G

• Optimize the Query Cache
• Increase the Number of InnoDB Buffer Pool Instances
• Tune InnoDB Log File Size and Flush Method
• Optimize File System and I/O Scheduler: Use the XFS or ext4 file system with the ‘noatime’ option to reduce disk I/O and set the I/O scheduler to ‘deadline’ for better performance

Die konkreten Anleitungen und Hintergrundinformationen habe ich hier aus Platzgründen stark gekürzt.

Die erste angeführte Maßnahme ist unumstritten, mit den restlichen Vorschlägen war ich weniger glücklich. Vom Einsatz des Query-Caches, den ChatGPT als Zweites vorschlägt, raten die Entwickler mittlerweile ab: Der läuft Cache single-threaded und kann damit leicht zum Engpass werden. In MySQL 8 entfiel die entsprechende Funktion bereits. MariaDB liefert das Feature noch mit, der Cache ist aber standardmäßig nicht mehr aktiv.

Die restlichen Maßnahmen dürften wohl kaum messbare Performance-Unterschiede mit sich bringen. Falls wirklich der Deadline-Scheduler zum Einsatz kommen soll (der letzte Chat-GPT-Vorschlag), gilt es zu beachten, dass er in aktuellen Kernel-Versionen (auch unter dem im Prompt erwähnten Ubuntu 24.04) mittlerweile »mq-deadline« heißt.

Auch Claude schlägt als erste und wichtigste Maßnahme vor, den Buffer-Pool so groß wie möglich zu machen (siehe Abbildung 2). So weit, so gut. Von den restlichen Vorschlägen Claudes überzeugt mich vor allem der vierte. Er geht spezifisch auf das im Prompt beschriebene Problem ein, dass es hier nicht eine riesige Datenbank gibt, sondern viele, vergleichsweise kleine DBs und Tabellen. Die »table_cache«-Einstellungen helfen hier definitiv weiter. Bei einem Server mit konventionellen Festplatten ist der resultierende Geschwindigkeitsunterschied möglicherweise bemerkbar. Kommen schnelle SSDs zum Einsatz, bleibt der Nutzen wohl eher überschaubar.

Abbildung 2: MariaDB-Tuning-Vorschläge von Claude.

Eher unglücklich war das von Claude als zweiter Punkt vorgeschlagene »innodb_flush_log_at_trx_commit = 0«. Zwar beschleunigt das Setting die Verarbeitung vieler Write-Transaktionen, allerdings auf Kosten der Datensicherheit. Mit der Einstellung kann es eine volle Sekunde dauern, bevor Transaktionen physisch gespeichert werden. Da mein Prompt explizit erwähnt, dass Kommandos wie »INSERT«, »UPDATE« und »DELETE« nur vergleichsweise selten vorkommen, bringt diese Maßnahme keine nennenswerten Vorteile.

Bei beiden KI-Tools habe ich einen anderen Vorschlag vermisst, der bei dem im Prompt beschriebenen Setup eigentlich naheliegend wäre: die Erhöhung des Limits für gleichzeitig offene Dateien über »mysql soft nofile 65535« und »mysql hard nofile 65535« in der »/etc/security/limits.conf«.

Beispiel: Docker-Setup

Kürzlich wollte ich mit Docker einen Monitoring-Server mit Prometheus und Grafana einrichten. Mit Docker selbst bin ich vertraut und weiß auch, wie ein Reverse Proxy funktioniert. Prometheus war jedoch komplettes Neuland für mich. Deshalb habe ich ein KI-Tool befragt, dieses Mal Claude:

Prompt: Prometheus and Grafana: I have a minimal Ubuntu Server installation with nginx and up-to-date Docker installed. NGINX hosts a static hello world page. I have Let’s Encrypt certificates for HTTPS installed. Up to here, everything works fine. Now I want to setup Prometheus and Grafana to monitor other systems. I want to use docker compose to run these services using internal (localhost) ports. nginx should act as a reverse proxy to expose these services externally using *https://myhost/grafana* and *https://myhost/prometheus*. Please help me with a minimal ‘compose.yaml’ file for Prometheus and Grafana and a configuration file for nginx to add the reverse proxy setup to my existing configuration which looks like this (…).

Claude lieferte nun eine wunderbare Schritt-für-Schritt-Anleitung für die »compose.yaml« sowie diverse Konfigurationsdateien für Grafana und Prometheus. Als ich den Anweisungen folgte, landete ich jedoch nach einer Stunde in einer Sackgasse (Abbildung 3).

Abbildung 3: Fehlersuche im Nginx- und Docker-Setup mit Claude.

Das Problem bestand darin, dass die Weiterleitung der Docker-Ports 3000 und 9090 auf die URLs https://myhost/grafana and https://myhost/prometheus nicht richtig funktionierte. Zwar wurde die Startseite von Prometheus und Grafana richtig angezeigt, aber alle dort dargestellten Links führten zu ungültigen Adressen.

Grundsätzlich gibt es zwei Orte, wo man auf die Adressen Einfluss nehmen kann: in der Nginx-Konfigurationsdatei mit Rewrite-Regeln oder in den »compose.yaml«-Files zur Konfiguration von Prometheus und Grafana. Wichtig ist dabei, dass die beiden Dateien aufeinander abgestimmt sind, damit die Adressanpassung nicht etwa doppelt erfolgt. Genau in diesem Punkt war der erste Setup-Vorschlag von Claude fehlerhaft.

Mit KI-Hilfe und Internetrecherchen (Prometheus- und Grafana-Handbücher, Stack Overflow etc.) konnte ich die Probleme letztlich lösen, aber es war ein mühsamer Prozess. Ungleich zielführender waren die Tipps meines Freunds Bernd Öggl, mit dem ich mich später über das Setup unterhalten habe. Von ihm bekam ich zwei Empfehlungen:

• Subdomains erleichtern die Konfiguration deutlich – also https://grafana.myhost statt https://myhost/grafana. Das gilt analog für Prometheus.
• Als Reverse Proxy samt HTTPS-Verschlüsselung verwendet man anstelle von Nginx auf dem Host besser das Programm Traefik [6] in einem Docker-Container.

Tatsächlich führen die beiden Ratschläge zu einer viel einfacheren, weniger fehleranfälligen Konfiguration. Das Problem an der Sache war, dass ich mich (unwissentlich) von vornherein für einen unnötig komplizierten Setup-Weg entschieden hatte. Das KI-Tool hatte aufgrund des Prompts kaum eine Wahl, als den von mir schon vorgegebenen Weg fortzusetzen. Langer Rede kurzer Sinn: selbst Schuld.

Den KI-Tools fehlt die “Intelligenz”, um von sich aus vorzuschlagen, zuerst einen Schritt zurückzugehen, um dann eine einfachere Lösung zu erzielen. Kompetente menschliche Hilfe bleibt der KI also überlegen.

Ollama

Ollama bietet die Möglichkeit, Sprachmodelle unkompliziert unter Linux, Windows und MacOS auszuführen. Das Installationsskript aus Listing 2 funktioniert auf vielen gängigen Distributionen.

wget https://ollama.com/install.sh
less install.sh  # kurze Kontrolle
sh install.sh

Erfreulicherweise stehen auf der Ollama-Website eine ganze Reihe kostenloser Modelle zur Auswahl. Die Lizenz dieser “freien” Modelle fällt allerdings weit weniger liberal aus als bei echter Open-Source-Software. Um ein Sprachmodell auszuprobieren, starten Sie das gewünschte Modell im Terminal, zum Beispiel mit »ollama run llama3.2«. Beim ersten Mal muss das mehrere Gigabyte große Sprachmodell heruntergeladen werden.

Sehr populär ist LLaMA von Meta. Es fällt mit rund 2 GByte Umfang recht klein aus und funktioniert selbst auf nicht besonders leistungsfähigen Rechnern zufriedenstellend. Das Modell beantwortet einfache Admin-Fragen mühelos. Ein Beispiel: “Linux: How can I find files in /etc not changed for at least two months?”

Für komplexere Aufgaben erweist sich Qwen-Coder als gute Wahl. Das Kommando »ollama run qwen2.5-coder:14b« lädt ein etwa 9 GByte großes Modell herunter. Es funktioniert auf einem Notebook mit 32 GByte RAM zufriedenstellend, wenn auch ziemlich langsam. Qwen-Coder ist ein freies, für das Coding optimiertes Sprachmodell, das auch andere IT-Fragen gut beantworten kann, zum Beispiel rund um die Linux-Administration.

Ollama läuft als Kommandozeilenprogramm im Terminal (Abbildung 4). Es gibt aber diverse Weboberflächen, die die Bedienung erleichtern und ähnlichen Komfort bieten wie ChatGPT oder Claude. Dazu zählt beispielsweise OpenWebUI [7].

Abbildung 4: Ollama mit dem lokalen Modell Llama 3.2 gibt Auskunft über den richtigen Einsatz des Kommandos »firewall-cmd«.

Standardmäßig verwendet Ollama zum Ausführen des Sprachmodells nur die CPU. Anleitungen zur Integration von Treibern für GPUs von Nvidia und AMD finden Sie auf der Ollama-Website. Beachten Sie aber, dass das ganze Modell im Grafikspeicher (VRAM) Platz haben muss, um die volle Geschwindigkeit auszureizen.

Das Problem bei der lokalen Ausführung von Sprachmodellen besteht darin, dass nur sehr große Modelle mit der Qualität kommerzieller Angebote mithalten können. Dazu brauchen Sie aber entsprechend leistungsfähige Hardware, idealerweise eine Nvidia-Grafikkarte mit reichlich VRAM. Mit normaler Hardware fallen sowohl die Verarbeitungsgeschwindigkeit von Prompts als auch die Qualität der Ergebnisse enttäuschend aus.

Kommerzielle Tools

Bringt Ihr Rechner für das lokale Ausführen von Sprachmodellen zu wenig Leistung oder stellt Sie die Qualität der Ergebnisse nicht zufrieden, müssen Sie bei den kommerziellen Anbietern bleiben. Allerdings passt die Anwendung der Web-Chatbots nicht perfekt zum Terminalalltag vieler Linux-Admins.

Um kommerzielle KI-Tools im Terminal auszuführen, greifen Sie am besten zum Python-Programm Llm [8], das seinerseits das Plugin Gpt4all benötigt. Darüber kommuniziert Llm mit den diversen Sprachmodellen (Listing 3).

$ pip3 install llm
$ llm install llm-gpt4all
$ llm models
  OpenAI Chat: gpt-4o (aliases: 4o)
  OpenAI Chat: gpt-4o-mini (aliases: 4o-mini)
  gpt4all: Meta-Llama-3 - Llama 3.1 8B (installed)
  ...

Wenn Llm die API von OpenAI [9] nutzen soll, geben Sie so Ihren API-Key über das Kommando »llm keys set openai« an. Nach diesen Vorbereitungen können Sie mit Llm Prompts an die OpenAI-API senden (Listing 4), die Antwort erscheint im Terminal. Derzeit kommt standardmäßig das Modell »gpt-4o-mini« zum Einsatz (»llm models default«). Ein anderes Sprachmodell wählen Sie bei Bedarf mit »–model Name« aus.

$ llm 'Linux/nft: How can I build a firewall with geoip blocking for some countries'

Die meisten APIs liefern das Ergebnis in Markdown-Formatierung. Sie erhalten im Terminal besser lesbaren Code, indem Sie den Output an einen Formatter weitergeben, zum Beispiel Bat oder Rich (Listing 5). Der große Nachteil besteht darin, dass Sie warten müssen, bis die gesamte Antwort eintrifft, bevor Sie das Ergebnis sehen (Abbildung 5). Normalerweise liefert die KI das Resultat stückweise, aber damit kommen gängige Formatierungswerkzeuge nicht zurecht.

$ pip install rich-cli
$ llm 'my prompt' | rich --markdown -

Abbildung 5: Llm führt den Prompt mit einer externen API aus, Rich formatiert die Ausgabe.

Beachten Sie, dass ein gewöhnliches ChatGPT- oder Claude-Abo für die Anwendung von Llm nicht ausreicht. Sie müssen dazu ein Guthaben für die API-Nutzung [10] erwerben. Die Abrechnung erfolgt nach Tokens und hängt vom genutzten Sprachmodell ab. Ein grober Richtwert: Eine typische Frage (zwei Absätze Text) mit einer zweiseitigen Antwort kostet zwischen 1 und 3 Cent. Je nach Modell geht es auch günstiger, etwa bei »gpt-4o-mini«. Kurz und gut: 10 US-Dollar Startguthaben genügen für eine Menge Experimente.

Sicherheitsprobleme

Die vielleicht größte Gefahr beim Einsatz von KI-Werkzeugen geht von Anweisungen aus, die zwar funktionieren, aber Sicherheitsprobleme mit sich bringen. Das Ursache liegt darin, dass das Internet voll von Anleitungen ist, die wenig Rücksicht auf Sicherheit nehmen. Grenzwertige Blogposts fließen ebenso in das Trainingsmaterial von Sprachmodellen ein wie sicherheitstechnisch wertvolle Beiträge. KI-Tools liefern im Mittel ebenso sichere beziehungsweise unsichere Anleitungen, wie man sie sonst im Internet beziehungsweise in anderen Trainingsquellen findet.

Um ein Beispiel zu nennen: Ich habe KI-Tools mehrfach zum Einrichten von Docker-Setups verwendet. Das hat meistens besser funktioniert als im vorhin behandelten Prometheus-Beispiel. Trotzdem tauchten immer wieder in »Dockerfile« oder »compose.yaml« veraltete Softwareversionen auf. Oft wurden Ports mit »3000:3000« dem ganzen Netzwerk zugänglich gemacht, die eigentlich nur »localhost« benötigt. In Containern liefen Prozesse mit Root-Rechten, wo ein normaler Benutzer ausgereicht hätte. Auf einem Entwicklungsrechner lässt sich all das verzeihen; bei einem produktiv genutzten Service stellen solche Ungereimtheiten unnötige Sicherheitsrisiken dar.

Fazit

KI-Tools sind nicht nur beim Programmieren eine echte Hilfe, sondern unterstützen auch bei Linux-Administrationsarbeiten. Allerdings sollten Sie dabei die Anweisungen der KI auf keinen Fall blind befolgen: Auch wenn die Richtung der Antwort oft stimmt, hapert es oft bei den Details und der Aktualität.

Ihr eigenes Wissen bleibt nach wie vor wertvoll. Je größer es ist, desto leichter können Sie die Qualität der Antworten abschätzen und gegebenenfalls um Nachbesserung bitten – und desto mehr werden Sie von KI-Tools profitieren. Die Hoffnung, dass künstliche Intelligenz Linux-Einsteiger über Nacht zu Profis macht, bleibt vorerst ein schöner Traum. (jlu)