Hostsharing Wiki - Benutzerbeiträge [de]

Container

2025-09-10T17:58:32Z

Hsh-marcsandlus:

== Übersicht ==

Es gibt die Möglichkeit, einen Container Server mit Docker oder mit Podman zu buchen.

Dies ist eine Managed Umgebung, also ohne Root-Rechte, wo Docker bzw. Podman rootless ausgeführt werden.

Falls vom Installationsskript einer Anwendung Root-Rechte erforderlich sind, kann entweder versucht werden, dies anzupassen, oder es kann ein Cloud Server gebucht werden, wo der Benutzer Root-Rechte hat.

== Erste Schritte ==

Bei der Bestellung des Container Servers sollte direkt der Public SSH Key mitgegeben werden, am besten bereits nach dem Ed25519-Standard, siehe auch [https://www.heise.de/tipps-tricks/SSH-Key-erstellen-so-geht-s-4400280.html].

Der Zugriff erfolgt über den Benutzer tallyman über SSH auf den Container Server.

<syntaxhighlight lang=shell>
ssh tallyman@vm4xxx.hostsharing.net
</syntaxhighlight>

Um einen "Hello World" Docker Container zu starten:

<syntaxhighlight lang=shell>
tallyman@vm4xxx:~$ docker run hello-world
</syntaxhighlight>

Entsprechend sieht der Befehl für Podman aus:

<syntaxhighlight lang=shell>
tallyman@vm4xxx:~$ podman run hello-world
</syntaxhighlight>

=== Hilfreiche Befehle für Docker ===

<syntaxhighlight lang=shell>
# in einem Ordner ausführen, wo eine Datei mit dem Namen docker-compose.yml liegt, um die Umgebung zu bauen und zu starten:
docker compose up --detach

# zeige alle laufenden Container
docker ps -a

# zeige die Logs eines Containers
docker logs mein-container

# wechsle in eine Shell im Container
docker exec -t -i mein-container /bin/sh

# Images aktualisieren
docker compose pull

# Containerumgebung stoppen und löschen
docker compose down
</syntaxhighlight>

=== Hilfreiche Befehle für Podman ===

TODO

== Beispiel Anwendungen ==
=== Container Umgebung mit Nginx und Certbot ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/nginx-certbot
=== Container Umgebung mit Caddy und Python Anwendung ===
TODO siehe https://codeberg.org/tpokorra/hs.compose/src/branch/main/caddy-test

Prozessmanagement mit systemd im Userspace

2024-11-27T08:12:51Z

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

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

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

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

== Eigene Serverdienste mit systemd ==

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

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

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

Die Ausgabe sollte sein:

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

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

=== systemd Units ===

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

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

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

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

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

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

Folgende Eigenschaften sind einstellbar:

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

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

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

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

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

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

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

=== systemd Unit starten und stoppen ===

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

==== Reload ====

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

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

==== Start und Stopp ====

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

bzw.

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

sind die Kommandos zum Starten und Beenden des Dienstes.

==== Enable und Disable ====

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

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

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

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

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

==== Status ====

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

oder

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

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

== Zeitgesteuerte Ausführung mit systemd ==

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

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

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

[Unit]
Description=My Cleanup Service

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

=== Testen ===

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

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

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

[Unit]
Description=Daily My Cleanup Timer

[Timer]
OnCalendar=daily
RandomizedDelaySec=3600

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

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

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

Eine ausführliche Dokumentation der Direktiven findet sich hier:

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

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

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

== RAM Kontingent eines Webspace ==

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

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

ansehen.

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

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

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

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

= weiterführende Links =

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

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

Umstellung von Daemon-Diensten auf systemd

2024-11-27T08:05:51Z

Hsh-marcsandlus:

== Anlass dieser Anleitung ==

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

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

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

== Praktische Umstellung ==

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

=== cronjob ===

TODO: auf Timer

=== monit ===

TODO: Beispiel

=== supervisor ===

TODO: Beispiel

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

TODO: siehe [[Systemd_im_Userspace#RAM_Kontingent_eines_Webspace]]

----
[[Kategorie:Systemd]]

BBB Meeting

2021-09-17T07:37:24Z

Hsh-marcsandlus:

= BBB Meeting =

'''Diese Seite befindet sich gerade im Aufbau und ist noch nicht fertiggestellt'''

Dies ist eine kleine Hilfeseite für das Angebot [https://www.hostsharing.net/bigbluebutton/bbb-meeting/ BBB Meeting] der [https://www.hostsharing.net/ Hostsharing eG].

== Einstiegsseite für Mitglieder ==

Auf der Seite [https://meeting.hs.coop/ meeting.hs.coop] kann sich jedes Mitglied der Hostsharing eG mit seinem Mitgliedsaccount (besteht aus drei Zeichen, i.A. Buchstaben, z.B. "mos") einloggen.

Nach dem Einloggen können beliebig viele Konferenzräume erstellt werden.

Jeder Raum besitzt einen zufälligen, schwer zu erratenden Link, z.B. [https://meeting.hs.coop/b/mos-cpy-mfv-xyz https://meeting.hs.coop/b/mos-cpy-mfv-xyz].

Dieser Link muss dann den weiteren Teilnehmern der Konferenz bekannt gemacht werden, z.B. per E-Mail oder durch Veröffentlichung auf einer Webseite.

== Zugriffseinstellungen für Räume ==

Es gibt mehrere Einstellungen, die den Zugang zu einem Raum regeln:

* '''Optionaler Raumzugangscode'''
** ist standardmäßig nicht gesetzt, d.h. jeder Teilnehmer, der den Link des Raumes aufruft, kann der Konferenz beitreten (sofern diese begonnen hat oder die Einstellung "Jeder Teilnehmer kann die Konferenz starten" aktiv ist)
** Teilnehmer können nur durch Eingabe dieses sechsstelligen Codes den Raum betreten
* '''Optionaler Code für Moderatoren'''
** ist standardmäßig nicht gesetzt, d.h. die Teilnehmer haben i.A. keine Moderatorrechte
** Teilnehmer können durch Eingabe dieses Codes den Raum als Moderator betreten
** Dieser Teilnehmer/Moderator startet damit auch ggfs. die Konferenz
** Mit dieser Option kann das Mitglied auswählten Dritten ermöglichen, eine Konferenz (als Moderator) zu starten. Es muss nur das Moderatorpasswort weitergegeben werden, nicht die Zugangsdaten zum Mitgliedsaccount
* '''Freigabe durch Moderator, bevor der Raum betreten werden kann'''
** standardmäßig betritt jeder Teilnehmer, der den Link des Raumes aufruft, die Konferenz
** durch Einschalten dieser Option betreten Teilnehmer nicht mehr sofort die Konferenz, sondern müssen auf die Freigabe durch einen Moderator warten
** Vorteil: zusätzliche Kontrolle, wer teilnimmt
* '''Jeder Teilnehmer kann die Konferenz starten'''
** ist standardmäßig nicht gesetzt, d.h. nur Moderatoren können eine Konferenz starten
** durch Einschalten dieser Option kann jeder Teilnehmer, der den Link aufruft, die Konferenz starten. ** Warnung: Jeder, der den Link zu diesem Raum kennt, kann eine Konferenz starten, die dem Mitglied in Rechnung gestellt wird!
** Möchte das Mitglied ausgewählten Teilnehmern ermöglichen, eine Konferenz zu starten, empfiehlt sich eher das Setzen eines "Codes für Moderatoren" (siehe oben)
* '''Alle Teilnehmer nehmen als Moderator teil'''
** standardmäßig nicht gesetzt
** die Option ist selbsterklärend

== Weitere Dokumentation zu BigBlueButton ==

Unser Mitglied Ferdinand Soethe hat ein sehr nützliches [https://bbb-handbuch.hostsharing.net/Praxishandbuch%20BBB.htm Praxishandbuch zu BigBlueButton] geschrieben.

[[Category:BigBlueButton]]

BBB Meeting

2021-09-16T22:24:06Z

Hsh-marcsandlus:

= BBB Meeting =

'''Diese Seite befindet sich gerade im Aufbau und ist noch nicht fertiggestellt'''

Dies ist eine kleine Hilfeseite für das Angebot [https://www.hostsharing.net/bigbluebutton/bbb-meeting/ BBB Meeting] der [https://www.hostsharing.net/ Hostsharing eG].

== Einstiegsseite für Mitglieder ==

Auf der Seite [https://meeting.hs.coop/ meeting.hs.coop] kann sich jedes Mitglied der Hostsharing eG mit seinem Mitgliedsaccount (besteht aus drei Zeichen, i.A. Buchstaben, z.B. "mos") einloggen.

Nach dem Einloggen können beliebig viele Konferenzräume erstellt werden.

Jeder Raum besitzt einen zufälligen, schwer zu erratenden Link, z.B. [https://meeting.hs.coop/b/mos-cpy-mfv-xyz https://meeting.hs.coop/b/mos-cpy-mfv-xyz].

Dieser Link muss dann den weiteren Teilnehmern der Konferenz bekannt gemacht werden, z.B. per E-Mail oder durch Veröffentlichung auf einer Webseite.

== Zugriffseinstellungen für Räume ==

Es gibt mehrere Einstellungen, die den Zugang zu einem Raum regeln:

* Optionaler Raumzugangscode
** ist standardmäßig nicht gesetzt, d.h. jeder Teilnehmer, der den Link des Raumes aufruft, die Konferenz
** Teilnehmer können nur durch Eingabe dieses sechsstelligen Codes den Raum betreten
* Optionaler Code für Moderatoren
** ist standardmäßig nicht gesetzt, d.h. die Teilnehmer haben i.A. keine Moderatorrechte
** Teilnehmer können durch Eingabe dieses Codes den Raum als Moderator betreten
** Mit dieser Option kann das Mitglied auswählten Dritten ermöglichen, eine Konferenz (als Moderator) zu starten
* Freigabe durch Moderator, bevor der Raum betreten werden kann
** standardmäßig betritt jeder Teilnehmer, der den Link des Raumes aufruft, die Konferenz
** durch Einschalten dieser Option betreten Teilnehmer nicht mehr sofort die Konferenz, sondern müssen auf die Freigabe durch einen Moderator warten
** Vorteil: zusätzliche Kontrolle, wer teilnehmen soll
* Jeder Teilnehmer kann die Konferenz starten
** ist standardmäßig nicht gesetzt, d.h. nur Moderatoren können eine Konferenz starten
** durch Einschalten dieser Option kann jeder Teilnehmer, der den Link aufruft, die Konferenz starten. ** Warnung: Jeder, der den Link zu diesem Raum kennt, kann eine Konferenz starten, die dem Mitglied in Rechnung gestellt wird!
** Möchte das Mitglied ausgewählten Teilnehmern ermöglichen, eine Konferenz zu starten, empfiehlt sich eher das Setzen eines "Codes für Moderatoren" (siehe oben)
* Alle Teilnehmer nehmen als Moderator teil
** standardmäßig nicht gesetzt
** die Option ist selbsterklärend

== Weitere Dokumentation zu BigBlueButton ==

Unser Mitglied Ferdinand Soethe hat ein sehr nützliches [https://bbb-handbuch.hostsharing.net/Praxishandbuch%20BBB.htm Praxishandbuch zu BigBlueButton] geschrieben.

[[Category:BigBlueButton]]

BBB Meeting

2021-09-16T09:50:52Z

Hsh-marcsandlus:

== BBB Meeting ==

'''Diese Seite befindet sich gerade im Aufbau und ist noch nicht fertiggestellt'''

Eine kleine Hilfeseite für das Angebot [https://www.hostsharing.net/bigbluebutton/bbb-meeting/ BBB Meeting] der [https://www.hostsharing.net/ Hostsharing eG].

=== Einstiegsseite für Mitglieder ===

Auf der Seite [https://meeting.hs.coop/ meeting.hs.coop] kann sich jedes Mitglied der Hostsharing eG mit seinem Mitgliedsaccount (besteht nur aus drei Zeichen, i.A. Buchstaben, z.B. "mos") einloggen.

Nach dem Einloggen können beliebig viele Konferenzräume erstellt werde.

Jeder Raum besitzt einen zufälligen, schwer zu erratenden Link, z.B. [https://meeting.hs.coop/b/mos-cpy-mfv-xyz https://meeting.hs.coop/b/mos-cpy-mfv-xyz]

Dieser Link muss dann den weiteren Teilnehmern der Konferenz weiter gegeben werden, z.B. per E-Mail.

=== Zugriffseinstellungen für Räume ===

Es gibt mehrere Einstellungen, die den Zugang zu einem Raum regeln:

* Optionaler Raumzugangscode
** ist standardmäßig nicht gesetzt
** Teilnehmer können nur durch Eingabe dieses sechsstelligen Codes den Raum betreten
* Optionaler Code für Moderatoren
** ist standardmäßig nicht gesetzt
** Teilnehmer können durch Eingabe dieses Codes den Raum als Moderator betreten
** Mit dieser Option kann das Mitglied auswählten Dritten ermöglichen, eine Konferenz (als Moderator) zu starten
* Freigabe durch Moderator, bevor der Raum betreten werden kann
** standardmäßig betritt jeder Teilnehmer, der den Link des Raumes aufruft, die Konferenz
** durch Einschalten dieser Option betreten Teilnehmer nicht mehr sofort die Konferenz, sondern müssen auf die Freigabe durch einen Moderator warten
** Vorteil: zusätzliche Kontrolle, wer teilnehmen soll
* Jeder Teilnehmer kann die Konferenz starten
** ist standardmäßig nicht gesetzt, d.h. nur Moderatoren können eine Konferenz starten
** durch Einschalten dieser Option kann jeder Teilnehmer, der den Link aufruft, die Konferenz starten. ** Warnung: Jeder, der den Link zu diesem Raum kennt, kann eine Konferenz starten, die dem Mitglied in Rechnung gestellt wird!
** Möchte das Mitglied ausgewählten Teilnehmern ermöglichen, eine Konferenz zu starten, empfiehlt sich eher das Setzen eines "Codes für Moderatoren" (siehe oben)
* Alle Teilnehmer nehmen als Moderator teil
** standardmäßig nicht gesetzt
** die Option ist selbsterklärend

[[Category:BigBlueButton]]

BBB Meeting

2021-09-16T09:49:28Z

Hsh-marcsandlus:

== BBB Meeting ==

'''Diese Seite befindet sich gerade im Aufbau und ist noch nicht fertiggestellt'''

Eine kleine Hilfeseite für das Angebot [https://www.hostsharing.net/bigbluebutton/bbb-meeting/ BBB Meeting] der [https://www.hostsharing.net/ Hostsharing eG].

=== Einstiegsseite für Mitglieder ===

Auf der Seite [https://meeting.hs.coop/ meeting.hs.coop] kann sich jedes Mitglied der Hostsharing eG mit seinem Mitgliedsaccount (besteht nur aus drei Zeichen, i.A. Buchstaben, z.B. "mos") einloggen.

Nach dem Einloggen können beliebig viele Konferenzräume erstellt werde.

Jeder Raum besitzt einen zufälligen, schwer zu erratenden Link, z.B. [https://meeting.hs.coop/b/mos-cpy-mfv-xyz https://meeting.hs.coop/b/mos-cpy-mfv-xyz]

Dieser Link muss dann den weiteren Teilnehmern der Konferenz weiter gegeben werden, z.B. per E-Mail.

=== Zugriffseinstellungen für Räume ===

Es gibt mehrere Einstellungen, die den Zugang zu einem Raum regeln:

* Optionaler Raumzugangscode
** ist standardmäßig nicht gesetzt
** Teilnehmer können nur durch Eingabe dieses sechsstelligen Codes den Raum betreten
* Optionaler Code für Moderatoren
** ist standardmäßig nicht gesetzt
** Teilnehmer können durch Eingabe dieses Codes den Raum als Moderator betreten
* Freigabe durch Moderator, bevor der Raum betreten werden kann
** standardmäßig betritt jeder Teilnehmer, der den Link des Raumes aufruft, die Konferenz
** durch Einschalten dieser Option betreten Teilnehmer nicht mehr sofort die Konferenz, sondern müssen auf die Freigabe durch einen Moderator warten
** Vorteil: zusätzliche Kontrolle, wer teilnehmen soll
* Jeder Teilnehmer kann die Konferenz starten
** ist standardmäßig nicht gesetzt, d.h. nur Moderatoren können eine Konferenz starten
** durch Einschalten dieser Option kann jeder Teilnehmer, der den Link aufruft, die Konferenz starten. ** Warnung: Jeder, der den Link zu diesem Raum kennt, kann eine Konferenz starten, die dem Mitglied in Rechnung gestellt wird!
** Möchte das Mitglied ausgewählten Teilnehmern ermöglichen, eine Konferenz zu starten, empfiehlt sich eher das Setzen eines "Codes für Moderatoren" (siehe oben)
* Alle Teilnehmer nehmen als Moderator teil
** standardmäßig nicht gesetzt
** die Option ist selbsterklärend

[[Category:BigBlueButton]]

BBB Meeting

2021-09-16T09:40:55Z

Hsh-marcsandlus: Die Seite wurde neu angelegt: „== BBB Meeting == '''Diese Seite befindet sich gerade im Aufbau und ist noch nicht fertiggestellt''' Eine kleine Hilfeseite für das Angebot [https://www.hos…“

== BBB Meeting ==

'''Diese Seite befindet sich gerade im Aufbau und ist noch nicht fertiggestellt'''

Eine kleine Hilfeseite für das Angebot [https://www.hostsharing.net/bigbluebutton/bbb-meeting/ BBB Meeting] der [https://www.hostsharing.net/ Hostsharing eG].

=== Einstiegsseite für Mitglieder ===

Auf der Seite [https://meeting.hs.coop/ meeting.hs.coop] kann sich jedes Mitglied der Hostsharing eG mit seinem Mitgliedsaccount (besteht nur aus drei Zeichen, i.A. Buchstaben, z.B. "mos") einloggen.

Nach dem Einloggen können beliebig viele Konferenzräume erstellt werde.

Jeder Raum besitzt einen zufälligen, schwer zu erratenden Link, z.B. [https://meeting.hs.coop/b/mos-cpy-mfv-xyz https://meeting.hs.coop/b/mos-cpy-mfv-xyz]

Dieser Link muss dann den weiteren Teilnehmern der Konferenz weiter gegeben werden, z.B. per E-Mail.

=== Zugriffseinstellungen für Räume ===

Es gibt mehrere Einstellungen, die den Zugang zu einem Raum regeln:

* Optionaler Raumzugangscode
** ist standardmäßig nicht gesetzt
** Teilnehmer können nur durch Eingabe dieses sechsstelligen Codes den Raum betreten
* Optionaler Code für Moderatoren
** ist standardmäßig nicht gesetzt
** Teilnehmer können durch Eingabe dieses Codes den Raum als Moderator betreten
* Freigabe durch Moderator, bevor der Raum betreten werden kann
** standardmäßig betritt jeder Teilnehmer, der den Link des Raumes aufruft, die Konferenz
** durch Einschalten dieser Option betreten Teilnehmer nicht mehr sofort die Konferenz, sondern müssen auf die Freigabe durch einen Moderator warten
** Vorteil: zusätzliche Kontrolle, wer teilnehmen soll
* Jeder Teilnehmer kann die Konferenz starten
** ist standardmäßig nicht gesetzt, d.h. nur das Mitglied kann eine Konferenz starten
**
* Alle Teilnehmer nehmen als Moderator teil

[[Category:BigBlueButton]]

Kategorie:BigBlueButton

2021-09-16T09:12:05Z

Hsh-marcsandlus: Die Seite wurde neu angelegt: „Diese Kategorie enthält alle Seiten zum Thema BigBlueButton bei der Hostsharing eG“

Diese Kategorie enthält alle Seiten zum Thema BigBlueButton bei der Hostsharing eG

TLS Zertifikat mit LEGO

2021-07-28T22:47:46Z

Hsh-marcsandlus:

= TLS Zertifikat mit LEGO =

Für den zentralen Apache Webserver werden bei Hostsharing automatisch TLS Zertifikate über den Dienst "Lets Encrypt" erzeugt und verlängert. Das wird über die Domain-Option "letsencrypt" gesteuert.

Teilweise will man aber eigene Serverdienste betreiben, die nicht über HTTP hinter dem Apache-Proxy erreichbar sind. Beispiele dafür sind ein eigener XMPP Server oder ein Mumble Server. Für diese Server können die Nutzer:innen der Hostsharing Plattform sehr leicht TLS Zertifikate erzeugen, indem sie den zentral installierten LEGO-Bot nutzen.

== Einrichtung ==

Zunächst muss eine Domain vorhanden sein, auf die das Zertifikat ausgestellt werden soll und die im Webspace über HTTP erreichbar ist.

Ich nutze hier den Service-User "xyz00-mumble" als Beispiel. Bei diesem User sei die Domain "mumble.hs-example.de" aufgeschaltet.

Dann lösche ich bei der Domain die HTTP-Weiterleitungen und die www-Subdomain:

rm -rf ~/doms/mumble.hs-example.de/subs/www \
~/doms/mumble.hs-example.de/subs-ssl/www \
~/doms/mumble.hs-example.de/htdocs/.htaccess \
~/doms/mumble.hs-example.de/htdocs-ssl/.htaccess

Das erste Zertifikat wird mit dem folgenden Befehl erzeugt:

/usr/bin/lego -d mumble.hs-example.de -a \
--email webmaster@mumble.hs-example.de -k ec256 \
--http.webroot $HOME/doms/mumble.hs-example.de/htdocs \
--http run

Bei der erfolgreichen Ausführung diese Befehls wurde ein verstecktes Verzeichnis ".lego" angelegt. In diesem Verzeichnis befinden sich die Daten zum neu angelegten Letsencrypt-Account und das Zertifikat mit dem zugehörigen private key.

Die Daten des Zertifikates kann man wie folgt auslesen:

openssl x509 -in .lego/certificates/mumble.hs-example.de.crt -noout -text

== regelmäßige Verlängerung ==

Für die automatische Verlängerung des Zertifikats können wir einen Cronjob aufsetzen, der zum Beispiel täglich oder wöchentlich läuft:

$ cat bin/lego-renew
#!/bin/bash
HOME=/home/pacs/xyz00/users/mumble
/usr/bin/lego -d mumble.hs-example.de -a \
--email webmaster@mumble.hs-example.de -k ec256 \
--http.webroot $HOME/doms/mumble.hs-example.de/htdocs \
--http renew

Die Ausführung des Skriptes wird über einen Cronjob gesteuert:

$ crontab -l
# m h dom mon dow command
HOME=/home/pacs/xyz00/users/mumble
MAILTO=webmaster@mumble.hs-example.de

# Renew mumble cert
34 4 * * 2 $HOME/bin/lego-renew

TLS Zertifikat mit LEGO

2021-07-28T22:45:05Z

Hsh-marcsandlus:

= TLS Zertifikat mit LEGO =

Für den zentralen Apache Webserver werden bei Hostsharing automatisch TLS Zertifikate über den Dienst "Lets Encrypt" erzeugt und verlängert. Das wird über die Domain-Option "letsencrypt" gesteuert.

Teilweise will man aber eigene Serverdienste betreiben, die nicht über HTTP hinter dem Apache-Proxy erreichbar sind. Beispiele dafür sind ein eigener XMPP Server oder ein Mumble Server. Für diese Server können die Nutzer:innen der Hostsharing Plattform sehr leicht TLS Zertifikate erzeugen, indem sie den zentral installierten LEGO-Bot nutzen.

== Einrichtung ==

Zunächst muss eine Domain vorhanden sein, auf die das Zertifikat ausgestellt werden soll und die im Webspace über HTTP erreichbar ist.

Ich nutze hier den Service-User "xyz00-mumble" als Beispiel. Bei diesem User sei die Domain "mumble.hs-example.de" aufgeschaltet.

Dann lösche ich bei der Domain die HTTP-Weiterleitungen und die www-Subdomain:

rm -rf ~/doms/mumble.hs-example.de/subs/www \
~/doms/mumble.hs-example.de/subs-ssl/www \
~/doms/mumble.hs-example.de/htdocs/.htaccess \
~/doms/mumble.hs-example.de/htdocs-ssl/.htaccess

Das erste Zertifikat wird mit dem folgenden Befehl erzeugt:

/usr/bin/lego -d mumble.hs-example.de -a \
--email webmaster@mumble.hs-example.de -k ec256 \
--http.webroot $HOME/doms/mumble.hs-example.de/htdocs \
--http run

Bei der erfolgreichen Ausführung diese Befehls wurde ein verstecktes Verzeichnis ".lego" angelegt. in diesem Verzeichnis befinden sich die Daten zum neu angelegten Letsencrypt-Account und das Zertifikat mit dem zugehörigen private key.

Die Daten des Zertifikates kann man wie folgt auslesen:

openssl x509 -in .lego/certificates/mumble.hs-example.de.crt -noout -text

== regelmäßige Verlängerung ==

Für die automatische Verlängerung des Zertifikats können wir einen Cronjob aufsetzen, der zum Beispiel täglich oder wöchentlich läuft:

$ cat bin/lego-renew
#!/bin/bash
HOME=/home/pacs/xyz00/users/mumble
/usr/bin/lego -d mumble.hs-example.de -a \
--email webmaster@mumble.hs-example.de -k ec256 \
--http.webroot $HOME/doms/mumble.hs-example.de/htdocs \
--http renew

Die Ausführung des Skriptes wird über einen Cronjob gesteuert:

$ crontab -l
# m h dom mon dow command
HOME=/home/pacs/xyz00/users/mumble
MAILTO=webmaster@mumble.hs-example.de

# Renew mumble cert
34 4 * * 2 $HOME/bin/lego-renew

Benutzer:Hsh-marcsandlus/BigBlueButton

2020-10-29T11:48:08Z

Hsh-marcsandlus:

Hier soll eine Sammlung von Tipps & Tricks zu BigBlueButton bei Hostsharing entstehen, ab einem gewissen Reifegrad der Seite wird sie ins Haupt-Wiki verschoben.

== Problemlösungen ==

Problem: Schlechtes Nutzererlebnis durch abgehacktes Audio

Die Bandbreite des Internetanschlusses auf Teilnehmer*innenseite ist häufig der "Flaschenhals", der zu einem schlechten Nutzererlebnis bei BigBlueButton führt. Aus verschiedenen Gründen kann der Audiostrom dann nicht mehr flüssig gesendet werden, oder die Audioströme der anderen Nutzer*innen nicht mehr flüssig empfangen werden.
* Teilnehmer*innen-Maßnahmen
*# Dringende Empfehlung: Computer durch '''LAN-Kabel''' mit Internet verbinden (statt per WLAN)
*# Falls LAN-Kabel keine Alternative ist, sollte die Teilnehmer*in sich '''nah am WLAN-Router''' mit direktem Sichtkontakt (keine Schränke, Mauern) aufhalten, um eine bessere Verbindung zu erhalten
*# '''Mobilfunk'''-Internetverbindung ist nicht zu empfehlen
*# Der Internetanschluss kann durch '''andere Aktivitäten''' (parallele Up-/Downloads) und Nutzer ausgelastet sein (z.B. durch IP-Fernsehen). Diese nach Möglichkeit unterlassen oder verringern
*# '''Telefoneinwahl''': Falls beim BBB die Telefoneinwahl konfiguriert ist, kann der Internetanschluss damit umgangen werden
*# '''Headset statt Lautsprecher''': Verwendet eine Teilnehmer*in statt eines Kopfhörers einen Lautsprecher, kann es passieren, dass ein eingeschaltetes Mikrofon die Lautsprecherausgabe wieder aufnimmt und zurück in den Konferenzraum sendet. Solche Rückkoppelungen lassen sich nicht immer technisch erfolgreich unterdrücken. Daher besser Kopfhörer oder direkt ein Headset verwenden.
*#* Auch bei Kopfhörern/Headsets gilt ebenfalls, dass eine Verbindung per Kabel besser als eine per Funk (z.B. Bluetooth) ist, da Funkverbindungen immer Verzögerungen besitzen
*# Die '''eigene Anzeige von Kameras''' anderer Teilnehmer*innen abschalten, um Internetbandbreite zu sparen (Datensparsamkeitseinstellungen im Menü oben rechts in einem BBB-Raum)
* Moderations-Maßnahmen
*# Den Präsentator*innen eine gute Internetverbindung nahelegen, sie sollten die Teilnehmer*innen-Maßnahmen von oben beherzigen
*# Je '''weniger Webcams eingeschaltet''' sind, desto besser. Bei größeren Konferenzen (schon ab 10 Teilnehmern) ist immer davon auszugehen, dass dort jemand mit einer schlechten Internetverbindung teilnimmt. Es sollte daher vorher sichergestellt sein, dass dies nicht ausgerechnet die Präsentator*in ist. Schlechte Internetverbindungen der Teilnehmer*innen haben bereits Probleme mit wenigen aktiven Kameras. Daher sollte die Gesamtanzahl der Kameras immer niedrig bleiben.
* Server-Maßnahmen Die Performance des BBB-Servers war bisher bei Hostsharing kein Problem, alle Server waren gut auf die geplanten Konferenzen eingestellt. Bei großen Konferenzen machen einem BBB-Server nur die Momente zu schaffen, in denen mehrere Kameras gleichzeitig eingeschaltet werden. Das ist leicht nachvollziehbar, bei z.B. 100 Teilnehmer*innen müssen von einem Moment auf den nächsten 100 Kamerabilder verteilt werden. Für ein paar Sekunden kann es da zu einer Überlastung des Servers und einer Verzögerung kommen. Trotzdem gibt es Möglichkeiten, den Server anzupassen, dass es auf Teilnehmer*innenseite nicht so schnell zur Überauslastung der Internetverbindung kommt:
*# Eine datensparsameres Kameraprofil zur Vorauswahl den Teilnehmer*innen präsentieren (siehe unten)
*# Die Bitraten der Kameraprofile reduzieren (s.u.)
*# Die Bitrate von Bildschirmpräsentationen reduzieren (s.u.)

== Anpassungsmöglichkeiten ==

Die beste englischsprachige Anlaufstelle ist https://docs.bigbluebutton.org/2.2/customize.html

=== Bandbreite auf Teilnehmerseite reduzieren ===

'''Teilnehmer*innen-Lösungen'''
# Ein datensparsameres Kameraprofil auswählen (z.B. "Niedrige Qualität")
# Die eigene Anzeige der Kameras der anderen Teilnehmer*innen abschalten, im Menü oben rechts im BBB-Raum
# Die Teilnehmer*innen-Maßnahmen beim Problem "Schlechtes Nutzererlebnis durch abgehacktes Audio" beachten

'''Server-Lösung 1''': In der Auswahlbox für Kameraprofile, die jeder Teilnehmer vor dem Einschalten seiner Webcam sieht, ein Profil mit kleinerer Kameraauflösung vorauswählen. Dies bewirkt, dass sich Teilnehmer bewusst für eine bessere Kameraqualität entscheiden müssen, dadurch die durchschnittlichen Kameraqualitäten sinken und somit jeder Teilnehmer (auch die ohne eingeschaltete Webcam) mehr Bandbreite ihres Internetanschlusses zur Verfügung haben.

Datei <code>/usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml</code> per Hand anpassen oder

Updaterobuste Lösung: in der Datei <code>/etc/bigbluebutton/bbb-conf/apply-config.sh</code> einfügen: 
<nowiki>echo " - Setting camera defaults"
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==low).default' true
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==medium).default' false
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==high).default' false
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==hd).default' false
</nowiki>
Dies wählt als voreingestelltes Kameraprofil ''low'' aus.

'''Server-Lösung 2''': Die Bitraten aller Kameraprofile reduzieren

Datei <code>/usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml</code> per Hand anpassen oder

Updaterobuste Lösung: in der Datei <code>/etc/bigbluebutton/bbb-conf/apply-config.sh</code> einfügen: 
<nowiki>echo " - Setting camera defaults"
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==low).bitrate' 50
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==medium).bitrate' 100
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==high).bitrate' 200
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==hd).bitrate' 300
</nowiki>
Dies setzt die Bitraten der vier Kameraprofile auf die gegebenen Werte.
Die Werkseinstellungen dieser Werte sind übrigens: 100, 200, 500, 800

Benutzer:Hsh-marcsandlus/BigBlueButton

2020-10-29T11:40:05Z

Hsh-marcsandlus:

Hier soll eine Sammlung von Tipps & Tricks zu BigBlueButton bei Hostsharing entstehen, ab einem gewissen Reifegrad der Seite wird sie ins Haupt-Wiki verschoben.

== Problemlösungen ==

Problem: Schlechtes Nutzererlebnis durch abgehacktes Audio

# Die Bandbreite des Internetanschlusses auf Teilnehmer*innenseite ist häufig der "Flaschenhals", der zu einem schlechten Nutzererlebnis bei BigBlueButton führt. Aus verschiedenen Gründen kann der Audiostrom dann nicht mehr flüssig gesendet werden, oder die Audioströme der anderen Nutzer*innen nicht mehr flüssig empfangen werden.
#* Teilnehmer*innen-Maßnahmen
#*# Dringende Empfehlung: Computer durch '''LAN-Kabel''' mit Internet verbinden (statt per WLAN)
#*# Falls LAN-Kabel keine Alternative ist, sollte die Teilnehmer*in sich '''nah am WLAN-Router''' mit direktem Sichtkontakt (keine Schränke, Mauern) aufhalten, um eine bessere Verbindung zu erhalten
#*# '''Mobilfunk'''-Internetverbindung ist nicht zu empfehlen
#*# Der Internetanschluss kann durch '''andere Aktivitäten''' (parallele Up-/Downloads) und Nutzer ausgelastet sein (z.B. durch IP-Fernsehen). Diese nach Möglichkeit unterlassen oder verringern
#*# '''Telefoneinwahl''': Falls beim BBB die Telefoneinwahl konfiguriert ist, kann der Internetanschluss damit umgangen werden
#*# '''Headset statt Lautsprecher''': Verwendet eine Teilnehmer*in statt eines Kopfhörers einen Lautsprecher, kann es passieren, dass ein eingeschaltetes Mikrofon die Lautsprecherausgabe wieder aufnimmt und zurück in den Konferenzraum sendet. Solche Rückkoppelungen lassen sich nicht immer technisch erfolgreich unterdrücken. Daher besser Kopfhörer oder direkt ein Headset verwenden.
#*#* Auch bei Kopfhörern/Headsets gilt ebenfalls, dass eine Verbindung per Kabel besser als eine per Funk (z.B. Bluetooth) ist, da Funkverbindungen immer Verzögerungen besitzen
#*#* Die eigene Anzeige von Kameras anderer Teilnehmer*innen abschalten, um Internetbandbreite zu sparen (Datensparsamkeitseinstellungen im Menü oben rechts in einem BBB-Raum)
#* Moderations-Maßnahmen
#*# Den Präsentator*innen eine gute Internetverbindung nahelegen, sie sollten die Teilnehmer*innen-Maßnahmen von oben beherzigen
#*# Je '''weniger Webcams eingeschaltet''' sind, desto besser. Bei größeren Konferenzen (schon ab 10 Teilnehmern) ist immer davon auszugehen, dass dort jemand mit einer schlechten Internetverbindung teilnimmt. Es sollte daher vorher sichergestellt sein, dass dies nicht ausgerechnet die Präsentator*in ist. Schlechte Internetverbindungen der Teilnehmer*innen haben bereits Probleme mit wenigen aktiven Kameras. Daher sollte die Gesamtanzahl der Kameras immer niedrig bleiben.
#* Server-Maßnahmen Die Performance des BBB-Servers war bisher bei Hostsharing kein Problem, alle Server waren gut auf die geplanten Konferenzen eingestellt. Bei großen Konferenzen machen einem BBB-Server nur die Momente zu schaffen, in denen mehrere Kameras gleichzeitig eingeschaltet werden. Das ist leicht nachvollziehbar, bei z.B. 100 Teilnehmer*innen müssen von einem Moment auf den nächsten 100 Kamerabilder verteilt werden. Für ein paar Sekunden kann es da zu einer Überlastung des Servers und einer Verzögerung kommen. Trotzdem gibt es Möglichkeiten, den Server anzupassen, dass es auf Teilnehmer*innenseite nicht so schnell zur Überauslastung der Internetverbindung kommt:
#*# Eine datensparsameres Kameraprofil zur Vorauswahl den Teilnehmer*innen präsentieren (siehe unten)
#*# Die Bitraten der Kameraprofile reduzieren (s.u.)
#*# Die Bitrate von Bildschirmpräsentationen reduzieren (s.u.)

== Anpassungsmöglichkeiten ==

Die beste englischsprachige Anlaufstelle ist https://docs.bigbluebutton.org/2.2/customize.html

=== Bandbreite auf Teilnehmerseite reduzieren ===

'''Teilnehmer-Lösungen'''

'''Server-Lösung 1''': In der Auswahlbox für Kameraprofile, die jeder Teilnehmer vor dem Einschalten seiner Webcam sieht, ein Profil mit kleinerer Kameraauflösung vorauswählen. Dies bewirkt, dass sich Teilnehmer bewusst für eine bessere Kameraqualität entscheiden müssen, dadurch die durchschnittlichen Kameraqualitäten sinken und somit jeder Teilnehmer (auch die ohne eingeschaltete Webcam) mehr Bandbreite ihres Internetanschlusses zur Verfügung haben.

Datei <code>/usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml</code> per Hand anpassen oder

Updaterobuste Lösung: in der Datei <code>/etc/bigbluebutton/bbb-conf/apply-config.sh</code> einfügen: 
<nowiki>echo " - Setting camera defaults"
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==low).default' true
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==medium).default' false
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==high).default' false
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==hd).default' false
</nowiki>
Dies wählt als voreingestelltes Kameraprofil ''low'' aus.

'''Server-Lösung 2''': Die Bitraten aller Kameraprofile reduzieren

Datei <code>/usr/share/meteor/bundle/programs/server/assets/app/config/settings.yml</code> per Hand anpassen oder

Updaterobuste Lösung: in der Datei <code>/etc/bigbluebutton/bbb-conf/apply-config.sh</code> einfügen: 
<nowiki>echo " - Setting camera defaults"
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==low).bitrate' 50
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==medium).bitrate' 100
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==high).bitrate' 200
yq w -i $HTML5_CONFIG 'public.kurento.cameraProfiles.(id==hd).bitrate' 300
</nowiki>
Dies setzt die Bitraten der vier Kameraprofile auf die gegebenen Werte.
Die Werkseinstellungen dieser Werte sind übrigens: 100, 200, 500, 800

Benutzer:Hsh-marcsandlus/BigBlueButton

2020-10-29T11:08:27Z

Hsh-marcsandlus: Die Seite wurde neu angelegt: „Hier soll eine Sammlung von Tipps & Tricks zu BigBlueButton bei Hostsharing entstehen, ab einem gewissen Reifegrad der Seite wird sie ins Haupt-Wiki verschoben…“

Benutzer:Hsh-marcsandlus

2020-10-29T09:53:53Z

Hsh-marcsandlus: /* Einstiegsseite für Marc O. Sandlus */

== Einstiegsseite für Marc O. Sandlus ==

[[Benutzer:Hsh-marcsandlus/Erfolgsrezepte]]

[[Benutzer:Hsh-marcsandlus/BigBlueButton]]

Coturn Installieren

2020-08-10T10:03:52Z

Hsh-marcsandlus: /* Installation */

Coturn STUN- und TURN-Server installieren

== Allgemein ==

[https://github.com/coturn/coturn Coturn] ist ein STUN- und TURN-Server, der die Steuerung von VoIP-, Video- und Audio-Verbindungen unterstützt.

== Spezielle Installation bei Hostsharing ==

In jedem dynamischen Webhosting-Paket der Hostsharing eG kann ein Coturn-Server betrieben werden.

Dazu muss für jede Coturn-Instanz die Option "Betrieb eines eigenen Serverdienstes" gebucht werden. Im Bereich des Shared Hosting ist die Option kostenpflichtig.

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

Geben Sie bei der Bestellung der Option "Eigener Serverdienst" an:

# den Service User, mit dessen Rechten der Coturn-Dienst laufen soll (also zum Beispiel "xyz00-coturn")

== Installation ==

Coturn ist bereits vorinstalliert. Die STUN-Funktion wenigstens zwei IP-Adressen benötigt, darf als zweite IP-Adresse in diesem Szenario IP-Adresse des Hives bzw. der VM verwendet werden.

<pre>
listening-ip=<IP-Adresse-des-Pakets>
listening-ip=<IP-Adresse-des-Hives/der-VM>
relay-ip=<IP-Adresse-des-Pakets>
listening-port=<zugewiesener-Port>
fingerprint
lt-cred-mech
use-auth-secret
static-auth-secret=<shared-secret>
realm=<xyz00.hostsharing.net>
total-quota=100
bps-capacity=0
stale-nonce
no-loopback-peers
no-multicast-peers
log-file=<pfad>/turnserver.log
pidfile=<pfad>/turnserver.pid
userdb=<pfad>/turnserver.db
no-tls
</pre>

Start mit turnserver -c <pfad>/turnserver.conf

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Eigene Daemons]]

Procmail

2020-03-05T19:26:03Z

Hsh-marcsandlus: typo

Procmail ist ein mächtiger Filter, der für viele komplexe Aufgaben verwendet werden kann. So sind z.B. variable Weiterleitungen und das Einbinden eines Spamfilters machbar. Mehr dazu unter www.procmail.org und auf dem Server in den Manpages zu procmail, procmailrc und procmailex.

Das Standard-Mail-Zustellungsprogramm (Local Delivery Agent - LDA) bei Hostsharing ist <tt>deliver</tt> aus dem <tt>dovecot</tt>-Paket. Hier können Filter über [[Managesieve]] angelegt und z.B. über [[Roundcube - Filter|Webmail konfiguriert]] werden. Procmail sollte nur noch von fortgeschrittenen Nutzern für komplexe Filteraufgaben benutzt werden.

=== Eingehende Emails an Procmail weiterleiten ===

Zur Nutzung von procmail wird im Homedirectory des Users eine Datei .forward angelegt, die nur aus einer Zeile besteht:

"|/usr/bin/procmail"

Damit werden alle Mails an das Programm procmail übergeben und die Auslieferung kann nun über die Datei [[Managesieve#Zusammenarbeit_mit_Procmail|~/.procmailrc]] konfiguriert werden.

=== Procmail konfigurieren ===

Das nachfolgende Beispiel zeigt wie ein [[Spamfilter]] eingebunden werden kann, und Emails automatisch in IMAP-Folder (Verzeichnisse) einsortiert werden können.

==== Verzeichnisse anlegen ====

Die angesprochenen Emailverzeichnisse sollten vorher angelegt worden sein, falls sie noch nicht existieren ist dies z.B. mit dem Befehle maildirmake möglich:

maildirmake Maildir
maildirmake -f Trash Maildir
maildirmake -f Spam Maildir
maildirmake -f Hostsharing Maildir

Alternativ können die Verzeichnisse auch über die Webmail-Oberfläche anlgelegt werden. Es ist übrigens korrekt, dass die Folder beim Anlegen ohne einen führenden Punkt im Namen erstellt werden, in der .procmailrc aber mit Punkt angegeben werden.

==== .procmailrc ====

Eine beispielhafte .procmailrc:
<pre>
## Logging abstellen
COMSAT=no
LOGABSTRACT=no
VERBOSE=no
LOGFILE=procmail.log

## Spamassassin für alle Mails aufrufen...
# Hier wird der systemweite Spamassassin-Daemon benutzt.
:0fw
| /usr/bin/spamc -U /var/run/spamd
## ...und Spam in den Spam Folder aussortieren
:0
* ^X-Spam-Flag: YES
Maildir/.Spam/

## Bsp. Mailinglisten von Hostsharing in eine extra Box
#:0
#* ^TO_(support|technik|website)@hostsharing\.net
#Maildir/.Hostsharing/

# Alle nicht ausgefilterten Mails landen in der normalen Mailbox
</pre>

Möchte man die Mails mit Sieve filtern lassen, will man am Ende von .procmailrc evtl. das Programm "[[Managesieve#Zusammenarbeit_mit_Procmail|deliver]]" aufrufen lassen.

==== Abwesenheitsbenachrichtigung (vacation) ====

Zunächst im Home-Ordner eine Datei vacation.msg erstellen, deren Text als Nachricht verschickt werden soll.

Dann in die .procmailrc folgende Zeilen einfügen:
<pre>
SHELL=/bin/sh
FORMAIL=/usr/bin/formail
SENDMAIL=/usr/sbin/sendmail
:0 Whc: vacation.lock
* ^TO_myself@example.com
# Nur E-Mails, die an meine Adresse adressiert sind
* !^FROM_DAEMON
# Daemons (Mailinglisten) ausschließen
* !^X-Loop: myself@example.com
# Loop vermeiden: eigene E-Mail ausschließen
| formail -rD 8192 vacation.cache
# Adresse des Senders im Cache speichern
:0 ehc
# e: letztes recipe trifft nicht zu (Adresse noch nicht im Cache vorhanden)
| ($FORMAIL -rA "Precedence: junk" -A "X-Loop: myself@example.com" ; /bin/cat vacation.msg ) | $SENDMAIL -oi -t -f myself@example.com
</pre>

Nun wird eine E-Mail mit dem Inhalt der Datei vacation.msg und dem Absender myself@example.com an die Absender empfangener Emails geschickt. Allerdings nur, wenn die Adresse noch nicht in der vacation.cache-Datei vorhanden war. Damit wird vermieden, dass ein Absender immer wieder die Abwesenheitsnachricht erhält.

=== Links zu weiteren Procmail Beispielen und Tipps ===

http://pm-doc.sourceforge.net/doc/

http://lipas.uwasa.fi/~ts/info/proctips.html (Timo's procmail tips and recipes)

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

Monit installieren

2020-03-03T23:44:13Z

Hsh-marcsandlus: Korrekturen

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

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

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

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

== Konfiguration ==

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

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

<pre>
xyz00@hxx:~$ cd
xyz00@hxx:~$ touch .monitrc
xyz00@hxx:~$ chmod 0600 .monitrc
xyz00@hxx:~$ edit .monitrc
</pre>

Und füllen sie mit folgendem Inhalt:

<pre>
set daemon 600
set logfile /home/pacs/xyz00/var/monit.log
set mailserver localhost
set alert admin@example.tld

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

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

== Monit Starten und Stoppen ==

'''Start:''' monit 
'''Stop:''' monit quit

=== Start eigener [[Daemon|Daemons]] beim Start des Servers ===

In die eigene [[Cron#Crontab|crontab]] folgenden Eintrag:

@reboot rm -f $HOME/.monit.pid && /usr/bin/monit -c "/home/pacs/xyz00/.monitrc"

== Managed Server monitoren ==

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

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

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

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

== Logfiles kontrollieren ==

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

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

touch .logrotate

Darin schreiben wir:

<pre>
compress

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

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

27 7 * * 5 logrotate -s /home/pacs/xyz00/.logrotate_state /home/pacs/xyz00/.logrotate

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

== externe Links ==

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

Graphics Magick installieren

2020-03-03T23:35:16Z

Hsh-marcsandlus:

=== GraphicsMagick ===

Seit 2002 ist GraphicsMagick die GPL Version von ImageMagick. GraphicsMagick ist aus der damaligen ImageMagick Version 5.5.2. hervorgegangen.

Die jetzige Version ist 1.3.5.
Die letzte Version kann man vom [ftp://ftp.graphicsmagick.org/pub/GraphicsMagick/ FTP server] herunterladen.

Will man diese Version verwenden, muss man die Binaries in das home-Verzeichnis kopieren, auf das der Paket-Admin (z.B. xyz00), unter dem die Domain läuft, zugreifen kann, und diese mit dem tar-Befehl extrahieren:

xyz00@hopi:~$ tar xvfpz GraphicsMagick-LATEST.tar.gz

Die Installation vorbereiten

cd bin/ GraphicsMagick-1.3.5
./configure --prefix=/home/pacs/xyz00 --enable-magick-compat

Programm installieren

make
make install

Überprüfen ob alles richtig installiert ist mit

cd ~/bin

xyz00@hopi:~/bin$ls -l
total 8925
drwxr-xr-x 2 root root 1024 Feb 11 10:57 .
drwxr-xr-x 12 root root 1024 Jan 14 11:46 ..
-rwxr-xr-x 1 root root 1223 Feb 11 10:57 GraphicsMagick++-config
-rwxr-xr-x 1 root root 1266 Feb 11 10:57 GraphicsMagick-config
-rwxr-xr-x 1 root root 1250 Feb 11 10:57 GraphicsMagickWand-config
-rwxr-xr-x 1 root root 5209711 Feb 11 10:57 PerlMagick
lrwxrwxrwx 1 root root 2 Feb 11 10:57 animate -> gm
lrwxrwxrwx 1 root root 2 Feb 11 10:57 composite -> gm
lrwxrwxrwx 1 root root 2 Feb 11 10:57 conjure -> gm
lrwxrwxrwx 1 root root 2 Feb 11 10:57 convert -> gm
lrwxrwxrwx 1 root root 2 Feb 11 10:57 display -> gm
-rwxr-xr-x 1 root root 3891115 Feb 11 10:57 gm
lrwxrwxrwx 1 root root 2 Feb 11 10:57 identify -> gm
lrwxrwxrwx 1 root root 2 Feb 11 10:57 import -> gm
lrwxrwxrwx 1 root root 2 Feb 11 10:57 mogrify -> gm
lrwxrwxrwx 1 root root 2 Feb 11 10:57 montage -> gm

=== Für TYPO3 braucht man nur folgende Variablen zu setzen ===

* [im_combine_filename] = 'combine' setzen
* [TTFdpi] = '96' setzen
* [gif_compress] ='' setzen

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

Webmaster on Demand

2020-03-03T23:12:08Z

Hsh-marcsandlus: Die Seite wurde neu angelegt: „== Informationen zum Webmaster-on-Demand-Service von Hostsharing.net == Der [https://www.hostsharing.net/service/webmaster-on-demand/ Webmaster-on-Demand von…“

== Informationen zum Webmaster-on-Demand-Service von Hostsharing.net ==

Der [https://www.hostsharing.net/service/webmaster-on-demand/ Webmaster-on-Demand von Hostsharing] kann Ihnen viele Arbeiten abnehmen, zum Beispiel die Grundinstallation von Software.

== Grundinstallation von Software ==

Beauftragen Sie den Webmaster-on-Demand einfach mittels einer E-Mail an [mailto:service@hostsharing.net service@hostsharing.net]. Die E-Mail sollte folgende Informationen enthalten:

* Art: (z.B. WordPress Grundinstallation, weitere Beispiele s.u.)
* Frist: (z.B. bis 18.00 Uhr am 29.2.2020, relevant für die Dringlichkeitsermittlung)
* Mitgliederkürzel: (z.B. xyz)
* Web-Paket: (z.B. xyz00)
* Benutzer: (z.B. xyz00-wp) (wir empfehlen aus Sicherheitsgründen, einen neuen Benutzernamen zu verwenden/anzugeben)
* Sub-Domain: (z.B. wp.example.com, example.com sollte bereits in [[HSAdmin]] angelegt sein)
* Bemerkungen: (z.B. inklusive Matomo-Modul)

Beispiele für installierbare Software (Aufwand in Klammern), weitere auf Anfrage:

* Confluence (2x15 Min.)
* Jira (2x15 Min.)
* [[Nextcloud]] (2x15 Min.)
* Taiga (4x15 Min.)
* [[Wordpress]] (2x15 Min.)
* ''weitere auf Anfrage''

Mailman Installieren

2019-12-17T20:23:31Z

Hsh-marcsandlus: /* E-Mail Adressen bei Mailman einrichten */

== Vorab: Die Wahl von Mailman 2 ==

Mailman 2 hängt von Python 2.7 ab und wird damit voraussichtlich nur noch eine begrenzte Nutzungsdauer haben. Mailman 3 ist jetzt verfügbar (siehe [[Mailman_3_installieren]]), aber deutlich schwerer und komplexer im Betrieb. Es gibt auch weniger leistungsfähige Software, um E-Mail-Verteiler zu betreiben, wie beispielsweise mlmmj. Für eine Diskussion der Situation im Oktober 2019, siehe das HS-Support-Archiv ab [https://lists.hostsharing.net/archiv/support/2019-October/067243.html hier.]

== Mailman 2 installieren ==

(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)

Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!

=== Unter welchem Account installieren? ===

Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn wenn Mailman vom Paketadmin installiert wird, haben ausnahmslos alle Paketuser direkten Zugriff auf die Mailman-Daten, und bei Sicherheitslücken in Mailman wäre eventuell eine Rechte-Eskalierung auf Paketadmin-Ebene potentiell zu befürchten.

Dem Paketuser, unter dem Mailman installiert wird, können mehrere Subdomains aufschaltet werden, und Mailinglisten können auch die Domainnamen verwenden, die anderen Paketusern gehören.

Vorteil der Installation als Paketuser ist, dass nur dieser direkten Zugriff auf die Mailmandaten hat und mailman ohne Paketadminrechte läuft. Während der Emailauslieferung gelten (wie immer bei der Mailweiterleitung durch .forward-Dateien oder durch procmail) die Rechte des Paketusers, dem die Mailman-Installation gehört.

Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.

=== Einen User und eine Domain anlegen ===

Unter admin.hostsharing.net als xyz00 anmelden; den User xyz00-listen erzeugen; die Domain listen.example.com mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.

Mit [[Login_mit_SSH|SSH]] an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.com/htdocs-ssl/.htaccess löschen:

~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess

Die Default-Subdomains www.* löschen:

~$ rm -r doms/listen.example.com/subs/www/
~$ rm -r doms/listen.example.com/subs-ssl/www/

=== Sourcen besorgen und entpacken ===

Unter http://www.gnu.org/software/mailman/ die aktuelle Software besorgen. Dort findet sich ein Link zu den 2er-Versionen von Mailman (http://ftp.gnu.org/gnu/mailman/). Die letzte Version downloaden ...

~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz

... und entpacken:

~$ tar -xzvf mailman-2.1.29.tgz

Ab diesem Augenblick gibt es ein Verzeichnis namens mailman-2.1.29/. Darin liegt die nunmehr entpackte ''Quellcode'' der Mailman-Software. Nach dem Kompilieren (folgt unten) wird die fertig kompilierte, gebrauchsfähige Mailman-Software in dem zusätzlich vorhandenen Verzeichnis mailman/ liegen. (Dieses Verzeichnis wird beim Konfigurieren der Source als "prefix" angegeben.)

=== var-Verzeichnis für Log-Dateien anlegen ===

Bei der Installation als Paketuser (xyz00-listen):
~$ cd && mkdir -p mailman/var
~$ chmod 02775 mailman/var

Bei der Installation als Paketadmin (xyz00):
~$ cd && mkdir var/mailman
~$ chmod 02775 var/mailman

=== Mailman konfigurieren ===

In das Source-Verzeichnis wechseln:

~$ cd mailman-2.1.29

Bei der Installation als Paketuser (xyz00-listen):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \
--with-username=xyz00-listen \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \
--with-cgi-gid=xyz00 \
--with-mail-gid=xyz00

Bei der Installation als Paketadmin (xyz00):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \
--with-username=xyz00 \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/var/mailman \
--with-cgi-gid=xyz00 \
--with-mail-gid=nogroup

(Die Rückwärtsschrägstriche "\" am Zeilenende bedeuten, dass der Befehl in der nächsten Zeile weitergeht. Alternativ können alle Argumente in eine Zeile getippt werden.)

=== Mailman kompilieren ===

~/mailman-2.1.29$ make
~/mailman-2.1.29$ make install

=== Datenrechte prüfen ===

Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:

~/mailman-2.1.29$ cd ..
~$ mailman/bin/check_perms -f

== Die neue Mailman-Installation konfigurieren ==

=== Konfigurationsdatei mm_cfg.py editieren ===

~$ nano mailman/Mailman/mm_cfg.py

Eine Beispielkonfiguration für listen.example.com könnte so aussehen:

[...]
##################################################
# Put YOUR site-specific settings below this line.
# -*- python -*-

DEFAULT_HOST_NAME = 'listen.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
DEFAULT_URL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)

DEFAULT_SERVER_LANGUAGE = 'de'

DEFAULT_URL_PATTERN = 'http://%s/'

# Es wird der HS Mailversand für Bulkmail verwendet:
SMTPHOST = 'localhost'
SMTPPORT = 4587
SMTP_AUTH = True
SMTP_USER = 'xyz00-listen'
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'
SMTP_USE_TLS = True

In ~/mailman/Mailman/Defaults.py sieht man, was in mm_cfg.py alles angepasst werden kann.

=== CGI-Programme in die Domain kopieren ===

Bei der Installation als Paketuser (xyz00-listen):

Die fertig kompilierten CGIs von Mailman müssen in das CGI-Verzeichnis der Domain (oder der Domains), auf der das Webfrontend von Mailman laufen soll, kopiert werden. Symbolische Links sind nicht ausreichend.

~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/

Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:

~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*

Bei der Installation als Paketadmin (xyz00):

Die CGI-Programme können im Mailman-Verzeichnis bleiben. Im CGI-Verzeichnis von jeder Domain, auf der das Mailman-Webfrontend laufen soll, werden symbolische Links dazu erstellt:

~$ cd doms/listen.example.com/cgi-ssl
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman

=== Mailman-Icons in die Domains kopieren ===

Die Icons können wahlweise verlinkt oder kopiert werden:

~$ cd doms/listen.example.com/htdocs-ssl
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons

oder

~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/

=== Die Datei .htaccess bearbeiten ===

Bei einer dedizierten Mailman-Domain sollte man dafür sorgen, dass Mailman nicht nur unter https://listen.example.com/cgi-bin/mailman, sondern auch unter https://listen.example.com erreichbar ist.

Dazu werden in ~/doms/listen.example.com/htdocs-ssl/.htaccess folgende Rewrite-Anweisungen eintragen.

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.

Wenn Mailman z.B. auf einer als Unterverzeichnis angelegten Subdomain läuft und unter https://www.example.com/mailman statt https://www.example.com/cgi-bin/mailman erreichbar sein soll, hilft folgendes in der ~/doms/example.com/subs-ssl/www/.htaccess:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

(In diesem Fall kann die Zeile DEFAULT_URL_PATTERN... in der mm_cfg.py auskommentiert werden.)

=== Hauptpasswort setzen ===

Das "site password" ist in Mailman eine Art Generalschlüssel: es wird neben dem jeweiligen Admin- oder Moderator-Passwort überall in der Weboberfläche für sämtliche Mailing-Listen akzeptiert. Also vorsichtig wählen! Das "site password" einrichten mit dem Befehl:

~$ mailman/bin/mmsitepass

=== Cronjobs einrichten ===

In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:

# Warteschlange jede Minute bearbeiten:
* * * * * ~/mailman/bin/qrunner -o -r All
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:
47 * * * * rm -f ~/var/mailman/logs/qrunner

Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.

Das Logfile wird stündlich gelöscht, da es sonst sehr schnell sehr groß wird. Falls Mailman von einem Paketuser (bspw. "xyz00-listen") installiert wurde, sollte die letzte Zeile im Beispiel oben so lauten:

47 * * * * rm -f ~/mailman/var/logs/qrunner

... entsprechend dem beim Konfigurieren angegebenen var-Verzeichnis, siehe oben.

Zudem müssen noch die von Mailman ohnehin vorgesehenen cron-Aufträge aus ~/mailman/cron/crontab.in dem crontab des Users angehängt werden:

crontab -l > mycronjobs.tmp
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp
crontab mycronjobs.tmp

== Mailinglisten einrichten ==

Jetzt läuft die Software; nun können die eigentlichen Verteiler angelegt werden. Als erster '''muß''' ein Hauptverteiler ("site list") eingerichtet werden. Dieser Verteiler dient u.a. als Absender der Paßwort-Erinnerungen an die Abonnenten aller Mailinglisten. Er hat standardmäßig den Namen "mailman". Falls ein anderer Name verwendet werden soll, muß dieser mit der Anweisung

MAILMAN_SITE_LIST = 'sitelistname'

in der Konfigurationsdatei mailman/Mailman/mm_cfg.py eingetragen werden.

=== Den Hauptverteiler "mailman" anlegen ===

Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.

Mit dem Mailman-Befehl newlist den Verteiler anlegen:

~$ mailman/bin/newlist mailman
Enter the email of the person running the list: admin@xyz00.hostsharing.net
Initial mailman password:

(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)

Nur dieses eine Mal für die "site list" müssen wir die Konfigurationsvorgaben laden. (Gewöhnliche Mailinglisten werden später über die Weboberfläche konfiguriert.)

Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:

~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman

Falls mailman vom Paketadmin ("xyz00") installiert wurde:

~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman

Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.

=== E-Mail Adressen bei Mailman einrichten ===

Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine E-Mail an den dabei eingetragenen Listenadministrator. Diese E-Mail enthält die Anweisung, E-Mail-Aliases für den neuen Verteiler und für die verschiedenen Mailman-Funktionen anzulegen. Bei Hostsharing wird die Zustellung von E-Mails an Mailman anders geregelt: alle E-Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. E-Mails an diese Adressen werden dann durch Pipe-Anweisungen in ''.forward-Dateien'' im Home-Verzeichnis des Mailman-Users mit den entsprechenden Argumenten an Mailman übergeben.

Falls Mailman von einem Paketuser (bspw. "xyz00-listen") installiert wurde, werden ''E-Mail-Adressen'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeilentool hsscript)] eingerichtet; die ''.forward-Dateien'' werden durch [[Login_mit_SSH|Shell-Befehle]] angelegt.

Das folgende Beispiel zeigt die Befehle, mit denen in einer interaktiven hsscript-Sitzung die E-Mail-Adressen für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten "mailman" durch den Namen der Mailingliste ersetzt.)

hsscript -u xyz00 -i
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})

Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.

Für jede der soeben eingerichteten Adressen wird nun eine .forward-Datei im Homeverzeichnis des Users xyz00-listen angelegt. Die Dateinamen bestehen aus der Zeichenfolge ".forward+" gefolgt vom Namen der ausführen soll. Der Inhalt der jeweiligen .forward-Datei legt die Weiterleitung der Mail durch einen Pipe an Mailman fest, mit dem jeweiligen Befehl als Argument:

"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"

Zum Beispiel wird die .forward-Datei .forward+mailman-subscribe verwendet, wenn eine E-Mail an die Adresse mailman-subscribe@listen.example.com eingeht. Aufgrund der oben eingerichteten E-Mail-Adresse mit dem Ziel "xyz00-listen+mailman-subscribe" wertet der Mail-Transfer-Agent die .forward-Datei .forward+mailman-subscribe im Home-Verzeichnis des Users xyz00-listen aus, und entsprechend ihrem Inhalt wird die Mail an die Mailman-Software mit den Argumenten "subscribe mailman" übergeben.

Das folgende Beispiel zeigt die Befehle, mit denen an der Befehlszeilenaufforderung der Shell die .forward-Dateien für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten und in den Namen der .forward-Dateien "mailman" durch den Namen der Mailingliste ersetzt, jedoch '''nicht''' in der Pfadangabe zum Mailman-Programm selbst; diese ändert sich ja nicht.)

echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe

Die vielen Befehle können von dieser Anleitung kopiert und nach Anpassung auf den tatsächlichen Unsernamen in die SSH-Sitzung kopiert werden. Noch leichter ist es, mit einem Editor einen Shell-Skript namens ~/bin/addforwards mit folgendem Inhalt zu erstellen:

#!/bin/sh
# .forward-Dateien für einen Verteiler unter Mailman einrichten.
#
if [ "$1" = "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "$2" != "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "`pwd`" != "`echo ~`" ] ; then
echo "Diesen Befehl vom Home-Verzeichnis aus aufrufen.\n"
exit
fi
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post $1\"" > .forward+$1
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin $1\"" > .forward+$1-admin
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces $1\"" > .forward+$1-bounces
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm $1\"" > .forward+$1-confirm
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join $1\"" > .forward+$1-join
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave $1\"" > .forward+$1-leave
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner $1\"" > .forward+$1-owner
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request $1\"" > .forward+$1-request
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe $1\"" > .forward+$1-subscribe
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe $1\"" > .forward+$1-unsubscribe
exit

Der Skript muß natürlich als ausführbar gekennzeichnet werden:

~$ chmod u+x bin/addforwards

Die Erweiterung dieses Skripts um die hsscript-Befehle wird dem Leser als Aufgabe überlassen.

=== Administration ===

Als erstes sollte man als Administrator der neuen Mailman-Installation die Liste "mailman" selbst abonnieren. Die Liste "mailman" kann aber unter https://listen.example.com/mailman/admin/mailman verwaltet werden.

Die Hauptseite der Mailman-Web-Verwaltung ist in unserem Beispiel (mit den oben angegebenen Rewrite-Anweisungen in der Datei .htaccess) https://listen.example.com/mailman/admin/. Diese Seite enthält Links zu den bisher eingerichteten Mailinglisten (außer "mailman") und einen Link, um neue Mailinglisten anzulegen (https://listen.example.com/mailman/create). Das Anlegen einer neuen Mailingliste geschieht entweder über diesen Link oder (wie oben) in der Shell mit dem Befehl:

~$ mailman/bin/newlist <Listenname>

In beiden Fällen müssen zusätzlich die E-Mail-Adressen und die .forward-Dateien wie bei dem Einrichten der Liste "mailman" nach Verfahren im obigen Abschnitt angelegt werden.

Für die Verwaltung der Mailinglisten im Alltag, d.h. den Umgang mit Bounces, Spam, Abonnenten usw., siehe u.a. die [https://wiki.list.org/ Mailman-Wiki].

== Feintuning ==

Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...

Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)

Es kann natürlich sein, dass ich zuviel lösche, aber bei mir funktioniert's. Wenn ihr also sicher(er) sein wollt, dass euch der Mailman nicht um die Ohren fliegt, macht das nicht!

* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:

# In a normal interactive Python environment, the japanese.pth and korean.pth
# files would be imported automatically. But because we inhibit the importing
# of the site module, we need to be explicit about importing these codecs.
if not jaok:
import japanese
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean
# codecs installed, however leave the first import in there in case an upgrade
# changes this.
if not kook:
import korean
import korean.aliases

auskommentieren.

Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.

Man kann auch noch die Debug-Informationen aus den binaries strippen:

strip ~/mailman/mail/mailman
strip ~/mailman/cgi-bin/*

Falls die CGIs nicht gesymlinkt wurden:

strip ~/doms/listen.example.com/cgi/mailman/*

== Multidomainfähigkeit ==

Seit Mailman 2.x kann eine Mailman-Installation unter gewissen Einschränkungen für mehrere Domains verwendet werden. Hier soll kurz gezeigt werden, was geht und wie es geht.

=== Anleitung ===

Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.

Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:

~$ mailman/bin/newlist listenname@listen.example.com

Es ist ggf. wichtig, dass in der mm_cfg.py eine entsprechende add_virtualhost-Direktive für www.example.com steht, die der Frontend-URL einen Host-Part für die Mailadressen zuordnet. Ist eine solche Direktive nicht vorhanden, so wird listen.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für E-Mailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. listen.example.com gerade zutrifft.)

Liegt das Frondend nicht auf der Maildomain ist es wichtig, dass ihr Mailman sagt, für welches die zugehörige Maildomain ist. Dies tut ihr in der Datei ~/mailman/Mailman/mm_cfg.py:

Also z.B.
DEFAULT_URL_HOST = 'www.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)

und
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')

Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.
Alle weiteren add_virtualhost-Direktiven ordnen einem Hostnamen für das Webfrontend (z.B. www.zoopnet.de) einen Hostpart für die Adresse der Mailinglisten (z.B. lists.zoopnet.de) zu.

Tip von Raimund Specht: Lässt man den zweiten Parameter weg, also schreibt z.B. add_virtualhost('www.example.org'), dann benutzt Mailman als Hostpart alles was nach dem ersten Punkt steht, hier also example.org als Maildomain.

Prinzipiell war's das. Man muss die Listeneinträge natürlich immer in die richtige virtusertable eintragen, und für gleichnamige Mailinglisten auf verschiedenen Domains (mailman@*) verschidene +Ergänzungen bzw. aliase verwenden. :)

=== Probleme ===

Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.

== Tips und Tricks ==

=== URL Änderungen ===
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url>
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.

=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===

Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:

< In Arbeit >

== Referenzen ==

Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html 

Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html> 

"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist 

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Mailinglisten]]
[[Kategorie:E-Mail]]

Mailman Installieren

2019-12-17T20:11:59Z

Hsh-marcsandlus: /* Unter welchem Account installieren? */

== Vorab: Die Wahl von Mailman 2 ==

Mailman 2 hängt von Python 2.7 ab und wird damit voraussichtlich nur noch eine begrenzte Nutzungsdauer haben. Mailman 3 ist jetzt verfügbar (siehe [[Mailman_3_installieren]]), aber deutlich schwerer und komplexer im Betrieb. Es gibt auch weniger leistungsfähige Software, um E-Mail-Verteiler zu betreiben, wie beispielsweise mlmmj. Für eine Diskussion der Situation im Oktober 2019, siehe das HS-Support-Archiv ab [https://lists.hostsharing.net/archiv/support/2019-October/067243.html hier.]

== Mailman 2 installieren ==

(zuletzt getestet mit mailman-2.1.29; Installation durch Paketuser)

Vielen Dank an alle Benutzer, die Verbesserungen beisteuern!

=== Unter welchem Account installieren? ===

Mailman kann vom Paketadmin (beipsielsweise "xyz00") oder von einem Paketuser (bspw. "xyz00-listen") installiert werden. Letzteres ist dringend empfohlen, denn wenn Mailman vom Paketadmin installiert wird, haben ausnahmslos alle Paketuser direkten Zugriff auf die Mailman-Daten, und bei Sicherheitslücken in Mailman wäre eventuell eine Rechte-Eskalierung auf Paketadmin-Ebene potentiell zu befürchten.

Dem Paketuser, unter dem Mailman installiert wird, können mehrere Subdomains aufschaltet werden, und Mailinglisten können auch die Domainnamen verwenden, die anderen Paketusern gehören.

Vorteil der Installation als Paketuser ist, dass nur dieser direkten Zugriff auf die Mailmandaten hat und mailman ohne Paketadminrechte läuft. Während der Emailauslieferung gelten (wie immer bei der Mailweiterleitung durch .forward-Dateien oder durch procmail) die Rechte des Paketusers, dem die Mailman-Installation gehört.

Nachteil der Installation als Paketuser ist lediglich, dass die Paketdomain mit dem SSL Zertifikat von Hostsharing nicht genutzt werden kann.

=== Einen User und eine Domain anlegen ===

Unter admin.hostsharing.net als xyz00 anmelden; den User xyz00-listen erzeugen; die Domain listen.example.com mit "Domain-User" xyz00-listen anlegen. Aus admin.hostsharing.net abmelden.

Mit [[Login_mit_SSH|SSH]] an hostsharing.net als xyz00-listen anmelden. Die Redirect-Zeile aus ~/doms/listen.example.com/htdocs-ssl/.htaccess löschen:

~$ echo "" > ~/doms/listen.example.com/htdocs-ssl/.htaccess

Die Default-Subdomains www.* löschen:

~$ rm -r doms/listen.example.com/subs/www/
~$ rm -r doms/listen.example.com/subs-ssl/www/

=== Sourcen besorgen und entpacken ===

Unter http://www.gnu.org/software/mailman/ die aktuelle Software besorgen. Dort findet sich ein Link zu den 2er-Versionen von Mailman (http://ftp.gnu.org/gnu/mailman/). Die letzte Version downloaden ...

~$ wget http://ftp.gnu.org/gnu/mailman/mailman-2.1.29.tgz

... und entpacken:

~$ tar -xzvf mailman-2.1.29.tgz

Ab diesem Augenblick gibt es ein Verzeichnis namens mailman-2.1.29/. Darin liegt die nunmehr entpackte ''Quellcode'' der Mailman-Software. Nach dem Kompilieren (folgt unten) wird die fertig kompilierte, gebrauchsfähige Mailman-Software in dem zusätzlich vorhandenen Verzeichnis mailman/ liegen. (Dieses Verzeichnis wird beim Konfigurieren der Source als "prefix" angegeben.)

=== var-Verzeichnis für Log-Dateien anlegen ===

Bei der Installation als Paketuser (xyz00-listen):
~$ cd && mkdir -p mailman/var
~$ chmod 02775 mailman/var

Bei der Installation als Paketadmin (xyz00):
~$ cd && mkdir var/mailman
~$ chmod 02775 var/mailman

=== Mailman konfigurieren ===

In das Source-Verzeichnis wechseln:

~$ cd mailman-2.1.29

Bei der Installation als Paketuser (xyz00-listen):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/users/listen/mailman \
--with-username=xyz00-listen \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/users/listen/mailman/var \
--with-cgi-gid=xyz00 \
--with-mail-gid=xyz00

Bei der Installation als Paketadmin (xyz00):
~/mailman-2.1.29$ ./configure --prefix=/home/pacs/xyz00/mailman \
--with-username=xyz00 \
--with-groupname=xyz00 \
--with-var-prefix=/home/pacs/xyz00/var/mailman \
--with-cgi-gid=xyz00 \
--with-mail-gid=nogroup

(Die Rückwärtsschrägstriche "\" am Zeilenende bedeuten, dass der Befehl in der nächsten Zeile weitergeht. Alternativ können alle Argumente in eine Zeile getippt werden.)

=== Mailman kompilieren ===

~/mailman-2.1.29$ make
~/mailman-2.1.29$ make install

=== Datenrechte prüfen ===

Sicherheitshalber die Dateirechte durch Mailmans mitgeliefertes Tool prüfen und ggf. korrigieren lassen:

~/mailman-2.1.29$ cd ..
~$ mailman/bin/check_perms -f

== Die neue Mailman-Installation konfigurieren ==

=== Konfigurationsdatei mm_cfg.py editieren ===

~$ nano mailman/Mailman/mm_cfg.py

Eine Beispielkonfiguration für listen.example.com könnte so aussehen:

[...]
##################################################
# Put YOUR site-specific settings below this line.
# -*- python -*-

DEFAULT_HOST_NAME = 'listen.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
DEFAULT_URL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST, DEFAULT_EMAIL_HOST)
add_virtualhost(zweite.listendomain.com, zweite.listendomain.com)

DEFAULT_SERVER_LANGUAGE = 'de'

DEFAULT_URL_PATTERN = 'http://%s/'

# Es wird der HS Mailversand für Bulkmail verwendet:
SMTPHOST = 'localhost'
SMTPPORT = 4587
SMTP_AUTH = True
SMTP_USER = 'xyz00-listen'
SMTP_PASSWD = 'das-passwort-des-o.-g.-users'
SMTP_USE_TLS = True

In ~/mailman/Mailman/Defaults.py sieht man, was in mm_cfg.py alles angepasst werden kann.

=== CGI-Programme in die Domain kopieren ===

Bei der Installation als Paketuser (xyz00-listen):

Die fertig kompilierten CGIs von Mailman müssen in das CGI-Verzeichnis der Domain (oder der Domains), auf der das Webfrontend von Mailman laufen soll, kopiert werden. Symbolische Links sind nicht ausreichend.

~$ mkdir ~/doms/listen.example.com/cgi-ssl/mailman
~$ cp mailman/cgi-bin/* doms/listen.example.com/cgi-ssl/mailman/

Zusätzlich muss das sticky-Flag von den kopierten Dateien entfernt werden:

~$ chmod g-s ~/doms/listen.example.com/cgi/mailman/*

Bei der Installation als Paketadmin (xyz00):

Die CGI-Programme können im Mailman-Verzeichnis bleiben. Im CGI-Verzeichnis von jeder Domain, auf der das Mailman-Webfrontend laufen soll, werden symbolische Links dazu erstellt:

~$ cd doms/listen.example.com/cgi-ssl
~/doms/listen.example.com/cgi-ssl$ ln -s ../../../mailman/cgi-bin mailman

=== Mailman-Icons in die Domains kopieren ===

Die Icons können wahlweise verlinkt oder kopiert werden:

~$ cd doms/listen.example.com/htdocs-ssl
~/doms/listen.example.com/htdocs-ssl$ ln -s ../../../mailman/icons

oder

~$ cp -R mailman/icons doms/listen.example.com/htdocs-ssl/

=== Die Datei .htaccess bearbeiten ===

Bei einer dedizierten Mailman-Domain sollte man dafür sorgen, dass Mailman nicht nur unter https://listen.example.com/cgi-bin/mailman, sondern auch unter https://listen.example.com erreichbar ist.

Dazu werden in ~/doms/listen.example.com/htdocs-ssl/.htaccess folgende Rewrite-Anweisungen eintragen.

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

Beachte dabei die zweite Zeile: Anfragen für Icons sollen ''nicht'' umgeschrieben werden.

Wenn Mailman z.B. auf einer als Unterverzeichnis angelegten Subdomain läuft und unter https://www.example.com/mailman statt https://www.example.com/cgi-bin/mailman erreichbar sein soll, hilft folgendes in der ~/doms/example.com/subs-ssl/www/.htaccess:

RewriteEngine On
RewriteCond %{REQUEST_URI} !^/icons/
RewriteRule ^mailman/(.*)$ /cgi-bin/mailman/$1
RewriteRule ^/cgi-bin/mailman/$ /cgi-bin/mailman/listinfo

(In diesem Fall kann die Zeile DEFAULT_URL_PATTERN... in der mm_cfg.py auskommentiert werden.)

=== Hauptpasswort setzen ===

Das "site password" ist in Mailman eine Art Generalschlüssel: es wird neben dem jeweiligen Admin- oder Moderator-Passwort überall in der Weboberfläche für sämtliche Mailing-Listen akzeptiert. Also vorsichtig wählen! Das "site password" einrichten mit dem Befehl:

~$ mailman/bin/mmsitepass

=== Cronjobs einrichten ===

In die [[Cron |Crontab]] werden Befehle eingetragen, um die Mail-Warteschlange abzuarbeiten, Logs zu löschen, usw.:

# Warteschlange jede Minute bearbeiten:
* * * * * ~/mailman/bin/qrunner -o -r All
# Verarbeitungslogs in der 47ten Minute jeder Stunde löschen:
47 * * * * rm -f ~/var/mailman/logs/qrunner

Damit übernimmt cron die Funktion des qrunner-Dämons, der normalerweise auf einem Mailman-Server laufen sollte.

Das Logfile wird stündlich gelöscht, da es sonst sehr schnell sehr groß wird. Falls Mailman von einem Paketuser (bspw. "xyz00-listen") installiert wurde, sollte die letzte Zeile im Beispiel oben so lauten:

47 * * * * rm -f ~/mailman/var/logs/qrunner

... entsprechend dem beim Konfigurieren angegebenen var-Verzeichnis, siehe oben.

Zudem müssen noch die von Mailman ohnehin vorgesehenen cron-Aufträge aus ~/mailman/cron/crontab.in dem crontab des Users angehängt werden:

crontab -l > mycronjobs.tmp
cat ~/mailman/cron/crontab.in >> mycronjobs.tmp
crontab mycronjobs.tmp

== Mailinglisten einrichten ==

Jetzt läuft die Software; nun können die eigentlichen Verteiler angelegt werden. Als erster '''muß''' ein Hauptverteiler ("site list") eingerichtet werden. Dieser Verteiler dient u.a. als Absender der Paßwort-Erinnerungen an die Abonnenten aller Mailinglisten. Er hat standardmäßig den Namen "mailman". Falls ein anderer Name verwendet werden soll, muß dieser mit der Anweisung

MAILMAN_SITE_LIST = 'sitelistname'

in der Konfigurationsdatei mailman/Mailman/mm_cfg.py eingetragen werden.

=== Den Hauptverteiler "mailman" anlegen ===

Die "site list" mit dem Namen "mailman" ist die Mailingliste der lokalen Mailman-Administratoren. Sie wird zur einwandfreien Funktion von Mailman benötigt.

Mit dem Mailman-Befehl newlist den Verteiler anlegen:

~$ mailman/bin/newlist mailman
Enter the email of the person running the list: admin@xyz00.hostsharing.net
Initial mailman password:

(Der Befehl newlist kann – alternativ zur Weboberfläche – später benutzt werden, um gewöhnliche Mailinglisten anzulegen.)

Nur dieses eine Mal für die "site list" müssen wir die Konfigurationsvorgaben laden. (Gewöhnliche Mailinglisten werden später über die Weboberfläche konfiguriert.)

Falls mailman vom Paketuser (bspw. "xyz00-listen") installiert wurde:

~$ mailman/bin/config_list -i ~/mailman/var/data/sitelist.cfg mailman

Falls mailman vom Paketadmin ("xyz00") installiert wurde:

~$ mailman/bin/config_list -i ~/var/mailman/data/sitelist.cfg mailman

Diese Konfigurationsdatei soll '''nicht''' auf gewöhnliche Mailinglisten anwendet werden.

=== E-Mail Adressen bei Mailman einrichten ===

Sobald ein neuer Verteiler angelegt worden ist, sendet Mailman eine E-Mail an den dabei eingetragenen Listenadministrator. Diese E-Mail enthält die Anweisung, E-Mail-Aliases für den neuen Verteiler und für die verschiedenen Mailman-Funktionen anzulegen. Bei Hostsharing wird die Zustellung von E-Mails an Mailman anders geregelt: alle E-Mails an Mailman werden an erweiterte ''E-Mail-Adressen'' des Mailman-Users xyz00-listen geschickt. Diese Adressen haben die form xyz00-listen'''+'''<liste>[_funktion]. E-Mails an diese Adressen werden dann durch Pipe-Anweisungen in ''.forward-Dateien'' im Home-Verzeichnis des Mailman-Users mit den entsprechenden Argumenten an Mailman übergeben.

Falls Mailman von einem Paketuser (bspw. "xyz00-listen") installiert wurde, werden ''E-Mail-Adressen'' werden durch [https://doc.hostsharing.net/users/administration/hsadmin/index.html hsadmin (bzw. das Befehlszeielentool hsscript)] eingerichtet; die ''.forward-Dateien'' werden durch [[Login_mit_SSH|Shell-Befehle]] angelegt.

Das folgende Beispiel zeigt die Befehle, mit denen in einer interaktiven hsscript-Sitzung die E-Mail-Adressen für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten "mailman" durch den Namen der Mailingliste ersetzt.)

hsscript -u xyz00 -i
[hsscript verlangt die Eingabe des Passworts vom Paketadmin xyz00; dann können diese Befehle eingegeben werden:]
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman',target:'xyz00-listen+mailman'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-admin',target:'xyz00-listen+mailman-admin'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-bounces',target:'xyz00-listen+mailman-bounces'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-confirm',target:'xyz00-listen+mailman-confirm'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-join',target:'xyz00-listen+mailman-join'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-leave',target:'xyz00-listen+mailman-leave'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-owner',target:'xyz00-listen+mailman-owner'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-request',target:'xyz00-listen+mailman-request'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-subscribe',target:'xyz00-listen+mailman-subscribe'}})
emailaddress.add ({set:{domain:'listen.example.com',localpart:'mailman-unsubscribe',target:'xyz00-listen+mailman-unsubscribe'}})

Die korrekte Einrichtung der E-Mail-Adressen kann in der Web-Oberfläche von hsadmin kontrolliert werden.

Für jede der soeben eingerichteten Adressen wird nun eine .forward-Datei im Homeverzeichnis des Users xyz00-listen angelegt. Die Dateinamen bestehen aus der Zeichenfolge ".forward+" gefolgt vom Namen der ausführen soll. Der Inhalt der jeweiligen .forward-Datei legt die Weiterleitung der Mail durch einen Pipe an Mailman fest, mit dem jeweiligen Befehl als Argument:

"|/home/pacs/xyz00/users/listen/mailman/mail/mailman [Befehl] [Listenname]"

Zum Beispiel wird die .forward-Datei .forward+mailman-subscribe verwendet, wenn eine E-Mail an die Adresse mailman-subscribe@listen.example.com eingeht. Aufgrund der oben eingerichteten E-Mail-Adresse mit dem Ziel "xyz00-listen+mailman-subscribe" wertet der Mail-Transfer-Agent die .forward-Datei .forward+mailman-subscribe im Home-Verzeichnis des Users xyz00-listen aus, und entsprechend ihrem Inhalt wird die Mail an die Mailman-Software mit den Argumenten "subscribe mailman" übergeben.

Das folgende Beispiel zeigt die Befehle, mit denen an der Befehlszeilenaufforderung der Shell die .forward-Dateien für die Hauptliste "mailman" eingerichtet werden. (Für spätere Mailinglisten wird in den Argumenten und in den Namen der .forward-Dateien "mailman" durch den Namen der Mailingliste ersetzt, jedoch '''nicht''' in der Pfadangabe zum Mailman-Programm selbst; diese ändert sich ja nicht.)

echo 'admin@xyz00.hostsharing.net' > .forward # Weiterleitung von cron Fehlern etc an Paketadmin.
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post mailman"' > .forward+mailman
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin mailman"' > .forward+mailman-admin
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces mailman"' > .forward+mailman-bounces
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm mailman"' > .forward+mailman-confirm
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join mailman"' > .forward+mailman-join
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave mailman"' > .forward+mailman-leave
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner mailman"' > .forward+mailman-owner
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request mailman"' > .forward+mailman-request
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe mailman"' > .forward+mailman-subscribe
echo '"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe mailman"' > .forward+mailman-unsubscribe

Die vielen Befehle können von dieser Anleitung kopiert und nach Anpassung auf den tatsächlichen Unsernamen in die SSH-Sitzung kopiert werden. Noch leichter ist es, mit einem Editor einen Shell-Skript namens ~/bin/addforwards mit folgendem Inhalt zu erstellen:

#!/bin/sh
# .forward-Dateien für einen Verteiler unter Mailman einrichten.
#
if [ "$1" = "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "$2" != "" ] ; then
echo "Aufruf: $0 Listenname\n"
exit
fi
if [ "`pwd`" != "`echo ~`" ] ; then
echo "Diesen Befehl vom Home-Verzeichnis aus aufrufen.\n"
exit
fi
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman post $1\"" > .forward+$1
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman admin $1\"" > .forward+$1-admin
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman bounces $1\"" > .forward+$1-bounces
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman confirm $1\"" > .forward+$1-confirm
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman join $1\"" > .forward+$1-join
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman leave $1\"" > .forward+$1-leave
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman owner $1\"" > .forward+$1-owner
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman request $1\"" > .forward+$1-request
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman subscribe $1\"" > .forward+$1-subscribe
echo "\"|/home/pacs/xyz00/users/listen/mailman/mail/mailman unsubscribe $1\"" > .forward+$1-unsubscribe
exit

Der Skript muß natürlich als ausführbar gekennzeichnet werden:

~$ chmod u+x bin/addforwards

Die Erweiterung dieses Skripts um die hsscript-Befehle wird dem Leser als Aufgabe überlassen.

=== Administration ===

Als erstes sollte man als Administrator der neuen Mailman-Installation die Liste "mailman" selbst abonnieren. Die Liste "mailman" kann aber unter https://listen.example.com/mailman/admin/mailman verwaltet werden.

Die Hauptseite der Mailman-Web-Verwaltung ist in unserem Beispiel (mit den oben angegebenen Rewrite-Anweisungen in der Datei .htaccess) https://listen.example.com/mailman/admin/. Diese Seite enthält Links zu den bisher eingerichteten Mailinglisten (außer "mailman") und einen Link, um neue Mailinglisten anzulegen (https://listen.example.com/mailman/create). Das Anlegen einer neuen Mailingliste geschieht entweder über diesen Link oder (wie oben) in der Shell mit dem Befehl:

~$ mailman/bin/newlist <Listenname>

In beiden Fällen müssen zusätzlich die E-Mail-Adressen und die .forward-Dateien wie bei dem Einrichten der Liste "mailman" nach Verfahren im obigen Abschnitt angelegt werden.

Für die Verwaltung der Mailinglisten im Alltag, d.h. den Umgang mit Bounces, Spam, Abonnenten usw., siehe u.a. die [https://wiki.list.org/ Mailman-Wiki].

== Feintuning ==

Wer will, kann auch noch etwas Platz sparen. Die normale Mailmaninstallation schlägt mit über 20 MB zu Buche...

Mit den folgenden Tips kann man das auf ca. 6 MB reduzieren :)

Es kann natürlich sein, dass ich zuviel lösche, aber bei mir funktioniert's. Wenn ihr also sicher(er) sein wollt, dass euch der Mailman nicht um die Ohren fliegt, macht das nicht!

* ~/mailman/cgi-bin und ~/mailman/icons können gelöscht werden, falls sie an andere Stelle kopiert worden sind.
* Die nicht benötigten Sprachen in ~/mailman/messages löschen.
* Die nicht benötigten Sprachen in ~/mailman/templates löschen (bis auf englisch).
* ~/mailman/tests kann, soweit ich das sehe, komplett gelöscht werden.
* Falls man koreanisch und japanisch nicht braucht, kann man folgendes machen:
* in ~/mailman/bin/paths.py, ~/mailman/cron/paths.py und ~/mailman/scripts/paths.py die Zeilen:

# In a normal interactive Python environment, the japanese.pth and korean.pth
# files would be imported automatically. But because we inhibit the importing
# of the site module, we need to be explicit about importing these codecs.
if not jaok:
import japanese
# As of KoreanCodecs 2.0.5, you had to do the second import to get the Korean
# codecs installed, however leave the first import in there in case an upgrade
# changes this.
if not kook:
import korean
import korean.aliases

auskommentieren.

Dann kann man ~/mailman/pythonlib/japanese, ~/mailman/pythonlib/korean, ~/mailman/pythonlib/korean.pth sowie ~/mailman/pythonlib/lib löschen.

Man kann auch noch die Debug-Informationen aus den binaries strippen:

strip ~/mailman/mail/mailman
strip ~/mailman/cgi-bin/*

Falls die CGIs nicht gesymlinkt wurden:

strip ~/doms/listen.example.com/cgi/mailman/*

== Multidomainfähigkeit ==

Seit Mailman 2.x kann eine Mailman-Installation unter gewissen Einschränkungen für mehrere Domains verwendet werden. Hier soll kurz gezeigt werden, was geht und wie es geht.

=== Anleitung ===

Logischerweise muss das Webfrontend (die CGIs) auf allen Domains installiert werden.

Wenn man nun Mailinglisten mit newlist neu anlegt, muss man den Hostnamen für das Webfontend mit angeben, und zwar so:

~$ mailman/bin/newlist listenname@listen.example.com

Es ist ggf. wichtig, dass in der mm_cfg.py eine entsprechende add_virtualhost-Direktive für www.example.com steht, die der Frontend-URL einen Host-Part für die Mailadressen zuordnet. Ist eine solche Direktive nicht vorhanden, so wird listen.example.com sowohl als URL für das Webfrontend wie auch als Hostpart für E-Mailadressen verwendet. (Was für separate aufgeschaltete Domains wie z.B. listen.example.com gerade zutrifft.)

Liegt das Frondend nicht auf der Maildomain ist es wichtig, dass ihr Mailman sagt, für welches die zugehörige Maildomain ist. Dies tut ihr in der Datei ~/mailman/Mailman/mm_cfg.py:

Also z.B.
DEFAULT_URL_HOST = 'www.example.com'
DEFAULT_EMAIL_HOST = 'listen.example.com'
add_virtualhost(DEFAULT_URL_HOST,DEFAULT_EMAIL_HOST)

und
add_virtualhost('www.zoopnet.de', 'lists.zoopnet.de')

Das bedeutet, dass Mailman per default davon ausgeht, dass alle Listen für die Domain example.com sind.
Alle weiteren add_virtualhost-Direktiven ordnen einem Hostnamen für das Webfrontend (z.B. www.zoopnet.de) einen Hostpart für die Adresse der Mailinglisten (z.B. lists.zoopnet.de) zu.

Tip von Raimund Specht: Lässt man den zweiten Parameter weg, also schreibt z.B. add_virtualhost('www.example.org'), dann benutzt Mailman als Hostpart alles was nach dem ersten Punkt steht, hier also example.org als Maildomain.

Prinzipiell war's das. Man muss die Listeneinträge natürlich immer in die richtige virtusertable eintragen, und für gleichnamige Mailinglisten auf verschiedenen Domains (mailman@*) verschidene +Ergänzungen bzw. aliase verwenden. :)

=== Probleme ===

Verschiedene Listen mit gleichem Namen (also z.B. liste@example1.com und liste@example2.com) sind mit Mailman 2.1 leider nicht möglich.

== Tips und Tricks ==

=== URL Änderungen ===
Nach URL Änderungen stimmen Links im Web-Interface nicht mehr und Listen werden nicht mehr angezeigt.
Es sind dann, zusätzlich zur Anpassung der mm_cfg.py, schon bestehende Listen und Archive mit folgendem Befehl zu aktualisieren:
~/mailman/bin/withlist -l -r fix_url <Listen_Name> -v -u <Neue_Url>
<Listen_Name> steht für die Mailingliste, die bearbeitet werden soll. <Neue_Url> für die neue URL/Webadresse des Webinterfaces.

=== Weitere Cron-Jobs zur Mailinglisten Verwaltung ===

Folgende Cronjobs helfen bei der Verwaltung und sind User freundlich:

< In Arbeit >

== Referenzen ==

Lösung zur installation als Domainadmin (xyz00-listen) statt Paketadmin (xyz00): https://lists.hostsharing.net/archiv/support/2009-June/019414.html 

Ältere Anleitung für Installation als Domain-Admin (xyz00-listen): <http://lists.hostsharing.net/archiv/support/2005-January/012426.html> 

"Kleine Tools" auf http://hs.andreasloesch.de/, wobei das 'pac-mm-install' wahrscheinlich nicht aktuell (genug) ist 

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Mailinglisten]]
[[Kategorie:E-Mail]]

Discourse installieren

2019-12-05T08:14:44Z

Hsh-marcsandlus: /* Cronjobs */

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

{{Textkasten|gelb|PostgreSQL Extensions|Die PostgreSQL-Datenbank braucht die extensions ``hstore`` und ``pg_trm``. Diese müssen vom hostsharing-support installiert werden.}}

Ansonsten liefe die Erstellung der Datenbank so:

su - postgres -c psql
CREATE DATABASE discourse;
CREATE USER discourse;
ALTER USER discourse WITH ENCRYPTED PASSWORD 'password';
ALTER DATABASE discourse OWNER TO discourse;
\connect discourse
CREATE EXTENSION hstore;
CREATE EXTENSION pg_trgm;

Entsprechende Funktionalität (von den extensions abgesehen) ist auch über den HSAdmin verfügbar.

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

cd
mkdir redis/etc redis/lib redis/log redis/run

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

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

== Installation von Ruby ==

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

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

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

starte neue Shell:

exec bash

Überprüfe rbenv-Installation

type rbenv

Installiere ruby-build als rbenv-Plugin

git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

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

rbenv install 2.4

== Installation von Discourse selber ==

Weiterhin Als User ''xyz00-discourse'':

cd ~
git clone https://github.com/discourse/discourse.git discourse
cd ~/discourse

Die stabile Version auschecken:

git checkout stable

Ruby Pakete installieren:

gem install bundler
bundle install -j$(getconf _NPROCESSORS_ONLN) --deployment --without development test

== Konfiguration der Discourse Software ==

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

cd ~/discourse
cp config/discourse_defaults.conf config/discourse.conf

Anpassen folgender Inhalte:

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

===TODO: Secrets setzen! ===
Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos

RAILS_ENV=production bundle exec rake secret

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

''config/sidekiq.conf''

=== Initialisieren der Datenbank ===

export SAFETY_ASSURED=1
# In Version 2.0.4 funktioniert db:migrate noch, ansonsten schema:load und seed nutzen!
#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

=== Kompilieren der Assets ===

RAILS_ENV=production bundle exec rails assets:precompile

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

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

APP_ROOT = '/home/pacs/xyz00/users/discourse/discourse'
daemonize false

== Starten der Dienste ==

Zum Start aller notwendigen Dienste wird in dieser Anleitung ''supervisor'' benutzt. Hier ein Beispiel für eine Datei ''~/supervisor/etc/supervisord.conf'' (überlange Zeilen werden hier im Wiki umgebrochen)

<nowiki>[supervisord]
logfile=/home/pacs/xyz00/users/discourse/supervisor/log/supervisord.log
logfile_maxbytes=50MB
logfile_backups=10
loglevel=error
pidfile=/home/pacs/xyz00/users/discourse/supervisor/run/supervisord.pid
minfds=1024
minprocs=200
childlogdir=/home/pacs/xyz00/users/discourse/supervisor/log/

[unix_http_server]
file=/home/pacs/xyz00/users/discourse/supervisor/run/supervisord.sock

[rpcinterface:supervisor]
supervisor.rpcinterface_factory = supervisor.rpcinterface:make_main_rpcinterface

[supervisorctl]
serverurl=unix:///home/pacs/xyz00/users/discourse/supervisor/run/supervisord.sock

[program:redis]
command=/usr/bin/redis-server /home/pacs/xyz00/users/discourse/redis/etc/redis.conf
stderr_logfile = /home/pacs/xyz00/users/discourse/supervisor/log/redis-stderr.log
stdout_logfile = /home/pacs/xyz00/users/discourse/supervisor/log/redis-stdout.log

[program:discourse-web]
directory=/home/pacs/xyz00/users/discourse/discourse
environment=RAILS_ENV="production"
command=/home/pacs/xyz00/users/discourse/.rbenv/shims/bundle exec puma -C config/puma.rb -b tcp://127.0.0.1:13000
stderr_logfile = /home/pacs/xyz00/users/discourse/supervisor/log/discourse-web-stderr.log
stdout_logfile = /home/pacs/xyz00/users/discourse/supervisor/log/discourse-web-stdout.log

[program:discourse-sidekiq]
directory=/home/pacs/xyz00/users/discourse/discourse
environment=RAILS_ENV="production"
command=/home/pacs/xyz00/users/discourse/.rbenv/shims/bundle exec sidekiq -C /home/pacs/xyz00/users/discourse/discourse/config/sidekiq.yml
stderr_logfile = /home/pacs/xyz00/users/discourse/supervisor/log/discourse-sidekiq-stderr.log
stdout_logfile = /home/pacs/xyz00/users/discourse/supervisor/log/discourse-sidekiq-stdout.log
</nowiki>

== Einrichten des Apache VHost ==

cd ~/doms/beispiel.discuss
rm -rf htdocs-ssl subs/www subs-ssl/www
ln -s ~/live/public htdocs-ssl
touch htdocs-ssl/.htaccess

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:

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]

== Cronjobs ==

''Cron'' wird genutzt, um nach dem Server reboot ''supervisord'' zu starten.

Einrichten der crontab mit ''cronttab -e''

HOME=/home/pacs/xyz00/users/discourse
MAILTO=discourse@beispiel.discuss
RAILS_ENV=production
NUM_DAYS=31

@reboot /usr/bin/supervisord -c /home/pacs/xyz00/users/discourse/supervisor/etc/supervisord.conf

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

=== Updates ===

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

==== Am Beispiel von 2.0.4 auf 2.1.0 ====

# 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 (git diff > /tmp/discourse.diff)
# Schauen, ob discourse (endlich :) ) eine neue Ruby-Version nutzt (z.B. in discourse_docker: image/discourse_fast_switch/Dockerfile , discourse: .rubocop
# git pull
# (Zur Sicherheit: git checkout stable)
# bundle
# RAILS_ENV=production bundle exec rake db:migrate
# RAILS_ENV=production bundle exec rake assets:precompile
# Services neu starten (Holzhammer: sv restart all)

==== Am Beispiel von 2.1.0 auf 2.2.0 ====

# 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; git diff > /tmp/discourse.diff)
# git pull (ggfs konflikte beheben)
# (Zur Sicherheit: git checkout stable)
# Schauen, ob discourse (endlich :) ) eine neue Ruby-Version nutzt (z.B. in discourse_docker: image/discourse_fast_switch/Dockerfile , discourse: .rubocop
# Dies ist der Fall, also
# rbenv install 2.5
# rbenv rehash
# echo "2.5.2" > .ruby-version
# gem update --system
# bundle
# RAILS_ENV=production bundle exec rake db:migrate
# RAILS_ENV=production bundle exec rake assets:precompile
# Services neu starten (Holzhammer: sv restart all)

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

== Historie ==

* 2018, 14 . September: Initiale Fassung
* 2019, Januar: Update-Informationen ergänzt

----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Webforen]]

Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Google Cloud SDK

2019-11-26T17:04:46Z

Hsh-marcsandlus: Die Seite wurde neu angelegt: „Diese Anleitung beschreibt die Installation der Google Cloud SDK und folgt dabei im wesentlichen der [https://cloud.google.com/sdk/docs/quickstart-linux?hl=de…“

Diese Anleitung beschreibt die Installation der Google Cloud SDK und folgt dabei im wesentlichen der [https://cloud.google.com/sdk/docs/quickstart-linux?hl=de Google-Anleitung].

== Schritt 1: Eigenen User-Account anlegen ==

Diese Schritt ist optional, erhöht aber durch die Trennung von den übrigen Anwendungen des Users die Sicherheit.

Nach dem Einloggen per ssh auf dem
<nowiki># Einloggen von außerhalb in das Webpaket bei hostsharing:
ssh -p 222 xyz@xyz00.hostsharing.net

# Anlegen eines neuen Unter-Users mittels hsadmin:
TODO
</nowiki>

== Schritt 2: Download und Entpacken des Softwarepakets ==

Ausführen als User, unter dem die Google Cloud SDK ausgeführt werden soll, z.B. durch
<nowiki>sudo -u xyz00-gcloud bash -i # (es sollte keine Passwortabfrage erscheinen)</nowiki>

<nowiki># Anlegen des Installationsverzeichnisses:
mkdir google-cloud-sdk

# Wechsel in dieses Verzeichnis
cd google-cloud-sdk

# Download des Installationspakets
# Hinweis 1: Der Link muss an die aktuelle Version angepasst werden, zum Zeitpunkt des Schreibens war es https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-245.0.0-linux-x86_64.tar.gz
# Der aktuelle Link findet sich unter https://cloud.google.com/sdk/docs/quickstart-linux?hl=de
# Hinweis 2: Der Link ist für Webpakete mit 32-Bit ebenfalls anzupassen.
curl -O https://dl.google.com/dl/cloudsdk/channels/rapid/downloads/google-cloud-sdk-VERSION-linux-x86_64.tar.gz

# Entpacken des Installationspakets:
tar zxvf google-cloud-sdk*.tar.gz google-cloud-sdk

# Ausführen des Google-Installationsskripts
# Das Skript fragt spezielle Konfigurationswünsche ab, die alle
# mit ihren Standardantworten akzeptiert werden können
./google-cloud-sdk/install.sh</nowiki>

Danach sollte man sich kurz ausloggen und erneut einloggen, weil sonst das Kommando <nowiki>gloud</nowiki> nicht gefunden wird:

<nowiki># Ausloggen:
exit

# Einloggen:
sudo -u xyz00-gcloud bash -i</nowiki>

== Schritt 3: Konfiguration ==

Die weitere Konfiguration kann nun interaktiv durchgeführt werden:

<nowiki>gcloud init</nowiki>

Hilfreich dabei ist auch Google-Anleitung [https://cloud.google.com/sdk/docs/quickstart-linux?hl=de]

== Schritt 4: Testen ==

== Schritt 5: Tipps für die Zeit nach der Installation ==

Da die Software vom User installiert wird, muss er auch dafür sorgen, dass sie auf dem aktuellen Stand bleibt. Die Eingabe von
<nowiki>gcloud version</nowiki>
zeigt die aktuell installierte Version an und gibt ggfs. auch den Hinweis und den genauen Kommandozeilenbefehl, sie zu aktualisieren:
<nowiki>gcloud components update</nowiki>

TODO Deinstallation

Benutzer:Hsh-marcsandlus/Erfolgsrezepte

2019-11-26T16:09:19Z

Hsh-marcsandlus:

== Erfolgsrezepte / Best practices für die Installation von Softwarepaketen auf hostsharing.net ==

Vorgestellt werden die Schritte, um eine bestimmte Software mit '''geringem technischen Aufwand bzw. Vorwissen''', aber '''sicher''' auf den Servern von [https://hostsharing.net/ hostsharing.net] zu installieren.

Die meisten Erfolgsrezepte bestehen aus den fünf Schritten

# Anlegen von nötigen (Unter-) Usern, Domains und Datenbanken mittels HSAdmin
# Download des entsprechenden aktuellen Softwarepakets
# Konfigurationsanpassungen
# Testen
# Tipps für die Zeit nach der Installation

Mit der Installation kann auch unser [https://www.hostsharing.net/service/webmaster-on-demand/ Webmaster-on-demand] beauftragt werden.

* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Allgemeines|Allgemeines]]

* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Dokuwiki|Dokuwiki]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Contao|Contao]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Matomo|Matomo]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Wordpress|Wordpress]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Drupal|Drupal]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Joomla|Joomla]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Typo3|Typo3]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Google Cloud SDK|Google Cloud SDK]]

Benutzer:Hsh-marcsandlus/Erfolgsrezepte

2019-11-26T11:56:22Z

Hsh-marcsandlus: /* Erfolgsrezepte / Best practices für die Installation von Softwarepaketen auf hostsharing.net */

Benutzer:Hsh-marcsandlus/Erfolgsrezepte

2019-11-26T11:27:30Z

Hsh-marcsandlus: /* Erfolgsrezepte / Best practices für die Installation von Softwarepaketen auf hostsharing.net */

== Erfolgsrezepte / Best practices für die Installation von Softwarepaketen auf hostsharing.net ==

Vorgestellt werden die Schritte, um eine bestimmte Software mit '''geringem technischen Aufwand bzw. Vorwissen''', aber '''sicher''' auf den Servern von [https://hostsharing.net/ hostsharing.net] zu installieren.

Die meisten Erfolgsrezepte bestehen aus den fünf Schritten

# Anlegen von nötigen (Unter-) Usern, Domains und Datenbanken mittels HSAdmin
# Download des entsprechenden aktuellen Softwarepakets
# Konfigurationsanpassungen
# Testen
# Tipps für die Zeit nach der Installation

* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Allgemeines|Allgemeines]]

* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Dokuwiki|Dokuwiki]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Contao|Contao]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Matomo|Matomo]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Wordpress|Wordpress]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Drupal|Drupal]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Joomla|Joomla]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Typo3|Typo3]]

Benutzer:Hsh-marcsandlus/Erfolgsrezepte

2019-11-26T09:04:05Z

Hsh-marcsandlus: /* Erfolgsrezepte / Best practices für Installation von Softwarepaketen auf hostsharing.net */

== Erfolgsrezepte / Best practices für die Installation von Softwarepaketen auf hostsharing.net ==

* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Allgemeines|Allgemeines]]

* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Dokuwiki|Dokuwiki]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Contao|Contao]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Matomo|Matomo]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Wordpress|Wordpress]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Drupal|Drupal]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Joomla|Joomla]]
* [[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Typo3|Typo3]]

Benutzer:Hsh-marcsandlus/Erfolgsrezepte

2019-11-26T09:00:56Z

Hsh-marcsandlus: Die Seite wurde neu angelegt: „ == Erfolgsrezepte / Best practices für Installation von Softwarepaketen auf hostsharing.net == Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Allgemeines Ben…“

== Erfolgsrezepte / Best practices für Installation von Softwarepaketen auf hostsharing.net ==

[[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Allgemeines]]
[[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Dokuwiki]]
[[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Contao]]
[[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Matomo]]
[[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Wordpress]]
[[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Drupal]]
[[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Joomla]]
[[Benutzer:Hsh-marcsandlus/Erfolgsrezepte/Typo3]]

