Hostsharing Wiki - Benutzerbeiträge [de]

Spamfilter

2026-02-16T13:04:01Z

Hsh-janulrichhasecke:

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei alternative Möglichkeiten:

1. Die Nutzung der "xmailin"-Server für eine komplette Domain

2. Die Einrichtung von Spamassassin für das persönliche Postfach

3. Nutzung der Spam-Appliance "SecureMX" für eine komplette Domain

= Alternative 1: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einer Domain-Administration oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Ein globaler Sieve-Filter für markiete Spam-Nachrichten ist in der Standard-Konfiguration voreingestellt,
so dass Nachrichten mit Spam-Bewertung in einen vorhandenen Spam-Ordner einsortiert werden.

Seit einigen Jahren betreibt Hostsharing zusätzlich zu den vorkonfigurierte Maileingangsservern einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Anfang 2026 ist eine Gruppe von Eingangsserver mit der Software "rspamd" hinzugekommen. Eingehende Nachrichten mit Malware oder sehr hoher Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem geringeren Spam-Score werden angenommen und zugestellt. Spamassassin fügt die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Status: Yes, score=11.29
</syntaxhighlight>

Der globale Sieve-Filter schiebt Nachrichten mit der Markierung "X-Spam-Status: Yes" in einen Ordner "Junk", wenn der Ordner vorhanden ist. Viele Mailprogramme legen beim ersten Verbinden mit dem IMAP-Server einen solchen Ordner an. Unser "Roundcube"
unter https://webmail.hostsharing.net ist entsprechend eingerichtet, so dass der Ordner nach einer Nutzung von Webmail vorhanden ist.

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 30 xmailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 30 xmailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

Die Änderung des Zonefile kann für eine Domain "hs-example.de" wie folgt überprüft werden:

<syntaxhighlight lang=bash>
dig +short -t MX hs-example.de @dns1.hostsharing.net
</syntaxhighlight>

Die folgende Ausgabe wird erwartet:

<syntaxhighlight lang=bash>
30 xmailin2.hostsharing.net.
30 xmailin3.hostsharing.net.
30 xmailin1.hostsharing.net.
</syntaxhighlight>

Die Reihenfolge der drei Eingangsserver kann variieren.
Die führende Zahl ist die Priorität im MX-Record (hier der Wert "30").

= Alternative 2: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) Kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können. Spamassassin kann für jedes Postfach individuell konfiguriert werden. Für die Einrichtung und Pflege ist Shell-Zugang zur Mailbox erforderlich.

Ein Bayesfilter kann mit den persönlichen Nachrichten angelernt werden. Dazu sind tiefergehende Shell-Kenntnisse erforderlich (Shell-Skript und Einrichtung eines systemd-Timers).

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert. Es muss über das Kommando "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht-oder-verzeichnis>
sa-learn --ham <platzhalter-erwünschte-nachricht-oder-verzeichnis>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
#!/bin/bash

HAM_MIN_AGE_DAYS=5
MAILDIR_HAM=${HOME}/Maildir/cur
TMPDIR=${HOME}/sa-learn-tmp
SPAMFOLDER=Junk
SPAMFOLDER_LEARNED=${SPAMFOLDER}.sa-learned
MAILDIR_SPAM=${HOME}/Maildir/.${SPAMFOLDER}

# Learn spam from MAILDIR_SPAM
mkdir -p ${TMPDIR}/spam
rm -f ${TMPDIR}/spam/*
SPAM_COUNT=0
for DIR in "cur" "new"; do
DIR="${MAILDIR_SPAM}/${DIR}"
cd ${DIR}
# echo "---" DIR ${DIR}
for SPAMFILE in $( ls ); do
# echo " " ${SPAMFILE}
TMPFILE="${TMPDIR}/spam/${SPAMFILE}"
if ! zcat "${SPAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${SPAMFILE}" "${TMPFILE}"
fi
SPAM_COUNT=$((SPAM_COUNT + 1))
done
done
sa-learn --spam ${TMPDIR}/spam/*

# Move processed spam to keep it in another folder
doveadm move -u $(whoami) INBOX.${SPAMFOLDER_LEARNED} mailbox INBOX.${SPAMFOLDER} all 2>/dev/null

# Learn ham from MAILDIR_HAM (> HAM_MIN_AGE_DAYS days; max. 2x spam count)
mkdir -p ${TMPDIR}/ham
rm -f ${TMPDIR}/ham/*
cd ${MAILDIR_HAM}
MAX_HAM=$((SPAM_COUNT * 2))
HAM_COUNT=0
for HAMFILE in $( find . -type f -mtime +${HAM_MIN_AGE_DAYS} -printf '%T@ %p\n' | sort -rn | cut -d' ' -f2- | head -n ${MAX_HAM} ); do
TMPFILE="${TMPDIR}/ham/${HAMFILE}"
if ! zcat "${HAMFILE}" > "${TMPFILE}" 2>/dev/null; then
cp "${HAMFILE}" "${TMPFILE}"
fi
HAM_COUNT=$((HAM_COUNT + 1))
done
sa-learn --ham ${TMPDIR}/ham/*

echo "Training erfolgte mit ${SPAM_COUNT} Spam, ${HAM_COUNT} (max ${MAX_HAM}) Ham Mails."
</syntaxhighlight>

Dabei werden Mails verarbeitet, unabhängig davon, ob sie durch Procmail (unkomprimiert) oder über den Mailclient (komprimiert) verschoben vorliegen.
Für Ham wird ein Teil des Inhalts der Inbox verwendet, wobei die empfohlene Maximalanzahl von zweimal der Spammailanzahl und ein minimales Alter in Tagen gilt. Das Mindestalter garantiert ein inzwischen erfolgtes manuelles Aussortieren des Spams. Der verarbeitete Spam wird anschließend in ein separates Verzeichnis verschoben um den späteren Zugriff auf False Positives zu ermöglichen.

Das Skript wird über einen systemd-Timer täglich ausgeführt, der pro Mailbox eingerichtet werden muss.

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch vom Hostsharing-Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

Gitea

2025-03-12T08:11:32Z

Hsh-janulrichhasecke: /* Gitea installieren */

== Gitea installieren ==

[https://gitea.io/en-us/ Gitea] ist ein einfacher, selbst gehosteter Git-Service wie GitHub oder GitLab. Die Software ist ein Fork von Gogs und ebenfalls in der Programmiersprache Go geschrieben. Gitea benötigt wenig Ressourcen.

Die hier beschriebene Installation benötigt im [https://www.hostsharing.net/paas/managed-webspace/ Hostsharing Managed Webspace] die Paket-Option "Arbeitsspeicher für eigene Serverdienste". Benötigt werden min. 128 MB.

Gitea unterstützt verschiedene Datenbanken. Wir gehen in dieser Anleitung davon aus, dass PostgreSQL benutzt wird.

=== Vorbereitung der Installation ===

Um Gitea auf der Managed Operation Platform von Hostsharing zu installieren, ist folgende Vorbereitung erforderlich.

# Anlegen eines Domain-Benutzers. In unserem Beispiel <code>xyz00-gitea</code>.
# Anlegen einer Domain. In unserem Beispiel <code>gitea.hs-example.de</code>.
# Anlegen eines Datenbank-Benutzers. Hier <code>xyz00_giteadbuser</code>.
# Anlegen einer Datenbank. Hier <code>xyz00_giteadb</code>.

Auf der Kommandozeile kann man dies folgendermaßen erledigen.

Man loggt sich als Paketbenutzer ein und startet die Kommandozeilenversion von HSAdmin mit dem Befehl <code>hsscript</code>:

<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>

Anschließend kann man die Vorbereitungsschritte 1 bis 4 erledigen:

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-gitea',password:'geheim',shell:'/bin/bash'}})
xyz00@hsadmin> domain.add({set:{name:'gitea.hs-example.de',user:'xyz00-gitea'}})
xyz00@hsadmin> postgresqluser.add({set:{name:'xyz00_giteadbuser',password:'geheim'}})
xyz00@hsadmin> postgresqldb.add({set:{name:'xyz00_giteadb',owner:'xyz00_giteadbuser'}})
</syntaxhighlight>

=== Installation von Gitea ===

Gitea wird als Binary zur Verfügung gestellt.
Wir installieren das Binary im Verzeichnis des Domain-Benutzers.
Wenn wir als Paketbenutzer eingeloggt sind, können wir den Benutzer folgendermaßen wechseln:

<syntaxhighlight lang=shell>
sudo -u xyz00-gitea -i
</syntaxhighlight>

Nun laden wir das passende Binary herunter.
Auf der Website https://dl.gitea.io/gitea/ finden Sie das jeweils aktuelle Binary (hier die 64-Bit-Version,
für die shared Server h01 bis h08 bitte die 32-Bit-Version gitea-1.7.0-linux-i386 herunterladen).

<syntaxhighlight lang=shell>
wget -O gitea https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64
chmod +x gitea
</syntaxhighlight>

Wir laden die GPG-Signatur herunter und überprüfen sie:

<syntaxhighlight lang=shell>
wget https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64.asc
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
gpg --verify gitea-1.7.0-linux-amd64.asc gitea
</syntaxhighlight>

Nun können wir Gitea testweise starten:

<syntaxhighlight lang=shell>
./gitea web
</syntaxhighlight>

Der Webserver von Gitea startet auf dem Port 3000. Das werden wir später ändern.

Der Server kann mit Ctrl-C beendet werden.

=== Konfiguration der Domain ===

Zunächst wechseln wir in das Verzeichnis <code>doms/gitea.hs-example.de</code> und löschen den Ordner für die Subdomain 'www':

<syntaxhighlight lang=shell>
rm -rf subs/www
rm -rf subs-ssl/www
</syntaxhighlight>

Anschließend tragen wir die Umleitung auf HTTPS ein, falls dies nicht schon geschehen ist.

<syntaxhighlight lang=shell>
vi htdocs/.htaccess
</syntaxhighlight>

Der Eintrag muss lauten:

<syntaxhighlight lang=apache>
Redirect permanent / https://gitea.hs-example.com/
</syntaxhighlight>

Dann legen wir die Datei <code>htdocs-ssl/.htaccess</code> mit folgendem Inhalt an:

<syntaxhighlight lang=apache>
DirectoryIndex disabled
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) http://localhost:31580/$1 [proxy,last]
</syntaxhighlight>

Merken Sie sich die Portnummer 31580.
Sie wird später bei der Konfiguration von Gitea gebraucht.
Die Portnummer bekommen Sie vom Hostmaster, wenn Sie für Ihren Webspace RAM buchen.
Wenn Sie einen Managed Server haben, können Sie selbst die Portnummer auswählen.

Damit ist die Konfiguration von Apache abgeschlossen.

=== Konfiguration von Gitea ===

Wir editieren nun die Konfigurationsdatei von Gitea <code>app.ini</code>.
Sie befindet sich in dem Verzeichnis <code>~/custom/conf</code>.

'''ACHTUNG''': Sie können die Konfiguration teilweise auch über das Webinterface durchführen. Starten Sie dazu Gitea, wie oben beschrieben, und versuchen Sie einen Benutzer zu registrieren. Daraufhin öffnet sich der Konfigurationsdialog. Sie müssen den Gitea-Benutzer, den Namen der Datenbank, den Datenbank-Benutzer und sein Passwort parat haben.

Die Konfigurationsdatei beginnt mit allgemeinen Einträgen:

<syntaxhighlight lang=shell>
APP_NAME = Gitea: Git with a cup of tea
RUN_USER = xyz00-gitea
RUN_MODE = prod
</syntaxhighlight>

Im Abschnitt [database] folgen die Angaben zur Datenbank:

<syntaxhighlight lang=ini>
[database]
DB_TYPE = postgres
HOST = 127.0.0.1:5432
NAME = xyz00_giteadb
USER = xyz00_giteadbuser
PASSWD = geheim
SSL_MODE = disable
PATH = data/gitea.db
</syntaxhighlight>

Es folgt der Pfad zu den Git-Repositorys und die Server-Konfiguration:

<syntaxhighlight lang=ini>
[repository]
ROOT = /home/pacs/xyz00/users/gitea/gitea-repositories

[server]
PROTOCOL = http
SSH_DOMAIN = gitea.hs-example.de
DOMAIN = gitea.hs-example.de
HTTP_ADDR = localhost
HTTP_PORT = 31580
ROOT_URL = https://gitea.hs-example.de/
DISABLE_SSH = false
SSH_PORT = 22
LFS_START_SERVER = true
</syntaxhighlight>

Für das Schreiben der Log Datei können Sie folgendes konfigurieren:

<syntaxhighlight lang=ini>
[log]
MODE = file
LEVEL = info
ROOT_PATH = /home/pacs/xyz00/users/gitea/custom/logs/
ROUTER = file
LOG_ROTATE = false
</syntaxhighlight>

'''ACHTUNG''': Bitte prüfen Sie, ob der Ordner zum Speichern der Log-Dateien von Gitea vorhanden ist. Bei Bedarf erstellen Sie die Ordnerstruktur entsprechend.

<syntaxhighlight lang=shell>
mkdir -p /home/pacs/xyz00/users/gitea/custom/logs
</syntaxhighlight>

Sie können nun Gitea starten:

<syntaxhighlight lang=shell>
./gitea web
</syntaxhighlight>

Der Git-Service ist dann im Browser unter der Adresse gitea.hs-example.de erreichbar.

=== Service einrichten ===

Zum Schluss müssen Sie noch den Service zum Starten von Gitea einrichten.

Das Service Skript speichern Sie unter dem Pfad <code>~/.config/systemd/user/gitea.service</code> ab.
Es hat folgenden Inhalt:

<syntaxhighlight lang=ini>
Description=Gitea

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=%h
ExecStart=%h/gitea web

[Install]
WantedBy=default.target
</syntaxhighlight>

Nun können Sie noch die Rotation der Logfiles konfigurieren.
Dies geschieht in der Datei <code>~/.logrotate</code>:

<syntaxhighlight lang=ini>
/home/pacs/xyz00/users/gitea/custom/logs/gitea.log {
copytruncate
daily
rotate 7
compress
missingok
}
</syntaxhighlight>

Damit logrotate regelmäßig ausgeführt wird, müssen Sie folgenden systemd Timer für denv Domain-Benutzers einrichten:

<code>~/.config/systemd/user/gitea_logrotate.service</code>
<syntaxhighlight lang=ini>
[Unit]
Description=rotate gittea logs

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate -s /home/pacs/xyz00/users/gitea/.logrotate.state /home/pacs/xyz00/users/gitea/.logrotate
</syntaxhighlight>

<code>~/.config/systemd/user/gitea_logrotate.timer</code>
<syntaxhighlight lang=ini>
[Unit]
Description=rotate gittea logs

[Timer]
OnCalendar=1:51
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Timer aktivieren und starten:
<syntaxhighlight lang=bash>
$ systemctl --user enable gitea_logrotate.timer
$ systemctl --user start gitea_logrotate.timer
</syntaxhighlight>

Die Uhrzeit für die Logrotation können Sie beliebig einstellen.

Abschließend können Sie Ihre Gitea-Instanz starten:

<syntaxhighlight lang=bash>
export XDG_RUNTIME_DIR=/run/user/$UID
systemctl --user start gitea
</syntaxhighlight>

'''ACHTUNG''': Bitte beachten Sie, dass für die Ausführung von Benutzerskripten mit systemctl für den aktuellen Benutzer im hsadmin die Shell "/bin/bash" konfiguriert sein muss.

=== Anmeldung über LDAP einrichten ===

Ohne weitere Konfiguration, können nun lokale Benutzer angelegt werden.

Falls Sie die Benutzerverwaltung noch an ein LDAP Verzeichnis anschließen wollen, können Sie diese Schritte ausführen:

Sie finden hier die Informationen zum Einrichten eines OpenLDAP Dienstes: [[OpenLDAP]]

Gehen Sie in der Weboberfläche von Git in die Administration, und dort in den Reiter "Authentifizierungsquellen", oder direkt auf dem Link https://git.hs-example.de/-/admin/auths

Dort sollten dann folgende Werte eingetragen werden:
* Authentifizierungstyp: LDAP (via BindDN)
* Host: <code>localhost</code> (bzw. der Name des Servers, auf dem OpenLDAP erreichbar ist)
* Port: <code>30389</code> (bzw. der Port auf dem OpenLDAP erreichbar ist)
* DN binden: <code>cn=admin,dc=hs-example,dc=de</code> (Der Benutzer der Zugriff auf alle Benutzer hat)
* Passwort binden: Das Passwort von dem DN Benutzer
* Basis für Benutzersuche: <code>ou=users,dc=hs-example,dc=de</code>
* Benutzerfilter: <code>(&(objectClass=inetOrgPerson)(uid=%s))</code>
* Admin-Filter: <code>(memberof=cn=admins,ou=groups,dc=hs-example,dc=de)</code> (diese Benutzer haben Admin Rechte in Gitea)
* Benutzernamens-Attribute: <code>DN</code>
* Vornamensattribut: <code>givenName</code>
* Nachnamensattribut: <code>sn</code>
* E-Mail-Attribut: <code>mail</code>

Hier noch ein Screenshot:

[[Datei:Gitea_LDAP_Einrichtung.png|500px]]

=== Default Branches ohne Force Push ===

In den Einstellungen von jedem Repository kann unter "Branches" eine Regel z.B. für den Hauptbranch erstellt werden, damit entweder nur Pull Requests und kein direkter Push erlaubt ist, oder dass Push erlaubt ist, aber kein Verändern der Historie mit force push.

Über diese SQL Befehl können die Einstellungen überprüft werden:

Zeige alle Repositories, die noch keine Regel für den Hauptbranch haben:

<syntaxhighlight lang=sql>
SELECT r.id, owner_name, lower_name, r.default_branch
FROM repository r
WHERE NOT EXISTS (
SELECT 1
FROM protected_branch pb
WHERE pb.repo_id = r.id AND pb.branch_name = r.default_branch
);
</syntaxhighlight>

Zeige die Regeln für die Hauptbranches:

<syntaxhighlight lang=sql>
SELECT r.id, owner_name, lower_name, r.default_branch, pb.can_push, pb.required_approvals
FROM repository r JOIN protected_branch pb ON pb.repo_id = r.id AND pb.branch_name = r.default_branch;
</syntaxhighlight>

== weiterführende Links ==

