Technische Empfehlungen und bewährte Praktiken für Centron-Tutorials

Einführung

Dieser Leitfaden ist ein Versuch, etablierte bewährte Praktiken und starke Empfehlungen für Autoren von Centron-Tutorials zusammenzufassen. Er soll eine Grundlage für Konsistenz, technische Korrektheit und Benutzerfreundlichkeit im Lehrmaterial von Centron bieten.

Dieser Leitfaden ist von Natur aus ein Arbeitsdokument und ein meinungsbildendes Dokument, basierend auf den wachsenden Erfahrungen interner technischer Schriftsteller und Redakteure, Community-Manager und Ingenieure. Seine Empfehlungen können sich ändern und sind speziell für Bildungsinhalte mit einer breiten Palette von Lesern und Endbenutzern geschrieben.

Softwarequellen und Installation

Viele Tutorials basieren auf bestehenden Tutorials als Voraussetzungen. Fügen Sie alle Voraussetzungen für den Artikel (einschließlich aller geschachtelten Voraussetzungen für die Voraussetzungen) in den Artikel ein, anstatt tief geschachtelte Voraussetzungslisten zu haben.

Bevorzugte Quellen

In etwa absteigender Reihenfolge der Vorliebe verwenden Sie die folgenden Installationsmechanismen:

1. Die vom Projekt empfohlene Methode, wenn sie als die beste bewertet wird. Viele Projekte ändern sich schnell und empfehlen, über die offiziellen Repositories hinauszugehen, aber einige Installationen (wie curl | bash-Muster) erfordern eine Beurteilung, ob sie verwendet werden sollen oder nicht.
2. Die offiziellen Paket-Repositories für die aktuelle Distribution und Version.
3. Sprachspezifische offizielle Pakete (NPM, CPAN, PIP, RubyGems, Composer usw.)
4. Projektspezifische Paket-Repositories (z.B. Nginx stellt seine eigenen Repos für aktuelle Versionen bereit) oder, auf Ubuntu, ein vertrauenswürdiges PPA. Stellen Sie sicher, dass diese von einer gut vertrauenswürdigen Quelle stammen, wie den Entwicklern des Projekts oder den Debian/Ubuntu-Paketbetreuern.
5. Binärdateien von der GitHub-Release-Seite des Projekts oder einer ähnlichen offiziellen Webquelle.
6. wget- oder curl-Installationsskripte, die in die Shell gepiped werden, mit einer angemessenen Warnung über die Überprüfung von Skripten.

Bevorzugte Installationsorte

Vermeiden Sie im Allgemeinen unnötige Komplikationen. Für nicht verpackte Software, die aus Quellen oder Binärdateien installiert wird, sollten Sie im Allgemeinen den Standardinstallationspräfix akzeptieren, es sei denn, er ist sehr ungewöhnlich oder führt zu Konflikten.

Ein Init-Skript, das den offiziellen Empfehlungen für die Distribution entspricht, sollte für dienstorientierte Software bereitgestellt werden, wenn es nicht bereits durch das Paket oder eine andere Installationsmethode bereitgestellt wird.

Auf Linux-Systemen platzieren Sie eigenständige Binärdateien oder Verzeichnisse in /opt und eigenständige Skripte in /usr/local/bin.

Software- und Systemwartung

Ubuntu- und Debian-Systeme sollten unattended-upgrades mit mindestens Sicherheitsupdates installiert und konfiguriert haben. Wir empfehlen kein automatisches Neustarten oder automatisches Update aller Pakete, angesichts des Kontexts.

Wir empfehlen im Allgemeinen die Verwendung des apt-Befehls für Ubuntu 18.04 und neuer. Ändern Sie apt-get und apt-cache, um apt zu verwenden. Wenn Sie apt-Befehle aktualisieren, verwenden Sie nicht die -y-Flagge; Leser sollten durch alle notwendigen Eingaben und Aufforderungen geführt werden.

