Spaß mit dem Serverwechsel (Uwe Ohse)

Spaß mit dem Serverwechsel

Aus $GRÜNDEN (haben viel mit dem Forum und unkalkulierbarem Platzbedarf nach geplanten Softwareänderungen und Vergrößerungen von Limits zu tun) wechsele ich gerade von einem Server zum Nächsten. Die Idee war natürlich, die ganzen Container schnell auf die neue Maschine zu ziehen, und dann da irgendwann (wann auch immer) aufzuräumen - sprich, die Sachen aus den alten void-linux-Containers in neue Container mit Alpine darin zu bringen, wenn mal Zeit ist (und irgendwann wäre dafür auch Zeit für gewesen, in den drei Web-Containern habe ich viel zu viel Zeug ausprobiert, und nicht immer ganz sauber wieder weggeräumt. Von daher ist ein gewisser Leidensdruck gegeben). Heute morgen wollte ich dann den Container mit meinem Web-Zeugs darin umziehen (als Erstem, und Unwichtigstem). Das sollte ja eine Kleinigkeit sein. Sollte. Na ja, war's auch. Rsync, Datenbank eingespielt, ein paar IP-Adressen angepasst (disjunkte IP-Adress-Bereiche auf den Servern, und so soll das auch sein), und fertig. Fertig? Nein. "setuidgid some-user /usr/local/bin/caddy /etc/caddy/Caddyfile" - "permission denied". Bitte was? Damit begann die Suche. Habe ich irgendwo die Zugriffsrechte verhunzt? Nein. Habe ich irrtümlich einen unpriviligierten Container konfiguriert? Nein. Habe ich irgendwelche hilfreichen Meldungen in irgendwelchen Logfiles? Nein (nicht mal nicht hilfreiche). Kann ich das dämliche Binary aufrufen, wenn ich mich als 'some-user' anmelde (was nicht Sinn der Übung wäre): Ja. What? Wenn ich statt setuidgid su oder sudo nehme, funktioniert es dann? Nein. Habe ich irgendwie die Capabilities versaut? Nein. Apparmor aus, ändert sich 'was? Nein. Ändert sich etwas, wenn ich dasselbe Container-Rootfs in einen anderen Container stecke, bei dem alles reibungslos läuft? Nein, es funktioniert immer noch nicht. Irgendwann ist mir dann die Lust ausgegangen, und ich hab' diesen verdammten Container einfach neu aufgesetzt, und nur /var/www 'rüberkopiert. Und siehe da, obige Zeile mit setuidgid funktioniert. Was los war? Keine Ahnung. Ich sterbe wahrscheinlich dumm. Aber damit habe ich zwar einen funktionierenden Container, aber keinen funktionierenden Webauftritt, denn nun durfte ich erst einmal ein paar Pakete nachinstallieren ("paar" = 28), und eben nur die, die ich wirklich brauche (der neue Container sollte möglichst aufgeräumt sein). Ausprobiert. Läuft. Fast. Problem #1: Der Thumbnail-Generator läuft nicht. WTF? Das ist doch nur ein billiger Wrapper um imagemagick und zu 99% überflüssig. Okay, ich habe offensichtich das eine Prozent getriggert. ~~Ich kenne meine Software echt gut...~~ Aber warum läuft das Script nicht? Zugriffsrechte? Nein. Falscher Pfad irgendwo? Nein. Inkompatibles imagemagick? Nein (seit Ewigkeiten nicht mehr vorgekommen). #!/bin/bash am Anfang? Ja. Bash installiert? Tatsächlich nicht, ich hab' tatsächlich die ganze Zeit mit ash und mksh gebastelt. Soweit, so gut. Läuft's? Ja. Also… abgesehen von diesen sporadisch auftauchenden Template-Snippets, Problem #2. Hm. bbcode installiert? Nein. Ok, das lässt sich schnell machen. 5 Minuten? Na ja, 15, ich musste erst mal meine gepatchte Version für PHP 7.3 wieder finden. So weit, so gut. Läuft es? Ja. Ok, bekomme ich auch Daten ins Monitoring? Nein. Stimmt ja, ich hab' da noch einige NAT-Regeln einzubauen. Ähm. Will ich wirklich diese Wüste von NAT-Regeln auf die neue Maschine bringen? Nein, ganz sicher nicht. Also... ab mit den Dingern hinter einen Reverse-Proxy (sagte ich schon, dass ich caddy liebe?). Eintragen in Prometheus, killall -1 prometheus, und warten... die Metriken tauchen nicht auf. promtool check config? Oops, er mag ja keine doppelten Job-Namen. Also so: - job_name: 'caddy' scheme: https metrics_path: /exporters/caddy/metrics basic_auth: username: "jemand" password: "etwas" static_configs: - targets: ['uwe.ohse.de'] - job_name: 'caddy-old-stuff' static_configs: - targets: ['10.11.12.13:9180'] # oder so. - [...] relabel_configs: - target_label: job replacement: caddy Und das machen wir jetzt mal für: caddy, memcache, opcache, php-fpm und mtail. So häßlich sieht die Prometheus-Konfiguration hoffentlich nur vorübergehend aus. Nein, ich bin nicht überzeugt, dass es eine gute Idee ist, die Häßlichkeit der Konfiguration von /etc/firewall-up.sh auf Caddyfile und prometheus.yml zu übertragen. In erster Linie wollte ich die Übertragung der Metriken verschlüsseln. Nächster Spaß: DNS umstellen. 5 Minuten… na gut, doch ein paar mehr. Wie immer. Wieso in aller Welt sind da noch etwas 15 Jahre alte Einträge? Warum räume ich das nicht auf? Ah... verflixt, die Adressen werden ja im VPN gebraucht. Hm. Das könnte ich auch mal aufräumen, dann wird das Zeug gleich 10 mal übersichtlicher, denke ich… aber nicht heute. Habe ich noch etwas zu tun? Kann der Container Mails versenden? Nein, kann er nicht. WTF? Ich habe doch exakt dieselbe doofe dma-Konfiguration verwendet wie anderswo, und da klappt es doch überall? Richtig, aber anderswo heißt der Container nicht "ohse.de". dma schneidet den eigenen Hostnamen beim Empänger immer ab (auch bei NULLCLIENT / SMARTHOST -Konfiguration, was ziemlich buggy ist), und mein Mailserver erwartet voll qualifizierte Empfängeradressen. Hm. Der Mailserver hat einfach Recht. dma macht an der Stelle Mist. Na gut, einen qmail als lokales Gateway aufzusetzen kostet ja nur ein paar Minuten (10, wegen Tippfehler). Aber mal nachdenken… ist "ohse.de" wirklich ein guter Hostname für den Container? Besser als "ohse" oder "web" oder so ist er auf jeden Fall, aber… jetzt habe ich in den Mails so tolle Sachen wie das hier: Received: (qmail 10544 invoked from network); 1 Feb 2020 18:23:14 -0000 Received: from x9.ohse.de (116.202.157.120) by mail with ESMTP; 1 Feb 2020 18:23:08 -0000 Received: (qmail 32581 invoked from network); 1 Feb 2020 18:22:54 -0000 Received: from unknown (HELO ohse.de) (10.9.8.1) by x9.ohse.de with SMTP; 1 Feb 2020 18:22:54 -0000 Received: from root (uid 0) (envelope-from root@ohse.de) id 31c0675 by ohse.de (DragonFly Mail Agent v20190809.644.g2670b36942); Sat, 01 Feb 2020 18:22:54 +0000 Was halb so wild wäre, wenn der Container, auf dem der wirkliche Mailserver läuft, nicht auch ohse.de heißen könnte. Er heißt jetzt mail, und das ist nicht schlecht, aber es wäre schon schöner, wenn man auch im Halbschlaf keine Verwechselungen begehen könnte. Also? Klar - sämtliche Container noch mal umbenennen. Sagen wir, auf uwe.x9.ohse.de (auch nicht ganz perfekt, aber ohse.x9.ohse.de ist verwechselbarer, und ohse.de.x9... ist einfach zu lang, und www geht wirklich nicht, weil da noch andere Container mit Web-Zeug darin sein werden), db.x9.ohse.de, ... So weit, so gut. Jetzt könnte man noch einen Reboot-Test machen. Sollte man… meinte ich.

