Hostsharing Wiki - Benutzerbeiträge [de]

Discourse installieren

2026-06-11T20:29:08Z

Tim00: workaround for issue with pnpm 10

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Discourse-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

{{Textkasten|rot|Support von der Discourse-Community|Die Discourse-Entwickler haben sich entschieden, nur eine mehr oder weniger genormte Installationsmethode (via docker) zu unterstützen. Dies ist so auf der hostsharing-Architektur aufgrund mehrerer Bedenken und Überlegungen nicht möglich. Die Community ist durchaus hilfreich, geht aber davon aus, dass quasi alle Nutzer* eine "supported"e Installation durchgeführt haben. Wenn man in entsprechenden Kanälen nach Hilfe fragt, sollte man unbedingt erwähnen, dass man discourse selber anhand dieser hier lesbaren Anleitung installiert hat, um bereits entsprechenden Kommentaren und Nachfragen vorzugreifen.}}

== Über ==

In diesem Artikel wird die Installation von discourse, Version 2.1.0 (September 2018) beschrieben.

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-discourse''
# Eine Domain mit ''xyz00-discourse' als Domain-Administrator, zum Beispiel ''beispiel.discussion''
# Einen Postgresql-User ''xyz00_discourseuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_discoursedb'' mit Datenbank-Owner ''xyz00_discourseuser''

Verwendete IP-Ports der Server-Dienste:
# Redis: localhost:32002
# Discourse-Web: localhost:13000

== Konfiguration der PostgreSQL Datenbank ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{Textkasten|gelb|Firewall/Redis Port|Leider unterstützt discourse nicht die Kommunikation mit Redis über Unix-Sockets. Dementsprechend muss der für Redis konfigurierte Port von dem hostsharing-Support in der Firewall freigegeben werden.}}

<syntaxhighlight lang=shell>
cd
mkdir redis/etc redis/lib redis/log redis/run
</syntaxhighlight>

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/redis/etc/redis.conf'' mit folgendem Inhalt:

<syntaxhighlight lang=shell line>
daemonize no
pidfile /home/pacs/xyz00/users/discourse/redis/run/redis-server.pid
port 32002
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/discourse/redis/log/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/discourse/redis/lib
</syntaxhighlight>

Für Discourse 3.x gilt: "Discourse requires Redis 6.2.0 or up"