Für CentOS- und Rocky-Linux-Tutorials empfehlen wir nun die Verwendung von dnf, das yum abgelöst hat und eine bessere Leistung bietet.

Wenn ein Tutorial auf den neuesten Updates basiert, rufen Sie während der Schritt-1-Einrichtung oder bei Bedarf update und upgrade auf. Rufen Sie zuerst update auf, damit Ihr Server die neuesten Versionen der Pakete abruft. Wenn Sie upgrade einbeziehen, das neue Versionen für jedes Paket herunterlädt und installiert, beachten Sie bitte, dass einige Benutzer sich entscheiden könnten, bestimmte Pakete in einer niedrigeren Version zu belassen.

Dienstverwaltung

Stellen Sie sicher, dass Sie native Init-Systembefehle verwenden, auch wenn Legacy-Kompatibilitätsbefehle verfügbar sind. Verwenden Sie beispielsweise sudo systemctl start [Dienstname], obwohl sudo service [Dienstname] start funktionieren wird.

Stellen Sie Informationen darüber bereit, wie der Dienst aktiviert oder deaktiviert werden kann, damit er beim Starten des Systems startet. Geben Sie an, wie das Ergebnis dienstbezogener Befehle überprüft wird, wenn es nicht eindeutig durch die Schnittstelle angezeigt wird (journalctl -u, systemctl status usw.).

Bevorzugen Sie Neustarts gegenüber Neuladungen für Dienste als Faustregel. In den meisten Fällen ist es wichtiger, einen bekannten Zustand zu gewährleisten, als eine kurzzeitige Dienstunterbrechung zu vermeiden, und Neustarts sind auch im Falle eines vollständigen Dienstausfalls nützlicher.

Systeminitialisierung

Sofern es nicht Teil eines Konfigurationsmanagement-Workflows ist, bevorzugen Sie Benutzerdatenskripte und bevorzugen Sie cloudinit-Skripte gegenüber Bash-Skripten in Benutzerdaten in den meisten Fällen.

Protokollierung und Fehlerbehebung

Erklären Sie, wo und wie auf Protokolle für installierte Dienste zugegriffen wird. Erklären Sie, wo relevant, systemctl- und journalctl-Befehle zur Überprüfung des Dienststatus und des Protokolloutputs. Bieten Sie, wenn möglich, prägnante Vorschläge zur Diagnose häufiger Fehlerfälle.

Stellen Sie sicher, dass die Protokollrotation für alle Fälle behandelt wird, in denen sie nicht von Paketen oder anderen Installationsmechanismen gehandhabt wird.

Zum Verfolgen von Klartext-Protokolldateien verwenden Sie tail -F, nicht tail -f, da letzteres eine Datei nicht über Umbenennungen hinweg verfolgen wird und Verwirrung stiften könnte, wenn Protokolle rotiert werden, während ein Benutzer sie beobachtet.

Benutzer- und Gruppenverwaltung

Erstellen Sie sudo-Benutzer anstelle der direkten Verwendung von root. Verweisen Sie auf die entsprechenden anfänglichen Servereinrichtungsleitfäden, die diese Aufgabe als Voraussetzung erklären.

Bei auf Debian basierenden Distributionen fügen Sie Benutzer hinzu und entfernen sie mit adduser sammy und deluser –remove-home sammy; bei auf RHEL basierenden Distributionen verwenden Sie adduser sammy (setzen Sie bei Bedarf ein Passwort mit passwd sammy) und userdel -r sammy.

Verleihen Sie sudo-Berechtigungen mit usermod -aG sudo sammy auf Ubuntu. CentOS ist etwas komplizierter. Moderne Versionen verwenden usermod -aG wheel sammy, aber einige Versionen erfordern erst das Aufheben der Kommentierung der wheel-Gruppenberechtigungen mit visudo. Speziell auf CentOS 5 muss sudo installiert sein und die wheel-Gruppe mit visudo entkommentiert werden; auf CentOS 6 ist sudo bereits installiert, aber wheel muss entkommentiert werden; CentOS 7 hat sudo und die wheel-Gruppe ist bereits eingerichtet.

