Hostsharing Wiki - Benutzerbeiträge [de]

Redmine im Webspace

2026-02-16T19:08:12Z

Hsh-peterhormanns: /* Redmine-Installation */

Redmine ist eine umfangreiche Projektmanagement-Software. Die Software ist multiprojektfähig und legt für jedes Projekt mehrere Werkzeuge an:
* Wiki
* Vorgangsverfolgung (Ticketsystem, Issue Tracker)
* Zeiterfassung
* Dokument- und Dateiverwaltung
* Foren
* Kalender, Gantt-Charts
* Schnittstelle zur Versionverwaltung (Git, Mercurial und weitere)

Diese Anleitung beschreibt, wie man Redmine auf der Managed Hosting Plattform von Hostsharing installieren kann. Redmine lässt sich in jedem Managed Webspace betreiben.

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-redmine''
# Eine Domain mit ''xyz00-redmine'' als Domain-Administrator, zum Beispiel ''prj.example.com''
# Die Domain muss aktualisiert werden: Domainoption ''passenger'' einschalten, ''fastcgi'' ausschalten
# Einen Postgresql-User ''xyz00_dbuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_prjdb'' mit Datenbank-Owner ''xyz00_dbuser''

== Ruby installieren ==

Für Redmine 6.0.x habe ich Ruby 3.3.x installiert. Siehe dazu die Seite [[RubyRBEnv]]

== Download, Entpacken, Konfiguration ==

Anmeldung per ssh als User ''xyz00-redmine":

<syntaxhighlight lang="shell">
ssh xyz00-redmine@xyz00.hostsharing.net
</syntaxhighlight>

Auf dem Hostsharing-Server:

<syntaxhighlight lang="shell">
cd ~
mkdir data
chmod 700 data
wget http://www.redmine.org/releases/redmine-6.0.6.tar.gz
tar xzf redmine-6.0.6.tar.gz
cd ~/redmine-6.0.6/config
</syntaxhighlight>

Anlegen der beiden Dateien "database.yml" und "configuration.yml" mit folgendem Inhalt:

database.yml:

<syntaxhighlight lang="yaml" line>
production:
adapter: postgresql
database: xyz00_prjdb
host: localhost
username: xyz00_dbuser
password: "meinPasswort"
</syntaxhighlight>

configuration.yml:

<syntaxhighlight lang="yaml" line>
default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: "127.0.0.1"
port: 4025
enable_starttls_auto: false
attachments_storage_path: "/home/pacs/xyz00/users/redmine/data"
autologin_cookie_name:
autologin_cookie_path:
autologin_cookie_secure:
scm_subversion_command:
scm_mercurial_command:
scm_git_command:
scm_cvs_command:
scm_bazaar_command:
scm_darcs_command:
scm_subversion_path_regexp:
scm_mercurial_path_regexp:
scm_git_path_regexp:
scm_cvs_path_regexp:
scm_bazaar_path_regexp:
scm_darcs_path_regexp:
scm_filesystem_path_regexp:
scm_stderr_log_file:
database_cipher_key:
</syntaxhighlight>

Achtung: Die Einrückung muss immer genau um zwei Leerzeichen erfolgen!

Der "attachments_storage_path" muss angepasst werden ("xyz00" und "redmine" durch den eigenen Webspace bzw. das eigene User-Postfix ersetzen). Wenn für den Webspace "Storage" gebucht ist, kann der Speicher nach "/home/storage/..." gelegt werden.

== Redmine-Installation ==

Weiterhin als "xyz00-redmine" auf dem Hostsharing-Server:

<syntaxhighlight lang="shell">
cd ~/redmine-6.0.6
bundle config set --local path 'vendor/bundle'
bundle config set --local without 'development:test'
bundle install
bundle exec rake generate_secret_token
RAILS_ENV=production bundle exec rake db:migrate
RAILS_ENV=production bundle exec rake redmine:load_default_data
</syntaxhighlight>

Weiter in der Shell:

<syntaxhighlight lang="shell">
cd ~/doms/prj.example.com/
rm -rf htdocs-ssl/ app-ssl/ subs/www/ subs-ssl/www/
ln -s $HOME/redmine-6.0.6 app-ssl
ln -s $HOME/redmine-6.0.6/public htdocs-ssl
</syntaxhighlight>

Wenn alles gut gegangen ist, ist die Redmine-Installation unter
https://prj.example.com erreichbar. Beim ersten Login als User "admin" mit Passwort "admin" wird ein neues Passwort konfiguriert.

Nach der Änderung des Admin-Passwort sollten einige Einstellungen im Bereich Administration/Konfiguration durchgesehen werden:
* im Bereich "Allgemein" der Applikationstitel, der Hostname und das Protokoll
* im Bereich "Mailbenachrichtigung" der E-Mail-Absender und die E-Mail-Fußzeile

== Konfiguration von Sidekiq ==

Für Hintergrundprozesse, zum Beispiel für den Versand von EMail-Benachrichtigungen, sollte man in einem produktiven System Sidekiq verwenden. Dazu müssen zwei Services konfiguriert werden: Redis und Sidekiq.

Zur Konfiguration von Redis als Service siehe [[Redis]]. In der Beispielkonfiguration lauscht Redis auf localhost:33033.

Wir machen diese Redis-URL dem Passenger-Prozess über eine Environment-Variable bekannt. Dazu schreiben wir in eine Datei
"~/doms/prj.example.com/.htaccess"

<syntaxhighlight lang="shell" line>
SetEnv REDIS_URL redis://:redispassword@127.0.0.1:33033/0
</syntaxhighlight>

Zur Installation von Sidekiq legen wir eine Datei "~/redmine-6.0.6/Gemfile.local" an. Der Inhalt ist:

<syntaxhighlight lang="shell" line>
gem 'sidekiq'
gem "redis", ">= 4.0.1"
</syntaxhighlight>

Im Verzeichnis "~/redmine-6.0.6/" ausführen: "bundle install"

Sidekiq bekommt die Redis-URL über seine Unit-Definition:

<syntaxhighlight lang="shell" line>
[Unit]
Description=Sidekiq Service

[Service]
WorkingDirectory=%h/redmine-6.0.6
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="REDIS_URL=redis://:redispassword@127.0.0.1:33033/0"
ExecStart=%h/.rbenv/shims/bundle exec sidekiq -q default -q mailers
StandardOutput=append:%h/var/log/sidekiq.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Nicht vergessen das Verzeichnis "~/var/log" anzulegen oder anzupassen.

== eingehende E-Mails ==

Wenn für eingehende E-Mail-Nachrichten jeweils ein Ticket angelegt werden soll, ist das über die Datei .forward möglich.

<syntaxhighlight lang="shell">
# cat .forward
"|/home/pacs/xyz00/users/redmine/.rbenv/shims/ruby /home/pacs/xyz00/users/redmine/redmine-6.0.6/extra/mail_handler/rdm-mailhandler.rb --url=https://prj.example.com --key=******** --project=pppp --tracker=tttt --allow-override=all --unknown-user=create"
</syntaxhighlight>

Im Wiki des Redmine Projekt sind die Optionen des Skript 'rdm-mailhandler.rb' beschrieben (siehe Links).

== weitere Schritte ==

Redmine ist ein stabiles Projektmanagement-Werkzeug. Es ist freie Software und weiterhin gepflegt. Die Benutzeroberfläche ist funktional. Sie macht aber einen etwas veralteten Eindruck.

Es gibt einige Themes und Plugins, die diesen Nachteil teilweise kompensieren können:
* Das Theme "farend bleuclair" sorgt für einen frischeren Ersteindruck
* Ein Kanban Board ist als Plugin verfügbar
* ebenso kann ein visueller Editor für das Wiki nachgerüstet werden

Weiterhin ist es möglich, das Anlegen von Tickets für eingehende E-Mail-Nachrichten zu konfigurieren.

== Links ==

