Homelab, Linux, JS & ABAP (~˘▾˘)~
 

Tag: wordpress

Uncategorized

[Blog] Umzug von Strato zu Netcup

 , , , , , , , ,

Mein letzter Blog-Umzug war im Juli 2020 von DigitalOcean zu Strato (siehe hier). Nun war es mal wieder Zeit.

Der Blog und alle meine weiteren Docker Container sind nun endlich nach über 4 Jahren von einem Strato VPS zu einem Netcup VPS auf ARM Basis umgezogen. Obwohl ich schon viele schlechte Erfahrungen mit Strato gemacht hatte, habe ich trotzdem damals den VPS bei Strato abgeschlossen, da dieser mit 1TB SSD Speichern zu der Zeit konkurrenzlos viel Speicher für 15 € im Monat bot. Das war für den Betrieb einer Nextcloud für mich entscheidend. Aber meine schlechten Erfahrungen setzten sich fort. Ich kann gar nicht aufzählen, wie viele Performanceprobleme und Ausfälle es gab. Manchmal nur ein paar Minuten oder Stunden. Manchmal auch einfach mehrere Tage. Anfangs habe ich noch Tickets aufgemacht, aber irgendwann hatte ich darauf auch keine Lust mehr. Warum ich trotzdem so lange bei Strato war? Wohl einfach aus faulheit… Aber als Strato diesem Sommer auch noch den Preis für den V40-16 von 15€ auf 17,70€ angehoben hat, vermutlich primär um die Altkunden loszuwerden bzw. diese zu drängen von der Virtuozzo auf die neue KVM Virtualisierungsplattform zu wechseln, war es endgültig genug. Hab mich einige Wochen nach VPS Anbietern umgeschaut, die einen VPS mit viel Speicher anbieten und wurde Ende Oktober bei Netcup fündig, als es eine Angebotsaktion gab, bei der für bestimmte VPS der Speicher verdoppelt wurde. Die Aktionsproduktseite gibt es nicht mehr, aber es handelt sich quasi um dieses Produkt mit doppeltem Speicher:
https://www.netcup.com/de/server/arm-server/vps-3000-arm-g11-mnz#vps-3000-arm-g11-vie
In meinem Fall also: VPS 3000 ARM G11 SE VIE SPS24 mit 1536 GB NVMe Speicher für 16,95 €

Das ganze auch noch monatlich kündbar und nicht mehr wie bei Strato jährlich. Für quasi das gleiche Geld gab es hier also erheblich mehr Leistung. Einziger “Knackpunkt”, der neue Server bedeutete auch ein Wechsel der CPU Architektur von x86 auf ARM. Ich habe daher sicherheitshalber erstmal für meine aktuell genutzten Anwendungen

  • WordPress
  • Nginx Proxy Manager
  • Nextcloud
  • OnlyOffice
  • Collabora
  • Vaultwarden
  • SMTP
  • Portainer
  • TeamSpeak3

geprüft, ob auch Docker Images für ARM bereitgestellt werden. Lediglich bei zwei Anwendungen war das nicht der Fall. Der Teamspeak3 Server, sowie der SMTP Container. Nach kurze Recherche habe ich aber direkt Ersatz gefunden (TS3 & SMTP). Wirklich neu aufsetzen musste ich daher lediglich den TeamSpeak3 Server, aber der Aufwand hielt sich in Grenzen.

Die ganze Migration verlief erheblich einfacher als erwartet. Mit dem folgenden Befehl habe ich jeden Ordner meiner Docker Anwendungen (praktischerweise hab ich damals alles ohne Docker Volumes aufgesetzt, alle Daten liegen also direkt in dem gleichen Ordner wie die docker-compose.yml) nacheinander auf den neuen Server übertragen. Bis auf die Nextcloud, eine Sache von wenigen Minuten.

sudo rsync -azP /opt/containers/nextcloud/ root@ip-address:/opt/containers/nextcloud