Aus $GRÜNDEN (haben viel mit dem Forum und unkalkulierbarem Platzbedarf nach geplanten Softwareänderungen und Vergrößerungen von Limits zu tun) wechsele ich gerade von einem Server zum Nächsten.

Die Idee war natürlich, die ganzen Container schnell auf die neue Maschine zu ziehen, und dann da irgendwann (wann auch immer) aufzuräumen - sprich, die Sachen aus den alten void-linux-Containers in neue Container mit Alpine darin zu bringen, wenn mal Zeit ist (und irgendwann wäre dafür auch Zeit für gewesen, in den drei Web-Containern habe ich viel zu viel Zeug ausprobiert, und nicht immer ganz sauber wieder weggeräumt. Von daher ist ein gewisser Leidensdruck gegeben).

Heute morgen wollte ich dann den Container mit meinem Web-Zeugs darin umziehen (als Erstem, und Unwichtigstem). Das sollte ja eine Kleinigkeit sein.

Sollte. Na ja, war's auch. Rsync, Datenbank eingespielt, ein paar IP-Adressen angepasst (disjunkte IP-Adress-Bereiche auf den Servern, und so soll das auch sein), und fertig.
Fertig?

Nein. "setuidgid some-user /usr/local/bin/caddy /etc/caddy/Caddyfile" - "permission denied".