* [https://gitea.io/ Gitea Webseite]
* [https://docs.gitea.io/ Dokumentation von Gitea]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/gitea Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Projektmanagement]]
[[Kategorie:Projektverwaltung]]

Nextcloud

2025-03-12T07:08:43Z

Hsh-janulrichhasecke: /* Redis Cache */ Formulierung für Arbeitsspeicher optimiert

= Nextcloud =

[https://nextcloud.com/ Nextcloud] ist eine PHP-basierte Open Source Lösung für gängige Cloud-Anwendungen, u.a.:

* Filesharing unter Nutzern derselben Nextcloud, und mit der Öffentlichkeit
* Single-Sign-On Authentifizierung (SSO)
* Videokonferenzen (WebRTC)
* Online-Office Anwendung [https://www.collaboraoffice.com/ Collabora Online]

Beispiel-Funktionalität, die über Plugins, sogenannte [https://apps.nextcloud.com/ "Apps"], bereit gestellt werden kann:

* Kalender, Aufgabenverwaltung, Adressbuch
* Datei-Kollaboration (Kommentare zu Dateien, Verschlagwortung)
* Feedreader
* E-Mail-Programm
* Fotogalerie
* Musik- und Videowiedergabe

= Nextcloud installieren =

== Vorbereitungen ==

In ''hsadmin'', zum Beispiel mit ''hsscript'':

''hsadmin''-Shell starten mit:

<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>

Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''cloud.example.org''
* PostgreSQL-User
* PostgreSQL Datenbank

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-cloud',password:'geheim',shell:'/bin/bash',comment:'Nextcloud'}})
xyz00@hsadmin> domain.add({set:{name:'cloud.example.org',user:'xyz00-cloud'}})
xyz00@hsadmin> postgresqluser.add({set:{name:'xyz00_nextclusr',password:'geheim'}})
xyz00@hsadmin> postgresqldb.add({set:{name:'xyz00_nextcloud',owner:'xyz00_nextclusr'}})
</syntaxhighlight>

== Nextcloud installieren ==

Anmelden als Linux-User ''xyz00-cloud'':

<syntaxhighlight lang=shell>
ssh -l xyz00-cloud xyz00.hostsharing.net
</syntaxhighlight>

''htdocs'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd
mkdir nextcloud
cd doms/cloud.example.org
rm -rf subs/www subs-ssl/www htdocs-ssl
ln -s $HOME/nextcloud htdocs-ssl
</syntaxhighlight>

Falls der ''Redirect'' auf die Domain ''example.org'' umleitet statt auf die Subdomain ''cloud.example.org'', kann diese Aktion helfen:

<syntaxhighlight lang=shell>
cd doms/cloud.example.org
mkdir -p subs-ssl/www
cp htdocs/.htaccess subs-ssl/www/.htaccess
</syntaxhighlight>

Nextcloud herunterladen und entpacken.

<syntaxhighlight lang=shell>
cd
wget https://download.nextcloud.com/server/releases/nextcloud-30.0.6.zip
unzip nextcloud-30.0.6.zip
rm nextcloud-30.0.6.zip
mkdir data tmp
chmod 700 data tmp
</syntaxhighlight>

Um Probleme mit der Anmeldung der Nextcloud App am Mobilgerät zu vermeiden, müssen folgende Zeilen in der Datei <code>doms/cloud.example.org/.htaccess</code> eingefügt werden:

<syntaxhighlight lang=htaccess>
RewriteEngine On
RewriteCond %{HTTP:Authorization} ^(.*)
RewriteRule .* - [e=HTTP_AUTHORIZATION:%1]
</syntaxhighlight>

== Nextcloud konfigurieren ==

Im Verzeichnis "$HOME/doms/cloud.example.org/fastcgi-ssl/" eine Datei "php.ini" anlegen mit folgendem Inhalt:

<syntaxhighlight lang=ini>
memory_limit=512M
session.save_path=/home/pacs/xyz00/users/cloud/tmp
</syntaxhighlight>

Dann mit einem Editor diese Datei bearbeiten: In der zweiten Zeile den korrekten Pfad des vorher angelegten tmp-Verzeichnisses eintragen.

Im Browser auf die Seite
http://cloud.example.org gehen und den Anweisungen folgen.

Auf der ersten Seite sind anzugeben:

* Login und Passwort für den Administrator definieren
* PostgreSQL als Datenbanksystem
* PostgreSQL-User und Passwort aus dem ersten Schritt oben
* Name der PostgreSQL-Datenbank aus dem ersten Schritt
* "localhost" als Datenbankserver (Nextcloud 23.0.2 empfiehlt hier die Angabe des Ports, diesen also lt. [[PostgreSQL]] angeben)
* Das Verzeichnis "/home/pacs/xyz00/users/cloud/data/" als Daten-Verzeichnis (bitte beachten: das im Eingabefeld voreingestellte verweist auf das Verzeichnis "/home/pacs/xyz00/users/cloud/'''nextcloud'''/data/")

'''Achtung!''' Die Felder für die Datenbank sind auf dem Startscreen hinter einem unscheinbaren Link versteckt. Um man das Formular für die Datenbank-Daten zu gelangen, muss man auf den Link klicken. Anschließend kann man die gewünschte Datenbank auswählen und die entsprechenden Daten eintragen. '''Das sollte geschehen, bevor man die Installation abschließt!''' Tut man dies nicht, wird Nextcloud mit SQLite installiert. Eine Änderung der Datenbank soll zwar laut Dokumentation auch später noch möglich sein, ging aber bei einem Test schief.

In der Konfigurationsdatei der Nextcloud (in ''~/nextcloud/config/config.php'') lassen sich weitere Voreinstellungen treffen:

<syntaxhighlight lang=php line>
'maintenance_window_start' => 1, // Wartungsfenster ab 1:00 Uhr
'defaultapp' => 'calendar,files', // bei Start wird der Kalender gezeigt
'default_phone_region' => 'DE', // Format Telefonnummern
'default_language' => 'de', // Sprache deutsch
'force_language' => 'de',
'default_locale' => 'de_DE', // Locale (Formatierung Zeitangaben etc.)
'force_locale' => 'de_DE',
</syntaxhighlight>

== Nextcloud beschleunigen ==

Dieser Teil ist optional.

Wenn regelmäßig '''im Browser''' mit Nextcloud gearbeitet werden soll, ist Nextcloud im Browser oft sehr langsam. Um dies zu verbessern, unterstützt Nextcloud die Anwendung von unterschiedlichen Cache-Verfahren (zum Beispiel Memcache, Redis).

=== Redis Cache ===

Redis ist auf den Hostsharing-Servern vorinstalliert und wird von den Nextcloud-Entwicklern empfohlen. Redis wird als eigener Serverdienst gestartet. '''In Verbindung mit Hostsharing Managed Webspace muss für Redis [https://www.hostsharing.net/paas/managed-webspace/ Arbeitsspeicher für eigene Serverdienste] gebucht werden'''.

Die Konfiguration des Redis-Dientes ist auf der Seite [[Redis]] beschrieben. Hier wird für Nextcloud die Variante mit einem Unixsocket benutzt.

In der Konfiguration der Nextcloud (in ''~/nextcloud/config/config.php'') wird der Redis-Cache wie folgt konfiguriert:

<syntaxhighlight lang=php line>
'memcache.local' => '\\OC\\Memcache\\Redis',
'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => '/home/pacs/xyz00/users/cloud/redis/var/redis-server.sock',
'port' => 0,
'password' => 'mein-redis-passwort',
'timeout' => 1.5,
),
</syntaxhighlight>

Um es perfekt zu machen, nutze ich ''logrotate'' um die Logdateien zu organisieren. Dazu die Konfiguration in ''~/.logrotate''

<syntaxhighlight lang=shell line>
compress
/home/pacs/xyz00/users/cloud/redis/var/redis.log {
rotate 5
daily
missingok
}
</syntaxhighlight>
Mit systemd-Timern werden die Logdateien täglich rotiert:

''~/.config/systemd/user/logrotate.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=rotate log files

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate -s %h/.logrotate.state %h/.logrotate
</syntaxhighlight>

''~/.config/systemd/user/logrotate.timer''
<syntaxhighlight lang=ini line>
[Unit]
Description=timer for nextcloud cleanup job

[Timer]
OnCalendar=1:1
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Den Timer aktivieren und starten:
<syntaxhighlight lang=shell line>
$ systemctl --user enable logrotate.timer
$ systemctl --user start logrotate.timer
</syntaxhighlight>

Mit einem weiteren Timer für die regelmäßigen Hintergrundaufgaben von Nextcloud lässt sie sich noch etwas beschleunigen:

''~/.config/systemd/user/nextcloud_background.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=nextcloud cleanup job

[Service]
Type=oneshot
ExecStart=php8.2 /home/pacs/xyz00/users/cloud/nextcloud/cron.php
</syntaxhighlight>

''~/.config/systemd/user/nextcloud_background.timer''
<syntaxhighlight lang=ini line>
[Unit]
Description=timer for nextcloud cleanup job

[Timer]
OnCalendar=*:0/5
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Den Timer aktivieren und starten:
<syntaxhighlight lang=shell line>
$ systemctl --user enable nextcloud_background.timer
$ systemctl --user start nextcloud_background.timer
</syntaxhighlight>

=== Nextcloud Push ===

Um Vorgänge wie Sync und Benachrichtigungen bei sehr großen Nextcloud Installationen zu beschleunigen, kann der <code>notify_push</code> Dienst hinzuinstalliert werden.

==== Abhängigkeiten und Einschränkungen ====
* <code>notify_push</code> muss Zugriff auf den gleichen Redis-Cache wie die Nextcloud haben
** aufgrund von eingeschränktem Passwort Support sollte ein Redis Socket mit sicheren Berechtigungseinstellungen als Alternative zum Redis Port mit Passwort konfiguriert werden.
* optimaler Weise holt sich <code>notify_push</code> benötigte informationen aus der <code>config.php</code> der bestehenden Nextcloud-Installation
* eine zusätzliche (Sub)domain im gleichen User ist nötig. Andernfalls muss die bestehende <code>.htaccess</code> muss aus o.g. Gründen modifiziert werden, dies könnte bei Nextcloud-Updates verloren gehen(!)
* Bestimmte Portbereiche sind bei Hostsharing eingeschränkt, es empfiehlt sich, direkt beispielsweise Port <code>37867</code> zu nehmen. aus diesem Grund ist das automatische Setup durch das Plugin bei Hostsharing nicht möglich!

==== Installation ====
Siehe auch: https://github.com/nextcloud/notify_push#manual-setup

1. Installieren der Nextcloud-App <code>notify_push</code> – (nach Push suchen, "Client Push" wählen) 
2. falls noch nicht erstellt: <code>mkdir -p ~/.config/systemd/user</code> 
3. mit Lieblingseditor die Datei <code>~/.config/systemd/user/notify_push.service</code> anlegen: 
<syntaxhighlight lang="ini" line>
[Unit]
Description = Push daemon for Nextcloud clients
Documentation = https://github.com/nextcloud/notify_push

[Service]
# Change if you already have something running on this port
Environment = PORT=37867
# We don't want to bind to 0.0.0.0, hence the --bind
ExecStart = /home/pacs/xyz00/users/cloud/bin/notify_push --bind 127.0.0.1 /home/pacs/xyz00/users/cloud/nextcloud/config/config.php
Type=notify

[Install]
WantedBy = default.target
</syntaxhighlight>
4. das Verzeichnis <code>~/bin</code> anlegen und die aktuellste binary herunterladen und ausführbar machen:
<syntaxhighlight lang="shell" line>release=`curl -L https://api.github.com/repos/nextcloud/notify_push/releases/latest -s | jq -r '.tag_name'` && wget --show-progress -qO ~/bin/notify_push https://github.com/nextcloud/notify_push/releases/download/$release/notify_push-x86_64-unknown-linux-musl && chmod +x ~/bin/notify_push</syntaxhighlight>
5. es könnte die folgende Umgebungsvariable zum Bedienen von systemd notwendig werden: <code>export XDG_RUNTIME_DIR=/run/user/$UID</code> 
6. den neuen systemd-Dienst automatisch bei Systemstart, sowie jetzt sofort starten: <code>systemctl enable --now --user notify_push</code> 
7. nun gehen wir in <code>doms/push.cloud.example.com/htdocs-ssl/.htaccess</code> und ersetzen den Inhalt (bevorzugt), oder wir ergänzen die .htaccess der Nextcloud im unteren Teil um die folgenden Zeilen (letzteres kann bei Updates überschrieben werden!):
<syntaxhighlight lang="apache" line>
# bei eigener (sub)domain ist /push/ nicht erforderlich, aber wer weiß, eventuell ist das mit robuster
RewriteCond %{REQUEST_URI} ^/push/ws [NC,OR]
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:37867/ws [proxy]

RewriteCond %{REQUEST_URI} ^/push [NC]
RewriteRule .* http://127.0.0.1:37867%{REQUEST_URI} [proxy]
</syntaxhighlight>
8. abschließend im Nextcloud Ordner die Konfiguration des Plugins anstoßen: <code>php occ notify_push:setup https://cloud.example.com/push</code> bzw. <code>php occ notify_push:setup https://push.cloud.example.com/push</code> 
9. es ist möglich, das die erkannte IP-Adresse des Hives noch nicht vertraut ist. In diesem Fall wird der obige Befehl scheitern und es muss jene aus der Fehlermeldung des Setups unter <code>trusted_proxies</code> in der <code>config.php</code> ergänzt werden. 

Es wird im Repo außerdem ein Testclient bereitgestellt, der sich testweise mit dem Push-Dienst verbindet

== Nextcloud mit Online Office ==

In Nextcloud können Office-Dokumente (Textverarbeitung, Tabellen und Präsentationen) im Browser bearbeitet werden. Dazu steht bei Hostsharing die Collabora Developer Version zur Verfügung. Bestellung und Konfiguration sind hier im Wiki auf der Seite [[Collabora_Online]] beschrieben.

== Nextcloud mit Nextcloud Talk ==

Über die Nextcloud-App "Talk" können Videokonfererenzen mit Screensharing durchgeführt werden. Für die regelmäßige Nutzung kann es sinnvoll sein, einen eigenen TURN Server zu betreiben. Siehe dazu [[Coturn_Installieren]]

== Virenscanner ==

Einige Nutzer wollen die Dateien in Ihrer Nextcloud regelmäßig auf Viren überprüfen. Auf unseren Servern steht dafür der OpenSource-Virenscanner "ClamAV" zur Verfügung. Wenn dieser Scanner benutzt wird, dann sollten die Einstellungen so gewählt sein, dass der ClamAV-Daemon über eine Socket Verbindung angesprochen wird. Die Einstellungen sind im Screenshot dokumentiert.

* Es wird die App [https://apps.nextcloud.com/apps/files_antivirus Antivirus für Dateien] installiert.
* Bei Modus wird gewählt: <code>ClamAV-Daemon (Socket)</code>
* Bei Socket wird gewählt: <code>/var/run/clamav/clamd.ctl</code>

[[Datei:Nextcloud-ClamAV-Einstellungen.png||nextcloud einstellungen für die virenscanner-app]]

== Volltextsuche ==

Über die Dokumente einer Nextcloud kann ein Volltextindex erstellt werden. Die Volltextsuche ermöglicht über den Index eine Suche über beliebige Begriffe, die in Dokumenten vorkommen.

Voraussetzung ist der Betrieb eines Elasticsearch Servers. Der Betrieb im Managed Webspace erfodert die Buchung von zwei "Serverdiensten". Nutzer eines Managed Server müssen mit einem spürbaren Mehrbedarf an Hauptspeicher rechnen.

Zur Installation von Elasticsearch existiert eine eigene Wikiseite: [[Elasticsearch]].

In der Nextcloud sind folgende ''Apps'' zu installieren:
* Full Text Search
* Full Text Search - Elasticsearch Platform
* Full Text Search - Files

nach der Installation der drei Apps steht in den Einstellungen ein neuer Menüpunkt "Volltextsuche" zur Verfügung.

Hier ist einzustellen:
* Suchplattform: Elasticsearch
* Adresse des Servlets: http://elastic:das-erzeugt-passwort@127.0.0.1:39200
* Index: frei-gewaehlter-name-idx
* Analyzer tokenizer: standard

Die anderen Einstellung nach den eigenen Vorstellungen vornehmen.

Der initiale Aufbau des Suchindex erfolgt über ein "occ"-Kommando auf der Shell:

<syntaxhighlight lang=shell line>
cd nextcloud/
php occ fulltextsearch:index --output
</syntaxhighlight>

Wenn dieser Fehler kommt:
<syntaxhighlight lang=text>
TypeError: Return value of OCA\Files_FullTextSearch\Model\MountPoint::isGlobal()
must be of the type bool, null returned in [...]/apps/files_fulltextsearch/lib/Model/MountPoint.php:103
</syntaxhighlight>
sollte dieser Patch angewendet werden: https://github.com/nextcloud/files_fulltextsearch/issues/125#issuecomment-877789742

Zur Pflege des Indexes wird ein weiterer Hintergrundprozess gestartet:

<syntaxhighlight lang=shell line>
cd nextcloud/
php occ fulltextsearch:live -q
</syntaxhighlight>

Die Monit Konfiguration dafür sieht so aus:

<syntaxhighlight lang=shell line>
#~/bin/start-fulltextsearchlive
#
#!/bin/bash
export HOME=/home/pacs/xyz00/users/cloud
cd $HOME
mkdir -p $HOME/var
cd $HOME/nextcloud
exec php occ fulltextsearch:live -q &
echo $! >$HOME/var/fulltextsearchlive.pid
</syntaxhighlight>

<syntaxhighlight lang=shell line>
#~/bin/stop-fulltextsearchlive
#
#!/bin/bash
export HOME=/home/pacs/xyz00/users/cloud
kill $( cat $HOME/var/fulltextsearchlive.pid )
</syntaxhighlight>

~/.monitrc (siehe oben von der Redis Installation) entsprechend ergänzen:
<syntaxhighlight lang=shell line>
check process fulltextsearchlive with pidfile /home/pacs/xyz00/users/cloud/var/fulltextsearchlive.pid
start program "/home/pacs/xyz00/users/cloud/bin/start-fulltextsearchlive"
stop program "/home/pacs/xyz00/users/cloud/bin/stop-fulltextsearchlive"
</syntaxhighlight>

== Integration mit LDAP ==

Um einheitliche Benutzerzugänge für verschiedene Anwendungen zu ermöglichen, wird oft auf ein zentrales LDAP Verzeichnis gesetzt.

Dieses kann für Nextcloud eingesetzt werden, damit Benutzer nicht lokal in Nextcloud, sondern in LDAP verwaltet werden können.

Siehe auch https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/user_auth_ldap.html

Dazu muss die App "LDAP user and group backend" in den Nextcloud Apps aktiviert werden.

Dann muss die LDAP Anbindung in den Administrationseinstellungen unter "LDAP/AD-Integration" eingerichtet werden.

Der Server mit Port, die BenutzerDN mit Passwort und die BaseDN müssen eingetragen werden.

Es muss auch bestimmt werden, welche Klasse (z.B. inetOrgPerson) die Benutzer brauchen, um Zugriff auf die Nextcloud zu erhalten.

Falls schon Benutzer in der Nextcloud existieren, und diese zu LDAP mitgenommen werden sollen, kann der Anleitung aus diesem Forum Eintrag gefolgt werden: https://help.nextcloud.com/t/migration-to-ldap-keeping-users-and-data/13205

* Voraussetzung ist, dass der Benutzernamen der zu übernehmenden Benutzer in Nextcloud der uid in LDAP entspricht.
* Es wird ein Administrator Benutzer benötigt, der lokal angelegt wurde, und auch lokal bleibt.
* Mit diesem Administrator Benutzer wird die LDAP Anbindung eingerichtet.
* In der Experten Ansicht von LDAP/AD muss bei "Attribut für interne Benutzernamen" eingetragen werden: uid
* Klicke den Schalter "LDAP Benutzernamenzuordnung löschen"
* Klicke den Schalter "LDAP Gruppennamenzuordnung löschen"
* dann in der MySQL Datenbank anmelden, und aus uc_users alle Benutzer bis auf den Administrator Benutzer löschen
* Dann in der Nextcloud Weboberfläche sich alle Benutzer anzeigen lassen
* Nun gelingt die Anmeldung mit den anderen Benutzern mit dem LDAP Passwort, und die Dateien wurden übernommen.

== Optimierung der Geschwindigkeit ==
Manchmal fühlt sich die Nextcloud träge an.

Folgende Änderungen können helfen:

* HTTP/2.0 aktivieren: dem Service von Hostsharing Bescheid geben
* Die App Dashboard deaktivieren, und dafür werden direkt die Dateien angezeigt
* Einblenden der README in den Ordnern abschalten: das kann pro Ordner in der UI geschehen (links unten), oder global: <code>occ config:app:set text workspace_available --value=0</code>. Siehe auch [https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/text_configuration.html#disable-rich-workspaces-globally]

== Default App einstellen ==

In der Datei config.php können wir einstellen, welche App direkt nach der Anmeldung gezeigt wird.

Das ist entweder die Dashboard App, wenn sie aktiviert ist, oder die Dateien App (files).

Falls der Kalender direkt angezeigt werden soll, muss folgende Zeile in der config.php hinzugefügt werden (siehe auch [https://docs.nextcloud.com/server/stable/admin_manual/configuration_server/config_sample_php_parameters.html#defaultapp]):

<syntaxhighlight lang=shell>
'defaultapp' => 'calendar',
</syntaxhighlight>

= Nextcloud Updates =

== Updater über die Shell starten ==

Wenn die NextCloud sich nicht über das Webfrontend updaten lässt, kann der Updater auch per Shell im directory /updater durch ausführen des updater.phar gestartet werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php updater/updater.phar
</syntaxhighlight>

Falls während des Updates kein Backup angelegt werden soll:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php updater/updater.phar --no-backup
</syntaxhighlight>

Es sollten außerdem ein paar Routine-Aufräumarbeiten durchgeführt werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-primary-keys --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-columns --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-indices --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:convert-filecache-bigint --no-interaction
</syntaxhighlight>

So können die Apps noch alle aktualisiert werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ app:update --all -n --no-ansi
</syntaxhighlight>

Für weitere Informationen kann auf die offizielle Doku ab Ziffer 2. zurückgegriffen werden.

* [https://docs.nextcloud.com/server/latest/admin_manual/maintenance/update.html#using-the-command-line-based-updater https://docs.nextcloud.com]

Hier gibt es ein kurzes Video, das die Anmeldung über die Kommandozeile mit Putty erklärt und die Aktualisierung von Nextcloud auf der Kommandozeile:

* [https://tube.solidcharity.net/w/0cf5ee97-ba7c-41df-a56f-8d1fea842ab0 Nextcloud auf der Kommandozeile aktualisieren]

== Wartungsmodus per Shell ein- oder ausschalten ==

So kann der Wartungsmodus angeschaltet werden:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --on
</syntaxhighlight>

So kann der Wartungsmodus wieder ausgeschaltet werden, d.h. die Nextcloud ist dann wieder in Betrieb:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --off
</syntaxhighlight>

== Webfrontend-Updater Probleme / Lösungen ==

=== Datenbank: Indizes | Primärschlüssel | Konvertierungen ===

Aufgetreten nach erfolgtem Versionsupdate Nextcloud 19 auf Nextcloud 20

Nach dem erfolgten Update lädt automatisch die Seite: '''Sicherheits- und Einrichtungswarnungen''' auf dieser wird angemerkt, dass manuelle Schritte für die Datenbank durchzuführen sind. Dies betrifft Indizes, Primärschlüssel und Konvertierungen.

Per Shell in der directory /nextcloud folgende Kommandos ausführen:

<syntaxhighlight lang=shell line>
xyz00-cloud@h00:~$ cd ~/nextcloud
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-primary-keys --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-columns --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:add-missing-indices --no-interaction
xyz00-cloud@h00:~/nextcloud$ php occ db:convert-filecache-bigint --no-interaction
</syntaxhighlight>

Wichtig ist hier dem durch Nextcloud angegebenen Kommando ein '''php''' voranzustellen.

== Update per Skript ==

Es ist möglich die regelmäßigen Updates weitgehend zu automatisieren. Ein Skript wäre etwa:

<syntaxhighlight lang=shell line>
#!/bin/bash
if [ -f $HOME/nextcloud/occ ]; then
echo "Nextcloud Update";
cd $HOME/nextcloud;
php updater/updater.phar -vv --no-backup --no-interaction
php occ maintenance:mode --on
php occ db:add-missing-primary-keys --no-interaction
php occ db:add-missing-columns --no-interaction
php occ db:add-missing-indices --no-interaction
php occ db:convert-filecache-bigint --no-interaction
php occ app:update --all
php occ maintenance:mode --off
else
echo "Keine Nextcloud Installation gefunden";
fi
</syntaxhighlight>

== Update: bei old-stable Version bleiben ==

Normalerweise fragt jede Nextcloud Instanz zentral ab, welches Update zur Verfügung steht, abhängig vom Release Channel. Dabei wird aber relativ schnell auf die nächste Version gewechselt, also z.B. von Nextcloud 28 auf Nextcloud 29, obwohl Nextcloud 28 noch mehrere Monate gepflegt wird, und manche Apps noch nicht bereit sind für Nextcloud 29.

Es kann aber auch eine Alternative eingerichtet werden, in der Datei nextcloud/config/config.php, unter dem Eintrag updater.server.url

Hier wird z.B. auf einen Updater von unserem Mitglied Timotheus Pokorra verwiesen:

<syntaxhighlight lang=php line>
updater_server_url: "https://ncupdater.solidcharity.com"
</syntaxhighlight>

Dahinter läuft ein Skript, mit dem wir noch länger eine bestimmte Version anbieten können: https://codeberg.org/tpokorra/ncupdater

= Daten auf HDD Storage =
== Einrichtung des HDD Storage ==

Um den langsameren aber günstigeren HDD Storage von Hostsharing zu nutzen, kann das data Verzeichnis von SSD auf HDD Storage verschoben werden. Ein symbolischer Link reicht nicht aus, man muss den Pfad in der Nextcloud Konfigurationsdatei anpassen.

<syntaxhighlight lang=shell>
# Nextcloud in Wartungsmodus versetzen
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --on
# Daten auf HDD Storage verschieben
xyz00-cloud@h00:~/nextcloud$ mv data /home/storage/xyz00/users/cloud/
# symbolischen Link anlegen
xyz00-cloud@h00:~/nextcloud$ ln -s /home/storage/xyz00/users/cloud/data data
# Pfad in config.php ändern
nano config/config.php
# Die Zeile mit 'datadirectory' finden und entsprechend ändern:
# 'datadirectory' => '/home/storage/xyz00/users/cloud/data',
# Wartungsmodus beenden
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --off
</syntaxhighlight>

Ein Fallstrick: Im data-Verzeichnis liegt eine versteckte Datei ".ncdata". Beim Move-Befehl "mv" für das komplette Data-Verzeichnis wird diese Datei mit verschoben. Sonst muss die Datei ggf. ins neue data-Verzeichnis kopiert werden!

= Einschränkende Bemerkungen =
== Nextcloud Sync Client ==

Der Nextcloud Sync Client erfüllt eine Funktion ähnlich wie Dropbox, und synchronisiert ganze Ordnerstrukturen.

Gerade wenn man mit mehreren Menschen in einer Nextcloud arbeitet, ist diese Funktion mit Vorsicht zu benutzen.

* Änderungen an der Ordnerstruktur sollten nicht lokal, sondern im Webbrowser vorgenommen werden.
* Wenn die Gefahr besteht, dass mehrere Menschen gleichzeitig eine Datei bearbeiten, sollte die Datei nicht lokal, sondern im Webbrowser bearbeitet werden.
* Aus Sicht des Datenschutzes und der Daten-Minimierung sollte überlegt werden, ob die Daten wirklich auf jeden Laptop und Rechner synchronisiert werden sollen, oder ob es reicht, ausschließlich über den Webbrowser auf die Daten zuzugreifen.

= weiterführende Links =

* [https://docs.nextcloud.com/ Nextcloud Dokumentation]
* [https://apps.nextcloud.com/ Nextcloud Erweiterungen ("Apps")]
* [https://ownyourbits.com/2019/06/29/understanding-and-improving-nextcloud-previews/ Optimierung des Caches für Previews]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/nextcloud Ansible Playbook für Hostsharing]

= Nextcloud Reseller bei HS =

[https://nextcloud.ossaas.de OS SaaS]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:CalDAV]]
[[Kategorie:Nextcloud]]

Gitea

2025-03-12T07:00:34Z

Hsh-janulrichhasecke: /* Gitea installieren */ Kaputten Satz im Einstieg repariert.

== Gitea installieren ==

[https://gitea.io/en-us/ Gitea] ist ein einfacher, selbst gehosteter Git-Service wie GitHub oder GitLab. Die Software ist ein Fork von Gogs und ebenfalls in der Programmiersprache Go geschrieben. Gitea benötigt wenig Ressourcen.

Die hier beschriebene Installation benötigt im [https://www.hostsharing.net/paas/managed-webspace/ Hostsharing Managed Webspace] die Paket-Option "Arbeitsspeicher für eigene Serverdienste". Benötigt werden min. 128 MB. Auch auf einem [https://www.hostsharing.net/paas/managed-server/ Hostsharing Managed-Server] muss genügend RAM verfügbar sein.

Gitea unterstützt verschiedene Datenbanken. Wir gehen in dieser Anleitung davon aus, dass PostgreSQL benutzt wird.

=== Vorbereitung der Installation ===

Um Gitea auf der Managed Operation Platform von Hostsharing zu installieren, ist folgende Vorbereitung erforderlich.

# Anlegen eines Domain-Benutzers. In unserem Beispiel <code>xyz00-gitea</code>.
# Anlegen einer Domain. In unserem Beispiel <code>gitea.hs-example.de</code>.
# Anlegen eines Datenbank-Benutzers. Hier <code>xyz00_giteadbuser</code>.
# Anlegen einer Datenbank. Hier <code>xyz00_giteadb</code>.

Auf der Kommandozeile kann man dies folgendermaßen erledigen.

Man loggt sich als Paketbenutzer ein und startet die Kommandozeilenversion von HSAdmin mit dem Befehl <code>hsscript</code>:

<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>

Anschließend kann man die Vorbereitungsschritte 1 bis 4 erledigen:

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-gitea',password:'geheim',shell:'/bin/bash'}})
xyz00@hsadmin> domain.add({set:{name:'gitea.hs-example.de',user:'xyz00-gitea'}})
xyz00@hsadmin> postgresqluser.add({set:{name:'xyz00_giteadbuser',password:'geheim'}})
xyz00@hsadmin> postgresqldb.add({set:{name:'xyz00_giteadb',owner:'xyz00_giteadbuser'}})
</syntaxhighlight>

=== Installation von Gitea ===

Gitea wird als Binary zur Verfügung gestellt.
Wir installieren das Binary im Verzeichnis des Domain-Benutzers.
Wenn wir als Paketbenutzer eingeloggt sind, können wir den Benutzer folgendermaßen wechseln:

<syntaxhighlight lang=shell>
sudo -u xyz00-gitea -i
</syntaxhighlight>

Nun laden wir das passende Binary herunter.
Auf der Website https://dl.gitea.io/gitea/ finden Sie das jeweils aktuelle Binary (hier die 64-Bit-Version,
für die shared Server h01 bis h08 bitte die 32-Bit-Version gitea-1.7.0-linux-i386 herunterladen).

<syntaxhighlight lang=shell>
wget -O gitea https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64
chmod +x gitea
</syntaxhighlight>

Wir laden die GPG-Signatur herunter und überprüfen sie:

<syntaxhighlight lang=shell>
wget https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64.asc
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
gpg --verify gitea-1.7.0-linux-amd64.asc gitea
</syntaxhighlight>

Nun können wir Gitea testweise starten:

<syntaxhighlight lang=shell>
./gitea web
</syntaxhighlight>

Der Webserver von Gitea startet auf dem Port 3000. Das werden wir später ändern.

Der Server kann mit Ctrl-C beendet werden.

=== Konfiguration der Domain ===

Zunächst wechseln wir in das Verzeichnis <code>doms/gitea.hs-example.de</code> und löschen den Ordner für die Subdomain 'www':

<syntaxhighlight lang=shell>
rm -rf subs/www
rm -rf subs-ssl/www
</syntaxhighlight>

Anschließend tragen wir die Umleitung auf HTTPS ein, falls dies nicht schon geschehen ist.

<syntaxhighlight lang=shell>
vi htdocs/.htaccess
</syntaxhighlight>

Der Eintrag muss lauten:

<syntaxhighlight lang=apache>
Redirect permanent / https://gitea.hs-example.com/
</syntaxhighlight>

Dann legen wir die Datei <code>htdocs-ssl/.htaccess</code> mit folgendem Inhalt an:

<syntaxhighlight lang=apache>
DirectoryIndex disabled
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) http://localhost:31580/$1 [proxy,last]
</syntaxhighlight>

Merken Sie sich die Portnummer 31580.
Sie wird später bei der Konfiguration von Gitea gebraucht.
Die Portnummer bekommen Sie vom Hostmaster, wenn Sie für Ihren Webspace RAM buchen.
Wenn Sie einen Managed Server haben, können Sie selbst die Portnummer auswählen.

Damit ist die Konfiguration von Apache abgeschlossen.

=== Konfiguration von Gitea ===

Wir editieren nun die Konfigurationsdatei von Gitea <code>app.ini</code>.
Sie befindet sich in dem Verzeichnis <code>~/custom/conf</code>.

'''ACHTUNG''': Sie können die Konfiguration teilweise auch über das Webinterface durchführen. Starten Sie dazu Gitea, wie oben beschrieben, und versuchen Sie einen Benutzer zu registrieren. Daraufhin öffnet sich der Konfigurationsdialog. Sie müssen den Gitea-Benutzer, den Namen der Datenbank, den Datenbank-Benutzer und sein Passwort parat haben.

Die Konfigurationsdatei beginnt mit allgemeinen Einträgen:

<syntaxhighlight lang=shell>
APP_NAME = Gitea: Git with a cup of tea
RUN_USER = xyz00-gitea
RUN_MODE = prod
</syntaxhighlight>

Im Abschnitt [database] folgen die Angaben zur Datenbank:

<syntaxhighlight lang=ini>
[database]
DB_TYPE = postgres
HOST = 127.0.0.1:5432
NAME = xyz00_giteadb
USER = xyz00_giteadbuser
PASSWD = geheim
SSL_MODE = disable
PATH = data/gitea.db
</syntaxhighlight>

Es folgt der Pfad zu den Git-Repositorys und die Server-Konfiguration:

<syntaxhighlight lang=ini>
[repository]
ROOT = /home/pacs/xyz00/users/gitea/gitea-repositories

[server]
PROTOCOL = http
SSH_DOMAIN = gitea.hs-example.de
DOMAIN = gitea.hs-example.de
HTTP_ADDR = localhost
HTTP_PORT = 31580
ROOT_URL = https://gitea.hs-example.de/
DISABLE_SSH = false
SSH_PORT = 22
LFS_START_SERVER = true
</syntaxhighlight>

Für das Schreiben der Log Datei können Sie folgendes konfigurieren:

<syntaxhighlight lang=ini>
[log]
MODE = file
LEVEL = info
ROOT_PATH = /home/pacs/xyz00/users/gitea/custom/logs/
ROUTER = file
LOG_ROTATE = false
</syntaxhighlight>

'''ACHTUNG''': Bitte prüfen Sie, ob der Ordner zum Speichern der Log-Dateien von Gitea vorhanden ist. Bei Bedarf erstellen Sie die Ordnerstruktur entsprechend.

<syntaxhighlight lang=shell>
mkdir -p /home/pacs/xyz00/users/gitea/custom/logs
</syntaxhighlight>

Sie können nun Gitea starten:

<syntaxhighlight lang=shell>
./gitea web
</syntaxhighlight>

Der Git-Service ist dann im Browser unter der Adresse gitea.hs-example.de erreichbar.

=== Service einrichten ===

Zum Schluss müssen Sie noch den Service zum Starten von Gitea einrichten.

Das Service Skript speichern Sie unter dem Pfad <code>~/.config/systemd/user/gitea.service</code> ab.
Es hat folgenden Inhalt:

<syntaxhighlight lang=ini>
Description=Gitea

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=%h
ExecStart=%h/gitea web

[Install]
WantedBy=default.target
</syntaxhighlight>

Nun können Sie noch die Rotation der Logfiles konfigurieren.
Dies geschieht in der Datei <code>~/.logrotate</code>:

<syntaxhighlight lang=ini>
/home/pacs/xyz00/users/gitea/custom/logs/gitea.log {
copytruncate
daily
rotate 7
compress
missingok
}
</syntaxhighlight>

Damit logrotate regelmäßig ausgeführt wird, müssen Sie folgenden systemd Timer für denv Domain-Benutzers einrichten:

<code>~/.config/systemd/user/gitea_logrotate.service</code>
<syntaxhighlight lang=ini>
[Unit]
Description=rotate gittea logs

[Service]
Type=oneshot
ExecStart=/usr/sbin/logrotate -s /home/pacs/xyz00/users/gitea/.logrotate.state /home/pacs/xyz00/users/gitea/.logrotate
</syntaxhighlight>

<code>~/.config/systemd/user/gitea_logrotate.timer</code>
<syntaxhighlight lang=ini>
[Unit]
Description=rotate gittea logs

[Timer]
OnCalendar=1:51
Persistent=True

[Install]
WantedBy=timers.target
</syntaxhighlight>

Timer aktivieren und starten:
<syntaxhighlight lang=bash>
$ systemctl --user enable gitea_logrotate.timer
$ systemctl --user start gitea_logrotate.timer
</syntaxhighlight>

Die Uhrzeit für die Logrotation können Sie beliebig einstellen.

Abschließend können Sie Ihre Gitea-Instanz starten:

<syntaxhighlight lang=bash>
export XDG_RUNTIME_DIR=/run/user/$UID
systemctl --user start gitea
</syntaxhighlight>

'''ACHTUNG''': Bitte beachten Sie, dass für die Ausführung von Benutzerskripten mit systemctl für den aktuellen Benutzer im hsadmin die Shell "/bin/bash" konfiguriert sein muss.

=== Anmeldung über LDAP einrichten ===

Ohne weitere Konfiguration, können nun lokale Benutzer angelegt werden.

Falls Sie die Benutzerverwaltung noch an ein LDAP Verzeichnis anschließen wollen, können Sie diese Schritte ausführen:

Sie finden hier die Informationen zum Einrichten eines OpenLDAP Dienstes: [[OpenLDAP]]

Gehen Sie in der Weboberfläche von Git in die Administration, und dort in den Reiter "Authentifizierungsquellen", oder direkt auf dem Link https://git.hs-example.de/-/admin/auths

Dort sollten dann folgende Werte eingetragen werden:
* Authentifizierungstyp: LDAP (via BindDN)
* Host: <code>localhost</code> (bzw. der Name des Servers, auf dem OpenLDAP erreichbar ist)
* Port: <code>30389</code> (bzw. der Port auf dem OpenLDAP erreichbar ist)
* DN binden: <code>cn=admin,dc=hs-example,dc=de</code> (Der Benutzer der Zugriff auf alle Benutzer hat)
* Passwort binden: Das Passwort von dem DN Benutzer
* Basis für Benutzersuche: <code>ou=users,dc=hs-example,dc=de</code>
* Benutzerfilter: <code>(&(objectClass=inetOrgPerson)(uid=%s))</code>
* Admin-Filter: <code>(memberof=cn=admins,ou=groups,dc=hs-example,dc=de)</code> (diese Benutzer haben Admin Rechte in Gitea)
* Benutzernamens-Attribute: <code>DN</code>
* Vornamensattribut: <code>givenName</code>
* Nachnamensattribut: <code>sn</code>
* E-Mail-Attribut: <code>mail</code>

Hier noch ein Screenshot:

[[Datei:Gitea_LDAP_Einrichtung.png|500px]]

=== Default Branches ohne Force Push ===

In den Einstellungen von jedem Repository kann unter "Branches" eine Regel z.B. für den Hauptbranch erstellt werden, damit entweder nur Pull Requests und kein direkter Push erlaubt ist, oder dass Push erlaubt ist, aber kein Verändern der Historie mit force push.

Über diese SQL Befehl können die Einstellungen überprüft werden:

Zeige alle Repositories, die noch keine Regel für den Hauptbranch haben:

<syntaxhighlight lang=sql>
SELECT r.id, owner_name, lower_name, r.default_branch
FROM repository r
WHERE NOT EXISTS (
SELECT 1
FROM protected_branch pb
WHERE pb.repo_id = r.id AND pb.branch_name = r.default_branch
);
</syntaxhighlight>

Zeige die Regeln für die Hauptbranches:

<syntaxhighlight lang=sql>
SELECT r.id, owner_name, lower_name, r.default_branch, pb.can_push, pb.required_approvals
FROM repository r JOIN protected_branch pb ON pb.repo_id = r.id AND pb.branch_name = r.default_branch;
</syntaxhighlight>

== weiterführende Links ==

* [https://gitea.io/ Gitea Webseite]
* [https://docs.gitea.io/ Dokumentation von Gitea]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/gitea Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Projektmanagement]]
[[Kategorie:Projektverwaltung]]

Spamfilter

2025-02-07T14:55:10Z

Hsh-janulrichhasecke: /* Alternative 2: Maileingangsserver mit Spamfilter nutzen */

Einrichtung, Konfiguration und Optimierung eines Spamfilters auf den Hostsharing Servern. Der Artikel beschreibt drei Möglichkeiten:

1. Die Einrichtung von Apamassassin für das persönliche Postfach

2. Die Nutzung der "smailin"-Server für eine komplette Domain

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Persönlichen Spamfilter einrichten =

Hier geht es darum, wie Personen mit (grundlegenden) kenntnissen in der Shell-Bedienung für ihr persönliches Postfach einen Spam-Filter einrichten können.

== Spamassassin Konfigurieren ==

Der Spamfilter "Spamassassin" ist bei HS vorinstalliert und kann wie auf der Seite [[Procmail]] beschrieben für eine Mailbox eingebunden werden.
Alternativ kann "spamc", das Kommando zur Nutzung des Spamassassin-Daemon, auch einfach in der Datei ".forward" eines Mail-Users aufgerufen werden:

<syntaxhighlight lang=bash>
"|/usr/bin/spamc -U /var/run/spamd -e /usr/lib/dovecot/deliver"
</syntaxhighlight>

Der Effekt: Spammassassin schreibt seine Testergebnisse in die Headerzeilen jeder E-Mail und leitet die E-Mails weiter an das Programm "deliver" aus dem Dovecot-Paket. Das Sortieren von Spam-EMail in einen Spam-Ordner lässt sich mit Sieve-Filtern umsetzen.

In dieser Variante kann man Spamassassin individuell konfigurieren. Dazu legt man im $HOME des Mailbox-Account ein Verzeichnis "$HOME/.spamassassin" an. Die Konfiguration erfolgt in der Datei "$HOME/.spamassassin/user_prefs".

Konfigurationsbeispiel:

<syntaxhighlight lang=bash>
required_score 4.0
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0
use_razor2 1
use_pyzor 1
</syntaxhighlight>

== Bayesfilter anlernen ==

Wenn der Bayesfilter eingeschaltet ist, macht es Sinn den Filter mit den Befehlen

<syntaxhighlight lang=bash>
sa-learn --spam <platzhalter-spam-nachricht>
sa-learn --ham <platzhalter-erwünschte-nachricht>
</syntaxhighlight>

anzulernen. Ein Bash-Skript für das Erlernen von Spam/Nonspam kann wie folgt aussehen:

<syntaxhighlight lang=bash>
!/bin/bash
#
# Learn Spam from Maildir folder Junk/LearnSpam
#
mkdir -p ${HOME}/sa-learn-tmp
cd ${HOME}/Maildir/.Junk.LearnSpam/cur/
for JUNK in $( ls ); do zcat ${JUNK} > ${HOME}/sa-learn-tmp/$( echo ${JUNK} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --spam ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnSpam/cur/*
#
# Learn Non-Spam from Maildir folder Junk/LearnHam
#
cd ${HOME}/Maildir/.Junk.LearnHam/cur/
for HAM in $( ls ); do zcat ${HAM} > ${HOME}/sa-learn-tmp/$( echo ${HAM} | cut -d'.' -f2 ).eml ; done
cd ${HOME}/
sa-learn --ham ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/sa-learn-tmp/*.eml
rm -f ${HOME}/Maildir/.Junk.LearnHam/cur/*
</syntaxhighlight>

Die Empfängerin der Nachrichten / der Empfänger füttert den Lernprozess, indem Spam-Nachrichten in den Ordner "Spam/LearnSpam" verschoben werden und indem gute Nachrichten in den Ordner "Spam/LearnHam" kopiert werden.

Das Skript wird über einen systemd-Timer täglich ausgefürt.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Zusätzlich zu den vorkonfigurierte Maileingangsservern betreibt Hostsharing seit einigen Jahren einen zweiten Satz von Maileingangsservern, bei denen Spamassassin bereits beim Annehmen einer E-Mail ausgeführt wird. Eingehende Nachrichten mit eindeutiger Bewertung als Spam werden bereits im SMTP-Dialog abgewiesen. Nachrichten mit einem Spam-Score über 5 Punkten werden angenommen und zugestellt. Spamassassin für die Bewertung für diese Nachrichten in die Header der Nachricht ein, zum Beispiel:

<syntaxhighlight lang=bash>
X-Spam-Flag: YES
X-Spam-Score: 6.263
X-Spam-Level: ******
</syntaxhighlight>

Anhand dieser Zeilen kann man in Roundcube Filter einrichten, die die Nachrichten beim Eintreffen der Nachricht in einen Spam-Ordner mit verdächtigen Nachrichten verschieben (siehe später folgenden Abschnitt).

== Eingangsserver konfigurieren ==

Die Maileingangsserver mit Spamassassin lassen sich pro Domain konfigurieren, indem die MX-Records im DNS-Zonefile gegenüber dem Default-Zonefile angepasst werden.

Im Zonefile entfällt der Platzhalter "{MX_RR}". Stattdessen werden die folgenden MX-Records eingefügt:

<syntaxhighlight lang=bash>
{DOM_HOSTNAME}. IN MX 10 smailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 smailin3.hostsharing.net.
</syntaxhighlight>

Zur Änderung der DNS-Zone siehe: https://www.hostsharing.net/doc/managed-operations-platform/zonefile/
Wer sich die Aktion auf der Shell nicht zutraut, möge bitte den "Webmaster on Demand" beauftragen.

== Spam-Ordner ==

Mit dem folgenden Filter können Nachrichten, die von Spamassassin markiert wurden, automatisch in einen Spam-Ordner verschoben werden.

[[Datei:2025-02-07 Sievefilter-Spam.png|960x480px|gerahmt|links|alternativtext=Screenshot Filterregel zum Spam Aussortieren|Filter in Roundcube einrichten]]

= Alternative 3: SecureMX zubuchen =

Über unseren Domain-Anbieter "Partnergate" bietet Hostsharing als dritte Alternative die kommerzielle Spam-Appliance von Cisco an. Das Produkt heißt bei Partnergate "SecureMX": https://www.hostsharing.net/loesungen/email/spam-abwehr/

Die Nutzung von SecureMX ist kostenpflichtig und wird auf Wunsch von Service eingerichtet.

Es ist zu beachten, dass bei der Nutzung von SecureMX alle eingehenden E-Mail Nachrichten über Server geleitet werden, die nicht unter der Kontrolle von Hostsharing stehen und proprietäre Software einsetzen. Dieser Sachverhalt muss vom Mitglied ggf. datenschutzrechtlich bewertet werden.

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Glossar]]

Diskussion:Mailman 3 installieren

2025-01-09T11:10:34Z

Hsh-janulrichhasecke: Feature-Wunsch

Die Einrichtung mit systemd fehlt auf der Seite.

Prozessmanagement mit systemd im Userspace

2024-12-05T07:53:52Z

Hsh-janulrichhasecke: /* Fehler: Failed to connect to bus: No such file or directory */

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Die systemd-Konfiguration wird in dem Verzeichnis des Benutzers eingerichtet, unter dem die Anwendung laufen soll.
In diesem Beispiel soll die Anwendung GotoSocial unter der Benutzerkennung von ''xyz00-service'' laufen.
Nachdem die Anwendung im Benutzer ''xyz00-service'' installiert wurde, erfolgt nun die Konfiguration von systemd in demselben Benutzer.

Benutzer, die systemd steuern sollen, müssen über eine gültige Shell verfügen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.
Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Der Pfad muss bei einem neuen Benutzer angelegt werden.

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Mit Hilfe von systemd können auch wiederkehrende Aufgaben zeitgesteuert automatisiert werden.
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also durch systemd Units ersetzen.
Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600
Persistent=true

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay bewirkt, dass der Prozess zufällig im Zeitraum einer Stunde gestartet wird.
Wenn mehrere Timer-Aufgaben täglich (daily) auf einem System gestartet werden, verhindert diese Einstellung, dass alle Prozesse exakt zur gleichen Zeit starten und das System eventuell überlasten.

Die zufällige Verzögerung sollte in einem sinnvollen Verhältnis zur Frequenz der Zeitsteuerung erfolgen.
Bei täglich ausgeführten Aufgaben mag eine Stunde (3600 Sekunden) sinnvoll sein.
Bei Aufgaben, die stündlich ausgeführt werden, wählt man eine kürzere Verzögerung, zum Beispiel fünf Minuten.

Die Syntax der Datei lässt sich mit diesem Befehl prüfen:

<syntaxhighlight lang=bash>
systemd-analyze verify $HOME/.config/systemd/user/my-cleanup.timer
</syntaxhighlight>

Einzelne Kalendereinträge lassen sich mit Erklärung ausgeben:

<syntaxhighlight lang=bash>
systemd-analyze calendar '*:0/2'
</syntaxhighlight>

Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

Der Timer muss noch aktiviert und gestartet werden:

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer --now
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

== Beliebte Fehler ==
=== Fehler: Failed to connect to bus: No such file or directory ===

Wenn ich einen systemctl Befehl ausführe, kommt:

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
Failed to connect to bus: No such file or directory
</syntaxhighlight>

Bitte prüfen, ob Lingering für den Benutzer aktiviert ist. Dazu muss im Hsadmin beim Benutzer die Login Shell <code>/bin/bash</code> eingetragen sein. Falls das bereits der Fall ist, ist es vielleicht ein sehr alter Benutzer. Dann bitte kurz auf <code>/usr/bin/passwd</code> stellen, und dann wieder auf <code>/bin/bash</code> zurückstellen.

Evtl. hilft es auch, die Umgebungsvariable XDG_RUNTIME_DIR zu setzen:

<syntaxhighlight lang="bash">
export XDG_RUNTIME_DIR=/run/user/$UID
</syntaxhighlight>

Das kann auch in die Datei <code>$HOME/.profile</code> eingefügt werden.

=== Fehler: Beim Starten passiert nichts ===

Ich hatte das Problem bei einem Redis Dienst. Er stoppte innerhalb von Millisekunden. In der Log Datei stand nichts.

Ursache: in der Service Datei war bei <code>WorkingDirectory</code> ein nicht existierendes Verzeichnis eingetragen.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html
* https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html#systemd-timer-catchup
* https://wiki.archlinux.org/title/Systemd/Timers#As_a_cron_replacement

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Umstellung von Daemon-Diensten auf systemd

2024-11-25T14:51:11Z

Hsh-janulrichhasecke: /* Praktische Umstellung */

== Anlass dieser Anleitung ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontingent in Schritten von jeweils 128 Megabyte. Das unterstützt uns besser bei der verursachergerechten Verteilung der Hardwarekosten, als es vorher mit einer Pauschale pro Serverdienst der Fall war. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

Damit die RAM Kontingente funktionieren, müssen im Managed Webspace alle Anwendungen, die im Userspace laufen, auf systemd umgestellt werden. Das betrifft Anwendungen, die bisher über z.B. cronjob, supervisor oder monit gestartet wurden.

Siehe auch unsere [[Systemd im Userspace]] Dokumentation.

== Praktische Umstellung ==

Für eine Übergangsphase steht jedem Managed Webspace genügend RAM zur Verfügung, um eigene Serverdienste zu starten.
Nach der Umstellung aller Dienste auf systemd wird dann das tatsächlich benötigte RAM-Kontingent ermittelt und gebucht.

=== cronjob ===

TODO: auf Timer

=== monit ===

TODO: Beispiel

=== supervisor ===

TODO: Beispiel

== Ermittlung und Buchung des benötigten RAM Kontingent ==

TODO: siehe [[Systemd_im_Userspace#RAM_Kontingent_eines_Webspace]]

----
[[Kategorie:Systemd]]

Prozessmanagement mit systemd im Userspace

2024-11-25T13:59:37Z

Hsh-janulrichhasecke: /* Zeitgesteuerte Ausführung mit systemd */

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Die systemd-Konfiguration wird in dem Verzeichnis des Benutzers eingerichtet, unter dem die Anwendung laufen soll.
In diesen Beispiel soll die Anwendung GotoSocial unter der Benutzerkennung von ''xyz00-service'' laufen.
Nachdem die Anwendung im Benutzer ''xyz00-service'' installiert wurde, erfolgt nun die Konfiguration von systemd in demselben Benutzer.

Benutzer, die systemd steuern sollen, müssen über eine gültige Shell verfügen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.
Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Der Pfad muss bei einem neuen Benutzer angelegt werden.

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Mit Hilfe von systemd können auch wiederkehrende Aufgaben zeitgesteuert automatisiert werden.
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also durch systemd Units ersetzen.
Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay bewirkt, dass der Prozess zufällig im Zeitraum einer Stunde gestartet wird.
Wenn mehrere Timer-Aufgaben täglich (daily) auf einem System gestartet werden, verhindert diese Einstellung, dass alle Prozesse exakt zur gleichen Zeit starten und das System eventuell überlasten.

Die zufällige Verzögerung sollte in einem sinnvollen Verhältnis zur Frequenz der Zeitsteuerung erfolgen.
Bei täglich ausgeführten Aufgaben mag eine Stunde (3600 Sekunden) sinnvoll sein.
Bei Aufgaben, die stündlich ausgeführt werden, wählt man eine kürzere Verzögerung, zum Beispiel fünf Minuten.

Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Prozessmanagement mit systemd im Userspace

2024-11-25T13:58:39Z

Hsh-janulrichhasecke: /* Eigene Serverdienste mit systemd */

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Die systemd-Konfiguration wird in dem Verzeichnis des Benutzers eingerichtet, unter dem die Anwendung laufen soll.
In diesen Beispiel soll die Anwendung GotoSocial unter der Benutzerkennung von ''xyz00-service'' laufen.
Nachdem die Anwendung im Benutzer ''xyz00-service'' installiert wurde, erfolgt nun die Konfiguration von systemd in demselben Benutzer.

Benutzer, die systemd steuern sollen, müssen über eine gültige Shell verfügen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.
Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Der Pfad muss bei einem neuen Benutzer angelegt werden.

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Mit Hilfe von systemd können wiederkehrende Aufgaben zeitgesteuert automatisiert werden.
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also mit systemd Units ersetzen.
Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay bewirkt, dass der Prozess zufällig im Zeitraum einer Stunde gestartet wird.
Wenn mehrere Timer-Aufgaben täglich (daily) auf einem System gestartet werden, verhindert diese Einstellung, dass alle Prozesse exakt zur gleichen Zeit starten und das System eventuell überlasten.

Die zufällige Verzögerung sollte in einem sinnvollen Verhältnis zur Frequenz der Zeitsteuerung erfolgen.
Bei täglich ausgeführten Aufgaben mag eine Stunde (3600 Sekunden) sinnvoll sein.
Bei Aufgaben, die stündlich ausgeführt werden, wählt man eine kürzere Verzögerung, zum Beispiel fünf Minuten.

Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Prozessmanagement mit systemd im Userspace

2024-11-25T13:53:09Z

Hsh-janulrichhasecke: /* Eigene Serverdienste mit systemd */

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Die systemd-Konfiguration wird in dem Verzeichnis des Benutzers eingerichtet, unter dem die Anwendung laufen soll.

In diesen Beispiel ist dies der Benutzer ''xyz00-service''.
Der Benutzer verfügt über eine gültige Shell, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.

Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Für einen neuen User legt man also zuerst dieses Verzeichnis an:

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Mit Hilfe von systemd können wiederkehrende Aufgaben zeitgesteuert automatisiert werden.
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also mit systemd Units ersetzen.
Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay bewirkt, dass der Prozess zufällig im Zeitraum einer Stunde gestartet wird.
Wenn mehrere Timer-Aufgaben täglich (daily) auf einem System gestartet werden, verhindert diese Einstellung, dass alle Prozesse exakt zur gleichen Zeit starten und das System eventuell überlasten.

Die zufällige Verzögerung sollte in einem sinnvollen Verhältnis zur Frequenz der Zeitsteuerung erfolgen.
Bei täglich ausgeführten Aufgaben mag eine Stunde (3600 Sekunden) sinnvoll sein.
Bei Aufgaben, die stündlich ausgeführt werden, wählt man eine kürzere Verzögerung, zum Beispiel fünf Minuten.

Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Prozessmanagement mit systemd im Userspace

2024-11-25T13:09:01Z

Hsh-janulrichhasecke: /* Einrichten des »timer-files« */ Verzögerungsbeispiele

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Um Serverdienste mit systemd zu verwalten, müssen folgende Voraussetzungen erfüllt werden:

In ''HSAdmin'' wird ein Service-User zur Rechtetrennung dieses Dienstes von anderen Anwendungen angelegt. In diesem Artikel soll der Beispiel-User ''xyz00-service'' im Webspace ''xyz00'' sein.

Dieser User bekommt bei der Einrichtung eine gültige Shell zugewiesen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.

Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Für einen neuen User legt man also zuerst dieses Verzeichnis an:

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Mit Hilfe von systemd können wiederkehrende Aufgaben zeitgesteuert automatisiert werden.
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also mit systemd Units ersetzen.
Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay bewirkt, dass der Prozess zufällig im Zeitraum einer Stunde gestartet wird.
Wenn mehrere Timer-Aufgaben täglich (daily) auf einem System gestartet werden, verhindert diese Einstellung, dass alle Prozesse exakt zur gleichen Zeit starten und das System eventuell überlasten.

Die zufällige Verzögerung sollte in einem sinnvollen Verhältnis zur Frequenz der Zeitsteuerung erfolgen.
Bei täglich ausgeführten Aufgaben mag eine Stunde (3600 Sekunden) sinnvoll sein.
Bei Aufgaben, die stündlich ausgeführt werden, wählt man eine kürzere Verzögerung, zum Beispiel fünf Minuten.

Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Prozessmanagement mit systemd im Userspace

2024-11-25T13:06:13Z

Hsh-janulrichhasecke: /* Einrichten des »timer-files« */ Formulierung

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Um Serverdienste mit systemd zu verwalten, müssen folgende Voraussetzungen erfüllt werden:

In ''HSAdmin'' wird ein Service-User zur Rechtetrennung dieses Dienstes von anderen Anwendungen angelegt. In diesem Artikel soll der Beispiel-User ''xyz00-service'' im Webspace ''xyz00'' sein.

Dieser User bekommt bei der Einrichtung eine gültige Shell zugewiesen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.

Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Für einen neuen User legt man also zuerst dieses Verzeichnis an:

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Mit Hilfe von systemd können wiederkehrende Aufgaben zeitgesteuert automatisiert werden.
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also mit systemd Units ersetzen.
Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay bewirkt, dass der Prozess zufällig im Zeitraum einer Stunde gestartet wird.
Wenn mehrere Timer-Aufgaben täglich (daily) auf einem System gestartet werden, verhindert diese Einstellung, dass alle Prozesse exakt zur gleichen Zeit starten und das System eventuell überlasten.

Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Prozessmanagement mit systemd im Userspace

2024-11-25T13:03:15Z

Hsh-janulrichhasecke: /* Zeitgesteuerte Ausführung mit systemd */ Stil

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Um Serverdienste mit systemd zu verwalten, müssen folgende Voraussetzungen erfüllt werden:

In ''HSAdmin'' wird ein Service-User zur Rechtetrennung dieses Dienstes von anderen Anwendungen angelegt. In diesem Artikel soll der Beispiel-User ''xyz00-service'' im Webspace ''xyz00'' sein.

Dieser User bekommt bei der Einrichtung eine gültige Shell zugewiesen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.

Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Für einen neuen User legt man also zuerst dieses Verzeichnis an:

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Mit Hilfe von systemd können wiederkehrende Aufgaben zeitgesteuert automatisiert werden.
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also mit systemd Units ersetzen.
Neben dem »service-file« wird dazu eine weitere Unit, nämlich ein »timer-file«, mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay stellt sich, dass nicht alle Prozesse auf dem System zur gleichen Zeit gestartet werden.
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Prozessmanagement mit systemd im Userspace

2024-11-25T12:37:34Z

Hsh-janulrichhasecke: /* Zeitgesteuerte Ausführung mit systemd */ Stil

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Um Serverdienste mit systemd zu verwalten, müssen folgende Voraussetzungen erfüllt werden:

In ''HSAdmin'' wird ein Service-User zur Rechtetrennung dieses Dienstes von anderen Anwendungen angelegt. In diesem Artikel soll der Beispiel-User ''xyz00-service'' im Webspace ''xyz00'' sein.

Dieser User bekommt bei der Einrichtung eine gültige Shell zugewiesen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.

Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Für einen neuen User legt man also zuerst dieses Verzeichnis an:

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Mit Hilfe von systemd können wiederkehrende Aufgaben zeitgesteuert automatisiert werden.
Cronjobs, die früher für solche Zwecke benutzt wurden, lassen sich also mit systemd Units ersetzen.
Ergänzend zu einem »service-file« wird eine weitere Unit, nämlich ein »timer-file« mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay stellt sich, dass nicht alle Prozesse auf dem System zur gleichen Zeit gestartet werden.
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Prozessmanagement mit systemd im Userspace

2024-11-25T12:26:30Z

Hsh-janulrichhasecke: /* Eigene Serverdienste mit systemd */ Stil

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

Um Serverdienste mit systemd zu verwalten, müssen folgende Voraussetzungen erfüllt werden:

In ''HSAdmin'' wird ein Service-User zur Rechtetrennung dieses Dienstes von anderen Anwendungen angelegt. In diesem Artikel soll der Beispiel-User ''xyz00-service'' im Webspace ''xyz00'' sein.

Dieser User bekommt bei der Einrichtung eine gültige Shell zugewiesen, so dass man sich per ''ssh'' oder vom Paketadmin mit dem Befehl ''sudo -i -u xyz00-service'' anmelden kann.

Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Units ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Für einen neuen User legt man also zuerst dieses Verzeichnis an:

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. In diesem Beispiel ist dies eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst bereits laufen muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis-Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei, in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

Wenn ein Dienst nach einem Reboot des Servers automatisch gestartet werden soll, muss er aktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

Wenn er nicht automatisch nach einem Reboot starten soll, muss der Dienst entsprechend deaktiviert werden:

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Bisher wurden meistens cronjobs eingesetzt, um wiederkehrende Aufgaben zu erledigen.

Auch Cronjobs können durch systemd ersetzt werden. Ergänzend zu einem »service-file« wird eine weitere Unit, nämlich ein »timer-file« mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay stellt sich, dass nicht alle Prozesse auf dem System zur gleichen Zeit gestartet werden.
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Prozessmanagement mit systemd im Userspace

2024-11-25T12:13:36Z

Hsh-janulrichhasecke: /* Über systemd */ Stil

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess hat im laufenden System die Prozessnummer "1". Er verwaltet alle anderen Prozesse als Kind-Prozesse.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Operations Platform kann jeder Account mit einer gültigen Login-Shell Dienste unter der Kontrolle von systemd starten.

Im Hostsharing Managed Webspace ist es zwingend, systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Hostsharing Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

In diesem Wiki finden sich viele Beispiele für systemd-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen für die wichtigsten Einstellungen.

Voraussetzung: In ''HSAdmin'' wird ein Service-User zur Rechtetrennung dieses Dienstes von anderen Anwendungen angelegt. In diesem Artikel soll der Beispiel-User ''xyz00-service'' im Webspace ''xyz00'' sein. Dieser User bekommt bei der Einrichtung eine gültige Shell zugewiesen, so dass man sich per ''ssh'' oder vom Paketadmin mit einem Befehl ''sudo -i -u xyz00-service'' anmelden kann. Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Unit ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Für einen neuen User legt man also zuerst dieses Verzeichnis an:

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. Ich verwende hier eine Beispielkonfiguration für eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Die meisten Eigenschaften sind selbsterklärend. Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst vorher starten muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird der die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Bisher wurden meistens cronjobs eingesetzt, um wiederkehrende Aufgaben zu erledigen.

Auch Cronjobs können durch systemd ersetzt werden. Ergänzend zu einem »service-file« wird eine weitere Unit, nämlich ein »timer-file« mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay stellt sich, dass nicht alle Prozesse auf dem System zur gleichen Zeit gestartet werden.
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

Umstellung von Daemon-Diensten auf systemd

2024-11-25T11:56:43Z

Hsh-janulrichhasecke:

== Anlass dieser Anleitung ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontingent in Schritten von jeweils 128 Megabyte. Das unterstützt uns besser bei der verursachergerechten Verteilung der Hardwarekosten, als es vorher mit einer Pauschale pro Serverdienst der Fall war. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

Damit die RAM Kontingente funktionieren, müssen im Managed Webspace alle Anwendungen, die im Userspace laufen, auf systemd umgestellt werden. Das betrifft Anwendungen, die bisher über z.B. cronjob, supervisor oder monit gestartet wurden.

Siehe auch unsere [[Systemd im Userspace]] Dokumentation.

== Praktische Umstellung ==

[Hier erklären, dass gerade viel RAM zur Verfügung.]

=== cronjob ===

TODO: auf Timer

=== monit ===

TODO: Beispiel

=== supervisor ===

TODO: Beispiel

== Ermittlung und Buchung des benötigten RAM Kontingent ==

TODO: siehe [[Systemd_im_Userspace#RAM_Kontingent_eines_Webspace]]

----
[[Kategorie:Systemd]]

Prozessmanagement mit systemd im Userspace

2024-11-25T11:51:25Z

Hsh-janulrichhasecke: /* Einrichten des »timer-files« */ Randomized Delay

== Über systemd ==
''systemd'' ist seit einigen Jahren das Init-System aller gängigen Linux-Distributionen. Der ''init''-Prozess ist im laufenden System der Prozess mit der Nummer "1", der alle anderen Prozesse als Kind-Prozesse verwaltet.

Auch ein normaler Account ohne besondere Privilegien kann systemd nutzen, um Prozesse im Userspace zu starten und zu kontrollieren. Auf der Hostsharing Managed Plattform hat jeder Account mit einer gültigen Login-Shell die Möglichkeit Dienste unter Kontrolle von systemd zu starten. In einem Webspace im Shared Hosting ist es zwingend systemd als Prozessmonitor für eigene Serverdienste zu nutzen; auf einem Managed Server ist es die empfohlene Vorgehensweise ("Best practice").

== Eigene Serverdienste mit systemd ==

In diesem Wiki finden sich viele Beispiele für systemd-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen für die wichtigsten Einstellungen.

Voraussetzung: In ''HSAdmin'' wird ein Service-User zur Rechtetrennung dieses Dienstes von anderen Anwendungen angelegt. In diesem Artikel soll der Beispiel-User ''xyz00-service'' im Webspace ''xyz00'' sein. Dieser User bekommt bei der Einrichtung eine gültige Shell zugewiesen, so dass man sich per ''ssh'' oder vom Paketadmin mit einem Befehl ''sudo -i -u xyz00-service'' anmelden kann. Die Umgebungsvariable ''XDG_RUNTIME_DIR'' sollte im Environment des Users gesetzt sein, wenn man erfolgreich angemeldet ist. Das testet man mit

<syntaxhighlight lang="bash">
echo $XDG_RUNTIME_DIR
</syntaxhighlight>

Die Ausgabe sollte sein:

<syntaxhighlight lang="bash">
xyz00-service@h01:~$ echo $XDG_RUNTIME_DIR
/run/user/112345
xyz00-service@h01:~$
</syntaxhighlight>

Dabei wird statt ''112345'' eine andere Zahl erscheinen. Diese Zahl ist die numerische User-Id des Users ''xyz00-service'' im System.

=== systemd Unit ===

Die systemd-Units für einen User werden im Verzeichnis ''$HOME/.config/systemd/user/'' verwaltet. Dieser Pfad ist fest vorgegeben. Für einen neuen User legt man also zuerst dieses Verzeichnis an:

<syntaxhighlight lang="bash">
mkdir -p $HOME/.config/systemd/user
</syntaxhighlight>

In diesem Verzeichnis wird für jeden Service eine Datei mit der Endung ''.service'' angelegt. Ich verwende hier eine Beispielkonfiguration für eine GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmiersprache ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial Service
#After=my-redis.service

[Service]
Type=simple
WorkingDirectory=%h/gotosocial
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/gotosocial/gotosocial --config-path %h/gotosocial/config.yaml server start
StandardOutput=append:%h/var/gotosocial.log
StandardError=inherit
Restart=always
PrivateTmp=true

[Install]
WantedBy=default.target
</syntaxhighlight>

Die meisten Eigenschaften sind selbsterklärend. Folgende Eigenschaften sind einstellbar:

; After: Hier kann eingestellt werden, welcher Dienst vorher starten muss, bevor dieser Dienst gestartet wird. Wenn GotoSocial eine Redis Instanz benötigt, könnte das entsprechend eingestellt werden.
; Type=simple : ''simple'' ist die Voreinstellung und kann weggelassen werden. Evtl. braucht man auch ''forking'', wenn ein Dienst als Daemon im Hintergrund startet. Wenn man die Wahl hat, sollte man den Dienst immer im Vordergrund starten und nicht forken.
; WorkingDirectory : ist das Verzeichnis, in dem der Dienst gestartet wird. %h ist in dieser Datei eine Abkürzung für das Home-Verzeichnis des Users.
; Environment : Hier wird die Variable ''PATH'' definiert. Man kann mehrere Einträge des Namens ''Environment'' eintragen und bei Bedarf eine beliebige Anzahl von Environment-Variablen definieren.
; ExecStart : Das Programm, das als Dienst ausgeführt wird. Man kann eine komplette Kommandozeile angeben.
; StandardOutput : Eine Log-Datei in die die Standardausgabe des laufenden Dienstes geschrieben wird.
; StandardError : Entsprechend zu ''StandardOutput''. Mit ''inherit'' wird der die Datei von ''StandardOutput'' geerbt.
; Restart=always : Der Dienst soll grundsätzlich neu gestartet werden, wenn der Prozess unerwartet beendet wird.
; PrivateTmp=true : ''/tmp'' und ''/var/tmp'' werden temporär im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : sollte im Usermodus von systemd meistens ''default.target'' sein. Andere Targets sind z.B. ''base.target'' oder ''timers.target''. Für eine komplette Liste: <code>systemctl list-units --user --type=target</code>

==== RAM- und CPU-Limits ====

Auf Wunsch kann man die RAM- und CPU-Ressourcen für den Dienst begrenzen. Dazu trägt man weitere Eigenschaften im Abschnitt ''Service'' ein:

<syntaxhighlight lang="ini" line>
[Service]
...
MemoryAccounting=true
CPUAccounting=true
MemoryHigh=512M
MemoryMax=768M
CPUQuota=50%
</syntaxhighlight>

; MemoryHigh : Weiches RAM-Limit, das ggf. überschritten werden kann, wenn es unvermeidlich ist.
; MemoryMax : Hartes, absolutes RAM-Limit.
; CPUQuota : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

==== Ausführliche Dokumentation der Direktiven ====
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html

=== systemd Unit starten und stoppen ===

Nachdem die systemd-Unit definiert ist, soll der Dienst gestartet werden.
Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

==== Reload ====

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
</syntaxhighlight>

Die Konfigurationsdateien im Verzeichnis ''$HOME/.config/systemd/user/'' werden neu eingelesen. Dieses Kommando ist nach jeder Änderung einer ''.service''-Datei nötig.

==== Start und Stopp ====

<syntaxhighlight lang="bash">
systemctl --user start gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user stop gotosocial.service
</syntaxhighlight>

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

<syntaxhighlight lang="bash">
systemctl --user enable gotosocial.service
</syntaxhighlight>

bzw.

<syntaxhighlight lang="bash">
systemctl --user disable gotosocial.service
</syntaxhighlight>

sind die Kommandos, die den Dienst für einen Reboot des Servers aktivieren bzw. deaktivieren.

==== Status ====

<syntaxhighlight lang="bash">
systemctl --user status
</syntaxhighlight>

oder

<syntaxhighlight lang="bash">
systemctl --user status gotosocial.service
</syntaxhighlight>

zeigen den Status aller Dienste des Users bzw. eines bestimmten Dienstes an.

== Zeitgesteuerte Ausführung mit systemd ==

Bisher wurden meistens cronjobs eingesetzt, um wiederkehrende Aufgaben zu erledigen.

Auch Cronjobs können durch systemd ersetzt werden. Ergänzend zu einem »service-file« wird eine weitere Unit, nämlich ein »timer-file« mit der Endung ».timer« angelegt und aktiviert.

=== Einrichten des »service-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.service

[Unit]
Description=My Cleanup Service

[Service]
Type=oneshot
ExecStart=%h/bin/cleanup-script
</syntaxhighlight>

=== Testen ===

<syntaxhighlight lang=bash>
$ systemctl --user start my-cleanup.service
</syntaxhighlight>

=== Einrichten des »timer-files« ===

<syntaxhighlight lang=bash>
$ cat $HOME/.config/systemd/user/my-cleanup.timer

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

[Install]
WantedBy=timers.target
</syntaxhighlight>

Der RandomizedDelay stellt sich, dass nicht alle Prozesse auf dem System zur gleichen Zeit gestartet werden.
Eine ausführliche Dokumentation der Direktiven findet sich hier:

https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

=== Aktivieren der zeitgesteuerten Ausführung ===

<syntaxhighlight lang=bash>
$ systemctl --user enable my-cleanup.timer
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

Den aktuell belegten RAM eines Webspace ''xyz00'' kann man sich mit dem Befehl

<syntaxhighlight lang="bash">
systemctl status pacs-xyz00.slice
</syntaxhighlight>

ansehen.

Etwa in der fünften Zeile der Ausgabe findet man eine Angabe der Form:

<syntaxhighlight lang="bash">
Memory: 58.4M (max: 14.8G available: 14.8G)
</syntaxhighlight>

Hier sind aktuell 58,4 Megabyte RAM genutzt, es sind 14,8 Gigabyte RAM für den Webspace verfügbar. Der verfügbare RAM ist das gebuchte Kontingent. Das gebuchte Kontigent wird im Shared Hosting deutlich kleiner sein.

Das RAM Kontingent wird in Schritten von jeweils 128 Ḿegabyte gebucht. Änderungen des RAM Kontingents für einen Webspace nimmt der Service unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

= weiterführende Links =

* https://www.freedesktop.org/software/systemd/man/latest/systemd.directives.html
* https://www.freedesktop.org/software/systemd/man/latest/systemd.timer.html

----
[[Kategorie:systemd]]
[[Kategorie:Eigene Daemons]]

DKIM

2024-09-24T16:17:30Z

Hsh-janulrichhasecke: /* Domainkey im DNS */ Versuch einer Umformulierung.

[[Kategorie:HSDoku]][[Kategorie:E-Mail]]
= DomainKeys Identified Mail (DKIM) =

DKIM ist ein Verfahren, dass die Authentizität einer E-Mail sicherstellen kann. Dazu wird die E-Mail auf dem sendenden System mit einer elektronischen Signatur in den unsichtbaren Headerzeilen der E-Mail versehen. Es kommt ein asymmetrisches Schlüsselverfahren zum Einsatz. Der sendende Server verwendet seinen privaten Schlüssel, um die Signatur zu erstellen.

Der öffentliche Schlüssel wird im DNS der E-Mail-Domain veröffentlicht, so dass Empfänger die Authentizität der Signatur prüfen können.

== DKIM bei Hostsharing aktivieren ==

Die Nutzer der Hostsharing-Plattform können E-Mails, die sie über die Hostsharing-Server versenden, mit einer DKIM Signatur versehen lassen. Dazu sind zwei Voraussetzungen notwendig:

# Die Veröffentlichung des öffentlichen Domainkey im DNS der eigenen E-Mail-Domain.
# Das Setzen der Domain-Option "Domain Key – DKIM" mit Hilfe von HSAdmin.

=== Domainkey im DNS ===

==== Wenn ein individuell angepasstes Zonefile existiert ====

Wenn das Zonefile individuell angepasst wurde, muss es entweder den Platzhalter

{DEFAULT_ZONEFILE}

oder den Platzhalter

{DKIM_RR}

enthalten.

Wenn das nicht der Fall ist, muss eine der beiden Zeilen ergänzt werden.

==== Wenn das Zonefile nicht verändert wurde ====

Wenn kein Zonefile im etc-Verzeichnis der Domain vorhanden ist, bedeutet dies, dass das Default-Zonefile mit der Zeile "{DEFAULT_ZONEFILE}" genutzt wird.

Die Veröffentlichung ddes Domainkeys ist dann mit einem einfachen "touch"-Befehl möglich.

xyz00-doms@h97:~$ touch doms/hs-example.de/etc/pri.hs-example.de

Daraufhin erstellt das System automatisch einen Domain-Key und veröffentlicht ihn.
Etwa drei Minuten nach dem "touch" liefert der Befehl

$ dig -t TXT +short default._domainkey.hs-example.de @dns1.hostsharing.net

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

einen Schlüssel in der Form:

v=DKIM1; h=sha256; k=rsa; s=email; " "p=MIIBIjAN [...]"

=== Domainoption DKIM ===

Über die Domainoption "Domain Key – DKIM" wird gesteuert, dass der SMTP-Server, auf dem der Webspace mit der Domain liegt, die ausgehenden E-Mail mit einer DKIM-Signatur ausstattet.

Zum Anpassen der Domainoptionen wählt man in HSAdmin links den Punkt "Web-Paket" und im rechten Bereich im Menü die Auswahl "Domain". Bei Domains, die ab 3. September 2021 eingerichtet wurden, ist die Domainoption per Voreinstellung gesetzt,

[[Datei:dkim-domain.png]]

[[Datei:dkim-option.png]]

== DKIM deaktivieren ==

Das Abstellen der DKIM-Option in folgender Reihenfolge wird funktionieren:

# Die Domainoption deaktivieren
# Abwarten bis alle mit der Option (und damit mit einer Signatur) versendeten E-Mail zugestellt sind
# Den Domainkey im DNS entfernen

== DKIM bei Google ==

Die Server von ''gmail'' sind so eingestellt, dass E-Mails von Domains ohne DKIM oder SPF nicht zugestellt werden. Die Empfängerseite wird nicht informiert. An die Absenderseite geht eine Fehlermeldung in der Art:
<Blockquote>... host gmail-smtp-in.l.google.com[2a00:1450:4010:c0f::1a] said: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. 550-5.7.26 550-5.7.26 Authentication results: 550-5.7.26 DKIM = did not pass 550-5.7.26 ...</blockquote>
Dieser Google-Support-Artikel: [https://support.google.com/a/answer/81126 Richtlinien für E-Mail-Absender] (abgerufen am 26. Mai 2024) soll das erläutern.

Nach erfolgreicher Umstellung findet sich im Header einer E-Mail in Googles Posteingang Text in der Art:
<blockquote>Authentication-Results: mx.google.com;
dkim=pass ...
spf=pass ...</blockquote>

== Links ==

* [https://de.wikipedia.org/wiki/DomainKeys DKIM Artikel der Wikipedia]
* [https://www.hostsharing.net/doc/managed-operations-platform/zonefile/ Hostsharing-Dokumentation zur Anpassung des Zonefile]
* [https://www.hostsharing.net/doc/managed-operations-platform/domain/#kap-domain-optionen Hostsharing-Dokumentation Domain-Optionen]

.htaccess

2024-07-31T07:12:34Z

Hsh-janulrichhasecke: /* Ausnahme die eigene IP-Adresse */

Mit <code>.htaccess</code> Dateien innerhalb der Dokument-Verzeichnisse einer Domain (möglichst in ~/doms/example.com/.htaccess oder gezielt in Unterverzeichnissen subs/www ect. ), können Einstellungen des Apache Webservers konfiguriert werden.

Zum Beispiel kann angegeben werden, welches Apache-Modul für bestimmte Dateien (oder bestimmte Datei-Endungen) benutzt werden soll, wohin Dokumente verschoben worden sind, oder auch, wer Zugriff auf die Dateien hat.

== Einstellen von MIME-Typen ==

<syntaxhighlight lang=apache line>
# Download von Zertifikaten ermöglichen:
AddType application/x-x509-ca-cert .crt
</syntaxhighlight>

== Einstellen des im HTTP Header angegebenen Zeichensatzes ==

für .html Dateien:
<syntaxhighlight lang=apache line>
AddCharset UTF-8 .html

# oder
AddDefaultCharset UTF-8
</syntaxhighlight>

(für PHP Skripte siehe [[PHP]] )

== Einstellen von Datei Handlern ==

<syntaxhighlight lang=apache line>
AddType application/x-httpd-phpcgi .php
Action application/x-httpd-phpcgi /fastcgi-bin/phpstub
</syntaxhighlight>

==Passwortschutz für Dateien==

'''Achtung:''' Sofern der Zugriff http Zugriff auf die Dateien nicht automatisch auf https:// bzw. [[TLS_/_SSL|SSL]] umgeleitet wird, können die Passwörter unverschlüsselt übertragen werden!

Zunächst wollen wir den Zugriff auf ein Unterverzeichnis unserer Beispiel-Domain per .htaccess einschränken. Dazu legen wir zunächst eine Passwort-Datei an. Am einfachsten lässt sich diese spezielle Passwort-Datei in einer Shell anlegen. Wir legen sie in das etc-Verzeichnis der Domain:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ cd ~/doms/example.com/etc
xyz00-doms@hopi$ htpasswd -c .htpasswd peter
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Beim ersten User, hier peter wird das Programm htpasswd mit der Option -c (create) aufgerufen, aber auch wirklich nur beim ersten mal, da sonst die Datei .htpasswd neu erzeugt werden würde und vorherige Einträge damit gelöscht wären.

Sollte es beim Versuch, die Datei anzulegen, zu der Fehlermeldung kommando htpasswd nicht bekannt kommen, dann müssen wir zunächst den Befehl lokalisieren und mit dem richtigen Pfad neu aufrufen:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ locate htpasswd
/usr/sbin/htpasswd
xyz00-doms@hopi$ /usr/sbin/htpasswd -c .htpasswd peter
</syntaxhighlight>

Beim zweiten User erfolgt der Aufruf dann ohne die Option -c:

<syntaxhighlight lang=bash>
xyz00-doms@hopi$ htpasswd .htpasswd petra
New password: *****
Re-type new password: *****
xyz00-doms@hopi$
</syntaxhighlight>

Die Sternchen * stehen selbstverständlich für das jeweilige Passwort, welches dem User zugeordnet werden soll.

Diese Datei könnten wir auch einfach mit scp/pscp oder FTP hochladen, dabei stellt sich dann jedoch die Frage, wie wir sie erzeugen. Auf den meisten Windows-Systemen dürfte kein htpasswd-Kommando verfügbar sein. Für diese Fälle gibt es eine online-Version z.b.: https://de.functions-online.com/crypt.html
die Ausgabe einfach mit Copy&Paste in eine Datei kopieren und diese hochladen.

Die so angelegte Passwort-Datei kann nun von einer oder mehreren .htaccess-Dateien verwendet werden. Dazu begeben wir uns in das zu schützende Verzeichnis und legen dort eine Datei .htaccess an. Dies kann wieder per Upload oder in einer Shell geschehen. Die Datei kann beispielsweise so aussehen:

<syntaxhighlight lang=apache line>
order allow,deny
allow from all
require valid-user
Authname "Privater Bereich, bitte Anmelden."
Authtype Basic
AuthUserFile /home/doms/example.com/etc/.htpasswd
</syntaxhighlight>

Dabei verweist die letzte Zeile auf die von uns angelegte .htpasswd Datei. Zu beachten ist:
* Das die Pfadangabe absolut erfolgt, um einen "Internal Server Error" zu vermeiden.
* Falls die Datei innerhalb des Dokumenten Verzeichnisses liegen muss, sie auf jeden Fall .htpasswd heißt, damit sie vom Webserver nicht herausgegeben wird.
* Die .htaccess Datei in den Paketdomains innerhalb des web/ bzw. web-ssl/ Verzeichnisses liegen muss, damit kein "Internal Server Error" auftritt.

===Passwortschutz von CGI- und PHP-Anwendungen===

Mit dem beschriebenen Mechanismus können selbstverständlich auch PHP-Skripte und CGI-Anwendungen vor unberechtigten Zugriffen geschützt werden. In dem geschützten Skript kann über die Umgebungsvariable <code>REDIRECT_REMOTE_USER</code> der Benutzername des Benutzers abgefragt werden, der sich angemeldet hat.

In PHP-Skripten kann mit Hilfe der automatisch global sichtbaren Variablen <code>$_ENV</code> auf die Umgebungsvariablen zugegriffen werden. Um die Variable <code>REDIRECT_REMOTE_USER</code> zu lesen, schreibt man also <code>$_ENV['REDIRECT_REMOTE_USER']</code>.

== Redirects ==

<syntaxhighlight lang=apache line>
Redirect permanent / http://www.example.com/
</syntaxhighlight>

== Rewrite Rules ==

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
</syntaxhighlight>

== Nur SSL erlauben und automatisch umschalten ==

Bei per Symlink zusammengeschalteten Verzeichnissen, kann dies für die Verzeichnisse auf die nur per SSL zugegriffen werden soll, wie folgt erreicht werden:

<syntaxhighlight lang=apache line>
# SSL so fordern, dass ggf. Basic Auth nur einmal innerhalb von SSL abgefragt wird.
#
#SSLOptions +StrictRequire #Bei HS festgelegt.
SSLRequireSSL
ErrorDocument 403 https://xyz00.hostsharing.net/https/URL/mit/entspechendem/Ziel/Verzeichnis
</syntaxhighlight>

In diesem Beispiel wird auf eine xyz00 Domain umgeleitet für die das HS Zertifikat gilt. Liegen die Seiten nicht dort ist die entprechende URL des Speicherortes mit https:// anzugegeben.

Bei separaten Verzeichnissen für ssl und nicht-ssl kann auch ein permanenter Redirekt gelegt werden.

Beispiel:
<syntaxhighlight lang=apache line>
Redirect permanent / https://www.example.org/
</syntaxhighlight>

Um alle http Requests nach https weiter zu leiten:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule .* https://%{HTTP_HOST}:443%{REQUEST_URI} [QSA,R=permanent,L]
</syntaxhighlight>

==Verzeichnislisting ausschalten==

Ruft ein Nutzer ein Verzeichnis auf, z.B. www.example.com/verzeichnis, so wird normalerweise die sich darin befindliche index.html als Standard aufgerufen. Gibt es diese Datei nicht, wird der Inhalt des Verzeichnisses gelistet. Das kann ein Sicherheitsproblem sein.

Die Einstellung
<syntaxhighlight lang=apache line>
IndexIgnore *
</syntaxhighlight>
sorgt dafür, dass alle Datein Unterhalb des Speicherortes der .htaccess Datei für das Verzeichnislisting ignoriert werden.

Hinweis: Das Listen der Verzeichnisse kann auch schon auf Dateisystemebene durch ändern der Verzeichnisrechte (o-r) unterbunden werden, wodurch auch lokale User berücksichtigt werden.

== Ausnahme die eigene IP-Adresse ==

Zum Testen willst du möglicherweise auf ein anderes Backend zugreifen, als es die normalen Webseiten-Besucherinnen tun. Du kannst die eigene IP-Adresse als "RewriteCond" verwenden:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REMOTE_ADDR} !=62.27.244.230
RewriteRule ^(.*) ajp://hsh02.hostsharing.net:8009/$1 [proxy,last]

RewriteRule ^(.*) ajp://127.0.0.1:34380/$1 [proxy,last]
</syntaxhighlight>

== Bestimmte Clients blockieren ==

Jeder Web-Browser gibt sich mit einer Kennung zu erkennen. Auch Bots sollten sich mit einer bestimmten Kennung zu erkennen geben. Diese Kennung wird ersichtlich, wenn Du die web.log Datei durchsuchst (siehe [[Traffic]]). Damit ist es möglich, bestimmte Clients oder Bots auszuschließen.

Hier im Beispiel werden der SemrushBot, der MJ12bot, und der AI Bot Claude von Anthropic ausgeschlossen:

<syntaxhighlight lang=apache line>
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_USER_AGENT} ^.*SemrushBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*MJ12bot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^.*ClaudeBot.*$ [OR]
RewriteCond %{HTTP_USER_AGENT} ^$
RewriteRule ^.* - [F,L]
</syntaxhighlight>

Siehe auch https://stackoverflow.com/a/35775449/1632368

== Bestimmte Verzeichnisse nicht ausliefern ==

zum Beispiel das .git Verzeichnis sollte nicht gezeigt werden:

<syntaxhighlight lang=apache line>
RedirectMatch 404 /\.git
</syntaxhighlight>

Oder wenn Wordpress für alle URLs mit HTTP Code 200 die Startseite anzeigt, denken manche Angreifer, es läuft ein mailman.

<syntaxhighlight lang=apache line>
RedirectMatch 404 /mailman/
</syntaxhighlight>

== Gesperrte Optionen ==

Einstellungen, die es ermöglichen würden, über den Webserver Rechte anderer
User zu erhalten, sind nicht erlaubt.
--
[[Kategorie:HSDoku]]
[[Kategorie:WWW]]
[[Kategorie:Glossar]]

E-Mail-Adressen

2024-04-11T13:05:07Z

Hsh-janulrichhasecke: /* Auf der Kommandozeile mit hsadmin CLI */ neuer link

{{delete|Seite ist in vielen Teilen veraltet. Inhalt sollte Bestandteil der Kerndoku sein.}}

= E-Mail Adressen einrichten =

== Mit dem WebFrontend ==

Siehe dazu [[WebFrontend]]

== Auf der Kommandozeile mit hsadmin CLI ==

Siehe dazu:
https://www.hostsharing.net/doc/managed-operations-platform/hsadmin/emailaddress/

= Standard Adressen =

== E-Mail Adressen von Hostsharing Mitgliedern ==
Jedes Mitglied bekommt eine E-Mail-Adresse der Form:

vorname.nachname@hostsharing.net

Diese wird an die E-Mailadresse, die in Stammdaten des HS Mitglieds angegeben ist, weitergeleitet.

== E-Mail Adressen von Hostsharing Paketen ==

Jedes Paket bekommt standardmäßig folgende E-Mailadressen eingerichtet:

owner@xyz00.hostsharing.net -> E-Mailadresse aus den Stammdaten des HS Mitglieds
admin@xyz00.hostsharing.net -> lokaler Paketadmin (xyz00@)
xyz00@xyz00.hostsharing.net -> lokale Mailbox des Paktadmins

== E-Mail Adressen lokaler User ==

Lokale User sind zunächst nur über den Hostsharing Host oder [[Hive]] erreichbar (xyz00@<hostname>.hostsharing.net oder xyz00@[[Hive|h00]].hostsharing.net). Diese Adressen ändern sich aber logischerweise bei einem Umzug des Pakets auf einen anderen Host oder
Hive und sind daher nicht zuverlässig verwendbar.

== E-Mail Adessen neu aufgeschalteter Domains ==

Jede aufgeschaltete Domain bekommt initial die E-Mail-Adressen webmaster@..., postmaster@... und abuse@... eingerichtet. Ein sogenannter Catch-All (*@... = jede beliebige Mailadresse für die Domain wird angenommen) kann selbstverständlich per [[Hsadmin-mail]] nachträglich eingerichtet werden. Das ist aber nicht zu empfehlen, wenn man nicht einen Spam-Sammler konfigurieren will.

Anpassungen von Anwendungen nach Debian Bookworm Upgrade

2024-01-30T09:25:56Z

Hsh-janulrichhasecke: /* Wer ist für was verantwortlich? */

== Wer ist für was verantwortlich? ==

Die Hostmaster aktualisieren das Betriebssytem.

Die Mitglieder sind für den Betrieb der eigenen Anwendungen im Userspace verantwortlich. Da dazu keine besonderen Rechte erforderlich sind, können die notwendigen Anpassungen vom technisch versierten Mitglied selbst vorgenommen werden.

Wenn das Mitglied die Anpassungen nicht selbst vornehmen kann oder will, kann ein [https://www.hostsharing.net/service/webmaster-on-demand/ Webmaster On Demand (WoD)] Auftrag erteilt werden, damit ein Hostmaster eine Anwendung wieder zum Laufen bringt. Schreibt bitte einfach eine E-Mail an service@ und nennt die Anwendung, um die es geht, und in welchem Benutzer sie läuft.

Auf dieser Seite teilen wir Anleitungen, wie man die eigene Anwendung selbst wieder zum Laufen bringt.

== Anpassungen an Python-Anwendungen ==

{{Textkasten|gelb|Achtung|Python 2.7 steht unter Debian 12 ("Bookworm") nicht mehr zur Verfügung!}}

Nach dem Upgrade müssen die meisten Python-Anwendungen angepasst werden.

Dazu muss das Virtual Environment gelöscht und neu angelegt werden, am besten mit der Standard Python-Version von Debian 12 (Bookworm). Das ist Python 3.11

Falls die Anwendung noch nicht mit Python 3.11 zurecht kommt, kann mit pyenv auch eine ältere Python-Version, z.B. 3.10 installiert werden: [[Eigenes_Python_installieren#Installation_mit_pyenv]]

Falls bereits mit pyenv eine eigene Python-Version installiert worden war, sollte diese gelöscht und nochmals installiert werden. Eventuell ist eine selbst installierte Python-Version aber auch nicht mehr nötig, und es kann mit der Version Python 3.11 vom Betriebssystem gearbeitet werden.

In der .profile oder .bash_profile sollte diese Variable gesetzt werden:

export PYTHONIOENCODING=utf-8

=== Änderungen beim Einsatz von Passenger und Python ===

Das Verhalten von Passenger auf Debian 12 Bookworm hat sich geändert: Es können nicht mehr die Parameter <code>PassengerPython</code> oder <code>PassengerFriendlyErrorPages</code> in der <code>.htaccess</code>-Datei gesetzt werden. Das führt zu einem 500er Fehler.

Falls ein Virtual Environment benutzt wird, sollte folgender Eintrag in der <code>.htaccess</code> Datei gesetzt werden:

SetEnv PYTHONPATH /home/pacs/xyz00/users/example/meinprojekt

Desweiteren sollte der Pfad zum Python-Binärprogramm in den Eigenschaften der Domain in HSAdmin konfiguriert werden, unter PassengerPython: z.B. <code>/home/pacs/xyz00/users/example/.pyenv/versions/3.9.18/bin/python3</code>, oder bei einem Virtual Environment: <code>/home/pacs/xyz00/users/example/meinprojekt/.venv/bin/python3</code>

(Versionsnummer, User und Paket im Pfad anpassen)

== Anpassungen an PHP Anwendungen ==

{{Textkasten|gelb|Achtung|Unter Debian 12 ("Bookworm") ist PHP 8.2 die Default Version. PHP 7.4 bleibt installiert. 
Auf Anfrage stellen wir auch PHP 8.0 und PHP 8.1 zur Verfügung.}}

In der .htaccess Datei müssen die Zeilen mit AddType und Action für PHP entfernt werden:

nano doms/meinedomain.de/.htaccess
# diese Zeilen entfernen:
AddType application/x-httpd-php81 .php
Action application/x-httpd-php81 /fastcgi-bin/phpstub81

Wenn bisher nur der voreingestellte phpstub verwendet wurde, lief die Seite bisher auf PHP 7.4. Nun würde sie auf PHP 8.2 laufen. Falls die Anwendung das nicht unterstützt, muss für die Domain in HSAdmin die gewünschte PHP Version in der Liste bei "FastCGI PHP-Interpreter" gewählt werden.

== Anpassungen an Ruby Anwendungen ==

Die meisten Ruby Anwendungen werden mit rbenv betrieben. Das funktioniert nach dem Upgrade auf Debian 12 Bookworm nicht mehr, wegen Inkompatibilitäten bei der OpenSSL-Bibliothek.

Daher muss die rbenv-Umgebung neu installiert werden, siehe [[RubyRBEnv]].

Es müssen auch meistens die Ruby Gems neu installiert werden.

# erst löschen
rm -Rf ~/.gem/
rm -Rf ~/.bundle
rm -Rf ~/.local/state/gem/

# dann installieren
cd meineapp # z.B. zammad
export RAILS_ENV="production"
bundle install

Falls '''Passenger''' zum Einsatz kommt: Das Verhalten von Passenger hat sich geändert. Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen. Sie müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Ruby Version verwendet werden soll.
Es kann entweder die vorinstallierte Ruby Version verwendet werden, oder eine Ruby Version unter einem Pfad wie <code>/home/pacs/xyz00/users/example/.rbenv/shims/ruby</code>.

== Anpassungen an Node.js Anwendungen ==
Es muss das Verzeichns <code>.nvm</code> im Home Verzeichnis gelöscht werden, und <code>node_modules</code> im Projekt.

Dann Node wieder neu installieren, siehe [[NodeJS]].

Dann <code>yarn install</code> bzw andere Befehle ausführen, um die Node Module wieder zu installieren.

Falls '''Passenger''' zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert. Die Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen, und müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Node Version verwendet werden soll.
Es kann entweder die vorinstallierte Node Version verwendet werden, oder eine Node Version unter dem Pfad z.B. <code>/home/pacs/xyz00/users/example/.nvm/versions/node/v20.11.0/bin/node</code>.

== Anpassungen an Java Anwendungen ==
=== Eigenes Java Development Kit (JDK) installieren ===

In Debian Buster lief Java 11. Unter Debian Bookworm steht Java 17 zur Verfügung.

Für Anwendungen, die weiterhin Java 11 benötigen, kann es pro User oder pro Paket installiert werden.

Ältere JDKs können hier als Binary für Linux/x64 heruntergeladen werden: https://jdk.java.net/archive/

Ein Beispiel für JDK 11:

mkdir ~/bin
cd bin
wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz
tar xzf openjdk-11.0.2_linux-x64_bin.tar.gz

Eine weitere zuverlässige Quelle für eine freie Distribution des OpenJDK ist die Eclipse Foundation: https://adoptium.net/de/

Dann muss im Tomcat (z.B. bin/setenv.sh) oder in der systemd Service Datei die Variable JAVA_HOME gesetzt werden:

JAVA_HOME=/home/pacs/xyz00/users/meinuser/bin/jdk-11

=== Eigenen Tomcat installieren ===

Bei Debian Buster lief Tomcat 9, auf Debian Bookworm steht Tomcat 10 zur Verfügung. Die beiden Versionen sind nicht kompatibel. Tomcat 9 implementiert Java EE 8; bei Tomcat 10 ist es Jakarta EE 9. Aus lizenzrechtlichen Gründen wurden alle Java-Packages aus den Java-EE-Spezifikationen von <code>javax.</code> nach <code>jakarta.</code> umbenannt.

Für eigene Anwendungen empfehlen wir, die Software entsprechend anzupassen und neu zu kompilieren. Für Software aus anderen Quellen kann das Tool <code>javax2jakarta</code> diesen Schritt in der Regel leisten.

Wenn die Migration nicht möglich oder nicht gewünscht ist, kann leicht ein vollständiger Tomcat 9 pro User installiert werden.

Ältere Versionen von Tomcat sind hier zu finden: https://tomcat.apache.org/download-90.cgi

mv tomcat tomcat.bak
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.84/bin/apache-tomcat-9.0.84.tar.gz
mv apache-tomcat-9.0.84 tomcat
cp tomcat.bak/conf/server.xml tomcat/conf/
cp tomcat.bak/conf/setenv.sh tomcat/conf/
cp -R tomcat.bak/webapps tomcat

Bitte darauf achten, ob noch weitere Konfigurationsdateien kopiert werden und Anpassungen an der context.xml und web.xml übernommen werden müssen.

== Anpassungen an Redis Diensten ==

Falls ein Redis-Dienst läuft, bitte kontrollieren, ob er noch richtig funktioniert.

Gegebenenfalls müssen in der Datei <code>redis.conf</code> relative Pfade in absolute Pfade geändert werden, falls dies nicht bereits der Fall ist (z.B. für <code>logfile</code>, <code>unixsocket</code>, <code>dir</code>).

== Aktualisierung von MongoDB ==

MongoDB wird bei uns nicht vom Betriebssystem bereitgestellt.

Falls MongoDB verwendet wird, müssen neue Binaries heruntergeladen werden. Dabei ist die Version für Ubuntu 22.04 zu verwenden, da es keine Version für Debian 12 (Bookworm) gibt: siehe https://www.mongodb.com/try/download/community

Anpassungen von Anwendungen nach Debian Bookworm Upgrade

2024-01-30T09:24:43Z

Hsh-janulrichhasecke: Sprachliche Überarbeitung

== Wer ist für was verantwortlich? ==

Die Hostmaster aktualisieren das Betriebssytem.

Die Mitglieder sind für den Betrieb der eigenen Anwendungen im Userspace verantwortlich. Da dazu keine besonderen Rechte erforderlich sind, können die notwendigen Anpassungen vom technisch versierten Mitglied selbst vorgenommen werden.

Wenn das Mitglied die Anpassungen nicht selbst vornehmen kann oder will, kann ein [https://www.hostsharing.net/service/webmaster-on-demand/ Webmaster On Demand (WoD)] Auftrag erteilt werden, damit ein Hostmaster eine Anwendung wieder zum Laufen bringt. Schreibt bitte einfach eine E-Mail an service@ und nennt die Anwendung, um die es geht, und in welchem Benutzer die Anwendung läuft.

Auf dieser Seite teilen wir Anleitungen, wie man die eigene Anwendung selbst wieder zum Laufen bringt.

== Anpassungen an Python-Anwendungen ==

{{Textkasten|gelb|Achtung|Python 2.7 steht unter Debian 12 ("Bookworm") nicht mehr zur Verfügung!}}

Nach dem Upgrade müssen die meisten Python-Anwendungen angepasst werden.

Dazu muss das Virtual Environment gelöscht und neu angelegt werden, am besten mit der Standard Python-Version von Debian 12 (Bookworm). Das ist Python 3.11

Falls die Anwendung noch nicht mit Python 3.11 zurecht kommt, kann mit pyenv auch eine ältere Python-Version, z.B. 3.10 installiert werden: [[Eigenes_Python_installieren#Installation_mit_pyenv]]

Falls bereits mit pyenv eine eigene Python-Version installiert worden war, sollte diese gelöscht und nochmals installiert werden. Eventuell ist eine selbst installierte Python-Version aber auch nicht mehr nötig, und es kann mit der Version Python 3.11 vom Betriebssystem gearbeitet werden.

In der .profile oder .bash_profile sollte diese Variable gesetzt werden:

export PYTHONIOENCODING=utf-8

=== Änderungen beim Einsatz von Passenger und Python ===

Das Verhalten von Passenger auf Debian 12 Bookworm hat sich geändert: Es können nicht mehr die Parameter <code>PassengerPython</code> oder <code>PassengerFriendlyErrorPages</code> in der <code>.htaccess</code>-Datei gesetzt werden. Das führt zu einem 500er Fehler.

Falls ein Virtual Environment benutzt wird, sollte folgender Eintrag in der <code>.htaccess</code> Datei gesetzt werden:

SetEnv PYTHONPATH /home/pacs/xyz00/users/example/meinprojekt

Desweiteren sollte der Pfad zum Python-Binärprogramm in den Eigenschaften der Domain in HSAdmin konfiguriert werden, unter PassengerPython: z.B. <code>/home/pacs/xyz00/users/example/.pyenv/versions/3.9.18/bin/python3</code>, oder bei einem Virtual Environment: <code>/home/pacs/xyz00/users/example/meinprojekt/.venv/bin/python3</code>

(Versionsnummer, User und Paket im Pfad anpassen)

== Anpassungen an PHP Anwendungen ==

{{Textkasten|gelb|Achtung|Unter Debian 12 ("Bookworm") ist PHP 8.2 die Default Version. PHP 7.4 bleibt installiert. 
Auf Anfrage stellen wir auch PHP 8.0 und PHP 8.1 zur Verfügung.}}

In der .htaccess Datei müssen die Zeilen mit AddType und Action für PHP entfernt werden:

nano doms/meinedomain.de/.htaccess
# diese Zeilen entfernen:
AddType application/x-httpd-php81 .php
Action application/x-httpd-php81 /fastcgi-bin/phpstub81

Wenn bisher nur der voreingestellte phpstub verwendet wurde, lief die Seite bisher auf PHP 7.4. Nun würde sie auf PHP 8.2 laufen. Falls die Anwendung das nicht unterstützt, muss für die Domain in HSAdmin die gewünschte PHP Version in der Liste bei "FastCGI PHP-Interpreter" gewählt werden.

== Anpassungen an Ruby Anwendungen ==

Die meisten Ruby Anwendungen werden mit rbenv betrieben. Das funktioniert nach dem Upgrade auf Debian 12 Bookworm nicht mehr, wegen Inkompatibilitäten bei der OpenSSL-Bibliothek.

Daher muss die rbenv-Umgebung neu installiert werden, siehe [[RubyRBEnv]].

Es müssen auch meistens die Ruby Gems neu installiert werden.

# erst löschen
rm -Rf ~/.gem/
rm -Rf ~/.bundle
rm -Rf ~/.local/state/gem/

# dann installieren
cd meineapp # z.B. zammad
export RAILS_ENV="production"
bundle install

Falls '''Passenger''' zum Einsatz kommt: Das Verhalten von Passenger hat sich geändert. Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen. Sie müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Ruby Version verwendet werden soll.
Es kann entweder die vorinstallierte Ruby Version verwendet werden, oder eine Ruby Version unter einem Pfad wie <code>/home/pacs/xyz00/users/example/.rbenv/shims/ruby</code>.

== Anpassungen an Node.js Anwendungen ==
Es muss das Verzeichns <code>.nvm</code> im Home Verzeichnis gelöscht werden, und <code>node_modules</code> im Projekt.

Dann Node wieder neu installieren, siehe [[NodeJS]].

Dann <code>yarn install</code> bzw andere Befehle ausführen, um die Node Module wieder zu installieren.

Falls '''Passenger''' zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert. Die Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen, und müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Node Version verwendet werden soll.
Es kann entweder die vorinstallierte Node Version verwendet werden, oder eine Node Version unter dem Pfad z.B. <code>/home/pacs/xyz00/users/example/.nvm/versions/node/v20.11.0/bin/node</code>.

== Anpassungen an Java Anwendungen ==
=== Eigenes Java Development Kit (JDK) installieren ===

In Debian Buster lief Java 11. Unter Debian Bookworm steht Java 17 zur Verfügung.

Für Anwendungen, die weiterhin Java 11 benötigen, kann es pro User oder pro Paket installiert werden.

Ältere JDKs können hier als Binary für Linux/x64 heruntergeladen werden: https://jdk.java.net/archive/

Ein Beispiel für JDK 11:

mkdir ~/bin
cd bin
wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz
tar xzf openjdk-11.0.2_linux-x64_bin.tar.gz

Eine weitere zuverlässige Quelle für eine freie Distribution des OpenJDK ist die Eclipse Foundation: https://adoptium.net/de/

Dann muss im Tomcat (z.B. bin/setenv.sh) oder in der systemd Service Datei die Variable JAVA_HOME gesetzt werden:

JAVA_HOME=/home/pacs/xyz00/users/meinuser/bin/jdk-11

=== Eigenen Tomcat installieren ===

Bei Debian Buster lief Tomcat 9, auf Debian Bookworm steht Tomcat 10 zur Verfügung. Die beiden Versionen sind nicht kompatibel. Tomcat 9 implementiert Java EE 8; bei Tomcat 10 ist es Jakarta EE 9. Aus lizenzrechtlichen Gründen wurden alle Java-Packages aus den Java-EE-Spezifikationen von <code>javax.</code> nach <code>jakarta.</code> umbenannt.

Für eigene Anwendungen empfehlen wir, die Software entsprechend anzupassen und neu zu kompilieren. Für Software aus anderen Quellen kann das Tool <code>javax2jakarta</code> diesen Schritt in der Regel leisten.

Wenn die Migration nicht möglich oder nicht gewünscht ist, kann leicht ein vollständiger Tomcat 9 pro User installiert werden.

Ältere Versionen von Tomcat sind hier zu finden: https://tomcat.apache.org/download-90.cgi

mv tomcat tomcat.bak
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.84/bin/apache-tomcat-9.0.84.tar.gz
mv apache-tomcat-9.0.84 tomcat
cp tomcat.bak/conf/server.xml tomcat/conf/
cp tomcat.bak/conf/setenv.sh tomcat/conf/
cp -R tomcat.bak/webapps tomcat

Bitte darauf achten, ob noch weitere Konfigurationsdateien kopiert werden und Anpassungen an der context.xml und web.xml übernommen werden müssen.

== Anpassungen an Redis Diensten ==

Falls ein Redis-Dienst läuft, bitte kontrollieren, ob er noch richtig funktioniert.

Gegebenenfalls müssen in der Datei <code>redis.conf</code> relative Pfade in absolute Pfade geändert werden, falls dies nicht bereits der Fall ist (z.B. für <code>logfile</code>, <code>unixsocket</code>, <code>dir</code>).

== Aktualisierung von MongoDB ==

MongoDB wird bei uns nicht vom Betriebssystem bereitgestellt.

Falls MongoDB verwendet wird, müssen neue Binaries heruntergeladen werden. Dabei ist die Version für Ubuntu 22.04 zu verwenden, da es keine Version für Debian 12 (Bookworm) gibt: siehe https://www.mongodb.com/try/download/community

Anpassungen von Anwendungen nach Debian Bookworm Upgrade

2024-01-30T09:22:50Z

Hsh-janulrichhasecke: Sprachliche Überarbeitung

== Wer ist für was verantwortlich? ==

Die Hostmaster aktualisieren das Betriebssytem.

Die Mitglieder sind für den Betrieb der eigenen Anwendungen im Userspace verantwortlich. Da dazu keine besonderen Rechte erforderlich sind, können die notwendigen Anpassungen vom technisch versierten Mitglied selbst vorgenommen werden.

Wenn das Mitglied die Anpassungen nicht selbst vornehmen kann oder will, kann ein [https://www.hostsharing.net/service/webmaster-on-demand/ Webmaster On Demand (WoD)] Auftrag erteilt werden, damit ein Hostmaster eine Anwendung wieder zum Laufen bringt. Schreibt bitte einfach eine E-Mail an service@ und nennt die Anwendung, um die es geht, und in welchem Benutzer die Anwendung läuft.

Auf dieser Seite teilen wir Anleitungen, wie man die eigene Anwendung selbst wieder zum Laufen bringt.

== Anpassungen an Python-Anwendungen ==

{{Textkasten|gelb|Achtung|Python 2.7 steht unter Debian 12 ("Bookworm") nicht mehr zur Verfügung!}}

Nach dem Upgrade müssen die meisten Python-Anwendungen angepasst werden.

Dazu muss das Virtual Environment gelöscht und neu angelegt werden, am besten mit der Standard Python-Version von Debian 12 (Bookworm). Das ist Python 3.11

Falls die Anwendung noch nicht mit Python 3.11 zurecht kommt, kann mit pyenv auch eine ältere Python-Version, z.B. 3.10 installiert werden: [[Eigenes_Python_installieren#Installation_mit_pyenv]]

Falls bereits mit pyenv eine eigene Python-Version installiert worden war, sollte diese gelöscht und nochmals installiert werden. Eventuell ist eine selbst installierte Python-Version aber auch nicht mehr nötig, und es kann mit der Version Python 3.11 vom Betriebssystem gearbeitet werden.

In der .profile oder .bash_profile sollte diese Variable gesetzt werden:

export PYTHONIOENCODING=utf-8

=== Änderungen beim Einsatz von Passenger und Python ===

Das Verhalten von Passenger auf Debian 12 Bookworm hat sich geändert: Es können nicht mehr die Parameter <code>PassengerPython</code> oder <code>PassengerFriendlyErrorPages</code> in der <code>.htaccess</code>-Datei gesetzt werden. Das führt zu einem 500er Fehler.

Falls ein Virtual Environment benutzt wird, sollte folgender Eintrag in der <code>.htaccess</code> Datei gesetzt werden:

SetEnv PYTHONPATH /home/pacs/xyz00/users/example/meinprojekt

Desweiteren sollte der Pfad zum Python-Binärprogramm in den Eigenschaften der Domain in HSAdmin konfiguriert werden, unter PassengerPython: z.B. <code>/home/pacs/xyz00/users/example/.pyenv/versions/3.9.18/bin/python3</code>, oder bei einem Virtual Environment: <code>/home/pacs/xyz00/users/example/meinprojekt/.venv/bin/python3</code>

(Versionsnummer, User und Paket im Pfad anpassen)

== Anpassungen an PHP Anwendungen ==

{{Textkasten|gelb|Achtung|Unter Debian 12 ("Bookworm") ist PHP 8.2 die Default Version. PHP 7.4 bleibt installiert. 
Auf Anfrage stellen wir auch PHP 8.0 und PHP 8.1 zur Verfügung.}}

In der .htaccess Datei müssen die Zeilen mit AddType und Action für PHP entfernt werden:

nano doms/meinedomain.de/.htaccess
# diese Zeilen entfernen:
AddType application/x-httpd-php81 .php
Action application/x-httpd-php81 /fastcgi-bin/phpstub81

Wenn bisher nur der voreingestellte phpstub verwendet wurde, lief die Seite bisher auf PHP 7.4. Nun würde sie auf PHP 8.2 laufen. Falls die Anwendung das nicht unterstützt, muss für die Domain in HSAdmin die gewünschte PHP Version in der Liste bei "FastCGI PHP-Interpreter" gewählt werden.

== Anpassungen an Ruby Anwendungen ==

Die meisten Ruby Anwendungen werden mit rbenv betrieben. Das funktioniert nach dem Upgrade auf Debian 12 Bookworm nicht mehr, wegen Inkompatibilitäten bei der OpenSSL-Bibliothek.

Daher muss die rbenv-Umgebung neu installiert werden, siehe [[RubyRBEnv]].

Es müssen auch meistens die Ruby Gems neu installiert werden.

# erst löschen
rm -Rf ~/.gem/
rm -Rf ~/.bundle
rm -Rf ~/.local/state/gem/

# dann installieren
cd meineapp # z.B. zammad
export RAILS_ENV="production"
bundle install

Falls '''Passenger''' zum Einsatz kommt: Das Verhalten von Passenger hat sich geändert. Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen. Sie müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Ruby Version verwendet werden soll.
Es kann entweder die vorinstallierte Ruby Version verwendet werden, oder eine Ruby Version unter einem Pfad wie <code>/home/pacs/xyz00/users/example/.rbenv/shims/ruby</code>.

== Anpassungen an Node.js Anwendungen ==
Es muss das Verzeichns <code>.nvm</code> im Home Verzeichnis gelöscht werden, und <code>node_modules</code> im Projekt.

Dann Node wieder neu installieren, siehe [[NodeJS]].

Dann <code>yarn install</code> bzw andere Befehle ausführen, um die Node Module wieder zu installieren.

Falls '''Passenger''' zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert. Die Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen, und müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Node Version verwendet werden soll.
Es kann entweder die vorinstallierte Node Version verwendet werden, oder eine Node Version unter dem Pfad z.B. <code>/home/pacs/xyz00/users/example/.nvm/versions/node/v20.11.0/bin/node</code>.

== Anpassungen an Java Anwendungen ==
=== Eigenes Java Development Kit (JDK) installieren ===

In Debian Buster lief Java 11. Unter Debian Bookworm steht Java 17 zur Verfügung.

Für Anwendungen, die weiterhin Java 11 benötigen, kann es pro User oder pro Paket installiert werden.

Ältere JDKs können hier als Binary für Linux/x64 heruntergeladen werden: https://jdk.java.net/archive/

Ein Beispiel für JDK 11:

mkdir ~/bin
cd bin
wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz
tar xzf openjdk-11.0.2_linux-x64_bin.tar.gz

Eine weitere zuverlässige Quelle für eine freie Distribution des OpenJDK ist die Eclipse Foundation: https://adoptium.net/de/

Dann muss im Tomcat (z.B. bin/setenv.sh) oder in der systemd Service Datei die Variable JAVA_HOME gesetzt werden:

JAVA_HOME=/home/pacs/xyz00/users/meinuser/bin/jdk-11

=== Eigenen Tomcat installieren ===

Bei Debian Buster lief Tomcat 9, auf Debian Bookworm steht Tomcat 10 zur Verfügung. Die beiden Versionen sind nicht kompatibel. Tomcat 9 implementiert Java EE 8; bei Tomcat 10 ist es Jakarta EE 9. Aus lizenzrechtlichen Gründen wurden alle Java-Packages aus den Java-EE-Spezifikationen von <code>javax.</code> nach <code>jakarta.</code> umbenannt.

Für eigene Anwendungen empfehlen wir, die Software entsprechend anzupassen und neu zu kompilieren. Für Software aus anderen Quellen kann das Tool <code>javax2jakarta</code> diesen Schritt in der Regel leisten.

Wenn die Migration nicht möglich oder nicht gewünscht ist, kann leicht ein vollständiger Tomcat 9 pro User installiert werden.

Ältere Versionen von Tomcat sind hier zu finden: https://tomcat.apache.org/download-90.cgi

mv tomcat tomcat.bak
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.84/bin/apache-tomcat-9.0.84.tar.gz
mv apache-tomcat-9.0.84 tomcat
cp tomcat.bak/conf/server.xml tomcat/conf/
cp tomcat.bak/conf/setenv.sh tomcat/conf/
cp -R tomcat.bak/webapps tomcat

Bitte darauf achten, ob noch weitere Konfigurationsdateien kopiert werden und Anpassungen an der context.xml und web.xml übernommen werden müssen.

== Anpassungen an Redis Diensten ==

Falls ein Redis Dienst läuft, bitte kontrollieren, ob er noch richtig funktioniert.

Gegebenenfalls müssen in der Datei <code>redis.conf</code> die relativen Pfade zu absoluten Pfaden geändert werden, wenn die nicht schon bereits absolute Pfade sind (z.B. <code>logfile</code>, <code>unixsocket</code>, <code>dir</code>)

== Aktualisierung von MongoDB ==

MongoDB wird bei uns nicht vom Betriebssystem bereitgestellt.

Falls MongoDB verwendet wird, müssen neue Binaries heruntergeladen werden. Dabei ist die Version für Ubuntu 22.04 zu verwenden, da es keine Version für Debian 12 (Bookworm) gibt: siehe https://www.mongodb.com/try/download/community

Anpassungen von Anwendungen nach Debian Bookworm Upgrade

2024-01-30T09:20:42Z

Hsh-janulrichhasecke: Sprachliche Überarbeitung

== Wer ist für was verantwortlich? ==

Die Hostmaster aktualisieren das Betriebssytem.

Die Mitglieder sind für den Betrieb der eigenen Anwendungen im Userspace verantwortlich. Da dazu keine besonderen Rechte erforderlich sind, können die notwendigen Anpassungen vom technisch versierten Mitglied selbst vorgenommen werden.

Wenn das Mitglied die Anpassungen nicht selbst vornehmen kann oder will, kann ein [https://www.hostsharing.net/service/webmaster-on-demand/ Webmaster On Demand (WoD)] Auftrag erteilt werden, damit ein Hostmaster eine Anwendung wieder zum Laufen bringt. Schreibt bitte einfach eine E-Mail an service@ und nennt die Anwendung, um die es geht, und in welchem Benutzer die Anwendung läuft.

Auf dieser Seite teilen wir Anleitungen, wie man die eigene Anwendung selbst wieder zum Laufen bringt.

== Anpassungen an Python-Anwendungen ==

{{Textkasten|gelb|Achtung|Python 2.7 steht unter Debian 12 ("Bookworm") nicht mehr zur Verfügung!}}

Nach dem Upgrade müssen die meisten Python-Anwendungen angepasst werden.

Dazu muss das Virtual Environment gelöscht und neu angelegt werden, am besten mit der Standard Python-Version von Debian 12 (Bookworm). Das ist Python 3.11

Falls die Anwendung noch nicht mit Python 3.11 zurecht kommt, kann mit pyenv auch eine ältere Python-Version, z.B. 3.10 installiert werden: [[Eigenes_Python_installieren#Installation_mit_pyenv]]

Falls bereits mit pyenv eine eigene Python-Version installiert worden war, sollte diese gelöscht und nochmals installiert werden. Eventuell ist eine selbst installierte Python-Version aber auch nicht mehr nötig, und es kann mit der Version Python 3.11 vom Betriebssystem gearbeitet werden.

In der .profile oder .bash_profile sollte diese Variable gesetzt werden:

export PYTHONIOENCODING=utf-8

=== Änderungen beim Einsatz von Passenger und Python ===

Das Verhalten von Passenger auf Debian 12 Bookworm hat sich geändert: Es können nicht mehr die Parameter <code>PassengerPython</code> oder <code>PassengerFriendlyErrorPages</code> in der <code>.htaccess</code>-Datei gesetzt werden. Das führt zu einem 500er Fehler.

Falls ein Virtual Environment benutzt wird, sollte folgender Eintrag in der <code>.htaccess</code> Datei gesetzt werden:

SetEnv PYTHONPATH /home/pacs/xyz00/users/example/meinprojekt

Desweiteren sollte der Pfad zum Python-Binärprogramm in den Eigenschaften der Domain in HSAdmin konfiguriert werden, unter PassengerPython: z.B. <code>/home/pacs/xyz00/users/example/.pyenv/versions/3.9.18/bin/python3</code>, oder bei einem Virtual Environment: <code>/home/pacs/xyz00/users/example/meinprojekt/.venv/bin/python3</code>

(Versionsnummer, User und Paket im Pfad anpassen)

== Anpassungen an PHP Anwendungen ==

{{Textkasten|gelb|Achtung|Unter Debian 12 ("Bookworm") ist PHP 8.2 die Default Version. PHP 7.4 bleibt installiert. 
Auf Anfrage stellen wir auch PHP 8.0 und PHP 8.1 zur Verfügung.}}

In der .htaccess Datei müssen die Zeilen mit AddType und Action für PHP entfernt werden:

nano doms/meinedomain.de/.htaccess
# diese Zeilen entfernen:
AddType application/x-httpd-php81 .php
Action application/x-httpd-php81 /fastcgi-bin/phpstub81

Wenn bisher nur der voreingestellte phpstub verwendet wurde, lief die Seite bisher auf PHP 7.4. Nun würde sie auf PHP 8.2 laufen. Falls die Anwendung das nicht unterstützt, muss für die Domain in HSAdmin die gewünschte PHP Version in der Liste bei "FastCGI PHP-Interpreter" gewählt werden.

== Anpassungen an Ruby Anwendungen ==

Die meisten Ruby Anwendungen werden mit rbenv betrieben. Das funktioniert nach dem Upgrade auf Debian 12 Bookworm nicht mehr, wegen Inkompatibilitäten bei der OpenSSL-Bibliothek.

Daher muss die rbenv-Umgebung neu installiert werden, siehe [[RubyRBEnv]].

Es müssen auch meistens die Ruby Gems neu installiert werden.

# erst löschen
rm -Rf ~/.gem/
rm -Rf ~/.bundle
rm -Rf ~/.local/state/gem/

# dann installieren
cd meineapp # z.B. zammad
export RAILS_ENV="production"
bundle install

Falls '''Passenger''' zum Einsatz kommt: Das Verhalten von Passenger hat sich geändert. Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen. Sie müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Ruby Version verwendet werden soll.
Es kann entweder die vorinstallierte Ruby Version verwendet werden, oder eine Ruby Version unter einem Pfad wie <code>/home/pacs/xyz00/users/example/.rbenv/shims/ruby</code>.

== Anpassungen an Node.js Anwendungen ==
Es muss das Verzeichns <code>.nvm</code> im Home Verzeichnis gelöscht werden, und <code>node_modules</code> im Projekt.

Dann Node wieder neu installieren, siehe [[NodeJS]].

Dann <code>yarn install</code> bzw andere Befehle ausführen, um die Node Module wieder zu installieren.

Falls '''Passenger''' zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert. Die Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen, und müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Node Version verwendet werden soll.
Es kann entweder die vorinstallierte Node Version verwendet werden, oder eine Node Version unter dem Pfad z.B. <code>/home/pacs/xyz00/users/example/.nvm/versions/node/v20.11.0/bin/node</code>.

== Anpassungen an Java Anwendungen ==
=== Eigenes Java Development Kit (JDK) installieren ===

In Debian Buster lief Java 11. Unter Debian Bookworm steht Java 17 zur Verfügung.

Für Anwendungen, die weiterhin Java 11 benötigen, kann es pro User oder pro Paket installiert werden.

Ältere JDKs können hier als Binary für Linux/x64 heruntergeladen werden: https://jdk.java.net/archive/

Ein Beispiel für JDK 11:

mkdir ~/bin
cd bin
wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz
tar xzf openjdk-11.0.2_linux-x64_bin.tar.gz

Eine weitere zuverlässige Quelle für eine freie Distribution des OpenJDK ist die Eclipse Foundation: https://adoptium.net/de/

Dann muss im Tomcat (z.B. bin/setenv.sh) oder in der systemd Service Datei die Variable JAVA_HOME gesetzt werden:

JAVA_HOME=/home/pacs/xyz00/users/meinuser/bin/jdk-11

=== Eigenen Tomcat installieren ===

Bei Debian Buster lief Tomcat 9, auf Debian Bookworm steht Tomcat 10 zur Verfügung. Die beiden Versionen sind nicht kompatibel. Tomcat 9 implementiert Java EE 8; bei Tomcat 10 ist es Jakarta EE 9. Aus lizenzrechtlichen Gründen wurden alle Java-Packages aus den Java-EE-Spezifikationen von <code>javax.</code> nach <code>jakarta.</code> umbenannt.

Für eigene Anwendungen empfehlen wir, die Software entsprechend anzupassen und neu zu kompilieren. Für Software aus anderen Quellen kann das Tool <code>javax2jakarta</code> diesen Schritt in der Regel leisten.

Wenn die Migration nicht möglich oder nicht gewünscht ist, kann leicht ein vollständiger Tomcat 9 pro User installiert werden.

Ältere Versionen von Tomcat sind hier zu finden: https://tomcat.apache.org/download-90.cgi

mv tomcat tomcat.bak
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.84/bin/apache-tomcat-9.0.84.tar.gz
mv apache-tomcat-9.0.84 tomcat
cp tomcat.bak/conf/server.xml tomcat/conf/
cp tomcat.bak/conf/setenv.sh tomcat/conf/
cp -R tomcat.bak/webapps tomcat

Darauf achten, ob noch weitere Konfigurationsdateien kopiert werden müssen, und Anpassungen an der context.xml und web.xml übernommen werden müssen.

== Anpassungen an Redis Diensten ==

Falls ein Redis Dienst läuft, bitte kontrollieren, ob er noch richtig funktioniert.

Gegebenenfalls müssen in der Datei <code>redis.conf</code> die relativen Pfade zu absoluten Pfaden geändert werden, wenn die nicht schon bereits absolute Pfade sind (z.B. <code>logfile</code>, <code>unixsocket</code>, <code>dir</code>)

== Aktualisierung von MongoDB ==

MongoDB wird bei uns nicht vom Betriebssystem bereitgestellt.

Falls MongoDB verwendet wird, müssen neue Binaries heruntergeladen werden. Dabei ist die Version für Ubuntu 22.04 zu verwenden, da es keine Version für Debian 12 (Bookworm) gibt: siehe https://www.mongodb.com/try/download/community

Anpassungen von Anwendungen nach Debian Bookworm Upgrade

2024-01-30T09:18:01Z

Hsh-janulrichhasecke: Sprachliche Überarbeitung

== Wer ist für was verantwortlich? ==

Die Hostmaster aktualisieren das Betriebssytem.

Die Mitglieder sind für den Betrieb der eigenen Anwendungen im Userspace verantwortlich. Da dazu keine besonderen Rechte erforderlich sind, können die notwendigen Anpassungen vom technisch versierten Mitglied selbst vorgenommen werden.

Wenn das Mitglied die Anpassungen nicht selbst vornehmen kann oder will, kann ein [https://www.hostsharing.net/service/webmaster-on-demand/ Webmaster On Demand (WoD)] Auftrag erteilt werden, damit ein Hostmaster eine Anwendung wieder zum Laufen bringt. Schreibt bitte einfach eine E-Mail an service@ und nennt die Anwendung, um die es geht, und in welchem Benutzer die Anwendung läuft.

Auf dieser Seite teilen wir Anleitungen, wie man die eigene Anwendung selbst wieder zum Laufen bringt.

== Anpassungen an Python-Anwendungen ==

{{Textkasten|gelb|Achtung|Python 2.7 steht unter Debian 12 ("Bookworm") nicht mehr zur Verfügung!}}

Nach dem Upgrade müssen die meisten Python-Anwendungen angepasst werden.

Dazu muss das Virtual Environment gelöscht und neu angelegt werden, am besten mit der Standard Python-Version von Debian 12 (Bookworm). Das ist Python 3.11

Falls die Anwendung noch nicht mit Python 3.11 zurecht kommt, kann mit pyenv auch eine ältere Python-Version, z.B. 3.10 installiert werden: [[Eigenes_Python_installieren#Installation_mit_pyenv]]

Falls bereits mit pyenv eine eigene Python-Version installiert worden war, sollte diese gelöscht und nochmals installiert werden. Eventuell ist eine selbst installierte Python-Version aber auch nicht mehr nötig, und es kann mit der Version Python 3.11 vom Betriebssystem gearbeitet werden.

In der .profile oder .bash_profile sollte diese Variable gesetzt werden:

export PYTHONIOENCODING=utf-8

=== Änderungen beim Einsatz von Passenger und Python ===

Das Verhalten von Passenger auf Debian 12 Bookworm hat sich geändert: Es können nicht mehr die Parameter <code>PassengerPython</code> oder <code>PassengerFriendlyErrorPages</code> in der <code>.htaccess</code>-Datei gesetzt werden. Das führt zu einem 500er Fehler.

Falls ein Virtual Environment benutzt wird, sollte folgender Eintrag in der <code>.htaccess</code> Datei gesetzt werden:

SetEnv PYTHONPATH /home/pacs/xyz00/users/example/meinprojekt

Desweiteren sollte der Pfad zum Python-Binärprogramm in den Eigenschaften der Domain in HSAdmin konfiguriert werden, unter PassengerPython: z.B. <code>/home/pacs/xyz00/users/example/.pyenv/versions/3.9.18/bin/python3</code>, oder bei einem Virtual Environment: <code>/home/pacs/xyz00/users/example/meinprojekt/.venv/bin/python3</code>

(Versionsnummer, User und Paket im Pfad anpassen)

== Anpassungen an PHP Anwendungen ==

{{Textkasten|gelb|Achtung|Unter Debian 12 ("Bookworm") ist PHP 8.2 die Default Version. PHP 7.4 bleibt installiert. 
Auf Anfrage stellen wir auch PHP 8.0 und PHP 8.1 zur Verfügung.}}

In der .htaccess Datei müssen die Zeilen mit AddType und Action für PHP entfernt werden:

nano doms/meinedomain.de/.htaccess
# diese Zeilen entfernen:
AddType application/x-httpd-php81 .php
Action application/x-httpd-php81 /fastcgi-bin/phpstub81

Wenn bisher nur der voreingestellte phpstub verwendet wurde, lief die Seite bisher auf PHP 7.4. Nun würde sie auf PHP 8.2 laufen. Falls die Anwendung das nicht unterstützt, muss für die Domain in HSAdmin die gewünschte PHP Version in der Liste bei "FastCGI PHP-Interpreter" gewählt werden.

== Anpassungen an Ruby Anwendungen ==

Die meisten Ruby Anwendungen werden mit rbenv betrieben. Das funktioniert nach dem Upgrade auf Debian 12 Bookworm nicht mehr, wegen Inkompatibilitäten bei der OpenSSL-Bibliothek.

Daher muss die rbenv-Umgebung neu installiert werden, siehe [[RubyRBEnv]].

Es müssen auch meistens die Ruby Gems neu installiert werden.

# erst löschen
rm -Rf ~/.gem/
rm -Rf ~/.bundle
rm -Rf ~/.local/state/gem/

# dann installieren
cd meineapp # z.B. zammad
export RAILS_ENV="production"
bundle install

Falls '''Passenger''' zum Einsatz kommt: Das Verhalten von Passenger hat sich geändert. Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen. Sie müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Ruby Version verwendet werden soll.
Es kann entweder die vorinstallierte Ruby Version verwendet werden, oder eine Ruby Version unter einem Pfad wie <code>/home/pacs/xyz00/users/example/.rbenv/shims/ruby</code>.

== Anpassungen an Node.js Anwendungen ==
Es muss das Verzeichns <code>.nvm</code> im Home Verzeichnis gelöscht werden, und <code>node_modules</code> im Projekt.

Dann Node wieder neu installieren, siehe [[NodeJS]].

Dann <code>yarn install</code> bzw andere Befehle ausführen, um die Node Module wieder zu installieren.

Falls '''Passenger''' zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert. Die Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen, und müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Node Version verwendet werden soll.
Es kann entweder die vorinstallierte Node Version verwendet werden, oder eine Node Version unter dem Pfad z.B. <code>/home/pacs/xyz00/users/example/.nvm/versions/node/v20.11.0/bin/node</code>.

== Anpassungen an Java Anwendungen ==
=== Eigenes Java JDK installieren ===
Auf Debian Buster lief lief Java 11. Auf Debian Bookworm steht Java 17 zur Verfügung.

Für Anwendungen, die weiterhin Java 11 benötigen, kann es pro User oder pro Paket installiert werden.

Ältere JDKs können hier als Binary für Linux/x64 heruntergeladen werden: https://jdk.java.net/archive/

Ein Beispiel für JDK 11:

mkdir ~/bin
cd bin
wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz
tar xzf openjdk-11.0.2_linux-x64_bin.tar.gz

Eine weitere zuverlässige Quelle für eine freie Distribution des OpenJDK ist die Eclipse Foundation: https://adoptium.net/de/

Dann muss z.B. im Tomcat (z.B. bin/setenv.sh) oder in der systemd Service Datei die Variable JAVA_HOME gesetzt werden:

JAVA_HOME=/home/pacs/xyz00/users/meinuser/bin/jdk-11

=== Eigenen Tomcat installieren ===

Bei Debian Buster lief Tomcat 9, auf Debian Bookworm steht Tomcat 10 zur Verfügung. Die beiden Versionen sind nicht kompatibel. Tomcat 9 implementiert Java EE 8; bei Tomcat 10 ist es Jakarta EE 9. Aus lizenzrechtlichen Gründen wurden alle Java-Packages aus den Java-EE-Spezifikationen von <code>javax.</code> nach <code>jakarta.</code> umbenannt.

Für eigene Anwendungen empfehlen wir, die Software entsprechend anzupassen und neu zu kompilieren. Für Software aus anderen Quellen kann das Tool <code>javax2jakarta</code> diesen Schritt in der Regel leisten.

Wenn die Migration nicht möglich oder nicht gewünscht ist, kann leicht ein vollständiger Tomcat 9 pro User installiert werden.

Ältere Versionen von Tomcat sind hier zu finden: https://tomcat.apache.org/download-90.cgi

mv tomcat tomcat.bak
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.84/bin/apache-tomcat-9.0.84.tar.gz
mv apache-tomcat-9.0.84 tomcat
cp tomcat.bak/conf/server.xml tomcat/conf/
cp tomcat.bak/conf/setenv.sh tomcat/conf/
cp -R tomcat.bak/webapps tomcat

Darauf achten, ob noch weitere Konfigurationsdateien kopiert werden müssen, und Anpassungen an der context.xml und web.xml übernommen werden müssen.

== Anpassungen an Redis Diensten ==

Falls ein Redis Dienst läuft, bitte kontrollieren, ob er noch richtig funktioniert.

Gegebenenfalls müssen in der Datei <code>redis.conf</code> die relativen Pfade zu absoluten Pfaden geändert werden, wenn die nicht schon bereits absolute Pfade sind (z.B. <code>logfile</code>, <code>unixsocket</code>, <code>dir</code>)

== Aktualisierung von MongoDB ==

MongoDB wird bei uns nicht vom Betriebssystem bereitgestellt.

Falls MongoDB verwendet wird, müssen neue Binaries heruntergeladen werden. Dabei ist die Version für Ubuntu 22.04 zu verwenden, da es keine Version für Debian 12 (Bookworm) gibt: siehe https://www.mongodb.com/try/download/community

Anpassungen von Anwendungen nach Debian Bookworm Upgrade

2024-01-30T09:05:29Z

Hsh-janulrichhasecke: Sprachliche Überarbeitung

== Wer ist für was verantwortlich? ==

Die Hostmaster aktualisieren das Betriebssytem.

Die Mitglieder sind für den Betrieb der eigenen Anwendungen im Userspace verantwortlich. Da dazu keine besonderen Rechte erforderlich sind, können die notwendigen Anpassungen vom technisch versierten Mitglied selbst vorgenommen werden.

Wenn das Mitglied die Anpassungen nicht selbst vornehmen kann oder will, kann ein [https://www.hostsharing.net/service/webmaster-on-demand/ Webmaster On Demand (WoD)] Auftrag erteilt werden, damit ein Hostmaster eine Anwendung wieder zum Laufen bringt. Schreibt bitte einfach eine E-Mail an service@ und nennt die Anwendung, um die es geht, und in welchem Benutzer die Anwendung läuft.

Auf dieser Seite teilen wir Anleitungen, wie man die eigene Anwendung selbst wieder zum Laufen bringt.

== Anpassungen an Python-Anwendungen ==

{{Textkasten|gelb|Achtung|Python 2.7 steht unter Debian 12 ("Bookworm") nicht mehr zur Verfügung!}}

Nach dem Upgrade müssen die meisten Python-Anwendungen angepasst werden.

Dazu muss das Virtual Environment gelöscht und neu angelegt werden, am besten mit der Standard Python-Version von Debian 12 (Bookworm). Das ist Python 3.11

Falls die Anwendung noch nicht mit Python 3.11 zurecht kommt, kann mit pyenv auch eine ältere Python-Version, z.B. 3.10 installiert werden: [[Eigenes_Python_installieren#Installation_mit_pyenv]]

Falls bereits mit pyenv eine eigene Python-Version installiert worden war, sollte diese gelöscht und nochmals installiert werden. Eventuell ist eine selbst installierte Python-Version aber auch nicht mehr nötig, und es kann mit der Version Python 3.11 vom Betriebssystem gearbeitet werden.

In der .profile oder .bash_profile sollte diese Variable gesetzt werden:

export PYTHONIOENCODING=utf-8

=== Änderungen beim Einsatz von Passenger und Python ===

Das Verhalten von Passenger auf Debian 12 Bookworm hat sich geändert: Es können nicht mehr die Parameter <code>PassengerPython</code> oder <code>PassengerFriendlyErrorPages</code> in der <code>.htaccess</code>-Datei gesetzt werden. Das führt zu einem 500er Fehler.

Falls ein Virtual Environment benutzt wird, sollte folgender Eintrag in der <code>.htaccess</code> Datei gesetzt werden:

SetEnv PYTHONPATH /home/pacs/xyz00/users/example/meinprojekt

Desweiteren sollte der Pfad zum Python-Binärprogramm in den Eigenschaften der Domain in HSAdmin konfiguriert werden, unter PassengerPython: z.B. <code>/home/pacs/xyz00/users/example/.pyenv/versions/3.9.18/bin/python3</code>, oder bei einem Virtual Environment: <code>/home/pacs/xyz00/users/example/meinprojekt/.venv/bin/python3</code>

(Versionsnummer, User und Paket im Pfad anpassen)

== Anpassungen an PHP Anwendungen ==

{{Textkasten|gelb|Achtung|Unter Debian 12 ("Bookworm") ist PHP 8.2 die Default Version. PHP 7.4 bleibt installiert. 
Auf Anfrage stellen wir auch PHP 8.0 und PHP 8.1 zur Verfügung.}}

In der .htaccess Datei müssen die Zeilen mit AddType und Action für PHP entfernt werden:

nano doms/meinedomain.de/.htaccess
# diese Zeilen entfernen:
AddType application/x-httpd-php81 .php
Action application/x-httpd-php81 /fastcgi-bin/phpstub81

Wenn bisher nur der voreingestellte phpstub verwendet wurde, lief die Seite bisher auf PHP 7.4. Nun würde sie auf PHP 8.2 laufen. Falls die Anwendung das nicht unterstützt, muss für die Domain in HSAdmin die gewünschte PHP Version in der Liste bei "FastCGI PHP-Interpreter" gewählt werden.

== Anpassungen an Ruby Anwendungen ==

Die meisten Ruby Anwendungen werden mit rbenv betrieben. Dieses funktioniert dann nicht mehr, wegen Inkompatibilitäten mit der openssl Bibliothek.

Daher muss die rbenv Umgebung neu installiert werden. siehe [[RubyRBEnv]]

Es müssen auch meistens die Ruby Gems neu installiert werden.

# erst löschen
rm -Rf ~/.gem/
rm -Rf ~/.bundle
rm -Rf ~/.local/state/gem/

# dann installieren
cd meineapp # z.B. zammad
export RAILS_ENV="production"
bundle install

Falls '''Passenger''' zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert. Die Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen, und müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Ruby Version verwendet werden soll.
Es kann entweder die vorinstallierte Ruby Version verwendet werden, oder eine Ruby Version unter dem Pfad z.B. <code>/home/pacs/xyz00/users/example/.rbenv/shims/ruby</code>.

== Anpassungen an Node.js Anwendungen ==
Es muss das Verzeichns <code>.nvm</code> im Home Verzeichnis gelöscht werden, und <code>node_modules</code> im Projekt.

Dann Node wieder neu installieren, siehe [[NodeJS]].

Dann <code>yarn install</code> bzw andere Befehle ausführen, um die Node Module wieder zu installieren.

Falls '''Passenger''' zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert. Die Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen, und müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Node Version verwendet werden soll.
Es kann entweder die vorinstallierte Node Version verwendet werden, oder eine Node Version unter dem Pfad z.B. <code>/home/pacs/xyz00/users/example/.nvm/versions/node/v20.11.0/bin/node</code>.

== Anpassungen an Java Anwendungen ==
=== Eigenes Java JDK installieren ===
Auf Debian Buster lief lief Java 11. Auf Debian Bookworm steht Java 17 zur Verfügung.

Für Anwendungen, die weiterhin Java 11 benötigen, kann es pro User oder pro Paket installiert werden.

Ältere JDKs können hier als Binary für Linux/x64 heruntergeladen werden: https://jdk.java.net/archive/

Ein Beispiel für JDK 11:

mkdir ~/bin
cd bin
wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz
tar xzf openjdk-11.0.2_linux-x64_bin.tar.gz

Eine weitere zuverlässige Quelle für eine freie Distribution des OpenJDK ist die Eclipse Foundation: https://adoptium.net/de/

Dann muss z.B. im Tomcat (z.B. bin/setenv.sh) oder in der systemd Service Datei die Variable JAVA_HOME gesetzt werden:

JAVA_HOME=/home/pacs/xyz00/users/meinuser/bin/jdk-11

=== Eigenen Tomcat installieren ===

Bei Debian Buster lief Tomcat 9, auf Debian Bookworm steht Tomcat 10 zur Verfügung. Die beiden Versionen sind nicht kompatibel. Tomcat 9 implementiert Java EE 8; bei Tomcat 10 ist es Jakarta EE 9. Aus lizenzrechtlichen Gründen wurden alle Java-Packages aus den Java-EE-Spezifikationen von <code>javax.</code> nach <code>jakarta.</code> umbenannt.

Für eigene Anwendungen empfehlen wir, die Software entsprechend anzupassen und neu zu kompilieren. Für Software aus anderen Quellen kann das Tool <code>javax2jakarta</code> diesen Schritt in der Regel leisten.

Wenn die Migration nicht möglich oder nicht gewünscht ist, kann leicht ein vollständiger Tomcat 9 pro User installiert werden.

Ältere Versionen von Tomcat sind hier zu finden: https://tomcat.apache.org/download-90.cgi

mv tomcat tomcat.bak
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.84/bin/apache-tomcat-9.0.84.tar.gz
mv apache-tomcat-9.0.84 tomcat
cp tomcat.bak/conf/server.xml tomcat/conf/
cp tomcat.bak/conf/setenv.sh tomcat/conf/
cp -R tomcat.bak/webapps tomcat

Darauf achten, ob noch weitere Konfigurationsdateien kopiert werden müssen, und Anpassungen an der context.xml und web.xml übernommen werden müssen.

== Anpassungen an Redis Diensten ==

Falls ein Redis Dienst läuft, bitte kontrollieren, ob er noch richtig funktioniert.

Gegebenenfalls müssen in der Datei <code>redis.conf</code> die relativen Pfade zu absoluten Pfaden geändert werden, wenn die nicht schon bereits absolute Pfade sind (z.B. <code>logfile</code>, <code>unixsocket</code>, <code>dir</code>)

== Aktualisierung von MongoDB ==

MongoDB wird bei uns nicht vom Betriebssystem bereitgestellt.

Falls MongoDB verwendet wird, müssen neue Binaries heruntergeladen werden. Dabei ist die Version für Ubuntu 22.04 zu verwenden, da es keine Version für Debian 12 (Bookworm) gibt: siehe https://www.mongodb.com/try/download/community

Anpassungen von Anwendungen nach Debian Bookworm Upgrade

2024-01-30T08:58:08Z

Hsh-janulrichhasecke: Sprachliche Überarbeitung

== Wer ist für was verantwortlich? ==

Die Hostmaster aktualisieren das Betriebssytem.

Die Mitglieder sind für den Betrieb der eigenen Anwendungen im Userspace verantwortlich. Da dazu keine besonderen Rechte erforderlich sind, können die notwendigen Anpassungen vom technisch versierten Mitglied selbst vorgenommen werden.

Wenn das Mitglied die Anpassungen nicht selbst vornehmen kann oder will, kann ein [https://www.hostsharing.net/service/webmaster-on-demand/ Webmaster On Demand (WoD)] Auftrag erteilt werden, damit ein Hostmaster eine Anwendung wieder zum Laufen bringt. Schreibt bitte einfach eine E-Mail an service@ und nennt die Anwendung, um die es geht, und in welchem Benutzer die Anwendung läuft.

Auf dieser Seite teilen wir Anleitungen, wie man die eigene Anwendung selbst wieder zum Laufen bringt.

== Anpassungen an Python Anwendungen ==

{{Textkasten|gelb|Achtung|Python 2.7 steht unter Debian 12 ("Bookworm") nicht mehr zur Verfügung!}}

Nach dem Upgrade müssen die meisten Python Anwendungen angepasst werden.

Dann muss das Virtual Environment gelöscht und neu angelegt werden, am besten mit der Standard Python Version von Debian, bei Bookworm ist das Python 3.11

Falls die Anwendung noch nicht mit Python 3.11 zurecht kommt, kann mit pyenv auch eine ältere Python Version, z.B. 3.10 installiert werden: [[Eigenes_Python_installieren#Installation_mit_pyenv]]

Falls bereits mit pyenv eine andere Python Version installiert worden war, sollte diese gelöscht und nochmals installiert werden. Evtl. ist das aber auch nicht mehr nötig, und es kann mit der Version Python 3.11 vom Betriebssystem gearbeitet werden.

Es sollte in der .profile oder .bash_profile diese Variable gesetzt werden:

export PYTHONIOENCODING=utf-8

=== Änderungen beim Einsatz von Passenger und Python ===
Falls Passenger zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert: Es können nicht mehr <code>PassengerPython</code> oder <code>PassengerFriendlyErrorPages</code> in der <code>.htaccess</code> Datei gesetzt werden. Das führt zu einem 500er Fehler.

Falls ein Virtual Environment benutzt wird, sollte folgender Eintrag in der <code>.htaccess</code> Datei gesetzt werden:

SetEnv PYTHONPATH /home/pacs/xyz00/users/example/meinprojekt

Desweiteren sollte der Pfad zum Python-Binärprogramm in den Eigenschaften der Domain in HSAdmin konfiguriert werden, unter PassengerPython: z.B. <code>/home/pacs/xyz00/users/example/.pyenv/versions/3.9.18/bin/python3</code>, oder bei einem Virtual Environment: <code>/home/pacs/xyz00/users/example/meinprojekt/.venv/bin/python3</code>

(Versionsnummer, User und Paket im Pfad anpassen)

== Anpassungen an PHP Anwendungen ==

{{Textkasten|gelb|Achtung|Unter Debian 12 ("Bookworm") ist PHP 8.2 die Default Version. PHP 7.4 bleibt installiert. 
Auf Anfrage stellen wir auch PHP 8.0 und PHP 8.1 zur Verfügung.}}

In der .htaccess Datei müssen die Zeilen mit AddType und Action für PHP entfernt werden:

nano doms/meinedomain.de/.htaccess
# diese Zeilen entfernen:
AddType application/x-httpd-php81 .php
Action application/x-httpd-php81 /fastcgi-bin/phpstub81

Wenn bisher nur der voreingestellte phpstub verwendet wurde, lief die Seite bisher auf PHP 7.4. Nun würde sie auf PHP 8.2 laufen. Falls die Anwendung das nicht unterstützt, muss für die Domain in HSAdmin die gewünschte PHP Version in der Liste bei "FastCGI PHP-Interpreter" gewählt werden.

== Anpassungen an Ruby Anwendungen ==

Die meisten Ruby Anwendungen werden mit rbenv betrieben. Dieses funktioniert dann nicht mehr, wegen Inkompatibilitäten mit der openssl Bibliothek.

Daher muss die rbenv Umgebung neu installiert werden. siehe [[RubyRBEnv]]

Es müssen auch meistens die Ruby Gems neu installiert werden.

# erst löschen
rm -Rf ~/.gem/
rm -Rf ~/.bundle
rm -Rf ~/.local/state/gem/

# dann installieren
cd meineapp # z.B. zammad
export RAILS_ENV="production"
bundle install

Falls '''Passenger''' zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert. Die Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen, und müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Ruby Version verwendet werden soll.
Es kann entweder die vorinstallierte Ruby Version verwendet werden, oder eine Ruby Version unter dem Pfad z.B. <code>/home/pacs/xyz00/users/example/.rbenv/shims/ruby</code>.

== Anpassungen an Node.js Anwendungen ==
Es muss das Verzeichns <code>.nvm</code> im Home Verzeichnis gelöscht werden, und <code>node_modules</code> im Projekt.

Dann Node wieder neu installieren, siehe [[NodeJS]].

Dann <code>yarn install</code> bzw andere Befehle ausführen, um die Node Module wieder zu installieren.

Falls '''Passenger''' zum Einsatz kommt, da hat sich das Verhalten von Passenger geändert. Die Einträge mit Passenger dürfen nicht mehr in <code>doms/meinedomain.de/.htaccess</code> stehen, und müssen dort auskommentiert werden.

In HSAdmin kann im Dialog "Domain ändern" eingestellt werden, welche Node Version verwendet werden soll.
Es kann entweder die vorinstallierte Node Version verwendet werden, oder eine Node Version unter dem Pfad z.B. <code>/home/pacs/xyz00/users/example/.nvm/versions/node/v20.11.0/bin/node</code>.

== Anpassungen an Java Anwendungen ==
=== Eigenes Java JDK installieren ===
Auf Debian Buster lief lief Java 11. Auf Debian Bookworm steht Java 17 zur Verfügung.

Für Anwendungen, die weiterhin Java 11 benötigen, kann es pro User oder pro Paket installiert werden.

Ältere JDKs können hier als Binary für Linux/x64 heruntergeladen werden: https://jdk.java.net/archive/

Ein Beispiel für JDK 11:

mkdir ~/bin
cd bin
wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz
tar xzf openjdk-11.0.2_linux-x64_bin.tar.gz

Eine weitere zuverlässige Quelle für eine freie Distribution des OpenJDK ist die Eclipse Foundation: https://adoptium.net/de/

Dann muss z.B. im Tomcat (z.B. bin/setenv.sh) oder in der systemd Service Datei die Variable JAVA_HOME gesetzt werden:

JAVA_HOME=/home/pacs/xyz00/users/meinuser/bin/jdk-11

=== Eigenen Tomcat installieren ===

Bei Debian Buster lief Tomcat 9, auf Debian Bookworm steht Tomcat 10 zur Verfügung. Die beiden Versionen sind nicht kompatibel. Tomcat 9 implementiert Java EE 8; bei Tomcat 10 ist es Jakarta EE 9. Aus lizenzrechtlichen Gründen wurden alle Java-Packages aus den Java-EE-Spezifikationen von <code>javax.</code> nach <code>jakarta.</code> umbenannt.

Für eigene Anwendungen empfehlen wir, die Software entsprechend anzupassen und neu zu kompilieren. Für Software aus anderen Quellen kann das Tool <code>javax2jakarta</code> diesen Schritt in der Regel leisten.

Wenn die Migration nicht möglich oder nicht gewünscht ist, kann leicht ein vollständiger Tomcat 9 pro User installiert werden.

Ältere Versionen von Tomcat sind hier zu finden: https://tomcat.apache.org/download-90.cgi

mv tomcat tomcat.bak
wget https://dlcdn.apache.org/tomcat/tomcat-9/v9.0.84/bin/apache-tomcat-9.0.84.tar.gz
mv apache-tomcat-9.0.84 tomcat
cp tomcat.bak/conf/server.xml tomcat/conf/
cp tomcat.bak/conf/setenv.sh tomcat/conf/
cp -R tomcat.bak/webapps tomcat

Darauf achten, ob noch weitere Konfigurationsdateien kopiert werden müssen, und Anpassungen an der context.xml und web.xml übernommen werden müssen.

== Anpassungen an Redis Diensten ==

Falls ein Redis Dienst läuft, bitte kontrollieren, ob er noch richtig funktioniert.

Gegebenenfalls müssen in der Datei <code>redis.conf</code> die relativen Pfade zu absoluten Pfaden geändert werden, wenn die nicht schon bereits absolute Pfade sind (z.B. <code>logfile</code>, <code>unixsocket</code>, <code>dir</code>)

== Aktualisierung von MongoDB ==

MongoDB wird bei uns nicht vom Betriebssystem bereitgestellt.

Falls MongoDB verwendet wird, müssen neue Binaries heruntergeladen werden. Dabei ist die Version für Ubuntu 22.04 zu verwenden, da es keine Version für Debian 12 (Bookworm) gibt: siehe https://www.mongodb.com/try/download/community

Hauptseite

2023-09-06T08:41:11Z

Hsh-janulrichhasecke:

{{HSDoku-Links}} __NOTOC__

== Willkommen im Hostsharing-Wiki! ==
... der '''inoffiziellen''' Dokumentation der Mitglieder von Hostsharing. Die wichtigsten Themen findest du in der Leiste oben. Alle Themen und Seiten des Wiki erreichst du am besten über die Kategorie [[:Kategorie:HSDoku|HSDoku]].

Die '''offizielle Kerndokumentation''' ist hier:
https://www.hostsharing.net/doc/

Allgemeine Fragen zum Umgang mit den HS Diensten und Angeboten beantwortet die HS Community in der '''[https://lists.hostsharing.net/mailman/listinfo/support Support Mailingliste]''' mit der Mailadresse [mailto:support@hostsharing.net support@hostsharing.net].

Fragen, die vertrauliche Themen behandeln (Domainnamen, Benutzernamen, Passwörter etc.) sollten direkt an den [[HS-Service]] gehen, der ansonsten kostenpflichtig ist. Ergänzende Hinweise finden sich in den [https://lists.hostsharing.net/archiv/global-announce/ Global Announces] der Hostmaster und des Vorstandes zu aktuellen Geschehnissen und technischen Änderungen bei Hostsharing.

Du kannst dich mit deinen HS Userdaten einloggen und mithelfen, die Dokumentation zu verbessern. In unserem [[Autorenportal]] findest du Hinweise dazu, wie du dich beteiligen kannst. Was hier ins Wiki gehört, und wie es gemacht wird, ist unter [[Hilfe:Hostsharing_Wiki_Konventionen|Konventionen]] erklärt.

Zum Testen und Rumspielen ist der [[Sandkasten]] da. Und nun viel Freude im Hostsharing Wiki :-)

== Hostsharing Benefits ==

Hostsharing.net ist die professionelle Alternative zur Administration eigener Root Server mit dem Bonus der Redundanz und des gemeinschaftlich organisierten Betriebes.

[[Green Web Foundation | Ökostrom: Hostsharing ist gelistet bei der Green Web Foundation]]

[[10 Missverständnisse über dedizierte root-Server | Rootserver Missverständnisse]] 
[[Rootserver Checkliste]]

==Mastodon-Instanz für Mitglieder==
[[Einrichtung und Benutzung von Mastodon-Accounts auf https://hostsharing.coop]] 
[[Einrichtung des Crossposting Bots]] 

----
[[Kategorie:Hostsharing Wiki]]
[[Kategorie:HSDoku]]

Hauptseite

2023-09-06T08:40:34Z

Hsh-janulrichhasecke: Neue URL

{{HSDoku-Links}} __NOTOC__

== Willkommen im Hostsharing-Wiki! ==
... der '''inoffiziellen''' Dokumentation der Mitglieder von Hostsharing. Die wichtigsten Themen findest du in der Leiste oben. Alle Themen und Seiten des Wiki erreichst du am besten über die Kategorie [[:Kategorie:HSDoku|HSDoku]].

Die '''offizielle Kerndokumentation''' ist hier:
https://www.hostsharing.net/doc

Allgemeine Fragen zum Umgang mit den HS Diensten und Angeboten beantwortet die HS Community in der '''[https://lists.hostsharing.net/mailman/listinfo/support Support Mailingliste]''' mit der Mailadresse [mailto:support@hostsharing.net support@hostsharing.net].

Fragen, die vertrauliche Themen behandeln (Domainnamen, Benutzernamen, Passwörter etc.) sollten direkt an den [[HS-Service]] gehen, der ansonsten kostenpflichtig ist. Ergänzende Hinweise finden sich in den [https://lists.hostsharing.net/archiv/global-announce/ Global Announces] der Hostmaster und des Vorstandes zu aktuellen Geschehnissen und technischen Änderungen bei Hostsharing.

Du kannst dich mit deinen HS Userdaten einloggen und mithelfen, die Dokumentation zu verbessern. In unserem [[Autorenportal]] findest du Hinweise dazu, wie du dich beteiligen kannst. Was hier ins Wiki gehört, und wie es gemacht wird, ist unter [[Hilfe:Hostsharing_Wiki_Konventionen|Konventionen]] erklärt.

Zum Testen und Rumspielen ist der [[Sandkasten]] da. Und nun viel Freude im Hostsharing Wiki :-)

== Hostsharing Benefits ==

Hostsharing.net ist die professionelle Alternative zur Administration eigener Root Server mit dem Bonus der Redundanz und des gemeinschaftlich organisierten Betriebes.

[[Green Web Foundation | Ökostrom: Hostsharing ist gelistet bei der Green Web Foundation]]

[[10 Missverständnisse über dedizierte root-Server | Rootserver Missverständnisse]] 
[[Rootserver Checkliste]]

==Mastodon-Instanz für Mitglieder==
[[Einrichtung und Benutzung von Mastodon-Accounts auf https://hostsharing.coop]] 
[[Einrichtung des Crossposting Bots]] 

----
[[Kategorie:Hostsharing Wiki]]
[[Kategorie:HSDoku]]

E-Mail

2022-08-09T15:53:35Z

Hsh-janulrichhasecke: link

{{HSDoku-Links}}

{{Baustelle}}

{{Kerndoku|https://doc.hostsharing.net/#kap-emails-lesen}}

Die (auch das) '''E-Mail''' (kurz ''Mail'', von englisch ''electronic mail'': „elektronische Post“ oder „elektronischer Brief“), manchmal als '''E-Post''' oder '''E-Brief''' bezeichnet, ist eine auf elektronischem Weg in [[Rechnernetz|Computernetzwerken]] übertragene [[Nachricht]].

E-Mail wird – noch vor dem [[World Wide Web]] – als wichtigster und meistgenutzter Dienst des [[Internet]]s angesehen.

== Weitergehende Konfigurationsmöglichkeiten ==

* Es können [[Mailinglisten]] eingerichtet werden.

* IMAP Konten lassen sich mit [[ImapCopy]] zu HS kopieren.

== E-Mail-Infrastruktur ==

Wir nutzen [http://www.postfix.org/ Postfix] als [[Mail Transfer Agent]](MTA) bzw. Mailserver. Diese Software dient dazu, eingehende Mails den lokalen Usern des Servers zuzuordnen, an interne oder externe Server zuzustellen.

E-Mails werden vom Mailsystem im Verzeichnis Maildir des jeweiligen User-Accounts abgelegt (der Name ist systemweit eingestellt und kann nicht verändert werden).

Damit sind die Mails im normalen Backup enthalten und gehen auch in die Quota des Paketes ein. Das Verzeichnis wird automatisch angelegt, wenn die erste E-Mail dort abgelegt wird.

Ist das Verzeichnis Maildir nicht angelegt, liefern E-Mail-Clients oder Webmail-Clients aufgrund des fehlenden Verzeichnisses eine Fehlermeldung.
Dies kann verhindert werden, indem auf der Shell in dem entsprechenden User-Account folgender Befehl ausführt wird:

<pre> maildirmake Maildir</pre>

== Adressierung und Weiterleitungen ==

Hostsharing unterscheidet zwischen E-Mail-Adresse und Mailbox.

Eine E-Mail-Adresse gibt an, wie eine eingehende Nachricht auszuliefern ist.

Eine Mailbox ist ein Ort, wo erhaltene E-Mails lagern, bis ein User sie lesen will,
typischerweise indem er mittels seiner Client-Software die Mails mit IMAP oder POP3
abholt und anzeigt.

In Hostsharing hat jeder User, ob Paketadmin oder Paketuser, eine Mailbox. E-Mail-Adressen
können unabhängig von tatsächlichen Usern eingerichtet werden.

=== E-Mail-Adressen ===

Eine E-Mail-Adresse ist in Hostsharing eine
Kennung der üblichen Form <code>userimbreitestensinn@domain</code>,
zusammen mit einer Zielangabe, das heißt, mit der Angabe, wohin eine mit dieser
Kennung adressierten E-Mail geliefert
werden soll. Bei Einrichtung einer E-Mail-Adresse in Hostsharing kann ein Ziel eine Mailbox
sein, oder aber eine andere E-Mail-Adresse (mit einer beliebigen Domain, ob bei Hostsharing
gehostet oder extern). Eine E-Mail-Adresse kann mehrere Ziele haben: dann wird die
eingehende Mail zur Auslieferung vervielfacht.

Es werden n:m-Verknüpfungen zwischen E-Mail-Adressen und Mailboxen ermöglicht. Das heißt,
mehrere E-Mail-Adressen können dieselbe Mailbox als Ziel haben, und eine E-Mail-Adresse
kann mehrere Mailboxen als Ziele haben.

=== E-Mail-Aliases ===

Ein E-Mail-Alias ist, ähnlich wie eine E-Mail-Adresse, mit einer Angabe verbunden, wie
mit einer entsprechend adressierten E-Mail bei Eingang zu verfahren ist. Ein E-Mail-Alias
in Hostsharing ist nicht an eine bestimmte Domain gebunden, wohl aber an ein bestimmtes
Paket. Daher beginnen alle Aliase mit einem Pakennamen (plus Bindestrich) in der Form xyz00-... (Damit kann ein Alias gleichlautend mit der Mailbox eines Paketusers sein: in diesem Fall hat der Alias
Vorrang; eine so geleitete Mail wird nicht in die Mailbox geliefert, sondern entsprechend dem zum Alias gehörenden Ziel.)

Das Ziel eines E-Mail-Alias ist
allerdings flexibler als das Ziel einer E-Mail-Adresse, und erlaubt beispielsweise, eingehende
Mails durch Programme verarbeiten zu lassen. Damit kann man unter anderem Mailverteiler flexibel definieren.

Insgesamt kann man damit komplex E-Mail-Setups konfigurieren. E-Mail-Aliases werden deshalb als
Werkzeug für Administratoren angeboten; der Endverbraucher wird in der Regel keine Aliases benötigen.

=== Formal ===

==== E-Mail-Adresse ====
:Form = <code>localpart@domainpart</code> 
:Beispiel = username@example.com 
:Ziel = Liste von (mehreren):
:* E-Mail-Adresse (intern oder extern)
:* E-Mail-Alias
:* Mailbox

==== E-Mail-Alias ====
:Form = <code>xyz00-aliasname</code> 
:Ziel = Liste von (mehreren):
:* E-Mail-Adresse (intern oder extern)
:* E-Mail-Alias
:* Mailbox
:* spezielle Funktion (Pipe, dateibasierter Verteiler, ...)

==== Mailbox ====
:Form = <code>xyz00</code> 
:Form = <code>xyz00-username</code> 
:*kann per [[POP3]] und/oder [[IMAP]] abgerufen werden
:*kann per [[Sieve]] gefiltert werden
:*kann durch .forward-Datei(en) umgelenkt werden

=== Bemerkungen ===

Wenn E-Mail-Alias gleich wie eine Mailbox-Bezeichnung lautet,
hat der Alias Vorrang. Um ankommende E-Mails dennoch in die Mailbox liefern zu lassen,
kann als Ziel eines Aliases die Mailbox-Bezeichnung mit vorangestelltem Backslash
angegeben werden (z. B. "\xyz00-username").

=== Outlook 2016, Outlook 2019, Outlook für Office 365 ===

Outlook 2016, Outlook 2019, Outlook für Office 365 erfordern folgenden Registry-Patch:

<pre>
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Setup]
"DisableOffice365SimplifiedAccountCreation"=dword:00000001
</pre>

Der "DisableOffice365SimplifiedAccountCreation"-Patch reaktiviert die Dialoge zur Einrichtung von E-Mail-Konten früherer Outlook-Versionen. Diese Dialoge erlauben u.a. die manuelle Konfiguration der E-Mail-Konten. Implizit sorgt dieser Patch auch dafür, dass jüngere Outlook-Versionen, die über klassisches Autodiscover (XML-basiert) bereitgestellten Konfigurationsoptionen korrekt verarbeitet. In unseren Tests zeigte sich, dass jüngere Outlook-Versionen ohne diesen Patch nicht alle per Autodiscover bereitgestellten Informationen zur Anwendung bringen. Das neue Protokoll Autodiscover V2 (JSON-basiert) bietet - nach unserem Kenntnisstand - hingegen keine Möglichkeit, Konfigurationen für die Zugriffsprotokolle POP3, IMAP und SMTP zu übermitteln.

== Weiterführende Links ==

[[HS-Mailrouting]]

----
[[Kategorie:HSDoku]]
[[Kategorie:E-Mail]]
[[Kategorie:Glossar]]

User

2022-08-09T15:51:50Z

Hsh-janulrichhasecke: /* Passwort ändern auf der HSAdmin Webseite */

{{HSDoku-Links}}

{{Kerndoku|https://doc.hostsharing.net}}

== Passwort ändern auf der HSAdmin Webseite ==

Siehe die Anleitung in der technischen Dokumentation: [https://doc.hostsharing.net/#kap-erstes-einloggen Änderung des Passworts]

== Passwort ändern mit dem Programm passwd ==

Das Passwort eines Users wird nicht in der hsadmin-Datenbank gespeichert, sondern in der Konfiguration des jeweiligen [[Hive]], auf dem das zugehörige [[Paket]] liegt. Daher kann es ''auch'' mit dem gängigen [[Shell]]-Befehl '''passwd''' geändert werden.

<pre><nowiki>
xyz00@hopi:~$ passwd

Changing password for mi
(current) UNIX password: ALTESPASSWORT
Enter new UNIX password: NEUESPASSWORT
Retype new UNIX password: NEUESPASSWORT
passwd: password updated successfully

xyz00@hopi:~$ █
</nowiki></pre>

Die Platzhalter NEUESPASSWORT und ALTESPASSWORT müssen dabei selbstverständlich gegen die entsprechenden Passworte ausgetauscht werden. Dabei sollte jedes Passwort mindestens 6 Zeichen lang sein, besser 8 Zeichen, und aus Buchstaben, Ziffern und ggf. Sonderzeichen bestehen. Auf Umlaute sollte verzichtet werden, da die Verwendung nicht mit allen Zugangswegen kompatibel ist.

Ggf. kommt es zu Fehlermeldungen, z.B. wenn das neue Passwort zu simpel ist, oder bei der Wiederholung nicht identisch mit dem ersten Passwort ist. In dem Fall, den Vorgang einfach wiederholen. Solange das neue Passwort nicht erfolgreich übernommen wurde, bleibt das alte gültig.

Es gibt User, denen der Paket-Admin nur das Recht eingeräumt hat, das eigene Passwort zu ändern, indem er ihnen die "Shell" /usr/bin/passwd zugewiesen hat. Diese User können durch einen Shell-Login nur ihr Passwort ändern, da das Programm passwd an Stelle einer Shell gestartet wird. Sie werden nach dem Einloggen automatisch auf diesen Dialog geführt.

== Identitätswechsel ==

Der Paketadmin kann mit
sudo -u xyz00-user -i
die Rechte eines seiner Paketuser annehmen, ohne dessen Passwort kennen zu müssen. Für Paketuser, die als initiale Shell nur /bin/passwd eingetragen haben, ist
sudo -u xyz00-user -s
zu verwenden, um in eine reguläre Shell zu kommen. Mit
"su xyz00-user"
ist auch regulären Benutzern ein Identitätswechel (z.B. zum Paketadmin) möglich, wenn sie das aktuelle Passwort des Zielaccounts kennen.

----
[[Kategorie:HSDoku]]
[[Kategorie:User]]
[[Kategorie:Hsadmin]]
[[Kategorie:Glossar]]
[[Kategorie:Einstieg bei Hostsharing]]

User

2022-08-09T15:50:53Z

Hsh-janulrichhasecke:

{{HSDoku-Links}}

{{Kerndoku|https://doc.hostsharing.net}}

== Passwort ändern auf der HSAdmin Webseite ==

Siehe die Anleitung in der technischen Dokumentation: [https://doc.hostsharing.net/einstieg/passwort.html#anderung-des-passworts Änderung des Passworts]

== Passwort ändern mit dem Programm passwd ==

Das Passwort eines Users wird nicht in der hsadmin-Datenbank gespeichert, sondern in der Konfiguration des jeweiligen [[Hive]], auf dem das zugehörige [[Paket]] liegt. Daher kann es ''auch'' mit dem gängigen [[Shell]]-Befehl '''passwd''' geändert werden.

<pre><nowiki>
xyz00@hopi:~$ passwd

Changing password for mi
(current) UNIX password: ALTESPASSWORT
Enter new UNIX password: NEUESPASSWORT
Retype new UNIX password: NEUESPASSWORT
passwd: password updated successfully

xyz00@hopi:~$ █
</nowiki></pre>

Die Platzhalter NEUESPASSWORT und ALTESPASSWORT müssen dabei selbstverständlich gegen die entsprechenden Passworte ausgetauscht werden. Dabei sollte jedes Passwort mindestens 6 Zeichen lang sein, besser 8 Zeichen, und aus Buchstaben, Ziffern und ggf. Sonderzeichen bestehen. Auf Umlaute sollte verzichtet werden, da die Verwendung nicht mit allen Zugangswegen kompatibel ist.

Ggf. kommt es zu Fehlermeldungen, z.B. wenn das neue Passwort zu simpel ist, oder bei der Wiederholung nicht identisch mit dem ersten Passwort ist. In dem Fall, den Vorgang einfach wiederholen. Solange das neue Passwort nicht erfolgreich übernommen wurde, bleibt das alte gültig.

Es gibt User, denen der Paket-Admin nur das Recht eingeräumt hat, das eigene Passwort zu ändern, indem er ihnen die "Shell" /usr/bin/passwd zugewiesen hat. Diese User können durch einen Shell-Login nur ihr Passwort ändern, da das Programm passwd an Stelle einer Shell gestartet wird. Sie werden nach dem Einloggen automatisch auf diesen Dialog geführt.

== Identitätswechsel ==

Der Paketadmin kann mit
sudo -u xyz00-user -i
die Rechte eines seiner Paketuser annehmen, ohne dessen Passwort kennen zu müssen. Für Paketuser, die als initiale Shell nur /bin/passwd eingetragen haben, ist
sudo -u xyz00-user -s
zu verwenden, um in eine reguläre Shell zu kommen. Mit
"su xyz00-user"
ist auch regulären Benutzern ein Identitätswechel (z.B. zum Paketadmin) möglich, wenn sie das aktuelle Passwort des Zielaccounts kennen.

----
[[Kategorie:HSDoku]]
[[Kategorie:User]]
[[Kategorie:Hsadmin]]
[[Kategorie:Glossar]]
[[Kategorie:Einstieg bei Hostsharing]]

Hsadmin

2022-08-09T15:37:27Z

Hsh-janulrichhasecke: link

{{Kerndoku|https://doc.hostsharing.net/#kap-hsadmin-einstieg}}

Am 25. Juli 2016 wurde eine neue Web-Oberfläche in Betrieb genommen.

Eine Einführung in die Bedienung findet Ihr auf der Seite [[HsadminWeb]]

---
[[Kategorie:Glossar]]

Einstieg bei Hostsharing

2022-08-09T15:35:26Z

Hsh-janulrichhasecke: /* Weiterführende Verweise */

{{HSDoku-Links}}

Hostsharing ist anders, das merkt jeder sehr schnell. Nicht nur, weil es sich um eine Genossenschaft mit Mitbestimmung, demokratischen Strukturen und vielen engagierten und hilfsbereiten Mitgliedern handelt. Dieses "Anders-Sein" fällt auch schnell bei der Administration der Hostsharing Pakete auf, die einem jede Menge Freiheit bietet. Die grundsätzliche Konfiguration erfolgt mit [https://doc.hostsharing.net/#kap-hsadmin-einstieg hsadmin], einem Interface, das (unter anderem) die Konfiguration der eigenen Pakete mit dem Browser erlaubt.

Doch wir können schon gleich zu Anfang beruhigen: bisher hat jeder die Administration seines Pakets binnen kürzester Zeit gemeistert und schnell gemerkt, welche Flexiblität man dadurch gewinnt. So kann die Administration auch automatisch aus eigenen Web-Anwendungen erfolgen, oder man kann die vielen kleinen UNIX-Tools verwenden, um seine Konfiguration automatisch zu bearbeiten, was ansonsten viele hunderte fehleranfällige Mausklicks bedeuten würde.

Diese Seiten werden helfen, die ersten Schritte bei der Einrichtung eines Hostsharing-Paketes zu gehen. Sie wenden sich an User mit geringer Erfahrung.

Viel Spaß.

== Weiterführende Verweise ==

; Die ersten Schritte zur eigenen Website
#: [[Dein erster Login]] dient zum Einrichten und Test der Verbindung und ändern des Passworts

; ohne vorgegebene Reihenfolge

:[[Login mit SSH]]
:[[Verzeichnis-Struktur]]
:[[Die wichtigsten Unix-Kommandos]]
:[[Editoren für Einsteiger]]
:[[User | User bearbeiten]]
:[https://doc.hostsharing.net/#domain-benutzer-anlegen Domains]
:[[E-Mail-Adressen]]
:[[Dateien per FTP hochladen]]
:[[Überwachung der HS-Dienste]]
:[https://doc.hostsharing.net/#managed-operations-platform Die Technik bei Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Einstieg bei Hostsharing]]

Einstieg bei Hostsharing

2022-08-09T15:33:32Z

Hsh-janulrichhasecke: link

{{HSDoku-Links}}

Hostsharing ist anders, das merkt jeder sehr schnell. Nicht nur, weil es sich um eine Genossenschaft mit Mitbestimmung, demokratischen Strukturen und vielen engagierten und hilfsbereiten Mitgliedern handelt. Dieses "Anders-Sein" fällt auch schnell bei der Administration der Hostsharing Pakete auf, die einem jede Menge Freiheit bietet. Die grundsätzliche Konfiguration erfolgt mit [https://doc.hostsharing.net/#kap-hsadmin-einstieg hsadmin], einem Interface, das (unter anderem) die Konfiguration der eigenen Pakete mit dem Browser erlaubt.

Doch wir können schon gleich zu Anfang beruhigen: bisher hat jeder die Administration seines Pakets binnen kürzester Zeit gemeistert und schnell gemerkt, welche Flexiblität man dadurch gewinnt. So kann die Administration auch automatisch aus eigenen Web-Anwendungen erfolgen, oder man kann die vielen kleinen UNIX-Tools verwenden, um seine Konfiguration automatisch zu bearbeiten, was ansonsten viele hunderte fehleranfällige Mausklicks bedeuten würde.

Diese Seiten werden helfen, die ersten Schritte bei der Einrichtung eines Hostsharing-Paketes zu gehen. Sie wenden sich an User mit geringer Erfahrung.

Viel Spaß.

== Weiterführende Verweise ==

; Die ersten Schritte zur eigenen Website
#: [[Dein erster Login]] dient zum Einrichten und Test der Verbindung und ändern des Passworts

; ohne vorgegebene Reihenfolge

:[[Login mit SSH]]
:[[Verzeichnis-Struktur]]
:[[Die wichtigsten Unix-Kommandos]]
:[[Editoren für Einsteiger]]
:[[User | User bearbeiten]]
:[https://doc.hostsharing.net/users/administration/domain/index.html Domains]
:[[E-Mail-Adressen]]
:[[Dateien per FTP hochladen]]
:[[Überwachung der HS-Dienste]]
:[https://doc.hostsharing.net/users/sicherheit/index.html Die Technik bei Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Einstieg bei Hostsharing]]

Hauptseite

2022-08-09T15:31:16Z

Hsh-janulrichhasecke: /* Willkommen im Hostsharing-Wiki! */

{{HSDoku-Links}} __NOTOC__

== Willkommen im Hostsharing-Wiki! ==
... der '''inoffiziellen''' Dokumentation der Mitglieder von Hostsharing. Die wichtigsten Themen findest du in der Leiste oben. Alle Themen und Seiten des Wiki erreichst du am besten über die Kategorie [[:Kategorie:HSDoku|HSDoku]].

Die '''offizielle Kerndokumentation''' ist hier:
https://doc.hostsharing.net

Allgemeine Fragen zum Umgang mit den HS Diensten und Angeboten beantwortet die HS Community in der '''[https://lists.hostsharing.net/mailman/listinfo/support Support Mailingliste]''' mit der Mailadresse [mailto:support@hostsharing.net support@hostsharing.net].

Fragen, die vertrauliche Themen behandeln (Domainnamen, Benutzernamen, Passwörter etc.) sollten direkt an den [[HS-Service]] gehen, der ansonsten kostenpflichtig ist. Ergänzende Hinweise finden sich in den [https://lists.hostsharing.net/archiv/global-announce/ Global Announces] der Hostmaster und des Vorstandes zu aktuellen Geschehnissen und technischen Änderungen bei Hostsharing.

Du kannst dich mit deinen HS Userdaten einloggen und mithelfen, die Dokumentation zu verbessern. In unserem [[Autorenportal]] findest du Hinweise dazu, wie du dich beteiligen kannst. Was hier ins Wiki gehört, und wie es gemacht wird, ist unter [[Hilfe:Hostsharing_Wiki_Konventionen|Konventionen]] erklärt.

Zum Testen und Rumspielen ist der [[Sandkasten]] da. Und nun viel Freude im Hostsharing Wiki :-)

== Hostsharing Benefits ==

Hostsharing.net ist die professionelle Alternative zur Administration eigener Root Server mit dem Bonus der Redundanz und des gemeinschaftlich organisierten Betriebes.

[[Green Web Foundation | Ökostrom: Hostsharing ist gelistet bei der Green Web Foundation]]

[[10 Missverständnisse über dedizierte root-Server | Rootserver Missverständnisse]] 
[[Rootserver Checkliste]]

==Mastodon-Instanz für Mitglieder==
[[Einrichtung und Benutzung von Mastodon-Accounts auf https://hostsharing.coop]] 
[[Einrichtung des Crossposting Bots]] 

----
[[Kategorie:Hostsharing Wiki]]
[[Kategorie:HSDoku]]

Diskussion:Einrichtung und Benutzung von Mastodon-Accounts auf https://hostsharing.coop

2022-05-04T09:14:03Z

Hsh-janulrichhasecke: Veralteter Text

Der Text ist vermutlich veraltet.

Cryptpad

2021-12-17T09:20:32Z

Hsh-janulrichhasecke: /* Webserver Konfiguration */

= Cryptpad =

'''Cryptpad''' ist ein Online-Office, dass in erster Linie im Internet-Browser zu bedienen ist. Das Alleinstellungsmerkmal ist die '''Ende-zu-Ende-Verschlüsselung''' aller Dokumente. Die Entschlüsselung und die Verschlüsselung erfolgen im Browser. Auf dem Server sind keinerlei lesbare Daten abgelegt.

Cryptpad bietet Editoren für formatierte '''Textdokumente''' (im HTML-Format) und für '''Markdown-Dateien''' und andere Textdateien. Der Anwendungsfall der '''Tabellenkalkulation''' wird durch Onlyoffice-Tabellen abgedeckt. Präsentationen können mit Hilfe von Markdown erstellt werden. Bilder und PDF-Dokumente können in die Umgebung hochgeladen und im Browser betrachtet werden. Ein '''Kalender''' und ein '''Kanbanboard''' zur Aufgabenverwaltung vervollständigen das Angebot.

Das Projekt stellt eine gute [https://docs.cryptpad.fr/de/admin_guide/installation.html Installationsanleitung] bereit. Leider ist die Konfiguration des Webservers nur für NGinX dokumentiert, so dass für die Konfiguration des Apache Webserver einige Experimente notwendig wurden.

= Installation =

Mitglieder, die einen Managed Webspace im Shared Hosting nutzen, müssen für ihre Cryptpad-Installation einen "eigenen Serverdienst" beim Hostsharing-Service anmelden. Diese Option ist im Shared Hosting kostenpflichtig. Für den Serverdienst wird ein IP-Port mit dem Server vereinbart. Im Beispiel wird Port '30001' genutzt.

Für die Installation werden mit Hilfe von HSAdmin ein User (hier: 'xyz00-cryptpad') und eine Domain angelegt (hier: 'cryptpad.hs-example.de'). Die Entwickler empfehlen die Nutzung von zwei Domains für eine Cryptpad Installation. Wir nutzen hier eine 'leichtgewichtige' Subdomain 'api.cryptpad.hs-example.de', die bei Hostsharing ohne weitere Konfiguration nutzbar ist.

== Webserver Konfiguration ==

Nach dem Aufschalten der Domain 'cryptpad.hs-example.de' passen wird die generierte Verzeichnisstruktur der Domain wie folgt an:

cd ~/doms/cryptpad.hs-example.de
rm -rf subs/www subs-ssl/www htdocs-ssl/.htaccess
mkdir subs/api subs-ssl/api

In die Verzeichnisse 'subs/api', 'subs-ssl/api' und 'htdocs-ssl' werden jeweils Dateien mit dem Namen '.htaccess' zur Konfiguration des Apache Webserver abgelegt:

cd ~/doms/cryptpad.hs-example.de

cat subs/api/.htaccess
Redirect permanent / https://api.cryptpad.hs-example.de/

cat subs-ssl/api/.htaccess
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:30001%{REQUEST_URI} [proxy]
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:30001%{REQUEST_URI} [proxy,last]

cat htdocs-ssl/.htaccess
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:30001%{REQUEST_URI} [proxy]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:30001%{REQUEST_URI} [proxy,last]

Eine weitere '.htaccess'-Datei liegt direkt im Hauptverzeichnis der Domain (die überlangen Zeilen beachten):

cd ~/doms/cryptpad.hs-example.de
cat .htaccess
Header Set Access-Control-Allow-Origin "*"
Header Set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header Set Access-Control-Allow-Headers "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range"
Header Set Access-Control-Max-Age "1728000"
Header Set Cross-Origin-Resource-Policy "cross-origin"
Header Set Cross-Origin-Embedder-Policy "require-corp"
Header Set Content-Security-Policy "default-src 'none'; child-src https://cryptpad.hs-example.de; worker-src https://cryptpad.hs-example.de; media-src * blob:; style-src 'unsafe-inline' 'self' cryptpad.hs-example.de; script-src 'self' 'unsafe-inline' 'unsafe-eval' resource: cryptpad.hs-example.de; connect-src 'self' https://cryptpad.hs-example.de cryptpad.hs-example.de https://api.cryptpad.hs-example.de blob: wss://api.cryptpad.hs-example.de api.cryptpad.hs-example.de; font-src 'self' data: cryptpad.hs-example.de; img-src data: * blob:; frame-src 'self' blob: api.cryptpad.hs-example.de cryptpad.hs-example.de https://cryptpad.hs-example.de https://api.cryptpad.hs-example.de;"

Zwei Datenverzeichnisse werden angelegt und direkt ins 'htdocs-ssl' verlinkt:

cd $HOME
mkdir data
mkdir data/blob
mkdir data/block
cd $HOME/doms/cryptpad.hs-example.de/htdocs-ssl/
ln -s /home/pacs/xyz00/users/cryptpad/data/blob .
ln -s /home/pacs/xyz00/users/cryptpad/data/block .

Dieser Link muss angepasst werden, wenn der Blob-Speicher in den Zusatzspeicher unter /home/storage verschoben wird (siehe unten)!

== Installation von NodeJS ==

Nach dieser [https://wiki.hostsharing.net/index.php?title=NodeJS Anleitung] hier im Wiki wird mit Hilfe von 'nvm' 'node' in der Version 12 installiert.

== Installation des Cryptpad ==

cd $HOME
npm install -g bower
git clone https://github.com/xwiki-labs/cryptpad.git cryptpad
cd cryptpad
# aktuelle Version nachsehen
git checkout 4.12.1
npm install
bower install
cd config
cp config.example.js config.js
vi config.js

Meine Konfiguration in der 'config.js':

$ cat config.js
module.exports = {

httpUnsafeOrigin: 'https://cryptpad.hs-example.de',
httpSafeOrigin: "https://api.cryptpad.hs-example.de",
httpAddress: '127.0.0.1',
httpPort: 30001,
maxWorkers: 4,
/*
adminKeys: [
"[admin@cryptpad.hs-example.de/xxxxxxxxxxxxxxxxxxxxxxxx=]",
],
*/
inactiveTime: 90, // days
archiveRetentionTime: 15,
accountRetentionTime: 365,
maxUploadSize: 8 * 1024 * 1024,
filePath: '/home/pacs/xyz00/users/cryptpad/data/file/',
archivePath: '/home/pacs/xyz00/users/cryptpad/data/archive/',
pinPath: '/home/pacs/xyz00/users/cryptpad/data/pins',
taskPath: '/home/pacs/xyz00/users/cryptpad/data/tasks',
blockPath: '/home/pacs/xyz00/users/cryptpad/data/block',
blobPath: '/home/pacs/xyz00/users/cryptpad/data/blob',
blobStagingPath: '/home/pacs/xyz00/users/cryptpad/data/blobstage',
decreePath: '/home/pacs/xyz00/users/cryptpad/data/decrees',
logPath: '/home/pacs/xyz00/users/cryptpad/data/logs',
logToStdout: true,
logLevel: 'info',
logFeedback: false,
verbose: false,
installMethod: 'unspecified',
};

Der Admin-Key wird später ergänzt. Der erste registrierte User im Cryptpad kann den Schlüssel aus seinem Profil herauskopieren.

Wenn größere Datenmengen erwartet werden, kann der 'blobPath' in den Zusatzspeicher verlegt werden:

blobPath: '/home/storage/xyz00/users/cryptpad/data/blob',

== Start des Cryptpad ==

Ich starte das Cryptpad zunächst einfach mit dem 'nohup'-Kommando:

cd ~/cryptpad
nohup node server &

== produktives Setup ==

Für ein produktives Setup fehlt noch das Erstellen einer Konfiguration für 'monit' oder 'supervisord' und für 'logrotate'.

= weiterführende Links =

* [https://cryptpad.fr/ Die Cryptpad Installation der Entwickler]
* [https://docs.cryptpad.fr/de/ Dokumentation in deutscher Sprache]
* [https://docs.cryptpad.fr/de/admin_guide/installation.html Installationanleitung]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:CalDAV]]

Cryptpad

2021-12-17T09:19:23Z

Hsh-janulrichhasecke: /* Installation */

= Cryptpad =

'''Cryptpad''' ist ein Online-Office, dass in erster Linie im Internet-Browser zu bedienen ist. Das Alleinstellungsmerkmal ist die '''Ende-zu-Ende-Verschlüsselung''' aller Dokumente. Die Entschlüsselung und die Verschlüsselung erfolgen im Browser. Auf dem Server sind keinerlei lesbare Daten abgelegt.

Cryptpad bietet Editoren für formatierte '''Textdokumente''' (im HTML-Format) und für '''Markdown-Dateien''' und andere Textdateien. Der Anwendungsfall der '''Tabellenkalkulation''' wird durch Onlyoffice-Tabellen abgedeckt. Präsentationen können mit Hilfe von Markdown erstellt werden. Bilder und PDF-Dokumente können in die Umgebung hochgeladen und im Browser betrachtet werden. Ein '''Kalender''' und ein '''Kanbanboard''' zur Aufgabenverwaltung vervollständigen das Angebot.

Das Projekt stellt eine gute [https://docs.cryptpad.fr/de/admin_guide/installation.html Installationsanleitung] bereit. Leider ist die Konfiguration des Webservers nur für NGinX dokumentiert, so dass für die Konfiguration des Apache Webserver einige Experimente notwendig wurden.

= Installation =

Mitglieder, die einen Managed Webspace im Shared Hosting nutzen, müssen für ihre Cryptpad-Installation einen "eigenen Serverdienst" beim Hostsharing-Service anmelden. Diese Option ist im Shared Hosting kostenpflichtig. Für den Serverdienst wird ein IP-Port mit dem Server vereinbart. Im Beispiel wird Port '30001' genutzt.

Für die Installation werden mit Hilfe von HSAdmin ein User (hier: 'xyz00-cryptpad') und eine Domain angelegt (hier: 'cryptpad.hs-example.de'). Die Entwickler empfehlen die Nutzung von zwei Domains für eine Cryptpad Installation. Wir nutzen hier eine 'leichtgewichtige' Subdomain 'api.cryptpad.hs-example.de', die bei Hostsharing ohne weitere Konfiguration nutzbar ist.

== Webserver Konfiguration ==

Nach dem Aufschalten der Domain 'cryptpad.hs-example.de' passen wird die generierte Verzeichnisstruktur der Domain wie folgt angepasst:

cd ~/doms/cryptpad.hs-example.de
rm -rf subs/www subs-ssl/www htdocs-ssl/.htaccess
mkdir subs/api subs-ssl/api

In die Verzeichnisse 'subs/api', 'subs-ssl/api' und 'htdocs-ssl' werden jeweils Dateien mit dem Namen '.htaccess' zur Konfiguration des Apache Webserver abgelegt:

cd ~/doms/cryptpad.hs-example.de

cat subs/api/.htaccess
Redirect permanent / https://api.cryptpad.hs-example.de/

cat subs-ssl/api/.htaccess
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:30001%{REQUEST_URI} [proxy]
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:30001%{REQUEST_URI} [proxy,last]

cat htdocs-ssl/.htaccess
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:30001%{REQUEST_URI} [proxy]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:30001%{REQUEST_URI} [proxy,last]

Eine weitere '.htaccess'-Datei liegt direkt im Hauptverzeichnis der Domain (die überlangen Zeilen beachten):

cd ~/doms/cryptpad.hs-example.de
cat .htaccess
Header Set Access-Control-Allow-Origin "*"
Header Set Access-Control-Allow-Methods "GET, POST, OPTIONS"
Header Set Access-Control-Allow-Headers "DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Content-Range,Range"
Header Set Access-Control-Max-Age "1728000"
Header Set Cross-Origin-Resource-Policy "cross-origin"
Header Set Cross-Origin-Embedder-Policy "require-corp"
Header Set Content-Security-Policy "default-src 'none'; child-src https://cryptpad.hs-example.de; worker-src https://cryptpad.hs-example.de; media-src * blob:; style-src 'unsafe-inline' 'self' cryptpad.hs-example.de; script-src 'self' 'unsafe-inline' 'unsafe-eval' resource: cryptpad.hs-example.de; connect-src 'self' https://cryptpad.hs-example.de cryptpad.hs-example.de https://api.cryptpad.hs-example.de blob: wss://api.cryptpad.hs-example.de api.cryptpad.hs-example.de; font-src 'self' data: cryptpad.hs-example.de; img-src data: * blob:; frame-src 'self' blob: api.cryptpad.hs-example.de cryptpad.hs-example.de https://cryptpad.hs-example.de https://api.cryptpad.hs-example.de;"

Zwei Datenverzeichnisse werden angelegt und direkt ins 'htdocs-ssl' verlinkt:

cd $HOME
mkdir data
mkdir data/blob
mkdir data/block
cd $HOME/doms/cryptpad.hs-example.de/htdocs-ssl/
ln -s /home/pacs/xyz00/users/cryptpad/data/blob .
ln -s /home/pacs/xyz00/users/cryptpad/data/block .

Dieser Link muss angepasst werden, wenn der Blob-Speicher in den Zusatzspeicher unter /home/storage verschoben wird (siehe unten)!

== Installation von NodeJS ==

Nach dieser [https://wiki.hostsharing.net/index.php?title=NodeJS Anleitung] hier im Wiki wird mit Hilfe von 'nvm' 'node' in der Version 12 installiert.

== Installation des Cryptpad ==

cd $HOME
npm install -g bower
git clone https://github.com/xwiki-labs/cryptpad.git cryptpad
cd cryptpad
# aktuelle Version nachsehen
git checkout 4.12.1
npm install
bower install
cd config
cp config.example.js config.js
vi config.js

Meine Konfiguration in der 'config.js':

$ cat config.js
module.exports = {

httpUnsafeOrigin: 'https://cryptpad.hs-example.de',
httpSafeOrigin: "https://api.cryptpad.hs-example.de",
httpAddress: '127.0.0.1',
httpPort: 30001,
maxWorkers: 4,
/*
adminKeys: [
"[admin@cryptpad.hs-example.de/xxxxxxxxxxxxxxxxxxxxxxxx=]",
],
*/
inactiveTime: 90, // days
archiveRetentionTime: 15,
accountRetentionTime: 365,
maxUploadSize: 8 * 1024 * 1024,
filePath: '/home/pacs/xyz00/users/cryptpad/data/file/',
archivePath: '/home/pacs/xyz00/users/cryptpad/data/archive/',
pinPath: '/home/pacs/xyz00/users/cryptpad/data/pins',
taskPath: '/home/pacs/xyz00/users/cryptpad/data/tasks',
blockPath: '/home/pacs/xyz00/users/cryptpad/data/block',
blobPath: '/home/pacs/xyz00/users/cryptpad/data/blob',
blobStagingPath: '/home/pacs/xyz00/users/cryptpad/data/blobstage',
decreePath: '/home/pacs/xyz00/users/cryptpad/data/decrees',
logPath: '/home/pacs/xyz00/users/cryptpad/data/logs',
logToStdout: true,
logLevel: 'info',
logFeedback: false,
verbose: false,
installMethod: 'unspecified',
};

Der Admin-Key wird später ergänzt. Der erste registrierte User im Cryptpad kann den Schlüssel aus seinem Profil herauskopieren.

Wenn größere Datenmengen erwartet werden, kann der 'blobPath' in den Zusatzspeicher verlegt werden:

blobPath: '/home/storage/xyz00/users/cryptpad/data/blob',

== Start des Cryptpad ==

Ich starte das Cryptpad zunächst einfach mit dem 'nohup'-Kommando:

cd ~/cryptpad
nohup node server &

== produktives Setup ==

Für ein produktives Setup fehlt noch das Erstellen einer Konfiguration für 'monit' oder 'supervisord' und für 'logrotate'.

= weiterführende Links =

* [https://cryptpad.fr/ Die Cryptpad Installation der Entwickler]
* [https://docs.cryptpad.fr/de/ Dokumentation in deutscher Sprache]
* [https://docs.cryptpad.fr/de/admin_guide/installation.html Installationanleitung]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:CalDAV]]

Matrix Synapse installieren

2020-08-27T11:03:59Z

Hsh-janulrichhasecke: Typo und Link zu Hostsharing Lösungen

Der Matrix Server ''Synapse'', der sogenannte 'Homeserver', ist aktuell die einzige vollständige serverseitige Implementierung des Matrix-Protokolls.

{{Textkasten|gelb|Work in Progress|Leider funktioniert die Server-zu-Server-Kommunikation von Synapse hinter dem Apache-Proxy mit den genannten Rewrite-Rules nicht. Bitten Sie dazu den Service, Ihren Apache VHost individuell für den Matrix Server anzupassen.
Weiterhin wird für die aktuelle Version von Synapse Python 3.8 benötigt. Es ist kein Problem sich ein Python 3.8 aus den Sourcen zu kompilieren. Das ist hier nicht noch nicht beschrieben.}}

Synapse wird bei Hostsharing als ''eigener Daemon'' betrieben. Der Betrieb ist im Shared Hosting anmelde- und kostenpflichtig. Daher empfehlen wir für den Betrieb einen ''Managed Server''.

Diese Anleitung beschreibt, wie man den Matrix-Homeserver Synapse auf der Managed Hosting Plattform von Hostsharing installieren kann. Dabei sind die User-IDs nach dem Schema @user:beispiel.de aufgebaut, der Homeserver an sich ist unter matrix.beispiel.de erreichbar.

== Vorbereitungen ==

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-matrix''
# Eine Domain mit ''xyz00-matrix'' als Domain-Administrator, zum Beispiel ''matrix.beispiel.de''
# Einen Postgresql-User ''xyz00_matrixuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_matrixdb'' mit Datenbank-Owner ''xyz00_matrixuser''

Verwendete IP-Ports der Server-Dienste:
# Monit: xyz00.hostsharing.net:32800
# Synapse: localhost:32801

== Installation von Synapse ==

Installationsanleitung basierend auf https://github.com/matrix-org/synapse/blob/master/INSTALL.md#installing-from-source

Als User ''xyz00-matrix" ein Python3 virtualenv erstellen

mkdir -p ~/synapse
virtualenv -p python3 ~/synapse/env
source ~/synapse/env/bin/activate
pip install --upgrade pip
pip install --upgrade setuptools

Synapse und Postgres-Dependencies installieren

pip install matrix-synapse[postgres]

Initiale Konfiguration mit richtigem server-name "beispiel.de" generieren, außerdem im laufenden Betrieb keine Statistiken an Matrix.org senden

cd ~/synapse
python -m synapse.app.homeserver --server-name beispiel.de --config-path homeserver.yaml --generate-config --report-stats=no

== Konfiguration von Synapse ==

In die initial generierte Konfiguration muss noch die Port- und Datenbank-Konfiguration eingetragen werden:

Port: Innerhalb der listener-section den Port 8008 auf 32801 (wie initial definiert) ändern, alles andere beibehalten:

- port: 32801
tls: false
bind_addresses: ['::1', '127.0.0.1']
type: http
x_forwarded: true

Postgres-Datenbank:

database:
# The database engine name
name: "psycopg2"
# Arguments to pass to the engine
args:
host: "localhost"
database: "xyz00_matrixdb"
user: "xyz00_matrixuser"
password: "meinPasswort"
cp_min: 5
cp_max: 10

== Starten der Dienste ==

Zum Start aller notwendigen Dienste wird in dieser Anleitung ''monit'' benutzt. Hier ein Beispiel für eine Datei ''.monitrc'' (überlange Zeilen werden hier im Wiki umgebrochen)

Das monitpassword auf jeden Fall durch ein sicheres Passwort ersetzen:

set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/users/matrix/monit/var/monit.log
set idfile /home/pacs/xyz00/users/matrix/monit/var/monit.id
set statefile /home/pacs/xyz00/users/matrix/monit/var/monit.state
set mailserver localhost
set mail-format { from: monit@matrix.beispiel.de }
set alert matrix@matrix.beispiel.de
set httpd port 32800 address xyz00.hostsharing.net
allow matrix:monitpassword
check process synapse with pidfile /home/pacs/xyz00/users/matrix/synapse/homeserver.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/homeserver.pid )'"

== Cronjobs ==

''Cron'' wird für eine Aufgabe genutzt:
* Start von monit nach einem Server Reboot

Einrichten der crontab mit ''cronttab -e''

HOME=/home/pacs/xyz00/users/matrix
MAILTO=matrix@matrix.beispiel.de

@reboot /usr/bin/monit -c $HOME/.monitrc

== Einrichten des Apache VHost ==

Die ''~/doms/matrix.beispiel.de/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:

DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32801%{REQUEST_URI} [NE,proxy]
RequestHeader set X-Forwarded-Proto "https"

== Well-Known unter beispiel.de ==

Damit die User-Accounts das Format @user:beispiel.de haben, der Server aber unter matrix.beispiel.de erreichbar ist, müssen noch folgende zwei Dateien unter der Domain beispiel.de abgelegt werden:

https://beispiel.de/.well-known/matrix/server
{
"m.server": "matrix.beispiel.de:443"
}

https://beispiel.de/.well-known/matrix/client
{
"m.homeserver": {
"base_url": "https://matrix.beispiel.de"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
}

Für die muss noch der CORS-Header Access-Control-Allow-Origin "*" gesetzt werden, damit die Datei aus beliebigem Riot-Web im Browser abrufbar ist. Dazu in den Ordner .well-known/matrix/ folgende .htaccess anlegen:

Header set Access-Control-Allow-Origin "*"

Die Dokumentation dazu findet man unter https://matrix.org/docs/spec/server_server/r0.1.2#get-well-known-matrix-server und https://matrix.org/docs/spec/client_server/r0.5.0#get-well-known-matrix-client

== Update von Synapse ==

source ~/synapse/env/bin/activate
pip install -U matrix-synapse[postgres]
monit restart synapse

== Riot-Web ==

Riot-Web ist aus Server-Seite eine rein statische html+javascript-Kombination, daher:

* Account und Domain anlegen (separat von der Synapse-Domain)
* aktuelles riot-web release .tgz herunterladen
* Symlink von htdocs-ssl auf entpacktes riot-web-Verzeichnis
* config.sample.json in config.json kopieren und Matrix-Homeserver-Einträge anpassen
* Piwik aus config.json entfernen

== SAML mit Synapse ==

Synapse unterstützt mit Version 1.1.0 SAML. Dazu wie folgt vorgehen:

Das Paket xmlsec1 muss installiert sein:

$ xmlsec1 --version
xmlsec1 1.2.23 (openssl)

Das Python-Paket pysaml2 installieren

source synapse/env/bin/activate
pip install pysaml2

In der homeserver.yaml die SAML-Direktiven einkommentieren, hier mit dem Beispiel eines SAML IdP unter https://login.beispiel.de/simplesaml/saml2/idp/metadata.php:

# Once SAML support is enabled, a metadata file will be exposed at
# https://<server>:<port>/_matrix/saml2/metadata.xml, which you may be able to
# use to configure your SAML IdP with. Alternatively, you can manually configure
# the IdP to use an ACS location of
# https://<server>:<port>/_matrix/saml2/authn_response.
#
saml2_config:
sp_config:
# point this to the IdP's metadata. You can use either a local file or
# (preferably) a URL.
metadata:
#local: ["saml2/idp.xml"]
remote:
- url: https://login.beispiel.de/simplesaml/saml2/idp/metadata.php

Wichtig ist außerdem, dass die public_baseurl in der homeserver.yaml gesetzt ist, damit Synapse weiß, wie es erreichbar ist und dies in seine SP-Metadaten einbauen kann:

public_baseurl: https://matrix.beispiel.de/

Die Service-Provider-Konfiguration als XML bekommt man von Synapse dann wie schon in der homeserver.yaml als Kommentar beschrieben, unter https://matrix.beispiel.de/_matrix/saml2/metadata.xml

Diese dann in den SAML-IdP-importieren und dann sollte der Single-Sign-On via SAML funktionieren.

== Federation Sender Worker für Synapse ==

Zur Parallelisierung bietet Synapse das Konzept "Worker" an, die spezifische Aufgaben übernehmen, damit der Hauptprozess diese nicht durchführen muss.

Details dazu: https://github.com/matrix-org/synapse/blob/master/docs/workers.md

Ein einfach einzurichtender Worker, der auch viel Last abfedert, ist der Federation Sender Worker, da das Verschicken des Federation-Traffics 10-50% der Serverlast ausmacht.

In der homeserver.yaml die Worker-Konfiguration aktivieren:

## Worker ##
worker_app: synapse.app.homeserver
daemonize: true

und dazugehörige Listener (Abschnitt listener:) aktivieren:

# The TCP replication port
- port: 32892
bind_address: '127.0.0.1'
type: replication
# The HTTP replication port
- port: 32893
bind_address: '127.0.0.1'
type: http
resources:
- names: [replication]

Funktionen, die Worker machen sollen, in der homeserver.yaml deaktivieren:

# disable federation sending here, use worker for it
send_federation: False

Dann Verzeichnis synapse/workers anlegen, darin federation_sender.yaml:

worker_app: synapse.app.federation_sender

# The replication listener on the synapse to talk to.
worker_replication_host: 127.0.0.1
worker_replication_port: 32892
worker_replication_http_port: 32893

worker_daemonize: True
worker_pid_file: /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
worker_log_config: /home/pacs/xyz00/users/matrix/synapse/federation_sender.log.config

.monitrc um worker erweitern:

check process federation_sender with pidfile /home/pacs/xyz00/users/matrix/synapse/federation_sender.pid
start program "/bin/bash -c 'export VIRTUAL_ENV=$HOME/synapse/env && export PATH=$VIRTUAL_ENV/bin:$PATH && cd $HOME/synapse && synctl -w workers/federation_sender.yaml start'"
stop program "/bin/bash -c '/bin/kill $( cat $HOME/synapse/federation_sender.pid )'"

Monit neu laden und synapse und federation_sender neustarten:

monit reload
monit restart all

Nach Updates ebenfalls immer Hauptprozess und alle Worker neustarten

monit restart all

== Links ==

* https://matrix.org/docs/projects/server/synapse
* https://github.com/matrix-org/synapse
* https://github.com/matrix-org/synapse/blob/master/INSTALL.md
* https://matrix.org/docs/spec/
* https://www.hostsharing.net/loesungen/matrix/

[[Kategorie:Installationsanleitungen]]