Danach noch die DNS Einträge angepasst und gewartet, bis diese sich aktualisieren. Bei der Nextcloud und Vaultwarden gingen komischerweise die User:Group Zuordnungen zum Teil nicht sauber rüber. Da musste ich daher noch kurz etwas nacharbeiten. Im Nginx Proxy Manager habe ich noch alle Zertifikate einmal aktualisiert und nach wenigen Stunden waren dann alle Container wieder über alte URL erreichbar.

Hätte ich geahnt, dass der Serverumzug so reibungslos verläuft, hätte ich das auf jeden Fall schon vor Jahren gemacht. Mit Netcup bin ich vollkommen zufrieden und mein Uptime Kuma konnte bisher kein einziges Erreichbarkeitsproblem des VPS feststellen, im Gegensatz zum Strato VPS, der immer mal wieder für einige Minuten nicht auf den Ping Test reagiert. Ich kann daher nur nochmals von den Strato VPS Produkten abraten.

WordPress

[WordPress] 4 levels of caching

 , ,

Good overview on: https://www.smarthomebeginner.com/wordpress-on-docker-traefik/#3_WordPress_Caching

Browser Caching: This is what tells the visitors browser to cache the files locally to speed up future site/page visits. We will set this up using Nginx. On Apache, this is accomplished using .htaccess files.

Server Caching: This caches static versions of pages (Page cache). We are going to accomplish this using Nginx FastCGI cache.

Frontend Caching: This means caching WordPress PHP files so they don’t have to be re-compiled for every visit. We are going to set this up using PHP OpCache.

Database Caching: This optimizes database queries by storing them in the RAM for faster delivery. We are going to use Redis for this.

Uncategorized

Blog umgezogen -> Docker

 , , , , , , , , , , , , , , , ,

Heute habe ich den Blog von einem DigitalOcean Droplet auf einen V-Root Server bei Strato umgezogen. Da der V-Root etwas mehr Power hat, werde ich einige Dienste, die ich bereits privat auf meinen Proxmox Servern hoste, auch auf den Strato Server umziehen. Bisher habe ich meine Anwendungen überwiegend in LXC’s (Linux Containern) oder auch VM’s installiert. In Kombination mit ZFS als Dateisystem (mit der großartigen Snapshot Fähigkeit) bin ich damit die letzten 4 Jahre ohne Probleme gefahren. Bei einem V-Root ist diese Möglichkeit nun nicht mehr gegeben. Daher habe ich die Chance genutzt, tiefer in das Thema Docker einzusteigen. Bisher habe ich nur vereinzelt Docker Container genutzt und die wenigen jeweils auch nochmal in einem LXC (vereinfachte mir das Snapshot handling). Nun also mal der Versuch, komplett auf Docker umzusteigen.

Der WordPress Blog ist als erstes in einen Docker Container umgezogen. Danach habe ich noch Nextcloud (plus OnlyOffice & Collabora) und Bitwarden aufgesetzt. Hier werde ich jedoch noch ein paar Tage testen, bevor ich mit all meinen Daten rüber migriere. Da man immer wieder von Traefik als Reverse Proxy in Kombination mit Docker liest, habe ich diesen probiert, jedoch nach mehreren Stunden etwas gefrustet wieder sein lassen. Auch wenn die ersten Services ganz gut damit liefen, scheint mir der Aufwand erheblich höher und die benötigten Labels für jeden Container nicht grade intuitiv. Da in den meisten Dokus Beispiele für Nginx zu finden sind, bin ich zurück zu dem Nginx Proxy Manager, welchen ich bereits seit Jahren erfolgreich zuhause im Einsatz habe. Auch wenn das bedeutet, dass ein Docker Container nun nicht “automatisch” via Traefik (durch 10-20 vorher zusammen gesuchte Labels je Service….) nach außen bereitgestellt wird, sondern nur nach “einigen wenigen” Klicks im Nginx Proxy Manager…. Nach meinem Gefühl, gibt sich das irgendwie nicht viel.