* [https://www.redmine.org/ Redmine Projekt]
* [https://www.redmine.org/projects/redmine/wiki/RedmineInstall Installationsanleitung]
* [https://github.com/farend/redmine_theme_farend_bleuclair Theme Farend Bleuclair]
* [https://github.com/jgraichen/redmine_dashboard Redmine Dashboard Plugin] oder [https://github.com/happy-se-life/kanban Kanban Board Plugin]
* [https://github.com/taqueci/redmine_wysiwyg_editor Wysiwyg Editor Plugin]
* [https://github.com/picman/redmine_dmsf Dokumentenverwaltung (DMS) mit WebDAV-Server und Volltextsuche]
* [https://www.redmine.org/projects/redmine/wiki/RedmineReceivingEmails Eingehende E-Mails verarbeiten]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Passenger]]
[[Kategorie:Projektverwaltung]]
[[Kategorie:Projektmanagement]]
[[Kategorie:WebDAV]]

Redmine im Webspace

2026-02-16T18:28:49Z

Hsh-peterhormanns: /* Konfiguration von Sidekiq */

Redmine ist eine umfangreiche Projektmanagement-Software. Die Software ist multiprojektfähig und legt für jedes Projekt mehrere Werkzeuge an:
* Wiki
* Vorgangsverfolgung (Ticketsystem, Issue Tracker)
* Zeiterfassung
* Dokument- und Dateiverwaltung
* Foren
* Kalender, Gantt-Charts
* Schnittstelle zur Versionverwaltung (Git, Mercurial und weitere)

Diese Anleitung beschreibt, wie man Redmine auf der Managed Hosting Plattform von Hostsharing installieren kann. Redmine lässt sich in jedem Managed Webspace betreiben.

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-redmine''
# Eine Domain mit ''xyz00-redmine'' als Domain-Administrator, zum Beispiel ''prj.example.com''
# Die Domain muss aktualisiert werden: Domainoption ''passenger'' einschalten, ''fastcgi'' ausschalten
# Einen Postgresql-User ''xyz00_dbuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_prjdb'' mit Datenbank-Owner ''xyz00_dbuser''

== Ruby installieren ==

Für Redmine 6.0.x habe ich Ruby 3.3.x installiert. Siehe dazu die Seite [[RubyRBEnv]]

== Download, Entpacken, Konfiguration ==

Anmeldung per ssh als User ''xyz00-redmine":

<syntaxhighlight lang="shell">
ssh xyz00-redmine@xyz00.hostsharing.net
</syntaxhighlight>

Auf dem Hostsharing-Server:

<syntaxhighlight lang="shell">
cd ~
mkdir data
chmod 700 data
wget http://www.redmine.org/releases/redmine-6.0.6.tar.gz
tar xzf redmine-6.0.6.tar.gz
cd ~/redmine-6.0.6/config
</syntaxhighlight>

Anlegen der beiden Dateien "database.yml" und "configuration.yml" mit folgendem Inhalt:

database.yml:

<syntaxhighlight lang="yaml" line>
production:
adapter: postgresql
database: xyz00_prjdb
host: localhost
username: xyz00_dbuser
password: "meinPasswort"
</syntaxhighlight>

configuration.yml:

<syntaxhighlight lang="yaml" line>
default:
email_delivery:
delivery_method: :smtp
smtp_settings:
address: "127.0.0.1"
port: 4025
enable_starttls_auto: false
attachments_storage_path: "/home/pacs/xyz00/users/redmine/data"
autologin_cookie_name:
autologin_cookie_path:
autologin_cookie_secure:
scm_subversion_command:
scm_mercurial_command:
scm_git_command:
scm_cvs_command:
scm_bazaar_command:
scm_darcs_command:
scm_subversion_path_regexp:
scm_mercurial_path_regexp:
scm_git_path_regexp:
scm_cvs_path_regexp:
scm_bazaar_path_regexp:
scm_darcs_path_regexp:
scm_filesystem_path_regexp:
scm_stderr_log_file:
database_cipher_key:
</syntaxhighlight>

Achtung: Die Einrückung muss immer genau um zwei Leerzeichen erfolgen!

Der "attachments_storage_path" muss angepasst werden ("xyz00" und "redmine" durch den eigenen Webspace bzw. das eigene User-Postfix ersetzen). Wenn für den Webspace "Storage" gebucht ist, kann der Speicher nach "/home/storage/..." gelegt werden.

== Redmine-Installation ==

Weiterhin als "xyz00-redmine" auf dem Hostsharing-Server:

<syntaxhighlight lang="shell">
cd ~/redmine-6.0.6
bundle config --local path 'vendor/bundle'
bundle config --local without 'development:test'
bundle install
bundle exec rake generate_secret_token
RAILS_ENV=production bundle exec rake db:migrate
RAILS_ENV=production bundle exec rake redmine:load_default_data
</syntaxhighlight>

Weiter in der Shell:

<syntaxhighlight lang="shell">
cd ~/doms/prj.example.com/
rm -rf htdocs-ssl/ app-ssl/ subs/www/ subs-ssl/www/
ln -s $HOME/redmine-6.0.6 app-ssl
ln -s $HOME/redmine-6.0.6/public htdocs-ssl
</syntaxhighlight>

Wenn alles gut gegangen ist, ist die Redmine-Installation unter
https://prj.example.com erreichbar. Beim ersten Login als User "admin" mit Passwort "admin" wird ein neues Passwort konfiguriert.

Nach der Änderung des Admin-Passwort sollten einige Einstellungen im Bereich Administration/Konfiguration durchgesehen werden:
* im Bereich "Allgemein" der Applikationstitel, der Hostname und das Protokoll
* im Bereich "Mailbenachrichtigung" der E-Mail-Absender und die E-Mail-Fußzeile

== Konfiguration von Sidekiq ==

Für Hintergrundprozesse, zum Beispiel für den Versand von EMail-Benachrichtigungen, sollte man in einem produktiven System Sidekiq verwenden. Dazu müssen zwei Services konfiguriert werden: Redis und Sidekiq.

Zur Konfiguration von Redis als Service siehe [[Redis]]. In der Beispielkonfiguration lauscht Redis auf localhost:33033.

Wir machen diese Redis-URL dem Passenger-Prozess über eine Environment-Variable bekannt. Dazu schreiben wir in eine Datei
"~/doms/prj.example.com/.htaccess"

<syntaxhighlight lang="shell" line>
SetEnv REDIS_URL redis://:redispassword@127.0.0.1:33033/0
</syntaxhighlight>

Zur Installation von Sidekiq legen wir eine Datei "~/redmine-6.0.6/Gemfile.local" an. Der Inhalt ist:

<syntaxhighlight lang="shell" line>
gem 'sidekiq'
gem "redis", ">= 4.0.1"
</syntaxhighlight>

Im Verzeichnis "~/redmine-6.0.6/" ausführen: "bundle install"

Sidekiq bekommt die Redis-URL über seine Unit-Definition:

<syntaxhighlight lang="shell" line>
[Unit]
Description=Sidekiq Service

[Service]
WorkingDirectory=%h/redmine-6.0.6
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="REDIS_URL=redis://:redispassword@127.0.0.1:33033/0"
ExecStart=%h/.rbenv/shims/bundle exec sidekiq -q default -q mailers
StandardOutput=append:%h/var/log/sidekiq.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Nicht vergessen das Verzeichnis "~/var/log" anzulegen oder anzupassen.

== eingehende E-Mails ==

Wenn für eingehende E-Mail-Nachrichten jeweils ein Ticket angelegt werden soll, ist das über die Datei .forward möglich.

<syntaxhighlight lang="shell">
# cat .forward
"|/home/pacs/xyz00/users/redmine/.rbenv/shims/ruby /home/pacs/xyz00/users/redmine/redmine-6.0.6/extra/mail_handler/rdm-mailhandler.rb --url=https://prj.example.com --key=******** --project=pppp --tracker=tttt --allow-override=all --unknown-user=create"
</syntaxhighlight>

Im Wiki des Redmine Projekt sind die Optionen des Skript 'rdm-mailhandler.rb' beschrieben (siehe Links).

== weitere Schritte ==

Redmine ist ein stabiles Projektmanagement-Werkzeug. Es ist freie Software und weiterhin gepflegt. Die Benutzeroberfläche ist funktional. Sie macht aber einen etwas veralteten Eindruck.

Es gibt einige Themes und Plugins, die diesen Nachteil teilweise kompensieren können:
* Das Theme "farend bleuclair" sorgt für einen frischeren Ersteindruck
* Ein Kanban Board ist als Plugin verfügbar
* ebenso kann ein visueller Editor für das Wiki nachgerüstet werden

Weiterhin ist es möglich, das Anlegen von Tickets für eingehende E-Mail-Nachrichten zu konfigurieren.

== Links ==

* [https://www.redmine.org/ Redmine Projekt]
* [https://www.redmine.org/projects/redmine/wiki/RedmineInstall Installationsanleitung]
* [https://github.com/farend/redmine_theme_farend_bleuclair Theme Farend Bleuclair]
* [https://github.com/jgraichen/redmine_dashboard Redmine Dashboard Plugin] oder [https://github.com/happy-se-life/kanban Kanban Board Plugin]
* [https://github.com/taqueci/redmine_wysiwyg_editor Wysiwyg Editor Plugin]
* [https://github.com/picman/redmine_dmsf Dokumentenverwaltung (DMS) mit WebDAV-Server und Volltextsuche]
* [https://www.redmine.org/projects/redmine/wiki/RedmineReceivingEmails Eingehende E-Mails verarbeiten]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Passenger]]
[[Kategorie:Projektverwaltung]]
[[Kategorie:Projektmanagement]]
[[Kategorie:WebDAV]]

RubyRBEnv

2026-02-16T18:00:36Z

Hsh-peterhormanns: Installation von ruby 3.3.10

== Eigene Ruby Installation ==

Oft ist die vorinstallierte Version der Programmiersprache Ruby (die in Debian enthaltene Version) zu alt für die eingesetze Software.

Hier eine kurze Anleitung, mit der man eine eigene Ruby-Umgebung für einen User einrichten kann.

=== Installation von rbenv ===

Konfiguration für einen User mit "/bin/bash" als Shell. Die Umgebungsvariablen werden in ".bash_profile" hinterlegt.

<syntaxhighlight lang=shell>
git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
source ~/.bash_profile
</syntaxhighlight>

Der Befehl

<syntaxhighlight lang=shell>
type rbenv
</syntaxhighlight>

sollte eine Ausgabe erzeugen, die beginnt: "rbenv is a function"

=== Installation von ruby-build ===

<syntaxhighlight lang=shell>
git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
</syntaxhighlight>

=== Installation von ruby ===

Mit dem Kommando

<syntaxhighlight lang=shell>
rbenv install --list
</syntaxhighlight>

erhält man eine Liste der aktuell untersützten Ruby-Versionen

Installation mit (hier Version 3.3.10):

<syntaxhighlight lang=shell>
rbenv install 3.3.10
rbenv global 3.3.10
gem install bundler
rbenv rehash
</syntaxhighlight>

Der Befehl

<syntaxhighlight lang=shell>
ruby -v
</syntaxhighlight>

liefert die Ausgabe "ruby 3.3.10 (2025-10-23 revision 343ea05002) [x86_64-linux]"

== Minimale Web Applikation mit Passenger ==

Zur Integration der eigenen Ruby-Installation in den Apache erfolgt über das Apache-Modul "Passenger".
Vor der Nutzung dieses Moduls bitte unbedingt die
[[Phusion Passenger|Hinweise zur Nutzung beachten]].

Für eine minimale Beispielanwendung legen wir eine Datei ''config.ru'' mit folgenden Inhalt an
("ru" kurz für "rackup"):

<syntaxhighlight lang=ruby line>
# config.ru

class App
def call(env)
headers = { 'Content-Type' => 'text/html' }
response = ['Greetings from Rack!!']
[200, headers, response]
end
end

run App.new
</syntaxhighlight>

== Sinatra Web Applikation mit Passenger ==

Um eine Beispielanwendung zu installieren, orientieren wir uns an https://github.com/phusion/passenger-ruby-sinatra-demo/tree/end_result

Im Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app-ssl/" legen wir folgende Dateien und Verzeichnisse an:

Gemfile:

<syntaxhighlight lang=ruby line>
source 'https://rubygems.org/'

gem 'sinatra'
gem 'tilt'
gem 'base64', '0.1.1'
</syntaxhighlight>

app.rb:

<syntaxhighlight lang=ruby line>
require 'sinatra/base'
require 'tilt/erb'

class ExampleApp < Sinatra::Base
get '/' do
erb :index
end
end
</syntaxhighlight>

config.ru:

<syntaxhighlight lang=ruby line>
require File.absolute_path("app.rb")

run ExampleApp
</syntaxhighlight>

views/index.erb:

<syntaxhighlight lang=html line>
<!DOCTYPE html>
<html>
<head><title>Hello</title></head>
<body>
<h1>Hello world!</h1>
<% if defined?(PhusionPassenger) %>
<p>Congratulations, you are running this app in Passenger!<br/>
You are running Ruby Version: <%= RUBY_VERSION %>
</p>
<% else %>
<p>You are not running this app in Passenger.</p>
<% end %>
</body>
</html>
</syntaxhighlight>

Im Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app-ssl/" führen wir aus:

<syntaxhighlight lang=shell line>
bundle config --local path vendor/bundle
bundle install
</syntaxhighlight>

== Links ==

* https://www.writesoftwarewell.com/definitive-guide-to-rack/

----
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

RubyRBEnv

2026-02-16T17:41:07Z

Hsh-peterhormanns: /* Installation von ruby */

== Eigene Ruby Installation ==

Oft ist die vorinstallierte Version der Programmiersprache Ruby (die in Debian enthaltene Version) zu alt für die eingesetze Software.

Hier eine kurze Anleitung, mit der man eine eigene Ruby-Umgebung für einen User einrichten kann.

=== Installation von rbenv ===

Konfiguration für einen User mit "/bin/bash" als Shell. Die Umgebungsvariablen werden in ".bash_profile" hinterlegt.

<syntaxhighlight lang=shell>
git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
source ~/.bash_profile
</syntaxhighlight>

Der Befehl

<syntaxhighlight lang=shell>
type rbenv
</syntaxhighlight>

sollte eine Ausgabe erzeugen, die beginnt: "rbenv is a function"

=== Installation von ruby-build ===

<syntaxhighlight lang=shell>
git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
</syntaxhighlight>

=== Installation von ruby ===

Mit dem Kommando

<syntaxhighlight lang=shell>
rbenv install --list
</syntaxhighlight>

erhält man eine Liste der aktuell untersützten Ruby-Versionen

Installation mit (hier Version 3.4.8):

<syntaxhighlight lang=shell>
rbenv install 3.4.8
rbenv global 3.4.8
gem install bundler
rbenv rehash
</syntaxhighlight>

Der Befehl

<syntaxhighlight lang=shell>
ruby -v
</syntaxhighlight>

liefert die Ausgabe "ruby 3.4.8 (2025-12-17 revision 995b59f666) +PRISM [x86_64-linux]"

== Minimale Web Applikation mit Passenger ==

Zur Integration der eigenen Ruby-Installation in den Apache erfolgt über das Apache-Modul "Passenger".
Vor der Nutzung dieses Moduls bitte unbedingt die
[[Phusion Passenger|Hinweise zur Nutzung beachten]].

Für eine minimale Beispielanwendung legen wir eine Datei ''config.ru'' mit folgenden Inhalt an
("ru" kurz für "rackup"):

<syntaxhighlight lang=ruby line>
# config.ru

class App
def call(env)
headers = { 'Content-Type' => 'text/html' }
response = ['Greetings from Rack!!']
[200, headers, response]
end
end

run App.new
</syntaxhighlight>

== Sinatra Web Applikation mit Passenger ==

Um eine Beispielanwendung zu installieren, orientieren wir uns an https://github.com/phusion/passenger-ruby-sinatra-demo/tree/end_result

Im Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app-ssl/" legen wir folgende Dateien und Verzeichnisse an:

Gemfile:

<syntaxhighlight lang=ruby line>
source 'https://rubygems.org/'

gem 'sinatra'
gem 'tilt'
gem 'base64', '0.1.1'
</syntaxhighlight>

app.rb:

<syntaxhighlight lang=ruby line>
require 'sinatra/base'
require 'tilt/erb'

class ExampleApp < Sinatra::Base
get '/' do
erb :index
end
end
</syntaxhighlight>

config.ru:

<syntaxhighlight lang=ruby line>
require File.absolute_path("app.rb")

run ExampleApp
</syntaxhighlight>

views/index.erb:

<syntaxhighlight lang=html line>
<!DOCTYPE html>
<html>
<head><title>Hello</title></head>
<body>
<h1>Hello world!</h1>
<% if defined?(PhusionPassenger) %>
<p>Congratulations, you are running this app in Passenger!<br/>
You are running Ruby Version: <%= RUBY_VERSION %>
</p>
<% else %>
<p>You are not running this app in Passenger.</p>
<% end %>
</body>
</html>
</syntaxhighlight>

Im Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app-ssl/" führen wir aus:

<syntaxhighlight lang=shell line>
bundle config --local path vendor/bundle
bundle install
</syntaxhighlight>

== Links ==

* https://www.writesoftwarewell.com/definitive-guide-to-rack/

----
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

RubyRBEnv

2026-02-16T17:36:15Z

Hsh-peterhormanns: /* Installation von ruby */

== Eigene Ruby Installation ==

Oft ist die vorinstallierte Version der Programmiersprache Ruby (die in Debian enthaltene Version) zu alt für die eingesetze Software.

Hier eine kurze Anleitung, mit der man eine eigene Ruby-Umgebung für einen User einrichten kann.

=== Installation von rbenv ===

Konfiguration für einen User mit "/bin/bash" als Shell. Die Umgebungsvariablen werden in ".bash_profile" hinterlegt.

<syntaxhighlight lang=shell>
git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bash_profile
echo 'eval "$(rbenv init -)"' >> ~/.bash_profile
source ~/.bash_profile
</syntaxhighlight>

Der Befehl

<syntaxhighlight lang=shell>
type rbenv
</syntaxhighlight>

sollte eine Ausgabe erzeugen, die beginnt: "rbenv is a function"

=== Installation von ruby-build ===

<syntaxhighlight lang=shell>
git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
</syntaxhighlight>

=== Installation von ruby ===

Mit dem Kommando

<syntaxhighlight lang=shell>
rbenv install --list
</syntaxhighlight>

erhält man eine Liste der aktuell untersützten Ruby-Versionen

Installation mit (hier Version 3.4.8):

<syntaxhighlight lang=shell>
rbenv install 3.4.8
rbenv global 3.4.8
gem install bundler
rbenv rehash
</syntaxhighlight>

Der Befehl

<syntaxhighlight lang=shell>
ruby -v
</syntaxhighlight>

liefert die Ausgabe "ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [x86_64-linux]"

== Minimale Web Applikation mit Passenger ==

Zur Integration der eigenen Ruby-Installation in den Apache erfolgt über das Apache-Modul "Passenger".
Vor der Nutzung dieses Moduls bitte unbedingt die
[[Phusion Passenger|Hinweise zur Nutzung beachten]].

Für eine minimale Beispielanwendung legen wir eine Datei ''config.ru'' mit folgenden Inhalt an
("ru" kurz für "rackup"):

<syntaxhighlight lang=ruby line>
# config.ru

class App
def call(env)
headers = { 'Content-Type' => 'text/html' }
response = ['Greetings from Rack!!']
[200, headers, response]
end
end

run App.new
</syntaxhighlight>

== Sinatra Web Applikation mit Passenger ==

Um eine Beispielanwendung zu installieren, orientieren wir uns an https://github.com/phusion/passenger-ruby-sinatra-demo/tree/end_result

Im Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app-ssl/" legen wir folgende Dateien und Verzeichnisse an:

Gemfile:

<syntaxhighlight lang=ruby line>
source 'https://rubygems.org/'

gem 'sinatra'
gem 'tilt'
gem 'base64', '0.1.1'
</syntaxhighlight>

app.rb:

<syntaxhighlight lang=ruby line>
require 'sinatra/base'
require 'tilt/erb'

class ExampleApp < Sinatra::Base
get '/' do
erb :index
end
end
</syntaxhighlight>

config.ru:

<syntaxhighlight lang=ruby line>
require File.absolute_path("app.rb")

run ExampleApp
</syntaxhighlight>

views/index.erb:

<syntaxhighlight lang=html line>
<!DOCTYPE html>
<html>
<head><title>Hello</title></head>
<body>
<h1>Hello world!</h1>
<% if defined?(PhusionPassenger) %>
<p>Congratulations, you are running this app in Passenger!<br/>
You are running Ruby Version: <%= RUBY_VERSION %>
</p>
<% else %>
<p>You are not running this app in Passenger.</p>
<% end %>
</body>
</html>
</syntaxhighlight>

Im Verzeichnis "/home/pacs/xyz00/users/example/doms/example.com/app-ssl/" führen wir aus:

<syntaxhighlight lang=shell line>
bundle config --local path vendor/bundle
bundle install
</syntaxhighlight>

== Links ==

* https://www.writesoftwarewell.com/definitive-guide-to-rack/

----
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Spamfilter

2026-02-16T12:36:46Z

Hsh-peterhormanns: /* Eingangsserver konfigurieren */

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. Aktuell ist eine Gruppe von Eingangsserver mit der Software "rspamd" hinzugekommen. Eingehende Nachrichten mit 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]]

Spamfilter

2026-02-16T12:33:33Z

Hsh-peterhormanns: /* Eingangsserver konfigurieren */

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. Aktuell ist eine Gruppe von Eingangsserver mit der Software "rspamd" hinzugekommen. Eingehende Nachrichten mit 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 10 xmailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 xmailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 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>
10 xmailin2.hostsharing.net.
10 xmailin3.hostsharing.net.
10 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 "10").

= 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]]

Spamfilter

2026-02-16T12:31:32Z

Hsh-peterhormanns: /* Eingangsserver konfigurieren */

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. Aktuell ist eine Gruppe von Eingangsserver mit der Software "rspamd" hinzugekommen. Eingehende Nachrichten mit 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 10 xmailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 xmailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 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>
10 xmailin2.hostsharing.net.
10 xmailin3.hostsharing.net.
10 xmailin1.hostsharing.net.
</syntaxhighlight>

= 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]]

Spamfilter

2026-02-16T12:29:24Z

Hsh-peterhormanns: smailin -> xmailin

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. Aktuell ist eine Gruppe von Eingangsserver mit der Software "rspamd" hinzugekommen. Eingehende Nachrichten mit 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 10 xmailin1.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 xmailin2.hostsharing.net.
{DOM_HOSTNAME}. IN MX 10 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>

= 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]]

Spamfilter

2026-02-16T12:02:01Z

Hsh-peterhormanns: Umstellunge der Reihenfolge

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

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

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

3. Nutzung der Spam-Appliance "SecureMX"

= Alternative 1: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einem Domain-Administrator oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Die einzelnen Nutzer:innen können mit Hilfe des Hostsharing-Webmail einen Filter einrichten, so dass verdächtige Nachrichten in einem 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. 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ügt 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 Eingehen 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.

TODO:
* xmailin1,2,3 ergänzen
* Kontrolle der MX-Record mit "dig"
* Sieve Filter kann entfallen, weil global konfiguriert!

== 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 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]]

Spamfilter

2026-02-16T11:52:06Z

Hsh-peterhormanns: /* Eingangsserver konfigurieren */

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

1. Die Einrichtung von Spamassassin 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 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 2: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einem Domain-Administrator oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Die einzelnen Nutzer:innen können mit Hilfe des Hostsharing-Webmail einen Filter einrichten, so dass verdächtige Nachrichten in einem 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. 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ügt 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 Eingehen 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.

TODO:
* xmailin1,2,3 ergänzen
* Kontrolle der MX-Record mit "dig"
* Sieve Filter kann entfallen, weil global konfiguriert!

== 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 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]]

Spamfilter

2025-12-17T11:11:07Z

Hsh-peterhormanns: /* Spamassassin Konfigurieren */

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

1. Die Einrichtung von Spamassassin 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 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>
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ührt, der pro Mailbox eingerichtet werden muss.

= Alternative 2: Maileingangsserver mit Spamfilter nutzen =

Diese Alternative kann von einem Domain-Administrator oder vom "Webmaster on Demand" für eine oder mehrere E-Mail-Domains eingerichtet werden. Die einzelnen Nutzer:innen können mit Hilfe des Hostsharing-Webmail einen Filter einrichten, so dass verdächtige Nachrichten in einem 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. 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ügt 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 Eingehen 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 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]]