Für Debian Buster und Bullseye ist daher das Installieren eines neueren Binaries erforderlich. Bei Debian Bookwork ist bereits Redis 7.0 enthalten (siehe https://packages.debian.org/search?keywords=redis-server).

Hier steht ein entsprechendes Binary für Debian Buster zur Verfügung, das mit dem Public Key von Timotheus geprüft werden kann:

* https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz
* Prüfsignatur: https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz.sig

Prüfen der Signatur:

<syntaxhighlight lang=shell>
gpg --verify redis-server-6.2.12-debian-buster.tar.gz.sig redis-server-6.2.12-debian-buster.tar.gz
</syntaxhighlight>

Das Binary muss nach <code>$HOME/bin</code> verschoben werden, und entsprechend beim Starten des Dienstes eingetragen werden.

== Installation von Ruby ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
echo 'eval "$(rbenv init -)"' >> ~/.profile
</syntaxhighlight>

starte neue Shell:

<syntaxhighlight lang=shell>
exec bash
</syntaxhighlight>

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

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

Nun kann die benötigte Ruby-Version installiert werden:

<syntaxhighlight lang=shell>
rbenv install 2.4
</syntaxhighlight>

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

<syntaxhighlight lang=shell>
cd ~
git clone https://github.com/discourse/discourse.git discourse
cd ~/discourse
</syntaxhighlight>

Die stabile Version auschecken:

<syntaxhighlight lang=shell>
git checkout stable
</syntaxhighlight>

Ruby Pakete installieren:

<syntaxhighlight lang=shell>
gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test
</syntaxhighlight>

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

Anpassen folgender Inhalte:
<syntaxhighlight lang=ini line>
db_host = 127.0.0.1
db_port = 5432
#db_backup_port = 5432 #(auskommentieren)
db_name = xyz00_discoursedb
db_username = xyz00_discourseuser
db_password = "" #db password
hostname = "discourse.xyz00" # hostname
smtp_address = localhost
smtp_enable_start_tls = false
smtp_openssl_verify_mode = 'none'
developer_emails = # your email-address
redis_host = 127.0.0.1
redis_port = 32002
</syntaxhighlight>
===TODO: Secrets setzen! ===
Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== Sidekiq für Hintergrund-Aufgaben konfigurieren ===

''config/sidekiq.conf''

Wichtig: development auf production ändern.

Mit diesem Dienst werden z.B. die E-Mails zur Aktivierung oder zum Passwort Reset verschickt.

=== Problem mit Content Security Policy ===

Um ein Problem mit Content Security Policy zu lösen, weil manche Dateien über http nachgeladen werden, muss in der Datei <code>config/site_settings.yml</code> der Default Wert für force_https auf True gesetzt werden:
<syntaxhighlight lang=yaml line>
force_https:
default: true
</syntaxhighlight>
=== Problem beim Aufsetzen der Datenbank vermeiden ===

'''→ Notiz Mai 2024:''' dies scheint aktuell nicht aufzutreten.

Aus irgendeinem Grund wird beim Initialisieren der Datenbank versucht, den TYPE hotlinked_media_status zweimal in der Datenbank anzulegen. Der Grund ist nicht ersichtlich.

Es kann folgende Änderung an der Datei <code>db/migrate/20220428094026_create_post_hotlinked_media.rb</code> vorgenommen werden:
<syntaxhighlight lang=ruby line>
reversible do |dir|
dir.up { execute <<~SQL }
DO $$ BEGIN CREATE TYPE hotlinked_media_status AS ENUM('downloaded', 'too_large', 'download_failed', 'upload_create_failed'); EXCEPTION WHEN duplicate_object THEN null; END $$;
SQL
dir.down { execute <<~SQL }
DROP TYPE hotlinked_media_status
SQL
end
</syntaxhighlight>
=== Initialisieren der Datenbank ===

<syntaxhighlight lang=shell>
export SAFETY_ASSURED=1
# In Version 2.0.4 funktioniert db:migrate noch, ansonsten db:schema:load und seed nutzen!
# In Version 3.0.3 funktioniert db:migrate auch noch, db:schema:load ging nicht weil die Datei structure.sql fehlte
#RAILS_ENV=production bundle exec rails db:schema:load
#RAILS_ENV=production bundle exec rails db:seed
RAILS_ENV=production bundle exec rails db:migrate
</syntaxhighlight>

=== Kompilieren der Assets ===

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rails assets:precompile
</syntaxhighlight>

=== Konfiguration des Web-Servers (am Beispiel Puma) ===

Die Datei ''config/puma.conf'' anpassen (hier nur Änderungen angezeigt):

<syntaxhighlight lang=ini>
APP_ROOT = '/home/pacs/xyz00/users/discourse/discourse'
daemonize false
</syntaxhighlight>

== Starten der Dienste ==

Zum Start aller notwendigen Dienste sollte systemd benutzt werden.

Die folgenden Dateien müssen nach <code>.config/systemd/user/</code> kopiert werden (überlange Zeilen werden hier im Wiki umgebrochen)

redis.service:

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

[Service]
WorkingDirectory=%h/var/redis
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/bin/redis-server %h/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

sidekiq.service:

<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Sidekiq Service

[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="DB_POOL=8"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec sidekiq -C %h/discourse/config/sidekiq.yml
StandardOutput=append:%h/var/log/sidekiq.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

discourse.service:

<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Web Service

[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="WEB_CONCURRENCY=2"
Environment="MAX_THREADS=5"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:13000
StandardOutput=append:%h/var/log/puma.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

== Einrichten des Apache VHost ==

<syntaxhighlight lang=shell>
cd ~/doms/beispiel.discuss
rm -rf htdocs-ssl subs/www subs-ssl/www
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess
</syntaxhighlight>

Dann die ''htdocs-ssl/.htaccess'' (durch das gelinkte Verzeichnis entspricht das dem Pfad /home/pacs/xyz00/users/discourse/discourse/public/.htaccess ) mit dem Editor der Wahl öffnen und folgende Konfiguration einfügen:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled

RequestHeader set X-Forwarded-Proto "https"

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://127.0.0.1:13000%{REQUEST_URI} [proxy,last]
</syntaxhighlight>
== Wartung ==
=== Backup ===

Discourse macht selbstätig backups und legt diese unter 'public/backups' ab. Enthalten ist ein Datenbank-Dump und die hochgeladenen Dateien.

Im Admin-Bereich lassen sich backups auch manuell antreten.

=== Admin Benutzer einladen ===

Manchmal brauchen wir einen neuen Admin Benutzer, den wir von der Kommandozeile aus einladen möchten.

<syntaxhighlight lang=shell>
cd /discourse
RAILS_ENV=production rake admin:invite[admin@example.org]
</syntaxhighlight>

=== Import aus mbox Archiven ===

Um zum Beispiel ein Mailman2 Archiv zu importieren, wo die Nachrichten als .mbox Datei vorliegen, sind folgende Schritte nötig:

Vorbereitungen an Discourse:

<syntaxhighlight lang=shell>
source .profile
cd discourse
bundle config set frozen false
IMPORT=1 bundle install
bundle config set frozen true
nano script/import_scripts/mbox/settings.yml
# dort ändern:
# data_dir: /home/pacs/xyz00/users/discourse/list-archiv
</syntaxhighlight>

Hochladen der Mailinglisten-Archive:
<syntaxhighlight lang=shell>
mkdir ~/list-archiv
# dort muss es Unterordner mit dem Namen der gewünschten Kategorie geben,
# und die mbox Datei muss auch diesen Namen haben, z.B.:
# ~/list-archiv/beispiel/beispiel.mbox
# ~/list-archiv/example/example.mbox
# um die Beiträge in den entsprechenden Kategorien beispiel und example einzufügen.
</syntaxhighlight>

Durchführen des Imports:
<syntaxhighlight lang=shell>
source .profile
cd discourse
RAILS_ENV=production IMPORT=1 bundle exec rails runner \
script/import_scripts/mbox.rb script/import_scripts/mbox/settings.yml
</syntaxhighlight>

=== Export ===
* Wenn ein Forum beendet wird, möchte man evtl. eine Sicherung als statische HTML Seiten.
** Das wird hier diskutiert: https://meta.discourse.org/t/how-do-i-export-the-complete-forum-as-static-html-pages/71007/3
* Um ein Forum von Discourse zu Flarum umzuziehen, hat Timotheus ein Skript geschrieben.
** Das Migrations-Skript: https://github.com/SolidCharity/discourse_to_flarum
** siehe auch https://discuss.flarum.org/d/4930-discourse-to-flarum-migration-support/29

=== Updates ===

Discourse wird über update via mail informieren (dies kann man m.W. abschalten).

Achtung: bei größeren Updates auch immer Änderungen an der Datei site_settings.yml (https://github.com/discourse/discourse/blob/main/config/site_settings.yml) beachten!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.3 auf 2026.1.4 ====

# Im Web-Backend unter Administration->Backups-> Read-Only Mouds setzen (oder Web Server so konfigurieren, dass keine Zugriffe mehr stattfinden können)
# Backup
# Die lokalen Änderungen sichern:
# cd discourse
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.3 > diff-2026.1.3.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.1.4 v2026.1.4
# evtl. Änderungen aus diff-2026.1.3.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.3.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.4/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.3.8
# rbenv global 3.3.8
# rbenv rehash
# echo "3.3.8" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
#
# to avoid this error: ERR_PNPM_INVALID_DEPENDENCY_NAME The current package contains a dependency with an invalid name: "@types/@glimmer__component"
# vi frontend/discourse-types/package.json

- "@types/@glimmer__component": "npm:@glimmer/component@^2.0.0",
- "@types/@glint__ember-tsc": "npm:@glint/ember-tsc@^1.0.7",
- "@types/@glint__template": "npm:@glint/template@^1.7.2"
+ "@types/glimmer__component": "npm:@glimmer/component@^2.0.0",
+ "@types/glint__ember-tsc": "npm:@glint/ember-tsc@^1.0.7",
+ "@types/glint__template": "npm:@glint/template@^1.7.2"

#
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# Falls die pg extension pg_vector nicht installiert ist: deaktiviere das Plugin während migrate, aber auch für später damit /admin/settings funktioniert (ansonsten in salt pillar pg_vector installieren, und als postgres user: create extension vector;)
## mkdir -p ~/plugins.bak
## mv plugins/discourse-ai ~/plugins.bak
# RAILS_ENV=production bundle exec rake db:migrate
# RAILS_ENV=production bundle exec rake assets:precompile
# Services neu starten
<syntaxhighlight lang=shell>
systemctl --user restart puma
systemctl --user restart sidekiq
systemctl --user restart redis
</syntaxhighlight>
* Zuletzt: Read-Only Modus wieder deaktivieren

=== Debugging ===

Es können folgende Einstellungen in der Datei config/environments/production.rb vorgenommen werden. Danach den Puma Dienst neustarten. Fehlermeldungen und Stacktraces werden dann im Browser ausgegeben.

<syntaxhighlight lang="ini" line>
config.log_level = :debug
config.action_dispatch.show_exceptions = :all
config.action_dispatch.debug_exception_log_level = :error

# Full error reports are enabled and caching is turned off
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
</syntaxhighlight>

=== Erforderliche Anpassungen ===
Weil wir bei Debian Bookworm noch mit ImageMagick 6.9 arbeiten, muss dieser [https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119 Patch] rückgängig gemacht werden:

<syntaxhighlight lang="bash" line>
wget https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119.patch -O ~/imagemagick.patch
patch -p1 --reverse < ~/imagemagick.patch
git commit -a -m "revert imagemagick patch" --no-verify
</syntaxhighlight>

== ToDos ==

* Ein Patch, um Discourse auch via Unix-Socket mit Redis sprechen lassen zu können dürfte relativ einfach sein (es wird ein Wrapper um das redis-gem genutzt).
* Konfiguration von discourse, um mit postgresql via Unix-Socket zu kommunizieren (DISCOURSE_DB_SOCKET environment variable)
* Performance-tuning an diversen Stellen, anhand der discourse_docker-Vorgaben (https://github.com/discourse/discourse_docker), z.B.
** thpoff (huge page settings)
** unicorn (hat eine wesentlich ausgefeiltere Konfigurations-Vorlage, wahrscheinlich bereits ordentlich optimiert)

== Links ==

* https://help.skysilk.com/support/solutions/articles/9000120927-how-to-install-discourse-without-docker-using-skysilk-vps-
* https://github.com/discourse/discourse_docker
* https://github.com/discourse/discourse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/discourse

== Historie ==

* 2018, 14 . September: Initiale Fassung
* 2019, Januar: Update-Informationen ergänzt
* 2022, Juni: systemd Dienste, Discourse 3.0

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Webforen]]
[[Kategorie:Ansible Playbook]]

Discourse installieren

2026-06-11T20:06:06Z

Tim00: /* Am Beispiel von 2026.1.3 auf 2026.1.4 */

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Discourse-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

{{Textkasten|rot|Support von der Discourse-Community|Die Discourse-Entwickler haben sich entschieden, nur eine mehr oder weniger genormte Installationsmethode (via docker) zu unterstützen. Dies ist so auf der hostsharing-Architektur aufgrund mehrerer Bedenken und Überlegungen nicht möglich. Die Community ist durchaus hilfreich, geht aber davon aus, dass quasi alle Nutzer* eine "supported"e Installation durchgeführt haben. Wenn man in entsprechenden Kanälen nach Hilfe fragt, sollte man unbedingt erwähnen, dass man discourse selber anhand dieser hier lesbaren Anleitung installiert hat, um bereits entsprechenden Kommentaren und Nachfragen vorzugreifen.}}

== Über ==

In diesem Artikel wird die Installation von discourse, Version 2.1.0 (September 2018) beschrieben.

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-discourse''
# Eine Domain mit ''xyz00-discourse' als Domain-Administrator, zum Beispiel ''beispiel.discussion''
# Einen Postgresql-User ''xyz00_discourseuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_discoursedb'' mit Datenbank-Owner ''xyz00_discourseuser''

Verwendete IP-Ports der Server-Dienste:
# Redis: localhost:32002
# Discourse-Web: localhost:13000

== Konfiguration der PostgreSQL Datenbank ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{Textkasten|gelb|Firewall/Redis Port|Leider unterstützt discourse nicht die Kommunikation mit Redis über Unix-Sockets. Dementsprechend muss der für Redis konfigurierte Port von dem hostsharing-Support in der Firewall freigegeben werden.}}

<syntaxhighlight lang=shell>
cd
mkdir redis/etc redis/lib redis/log redis/run
</syntaxhighlight>

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/redis/etc/redis.conf'' mit folgendem Inhalt:

<syntaxhighlight lang=shell line>
daemonize no
pidfile /home/pacs/xyz00/users/discourse/redis/run/redis-server.pid
port 32002
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/discourse/redis/log/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/discourse/redis/lib
</syntaxhighlight>

Für Discourse 3.x gilt: "Discourse requires Redis 6.2.0 or up"

Für Debian Buster und Bullseye ist daher das Installieren eines neueren Binaries erforderlich. Bei Debian Bookwork ist bereits Redis 7.0 enthalten (siehe https://packages.debian.org/search?keywords=redis-server).

Hier steht ein entsprechendes Binary für Debian Buster zur Verfügung, das mit dem Public Key von Timotheus geprüft werden kann:

* https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz
* Prüfsignatur: https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz.sig

Prüfen der Signatur:

<syntaxhighlight lang=shell>
gpg --verify redis-server-6.2.12-debian-buster.tar.gz.sig redis-server-6.2.12-debian-buster.tar.gz
</syntaxhighlight>

Das Binary muss nach <code>$HOME/bin</code> verschoben werden, und entsprechend beim Starten des Dienstes eingetragen werden.

== Installation von Ruby ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
echo 'eval "$(rbenv init -)"' >> ~/.profile
</syntaxhighlight>

starte neue Shell:

<syntaxhighlight lang=shell>
exec bash
</syntaxhighlight>

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

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

Nun kann die benötigte Ruby-Version installiert werden:

<syntaxhighlight lang=shell>
rbenv install 2.4
</syntaxhighlight>

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

<syntaxhighlight lang=shell>
cd ~
git clone https://github.com/discourse/discourse.git discourse
cd ~/discourse
</syntaxhighlight>

Die stabile Version auschecken:

<syntaxhighlight lang=shell>
git checkout stable
</syntaxhighlight>

Ruby Pakete installieren:

<syntaxhighlight lang=shell>
gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test
</syntaxhighlight>

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

Anpassen folgender Inhalte:
<syntaxhighlight lang=ini line>
db_host = 127.0.0.1
db_port = 5432
#db_backup_port = 5432 #(auskommentieren)
db_name = xyz00_discoursedb
db_username = xyz00_discourseuser
db_password = "" #db password
hostname = "discourse.xyz00" # hostname
smtp_address = localhost
smtp_enable_start_tls = false
smtp_openssl_verify_mode = 'none'
developer_emails = # your email-address
redis_host = 127.0.0.1
redis_port = 32002
</syntaxhighlight>
===TODO: Secrets setzen! ===
Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== Sidekiq für Hintergrund-Aufgaben konfigurieren ===

''config/sidekiq.conf''

Wichtig: development auf production ändern.

Mit diesem Dienst werden z.B. die E-Mails zur Aktivierung oder zum Passwort Reset verschickt.

=== Problem mit Content Security Policy ===

Um ein Problem mit Content Security Policy zu lösen, weil manche Dateien über http nachgeladen werden, muss in der Datei <code>config/site_settings.yml</code> der Default Wert für force_https auf True gesetzt werden:
<syntaxhighlight lang=yaml line>
force_https:
default: true
</syntaxhighlight>
=== Problem beim Aufsetzen der Datenbank vermeiden ===

'''→ Notiz Mai 2024:''' dies scheint aktuell nicht aufzutreten.

Aus irgendeinem Grund wird beim Initialisieren der Datenbank versucht, den TYPE hotlinked_media_status zweimal in der Datenbank anzulegen. Der Grund ist nicht ersichtlich.

Es kann folgende Änderung an der Datei <code>db/migrate/20220428094026_create_post_hotlinked_media.rb</code> vorgenommen werden:
<syntaxhighlight lang=ruby line>
reversible do |dir|
dir.up { execute <<~SQL }
DO $$ BEGIN CREATE TYPE hotlinked_media_status AS ENUM('downloaded', 'too_large', 'download_failed', 'upload_create_failed'); EXCEPTION WHEN duplicate_object THEN null; END $$;
SQL
dir.down { execute <<~SQL }
DROP TYPE hotlinked_media_status
SQL
end
</syntaxhighlight>
=== Initialisieren der Datenbank ===

<syntaxhighlight lang=shell>
export SAFETY_ASSURED=1
# In Version 2.0.4 funktioniert db:migrate noch, ansonsten db:schema:load und seed nutzen!
# In Version 3.0.3 funktioniert db:migrate auch noch, db:schema:load ging nicht weil die Datei structure.sql fehlte
#RAILS_ENV=production bundle exec rails db:schema:load
#RAILS_ENV=production bundle exec rails db:seed
RAILS_ENV=production bundle exec rails db:migrate
</syntaxhighlight>

=== Kompilieren der Assets ===

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rails assets:precompile
</syntaxhighlight>

=== Konfiguration des Web-Servers (am Beispiel Puma) ===

Die Datei ''config/puma.conf'' anpassen (hier nur Änderungen angezeigt):

<syntaxhighlight lang=ini>
APP_ROOT = '/home/pacs/xyz00/users/discourse/discourse'
daemonize false
</syntaxhighlight>

== Starten der Dienste ==

Zum Start aller notwendigen Dienste sollte systemd benutzt werden.

Die folgenden Dateien müssen nach <code>.config/systemd/user/</code> kopiert werden (überlange Zeilen werden hier im Wiki umgebrochen)

redis.service:

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

[Service]
WorkingDirectory=%h/var/redis
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/bin/redis-server %h/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

sidekiq.service:

<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Sidekiq Service

[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="DB_POOL=8"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec sidekiq -C %h/discourse/config/sidekiq.yml
StandardOutput=append:%h/var/log/sidekiq.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

discourse.service:

<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Web Service

[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="WEB_CONCURRENCY=2"
Environment="MAX_THREADS=5"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:13000
StandardOutput=append:%h/var/log/puma.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

== Einrichten des Apache VHost ==

<syntaxhighlight lang=shell>
cd ~/doms/beispiel.discuss
rm -rf htdocs-ssl subs/www subs-ssl/www
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess
</syntaxhighlight>

Dann die ''htdocs-ssl/.htaccess'' (durch das gelinkte Verzeichnis entspricht das dem Pfad /home/pacs/xyz00/users/discourse/discourse/public/.htaccess ) mit dem Editor der Wahl öffnen und folgende Konfiguration einfügen:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled

RequestHeader set X-Forwarded-Proto "https"

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://127.0.0.1:13000%{REQUEST_URI} [proxy,last]
</syntaxhighlight>
== Wartung ==
=== Backup ===

Discourse macht selbstätig backups und legt diese unter 'public/backups' ab. Enthalten ist ein Datenbank-Dump und die hochgeladenen Dateien.

Im Admin-Bereich lassen sich backups auch manuell antreten.

=== Admin Benutzer einladen ===

Manchmal brauchen wir einen neuen Admin Benutzer, den wir von der Kommandozeile aus einladen möchten.

<syntaxhighlight lang=shell>
cd /discourse
RAILS_ENV=production rake admin:invite[admin@example.org]
</syntaxhighlight>

=== Import aus mbox Archiven ===

Um zum Beispiel ein Mailman2 Archiv zu importieren, wo die Nachrichten als .mbox Datei vorliegen, sind folgende Schritte nötig:

Vorbereitungen an Discourse:

<syntaxhighlight lang=shell>
source .profile
cd discourse
bundle config set frozen false
IMPORT=1 bundle install
bundle config set frozen true
nano script/import_scripts/mbox/settings.yml
# dort ändern:
# data_dir: /home/pacs/xyz00/users/discourse/list-archiv
</syntaxhighlight>

Hochladen der Mailinglisten-Archive:
<syntaxhighlight lang=shell>
mkdir ~/list-archiv
# dort muss es Unterordner mit dem Namen der gewünschten Kategorie geben,
# und die mbox Datei muss auch diesen Namen haben, z.B.:
# ~/list-archiv/beispiel/beispiel.mbox
# ~/list-archiv/example/example.mbox
# um die Beiträge in den entsprechenden Kategorien beispiel und example einzufügen.
</syntaxhighlight>

Durchführen des Imports:
<syntaxhighlight lang=shell>
source .profile
cd discourse
RAILS_ENV=production IMPORT=1 bundle exec rails runner \
script/import_scripts/mbox.rb script/import_scripts/mbox/settings.yml
</syntaxhighlight>

=== Export ===
* Wenn ein Forum beendet wird, möchte man evtl. eine Sicherung als statische HTML Seiten.
** Das wird hier diskutiert: https://meta.discourse.org/t/how-do-i-export-the-complete-forum-as-static-html-pages/71007/3
* Um ein Forum von Discourse zu Flarum umzuziehen, hat Timotheus ein Skript geschrieben.
** Das Migrations-Skript: https://github.com/SolidCharity/discourse_to_flarum
** siehe auch https://discuss.flarum.org/d/4930-discourse-to-flarum-migration-support/29

=== Updates ===

Discourse wird über update via mail informieren (dies kann man m.W. abschalten).

Achtung: bei größeren Updates auch immer Änderungen an der Datei site_settings.yml (https://github.com/discourse/discourse/blob/main/config/site_settings.yml) beachten!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.3 auf 2026.1.4 ====

# Im Web-Backend unter Administration->Backups-> Read-Only Mouds setzen (oder Web Server so konfigurieren, dass keine Zugriffe mehr stattfinden können)
# Backup
# Die lokalen Änderungen sichern:
# cd discourse
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.3 > diff-2026.1.3.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.1.4 v2026.1.4
# evtl. Änderungen aus diff-2026.1.3.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.3.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.4/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.3.8
# rbenv global 3.3.8
# rbenv rehash
# echo "3.3.8" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# Falls die pg extension pg_vector nicht installiert ist: deaktiviere das Plugin während migrate, aber auch für später damit /admin/settings funktioniert (ansonsten in salt pillar pg_vector installieren, und als postgres user: create extension vector;)
## mkdir -p ~/plugins.bak
## mv plugins/discourse-ai ~/plugins.bak
# RAILS_ENV=production bundle exec rake db:migrate
# RAILS_ENV=production bundle exec rake assets:precompile
# Services neu starten
<syntaxhighlight lang=shell>
systemctl --user restart puma
systemctl --user restart sidekiq
systemctl --user restart redis
</syntaxhighlight>
* Zuletzt: Read-Only Modus wieder deaktivieren

=== Debugging ===

Es können folgende Einstellungen in der Datei config/environments/production.rb vorgenommen werden. Danach den Puma Dienst neustarten. Fehlermeldungen und Stacktraces werden dann im Browser ausgegeben.

<syntaxhighlight lang="ini" line>
config.log_level = :debug
config.action_dispatch.show_exceptions = :all
config.action_dispatch.debug_exception_log_level = :error

# Full error reports are enabled and caching is turned off
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
</syntaxhighlight>

=== Erforderliche Anpassungen ===
Weil wir bei Debian Bookworm noch mit ImageMagick 6.9 arbeiten, muss dieser [https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119 Patch] rückgängig gemacht werden:

<syntaxhighlight lang="bash" line>
wget https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119.patch -O ~/imagemagick.patch
patch -p1 --reverse < ~/imagemagick.patch
git commit -a -m "revert imagemagick patch" --no-verify
</syntaxhighlight>

== ToDos ==

* Ein Patch, um Discourse auch via Unix-Socket mit Redis sprechen lassen zu können dürfte relativ einfach sein (es wird ein Wrapper um das redis-gem genutzt).
* Konfiguration von discourse, um mit postgresql via Unix-Socket zu kommunizieren (DISCOURSE_DB_SOCKET environment variable)
* Performance-tuning an diversen Stellen, anhand der discourse_docker-Vorgaben (https://github.com/discourse/discourse_docker), z.B.
** thpoff (huge page settings)
** unicorn (hat eine wesentlich ausgefeiltere Konfigurations-Vorlage, wahrscheinlich bereits ordentlich optimiert)

== Links ==

* https://help.skysilk.com/support/solutions/articles/9000120927-how-to-install-discourse-without-docker-using-skysilk-vps-
* https://github.com/discourse/discourse_docker
* https://github.com/discourse/discourse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/discourse

== Historie ==

* 2018, 14 . September: Initiale Fassung
* 2019, Januar: Update-Informationen ergänzt
* 2022, Juni: systemd Dienste, Discourse 3.0

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Webforen]]
[[Kategorie:Ansible Playbook]]

Kategorie:Installationsanleitungen

2026-06-10T10:03:08Z

Tim00: /* Tools */

{{HSDoku-Links}}
Manche Software wird von vielen unserer Mitglieder verwendet. Deshalb werden hier Installationen dokumentiert, wie sie bei anderen Mitgliedern funktionieren, um die Sache zu erleichtern.

Es gibt auch eine [[Hostsharing_Wiki:Wunschliste Installationsanleitungen|Wunschliste]], in der du Software eintragen kannst, für die du dir eine Installationsanleitung wünscht.

Zum Entfernen einer Anwendung, kannst du dieser Anleitung folgen: [[Deinstallieren einer Anwendung]]

=== Freie und datenschutzfreundliche Software-Alternativen ===

Linksammlungen, die helfen, alternative Software zu finden:

* https://switching.software/
* https://prism-break.org/de/

=== Tools ===
Liste mit Tools, die von Hostsharing Mitgliedern veröffentlicht wurden.

* http://hs.andreasloesch.de
* https://codeberg.org/tpokorra/hostsharing-scripts
** z.B. [[Skript hs-list-apps]] zum Anzeigen der installierten Anwendungen
** z.B. [[RAM_Belegung#Skript_list-memory-usage|Skript list-memory-usage]] zum Anzeigen des RAM Verbrauchs
* https://codeberg.org/tpokorra/hs.ansible

[[Kategorie:HSDoku]]

Skript hs-list-apps

2026-06-10T08:25:14Z

Tim00: /* Beschreibung */

== Beschreibung ==

hs-list-apps ist ein Skript, in Python geschrieben, welches viele der aktuell installierten Anwendungen und die Belegung von RAM, SSD und HDD anzeigt.

Es hilft, gerade bei Paketen mit vielen Anwendungen, den Überblick zu behalten. Als Reseller will ich zum Beispiel wissen, wieviele Nextclouds in meinem Paket installiert sind, wieviel Platz sie belegen, und auf welchem Versionsstand sie sind.

Das Skript wird momentan hier gepflegt: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/hs-list-apps

== Einschränkungen ==

Es werden bisher einige Anwendungen unterstützt, aber längst nicht alle Anwendungen, die bei Hostsharing installiert werden können oder installiert worden sind. Weitere Anwendungen können gerne ins Skript aufgenommen werden. Bitte einen PR oder Issue auf dem Repo bei Codeberg aufmachen.

Es werden einige Annahmen getroffen, wo eine Anwendung zu finden ist. Damit vermeiden wir einen vollständigen Scan der Dateien, der sehr zeitintensiv wäre. z.B. wird erwartet, dass die Nextclouds alle im Benutzerverzeichnis im Ordner nextcloud liegen.

Es wird versucht, die richtige Domain zu bestimmen. Wenn im Benutzer aber mehrere Domains eingetragen sind, wird die mit dem längsten Namen angezeigt.

== Benutzung ==

Das Skript steht auf den Hives zur Verfügung, es liegt in /usr/local/bin, und ist damit Teil des Standardpfades.

Das Skript kann entweder innerhalb eines Benutzers aufgerufen werden:

<syntaxhighlight lang=shell>
xyz00-nextcloud@h01:~$ hs-list-apps --detail
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 164.7M | 1.4G | 131M |
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
</syntaxhighlight>

Ohne den Parameter --detail wird der SSD Platz und der HDD Platz nicht berechnet. Das kann sonst etwas Zeit in Anspruch nehmen.

Das Skript kann auch vom Paket Admin aufgerufen werden:

<syntaxhighlight lang=shell>
xyz00@h01:~$ hs-list-apps
|-----------|---------------|-------|-----------------|----------------------------- -----|-------|-----|-----|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
| Wordpress | 6.8.3 | xyz00 | mywordpresstest | https://www.example.de | 21.2M | | |
| OpenLDAP | 2.5.13+dfsg-5 | xyz00 | openldap | https://openldap.example.de | 28.5M | | |
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 33.0M | | |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
</syntaxhighlight>

Das Skript kann auch nur nach bestimmten Anwendungen suchen:

<syntaxhighlight lang=shell>
xyz00@h01:~$ hs-list-apps --app nextcloud
|-----------|---------------|-------|-----------------|----------------------------- -----|-------|-----|-----|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 33.0M | | |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
</syntaxhighlight>

Skript hs-list-apps

2026-06-10T08:19:34Z

Tim00: /* Beschreibung */

== Beschreibung ==

hs-list-apps ist ein Skript, in Python geschrieben, welches die aktuell installierten Anwendungen und die Belegung von RAM, SSD und HDD anzeigt.

Es hilft, gerade bei Paketen mit vielen Anwendungen, den Überblick zu behalten. Als Reseller will ich zum Beispiel wissen, wieviele Nextclouds in meinem Paket installiert sind, wieviel Platz sie belegen, und auf welchem Versionsstand sie sind.

Das Skript wird momentan hier gepflegt: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/hs-list-apps

== Einschränkungen ==

Es werden bisher einige Anwendungen unterstützt, aber längst nicht alle Anwendungen, die bei Hostsharing installiert werden können oder installiert worden sind. Weitere Anwendungen können gerne ins Skript aufgenommen werden. Bitte einen PR oder Issue auf dem Repo bei Codeberg aufmachen.

Es werden einige Annahmen getroffen, wo eine Anwendung zu finden ist. Damit vermeiden wir einen vollständigen Scan der Dateien, der sehr zeitintensiv wäre. z.B. wird erwartet, dass die Nextclouds alle im Benutzerverzeichnis im Ordner nextcloud liegen.

Es wird versucht, die richtige Domain zu bestimmen. Wenn im Benutzer aber mehrere Domains eingetragen sind, wird die mit dem längsten Namen angezeigt.

== Benutzung ==

Das Skript steht auf den Hives zur Verfügung, es liegt in /usr/local/bin, und ist damit Teil des Standardpfades.

Das Skript kann entweder innerhalb eines Benutzers aufgerufen werden:

<syntaxhighlight lang=shell>
xyz00-nextcloud@h01:~$ hs-list-apps --detail
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 164.7M | 1.4G | 131M |
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
</syntaxhighlight>

Ohne den Parameter --detail wird der SSD Platz und der HDD Platz nicht berechnet. Das kann sonst etwas Zeit in Anspruch nehmen.

Das Skript kann auch vom Paket Admin aufgerufen werden:

<syntaxhighlight lang=shell>
xyz00@h01:~$ hs-list-apps
|-----------|---------------|-------|-----------------|----------------------------- -----|-------|-----|-----|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
| Wordpress | 6.8.3 | xyz00 | mywordpresstest | https://www.example.de | 21.2M | | |
| OpenLDAP | 2.5.13+dfsg-5 | xyz00 | openldap | https://openldap.example.de | 28.5M | | |
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 33.0M | | |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
</syntaxhighlight>

Das Skript kann auch nur nach bestimmten Anwendungen suchen:

<syntaxhighlight lang=shell>
xyz00@h01:~$ hs-list-apps --app nextcloud
|-----------|---------------|-------|-----------------|----------------------------- -----|-------|-----|-----|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 33.0M | | |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
</syntaxhighlight>

Hs-list-apps

2026-06-10T08:18:29Z

Tim00: Tim00 verschob die Seite Hs-list-apps nach Skript hs-list-apps

#WEITERLEITUNG [[Skript hs-list-apps]]

Skript hs-list-apps

2026-06-10T08:18:29Z

Tim00: Tim00 verschob die Seite Hs-list-apps nach Skript hs-list-apps

== Beschreibung ==

hs-list-apps ist ein Skript, in Python geschrieben, welches die aktuell installierten Anwendungen und die Belegung von RAM, SSD und HDD anzeigt.

Das Skript wird momentan hier gepflegt: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/hs-list-apps

== Einschränkungen ==

Es werden bisher einige Anwendungen unterstützt, aber längst nicht alle Anwendungen, die bei Hostsharing installiert werden können oder installiert worden sind. Weitere Anwendungen können gerne ins Skript aufgenommen werden. Bitte einen PR oder Issue auf dem Repo bei Codeberg aufmachen.

Es werden einige Annahmen getroffen, wo eine Anwendung zu finden ist. Damit vermeiden wir einen vollständigen Scan der Dateien, der sehr zeitintensiv wäre. z.B. wird erwartet, dass die Nextclouds alle im Benutzerverzeichnis im Ordner nextcloud liegen.

Es wird versucht, die richtige Domain zu bestimmen. Wenn im Benutzer aber mehrere Domains eingetragen sind, wird die mit dem längsten Namen angezeigt.

== Benutzung ==

Das Skript steht auf den Hives zur Verfügung, es liegt in /usr/local/bin, und ist damit Teil des Standardpfades.

Das Skript kann entweder innerhalb eines Benutzers aufgerufen werden:

<syntaxhighlight lang=shell>
xyz00-nextcloud@h01:~$ hs-list-apps --detail
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 164.7M | 1.4G | 131M |
|-----------|---------|-------|-----------|-----------------------------------|--------|------|------|
</syntaxhighlight>

Ohne den Parameter --detail wird der SSD Platz und der HDD Platz nicht berechnet. Das kann sonst etwas Zeit in Anspruch nehmen.

Das Skript kann auch vom Paket Admin aufgerufen werden:

<syntaxhighlight lang=shell>
xyz00@h01:~$ hs-list-apps
|-----------|---------------|-------|-----------------|----------------------------- -----|-------|-----|-----|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
| Wordpress | 6.8.3 | xyz00 | mywordpresstest | https://www.example.de | 21.2M | | |
| OpenLDAP | 2.5.13+dfsg-5 | xyz00 | openldap | https://openldap.example.de | 28.5M | | |
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 33.0M | | |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
</syntaxhighlight>

Das Skript kann auch nur nach bestimmten Anwendungen suchen:

<syntaxhighlight lang=shell>
xyz00@h01:~$ hs-list-apps --app nextcloud
|-----------|---------------|-------|-----------------|----------------------------- -----|-------|-----|-----|
| AppName | Version | PAC | USER | URL | RAM | SSD | HDD |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
| Nextcloud | 32.0.6 | xyz00 | nextcloud | https://test.nextcloud.example.de | 33.0M | | |
|-----------|---------------|-------|-----------------|-----------------------------------|-------|-----|-----|
</syntaxhighlight>

Skript hs-list-apps

2026-06-10T08:17:59Z

Tim00: Die Seite wurde neu angelegt: „== Beschreibung == hs-list-apps ist ein Skript, in Python geschrieben, welches die aktuell installierten Anwendungen und die Belegung von RAM, SSD und HDD anzeigt. Das Skript wird momentan hier gepflegt: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/hs-list-apps == Einschränkungen == Es werden bisher einige Anwendungen unterstützt, aber längst nicht alle Anwendungen, die bei Hostsharing installiert werden können oder installier…“

Benutzer:Tim00

2026-06-10T08:14:16Z

Tim00:

Ich heiße Timotheus Pokorra. Ich bin in Siegen, NRW aufgewachsen, und lebe jetzt in Plauen, Sachsen.

Ich bin seit Juni 2002 Mitglied bei Hostsharing.

Seit Oktober 2016 bin ich für die Wartung der Seite wiki.hostsharing.net zuständig.

Seit März 2023 bin ich als Hostmaster und Software-Entwickler bei Hostsharing in Teilzeit angestellt.

Kategorie:Installationsanleitungen

2026-06-10T08:04:59Z

Tim00: /* Tools */

{{HSDoku-Links}}
Manche Software wird von vielen unserer Mitglieder verwendet. Deshalb werden hier Installationen dokumentiert, wie sie bei anderen Mitgliedern funktionieren, um die Sache zu erleichtern.

Es gibt auch eine [[Hostsharing_Wiki:Wunschliste Installationsanleitungen|Wunschliste]], in der du Software eintragen kannst, für die du dir eine Installationsanleitung wünscht.

Zum Entfernen einer Anwendung, kannst du dieser Anleitung folgen: [[Deinstallieren einer Anwendung]]

=== Freie und datenschutzfreundliche Software-Alternativen ===

Linksammlungen, die helfen, alternative Software zu finden:

* https://switching.software/
* https://prism-break.org/de/

=== Tools ===
Liste mit Tools, die von Hostsharing Mitgliedern veröffentlicht wurden.

* http://hs.andreasloesch.de
* https://codeberg.org/tpokorra/hostsharing-scripts
** z.B. [[hs-list-apps]] zum Anzeigen der installierten Anwendungen
* https://codeberg.org/tpokorra/hs.ansible

[[Kategorie:HSDoku]]

Kategorie:Installationsanleitungen

2026-06-10T08:02:04Z

Tim00: /* Tools */

{{HSDoku-Links}}
Manche Software wird von vielen unserer Mitglieder verwendet. Deshalb werden hier Installationen dokumentiert, wie sie bei anderen Mitgliedern funktionieren, um die Sache zu erleichtern.

Es gibt auch eine [[Hostsharing_Wiki:Wunschliste Installationsanleitungen|Wunschliste]], in der du Software eintragen kannst, für die du dir eine Installationsanleitung wünscht.

Zum Entfernen einer Anwendung, kannst du dieser Anleitung folgen: [[Deinstallieren einer Anwendung]]

=== Freie und datenschutzfreundliche Software-Alternativen ===

Linksammlungen, die helfen, alternative Software zu finden:

* https://switching.software/
* https://prism-break.org/de/

=== Tools ===
Liste mit Tools, die von Hostsharing Mitgliedern veröffentlicht wurden.

* http://hs.andreasloesch.de
* https://codeberg.org/tpokorra/hostsharing-scripts
* https://codeberg.org/tpokorra/hs.ansible

[[Kategorie:HSDoku]]

Wordpress

2026-06-06T20:52:23Z

Tim00: /* Seiten Cache einrichten */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

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

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

== Seiten Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Seiten-Cache wurde nicht erkannt, ...", kann das Plugin WP Super Cache von Automattic installiert werden: https://wordpress.org/plugins/wp-super-cache/

Der Cache muss dann in den Einstellungen des Plugins aktiviert werden.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-06-06T20:47:25Z

Tim00: /* Objekt Cache einrichten */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

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

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

Falls bei dem Bericht über den Zustand der Webseite dieser Eintrag erscheint: "Du solltest einen persistenten Objekt-Cache verwenden", sollte [[Redis#Redis_installieren|Redis installiert]] werden. Es reicht, wenn Redis auf einem Unix-Socket läuft, es muss nicht auf einem Port laufen.

In der wp-config.php sollte dann (relativ weit oben) eingetragen werden:

<syntaxhighlight lang="php">
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/home/pacs/xyz00/users/service/redis/var/redis-server.sock');
define('WP_REDIS_PASSWORD', 'topsecret');
</syntaxhighlight>

Dann kann z.B. das Plugin "Redis Object Cache" von Till Küss installiert werden: https://de.wordpress.org/plugins/redis-cache/

Danach lässt sich der Object Cache unter "Einstellungen / Redis" aktivieren.

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Redis

2026-06-06T20:38:07Z

Tim00: /* Konfiguration */ maxmemory

== Redis installieren ==

'''Redis''' ist ein einfacher Datenspeicher für Schlüssel-Wert-Paare. Datensätze werden jeweils unter einem Schlüssel abgelegt. Die Daten werden jeweils im Hauptspeicher gehalten und nur zu konfigurierbaren Zeitpunkten auf die Festplatte gesichert.

Redis-Datenbanken werden häufig zur Speicherung von Warteschlangen benutzt. In Redis werden Aufträge gespeichert, die asynchron von Hintergrundprogrammen abgearbeitet werden.

=== Konfiguration ===

Redis ist auf den Hostsharing-Servern vorinstalliert. Für die Nutzung muss lediglich eine Konfigurationsdatei angelegt werden und ein Hitergrundprogramm gestartet werden.

Im folgenden wird für den User ''xyz00-service'' ein Redis-Dienst eingerichtet.
Der User ''xyz00-service'' ist in HSAdmin mit ''/bin/bash'' als Shell eingerichtet.

Nach dem Login als ''xyz00-service'' lege ich Verzeichnisse ''~/redis/etc'' und ''~/redis/var'' an:

<syntaxhighlight lang="shell">
mkdir -p redis/{etc,var}
</syntaxhighlight>

Im etc-Verzeichnis wird die Konfigurationsdatei ''redis.conf'' für den Redis-Dienst abgelegt.

Eine Beispiel-Konfiguration ist:

<syntaxhighlight lang="shell" line>
requirepass <generiertes-passwort>
bind 127.0.0.1
port 33033
tcp-backlog 128
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/service/redis/var/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/service/redis/var/
maxmemory 500mb
maxmemory-policy allkeys-lru
</syntaxhighlight>

Der Redis-Dienst ist über die Server-lokale Netzwerk-Adresse 127.0.0.1 erreichbar und mit einem Passwort geschützt. Der Port ''33033'' für die Netzwerk-Schnittstelle muss ggf. angepasst werden.

Der Dienst wird gestartet mit:

<syntaxhighlight lang="shell">
xyz00-service@h00:~/redis$ /usr/bin/redis-server etc/redis.conf
</syntaxhighlight>

Mit Ctrl-C kann der Dienst wieder gestoppt werden.

Alternativ kann der zugriff auf Redis über einen Unixsocket erfolgen. Dann entfällt die Zeile 'bind 127.0.0.1' in der Konfiguration, der port wird auf 0 gesetzt. Stattdessen wir ein Unixsocket konfiguriert:

<syntaxhighlight lang="shell" line>
unixsocket /home/pacs/xyz00/users/service/redis/var/redis-server.sock
unixsocketperm 700
port 0
</syntaxhighlight>

(der Unixsocket benötigt in der Konfiguration den vollständigen absoluten Pfad zum Socket im Dateisystem!)

=== Einrichtung als Server-Dienst ===

'''Redis''' soll über den Systemdienst '''SystemD''' automatisch im Hintergrund gestartet werden.

Dazu wird im Verzeichnis ''~/.config/systemd/user'' eine Datei ''redis.service'' mit dem folgenden Inhalt angelegt:

<syntaxhighlight lang="ini" line>
[Unit]
Description=Redis Service
After=network-online.target

[Service]
WorkingDirectory=%h/redis
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=/usr/bin/redis-server %h/redis/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Die Datei wird mit den folgenden Shell-Kommandos geladen und aktiviert:

<syntaxhighlight lang="shell">
systemctl --user daemon-reload
systemctl --user enable --now redis.service
</syntaxhighlight>

Mit den Kommandos

<syntaxhighlight lang="shell">
systemctl --user status
systemctl --user status redis.service
</syntaxhighlight>

kann der Status des Dienstes ermittelt werden.

=== Links ===

* [https://redis.io/ Internetseite des Redis Projekts]

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

Wordpress

2026-06-06T20:31:14Z

Tim00: Objekt Cache einrichten

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

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

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

== Objekt Cache einrichten ==

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Prozessmanagement mit systemd im Userspace

2026-06-06T05:30:55Z

Tim00: /* Einrichten des »service-files« */

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

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

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

== Eigene Serverdienste mit systemd ==

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

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

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

Die Ausgabe sollte sein:

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

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

=== systemd Units ===

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

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

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

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

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

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

Folgende Eigenschaften sind einstellbar:

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

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

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

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

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

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

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

=== systemd Unit starten und stoppen ===

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

==== Reload ====

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

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

==== Start und Stopp ====

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

bzw.

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

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

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

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

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

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

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

==== Status ====

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

oder

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

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

=== Ressourcen einer systemd Unit beschränken ===

Mit den folgenden Befehlen können die zur Verfügung stehenden Ressourcen einer systemd Unit beschränkt werden:

<syntaxhighlight lang="bash">
systemctl --user set-property gitea.service MemoryMax=500M
systemctl --user set-property gitea.service CPUQuota=25%
systemctl --user set-property gitea.service TasksMax=100
systemctl --user daemon-reload
</syntaxhighlight>

== Zeitgesteuerte Ausführung mit systemd ==

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

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

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

[Unit]
Description=My Cleanup Service

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

ExecStopPost=/usr/local/bin/hs-notify-unit-failure %N %H %u $EXIT_CODE $SERVICE_RESULT %u
</syntaxhighlight>

Bemerkung: das Skript hs-notify-unit-failure schickt bei einem Fehler des Hauptskripts eine E-Mail an den aktuellen Benutzer, die über .forward oder über .procmailrc auch an eine andere E-Mail Adresse weitergeleitet werden kann.

Alternativ kann auch eine Umgebungsvariable (z.B. MAILTO) gesetzt werden, in der mehrere E-Mailadressen mit Komma getrennt sein dürfen:

<syntaxhighlight lang=bash line>
Environment="MAILTO=email1@example.org,alarm@example.org"
ExecStopPost=/usr/local/bin/hs-notify-unit-failure %N %H %u $EXIT_CODE $SERVICE_RESULT $MAILTO
</syntaxhighlight>

=== Testen ===

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

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

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

[Unit]
Description=Daily My Cleanup Timer

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

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

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

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

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

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

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

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

Eine ausführliche Dokumentation der Direktiven findet sich hier:

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

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

Der Timer muss noch aktiviert und gestartet werden:

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

=== Übersicht über die Timer im aktuellen User ===

<syntaxhighlight lang=bash>
$ systemctl --user list-timers --all
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

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

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

ansehen.

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

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

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

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

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

Wenn ich einen systemctl Befehl ausführe, kommt:

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

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

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

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

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

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

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

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

= weiterführende Links =

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

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

Wordpress

2026-06-06T05:17:03Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

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

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
SELECT m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name
FROM wp_usermeta AS m join wp_users AS u ON m.user_id = u.id
WHERE meta_value LIKE '%administrator%';
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-06-06T05:16:13Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

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

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

In der Datenbank sollten die Benutzer mit administrator Rechten kontrolliert werden:

<syntaxhighlight lang=sql>
select m.meta_key, m.meta_value, u.id, u.user_login, u.user_email, u.display_name from wp_usermeta as m join wp_users as u ON m.user_id = u.id where meta_value like '%administrator%'
;
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-06-05T20:44:27Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

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

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-06-05T20:08:22Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

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

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

Verdächtige Dateien finden, die versuchen, einen Benutzer mit administrator Rechten anzulegen:

<syntaxhighlight lang=shell>
grep -r '\\"administrator\\"' wp-content/languages/plugins/
grep -r '\\"administrator\\"' --include \*.php wp-content/cache/
grep -r '\\"administrator\\"' --include \*.php wp-content/uploads/
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-06-02T04:35:25Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

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

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

Verdächtige Dateien im uploads und cache Verzeichnis finden:

<syntaxhighlight lang=shell>
find wp-content/uploads wp-content/cache -type f \
$ -name '*.php' -o -name '*.phtml' -o -name '*.phar' -o -name '*.ico' $ -ls
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Login mit SSH

2026-06-02T04:03:47Z

Tim00: Einrückung von Unterthemen

{{Baustelle}}

Um sich einloggen zu können, brauchst Du natürlich die Daten, die Dir von Hostsharing in einer Mail nach der Anmeldung zugeschickt wurden:

Hostname: '''xyz00.hostsharing.net''' (wenn eine eigene Domain konnektiert ist auch <eigene-domain>.<tld>)

Username: '''xyz00'''

Passwort: '''(wie in der automatischen Mail mitgeteilt)'''

Bei xyz00 handelt es sich um den Account des Paket-Admins. Initial ist für jedes neue Paket nur ein Admin-Account eingerichtet, dessen Benutzername die Form '''xyz00''' besitzt.

Da dieser Account sehr viel Macht über das Paket hat, darf er nur über sichere Protokolle wie SSH benutzt werden. Unsichere Protokolle wie direktes FTP dürfen nicht verwendet werden, da diese die Passwörter im Klartext übertragen. Jeder Administrator auf der Übertragungsstrecke könnte mitlesen.

Gleich vorab: Seine Website kann man später freilich über einen separaten Account per ftps, sftp, scp (und zur Not auch ftp) hochladen, doch dazu später mehr.

Linux Systeme haben meist ssh, scp und sftp Clients vorinstalliert. Eine Freie Software zum sicheren Dateitransfer für Windows ist z.B. [http://winscp.net WinSCP] und ein Shell Zugang mit [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY].

Nach der ggf. nötigen Installation eines ssh Clients, die hier nicht beschrieben werden, da sie nicht Hostsharing-spezifisch ist, kann der erste Login erfolgen.

== Login ==

Mit OpenSSH ist der Aufruf auf der Kommandozeile z.B. folgender:

ssh xyz00@xyz00.hostsharing.net

Nach Aufbau der Verbindung wird dann das [[Passwort]] erfragt.
Danach erscheint in etwa folgende Bildschirmausgabe:

<syntaxhighlight lang="bash">
Last login: Fri Apr 19 06:43:45 2002 from p5081f0c7.dip.t-dialin.net on pts/7

Linux hopi 2.4.17 #2 SMP Thu Jan 17 14:35:38 CET 2002 i686 unknown

+----------------------------------------------------------------+
| hopi.hostsharing.net |
| Bei Fragen oder Problemen bitte E-Mail an: |
| support@hostsharing.net (öffentliche Mailingliste) |
+----------------------------------------------------------------+

Last login: Fri Apr 19 09:36:34 2002 from 62.156.160.59

xyz0@hopi:~$ █
</syntaxhighlight>

Es macht durchaus Sinn, die ganz oben genannte "Last Login" Zeile zu prüfen, ob man dies auch selbst war (Uhrzeit und Provider), unten die "Last Login" Zeile gibt genau genommen das aktuelle Login aus, weil der Programmteil nach dem eigentlichen Login ausgeführt wird.

Als nächstes ändern wir gleich unser [[Passwort]], da dieses schließlich unverschlüsselt per E-Mail versendet wurde. Dies geschieht unter UNIX mit dem Kommando passwd

== Passwort ändern ==

Eine Änderung des Passwortes geht dem Befehl passwd:

<syntaxhighlight lang="bash">
xyz00@hopi:~$ passwd

Changing password for xyz00

(current) UNIX password: ALTESPASSWORT

Enter new UNIX password: NEUESPASSWORT

Retype new UNIX password: NEUESPASSWORT

passwd: password updated successfully

xyz00@hopi:~$ █

</syntaxhighlight>

Die Platzhalter '''NEUESPASSWORT''' und '''ALTESPASSWORT''' müssen dabei selbstverständlich gegen die entsprechenden [[Passworte]] ausgetauscht werden. Dabei sollte jedes Passwort mindestens 6 Zeichen lang sein, besser 8 Zeichen, und aus Buchstaben, Ziffern und ggf. Sonderzeichen bestehen. Allerdings sollte auf Umlaute verzichtet werden, da diese je nach verwendetem Zugangsweg nicht verwendet werden könnten.

Ggf. kommt es zu Fehlermeldungen, z.B. wenn das neue [[Passwort]] zu simpel ist, oder bei der Wiederholung nicht identisch mit dem ersten Passwort ist. In dem Fall, den Vorgang einfach wiederholen. Solange das neue Passwort nicht erfolgreich übernommen wurde, bleibt das alte gültig.

Es gibt User, denen der Paket-Admin nur das Recht eingeräumt hat, das eigene Passwort zu ändern, indem er ihnen die "Shell" /usr/bin/passwd zugewiesen hat. Diese User können durch einen Shell-Login nur ihr Passwort ändern, da das Programm passwd an Stelle einer Shell gestartet wird. Sie werden nach dem Einloggen automatisch auf diesen Dialog geführt.Mehr dazu unter [[User#Rechte]].

==Sitzung beenden==

Um die Sitzung zu beenden, sich also auszuloggen, gibt man exit ein. Das sieht dann so aus:

<syntaxhighlight lang="bash">
xyz00@hopi:~$ exit
logout
Connection to xyz00.hostsharing.net closed.
</syntaxhighlight>
== Login ohne Passwort ==
Um logins durch automatisierte Versuche zu erschweren sind auf den shared hosts Mechanismen in Betrieb, die ein Login mit Passwort erschweren, zum Beispiel durch ein Timeout, dass die Eingabe eines Passworts, wenn sie zu lange dauert, nicht funktioniert.
<syntaxhighlight lang="bash">
(xyz00@xyz00.hostsharing.net) Password:
Connection closed by 2a01:37:1000::53df:4f85:0 port 22
</syntaxhighlight>
Man muss also das Passwort in der Zwischenablage haben, dann den Loginbefehl geben und dann sofort das Passwort eingeben. Das ist in vielerlei hinsicht unsicher, da die Zwischenablage evtl gespeichert wird. (ein passwort Manager wie keepassXC löscht die eigenen Abgelegten Werte per Default nach einigen Sekunden), diese Methode, weil es wirklich schnell gehen muss (wenige Sekunden zur Passworteingabe) kann auch zu anderen Fehler führen die dass Passwort offenlegen, z.B. weil es versehentlich in der Hektik in ein falsches Fenster gepostet wird.
Auch aus anderen Gründen sollte daher der Zugang über SSH mit einem Schlüsselpaar erfolgen.

== Login mit SSH Key ==

Es besteht die Möglichkeit, einen public SSH Key in den Benutzer hochzuladen. Dann kann die Anmeldung über den privaten Key erfolgen. Siehe auch zur Erstellung des Key Paares: [https://www.heise.de/tipps-tricks/SSH-Key-erstellen-so-geht-s-4400280.html]

Der public SSH Key muss dann hier gespeichert werden:

<syntaxhighlight lang="bash">
mkdir -p ~/.ssh
nano .ssh/authorized_keys
# hier den public Key einfügen, und speichern
chmod 600 .ssh/authorized_keys
</syntaxhighlight>

Manchmal schlägt bei Power-Usern die Anmeldung fehl, wenn zu viele SSH Keys zur Verfügung stehen, und die alle durchprobiert werden. Dann kommt nach einer gewissen Anzahl die Fehlermeldung: zu viele Anmeldungsversuche.

Die Lösung: beim SSH Aufruf muss der richtige private Key referenziert werden, und die anderen Keys ignoriert werden:

<syntaxhighlight lang="bash">
ssh -p 22 -i /root/.ssh/id_ed25519 -o IdentitiesOnly=yes xyz00@xyz00.hostsharing.net
</syntaxhighlight>

== Zusätzliche Möglichkeiten ==

=== Bestimmte Shell Kommandos automatisch ausführen ===

Lege in dem Verzeichnis, in dem Du direkt nach dem Login landest, mit dem Editor Deiner Wahl die Datei .bash_profile mit folgendem Inhalt an:
<syntaxhighlight lang="bash" line>
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
BASH_ENV=$HOME/.bashrc
</syntaxhighlight>

Und nun kannst du in der Datei .bashrc shell Kommandos eingeben. z.B.: quota -g

=== Editor in der Shell einstellen ===

1. manuell Einloggen und:
<syntaxhighlight lang="ini">
VISUAL=nano
export VISUAL
EDITOR=nano
export EDITOR
</syntaxhighlight>

2. in der bash geht es auch kürzer:
<syntaxhighlight lang="bash">
export EDITOR=nano
export VISUAL=nano
</syntaxhighlight>

3. automatisch bei jedem Login
Mit obigen Kommandos in der ~/.bash_profile-Datei.

=== Als Paketadmin in einen Unterbenutzer wechseln ===

Wenn du als Paketadmin xyz00 per SSH angemeldet bist, kannst du ohne Passwort in den Unterbenutzer xyz00-webseite wechseln:

<syntaxhighlight lang="bash">
sudo -iu xyz00-webseite
</syntaxhighlight>

Bei Unix-Benutzern, die z.B. nur für Postfächer genutzt werden, ist als Shell nur passwd eingerichtet. Daher musst du bei sudo die gewünsche Shell angeben:

<syntaxhighlight lang="bash">
sudo -u xyz00-mail_klaus -s bash
</syntaxhighlight>

==Weiterführende Links==

[[HS-Server:SSH-Hostkeys]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Einstieg bei Hostsharing]]
[[Kategorie:Glossar]]

Login mit SSH

2026-06-02T04:02:52Z

Tim00: Als Paketadmin in einen Unterbenutzer wechseln

{{Baustelle}}

Um sich einloggen zu können, brauchst Du natürlich die Daten, die Dir von Hostsharing in einer Mail nach der Anmeldung zugeschickt wurden:

Hostname: '''xyz00.hostsharing.net''' (wenn eine eigene Domain konnektiert ist auch <eigene-domain>.<tld>)

Username: '''xyz00'''

Passwort: '''(wie in der automatischen Mail mitgeteilt)'''

Bei xyz00 handelt es sich um den Account des Paket-Admins. Initial ist für jedes neue Paket nur ein Admin-Account eingerichtet, dessen Benutzername die Form '''xyz00''' besitzt.

Da dieser Account sehr viel Macht über das Paket hat, darf er nur über sichere Protokolle wie SSH benutzt werden. Unsichere Protokolle wie direktes FTP dürfen nicht verwendet werden, da diese die Passwörter im Klartext übertragen. Jeder Administrator auf der Übertragungsstrecke könnte mitlesen.

Gleich vorab: Seine Website kann man später freilich über einen separaten Account per ftps, sftp, scp (und zur Not auch ftp) hochladen, doch dazu später mehr.

Linux Systeme haben meist ssh, scp und sftp Clients vorinstalliert. Eine Freie Software zum sicheren Dateitransfer für Windows ist z.B. [http://winscp.net WinSCP] und ein Shell Zugang mit [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY].

Nach der ggf. nötigen Installation eines ssh Clients, die hier nicht beschrieben werden, da sie nicht Hostsharing-spezifisch ist, kann der erste Login erfolgen.

== Login ==

Mit OpenSSH ist der Aufruf auf der Kommandozeile z.B. folgender:

ssh xyz00@xyz00.hostsharing.net

Nach Aufbau der Verbindung wird dann das [[Passwort]] erfragt.
Danach erscheint in etwa folgende Bildschirmausgabe:

<syntaxhighlight lang="bash">
Last login: Fri Apr 19 06:43:45 2002 from p5081f0c7.dip.t-dialin.net on pts/7

Linux hopi 2.4.17 #2 SMP Thu Jan 17 14:35:38 CET 2002 i686 unknown

+----------------------------------------------------------------+
| hopi.hostsharing.net |
| Bei Fragen oder Problemen bitte E-Mail an: |
| support@hostsharing.net (öffentliche Mailingliste) |
+----------------------------------------------------------------+

Last login: Fri Apr 19 09:36:34 2002 from 62.156.160.59

xyz0@hopi:~$ █
</syntaxhighlight>

Es macht durchaus Sinn, die ganz oben genannte "Last Login" Zeile zu prüfen, ob man dies auch selbst war (Uhrzeit und Provider), unten die "Last Login" Zeile gibt genau genommen das aktuelle Login aus, weil der Programmteil nach dem eigentlichen Login ausgeführt wird.

Als nächstes ändern wir gleich unser [[Passwort]], da dieses schließlich unverschlüsselt per E-Mail versendet wurde. Dies geschieht unter UNIX mit dem Kommando passwd

== Passwort ändern ==

Eine Änderung des Passwortes geht dem Befehl passwd:

<syntaxhighlight lang="bash">
xyz00@hopi:~$ passwd

Changing password for xyz00

(current) UNIX password: ALTESPASSWORT

Enter new UNIX password: NEUESPASSWORT

Retype new UNIX password: NEUESPASSWORT

passwd: password updated successfully

xyz00@hopi:~$ █

</syntaxhighlight>

Die Platzhalter '''NEUESPASSWORT''' und '''ALTESPASSWORT''' müssen dabei selbstverständlich gegen die entsprechenden [[Passworte]] ausgetauscht werden. Dabei sollte jedes Passwort mindestens 6 Zeichen lang sein, besser 8 Zeichen, und aus Buchstaben, Ziffern und ggf. Sonderzeichen bestehen. Allerdings sollte auf Umlaute verzichtet werden, da diese je nach verwendetem Zugangsweg nicht verwendet werden könnten.

Ggf. kommt es zu Fehlermeldungen, z.B. wenn das neue [[Passwort]] zu simpel ist, oder bei der Wiederholung nicht identisch mit dem ersten Passwort ist. In dem Fall, den Vorgang einfach wiederholen. Solange das neue Passwort nicht erfolgreich übernommen wurde, bleibt das alte gültig.

Es gibt User, denen der Paket-Admin nur das Recht eingeräumt hat, das eigene Passwort zu ändern, indem er ihnen die "Shell" /usr/bin/passwd zugewiesen hat. Diese User können durch einen Shell-Login nur ihr Passwort ändern, da das Programm passwd an Stelle einer Shell gestartet wird. Sie werden nach dem Einloggen automatisch auf diesen Dialog geführt.Mehr dazu unter [[User#Rechte]].

==Sitzung beenden==

Um die Sitzung zu beenden, sich also auszuloggen, gibt man exit ein. Das sieht dann so aus:

<syntaxhighlight lang="bash">
xyz00@hopi:~$ exit
logout
Connection to xyz00.hostsharing.net closed.
</syntaxhighlight>
== Login ohne Passwort ==
Um logins durch automatisierte Versuche zu erschweren sind auf den shared hosts Mechanismen in Betrieb, die ein Login mit Passwort erschweren, zum Beispiel durch ein Timeout, dass die Eingabe eines Passworts, wenn sie zu lange dauert, nicht funktioniert.
<syntaxhighlight lang="bash">
(xyz00@xyz00.hostsharing.net) Password:
Connection closed by 2a01:37:1000::53df:4f85:0 port 22
</syntaxhighlight>
Man muss also das Passwort in der Zwischenablage haben, dann den Loginbefehl geben und dann sofort das Passwort eingeben. Das ist in vielerlei hinsicht unsicher, da die Zwischenablage evtl gespeichert wird. (ein passwort Manager wie keepassXC löscht die eigenen Abgelegten Werte per Default nach einigen Sekunden), diese Methode, weil es wirklich schnell gehen muss (wenige Sekunden zur Passworteingabe) kann auch zu anderen Fehler führen die dass Passwort offenlegen, z.B. weil es versehentlich in der Hektik in ein falsches Fenster gepostet wird.
Auch aus anderen Gründen sollte daher der Zugang über SSH mit einem Schlüsselpaar erfolgen.

== Login mit SSH Key ==

Es besteht die Möglichkeit, einen public SSH Key in den Benutzer hochzuladen. Dann kann die Anmeldung über den privaten Key erfolgen. Siehe auch zur Erstellung des Key Paares: [https://www.heise.de/tipps-tricks/SSH-Key-erstellen-so-geht-s-4400280.html]

Der public SSH Key muss dann hier gespeichert werden:

<syntaxhighlight lang="bash">
mkdir -p ~/.ssh
nano .ssh/authorized_keys
# hier den public Key einfügen, und speichern
chmod 600 .ssh/authorized_keys
</syntaxhighlight>

Manchmal schlägt bei Power-Usern die Anmeldung fehl, wenn zu viele SSH Keys zur Verfügung stehen, und die alle durchprobiert werden. Dann kommt nach einer gewissen Anzahl die Fehlermeldung: zu viele Anmeldungsversuche.

Die Lösung: beim SSH Aufruf muss der richtige private Key referenziert werden, und die anderen Keys ignoriert werden:

<syntaxhighlight lang="bash">
ssh -p 22 -i /root/.ssh/id_ed25519 -o IdentitiesOnly=yes xyz00@xyz00.hostsharing.net
</syntaxhighlight>

== Zusätzliche Möglichkeiten ==

== Bestimmte Shell Kommandos automatisch ausführen ==

Lege in dem Verzeichnis, in dem Du direkt nach dem Login landest, mit dem Editor Deiner Wahl die Datei .bash_profile mit folgendem Inhalt an:
<syntaxhighlight lang="bash" line>
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
BASH_ENV=$HOME/.bashrc
</syntaxhighlight>

Und nun kannst du in der Datei .bashrc shell Kommandos eingeben. z.B.: quota -g

== welcher Editor in der shell ==

1. manuell Einloggen und:
<syntaxhighlight lang="ini">
VISUAL=nano
export VISUAL
EDITOR=nano
export EDITOR
</syntaxhighlight>

2. in der bash geht es auch kürzer:
<syntaxhighlight lang="bash">
export EDITOR=nano
export VISUAL=nano
</syntaxhighlight>

3. automatisch bei jedem Login
Mit obigen Kommandos in der ~/.bash_profile-Datei.

== Als Paketadmin in einen Unterbenutzer wechseln ==

Wenn du als Paketadmin xyz00 per SSH angemeldet bist, kannst du ohne Passwort in den Unterbenutzer xyz00-webseite wechseln:

<syntaxhighlight lang="bash">
sudo -iu xyz00-webseite
</syntaxhighlight>

Bei Unix-Benutzern, die z.B. nur für Postfächer genutzt werden, ist als Shell nur passwd eingerichtet. Daher musst du bei sudo die gewünsche Shell angeben:

<syntaxhighlight lang="bash">
sudo -u xyz00-mail_klaus -s bash
</syntaxhighlight>

==Weiterführende Links==

[[HS-Server:SSH-Hostkeys]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Einstieg bei Hostsharing]]
[[Kategorie:Glossar]]

Wordpress

2026-06-01T20:38:10Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

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

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden:

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Wordpress

2026-06-01T20:37:52Z

Tim00: /* Gehackte Dateien identifizieren */

= Wordpress in 5 Minuten =

Installiert wird Wordpress hier unter der Domain https://blog.example.org.

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -i
Password: ********
</syntaxhighlight>
Dann nacheinander anlegen:

* Linux User als Domain-Administrator
* Subdomain ''blog.example.org''
* MySQL-User
* MySQL Datenbank
<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-blog',password:'geheim',shell:'/bin/bash',comment:'Wordpress Blog'}})
xyz00@hsadmin> domain.add({set:{name:'blog.example.org',user:'xyz00-blog'}})
xyz00@hsadmin> mysqluser.add({set:{name:'xyz00_wpuser',password:'geheim'}})
xyz00@hsadmin> mysqldb.add({set:{name:'xyz00_wpdb',owner:'xyz00_wpuser'}})
</syntaxhighlight>
== Wordpress installieren ==

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

ssh -l xyz00-blog xyz00.hostsharing.net

''htdocs-ssl'' Verzeichnis vorbereiten

<syntaxhighlight lang=shell>
cd doms/blog.example.org
rm -rf subs/www subs-ssl/www
cd htdocs-ssl
rm .htaccess
</syntaxhighlight>

Wordpress downloaden & entpacken z.b. im htdocs-ssl Verzeichnis

<syntaxhighlight lang=shell>
wget -O - https://wordpress.org/latest.tar.gz |tar -xz --strip 1
</syntaxhighlight>

== Wordpress konfigurieren ==

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

= Verschiedene Hinweise und Anleitungen =
== wp-cli installieren ==

wp-cli ist das Kommandozeilen-Werkzeug für WordPress: https://wp-cli.org/de/

Es kann so installiert werden:

<syntaxhighlight lang=shell>
mkdir ~/bin
cd ~/bin
wget https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod a+x wp-cli.phar
</syntaxhighlight>

== Uraltes Wordpress aktualisieren ==

Manche Wordpress Installationen sind so alt, dass wp-login nicht mehr funktioniert.

Mit wp-cli kann Wordpress auf die aktuelle Version aktualisiert werden:

<syntaxhighlight lang=shell>
cd ~/wordpress # oder ~/doms/meinedomain.de/subs-ssl/www/ oder wo sonst Wordpress installiert ist
~/bin/wp-cli.phar core update
</syntaxhighlight>

== Gehackte Dateien identifizieren ==

Falls die Wordpress Instanz gehackt wurde, müssen die veränderten Dateien identifiziert und gelöscht werden.

Das geht wieder mit wp-cli.

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar core verify-checksums
~/bin/wp-cli.phar plugin --skip-themes --skip-plugins verify-checksums --all
</syntaxhighlight>

in der wp-config.php sollte keine verdächtige Datei eingebunden werden

<syntaxhighlight lang=shell>
grep include wp-config.php
</syntaxhighlight>

== Einen Admin Benutzer hinzufügen ==

Wenn du die Pflege einer WordPress Instanz übernehmen sollst, aber noch keinen Admin Benutzer hast:

<syntaxhighlight lang=shell>

~/bin/wp-cli.phar user create meinuser admin@example.org --role=administrator
</syntaxhighlight>

Entsprechend kann der Benutzer auch wieder gelöscht werden:

<syntaxhighlight lang=shell>
cd ~/wordpress
~/bin/wp-cli.phar user delete meinuser
</syntaxhighlight>

== Bestehendes Wordpress auf neue Domain umziehen ==
Meistens muss nichts weiter geändert werden als die Home und die SITE_URL Option.

Einfach zu ändern geht das indem man sich via phpmyadmin.hostsharing.net in den Datenbank User des Wordpress einloggt und sich die Tabelle wp_options ansieht. Dort müssen die Zeilen mit `siteurl` und `home` an die neuen URLs angepasst werden.

Alternativ kann man das auch über das wp-config.php machen. Meistens gibt es die beiden Einträge noch nicht, einfach an die passende Stelle für die Custom Config neu eintragen:

<syntaxhighlight lang=php>
define('WP_HOME','https://www.new-domain.de/');
define('WP_SITEURL','https://www.new-domain.de/');
</syntaxhighlight>

Generell lohnt es sich die wp_options Tabelle mal noch auf alte Domain Einträge zu untersuchen und ggf zu ersetzen.
Das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%https://old-domain.de%"
</syntaxhighlight>

== Bestehendes Wordpress auf neuen User / Server umziehen / Uploads auf Storage auslagern ==

Meistens muss dafür keine weitere Änderung vorgenommen werden. Manchmal haben vorherige Anbieter einen alternativen Upload Pfad gesetzt. Das zeigt sich dadurch das man angeblich keine Schreibberechtigungen hätte beim Hochladen von z.B. Bildern.

Eine Möglichkeit was dort kaputt sein könnte ist, das die Option `upload_path` noch auf einen alten Pfad vom alten Anbieter gesetzt wurde. Diese Option ist auch zu gebrauchen wenn der häufiger doch mal recht schnell wachsende Uploads Ordner auf den Storage und nicht auf die SSD ausgelagert werden soll.

In der wp_options DB-Tabelle muss entsprechend die Variable `upload_path` angepasst werden. z.B. für den User xyz00-wordpress zu /home/storage/xyz00/users/wordpress/uploads

Generell lohnt es sich die wp_options Tabelle noch mal auf den Alten Pfad zu untersuchen und ggf. anzupassen, das geht z.B. so:

<syntaxhighlight lang=sql>
SELECT * FROM wp_options WHERE option_value LIKE "%/old/path/%"
</syntaxhighlight>

= Links =

*[https://wordpress.org/ Offizielle Webseite von Wordpress]
*[https://wp-cli.org/de/ WP-CLI ist das Kommandozeilen-Werkzeug für WordPress]
*[https://github.com/tpokorra/Hostsharing-Ansible-Wordpress Ansible Playbook für Hostsharing]

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Blog]]
[[Kategorie:CMS]]

Mlmmj

2026-05-18T14:02:31Z

Tim00: /* Einrichtung */

[http://www.mlmmj.org/ mlmmj], angeblich eine Abkürzung für "Mailing List Management Made Joyful", ist ein Programm, mit dem in einem Hostsharing Paket E-Mail-Verteiler realisiert werden kann.

Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese vielleicht auch den Wikipedia-Artikel:
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]

Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.

Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.

== Voraussetzungen ==

Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert. (Wer die Software selbst kompilieren möchte kann aktuellen Source-Code bei [https://codeberg.org/mlmmj/mlmmj codeberg.org] finden.)

Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.

In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.

Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein. Den lokalen Teil dieser Adresse, ''discuss'', ist der Listenname. Der Listenname darf auf keinen Fall das Plus-Zeichen (+) enthalten, weil dies ein Sonderbedeutung für die Listensteuerung hat: ''mlmmj'' wird nämlich Befehle der Abonnenten über erweiterte Adressen annehmen, wie z.B. ''discuss+help@example.org''.

Die Domain ''example.org'' muss dazu bei einem beliebigen User im Paket ''xyz00'' [[aufgeschaltet]] sein. ("Aufgeschaltet" bedeutet, daß diese Domain bei Hostsharing gehostet wird und der Domainname als Verzeichnis /home/pacs/xyz00/*User*/doms/example.org/ erscheint.)

== Einrichtung ==

Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.

Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:

<syntaxhighlight lang=shell>
xyz00@h03:~$ hsscript -i
Password: *************
xyz00@hsadmin>
</syntaxhighlight>

In ''hsadmin'' werden ein User und eine spezifische E-Mail-Adresse (siehe localpart) oder eine Catchall Adresse (localpart leer lassen) angelegt.

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})
xyz00@hsadmin> bye
</syntaxhighlight>

Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.

Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:

<syntaxhighlight lang=shell>
mkdir /home/pacs/xyz00/users/list/mlmmj
</syntaxhighlight>

Dann lege ich die Mailingliste mit folgendem Kommando an:

<syntaxhighlight lang=shell>
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj
</syntaxhighlight>

Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:

<syntaxhighlight lang=output line>
The Domain for the List? [] : example.org
The emailaddress of the list owner? [postmaster] : webmaster@example.org
For the list texts you can choose between the following languages or
give an absolute path to a directory containing the texts.
Available languages:
cz da de en es fr it nl ru
The path to texts for the list? [en] : de
</syntaxhighlight>

Das skript ''mlmmj-make-ml'' legt daraufhin unter "/home/pacs/xyz00/users/list/mlmmj" ein Verzeichnis "discuss" an, das die Datenstruktur zur Verwaltung der Mailingliste enthält.

Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/TUNABLES.html Internetseite von mlmmj].

Damit mlmmj die Verteilung der Post übernimmt, muß ich im Heimat-Verzeichnis des users xyz00-list die Datei <tt>.forward</tt> mit folgenden Inhalt (INKLUSIVE der Anführungszeichen!) erstellen:

<syntaxhighlight lang=shell>
"|/usr/bin/mlmmj-receive -L /home/pacs/xyz00/users/list/mlmmj/discuss/"
</syntaxhighlight>

(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)

<syntaxhighlight lang=shell>
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive
</syntaxhighlight>

Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.

Für regelmäßige Aufgaben der Listen-Managers definiere ich den systemd timer wie folgt (immer noch als ''xyz00-list''):

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

[Service]
Type=oneshot
ExecStart=/usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F
</syntaxhighlight>

~/.config/systemd/user/mlmmj.timer
<syntaxhighlight lang=ini>
[Unit]
Description=mlmmj maintenance

[Timer]
OnCalendar=*:28/4
Persistent=True

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

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

Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:

<syntaxhighlight lang=shell>
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c
</syntaxhighlight>

Dabei bewirkt "-c", dass der Abonnent eine Begrüßungs-Nachricht erhält. Alternativ kann man "-C" (großes C) angeben: dann muss der Abonnent das Abo durch Antworten auf die Nachricht bestätigen.

== weitere Optionen ==

Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:

Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".

<syntaxhighlight lang=shell>
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix
</syntaxhighlight>

Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:

<syntaxhighlight lang=shell>
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost
</syntaxhighlight>

Damit der Listen-Owner weitere Abonnements bestätigen muss:

<syntaxhighlight lang=shell>
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod
</syntaxhighlight>

Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:

<syntaxhighlight lang=shell>
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders
</syntaxhighlight>

=== Massenversand über anderen Postausgangsserver ===
Beim Massenversand, z.B. bei Newslettern, nutzen Sie bitte möglichst den dedizierten Postausgangsserver für den Massenversand. Dadurch tragen Sie dazu bei, die Reputation unserer regulären Ausgangsserver aufrechtzuerhalten.

Um dies zu tun, setzen Sie den SMTP-Port entsprechend:

<syntaxhighlight lang=shell>
echo "4025" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/smtpport
</syntaxhighlight>

Weitere Konfigurationsvariante des Ausgangsserver sind unter https://www.hostsharing.net/doc/managed-operations-platform/email/ zu finden.

Weitere Möglichkeiten finden Sie (wie oben bereits angegeben)
auf der [http://mlmmj.org/TUNABLES.html Internetseite von mlmmj].

=== Achtung: DKIM ===

Mlmmj gibt die Möglichkeit, mit '''delheaders''' und '''customheaders''' die Header der durchgeleiteten Mail umfangreich zu ändern. Allerdings tragen Mails heute häufig kryptografische Signaturen der sendenden Mailserver. Eine DKIM-Signatur sichert damit in der Regel die Integrität des Body der Mail sowie der Header ''Subject:'', ''From:'', ''To:'', ''Date:'', ''From'', und oft auch ''Reply-To:''.

Wird zum Beispiel mit einem Prefix das Subject geändert oder ein Footer angehängt, macht dies die DKIM-Signatur ungültig. Das ist für viele Mailprovider ein Grund die Nachricht abzuweisen. (siehe auch Diskussions-Seite zum Artikel)

== Zur Konfiguration im Browser ==

Die Original-Distribution von ''mlmmj'' enthält ein paar einfache PHP- und Perl-Skripte. Das sind Beispiele für Subscribe-/Unsubscribe-Formulare, ein Admin-Formular zum Eintragen und Löschen von Abonnements und eine Seite mit der gesamten Listen-Konfiguration.

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"
</syntaxhighlight>
Und weiter als "xyz00-list".

Download der neuesten Version der Sourcen von mlmmj von https://codeberg.org/mlmmj/mlmmj (noch besser: Download des aktuellen Debian-Pakets von [https://packages.debian.org/bookworm/all/mlmmj-php-web-admin/download debian.org]: da sind einige veraltete PHP-Ausdrücke schon herausgepatcht) und diese in einem temporären Verzeichnis entpacken (mit tar oder dpkg-deb).

Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...

* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;
* die Dateien aus "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs/" nach "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" verschieben;
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;
* in "/home/pacs/xyz00/users/list/mlmmj" und in "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" eine ".htaccess" mit folgendem Inhalt ablegen:
<syntaxhighlight lang=apache line>
Require valid-user
AuthType Basic
AuthName "mlmmj web-interface"
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd
</syntaxhighlight>
* Und schließlich die "htpasswd"-Datei anlegen.

cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/
htpasswd -c htpasswd listadmin

* Ein Passwort angeben.

Nun enthält diese PHP-Anwendung, wenn man sie nicht dem Debian-Paket entnommen hat, leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch

* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:
<syntaxhighlight lang=diff line>
@@ -38,4 +38,5 @@
# use scandir to have alphabetical order
foreach (scandir($topdir) as $file) {
- if (!ereg("^\.",$file))
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))
+ if (!preg_match('/^\./',$file))
{
</syntaxhighlight>
und das Ergebnis auf https://lists.example.org anschauen.

== Mehrere Mailinglisten betreiben ==

Wenn mehrere Mailinglisten in einem Account und mit einer Admin-Oberfläche betrieben werden soll, empfiehlt sich die Nutzung von Procmail für den Aufruf von ''mlmmj'' für die jeweiligen Liste mit ihrem Daten-Verzeichnis.

Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:

<syntaxhighlight lang=shell>
|/usr/bin/procmail
</syntaxhighlight>

Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:

<syntaxhighlight lang=shell>
SHELL=/bin/sh
HOMEDIR=/home/pacs/xyz00/users/list
MAILDIR=/home/pacs/xyz00/users/list/Maildir
PMDIR=/home/pacs/xyz00/users/list
VERBOSE=yes
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log
DEFAULT

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/

:0
{ EXITCODE 67 }
</syntaxhighlight>

Bitte dafür sorgen, dass das Verzeichnis ''/home/pacs/xyz00/users/list/var'' existiert.

Der kryptische reguläre Ausdruck hinter dem Header ''X-Original-To:'' passt auf den Beginn der E-Mail-Adresse bis zum ersten ''@''- oder ''+''-Zeichen. In der Variable ''MATCH'' steht also der Name der Mailingliste, d.h. der Name der Verzeichnisses, in dem die Liste verwaltet wird.

Sehr wichtig ist die Zeile ''DEFAULT'' zu Beginn der ''.procmailrc''. Die Variable ''DEFAULT'' wird von ''procmail'' gesetzt. Wir sorgen mit dieser Zeile dafür, dass sie wieder undefiniert ist. Diese Variable wird intern von ''mlmmj'' benutzt, wenn sie gesetzt ist. Das führt in Kombination mit ''procmail'' zu Fehlfunktionen (vgl. Links).

===Groß- und Kleinschreibung===

Achtung, mit der Groß- und Kleinschreibung von Listennamen gibt es bei dieser Procmail-Lösung eine kleine Tücke. Procmail übernimmt in die Variable $MATCH genau die in der X-Original-To-Headerzeile vorgefundene Schreibweise, und diese kann denkbarerweise "Listen-Name" oder "listen-name" oder "Listen-name" sein. <tt>mlmmj</tt> hingegen wird diesen Wert in Unix-Manier mit dem genauen Verzeichnisnamen <tt>${HOME}/mlmmj/listen-name</tt> vergleichen, und bei unterschiedlicher Schreibweise die Mail nicht verteilen.

====Lösung 1====

Eine teilweise Lösung besteht darin, den Listennamen in dem <tt>mlmmj</tt>-Aufruf in der <tt>.procmailrc</tt> in Kleinbuchstaben umzuschreiben. Dann lautet das Rezept so:

<syntaxhighlight lang=shell>
:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/
</syntaxhighlight>

Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.

In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!

(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:

<syntaxhighlight lang=output>
xyz00-list@h02:~$ ls -lA mlmmj/
total 8
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder
</syntaxhighlight>

====Lösung 2====

Bash kann bei der Auflösung von Variablen die Groß- und Kleinschreibung manipulieren. (Siehe dazu bei der Zeichenfolge <tt>,,</tt> in <tt>man bash</tt>.) Dann ist <tt>$(echo ${MATCH} | tr [:upper:] [:lower:])</tt> gleichbedeutend mit <tt>${MATCH,,}</tt>. Allerdings braucht procmail einige Überredung, um Bash zu verwenden.

<syntaxhighlight lang=shell>
SHELL=/bin/bash
SHELLMETAS=&|<>~;?*[{
HOMEDIR= ...

...

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH,,}/
</syntaxhighlight>

Die Tücke ist, daß procmail den in SHELL angegebenen Shell nur dann verwendet, wenn die Befehlszeile eines der in SHELLMETAS angegebenen Zeichen enthält. Und das '|' am Anfang der Zeile zählt dabei nicht! In diesem Beispiel ist es das Zeichen <tt>{</tt>, das den Einsatz von Bash auslöst.

Beide Lösungen scheinen zu funktionieren; Angabe ohne Gewähr.

== Hilfreiche Befehle ==

Suche, wo eine E-Mail Adresse abonniert ist:

<syntaxhighlight lang=shell>
xyz00@h03:~$ grep -r beispiel.adresse@example.org mlmmj/*/subscribers.d
</syntaxhighlight>

Entferne eine E-Mail Adresse von einer Liste, still und ohne Rückfrage (siehe auch https://mlmmj.org/mlmmj-unsub.html):

<syntaxhighlight lang=shell>
xyz00@h03:~$ /usr/bin/mlmmj-unsub -L $HOME/mlmmj/public-discussion/ -a beispiel.adresse@example.org -q
</syntaxhighlight>

Liste alle Listen mit ihren Abonnenten:

<syntaxhighlight lang=shell line>
xyz00@h03:~$ for d in mlmmj/*; do cat $d/control/listaddress; for f in $d/subscribers.d/*; do cat $f | sed -e 's/^/ /g'; done; done
</syntaxhighlight>

== Links ==

* http://mlmmj.org/ Projektseite
* https://codeberg.org/mlmmj mlmmj auf Codeberg
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS
* [https://web.archive.org/web/20221228110514/https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ (via web.archive.org)] Nutzung von mlmmj in Verbindung mit Procmail
* [https://gist.github.com/kboss/7c9593f0fd9219406226c4f11256b98a Einfaches Python-Script zum Massenimport aus einem Texfile.] Geht bestimmt auch eleganter mit purem Bash
* Ein Self-Service zum Subscriben/Unsubscriben lässt sich in Form von Mail-to-Links in Webseiten einbinden. Beispiele gibt es bei Hostsharing für die öffentlichen "public"-Mailinglisten: https://www.hostsharing.net/lists/public-discussion/ . Alternativ auf https://github.com/hblasum/mlmmj-php-web-simplified ein Webfrontend mit dem sich Benutzerinnen und Benutzer selbst ein-/austragen können (Vereinfachung von mlmmj-php-web von Christoph Thiel).

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Mailinglisten]]
[[Kategorie:E-Mail]]

Mlmmj

2026-05-18T14:00:33Z

Tim00: /* Einrichtung */

[http://www.mlmmj.org/ mlmmj], angeblich eine Abkürzung für "Mailing List Management Made Joyful", ist ein Programm, mit dem in einem Hostsharing Paket E-Mail-Verteiler realisiert werden kann.

Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese vielleicht auch den Wikipedia-Artikel:
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]

Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.

Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.

== Voraussetzungen ==

Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert. (Wer die Software selbst kompilieren möchte kann aktuellen Source-Code bei [https://codeberg.org/mlmmj/mlmmj codeberg.org] finden.)

Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.

In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.

Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein. Den lokalen Teil dieser Adresse, ''discuss'', ist der Listenname. Der Listenname darf auf keinen Fall das Plus-Zeichen (+) enthalten, weil dies ein Sonderbedeutung für die Listensteuerung hat: ''mlmmj'' wird nämlich Befehle der Abonnenten über erweiterte Adressen annehmen, wie z.B. ''discuss+help@example.org''.

Die Domain ''example.org'' muss dazu bei einem beliebigen User im Paket ''xyz00'' [[aufgeschaltet]] sein. ("Aufgeschaltet" bedeutet, daß diese Domain bei Hostsharing gehostet wird und der Domainname als Verzeichnis /home/pacs/xyz00/*User*/doms/example.org/ erscheint.)

== Einrichtung ==

Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.

Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:

<syntaxhighlight lang=shell>
xyz00@h03:~$ hsscript -i
Password: *************
xyz00@hsadmin>
</syntaxhighlight>

In ''hsadmin'' werden ein User und eine Catchall E-Mail-Adresse angelegt.

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})
xyz00@hsadmin> bye
</syntaxhighlight>

Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.

Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:

<syntaxhighlight lang=shell>
mkdir /home/pacs/xyz00/users/list/mlmmj
</syntaxhighlight>

Dann lege ich die Mailingliste mit folgendem Kommando an:

<syntaxhighlight lang=shell>
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj
</syntaxhighlight>

Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:

<syntaxhighlight lang=output line>
The Domain for the List? [] : example.org
The emailaddress of the list owner? [postmaster] : webmaster@example.org
For the list texts you can choose between the following languages or
give an absolute path to a directory containing the texts.
Available languages:
cz da de en es fr it nl ru
The path to texts for the list? [en] : de
</syntaxhighlight>

Das skript ''mlmmj-make-ml'' legt daraufhin unter "/home/pacs/xyz00/users/list/mlmmj" ein Verzeichnis "discuss" an, das die Datenstruktur zur Verwaltung der Mailingliste enthält.

Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/TUNABLES.html Internetseite von mlmmj].

Damit mlmmj die Verteilung der Post übernimmt, muß ich im Heimat-Verzeichnis des users xyz00-list die Datei <tt>.forward</tt> mit folgenden Inhalt (INKLUSIVE der Anführungszeichen!) erstellen:

<syntaxhighlight lang=shell>
"|/usr/bin/mlmmj-receive -L /home/pacs/xyz00/users/list/mlmmj/discuss/"
</syntaxhighlight>

(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)

<syntaxhighlight lang=shell>
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive
</syntaxhighlight>

Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.

Für regelmäßige Aufgaben der Listen-Managers definiere ich den systemd timer wie folgt (immer noch als ''xyz00-list''):

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

[Service]
Type=oneshot
ExecStart=/usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F
</syntaxhighlight>

~/.config/systemd/user/mlmmj.timer
<syntaxhighlight lang=ini>
[Unit]
Description=mlmmj maintenance

[Timer]
OnCalendar=*:28/4
Persistent=True

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

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

Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:

<syntaxhighlight lang=shell>
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c
</syntaxhighlight>

Dabei bewirkt "-c", dass der Abonnent eine Begrüßungs-Nachricht erhält. Alternativ kann man "-C" (großes C) angeben: dann muss der Abonnent das Abo durch Antworten auf die Nachricht bestätigen.

== weitere Optionen ==

Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:

Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".

<syntaxhighlight lang=shell>
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix
</syntaxhighlight>

Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:

<syntaxhighlight lang=shell>
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost
</syntaxhighlight>

Damit der Listen-Owner weitere Abonnements bestätigen muss:

<syntaxhighlight lang=shell>
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod
</syntaxhighlight>

Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:

<syntaxhighlight lang=shell>
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders
</syntaxhighlight>

=== Massenversand über anderen Postausgangsserver ===
Beim Massenversand, z.B. bei Newslettern, nutzen Sie bitte möglichst den dedizierten Postausgangsserver für den Massenversand. Dadurch tragen Sie dazu bei, die Reputation unserer regulären Ausgangsserver aufrechtzuerhalten.

Um dies zu tun, setzen Sie den SMTP-Port entsprechend:

<syntaxhighlight lang=shell>
echo "4025" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/smtpport
</syntaxhighlight>

Weitere Konfigurationsvariante des Ausgangsserver sind unter https://www.hostsharing.net/doc/managed-operations-platform/email/ zu finden.

Weitere Möglichkeiten finden Sie (wie oben bereits angegeben)
auf der [http://mlmmj.org/TUNABLES.html Internetseite von mlmmj].

=== Achtung: DKIM ===

Mlmmj gibt die Möglichkeit, mit '''delheaders''' und '''customheaders''' die Header der durchgeleiteten Mail umfangreich zu ändern. Allerdings tragen Mails heute häufig kryptografische Signaturen der sendenden Mailserver. Eine DKIM-Signatur sichert damit in der Regel die Integrität des Body der Mail sowie der Header ''Subject:'', ''From:'', ''To:'', ''Date:'', ''From'', und oft auch ''Reply-To:''.

Wird zum Beispiel mit einem Prefix das Subject geändert oder ein Footer angehängt, macht dies die DKIM-Signatur ungültig. Das ist für viele Mailprovider ein Grund die Nachricht abzuweisen. (siehe auch Diskussions-Seite zum Artikel)

== Zur Konfiguration im Browser ==

Die Original-Distribution von ''mlmmj'' enthält ein paar einfache PHP- und Perl-Skripte. Das sind Beispiele für Subscribe-/Unsubscribe-Formulare, ein Admin-Formular zum Eintragen und Löschen von Abonnements und eine Seite mit der gesamten Listen-Konfiguration.

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"
</syntaxhighlight>
Und weiter als "xyz00-list".

Download der neuesten Version der Sourcen von mlmmj von https://codeberg.org/mlmmj/mlmmj (noch besser: Download des aktuellen Debian-Pakets von [https://packages.debian.org/bookworm/all/mlmmj-php-web-admin/download debian.org]: da sind einige veraltete PHP-Ausdrücke schon herausgepatcht) und diese in einem temporären Verzeichnis entpacken (mit tar oder dpkg-deb).

Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...

* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;
* die Dateien aus "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs/" nach "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" verschieben;
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;
* in "/home/pacs/xyz00/users/list/mlmmj" und in "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" eine ".htaccess" mit folgendem Inhalt ablegen:
<syntaxhighlight lang=apache line>
Require valid-user
AuthType Basic
AuthName "mlmmj web-interface"
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd
</syntaxhighlight>
* Und schließlich die "htpasswd"-Datei anlegen.

cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/
htpasswd -c htpasswd listadmin

* Ein Passwort angeben.

Nun enthält diese PHP-Anwendung, wenn man sie nicht dem Debian-Paket entnommen hat, leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch

* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:
<syntaxhighlight lang=diff line>
@@ -38,4 +38,5 @@
# use scandir to have alphabetical order
foreach (scandir($topdir) as $file) {
- if (!ereg("^\.",$file))
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))
+ if (!preg_match('/^\./',$file))
{
</syntaxhighlight>
und das Ergebnis auf https://lists.example.org anschauen.

== Mehrere Mailinglisten betreiben ==

Wenn mehrere Mailinglisten in einem Account und mit einer Admin-Oberfläche betrieben werden soll, empfiehlt sich die Nutzung von Procmail für den Aufruf von ''mlmmj'' für die jeweiligen Liste mit ihrem Daten-Verzeichnis.

Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:

<syntaxhighlight lang=shell>
|/usr/bin/procmail
</syntaxhighlight>

Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:

<syntaxhighlight lang=shell>
SHELL=/bin/sh
HOMEDIR=/home/pacs/xyz00/users/list
MAILDIR=/home/pacs/xyz00/users/list/Maildir
PMDIR=/home/pacs/xyz00/users/list
VERBOSE=yes
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log
DEFAULT

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/

:0
{ EXITCODE 67 }
</syntaxhighlight>

Bitte dafür sorgen, dass das Verzeichnis ''/home/pacs/xyz00/users/list/var'' existiert.

Der kryptische reguläre Ausdruck hinter dem Header ''X-Original-To:'' passt auf den Beginn der E-Mail-Adresse bis zum ersten ''@''- oder ''+''-Zeichen. In der Variable ''MATCH'' steht also der Name der Mailingliste, d.h. der Name der Verzeichnisses, in dem die Liste verwaltet wird.

Sehr wichtig ist die Zeile ''DEFAULT'' zu Beginn der ''.procmailrc''. Die Variable ''DEFAULT'' wird von ''procmail'' gesetzt. Wir sorgen mit dieser Zeile dafür, dass sie wieder undefiniert ist. Diese Variable wird intern von ''mlmmj'' benutzt, wenn sie gesetzt ist. Das führt in Kombination mit ''procmail'' zu Fehlfunktionen (vgl. Links).

===Groß- und Kleinschreibung===

Achtung, mit der Groß- und Kleinschreibung von Listennamen gibt es bei dieser Procmail-Lösung eine kleine Tücke. Procmail übernimmt in die Variable $MATCH genau die in der X-Original-To-Headerzeile vorgefundene Schreibweise, und diese kann denkbarerweise "Listen-Name" oder "listen-name" oder "Listen-name" sein. <tt>mlmmj</tt> hingegen wird diesen Wert in Unix-Manier mit dem genauen Verzeichnisnamen <tt>${HOME}/mlmmj/listen-name</tt> vergleichen, und bei unterschiedlicher Schreibweise die Mail nicht verteilen.

====Lösung 1====

Eine teilweise Lösung besteht darin, den Listennamen in dem <tt>mlmmj</tt>-Aufruf in der <tt>.procmailrc</tt> in Kleinbuchstaben umzuschreiben. Dann lautet das Rezept so:

<syntaxhighlight lang=shell>
:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/
</syntaxhighlight>

Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.

In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!

(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:

<syntaxhighlight lang=output>
xyz00-list@h02:~$ ls -lA mlmmj/
total 8
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder
</syntaxhighlight>

====Lösung 2====

Bash kann bei der Auflösung von Variablen die Groß- und Kleinschreibung manipulieren. (Siehe dazu bei der Zeichenfolge <tt>,,</tt> in <tt>man bash</tt>.) Dann ist <tt>$(echo ${MATCH} | tr [:upper:] [:lower:])</tt> gleichbedeutend mit <tt>${MATCH,,}</tt>. Allerdings braucht procmail einige Überredung, um Bash zu verwenden.

<syntaxhighlight lang=shell>
SHELL=/bin/bash
SHELLMETAS=&|<>~;?*[{
HOMEDIR= ...

...

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH,,}/
</syntaxhighlight>

Die Tücke ist, daß procmail den in SHELL angegebenen Shell nur dann verwendet, wenn die Befehlszeile eines der in SHELLMETAS angegebenen Zeichen enthält. Und das '|' am Anfang der Zeile zählt dabei nicht! In diesem Beispiel ist es das Zeichen <tt>{</tt>, das den Einsatz von Bash auslöst.

Beide Lösungen scheinen zu funktionieren; Angabe ohne Gewähr.

== Hilfreiche Befehle ==

Suche, wo eine E-Mail Adresse abonniert ist:

<syntaxhighlight lang=shell>
xyz00@h03:~$ grep -r beispiel.adresse@example.org mlmmj/*/subscribers.d
</syntaxhighlight>

Entferne eine E-Mail Adresse von einer Liste, still und ohne Rückfrage (siehe auch https://mlmmj.org/mlmmj-unsub.html):

<syntaxhighlight lang=shell>
xyz00@h03:~$ /usr/bin/mlmmj-unsub -L $HOME/mlmmj/public-discussion/ -a beispiel.adresse@example.org -q
</syntaxhighlight>

Liste alle Listen mit ihren Abonnenten:

<syntaxhighlight lang=shell line>
xyz00@h03:~$ for d in mlmmj/*; do cat $d/control/listaddress; for f in $d/subscribers.d/*; do cat $f | sed -e 's/^/ /g'; done; done
</syntaxhighlight>

== Links ==

* http://mlmmj.org/ Projektseite
* https://codeberg.org/mlmmj mlmmj auf Codeberg
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS
* [https://web.archive.org/web/20221228110514/https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ (via web.archive.org)] Nutzung von mlmmj in Verbindung mit Procmail
* [https://gist.github.com/kboss/7c9593f0fd9219406226c4f11256b98a Einfaches Python-Script zum Massenimport aus einem Texfile.] Geht bestimmt auch eleganter mit purem Bash
* Ein Self-Service zum Subscriben/Unsubscriben lässt sich in Form von Mail-to-Links in Webseiten einbinden. Beispiele gibt es bei Hostsharing für die öffentlichen "public"-Mailinglisten: https://www.hostsharing.net/lists/public-discussion/ . Alternativ auf https://github.com/hblasum/mlmmj-php-web-simplified ein Webfrontend mit dem sich Benutzerinnen und Benutzer selbst ein-/austragen können (Vereinfachung von mlmmj-php-web von Christoph Thiel).

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Mailinglisten]]
[[Kategorie:E-Mail]]

Login mit SSH

2026-04-30T06:49:22Z

Tim00: /* Login mit SSH Key */

{{Baustelle}}

Um sich einloggen zu können, brauchst Du natürlich die Daten, die Dir von Hostsharing in einer Mail nach der Anmeldung zugeschickt wurden:

Hostname: '''xyz00.hostsharing.net''' (wenn eine eigene Domain konnektiert ist auch <eigene-domain>.<tld>)

Username: '''xyz00'''

Passwort: '''(wie in der automatischen Mail mitgeteilt)'''

Bei xyz00 handelt es sich um den Account des Paket-Admins. Initial ist für jedes neue Paket nur ein Admin-Account eingerichtet, dessen Benutzername die Form '''xyz00''' besitzt.

Da dieser Account sehr viel Macht über das Paket hat, darf er nur über sichere Protokolle wie SSH benutzt werden. Unsichere Protokolle wie direktes FTP dürfen nicht verwendet werden, da diese die Passwörter im Klartext übertragen. Jeder Administrator auf der Übertragungsstrecke könnte mitlesen.

Gleich vorab: Seine Website kann man später freilich über einen separaten Account per ftps, sftp, scp (und zur Not auch ftp) hochladen, doch dazu später mehr.

Linux Systeme haben meist ssh, scp und sftp Clients vorinstalliert. Eine Freie Software zum sicheren Dateitransfer für Windows ist z.B. [http://winscp.net WinSCP] und ein Shell Zugang mit [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY].

Nach der ggf. nötigen Installation eines ssh Clients, die hier nicht beschrieben werden, da sie nicht Hostsharing-spezifisch ist, kann der erste Login erfolgen.

== Login ==

Mit OpenSSH ist der Aufruf auf der Kommandozeile z.B. folgender:

ssh xyz00@xyz00.hostsharing.net

Nach Aufbau der Verbindung wird dann das [[Passwort]] erfragt.
Danach erscheint in etwa folgende Bildschirmausgabe:

<syntaxhighlight lang="bash">
Last login: Fri Apr 19 06:43:45 2002 from p5081f0c7.dip.t-dialin.net on pts/7

Linux hopi 2.4.17 #2 SMP Thu Jan 17 14:35:38 CET 2002 i686 unknown

+----------------------------------------------------------------+
| hopi.hostsharing.net |
| Bei Fragen oder Problemen bitte E-Mail an: |
| support@hostsharing.net (öffentliche Mailingliste) |
+----------------------------------------------------------------+

Last login: Fri Apr 19 09:36:34 2002 from 62.156.160.59

xyz0@hopi:~$ █
</syntaxhighlight>

Es macht durchaus Sinn, die ganz oben genannte "Last Login" Zeile zu prüfen, ob man dies auch selbst war (Uhrzeit und Provider), unten die "Last Login" Zeile gibt genau genommen das aktuelle Login aus, weil der Programmteil nach dem eigentlichen Login ausgeführt wird.

Als nächstes ändern wir gleich unser [[Passwort]], da dieses schließlich unverschlüsselt per E-Mail versendet wurde. Dies geschieht unter UNIX mit dem Kommando passwd

== Passwort ändern ==

Eine Änderung des Passwortes geht dem Befehl passwd:

<syntaxhighlight lang="bash">
xyz00@hopi:~$ passwd

Changing password for xyz00

(current) UNIX password: ALTESPASSWORT

Enter new UNIX password: NEUESPASSWORT

Retype new UNIX password: NEUESPASSWORT

passwd: password updated successfully

xyz00@hopi:~$ █

</syntaxhighlight>

Die Platzhalter '''NEUESPASSWORT''' und '''ALTESPASSWORT''' müssen dabei selbstverständlich gegen die entsprechenden [[Passworte]] ausgetauscht werden. Dabei sollte jedes Passwort mindestens 6 Zeichen lang sein, besser 8 Zeichen, und aus Buchstaben, Ziffern und ggf. Sonderzeichen bestehen. Allerdings sollte auf Umlaute verzichtet werden, da diese je nach verwendetem Zugangsweg nicht verwendet werden könnten.

Ggf. kommt es zu Fehlermeldungen, z.B. wenn das neue [[Passwort]] zu simpel ist, oder bei der Wiederholung nicht identisch mit dem ersten Passwort ist. In dem Fall, den Vorgang einfach wiederholen. Solange das neue Passwort nicht erfolgreich übernommen wurde, bleibt das alte gültig.

Es gibt User, denen der Paket-Admin nur das Recht eingeräumt hat, das eigene Passwort zu ändern, indem er ihnen die "Shell" /usr/bin/passwd zugewiesen hat. Diese User können durch einen Shell-Login nur ihr Passwort ändern, da das Programm passwd an Stelle einer Shell gestartet wird. Sie werden nach dem Einloggen automatisch auf diesen Dialog geführt.Mehr dazu unter [[User#Rechte]].

==Sitzung beenden==

Um die Sitzung zu beenden, sich also auszuloggen, gibt man exit ein. Das sieht dann so aus:

<syntaxhighlight lang="bash">
xyz00@hopi:~$ exit
logout
Connection to xyz00.hostsharing.net closed.
</syntaxhighlight>
== Login ohne Passwort ==
Um logins durch automatisierte Versuche zu erschweren sind auf den shared hosts Mechanismen in Betrieb, die ein Login mit Passwort erschweren, zum Beispiel durch ein Timeout, dass die Eingabe eines Passworts, wenn sie zu lange dauert, nicht funktioniert.
<syntaxhighlight lang="bash">
(xyz00@xyz00.hostsharing.net) Password:
Connection closed by 2a01:37:1000::53df:4f85:0 port 22
</syntaxhighlight>
Man muss also das Passwort in der Zwischenablage haben, dann den Loginbefehl geben und dann sofort das Passwort eingeben. Das ist in vielerlei hinsicht unsicher, da die Zwischenablage evtl gespeichert wird. (ein passwort Manager wie keepassXC löscht die eigenen Abgelegten Werte per Default nach einigen Sekunden), diese Methode, weil es wirklich schnell gehen muss (wenige Sekunden zur Passworteingabe) kann auch zu anderen Fehler führen die dass Passwort offenlegen, z.B. weil es versehentlich in der Hektik in ein falsches Fenster gepostet wird.
Auch aus anderen Gründen sollte daher der Zugang über SSH mit einem Schlüsselpaar erfolgen.

== Login mit SSH Key ==

Es besteht die Möglichkeit, einen public SSH Key in den Benutzer hochzuladen. Dann kann die Anmeldung über den privaten Key erfolgen. Siehe auch zur Erstellung des Key Paares: [https://www.heise.de/tipps-tricks/SSH-Key-erstellen-so-geht-s-4400280.html]

Der public SSH Key muss dann hier gespeichert werden:

<syntaxhighlight lang="bash">
mkdir -p ~/.ssh
nano .ssh/authorized_keys
# hier den public Key einfügen, und speichern
chmod 600 .ssh/authorized_keys
</syntaxhighlight>

Manchmal schlägt bei Power-Usern die Anmeldung fehl, wenn zu viele SSH Keys zur Verfügung stehen, und die alle durchprobiert werden. Dann kommt nach einer gewissen Anzahl die Fehlermeldung: zu viele Anmeldungsversuche.

Die Lösung: beim SSH Aufruf muss der richtige private Key referenziert werden, und die anderen Keys ignoriert werden:

<syntaxhighlight lang="bash">
ssh -p 22 -i /root/.ssh/id_ed25519 -o IdentitiesOnly=yes xyz00@xyz00.hostsharing.net
</syntaxhighlight>

== Zusätzliche Möglichkeiten ==

== Bestimmte Shell Kommandos automatisch ausführen ==

Lege in dem Verzeichnis, in dem Du direkt nach dem Login landest, mit dem Editor Deiner Wahl die Datei .bash_profile mit folgendem Inhalt an:
<syntaxhighlight lang="bash" line>
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
BASH_ENV=$HOME/.bashrc
</syntaxhighlight>

Und nun kannst du in der Datei .bashrc shell Kommandos eingeben. z.B.: quota -g

== welcher Editor in der shell ==

1. manuell Einloggen und:
<syntaxhighlight lang="ini">
VISUAL=nano
export VISUAL
EDITOR=nano
export EDITOR
</syntaxhighlight>

2. in der bash geht es auch kürzer:
<syntaxhighlight lang="bash">
export EDITOR=nano
export VISUAL=nano
</syntaxhighlight>

3. automatisch bei jedem Login
Mit obigen Kommandos in der ~/.bash_profile-Datei.

==Weiterführende Links==

[[HS-Server:SSH-Hostkeys]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Einstieg bei Hostsharing]]
[[Kategorie:Glossar]]

Login mit SSH

2026-04-30T06:46:22Z

Tim00: /* Login ohne Passwort */

{{Baustelle}}

Um sich einloggen zu können, brauchst Du natürlich die Daten, die Dir von Hostsharing in einer Mail nach der Anmeldung zugeschickt wurden:

Hostname: '''xyz00.hostsharing.net''' (wenn eine eigene Domain konnektiert ist auch <eigene-domain>.<tld>)

Username: '''xyz00'''

Passwort: '''(wie in der automatischen Mail mitgeteilt)'''

Bei xyz00 handelt es sich um den Account des Paket-Admins. Initial ist für jedes neue Paket nur ein Admin-Account eingerichtet, dessen Benutzername die Form '''xyz00''' besitzt.

Da dieser Account sehr viel Macht über das Paket hat, darf er nur über sichere Protokolle wie SSH benutzt werden. Unsichere Protokolle wie direktes FTP dürfen nicht verwendet werden, da diese die Passwörter im Klartext übertragen. Jeder Administrator auf der Übertragungsstrecke könnte mitlesen.

Gleich vorab: Seine Website kann man später freilich über einen separaten Account per ftps, sftp, scp (und zur Not auch ftp) hochladen, doch dazu später mehr.

Linux Systeme haben meist ssh, scp und sftp Clients vorinstalliert. Eine Freie Software zum sicheren Dateitransfer für Windows ist z.B. [http://winscp.net WinSCP] und ein Shell Zugang mit [http://www.chiark.greenend.org.uk/~sgtatham/putty/ PuTTY].

Nach der ggf. nötigen Installation eines ssh Clients, die hier nicht beschrieben werden, da sie nicht Hostsharing-spezifisch ist, kann der erste Login erfolgen.

== Login ==

Mit OpenSSH ist der Aufruf auf der Kommandozeile z.B. folgender:

ssh xyz00@xyz00.hostsharing.net

Nach Aufbau der Verbindung wird dann das [[Passwort]] erfragt.
Danach erscheint in etwa folgende Bildschirmausgabe:

<syntaxhighlight lang="bash">
Last login: Fri Apr 19 06:43:45 2002 from p5081f0c7.dip.t-dialin.net on pts/7

Linux hopi 2.4.17 #2 SMP Thu Jan 17 14:35:38 CET 2002 i686 unknown

+----------------------------------------------------------------+
| hopi.hostsharing.net |
| Bei Fragen oder Problemen bitte E-Mail an: |
| support@hostsharing.net (öffentliche Mailingliste) |
+----------------------------------------------------------------+

Last login: Fri Apr 19 09:36:34 2002 from 62.156.160.59

xyz0@hopi:~$ █
</syntaxhighlight>

Es macht durchaus Sinn, die ganz oben genannte "Last Login" Zeile zu prüfen, ob man dies auch selbst war (Uhrzeit und Provider), unten die "Last Login" Zeile gibt genau genommen das aktuelle Login aus, weil der Programmteil nach dem eigentlichen Login ausgeführt wird.

Als nächstes ändern wir gleich unser [[Passwort]], da dieses schließlich unverschlüsselt per E-Mail versendet wurde. Dies geschieht unter UNIX mit dem Kommando passwd

== Passwort ändern ==

Eine Änderung des Passwortes geht dem Befehl passwd:

<syntaxhighlight lang="bash">
xyz00@hopi:~$ passwd

Changing password for xyz00

(current) UNIX password: ALTESPASSWORT

Enter new UNIX password: NEUESPASSWORT

Retype new UNIX password: NEUESPASSWORT

passwd: password updated successfully

xyz00@hopi:~$ █

</syntaxhighlight>

Die Platzhalter '''NEUESPASSWORT''' und '''ALTESPASSWORT''' müssen dabei selbstverständlich gegen die entsprechenden [[Passworte]] ausgetauscht werden. Dabei sollte jedes Passwort mindestens 6 Zeichen lang sein, besser 8 Zeichen, und aus Buchstaben, Ziffern und ggf. Sonderzeichen bestehen. Allerdings sollte auf Umlaute verzichtet werden, da diese je nach verwendetem Zugangsweg nicht verwendet werden könnten.

Ggf. kommt es zu Fehlermeldungen, z.B. wenn das neue [[Passwort]] zu simpel ist, oder bei der Wiederholung nicht identisch mit dem ersten Passwort ist. In dem Fall, den Vorgang einfach wiederholen. Solange das neue Passwort nicht erfolgreich übernommen wurde, bleibt das alte gültig.

Es gibt User, denen der Paket-Admin nur das Recht eingeräumt hat, das eigene Passwort zu ändern, indem er ihnen die "Shell" /usr/bin/passwd zugewiesen hat. Diese User können durch einen Shell-Login nur ihr Passwort ändern, da das Programm passwd an Stelle einer Shell gestartet wird. Sie werden nach dem Einloggen automatisch auf diesen Dialog geführt.Mehr dazu unter [[User#Rechte]].

==Sitzung beenden==

Um die Sitzung zu beenden, sich also auszuloggen, gibt man exit ein. Das sieht dann so aus:

<syntaxhighlight lang="bash">
xyz00@hopi:~$ exit
logout
Connection to xyz00.hostsharing.net closed.
</syntaxhighlight>
== Login ohne Passwort ==
Um logins durch automatisierte Versuche zu erschweren sind auf den shared hosts Mechanismen in Betrieb, die ein Login mit Passwort erschweren, zum Beispiel durch ein Timeout, dass die Eingabe eines Passworts, wenn sie zu lange dauert, nicht funktioniert.
<syntaxhighlight lang="bash">
(xyz00@xyz00.hostsharing.net) Password:
Connection closed by 2a01:37:1000::53df:4f85:0 port 22
</syntaxhighlight>
Man muss also das Passwort in der Zwischenablage haben, dann den Loginbefehl geben und dann sofort das Passwort eingeben. Das ist in vielerlei hinsicht unsicher, da die Zwischenablage evtl gespeichert wird. (ein passwort Manager wie keepassXC löscht die eigenen Abgelegten Werte per Default nach einigen Sekunden), diese Methode, weil es wirklich schnell gehen muss (wenige Sekunden zur Passworteingabe) kann auch zu anderen Fehler führen die dass Passwort offenlegen, z.B. weil es versehentlich in der Hektik in ein falsches Fenster gepostet wird.
Auch aus anderen Gründen sollte daher der Zugang über SSH mit einem Schlüsselpaar erfolgen.

== Login mit SSH Key ==

* TODO: Wie lege ich einen private und einen public SSH Key an?
* TODO: wie lade ich den public SSH Key hoch nach .ssh/authorized_keys; chmod 600 .ssh/authorized_keys

Manchmal schlägt bei Power-Usern die Anmeldung fehl, wenn zu viele SSH Keys zur Verfügung stehen, und die alle durchprobiert werden. Dann kommt nach einer gewissen Anzahl die Fehlermeldung: zu viele Anmeldungsversuche.

Die Lösung: beim SSH Aufruf muss der richtige private Key referenziert werden, und die anderen Keys ignoriert werden:

<syntaxhighlight lang="bash">
ssh -p 22 -i /root/.ssh/id_ed25519 -o IdentitiesOnly=yes xyz00@xyz00.hostsharing.net
</syntaxhighlight>

== Zusätzliche Möglichkeiten ==

== Bestimmte Shell Kommandos automatisch ausführen ==

Lege in dem Verzeichnis, in dem Du direkt nach dem Login landest, mit dem Editor Deiner Wahl die Datei .bash_profile mit folgendem Inhalt an:
<syntaxhighlight lang="bash" line>
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
BASH_ENV=$HOME/.bashrc
</syntaxhighlight>

Und nun kannst du in der Datei .bashrc shell Kommandos eingeben. z.B.: quota -g

== welcher Editor in der shell ==

1. manuell Einloggen und:
<syntaxhighlight lang="ini">
VISUAL=nano
export VISUAL
EDITOR=nano
export EDITOR
</syntaxhighlight>

2. in der bash geht es auch kürzer:
<syntaxhighlight lang="bash">
export EDITOR=nano
export VISUAL=nano
</syntaxhighlight>

3. automatisch bei jedem Login
Mit obigen Kommandos in der ~/.bash_profile-Datei.

==Weiterführende Links==

[[HS-Server:SSH-Hostkeys]]

----
[[Kategorie:HSDoku]]
[[Kategorie:Einstieg bei Hostsharing]]
[[Kategorie:Glossar]]

Prozessmanagement mit systemd im Userspace

2026-04-28T12:27:36Z

Tim00: /* systemd Unit begrenzen */

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

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

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

== Eigene Serverdienste mit systemd ==

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

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

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

Die Ausgabe sollte sein:

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

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

=== systemd Units ===

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

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

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

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

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

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

Folgende Eigenschaften sind einstellbar:

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

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

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

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

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

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

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

=== systemd Unit starten und stoppen ===

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

==== Reload ====

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

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

==== Start und Stopp ====

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

bzw.

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

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

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

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

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

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

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

==== Status ====

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

oder

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

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

=== Ressourcen einer systemd Unit beschränken ===

Mit den folgenden Befehlen können die zur Verfügung stehenden Ressourcen einer systemd Unit beschränkt werden:

<syntaxhighlight lang="bash">
systemctl --user set-property gitea.service MemoryMax=500M
systemctl --user set-property gitea.service CPUQuota=25%
systemctl --user set-property gitea.service TasksMax=100
systemctl --user daemon-reload
</syntaxhighlight>

== Zeitgesteuerte Ausführung mit systemd ==

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

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

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

[Unit]
Description=My Cleanup Service

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

ExecStopPost=/usr/local/bin/hs-notify-unit-failure %N %H %u $EXIT_CODE $SERVICE_RESULT %u
</syntaxhighlight>

Bemerkung: das Skript hs-notify-unit-failure schickt bei einem Fehler des Hauptskripts eine E-Mail an den aktuellen Benutzer, die über .forward oder über .procmailrc auch an eine andere E-Mail Adresse weitergeleitet werden kann.

=== Testen ===

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

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

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

[Unit]
Description=Daily My Cleanup Timer

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

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

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

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

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

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

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

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

Eine ausführliche Dokumentation der Direktiven findet sich hier:

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

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

Der Timer muss noch aktiviert und gestartet werden:

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

=== Übersicht über die Timer im aktuellen User ===

<syntaxhighlight lang=bash>
$ systemctl --user list-timers --all
</syntaxhighlight>

== RAM Kontingent eines Webspace ==

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

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

ansehen.

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

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

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

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

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

Wenn ich einen systemctl Befehl ausführe, kommt:

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

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

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

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

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

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

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

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

= weiterführende Links =

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

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

Speicherbelegung

2026-04-28T06:47:32Z

Tim00: /* Speicherbelegung von einzelnen Benutzern prüfen */

== Paketspeicher ==

Der im gesamten Paket zur Verfügung stehende bzw genutzte Speicher kann wie folgt abgefragt werden:

Einloggen als Paketadmin

{{Textkasten|gruen||xyz00@h01:~$ pac-du-quota}}
Es wird der Speicherplatz (NVMe SSD) und der Zusatz-Speicherplatz (HDD) angezeigt.

oder

{{Textkasten|gruen||xyz00@h01:~$ quota -gs}}
(g > wir nutzen Gruppenquota, s > für Ausgabe in MB). Die Felder bedeuten:

{| class="wikitable" style="margin: 0em 0em 0em 2em; font-size:1em;"
|- style="background-color:orange;"
!Feld !! Bedeutung
|- style="background-color:#CAE1FF;"
|blocks || KB belegt
|- style="background-color:#B9D3EE;"
|quota || normales (gebuchtes) Limit in KB; "soft quota"
|- style="background-color:#CAE1FF;"
|limit || maximales (temporär toleriertes) Limit in KB; "hard quota"
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "quota" bleiben darf (ist nur gesetzt, wenn blocks>quota)
|- style="background-color:#CAE1FF;"
|files ||Anzahl der INodes (entspricht nicht immer, aber fast einem File. Lediglich Hardlinks verbrauchen nur einen INode pro "realer" Datei)
|- style="background-color:#B9D3EE;"
|quota ||normales Limit der INode-Anzahl
|- style="background-color:#CAE1FF;"
|limit ||maximales Limit der INode-Anzahl
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "INode-quota" bleiben darf (ist nur gesetzt, wenn quota überschritten ist)
|-
|}

Um zu prüfen, ob ein Paket die Quota bald erreicht oder schon überschritten hat, muss man '''blocks''' mit '''quota''' in Verhältnis setzen. Wenn '''blocks > quota''', beginnt die ''grace period'', während der ein weiterer Anstieg des Speicherverbrauchs noch toleriert wird. In jedem Fall gilt '''blocks < limit''': die "hard quota" kann nicht überschritten werden und liegt z.B. bei 150% der "soft quota".

Der genutzte Speicher nur für den Paketadmin selbst kann mit '''du''' abgefragt werden: Einloggen als Paket-Admin und '''du -h''' eingeben. Der Befehl listet die aktuellen Größen der einzelnen Verzeichnisse auf und am Ende den gesamt belegten Plattenplatz in MB.

{{Textkasten|gruen||'''Achtung:''' Die Auflistung (mit '''du''') erfolgt ohne den Speicherplatz der User, für deren Verzeichnisse der Paketadmin kein Zugriffsrecht hat, ohne Dateien in /tmp/ und ohne Datenbanken!}}

An dieser Stelle unser Danke an die Mitglieder Andreas Loesch und Timotheus Pokorra die das hervorragende Skript 'pac-du-quota' bereit gestellt haben.

== Unvermutete Speicherbelegung ==

Manchmal wunderst du dich, welche Dateien deinen Speicherplatz belegen?

du und pac-du-quota zeigen nur die Dateien im Home Verzeichnis.

Manche Anwendungen legen im /tmp Verzeichnis für deinen Benutzer Dateien an.

Diese Dateien findest du mit diesem Befehl, für deinen aktuellen Benutzer:

<syntaxhighlight lang=shell>
xyz00-meinbenutzer@hxy:~$ find /tmp/user/$UID
xyz00-meinbenutzer@hxy:~$ ls -la /tmp
</syntaxhighlight>

== Warnung bei Erreichen des Quotas ==

=== Warnungen beim Paketspeicher ===

Wenn die Speicherbelegung (Soft- oder Hard-Quota) beim Paketspeicher überschritten wird, bekommen die dafür eingetragenen E-Mail-Adressen (siehe Ansprechpartner, OPERATIONS_ALERT) jeden Morgen eine E-Mail mit einem Warn-Hinweis.

=== Speicherbelegung von einzelnen Benutzern prüfen ===

Diese automatische E-Mail berücksichtigt nicht die Quotas der einzelnen Benutzer/Postfächer.

Dafür kann das folgende Python-Skript genutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/check-userquota.py

Es sollte im bin Verzeichnis des Paketnutzers (/home/pacs/xyz00/bin) gespeichert werden.

Es muss mit einem Timer eingerichtet werden:

<syntaxhighlight lang=shell>
xyz00@h00:~$ cat .config/systemd/user/check-userquota.timer
[Unit]
Description=check user quota

[Timer]
OnCalendar=00:55:00
RandomizedDelaySec=3 minutes
Persistent=true

[Install]
WantedBy=timers.target

xyz00@h00:~$ cat .config/systemd/user/check-userquota.service
[Unit]
Description=check user quotas

[Service]
Environment="MAILTO=monitoring@meinedomain.de"
ExecStart=%h/bin/check-userquota.py
</syntaxhighlight>

Aktivieren des Timers mit:

<syntaxhighlight lang=shell>
systemctl --user enable check-userquota.timer --now
</syntaxhighlight>

----
[[Kategorie:Pakete bei HS]]
[[Kategorie:HSDoku]]

Speicherbelegung

2026-04-28T06:37:23Z

Tim00: Warn-Emails bei Speicherüberschreitung

== Paketspeicher ==

Der im gesamten Paket zur Verfügung stehende bzw genutzte Speicher kann wie folgt abgefragt werden:

Einloggen als Paketadmin

{{Textkasten|gruen||xyz00@h01:~$ pac-du-quota}}
Es wird der Speicherplatz (NVMe SSD) und der Zusatz-Speicherplatz (HDD) angezeigt.

oder

{{Textkasten|gruen||xyz00@h01:~$ quota -gs}}
(g > wir nutzen Gruppenquota, s > für Ausgabe in MB). Die Felder bedeuten:

{| class="wikitable" style="margin: 0em 0em 0em 2em; font-size:1em;"
|- style="background-color:orange;"
!Feld !! Bedeutung
|- style="background-color:#CAE1FF;"
|blocks || KB belegt
|- style="background-color:#B9D3EE;"
|quota || normales (gebuchtes) Limit in KB; "soft quota"
|- style="background-color:#CAE1FF;"
|limit || maximales (temporär toleriertes) Limit in KB; "hard quota"
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "quota" bleiben darf (ist nur gesetzt, wenn blocks>quota)
|- style="background-color:#CAE1FF;"
|files ||Anzahl der INodes (entspricht nicht immer, aber fast einem File. Lediglich Hardlinks verbrauchen nur einen INode pro "realer" Datei)
|- style="background-color:#B9D3EE;"
|quota ||normales Limit der INode-Anzahl
|- style="background-color:#CAE1FF;"
|limit ||maximales Limit der INode-Anzahl
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "INode-quota" bleiben darf (ist nur gesetzt, wenn quota überschritten ist)
|-
|}

Um zu prüfen, ob ein Paket die Quota bald erreicht oder schon überschritten hat, muss man '''blocks''' mit '''quota''' in Verhältnis setzen. Wenn '''blocks > quota''', beginnt die ''grace period'', während der ein weiterer Anstieg des Speicherverbrauchs noch toleriert wird. In jedem Fall gilt '''blocks < limit''': die "hard quota" kann nicht überschritten werden und liegt z.B. bei 150% der "soft quota".

Der genutzte Speicher nur für den Paketadmin selbst kann mit '''du''' abgefragt werden: Einloggen als Paket-Admin und '''du -h''' eingeben. Der Befehl listet die aktuellen Größen der einzelnen Verzeichnisse auf und am Ende den gesamt belegten Plattenplatz in MB.

{{Textkasten|gruen||'''Achtung:''' Die Auflistung (mit '''du''') erfolgt ohne den Speicherplatz der User, für deren Verzeichnisse der Paketadmin kein Zugriffsrecht hat, ohne Dateien in /tmp/ und ohne Datenbanken!}}

An dieser Stelle unser Danke an die Mitglieder Andreas Loesch und Timotheus Pokorra die das hervorragende Skript 'pac-du-quota' bereit gestellt haben.

== Unvermutete Speicherbelegung ==

Manchmal wunderst du dich, welche Dateien deinen Speicherplatz belegen?

du und pac-du-quota zeigen nur die Dateien im Home Verzeichnis.

Manche Anwendungen legen im /tmp Verzeichnis für deinen Benutzer Dateien an.

Diese Dateien findest du mit diesem Befehl, für deinen aktuellen Benutzer:

<syntaxhighlight lang=shell>
xyz00-meinbenutzer@hxy:~$ find /tmp/user/$UID
xyz00-meinbenutzer@hxy:~$ ls -la /tmp
</syntaxhighlight>

== Warnung bei Erreichen des Quotas ==

=== Warnungen beim Paketspeicher ===

Wenn die Speicherbelegung (Soft- oder Hard-Quota) beim Paketspeicher überschritten wird, bekommen die dafür eingetragenen E-Mail-Adressen (siehe Ansprechpartner, OPERATIONS_ALERT) jeden Morgen eine E-Mail mit einem Warn-Hinweis.

=== Speicherbelegung von einzelnen Benutzern prüfen ===

Diese automatische E-Mail berücksichtigt nicht die Quotas der einzelnen Benutzer/Postfächer.

Dafür kann das folgende Python-Skript genutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/check-userquota.py

Es sollte im bin Verzeichnis des Paketnutzers (/home/pacs/xyz00/bin) gespeichert werden.

Es muss mit einem Timer eingerichtet werden:

<syntaxhighlight lang=shell>
xyz00@h00:~$ cat .config/systemd/user/check-userquota.timer
[Unit]
Description=check user quota

[Timer]
OnCalendar=00:55:00
RandomizedDelaySec=3 minutes
Persistent=true

[Install]
WantedBy=timers.target

xyz00@h00:~$ cat .config/systemd/user/check-userquota.service
[Unit]
Description=check user quotas

[Service]
Environment="MAILTO=monitoring@meinedomain.de"
ExecStart=%h/bin/check-userquota.py
</syntaxhighlight>

Aktivieren des Timers mit:

<syntaxhighlight lang=shell>
systemctl --user enable check-userquota --now
</syntaxhighlight>

----
[[Kategorie:Pakete bei HS]]
[[Kategorie:HSDoku]]

Speicherbelegung

2026-04-28T06:31:49Z

Tim00: Warn-Emails bei Speicherüberschreitung

== Paketspeicher ==

Der im gesamten Paket zur Verfügung stehende bzw genutzte Speicher kann wie folgt abgefragt werden:

Einloggen als Paketadmin

{{Textkasten|gruen||xyz00@h01:~$ pac-du-quota}}
Es wird der Speicherplatz (NVMe SSD) und der Zusatz-Speicherplatz (HDD) angezeigt.

oder

{{Textkasten|gruen||xyz00@h01:~$ quota -gs}}
(g > wir nutzen Gruppenquota, s > für Ausgabe in MB). Die Felder bedeuten:

{| class="wikitable" style="margin: 0em 0em 0em 2em; font-size:1em;"
|- style="background-color:orange;"
!Feld !! Bedeutung
|- style="background-color:#CAE1FF;"
|blocks || KB belegt
|- style="background-color:#B9D3EE;"
|quota || normales (gebuchtes) Limit in KB; "soft quota"
|- style="background-color:#CAE1FF;"
|limit || maximales (temporär toleriertes) Limit in KB; "hard quota"
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "quota" bleiben darf (ist nur gesetzt, wenn blocks>quota)
|- style="background-color:#CAE1FF;"
|files ||Anzahl der INodes (entspricht nicht immer, aber fast einem File. Lediglich Hardlinks verbrauchen nur einen INode pro "realer" Datei)
|- style="background-color:#B9D3EE;"
|quota ||normales Limit der INode-Anzahl
|- style="background-color:#CAE1FF;"
|limit ||maximales Limit der INode-Anzahl
|- style="background-color:#B9D3EE;"
|grace || Anzahl der Tage, die man noch über "INode-quota" bleiben darf (ist nur gesetzt, wenn quota überschritten ist)
|-
|}

Um zu prüfen, ob ein Paket die Quota bald erreicht oder schon überschritten hat, muss man '''blocks''' mit '''quota''' in Verhältnis setzen. Wenn '''blocks > quota''', beginnt die ''grace period'', während der ein weiterer Anstieg des Speicherverbrauchs noch toleriert wird. In jedem Fall gilt '''blocks < limit''': die "hard quota" kann nicht überschritten werden und liegt z.B. bei 150% der "soft quota".

Der genutzte Speicher nur für den Paketadmin selbst kann mit '''du''' abgefragt werden: Einloggen als Paket-Admin und '''du -h''' eingeben. Der Befehl listet die aktuellen Größen der einzelnen Verzeichnisse auf und am Ende den gesamt belegten Plattenplatz in MB.

{{Textkasten|gruen||'''Achtung:''' Die Auflistung (mit '''du''') erfolgt ohne den Speicherplatz der User, für deren Verzeichnisse der Paketadmin kein Zugriffsrecht hat, ohne Dateien in /tmp/ und ohne Datenbanken!}}

An dieser Stelle unser Danke an die Mitglieder Andreas Loesch und Timotheus Pokorra die das hervorragende Skript 'pac-du-quota' bereit gestellt haben.

== Unvermutete Speicherbelegung ==

Manchmal wunderst du dich, welche Dateien deinen Speicherplatz belegen?

du und pac-du-quota zeigen nur die Dateien im Home Verzeichnis.

Manche Anwendungen legen im /tmp Verzeichnis für deinen Benutzer Dateien an.

Diese Dateien findest du mit diesem Befehl, für deinen aktuellen Benutzer:

<syntaxhighlight lang=shell>
xyz00-meinbenutzer@hxy:~$ find /tmp/user/$UID
xyz00-meinbenutzer@hxy:~$ ls -la /tmp
</syntaxhighlight>

== Warnung bei Erreichen des Quotas ==

== Warnungen beim Paketspeicher ==

Wenn die Speicherbelegung (Soft- oder Hard-Quota) beim Paketspeicher überschritten wird, bekommen die dafür eingetragenen E-Mail-Adressen jeden Morgen eine E-Mail mit einem Warn-Hinweis.

== Speicherbelegung von einzelnen Benutzern prüfen ==

Diese automatische E-Mail berücksichtigt nicht die Quotas der einzelnen Benutzer/Postfächer.

Dafür kann das folgende Python-Skript genutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/check-userquota.py

Es sollte im bin Verzeichnis des Paketnutzers (/home/pacs/xyz00/bin) gespeichert werden.

Es muss mit einem Timer eingerichtet werden:

<syntaxhighlight lang=shell>
xyz00@h00:~$ cat .config/systemd/user/check-userquota.timer
[Unit]
Description=check user quota

[Timer]
OnCalendar=00:55:00
RandomizedDelaySec=3 minutes
Persistent=true

[Install]
WantedBy=timers.target

xyz00@h00:~$ cat .config/systemd/user/check-userquota.service
[Unit]
Description=check user quotas

[Service]
Environment="MAILTO=monitoring@meinedomain.de"
ExecStart=%h/bin/check-userquota.py
</syntaxhighlight>

Aktivieren des Timers mit:

<syntaxhighlight lang=shell>
systemctl --user enable check-userquota --now
</syntaxhighlight>

----
[[Kategorie:Pakete bei HS]]
[[Kategorie:HSDoku]]

Nextcloud

2026-04-27T08:18:03Z

Tim00: /* weiterführende Links */ kaputten Link ersetzt

= Nextcloud =

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

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

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

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

= Nextcloud installieren =

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:

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

Dann nacheinander anlegen:

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

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

== Nextcloud installieren ==

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

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

''htdocs'' Verzeichnis vorbereiten

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

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

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

Nextcloud herunterladen und entpacken.

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

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

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

== Nextcloud konfigurieren ==

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

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

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

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

Auf der ersten Seite sind anzugeben:

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

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

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

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

== Nextcloud beschleunigen ==

Dieser Teil ist optional.

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

=== Redis Cache ===

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

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

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

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

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

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

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

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

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

[Timer]
OnCalendar=1:1
Persistent=True

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

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

=== Nextcloud Cronjob ===

Für die regelmäßigen Hintergrundaufgaben innerhalb der Nextcloud sollte ein Cronjob eingerichtet werden. Wir lösen dies hier mit einem weiteren Systemd-Timer:

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

[Service]
Type=oneshot
ExecStart=/usr/bin/php %h/nextcloud/cron.php
</syntaxhighlight>

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

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

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

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

=== Nextcloud Push ===

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

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

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

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

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

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

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

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

== Nextcloud mit Online Office ==

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

== Nextcloud mit Nextcloud Talk ==

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

Das Hochleistungs-Backend haben wir mittlerweile bei manchen Mitgliedern bereits im Einsatz. Es wird auf einem Container Server installiert. (siehe auch [[Container#Nextcloud_High_Performance_Backend_mit_Caddy|Nextcloud High Performance Backend auf Container Server]])

Unser Mitglied Timotheus Pokorra bietet auch einen Nextcloud High Performance Backend Server zum Teilen an. Siehe [https://solidevereine.de/organisation/nextcloud/#highperf]

Ohne das Hochleistungs-Backend macht wohl die Audio bzw. Video Funktion kaum Sinn, wenn es mit mehr als 2 Teilnehmern genutzt werden soll. Deswegen empfehlen wir, die Anrufe in Talk zu deaktivieren, und stattdessen die BBB zu benutzen.

Das Deaktivieren der Anrufe geschieht in der Administrationsoberfläche von Nextcloud, unter Talk, "Auf Gruppen beschränken", "Starten von Anrufen begrenzen": "Anrufe deaktivieren"

[[Datei:NextcloudTalkAnrufeDeaktivieren.png]]

Die Warnung wegen dem fehlenden Hochleistungs-Backend lässt sich "entschärfen": in der Einstellungsseite von Talk in der Administrationsoberfläche, ganz oben, deaktiviere: "Vor Verbindungsproblemen bei Anrufen mit mehr als 2 Teilnehmern warnen"

[[Datei:NextcloudTalkWarnungDeaktivieren.png]]

== Virenscanner ==

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

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

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

== Volltextsuche ==

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

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

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

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

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

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

Die anderen Einstellung nach den eigenen Vorstellungen vornehmen.

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

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

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

Zur Pflege des Indexes wird ein weiterer Hintergrundprozess gestartet:

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

Die Monit Konfiguration dafür sieht so aus:

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

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

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

== Integration mit LDAP ==

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

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

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

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

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

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

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

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

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

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

Folgende Änderungen können helfen:

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

== Default App einstellen ==

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

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

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

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

= Nextcloud Updates =

== Updater über die Shell starten ==

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

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

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

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

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

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

So können die Apps noch alle aktualisiert werden:

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

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

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

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

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

== Wartungsmodus per Shell ein- oder ausschalten ==

So kann der Wartungsmodus angeschaltet werden:

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

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

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

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

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

Aufgetreten nach erfolgtem Versionsupdate Nextcloud 19 auf Nextcloud 20

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

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

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

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

== Update per Skript ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

= weiterführende Links =

* [https://docs.nextcloud.com/ Nextcloud Dokumentation]
* [https://apps.nextcloud.com/ Nextcloud Erweiterungen ("Apps")]
* [https://docs.nextcloud.com/server/stable/admin_manual/installation/server_tuning.html Optimierung des Caches z.B. für Previews]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/nextcloud Ansible Playbook für Hostsharing]

= Nextcloud Reseller bei HS =

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

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

Collabora Online

2026-04-14T06:13:35Z

Tim00: /* Collabora konfigurieren */ IPv6 und IPv4 eintragen

= Collabora installieren =

== Empfohlene Hardwareausrüstung ==

siehe auch https://sdk.collaboraonline.com/docs/installation/Configuration.html#performance

Wir konfigurieren nun Collabora Online so, dass die Anzahl der verfügbaren CPUs automatisch berücksichtigt wird.

== Vorbereitungen ==

Voraussetzungen sind folgende Punkte:

1. Per Mail an service@hostsharing.net die Aktivierung der Paket Option Collabora Online beauftragen mit der Angabe des Paketkürzel xyz00 und des Benutzers xyz00-cloud unter der die Installation läuft.

2. Grundlage bei Hostsharing ist die Installation der Nextcloud laut Wiki Anleitung [[Nextcloud]].

3. Die APP ''Nextcloud Office'' erst installieren wenn der Service die Bestätigung gesendet hat, dass die Aktivierung erfolgt ist. Hinweis: Bei der Nextcloud-Installation wird ''Nextcloud Office'' u.U. automatisch mit installiert. In diesem Fall ist es notwendig, die App zunächst zu deaktivieren: als Admin im Profilmenü "+ Apps" öffnen und sie dort unter "Aktive Apps" deaktivieren.

== Collabora installieren ==

Collabora ist auf allen 64 Bit hive installiert. Es muss hier nun noch die APP Collabora Online in der Nextcloud installiert werden.

'''WICHTIG:''' Die Freigabe vom Service muss erst per Mail vorliegen!!

1. Anmeldung als '''Admin''' in der Nextcloud Installation

2. Rechts oben auf '''Profilmenü''' den Eintrag '''+APP''' auswählen
[[Datei:Hs-collabora-app-install.jpg|300px]]

3. Im '''Suchfeld''' oben "Nextcloud Office" eingeben
[[Datei:Nextcloud-Office-Suche.png|600px]]

4. Auf den Button ''Herunterladen und aktivieren'' klicken

Damit ist die APP Nextcloud Office installiert und muss nun noch konfiguriert werden.

== Collabora konfigurieren ==

Rechts oben unter '''Profilmenü''' den Eintrag '''Einstellungen''' auswählen.

Anschließend im linken Fensterbereich unter dem Menüpunkt '''Verwaltung'''
den Eintrag '''Collabora Online''' auswählen.

[[Bild:Nextcloud-Office-Menue.png|300px]]

Hier muss nun die PaketDomain entsprechend Eingetragen werden.
Wobei '''xyz00'''.hostsharing.net durch Ihr Paket Kürzel zu ersetzten ist.
Es wird kein Port eingetragen!
Anschließend einmal auf den Button ''Anwenden'' klicken.
[[Bild:Nextcloud-Office-URL.png|600px]]

Es wird empfohlen bei 'Allow list for WOPI requests' die aufgelöste IP Adresse des Webpaketes xyz00.hostsharing.net einzutragen. Sodass nur diese Collabora Instanz Dokumente aus der Nextcloud erhalten kann. Die IP erhält man z.B. über den Konsolenbefehl

<syntaxhighlight lang=shell>
dig -t AAAA xyz00.hostsharing.net +short
2a01:37:1000::53df:4fb1:0
dig -t A xyz00.hostsharing.net +short
83.223.79.177
</syntaxhighlight>

Die beiden IP Adressen sollten mit Komma getrennt in der Nextcloud auf der Admin Config Seite von Collabora hinterlegt werden.

Weitere Einstellungen können individuell noch vorgenommen werden.

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

Discourse installieren

2026-04-14T03:56:59Z

Tim00: /* Am Beispiel von 2026.1.1 auf 2026.1.3 */

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Discourse-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

{{Textkasten|rot|Support von der Discourse-Community|Die Discourse-Entwickler haben sich entschieden, nur eine mehr oder weniger genormte Installationsmethode (via docker) zu unterstützen. Dies ist so auf der hostsharing-Architektur aufgrund mehrerer Bedenken und Überlegungen nicht möglich. Die Community ist durchaus hilfreich, geht aber davon aus, dass quasi alle Nutzer* eine "supported"e Installation durchgeführt haben. Wenn man in entsprechenden Kanälen nach Hilfe fragt, sollte man unbedingt erwähnen, dass man discourse selber anhand dieser hier lesbaren Anleitung installiert hat, um bereits entsprechenden Kommentaren und Nachfragen vorzugreifen.}}

== Über ==

In diesem Artikel wird die Installation von discourse, Version 2.1.0 (September 2018) beschrieben.

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-discourse''
# Eine Domain mit ''xyz00-discourse' als Domain-Administrator, zum Beispiel ''beispiel.discussion''
# Einen Postgresql-User ''xyz00_discourseuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_discoursedb'' mit Datenbank-Owner ''xyz00_discourseuser''

Verwendete IP-Ports der Server-Dienste:
# Redis: localhost:32002
# Discourse-Web: localhost:13000

== Konfiguration der PostgreSQL Datenbank ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{Textkasten|gelb|Firewall/Redis Port|Leider unterstützt discourse nicht die Kommunikation mit Redis über Unix-Sockets. Dementsprechend muss der für Redis konfigurierte Port von dem hostsharing-Support in der Firewall freigegeben werden.}}

<syntaxhighlight lang=shell>
cd
mkdir redis/etc redis/lib redis/log redis/run
</syntaxhighlight>

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/redis/etc/redis.conf'' mit folgendem Inhalt:

<syntaxhighlight lang=shell line>
daemonize no
pidfile /home/pacs/xyz00/users/discourse/redis/run/redis-server.pid
port 32002
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/discourse/redis/log/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/discourse/redis/lib
</syntaxhighlight>

Für Discourse 3.x gilt: "Discourse requires Redis 6.2.0 or up"

Für Debian Buster und Bullseye ist daher das Installieren eines neueren Binaries erforderlich. Bei Debian Bookwork ist bereits Redis 7.0 enthalten (siehe https://packages.debian.org/search?keywords=redis-server).

Hier steht ein entsprechendes Binary für Debian Buster zur Verfügung, das mit dem Public Key von Timotheus geprüft werden kann:

* https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz
* Prüfsignatur: https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz.sig

Prüfen der Signatur:

<syntaxhighlight lang=shell>
gpg --verify redis-server-6.2.12-debian-buster.tar.gz.sig redis-server-6.2.12-debian-buster.tar.gz
</syntaxhighlight>

Das Binary muss nach <code>$HOME/bin</code> verschoben werden, und entsprechend beim Starten des Dienstes eingetragen werden.

== Installation von Ruby ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
echo 'eval "$(rbenv init -)"' >> ~/.profile
</syntaxhighlight>

starte neue Shell:

<syntaxhighlight lang=shell>
exec bash
</syntaxhighlight>

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

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

Nun kann die benötigte Ruby-Version installiert werden:

<syntaxhighlight lang=shell>
rbenv install 2.4
</syntaxhighlight>

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

<syntaxhighlight lang=shell>
cd ~
git clone https://github.com/discourse/discourse.git discourse
cd ~/discourse
</syntaxhighlight>

Die stabile Version auschecken:

<syntaxhighlight lang=shell>
git checkout stable
</syntaxhighlight>

Ruby Pakete installieren:

<syntaxhighlight lang=shell>
gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test
</syntaxhighlight>

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

Anpassen folgender Inhalte:
<syntaxhighlight lang=ini line>
db_host = 127.0.0.1
db_port = 5432
#db_backup_port = 5432 #(auskommentieren)
db_name = xyz00_discoursedb
db_username = xyz00_discourseuser
db_password = "" #db password
hostname = "discourse.xyz00" # hostname
smtp_address = localhost
smtp_enable_start_tls = false
smtp_openssl_verify_mode = 'none'
developer_emails = # your email-address
redis_host = 127.0.0.1
redis_port = 32002
</syntaxhighlight>
===TODO: Secrets setzen! ===
Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== Sidekiq für Hintergrund-Aufgaben konfigurieren ===

''config/sidekiq.conf''

Wichtig: development auf production ändern.

Mit diesem Dienst werden z.B. die E-Mails zur Aktivierung oder zum Passwort Reset verschickt.

=== Problem mit Content Security Policy ===

Um ein Problem mit Content Security Policy zu lösen, weil manche Dateien über http nachgeladen werden, muss in der Datei <code>config/site_settings.yml</code> der Default Wert für force_https auf True gesetzt werden:
<syntaxhighlight lang=yaml line>
force_https:
default: true
</syntaxhighlight>
=== Problem beim Aufsetzen der Datenbank vermeiden ===

'''→ Notiz Mai 2024:''' dies scheint aktuell nicht aufzutreten.

Aus irgendeinem Grund wird beim Initialisieren der Datenbank versucht, den TYPE hotlinked_media_status zweimal in der Datenbank anzulegen. Der Grund ist nicht ersichtlich.

Es kann folgende Änderung an der Datei <code>db/migrate/20220428094026_create_post_hotlinked_media.rb</code> vorgenommen werden:
<syntaxhighlight lang=ruby line>
reversible do |dir|
dir.up { execute <<~SQL }
DO $$ BEGIN CREATE TYPE hotlinked_media_status AS ENUM('downloaded', 'too_large', 'download_failed', 'upload_create_failed'); EXCEPTION WHEN duplicate_object THEN null; END $$;
SQL
dir.down { execute <<~SQL }
DROP TYPE hotlinked_media_status
SQL
end
</syntaxhighlight>
=== Initialisieren der Datenbank ===

<syntaxhighlight lang=shell>
export SAFETY_ASSURED=1
# In Version 2.0.4 funktioniert db:migrate noch, ansonsten db:schema:load und seed nutzen!
# In Version 3.0.3 funktioniert db:migrate auch noch, db:schema:load ging nicht weil die Datei structure.sql fehlte
#RAILS_ENV=production bundle exec rails db:schema:load
#RAILS_ENV=production bundle exec rails db:seed
RAILS_ENV=production bundle exec rails db:migrate
</syntaxhighlight>

=== Kompilieren der Assets ===

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rails assets:precompile
</syntaxhighlight>

=== Konfiguration des Web-Servers (am Beispiel Puma) ===

Die Datei ''config/puma.conf'' anpassen (hier nur Änderungen angezeigt):

<syntaxhighlight lang=ini>
APP_ROOT = '/home/pacs/xyz00/users/discourse/discourse'
daemonize false
</syntaxhighlight>

== Starten der Dienste ==

Zum Start aller notwendigen Dienste sollte systemd benutzt werden.

Die folgenden Dateien müssen nach <code>.config/systemd/user/</code> kopiert werden (überlange Zeilen werden hier im Wiki umgebrochen)

redis.service:

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

[Service]
WorkingDirectory=%h/var/redis
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/bin/redis-server %h/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

sidekiq.service:

<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Sidekiq Service

[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="DB_POOL=8"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec sidekiq -C %h/discourse/config/sidekiq.yml
StandardOutput=append:%h/var/log/sidekiq.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

discourse.service:

<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Web Service

[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="WEB_CONCURRENCY=2"
Environment="MAX_THREADS=5"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:13000
StandardOutput=append:%h/var/log/puma.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

== Einrichten des Apache VHost ==

<syntaxhighlight lang=shell>
cd ~/doms/beispiel.discuss
rm -rf htdocs-ssl subs/www subs-ssl/www
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess
</syntaxhighlight>

Dann die ''htdocs-ssl/.htaccess'' (durch das gelinkte Verzeichnis entspricht das dem Pfad /home/pacs/xyz00/users/discourse/discourse/public/.htaccess ) mit dem Editor der Wahl öffnen und folgende Konfiguration einfügen:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled

RequestHeader set X-Forwarded-Proto "https"

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://127.0.0.1:13000%{REQUEST_URI} [proxy,last]
</syntaxhighlight>
== Wartung ==
=== Backup ===

Discourse macht selbstätig backups und legt diese unter 'public/backups' ab. Enthalten ist ein Datenbank-Dump und die hochgeladenen Dateien.

Im Admin-Bereich lassen sich backups auch manuell antreten.

=== Admin Benutzer einladen ===

Manchmal brauchen wir einen neuen Admin Benutzer, den wir von der Kommandozeile aus einladen möchten.

<syntaxhighlight lang=shell>
cd /discourse
RAILS_ENV=production rake admin:invite[admin@example.org]
</syntaxhighlight>

=== Import aus mbox Archiven ===

Um zum Beispiel ein Mailman2 Archiv zu importieren, wo die Nachrichten als .mbox Datei vorliegen, sind folgende Schritte nötig:

Vorbereitungen an Discourse:

<syntaxhighlight lang=shell>
source .profile
cd discourse
bundle config set frozen false
IMPORT=1 bundle install
bundle config set frozen true
nano script/import_scripts/mbox/settings.yml
# dort ändern:
# data_dir: /home/pacs/xyz00/users/discourse/list-archiv
</syntaxhighlight>

Hochladen der Mailinglisten-Archive:
<syntaxhighlight lang=shell>
mkdir ~/list-archiv
# dort muss es Unterordner mit dem Namen der gewünschten Kategorie geben,
# und die mbox Datei muss auch diesen Namen haben, z.B.:
# ~/list-archiv/beispiel/beispiel.mbox
# ~/list-archiv/example/example.mbox
# um die Beiträge in den entsprechenden Kategorien beispiel und example einzufügen.
</syntaxhighlight>

Durchführen des Imports:
<syntaxhighlight lang=shell>
source .profile
cd discourse
RAILS_ENV=production IMPORT=1 bundle exec rails runner \
script/import_scripts/mbox.rb script/import_scripts/mbox/settings.yml
</syntaxhighlight>

=== Export ===
* Wenn ein Forum beendet wird, möchte man evtl. eine Sicherung als statische HTML Seiten.
** Das wird hier diskutiert: https://meta.discourse.org/t/how-do-i-export-the-complete-forum-as-static-html-pages/71007/3
* Um ein Forum von Discourse zu Flarum umzuziehen, hat Timotheus ein Skript geschrieben.
** Das Migrations-Skript: https://github.com/SolidCharity/discourse_to_flarum
** siehe auch https://discuss.flarum.org/d/4930-discourse-to-flarum-migration-support/29

=== Updates ===

Discourse wird über update via mail informieren (dies kann man m.W. abschalten).

Achtung: bei größeren Updates auch immer Änderungen an der Datei site_settings.yml (https://github.com/discourse/discourse/blob/main/config/site_settings.yml) beachten!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.1 auf 2026.1.3 ====

# Im Web-Backend unter Administration->Backups-> Read-Only Mouds setzen (oder Web Server so konfigurieren, dass keine Zugriffe mehr stattfinden können)
# Backup
# Die lokalen Änderungen sichern:
# cd discourse
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.1 > diff-2026.1.1.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.1.3 v2026.1.3
# evtl. Änderungen aus diff-2026.1.1.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.1.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.3/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.3.8
# rbenv global 3.3.8
# rbenv rehash
# echo "3.3.8" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# Falls die pg extension pg_vector nicht installiert ist: deaktiviere das Plugin während migrate, aber auch für später damit /admin/settings funktioniert (ansonsten in salt pillar pg_vector installieren, und als postgres user: create extension vector;)
## mkdir -p ~/plugins.bak
## mv plugins/discourse-ai ~/plugins.bak
# RAILS_ENV=production bundle exec rake db:migrate
# RAILS_ENV=production bundle exec rake assets:precompile
# Services neu starten
<syntaxhighlight lang=shell>
systemctl --user restart puma
systemctl --user restart sidekiq
systemctl --user restart redis
</syntaxhighlight>
* Zuletzt: Read-Only Modus wieder deaktivieren

=== Debugging ===

Es können folgende Einstellungen in der Datei config/environments/production.rb vorgenommen werden. Danach den Puma Dienst neustarten. Fehlermeldungen und Stacktraces werden dann im Browser ausgegeben.

<syntaxhighlight lang="ini" line>
config.log_level = :debug
config.action_dispatch.show_exceptions = :all
config.action_dispatch.debug_exception_log_level = :error

# Full error reports are enabled and caching is turned off
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
</syntaxhighlight>

=== Erforderliche Anpassungen ===
Weil wir bei Debian Bookworm noch mit ImageMagick 6.9 arbeiten, muss dieser [https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119 Patch] rückgängig gemacht werden:

<syntaxhighlight lang="bash" line>
wget https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119.patch -O ~/imagemagick.patch
patch -p1 --reverse < ~/imagemagick.patch
git commit -a -m "revert imagemagick patch" --no-verify
</syntaxhighlight>

== ToDos ==

* Ein Patch, um Discourse auch via Unix-Socket mit Redis sprechen lassen zu können dürfte relativ einfach sein (es wird ein Wrapper um das redis-gem genutzt).
* Konfiguration von discourse, um mit postgresql via Unix-Socket zu kommunizieren (DISCOURSE_DB_SOCKET environment variable)
* Performance-tuning an diversen Stellen, anhand der discourse_docker-Vorgaben (https://github.com/discourse/discourse_docker), z.B.
** thpoff (huge page settings)
** unicorn (hat eine wesentlich ausgefeiltere Konfigurations-Vorlage, wahrscheinlich bereits ordentlich optimiert)

== Links ==

* https://help.skysilk.com/support/solutions/articles/9000120927-how-to-install-discourse-without-docker-using-skysilk-vps-
* https://github.com/discourse/discourse_docker
* https://github.com/discourse/discourse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/discourse

== Historie ==

* 2018, 14 . September: Initiale Fassung
* 2019, Januar: Update-Informationen ergänzt
* 2022, Juni: systemd Dienste, Discourse 3.0

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Webforen]]
[[Kategorie:Ansible Playbook]]

Discourse installieren

2026-04-04T18:56:36Z

Tim00: /* Am Beispiel von 2026.1.1 auf 2026.1.3 */

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Discourse-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

{{Textkasten|rot|Support von der Discourse-Community|Die Discourse-Entwickler haben sich entschieden, nur eine mehr oder weniger genormte Installationsmethode (via docker) zu unterstützen. Dies ist so auf der hostsharing-Architektur aufgrund mehrerer Bedenken und Überlegungen nicht möglich. Die Community ist durchaus hilfreich, geht aber davon aus, dass quasi alle Nutzer* eine "supported"e Installation durchgeführt haben. Wenn man in entsprechenden Kanälen nach Hilfe fragt, sollte man unbedingt erwähnen, dass man discourse selber anhand dieser hier lesbaren Anleitung installiert hat, um bereits entsprechenden Kommentaren und Nachfragen vorzugreifen.}}

== Über ==

In diesem Artikel wird die Installation von discourse, Version 2.1.0 (September 2018) beschrieben.

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-discourse''
# Eine Domain mit ''xyz00-discourse' als Domain-Administrator, zum Beispiel ''beispiel.discussion''
# Einen Postgresql-User ''xyz00_discourseuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_discoursedb'' mit Datenbank-Owner ''xyz00_discourseuser''

Verwendete IP-Ports der Server-Dienste:
# Redis: localhost:32002
# Discourse-Web: localhost:13000

== Konfiguration der PostgreSQL Datenbank ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{Textkasten|gelb|Firewall/Redis Port|Leider unterstützt discourse nicht die Kommunikation mit Redis über Unix-Sockets. Dementsprechend muss der für Redis konfigurierte Port von dem hostsharing-Support in der Firewall freigegeben werden.}}

<syntaxhighlight lang=shell>
cd
mkdir redis/etc redis/lib redis/log redis/run
</syntaxhighlight>

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/redis/etc/redis.conf'' mit folgendem Inhalt:

<syntaxhighlight lang=shell line>
daemonize no
pidfile /home/pacs/xyz00/users/discourse/redis/run/redis-server.pid
port 32002
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/discourse/redis/log/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/discourse/redis/lib
</syntaxhighlight>

Für Discourse 3.x gilt: "Discourse requires Redis 6.2.0 or up"

Für Debian Buster und Bullseye ist daher das Installieren eines neueren Binaries erforderlich. Bei Debian Bookwork ist bereits Redis 7.0 enthalten (siehe https://packages.debian.org/search?keywords=redis-server).

Hier steht ein entsprechendes Binary für Debian Buster zur Verfügung, das mit dem Public Key von Timotheus geprüft werden kann:

* https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz
* Prüfsignatur: https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz.sig

Prüfen der Signatur:

<syntaxhighlight lang=shell>
gpg --verify redis-server-6.2.12-debian-buster.tar.gz.sig redis-server-6.2.12-debian-buster.tar.gz
</syntaxhighlight>

Das Binary muss nach <code>$HOME/bin</code> verschoben werden, und entsprechend beim Starten des Dienstes eingetragen werden.

== Installation von Ruby ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
echo 'eval "$(rbenv init -)"' >> ~/.profile
</syntaxhighlight>

starte neue Shell:

<syntaxhighlight lang=shell>
exec bash
</syntaxhighlight>

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

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

Nun kann die benötigte Ruby-Version installiert werden:

<syntaxhighlight lang=shell>
rbenv install 2.4
</syntaxhighlight>

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

<syntaxhighlight lang=shell>
cd ~
git clone https://github.com/discourse/discourse.git discourse
cd ~/discourse
</syntaxhighlight>

Die stabile Version auschecken:

<syntaxhighlight lang=shell>
git checkout stable
</syntaxhighlight>

Ruby Pakete installieren:

<syntaxhighlight lang=shell>
gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test
</syntaxhighlight>

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

Anpassen folgender Inhalte:
<syntaxhighlight lang=ini line>
db_host = 127.0.0.1
db_port = 5432
#db_backup_port = 5432 #(auskommentieren)
db_name = xyz00_discoursedb
db_username = xyz00_discourseuser
db_password = "" #db password
hostname = "discourse.xyz00" # hostname
smtp_address = localhost
smtp_enable_start_tls = false
smtp_openssl_verify_mode = 'none'
developer_emails = # your email-address
redis_host = 127.0.0.1
redis_port = 32002
</syntaxhighlight>
===TODO: Secrets setzen! ===
Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== Sidekiq für Hintergrund-Aufgaben konfigurieren ===

''config/sidekiq.conf''

Wichtig: development auf production ändern.

Mit diesem Dienst werden z.B. die E-Mails zur Aktivierung oder zum Passwort Reset verschickt.

=== Problem mit Content Security Policy ===

Um ein Problem mit Content Security Policy zu lösen, weil manche Dateien über http nachgeladen werden, muss in der Datei <code>config/site_settings.yml</code> der Default Wert für force_https auf True gesetzt werden:
<syntaxhighlight lang=yaml line>
force_https:
default: true
</syntaxhighlight>
=== Problem beim Aufsetzen der Datenbank vermeiden ===

'''→ Notiz Mai 2024:''' dies scheint aktuell nicht aufzutreten.

Aus irgendeinem Grund wird beim Initialisieren der Datenbank versucht, den TYPE hotlinked_media_status zweimal in der Datenbank anzulegen. Der Grund ist nicht ersichtlich.

Es kann folgende Änderung an der Datei <code>db/migrate/20220428094026_create_post_hotlinked_media.rb</code> vorgenommen werden:
<syntaxhighlight lang=ruby line>
reversible do |dir|
dir.up { execute <<~SQL }
DO $$ BEGIN CREATE TYPE hotlinked_media_status AS ENUM('downloaded', 'too_large', 'download_failed', 'upload_create_failed'); EXCEPTION WHEN duplicate_object THEN null; END $$;
SQL
dir.down { execute <<~SQL }
DROP TYPE hotlinked_media_status
SQL
end
</syntaxhighlight>
=== Initialisieren der Datenbank ===

<syntaxhighlight lang=shell>
export SAFETY_ASSURED=1
# In Version 2.0.4 funktioniert db:migrate noch, ansonsten db:schema:load und seed nutzen!
# In Version 3.0.3 funktioniert db:migrate auch noch, db:schema:load ging nicht weil die Datei structure.sql fehlte
#RAILS_ENV=production bundle exec rails db:schema:load
#RAILS_ENV=production bundle exec rails db:seed
RAILS_ENV=production bundle exec rails db:migrate
</syntaxhighlight>

=== Kompilieren der Assets ===

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rails assets:precompile
</syntaxhighlight>

=== Konfiguration des Web-Servers (am Beispiel Puma) ===

Die Datei ''config/puma.conf'' anpassen (hier nur Änderungen angezeigt):

<syntaxhighlight lang=ini>
APP_ROOT = '/home/pacs/xyz00/users/discourse/discourse'
daemonize false
</syntaxhighlight>

== Starten der Dienste ==

Zum Start aller notwendigen Dienste sollte systemd benutzt werden.

Die folgenden Dateien müssen nach <code>.config/systemd/user/</code> kopiert werden (überlange Zeilen werden hier im Wiki umgebrochen)

redis.service:

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

[Service]
WorkingDirectory=%h/var/redis
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/bin/redis-server %h/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

sidekiq.service:

<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Sidekiq Service

[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="DB_POOL=8"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec sidekiq -C %h/discourse/config/sidekiq.yml
StandardOutput=append:%h/var/log/sidekiq.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

discourse.service:

<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Web Service

[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="WEB_CONCURRENCY=2"
Environment="MAX_THREADS=5"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:13000
StandardOutput=append:%h/var/log/puma.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

== Einrichten des Apache VHost ==

<syntaxhighlight lang=shell>
cd ~/doms/beispiel.discuss
rm -rf htdocs-ssl subs/www subs-ssl/www
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess
</syntaxhighlight>

Dann die ''htdocs-ssl/.htaccess'' (durch das gelinkte Verzeichnis entspricht das dem Pfad /home/pacs/xyz00/users/discourse/discourse/public/.htaccess ) mit dem Editor der Wahl öffnen und folgende Konfiguration einfügen:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled

RequestHeader set X-Forwarded-Proto "https"

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://127.0.0.1:13000%{REQUEST_URI} [proxy,last]
</syntaxhighlight>
== Wartung ==
=== Backup ===

Discourse macht selbstätig backups und legt diese unter 'public/backups' ab. Enthalten ist ein Datenbank-Dump und die hochgeladenen Dateien.

Im Admin-Bereich lassen sich backups auch manuell antreten.

=== Admin Benutzer einladen ===

Manchmal brauchen wir einen neuen Admin Benutzer, den wir von der Kommandozeile aus einladen möchten.

<syntaxhighlight lang=shell>
cd /discourse
RAILS_ENV=production rake admin:invite[admin@example.org]
</syntaxhighlight>

=== Import aus mbox Archiven ===

Um zum Beispiel ein Mailman2 Archiv zu importieren, wo die Nachrichten als .mbox Datei vorliegen, sind folgende Schritte nötig:

Vorbereitungen an Discourse:

<syntaxhighlight lang=shell>
source .profile
cd discourse
bundle config set frozen false
IMPORT=1 bundle install
bundle config set frozen true
nano script/import_scripts/mbox/settings.yml
# dort ändern:
# data_dir: /home/pacs/xyz00/users/discourse/list-archiv
</syntaxhighlight>

Hochladen der Mailinglisten-Archive:
<syntaxhighlight lang=shell>
mkdir ~/list-archiv
# dort muss es Unterordner mit dem Namen der gewünschten Kategorie geben,
# und die mbox Datei muss auch diesen Namen haben, z.B.:
# ~/list-archiv/beispiel/beispiel.mbox
# ~/list-archiv/example/example.mbox
# um die Beiträge in den entsprechenden Kategorien beispiel und example einzufügen.
</syntaxhighlight>

Durchführen des Imports:
<syntaxhighlight lang=shell>
source .profile
cd discourse
RAILS_ENV=production IMPORT=1 bundle exec rails runner \
script/import_scripts/mbox.rb script/import_scripts/mbox/settings.yml
</syntaxhighlight>

=== Export ===
* Wenn ein Forum beendet wird, möchte man evtl. eine Sicherung als statische HTML Seiten.
** Das wird hier diskutiert: https://meta.discourse.org/t/how-do-i-export-the-complete-forum-as-static-html-pages/71007/3
* Um ein Forum von Discourse zu Flarum umzuziehen, hat Timotheus ein Skript geschrieben.
** Das Migrations-Skript: https://github.com/SolidCharity/discourse_to_flarum
** siehe auch https://discuss.flarum.org/d/4930-discourse-to-flarum-migration-support/29

=== Updates ===

Discourse wird über update via mail informieren (dies kann man m.W. abschalten).

Achtung: bei größeren Updates auch immer Änderungen an der Datei site_settings.yml (https://github.com/discourse/discourse/blob/main/config/site_settings.yml) beachten!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2026.1.1 auf 2026.1.3 ====

# Im Web-Backend unter Administration->Backups-> Read-Only Mouds setzen (oder Web Server so konfigurieren, dass keine Zugriffe mehr stattfinden können)
# Backup
# Die lokalen Änderungen sichern:
# cd discourse
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2026.1.1 > diff-2026.1.1.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.1.3 v2026.1.3
# evtl. Änderungen aus diff-2026.1.1.txt wieder übernehmen und committen
# patch -p1 < diff-2026.1.1.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.3/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.3.8
# rbenv global 3.3.8
# rbenv rehash
# echo "3.3.8" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# wir haben keine pg extension pg_vector, daher deaktivieren wir das Plugin während migrate, aber auch für später damit /admin/settings funktioniert:
# mkdir -p ~/plugins.bak
# mv plugins/discourse-ai ~/plugins.bak
# RAILS_ENV=production bundle exec rake db:migrate
# RAILS_ENV=production bundle exec rake assets:precompile
# Services neu starten
<syntaxhighlight lang=shell>
systemctl --user restart puma
systemctl --user restart sidekiq
systemctl --user restart redis
</syntaxhighlight>
* Zuletzt: Read-Only Modus wieder deaktivieren

=== Debugging ===

Es können folgende Einstellungen in der Datei config/environments/production.rb vorgenommen werden. Danach den Puma Dienst neustarten. Fehlermeldungen und Stacktraces werden dann im Browser ausgegeben.

<syntaxhighlight lang="ini" line>
config.log_level = :debug
config.action_dispatch.show_exceptions = :all
config.action_dispatch.debug_exception_log_level = :error

# Full error reports are enabled and caching is turned off
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
</syntaxhighlight>

=== Erforderliche Anpassungen ===
Weil wir bei Debian Bookworm noch mit ImageMagick 6.9 arbeiten, muss dieser [https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119 Patch] rückgängig gemacht werden:

<syntaxhighlight lang="bash" line>
wget https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119.patch -O ~/imagemagick.patch
patch -p1 --reverse < ~/imagemagick.patch
git commit -a -m "revert imagemagick patch" --no-verify
</syntaxhighlight>

== ToDos ==

* Ein Patch, um Discourse auch via Unix-Socket mit Redis sprechen lassen zu können dürfte relativ einfach sein (es wird ein Wrapper um das redis-gem genutzt).
* Konfiguration von discourse, um mit postgresql via Unix-Socket zu kommunizieren (DISCOURSE_DB_SOCKET environment variable)
* Performance-tuning an diversen Stellen, anhand der discourse_docker-Vorgaben (https://github.com/discourse/discourse_docker), z.B.
** thpoff (huge page settings)
** unicorn (hat eine wesentlich ausgefeiltere Konfigurations-Vorlage, wahrscheinlich bereits ordentlich optimiert)

== Links ==

* https://help.skysilk.com/support/solutions/articles/9000120927-how-to-install-discourse-without-docker-using-skysilk-vps-
* https://github.com/discourse/discourse_docker
* https://github.com/discourse/discourse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/discourse

== Historie ==

* 2018, 14 . September: Initiale Fassung
* 2019, Januar: Update-Informationen ergänzt
* 2022, Juni: systemd Dienste, Discourse 3.0

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Webforen]]
[[Kategorie:Ansible Playbook]]

Collabora Online

2026-03-14T04:51:44Z

Tim00: /* Empfohlene Hardwareausrüstung */

= Collabora installieren =

== Empfohlene Hardwareausrüstung ==

siehe auch https://sdk.collaboraonline.com/docs/installation/Configuration.html#performance

Wir konfigurieren nun Collabora Online so, dass die Anzahl der verfügbaren CPUs automatisch berücksichtigt wird.

== Vorbereitungen ==

Voraussetzungen sind folgende Punkte:

1. Per Mail an service@hostsharing.net die Aktivierung der Paket Option Collabora Online beauftragen mit der Angabe des Paketkürzel xyz00 und des Benutzers xyz00-cloud unter der die Installation läuft.

2. Grundlage bei Hostsharing ist die Installation der Nextcloud laut Wiki Anleitung [[Nextcloud]].

3. Die APP ''Nextcloud Office'' erst installieren wenn der Service die Bestätigung gesendet hat, dass die Aktivierung erfolgt ist. Hinweis: Bei der Nextcloud-Installation wird ''Nextcloud Office'' u.U. automatisch mit installiert. In diesem Fall ist es notwendig, die App zunächst zu deaktivieren: als Admin im Profilmenü "+ Apps" öffnen und sie dort unter "Aktive Apps" deaktivieren.

== Collabora installieren ==

Collabora ist auf allen 64 Bit hive installiert. Es muss hier nun noch die APP Collabora Online in der Nextcloud installiert werden.

'''WICHTIG:''' Die Freigabe vom Service muss erst per Mail vorliegen!!

1. Anmeldung als '''Admin''' in der Nextcloud Installation

2. Rechts oben auf '''Profilmenü''' den Eintrag '''+APP''' auswählen
[[Datei:Hs-collabora-app-install.jpg|300px]]

3. Im '''Suchfeld''' oben "Nextcloud Office" eingeben
[[Datei:Nextcloud-Office-Suche.png|600px]]

4. Auf den Button ''Herunterladen und aktivieren'' klicken

Damit ist die APP Nextcloud Office installiert und muss nun noch konfiguriert werden.

== Collabora konfigurieren ==

Rechts oben unter '''Profilmenü''' den Eintrag '''Einstellungen''' auswählen.

Anschließend im linken Fensterbereich unter dem Menüpunkt '''Verwaltung'''
den Eintrag '''Collabora Online''' auswählen.

[[Bild:Nextcloud-Office-Menue.png|300px]]

Hier muss nun die PaketDomain entsprechend Eingetragen werden.
Wobei '''xyz00'''.hostsharing.net durch Ihr Paket Kürzel zu ersetzten ist.
Es wird kein Port eingetragen!
Anschließend einmal auf den Button ''Anwenden'' klicken.
[[Bild:Nextcloud-Office-URL.png|600px]]

Es wird empfohlen bei 'Allow list for WOPI requests' die aufgelöste IP Adresse des Webpaketes xyz00.hostsharing.net einzutragen. Sodass nur diese Collabora Instanz Dokumente aus der Nextcloud erhalten kann. Die IP erhält man z.B. über den Konsolenbefehl

<syntaxhighlight lang=shell>
dig xyz00.hostsharing.net
</syntaxhighlight>

Die Relevante Zeile im Output sieht ungefähr so aus:

<syntaxhighlight lang=output line>
;; ANSWER SECTION:
xyz00.hostsharing.net. 3807 IN A 83.223.79.177
</syntaxhighlight>

Die IP Adresse ist die, die dann auch in der Nextcloud auf der Admin Config Seite von Collabora hinterlegt werden muss.

Weitere Einstellungen können individuell noch vorgenommen werden.

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

ImapCopy

2026-03-13T14:56:56Z

Tim00: /* Config Web.de -> HS Benutzer */

== ImapCopy ==

ImapCopy ist ein Werkzeug, mit dem man ein komplettes IMAP-Postfach in ein IMAP-Postfach auf einem anderen Server (bei einem anderen Anbieter) kopieren kann. Wir verwenden es für die Migration von Postfächern. Eine Alternative ist [[OfflineIMAP]].

== Installation ImapCopy ==

ImapCopy ist auf den HS Hives schon installiert

== Einrichtung allgemein ==

Anmelden per ssh als ein Benutzer in einem HS-Paket.

<syntaxhighlight lang="bash">
xyz00-imapcopy@h01:~$
</syntaxhighlight>

Dort wird ein Arbeitsverzeichnis erstellt

<syntaxhighlight lang="bash">
xyz00-imapcopy@h01:~$ mkdir imapcopy
xyz00-imapcopy@h01:~$ cd imapcopy
</syntaxhighlight>

Die Konfiguration wird in einer Datei ImapCopy.cfg gespeichert

<syntaxhighlight lang="bash">
xyz00-imapcopy@h01:~/imapcopy$ vi ImapCopy.cfg
</syntaxhighlight>

=== Config Web.de -> HS Benutzer ===

Muster Inhalt der Datei ImapCopy.cfg

<syntaxhighlight lang="bash" line>
#############################################################
# imapcopy config
# all lines beginning with # are comments and will be ignored
#############################################################

##############
# Sourceserver
##############
#SourceServer imap.web.de
#SourcePort 143
SourceServer 127.0.0.1
SourcePort 10143

###################
# Destinationserver
###################
#DestServer xyz00.hostsharing.net
#DestPort 143
DestServer 127.0.0.1
DestPort 20143

#########
# Options
#########
#
# DebugSrc and DebugDest will show all traffic between IMAPCopy and Server
#
#DebugSrc
#DebugDst

#################
# Folders to skip
#################
#skipfolder INBOX.Trash
#skipfolder INBOX.Sent
#skipfolder "INBOX.Sent Objects"

#################
# Folders to copy
#################
#copyfolder INBOX
#copyfolder "INBOX.My personal files"
#copyfolder INBOX.Net-Connection.dy
#copyfolder INBOX.test

#######################################################
# Rootfolder
# Can be specified to copy the Folder-Structure under
# a separate folder instead of inbox
#######################################################
#DstRootFolder "Your old Mails"

###############################################################
# Specify Flags that are supported on the destination server
# (AllowFlags) or flags that should be filtered out (DenyFlags)
# If not specified, all Flags are copyied 1:1
# If AllowFlags is specified, all not specified Flags will be
# removed and not copied to the destination
# If DenyFlags is specified, those flags will be removed and
# the remaining ones will be copied
# Both (AllowFlags and DenyFlags) could be specified but
# would (in most cases) make no sense
##############################################################
#AllowFlags "\Seen\Answered\Flagged\Deleted\Draft Junk NonJunk $MDNSent $Forwared"
DenyFlags "\Recent"

##############################################################
# Timezone conversion
# The imap rfc is not clear on what kind of time offsets
# can be used. +XXXX -XXXX will be supported on all servers
# You can add as many entries as needed in the form
# converttimezone SRC DST
# to convert zones that your target server rejects
##############################################################
converttimezone "UTC" "+0000"
converttimezone "UT" "+0000"

#############################
# List of users and passwords
#############################
# SourceUser SourcePassword DestinationUser DestinationPassword
Copy "xyz@web.de" "Euer-Passwort" "xyz00-imap" "Benutzer-Passwort"
</syntaxhighlight>

=== Config gmail.com -> HS Benutzer ===

Da ImapCopy nicht direkt SSL unterstützt benötigt z.b. gmail und ggf einige andere die weiter unten beschrieben Lösung mit einem stunnel.

== Testen einer Verbindung ==

Zum testen ob die Daten alle OK sind auf der shell einfach:

<syntaxhighlight lang="bash">
xyz00-imapcopy@h01:~/imapcopy$ imapcopy -t
</syntaxhighlight>

eingeben.

== Daten austauschen ==

Wir empfehlen: Benutze eine <code>screen</code> Sitzung, damit die Übertragung nicht durch einen Verbindungsabbruch durcheinander kommt!

<syntaxhighlight lang="bash">
xyz00-imapcopy@h01:~/imapcopy$ screen
xyz00-imapcopy@h01:~/imapcopy$ imapcopy
</syntaxhighlight>

== Hilfe ==

<syntaxhighlight lang="bash">
xyz00-imapcopy@h01:~/imapcopy$ imapcopy -h
xyz00-imapcopy@h01:~/imapcopy$ man imapcopy
</syntaxhighlight>

== Python Skript zur Massenverarbeitung ==

Wenn viele Postfächer umgezogen werden sollen, ist es hilfreich, wenn die Befehle und die Passwörter generiert werden können.

Dafür haben wir ein Python-Skript, das in diesem Repository zur Verfügung steht:
* [https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/create_and_move_mailboxes.py create_and_move_mailboxes.py]
* mit einer entsprechenden Konfigurations-Datei: [https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/create_and_move_mailboxes_config-sample.py create_and_move_mailboxes_config-sample.py]

In der Konfigurations-Datei werden die Postfächer mit E-Mail-Adresse und Aliasen, und die Verteiler konfiguriert.

Die Passwörter werden nur einmal generiert, und in einer sqlite Datenbank gespeichert.

<syntaxhighlight lang="bash" line>
# dem Kunden die neuen Passwörter mitteilen:
ACTION=info python3 create_and_move_mailboxes.py
# Anweisungen in hsscript ausführen:
ACTION=hsadmin python3 create_and_move_mailboxes.py
# Anweisungen in ImapCopy einfügen:
ACTION=imapcopy python3 create_and_move_mailboxes.py
</syntaxhighlight>

== ssl via stunnel ==

Es wird eine Konfuguration Datei , hier stunnel-to-gmail.conf, benötigt.

<syntaxhighlight lang="bash">
xyz00-imapcopy@h01:~/imapcopy$ vi stunnel-to-gmail.conf
</syntaxhighlight>

Inhalt der Datei stunnel-to-gmail.conf:

<syntaxhighlight lang="ini" line>
foreground=yes

; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1

; Some debugging stuff useful for troubleshooting
debug = 7

; Pfad for pid file
pid = /tmp/stunnel4-xyz00.pid

; Use it for client mode
client = yes

; Service-level configuration

[imap]
accept = 127.0.0.1:10143
connect = imap.gmail.com:993
retry = yes

[imap]
accept = 127.0.0.1:20143
connect = xyz00.hostsharing.net:993
retry = yes
</syntaxhighlight>

=== Änderung in der ImapCopy.cfg ===

<syntaxhighlight lang="ini" line>
##############
# Sourceserver
##############
SourceServer 127.0.0.1
SourcePort 10143

###################
# Destinationserver
###################
DestServer 127.0.0.1
DestPort 20143

#############################
# List of users and passwords
#############################
# SourceUser SourcePassword DestinationUser DestinationPassword
Copy "xyz@gmail.com" "passwort" "xyz00-imap" "passwort"
</syntaxhighlight>

=== stunnel aufbauen ===

Wir öffnen eine zweite Shell, starten dort screen, um kein Problem bei Verbindungsabbrüchen zu haben, und starten dann den stunnel:

<syntaxhighlight lang="bash" line>
xyz00-imapcopy@h01:~/imapcopy$ screen
xyz00-imapcopy@h01:~/imapcopy$ stunnel4 stunnel-to-gmail.conf
</syntaxhighlight>

=== Verbindung prüfen und herstellen ===

Siehe -> Testen einer Verbindung
und -> Daten austauschen

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

Speicherbelegung

2026-03-12T14:13:58Z

Tim00: /* Unvermutete Speicherbelegung */

Discourse installieren

2026-03-12T05:28:00Z

Tim00: /* Am Beispiel von 2025.12.0 auf 2026.1.1 */

{{Textkasten|gelb|Für Managed Server|Ein funktionierender Discourse-Server erfordert mehrere laufende Server-Dienste. Für den Betrieb ist ein Managed Server sinnvoll.}}

{{Textkasten|rot|Support von der Discourse-Community|Die Discourse-Entwickler haben sich entschieden, nur eine mehr oder weniger genormte Installationsmethode (via docker) zu unterstützen. Dies ist so auf der hostsharing-Architektur aufgrund mehrerer Bedenken und Überlegungen nicht möglich. Die Community ist durchaus hilfreich, geht aber davon aus, dass quasi alle Nutzer* eine "supported"e Installation durchgeführt haben. Wenn man in entsprechenden Kanälen nach Hilfe fragt, sollte man unbedingt erwähnen, dass man discourse selber anhand dieser hier lesbaren Anleitung installiert hat, um bereits entsprechenden Kommentaren und Nachfragen vorzugreifen.}}

== Über ==

In diesem Artikel wird die Installation von discourse, Version 2.1.0 (September 2018) beschrieben.

== Vorbereitungen ==

Mit Hilfe von HSAdmin wird angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-discourse''
# Eine Domain mit ''xyz00-discourse' als Domain-Administrator, zum Beispiel ''beispiel.discussion''
# Einen Postgresql-User ''xyz00_discourseuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_discoursedb'' mit Datenbank-Owner ''xyz00_discourseuser''

Verwendete IP-Ports der Server-Dienste:
# Redis: localhost:32002
# Discourse-Web: localhost:13000

== Konfiguration der PostgreSQL Datenbank ==

Es müssen noch Erweiterungen für Postgresql installiert werden:

<syntaxhighlight lang=shell line>
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS hstore WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS pg_trgm WITH SCHEMA public;"
psql --user xyz00_discourseuser -c "CREATE EXTENSION IF NOT EXISTS unaccent WITH SCHEMA public;"
</syntaxhighlight>

== Konfiguration des Redis Server ==

{{Textkasten|gelb|Firewall/Redis Port|Leider unterstützt discourse nicht die Kommunikation mit Redis über Unix-Sockets. Dementsprechend muss der für Redis konfigurierte Port von dem hostsharing-Support in der Firewall freigegeben werden.}}

<syntaxhighlight lang=shell>
cd
mkdir redis/etc redis/lib redis/log redis/run
</syntaxhighlight>

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/redis/etc/redis.conf'' mit folgendem Inhalt:

<syntaxhighlight lang=shell line>
daemonize no
pidfile /home/pacs/xyz00/users/discourse/redis/run/redis-server.pid
port 32002
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/discourse/redis/log/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/discourse/redis/lib
</syntaxhighlight>

Für Discourse 3.x gilt: "Discourse requires Redis 6.2.0 or up"

Für Debian Buster und Bullseye ist daher das Installieren eines neueren Binaries erforderlich. Bei Debian Bookwork ist bereits Redis 7.0 enthalten (siehe https://packages.debian.org/search?keywords=redis-server).

Hier steht ein entsprechendes Binary für Debian Buster zur Verfügung, das mit dem Public Key von Timotheus geprüft werden kann:

* https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz
* Prüfsignatur: https://download.solidcharity.com/tarballs/tpokorra/hostsharing/redis-server-6.2.12-debian-buster.tar.gz.sig

Prüfen der Signatur:

<syntaxhighlight lang=shell>
gpg --verify redis-server-6.2.12-debian-buster.tar.gz.sig redis-server-6.2.12-debian-buster.tar.gz
</syntaxhighlight>

Das Binary muss nach <code>$HOME/bin</code> verschoben werden, und entsprechend beim Starten des Dienstes eingetragen werden.

== Installation von Ruby ==

Als User ''xyz00-discourse'': Installation von Ruby mit ''rbenv'' mit folgenden Befehlen:

Zunächst ''rbenv'' and ''ruby-build'':

<syntaxhighlight lang=shell line>
git clone https://github.com/rbenv/rbenv.git ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
echo 'eval "$(rbenv init -)"' >> ~/.profile
</syntaxhighlight>

starte neue Shell:

<syntaxhighlight lang=shell>
exec bash
</syntaxhighlight>

Überprüfe rbenv-Installation

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

Installiere ruby-build als rbenv-Plugin

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

Nun kann die benötigte Ruby-Version installiert werden:

<syntaxhighlight lang=shell>
rbenv install 2.4
</syntaxhighlight>

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

<syntaxhighlight lang=shell>
cd ~
git clone https://github.com/discourse/discourse.git discourse
cd ~/discourse
</syntaxhighlight>

Die stabile Version auschecken:

<syntaxhighlight lang=shell>
git checkout stable
</syntaxhighlight>

Ruby Pakete installieren:

<syntaxhighlight lang=shell>
gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test
</syntaxhighlight>

== Konfiguration der Discourse Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/discourse/discourse/config/discourse.conf'' anhand der Beispiel-Datei:

<syntaxhighlight lang=shell>
cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf
</syntaxhighlight>

Anpassen folgender Inhalte:
<syntaxhighlight lang=ini line>
db_host = 127.0.0.1
db_port = 5432
#db_backup_port = 5432 #(auskommentieren)
db_name = xyz00_discoursedb
db_username = xyz00_discourseuser
db_password = "" #db password
hostname = "discourse.xyz00" # hostname
smtp_address = localhost
smtp_enable_start_tls = false
smtp_openssl_verify_mode = 'none'
developer_emails = # your email-address
redis_host = 127.0.0.1
redis_port = 32002
</syntaxhighlight>
===TODO: Secrets setzen! ===
Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rake secret
</syntaxhighlight>

=== Sidekiq für Hintergrund-Aufgaben konfigurieren ===

''config/sidekiq.conf''

Wichtig: development auf production ändern.

Mit diesem Dienst werden z.B. die E-Mails zur Aktivierung oder zum Passwort Reset verschickt.

=== Problem mit Content Security Policy ===

Um ein Problem mit Content Security Policy zu lösen, weil manche Dateien über http nachgeladen werden, muss in der Datei <code>config/site_settings.yml</code> der Default Wert für force_https auf True gesetzt werden:
<syntaxhighlight lang=yaml line>
force_https:
default: true
</syntaxhighlight>
=== Problem beim Aufsetzen der Datenbank vermeiden ===

'''→ Notiz Mai 2024:''' dies scheint aktuell nicht aufzutreten.

Aus irgendeinem Grund wird beim Initialisieren der Datenbank versucht, den TYPE hotlinked_media_status zweimal in der Datenbank anzulegen. Der Grund ist nicht ersichtlich.

Es kann folgende Änderung an der Datei <code>db/migrate/20220428094026_create_post_hotlinked_media.rb</code> vorgenommen werden:
<syntaxhighlight lang=ruby line>
reversible do |dir|
dir.up { execute <<~SQL }
DO $$ BEGIN CREATE TYPE hotlinked_media_status AS ENUM('downloaded', 'too_large', 'download_failed', 'upload_create_failed'); EXCEPTION WHEN duplicate_object THEN null; END $$;
SQL
dir.down { execute <<~SQL }
DROP TYPE hotlinked_media_status
SQL
end
</syntaxhighlight>
=== Initialisieren der Datenbank ===

<syntaxhighlight lang=shell>
export SAFETY_ASSURED=1
# In Version 2.0.4 funktioniert db:migrate noch, ansonsten db:schema:load und seed nutzen!
# In Version 3.0.3 funktioniert db:migrate auch noch, db:schema:load ging nicht weil die Datei structure.sql fehlte
#RAILS_ENV=production bundle exec rails db:schema:load
#RAILS_ENV=production bundle exec rails db:seed
RAILS_ENV=production bundle exec rails db:migrate
</syntaxhighlight>

=== Kompilieren der Assets ===

<syntaxhighlight lang=shell>
RAILS_ENV=production bundle exec rails assets:precompile
</syntaxhighlight>

=== Konfiguration des Web-Servers (am Beispiel Puma) ===

Die Datei ''config/puma.conf'' anpassen (hier nur Änderungen angezeigt):

<syntaxhighlight lang=ini>
APP_ROOT = '/home/pacs/xyz00/users/discourse/discourse'
daemonize false
</syntaxhighlight>

== Starten der Dienste ==

Zum Start aller notwendigen Dienste sollte systemd benutzt werden.

Die folgenden Dateien müssen nach <code>.config/systemd/user/</code> kopiert werden (überlange Zeilen werden hier im Wiki umgebrochen)

redis.service:

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

[Service]
WorkingDirectory=%h/var/redis
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/bin/redis-server %h/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

sidekiq.service:

<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Sidekiq Service

[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="DB_POOL=8"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec sidekiq -C %h/discourse/config/sidekiq.yml
StandardOutput=append:%h/var/log/sidekiq.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

discourse.service:

<syntaxhighlight lang=ini line>
[Unit]
Description=Discourse Web Service

[Service]
WorkingDirectory=%h/discourse
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
Environment="RAILS_ENV=production"
Environment="WEB_CONCURRENCY=2"
Environment="MAX_THREADS=5"
Environment="MALLOC_ARENA_MAX=2"
ExecStart=%h/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:13000
StandardOutput=append:%h/var/log/puma.out.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

== Einrichten des Apache VHost ==

<syntaxhighlight lang=shell>
cd ~/doms/beispiel.discuss
rm -rf htdocs-ssl subs/www subs-ssl/www
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess
</syntaxhighlight>

Dann die ''htdocs-ssl/.htaccess'' (durch das gelinkte Verzeichnis entspricht das dem Pfad /home/pacs/xyz00/users/discourse/discourse/public/.htaccess ) mit dem Editor der Wahl öffnen und folgende Konfiguration einfügen:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled

RequestHeader set X-Forwarded-Proto "https"

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://127.0.0.1:13000%{REQUEST_URI} [proxy,last]
</syntaxhighlight>
== Wartung ==
=== Backup ===

Discourse macht selbstätig backups und legt diese unter 'public/backups' ab. Enthalten ist ein Datenbank-Dump und die hochgeladenen Dateien.

Im Admin-Bereich lassen sich backups auch manuell antreten.

=== Admin Benutzer einladen ===

Manchmal brauchen wir einen neuen Admin Benutzer, den wir von der Kommandozeile aus einladen möchten.

<syntaxhighlight lang=shell>
cd /discourse
RAILS_ENV=production rake admin:invite[admin@example.org]
</syntaxhighlight>

=== Import aus mbox Archiven ===

Um zum Beispiel ein Mailman2 Archiv zu importieren, wo die Nachrichten als .mbox Datei vorliegen, sind folgende Schritte nötig:

Vorbereitungen an Discourse:

<syntaxhighlight lang=shell>
source .profile
cd discourse
bundle config set frozen false
IMPORT=1 bundle install
bundle config set frozen true
nano script/import_scripts/mbox/settings.yml
# dort ändern:
# data_dir: /home/pacs/xyz00/users/discourse/list-archiv
</syntaxhighlight>

Hochladen der Mailinglisten-Archive:
<syntaxhighlight lang=shell>
mkdir ~/list-archiv
# dort muss es Unterordner mit dem Namen der gewünschten Kategorie geben,
# und die mbox Datei muss auch diesen Namen haben, z.B.:
# ~/list-archiv/beispiel/beispiel.mbox
# ~/list-archiv/example/example.mbox
# um die Beiträge in den entsprechenden Kategorien beispiel und example einzufügen.
</syntaxhighlight>

Durchführen des Imports:
<syntaxhighlight lang=shell>
source .profile
cd discourse
RAILS_ENV=production IMPORT=1 bundle exec rails runner \
script/import_scripts/mbox.rb script/import_scripts/mbox/settings.yml
</syntaxhighlight>

=== Export ===
* Wenn ein Forum beendet wird, möchte man evtl. eine Sicherung als statische HTML Seiten.
** Das wird hier diskutiert: https://meta.discourse.org/t/how-do-i-export-the-complete-forum-as-static-html-pages/71007/3
* Um ein Forum von Discourse zu Flarum umzuziehen, hat Timotheus ein Skript geschrieben.
** Das Migrations-Skript: https://github.com/SolidCharity/discourse_to_flarum
** siehe auch https://discuss.flarum.org/d/4930-discourse-to-flarum-migration-support/29

=== Updates ===

Discourse wird über update via mail informieren (dies kann man m.W. abschalten).

Achtung: bei größeren Updates auch immer Änderungen an der Datei site_settings.yml (https://github.com/discourse/discourse/blob/main/config/site_settings.yml) beachten!

Siehe auch die unterstützten Releases: https://releases.discourse.org/ und die Tags: https://github.com/discourse/discourse/tags

==== Am Beispiel von 2025.12.0 auf 2026.1.1 ====

# Im Web-Backend unter Administration->Backups-> Read-Only Mouds setzen (oder Web Server so konfigurieren, dass keine Zugriffe mehr stattfinden können)
# Backup
# Die lokalen Änderungen sichern:
# cd discourse
# mv ~/plugins.bak/discourse-ai plugins
# git diff v2025.12.0 > diff-2025.12.0.txt
# git fetch
# git checkout -b hostsharing-deployment-v2026.1.1 v2026.1.1
# evtl. Änderungen aus diff-2025.12.0.txt wieder übernehmen und committen
# patch -p1 < diff-2025.12.0.txt
# git commit -a -m "spezifische Änderungen für diese Instanz" --no-verify
# Schauen, ob discourse eine neue Ruby-Version nutzt (z.B. in https://github.com/discourse/discourse_docker/blob/main/image/base/Dockerfile bzw. https://github.com/discourse/discourse/blob/v2026.1.1/Gemfile)
# Ist dies der Fall, dann:
# rbenv install 3.3.8
# rbenv global 3.3.8
# rbenv rehash
# echo "3.3.8" > .ruby-version
# installiere Node 22: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/install-nodejs.sh
# source ~/.profile
# gem update --system
# bundle install
# npm install -g terser uglify-js pnpm@10
# corepack use pnpm@latest-10
# pnpm install
# export $(grep -v '^#' ~/discourse.env | xargs -d '\n')
# source ~/.profile
# wir haben keine pg extension pg_vector, daher deaktivieren wir das Plugin während migrate, aber auch für später damit /admin/settings funktioniert:
# mkdir -p ~/plugins.bak
# mv plugins/discourse-ai ~/plugins.bak
# RAILS_ENV=production bundle exec rake db:migrate
# RAILS_ENV=production bundle exec rake assets:precompile
# Services neu starten
<syntaxhighlight lang=shell>
systemctl --user restart puma
systemctl --user restart sidekiq
systemctl --user restart redis
</syntaxhighlight>
* Zuletzt: Read-Only Modus wieder deaktivieren

=== Debugging ===

Es können folgende Einstellungen in der Datei config/environments/production.rb vorgenommen werden. Danach den Puma Dienst neustarten. Fehlermeldungen und Stacktraces werden dann im Browser ausgegeben.

<syntaxhighlight lang="ini" line>
config.log_level = :debug
config.action_dispatch.show_exceptions = :all
config.action_dispatch.debug_exception_log_level = :error

# Full error reports are enabled and caching is turned off
config.consider_all_requests_local = true
config.action_controller.perform_caching = false
</syntaxhighlight>

=== Erforderliche Anpassungen ===
Weil wir bei Debian Bookworm noch mit ImageMagick 6.9 arbeiten, muss dieser [https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119 Patch] rückgängig gemacht werden:

<syntaxhighlight lang="bash" line>
wget https://github.com/discourse/discourse/commit/17aa831337e352dfd875f1b4ddc4492bd0835119.patch -O ~/imagemagick.patch
patch -p1 --reverse < ~/imagemagick.patch
git commit -a -m "revert imagemagick patch" --no-verify
</syntaxhighlight>

== ToDos ==

* Ein Patch, um Discourse auch via Unix-Socket mit Redis sprechen lassen zu können dürfte relativ einfach sein (es wird ein Wrapper um das redis-gem genutzt).
* Konfiguration von discourse, um mit postgresql via Unix-Socket zu kommunizieren (DISCOURSE_DB_SOCKET environment variable)
* Performance-tuning an diversen Stellen, anhand der discourse_docker-Vorgaben (https://github.com/discourse/discourse_docker), z.B.
** thpoff (huge page settings)
** unicorn (hat eine wesentlich ausgefeiltere Konfigurations-Vorlage, wahrscheinlich bereits ordentlich optimiert)

== Links ==

* https://help.skysilk.com/support/solutions/articles/9000120927-how-to-install-discourse-without-docker-using-skysilk-vps-
* https://github.com/discourse/discourse_docker
* https://github.com/discourse/discourse
* https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/discourse

== Historie ==

* 2018, 14 . September: Initiale Fassung
* 2019, Januar: Update-Informationen ergänzt
* 2022, Juni: systemd Dienste, Discourse 3.0

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Webforen]]
[[Kategorie:Ansible Playbook]]

Umzug aller Postfächer einer Domain

2026-03-10T17:24:03Z

Tim00: /* Szenario */

== Szenario ==

Das neue Mitglied hat bisher eine Domain und mehrere Postfächer bei einem Anbieter. Nun soll die Domain, die Webseite, die Postfächer und evtl. auch andere Anwendungen, z.B. eine Nextcloud, zu Hostsharing umgezogen werden.

Wir betrachten hier erstmal nur den Umzug der Postfächer und der E-Mail Adressen. Die weiteren Schritte können im Anschluss durchgeführt werden.

== Durchzuführende Schritte ==

=== Vorbereitungen an den Einstellungen der Domain ===
==== TTL heruntersetzen ====
Beim bisherigen Anbieter sollte die TTL auf dem MX Eintrag der Domain auf 600 Sekunden gesetzt werden (10 Minuten).
Das sollte spätestens einen Tag vor dem Umzug erledigt werden, um den Default-Wert der TTL von bis zu 24 Stunden zu vermeiden.
Dadurch wird die Zeitspanne verringert, in der während des Umzugs nach dem Ändern des MX Eintrages sich der neue Mailempfangsserver im DNS herumspricht.

Der aktuelle TTL lässt sich mit diesem Befehl prüfen:

<syntaxhighlight lang=shell>
dig -t MX meinedomain.de
meinedomain.de. 86400 IN MX 0 xyz.mail.protection.outlook.com.
</syntaxhighlight>

==== SPF Eintrag erweitern ====
Es sollte der SPF TXT Eintrag um <code>include:spf.hostsharing.net</code> erweitert werden.

=== Vorbereitungen in HSAdmin ===

Es sollte in HSAdmin auf https://admin.hostsharing.net folgende Dinge angelegt werden:

* die Domain meinedomain.de sollte angelegt werden
* es sollten die Postfächer als Unix Benutzer angelegt werden, und temporäre Passwörter vergeben werden.
* es sollten die E-Mail Adressen, Aliase und Weiterleitungen eingerichtet werden.

Es kann dafür auch dieses Python-Skript benutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/create_and_move_mailboxes.py

=== Ankündigung an die Nutzenden ===

Rechtzeitig muss eine Anleitung und die neuen Zugangsdaten an die Nutzenden weitergegeben werden. Am besten sollten diese Menschen auch über einen anderen Kanal zu erreichen sein, falls es Probleme beim Wechsel auf das neue Postfach gibt.

Folgende Sachen sollten erwähnt werden:

* Umstellung der Zugangsdaten. Siehe auch Screenshots für Thunderbird auf https://www.hostsharing.net/doc/managed-operations-platform/email/
* Möglichkeit von Webmail: https://webmail.hostsharing.net
** dabei sollte beachtet werden:
*** Absender Adresse muss bei der ersten Anmeldung korrigiert werden.
*** evtl. müssen in den Einstellungen die Unterordner abonniert werden, sonst werden sie im Posteingang nicht angezeigt
* Ändern des temporären Passworts
** nach dem erfolgreichen Umzug der Postfächer muss jede Benutzerin das Passwort öndern
** das geschieht auf https://admin.hostsharing.net: anmelden, und dann oben rechts auf den eigenen Benutzernamen klicken

=== Der tatsächliche Umzug ===

Folgende Schritte müssen während des Umzugs in dieser Reihenfolge passieren:

* der MX Eintrag auf der Domain muss geändert werden. Alte MX Einträge müssen entfernt werden, und die 3 Einträge mailin1.hostsharing.net, mailin2.hostsharing.net und mailin3.hostsharing.net müssen eingefügt werden.
* die Passwörter für die alten Postfächer müssen zurückgesetzt werden, es reicht ein Passwort für alle.
* die Inhalte der Postfächer werden über imapcopy in die Postfächer bei Hostsharing kopiert.

=== Nacharbeiten ===

Nach dem erfolgreichen Umzug:

* die Benutzer ändern die Passwörter ihrer neuen Postfächer
* die Benutzer konfigurieren den E-Mail Client mit den neuen Zugangsdaten

Wenn sich der Staub gelegt hat, können danach die Webseite, weitere Anwendungen, und schließlich die gesamte Domain zu Hostsharing umgezogen werden.

Umzug aller Postfächer einer Domain

2026-03-10T15:47:17Z

Tim00: /* Durchzuführende Schritte */

== Szenario ==

Das neue Mitglied hat bisher eine Domain und mehrere Postfächer bei einem Anbieter. Nun soll die Domain, die Webseite, die Postfächer und evtl. auch andere Anwendungen, z.B. eine Nextcloud, zu Hostsharing umgezogen werden.

Wir betrachten hier erstmal nur dem Umzug der Postfächer und der E-Mail Adressen. Die weiteren Schritte können im Anschluss durchgeführt werden.

== Durchzuführende Schritte ==

=== Vorbereitungen an den Einstellungen der Domain ===
==== TTL heruntersetzen ====
Beim bisherigen Anbieter sollte die TTL auf dem MX Eintrag der Domain auf 600 Sekunden gesetzt werden (10 Minuten).
Das sollte spätestens einen Tag vor dem Umzug erledigt werden, um den Default-Wert der TTL von bis zu 24 Stunden zu vermeiden.
Dadurch wird die Zeitspanne verringert, in der während des Umzugs nach dem Ändern des MX Eintrages sich der neue Mailempfangsserver im DNS herumspricht.

Der aktuelle TTL lässt sich mit diesem Befehl prüfen:

<syntaxhighlight lang=shell>
dig -t MX meinedomain.de
meinedomain.de. 86400 IN MX 0 xyz.mail.protection.outlook.com.
</syntaxhighlight>

==== SPF Eintrag erweitern ====
Es sollte der SPF TXT Eintrag um <code>include:spf.hostsharing.net</code> erweitert werden.

=== Vorbereitungen in HSAdmin ===

Es sollte in HSAdmin auf https://admin.hostsharing.net folgende Dinge angelegt werden:

* die Domain meinedomain.de sollte angelegt werden
* es sollten die Postfächer als Unix Benutzer angelegt werden, und temporäre Passwörter vergeben werden.
* es sollten die E-Mail Adressen, Aliase und Weiterleitungen eingerichtet werden.

Es kann dafür auch dieses Python-Skript benutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/create_and_move_mailboxes.py

=== Ankündigung an die Nutzenden ===

Rechtzeitig muss eine Anleitung und die neuen Zugangsdaten an die Nutzenden weitergegeben werden. Am besten sollten diese Menschen auch über einen anderen Kanal zu erreichen sein, falls es Probleme beim Wechsel auf das neue Postfach gibt.

Folgende Sachen sollten erwähnt werden:

* Umstellung der Zugangsdaten. Siehe auch Screenshots für Thunderbird auf https://www.hostsharing.net/doc/managed-operations-platform/email/
* Möglichkeit von Webmail: https://webmail.hostsharing.net
** dabei sollte beachtet werden:
*** Absender Adresse muss bei der ersten Anmeldung korrigiert werden.
*** evtl. müssen in den Einstellungen die Unterordner abonniert werden, sonst werden sie im Posteingang nicht angezeigt
* Ändern des temporären Passworts
** nach dem erfolgreichen Umzug der Postfächer muss jede Benutzerin das Passwort öndern
** das geschieht auf https://admin.hostsharing.net: anmelden, und dann oben rechts auf den eigenen Benutzernamen klicken

=== Der tatsächliche Umzug ===

Folgende Schritte müssen während des Umzugs in dieser Reihenfolge passieren:

* der MX Eintrag auf der Domain muss geändert werden. Alte MX Einträge müssen entfernt werden, und die 3 Einträge mailin1.hostsharing.net, mailin2.hostsharing.net und mailin3.hostsharing.net müssen eingefügt werden.
* die Passwörter für die alten Postfächer müssen zurückgesetzt werden, es reicht ein Passwort für alle.
* die Inhalte der Postfächer werden über imapcopy in die Postfächer bei Hostsharing kopiert.

=== Nacharbeiten ===

Nach dem erfolgreichen Umzug:

* die Benutzer ändern die Passwörter ihrer neuen Postfächer
* die Benutzer konfigurieren den E-Mail Client mit den neuen Zugangsdaten

Wenn sich der Staub gelegt hat, können danach die Webseite, weitere Anwendungen, und schließlich die gesamte Domain zu Hostsharing umgezogen werden.

Umzug aller Postfächer einer Domain

2026-03-10T15:46:04Z

Tim00: /* SPF Eintrag erweitern */

== Szenario ==

Das neue Mitglied hat bisher eine Domain und mehrere Postfächer bei einem Anbieter. Nun soll die Domain, die Webseite, die Postfächer und evtl. auch andere Anwendungen, z.B. eine Nextcloud, zu Hostsharing umgezogen werden.

Wir betrachten hier erstmal nur dem Umzug der Postfächer und der E-Mail Adressen. Die weiteren Schritte können im Anschluss durchgeführt werden.

== Durchzuführende Schritte ==

=== TTL heruntersetzen ===
Beim bisherigen Anbieter sollte die TTL auf dem MX Eintrag der Domain auf 600 Sekunden gesetzt werden (10 Minuten).
Das sollte spätestens einen Tag vor dem Umzug erledigt werden, um den Default-Wert der TTL von bis zu 24 Stunden zu vermeiden.
Dadurch wird die Zeitspanne verringert, in der während des Umzugs nach dem Ändern des MX Eintrages sich der neue Mailempfangsserver im DNS herumspricht.

Der aktuelle TTL lässt sich mit diesem Befehl prüfen:

<syntaxhighlight lang=shell>
dig -t MX meinedomain.de
meinedomain.de. 86400 IN MX 0 xyz.mail.protection.outlook.com.
</syntaxhighlight>

=== SPF Eintrag erweitern ===
Es sollte der SPF TXT Eintrag um <code>include:spf.hostsharing.net</code> erweitert werden.

=== Vorbereitungen in HSAdmin ===

Es sollte in HSAdmin auf https://admin.hostsharing.net folgende Dinge angelegt werden:

* die Domain meinedomain.de sollte angelegt werden
* es sollten die Postfächer als Unix Benutzer angelegt werden, und temporäre Passwörter vergeben werden.
* es sollten die E-Mail Adressen, Aliase und Weiterleitungen eingerichtet werden.

Es kann dafür auch dieses Python-Skript benutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/create_and_move_mailboxes.py

=== Ankündigung an die Nutzenden ===

Rechtzeitig muss eine Anleitung und die neuen Zugangsdaten an die Nutzenden weitergegeben werden. Am besten sollten diese Menschen auch über einen anderen Kanal zu erreichen sein, falls es Probleme beim Wechsel auf das neue Postfach gibt.

Folgende Sachen sollten erwähnt werden:

* Umstellung der Zugangsdaten. Siehe auch Screenshots für Thunderbird auf https://www.hostsharing.net/doc/managed-operations-platform/email/
* Möglichkeit von Webmail: https://webmail.hostsharing.net
** dabei sollte beachtet werden:
*** Absender Adresse muss bei der ersten Anmeldung korrigiert werden.
*** evtl. müssen in den Einstellungen die Unterordner abonniert werden, sonst werden sie im Posteingang nicht angezeigt
* Ändern des temporären Passworts
** nach dem erfolgreichen Umzug der Postfächer muss jede Benutzerin das Passwort öndern
** das geschieht auf https://admin.hostsharing.net: anmelden, und dann oben rechts auf den eigenen Benutzernamen klicken

=== Der tatsächliche Umzug ===

Folgende Schritte müssen während des Umzugs in dieser Reihenfolge passieren:

* der MX Eintrag auf der Domain muss geändert werden. Alte MX Einträge müssen entfernt werden, und die 3 Einträge mailin1.hostsharing.net, mailin2.hostsharing.net und mailin3.hostsharing.net müssen eingefügt werden.
* die Passwörter für die alten Postfächer müssen zurückgesetzt werden, es reicht ein Passwort für alle.
* die Inhalte der Postfächer werden über imapcopy in die Postfächer bei Hostsharing kopiert.

=== Nacharbeiten ===

Nach dem erfolgreichen Umzug:

* die Benutzer ändern die Passwörter ihrer neuen Postfächer
* die Benutzer konfigurieren den E-Mail Client mit den neuen Zugangsdaten

Wenn sich der Staub gelegt hat, können danach die Webseite, weitere Anwendungen, und schließlich die gesamte Domain zu Hostsharing umgezogen werden.

Umzug aller Postfächer einer Domain

2026-03-10T15:45:25Z

Tim00: /* TTL heruntersetzen */

== Szenario ==

Das neue Mitglied hat bisher eine Domain und mehrere Postfächer bei einem Anbieter. Nun soll die Domain, die Webseite, die Postfächer und evtl. auch andere Anwendungen, z.B. eine Nextcloud, zu Hostsharing umgezogen werden.

Wir betrachten hier erstmal nur dem Umzug der Postfächer und der E-Mail Adressen. Die weiteren Schritte können im Anschluss durchgeführt werden.

== Durchzuführende Schritte ==

=== TTL heruntersetzen ===
Beim bisherigen Anbieter sollte die TTL auf dem MX Eintrag der Domain auf 600 Sekunden gesetzt werden (10 Minuten).
Das sollte spätestens einen Tag vor dem Umzug erledigt werden, um den Default-Wert der TTL von bis zu 24 Stunden zu vermeiden.
Dadurch wird die Zeitspanne verringert, in der während des Umzugs nach dem Ändern des MX Eintrages sich der neue Mailempfangsserver im DNS herumspricht.

Der aktuelle TTL lässt sich mit diesem Befehl prüfen:

<syntaxhighlight lang=shell>
dig -t MX meinedomain.de
meinedomain.de. 86400 IN MX 0 xyz.mail.protection.outlook.com.
</syntaxhighlight>

=== SPF Eintrag erweitern ===
Es sollte der SPF TXT Eintrag um spf.hostsharing.net erweitert werden.

=== Vorbereitungen in HSAdmin ===

Es sollte in HSAdmin auf https://admin.hostsharing.net folgende Dinge angelegt werden:

* die Domain meinedomain.de sollte angelegt werden
* es sollten die Postfächer als Unix Benutzer angelegt werden, und temporäre Passwörter vergeben werden.
* es sollten die E-Mail Adressen, Aliase und Weiterleitungen eingerichtet werden.

Es kann dafür auch dieses Python-Skript benutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/create_and_move_mailboxes.py

=== Ankündigung an die Nutzenden ===

Rechtzeitig muss eine Anleitung und die neuen Zugangsdaten an die Nutzenden weitergegeben werden. Am besten sollten diese Menschen auch über einen anderen Kanal zu erreichen sein, falls es Probleme beim Wechsel auf das neue Postfach gibt.

Folgende Sachen sollten erwähnt werden:

* Umstellung der Zugangsdaten. Siehe auch Screenshots für Thunderbird auf https://www.hostsharing.net/doc/managed-operations-platform/email/
* Möglichkeit von Webmail: https://webmail.hostsharing.net
** dabei sollte beachtet werden:
*** Absender Adresse muss bei der ersten Anmeldung korrigiert werden.
*** evtl. müssen in den Einstellungen die Unterordner abonniert werden, sonst werden sie im Posteingang nicht angezeigt
* Ändern des temporären Passworts
** nach dem erfolgreichen Umzug der Postfächer muss jede Benutzerin das Passwort öndern
** das geschieht auf https://admin.hostsharing.net: anmelden, und dann oben rechts auf den eigenen Benutzernamen klicken

=== Der tatsächliche Umzug ===

Folgende Schritte müssen während des Umzugs in dieser Reihenfolge passieren:

* der MX Eintrag auf der Domain muss geändert werden. Alte MX Einträge müssen entfernt werden, und die 3 Einträge mailin1.hostsharing.net, mailin2.hostsharing.net und mailin3.hostsharing.net müssen eingefügt werden.
* die Passwörter für die alten Postfächer müssen zurückgesetzt werden, es reicht ein Passwort für alle.
* die Inhalte der Postfächer werden über imapcopy in die Postfächer bei Hostsharing kopiert.

=== Nacharbeiten ===

Nach dem erfolgreichen Umzug:

* die Benutzer ändern die Passwörter ihrer neuen Postfächer
* die Benutzer konfigurieren den E-Mail Client mit den neuen Zugangsdaten

Wenn sich der Staub gelegt hat, können danach die Webseite, weitere Anwendungen, und schließlich die gesamte Domain zu Hostsharing umgezogen werden.

Umzug aller Postfächer einer Domain

2026-03-10T15:44:03Z

Tim00: /* Ankündigung an die Nutzenden */

== Szenario ==

Das neue Mitglied hat bisher eine Domain und mehrere Postfächer bei einem Anbieter. Nun soll die Domain, die Webseite, die Postfächer und evtl. auch andere Anwendungen, z.B. eine Nextcloud, zu Hostsharing umgezogen werden.

Wir betrachten hier erstmal nur dem Umzug der Postfächer und der E-Mail Adressen. Die weiteren Schritte können im Anschluss durchgeführt werden.

== Durchzuführende Schritte ==

=== TTL heruntersetzen ===
Beim bisherigen Anbieter sollte die TTL auf dem MX Eintrag der Domain auf 600 Sekunden gesetzt werden (10 Minuten).
Das sollte spätestens einen Tag vor dem Umzug erledigt werden, um den Default-Wert der TTL von bis zu 24 Stunden zu vermeiden.
Dadurch wird die Zeitspanne verringert, in der während des Umzugs nach dem Ändern des MX Eintrages sich der neue Mailempfangsserver im DNS herumspricht.

Der aktuelle TTL lässt sich mit diesem Befehl prüfen:

<syntaxhighlight lang=shell>
dig -t MX meinedomain.de
meinedomain.de. 86400 IN MX 0 xyz.mail.protection.outlook.com.
</syntaxhighlight>

=== Vorbereitungen in HSAdmin ===

Es sollte in HSAdmin auf https://admin.hostsharing.net folgende Dinge angelegt werden:

* die Domain meinedomain.de sollte angelegt werden
* es sollten die Postfächer als Unix Benutzer angelegt werden, und temporäre Passwörter vergeben werden.
* es sollten die E-Mail Adressen, Aliase und Weiterleitungen eingerichtet werden.

Es kann dafür auch dieses Python-Skript benutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/create_and_move_mailboxes.py

=== Ankündigung an die Nutzenden ===

Rechtzeitig muss eine Anleitung und die neuen Zugangsdaten an die Nutzenden weitergegeben werden. Am besten sollten diese Menschen auch über einen anderen Kanal zu erreichen sein, falls es Probleme beim Wechsel auf das neue Postfach gibt.

Folgende Sachen sollten erwähnt werden:

* Umstellung der Zugangsdaten. Siehe auch Screenshots für Thunderbird auf https://www.hostsharing.net/doc/managed-operations-platform/email/
* Möglichkeit von Webmail: https://webmail.hostsharing.net
** dabei sollte beachtet werden:
*** Absender Adresse muss bei der ersten Anmeldung korrigiert werden.
*** evtl. müssen in den Einstellungen die Unterordner abonniert werden, sonst werden sie im Posteingang nicht angezeigt
* Ändern des temporären Passworts
** nach dem erfolgreichen Umzug der Postfächer muss jede Benutzerin das Passwort öndern
** das geschieht auf https://admin.hostsharing.net: anmelden, und dann oben rechts auf den eigenen Benutzernamen klicken

=== Der tatsächliche Umzug ===

Folgende Schritte müssen während des Umzugs in dieser Reihenfolge passieren:

* der MX Eintrag auf der Domain muss geändert werden. Alte MX Einträge müssen entfernt werden, und die 3 Einträge mailin1.hostsharing.net, mailin2.hostsharing.net und mailin3.hostsharing.net müssen eingefügt werden.
* die Passwörter für die alten Postfächer müssen zurückgesetzt werden, es reicht ein Passwort für alle.
* die Inhalte der Postfächer werden über imapcopy in die Postfächer bei Hostsharing kopiert.

=== Nacharbeiten ===

Nach dem erfolgreichen Umzug:

* die Benutzer ändern die Passwörter ihrer neuen Postfächer
* die Benutzer konfigurieren den E-Mail Client mit den neuen Zugangsdaten

Wenn sich der Staub gelegt hat, können danach die Webseite, weitere Anwendungen, und schließlich die gesamte Domain zu Hostsharing umgezogen werden.

Umzug aller Postfächer einer Domain

2026-03-10T15:39:38Z

Tim00: /* Ankündigung an die Nutzenden */

== Szenario ==

Das neue Mitglied hat bisher eine Domain und mehrere Postfächer bei einem Anbieter. Nun soll die Domain, die Webseite, die Postfächer und evtl. auch andere Anwendungen, z.B. eine Nextcloud, zu Hostsharing umgezogen werden.

Wir betrachten hier erstmal nur dem Umzug der Postfächer und der E-Mail Adressen. Die weiteren Schritte können im Anschluss durchgeführt werden.

== Durchzuführende Schritte ==

=== TTL heruntersetzen ===
Beim bisherigen Anbieter sollte die TTL auf dem MX Eintrag der Domain auf 600 Sekunden gesetzt werden (10 Minuten).
Das sollte spätestens einen Tag vor dem Umzug erledigt werden, um den Default-Wert der TTL von bis zu 24 Stunden zu vermeiden.
Dadurch wird die Zeitspanne verringert, in der während des Umzugs nach dem Ändern des MX Eintrages sich der neue Mailempfangsserver im DNS herumspricht.

Der aktuelle TTL lässt sich mit diesem Befehl prüfen:

<syntaxhighlight lang=shell>
dig -t MX meinedomain.de
meinedomain.de. 86400 IN MX 0 xyz.mail.protection.outlook.com.
</syntaxhighlight>

=== Vorbereitungen in HSAdmin ===

Es sollte in HSAdmin auf https://admin.hostsharing.net folgende Dinge angelegt werden:

* die Domain meinedomain.de sollte angelegt werden
* es sollten die Postfächer als Unix Benutzer angelegt werden, und temporäre Passwörter vergeben werden.
* es sollten die E-Mail Adressen, Aliase und Weiterleitungen eingerichtet werden.

Es kann dafür auch dieses Python-Skript benutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/create_and_move_mailboxes.py

=== Ankündigung an die Nutzenden ===

Rechtzeitig muss eine Anleitung und die neuen Zugangsdaten an die Nutzenden weitergegeben werden. Am besten sollten diese Menschen auch über einen anderen Kanal zu erreichen sein, falls es Probleme beim Wechsel auf das neue Postfach gibt.

Folgende Sachen sollten erwähnt werden:

* Umstellung der Zugangsdaten. Siehe auch Screenshots für Thunderbird auf https://www.hostsharing.net/doc/managed-operations-platform/email/
* Möglichkeit von Webmail: https://webmail.hostsharing.net
** dabei sollte beachtet werden:
*** Absender Adresse muss bei der ersten Anmeldung korrigiert werden.
*** evtl. müssen in den Einstellungen die Unterordner abonniert werden, sonst werden sie im Posteingang nicht angezeigt
* Ändern des temporären Passworts
** nach dem erfolgreichen Umzug der Postfächer muss jede Benutzerin das Passwort öndern
** das geschieht auf https://admin.hostsharing.net: anmelden, und dann oben rechts auf den eigenen Benutzernamen klicken

Umzug aller Postfächer einer Domain

2026-03-10T15:39:17Z

Tim00: /* Ankündigung an die Nutzenden */

== Szenario ==

Das neue Mitglied hat bisher eine Domain und mehrere Postfächer bei einem Anbieter. Nun soll die Domain, die Webseite, die Postfächer und evtl. auch andere Anwendungen, z.B. eine Nextcloud, zu Hostsharing umgezogen werden.

Wir betrachten hier erstmal nur dem Umzug der Postfächer und der E-Mail Adressen. Die weiteren Schritte können im Anschluss durchgeführt werden.

== Durchzuführende Schritte ==

=== TTL heruntersetzen ===
Beim bisherigen Anbieter sollte die TTL auf dem MX Eintrag der Domain auf 600 Sekunden gesetzt werden (10 Minuten).
Das sollte spätestens einen Tag vor dem Umzug erledigt werden, um den Default-Wert der TTL von bis zu 24 Stunden zu vermeiden.
Dadurch wird die Zeitspanne verringert, in der während des Umzugs nach dem Ändern des MX Eintrages sich der neue Mailempfangsserver im DNS herumspricht.

Der aktuelle TTL lässt sich mit diesem Befehl prüfen:

<syntaxhighlight lang=shell>
dig -t MX meinedomain.de
meinedomain.de. 86400 IN MX 0 xyz.mail.protection.outlook.com.
</syntaxhighlight>

=== Vorbereitungen in HSAdmin ===

Es sollte in HSAdmin auf https://admin.hostsharing.net folgende Dinge angelegt werden:

* die Domain meinedomain.de sollte angelegt werden
* es sollten die Postfächer als Unix Benutzer angelegt werden, und temporäre Passwörter vergeben werden.
* es sollten die E-Mail Adressen, Aliase und Weiterleitungen eingerichtet werden.

Es kann dafür auch dieses Python-Skript benutzt werden: https://codeberg.org/tpokorra/hostsharing-scripts/src/branch/main/create_and_move_mailboxes.py

=== Ankündigung an die Nutzenden ===

Rechtzeitig muss eine Anleitung und die neuen Zugangsdaten an die Nutzenden weitergegeben werden. Am besten sollten diese Menschen auch über einen anderen Kanal zu erreichen sein, falls es Probleme beim Wechsel auf das neue Postfach gibt.

Folgende Sachen sollten erwähnt werden:

* Umstellung der Zugangsdaten. Siehe auch Screenshots für Thunderbird auf https://www.hostsharing.net/doc/managed-operations-platform/email/
* Möglichkeit von Webmail: https://webmail.hostsharing.net
* dabei sollte beachtet werden:
* Absender Adresse muss bei der ersten Anmeldung korrigiert werden.
* evtl. müssen in den Einstellungen die Unterordner abonniert werden, sonst werden sie im Posteingang nicht angezeigt
* Ändern des temporären Passworts
* nach dem erfolgreichen Umzug der Postfächer muss jede Benutzerin das Passwort öndern
* das geschieht auf https://admin.hostsharing.net: anmelden, und dann oben rechts auf den eigenen Benutzernamen klicken

Umzug aller Postfächer einer Domain

2026-03-10T15:00:12Z

Tim00: Die Seite wurde neu angelegt: „== Szenario == Das neue Mitglied hat bisher eine Domain und mehrere Postfächer bei einem Anbieter. Nun soll die Domain, die Webseite, die Postfächer und evtl. auch andere Anwendungen, z.B. eine Nextcloud, zu Hostsharing umgezogen werden. Wir betrachten hier erstmal nur dem Umzug der Postfächer und der E-Mail Adressen. Die weiteren Schritte können im Anschluss durchgeführt werden. == Durchzuführende Schritte == === TTL heruntersetzen === Beim bis…“

Domains

2026-03-10T14:48:03Z

Tim00: /* Aktionen */

{{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]]
* Eine Domain kündigen: [[Domainkündigung]]
* Verwalten von Domains, Subdomains, Eigentümer, Nameserver: [[Domainverwaltung]]
* Umzug von allen Postfächern einer Domain von einem anderen Anbieter zu Hostsharing: [[Umzug aller Postfächer einer Domain]]

= Weiterführende Links =

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

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