Meine Kernkompetenzen und Interessen sind die Low-Level-Mechanismen in Linux:
Kernel
Prozesse
PAM (Pluggable Authentication Modules)
Terminals (tmux; serielle Konsolen)
Shell (bash), Shellscripting
SSH
systemd
LVM
device mapper
MD (multiple devices – Software RAID)
Dateisysteme (ext4, btrfs)
Netzwerk (systemd-networkd; ip; advanced routing; tcpdump; traffic shaping)
Kryptografie (LUKS, OpenPGP, X.509, OpenSSL)
Sicherheit (sudo, capabilities, SELinux)
Firewall (nftables; iptables; firewalld)
Virtualisierung (VMs, nicht Container: Proxmox; libvirtd; QEMU)
GRUB (Bootloader)
...und Puppet. Nicht low-level, aber ständiger Begleiter.
Applikationen, mit denen ich schon zu tun hatte, aber weniger intensiv oder nicht in letzter Zeit:
Ceph
Datenbanken: PostgreSQL, MySQL/MariaDB
Webserver: Apache
Loadbalancer: HAproxy
Python
Redmine (FOSS-Ticketsystem)
Postfix (SMTP)
Dovecot (IMAP)
dnsmasq
IPsec
Git
Docker
Meine Haltung ist, dass Linux-Installationen so gebaut werden sollten, dass das System dann noch möglichst gut funktioniert, wenn Dinge schiefgehen. Richtig schiefgehen. Denn dann will man so schnell wie möglich das eigentliche Problem bearbeiten – und sich nicht erst mal darum kümmern, wie man einen guten (und trotzdem sicheren) Zugang zu dem System bekommt, das womöglich nicht einmal mehr ordentlich bootet. Folgendes ist mir deshalb wichtig:
eine zweite Linux-Installation auf jedem System, ein Rettungslinux (linuxrec) mit den SSH-Schlüsseln der Admins und einem eigenen UEFI-Booteintrag
eine zweistufige GRUB-Installation, deren erste Ebene nie verändert wird – was (zusammen mit dem read-only-Mount von /boot/efi) das Risiko von Problemen beim Update minimiert
Konfiguration der seriellen Konsole in GRUB und der Kernel-Kommandozeile, so dass man den Bootvorgang darüber beeinflussen kann
zwei virtuelle Platten: die erste mit GPT, EFI-Systempartition, L1-GRUB-Partition, /boot-Partition, linuxrec-Partition; die zweite Platte komplett LVM (ohne Partitionstabelle) für triviale Vergrößerungen und Umzug auf eine andere Platte im laufenden Betrieb; relevante Datenmengen immer auf eine gesonderte Platte
getrennte Dateisysteme für v.a. /home, /var und /var/log, so dass
alle Partitionen, die für Nicht-root-User beschreibbar sind, noexec gemountet werden können
dass Volllaufen eines Dateisystems nicht gleich alles im System blockiert
eine Beschädigung des Root-Dateisystems durch einen Absturz, die das Booten verhindert, sehr unwahrscheinlich ist
Einrichtung eines Users (consoleadmin), der sich nur auf der virtuellen oder seriellen Konsole einloggen kann, nicht aber per SSH (was mit terminalspezifischen PAM-Gruppenmitgliedschaften durchgesetzt wird), aber eine SUID-root-Shell hat, die statisch kompiliert ist (sash, busybox, bash-static), damit man auch bei zerstörtem sudo im laufenden System noch reparieren kann
zwei IP-Adressen pro System, damit der Zugang zu Diensten für User sofort und trivial blockiert werden kann (Interface down oder virtuelle Verkabelung im Hypervisor trennen)
SSH-Schlüssel der User außerhalb des Homverzeichnisses, für sie nur lesbar
Zugriff auf SUID- / SGID-Programme über Dateisystemrechte (gesonderte Gruppen) auf die User / Accounts beschränken, die ihn benötigen
Das manuelle Aufsetzen von Linux-VMs und auch Linux-Installationen auf Hardware sollte unbedingt vermieden werden. Meine Vorgehensweise ist, ein gutes Linux-Template zu erstellen, zu klonen und dann mit Puppet einzurichten. Ansible meide ich. Puppets Pull-Ansatz hat generelle Vorteile, aber in erster Linie kann ich die Ansible-Syntax nicht leiden.
Ich bin kein Fan von Containern und noch weniger von der Cloud. Beides hat seine Vorteile, aber ich betrachte Container grundsätzlich misstrauisch als potentiell schlechte Linux-Installationen, die Fehlerbehebung unnötig erschweren. Von Cloud-Techniken habe ich wenig Ahnung, und ich strebe nicht an, mir dieses Wissen anzueignen.