Wenn Sie Befehle mit erhöhten Rechten verwenden, stellen Sie sicher, dass sie wie geschrieben getestet werden. Um Umgebungsvariablen über sudo zu übergeben, verwenden Sie sudo -E command_to_run (falls das gesamte Umfeld vertrauenswürdig ist) oder sudo FOO=BAR command_to_run. Für Fälle, die eine Root-Shell erfordern, verwenden Sie sudo -i. Für Fälle, die eine Umleitung benötigen, verwenden Sie tee -a, um an das Ziel anzuhängen, statt es zu ersetzen: [sudo] command_to_run | sudo tee [-a] file_to_change.

Bevorzugte Werkzeuge

Für interaktive Shells gehen Sie von Bash auf GNU/Linux-Systemen aus, explizit erwähnt, wenn relevant. Auf FreeBSD verwenden Sie tcsh, da es standardmäßig verfügbar ist und nützliche Funktionen bietet.

Für Texteditoren fügen wir den Hinweis „Verwenden Sie [bevorzugt] oder Ihren Lieblings-Texteditor“ hinzu und schließen die folgenden anfängerfreundlichen Editoren in Befehlen für diejenigen ein, die kopieren und einfügen. Unter Linux verwenden wir standardmäßig nano; unter FreeBSD defaulten wir zu ee. vi(m) ist zulässig, aber vermeiden Sie es in einführenden Themen, wo es ein Hindernis für Anfänger darstellen könnte.

Für die Dateiübertragung empfehlen wir in den meisten Fällen sftp für seine interaktive und scp-ähnliche Nutzung, obwohl es an Push-Funktionalität fehlt, so dass scp akzeptabel ist. rsync ist nützlich für Backups und große Übertragungen (oder viele kleine Dateien). Verwenden Sie unter keinen Umständen FTP. Wir bemühen uns auch, curl gegenüber wget aufgrund seiner Robustheit zu standardisieren. Der Vorteil von wget liegt meist im rekursiven Download (d. h. ein spezieller Anwendungsfall, der für unsere Art von Inhalten nicht üblich ist).

Bei Maschinen, die mit iproute2-Dienstprogrammen ausgeliefert werden, bevorzugen wir diese gegenüber der als veraltet geltenden net-tools-Suite. Im Allgemeinen bieten iproute2-Dienstprogramme wie ss eine bessere Unterstützung für mehrere Schnittstellen, IPv6, neue Kernel-Funktionalitäten usw. Daher sollten wir ip route statt route, ip addr show statt ifconfig usw. verwenden. Manchmal ist die Ausgabe der älteren Dienstprogramme standardmäßig etwas sauberer, aber die Ausgabe selbst ist etwas weniger vertrauenswürdig, da sie Randfälle nicht so gut handhaben. Wo möglich, werden wir die ausführlichere Ausgabe mit verfügbaren Flags steuern.

Skripting

Im Kontext von Systemadministration-Tutorials sollten Sie im Allgemeinen lange benutzerdefinierte Skripte und lange Shell-Skripte vermeiden.

Vom Autor geschriebene Skripte (und möglicherweise andere Ressourcen) sollten in einem pro-Artikel-Repository im do-community GitHub-Account mit einem Link zum veröffentlichten Tutorial leben. Befolgen Sie im Allgemeinen gute Skript-Praktiken. Setzen Sie beispielsweise alle Variablen, die der Benutzer ausfüllen muss, an den Anfang des Skripts, vorzugsweise in einem gut markierten Abschnitt. Geben Sie Inline-Kommentare an, wo nötig, um menschenlesbare Skripte zu liefern. Stellen Sie sicher, dass Ihre Beschreibungen des Codes nicht ausschließlich in Kommentaren gegeben werden, sondern dass Sie auch Prosa-Beschreibungen mit weiteren Erläuterungen als in den Kommentaren geben.

