Thema: automation
-
Tale MCP: Deployment-Endpunkt und Organisationsbereich
Tale stellt für Wissen und Automatisierungen einen deploymentspezifischen MCP-Endpunkt bereit, der Bearer-API-Keys und die Eingrenzung auf eine Organisation verwendet. Diese Referenz fasst die dokumentierten Verbindungs- und Berechtigungsgrenzen zusammen.
-
rc.conf, sysrc und service unter FreeBSD: Dienste aktivieren, starten und prüfen, was beim Booten läuft
Dienste werden unter FreeBSD deklarativ über eine rc.conf-Variable aktiviert (in /etc/rc.conf oder in einer dienstspezifischen Datei unter /etc/rc.conf.d); sysrc und service <name> enable schreiben lediglich diese Variable, und rc.conf selbst soll nichts direkt ausführen, sondern nur Variablen setzen, die die rc-Skripte in /etc/rc.d auswerten. Mit sysrc lassen sich diese Variablen aus einem Skript heraus sicher bearbeiten, und service startet und stoppt das zugehörige rc.d-Skript und meldet dessen Status.
-
Warum ein unbeaufsichtigtes Skript unter macOS stillschweigend scheitert: TCC-Berechtigungen für Dateien, Bedienungshilfen und Automation
macOS regelt den Zugriff auf Dateien ausserhalb des App-Containers, die Steuerung von Tastatur und Bildschirm sowie Apple Events zwischen Apps über TCC. Massgeblich ist dabei die Code-Identität des aufrufenden Binaries, nicht der Unix-Benutzer: root umgeht die Prüfung also nicht, und ein neu gebautes, unsigniertes oder ad hoc signiertes Tool muss die Berechtigungen von vorn erhalten.
-
Locale und Zeitzone setzen sowie Pakete nicht interaktiv neu konfigurieren unter Debian und Ubuntu
localectl, timedatectl und update-locale ändern Locale und Zeitzone ohne Textdialog; dpkg-reconfigure -f noninteractive führt die debconf-gesteuerte Konfiguration eines Pakets erneut so aus, wie ein Skript die ursprüngliche Installation ausführen würde. Beides eignet sich für Provisioning-Skripte ohne angeschlossenes Terminal.
-
Ansible-Ad-hoc-Befehle und Check-Modus für einen sicheren ersten Lauf gegen eine Serverflotte
Ein Ad-hoc-Befehl mit `ansible` führt ein Modul ohne Playbook auf einem oder mehreren Hosts aus. In Kombination mit `--check --diff` und einem eng gefassten `--limit` kann ein Agent sehen, was eine Änderung an einer Flotte bewirken würde, bevor sie tatsächlich erfolgt.
-
z/OS über z/OSMF automatisieren: die REST-APIs für Jobs, Datasets und Dateien
z/OSMF stellt z/OS-Jobs, Datasets und z/OS-UNIX-Dateien als gewöhnliche HTTPS-/REST-Ressourcen bereit und ist damit die für Agenten am besten geeignete Schnittstelle zum System. Anfragen benötigen den benutzerdefinierten Header X-CSRF-ZOSMF-HEADER (zustandsändernde Aufrufe werden ohne ihn abgelehnt), und Antworten verwenden Standard-HTTP-Statuscodes statt 3270-Meldungstexten.
-
systemd-Timer als Cron-Ersatz: OnCalendar, Persistent= und RandomizedDelaySec
Eine systemd-.timer-Unit zusammen mit einem oneshot-.service kann einen crontab-Eintrag ersetzen und ergänzt ihn um Nachholläufe nach Ausfallzeiten sowie zufällige Verzögerung über eine Flotte von Hosts. Diese Methodik schreibt, validiert und aktiviert ein solches Paar und erklärt, was Persistent= und RandomizedDelaySec= tatsächlich bewirken.
-
SMIT als Befehlsgenerator statt als Menüsystem nutzen
Die Menüs von smit/smitty führen letztlich gewöhnliche AIX-Befehle aus, und das Werkzeug zeigt diese auch an: Das Ausgabefenster enthält die zusammengesetzte Befehlszeile, und smit.log/smit.script halten jeden Befehl mit exakten Optionen und Zeitstempeln fest. Wer nach einer menügeführten Aufgabe smit.script liest, findet schnell den äquivalenten nicht interaktiven Befehl.
-
FreeBSD aktualisieren: freebsd-update für das Basissystem, pkg upgrade für Pakete und pkg audit für bekannte Schwachstellen
FreeBSD verteilt das Patchen auf zwei voneinander unabhängige Werkzeuge: freebsd-update fetch/install für das Basissystem (mit upgrade -r für einen Wechsel des Major-Release) und pkg upgrade für installierte Pakete. pkgbase, also die Installation des Basissystems selbst als pkg(8)-Pakete, ist für FreeBSD 14 als experimentell und für FreeBSD 15.0 als Technology Preview dokumentiert und noch nicht der Standardweg.
-
Linux-Administrationsbefehle für unbeaufsichtigte Agenten nicht interaktiv ausführen
Interaktive Standardeinstellungen – ein Pager, eine Bestätigungsabfrage, eine Locale, die Zahlen umformatiert, eine sudo-Passwortabfrage ohne Terminal für die Eingabe – sind unter Linux die häufigsten Gründe, weshalb eine unbeaufsichtigte Agenten-Session hängen bleibt oder Ausgaben falsch parst. Dieser Artikel listet die Flags und Umgebungsvariablen auf, mit denen sich jede davon abschalten lässt.
-
launchd-Domains: LaunchAgent oder LaunchDaemon wählen und mit launchctl laden
LaunchAgents und LaunchDaemons liegen in unterschiedlichen Verzeichnissen, laufen in verschiedenen launchd-Domains und werden mit den modernen Subcommands bootstrap, bootout, enable, kickstart und print verwaltet statt mit dem veralteten Paar load/unload. Diese Methodik beschreibt, wie die passende Domain gewählt, eine minimale plist geschrieben und der Status geprüft wird.
-
Geheimnisse für unbeaufsichtigte Skripte speichern: systemd-Credentials, DPAPI, macOS-Keychain – und was man vermeiden sollte
Jedes Betriebssystem bietet einen Mechanismus, um einem Skript ein Geheimnis zu übergeben, ohne es in einer Umgebungsvariable oder einem Kommandozeilenargument preiszugeben, das andere Prozesse oder Logs lesen können: systemd mit LoadCredential=, Windows DPAPI über Export-Clixml oder SecretManagement sowie die macOS-Keychain über security find-generic-password.
-
Betriebssystem aus einem Skript erkennen: uname, os-release, sw_vers, oslevel und eine Fallback-Reihenfolge
Ein portables Skript braucht eine verlässliche Methode, um nach Betriebssystem und Version zu verzweigen, bevor es einen OS-spezifischen Befehl aus den anderen Artikeln dieser Reihe ausführt. Diese Methodik beschreibt für POSIX-Shells und PowerShell eine Fallback-Reihenfolge von der spezifischsten, zuverlässigsten Quelle bis zur Notlösung per Schätzung.
-
SSH known_hosts und Host-Key-Prüfung in der Automatisierung: ssh-keyscan plus Out-of-Band-Verifikation
Auch automatisierte SSH-Verbindungen müssen den Host-Key des Servers prüfen; ssh-keyscan allein sammelt nur einen Schlüssel ein, ohne dessen Echtheit zu belegen. StrictHostKeyChecking=accept-new, HashKnownHosts und SSHFP-Records decken jeweils einen anderen Teil einer sicheren Lösung ohne interaktive Rückfrage ab.
-
SUSE Linux mit zypper administrieren: Refresh, Patch, Update und dup sowie nicht interaktive Läufe
zypper trennt das Aktualisieren der Repository-Metadaten, das Einspielen offizieller Patches, das Update einzelner Pakete und das vollständige Distributions-Upgrade in vier eigene Befehle. Wer weiss, welcher Befehl wann passt, wie zypper unbeaufsichtigt läuft, wie sich nach einem Update Prozesse finden lassen, die noch gelöschte Dateien verwenden, und wie eine Paketversion gesperrt wird, verhindert, dass ein Agent einen SUSE-Host beschädigt.
-
Die PF-Firewall unter FreeBSD: pf.conf vor dem Laden mit pfctl -n testen und per geplantem Rollback gegen SSH-Aussperrung absichern
Die Regeln in pf.conf bauen auf einer Standardrichtlinie (pass/block) auf und können über Anchors um Teilregelwerke ergänzt werden. Geladen werden sie mit pfctl -f erst, nachdem pfctl -nf sie geparst hat, ohne sie zu laden. Da ein fehlerhaftes Regelwerk genau die SSH-Sitzung kappen kann, mit der es eingespielt wird, ist ein vor dem Laden neuer Regeln mit at(1) geplanter, unbeaufsichtigter Rollback ein verbreitetes Sicherheitsmuster (keine PF-Funktion), um Änderungen auf einem entfernten FreeBSD-Host zu testen.
-
apt und dpkg unter Debian und Ubuntu nicht interaktiv ausführen, ohne an Rückfragen hängenzubleiben
Ein skriptgesteuerter Lauf von apt-get oder dpkg kann an einer debconf-Rückfrage, einer Frage zu geänderten Konfigurationsdateien oder einer gehaltenen dpkg-Sperre hängenbleiben. Mit gesetztem DEBIAN_FRONTEND, den passenden confold-/confdef-Optionen und vorab hinterlegten debconf-Antworten endet die Installation entweder erfolgreich oder mit einer klaren Fehlermeldung.
-
Homebrew nicht interaktiv auf einem Build-Agent betreiben: NONINTERACTIVE, Umgebungsvariablen und Brewfile
Installer, Auto-Update- und Analytics-Verhalten von Homebrew sowie Formula-Versionen lassen sich für den Einsatz auf einem CI-Runner ohne Rückfrage steuern; mit einem Brewfile ist der installierte Bestand über alle Runner hinweg reproduzierbar.
-
Unbeaufsichtigte RHEL-Installation mit einer Kickstart-Datei aufbauen
Eine Kickstart-Datei steuert die Installation von RHEL, Rocky Linux oder AlmaLinux ohne interaktive Eingaben und kombiniert einzeilige Befehle mit %pre- und %post-Skripten. Die Methodik behandelt die Validierung vor dem Einsatz, die Übergabe beim Booten und das Heraushalten von Geheimnissen aus einer Datei, die oft ohne Authentifizierung ausgeliefert wird.
-
unattended-upgrades für automatische Sicherheitsupdates unter Debian und Ubuntu konfigurieren
unattended-upgrades installiert Paketupdates zeitgesteuert und wird über zwei Dateien konfiguriert: 20auto-upgrades (ob und wie oft) und 50unattended-upgrades (welche Quellen und ob neu gestartet wird). Ein Test mit --dry-run --debug vor dem Produktiveinsatz verhindert unerwartete Neustarts oder halb eingespielte Upgrades.
Maschinenlesbar: JSON