Hostsharing Wiki - Letzte Änderungen [de]

ListMonk installieren

Tim00 — Fri, 21 Aug 2026 10:06:48 GMT

Installation mit Ansible Skript

← Nächstältere Version		Version vom 21. August 2026, 10:06 Uhr
Zeile 51:		Zeile 51:

	=== Installation mit Ansible Skript ===		=== Installation mit Ansible Skript ===
	Es gibt ein Ansible Skript für Hostsharing [https://codeberg.org/tpokorra/hs.ansible~~/src/branch/main/playbooks/~~listmonk], das die Installation automatisiert vornimmt, und schon den SMTP und POP Zugang konfiguriert.		Es gibt ein Ansible Skript für Hostsharing [https://codeberg.org/tpokorra/hs.ansible.app.listmonk], das die Installation automatisiert vornimmt, und schon den SMTP und POP Zugang konfiguriert.

	Dort kann man sicherlich auch Feinheiten der Installation abschauen, wenn man ListMonk manuell installieren will.		Dort kann man sicherlich auch Feinheiten der Installation abschauen, wenn man ListMonk manuell installieren will.

Wordpress

Tim00 — Thu, 20 Aug 2026 10:46:09 GMT

Gehackte Dateien identifizieren

← Nächstältere Version		Version vom 20. August 2026, 10:46 Uhr
(3 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 75:		Zeile 75:
	</syntaxhighlight>		</syntaxhighlight>

	== ~~Gehackte Dateien identifizieren~~ ==		== Umgang mit einem gehackten Wordpress ==

	Falls die Wordpress Instanz gehackt wurde, ~~müssen die veränderten Dateien identifiziert und gelöscht werden.~~		Falls die Wordpress Instanz gehackt wurde, gibt es 2 Möglichkeiten:

	Das ~~geht wieder~~ mit ~~wp-cli.~~		* Es kann die Webseite inkl. Dateien und Datenbank auf den Stand aus dem Backup vor dem Angriff zurückgesetzt werden, und muss dann umgehend aktualisiert werden. Bei diesem Vorgehen gehen die seitdem erfassten Beiträge verloren. Leider liegt der Zeitpunkt des Angriffs manchmal schon länger zurück.
			* Ansonsten müssen die veränderten Dateien identifiziert und gelöscht werden.

			Das Identifizieren der veränderten Dateien kann mit folgenden Mitteln geschehen:

	<syntaxhighlight lang=shell>		<syntaxhighlight lang=shell>
Zeile 93:		Zeile 96:
	</syntaxhighlight>		</syntaxhighlight>

			Zuletzt geänderte Dateien finden, im Beispiel der letzten 3 Tage:

			<syntaxhighlight lang=shell>
			find -ctime -3
			</syntaxhighlight>

	Verdächtige Dateien im uploads und cache Verzeichnis finden:		Verdächtige Dateien im uploads und cache Verzeichnis finden:
Zeile 99:		Zeile 107:
	find wp-content/uploads wp-content/cache -type f \		find wp-content/uploads wp-content/cache -type f \
	$ -name '.php' -o -name '.phtml' -o -name '.phar' -o -name '.ico' $ -ls		$ -name '.php' -o -name '.phtml' -o -name '.phar' -o -name '.ico' $ -ls
			</syntaxhighlight>

			Verdächtige Dateien finden, die Schadcode speziell kodiert haben:

			<syntaxhighlight lang=shell>
			grep -rl "eval(base64_decode\\|eval(gzinflate\\|eval(str_rot13\\|eval(htmlspecialchars_decode" . --include="*.php" 2>/dev/null
	</syntaxhighlight>		</syntaxhighlight>

DKIM

Kph00 — Wed, 19 Aug 2026 11:24:21 GMT

Ein Hinweis wurde deutlicher hervorgehoben.

← Nächstältere Version		Version vom 19. August 2026, 11:24 Uhr
Zeile 35:		Zeile 35:
	Die Veröffentlichung des Domainkeys ist dann mit einem einfachen "touch"-Befehl möglich.		Die Veröffentlichung des Domainkeys ist dann mit einem einfachen "touch"-Befehl möglich.

			{{Textkasten\|blau\|Platzhalter "hs-example.de"\|In den folgenden Aufrufen ist der Platzhalter "hs-example.de" durch die eigende Domain zu ersetzen.}}
	<syntaxhighlight lang=shell>		<syntaxhighlight lang=shell>
	touch doms/hs-example.de/etc/pri.hs-example.de		touch doms/hs-example.de/etc/pri.hs-example.de
Zeile 45:		Zeile 46:
	dig -t TXT +short hskey1._domainkey.hs-example.de @dns1.hostsharing.net		dig -t TXT +short hskey1._domainkey.hs-example.de @dns1.hostsharing.net
	</syntaxhighlight>		</syntaxhighlight>

	~~("hs-example.de" durch die eigene Domain ersetzen)~~

	das folgende Alias:		das folgende Alias:

Speicherbelegung

Tim00 — Wed, 19 Aug 2026 07:27:30 GMT

Unvermutete Speicherbelegung

← Nächstältere Version		Version vom 19. August 2026, 07:27 Uhr
Zeile 55:		Zeile 55:
	<syntaxhighlight lang=shell>		<syntaxhighlight lang=shell>
	xyz00-meinbenutzer@hxy:~$ find /tmp/user/$UID		xyz00-meinbenutzer@hxy:~$ find /tmp/user/$UID
	xyz00-meinbenutzer@hxy:~$ ls -la /tmp		xyz00-meinbenutzer@hxy:~$ ls -lat /tmp \| grep xyz00
			</syntaxhighlight>

			Falls eine Datei fntxyzabc heißt, kann so erfahren werden, welcher Prozess die Datei geschrieben hat:

			<syntaxhighlight lang=shell>
			xyz00-meinbenutzer@hxy:~$ lsof /tmp/fntxyzabc
	</syntaxhighlight>		</syntaxhighlight>

Container

Tim00 — Wed, 19 Aug 2026 04:39:42 GMT

Tunnel zur Managed Datenbank einrichten

@@ Zeile 93: / Zeile 93: @@
 Wenn wir eine managed Datenbank aus der Managed Umgebung auf dem Container Server einbinden wollen, sind folgende Schritte notwendig:
-* TODO Es muss ein Tunnel eingerichtet werden, damit die Datenbank vom Container Server aus erreichbar ist.
+* Es muss ein Tunnel eingerichtet werden, damit die Datenbank vom Container Server aus erreichbar ist.
 * TODO: Anpassungen an Docker Compose. Beispiel

Discourse installieren

Tim00 — Thu, 06 Aug 2026 09:21:20 GMT

Erforderliche Anpassungen

← Nächstältere Version		Version vom 6. August 2026, 09:21 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 387:		Zeile 387:
	Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags		Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

	==== Am Beispiel von 2026.1.4 auf 2026.1.5 ====		==== Am Beispiel von 2026.1.5 auf 2026.1.7 ====

	# Im Web-Backend unter Administration->Backups-> Read-Only Mouds setzen (oder Web Server so konfigurieren, dass keine Zugriffe mehr stattfinden können)		# Im Web-Backend unter Administration->Backups-> Read-Only Mouds setzen (oder Web Server so konfigurieren, dass keine Zugriffe mehr stattfinden können)
Zeile 394:		Zeile 394:
	# cd discourse		# cd discourse
	# mv ~/plugins.bak/discourse-ai plugins		# mv ~/plugins.bak/discourse-ai plugins
	# git diff v2026.1.4 > diff-2026.1.4.txt		# git diff v2026.1.5 > diff-2026.1.5.txt
	# git fetch		# git fetch
	# git checkout -b hostsharing-deployment-v2026.1.5 v2026.1.5		# git checkout -b hostsharing-deployment-v2026.1.7 v2026.1.7
	# evtl. Änderungen aus diff-2026.1.4.txt wieder übernehmen und committen		# evtl. Änderungen aus diff-2026.1.5.txt wieder übernehmen und committen
	# patch -p1 < diff-2026.1.4.txt		# patch -p1 < diff-2026.1.5.txt
	# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify		# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
	# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.5/Gemfile)		# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.7/Gemfile)
	# Ist dies der Fall, dann:		# Ist dies der Fall, dann:
	# rbenv install 3.3.8		# rbenv install 3.3.8
Zeile 462:		Zeile 462:
	git commit -a -m "revert imagemagick patch" --no-verify		git commit -a -m "revert imagemagick patch" --no-verify
	</syntaxhighlight>		</syntaxhighlight>

			Update: es hat sich wieder mehr im Code verändert. Bitte den Patch von https://codeberg.org/tpokorra/hs.ansible/src/branch/main/roles/apps/discourse/templates/imagemagick.patch benutzen!

	== ToDos ==		== ToDos ==

Matrix Synapse installieren

Tim00 — Tue, 04 Aug 2026 09:36:19 GMT

Verwalten von Benutzern

@@ Zeile 36: / Zeile 36: @@
 <syntaxhighlight lang="shell">
 source ~/synapse/.venv/bin/activate
 pip install pipenv
 pipenv install matrix-synapse[postgres,oidc] lxml authlib
@@ Zeile 111: / Zeile 101: @@
 systemctl --user start synapse.service
 </syntaxhighlight>
 == Einrichten des Apache VHost ==
@@ Zeile 124: / Zeile 153: @@
 RequestHeader set X-Forwarded-Proto "https"
 </syntaxhighlight>
 == Well-Known unter beispiel.de ==

Prozessmanagement mit systemd im Userspace

Tim00 — Mon, 03 Aug 2026 10:31:07 GMT

RAM- und CPU-Limits

← Nächstältere Version		Version vom 3. August 2026, 10:31 Uhr
Zeile 82:		Zeile 82:
	MemoryHigh=512M		MemoryHigh=512M
	MemoryMax=768M		MemoryMax=768M
			MemorySwapMax=128M
	CPUQuota=50%		CPUQuota=50%
	</syntaxhighlight>		</syntaxhighlight>
Zeile 87:		Zeile 88:
	; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.		; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
	; MemoryMax : Hartes, absolutes RAM-Limit.		; MemoryMax : Hartes, absolutes RAM-Limit.
			; MemorySwapMax: Wenn wir den RAM begrenzen, sollten wir auch den Swap begrenzen, da ansonsten die SSDs langfristig Schaden nehmen bei zu viel Swapping
	; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.		; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

ListMonk installieren

Tim00 — Sat, 01 Aug 2026 21:32:59 GMT

Links

← Nächstältere Version		Version vom 1. August 2026, 21:32 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 70:		Zeile 70:
	* https://listmonk.app/ Projektseite		* https://listmonk.app/ Projektseite
	* https://github.com/knadh/listmonk ListMonk auf Github		* https://github.com/knadh/listmonk ListMonk auf Github
	* https://codeberg.org/tpokorra/hs.ansible~~/src/branch/main/playbooks/~~listmonk Ansible ~~Skript~~ für Hostsharing ~~von Timotheus Pokorra~~		* https://codeberg.org/tpokorra/hs.ansible.app.listmonk Ansible Rolle für Hostsharing

	----		----

Vaultwarden

Jsu00 — Fri, 31 Jul 2026 09:54:51 GMT

← Nächstältere Version		Version vom 31. Juli 2026, 09:54 Uhr
(Eine dazwischenliegende Version desselben Benutzers wird nicht angezeigt)
Zeile 82:		Zeile 82:

	= Update von Vaultwarden =		= Update von Vaultwarden =
			Das Update von Vaultwarden auf einem Hostsharing-Server erfordert ein paar Besonderheiten. Diese Anleitung beschreibt das Update ohne Docker unter Nutzung der vorkompilierten Binärdatei. Wegen abweichender <code>glibc</code>-Versionen wird zwingend die '''Alpine-Version''' verwendet, die per Skript aus dem offiziellen Docker-Image extrahiert wird.
	Das Update von Vaultwarden auf einem Hostsharing-Server erfordert ein paar Besonderheiten. Diese Anleitung beschreibt das Update ohne Docker unter Nutzung der vorkompilierten Binärdatei. Wegen abweichender `glibc`-Versionen wird zwingend die Alpine-Version verwendet, die per Skript aus dem offiziellen Docker-Image extrahiert wird.		Die folgende Anleitung geht davon aus, dass Vaultwarden im Verzeichnis <code>~/vaultwarden</code> installiert ist.
			== Manuell (Schritte einzeln) ==
	Die folgende Anleitung geht davon aus, dass Vaultwarden im Verzeichnis `~/vaultwarden` installiert ist.		=== Dienst stoppen und Backup erstellen ===

	== Dienst stoppen und Backup erstellen ==

	<syntaxhighlight lang=shell>		<syntaxhighlight lang=shell>
	cd ~/vaultwarden		cd ~/vaultwarden
Zeile 96:		Zeile 93:
	mv web-vault web-vault_alt		mv web-vault web-vault_alt
	</syntaxhighlight>		</syntaxhighlight>
			=== Vaultwarden Backend (Alpine) aktualisieren ===
	== Vaultwarden Backend (Alpine) aktualisieren ==

	<syntaxhighlight lang=shell>		<syntaxhighlight lang=shell>
	wget -qO docker-image-extract https://raw.githubusercontent.com/jjlin/docker-image-extract/main/docker-image-extract		wget -qO docker-image-extract https://raw.githubusercontent.com/jjlin/docker-image-extract/main/docker-image-extract
Zeile 106:		Zeile 101:
	chmod +x vaultwarden		chmod +x vaultwarden
	</syntaxhighlight>		</syntaxhighlight>
			=== Web-Vault (Frontend) aktualisieren ===
	== Web-Vault (Frontend) aktualisieren ==		Den direkten Link zur aktuellen <code>.tar.gz</code>-Datei unter https://github.com/dani-garcia/bw_web_builds/releases/latest manuell kopieren.

	Den direkten Link zur aktuellen `.tar.gz`-Datei unter https://github.com/dani-garcia/bw_web_builds/releases/latest manuell kopieren.

	<syntaxhighlight lang=shell>		<syntaxhighlight lang=shell>
	wget -O web-vault.tar.gz "HIER_KOPIERTEN_LINK_EINFÜGEN"		wget -O web-vault.tar.gz "HIER_KOPIERTEN_LINK_EINFÜGEN"
	tar -xzf web-vault.tar.gz		tar -xzf web-vault.tar.gz
	</syntaxhighlight>		</syntaxhighlight>
			=== Aufräumen und Dienst neu starten ===
	== Aufräumen und Dienst neu starten ==

	<syntaxhighlight lang=shell>		<syntaxhighlight lang=shell>
	rm -rf output docker-image-extract web-vault.tar.gz		rm -rf output docker-image-extract web-vault.tar.gz
	systemctl --user start vaultwarden		systemctl --user start vaultwarden
	systemctl --user status vaultwarden		systemctl --user status vaultwarden
			</syntaxhighlight>
			=== Abschluss ===
			Wenn der Server nach dem Update fehlerfrei läuft, können die Backups entfernt werden:
			<syntaxhighlight lang=shell>
			rm -rf vaultwarden_alt web-vault_alt data_backup_*
	</syntaxhighlight>		</syntaxhighlight>

	~~== Abschluss ==~~

	~~Wenn der Server nach dem Update fehlerfrei läuft, können die Backups entfernt werden:~~

			== Empfohlen: Update per Skript (ein Befehl) ==
			Ein öffentliches Hilfsskript erledigt Backup, Backend-Update (Alpine), Web-Vault-Update und Neustart automatisch. Das Skript wird nur nach <code>/tmp</code> geladen und danach wieder gelöscht — es bleibt nichts in der Installation liegen.
			Voraussetzungen: <code>wget</code>, <code>tar</code>, <code>systemctl --user</code>, Layout unter <code>~/vaultwarden</code> mit <code>vaultwarden</code>, <code>web-vault/</code> und <code>data/</code>.
			Update ausführen:
			<syntaxhighlight lang=shell>
			TMP=$(mktemp -d) && wget -qO "$TMP/update-vaultwarden.sh" "https://raw.githubusercontent.com/hiasluz/vaultwarden-update/main/update-vaultwarden.sh" && bash "$TMP/update-vaultwarden.sh"; rm -rf "$TMP"
			</syntaxhighlight>
			Quellen und Details: https://github.com/hiasluz/vaultwarden-update
			Nach erfolgreichem Funktionstest die Backups entfernen:
			<syntaxhighlight lang=shell>
			TMP=$(mktemp -d) && wget -qO "$TMP/update-vaultwarden.sh" "https://raw.githubusercontent.com/hiasluz/vaultwarden-update/main/update-vaultwarden.sh" && bash "$TMP/update-vaultwarden.sh" --cleanup-old; rm -rf "$TMP"
			</syntaxhighlight>
			=== Anderes Installationsverzeichnis ===
			Das Skript fragt '''nicht''' interaktiv nach dem Pfad. Standard ist <code>$HOME/vaultwarden</code>. Liegt die Installation woanders, setzt man den Pfad selbst über die Umgebungsvariable <code>VW_DIR</code> (vor dem Aufruf von <code>bash</code>):
	<syntaxhighlight lang=shell>		<syntaxhighlight lang=shell>
	rm -rf vaultwarden_alt web-vault_alt data_backup_*		TMP=$(mktemp -d) && wget -qO "$TMP/update-vaultwarden.sh" "https://raw.githubusercontent.com/hiasluz/vaultwarden-update/main/update-vaultwarden.sh" && VW_DIR="/pfad/zu/deiner/installation" bash "$TMP/update-vaultwarden.sh"; rm -rf "$TMP"
	</syntaxhighlight>		</syntaxhighlight>
			<code>/pfad/zu/deiner/installation</code> durch das eigene Verzeichnis ersetzen (das Verzeichnis, in dem <code>vaultwarden</code>, <code>web-vault/</code> und <code>data/</code> liegen).