Bevorzugen Sie /bin/sh anstelle von bash und vermeiden Sie Bash-spezifische Features, wenn Portabilität oder plattformübergreifende Wiederverwendung ein Anliegen sind. Verwenden Sie die Shell und coreutils/standard Unix-Werkzeuge für kleine Aufgaben; vermeiden Sie es, neue Abhängigkeiten rein für Klebe-Sprachaufgaben einzuführen, es sei denn, die Vorteile sind erheblich. Bevorzugen Sie #!/usr/bin/env Interpreter gegenüber #!/path/to/interpreter.

Verwenden Sie im Allgemeinen cron für die Planung wiederkehrender Aufgaben, aber systemd-Timer sind auch akzeptabel.

Dateisystem-Standorte

Verwenden Sie your_server_ip und your_domain, wenn möglich, anstatt Dokumentations-IP-Bereiche oder example.com.

Stellen Sie beim Herunterladen von Skripten oder Daten sicher, dass der Benutzer sich in einem beschreibbaren Verzeichnis befindet oder Pfade explizit angegeben sind. Für Dateien, die zur Referenz oder Wiederverwendung verfügbar sein sollten, verwenden Sie das Home-Verzeichnis des Benutzers, es sei denn, sie gehören an einen anderen, standardmäßig gut definierten Pfad im Dateisystem (wie /opt oder /etc). Für Wegwerfdateien verwenden Sie /tmp.

Wenn sich ein Tutorial auf ein bestimmtes Verzeichnis bezieht, stellen Sie sicher, dass Sie die cd-Befehle bereitstellen, die den Leser zu diesem Verzeichnis führen, bevor sie Befehle ausführen.

Webserver

Wir empfehlen die Debian-Stil-Konfigurationsverzeichnisse für Distributionen, die dies nicht standardmäßig so strukturieren. Testen Sie immer Konfigurationsänderungen (Apache verwendet sudo apachectl configtest und Nginx verwendet sudo nginx -t). /var/www/html sollte als Dokumentenstamm für alle Webserver verwendet werden. Nginx’s /usr/share/nginx/html Standard sollte geändert werden, da dieses Verzeichnis dem Paket gehören und potenziell durch Paketaktualisierungen modifiziert werden kann. Dies ist in Ubuntu 16.04 kein Problem mehr, bleibt aber für frühere Versionen relevant.

Für Apache- oder Nginx-Tutorials verwenden Sie dedizierte virtuelle Host-Blöcke anstelle der Bearbeitung der Standardkonfigurationsdateien. Dieser Weg kann häufige Fehler vermeiden und die Standarddateien als beabsichtigte Fallback-Konfiguration beibehalten.

Sicherheit

Verschlüsseln und authentifizieren Sie alle Verbindungen zwischen Systemen. Ermutigen Sie Benutzer nicht (explizit oder implizit), Anmeldeinformationen zu senden oder nicht-öffentliche Daten unverschlüsselt zu übertragen.

Insbesondere dürfen Passwörter und Schlüsselmaterial nicht über unsichere Verbindungen übertragen werden. Datenbankverbindungen, Logging, Cluster-Management und andere Dienste sollten idealerweise jederzeit verschlüsselt sein.

Webbasierte Kontrollfelder müssen über HTTPS-Verbindungen bereitgestellt werden, und TLS/SSL sollte für Dienste verwendet werden, bei denen es unterstützt wird. Alle Webserver sollten HTTPS-fähig (oder zumindest fähig) sein. Verwenden Sie ein certbot-Prerequisit, um SSL-Zertifizierung zu bieten. Öffentlich zugängliche Dienste wie reines HTTP sind zulässig, da Benutzer sie möglicherweise noch anbieten möchten oder müssen, sollten aber im Allgemeinen, besonders bei dynamischen Inhalten, stark abgeraten werden. Für Artikel, die eine reine HTTP-Verbindung bereitstellen, fügen Sie eine Notiz oder Warnung hinzu, um reines HTTP zu entmutigen und HTTPS zu fördern.

