Der Moment*, wenn man nur mal schnell gitea aktualisieren will.
* die Stunden
Vorgeschichte:
Ich habe ein paar interne Dienste mit meiner eigenen Certificate Authority signiert.
Dinge, die ich beim Updaten von gitea getan habe:
- validate_certificates auf true gesetzt 😆
- Versionszähler hochgesetzt
- mit Ansible aktualisiert und debuggt, warum update nicht ging
- Ansible aktualisiert
Auf das Problem gekommen: die gitea VM hat ihrem eigenen Zertifikat nicht getraut.
mittelfristig: mal ein richtiges gitea-Paket verwenden
Todo:
kurzfristig: Meine Ansible Rollen erweitern. Die CA muss überall noch zu den vertrauenswürdigen Stellen und mein Playbook hatte auch das signierte Zertifikat wieder überschrieben.
Der Moment, wenn Ansible 1,5h hängt, aber angeblich jeder Task unter 6 Sekunden gedauert hat. 🙃
Problem gefunden:
- name: enable ufw
ufw:
state: enabled
Das führt ein ufw -f enable (inkl. kurzem Verbindungsabbruch) aus, egal ob ufw an ist oder nicht. Wenn man das dann noch gleichzeitig auf alle Hosts und den Ansiblerechner los lässt, dann trennt man mal schnell alle Verbindungen 🙄
ufw ist aber auch nicht gerade schnell:
time sudo /usr/sbin/ufw default allow outgoing
Default outgoing policy changed to 'allow'
(be sure to update your rules accordingly)
real 0m6.567s
user 0m2.798s
sys 0m3.685s
Ich weiß gar nicht, wo ich mich beschweren soll. Das ist nur auf dem Raspberry Pi so langsam. Sonst ist es nur 2 Sekunden langsam
@flo Ja. Aber ich denke mal firewalld wäre die beste alternative (ich denke mal nicht du willst iptables nutzen :))
Ansonnsten find ich ja safing's portmaster interessant, allerdings hat das natürlich nichts auf einem server zu suchen.
@sp1rit firewalld ist auch eine ernstzunehmende Alternative. Leider ist das dann schon ein größerer Aufwand :/