Bitte was? Damit begann die Suche.

Habe ich irgendwo die Zugriffsrechte verhunzt? Nein.
Habe ich irrtümlich einen unpriviligierten Container konfiguriert? Nein.
Habe ich irgendwelche hilfreichen Meldungen in irgendwelchen Logfiles? Nein (nicht mal nicht hilfreiche).
Kann ich das dämliche Binary aufrufen, wenn ich mich als 'some-user' anmelde (was nicht Sinn der Übung wäre): Ja. What?
Wenn ich statt setuidgid su oder sudo nehme, funktioniert es dann? Nein.
Habe ich irgendwie die Capabilities versaut? Nein.
Apparmor aus, ändert sich 'was? Nein.
Ändert sich etwas, wenn ich dasselbe Container-Rootfs in einen anderen Container stecke, bei dem alles reibungslos läuft? Nein, es funktioniert immer noch nicht.

Irgendwann ist mir dann die Lust ausgegangen, und ich hab' diesen verdammten Container einfach neu
aufgesetzt, und nur /var/www 'rüberkopiert. Und siehe da, obige Zeile mit setuidgid funktioniert. Was los war? Keine Ahnung. Ich sterbe wahrscheinlich dumm.

Aber damit habe ich zwar einen funktionierenden Container, aber keinen funktionierenden Webauftritt, denn nun durfte ich erst einmal ein paar Pakete nachinstallieren ("paar" = 28), und eben nur die, die ich wirklich brauche (der neue Container sollte möglichst aufgeräumt sein).

Ausprobiert. Läuft. Fast.
Problem #1: Der Thumbnail-Generator läuft nicht. WTF? Das ist doch nur ein billiger Wrapper um imagemagick und zu 99% überflüssig. Okay, ich habe offensichtich das eine Prozent getriggert. ~~Ich kenne meine Software echt gut...~~ Aber warum läuft das Script nicht? Zugriffsrechte? Nein. Falscher Pfad irgendwo? Nein. Inkompatibles imagemagick? Nein (seit Ewigkeiten nicht mehr vorgekommen). #!/bin/bash am Anfang? Ja. Bash installiert? Tatsächlich nicht, ich hab' tatsächlich die ganze Zeit mit ash und mksh gebastelt.

Soweit, so gut. Läuft's?
Ja. Also… abgesehen von diesen sporadisch auftauchenden Template-Snippets, Problem #2. Hm. bbcode installiert? Nein. Ok, das lässt sich schnell machen. 5 Minuten? Na ja, 15, ich musste erst mal meine gepatchte Version für PHP 7.3 wieder finden.

So weit, so gut. Läuft es? Ja.

Ok, bekomme ich auch Daten ins Monitoring?
Nein.
Stimmt ja, ich hab' da noch einige NAT-Regeln einzubauen.
Ähm. Will ich wirklich diese Wüste von NAT-Regeln auf die neue Maschine bringen? Nein, ganz sicher nicht.
Also... ab mit den Dingern hinter einen Reverse-Proxy (sagte ich schon, dass ich caddy liebe?).

Eintragen in Prometheus, killall -1 prometheus, und warten... die Metriken tauchen nicht auf.
promtool check config? Oops, er mag ja keine doppelten Job-Namen. Also so:

- job_name: 'caddy'
scheme: https
metrics_path: /exporters/caddy/metrics
basic_auth:
username: "jemand"
password: "etwas"
static_configs:
- targets: ['uwe.ohse.de']

- job_name: 'caddy-old-stuff'
static_configs:
- targets: ['10.11.12.13:9180'] # oder so.
- [...]
relabel_configs:
- target_label: job
replacement: caddy

Und das machen wir jetzt mal für: caddy, memcache, opcache, php-fpm und mtail. So häßlich sieht die Prometheus-Konfiguration hoffentlich nur vorübergehend aus.
Nein, ich bin nicht überzeugt, dass es eine gute Idee ist, die Häßlichkeit der Konfiguration von /etc/firewall-up.sh auf Caddyfile und prometheus.yml zu übertragen. In erster Linie wollte ich die Übertragung der Metriken verschlüsseln.

Nächster Spaß: DNS umstellen. 5 Minuten… na gut, doch ein paar mehr. Wie immer. Wieso in aller Welt sind da noch etwas 15 Jahre alte Einträge? Warum räume ich das nicht auf? Ah... verflixt, die Adressen werden ja im VPN gebraucht. Hm. Das könnte ich auch mal aufräumen, dann wird das Zeug gleich 10 mal übersichtlicher, denke ich… aber nicht heute.

Habe ich noch etwas zu tun? Kann der Container Mails versenden?
Nein, kann er nicht. WTF? Ich habe doch exakt dieselbe doofe dma-Konfiguration verwendet wie anderswo, und da klappt es doch überall?
Richtig, aber anderswo heißt der Container nicht "ohse.de". dma schneidet den eigenen Hostnamen beim Empänger immer ab (auch bei NULLCLIENT / SMARTHOST -Konfiguration, was ziemlich buggy ist), und mein Mailserver erwartet voll qualifizierte Empfängeradressen. Hm.
Der Mailserver hat einfach Recht. dma macht an der Stelle Mist. Na gut, einen qmail als lokales Gateway aufzusetzen kostet ja nur ein paar Minuten (10, wegen Tippfehler).

Aber mal nachdenken… ist "ohse.de" wirklich ein guter Hostname für den Container? Besser als "ohse" oder "web" oder so ist er auf jeden Fall, aber… jetzt habe ich in den Mails so tolle Sachen wie das hier:


Received: (qmail 10544 invoked from network); 1 Feb 2020 18:23:14 -0000                                                                                                                                                                                      
Received: from x9.ohse.de (116.202.157.120)                                                                                                                                                                                                                  
        by mail with ESMTP; 1 Feb 2020 18:23:08 -0000                                                                                                                                                                                                        
Received: (qmail 32581 invoked from network); 1 Feb 2020 18:22:54 -0000                                                                                                                                                                                      
Received: from unknown (HELO ohse.de) (10.9.8.1)                                                                                                                                                                                                     
        by x9.ohse.de with SMTP; 1 Feb 2020 18:22:54 -0000                                                                                                                                                                                                   
Received: from root (uid 0)                                                                                                                                                                                                                                  
        (envelope-from root@ohse.de)                                                                                                                                                                                                                 
        id 31c0675                                                                                                                                                                                                                                           
        by ohse.de (DragonFly Mail Agent v20190809.644.g2670b36942);                                                                                                                                                                                 
        Sat, 01 Feb 2020 18:22:54 +0000

Was halb so wild wäre, wenn der Container, auf dem der wirkliche Mailserver läuft, nicht auch ohse.de heißen könnte. Er heißt jetzt mail, und das ist nicht schlecht, aber es wäre schon schöner, wenn man auch im Halbschlaf keine Verwechselungen begehen könnte.

Also? Klar - sämtliche Container noch mal umbenennen. Sagen wir, auf uwe.x9.ohse.de (auch nicht ganz perfekt, aber ohse.x9.ohse.de ist verwechselbarer, und ohse.de.x9... ist einfach zu lang, und www geht wirklich nicht, weil da noch andere Container mit Web-Zeug darin sein werden), db.x9.ohse.de, ...

So weit, so gut.

Jetzt könnte man noch einen Reboot-Test machen. Sollte man… meinte ich.

Diashow