1 Jahr Blog hinter dem Webcache

Wir haben hier natürlich für den November 2023 nur einen halben Monat, weil die Stats vom 13. des Monats sind. Eine kleine Rückschau zur Technik gibt es auch noch.

Sie verpassen nichts, sind nur Zahlen pro Monat mit einigen Balkendiagrammen.

1 Jahr Blog Zugriffszahlen

Einfach nur Zahlen veröffentlichen kann jeder, deswegen ein kleiner Bericht aus dem Jahr des Caches.

Aus dem Leben eines Webcaches

Die meiste Zeit lief das Cache problemlos, sonst hätte ich es auch nicht benutzt. Die Vorteile liegen klar auf der Hand, weil die Zugriffszeiten massiv verbessert wurden. Allerdings stieg auch der Komplexitätsgrad der Serverkonfiguration an:

– DNS Proxies
– Backend-Webserver
– Fake DNS Server
– Cacheserver

Ohne groß ins Detail zu gehen, weil mit irgendwas muß man ja sein täglich Brot verdienen ;), kommen wir zu einer Besonderheit der Konstruktion: Der Backendserver hat eine andere IP als der Cacheserver.

Weil das so ist, muß man dem Cache irgendwie mitteilen, daß eine aufgerufene Domain eine ganz andere IP hat. Dazu benutzt man einen FakeDNS Server. Der war in Perl geschrieben und besteht im Prinzip nur aus einer einzigen Schleife: „Wenn wer fragt, sagt diese IP auf“. Das dumme daran ist, es ist Perl. Perl fällt aus bzw. für den Fragenden kommt einfach ab und zu mal keine Antwort.

„Keine Antwort“ meint aber im Cache: „Hey, der DNS Server ist tod.“   Was macht ein Cache wenn der Server „tod“ ist? Genau, es entfernt den DNS aus der Liste der aktiven DNS Server. Ziemlich blöd, wenn das nur ein Server ist 🙁 Also haben wir zwei konfiguriert und das Cache sollte Roundrobin machen. Machts aber nicht, auch wenn es in der Anleitung steht 😉

d.h. ein dritter FakeDNS mußte her und da hörte der Spaß auf. Statt noch ein Perlscript zu starten, wurde named als Forwarder konfiguriert. Das antwortet jetzt immer stabil  auf Anfragen, weil es nur einmal am Tag nachfragt und geht so mit den arbeitsscheuen Perlscripten wohlwollend um.

Warum Perlscripte?

Weil um eine einzige IP auszugeben, ein vollwertiger PowerDNS nebst Datenbank vielleicht ein bisschen zu viel wäre. Dachte ich. Heute tendiere ich dazu mal entsprechend umzubauen, weil das den Komplexitätsgrad verringert und die Stabilität erhöht. Der Preis wird eine Datenbank basierte Pflege beinhalten, statt einfach ‚echo „domain.de 123.45.67.89“ >> fakedomainliste.txt‚ zu benutzen. Ein kleiner Preis, im Vergleich zum Stress durch die Ausfälle.

Wenn Ihr also plant WordPress mit einem Cache zu betreiben, dann macht es gleich richtig.

Praktischerweise konnte man aus diesem privaten Beispiel sehr viel für unsere Firma übernehmen und jetzt haben wir ein miniCloudflare, nur ohne Abhängigkeit von einer US-Firma \o/  Das reduziert die Last und macht Kunden glücklich.

Linux am Dienstag – Programm für den 22.8.2023

Es ist Dienstag und wir haben da mal wieder etwas Linux im Gepäck: Perl, SED, Sqllite das ganze Drama 😉

Linux am Dienstag – Programm für den 22.8.2023

am Dienstag geht es ab 19 Uhr u.a. um folgende Themen:

    • Vortrag – Perl statt SED
    • Datenbanken – Von der Misere SQLITE zu exportieren
    • Sicherheit – Google glaubt an Post-Quantum-Verschlüsselung in Chrome II
    • EMails – Hotmail + DNS Panne = Spams
    • Sicherheit – WINRAR mit RCE Exploit

und andere IT-Newsbeiträge aus aller Welt. Wie jede Woche per Videokonferenz auf https://meet.cloud-foo.de/Linux .

Hinweis: Die bisherigen Vorträge findet man unter https://linux-am-dienstag.de/archiv/ .

g..g..gi…gi..git…gitolite!

Ok, sehr dramatischer Titel, ich gebs zu 🙂 Gitolite kennt der ein oder andere Entwickler sicher, weil man damit auf seinem eigenen Server Git Repos nutzen kann, was auch gern benutzt wird.

g..g..gi…gi..git…gitolite!

Nun ist gitolite keine neue Erfindung, sondern schon eine Weile alt. So alt, daß es schon seit 2017 gitolite3 gibt. Gitolite(2)  wurde dagegen eingestellt, weil es EOL hatte. Fedora stellt daher dafür keine Pakete mehr zur Verfügung und installiert ersatzweise gitolite3.

„Das ist blöd!“ stellten wir nach einem Serverupgrade fest, da das Paket gitolite(2) beim Löschen 6 GB Projektdaten mit ins Nirvana gezogen hatte, da diese im Homedir liegen.. dachten wir. Zum Glück hatten wir eine Anpassung für Chroots gemacht, so daß nur der Link auf das Homedir gelöscht wurde, aber die Daten noch in der Chroot lagen. Wir hätten natürlich auch ein Backup gehabt, aber so war es noch einfacher.

„Bekomme es wieder zum Laufen…“

Etwas schwieriger gestaltete sich die Reinstallation unter Fedora 31, da sich zwischenzeitlich Perl von 5.28 auf 5.30 geändert hatte, und gitolite Paket aber unbedingt 5.28 haben wollte. Nun ja, Perl 5.30 zu entfernen kam nicht in Frage, also riskierten wir es und installierten gitolite ohne Abhängigkeiten:

rpm -i –nodeps https://kojipkgs.fedoraproject.org//vol/fedora_koji_archive04/packages/gitolite/2.3.1/18.fc29/noarch/gitolite-2.3.1-18.fc29.noarch.rpm

Zum Glück funktioniert gitolite 2.3.1 auch mit Perl 5.30 bislang ohne Fehler, so daß erstmal weiter gearbeitet werden kann. Es ist nämlich durchaus ein mächtiges Stück Arbeit, von Gitolite2 auf Gitolite3 umzusteigen, wie die Migrationsanweisung zeigt. Daher hat der Betroffene nun gleich Gitlab ins Auge gefasst. Mal sehen wie das wird 😉