Benutzer:Hsh-marcsandlus

2019-11-26T08:57:32Z

Hsh-marcsandlus: /* Einstiegsseite für Marc O. Sandlus */

== Einstiegsseite für Marc O. Sandlus ==

[[Benutzer:Hsh-marcsandlus/Erfolgsrezepte]]

Benutzer:Hsh-marcsandlus

2019-11-26T08:56:23Z

Hsh-marcsandlus: Die Seite wurde neu angelegt: „== Einstiegsseite für Marc O. Sandlus ==“

== Einstiegsseite für Marc O. Sandlus ==

Matomo Installieren

2019-11-25T17:31:17Z

Hsh-marcsandlus: /* Abschnitt 3.2 "Widerspruchsmöglichkeit bereitstellen" */

[http://piwik.org/ Piwik] ist eine Open Source-Alternative zu Google Analytics und anderen Analysetools. Es kann datenschutzkonform eingerichtet werden und ist mandantenfähig. In Piwik eingerichtete User sehen nur die Daten der für sie freigeschalteten Domains.

Dabei ist eine Installation von Piwik für alle zu analysierenden Webseiten ausreichend. Zum Einrichten von weiteren Webseiten, die Piwik überwachen soll, siehe [[Piwik]].

Piwik benötigt serverseitig [[PHP]] und [[MySQL]] (oder [[PostgreSQL]]) und setzt im Default clientseitig JavaScript voraus. Statische Zählpixel sind alternativ möglich.

== Download und Installation ==

$ cd
$ wget http://piwik.org/latest.zip
$ unzip latest.zip
$ mv piwik /home/pacs/xyz00/users/otto/doms/mydomain.de/subs/www/.

=== Apache Rewrite ===

Bei einer Installation von komplexen Anwendungen wie z.B. [[Plone]] kann es notwendig sein, die Zugriffe auf den Unterordner piwik vor anderen RewriteRule-Anweisungen einzufügen, damit die Installation erreicht werden kann:

$ vim /home/pacs/xyz00/users/otto/doms/mydomain.de/subs/www/.htaccess

RewriteBase /
RewriteCond %{SERVER_PORT} ^80$
RewriteCond %{REQUEST_URI} !=/index.php
RewriteRule ^piwik/(.*)$ piwik/$1 [L,PT]

=== Installationsassistent ===

Dann die Seite http://www.mydomain.de/piwik aufrufen und den Installationsassistenten durchklicken. Hierbei müssen Fragen zur MySQL-Anbindung, dem Piwik-Superuser und der ersten Webseite, die in Piwik ausgewertet werden soll, beantwortet werden. Der Assistent weist mit deutlicher Farbgebung und einem "Fortschrittsbalken" auf den Fortschritt der Installation hin.

Piwik behauptet von sich eine "5-Minuten-Installation" zu ermöglichen ([http://de.piwik.org/dokumentation/piwik-installieren/ offizielle Installationsanleitung]).

Für die Installation sind die Anleitungen von Hostsharing zum Anlegen und Verwalten von [[Datenbanken]] hilfreich. Folgende Angaben müssen für Piwik bereitgehalten werden:
* Adresse des Datenbankservers ("localhost")
* der Name der angelegten Datenbank
* der vergebene DB-Benutzername (z.B. xyz00_otto)
* das DB-Passwort, das beim Anlegen dieser Datenbank für xyz00_otto vergeben wurde)
* ein (optionales) Datenbank-Prefix (Voreinstellung: piwik_)

Danach wird ein Superuser-Account angelegt, der über einen frei definierbaren Benutzernamen, ein Passwort und eine Mailadresse definiert wird.

Standardmäßig werden Daten der ersten Webseite, die erfasst werden soll, mit abgefragt. Wichtigste Angaben sind Name und URL.

== Datenschutz ==

Um die Installation gemäß deutschen Rechts datenschutzkonform zu halten empfiehlt sich eine Anpassung gemäß der Vorgaben des [https://www.datenschutzzentrum.de/ Unabhängigen Datenschutzzentrums Schleswig-Holstein], die [https://www.datenschutzzentrum.de/uploads/projekte/verbraucherdatenschutz/20110315-webanalyse-piwik.pdf als PDF heruntergeladen werden] kann.

Das gesamte Dokument wird zum Lesen empfohlen. Hieraus sind u.a. wichtig:

=== Abschnitt 3.1 "Plugin AnonymizeIP einsetzen" ===

Hierfür ist im Piwik-Menü als superuser das Plugin zu aktivieren: Einstellungen > Plugins > AnonymizeIP aktivieren. Die Anzahl der zu kürzenden Oktale gibt man über eine Konfiguration in config/config.ini.php an:
<pre>
[Tracker]
ip_address_mask_length = 2
</pre>

Mit dieser Einstellung wird die IP-Adresse z.B. als 89.247.0.0 angezeigt. Siehe hierzu die Erläuterungen im oben verlinkten PDF. Nach Abschnitt 3.6 soll die Lebensdauer der Cookies auf kleine Werte, z.B. weniger als 1 Woche (640800 Sekunden) gesetzt werden.

<pre>
[Tracker]
ip_address_mask_length = 2
cookie_expire = 640800
</pre>

=== Abschnitt 3.2 "Widerspruchsmöglichkeit bereitstellen" ===

Piwik ermöglicht opt-out mittels der Nutzung eines Cookies. Die Möglichkeit hierzu ist dem User der Webseite bereitzustellen. Die Einbindung erfolgt über einen IFrame, dessen Code im Piwik unter Einstellungen > Allgemeine Einstellungen > "Piwik-Deaktivierung für Ihre Besucher" zu finden ist.

<pre>
<iframe frameborder="no" width="600px" height="200px" src="http://www.example.com/x_piwik/index.php?module=CoreAdminHome&action=optOut&language=de"></iframe>
</pre>

Siehe auch hierzu die Erläuterungen im oben verlinkten PDF.

----

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:Piwik]]

PHP

2019-11-25T17:23:35Z

Hsh-marcsandlus:

PHP wird heute bei HS standardmäßig per FastCGI vorkonfiguriert. Dafür wird in jedem Domainverzeichnis unter fastcgi/ eine phpstub Datei angelegt und der Apache Webserver ist konfiguriert .php Dateien über diesen "Stub" mit den Rechten des Users auszuführen.

Zur Wiederherstellung des originalen phpstub ist dieser zentral abgelegt als

/usr/local/src/phpstub

Anwender, die lediglich PHP-Dateien hochgeladen haben, brauchen ausdrücklich keine eigene php.ini.

=== Anpassung der PHP Grundkonfiguration ===

Um die PHP Konfiguration an eigene Bedürfnisse anzupassen, legt man eine Konfigurationsdatei namens php.ini im fastcgi Verzeichnis der Domain an (für https:// entsprechend im -ssl Verzeichnis). In dieser Datei müssen nicht alle Konfigurationsoptionen von PHP definiert sein, sondern nur die, die sich gegenüber der Standard php.ini ändern sollen. Diese liegt in /etc/php/VERSION/cgi und kann dort eingesehen werden.

'''Achtung:''' Kommentare nicht mit # einleiten (kann zu unerwarteten Fehlkonfigurationen führen), Kommentarzeichen ist das Semikolon ";".

Häufig anzupassen sind z.B.:

* die Content-Type charset= Vorgabe für den HTTP Header.

* der maximal verwendbare Hauptspeicher (memory_limit).

* die maximale Größe hochgeladener Dateien (post_max_size).

* die aktiven Extensions.

Beispiel einer php.ini:

<pre>
------8< SCHNIPP >8------
[..]
memory_limit = 128M (default)
post_max_size = 8M (default)
upload_max_filesize = 2M (default)

[..]
default_charset = "UTF-8"
; (ist sonst iso-8859-1)
; Der charset kann aber wiederum durch einen Funktionsaufruf
; header("Content-Type: text/html; charset=iso-8859-1")
; im PHP-Skript überschrieben werden (sofern output_buffering = On).
------8< SCHNIPP >8------
</pre>

'''Beachte:''' Eine geänderte php.ini Konfiguration wird mit FastCGI erst übernommen, wenn die PHP Prozesse des Users (die über längere Zeit laufen bleiben) neu gestartet werden.

Die Brechstange, mit der das Neustarten der PHP Prozesse erzwungen werden kann, ist diese zu killen:
<pre>
killall php -u $USER
</pre>
$USER = ist der aktuell angemeldeten Benutzer und muss nicht durch den Benutzernamen (xyz00 oder xyz00-user) ersetzt werden. Nur die Prozesse der $USER werden gelöscht.

=== PHP Sicherheit ===

==== open_basedir ====

Sofern der PHP Parameter open_basdir nicht gesetzt ist (Vorgabe) können (kompromittierte) php Skripte an alle Dateien kommen des Users kommen, ohne einen extra Shellzugang installieren zu müssen und dadurch entdeckt zu werden.

Die Passwortabfrage von Hsadmin bringt eine Abhilfe für die zentralen Dienste. (Sofern Du dein Passwort nicht in eine Datei schreibst und die Abfrage so wieder ausschaltest, wovon besser abzusehen ist.) Doch alle Daten auf die Du als Benutzer zugreifen kannst sind prinzipiell den PHP-Skripten ausgeliefert.

Mit open_basedir wird festgelegt in welchen Verzeichnissen PHP Skripte lesen und schreiben dürfen. Geprüft wird dabei ob der zu öffnende Pfad mit dem angegebene Pfad beginnt. Es ist daher wichtig ob sich am Ende ein "/" befindet oder nicht. Ein open_basedir von /home/doms/example.org/subs/www (ohne /) erlaubt somit z.B. auch Zugriffe auf die Subdomain www2 etc.

Beispielzeile für die php.ini:
open_basedir = /home/doms/example.org/subs/

Wenn man mehrere Subdomains hat und diese isolieren möchte, ist dies durch Aufschaltung von lokalen Subdomains auf verschiedene User möglich. (Siehe https://doc.hostsharing.net/users/administration/domain/index.html )

==== safe_mode ====
{{Textkasten|rot|Veraltete Option|Die Verwendung des Safe Mode wird explizit '''nicht''' empfohlen. Mit PHP 5.3.0 ist der Safe Mode veraltet, in PHP 6 gibt es diese Option nicht mehr.}}

Dank (Fast)CGI laufen PHP Skripte zwar "nur" mit Userrechten, dennoch ist es ratsam, den PHP safe_mode zu aktivieren, sofern dies mit den eingesetzten PHP Skripten möglich ist. Der safe_mode kann auch die Daten des Users vor (kompromittierten) PHP Skripten schützen. In der php.ini ist dafür die Option

safe_mode = On

zu setzten, und die weiteren Optionen sind zu prüfen.

Falls Systembefehle oder Shellskripte ausgeführt werden müssen, sollten diese über ein extra safe_mode_exec_dir außerhalb des open_basedir bereitgestellt werden (z.B. ~/priv/bin).

==== Sicherheitskritische Funktionen ====

Weitere Dinge die deaktiviert werden sollten, wenn sie nicht benötigt werden, was im allgemeinen der Fall ist, sind: Das öffnen von URLs als Dateien,

allow_url_fopen = Off

und die Ausführung von Systembefehlen.

disable_functions = show_source, system, passthru, shell_exec, exec, phpinfo, popen, proc_open

=== eigene PHP Konfigurationen und verschiedene nebeneinander verwenden ===

Um verschiedene PHP Konfigurationen nebeneinander zu verwenden, kopierst Du den phpstub in ein Unterzeichnis von (fast)cgi(-ssl) und mappst (Einträge in der .htaccess) nach Belieben deine PHP Dateien darauf.
So können beliebig viele Konfigurationen bei einer Domain nebeneinander genutzt werden.

==== Beispiel muster.example.com ====
<pre>
mkdir ~/doms/example.com/fastcgi/muster
cp ~/doms/example.com/fastcgi/phpstub ~/doms/example.com/fastcgi/muster/phpstub

und wenn benötigt:
vi ~/doms/example.com/fastcgi/muster/php.ini
</pre>

Anschließend muss der Apache Webserver noch angewiesen werden auch diese bestimmte Konfiguration von PHP zu verwenden. Dazu werden der [[.htaccess]] Datei im DocumentRoot der Sub-Domain zwei Zeilen hinzugefügt bzw. eine .htaccess mit den zwei Zeilen angelegt.
Im Beispiel handelt es sich um die Domain muster.example.com, also:

<pre>
cd ~/doms/example.com/subs/muster
vi .htaccess

AddType application/x-httpd-phpfastcgi .php
Action application/x-httpd-phpfastcgi /fastcgi-bin/muster/phpstub
</pre>

== Vorinstallierte PHP Version wechseln ==
Hostsharing bietet neben der aktuellen (2019-04-15) Standardversion 7.0.x auch PHP 7.1, 7.2, und 7.3 an.

Um die Version zu wechseln, genügt es, den jeweiligen phpstub auszutauschen. Version 7.3 liegt unter <code>/usr/local/src/phpstub/phpstub73</code>; das Versionformat ist entsprechend <code>/usr/local/src/phpstub/phpstubXX</code>.

===phpstub für PHP 7.3 kopieren===

<pre>
$ cp /usr/local/src/phpstub/phpstub73 ~/doms/example.com/fastcgi/
$ cp /usr/local/src/phpstub/phpstub73 ~/doms/example.com/fastcgi-ssl/
</pre>

===phpstub für PHP 7.3 aktivieren===

In der jeweiligen <code>.htaccess</code> eines Ordners genügt, die PHP Dateizuordnung zu überschreiben:

<pre>
AddType application/x-httpd-php73 .php
Action application/x-httpd-php73 /fastcgi-bin/phpstub73
</pre>

Damit wird für den aktuellen Ordner und alle Unterordner PHP 7.3 verwendet.

Auf die gleiche Weise können auch PHP 7.2 oder PHP 7.1 aktiviert werden

== Eigene PHP Version ==
Es kann auch eine eigene PHP Version im Paket installiert werden.
Eine kurz Anleitung ist unter [[Eigene_PHP_Version]] beschrieben.

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

Nextcloud

2019-11-25T17:20:11Z

Hsh-marcsandlus: /* Nextcloud beschleunigen */

= Nextcloud installieren =

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:

hsscript -u xyz00 -i
Password: ********

Dann nacheinander anlegen:

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

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'}})

== Nextcloud installieren ==

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

ssh -l xyz00-cloud xyz00.hostsharing.net

''htdocs'' Verzeichnis vorbereiten

cd
mkdir nextcloud
cd doms/cloud.example.org
rm -rf subs/www subs-ssl/www htdocs-ssl
ln -s $HOME/nextcloud htdocs-ssl

Nextcloud herunterladen und entpacken.

cd
wget https://download.nextcloud.com/server/releases/nextcloud-16.0.4.zip
unzip nextcloud-16.0.4.zip
rm nextcloud-16.0.4.zip
mkdir data tmp
chmod 700 data tmp

== Nextcloud konfigurieren ==

Zur Zeit muss für Nextcloud PHP in der Version 7.3 manuell aktiviert werden. Eine Anleitung dazu findet sich auf der Seite [[PHP#Vorinstallierte_PHP_Version_wechseln]]

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

session.save_path=/home/pacs/xyz00/users/cloud/tmp
opcache.enable=1
opcache.enable_cli=1
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=10000
opcache.memory_consumption=128
opcache.save_comments=1
opcache.revalidate_freq=1

Dann mit einem Editor diese Datei bearbeiten: In der erste 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
* Das Verzeichnis "/home/pacs/xyz00/users/cloud/data/" als Daten-Verzeichnis

== 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 ist auf den Hostsharing-Servern vorinstalliert und wird von den Nextcloud-Entwicklern empfohlen. In Verbindung mit einem Shared Webspace muss Redis als eigener Server Daemon angemeldet werden und ist kostenpflichtig. Mit dem Hostsharing-Service wird ein IP-Port für die Nutzung von Redis vereinbart.

Für den Redis-Dienst lege ich folgende Struktur an:

cd ~
mkdir -p ~/redis/etc
mkdir -p ~/redis/var

In ''~/redis/etc'' lege ich eine Konfigurationsdatei ''redis.conf'' für den Redis-Dienst ab:

daemonize yes
pidfile /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid
requirepass mein-redis-passwort
port 32123
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/cloud/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/cloud/redis/var

Den Start und das Monitoring des Redis-Dienstes übernimmet ''monit''. Hier eine geeignete Datei ''~/.monitrc'':

set daemon 60
with start delay 120
set logfile /home/pacs/xyz00/users/cloud/monit/var/monit.log
set idfile /home/pacs/xyz00/users/cloud/monit/var/monit.id
set statefile /home/pacs/xyz00/users/cloud/monit/var/monit.state
set mailserver localhost
set mail-format { from: monit@cloud.example.com }
set alert webmaster@example.com
set httpd port 32123 address xyz00.hostsharing.net
allow nextcloud:mein-monit-passwort
check process redis with pidfile /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid
start program "/usr/bin/redis-server /home/pacs/xyz00/users/cloud/redis/etc/redis.conf"
stop program "/bin/bash -c '/bin/kill $( cat /home/pacs/xyz00/users/cloud/redis/var/redis-server.pid )'"

Verzeichnis für ''monit'' anlgegen:

cd ~
mkdir -p monit/var

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

'memcache.distributed' => '\\OC\\Memcache\\Redis',
'memcache.locking' => '\\OC\\Memcache\\Redis',
'redis' =>
array (
'host' => '127.0.0.1',
'port' => 32123,
'password' => 'mein-redis-passwort',
'timeout' => 1.5,
),

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

compress
/home/pacs/xyz00/users/cloud/redis/var/redis.log {
rotate 5
daily
missingok
}
/home/pacs/xyz00/users/cloud/monit/var/monit.log {
rotate 2
weekly
missingok
}

Eine Crontab sorgt für den Start von Monit und das tägliche Rotieren der Logdateien:

# m h dom mon dow command
HOME=/home/pacs/xyz00/users/cloud
PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
MAILTO=webmaster@example.com
@reboot /usr/bin/monit -c $HOME/.monitrc
1 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate
1,16,31,46 * * * * /usr/bin/php7.3 $HOME/nextcloud/cron.php

Die letzte Zeile der ''crontab'' enthält den Cronjob für die regelmäßigen Hintergrundprozesse der Nextcloud. Durch die Erledigung dieser Aufgaben mit Cron lässt sich die Nextcloud ebenfalls etwas beschleunigen.

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

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