Einige weitere Dienste stehen noch auf der Liste und auch ein paar neue Sachen möchte ich mit aufnehmen. Bereits installiert sind:

  • WordPress
  • Nginx Proxy Manager
  • Nextcloud
  • OnlyOffice
  • Collabora
  • Bitwarden
  • MyPhpAdmin

Es folgen noch:

  • Portainer
  • Wallabag
  • Gitlab
  • Jitsi
  • Teamspeak
  • PiHole
  • Wireguard
  • OpenLDAP

Und je länger man nachdenkt, desto mehr fällt einem sicherlich noch ein. 🙂
Die Docker-Compose Dateien werde ich dann final auch hier Veröffentlichen mit allen zugehörigen Links, die mir bei der ein oder anderen Schwierigkeit geholfen haben.

WordPress

[WordPress] SyntaxHighlighter Ampersand character

 , ,

Recently I noticed that the character & is displayed in the SyntaxHighlighter like this: &amp

To fix this, simply add this snippet of the user kaggdesign to /var/www/html/wp-content/plugins/syntaxhighlighter/syntaxhighlighter.php 

/**
 * Filter to fix issue with & in SyntaxHighlighter Evolved plugin.
 *
 * @param string $code Code to format.
 * @param array $atts Attributes.
 * @param string $tag Tag.
 *
 * @return string
 */
function kagg_syntaxhighlighter_precode( $code, $atts, $tag ) {
	if ( 'code' === $tag ) {
		$code = wp_specialchars_decode( $code );
	}
	return $code;
}
add_filter( 'syntaxhighlighter_precode', 'kagg_syntaxhighlighter_precode', 10, 3 );

This can be done directly from the webinterface. Just go to Plugins -> Plugin Editor -> select the Plugin SyntaxHighlighter Evolved -> add the snippet to the end

WordPress

[WordPress] Remove Google Fonts in Theme Fluida

 , ,

I usually try to avoid Google products, especially when it comes to web tracking, although I’m a big fan of what they do in other technologies.
Today I was testing another WordPress Theme called Fluida, a free theme from Cryout Creations. It’s clean and simple, the only thing that bothers me, is the usage of the Google Fonts API. Even if you don’t enter a Google Font in the settings, it’s connecting to the API.

Google Fonts has advantages as well as disadvantages. Read more about it here.

There are a few WordPress plugins to remove Google Fonts (e.g. Autoptimize), but I tried to avoid another plugin and wanted to do it manually. After a short search through the theme I found “includes/styles.php”. There you just had to comment out the following lines and it’s done.

	// Google fonts
        $gfonts = array();
	$roots = array();
	foreach ( $cryout_theme_structure['google-font-enabled-fields'] as $item ) {
		$itemg = $item . 'google';
		$itemw = $item . 'weight';
		// custom font names
		if ( ! empty( $options[$itemg] ) && ! preg_match( '/custom\sfont/i', $options[$item] ) ) {
				if ( $item == _CRYOUT_THEME_PREFIX . '_fgeneral' ) { 
					$gfonts[] = cryout_gfontclean( $options[$itemg], ":100,200,300,400,500,600,700,800,900" ); // include all weights for general font 
				} else {
					$gfonts[] = cryout_gfontclean( $options[$itemg], ":".$options[$itemw] );
				};
				$roots[] = cryout_gfontclean( $options[$itemg] );
		}
		// preset google fonts
		if ( preg_match('/^(.*)\/gfont$/i', $options[$item], $bits ) ) {
				if ( $item == _CRYOUT_THEME_PREFIX . '_fgeneral' ) { 
					$gfonts[] = cryout_gfontclean( $bits[1], ":100,200,300,400,500,600,700,800,900" ); // include all weights for general font 
				} else {
					$gfonts[] = cryout_gfontclean( $bits[1], ":".$options[$itemw] );
				};
				$roots[] = cryout_gfontclean( $bits[1] );
		}
	};