Tomcat Installieren

2025-09-30T10:48:11Z

Hsh-peterhormanns: /* Start des Tomcat Servers */

Apache Tomcat installieren

== Allgemein ==

[http://tomcat.apache.org/ Apache Tomcat] ist ein Webserver (HTTP-Server), der in der Programmiersprache Java entwickelt ist. Er dient in erster Linie dazu, dynamische Web-Anwendungen zu betreiben, die ebenfalls in Java programmiert sind. Basis-Technologien sind [http://de.wikipedia.org/wiki/Servlet Java-Servlets] und [http://de.wikipedia.org/wiki/JSP Java Server Pages (JSP)].

Mit Hilfe von Apache Tomcat ist bei Hostsharing das Hosting von komplexen Java Web-Applikationen problemlos möglich.

== Spezielle Installation bei Hostsharing ==

In jedem dynamischen Webhosting-Paket der Hostsharing eG können einer (oder mehrere) Tomcat-Webserver betrieben werden.

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 512 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.

Diese Anleitung dokumentiert die Installation des Apache Tomcat Servers als Service-User in einem WEB-Paket bei Hostsharing. Mit der Einrichtung der Option "eigener Serverdienst" werden für die Paket-IP-Adresse einer oder mehrere IP-Ports reserviert. An diese Ports wird der eigene Serverdienst (also der Tomcat-Server) am Localhost-Interface gebunden.

Bei der Anmeldung (bei service(at)hostsharing.net bitte angeben:

# den Service User, mit dessen Rechten der Tomcat-Dienst laufen soll (also zum Beispiel "xyz00-tomcat")
# wieviele IP-Ports reserviert werden sollen (in der folgenden Anleitung verwenden wir drei nicht-privilegierte Ports:
* 38005 als "Shutdown"-Schnittstelle
* 38006 für eine AJP-Listener

== Installation ==

Vorbemerkung: Mit Debian 12 ('Bookworm') wird Tomcat 10 von der Distribution mitgeliefert.

Auf den Hostsharing-Servern ist das Debian-Paket "tomcat10-user" installiert. Es stellt den
Apache Tomcat Server in der Version 10.1.x für den Betrieb als normaler (nicht privilegierter) User bereit.
Dabei wird die zentral installierte Tomcat-Software benutzt, die über Betriebssystem-Updates mit Sicherheits-Updates versorgt wird.

Für die Installation der Konfigurations-Dateien in Heimat-Verzeichnis des Benutzers wird folgender Befehl
mit den Rechten des Service-Users aufgerufen:

<syntaxhighlight lang="bash">
xyz00-tomcat@h00:~$ tomcat10-instance-create tomcat
</syntaxhighlight>

Ich bevorzuge das catalina.sh-Startskript zum Testen:

<syntaxhighlight lang="bash">
xyz00-tomcat@h00:~$ cp /usr/share/tomcat10/bin/catalina.sh tomcat/bin/
</syntaxhighlight>

Dieser Befehl legt ein Verzeichnis "tomcat" mit der üblichen Dateistruktur für einen Tomcat-Server an:

<syntaxhighlight lang="bash">
bin
bin/catalina.sh
bin/setenv.sh
bin/shutdown.sh
bin/startup.sh
conf
conf/catalina.properties
conf/context.xml
conf/jaspic-providers.xml
conf/logging.properties
conf/server.xml
conf/tomcat-users.xml
conf/web.xml
logs
policy
policy/catalina.policy
temp
webapps
work
</syntaxhighlight>

In der Hauptsache muss die Konfigurationsdatei "server.xml" im Verzeichnis "~/tomcat/conf/" angepasst werden.

Beispiel für eine minimale "server.xml":

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="38005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<Service name="Catalina">
<Connector protocol="AJP/1.3" address="127.0.0.1" port="38006" redirectPort="443" secretRequired="false" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="../webapps" unpackWARs="true" autoDeploy="true"></Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Angepasst werden müssen:
* die beiden IP-Ports (im Beispiel 38005 und 38006 am Localhost-Interface)

== Deployment einer Anwendung ==

In der Beispiel-Konfiguration wurde das Verzeichnis ''$HOME/webapps/'' für die Anwendungen konfiguriert. Wir legen dieses Verzeichnis an und kopieren eine minimale Anwendung hinein:

<syntaxhighlight lang="bash">
mkdir -p $HOME/webapps/hello/WEB-INF/
</syntaxhighlight>

Dort legen wir die Datei ~/webapps/hello/WEB-INF/web.xml mit folgendem Inhalt an:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
</web-app>
</syntaxhighlight>

Dazu eine einfache JSP-Datei ~/webapps/hello/index.jsp:

<syntaxhighlight lang="html" line>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html lang="de-de">
<body>
<h1>Hallo Welt</h1>
<p>Java Version: <%= System.getProperty("java.version") %></p>
</body>
</html>
</syntaxhighlight>

Nun können wir die HTTP-Requests, die an eine Domain im Paket gesendet werden, an den Tomcat weiterleiten.
Das funktioniert über eine ''.htaccess''-Datei, zum Beispiel im Verzeichnis ''~/doms/hs-example.de/htdocs-ssl'':

<syntaxhighlight lang="apache" line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^(.*) ajp://127.0.0.1:38006/$1 [proxy,last]
</syntaxhighlight>

Achtung der IP-Port 38006 muss hier wieder angepasst werden!

Dadurch ist die Mini-Anwendung unter der URL "https://hs-example.de/hello/" erreichbar.

== Start des Tomcat Servers ==

Der Tomcat kann über die Skripte in "~/tomcat/bin/" gestartet und gestoppt werden.

<syntaxhighlight lang="bash">
cd ~/tomcat
./bin/startup.sh
</syntaxhighlight>

Log-Ausgaben des Servers sind in "~/tomcat/logs/catalina.out" zu finden.

Damit der Tomcat bei einem Reboot der Hostsharing-Server automatisch gestartet wird,
konfigurieren wir den Prozessmonitor ''systemd'' entsprechend.

Wir legen ein Verzeichnis für die Konfiguration des ''systemd'' an und legen eine Unit-Konfiguration für einen Service dort ab:

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

Die Unit-Datei ''~/.config/systemd/user/tomcat.service''

<syntaxhighlight lang="ini" line>
[Unit]
Description=Tomcat User Service

[Service]
WorkingDirectory=%h/tomcat
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64"
Environment="JAVA_OPTS=-Xms256M -Xmx512M"
Environment="UMASK=0022"
ExecStart=%h/tomcat/bin/catalina.sh run
StandardOutput=append:%h/tomcat/logs/catalina.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Auf Wunsch kann ''SystemD'' RAM- und CPU-Ressourcen begrenzen. Dazu wird der Abschnitt ''Service'' ergänzt:

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

Die letzte Aufgabe ist das Einrichten der Bereinigung für die Log-Dateien.

Dazu lege ich die Konfigurationsdatei ''.logrotate'' im $HOME-Verzeichnis an:

<syntaxhighlight lang="bash" line>
/home/pacs/xyz00/users/tomcat/tomcat/logs/catalina.log {
copytruncate
compress
rotate 5
daily
missingok
}
</syntaxhighlight>

Für die Bereinigung der Log-Dateien noch zwei systemd-Timer:

~/.config/systemd/user/logrotate.service
<syntaxhighlight lang="bash" line>
[Unit]
Description=rotate tomcat logs

[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=rotate tomcat logs

[Timer]
OnCalendar=1:1
Persistent=True

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

~/.config/systemd/user/delete_old_logs.service
<syntaxhighlight lang="bash" line>
[Unit]
Description=delete old log files

[Service]
Type=oneshot
ExecStart=/usr/bin/find %h/tomcat/logs -type f -mmin +10080 -delete
</syntaxhighlight>

~/.config/systemd/user/delete_old_logs.timer
<syntaxhighlight lang="ini" line>
[Unit]
Description=delete old log files

[Timer]
OnCalendar=14:3
Persistent=True

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

Timer aktivieren und starten:
<syntaxhighlight lang="bash" line>
$ systemctl --user enable logrotate.timer
$ systemctl --user start logrotate.timer
$ systemctl --user enable delete_old_logs.timer
$ systemctl --user start delete_old_logs.timer
$ systemctl --user list-timers --all
</syntaxhighlight>

Dann gehen wir daran unsere Anwendungen im Tomcat zu deployen.

== Links ==

*[http://tomcat.apache.org/ Apache Tomcat Homepage (Englisch)]
*[http://tomcat.apache.org/tomcat-9.0-doc/index.html Apache Tomcat Dokumentation (Version 9.0, Englisch)]
*[http://wiki.apache.org/tomcat/FrontPage Apache Tomcat Wiki (Englisch)]
*[https://github.com/tpokorra/Hostsharing-Ansible-Tomcat Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Java]]
[[Kategorie:Eigene Daemons]]

Tomcat Installieren

2025-09-30T10:42:34Z

Hsh-peterhormanns: /* Start des Tomcat Servers */

Apache Tomcat installieren

== Allgemein ==

[http://tomcat.apache.org/ Apache Tomcat] ist ein Webserver (HTTP-Server), der in der Programmiersprache Java entwickelt ist. Er dient in erster Linie dazu, dynamische Web-Anwendungen zu betreiben, die ebenfalls in Java programmiert sind. Basis-Technologien sind [http://de.wikipedia.org/wiki/Servlet Java-Servlets] und [http://de.wikipedia.org/wiki/JSP Java Server Pages (JSP)].

Mit Hilfe von Apache Tomcat ist bei Hostsharing das Hosting von komplexen Java Web-Applikationen problemlos möglich.

== Spezielle Installation bei Hostsharing ==

In jedem dynamischen Webhosting-Paket der Hostsharing eG können einer (oder mehrere) Tomcat-Webserver betrieben werden.

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 512 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.

Diese Anleitung dokumentiert die Installation des Apache Tomcat Servers als Service-User in einem WEB-Paket bei Hostsharing. Mit der Einrichtung der Option "eigener Serverdienst" werden für die Paket-IP-Adresse einer oder mehrere IP-Ports reserviert. An diese Ports wird der eigene Serverdienst (also der Tomcat-Server) am Localhost-Interface gebunden.

Bei der Anmeldung (bei service(at)hostsharing.net bitte angeben:

# den Service User, mit dessen Rechten der Tomcat-Dienst laufen soll (also zum Beispiel "xyz00-tomcat")
# wieviele IP-Ports reserviert werden sollen (in der folgenden Anleitung verwenden wir drei nicht-privilegierte Ports:
* 38005 als "Shutdown"-Schnittstelle
* 38006 für eine AJP-Listener

== Installation ==

Vorbemerkung: Mit Debian 12 ('Bookworm') wird Tomcat 10 von der Distribution mitgeliefert.

Auf den Hostsharing-Servern ist das Debian-Paket "tomcat10-user" installiert. Es stellt den
Apache Tomcat Server in der Version 10.1.x für den Betrieb als normaler (nicht privilegierter) User bereit.
Dabei wird die zentral installierte Tomcat-Software benutzt, die über Betriebssystem-Updates mit Sicherheits-Updates versorgt wird.

Für die Installation der Konfigurations-Dateien in Heimat-Verzeichnis des Benutzers wird folgender Befehl
mit den Rechten des Service-Users aufgerufen:

<syntaxhighlight lang="bash">
xyz00-tomcat@h00:~$ tomcat10-instance-create tomcat
</syntaxhighlight>

Ich bevorzuge das catalina.sh-Startskript zum Testen:

<syntaxhighlight lang="bash">
xyz00-tomcat@h00:~$ cp /usr/share/tomcat10/bin/catalina.sh tomcat/bin/
</syntaxhighlight>

Dieser Befehl legt ein Verzeichnis "tomcat" mit der üblichen Dateistruktur für einen Tomcat-Server an:

<syntaxhighlight lang="bash">
bin
bin/catalina.sh
bin/setenv.sh
bin/shutdown.sh
bin/startup.sh
conf
conf/catalina.properties
conf/context.xml
conf/jaspic-providers.xml
conf/logging.properties
conf/server.xml
conf/tomcat-users.xml
conf/web.xml
logs
policy
policy/catalina.policy
temp
webapps
work
</syntaxhighlight>

In der Hauptsache muss die Konfigurationsdatei "server.xml" im Verzeichnis "~/tomcat/conf/" angepasst werden.

Beispiel für eine minimale "server.xml":

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="38005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<Service name="Catalina">
<Connector protocol="AJP/1.3" address="127.0.0.1" port="38006" redirectPort="443" secretRequired="false" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="../webapps" unpackWARs="true" autoDeploy="true"></Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Angepasst werden müssen:
* die beiden IP-Ports (im Beispiel 38005 und 38006 am Localhost-Interface)

== Deployment einer Anwendung ==

In der Beispiel-Konfiguration wurde das Verzeichnis ''$HOME/webapps/'' für die Anwendungen konfiguriert. Wir legen dieses Verzeichnis an und kopieren eine minimale Anwendung hinein:

<syntaxhighlight lang="bash">
mkdir -p $HOME/webapps/hello/WEB-INF/
</syntaxhighlight>

Dort legen wir die Datei ~/webapps/hello/WEB-INF/web.xml mit folgendem Inhalt an:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
</web-app>
</syntaxhighlight>

Dazu eine einfache JSP-Datei ~/webapps/hello/index.jsp:

<syntaxhighlight lang="html" line>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html lang="de-de">
<body>
<h1>Hallo Welt</h1>
<p>Java Version: <%= System.getProperty("java.version") %></p>
</body>
</html>
</syntaxhighlight>

Nun können wir die HTTP-Requests, die an eine Domain im Paket gesendet werden, an den Tomcat weiterleiten.
Das funktioniert über eine ''.htaccess''-Datei, zum Beispiel im Verzeichnis ''~/doms/hs-example.de/htdocs-ssl'':

<syntaxhighlight lang="apache" line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^(.*) ajp://127.0.0.1:38006/$1 [proxy,last]
</syntaxhighlight>

Achtung der IP-Port 38006 muss hier wieder angepasst werden!

Dadurch ist die Mini-Anwendung unter der URL "https://hs-example.de/hello/" erreichbar.

== Start des Tomcat Servers ==

Der Tomcat kann über die Skripte in "~/tomcat/bin/" gestartet und gestoppt werden.

<syntaxhighlight lang="bash">
cd ~/tomcat
./bin/startup.sh
</syntaxhighlight>

Log-Ausgaben des Servers sind in "~/tomcat/logs/catalina.out" zu finden.

Damit der Tomcat bei einem Reboot der Hostsharing-Server automatisch gestartet wird,
konfigurieren wir den Prozessmonitor ''systemd'' entsprechend.

Wir legen ein Verzeichnis für die Konfiguration des ''systemd'' an und legen eine Unit-Konfiguration für einen Service dort ab:

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

Die Unit-Datei ''~/.config/systemd/user/tomcat.service''

<syntaxhighlight lang="ini" line>
[Unit]
Description=Tomcat User Service

[Service]
WorkingDirectory=%h/tomcat
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64"
Environment="JAVA_OPTS=-Xms256M -Xmx512M"
Environment="UMASK=0022"
ExecStart=%h/tomcat/bin/catalina.sh run
StandardOutput=append:%h/tomcat/logs/catalina.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Auf Wunsch kann ''SystemD'' RAM- und CPU-Ressourcen begrenzen. Dazu wird der Abschnitt ''Service'' ergänzt:

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

Die letzte Aufgabe ist das Einrichten der Bereinigung für die Log-Dateien.

Dazu lege ich die Konfigurationsdatei ''.logrotate'' im $HOME-Verzeichnis an:

<syntaxhighlight lang="bash" line>
/home/pacs/xyz00/users/tomcat/tomcat/logs/catalina.log {
copytruncate
compress
rotate 5
daily
missingok
}
</syntaxhighlight>

Für die Bereinigung der Log-Dateien noch zwei systemd-Timer:

~/.config/systemd/user/logrotate.service
<syntaxhighlight lang="bash" line>
[Unit]
Description=rotate tomcat logs

[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=rotate tomcat logs

[Timer]
OnCalendar=1:1
Persistent=True

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

~/.config/systemd/user/delete_old_logs.service
<syntaxhighlight lang="bash" line>
[Unit]
Description=delete old log files

[Service]
Type=oneshot
ExecStart=/usr/bin/find %h/tomcat/logs -type f -mmin +10080 -delete
</syntaxhighlight>

~/.config/systemd/user/delete_old_logs.timer
<syntaxhighlight lang="ini" line>
[Unit]
Description=delete old log files

[Timer]
OnCalendar=14:3
Persistent=True

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

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

Dann gehen wir daran unsere Anwendungen im Tomcat zu deployen.

== Links ==

*[http://tomcat.apache.org/ Apache Tomcat Homepage (Englisch)]
*[http://tomcat.apache.org/tomcat-9.0-doc/index.html Apache Tomcat Dokumentation (Version 9.0, Englisch)]
*[http://wiki.apache.org/tomcat/FrontPage Apache Tomcat Wiki (Englisch)]
*[https://github.com/tpokorra/Hostsharing-Ansible-Tomcat Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Java]]
[[Kategorie:Eigene Daemons]]

Tomcat Installieren

2025-09-30T10:35:48Z

Hsh-peterhormanns: /* Start des Tomcat Servers */

Apache Tomcat installieren

== Allgemein ==

[http://tomcat.apache.org/ Apache Tomcat] ist ein Webserver (HTTP-Server), der in der Programmiersprache Java entwickelt ist. Er dient in erster Linie dazu, dynamische Web-Anwendungen zu betreiben, die ebenfalls in Java programmiert sind. Basis-Technologien sind [http://de.wikipedia.org/wiki/Servlet Java-Servlets] und [http://de.wikipedia.org/wiki/JSP Java Server Pages (JSP)].

Mit Hilfe von Apache Tomcat ist bei Hostsharing das Hosting von komplexen Java Web-Applikationen problemlos möglich.

== Spezielle Installation bei Hostsharing ==

In jedem dynamischen Webhosting-Paket der Hostsharing eG können einer (oder mehrere) Tomcat-Webserver betrieben werden.

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "RAM". Benötigt werden min. 512 MB. Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/ gebucht werden muss der RAM auch bei einem Managed-Server.

Diese Anleitung dokumentiert die Installation des Apache Tomcat Servers als Service-User in einem WEB-Paket bei Hostsharing. Mit der Einrichtung der Option "eigener Serverdienst" werden für die Paket-IP-Adresse einer oder mehrere IP-Ports reserviert. An diese Ports wird der eigene Serverdienst (also der Tomcat-Server) am Localhost-Interface gebunden.

Bei der Anmeldung (bei service(at)hostsharing.net bitte angeben:

# den Service User, mit dessen Rechten der Tomcat-Dienst laufen soll (also zum Beispiel "xyz00-tomcat")
# wieviele IP-Ports reserviert werden sollen (in der folgenden Anleitung verwenden wir drei nicht-privilegierte Ports:
* 38005 als "Shutdown"-Schnittstelle
* 38006 für eine AJP-Listener

== Installation ==

Vorbemerkung: Mit Debian 12 ('Bookworm') wird Tomcat 10 von der Distribution mitgeliefert.

Auf den Hostsharing-Servern ist das Debian-Paket "tomcat10-user" installiert. Es stellt den
Apache Tomcat Server in der Version 10.1.x für den Betrieb als normaler (nicht privilegierter) User bereit.
Dabei wird die zentral installierte Tomcat-Software benutzt, die über Betriebssystem-Updates mit Sicherheits-Updates versorgt wird.

Für die Installation der Konfigurations-Dateien in Heimat-Verzeichnis des Benutzers wird folgender Befehl
mit den Rechten des Service-Users aufgerufen:

<syntaxhighlight lang="bash">
xyz00-tomcat@h00:~$ tomcat10-instance-create tomcat
</syntaxhighlight>

Ich bevorzuge das catalina.sh-Startskript zum Testen:

<syntaxhighlight lang="bash">
xyz00-tomcat@h00:~$ cp /usr/share/tomcat10/bin/catalina.sh tomcat/bin/
</syntaxhighlight>

Dieser Befehl legt ein Verzeichnis "tomcat" mit der üblichen Dateistruktur für einen Tomcat-Server an:

<syntaxhighlight lang="bash">
bin
bin/catalina.sh
bin/setenv.sh
bin/shutdown.sh
bin/startup.sh
conf
conf/catalina.properties
conf/context.xml
conf/jaspic-providers.xml
conf/logging.properties
conf/server.xml
conf/tomcat-users.xml
conf/web.xml
logs
policy
policy/catalina.policy
temp
webapps
work
</syntaxhighlight>

In der Hauptsache muss die Konfigurationsdatei "server.xml" im Verzeichnis "~/tomcat/conf/" angepasst werden.

Beispiel für eine minimale "server.xml":

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="38005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container"
type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>
<Service name="Catalina">
<Connector protocol="AJP/1.3" address="127.0.0.1" port="38006" redirectPort="443" secretRequired="false" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="../webapps" unpackWARs="true" autoDeploy="true"></Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Angepasst werden müssen:
* die beiden IP-Ports (im Beispiel 38005 und 38006 am Localhost-Interface)

== Deployment einer Anwendung ==

In der Beispiel-Konfiguration wurde das Verzeichnis ''$HOME/webapps/'' für die Anwendungen konfiguriert. Wir legen dieses Verzeichnis an und kopieren eine minimale Anwendung hinein:

<syntaxhighlight lang="bash">
mkdir -p $HOME/webapps/hello/WEB-INF/
</syntaxhighlight>

Dort legen wir die Datei ~/webapps/hello/WEB-INF/web.xml mit folgendem Inhalt an:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<web-app
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
id="WebApp_ID" version="3.0">
</web-app>
</syntaxhighlight>

Dazu eine einfache JSP-Datei ~/webapps/hello/index.jsp:

<syntaxhighlight lang="html" line>
<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<html lang="de-de">
<body>
<h1>Hallo Welt</h1>
<p>Java Version: <%= System.getProperty("java.version") %></p>
</body>
</html>
</syntaxhighlight>

Nun können wir die HTTP-Requests, die an eine Domain im Paket gesendet werden, an den Tomcat weiterleiten.
Das funktioniert über eine ''.htaccess''-Datei, zum Beispiel im Verzeichnis ''~/doms/hs-example.de/htdocs-ssl'':

<syntaxhighlight lang="apache" line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^(.*) ajp://127.0.0.1:38006/$1 [proxy,last]
</syntaxhighlight>

Achtung der IP-Port 38006 muss hier wieder angepasst werden!

Dadurch ist die Mini-Anwendung unter der URL "https://hs-example.de/hello/" erreichbar.

== Start des Tomcat Servers ==

Der Tomcat kann über die Skripte in "~/tomcat/bin/" gestartet und gestoppt werden.

<syntaxhighlight lang="bash">
cd ~/tomcat
./bin/startup.sh
</syntaxhighlight>

Log-Ausgaben des Servers sind in "~/tomcat/logs/catalina.out" zu finden.

Damit der Tomcat bei einem Reboot der Hostsharing-Server automatisch gestartet wird,
konfigurieren wir den Prozessmonitor ''systemd'' entsprechend.

Wir legen ein Verzeichnis für die Konfiguration des ''systemd'' an und legen eine Unit-Konfiguration für einen Service dort ab:

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

Die Unit-Datei ''~/.config/systemd/user/tomcat.service''

<syntaxhighlight lang="ini" line>
[Unit]
Description=Tomcat User Service

[Service]
WorkingDirectory=%h/tomcat
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="JAVA_HOME=/usr/lib/jvm/java-17-openjdk-amd64"
Environment="JAVA_OPTS=-Xms256M -Xmx512M"
Environment="UMASK=0022"
ExecStart=%h/tomcat/bin/catalina.sh run
StandardOutput=append:%h/tomcat/logs/catalina.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Auf Wunsch kann ''SystemD'' RAM- und CPU-Ressourcen begrenzen. Dazu wird der Abschnitt ''Service'' ergänzt:

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

Die letzte Aufgabe ist das Einrichten der Bereinigung für die Log-Dateien.

Dazu lege ich die Konfigurationsdatei ''.logrotate'' im $HOME-Verzeichnis an:

<syntaxhighlight lang="bash" line>
/home/pacs/xyz00/users/tomcat/tomcat/logs/catalina.log {
copytruncate
compress
rotate 5
daily
missingok
}
</syntaxhighlight>

Für die Bereinigung der Log-Dateien noch zwei systemd-Timer:

~/.config/systemd/user/logrotate.service
<syntaxhighlight lang="bash" line>
[Unit]
Description=rotate tomcat logs

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

~/.config/systemd/user/logrotate.timer
<syntaxhighlight lang="ini" line>
[Unit]
Description=rotate tomcat logs

[Timer]
OnCalendar=1:1
Persistent=True

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

~/.config/systemd/user/delete_old_logs.service
<syntaxhighlight lang="bash" line>
[Unit]
Description=delete old log files

[Service]
Type=oneshot
ExecStart=/usr/bin/find /home/pacs/xyz00/users/tomcat/tomcat/logs -type f -mmin +10080 -delete
</syntaxhighlight>

~/.config/systemd/user/delete_old_logs.timer
<syntaxhighlight lang="ini" line>
[Unit]
Description=delete old log files

[Timer]
OnCalendar=14:3
Persistent=True

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

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

Dann gehen wir daran unsere Anwendungen im Tomcat zu deployen.

== Links ==

*[http://tomcat.apache.org/ Apache Tomcat Homepage (Englisch)]
*[http://tomcat.apache.org/tomcat-9.0-doc/index.html Apache Tomcat Dokumentation (Version 9.0, Englisch)]
*[http://wiki.apache.org/tomcat/FrontPage Apache Tomcat Wiki (Englisch)]
*[https://github.com/tpokorra/Hostsharing-Ansible-Tomcat Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Java]]
[[Kategorie:Eigene Daemons]]

RechteSchleuse

2025-05-21T16:46:21Z

Hsh-peterhormanns: kein Lesen-für-alle am $HOME

= Rechte-Schleuse =

Die Domains liegen bei Hostsharing in einem Unterverzeichnis ~/doms der einzelnen User.
Damit der Apache-Webserver die Dateien erreichen kann und die Dateien andererseits nicht allgemein
zugänglich sind, gibt es die sog. "Rechte-Schleuse".

Die Rechte müssen wie folgt gesetzt sein:

<syntaxhighlight lang=output>
xyz00-abc@h03:~$ ls -ld . doms/ doms/example.com/ doms/example.com/*
drwxr-x--- 5 xyz00-abc httpd 76 Oct 13 2010 .
dr-xr-x--T 5 httpd xyz00 47 Feb 22 2011 doms/
drwxr-x--- 12 xyz00-abc httpd 138 Feb 22 2011 doms/example.com/
drwxr-xr-x 2 xyz00-abc xyz00 21 Feb 22 2011 doms/example.com/cgi
drwxr-xr-x 2 xyz00-abc xyz00 21 Feb 22 2011 doms/example.com/cgi-ssl
drwxr-xr-x 2 xyz00-abc xyz00 6 Feb 22 2011 doms/example.com/etc
drwxr-xr-x 2 xyz00-abc xyz00 20 Feb 22 2011 doms/example.com/fastcgi
drwxr-xr-x 2 xyz00-abc xyz00 20 Feb 22 2011 doms/example.com/fastcgi-ssl
drwxr-xr-x 2 xyz00-abc xyz00 22 Feb 22 2011 doms/example.com/htdocs
drwxr-xr-x 2 xyz00-abc xyz00 22 Feb 22 2011 doms/example.com/htdocs-ssl
drwxr-xr-x 3 xyz00-abc xyz00 16 Feb 22 2011 doms/example.com/subs
drwxr-xr-x 3 xyz00-abc xyz00 16 Feb 22 2011 doms/example.com/subs/www
drwxr-xr-x 3 xyz00-abc xyz00 16 Feb 22 2011 doms/example.com/subs-ssl
drwxr-xr-x 3 xyz00-abc xyz00 16 Feb 22 2011 doms/example.com/subs-ssl/www
drwxr-xr-x 2 xyz00-abc xyz00 6 Feb 22 2011 doms/example.com/var
</syntaxhighlight>

[[Kategorie:HSDoku]]

Monit installieren

2025-02-14T13:46:24Z

Hsh-peterhormanns: Starte Monit im init-mode, nicht im daemon-mode

== Über Monit ==

Monit ist ein ressourcensparendes Programm zur Überwachung eines Server oder von [[Daemon|Diensten ("Daemons")]] auf einem Server.

Es fragt regelmäßig den Zustand des zu überwachenden Prozesses ab und kann bei einem Absturz den Prozess selbstständig neu starten. Für Betriebssystem-Ressourcen, wie Festplatten-Kapazität oder CPU- und RAM-Auslastung, können Schwellwerte angegeben werden, bei deren Überschreitung Monit per E-Mail alarmiert und in eine Log-Datei protokolliert.

In dieser Beschreibung wird der Start des Servers und von Monit durch den Paketadmin angenommen. Sollte ein davon verschiedener Domain-Admin der "Befehlshaber" sein, so müssen die Pfade entsprechend korrigiert werden. Von "/home/pacs/xyz00" zu "/home/pacs/xyz00/users/user".

{{Textkasten|rot|Besser systemd benutzen|Achtung: wir empfehlen nicht mehr den Einsatz von monit als Prozessmanager. Alle Anwendungen sollten mit [[Prozessmanagement mit systemd im Userspace|Systemd im Userspace]] gestartet werden. Monit kann weiterhin zur Überwachung des Servers eingesetzt werden.}}

== Konfiguration ==

Monit sucht seine Konfiguration beim Start zuerst in der Datei ~/.monitrc im Homeverzeichnis des Users, der monit startet.

Wir erstellen also diese Datei im Hauptverzeichnis des Users und sorgen dafür, dass sie nur von diesem gelesen und beschrieben werden kann:

<syntaxhighlight lang=shell>
xyz00@hxx:~$ cd
xyz00@hxx:~$ touch .monitrc
xyz00@hxx:~$ chmod 0600 .monitrc
xyz00@hxx:~$ edit .monitrc
</syntaxhighlight>

Und füllen sie mit folgendem Inhalt:

<syntaxhighlight lang=shell>
set init
set daemon 600
set logfile /home/pacs/xyz00/var/monit.log
set mailserver localhost
set alert admin@example.tld

check process apache2 with pidfile /home/pacs/xyz00/etc/apache2/run/apache2.pid
start program "/bin/bash -c '/home/pacs/xyz00/etc/apache2/apache2_start'"
stop program "/bin/bash -c '/home/pacs/xyz00/etc/apache2/apache2_stop'"
if failed host example.tld port 8080 with timeout 60 seconds then restart
</syntaxhighlight>

'''Achtung:''' Dieses Beispiel geht davon aus, dass die entsprechenden Start- und Stopskripte existieren und der Pfad zum pidfile des Apachen stimmt.

== Monit Starten und Stoppen ==

Wird nun per systemd realisiert dazu

noch einen systemd service für Monit anlegen:

''~/.config/systemd/user/monit.service''
<syntaxhighlight lang=ini>
[Unit]
Description=monit

[Service]
ExecStartPre=rm -f %h/.monit.id
ExecStart=/usr/bin/monit -c %h/.monitrc

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

Service aktivieren und starten:

<syntaxhighlight lang=shell>
$ systemctl --user enable monit.service
$ systemctl --user start monit.service
</syntaxhighlight>

== Managed Server monitoren ==

Bei der Nutzung eines Managed Server ist das Hostsharing-Mitglied selbst dafür verantwortlich, die Ressourcen des Servers
ausreichend zu dimensionieren. Monit kann helfen Engpässe zu entdecken.

Mit den folgenden Zeilen in der .monitrc wird bei der Überschreitung von bestimmten Schwellwerten beim Load,
bei der RAM- und CPU-Auslastung und der Festplatten-Auslastung der E-Mail alarmiert und ins monit.log protokolliert:

<syntaxhighlight lang=shell line>
check system h00.hostsharing.net
if loadavg (1min) > 5 then alert
if loadavg (5min) > 3 then alert
if memory usage > 85% then alert
if cpu usage (user) > 70% then alert
if cpu usage (system) > 30% then alert
if cpu usage (wait) > 20% then alert

check device datafs with path /dev/vda2
if failed permission 0660 then alert
if failed uid root then alert
if failed gid "disk" then alert
if space usage > 85 % then alert
if inode usage > 85 % then alert
</syntaxhighlight>

== Logfiles kontrollieren ==

Monit loggt entsprechend der Konfiguration seine "Taten" in ~/var/monit.log

Damit das Logfile nicht zu groß wird, benutzen wir '''logrotate''', das von [[cron]] aufgerufen wird, einmal pro Woche das Logfile komprimiert und zwei alte Versionen hält. Dazu erstellen wir die Konfigdatei .logrotate im Hauptverzeichnis des Users:

<syntaxhighlight lang=shell>
touch .logrotate
</syntaxhighlight>

Darin schreiben wir:

<syntaxhighlight lang=shell line>
compress

/home/pacs/xyz00/var/monit.log {
rotate 2
weekly
}
</syntaxhighlight>

Nun brauchen wir noch einen Aufruf von logrotate durch [[cron]]. Bitte beachten, logrotate merkt sich den letzten Zustand der Logdatei in einem Statusfile. Das muss in der [[Cron#Crontab|crontab]] mit angegeben werden. Wir editieren die crontab und schreiben:

<syntaxhighlight lang=shell line>
27 7 * * 5 logrotate -s /home/pacs/xyz00/.logrotate_state /home/pacs/xyz00/.logrotate
</syntaxhighlight>

Damit wird jeden Freitag um 7:27 Uhr das monit.log "rotiert". '''Achtung:''' bitte einen anderen Tag und eine andere Uhrzeit wählen, damit nicht alle logrotates zur gleichen Zeit starten.

== externe Links ==

* [https://www.mmonit.com/monit/ Monit Homepage]
* [https://www.mmonit.com/monit/documentation/monit.html Monit Dokumentation]
* [https://www.mmonit.com/wiki/ Monit Wiki]

[[Kategorie:Installationsanleitungen]]
[[Kategorie:eigene Daemons]]
[[Kategorie:Managed Server]]

Domains

2025-02-14T11:23:02Z

Hsh-peterhormanns: Ljnk auf Kerndoku oben

{{HSDoku-DomainLinks}}
__NOTOC__

= Domains bei Hostsharing =

aktuelle Dokumentation:

{{Kerndoku|https://www.hostsharing.net/doc/managed-operations-platform/domain/}}

Die Domainverwaltung bei Hostsharing ist in zwei unabhängige Bereiche aufgeteilt:

* Die '''Domaineinrichtung''' in den HS-Paketen, zur Erstellung des Domainverzeichnisses unter [[~/]]doms im Paket und [[Aufschaltung]] einer Domain auf HS [[DNS|Name]]-, Mail- und Webserver. Dies geschieht mit [[hsadmin]] im Webfrontend oder auf der Kommandozeile.

* Das '''[http://www.domain-bestellsystem.de Domainbestellsystem]''' des HS-Partnerunternehmens Partnergate zur [[Konnektierung]], also der eigentlichen Registrierung von Domains bei einem Registrar, und zur Vergabe weiterer Aufträgen an Registrierungstellen. Jedes Mitglied von Hostsharing erhielt für dieses Domainbestellsystem Zugangsdaten, bestehend aus einem Benutzernamen der Form hs-xyz und einem Passwort.

Bei anderen Hostern ist eine Domainbestellung teilweise eine feste Kopplung der Registrierung einer Domain mit Konnektierung und gleichzeitiger Aufschaltung auf bestimmte Nameserver und Webpakete. HS ist hier wesentlich flexibler. Der über HS angebotene Zugang zum Domain-Bestellsystem erlaubt es, Domains zu registrieren und auf frei wählbare DNS-Server zu konnektieren. Auf den HS Nameservern und Paketen lassen sich gleichzeitig beliebige weltweit registrierbare Domains einrichten. Hostsharing unterstützt damit die Einrichtung und den Betrieb von Domains die von beliebigen (auch sehr exotischen) Registrierungsstellen verwaltet und abgerechnet werden können.

= Aktionen =

Typische Domainaktionen beinhalten also koordinierte Änderungen sowohl in der Domainregistrierung als auch der HS-Einrichtung, wie in folgenden Seiten aufgezeigt:

* Eine Domain einrichten: [[Domainregistrierung]]<br>
* Eine Domain kündigen: [[Domainkündigung]]<br>
* Verwalten von Domains, Subdomains, Eigentümer, Nameserver: [[Domainverwaltung]]<br>

= Weiterführende Links =

Was ist eine [[Domain]]<br>
Was ist ein [[Handles|Domainhandle]]<br>
[[FAQ#Domains|Einträge zu Domains in der HS FAQ]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Domains]]

DeltaChat

2025-02-14T10:37:19Z

Hsh-peterhormanns: /* Einrichtung von Postfächern */

== Delta Chat ==

DeltaChat ist eine Messenger für Ende-zu-Ende-verschlüsselte Kommunikation mit Kurznachrichten. Die Funktionalität ist mit Signal, Threema oder WhatsApp oder mit den OpenSource Protokollen Matrix oder XMPP vergleichbar. Der Vorteil ist hier, dass DeltChat die Standard-Protokolle SMTP und IMAP verwendet, die Basis für die E-Mail Kommunikation sind. Diese Infrastruktur ist bei Hostsharing vorhanden und wird von der Genossenschaft gepflegt.

Eigentlich könnte diese Seite also leer bleiben: Es gibt keine DeltaChat-Software, die Hostsharing-Mitlgieder auf ihrem Server oder in ihrem Webspace installieren müssten. IMAP- und SMTP-Server sind als gemanagete Komponenten vorhanden.

=== Vorbereitungen für die Nutzung von DeltaChat ===

Grundsätzlich kann man das normale Postfach auch für die Kommunikation mit DeltaChat nutzen. Oft wird als Argument für DeltaChat angeführt, dass man mit DeltaChat mit jeder E-Mail-Adresse kommunizieren kann. Ich empfehle das ausdrücklich nicht!

==== Einrichtung einer Domain ====

Daher richte ich für DeltaChat eine eigene Domain oder Subdomain ein. In diesem Artikel soll die Domain "chat.hs-example.de" sein.

Ich lege einen Account als Domain-Verwaltung für die Domain ein und schalte die Domain bei diesem Account auf. Es ist sinnvoll für die Domain "Greylisting" zu deaktivieren. "DKIM" und "E-Mail-Autokonfiguration" sollten auf jeden Fall eingeschaltet bleiben!

==== Anpassung des Zonefile ====

Grundsätzlich kann dieser Schritt übersprungen werden. Ich habe das Zonefile etwas vereinfacht und an die Konfiguration eines Chatmail-Server für DeltaChat angepasst.

<syntaxhighlight lang="text" line>
{HEADER}
{SOA_RR}
{NS_RR}
{A_RR}
{AAAA_RR}
mta-sts.{DOM_HOSTNAME}. CNAME {DOM_HOSTNAME}.
www.{DOM_HOSTNAME}. CNAME {DOM_HOSTNAME}.
{MX_RR}
{MAILSERVICES_RR} {SPF_RR}
_dmarc.{DOM_HOSTNAME}. TXT "v=DMARC1;p=reject;adkim=s;aspf=s"
_mta-sts.{DOM_HOSTNAME}. TXT "v=STSv1; id=202407031637"
{DKIM_RR}
_adsp._domainkey.{DOM_HOSTNAME}. TXT "dkim=discardable"
</syntaxhighlight>

Für das "MTA-STS"-Verfahren muss zusätzliche eine kleine Textdatei unter URL "https://mta-sts.chat.example.com/.well-known/mta-sts.txt" der Subdomain "mts-sts" abgelegt werden. Der Inhalt zum Beispiel:

<syntaxhighlight lang="text" line>
version: STSv1
mode: enforce
mx: mailin1.hostsharing.net
mx: mailin2.hostsharing.net
mx: mailin3.hostsharing.net
max_age: 2419200
</syntaxhighlight>

==== Einrichtung von Postfächern ====

Anschließend richte ich für jede Person, die DeltaChat nutzen soll ein Postfach und eine E-Mail-Adresse ein. Wenn die Accounts weitgehend anonym sein sollen, könnten die DeltaChat-Adressen so aussehen: "chat.295048@chat.hs-example.de" und "chat.873610@chat.hs-example.de".

Sei mein Webspace "xyz99". In HSAdmin richte ich also Postfächer (User) ein: "xyz99-chat.295048" und "xyz99-chat.873610". Wenn man für die User eine Quota für die SSD angibt, wird der Speicherbedarf in der DeltaChat-App auch angezeigt. Allerdings müssen alte Nachrichten auch gelöscht werden, sonst werden nach Überschreitung des Hardlimit oder der Gracetime keine Nachrichten mehr angenommen.

Im letzten Schritt lege ich in HSAdmin die E-Mail-Adressen für DeltaChat an. Also die erste Adresse mit:

* lokaler Teil: "chat.295048"
* Domain: "chat.hs-example.de"
* Postfach/Weiterleitung (Postfach wählen): "xyz99-chat.295048"

Das Feld "subdomain" bleibt leer. Die zweite und ggf. weitere Adressen analog anlegen.

== Links ==

* https://get.delta.chat/
* https://github.com/deltachat/interface/blob/main/uri-schemes.md

[[Kategorie:Messenger]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

DeltaChat

2025-02-14T10:36:31Z

Hsh-peterhormanns: /* Einrichtung von Postfächern */

== Delta Chat ==

DeltaChat ist eine Messenger für Ende-zu-Ende-verschlüsselte Kommunikation mit Kurznachrichten. Die Funktionalität ist mit Signal, Threema oder WhatsApp oder mit den OpenSource Protokollen Matrix oder XMPP vergleichbar. Der Vorteil ist hier, dass DeltChat die Standard-Protokolle SMTP und IMAP verwendet, die Basis für die E-Mail Kommunikation sind. Diese Infrastruktur ist bei Hostsharing vorhanden und wird von der Genossenschaft gepflegt.

Eigentlich könnte diese Seite also leer bleiben: Es gibt keine DeltaChat-Software, die Hostsharing-Mitlgieder auf ihrem Server oder in ihrem Webspace installieren müssten. IMAP- und SMTP-Server sind als gemanagete Komponenten vorhanden.

=== Vorbereitungen für die Nutzung von DeltaChat ===

Grundsätzlich kann man das normale Postfach auch für die Kommunikation mit DeltaChat nutzen. Oft wird als Argument für DeltaChat angeführt, dass man mit DeltaChat mit jeder E-Mail-Adresse kommunizieren kann. Ich empfehle das ausdrücklich nicht!

==== Einrichtung einer Domain ====

Daher richte ich für DeltaChat eine eigene Domain oder Subdomain ein. In diesem Artikel soll die Domain "chat.hs-example.de" sein.

Ich lege einen Account als Domain-Verwaltung für die Domain ein und schalte die Domain bei diesem Account auf. Es ist sinnvoll für die Domain "Greylisting" zu deaktivieren. "DKIM" und "E-Mail-Autokonfiguration" sollten auf jeden Fall eingeschaltet bleiben!

==== Anpassung des Zonefile ====

Grundsätzlich kann dieser Schritt übersprungen werden. Ich habe das Zonefile etwas vereinfacht und an die Konfiguration eines Chatmail-Server für DeltaChat angepasst.

<syntaxhighlight lang="text" line>
{HEADER}
{SOA_RR}
{NS_RR}
{A_RR}
{AAAA_RR}
mta-sts.{DOM_HOSTNAME}. CNAME {DOM_HOSTNAME}.
www.{DOM_HOSTNAME}. CNAME {DOM_HOSTNAME}.
{MX_RR}
{MAILSERVICES_RR} {SPF_RR}
_dmarc.{DOM_HOSTNAME}. TXT "v=DMARC1;p=reject;adkim=s;aspf=s"
_mta-sts.{DOM_HOSTNAME}. TXT "v=STSv1; id=202407031637"
{DKIM_RR}
_adsp._domainkey.{DOM_HOSTNAME}. TXT "dkim=discardable"
</syntaxhighlight>

Für das "MTA-STS"-Verfahren muss zusätzliche eine kleine Textdatei unter URL "https://mta-sts.chat.example.com/.well-known/mta-sts.txt" der Subdomain "mts-sts" abgelegt werden. Der Inhalt zum Beispiel:

<syntaxhighlight lang="text" line>
version: STSv1
mode: enforce
mx: mailin1.hostsharing.net
mx: mailin2.hostsharing.net
mx: mailin3.hostsharing.net
max_age: 2419200
</syntaxhighlight>

==== Einrichtung von Postfächern ====

Anschließend richte ich für jede Person, die DeltaChat nutzen soll ein Postfach und eine E-Mail-Adresse ein. Wenn die Accounts weitgehend anonym sein sollen, könnten die DeltaChat-Adressen so aussehen: "chat.295048@chat.hs-example.de" und "chat.873610@chat.hs-example.de".

Sei mein Webspace "xyz99". In HSAdmin richte ich also Postfächer (User) ein: "xyz99-chat.295048" und "xyz99-chat.873610". Wenn man für die User eine Quota für die SSD angibt, wird der Speicherbedarf in der DeltaChat-App auch angezeigt. Allerdings müssen alte Nachrichten auch gelöscht werden, sonst werden nach Überschreitung des Hardlimit oder der Gracetime keine Nachrichten mehr angenommen.

Im letzten Schritt lege ich in HSAdmin die E-Mail-Adressen für DeltaChat an. Also die erste Adresse mit:

* lokaler Teil: "chat.295048"
* Domain: "chat.example.com"
* Postfach/Weiterleitung (Postfach wählen): "xyz99-chat.295048"

Das Feld "subdomain" bleibt leer. Die zweite und ggf. weitere Adressen analog anlegen.

== Links ==

* https://get.delta.chat/
* https://github.com/deltachat/interface/blob/main/uri-schemes.md

[[Kategorie:Messenger]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

DeltaChat

2025-02-14T10:34:20Z

Hsh-peterhormanns: /* Anpassung des Zonefile */

== Delta Chat ==

DeltaChat ist eine Messenger für Ende-zu-Ende-verschlüsselte Kommunikation mit Kurznachrichten. Die Funktionalität ist mit Signal, Threema oder WhatsApp oder mit den OpenSource Protokollen Matrix oder XMPP vergleichbar. Der Vorteil ist hier, dass DeltChat die Standard-Protokolle SMTP und IMAP verwendet, die Basis für die E-Mail Kommunikation sind. Diese Infrastruktur ist bei Hostsharing vorhanden und wird von der Genossenschaft gepflegt.

Eigentlich könnte diese Seite also leer bleiben: Es gibt keine DeltaChat-Software, die Hostsharing-Mitlgieder auf ihrem Server oder in ihrem Webspace installieren müssten. IMAP- und SMTP-Server sind als gemanagete Komponenten vorhanden.

=== Vorbereitungen für die Nutzung von DeltaChat ===

Grundsätzlich kann man das normale Postfach auch für die Kommunikation mit DeltaChat nutzen. Oft wird als Argument für DeltaChat angeführt, dass man mit DeltaChat mit jeder E-Mail-Adresse kommunizieren kann. Ich empfehle das ausdrücklich nicht!

==== Einrichtung einer Domain ====

Daher richte ich für DeltaChat eine eigene Domain oder Subdomain ein. In diesem Artikel soll die Domain "chat.hs-example.de" sein.

Ich lege einen Account als Domain-Verwaltung für die Domain ein und schalte die Domain bei diesem Account auf. Es ist sinnvoll für die Domain "Greylisting" zu deaktivieren. "DKIM" und "E-Mail-Autokonfiguration" sollten auf jeden Fall eingeschaltet bleiben!

==== Anpassung des Zonefile ====

Grundsätzlich kann dieser Schritt übersprungen werden. Ich habe das Zonefile etwas vereinfacht und an die Konfiguration eines Chatmail-Server für DeltaChat angepasst.

<syntaxhighlight lang="text" line>
{HEADER}
{SOA_RR}
{NS_RR}
{A_RR}
{AAAA_RR}
mta-sts.{DOM_HOSTNAME}. CNAME {DOM_HOSTNAME}.
www.{DOM_HOSTNAME}. CNAME {DOM_HOSTNAME}.
{MX_RR}
{MAILSERVICES_RR} {SPF_RR}
_dmarc.{DOM_HOSTNAME}. TXT "v=DMARC1;p=reject;adkim=s;aspf=s"
_mta-sts.{DOM_HOSTNAME}. TXT "v=STSv1; id=202407031637"
{DKIM_RR}
_adsp._domainkey.{DOM_HOSTNAME}. TXT "dkim=discardable"
</syntaxhighlight>

Für das "MTA-STS"-Verfahren muss zusätzliche eine kleine Textdatei unter URL "https://mta-sts.chat.example.com/.well-known/mta-sts.txt" der Subdomain "mts-sts" abgelegt werden. Der Inhalt zum Beispiel:

<syntaxhighlight lang="text" line>
version: STSv1
mode: enforce
mx: mailin1.hostsharing.net
mx: mailin2.hostsharing.net
mx: mailin3.hostsharing.net
max_age: 2419200
</syntaxhighlight>

==== Einrichtung von Postfächern ====

Anschließend richte ich für jede Person, die DeltaChat nutzen soll ein Postfach und eine E-Mail-Adresse ein. Wenn die Accounts weitgehend anonym sein sollen, könnten die DeltaChat-Adressen so aussehen: "chat.295048@chat.example.com" und "chat.873610@chat.example.com".

Sei mein Webspace "xyz99". In HSAdmin richte ich also Postfächer (User) ein: "xyz99-chat.295048" und "xyz99-chat.873610". Wenn man für die User eine Quota für die SSD angibt, wird der Speicherbedarf in der DeltaChat-App auch angezeigt. Allerdings müssen alte Nachrichten auch gelöscht werden, sonst werden nach Überschreitung des Hardlimit oder der Gracetime keine Nachrichten mehr angenommen.

Im letzten Schritt lege ich in HSAdmin die E-Mail-Adressen für DeltaChat an. Also die erste Adresse mit:

* lokaler Teil: "chat.295048"
* Domain: "chat.example.com"
* Postfach/Weiterleitung (Postfach wählen): "xyz99-chat.295048"

Das Feld "subdomain" bleibt leer. Die zweite und ggf. weitere Adressen analog anlegen.

== Links ==

* https://get.delta.chat/
* https://github.com/deltachat/interface/blob/main/uri-schemes.md

[[Kategorie:Messenger]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

DeltaChat

2025-02-14T10:32:54Z

Hsh-peterhormanns: /* Vorbereitungen für die Nutzung von DeltaChat */

== Delta Chat ==

DeltaChat ist eine Messenger für Ende-zu-Ende-verschlüsselte Kommunikation mit Kurznachrichten. Die Funktionalität ist mit Signal, Threema oder WhatsApp oder mit den OpenSource Protokollen Matrix oder XMPP vergleichbar. Der Vorteil ist hier, dass DeltChat die Standard-Protokolle SMTP und IMAP verwendet, die Basis für die E-Mail Kommunikation sind. Diese Infrastruktur ist bei Hostsharing vorhanden und wird von der Genossenschaft gepflegt.

Eigentlich könnte diese Seite also leer bleiben: Es gibt keine DeltaChat-Software, die Hostsharing-Mitlgieder auf ihrem Server oder in ihrem Webspace installieren müssten. IMAP- und SMTP-Server sind als gemanagete Komponenten vorhanden.

=== Vorbereitungen für die Nutzung von DeltaChat ===

Grundsätzlich kann man das normale Postfach auch für die Kommunikation mit DeltaChat nutzen. Oft wird als Argument für DeltaChat angeführt, dass man mit DeltaChat mit jeder E-Mail-Adresse kommunizieren kann. Ich empfehle das ausdrücklich nicht!

==== Einrichtung einer Domain ====

Daher richte ich für DeltaChat eine eigene Domain oder Subdomain ein. In diesem Artikel soll die Domain "chat.hs-example.de" sein.

Ich lege einen Account als Domain-Verwaltung für die Domain ein und schalte die Domain bei diesem Account auf. Es ist sinnvoll für die Domain "Greylisting" zu deaktivieren. "DKIM" und "E-Mail-Autokonfiguration" sollten auf jeden Fall eingeschaltet bleiben!

==== Anpassung des Zonefile ====

Grundsätzlich kann dieser Schritt übersprungen werden. Ich habe das Zonefile etwas vereinfacht und an die Konfiguration eine Chatmail-Server für DeltaChat angepasst.

<syntaxhighlight lang="text" line>
{HEADER}
{SOA_RR}
{NS_RR}
{A_RR}
{AAAA_RR}
mta-sts.{DOM_HOSTNAME}. CNAME {DOM_HOSTNAME}.
www.{DOM_HOSTNAME}. CNAME {DOM_HOSTNAME}.
{MX_RR}
{MAILSERVICES_RR} {SPF_RR}
_dmarc.{DOM_HOSTNAME}. TXT "v=DMARC1;p=reject;adkim=s;aspf=s"
_mta-sts.{DOM_HOSTNAME}. TXT "v=STSv1; id=202407031637"
{DKIM_RR}
_adsp._domainkey.{DOM_HOSTNAME}. TXT "dkim=discardable"
</syntaxhighlight>

Für das "MTA-STS"-Verfahren muss zusätzliche eine kleine Textdatei unter URL "https://mta-sts.chat.example.com/.well-known/mta-sts.txt" der Subdomain "mts-sts" abgelegt werden. Der Inhalt zum Beispiel:

<syntaxhighlight lang="text" line>
version: STSv1
mode: enforce
mx: mailin1.hostsharing.net
mx: mailin2.hostsharing.net
mx: mailin3.hostsharing.net
max_age: 2419200
</syntaxhighlight>

==== Einrichtung von Postfächern ====

Anschließend richte ich für jede Person, die DeltaChat nutzen soll ein Postfach und eine E-Mail-Adresse ein. Wenn die Accounts weitgehend anonym sein sollen, könnten die DeltaChat-Adressen so aussehen: "chat.295048@chat.example.com" und "chat.873610@chat.example.com".

Sei mein Webspace "xyz99". In HSAdmin richte ich also Postfächer (User) ein: "xyz99-chat.295048" und "xyz99-chat.873610". Wenn man für die User eine Quota für die SSD angibt, wird der Speicherbedarf in der DeltaChat-App auch angezeigt. Allerdings müssen alte Nachrichten auch gelöscht werden, sonst werden nach Überschreitung des Hardlimit oder der Gracetime keine Nachrichten mehr angenommen.

Im letzten Schritt lege ich in HSAdmin die E-Mail-Adressen für DeltaChat an. Also die erste Adresse mit:

* lokaler Teil: "chat.295048"
* Domain: "chat.example.com"
* Postfach/Weiterleitung (Postfach wählen): "xyz99-chat.295048"

Das Feld "subdomain" bleibt leer. Die zweite und ggf. weitere Adressen analog anlegen.

== Links ==

* https://get.delta.chat/
* https://github.com/deltachat/interface/blob/main/uri-schemes.md

[[Kategorie:Messenger]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]

Grouprise

2024-11-23T10:26:20Z

Hsh-peterhormanns: veraltetes gelöscht

== Installation von Grouprise ==

Grouprise / Stadtgestalten ist eine Software für die Menschen in einer Stadt oder Region. Sie ermöglicht es, dass einzelne Personen sich in Gruppen engagieren und austauschen. Grouprise ist freie Software (FOSS), die Lizenz ist die AGPL.

Die Software beinhaltet eine Mailinglisten-ähnliche Funktionalität in Kombination mit der Diskussion über die HTML-Oberfläche. Für Die Mailfunktionalität nutzen wir hier die Subdomain, unter der auch die Anwendung läuft. Im Beispiel ist das "groups.hs-example.de". Für diese Domain wird hier eine Catch-All-Mailadresse eingerichtet.

==== Vorbereitungen in HSAdmin ====

In HSAdmin werden angelegt:
* ein Service-User,
* eine Domain,
* ein Postgres-User und eine Datenbank,
* eine Catch-All E-Mail Adresse

<syntaxhighlight lang="bash">
xyz00@h00:~$ hsscript -i
Password: *********************
xyz00@hsadmin> user.add({ set: { name:'xyz00-groups', password:'******', shell:'/bin/bash' } })
xyz00@hsadmin> domain.add({ set: { name:'groups.hs-example.de', user:'xyz00-groups' } })
xyz00@hsadmin> postgresqluser.add({ set: { name:'xyz00_groups', password:'******' } })
xyz00@hsadmin> postgresqldb.add({ set: { name:'xyz00_groups', owner:'xyz00_groups' } })
xyz00@hsadmin> emailaddress.add({ set: { localpart:'', domain:'groups.hs-example.de', target:'xyz00-groups' } })
xyz00@hsadmin> bye
xyz00@h00:~$
</syntaxhighlight>

==== Notizen zur Installation ====

<syntaxhighlight lang="bash">
xyz00-groups@h00:~$ git clone https://git.hack-hro.de/grouprise/grouprise.git
xyz00-groups@h00:~$ cd grouprise/
xyz00-groups@h00:~/grouprise$ git tag
xyz00-groups@h00:~/grouprise$ git checkout v5.5.1
xyz00-groups@h00:~/grouprise$ make virtualenv-update
</syntaxhighlight>

Den Secret_Key kann man wie folgt erzeugen:

<syntaxhighlight lang="bash">
python3 -c "import secrets; print(secrets.token_urlsafe(32))"
</syntaxhighlight>

Anlegen einer Datei ''$HOME/.config/grouprise/conf.d/grouprise.yaml'' mit folgendem Inhalt:

<syntaxhighlight lang="yaml">
domain: groups.hs-example.de
log_recipient_emails:
- webmaster@groups.hs-example.de
database:
engine: postgresql
host: localhost
name: xyz00_groups
user: xyz00_groups
password: "*****"
secret_key: "XXXXXXXXXXXXXXXXXXXXXXXXXXX"
feed_importer_gestalt_id: 1
operator_group_id: 1
unknown_gestalt_id: 32

mailinglist_enabled: True

branding:
logo_backdrop: /-/site/logo_backdrop.svg
logo_favicon: /-/site/favicon.ico
logo_square: /-/site/logo_large.svg
logo_text: /-/site/logo_text.svg

backup_path: /home/storage/xyz00/users/groups/backup

extra_django_settings_filenames:
- /home/pacs/xyz00/users/groups/etc/settings.py
</syntaxhighlight>

Datenbankmigration und statische Assets erzeugen:
<syntaxhighlight lang="bash">
xyz00-groups@h00:~/grouprise$ mkdir -p $HOME/var
xyz00-groups@h00:~/grouprise$ mkdir -p $HOME/etc
xyz00-groups@h00:~/grouprise$ . build/venv/bin/activate
xyz00-groups@h00:~/grouprise$ python manage.py migrate
xyz00-groups@h00:~/grouprise$ make
xyz00-groups@h00:~/grouprise$
</syntaxhighlight>

==== Integration in den Apache ====

<syntaxhighlight lang="bash">
xyz00@h00:~$ hsscript -i
Password: *********************
xyz00@hsadmin> domain.update({where:{name:'groups.hs-example.de'},set:{passengerpython:'/home/pacs/xyz00/users/groups/grouprise/build/venv/bin/python',domainoptions:['htdocsfallback','indexes','dkim','passenger','autoconfig','greylisting','letsencrypt']}})
xyz00@hsadmin> bye
xyz00@h00:~$
</syntaxhighlight>

<syntaxhighlight lang="bash">
xyz00-groups@h00:~/grouprise$ cd $HOME/doms/groups.hs-example.de/
xyz00-groups@h00:~/doms/groups.hs-example.de$ rm -rf subs/www/ subs-ssl/www/ htdocs-ssl/.htaccess
xyz00-groups@h00:~/doms/groups.hs-example.de$ cd htdocs-ssl/
xyz00-groups@h00:~/doms/groups.hs-example.de/htdocs-ssl$ mkdir stadt
xyz00-groups@h00:~/doms/groups.hs-example.de/htdocs-ssl$ cd stadt/
xyz00-groups@h00:~/doms/groups.hs-example.de/htdocs-ssl/stadt$ ln -s $HOME/grouprise/static .
xyz00-groups@h00:~/doms/groups.hs-example.de/htdocs-ssl/stadt$ ln -s $HOME/grouprise/media .
xyz00-groups@h00:~/doms/groups.hs-example.de/htdocs-ssl/stadt$ cd $HOME/doms/groups.hs-example.de/app-ssl
xyz00-groups@h00:~/doms/groups.hs-example.de/app-ssl$ vi passenger_wsgi.py
xyz00-groups@h00:~/doms/groups.hs-example.de/app-ssl$ cat passenger_wsgi.py
import sys, os
sys.path.append("/home/pacs/xyz00/users/groups/grouprise")
from django.conf import settings
from django.core.wsgi import get_wsgi_application
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "grouprise.settings")
application = get_wsgi_application()
</syntaxhighlight>

Die Datei ''$HOME/doms/groups.hs-example.de/app-ssl/passenger_wsgi.py'':
<syntaxhighlight lang="bash">
import sys, os
sys.path.append("/home/pacs/xyz00/users/groups/grouprise")
from django.conf import settings
from django.core.wsgi import get_wsgi_application
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "grouprise.settings")
application = get_wsgi_application()
</syntaxhighlight>

==== Senden von E-Mail ====

Der Versand auf E-Mail erfolgt asynchron durch einen eigenen Prozess. Das Starten des Prozess erfolgt von Hand wie folgt:

<syntaxhighlight lang="bash">
cd $HOME/grouprise
. build/venv/bin/activate
python manage.py run_huey --logfile $HOME/var/huey_consumer.log
</syntaxhighlight>

Es ist sinnvoll ein kleines Start- und Stopskript zu schreiben und den Prozess zum Beispiel mit "monit" zu kontrollieren.

==== Empfang von E-Mail ====

Ankommmende E-Mail an ein Grouprise-Forum werden über die Datei ".forward" im $HOME des Service-Users in ein Skript "~/bin/mailin" geleitet.

Inhalt des Skriptes

<pre>
xyz00-groups@h00:~$ cat bin/mailin
#!/bin/bash
umask 0022
export LANG=de_DE.ISO-8859-1
(cd /home/pacs/xyz00/users/groups/stadtgestalten && /home/pacs/xyz00/users/groups/stadtgestalten/build/venv/bin/python manage.py processincomingmessage)
</pre>

Die Datei ".forward"

<pre>
xyz00-groups@h00:~$ cat .forward
|/home/pacs/xyz00/users/groups/bin/mailin
</pre>

==== Suchfunktion ====

Aufbau des Suchindex für Artikel in Grouprise

<pre>
cd ~/stadtgestalten
. build/venv/bin/activate
python manage.py clear_index
python manage.py rebuild_index
</pre>

Regelmäßige Updates des Suchindex per Cron:

<pre>
xyz00-groups@h00:~$ crontab -l
# m h dom mon dow command
HOME=/home/pacs/xyz00/users/groups
VIRTUAL_ENV=/home/pacs/xyz00/users/stadt/stadtgestalten/build/venv
PATH=/home/pacs/xyz00/users/groups/stadtgestalten/build/venv/bin:/home/pacs/xyz00/users/groups/.nvm/versions/node/v10.21.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
MAILTO=webmaster@groups.hs-example.com
0 */5 * * * cd $HOME/stadtgestalten && $VIRTUAL_ENV/bin/python manage.py update_index >/dev/null 2>&1
</pre>

== Links ==

=== Webseite ===

* https://grouprise.org
* https://git.hack-hro.de/grouprise/grouprise/ (Git Repository)

=== Grouprise Installationen ===

* https://stadtgestalten.org/ Rostock
* https://stadtimpuls.org/ Greifswald
* https://schwerin-aktiv.org/ Schwerin

=== Handbuch für Nutzer:innen ===

* https://stadtgestalten.org/stadtgestalten/tools/
* https://stadtgestalten.org/stadtgestalten/tools-print/ (als PDF)

Prozessmanagement mit systemd im Userspace

2024-10-23T19:20:10Z

Hsh-peterhormanns: /* SystemD Unit starten und stoppen */

''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").

== RAM Kontingente ==

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 Ḿegabyte. 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.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet 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

[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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== 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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:19:44Z

Hsh-peterhormanns: /* SystemD Unit starten und stoppen */

''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").

== RAM Kontingente ==

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 Ḿegabyte. 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.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet 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

[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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== 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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:14:35Z

Hsh-peterhormanns: /* SystemD Unit */

''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").

== RAM Kontingente ==

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 Ḿegabyte. 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.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet 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

[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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:13:45Z

Hsh-peterhormanns: /* SystemD Unit */

''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").

== RAM Kontingente ==

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 Ḿegabyte. 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.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:12:14Z

Hsh-peterhormanns: /* Eigene Serverdienste mit 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").

== RAM Kontingente ==

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 Ḿegabyte. 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.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:11:11Z

Hsh-peterhormanns: /* RAM Kontingente */

''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").

== RAM Kontingente ==

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 Ḿegabyte. 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.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:10:26Z

Hsh-peterhormanns: /* RAM Kontingente */

''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").

== RAM Kontingente ==

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 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:09:45Z

Hsh-peterhormanns:

''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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:08:44Z

Hsh-peterhormanns:

''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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:06:49Z

Hsh-peterhormanns: Status

''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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:04:54Z

Hsh-peterhormanns:

''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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:03:58Z

Hsh-peterhormanns: /* Reload */

''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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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 beim Reboot des Servers aktivieren bzw. deaktivieren.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:03:22Z

Hsh-peterhormanns: /* SystemD Unit starten und stoppen */

''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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

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 eine ''.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 beim Reboot des Servers aktivieren bzw. deaktivieren.

Prozessmanagement mit systemd im Userspace

2024-10-23T19:01:27Z

Hsh-peterhormanns: Start Stop Enable

''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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

=== SystemD Unit starten und stoppen ===

Für die Verwaltung des Dienstes stehen die folgenden Kommandos zur Verfügung:

<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 eine ''.service''-Datei nötig.

<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 der Dienstes.

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

bzw.

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

sind die Kommados, die den Dienst beim Reboot des Servers aktivieren bzw. deaktivieren.

Prozessmanagement mit systemd im Userspace

2024-10-23T18:52:47Z

Hsh-peterhormanns: /* RAM- und CPU-Limits */

''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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

Prozessmanagement mit systemd im Userspace

2024-10-23T18:52:35Z

Hsh-peterhormanns: /* RAM- und CPU-Limits */

''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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.
; CPUQuoa : Maximale Belegung eines CPU-Threads in Prozent. Werte über 100% sind sinnvoll, wenn mehr als ein CPU-Thread verfügbar ist.

Prozessmanagement mit systemd im Userspace

2024-10-23T18:51:07Z

Hsh-peterhormanns: ResourceAccounting

''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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="ini" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

=== 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.

Prozessmanagement mit systemd im Userspace

2024-10-23T18:41:02Z

Hsh-peterhormanns: /* Eigene Serverdienste mit 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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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.

Die SystemD-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="xml" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

Prozessmanagement mit systemd im Userspace

2024-10-23T18:40:15Z

Hsh-peterhormanns: Eigenschaften

''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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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.

Die SystemD-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="xml" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 leufenden Dienstes geschrieben wird.
; StandardError : Entsprechen 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 : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

Prozessmanagement mit systemd im Userspace

2024-10-23T18:39:15Z

Hsh-peterhormanns: Eigenschaften

''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 allen 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").

== RAM Kontingente ==

Ab November 2024 unterstützt die Managed Plattform ein RAM Kontigent pro Managed Webspace. Mitglieder buchen für ihre Webspaces jeweils ein RAM Kontigent in Schritten von jeweils 128 Ḿegabyte. 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 Server unter [mailto:service@hostsharing.net service@hostsharing.net] entgegen, wie es bei anderen Paketoptionen die Vorgehensweise ist.

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.

== Eigene Serverdienste mit SystemD ==

In diesem Wiki findet sich viele Beispiele für SystemD-Units zur Kontrolle eines Serverdienstes. An dieser Stelle folgen Erläuterungen 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.

Die SystemD-Unit 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 ein Beispiel für ein GotoSocial-Instanz. GotoSocial ist ein einfaches Binärprogramm, das in der Programmierspreche ''Go'' programmiert ist.

<syntaxhighlight lang="xml" line>
[Unit]
Description=GotoSocial 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=file:%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:

; 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 leufenden Dienstes geschrieben wird.
; StandardError : Entsprechen 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 : Für /tmp und /var/tmp werden im Namespace gemountet, so dass sie nicht mit anderen Prozessen geteilt werden.
; WantedBy : muss im Usermodus von SystemD immer ''default.target'' sein. Andere Targets sind nicht definiert.

Prozessmanagement mit systemd im Userspace

2024-10-23T18:24:25Z

Hsh-peterhormanns: /* Eigene Serverdienste mit SystemD */

Prozessmanagement mit systemd im Userspace

2024-10-23T18:19:38Z

Hsh-peterhormanns: einfache Service-Unit

Prozessmanagement mit systemd im Userspace

2024-10-23T17:38:22Z

Hsh-peterhormanns: syntax

Prozessmanagement mit systemd im Userspace

2024-10-23T17:37:48Z

Hsh-peterhormanns: syntax

Prozessmanagement mit systemd im Userspace

2024-10-23T17:34:25Z

Hsh-peterhormanns: .config-Verzeichnis

Prozessmanagement mit systemd im Userspace

2024-10-23T17:29:11Z

Hsh-peterhormanns: XDG_RUNTIME_DIR

Prozessmanagement mit systemd im Userspace

2024-10-23T14:57:36Z

Hsh-peterhormanns: RAM Kontigente