PRAXIS-HANDBUCH

Sicher arbeiten.
Nachvollziehbar lösen.

Das Betriebshandbuch für Shell-Sitzungen, Serveränderungen, Fehlersuche und IRC-Infrastruktur. Nicht bloß Befehle, sondern Arbeitsweisen mit Prüfung und Rückweg.

Erst die Shell verstehen → Befehle nachschlagen

PRAXIS 01#handbuch-1

Eine Shell-Sitzung bewusst beginnen

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.

shell-hilfe · bash
 id; hostnamectl --static; pwd; printf "Shell: %s\n" "$SHELL"
PRAXIS 02#handbuch-2

Befehle vor der Ausführung zerlegen

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"
PRAXIS 03#handbuch-3

Pipelines mit klaren Fehlergrenzen bauen

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.

shell-hilfe · bash
 set -o pipefail; journalctl -b | grep -i error | tail -n 20
PRAXIS 04#handbuch-4

Shell-Diagnose ohne Blindflug

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.

shell-hilfe · bash
 id; pwd; df -h; systemctl --failed; journalctl -p warning -b
PRAXIS 05#handbuch-5

Sichere Änderungen am Server

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.

shell-hilfe · bash
 sudo cp config config.bak; nginx -t; systemctl reload nginx
PRAXIS 06#handbuch-6

IRC-Verbindungen sauber absichern

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.

shell-hilfe · bash
 openssl s_client -connect irc.example:6697 -servername irc.example
PRAXIS 07#handbuch-7

ZNC als dauerhafte Verbindungsschicht

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.

shell-hilfe · bash
 znc --version; journalctl -u znc --since today
PRAXIS 08#handbuch-8

Eggdrop und Tcl kontrolliert erweitern

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.

shell-hilfe · bash
 bind pub - !status pub_status; putlog "status requested"
PRAXIS 09#handbuch-9

IRCd wartbar betreiben

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.

shell-hilfe · bash
 inspircd --version; systemctl status inspircd
PRAXIS 10#handbuch-10

Backups sind erst nach Restore-Tests Backups

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.

shell-hilfe · bash
 sqlite3 app.sqlite "PRAGMA integrity_check;"
PRAXIS 11#handbuch-11

Gute Community-Fragen erzeugen gute Antworten

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.

Anleitungen öffnen → Forum