Ab einer gewissen Anzahl von Argumenten wünscht man sich für eigene Python-Skripte eine automatische Vervollständigung nach dem Vorbild von Standardwerkzeugen, und wie immer ist man mit diesem Wunsch im Internet nicht allein.
shtab erzeugt automatisch zsh completion scripts, wenn
- das Skript eine Funktion enthält, die ein
argparse.ArgumentParser()-Objekt zurückliefert - man dem initiierenden Aufruf dieses Objekts den Parameter
prog (parser = argparse.ArgumentParser(description='Backup with rsync', prog='rb')) oder shtab das Argument --prog=rb beifügt rb kein in .zshrc definiertes Alias, sondern – wenn schon nicht der Name des Programms – wenigstens ein Symlink ist
Ist eine dieser Voraussetzungen nicht erfüllt, scheitert die Generierung, oder das gewünschte completion script wird nicht für rb herangezogen. Andernfalls hat –
shtab --shell=zsh rbackup.get_parser | sudo tee /usr/local/share/zsh/site-functions/_rb
– den gewünschten Effekt. Zwar habe ich mehr als die der Zeitersparnis angemessenen 30 Minuten investiert, aber man kann nicht alles messen.
Der Eintrag von Servernamen in /etc/hosts genügt, um aus einem Redaktionssystem aus Sicht des Browsers einen namentlich ansprechbaren Webserver zu machen, aber auch ambitionierte Amateurinnen sollten nicht auf ein getrenntes System verzichten. Statt DNSMasq oder einem teuren Router kann man unter Ubuntu Bind9 konfigurieren, um eine eigene TLD im lokalen Netz zu etablieren:
# /etc/bind/named.conf.local
zone "mytld" {
type master;
file "/etc/bind/db.mytld";
};
# /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
dnssec-validation auto;
validate-except { "mytld"; };
forwarders { 1.1.1.1; };
listen-on { 127.0.0.1; 192.168.78.0/24; };
listen-on-v6 { any; };
};
# /etc/bind/db.mytld
$TTL 604800
@ IN SOA ns.mytld. root.mytld. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns.mytld.
* IN A 192.168.78.42
Als Nameserver für alle anderen Domains (forwarders) kommt Cloudflare (1.1.1.1) zum Einsatz, und die DNSSEC-Validierung wird für die neue TLD deaktiviert. Interessanterweise hält diese Konfiguration Bind9 nicht davon ab, sich bei Cloudflare (erfolglos) nach dem Delegation Signer zu erkundigen:
16:28:34.165569 IP myserver.49728 > one.one.one.one.domain: 45669+% [1au] DS? mytld. (46)
16:28:34.179688 IP one.one.one.one.domain > myserver.49728: 45669 NXDomain* 0/6/1 (1026)
Wenn nun der neue DNS-Server auf einem lokalen Netgear-Router hinterlegt wird, bringt man sich um die Segnungen von DNSSEC, weil Netgear DNSSEC-Unterstützung im privaten Bereich offenbar für unnötig hält. Stattdessen müssen alle lokalen Endgeräte (solange sie sich im heimischen LAN/WLAN aufhalten) direkt mit dem DNS-Server und Cloudflare als Fallback interagieren.
Erstaunlich schwierig ist es, den Server zum dogfooding zu bewegen: Er erhält per DHCP die IP-Adresse des Routers und verwendet sie auch für DNS-Anfragen. Trägt man die Loopback-Adresse 127.0.0.1 in /etc/systemd/resolved.conf ein, meldet resolvectl status zwar:
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
aber wegen der fehlenden netplan-Konfiguration auch:
Link 2 (eno1)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.78.1
DNS Servers: 192.168.78.1
Abhilfe schaffen – anders als von Kumar getestet – nur folgende Einträge in /etc/netplan/00-installer-config.yaml:
network:
ethernets:
eno1:
dhcp4: true
dhcp4-overrides:
use-dns: false
nameservers:
addresses: [127.0.0.1]
version: 2
in Verbindung mit DNSSEC=yes in /etc/systemd/resolved.conf:
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported
resolv.conf mode: stub
Link 2 (eno1)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=yes/supported
Current DNS Server: 127.0.0.1
DNS Servers: 127.0.0.1
Den autoritativen Nameserver für eine TLD zu betreiben, ist ein erhebendes Gefühl (trotz kleiner Schwierigkeiten mit modernen HTTPS-Einträgen).