Das Betriebshandbuch für Shell-Sitzungen, Serveränderungen, Fehlersuche und IRC-Infrastruktur. Nicht bloß Befehle, sondern Arbeitsweisen mit Prüfung und Rückweg.
Bevor du arbeitest, klärst du Identität, Host, Shell und Verzeichnis. Das wirkt banal, verhindert aber die teuersten Fehler: richtige Befehle auf dem falschen Server, als falscher Benutzer oder im falschen Pfad. Lies den Prompt als Warnsignal, nicht nur als Dekoration. Ein Root-Prompt ist kein Arbeitsmodus, sondern eine kurzzeitig erhöhte Verantwortung.
Lies eine Kommandozeile von links nach rechts: Programm, Optionen, Argumente, Umleitungen und Verknüpfungen. Prüfe Variablen und Dateimuster separat, bevor ein verändernder Befehl sie verwendet. Mit type und command -v erkennst du, ob ein Name ein Alias, Built-in oder externes Programm ist. So wird aus Copy-and-paste eine nachvollziehbare Entscheidung.
shell-hilfe · bash
$ type rm; command -v find; printf "Ziel: %q\n" "$target"
Eine Pipeline verbindet kleine Werkzeuge, kann aber Fehler im vorderen Teil verdecken. Teste jeden Abschnitt einzeln, begrenze Ausgaben und speichere Diagnoseinformationen getrennt. In Bash-Skripten macht pipefail einen Fehler innerhalb der Kette sichtbar. Bei produktiven Daten gehört vor die schreibende Aktion immer eine lesende Vorschau.
Beginne mit beobachtenden Befehlen. Prüfe Identität, Arbeitsverzeichnis, freien Speicher, laufende Prozesse und die letzten relevanten Protokolle, bevor du einen Zustand veränderst. Eine Diagnose ist erst belastbar, wenn sie reproduzierbar ist. Notiere Befehl, Zeitpunkt und Ausgabe. So wird aus einem spontanen Eingriff ein nachvollziehbarer Lösungsweg.
Eine Änderung braucht ein Ziel, einen Prüfpunkt und einen Rückweg. Sichere die betroffene Konfiguration, validiere ihre Syntax und lade einen Dienst erst danach neu. Ein Neustart ist kein Diagnosewerkzeug. Nutze getrennte Benutzer, minimale Rechte und protokolliere administrative Eingriffe.
TLS schützt den Transport, SASL bindet die Verbindung früh an den registrierten Account. Prüfe Zertifikatsnamen, Ports und die tatsächlich ausgehandelte TLS-Version. Operator-Rechte gehören nicht in alltägliche Konten. Services-Passwörter sollten einmalig, lang und außerhalb öffentlicher Bot-Skripte gespeichert sein.
Ein Bouncer ist kein bloßer Dauerclient. Er verwaltet Identität, Wiedergabe und mehrere Endgeräte. Begrenze Playback, aktiviere vertrauenswürdige Module bewusst und nutze pro Netzwerk getrennte Zugangsdaten. Nach Updates werden Zertifikat, SASL-Mechanismus und Modulstatus geprüft.
Tcl-Skripte laufen im Vertrauensbereich des Bots. Fremde Skripte werden gelesen, auf Dateizugriffe und externe Prozesse geprüft und zuerst in einer isolierten Instanz getestet. Channel-Flags sollten nur die Rechte vergeben, die ein Befehl tatsächlich benötigt. Fehler gehören ins Log, nicht in stille catch-Blöcke.
Trenne Listener, Operator-Regeln, Services und Netzwerkverbindungen logisch. Konfigurationen gehören in Versionsverwaltung, Geheimnisse nicht. Vor einem Rehash wird die Syntax geprüft; vor Upgrades existieren Datenbank- und Konfigurationsbackups. Rate-Limits, DNSBL und Verbindungsgrenzen müssen zur Größe des Netzes passen.
Eine vorhandene Datei beweist keine Wiederherstellbarkeit. SQLite-Sicherungen entstehen über die Backup-API oder VACUUM INTO, nicht durch unkoordiniertes Kopieren einer aktiven WAL-Datenbank. Prüfe Integrität, Aufbewahrung und Speicherort. Mindestens eine Kopie gehört außerhalb des Webspace.
Nenne Ziel, Umgebung, bereits geprüfte Schritte und vollständige Fehlermeldungen. Entferne Passwörter, Tokens, öffentliche IP-Adressen und personenbezogene Daten. Formatiere Ausgaben als Code und beschreibe, was direkt vor dem Fehler verändert wurde.
shell-hilfe · bash
$ System · Version · Ziel · Ausgabe · Erwartung · bisherige Schritte
KONKRET UMSETZEN
Bereit für den nächsten Schritt?
Die Anleitungen führen durch Installationen; das Forum hilft bei deinem konkreten Fall.