Vermeiden Sie Praktiken, die eine geringe Sicherheit durch Obskurität oder Theatralik darstellen, wie das Ändern des Standard-SSH-Ports. Konfigurieren Sie eine Firewall. Unsere distributionsspezifischen Empfehlungen sind ufw für Ubuntu, iptables für Debian und firewalld für CentOS. Allerdings ist iptables am konsistentesten über Plattformen hinweg und verfügt über viele Tools, die darin eingebunden sind.

SSH

Halten Sie den Standard-SSH-Port als Norm bei. Ändern Sie den Port nur in spezifischen Situationen, in denen dies ein primäres Anliegen ist.

Deaktivieren Sie die Passwortauthentifizierung und verwenden Sie nur Schlüsselauthentifizierung für den Root-Zugang oder deaktivieren Sie den Root-Login vollständig. Verwenden Sie starke SSH-Schlüssel: mindestens 2048-Bit RSA, aber 4096 wird empfohlen; ECDSA wird aus technischen Gründen nicht mehr empfohlen; und Ed25519- und elliptische Kurven-Algorithmen sind noch nicht weit genug verbreitet.

Verwenden Sie Passphrasen für interaktive Schlüssel, aber nicht für nicht-interaktive Prozesse. Richten Sie SSH-Schlüssel ein oder kopieren Sie sie und ändern Sie das Eigentum von dem Root-Konto zum Benutzer-Heimverzeichnis. Installieren Sie fail2ban, wo es praktikabel ist.

Beachten Sie, dass SSH-Agent-Weiterleitung für normale Workflows auf Plattformen wie CoreOS notwendig ist, aber auch mit Sicherheitsbedenken verbunden ist. Im Wesentlichen kann jeder mit Berechtigungen auf Ihrem Host den Weiterleitungssocket nutzen, um sich mit Ihrem lokalen ssh-agent zu verbinden.

SSL/TLS

Wir empfehlen dringend die Verwendung von Let’s Encrypt für eine einfache Handhabung und empfehlen TLS. Verwenden Sie starke SSL-Sicherheit; schauen Sie auf https://cipherli.st/ (sowohl moderne als auch Legacy-Empfehlungen).

Für Hosts ohne Domainnamen empfehlen wir ein selbstsigniertes Zertifikat mit ausreichender Stärke. Schauen Sie wieder auf https://cipherli.st/ sowie die Erstellung von selbstsignierten Zertifikaten, die in Anleitungen wie dieser für Nginx verwendet werden. Richten Sie einen starken Diffie-Hellman-Schlüssel ein, wenn Sie die Verschlüsselung aktivieren, wie in den Anleitungen für selbstsignierte SSL-Zertifikate auf Apache und Nginx.

VPN

Wir empfehlen VPNs als Lösung für allgemeine verschlüsselte Kommunikation zwischen Servern. VPNs werden zunehmend wertvoll, wenn mehrere Dienste zwischen Servern geschützt werden müssen; statt jeden Dienst einzeln zu verschlüsseln, kann die gesamte interne Kommunikation durch das VPN geleitet werden. Dieser Ansatz ist besonders nützlich, wenn die betreffenden Dienste keine native Verschlüsselung unterstützen.

Schlussfolgerung

Dies ist ein inhärent meinungsbehaftetes, lebendiges Dokument und wird oft aktualisiert. Die Technik ändert sich schnell, und wir bei Centron tun unser Bestes, um Schritt zu halten, aber wenn Sie Fehler bemerken oder Feedback haben, überwachen wir die Kommentare unten.