Hostsharing Wiki - Benutzerbeiträge [de]

Phusion Passenger

2026-03-28T10:21:19Z

Sib: kleine Anpassungen an der Beschreibung

Phusion Passenger ist ein Apache-Plugin zur Integration von Apps auf Domain (vhost) Ebene.
Dabei kann es sich z.B. um [[NodeJS]], [[RubyOnRails]], [[Django|Django]] oder weitere Laufzeitumgebungen handeln.

== Aktivierung / Deaktivierung ==

Das Passenger-Modul wird über eine Domain-Option in HSAdmin aktiviert. Nach der Aktivierung werden Anwendungen im Verzeichnis "app" bzw. "app-ssl" unter der aufgeschalteten Domain im Phusion Passenger ausgeführt

Phusion Passenger ist immer für die gesamte aufgeschaltete Domain aktiviert,
die Bereitstellung einer App wirkt also auch auf Subdomains im Verzeichnis 'subs'.
Insbesondere wird damit PHP für die jeweilige Domain deaktiviert.
Statische Dateien (z.B. index.html) aus htdocs* und subs* sind davon nicht betroffen.
Idealerweise wird für jede App eine eigene Subdomain mit HSAdmin aufgeschaltet.

Sobald eine App einmal geladen ist, sind die Settings und Mappings Bestandteil der transienten Apache vhost-Konfiguration. Änderungen an .htaccess-Settings bzgl. Passenger kommen dann nicht mehr direkt zum Tragen, weil die .htaccess zu Gunsten der Effizienz nicht mehr ausgewertet wird.

Zum Deaktivieren einer App muss diese im app und app-ssl Verzeichnis gelöscht werden.

== Konfiguration ==

Die Auswahl des Interpreters für die Skriptsprachen Python, Ruby und JavaScript (NodeJS) für die Ausführung Apache-Passenger-Modul erfolgt über Variablen "PassengerPython", "PassengerRuby" und "PassengerNodejs" in der Apache-VHost-Definition für die Domain. Der Inhalt dieser Variablen wird über HSAdmin im Dialog "Domain ändern" gesteuert.

Die Voreinstellungen sind:
<syntaxhighlight lang=apache>
PassengerPython /usr/bin/python3

PassengerRuby /usr/bin/ruby

PassengerNodejs /usr/bin/node
</syntaxhighlight>
Eigene Konfigurationen wären zum Beipiel (Für den Webspace "xyz00" und den User "xyz00-example"):
<syntaxhighlight lang=apache>
PassengerNodejs /home/pacs/xyz00/users/example/.nvm/versions/node/v20.11.0/bin/node
</syntaxhighlight>
oder
<syntaxhighlight lang=apache>
PassengerRuby /home/pacs/xyz00/users/example/.rbenv/shims/ruby
</syntaxhighlight>
oder
<syntaxhighlight lang=apache>
PassengerPython /home/pacs/xyz00/users/example/my_venv/bin/python
</syntaxhighlight>
(Nähere Informationen bitte den jeweiligen Wiki-Seiten über die spezifischen Laufzeitumgebungen entnehmen.)

Die Einstellung "PassengerFriendlyErrorPages on" kann ebenfall in HSAdmin als Domain-Option aktiviert werden. Nach dem Abschluss des Debugging sollte die Option wieder abgeschaltet werden!

== Neueinlesen der Konfiguration / Restart der App ==

Über den <code>passenger-config</code>-Befehl: 
⚠️ Hinweis: sudo -u reicht hier nicht aus. Beispielsweise su - xyz00-anwendung verwenden damit die App erkannt wird. ⚠️
<syntaxhighlight lang=output>
xyz00-anwendung@host:~$ passenger-config restart-app
Please select the application to restart.
Tip: re-run this command with --help to learn how to automate it.
If the menu doesn't display correctly, press '!'

‣ /home/doms/anwendung.domain/app-ssl/ (production)
Cancel
</syntaxhighlight>
Die gewünschte Anwendung jetzt nurnoch mit <code>Enter</code> bestätigen.

Über eine Trigger-Datei:

Passenger Apps werden wir folgt neu gestartet oder neu geladen:
<syntaxhighlight lang=shell>
mkdir app(-ssl)/tmp
touch app(-ssl)/tmp/restart.txt
</syntaxhighlight>
Das führt nach einer Weile zu einem graceful Restart der App.
D.h., die einzelnen Prozesse werden sukzessive zwischen der Bedienung von HTTP-Requests neu gestartet.
Im Rahmen dieses Restarts sollten geänderte .htaccess Direktiven ihre Wirkung entfalten.
Entsprechendes gilt für Änderungen an der Applikation selbst.

== Minimale Programme für Tests von Passenger ==
* Python: siehe [[Eigenes_Python_installieren#Python_Web_Applikation_mit_Passenger]]
* Node: siehe [[NodeJS#NodeJS_Web-Applikation]]
* Ruby: siehe [[RubyRBEnv#Ruby_Web_Applikation_mit_Passenger]]

== Links ==

* weitere Tipps und Beispiel für die Programmiersprachen Python und Ruby in der Support Mailingliste: [https://lists.hostsharing.net/archiv/support/2015-January/066080.html]

----
[[Kategorie:HSDoku]]
[[Kategorie:Passenger]]

Mitglieder-Quellen

2026-01-22T11:36:48Z

Sib: refactor

'''Aktivitäten-Sammlung der Hostsharing Mitglieder-Gemeinschaft'''

'''Frage''': Hast du dich schon mal gefragt, ob du in der '''Hostsharing Mitglieder-Gemeinschaft'''
(etwa 300 Mitglieder Stand Januar 2026)
das einzige Mitglied bist,
welches sich mit Software XYZ befasst?

'''Antwort''': Hier findest du es heraus! Diese Aktivitäten-Sammlung,
aus der Mitglieder-Gemeinschaft der
[https://www.hostsharing.net Hostsharing eG],
bieten Interessenten die Möglichkeit,
in kooperativer Anstrengung,
die gemeinsame IT-Infrastruktur von '''Hostsharing''' weiterzuentwickeln.

Diese Sammlung stammt aus der gemeinschaftlich betriebenen IT-Infrastruktur von '''Hostsharing'''. An dieser Stelle ist es nicht von Bedeutung, ob sie auch mit anderer Infrastruktur kompatibel ist.

Möchtest du mit deiner Aktivität zu dieser Sammlung beitragen? Keine falsche Bescheidenheit! Bitte bearbeite diese Seite direkt selbst oder bitte ein anderes Mitglied um Unterstützung. Danke!

== Dokumentation ==

WiP

== Erfahrung ==

* [[Anwendungen_mit_Ansible_installieren|Ansible]]: [[User:sib|sib]], [[User:tim00|tim00]]
* [[CiviCRM_installieren|CiviCRM]]: [[User:tim00|tim00]]
* [[Gitea]]: [[User:sib|sib]]
* [[Mlmmj]]: [[User:sib|sib]]
* [[Nextcloud]]: [[User:sib|sib]], [[User:tim00|tim00]]
* [[Eigenes_Python_installieren|Python]]: [[User:tim00|tim00]]
* OpenPetra: [[User:tim00|tim00]]
* [[Roundcube]]: [[User:sib|sib]]

== Konfiguration ==

* [https://github.com/seb-schulz/cert-manager-webhook-hostsharing ACME Webhook für Cert Manager]
* [https://codeberg.org/tpokorra/hs.ansible Automatisierung mit Ansible]
* [https://github.com/sebatec-eu/config-mate Sebatec: Go-Konfiguration]
* [https://github.com/sebatec-eu/ssh-deploy-action Sebatec: Wiederverwendbar GitHub Action für SSH-Installation]
* [https://github.com/seb-schulz/hostsharing-dyndns Service-Konfiguratin für DynDNS]

== Plattform ==

WiP

== Service ==

* [https://solidevereine.de/organisation/nextcloud/#highperf Solidevereine: Nextcloud High Performance Backend (HPB) für Nextcloud Talk]
* [https://nextcloud.ossaas.de Solidevereine: OS SaaS (Open Source Software as a Service): Nextcloud]
* [https://openpetra.ossaas.de Solidevereine: OS SaaS (Open Source Software as a Service): OpenPetra]
* [https://www.swingbe.de/service/engineering SwIngBe: Full-Service-IT-Dienstleistungen]

== Software ==

WiP

Benutzer:Sib

2026-01-22T11:28:05Z

Sib: refactor

Das ist die Wiki-Seite vom Mitglied '''[https://swingbe.de Software Ingenieur Begerad(SiB)]'''.

Was '''SiB''' im Allgemeinen den Kunden anbietet,
wird
(aus unterschiedlichen Perspektiven)
auf der '''[https://www.swingbe.de/offer Angebot]'''
-Seite präsentiert.

Dienstleistungen hat '''SiB''' auf der '''[https://www.swingbe.de/service Leistungen]'''
-Seite zusammengefasst.

Benutzer:Sib

2026-01-22T11:27:47Z

Sib: initial commit

Mitglieder-Quellen

2026-01-22T10:20:41Z

Sib: refactor

'''Quellen der Hostsharing Mitglieder-Gemeinschaft'''

'''Frage''': Hast du dich schon mal gefragt, ob du in der '''Hostsharing Mitglieder-Gemeinschaft'''
(etwa 300 Mitglieder Stand Januar 2026)
das einzige Mitglied bist,
welches sich mit Software XYZ befasst?

'''Antwort''': Hier findest du es heraus! Diese Quellen,
aus der Mitglieder-Gemeinschaft der [https://www.hostsharing.net Hostsharing eG],
bieten Interessenten die Möglichkeit,
in kooperativer Anstrengung,
das gemeinsame IT-Infrastruktor von '''Hostsharing''' weiterzuentwickeln.

Diese Sammlung stammt aus der gemeinschaftlich betriebenen IT-Infrastruktur von '''Hostsharing'''. An dieser Stelle ist es nicht von Bedeutung, ob sie auch mit anderer Infrastruktur kompatibel ist.

Diese Quellen beinhalten unter anderem:

* Erfahrung
* Konfiguration
* Service

Hast du einen Beitrag zu dieser Seite? Keine falsche Bescheidenheit! Bitte bearbeite diese Seite direkt selbst. Danke!

== Dokumentation ==

WiP

== Erfahrung ==

* [[Anwendungen_mit_Ansible_installieren|Ansible]]: [[User:sib|sib]], [[User:tim00|tim00]]
* [[CiviCRM_installieren|CiviCRM]]: [[User:tim00|tim00]]
* [[Gitea]]: [[User:sib|sib]]
* [[Mlmmj]]: [[User:sib|sib]]
* [[Nextcloud]]: [[User:sib|sib]], [[User:tim00|tim00]]
* [[Eigenes_Python_installieren|Python]]: [[User:tim00|tim00]]
* OpenPetra: [[User:tim00|tim00]]
* [[Roundcube]]: [[User:sib|sib]]

== Konfiguration ==

* [https://github.com/seb-schulz/cert-manager-webhook-hostsharing ACME Webhook für Cert Manager]
* [https://codeberg.org/tpokorra/hs.ansible Automatisierung mit Ansible]
* [https://github.com/sebatec-eu/config-mate Sebatec: Go-Konfiguration]
* [https://github.com/sebatec-eu/ssh-deploy-action Sebatec: Wiederverwendbar GitHub Action für SSH-Installation]
* [https://github.com/seb-schulz/hostsharing-dyndns Service-Konfiguratin für DynDNS]

== Plattform ==

WiP

== Service ==

* [https://solidevereine.de/organisation/nextcloud/#highperf Solidevereine: Nextcloud High Performance Backend (HPB) für Nextcloud Talk]
* [https://nextcloud.ossaas.de Solidevereine: OS SaaS (Open Source Software as a Service): Nextcloud]
* [https://openpetra.ossaas.de Solidevereine: OS SaaS (Open Source Software as a Service): OpenPetra]
* [https://www.swingbe.de/service/engineering SwIngBe: Full-Service-IT-Dienstleistungen]

== Software ==

WiP

Mitglieder-Quellen

2026-01-21T15:10:11Z

Sib: Liste der Erfahrungen erweitert

'''Quellen der Hostsharing Mitglieder-Gemeinschaft'''

Diese Quellen,
aus der Mitglieder-Gemeinschaft der [https://www.hostsharing.net Hostsharing eG],
bieten Interessenten die Möglichkeit,
in kooperativer Anstrengung,
das gemeinsame IT und Hosting zu verbessern
(Alias: '''[https://en.wikipedia.org/wiki/Community_building Community Building]''').

Diese Quellen beinhalten unter anderem:

* Plattform
* Service
* Software

Diese Sammlung richtet sich an die Hosting- und IT-Umgebung von Hostsharing.

Möchtest du etwas dazugeben oder anpassen? Zögere bitte nicht diese Seite direkt zu bearbeiten.

== Dokumentation ==

* [[Mitglieder-Quellen|Quellen der Hostsharing Mitglieder-Gemeinschaft]]

== Erfahrung ==

* [[Anwendungen_mit_Ansible_installieren|Ansible]]: [[User:sib|sib]], [[User:tim00|tim00]]
* [[CiviCRM_installieren|CiviCRM]]: [[User:tim00|tim00]]
* [[Gitea]]: [[User:sib|sib]]
* [[Mlmmj]]: [[User:sib|sib]]
* [[Nextcloud]]: [[User:sib|sib]], [[User:tim00|tim00]]
* [[Eigenes_Python_installieren|Python]]: [[User:tim00|tim00]]
* OpenPetra: [[User:tim00|tim00]]
* [[Roundcube]]: [[User:sib|sib]]

== Konfiguration ==

* [https://github.com/seb-schulz/cert-manager-webhook-hostsharing ACME Webhook für Cert Manager]
* [https://codeberg.org/tpokorra/hs.ansible Automatisierung mit Ansible]
* [https://github.com/sebatec-eu/config-mate Sebatec: Go-Konfiguration]
* [https://github.com/sebatec-eu/ssh-deploy-action Sebatec: Wiederverwendbar GitHub Action für SSH-Installation]
* [https://github.com/seb-schulz/hostsharing-dyndns Service-Konfiguratin für DynDNS]

== Plattform ==

WiP

== Service ==

* [https://solidevereine.de/organisation/nextcloud/#highperf Solidevereine: Nextcloud High Performance Backend (HPB) für Nextcloud Talk]
* [https://nextcloud.ossaas.de Solidevereine: OS SaaS (Open Source Software as a Service): Nextcloud]
* [https://openpetra.ossaas.de Solidevereine: OS SaaS (Open Source Software as a Service): OpenPetra]
* [https://www.swingbe.de/service/engineering SwIngBe: Full-Service-IT-Dienstleistungen]

== Software ==

WiP

Mitglieder-Quellen

2026-01-21T14:47:52Z

Sib: refactor

'''Quellen der Hostsharing Mitglieder-Gemeinschaft'''

Diese Quellen,
aus der Mitglieder-Gemeinschaft der [https://www.hostsharing.net Hostsharing eG],
bieten Interessenten die Möglichkeit,
in kooperativer Anstrengung,
das gemeinsame IT und Hosting zu verbessern
(Alias: '''[https://en.wikipedia.org/wiki/Community_building Community Building]''').

Diese Quellen beinhalten unter anderem:

* Plattform
* Service
* Software

Diese Sammlung richtet sich an die Hosting- und IT-Umgebung von Hostsharing.

Möchtest du etwas dazugeben oder anpassen? Zögere bitte nicht diese Seite direkt zu bearbeiten.

== Dokumentation ==

* [[Mitglieder-Quellen|Quellen der Hostsharing Mitglieder-Gemeinschaft]]

== Erfahrung ==

* Ansible: [[User:sib|sib]], [[User:tim00|tim00]]
* CiviCRM: [[User:tim00|tim00]]
* Nextcloud: [[User:sib|sib]], [[User:tim00|tim00]]
* Python: [[User:tim00|tim00]]
* OpenPetra: [[User:tim00|tim00]]

== Konfiguration ==

* [https://github.com/seb-schulz/cert-manager-webhook-hostsharing ACME Webhook für Cert Manager]
* [https://codeberg.org/tpokorra/hs.ansible Automatisierung mit Ansible]
* [https://github.com/sebatec-eu/config-mate Sebatec: Go-Konfiguration]
* [https://github.com/sebatec-eu/ssh-deploy-action Sebatec: Wiederverwendbar GitHub Action für SSH-Installation]
* [https://github.com/seb-schulz/hostsharing-dyndns Service-Konfiguratin für DynDNS]

== Plattform ==

WiP

== Service ==

* [https://solidevereine.de/organisation/nextcloud/#highperf Solidevereine: Nextcloud High Performance Backend (HPB) für Nextcloud Talk]
* [https://nextcloud.ossaas.de Solidevereine: OS SaaS (Open Source Software as a Service): Nextcloud]
* [https://openpetra.ossaas.de Solidevereine: OS SaaS (Open Source Software as a Service): OpenPetra]
* [https://www.swingbe.de/service/engineering SwIngBe: Full-Service-IT-Dienstleistungen]

== Software ==

WiP

Mitglieder-Quellen

2026-01-21T14:44:40Z

Sib: initial commit

'''Quellen der Hostsharing Mitglieder-Gemeinschaft''':

Diese Quellen,
aus der Mitglieder-Gemeinschaft der [https://www.hostsharing.net Hostsharing eG],
bieten Interessenten die Möglichkeit,
in kooperativer Anstrengung,
das gemeinsame IT und Hosting zu verbessern
('''[https://en.wikipedia.org/wiki/Community_building Community Building]''').

Diese Quellen beinhalten unter anderem:

* Plattform
* Service
* Software

Diese Sammlung richtet sich an die Hosting- und IT-Umgebung von Hostsharing.

Möchtest du etwas dazugeben oder anpassen? Zögere bitte nicht diese Seite direkt zu bearbeiten.

== Dokumentation ==

* [[Mitglieder-Quellen|Quellen der Hostsharing Mitglieder-Gemeinschaft]]

== Erfahrung ==

* Ansible: [[User:sib|sib]], [[User:tim00|tim00]]
* CiviCRM: [[User:tim00|tim00]]
* Nextcloud: [[User:sib|sib]], [[User:tim00|tim00]]
* Python: [[User:tim00|tim00]]
* OpenPetra: [[User:tim00|tim00]]

== Konfiguration ==

* [https://github.com/seb-schulz/cert-manager-webhook-hostsharing ACME Webhook für Cert Manager]
* [https://codeberg.org/tpokorra/hs.ansible Automatisierung mit Ansible]
* [https://github.com/sebatec-eu/config-mate Sebatec: Go-Konfiguration]
* [https://github.com/sebatec-eu/ssh-deploy-action Sebatec: Wiederverwendbar GitHub Action für SSH-Installation]
* [https://github.com/seb-schulz/hostsharing-dyndns Service-Konfiguratin für DynDNS]

== Plattform ==

WiP

== Service ==

* [https://solidevereine.de/organisation/nextcloud/#highperf Solidevereine: Nextcloud High Performance Backend (HPB) für Nextcloud Talk]
* [https://nextcloud.ossaas.de Solidevereine: OS SaaS (Open Source Software as a Service): Nextcloud]
* [https://openpetra.ossaas.de Solidevereine: OS SaaS (Open Source Software as a Service): OpenPetra]
* [https://www.swingbe.de/service/engineering SwIngBe: Full-Service-IT-Dienstleistungen]

== Software ==

WiP

Roundcube

2025-11-14T13:52:58Z

Sib: update address of Roundcube Wiki

Für alle Hostsharing-Mitglieder und ihre Kunden gibt es eine zentrale Webmail-Installation, die unter https://webmail.hostsharing.net erreichbar ist.

Diese Dokumentation beschreibt lediglich die wichtigsten Funktionen zum Einstieg. Weitere allgemeine Dokumentation gibt es im Wiki des Roundcube-Projekts [https://github.com/roundcube/roundcubemail/wiki]

== Einrichten - Der erste Aufruf ==
[[Bild:Roundcube-031-login.png‎|miniatur|200px|right|Screenshot Webmail Einloggen]]

Dieser Abschnitt behandelt das erstmalige Einloggen eines neuen Nutzers. Hatte dieser Nutzer bereits vorher die alte Webmail-Installation [[IlohaMail]] benutzt, sind die Grundeinstellungen bereits übernommen.

Auf dem Startbildschirm erscheinen Eingabefelder für Benutzernamen und Passwort. Beides Eingeben und 'Anmelden' klicken oder Return-Taste drücken.

'''Beispiel'''

<syntaxhighlight lang=ini line>
Benutzer: xyz00-otto
Passwort: ganzgeheimespasswort
</syntaxhighlight>

=== Maildir anlegen für neu angelegten Nutzer ===
Frisch angelegte Nutzer können sich nur einloggen, wenn in ihrem Account bereits der IMAP-Account durch Anlage des Verzeichnisses ~/Maildir erfolgt ist. Andernfalls findet das System keinen gültigen IMAP-Email-Account. Die Fehlermeldung "Keine Verbindung zum IMAP-Server" erscheint:

[[Bild:Roundcube-errormessage-noconnection.png‎|none]]

Diese Initialisierung kann wahlweise erfolgen durch

# Versand einer Email von anderem Mail-Account an den neu erstellten Account (hierzu eine Email-Adresse mit dem Account verknüpfen)
# Einloggen über die Shell in den Account des neuen Nutzers und dort Aufruf von

<syntaxhighlight lang=shell>
maildirmake ~/Maildir
</syntaxhighlight>

=== Angabe von Namen und Email-Adresse ===

[[Bild:Roundcube-firstlogin-userinfo1.png‎|right|300px|miniatur|Aufforderung Eingabe Name/Email-Adresse]]

Beim erstmaligen Einloggen in Roundcube müssen im Webmail-System der Name des Nutzers und seine Email-Adresse hinterlegt werden. Dazu erscheint beim Einloggen ein Fenster, das zur Eingabe dieser Informationen auffordert.

Die eingegebenen Daten werden beim Versand von Emails als Absendername und Absender-Email-Adresse benutzt. Dies hat keinen Einfluß auf den ''Empfang'' von Emails. Weitere Namen/Adressen zum Versenden können als [[#Identit.C3.A4ten|Identitäten]] angelegt werden.

[[Bild:Roundcube-firstlogin-userinfo2.png‎|right|300px|miniatur|Angabe von Namen und Email-Adresse]]

'''Beispiel für Default-Werte'''

<syntaxhighlight lang=ini line>
Name: xyz00-otto
Email-Adresse: xyz-otto@h01.hostsharing.net
</syntaxhighlight>

'''Eingabe der nutzerspezifischen Angaben '''

<syntaxhighlight lang=ini line>
Name: Otto Musterer
Email-Adresse: otto@example.org
</syntaxhighlight>

=== Spezialordner ===
[[Bild:Roundcube-special-folders.png‎|right|Ordnerliste]]

Roundcube zeigt die Ordner für Posteingang, Entwürfe, Gesendete Emails, Papierkorb und Spam gesondert am Anfang der Ordnerliste an. Dabei ist die Bezeichnung des Ordners analog der eingestellten Sprache unabhängig vom echten Namen der Ordner.

Die folgende Tabelle zeigt die Funktion der Ordner, ihren deutschen Namen in der Ordnerliste und den Default-Wert für den echten Ordnernamen.

{| border="1" cellpadding="4" cellspacing="0"
|+ align="bottom" style="color:#e76700;"|
|-
!Text
!Beschreibung
!Ordnername
!Automatisch erstellt
|-
|Posteingang
|Posteingang
|INBOX
| align="center" | X
|-
|Gesendet
|Gesendete Emails
|INBOX.Sent
| align="center" | X
|-
|Entwürfe
|noch nicht versandte Emails im Entwurfsstadium
|INBOX.Drafts
| align="center" | X
|-
|Gelöscht
|Papierkorb - Emails, die zum Löschen in den Papierkorb verschoben wurden
|INBOX.Trash
| align="center" | X
|-
|Spam
|Emails, die als Spam markiert und verschoben wurden
|INBOX.Junk
|  
|}
[[Bild:Roundcube-special-folders-settings.png‎|right|300px|miniatur|Setzen der Spezialordner]]

Sind die Ordner beim ersten Einloggen schon vorhanden, werden sie automatisch mit ihrer Spezialfunktion verknüpft. Sind sie noch nicht vorhanden, werden sie automatisch durch Roundcube erstellt.

Hat man andere Ordnernamen für die Spezialordner, wie z.B. <tt>INBOX.Gesendet</tt> oder <tt>INBOX.sent-mail</tt> für gesendete Email kann die Zuordnung zu den Spezialordnern unter Einstellungen → Spezialordner geändert werden.

Siehe Beispiel rechts: Für die gesendeten Emails wird der Ordner <tt>INBOX.versendet</tt> benutzt. Ein Ordner für Spams ist im Beispiel nicht verknüpft, die anderen Ordner haben ihre Standardwerte. Der Ordner für den Posteingang kann nicht verändert werden.

Für Weiteres zu Ordnern siehe den entsprechenden Abschnitt
'[[#Ordner|Ordner]]'.

== Grundsätzliche Email-Funktionen ==
Nach dem Einloggen erscheint im Hauptfenster eine Liste der Emails im Posteingang. Eine kurze Erklärung der einzelnen Funktionen ist in der Tabelle unterhalb des Screenshots zu sehen.

[[Bild:Roundcube-mainscreen.png|none|700px|miniatur]]

{| border="1" cellpadding="4" cellspacing="0"
|+ align="bottom" style="color:#e76700;"|
|-
!Feld
!Kurztext
!Beschreibung
|-
| align="center" | A
|Ordnerliste
|Liste der abonnierten Ordner. [[#Spezialordner|Spezialordner]] werden oben gezeigt. Ordner mit ungelesenen Mails erscheinen '''fett''' mit der Anzahl der ungelsenen Mails dahinter. Siehe separaten Abschnitt wie weitere [[#Ordner abonnieren|Ordner abonniert]] werden können.
|-
| align="center" | B
|Email-Liste Sortierungsleiste
|Standardmäßig werden Emails absteigend nach Eingangsdatum sortiert. Durch Klicken auf 'Betreff', 'Absender', 'Datum' oder 'Größe' kann nach diesen sortiert werden und durch nochmaliges Klicken die Sortierreihenfolge geändert werden.

Es ist derzeit nicht möglich die angezeigten Spalten zu verändern oder zu verschieben. Auch ist eine Thread-Darstellung nicht möglich. Beides wird ggf. mit späteren Versionen von Roundcube implementiert.
|-
| align="center" | C
|Emails Listenansicht
|Wichtigste Infos zu Emails wie Absender, Subject, Datum. Ungelesene Emails sind '''fett''' dargestellt und sind am Anfang der Zeile durch einen blauen Stern markiert. Durch anklicken einer Email erscheint diese im Vorschaufenster
|-
| align="center" | D
|Vorschaufenster
|Im unteren Teil des Bildschirms werden ausgewählte Emails angezeigt. Innerhalb des Fensters kann gescrollt werden. Auch bei Text-Emails werden rudimentäre Formatierungen angezeigt, wie beispielsweise farbiges Hervorheben von Zitierungen
|-
| align="center" | E
|Email-Header
|Anzeige der wichtigsten Email-Header. Zusätzliche Header können angezeigt werden, in dem auf den Pfeil am unteren Ende der Header geklickt wird. Durch Klicken auf die Figur neben Namen/Email-Adresse, kann diese in das Adressbuch übernommen werden.
|-
| align="center" | F
|Neues Fenster
|Öffnen der Email in einem neuen Fenster
|-
| align="center" | G
|Seitenauswahl
|Standardmäßig werden bis zu 40 Emails in der Übersicht je Seite angezeigt. In diesem Bereich kann durch die Seiten gescrollt werden. Die maximale Anzahl der Emails in der Listenansicht kann über die Einstellungen verändert werden, ist systemseitig allerdings auf 80 beschränkt.
|-
| align="center" | H
| Email-Auswahl
|Buttons zur Auwahl von Emails in der Listenansicht. Von links nach rechts: a) alle Auswählen b) ungelesene Mails auswählen c) Auswahl invertieren d) keine Mails auswählen.

Diese Auswahl kann dann auf andere Funktionen (wie z.B. Löschen) angewandt werden.
|-
|-
| align="center" | a
|Auf neue Nachrichten überprüfen
|Ausgewählter Ordner wird neu gelesen
|-
| align="center" | b
|Neue Nachricht schreiben
|
|-
| align="center" | c
|Antwort verfassen
|Nur an Sender antworten
|-
| align="center" | d
|Antwort an Versender und alle Empfänger verfassen
|
|-
| align="center" | e
|Nachricht weiterleiten
|Original-Nachricht wird in der neuen Email als Text eingefügt. Anhänge der Original-Nachricht werden als Anhang weitergeleitet.
|-
| align="center" | f
|Als Anhang weiterleiten
|Original-Nachricht wird als Anhang weitergeleitet
|-
| align="center" | g
|Nachricht in den Papierkorb verschieben
|Nachricht wird zunächst nicht gelöscht sondern nur verschoben. Je nach Einstellung wird der Papierkorb beim Ausloggen geleert oder bleibt erhalten (Default: kein Löschen)
|-
| align="center" | h
|Mark as Junk
|Email wird in den Spam-Ordner verschoben, sofern ein solcher in den Einstellungen als Spezialornder markiert wurde. Andernfalls keine Funktion.
|-
| align="center" | i
|Nachrichten markieren
|Ausgewählte Nachrichten können als gelesen/ungelesen markiert werden, oder zur Hervorhebung mit einem Stern markiert werden.
|-
| align="center" | j
|Weiter Aktionen...
|Ausgewählte Nachricht drucken, speichern, Quelltext anzeigen, in neuem Fenster öffnen.
|-
| align="center" | k
|Filter
|Im Textfeld kann eine Zeichenkette eingegeben werden nach der im Subject gesucht wird. Nur diese Emails werden in der Liste angezeigt. Über die Drop-Down-Box links vom Textfeld kann die Suche eingeschränkt werden auf alle / ungelesene / unbeantwortete / markierte / gelöschte Emails. (Gelöschte nur, sofern diese nicht im Papierkorb sind, sondern mit dem IMAP-Status gelöscht versehen werden. Diese werden aber standardmäßig nicht angezeigt.)
|-
|}

== Einstellungen ==

Jeder Nutzer kann gewisse Einstellungen vornehmen, die das Aussehen oder Verhalten von Roundcube verändern:

Einstellungen, die auf der linken Seite des Einstellungsmenu zu erreichen sind:

* Benutzeroberfläche: Sprache, Datumsanzeige, Zeitzone, Listenansicht
* Mailbox-Ansicht: Nachrichtenvorschau, Lesebestätigung, Prüfen auf neue Nachrichten, ...
* Nachrichtenerstellung: HTML-Nachrichten verfassen, Speichern von Entwürfen, ...
* Nachrichtendarstellung: Anzeige von HTML und externen Bildern festlegen, ...
* Spezialordner: Zuordnung von Ordnernamen zu Spezialordnern, siehe [[#Spezialordner|Spezialordner]]
* Server-Einstellungen: Löschverhalten
* Konto-Einstellungen: (keine Einstellungen)

Einstellungen über separate Reiter:

* Ordner: siehe gesonderte Dokumentation im Abschnitt [[#Ordner|Ordner]]
* Identitäten: siehe gesonderte Dokumentation im Abschnitt [[#Identit.C3.A4ten|Identitäten]]

[[Bild:Roundcube-addressbook.png‎|right|miniatur|350px|Adressbuchansicht]]
== Kontakte - Adressbuch ==

Das Adressbuch kann lediglich folgende Felder Speichern

* Angezeigter Name: Freitext, kann aus Vor- und Nachnamen bestehen, aber auch andere Angaben wie Firma. Dieser Text erscheint in der Liste der Adressbuch-Einträge.
* Vorname
* Nachname
* Email-Adresse.

[[Bild:Roundcube-compose-selectaddress.png‎|right|miniatur|350px|Erstellen von Mails: Auswahl aus Adressbuch]]
Beim Verfassen von Emails wird bei der Eingabe von Adressen in den Feldern 'An' und 'Kopie' das Adressbuch nach Einträgen durchsucht, die die getippten Buchstaben enthalten. Beim Tippen von 'ing' wird gefunden: 'Ingo' aber auch 'Hostsharing'.

 
Beim Empfang von Emails können VCards des Senders in das Adressbuch übernommen werden, allerdings gibt es noch keine Funktion in Roundcube um diese auszulesen oder zu benutzen.

 
== Identitäten ==

Jeder Nutzer kann die Absenderangaben von zu versendenden Emails mit verschiedenen Identitäten variabel gestalten, z.B.:

[[Bild:Roundcube-identities-newmail.png‎|right]]
* verschiedene Absendernamen für die einzelnen Familienmitglieder
* verschiedene Email-Adressen, die dem selben Account zugeordnet sind (Privat/Büro)
* verschiedene Signaturen
* ....

Die Identitäten können beim Schreiben von neuen Emails über ein Drop-Down-Menü ausgewählt werden (siehe nebenstehendes Bild). Bei der Beantwortung von Emails versucht Roundcube die am besten passende Identität anhand des ursprünglichen Empfängernamens herauszufinden.

 
[[Bild:Roundcube-identities-list.png‎|right]]
Unter Einstellungen → Identitäten (Reiter) wird im linken Teil eine Liste der erstellten Identitäten angezeigt, die sich per Klick zum Verändern auswählen lassen.

 
[[Bild:Roundcube-identities-edit-text.png‎|right]]
Je Identität können angegeben werden:

* Der angezeigte Name
* Die Email-Adresse des Absenders
* Das Feld Organisation (wird wenig benutzt)
* Eine Adresse, an die geantwortet werden soll, sofern verschieden von der Absender-Email-Adresse
* Eine Email-Adresse an die standardmäßig beim Versand eine Blindkopie (Bcc) mitverschickt wird.
* Eine Signatur, die automatisch angehängt wird. Bei Emails im Textformat wird der Signaturtrenner <tt>--</tt> automatisch von Roundcube eingefügt.
* Eine Angabe, ob die Signatur in HTML verfasst werden soll (siehe Beipiel unten)
* Ein Häkchen, das festsetzt, ob diese Signatur die Standardsignatur ist und bei neuen Emails benutzt wird (sofern keine andere vom Nutzer ausgewählt wird.)

[[Bild:Roundcube-identities-edit-html.png‎|left|miniatur|350px|HTML-Signatur]]
 
== Ordner ==

[[Bild:Roundcube-folders.png‎|right]]

Roundcube zeigt in der Ordnerliste nur die abonnierten Ordner an. In diesem Menu kann ausgewählt werden, welche Ordner abonniert werden sollen. Auch können neue Ordner angelegt oder vorhandene gelöscht werden. Die Abonnements, die durch andere Email-Programme (z.B. Thunderbird) vorgenommen wurden, werden automatisch berücksichtigt, wenn das Email-Programm, diese auf dem Email-Server ablegt.

{| border="1" cellpadding="4" cellspacing="0"
|+ align="bottom" style="color:#e76700;"|
|-
!Feld
!Kurztext
!Beschreibung
|-
| align="center" | A
|Spezialordner
|Spezialordner können nicht aus dem Abo genommen werden oder gelöscht werden, solange sie als Spezialordner zugewiesen sind. (siehe [[#Spezialordner|Spezialordner].
|-
| align="center" | B
|Normale Ordner
|Es werden alle weiteren Ordner für dieses Email-Konto angezeigt. Diese können abonniert, umbenannt oder gelöscht werden. Außerdem wird für jeden Ordner die Zahl der enthaltenen Emails angezeigt.
|-
| align="center" | C
|Abonnement
|Durch Setzen eines Hakens wird der Ordner für künftige Benutzung abonniert.
|-
| align="center" | D
|Umbenennen/Löschen
|Ausgewählte Ordner können gelöscht oder umbenannt werden.
|-
|}

==== Anlegen neuer Ordner ====
Am unteren Ende des Ordnerfensters können über ein Textfeld neue Ordner angelegt werden. Diese werden automatisch abonniert.

== Nutzung weiterer Features ==

Die Dokumentation zu weiteren ggf. weniger häufig benutzten Funktionen sind auf separaten Wiki-Seiten dokumentiert:

* [[Roundcube - Filter|Filter]]: Automatisches Filtern von E-Mails mit Managesieve, z.B. Verschieben in andere Ordner, Abwesenheitsmeldung etc.
* [[Roundcube - Threads|Thread-Anzeige]]: Gruppieren von Emails nach Themen
* [[Roundcube - Adressgruppen|Adressgruppen]]: Erstellen von Verteilerlisten im Adressbuch
* [[Roundcube - Emailhervorhebung|Hervorhebung von Emails]]: Markieren von Emails durch Farben abhängig vom Versender, Subject, etc.

== Sicherheit und Datenschutz ==

Zugriff auf das Webmail-Programm erfolgt ausschließlich SSL-verschlüsselt über <tt><nowiki>https://</nowiki></tt>.

Nutzerdaten wie Kontakte oder Identitäten werden in einer PostgreSQL-Datenbank abgespeichert. Das Passwort des Users wird temporär verschlüsselt zwischengespeichert. Außerdem werden von den Emails in den Ordner die Kopfzeilen - Absender, Empfänger, Thema, Datum, ... - für die schnellere Bearbeitung zwischengespeichert. Passwort und Kopfzeilen werden nach dem Ausloggen gelöscht.

Auf die Datenbank können nur Hostmaster und Maintainer zugreifen, die jeweils eine Datenschutzerklärung unterschrieben haben müssen.

== Weiteres ==

Die für den Webmailer benutzte Software ist [http://roundcube.net Roundcube]

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

Roundcube - Filter

2025-11-12T05:03:14Z

Sib: Abschnitt Quellen entfernt, weil diese nicht mehr existieren

== Roundcube - Filter ==

Das Webmailprogramm [[Roundcube]] erlaubt Emails automatisch zu Filtern. Dieser Artikel beschreibt, wie mit der Erweiterung sieverules solche Filter definiert werden können.

=== Allgemeines zum Filtern ===

Über das Mailzustellungsprogramm Deliver ist es mit der Erweiterung [[Managesieve]] möglich Emails beim Eintreffen in der Mailbox zu Filtern. Die Filterung findet hierbei bereits auf dem Server statt, so daß der User nicht mit seinem Mailprogramm oder Webmailer eingeloggt sein muß.

Hierbei ist es möglich u.a. folgende Aktionen durchzuführen

* Mails in einen bestimmten Ordner abzuspeichern
* Mails an einen anderen Empfänger weiterzuleiten
* eine Abwesenheitsmeldung zu verschicken
* den Empfang einer Email abzulehnen
* eine Mail zu löschen

Die Ausführung dieser Filteraktionen kann gesteuert werden z.B. basierend auf

* dem Absender der eintreffenden Email
* des Titels oder Teilen hiervon
* dem Vorhandensein oder Nichtvorhandensein bestimmter Wörter im Text der Nachricht
* die Auswertung von zusätzlichen Mail-Headern.

[[Bild:Sieve-01-einstellungen.png|miniatur|250px|right|Einstellungen]]
Detaillierte Informationen können z.B. der [http://de.wikipedia.org/wiki/Sieve Wikipedia] oder unter [http://www.sieve.info sieve.info] entnommen werden. Im Hostsharing-Wiki unter [[Managesieve]] sind ebenfalls weitere Grundlageninformationen zu finden.

=== Einrichtung ===

Hinweis: Wenn der Nutzer schon eine .forward mit z.b. procmail nutzt muss wie unter
[https://wiki.hostsharing.net/index.php?title=Managesieve#Zusammenarbeit_mit_Procmail Zusammenarbeit_mit_Procmail]
beschrieben ist beachtet werden.

Filter können unter <tt>Einstellungen</tt> eingerichtet und verändert werden. Hierzu im Menu Einstellungen den Reiter ganz rechts <tt>Filter</tt> auswählen.

 
[[Bild:Sieve-02-mailuebersicht.png|center|none|frame|Ungefilterter Posteingang]]
Für die folgenden Beispiele wird davon ausgegangen, daß der Nutzer in seinem Posteingang ohne Filter die Situation, wie im Bild oben angezeigt vorfindet: Viele Emails aus (drei) Mailinglisten und eine private Email. Alle Mails sind in einem Ordner und erschweren das Finden der ggf. wichtigen privaten Email.

[[Bild:Sieve-03-neuer-filter.png|miniatur|250px|right|Neuen Filter anlegen]]
Zunächst soll ein neuer Filter angelegt werden, der die Emails der Mailingliste <tt>otrs-de</tt> [http://doc.otrs.org/2.2/de/html/additional-resources-mailinglists.html] in einen eigenen Ordner verschiebt.

Hierzu unter der (leeren) Filterliste auf das <tt>+</tt> zum Anlegen eines Neuen Filters klicken.
 
[[Bild:Sieve-04-OTRS-filter.png|miniatur|600px|right|Anlegen eines Filters für eine Mailingliste]]
Im neu geöffneten Formular kann der neue Filter definiert werden.

* '''Filternamen''' vergeben: zum Beispiel OTRS für die entsprechende Maillingliste (oder zur besseren späteren Erinnerung: "Mailingliste otrs-de"). OTRS
* '''Filterregel''': Hier wird definiert unter welchen Bedingungen der Filter angewandt werden soll. Drei Optionen stehen zur Auswahl
** Irgendeine Bedingung muß erfüllt sein (ODER)
** Alle Bedingungen müssen erfüllt sein (UND) Auswählen
** Die Bedingung ist für alle Emails gültig (keine Bedingung notwendig)
* Die Definition der Filterregel beinhaltet das Auswahl eines Teils der Nachricht (z.B. Absender, Datum, Betreff, Text) und einem Wert, mit dem verglichen werden soll. In unserem Beispiel: BETREFF enthält <nowiki>[otrs-de]</nowiki>
* '''Filteraktion''': Die Aktion, die ausgeführt werden soll. Verschiebe Nachricht nach OTRS 
Bei Aktionen, die Nachrichten in andere Ordner verschieben oder kopieren werden die möglichen Ordner die zum Zeitpunkt der Filteranlage existieren in einem Drop-Down-Menu angezeigt.
* '''Speichern'''

[[Bild:Sieve-05-hostsharing-filter.png|miniatur|600px|right|Filter für Mailingliste über Mail-Header und Ausnahme]]
=== Weitere Beispiele ===

==== Maillinglisten Filter ====

Im Beispiel rechts werden wieder die Emails einer Mailinglliste gefiltert. Hier handelt es sich um die <tt>Technik</tt>-Liste von Hostsharing.

Der Filter erhält folgende Kriterien:
* '''Filterregel''': Der Filter wird '''nicht''' angewandt, wenn der Text der Nachricht das Wort "Festplattencrash" enthält, der Empfänger, solche Emails also in seinem Posteingang behalten möchte. Darüber hinaus wird die Mailingliste identifiziert über den Mail-Header <tt>List-Id</tt>. Solche zusätzlichen Mail-Header können über die Auswahl "Anderer Header" ausgewählt werden. Beide Bedingungen müssen erfüllt sein (UND), also "trifft alle folgenden Regeln" auswählen.
* '''Filteraktion''': Wie im ersten Beispiele wieder das Verschieben in einen Ordner, hier <tt>hostsharing</tt>.

 
[[Bild:Sieve-06-abwesenheitsmeldung-filter.png|miniatur|600px|right|Abwesenheitsmeldung]]
==== Abwesenheitsmeldung ====

Nutzer möchten oft bei längerer Abwesenheit dem Absender einer Email mitteilen, daß sie die empfangene Email z.B. wegen Urlaubs nicht lesen können. Hierzu kann eine Abwesenheitsmeldung definiert werden, die automatisch eine Antwort-Email generiert mit einem vordefinierten Text.

Im Beispiel sollen die Absender "peter.lustig" und "Wickie" keine Abwesenheitsmeldung erhalten, sowie bei Emails, die das Wort "Werbung" im Betreff enthalten auch keine Abwesenheitsmeldung verschickt werden.
* "Absender enthält nicht 'peter.lustig'" - Ein Vergleich mit der Email-''Adresse'' wird durchgeführt. Peter <peter.lustig@example.org> - Hier ist peter.lustig in der Adresse enthalten Peter.Lustig <peter@example.org> - Hier ist peter.lustig ''nicht'' in der ''Adresse'' enthalten.
* "Anderer Header "From" enthält nicht 'Wickie'" - Ein Vergleich mit der ''kompletten Absender-Angabe'' wird durchgeführt ''Susanne <wickie@example.org>'' aber auch ''Wickie <susanne@example.org>'' werden gefunden
* "Betreff enthält nicht 'Werbung' - Das Wort Werbung darf nicht im Betreff enthalten sein.

In den '''Filteraktionen''' wird die Aktion "Abwesenheitsmeldung" ausgewählt.
* '''Absender''': Hat man mehrere Identitäten in Webmail angelegt, kann man hier aussuchen unter welchem Absender die Abwesenheitsmeldung geschickt werden soll.
* '''Alias''': Die Vacation-Extension schickt Abwesenheitsmeldungen '''nur''' wenn die Mail an eine dem System für ''diesen'' Account bekannte Email-Adresse geschickt wurde. Im konkreten Fall bei der Erstellung über Roundcube müssen also für jede Email-Adresse Identitäten angelegt werden, also z.B. sowohl max.mustermann@example.org und maexchen@example.org. Diese müssen dann auch unter "Alias" explizit ausgewählt werden. Werden Emails an den Account mit einer anderen Empfänger-Adresse geschickt, erhalten diese '''keine''' Abwesenheitsmeldung. siehe auch [http://tools.ietf.org/html/rfc5230#section-4.5 RFC5230] Abschnitt 4.5
* '''Zeitraum''': Sagt aus, nach wieviel Tagen ein Absender eine erneute Abwesenheitsmeldung erhält. Im Beispiel also z.B. nur einmal alle 3 Tage. Wenn der Absender dazwischen neue Emails versendet, erhält er keine neue Abwesenheitsmeldung. Nach 3 Tagen wird bei erneuten Emails wieder eine Abwesenheitsmeldung verschickt. Hierz speichert sich <tt>deliver</tt> eine Liste der Empfänger.
* '''Betreff''': Der Betreff der Abwesenheitsmeldung, z.B. "Abwesenheit - Urlaub"; der originale Betreff der Email kann zur Identifizierung angehängt werden. Wird also automatisch auf eine Mail "Geburtstagseinladung" geantwortet, wäre der Betreff der Abwesenheitsmeldung "Abwesenheit - Urlaub Geburtstagseinladung".
* '''Nachricht''': Der eigentliche Text der Abwesenheitsmeldung, z.B. Dauer der Abwesenheitsmeldung, Vertretungsregelung, Erreichbarkeit.

[[Bild:Sieve-07-reihenfolge-a.png|miniatur|300px|left|Reihenfolge Filter ändern über Pfeile]]
[[Bild:Sieve-07-reihenfolge-b.png|miniatur|300px|right|Nach Änderung der Reihenfolge]]
===== Reihenfolge von Filtern =====

Insbesondere bei Abwesenheitsmeldungen ist die Reihenfolge der Filter wichtig. Im Beispiel links wird der Filter "osm" erst nach der Abwesenheitsmeldung angewandt, Mails, die durch diesen Filter nicht schon wegsortiert wurden, erhalten also eine Abwesenheitsmeldung. Wenn dies unerwünscht ist, muß der Filter '''vor''' den Filter der Abwesenheitsmeldung verschoben werden (über die Pfeile rechts neben des Filterliste).

 
In (u.a.) folgenden Fällen werden '''Abwesenheitsmeldungen vom System nicht verschickt''':
* Die Absenderadresse deutet auf eine Mailingliste hin, z.B. beginnt mit: ''mailer-daemon'', ''listserv'', ''majordomo'', ''owner-'' oder enthält ''-request''
* Es existiert ein Header "Precedence" der ''junk'', ''bulk'' oder ''list'' enthält.
* Der Empfänger der Nachricht steht nicht in ''To'' oder ''Cc''.
* Sender und Empfänger haben dieselbe Email-Adresse.

[[Bild:Sieve-08-kopiesenden.png|miniatur|600px|right|TEXT]]

==== Kopie an anderen Empfänger versenden. ====

Eine erhaltene Email soll an eine andere Email-Adresse (in Kopie) weitergeleitet werden, z.B. von der Privatadresse an die Geschäftsadresse.

* '''Filterregel''': In diesem Beispiel soll der lokale Teil der Absender-Adresse verglichen werden. "Absender" wählen, dann "weitere Optionen" '''(1)''' und unter ''Operatoren'' ''User-Teil gleich''. '''(2)''' Im Beispiel wurde der User-Teil mit ''susanne.musterfrau'' '''(3)''' angegeben. Zur Email-Adresse ''susanne.musterfrau@example.de'' wird ein Match gefunden für ''sara-susanne.musterfrau@example.org'' hingegen nicht, weil der lokale Teil der Email-Adresse nicht übereinstimmt.
* '''Filteraktionen''': "Sende eine Kopie an" wählen '''(4)''' und eine Ziel-Adresse angeben.

 

[[Bild:Sieve-09-filter-abschalten-a.png|miniatur|400px|left|Filter abschalten]]
[[Bild:Sieve-09-filter-abschalten-b.png|miniatur|300px|right|Filterübersicht im inaktivem Filter]]
==== Filter deaktivieren/aktivieren ====

Soll ein Filter temporär deaktivitert werden, kann in der Filterbearbeitung '''Filterregel abschalten''' angeklickt werden. In der Filterübersicht ist der Filter dann als ''"(abgeschaltet)"'' markiert.

 
[[Bild:Sieve-10-nach-anwendung-filter.png|miniatur|600px|right|Nach dem Filtern]]
==== Nach dem Filtern ====

Die im obigen Beispiel gezeigte Inbox mit über 200 Emails sieht nach Anwendung der Filter wie im nebenstehenden Bild aus.

* Im Posteingang '''(1)''' ist nur noch eine private Email vorhanden
* Die Emails and die Mailinglisten wurden in die jeweiligen Ordner '''(2)''' einsortiert.

=== Technisches ===

==== Speicherort ====

Roundcube speichert die erstellten Regeln unter
<syntaxhighlight lang=shell>
~/Maildir/sieve/roundcube.sieve
</syntaxhighlight>

und verlinkt diese Filterdatei automatisch für die Benutzung mit dovecot:
<syntaxhighlight lang=shell>
xyz00@h01:~$ ls -al
drwxr-xr-x 5 xyz00-max xyz00 4096 Nov 16 07:28 .
drwxr-xr-x 28 xyz00-max xyz00 4096 Oct 22 23:06 ..
lrwxrwxrwx 1 xyz00-max xyz00 29 Nov 16 07:28 .dovecot.sieve -> Maildir/sieve/roundcube.sieve
</syntaxhighlight>
Wurden von anderen Programmen -- oder manuell -- andere Filtersets angelegt, werden diese vom Plugin deaktiviert. Die ursprüngliche Filterdatei bleibt erhalten, aber obiger Symlink verweist dann auf die Roundcube-Filter.

==== Manuelles Editieren ====

Vom manuellen Bearbeiten der Filterdatei <tt>roundcube.sieve</tt> wird abgeraten, da bei erneutem Einlesen durch das Roundcube-Plugin diese Regeln mit großer Wahrscheinlichkeit wieder automatisch umgeschrieben werden.

Für komplexeres Filtern kann eine komplett manuelle Datei angelegt werden und entsprechend verlinkt werden. Siehe auch den Artikel zu [[Managesieve]].

==== Links ====

Einige Sieve-relevante Links, sind im entsprechenden [https://wiki.hostsharing.net/index.php?title=Managesieve#Links Managesieve Wiki-Artikel] angegeben:
----
[[Kategorie:HSDoku]]
[[Kategorie:E-Mail]]
[[Kategorie:Glossar]]

LTB-SSP

2025-06-05T12:09:16Z

Sib: Installation von LTB-SSP dokumentieren

= LTB Self Service Password (SSP) =

[https://ltb-project.org/documentation/self-service-password.html LTB Self Service Password] ist ein Dienst zur Kennwort-Zuruecksetzung (Password Reset) fuer Verzeichnis-Dienste wie bspw. [[OpenLDAP]], welcher vom [https://ltb-project.org/documentation/index.html LDAP Tool Box Projekt] stammt.

= LTB SSP Installation =

== Vorbereitung ==

Wir fragen den [[HS-Service]], ob das [https://packages.debian.org/bookworm/all/smarty3/download Smarty] Paket auf dem entsprechenden Managed Server installiert werden kann und warten auf Antwort.

Nach positiver Antwort legen wir mit Hilfe von HSAdmin die folgende Konfiguration an.

* Einen Domain User mit der Shell '/bin/bash' erstellen; bspw. "xyz00-ltb_ssp"
* Beim User schalten wir eine Domain auf; bspw. "pwreset.example.com"

== Installation ==

Per SSH verbinden wir uns mit dem entsprechenden Domain User und fuehren die folgenden Instruktionen aus.

<syntaxhighlight lang=shell>
ssh xyz03-ltb_ssp@xyz03.hostsharing.net
wget https://ltb-project.org/archives/ltb-project-self-service-password-1.7.3.tar.gz
tar -xzf ltb-project-self-service-password-1.7.3.tar.gz
rm ltb-project-self-service-password-1.7.3.tar.gz
ln -s ltb-project-self-service-password-1.7.3 ltb_ssp
cd ~/doms/pwreset.example.com
rm -r subs subs-ssl htdocs-ssl
ln -s /home/pacs/xyz03/users/ltb_ssp/ltb_ssp/htdocs htdocs-ssl
cd htdocs-ssl
ln -s /home/pacs/xyz03/users/ltb_ssp/ltb_ssp/rest
cd ..
vi fastcgi-ssl/php.ini
[PHP]
display_errors = Off
log_errors = On
error_log = /home/pacs/xyz03/users/ltb_ssp/logs/php_errors.log
:wq
mkdir -p /home/pacs/xyz03/users/ltb_ssp/ltb_ssp/cache
mkdir -p /home/pacs/xyz03/users/ltb_ssp/ltb_ssp/templates_c
</syntaxhighlight>

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

Guter Stil

2025-06-05T12:05:57Z

Sib: Kategorie angepasst

Eine gute Seite im HS-Wiki hat einen passenden Namen, der auf das Einfachste reduziert ist. Wenn andere Worte mit der gleichen Bedeutung (Synonyme) auf die gleiche Seite linken sollen, dann kann eine Weiterleitung angelegt werden.

Eine gute Seite enthält Fakten. Sie ist wenn möglich in der zweiten oder dritten Person geschrieben, damit andere leichter an der Seite weiterarbeiten können. In der ersten Person wird nur geschrieben, wenn über Erfahrungen berichtet wird, die sich nicht auf Fakten oder Ratschläge reduzieren lassen. Auf den Diskussionsseiten wird immer in der ersten Person geschrieben. Am Ende des eigenen Beitrages auf den Diskussionsseiten kann unterschrieben werden. Das Wichtigste steht da, wo es leicht zu lesen ist: am Anfang, nicht am Ende. Das Ändern der Seiten erfolgt so, dass der Fluß der Ideen herausgestrichen wird, nicht die zeitliche Aufeinanderfolge der Beiträge. Erst dann, wenn eine Seite zu groß und damit unübersichtlich wird, sollte sie mit Links in weitere Seiten aufgeteilt werden.

Das Wiki hat einfache TextFormatierungsRegeln. Jede Zeile beginnt ohne Leerzeichen und jeder Absatz endet mit einer leeren Zeile. Wörter in eckigen <nowiki>[[Klammern]]</nowiki> werden zu Links auf andere Seiten. Die richtigen Wörter für einen Link zu finden braucht Kreativität.

Kontrolliere das Ergebnis Deiner Eingaben mit der Vorschau, bevor Du die Seite endgültig speicherst.

----
[[Kategorie: Hilfe]]
[[Kategorie:Hostsharing Wiki]]

LLDAP

2025-06-05T09:44:58Z

Sib: added link to page LTB-SSP

== LDAP Kontoverwaltung mit LLDAP ==

LLDAP ist ein LDAP Server, der in der Programmiersprache Rust implementiert ist. LLDAP verwendet eine relationale Datenbank zum Speichern der Accounts und Gruppen. LLDAP läßt sich als eigener Daemon betreiben. Er bringt ein einfaches Webfrontend für die Verwaltung der Konten und Gruppen und eine Funktion zum Passwort-Rücksetzen mit.

=== Vorbereitungen in HSAdmin ===

Mit Hilfe von HSAdmin werden im ersten Schritt ein Service-User, eine Domain und ein PostgreSQL-User mit PostgreSQL-Datenbank angelegt. Der Service-User heißt im folgenden "''xyz00-lldap''", die Domain "''account.hs-example.de''", PostgreSQL-User und -Datenbank heißen beide "''xyz00_lldap''". Das PostgreSQL-Passwort sei "''pg_password_99''".

=== Download und entpacken ===

Die aktuelle Version von LLDAP ist v0.6.1.

Ich melde mich als User "''xyz00-lldap''" und lade das Binärpaket mit wget:

<syntaxhighlight lang="bash">
wget https://github.com/lldap/lldap/releases/download/v0.6.1/amd64-lldap.tar.gz
tar xzf amd64-lldap.tar.gz
mv amd64-lldap lldap
</syntaxhighlight>

=== Konfiguration ===

Die Konfiguration erfolgt über eine Datei "''lldap_config.toml''" im Verzeichnis "''~/lldap''". die Datei erstelle ich wie folgt:

<syntaxhighlight lang="bash">
cd ~/lldap
touch lldap_config.toml
vim lldap_config.toml
</syntaxhighlight>

der Inhalt nach dem Bearbeiten ist zum Beispiel:

<syntaxhighlight lang="toml">
verbose=true
ldap_host = "127.0.0.1"
ldap_port = 33891
http_host = "127.0.0.1"
http_port= 33881
http_url = "https://account.hs-example.de"
jwt_secret = "generierte-zufallszeichenkett-als-secret"
ldap_base_dn = "dc=hs-example,dc=de"
ldap_user_dn = "admin"
ldap_user_email = "webmaster@hs-example.de"
ldap_user_pass = "ldap-admin-password-generieren"
force_ldap_user_pass_reset = false
database_url = "postgres://xyz00_lldap:pg_password_99@localhost/xyz00_lldap"
key_seed = "generierte-zufallszeichenkette"

[smtp_options]
enable_password_reset = true
server = "localhost"
port = 4025
smtp_encryption = "NONE"
from="LLDAP Admin <webmaster@hs-example.de>"

[ldaps_options]
enabled = false
</syntaxhighlight>

Bei der Installation sollten folgende Einstellungen angepasst werden:
* die Ports für LDAP und HTTP
* Die Domain "''hs-example.de''" bzw. "''account.hs-example.de''"
* Der Account-Präfix "''xyz00''"
* Die Passworte und Secret-Zeichenketten
* "''verbose''" soltle auf "''false''" geändert werden, wenn alles läuft.

Das Anlegen der Datenbank-Tabellen erfolgt und ein ersten Start des Servers erfolgt mit den Befehlen:

<syntaxhighlight lang="bash">
cd ~/lldap
./lldap create_schema
./lldap run
Ctrl-C
</syntaxhighlight>

=== Proxy-Konfiguration ===

Für den Zugriff auf das Admin-Frontend über den Browser konfiguriere ich die Domain:

<syntaxhighlight lang="bash">
cd ~/doms/account.hs-example.de
rm -rf subs/www subs-ssl/www htdocs-ssl
ln -s $HOME/lldap/app htdocs-ssl
touch htdocs-ssl/.htaccess
vim htdocs-ssl/.htaccess
</syntaxhighlight>

Mit dem Inhalt:

<syntaxhighlight lang="apache">
DirectoryIndex disabled
RewriteEngine On
RewriteBase /

RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
RewriteRule .* http://127.0.0.1:33881%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"
</syntaxhighlight>

Achtung: Port 33881 wie in der Konfig-Datei anpassen!

=== LLDAP als Service einrichten ===

LLDAP soll als Service unter Kontrolle von SystemD laufen.

<syntaxhighlight lang="bash">
cd ~
mkdir -p .config/systemd/user
mkdir var
vim .config/systemd/user/lldap.service
</syntaxhighlight>

Inhalt der Datei:

<syntaxhighlight lang="toml">
[Unit]
Description=LLDAP Service

[Service]
WorkingDirectory=%h/lldap
Environment="PATH=/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/lldap/lldap run
StandardOutput=append:%h/var/lldap.log
StandardError=inherit
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Aktivieren und Starten des Dienstes:

<syntaxhighlight lang="bash">
cd ~
systemctl --user daemon-reload
systemctl --user enable lldap.service
systemctl --user start lldap.service
</syntaxhighlight>

Wenn alles gut gegangen ist, kann mann sich als "''admin''" mit dem Passwort aus der Zeile "''ldap_user_pass''" unter https://account.hs-exampel.de anmelden.

=== weitere Verbesserungen ===

Bisher ging es darum, schnell einen LDAP-Dienst aufzusetzen. Leider lädt die fertig kompilierte Distribution, die wir hier benutzt haben, ihre Fonts, das CSS und JavaScript aus CDN-Netzwerken und von Google Servern. Das wollte ihr vermutlich nicht. Ich habe dazu den folgenden Issue im Github-Tracker gefunden: https://github.com/lldap/lldap/issues/93 Wenn ich richtig verstehe, kann man selbst eine Distribution erstellen, die die entsprechenden Ressourcen lokal hostet.

=== Links ===

* [https://github.com/lldap/lldap Github Projekt LLDAP]
* [https://github.com/lldap/lldap/tree/main?tab=readme-ov-file#client-configuration Client-Konfigurationsbeispiele]
* [[LTB-SSP]]

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

OpenLDAP

2025-05-18T04:43:02Z

Sib: fix broken Systemd syntax of Openldap service file

{{Baustelle}}

== OpenLDAP installieren ==

Voraussetzung: Das Debian-Paket "slapd" ist auf dem Managed Server vorinstalliert.

<syntaxhighlight lang="bash" line>
#!/bin/sh

BASE_DIR="${HOME}/slapd2"
BASE_DN="dc=example,dc=com"

INITIAL_PASSWORD="myInitialPassword"

BIND_IP_ADDR="127.0.0.1"
BIND_IP_PORT="12345"

############################################################################

# Fail, if base directory already exists

if test -e ${BASE_DIR}; then
echo "Initialization failed." >&2
echo "Base directory already exists." >&2
exit 1
fi

# Create directory

mkdir -p -m 700 ${BASE_DIR}
cd ${BASE_DIR}

# Unpack initital configuration

cat <<EOF |base64 -d |tar -xz
H4sIALShi2IAA+w9a3PjNpLzGb8Cm0yVPXexI74ky1v5oNhOynse22vZqWS/XFEkZHOHIhWKmrE3
Nf/9GgDx4AMQZWtcud1R1ZQloUV0o5/obmBIGX3/5gu/BvAaDQZvBp47CgKXfXZ8n/2tXm8c3/Xd
kTvwAvjeGQSe+wYHXxox+lqvyrDAGP6Swg5HitVrIPS6LwL8j7IfojybJ/dfSBIY/4OgB/+d0Wg0
BP67vh985f9rvOr8h3eLPF6n5I/B58M0TuY7mYMyeEj5beD/aDAU/HdhBPgfDD3vDR7sZPYNr/9w
/n+LJ3e3Vwc/n12e3Uxuz07xT+cXZ/gAn17hy6tbfHZ6fvuXv+C7FcFpHC5BOJL50yH6Fp/cnHgu
PgpmQw9sNoqzY6wLD8pn/yRReZKGq9UxztPoPRu5SFYligBWAxRj12H5cIy/X6+K79Nk9j2dTg1e
5GF8jAF+FkYf/ncRz9CqLNZRuS7C9Mo8FcnK4unu7vz0GA+CURw5w8GB74/JgTPwooNxPHcPxl4c
+t7Q8QYDgqKChGVerC7DBWEEhfEiyb6TCsIByG2yICA2i+UxdgcuOC1v4IwCzxn+g894Mr1sjhwG
7tGRH/zjWy7y31b/4IXYoibEMitfdsusz+e/Sf+dXeu/xf+PvFFb/wdf9f81Xi/Tfy8gThDMnIb+
O33139la/wsyT7KyNeB8XpDFjBT5fGvD4M1H/nw0PzoYetG8MgxzMj84GgcgrkdzMBDz5xqGYDCG
B3qg903DIEcOnaE/9rxdGgZt1o38r+s/LNKPYGBJFv8Aaw1mdidGYJP/H3q6/4dxZxj4X/X/VV4v
0/8oHgy80YDrf0t4WkagGj7hwqu+YJptd+r1nzb8ehzPorpf917Rr4+D0eBP59f7vlr+fxU9kEW4
O+f/pof+O35D/wPHC77q/2u8Xqb/o9j3ZiEobuX/ufC09H7Kvq50l7r/Cs6s7rVfNLTdI6Fb03YS
v6K2B/54/P9W29uvlv8/DctwFq7ID38cOJ/nRZ6VYHZfZg426L/juk5d/13qVb7q/2u8Xqb/8/nw
aDw6CoX/7xSeljkQUCIOaAz/VP1OhQniBxAn1J6bRpMoIvRnED+UOf4vPHvCcXZIHsOo/OE+iS/X
dFPww+C/1+o91cglIQUYgZi+J48lKTKEw5R+CtflA16EWXhP6MPgiWArPtSmcuhUcpZvvuFwAFbH
yK3A2Hp8A4+ermfc7jV+MU3+BZuSRVIe4wAMidkoNtataRYH82HdLM42mMVdWEPHP+pnDf/MRvA/
+GWI/3ZaCdgi/1/Ff/DW/5r/f42Xif/wDmxqlBfk5VsBu//3hrTmV+f/yBl+jf9f5fVC/z87In7s
+CL+r0Rm8wZAAoLDLMsima3BAz0tCXfl+9g9DA79QxdfTt6f4b0PWf4pJfE9Oc/mebEIyyTP9vDp
2fQE7938dOK6wfAYf0BYgOFEhzv7+93k4vz2NxyB7zy/z2De92EZPeDpb5e3k1+xc+gdDg8dmM85
dPwhvHWCQ4Qd16FfBH+A1A6PPuN3ncg6ElmfI7uP91Yw6d5qXWTg+/bwuyaisColRnh/Hi6S9Okd
pmD7q3cYUMafHhJArHwgGJxuUj7hZIUp9RmEDHt4enfNoA24uBKXoFo4kNkkTHnk01owPoizNcJ0
HOdzbWLbst39OL290b6mgQ2gkt2vAADhDSvL19X3/xj6pkX1JCFDuagRrGmUr2koctlcVz9wxse4
/IRwfpCSEuI5fD69OoB4Yoir38DfmGgruBlDkAAHT88vf744O/hlcnF3ZkDWl8iOJLIpIJvmUZjC
SrawraQAkOUAkunAa644EBqukpisQI43Mj2Q0x8pASypAJYQ1V0V10X+Mcki0kQDYSEGFA6D7C0r
yJfhM5T4jDV8CkI4TvTNJI7hgav6oiBcYUMhcMhBuExKPHoLJaxtQyx7CSUou+MaVX0kKXMGkrQc
qMqL+zBL/sXMTQe3EaaE6UC1tZ2RNAcccZlvXNsjhYGjMFg3UAjTuywpdUQQ1gSvDorXAPtcfMYK
H2GqwXakpGVq2LcYvEEeJSBtCMf4U1I+1OzNhrkc5RYcX5q3sIgefobNXXtKPobvEabD3+GYLAsS
weQx3X2R7CEEUY+n+hP62AQ3MOGnPIEjzO9svUoyEOMTmPY+L55aSAIAwgwERxLmmYaXAiD8Qhl3
lA9xKtu7t8zBRKRSaRsk8FGQsFAAdOBPa24GGuhQgw54WA8H4phIUN7DGdVIOMk75IQPgXsAoSQv
WnwdZXAehsX3B8a1V57EOdIQv5rPk4j8mD+2cL+GUXyFMAPADOKl+MPa24XHgr9yRc5Y4P/wtErA
zZ2SNPlIiidOC7dNLU90XQFjAY05OObwvUhDeDNznqMXyq25A2HqSEqWD3lGDPHVLYwjzCCwAJE0
NH5cI6QxJmlBuDc1wQDCViMxypO5jkbMo4WQRyCBx4l97GTgmqZWLsx1talL8nhLikUCHuk8ph6B
Jo80RMDwSlQAFgtgrEP3wMtoNJQrcz3pWudhtEogSCe3TVbD0CP1rqi5Vj+Jn+D9n8LHd1j+UoqA
GUsIFCo8XdP6udrmSHjBR/iNyTr/Sh+IJzEYt4ZxztYLiP+jKZOsmvjVRroUCWH7KntDagtMFCg/
6Qo/mWQ0BVtFJMn09LJDEHkUVYOEIP/0kqJbV60elCFsom0zZUMjZcp3usJ3FuQe/BspSGziEGyC
sYARzki6UhoT1dzvRhyZ4zFJuatcoytcI4T1ZcJX9DyLwfyWecsCgFPQwIAJEu4Z7mYLKwabRItN
dpW/dKW/LMicFLCUwoW8J+VDHndIkoQE0ipvs6hgezgLX+wMEbbtDV3lEt2xQnEFNostpUkoENah
OkKrjocYFxVEorGsXp99ratcnidc3mq9XOYFxNCT5TKlMgDTn9BqzGMpaUBYhuACGocKHCKtCl4S
wzceypJrlCBs18cjE/LKxXnCxfEOsdZa86/pTjOku4UiXy+54sUJFfn7dbJ6IPGlJe2ifJonfFr+
KeuYin2L96tEC6oIf7fldMpVeZ4wM3lKrqJovQyzsj0rH0C4pERS0O0m9JTP8YRdo9nQE1JQftGN
S4ffCQYIjzGFw5EC/I5+g/86A1NS3+ookDNaVmsJM8IGETBJgKf8jCdsXTTZhPMYuHIy2QnGQ6Z6
22Cs/Icn7BktR+YF7I9vyMecKxDdMHXYM469hAe/In6AU/hFgwyjiQNjIfAcm/BUXsQTRk1bDSOm
IobjmGq/eA6uIA/6mhpxVT7CF0YsKnLYkqvpr8Oky+NVaFLgGrJLAO+7mhw/hOkXAxOKykf4rgw9
78ElVcmkvfusI384RzgpYPu3s+yxp+y978nALCmTMG07KDEAFgWWapUvWAYxTFNqYugkq+8wPBxn
ecnwqbLhgOjhZkSU7fZFjHtPwHIyCfn7GkLExu5AOE320N8FgIhTwMZR0y6fsBkBZdB9EaI+BoPB
XZb8viad+xNdaAY0pwaAONEgpd2YJWUtMu2hiEMTnsoT+MIwx5YFgmCZLQ7CDZyawdvVzenZDUQI
2sBVEZNWPE2HEe6RDjFEd6aMunI4vjDdnQm7lgAIKJn965vYc00hs68VeFSQmZd5lKe2ahSN4DiU
oRjV8ZAtIjjT/tDXakDC3nFpfN8d/VSiiuphEA+CJK76E3pwFww9C86M/FUOJBDB2UMOFtWsWpiO
A3+7deo5uS6ENyeErJU/X7mWwG3Fx+k9dcMPi67YXouLNbAeCmPycr5yIYEn93VpGVqiBo4Kg2r6
379u5d0s3tdXLiUQljxexPX0X4ULs8cgfafvT/doAthuon3lI4bCRC9XZB3n2dNCPBuMsTvY98uH
d7Dd44MIPy2Yq6ROSRSVNs1F3cHgcHzoer576Ixpd+JgAA59QIVceuxFmNCyXzGPjlz3PXxAeJY/
1jy34478YwxvAAJTEAaAuwT5fBJwUcVcmhG+qY82RbpPztwdwo50+Bn4bqB0bKFUZGuA1JgWY+Mc
KIbd32KZg+cldOPRIPV71/VHx5gDwr4PIDmcjd4pwk3t7aC2D610k4vwpm1uMLBxV7gfWbqKTxk1
e3rmj7O1IlNB8hKXpXL5JWg2EEm9GIwfHvlAluMF/piq7aGqIpJKfNlfmZZAoFUfotW4GtX467lH
g2OckvswesKhmI+pFgMWOQtWNIbIgz3MugbbrYBxPwgyrnJGWgdlrbVkKFtLqvaAljkKsRyh5gE2
z/kSA4J3J7d3N5ML/P5ueosj/H7yG6yeVofEb2mqLCqSJTOn77rxcCQewlyLboEORNTQ9A7h6xYm
HAVeN38LuJBJusrZOx2rFR1Ma+iB2poQdCWCwm7rZeM2kpkoKyOsxdhda5ZXCNPMwDVM9ykv4jay
nAjwA29xs4gKX2kZb/jUyrFyIptZTYQLGDAkCGFEq4BUnzqLEnwMQhGtHgDfGVLYMIJNVQTGFMo1
Rmat0ld95iVL+UGRZy6rgaR28trIaU9yOujgNO8l6OQ3rGerkcDC9rWV77xKXxPf5/OdbgRr+eyX
8B3hOud7872L7VWn1Vulri9gOzBAZ/x2bPcl22WZnxSrLtXGYoCzFjY2LeaC+clg2ojO1snl9rpx
PiOc90M3kOiOOqX02oA8BHzNhhedHP6+bU15v0pL4EAWepmaXgInZWGDqeklcNy4bTY1vSQO4X6m
5i3Vail2Bs4NJeeOOjl3k3f0C3XZF5W47nTFWcW6bhsBnNsBy6qlRDthWWUjYDto4pg0hXp634on
2olhqZgMa9bB5l7qOpJMFwlillK4mtMHtrfEVcaBJxNZ9hDvQ8j4zszufZGvqFmdhsuAzV5tGXn5
pSKnp+E5kpSIpr893gyZ0fyn0ewwWyHBNtkcSlHaTQN3ezSjsnXAYxJphJ8R8JhEGix4H8dXDZkl
l8ktLVHtLBJiUZXdNo0Vc0UeSqtUXhd51FWcBe6iWkVzKQA3GidNFtdSm0BpN+4X1MZFdlpqGJxV
LZSbENVbLbu1qqOurFQMYUaDuQZc1zahZT1thqM2RY5MYk0nHcYiTgr4JdWN1dOKdpMucHgPWOP9
kDa1gxhUlqO1RE1P3z5YQOXZgJ/aE8kG1Jh8BGnrQrEasOwdlUyoHn27uUqZhe+zlCqol72ooGB5
dj9Zlw9UCvii3K06m2xCzIFZNVFBs6BOCc/k7tfzi/PJzW+cnkZF2ICYCjtle6mqrVGZE/XLxpoi
zLbk2vNDBWnAaB8bqqfMMhgrlnRsUqOEMaqramggUgWrsgG1cn+8gmRygki6QZGWl74QdDnG/Nda
y5vNQQKRetre6ig3usk+JkoFerJ7lcrElERrygJjsQRhRjzrFFhVwPWaSQd/J3VLJNPoQLUJv5Em
eir90yl8B7+4fFY6jHAboIVKR7bdiIgWUsjy+c3FabLiSTTqefIka++lEdYMtcZMmyQbNAC/ZS1d
/XFWnlK2v8aL2OZJeJ6flmwMe8LOjI9134/wbgIgFnHAAuwkAGLhD8I9A6A+4TnaLuGzXWTuailQ
EfMsPyRNTxAcjahSXv/PubD6CHdqYS+z7yrXLrt+YdKTSWtKOqEmz/RYgdXOM8EyCnldNRC2mvm3
BhNvIElFA26t5HZyc9FJlXCeIoNbJ6JTFzvn9VgmX5UA3GAAn6SbT8MZCF18d3N+VRUe9La8wWh8
LM75lA9hyZrxwiRbsXoY/EhL5ZdPSwhg+Aqrp8J6ABuo8tRo6MbVN5ZWtCMCoCrLlAg3wZ4BEdNe
s7zCwZSH0It3hnCEGxuwGrEBv6CxlqyU4MmmkzhqrCH1V7SihVo1rU3oxJEBhaGGAv0rdBLMYnty
bwSTwwjMhrCd/ITS/Lz7dQLHbVwkQV7zfp3xyP03ul/nz/6ynf93Pkc59cUvvQHAfv7fHdLD/o3z
/4Hz9fz/q7xeeP+X77qjeTCQ5/+FyPS4AUCBGu4AMDYiyHNDj+VZRs91x1c3VaiE8M6O8Bm6d52A
91CYrwMw4S3cCt3bNN0bOFTeoGhqF9uGFlqD7XvmzR345gMWFmK0ZhCY9AM7EfUxp66ZnLLTNR86
Ol8oCIXA1W/6UPf8/kI7pzwLcfL0Tp4vmkeREK6IoYPtw0df5LIEOyXmKMuR1TLYhZRNoaM5FfY9
3v/ZA948vuvVKekBLmC2TdgEFmz0vAAzDbXucL6s4hw0y4Ksnrm2W5wxsq/t0EKNCGAf8lUrXAV9
pl+zABEe97JmxX6nui1UjCxUyLIGv/RM3wXSsgNlyeklZYYcl5S0DpBY15x2wSt8TQ2stl47maSP
82i9gBhS6xeFBW8Ym1YTNiVC/NLOD4S38hNb88PWZifz+wLVW3WjQnWPA6eP16h709SiiNUKd0eT
Y3PZKqFf4foLBFM8E4hwnW0f+cjzCKMZol0zy7H5dFUJqHDlKULKLhAinS6uRDxVYSDOok+bjtwa
9cmxOXGZNRDIXFT5h472xlR0CGu4Y/Dm9zRZtoFDCH9RdXJsvtxVd7U85AtyTdNxe/w9wq1z3a2Q
hcKp9F/b38shhLc4yb+JcO3wR2A6N+TY/L7M7a0IbMbLUOtwpIkgXSQ1iO0tOzXqfSXRFhnItGBe
PtA1rFqje502N3WfOzbnLU9ohzckyotYIx51tqc+v/nWsblfeQ57cdpEBKz9jhGxOVd5hHrx65dH
xNpnLuKqbPrFEXGtzd/y1PPVpIEJrYTvGBObl5FHmCP6p4YLbI8M/dQvwMXmM9TRVNnoLs5zdHo8
luprdcXHVRe92eIg3Ns5GC/LsPkFT4Xv4BVqVxy1Y0nmBZqXM/S75wjCLPNNRy+558iSXXfUYVfe
bRSmKoqEDaxGmRjH1cVdW25T+EUaO/Ljrs1D+OqswiKfJRTX6g1o40Y3ziH7OHLa9bYzR07vENzo
yF2bn9KOBC/59ov/vW32oHcQzQB7BS+iG3UnwYsT0KhgA802n+irQ1URvV9vXiQki9OnkxzQ7LwA
skovVXDyzsfMfm8U2joj2CnStmshjCSKfcO6daa4FXnXN7L2XEITXXodzHY6aHPNfvcRgWlJM1nr
Vatm1+i8pjdNrrsNZ93GIPzF9gqezePLU9T/DDNSyii0tfX+Gx3GCzG+9bEmWKztj3ZZqbLmnWWI
CQhfs34IkkXkasm73VpcY8e3lhIO58uqDafH1UMQzloutzBiKGKK2TpJY1gWdUK0tu7ijKgA29Zd
IbxTUbKFF74IL+LphJ3IVy1tCKsQaTrBcrQHPuM+F/d4tsBAngpfwUKk5IJ8JGmFAa2dNERhyoAw
g9oKUY8e4e2Bqs3jy7Phq/WMts28T7JksV5QNBCutwhW2HI4TAHB1/VFmNlImqLqg7DNV2vHwDnC
4WNPhBlg9kUQtjlaeVhcRIHT5D4DG12Qjhj4WkSKEqh33YAj7Hq2+zaMOMoM2/ntDeGtv9VCIn2z
cX6L1fAzUtStOxaM2wrP5iID4SLDdZzUKy4IU0TZ93h/fZCGn3oVXHx7vcW3ObRg2EjwXa9nKV2L
roT5Uoxtn3t9SZHOfFLX1DqkblpfJmleikMYexn5dA0uTfvqnfWUFy0vJfwkRLuSTNsM5wiLw/wz
1qWnapy0gMlO5ogKIXyQZS14T3eMjewiaztu7TZZ72OVgaONfvp+zdK/iLo7JfXAhXbvatk0+Fjt
l1pdiQiLPUVjoB3nrSnC7UAizyTu9H/SUSbCcgDaxF6pQRGL4+tNprB71dpMKw6KHlzV/ag3lOoX
sddpgt1E+0vt/mzGL3NXrDmkkRfX7yk90qhAuNYs2y5nic7efLHIBYom8pCFwI3k1YpM/HhBvUKj
wfDShvaFqBZoX0n7YjtubFozEadSpbJ1P2vLwteppoWmddK3swjPzCjauhbHDbZOQf6IOPkD0XTH
OY8mshvxy5S1eDZnLcdojQ2ZqkbHc3NmtdOu/mDNj1Ubbi0h2I0uIx6CIUG+9SBCvUO80T4ulgZh
2QXd+v8OZMN1z0bqJXCw0XfdPHum92w3n93o+6abK0PD+LneLt5uLu9oRYeti96M/tjjSJ2hI74g
98CAZvu8fmzWcpLXKDwiSuOX2zDmXIcFN3v0rAHvl2254JqFqy6Js+tw6+YFO0ft/KQ18C04aucn
7Oq34aidn/TA8hYctfOTnooxHdM1clTWhi+np5pFYJykN4e0eFkVSWDy96fq7a/y7eVUvp1eKWDY
4quqhu0YrhHTUc1w3ZCU2qCqe7od5tKz5eJ/NWGQYOTol02z1+ioptYNwkHtDiDzmVIjpiLPoWU0
5R0ztLhV5S2bPqQBru5q7TwnappdntxhUfNV7T4XxMjer/8vJV3ehYbUdcbrORvLyU4jVo6O1Sk9
8MnEbBVi1jegT6VyKZYjmsaJxO78d/6IC3qmIQVmhvTGA3Pn/ioUc4pTZ81sBB17K7+Hhz3qI++e
3Yg/mgf1/9aazF+xEX/kBP7XRvx/95et/9/9nCWrHfxP4Pb+f8cPhk6z/3/g+l/7/1/j9bL+fz/0
B8NZOJf9/0xkejT//197V9vcKI6E77N/hao2H672sglgMDhX88GbZOZ8N3Fcca5mv21hwA43DrC2
s5Nc1fz365aEkBBgkjjeqw3aqh2H19YLT7e6W4/4dTWZ/8WCKOo3FBzAQSpiTLd3Efl0eX49Qy7b
Vfh3XGUPh5g9WR/4a0k31z75gNEM7vLCmlql8skW+oMucj4DuXL+fJOCsftAGadxq6yUVpBmIoTF
DUodKRF5bQYIo6F+ifiWJn5u7q/SZZzM7kCRyrLnArM+odeQDbvoGfKWpKXit5O3r8krWBDu/DD9
9tnfbM/v/GQpDxIw6JHfqRXDLWs7t+32gKosA0WWKyUNBmcVTISWSwPaCeFoQriqEP7j2wsx0ITw
FCG++OtEDeoxQXpkz13iaoIMFUHGCQxLmHmVJYHhsWdJPE0SkY7PRLl8zOBbf/smGeqCmIogH1e+
3jPr9kuN2olh6ugv8uEZ4dO/47ACRABoqpA9x5fnhSV4tKo2eVEHc+E6YzJO4s0k2pZJtHtVkPdS
WSn9aYtESx25hacmKaS8XcdZwcI2QYooxkSy5SdKQuB/xkltYrIOv8KZEGezaI3UONN0vS2NJ3jp
vr8vU0dfwTtTiMKZ2CUi6DqCZFMHUuF9iLP8Qdpmb+gv2e5ftZg6ogoPQ5oEN1mgS/I2OGbqkCrW
98fZP9LNVl1GN56yNMoeqUmkfFYaa+PGfTrECj9InMFQ/5auv2rCYTo/PbMf4Xrke6tW1FFYeEeo
rPf+pkZWPHNQWa0KO10gtR+UNra6Gp3zvFno8bftcEuHZ0HQMU/T7dRfwxe+LZpwnQUncAIaMcNT
IcmKKypxrzYhVwdbsUcfvvljXGDsz/A3ie/9ZUQwYKrNVp5lGTdpAEsHY7H0ATTAlZ+xXKtdW4vr
QCpWLrDHXDJHZqkWULd9qLuBsic7DgADJKoYp1VpBLLY1olwgqab+HGUh5hZr4xQFrT9Usobu0C3
MI9Cs7T16fVs/EvBkbKp9RpSgqYjSsMB/++ROBQO/qX0W5n91RElFXMsvBu+dpgGtyP7KX8K1olq
1JWrH4Yx8/Qi746oJCV1ZzfAt8HEqq/5g4jH59XokZzxqTT5EodgDlT89h/Fbz4jEH+DYQ61R9Nc
HGIGsvgTzdSWREha21jyyPjErDdtXCAv7UIiLM3HRwP7Ix8LRb9L/QyGvNTTwsRtV4Xyp20Jr4Kw
bapqQEmRxzR8FW1JbrRQ5kTBWdhQD8WEoykDmiXFa6hUoS7SrlbA1oyp+j5ICGi/TDHeGsVWzbOi
iTG0miZtZS5bgFbBm05Nrkp5F6zRryfnpzfTczLHnalwprtDZtmIU4cE5blrJW/ZRrROBophVicv
6dHcl2PezjKhZT3eybaeGOY6beVRvpi8iT9YFdot22zVciNwUXmT/Kqdw0KxAYXQeJzbVaL9yxRr
O6tRtj0t4fFI5CmiXpEe64JEXLKTWVabzQk4mWC0Pz/XDljKdqglHCRM1wuRGWlJHKC3EoXnnxIV
fjKeQfs0yF6YH+1GsuYcsApvCTxLpcsaJXzlWUxJcHdLw8eDZMyIv3hGDRNSocKsjXaWxBRWfBRF
nmFdKLSxI/5xwdilRoZPCnO5Ws+CIIWN3RAKLUlhScaoP19FlWIgYyMVA68qbOFaQf5KctsW03lk
A5tuj/3S2OdwMVRJyBbGIWOfQ894H7HPpvhf/3sMCJSulyyx88WRwOb4n+HYbl+N/1mm2e/ifwcp
r4v/RRH0mD0fiPhfaci0iARqd9TEBC2k7aXbV+EGVm6fsl6K+Uzgrz8DliUbhYy7R+BDRkqRuzgA
fFqxK3CnUpYyteb87Su6HfCORHdl8fke1wmatZUTTDARwPAW001l5w9fGWXRKgqWmw0lH8+vp0iO
m5IlRN2/qVxXMDheypKm1xUjdbWrIutrawt6n3gDXfKkbBNI6UtpVYuN26m/YpuSeYRTqZB8u4sS
wm/GaSMCPM3OPUBtW0Ylq6ueT9ui+2yVPkWR6uOj68VY3ZOHezS3/NXqSelyMHb4rbt6XGUueGUb
yMub27WBXdsGdqkNbin9rMS6xloAWWkprQC9jI5xdE8UuxS1WK4CJs7ev+KmhWyD3Er9TxYtpyoT
m6iYT/45vfzEfIKteNjqthEf1A+z3IoXn9BnP1k+0BdK7A3lz+zbOt5uIxxPZJOlX+HXit9W3/QF
68EePrPc79duiLn1Q0zsiIu89Ffjq0t5O3g5U5Q1wfRf57MfXLrejaUJMpgBxOHM82R2ik+p6K6K
ddd1I8erR0QRq6KuNJDGtCpGjqBwYIigsucfUxbv8xn5Acz/6cdf2m2n3rAoq0rUwneGuvx6vSzv
iyNkFW6na3Vp+FTaIKdqZy95utYTtN+4kq5yDUFhDtAJr6o+8ZDQMDjdOSIq8EoHsJOo747vxp6v
4KJ8CtpqLgxn0dRwvjn6ERFfPLoPChJttoRKciDka7MI23EBl2Px/Qr5zcoSF3nBGHcxl2jYjwhu
WF6QC0jLB7SPn99e/iDyJRd02L0ii3XuDi11JmcecCbnOcP++5jJvayo8z/oSsS5OcA0cvneh/PT
PbwDG9x1jLr5H5ZS/ufAgNPE2cO7d5Z3Pv/b2f+oBn6P1oCWHwD/ATviZPtMTwCd/xu1/W8atlua
/1uu63bz/0OUV87/B2DhLsIhnf9XjRTNAcB1RPkwv7Hm7A19VtXJbZr1itupiZK/OL9NGFxn3CGO
XLZsT6Rc+7Idj+Ttkhp0nSKMpOsczw78uRP9NOgHC67rFgvjJ2/owLD3FqDzFi/VdY4xhAfalq7r
xBmwyfre0NunrpPe+kcP0668UXkW/sMR/gU9SwPswn/LLq3/sNDK6vD/EOV1+L9wHC/wbUfD/2Kk
aGDOAPZaP9GsA1qhv/za4k0XMNFZxcnyjMC8J13LpwDMYUp6husML+XjNP3j+vyM6Bv3NV2mXcD+
HV2cqdpFu+J6gdfc501Tr31E60maZ+B5QRAGnqp5zH1qHseu0zyOfWIaLnzXb6B58K1/9AfyJy8N
+G98Z0dfvQJwR/wPhk+/vP7PNrv430HK6/B/2F94RmC4Of7rg0fD8fySHM+LI9R6D8ThUYCbKtOD
25T8SOZPJExOIswb/SBy6T4Yf3sofiOuZFG0BigL8Xf0iN5GJCTCv5B7n5v8+DB4IiDeVzpRSNPt
xaQSn/jZ6ZczMp6Mb8ejz79OR7PZl+ubiwaULlWy5BHrDy1fXdcd7PCI7WNftb7TcnLwrvxf773s
sv/3sPx7J/4PAPM5/ruuO0D/n9vv/D8HKa/D/8Fi6Iem4+j4TwfPTvAvG7fhvFIt8IfBsbnIlj8j
P49ml79ejG9Of/epRT17WCzix/z4RNchmNK++aBk14Me2ESrBY1xUq3gJ2nydJ8+bOhWLUxPJJQV
XHmeWTxPy2rXnvkjAdwOlfstodOKk/iIqzQsJiOaWpJqVquUaCud30XB1wx3kT4jjmmRvsGOj5Mw
esx3gGVUhdFvyqkgOcaIUumo0LHHRRZ76RI2dzkuUtjz81f+4yz+L3Qj2nlg2HmW3TS/EUNAVZoR
KDBPDSPZhwsj9U3b+HMmBCr4vw+wryg78B+GRY7/0DAOHDfhws7/c5DySvyfz10vKPg/amz+T6t0
7q9ovp9k36+XG0wbloB8/ZCcblZ+Fp74cJJiYrqk5NNnCMIUgqdxWHtXFlMgvU3T1e0dwiq83mwA
Gy5XyTy33EXJPPff3jy3vUHLOPV+cQUb700H2F94/Lfe/yvHf2ks0DANZ2B18d9DFLCd/s/636b9
b/e7/u9KV7rSla50pStd6UpXutKVrnSlK13pSle60pWudKUrXXlJ+R8PJCZ+APAAAA==
EOF

# Patch configuration files

sed -e"s%BASE_DIR%${BASE_DIR}%" -i $(find -name \*.ldif)
sed -e"s%BASE_DN%${BASE_DN}%" -i $(find -name \*.ldif)
sed -e"s%INITIAL_PASSWORD%${INITIAL_PASSWORD}%" -i $(find -name \*.ldif)

# Fix CRC32 checksums on configuration files

for FILE in $(find -name \*.ldif); do
CRC32=$(tail -n +3 ${FILE} |crc32 /dev/stdin)
sed -e"s/^# CRC32 [0-9a-f]*$/# CRC32 ${CRC32}/" -i ${FILE}
done

# Add Root DSE

DC=$(echo ${BASE_DN} |cut -d "," -f1 |cut -d "=" -f2)

cat <<EOF |/usr/sbin/slapadd -F "${BASE_DIR}/etc" -b ${BASE_DN}
dn: ${BASE_DN}
dc: ${DC}
objectClass: domain
objectClass: top
structuralObjectClass: domain
EOF

# Print instructions

cat <<EOF

Instructions
============

Launch slapd (debug level 0 - foreground mode)
$ /usr/sbin/slapd -h "ldap://${BIND_IP_ADDR}:${BIND_IP_PORT}/" -F "${BASE_DIR}/etc" -d 0

LDAPvi on cn=config
$ ldapvi -h "ldap://${BIND_IP_ADDR}:${BIND_IP_PORT}/" -D "cn=admin,cn=config" -b "cn=config"

LDAPvi on ${BASE_DN}
$ ldapvi -h "ldap://${BIND_IP_ADDR}:${BIND_IP_PORT}/" -D "cn=admin,${BASE_DN}" -b "${BASE_DN}"

Do not forget to update the intitial passwords for both identities:

cn=admin,cn=config
cn=admin,${BASE_DN}

EOF
</syntaxhighlight>

== Basis-Struktur ergänzen ==
Für viele Anwendungsfälle – wie eine Synchronisation mit [[Keycloak installieren|Keycloak]] – wird empfohlen noch zwei <code>Organizational Units</code> zu ergänzen:

'''Editor starten mit:'''
<syntaxhighlight lang=bash>ldapvi -h "ldap://127.0.0.1:12345/" -D "cn=admin,dc=example,dc=com" -b "dc=example,dc=com" </syntaxhighlight>

'''Oben die folgenden Zeilen ergänzen:'''
<syntaxhighlight lang=bash line>
add ou=users,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: users

add ou=groups,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: groups
</syntaxhighlight>
Nun den Editor schließen und noch mit <code>y</code> bestätigen.

== Autostart ==

Um den neuen LDAP-Dienst dauerhaft laufen zu lassen, sollte [[Systemd]] genutzt werden. Hier ein Beispiel dafür:

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

In das Verzeichnis die Datei <code>slapd.service</code> legen und mit beispielsweise den folgenden Inhalten befüllen:

<syntaxhighlight lang=ini line>
[Unit]
Description=Slapd2 Server

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=/home/pacs/xyz00/users/ldap/

# eg -d 255 for higher loglevel
ExecStart=/usr/sbin/slapd -h ldap://127.0.0.1:12345/ -F /home/pacs/xyz00/users/ldap/slapd2/etc -d 0
PIDFile=/home/pacs/xyz00/users/ldap/slapd2/run/slapd.pid

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

Im Anschluss:
<syntaxhighlight lang=bash>
systemctl enable --user slapd
systemctl start --user slapd
</syntaxhighlight>

'''Hinweis:''' unter Umständen muss ein Administator diese Funktionalität erst für Sie freischalten. Ihr User benötigt womöglich außerdem die folgende Umgebungsvariable um die Befehle ausführen zu können:
<syntaxhighlight lang=bash>
export XDG_RUNTIME_DIR=/run/user/$UID
</syntaxhighlight>

== Pflege der LDAP Daten über die Kommandozeile ==
=== Benutzer anlegen ===

Datei adduser.ldif (entsprechende Werte ersetzen):

<syntaxhighlight lang=bash line>
dn: uid=mmustermann,ou=users,dc=example,dc=org
objectClass: inetOrgPerson
cn: Max
sn: Mustermann
uid: mmustermann
userPassword: TopSecret1234
mail: mmustermann@example.org
</syntaxhighlight>

Dann ausführen:
<syntaxhighlight lang=bash>
ldapadd -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f adduser.ldif
</syntaxhighlight>

=== Passwort von Benutzer ändern ===
<syntaxhighlight lang=bash>
export PORT=30389
export BASE_DN="dc=example,dc=org"
ldappasswd -H ldap://127.0.0.1:$PORT -x -D "cn=admin,$BASE_DN" -W -S "uid=mmustermann,ou=users,$BASE_DN"
</syntaxhighlight>

=== Nach Benutzern suchen ===

<syntaxhighlight lang=bash>
export PORT=30389
export BASE_DN="dc=example,dc=org"
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT # geht sogar ohne Benutzer
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT -D "cn=admin,cn=config" -W
</syntaxhighlight>

Was kann der normale Benutzer sehen:
<syntaxhighlight lang=bash>
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT -D "uid=mmustermann,ou=users,$BASE_DN" -W
</syntaxhighlight>

nach Personen mit bestimmter Klasse suchen:
<syntaxhighlight lang=bash>
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W "objectClass=inetOrgPerson"
</syntaxhighlight>

=== Eigenschaften aktualisieren ===

Datei modify_email.ldif:
<syntaxhighlight lang=ldap line>
dn: uid=mmustermann,ou=users,dc=example,dc=org
changetype: modify
replace: mail
mail: mmustermann2@example.org
</syntaxhighlight>

Dann ausführen:
<syntaxhighlight lang=bash>
ldapmodify -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f modify_email.ldif
</syntaxhighlight>

=== Neue Gruppe anlegen ===

Einmal vorbereiten, memberof overlay installieren:

Datei add-memberof-overlay.ldif:

<syntaxhighlight lang=bash line>
dn: olcOverlay=memberof,olcDatabase={1}mdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfRefInt: TRUE
olcMemberOfDangling: ignore
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
</syntaxhighlight>

Dann ausführen:

<syntaxhighlight lang=bash>
ldapadd -H ldap://127.0.0.1:$PORT -D "cn=admin,cn=config" -W -f add-memberof-overlay.ldif
</syntaxhighlight>

Datei addgroup.ldif (entsprechende Werte ersetzen):

<syntaxhighlight lang=bash line>
dn: cn=admins,ou=groups,dc=example,dc=org
cn: admins
objectclass: groupOfNames
member: uid=mmustermann,ou=users,dc=example,dc=org
</syntaxhighlight>

Dann ausführen:
<syntaxhighlight lang=bash>
ldapadd -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f addgroup.ldif
</syntaxhighlight>

=== Benutzer zu einer Gruppe hinzufügen ===

Datei addmember.ldif (entsprechende Werte ersetzen):

<syntaxhighlight lang=bash line>
dn: cn=admins,ou=groups,dc=example,dc=org
changetype: modify
add: member
member: uid=mmustermann,ou=users,dc=example,dc=org
</syntaxhighlight>

Dann ausführen:
<syntaxhighlight lang=bash>
ldapmodify -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f addmember.ldif
</syntaxhighlight>

=== Liste alle Benutzer einer Gruppe ===

<syntaxhighlight lang=bash>
export FILTER="(&(objectClass=inetOrgPerson)(memberof=CN=admins,OU=groups,DC=example,DC=org))"
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W $FILTER
</syntaxhighlight>

=== Benutzer aus einer Gruppe entfernen ===

Datei dropmember.ldif (entsprechende Werte ersetzen):

<syntaxhighlight lang=ldap>
dn: cn=admins,ou=groups,dc=example,dc=org
changetype: modify
delete: member
member: uid=mmustermann,ou=users,dc=example,dc=org
</syntaxhighlight>

Dann ausführen:

<syntaxhighlight lang=bash>
ldapmodify -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f dropmember.ldif
</syntaxhighlight>

=== Benutzer löschen ===

<syntaxhighlight lang=bash>
ldapdelete -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W "uid=mmustermann,ou=users,$BASE_DN"
</syntaxhighlight>

=== Gruppe löschen ===

Datei delete_group.ldif:

<syntaxhighlight lang=ldap>
dn: cn=Test,ou=groups,dc=example,dc=org
changetype: delete
</syntaxhighlight>

Dann ausführen:
<syntaxhighlight lang=bash>
ldapmodify -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f delete_group.ldif
</syntaxhighlight>

== Links ==
*[https://www.vincentliefooghe.net/content/openldap-setup-multiple-instances-server Ein Setup für mehrere OpenLDAP Instanzen auf einem Server]

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

Diskussion:Mlmmj

2025-04-11T10:39:28Z

Sib: add section Mlmmj PHP Web Admin Front End

= Mlmmj und DKIM =

Testweise habe ich E-Mail so geändert, dass sie "sauber" von Listenserver als Absender kommen und an den Empfänger gehen.

Ein Skript zum Umschreiben des From:-Header:

$ cat bin/receive-message
#!/bin/bash
sed -e "s/^From:$[^<]*$<.*/From:\1<$1@hs-example.de>/"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/lists/mlmmj/$1/

Damit wird vor der Übergabe an Mlmmj die From:-Zeile einer eingehenden Listenmail so umgeschrieben, daß der Realname erhalten bleibt und die Adresse mit der des Verteilers ersetzt wird – also bspw. von <code><nowiki>From: "Hinz Kunz" <hinzkunz@example.com></nowiki></code> in <code><nowiki>From: "Hinz Kunz" <meinverteiler@hs-example.de></nowiki></code>. (Der Name des Verteilers ergibt sich aus dem Parameter $1: siehe den Aufruf von receive-message in der .procmailrc unten.)

.forward und .procmailrc:

$ cat .forward
"|/usr/bin/procmail -p"

$ cat .procmailrc
SHELL=/bin/sh
HOMEDIR=/home/pacs/xyz00/users/lists
MAILDIR=/home/pacs/xyz00/users/lists/Maildir
PMDIR=/home/pacs/xyz00/users/lists
VERBOSE=yes
LOGFILE=/home/pacs/xyz00/users/lists/var/procmail.log
DEFAULT

:0:
* ^X-Original-To: ()\/[^@+]+
|/home/pacs/xyz00/users/lists/bin/receive-message ${MATCH}

:0
{ EXITCODE 67 }

Im "control"-Ordner sorge ich dafür, dass der To:-Header, die Message-ID und die DKIM-Signatur gelöscht werden:

$ cat delheaders
DKIM-Signature:
To:
Message-ID:

$ touch addtohdr

Das Flag "addtohdr" sorgt dafür, dass mlmmj einen To:-Header an den endgültigen Empfänger der E-Mail einfügt.

= Mlmmj PHP Web Admin Front End =

* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;
-> Die Datei config.php existiert nicht!

Traffic

2025-03-25T19:12:59Z

Sib: add troubleshooting for traffic cos of Wordpress login bots

Als Traffic bezeichnet man Datenverkehr zwischen zwei Computersystemen.

Dies beinhaltet [[Logging#HTTP-Traffic|Web]], [[Logging#Mail-Traffic|Mail]] und [[Logging#FTP-Traffic|FTP]] Verbindungen.

==Traffic Ursachen erkennen==

Hostsharing teilt per Mail mit, wenn der tägliche Durchschnitt an gebuchtem Traffic überschritten wurde. In der Mail steht, welches Paket den Traffic verursacht hat und die Warnung, dass Konsequenzen für die Monatsabrechnungen entstehen können. Wer nicht selbst die Ursachen des zusätzlichen Traffic kennt, kann sie mit folgenden Methoden ergründen:

Als erstes einfach mal den Log ansehen und durchscrollen.

<syntaxhighlight lang=shell>
less ~/var/web.log
less ~/var/web.log-yesterday
</syntaxhighlight>

Da kann man oft schon alleine durch Ansehen gleichförmige Strukturen erkennen, z.B. massenhafte Login-Versuche auf einen Wordpress Blog, die sehr viel Traffic generieren.

==Webzugriffe analysieren==

Diese Idee von Michael Hierweck: Wie bekomme ich heraus, welche Web-Zugriffe für mein Traffic-Volumen
maßgeblich verantwortlich sind?

<syntaxhighlight lang=shell line>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n
</syntaxhighlight>
* Zeile 1: Traffic aus dem Log extrahieren, sortieren, zählen.
* Zeile 2: über die Einträge wandern
* Zeile 3: Produkt aus Zugriffen und Einzelvolumen berechnen
* Zeile 4: Ausgabe von Produkt, Zugriffen und Einzelvolume je Zugriff
* Zeile 5: sortieren

Das Ganze als Einzeiler zum Kopieren, Einfügen und Ausführen im Terminal:
<syntaxhighlight lang=shell>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//'|while read FACTOR SUM; do echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";done |sort -n
</syntaxhighlight>

Dieser Skript gibt den Traffic aus, den gleichförmige Einzelzugriffe generieren, die größten Brocken stehen unten. Z.B.:

<syntaxhighlight lang=output line>
219558 6 36593
232288 14 16592
239998 22 10909
270812 2 135406
304520 5 60904
318248 14 22732
559062 14 39933
602760 20 30138
711496 8 88937
2325929 101 23029
2351668 29 81092
</syntaxhighlight>

Ganz unten sieht man, dass 29 Zugriffe mit je 81092 Bytes zusammen 2351668 Bytes Traffic gekostet haben. In diesem Fall kann man nun ganz simpel im Log nach der dritten Zahl greppen und in less anzeigen, z.B. so:

<syntaxhighlight lang=shell>
grep 81092 $HOME/var/web.log | less
</syntaxhighlight>

=== Wenn ich dieses Script öfter brauche ... ===

lohnt es sich, daraus ein kleines Programm zu machen.
Dazu einfach

* Texteditor Eurer Wahl öffnen
* Script-Text hier kopieren und in den Editor einfügen
Hier noch mal eine etwas erweiterte Version
<syntaxhighlight lang=shell line>
#!/bin/bash
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher heute -----------------
echo ---------------------------------------------------------------
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10

echo
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher gestern ---------------
echo ---------------------------------------------------------------
echo
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log-yesterday |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10
echo
echo Sie koennen nun nach dem Versacher suchen, indem sie die
echo Logfiles des Tages nach dem Einzelvolumen durchsuchen
echo 'Befehl: grep 81092 $HOME/var/web.log | less'
</syntaxhighlight>
* Script als Datei ohne Erweiterung unter einem griffigen Namen wie "volumenauswertung" speichern
* Scriptdatei in das Home-Verzeichnis des Paket-Users auf dem Server laden.
* Permission x zufügen, um das Skript ausführbar zu machen.(In WinSCP: Rechtsklick auf Datei, Eigenschaften-Dialog öffnen, X-Eigenschaft für den Eigentümer setzen)

Nun kann man dieses Script jederzeit mit ./volumenauswertung starten.

== Wie erkenne ich, welche Webseite gestern am meisten Traffic Volumen hatte? ==

Dieser Einzeiler sollte es zeigen (Datum entsprechend ändern):

<syntaxhighlight lang=shell>
for f in ${HOME}/var/web-*-20230401*; do echo $f; gunzip -c $f | perl -nE '/\[.+\] ".+" \d+ (\d+)/; $sum += $1; END { printf("%.1f", $sum/1024/1024); print " MB\n"}'; done
</syntaxhighlight>

== Wie bekomme ich IPs mit massenhaften Web-Zugriffen erkannt und gesperrt? ==

IPs mit mehrstelligen Zugriffen werden so gefunden (Hier alle IPs mit vierstelligen Zugriffen, beachte die Ziffer 4 im Ausdruck "egrep '^[0-9]{4,} .*$'"):
<syntaxhighlight lang=shell>
cat ${HOME}/var/web.log |cut -d ' ' -f2 | sort | uniq -c |sed -e's/^ *//' | egrep '^[0-9]{4,} .*$'
</syntaxhighlight>
Als Paketadmin alle IPs mit 10.000 und mehr Web-Zugriffen aus dem
heutigen Log filtern und dafür Sperreinträge erzeugen, die man in die
.htaccess kopieren kann:

<syntaxhighlight lang=shell line>
cat ${HOME}/var/web.log |cut -d ' ' -f2 |sort |uniq -c \
|sed -e's/^ *//' | egrep '^[0-9]{5,} .*$' |cut -d ' ' -f 2 \
|xargs -n1 -r -I XXX echo "deny from XXX"
</syntaxhighlight>

* Zeile 1: Log auswerten und IPs extrahieren und zählen
* Zeile 2: Filtern (Mit der Anweisung '''egrep '^[0-9]{5,} .*$'''' werden durch die Ziffer 5 nur die gefundenen Einträge mit einer fünfstelligen Anzahl von Zugriffen gefunden. Ändert man 5 in 4, werden analog alle Einträge mit vierstelligen Zugriffszahlen gefunden.
* Zeile 3: Einträge erzeugen

== Troubleshooting ==
=== Viel Traffic durch Login-Versuche auf Wordpress-Seiten ===
Login-Versuche auf Wordpress-Seiten können viel Traffic verursachen. Auf folgende Weise können wir diesen Traffic vermeiden, weil stumpfe Login-Roboter nicht an der [https://httpd.apache.org/docs/2.4/howto/auth.html Basic Authentication von Apache] vorbei kommen. Wir editieren die Datei '.htaccess' im Domainverzeichnis:

<syntaxhighlight lang=shell>
cd ~/doms/example.com
edit .htaccess
</syntaxhighlight>

Im Editor geben wir der Datei ''.htaccess'' den folgenden Inhalt hinzu.

<syntaxhighlight lang=shell>
<Files wp-login.php>
AuthName "Protect against silly robots, User username, Pw s3cr3t"
AuthType Basic
AuthUserFile ~/doms/example.com/.htpasswd
Require valid-user
</Files>
</syntaxhighlight>

Wir generieren den Hash für das Passwort ''s3cr3t'' für den Benutzer ''username'' mit dem ''htpasswd'' Tool auf folgende Weise:

<syntaxhighlight lang=shell>
cd ~/doms/example.com
htpasswd -b -c .htpasswd username s3cr3t
</syntaxhighlight>

Danach existiert die Datei '~/doms/example.com/.htpasswd', mit der Apache den Benutzer und das Passwort prüft.

Falls das Benutzer-Formular der Wordpress-Instanz im Browser über die Adresse ''example.com/wp-login.php'' erreichbar ist, werden wir in Zukunft als Erstes von Apache und als Zweites von Wordpress nach Benutzer und Passwort gefragt.

[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]
[[Kategorie:Traffic]]
[[Kategorie:WebStatistik]]

Traffic

2025-03-24T13:02:21Z

Sib: add troubleshooting for traffic cos of Wordpress login bots

Als Traffic bezeichnet man Datenverkehr zwischen zwei Computersystemen.

Dies beinhaltet [[Logging#HTTP-Traffic|Web]], [[Logging#Mail-Traffic|Mail]] und [[Logging#FTP-Traffic|FTP]] Verbindungen.

==Traffic Ursachen erkennen==

Hostsharing teilt per Mail mit, wenn der tägliche Durchschnitt an gebuchtem Traffic überschritten wurde. In der Mail steht, welches Paket den Traffic verursacht hat und die Warnung, dass Konsequenzen für die Monatsabrechnungen entstehen können. Wer nicht selbst die Ursachen des zusätzlichen Traffic kennt, kann sie mit folgenden Methoden ergründen:

Als erstes einfach mal den Log ansehen und durchscrollen.

<syntaxhighlight lang=shell>
less ~/var/web.log
less ~/var/web.log-yesterday
</syntaxhighlight>

Da kann man oft schon alleine durch Ansehen gleichförmige Strukturen erkennen, z.B. massenhafte Login-Versuche auf einen Wordpress Blog, die sehr viel Traffic generieren.

==Webzugriffe analysieren==

Diese Idee von Michael Hierweck: Wie bekomme ich heraus, welche Web-Zugriffe für mein Traffic-Volumen
maßgeblich verantwortlich sind?

<syntaxhighlight lang=shell line>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n
</syntaxhighlight>
* Zeile 1: Traffic aus dem Log extrahieren, sortieren, zählen.
* Zeile 2: über die Einträge wandern
* Zeile 3: Produkt aus Zugriffen und Einzelvolumen berechnen
* Zeile 4: Ausgabe von Produkt, Zugriffen und Einzelvolume je Zugriff
* Zeile 5: sortieren

Das Ganze als Einzeiler zum Kopieren, Einfügen und Ausführen im Terminal:
<syntaxhighlight lang=shell>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//'|while read FACTOR SUM; do echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";done |sort -n
</syntaxhighlight>

Dieser Skript gibt den Traffic aus, den gleichförmige Einzelzugriffe generieren, die größten Brocken stehen unten. Z.B.:

<syntaxhighlight lang=output line>
219558 6 36593
232288 14 16592
239998 22 10909
270812 2 135406
304520 5 60904
318248 14 22732
559062 14 39933
602760 20 30138
711496 8 88937
2325929 101 23029
2351668 29 81092
</syntaxhighlight>

Ganz unten sieht man, dass 29 Zugriffe mit je 81092 Bytes zusammen 2351668 Bytes Traffic gekostet haben. In diesem Fall kann man nun ganz simpel im Log nach der dritten Zahl greppen und in less anzeigen, z.B. so:

<syntaxhighlight lang=shell>
grep 81092 $HOME/var/web.log | less
</syntaxhighlight>

=== Wenn ich dieses Script öfter brauche ... ===

lohnt es sich, daraus ein kleines Programm zu machen.
Dazu einfach

* Texteditor Eurer Wahl öffnen
* Script-Text hier kopieren und in den Editor einfügen
Hier noch mal eine etwas erweiterte Version
<syntaxhighlight lang=shell line>
#!/bin/bash
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher heute -----------------
echo ---------------------------------------------------------------
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10

echo
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher gestern ---------------
echo ---------------------------------------------------------------
echo
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log-yesterday |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10
echo
echo Sie koennen nun nach dem Versacher suchen, indem sie die
echo Logfiles des Tages nach dem Einzelvolumen durchsuchen
echo 'Befehl: grep 81092 $HOME/var/web.log | less'
</syntaxhighlight>
* Script als Datei ohne Erweiterung unter einem griffigen Namen wie "volumenauswertung" speichern
* Scriptdatei in das Home-Verzeichnis des Paket-Users auf dem Server laden.
* Permission x zufügen, um das Skript ausführbar zu machen.(In WinSCP: Rechtsklick auf Datei, Eigenschaften-Dialog öffnen, X-Eigenschaft für den Eigentümer setzen)

Nun kann man dieses Script jederzeit mit ./volumenauswertung starten.

== Wie erkenne ich, welche Webseite gestern am meisten Traffic Volumen hatte? ==

Dieser Einzeiler sollte es zeigen (Datum entsprechend ändern):

<syntaxhighlight lang=shell>
for f in ${HOME}/var/web-*-20230401*; do echo $f; gunzip -c $f | perl -nE '/\[.+\] ".+" \d+ (\d+)/; $sum += $1; END { printf("%.1f", $sum/1024/1024); print " MB\n"}'; done
</syntaxhighlight>

== Wie bekomme ich IPs mit massenhaften Web-Zugriffen erkannt und gesperrt? ==

IPs mit mehrstelligen Zugriffen werden so gefunden (Hier alle IPs mit vierstelligen Zugriffen, beachte die Ziffer 4 im Ausdruck "egrep '^[0-9]{4,} .*$'"):
<syntaxhighlight lang=shell>
cat ${HOME}/var/web.log |cut -d ' ' -f2 | sort | uniq -c |sed -e's/^ *//' | egrep '^[0-9]{4,} .*$'
</syntaxhighlight>
Als Paketadmin alle IPs mit 10.000 und mehr Web-Zugriffen aus dem
heutigen Log filtern und dafür Sperreinträge erzeugen, die man in die
.htaccess kopieren kann:

<syntaxhighlight lang=shell line>
cat ${HOME}/var/web.log |cut -d ' ' -f2 |sort |uniq -c \
|sed -e's/^ *//' | egrep '^[0-9]{5,} .*$' |cut -d ' ' -f 2 \
|xargs -n1 -r -I XXX echo "deny from XXX"
</syntaxhighlight>

* Zeile 1: Log auswerten und IPs extrahieren und zählen
* Zeile 2: Filtern (Mit der Anweisung '''egrep '^[0-9]{5,} .*$'''' werden durch die Ziffer 5 nur die gefundenen Einträge mit einer fünfstelligen Anzahl von Zugriffen gefunden. Ändert man 5 in 4, werden analog alle Einträge mit vierstelligen Zugriffszahlen gefunden.
* Zeile 3: Einträge erzeugen

== Troubleshooting ==
=== Viel Traffic durch Login-Versuche auf Wordpress-Seiten ===
Login-Versuche auf Wordpress-Seiten können viel Traffic verursachen. Auf folgende Weise können wir diesen Traffic vermeiden, weil stumpfe Login-Roboter nicht an der [https://httpd.apache.org/docs/2.4/howto/auth.html Basic Authentication von Apache] vorbei kommen.

<syntaxhighlight lang=shell>
cd /home/pacs/<xyz00>/users/<user>/doms/<domain>
vi .htaccess
</syntaxhighlight>

Wir geben zur Datei ''.htaccess'' den folgenden Inhalt hinzu.

<syntaxhighlight lang=shell>
<Files wp-login.php>
AuthName "Protect against silly robots, User username, Pw s3cr3t"
AuthType Basic
AuthUserFile /home/pacs/<xyz00>/users/<user>/doms/<domain>/.htpasswd
Require valid-user
</Files>
</syntaxhighlight>

Wir generieren den Hash für das Passwort ''s3cr3t'' für den Benutzer ''username'' mit dem ''htpasswd'' Tool auf folgende Weise.

<syntaxhighlight lang=shell>
cd /home/pacs/<xyz00>/users/<user>/doms/<domain>
htpasswd -b -c .htpasswd username s3ct3t
</syntaxhighlight>

Falls das Benutzer-Formular der Wordpress-Instanz im Browser über die Adresse ''<domain>/wp-login.php'' erreichbar ist, werden wir in Zukunft als Erstes von Apache und als Zweites von Wordpress nach Benutzer und Passwort gefragt.

[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]
[[Kategorie:Traffic]]
[[Kategorie:WebStatistik]]

Traffic

2025-03-24T12:55:22Z

Sib: add troubleshooting for traffic cos of Wordpress login bots

Als Traffic bezeichnet man Datenverkehr zwischen zwei Computersystemen.

Dies beinhaltet [[Logging#HTTP-Traffic|Web]], [[Logging#Mail-Traffic|Mail]] und [[Logging#FTP-Traffic|FTP]] Verbindungen.

==Traffic Ursachen erkennen==

Hostsharing teilt per Mail mit, wenn der tägliche Durchschnitt an gebuchtem Traffic überschritten wurde. In der Mail steht, welches Paket den Traffic verursacht hat und die Warnung, dass Konsequenzen für die Monatsabrechnungen entstehen können. Wer nicht selbst die Ursachen des zusätzlichen Traffic kennt, kann sie mit folgenden Methoden ergründen:

Als erstes einfach mal den Log ansehen und durchscrollen.

<syntaxhighlight lang=shell>
less ~/var/web.log
less ~/var/web.log-yesterday
</syntaxhighlight>

Da kann man oft schon alleine durch Ansehen gleichförmige Strukturen erkennen, z.B. massenhafte Login-Versuche auf einen Wordpress Blog, die sehr viel Traffic generieren.

==Webzugriffe analysieren==

Diese Idee von Michael Hierweck: Wie bekomme ich heraus, welche Web-Zugriffe für mein Traffic-Volumen
maßgeblich verantwortlich sind?

<syntaxhighlight lang=shell line>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n
</syntaxhighlight>
* Zeile 1: Traffic aus dem Log extrahieren, sortieren, zählen.
* Zeile 2: über die Einträge wandern
* Zeile 3: Produkt aus Zugriffen und Einzelvolumen berechnen
* Zeile 4: Ausgabe von Produkt, Zugriffen und Einzelvolume je Zugriff
* Zeile 5: sortieren

Das Ganze als Einzeiler zum Kopieren, Einfügen und Ausführen im Terminal:
<syntaxhighlight lang=shell>
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//'|while read FACTOR SUM; do echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";done |sort -n
</syntaxhighlight>

Dieser Skript gibt den Traffic aus, den gleichförmige Einzelzugriffe generieren, die größten Brocken stehen unten. Z.B.:

<syntaxhighlight lang=output line>
219558 6 36593
232288 14 16592
239998 22 10909
270812 2 135406
304520 5 60904
318248 14 22732
559062 14 39933
602760 20 30138
711496 8 88937
2325929 101 23029
2351668 29 81092
</syntaxhighlight>

Ganz unten sieht man, dass 29 Zugriffe mit je 81092 Bytes zusammen 2351668 Bytes Traffic gekostet haben. In diesem Fall kann man nun ganz simpel im Log nach der dritten Zahl greppen und in less anzeigen, z.B. so:

<syntaxhighlight lang=shell>
grep 81092 $HOME/var/web.log | less
</syntaxhighlight>

=== Wenn ich dieses Script öfter brauche ... ===

lohnt es sich, daraus ein kleines Programm zu machen.
Dazu einfach

* Texteditor Eurer Wahl öffnen
* Script-Text hier kopieren und in den Editor einfügen
Hier noch mal eine etwas erweiterte Version
<syntaxhighlight lang=shell line>
#!/bin/bash
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher heute -----------------
echo ---------------------------------------------------------------
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10

echo
echo ---------------------------------------------------------------
echo ------------- Top 10 Traffic_Verusacher gestern ---------------
echo ---------------------------------------------------------------
echo
echo Gesamtvolumen, Zugriffe, Einzelvolumen
cat $HOME/var/web.log-yesterday |cut -d ' ' -f11 | grep -o '[0-9]*' | sort -n |uniq -c |sed -e's/^ *//' \
|while read FACTOR SUM; do
echo "$((${FACTOR} * ${SUM})) ${FACTOR} ${SUM}";
done |sort -n -r|head -10
echo
echo Sie koennen nun nach dem Versacher suchen, indem sie die
echo Logfiles des Tages nach dem Einzelvolumen durchsuchen
echo 'Befehl: grep 81092 $HOME/var/web.log | less'
</syntaxhighlight>
* Script als Datei ohne Erweiterung unter einem griffigen Namen wie "volumenauswertung" speichern
* Scriptdatei in das Home-Verzeichnis des Paket-Users auf dem Server laden.
* Permission x zufügen, um das Skript ausführbar zu machen.(In WinSCP: Rechtsklick auf Datei, Eigenschaften-Dialog öffnen, X-Eigenschaft für den Eigentümer setzen)

Nun kann man dieses Script jederzeit mit ./volumenauswertung starten.

== Wie erkenne ich, welche Webseite gestern am meisten Traffic Volumen hatte? ==

Dieser Einzeiler sollte es zeigen (Datum entsprechend ändern):

<syntaxhighlight lang=shell>
for f in ${HOME}/var/web-*-20230401*; do echo $f; gunzip -c $f | perl -nE '/\[.+\] ".+" \d+ (\d+)/; $sum += $1; END { printf("%.1f", $sum/1024/1024); print " MB\n"}'; done
</syntaxhighlight>

== Wie bekomme ich IPs mit massenhaften Web-Zugriffen erkannt und gesperrt? ==

IPs mit mehrstelligen Zugriffen werden so gefunden (Hier alle IPs mit vierstelligen Zugriffen, beachte die Ziffer 4 im Ausdruck "egrep '^[0-9]{4,} .*$'"):
<syntaxhighlight lang=shell>
cat ${HOME}/var/web.log |cut -d ' ' -f2 | sort | uniq -c |sed -e's/^ *//' | egrep '^[0-9]{4,} .*$'
</syntaxhighlight>
Als Paketadmin alle IPs mit 10.000 und mehr Web-Zugriffen aus dem
heutigen Log filtern und dafür Sperreinträge erzeugen, die man in die
.htaccess kopieren kann:

<syntaxhighlight lang=shell line>
cat ${HOME}/var/web.log |cut -d ' ' -f2 |sort |uniq -c \
|sed -e's/^ *//' | egrep '^[0-9]{5,} .*$' |cut -d ' ' -f 2 \
|xargs -n1 -r -I XXX echo "deny from XXX"
</syntaxhighlight>

* Zeile 1: Log auswerten und IPs extrahieren und zählen
* Zeile 2: Filtern (Mit der Anweisung '''egrep '^[0-9]{5,} .*$'''' werden durch die Ziffer 5 nur die gefundenen Einträge mit einer fünfstelligen Anzahl von Zugriffen gefunden. Ändert man 5 in 4, werden analog alle Einträge mit vierstelligen Zugriffszahlen gefunden.
* Zeile 3: Einträge erzeugen

== Troubleshooting ==
=== Viel Traffic durch Login-Versuche auf Wordpress-Seiten ===
Login-Versuche auf Wordpress-Seiten können viel Traffic verursachen. Auf folgende Weise kann ich diesen Traffic vermeiden, weil stumpfe Login-Roboter nicht an der [https://httpd.apache.org/docs/2.4/howto/auth.html Basic Authentication von Apache] vorbei kommen.

<syntaxhighlight lang=shell>
cd /home/pacs/<xyz00>/users/<user>/doms/<domain>
vi .htaccess
</syntaxhighlight>

Zu der Datei ''.htaccess'' den folgenden Inhalt hinzufügen.

<syntaxhighlight lang=shell>
<Files wp-login.php>
AuthName "Protect against silly robots, User username, Pw s3cr3t"
AuthType Basic
AuthUserFile /home/pacs/<xyz00>/users/<user>/doms/<domain>/.htpasswd
Require valid-user
</Files>
</syntaxhighlight>

Falls das Benutzer-Formular der Wordpress-Instanz im Browser über die Adresse ''<domain>/wp-login.php'' erreichbar ist, werden wir in Zukunft als Erstes von Apache und als Zweites von Wordpress nach Benutzer und Passwort gefragt.

[[Kategorie:HSDoku]]
[[Kategorie:Glossar]]
[[Kategorie:Traffic]]
[[Kategorie:WebStatistik]]

OpenLDAP

2025-03-06T17:14:00Z

Sib: adjust "Instructions" section to make it more consistent with the remaining wiki page

{{Baustelle}}

== OpenLDAP installieren ==

Voraussetzung: Das Debian-Paket "slapd" ist auf dem Managed Server vorinstalliert.

<syntaxhighlight lang="bash" line>
#!/bin/sh

BASE_DIR="${HOME}/slapd2"
BASE_DN="dc=example,dc=com"

INITIAL_PASSWORD="myInitialPassword"

BIND_IP_ADDR="127.0.0.1"
BIND_IP_PORT="12345"

############################################################################

# Fail, if base directory already exists

if test -e ${BASE_DIR}; then
echo "Initialization failed." >&2
echo "Base directory already exists." >&2
exit 1
fi

# Create directory

mkdir -p -m 700 ${BASE_DIR}
cd ${BASE_DIR}

# Unpack initital configuration

cat <<EOF |base64 -d |tar -xz
H4sIALShi2IAA+w9a3PjNpLzGb8Cm0yVPXexI74ky1v5oNhOynse22vZqWS/XFEkZHOHIhWKmrE3
Nf/9GgDx4AMQZWtcud1R1ZQloUV0o5/obmBIGX3/5gu/BvAaDQZvBp47CgKXfXZ8n/2tXm8c3/Xd
kTvwAvjeGQSe+wYHXxox+lqvyrDAGP6Swg5HitVrIPS6LwL8j7IfojybJ/dfSBIY/4OgB/+d0Wg0
BP67vh985f9rvOr8h3eLPF6n5I/B58M0TuY7mYMyeEj5beD/aDAU/HdhBPgfDD3vDR7sZPYNr/9w
/n+LJ3e3Vwc/n12e3Uxuz07xT+cXZ/gAn17hy6tbfHZ6fvuXv+C7FcFpHC5BOJL50yH6Fp/cnHgu
PgpmQw9sNoqzY6wLD8pn/yRReZKGq9UxztPoPRu5SFYligBWAxRj12H5cIy/X6+K79Nk9j2dTg1e
5GF8jAF+FkYf/ncRz9CqLNZRuS7C9Mo8FcnK4unu7vz0GA+CURw5w8GB74/JgTPwooNxPHcPxl4c
+t7Q8QYDgqKChGVerC7DBWEEhfEiyb6TCsIByG2yICA2i+UxdgcuOC1v4IwCzxn+g894Mr1sjhwG
7tGRH/zjWy7y31b/4IXYoibEMitfdsusz+e/Sf+dXeu/xf+PvFFb/wdf9f81Xi/Tfy8gThDMnIb+
O33139la/wsyT7KyNeB8XpDFjBT5fGvD4M1H/nw0PzoYetG8MgxzMj84GgcgrkdzMBDz5xqGYDCG
B3qg903DIEcOnaE/9rxdGgZt1o38r+s/LNKPYGBJFv8Aaw1mdidGYJP/H3q6/4dxZxj4X/X/VV4v
0/8oHgy80YDrf0t4WkagGj7hwqu+YJptd+r1nzb8ehzPorpf917Rr4+D0eBP59f7vlr+fxU9kEW4
O+f/pof+O35D/wPHC77q/2u8Xqb/o9j3ZiEobuX/ufC09H7Kvq50l7r/Cs6s7rVfNLTdI6Fb03YS
v6K2B/54/P9W29uvlv8/DctwFq7ID38cOJ/nRZ6VYHZfZg426L/juk5d/13qVb7q/2u8Xqb/8/nw
aDw6CoX/7xSeljkQUCIOaAz/VP1OhQniBxAn1J6bRpMoIvRnED+UOf4vPHvCcXZIHsOo/OE+iS/X
dFPww+C/1+o91cglIQUYgZi+J48lKTKEw5R+CtflA16EWXhP6MPgiWArPtSmcuhUcpZvvuFwAFbH
yK3A2Hp8A4+ermfc7jV+MU3+BZuSRVIe4wAMidkoNtataRYH82HdLM42mMVdWEPHP+pnDf/MRvA/
+GWI/3ZaCdgi/1/Ff/DW/5r/f42Xif/wDmxqlBfk5VsBu//3hrTmV+f/yBl+jf9f5fVC/z87In7s
+CL+r0Rm8wZAAoLDLMsima3BAz0tCXfl+9g9DA79QxdfTt6f4b0PWf4pJfE9Oc/mebEIyyTP9vDp
2fQE7938dOK6wfAYf0BYgOFEhzv7+93k4vz2NxyB7zy/z2De92EZPeDpb5e3k1+xc+gdDg8dmM85
dPwhvHWCQ4Qd16FfBH+A1A6PPuN3ncg6ElmfI7uP91Yw6d5qXWTg+/bwuyaisColRnh/Hi6S9Okd
pmD7q3cYUMafHhJArHwgGJxuUj7hZIUp9RmEDHt4enfNoA24uBKXoFo4kNkkTHnk01owPoizNcJ0
HOdzbWLbst39OL290b6mgQ2gkt2vAADhDSvL19X3/xj6pkX1JCFDuagRrGmUr2koctlcVz9wxse4
/IRwfpCSEuI5fD69OoB4Yoir38DfmGgruBlDkAAHT88vf744O/hlcnF3ZkDWl8iOJLIpIJvmUZjC
SrawraQAkOUAkunAa644EBqukpisQI43Mj2Q0x8pASypAJYQ1V0V10X+Mcki0kQDYSEGFA6D7C0r
yJfhM5T4jDV8CkI4TvTNJI7hgav6oiBcYUMhcMhBuExKPHoLJaxtQyx7CSUou+MaVX0kKXMGkrQc
qMqL+zBL/sXMTQe3EaaE6UC1tZ2RNAcccZlvXNsjhYGjMFg3UAjTuywpdUQQ1gSvDorXAPtcfMYK
H2GqwXakpGVq2LcYvEEeJSBtCMf4U1I+1OzNhrkc5RYcX5q3sIgefobNXXtKPobvEabD3+GYLAsS
weQx3X2R7CEEUY+n+hP62AQ3MOGnPIEjzO9svUoyEOMTmPY+L55aSAIAwgwERxLmmYaXAiD8Qhl3
lA9xKtu7t8zBRKRSaRsk8FGQsFAAdOBPa24GGuhQgw54WA8H4phIUN7DGdVIOMk75IQPgXsAoSQv
WnwdZXAehsX3B8a1V57EOdIQv5rPk4j8mD+2cL+GUXyFMAPADOKl+MPa24XHgr9yRc5Y4P/wtErA
zZ2SNPlIiidOC7dNLU90XQFjAY05OObwvUhDeDNznqMXyq25A2HqSEqWD3lGDPHVLYwjzCCwAJE0
NH5cI6QxJmlBuDc1wQDCViMxypO5jkbMo4WQRyCBx4l97GTgmqZWLsx1talL8nhLikUCHuk8ph6B
Jo80RMDwSlQAFgtgrEP3wMtoNJQrcz3pWudhtEogSCe3TVbD0CP1rqi5Vj+Jn+D9n8LHd1j+UoqA
GUsIFCo8XdP6udrmSHjBR/iNyTr/Sh+IJzEYt4ZxztYLiP+jKZOsmvjVRroUCWH7KntDagtMFCg/
6Qo/mWQ0BVtFJMn09LJDEHkUVYOEIP/0kqJbV60elCFsom0zZUMjZcp3usJ3FuQe/BspSGziEGyC
sYARzki6UhoT1dzvRhyZ4zFJuatcoytcI4T1ZcJX9DyLwfyWecsCgFPQwIAJEu4Z7mYLKwabRItN
dpW/dKW/LMicFLCUwoW8J+VDHndIkoQE0ipvs6hgezgLX+wMEbbtDV3lEt2xQnEFNostpUkoENah
OkKrjocYFxVEorGsXp99ratcnidc3mq9XOYFxNCT5TKlMgDTn9BqzGMpaUBYhuACGocKHCKtCl4S
wzceypJrlCBs18cjE/LKxXnCxfEOsdZa86/pTjOku4UiXy+54sUJFfn7dbJ6IPGlJe2ifJonfFr+
KeuYin2L96tEC6oIf7fldMpVeZ4wM3lKrqJovQyzsj0rH0C4pERS0O0m9JTP8YRdo9nQE1JQftGN
S4ffCQYIjzGFw5EC/I5+g/86A1NS3+ookDNaVmsJM8IGETBJgKf8jCdsXTTZhPMYuHIy2QnGQ6Z6
22Cs/Icn7BktR+YF7I9vyMecKxDdMHXYM469hAe/In6AU/hFgwyjiQNjIfAcm/BUXsQTRk1bDSOm
IobjmGq/eA6uIA/6mhpxVT7CF0YsKnLYkqvpr8Oky+NVaFLgGrJLAO+7mhw/hOkXAxOKykf4rgw9
78ElVcmkvfusI384RzgpYPu3s+yxp+y978nALCmTMG07KDEAFgWWapUvWAYxTFNqYugkq+8wPBxn
ecnwqbLhgOjhZkSU7fZFjHtPwHIyCfn7GkLExu5AOE320N8FgIhTwMZR0y6fsBkBZdB9EaI+BoPB
XZb8viad+xNdaAY0pwaAONEgpd2YJWUtMu2hiEMTnsoT+MIwx5YFgmCZLQ7CDZyawdvVzenZDUQI
2sBVEZNWPE2HEe6RDjFEd6aMunI4vjDdnQm7lgAIKJn965vYc00hs68VeFSQmZd5lKe2ahSN4DiU
oRjV8ZAtIjjT/tDXakDC3nFpfN8d/VSiiuphEA+CJK76E3pwFww9C86M/FUOJBDB2UMOFtWsWpiO
A3+7deo5uS6ENyeErJU/X7mWwG3Fx+k9dcMPi67YXouLNbAeCmPycr5yIYEn93VpGVqiBo4Kg2r6
379u5d0s3tdXLiUQljxexPX0X4ULs8cgfafvT/doAthuon3lI4bCRC9XZB3n2dNCPBuMsTvY98uH
d7Dd44MIPy2Yq6ROSRSVNs1F3cHgcHzoer576Ixpd+JgAA59QIVceuxFmNCyXzGPjlz3PXxAeJY/
1jy34478YwxvAAJTEAaAuwT5fBJwUcVcmhG+qY82RbpPztwdwo50+Bn4bqB0bKFUZGuA1JgWY+Mc
KIbd32KZg+cldOPRIPV71/VHx5gDwr4PIDmcjd4pwk3t7aC2D610k4vwpm1uMLBxV7gfWbqKTxk1
e3rmj7O1IlNB8hKXpXL5JWg2EEm9GIwfHvlAluMF/piq7aGqIpJKfNlfmZZAoFUfotW4GtX467lH
g2OckvswesKhmI+pFgMWOQtWNIbIgz3MugbbrYBxPwgyrnJGWgdlrbVkKFtLqvaAljkKsRyh5gE2
z/kSA4J3J7d3N5ML/P5ueosj/H7yG6yeVofEb2mqLCqSJTOn77rxcCQewlyLboEORNTQ9A7h6xYm
HAVeN38LuJBJusrZOx2rFR1Ma+iB2poQdCWCwm7rZeM2kpkoKyOsxdhda5ZXCNPMwDVM9ykv4jay
nAjwA29xs4gKX2kZb/jUyrFyIptZTYQLGDAkCGFEq4BUnzqLEnwMQhGtHgDfGVLYMIJNVQTGFMo1
Rmat0ld95iVL+UGRZy6rgaR28trIaU9yOujgNO8l6OQ3rGerkcDC9rWV77xKXxPf5/OdbgRr+eyX
8B3hOud7872L7VWn1Vulri9gOzBAZ/x2bPcl22WZnxSrLtXGYoCzFjY2LeaC+clg2ojO1snl9rpx
PiOc90M3kOiOOqX02oA8BHzNhhedHP6+bU15v0pL4EAWepmaXgInZWGDqeklcNy4bTY1vSQO4X6m
5i3Vail2Bs4NJeeOOjl3k3f0C3XZF5W47nTFWcW6bhsBnNsBy6qlRDthWWUjYDto4pg0hXp634on
2olhqZgMa9bB5l7qOpJMFwlillK4mtMHtrfEVcaBJxNZ9hDvQ8j4zszufZGvqFmdhsuAzV5tGXn5
pSKnp+E5kpSIpr893gyZ0fyn0ewwWyHBNtkcSlHaTQN3ezSjsnXAYxJphJ8R8JhEGix4H8dXDZkl
l8ktLVHtLBJiUZXdNo0Vc0UeSqtUXhd51FWcBe6iWkVzKQA3GidNFtdSm0BpN+4X1MZFdlpqGJxV
LZSbENVbLbu1qqOurFQMYUaDuQZc1zahZT1thqM2RY5MYk0nHcYiTgr4JdWN1dOKdpMucHgPWOP9
kDa1gxhUlqO1RE1P3z5YQOXZgJ/aE8kG1Jh8BGnrQrEasOwdlUyoHn27uUqZhe+zlCqol72ooGB5
dj9Zlw9UCvii3K06m2xCzIFZNVFBs6BOCc/k7tfzi/PJzW+cnkZF2ICYCjtle6mqrVGZE/XLxpoi
zLbk2vNDBWnAaB8bqqfMMhgrlnRsUqOEMaqramggUgWrsgG1cn+8gmRygki6QZGWl74QdDnG/Nda
y5vNQQKRetre6ig3usk+JkoFerJ7lcrElERrygJjsQRhRjzrFFhVwPWaSQd/J3VLJNPoQLUJv5Em
eir90yl8B7+4fFY6jHAboIVKR7bdiIgWUsjy+c3FabLiSTTqefIka++lEdYMtcZMmyQbNAC/ZS1d
/XFWnlK2v8aL2OZJeJ6flmwMe8LOjI9134/wbgIgFnHAAuwkAGLhD8I9A6A+4TnaLuGzXWTuailQ
EfMsPyRNTxAcjahSXv/PubD6CHdqYS+z7yrXLrt+YdKTSWtKOqEmz/RYgdXOM8EyCnldNRC2mvm3
BhNvIElFA26t5HZyc9FJlXCeIoNbJ6JTFzvn9VgmX5UA3GAAn6SbT8MZCF18d3N+VRUe9La8wWh8
LM75lA9hyZrxwiRbsXoY/EhL5ZdPSwhg+Aqrp8J6ABuo8tRo6MbVN5ZWtCMCoCrLlAg3wZ4BEdNe
s7zCwZSH0It3hnCEGxuwGrEBv6CxlqyU4MmmkzhqrCH1V7SihVo1rU3oxJEBhaGGAv0rdBLMYnty
bwSTwwjMhrCd/ITS/Lz7dQLHbVwkQV7zfp3xyP03ul/nz/6ynf93Pkc59cUvvQHAfv7fHdLD/o3z
/4Hz9fz/q7xeeP+X77qjeTCQ5/+FyPS4AUCBGu4AMDYiyHNDj+VZRs91x1c3VaiE8M6O8Bm6d52A
91CYrwMw4S3cCt3bNN0bOFTeoGhqF9uGFlqD7XvmzR345gMWFmK0ZhCY9AM7EfUxp66ZnLLTNR86
Ol8oCIXA1W/6UPf8/kI7pzwLcfL0Tp4vmkeREK6IoYPtw0df5LIEOyXmKMuR1TLYhZRNoaM5FfY9
3v/ZA948vuvVKekBLmC2TdgEFmz0vAAzDbXucL6s4hw0y4Ksnrm2W5wxsq/t0EKNCGAf8lUrXAV9
pl+zABEe97JmxX6nui1UjCxUyLIGv/RM3wXSsgNlyeklZYYcl5S0DpBY15x2wSt8TQ2stl47maSP
82i9gBhS6xeFBW8Ym1YTNiVC/NLOD4S38hNb88PWZifz+wLVW3WjQnWPA6eP16h709SiiNUKd0eT
Y3PZKqFf4foLBFM8E4hwnW0f+cjzCKMZol0zy7H5dFUJqHDlKULKLhAinS6uRDxVYSDOok+bjtwa
9cmxOXGZNRDIXFT5h472xlR0CGu4Y/Dm9zRZtoFDCH9RdXJsvtxVd7U85AtyTdNxe/w9wq1z3a2Q
hcKp9F/b38shhLc4yb+JcO3wR2A6N+TY/L7M7a0IbMbLUOtwpIkgXSQ1iO0tOzXqfSXRFhnItGBe
PtA1rFqje502N3WfOzbnLU9ohzckyotYIx51tqc+v/nWsblfeQ57cdpEBKz9jhGxOVd5hHrx65dH
xNpnLuKqbPrFEXGtzd/y1PPVpIEJrYTvGBObl5FHmCP6p4YLbI8M/dQvwMXmM9TRVNnoLs5zdHo8
luprdcXHVRe92eIg3Ns5GC/LsPkFT4Xv4BVqVxy1Y0nmBZqXM/S75wjCLPNNRy+558iSXXfUYVfe
bRSmKoqEDaxGmRjH1cVdW25T+EUaO/Ljrs1D+OqswiKfJRTX6g1o40Y3ziH7OHLa9bYzR07vENzo
yF2bn9KOBC/59ov/vW32oHcQzQB7BS+iG3UnwYsT0KhgA802n+irQ1URvV9vXiQki9OnkxzQ7LwA
skovVXDyzsfMfm8U2joj2CnStmshjCSKfcO6daa4FXnXN7L2XEITXXodzHY6aHPNfvcRgWlJM1nr
Vatm1+i8pjdNrrsNZ93GIPzF9gqezePLU9T/DDNSyii0tfX+Gx3GCzG+9bEmWKztj3ZZqbLmnWWI
CQhfs34IkkXkasm73VpcY8e3lhIO58uqDafH1UMQzloutzBiKGKK2TpJY1gWdUK0tu7ijKgA29Zd
IbxTUbKFF74IL+LphJ3IVy1tCKsQaTrBcrQHPuM+F/d4tsBAngpfwUKk5IJ8JGmFAa2dNERhyoAw
g9oKUY8e4e2Bqs3jy7Phq/WMts28T7JksV5QNBCutwhW2HI4TAHB1/VFmNlImqLqg7DNV2vHwDnC
4WNPhBlg9kUQtjlaeVhcRIHT5D4DG12Qjhj4WkSKEqh33YAj7Hq2+zaMOMoM2/ntDeGtv9VCIn2z
cX6L1fAzUtStOxaM2wrP5iID4SLDdZzUKy4IU0TZ93h/fZCGn3oVXHx7vcW3ObRg2EjwXa9nKV2L
roT5Uoxtn3t9SZHOfFLX1DqkblpfJmleikMYexn5dA0uTfvqnfWUFy0vJfwkRLuSTNsM5wiLw/wz
1qWnapy0gMlO5ogKIXyQZS14T3eMjewiaztu7TZZ72OVgaONfvp+zdK/iLo7JfXAhXbvatk0+Fjt
l1pdiQiLPUVjoB3nrSnC7UAizyTu9H/SUSbCcgDaxF6pQRGL4+tNprB71dpMKw6KHlzV/ag3lOoX
sddpgt1E+0vt/mzGL3NXrDmkkRfX7yk90qhAuNYs2y5nic7efLHIBYom8pCFwI3k1YpM/HhBvUKj
wfDShvaFqBZoX0n7YjtubFozEadSpbJ1P2vLwteppoWmddK3swjPzCjauhbHDbZOQf6IOPkD0XTH
OY8mshvxy5S1eDZnLcdojQ2ZqkbHc3NmtdOu/mDNj1Ubbi0h2I0uIx6CIUG+9SBCvUO80T4ulgZh
2QXd+v8OZMN1z0bqJXCw0XfdPHum92w3n93o+6abK0PD+LneLt5uLu9oRYeti96M/tjjSJ2hI74g
98CAZvu8fmzWcpLXKDwiSuOX2zDmXIcFN3v0rAHvl2254JqFqy6Js+tw6+YFO0ft/KQ18C04aucn
7Oq34aidn/TA8hYctfOTnooxHdM1clTWhi+np5pFYJykN4e0eFkVSWDy96fq7a/y7eVUvp1eKWDY
4quqhu0YrhHTUc1w3ZCU2qCqe7od5tKz5eJ/NWGQYOTol02z1+ioptYNwkHtDiDzmVIjpiLPoWU0
5R0ztLhV5S2bPqQBru5q7TwnappdntxhUfNV7T4XxMjer/8vJV3ehYbUdcbrORvLyU4jVo6O1Sk9
8MnEbBVi1jegT6VyKZYjmsaJxO78d/6IC3qmIQVmhvTGA3Pn/ioUc4pTZ81sBB17K7+Hhz3qI++e
3Yg/mgf1/9aazF+xEX/kBP7XRvx/95et/9/9nCWrHfxP4Pb+f8cPhk6z/3/g+l/7/1/j9bL+fz/0
B8NZOJf9/0xkejT//197V9vcKI6E77N/hao2H672sglgMDhX88GbZOZ8N3Fcca5mv21hwA43DrC2
s5Nc1fz365aEkBBgkjjeqw3aqh2H19YLT7e6W4/4dTWZ/8WCKOo3FBzAQSpiTLd3Efl0eX49Qy7b
Vfh3XGUPh5g9WR/4a0k31z75gNEM7vLCmlql8skW+oMucj4DuXL+fJOCsftAGadxq6yUVpBmIoTF
DUodKRF5bQYIo6F+ifiWJn5u7q/SZZzM7kCRyrLnArM+odeQDbvoGfKWpKXit5O3r8krWBDu/DD9
9tnfbM/v/GQpDxIw6JHfqRXDLWs7t+32gKosA0WWKyUNBmcVTISWSwPaCeFoQriqEP7j2wsx0ITw
FCG++OtEDeoxQXpkz13iaoIMFUHGCQxLmHmVJYHhsWdJPE0SkY7PRLl8zOBbf/smGeqCmIogH1e+
3jPr9kuN2olh6ugv8uEZ4dO/47ACRABoqpA9x5fnhSV4tKo2eVEHc+E6YzJO4s0k2pZJtHtVkPdS
WSn9aYtESx25hacmKaS8XcdZwcI2QYooxkSy5SdKQuB/xkltYrIOv8KZEGezaI3UONN0vS2NJ3jp
vr8vU0dfwTtTiMKZ2CUi6DqCZFMHUuF9iLP8Qdpmb+gv2e5ftZg6ogoPQ5oEN1mgS/I2OGbqkCrW
98fZP9LNVl1GN56yNMoeqUmkfFYaa+PGfTrECj9InMFQ/5auv2rCYTo/PbMf4Xrke6tW1FFYeEeo
rPf+pkZWPHNQWa0KO10gtR+UNra6Gp3zvFno8bftcEuHZ0HQMU/T7dRfwxe+LZpwnQUncAIaMcNT
IcmKKypxrzYhVwdbsUcfvvljXGDsz/A3ie/9ZUQwYKrNVp5lGTdpAEsHY7H0ATTAlZ+xXKtdW4vr
QCpWLrDHXDJHZqkWULd9qLuBsic7DgADJKoYp1VpBLLY1olwgqab+HGUh5hZr4xQFrT9Usobu0C3
MI9Cs7T16fVs/EvBkbKp9RpSgqYjSsMB/++ROBQO/qX0W5n91RElFXMsvBu+dpgGtyP7KX8K1olq
1JWrH4Yx8/Qi746oJCV1ZzfAt8HEqq/5g4jH59XokZzxqTT5EodgDlT89h/Fbz4jEH+DYQ61R9Nc
HGIGsvgTzdSWREha21jyyPjErDdtXCAv7UIiLM3HRwP7Ix8LRb9L/QyGvNTTwsRtV4Xyp20Jr4Kw
bapqQEmRxzR8FW1JbrRQ5kTBWdhQD8WEoykDmiXFa6hUoS7SrlbA1oyp+j5ICGi/TDHeGsVWzbOi
iTG0miZtZS5bgFbBm05Nrkp5F6zRryfnpzfTczLHnalwprtDZtmIU4cE5blrJW/ZRrROBophVicv
6dHcl2PezjKhZT3eybaeGOY6beVRvpi8iT9YFdot22zVciNwUXmT/Kqdw0KxAYXQeJzbVaL9yxRr
O6tRtj0t4fFI5CmiXpEe64JEXLKTWVabzQk4mWC0Pz/XDljKdqglHCRM1wuRGWlJHKC3EoXnnxIV
fjKeQfs0yF6YH+1GsuYcsApvCTxLpcsaJXzlWUxJcHdLw8eDZMyIv3hGDRNSocKsjXaWxBRWfBRF
nmFdKLSxI/5xwdilRoZPCnO5Ws+CIIWN3RAKLUlhScaoP19FlWIgYyMVA68qbOFaQf5KctsW03lk
A5tuj/3S2OdwMVRJyBbGIWOfQ894H7HPpvhf/3sMCJSulyyx88WRwOb4n+HYbl+N/1mm2e/ifwcp
r4v/RRH0mD0fiPhfaci0iARqd9TEBC2k7aXbV+EGVm6fsl6K+Uzgrz8DliUbhYy7R+BDRkqRuzgA
fFqxK3CnUpYyteb87Su6HfCORHdl8fke1wmatZUTTDARwPAW001l5w9fGWXRKgqWmw0lH8+vp0iO
m5IlRN2/qVxXMDheypKm1xUjdbWrIutrawt6n3gDXfKkbBNI6UtpVYuN26m/YpuSeYRTqZB8u4sS
wm/GaSMCPM3OPUBtW0Ylq6ueT9ui+2yVPkWR6uOj68VY3ZOHezS3/NXqSelyMHb4rbt6XGUueGUb
yMub27WBXdsGdqkNbin9rMS6xloAWWkprQC9jI5xdE8UuxS1WK4CJs7ev+KmhWyD3Er9TxYtpyoT
m6iYT/45vfzEfIKteNjqthEf1A+z3IoXn9BnP1k+0BdK7A3lz+zbOt5uIxxPZJOlX+HXit9W3/QF
68EePrPc79duiLn1Q0zsiIu89Ffjq0t5O3g5U5Q1wfRf57MfXLrejaUJMpgBxOHM82R2ik+p6K6K
ddd1I8erR0QRq6KuNJDGtCpGjqBwYIigsucfUxbv8xn5Acz/6cdf2m2n3rAoq0rUwneGuvx6vSzv
iyNkFW6na3Vp+FTaIKdqZy95utYTtN+4kq5yDUFhDtAJr6o+8ZDQMDjdOSIq8EoHsJOo747vxp6v
4KJ8CtpqLgxn0dRwvjn6ERFfPLoPChJttoRKciDka7MI23EBl2Px/Qr5zcoSF3nBGHcxl2jYjwhu
WF6QC0jLB7SPn99e/iDyJRd02L0ii3XuDi11JmcecCbnOcP++5jJvayo8z/oSsS5OcA0cvneh/PT
PbwDG9x1jLr5H5ZS/ufAgNPE2cO7d5Z3Pv/b2f+oBn6P1oCWHwD/ATviZPtMTwCd/xu1/W8atlua
/1uu63bz/0OUV87/B2DhLsIhnf9XjRTNAcB1RPkwv7Hm7A19VtXJbZr1itupiZK/OL9NGFxn3CGO
XLZsT6Rc+7Idj+Ttkhp0nSKMpOsczw78uRP9NOgHC67rFgvjJ2/owLD3FqDzFi/VdY4xhAfalq7r
xBmwyfre0NunrpPe+kcP0668UXkW/sMR/gU9SwPswn/LLq3/sNDK6vD/EOV1+L9wHC/wbUfD/2Kk
aGDOAPZaP9GsA1qhv/za4k0XMNFZxcnyjMC8J13LpwDMYUp6husML+XjNP3j+vyM6Bv3NV2mXcD+
HV2cqdpFu+J6gdfc501Tr31E60maZ+B5QRAGnqp5zH1qHseu0zyOfWIaLnzXb6B58K1/9AfyJy8N
+G98Z0dfvQJwR/wPhk+/vP7PNrv430HK6/B/2F94RmC4Of7rg0fD8fySHM+LI9R6D8ThUYCbKtOD
25T8SOZPJExOIswb/SBy6T4Yf3sofiOuZFG0BigL8Xf0iN5GJCTCv5B7n5v8+DB4IiDeVzpRSNPt
xaQSn/jZ6ZczMp6Mb8ejz79OR7PZl+ubiwaULlWy5BHrDy1fXdcd7PCI7WNftb7TcnLwrvxf773s
sv/3sPx7J/4PAPM5/ruuO0D/n9vv/D8HKa/D/8Fi6Iem4+j4TwfPTvAvG7fhvFIt8IfBsbnIlj8j
P49ml79ejG9Of/epRT17WCzix/z4RNchmNK++aBk14Me2ESrBY1xUq3gJ2nydJ8+bOhWLUxPJJQV
XHmeWTxPy2rXnvkjAdwOlfstodOKk/iIqzQsJiOaWpJqVquUaCud30XB1wx3kT4jjmmRvsGOj5Mw
esx3gGVUhdFvyqkgOcaIUumo0LHHRRZ76RI2dzkuUtjz81f+4yz+L3Qj2nlg2HmW3TS/EUNAVZoR
KDBPDSPZhwsj9U3b+HMmBCr4vw+wryg78B+GRY7/0DAOHDfhws7/c5DySvyfz10vKPg/amz+T6t0
7q9ovp9k36+XG0wbloB8/ZCcblZ+Fp74cJJiYrqk5NNnCMIUgqdxWHtXFlMgvU3T1e0dwiq83mwA
Gy5XyTy33EXJPPff3jy3vUHLOPV+cQUb700H2F94/Lfe/yvHf2ks0DANZ2B18d9DFLCd/s/636b9
b/e7/u9KV7rSla50pStd6UpXutKVrnSlK13pSle60pWudKUrXXlJ+R8PJCZ+APAAAA==
EOF

# Patch configuration files

sed -e"s%BASE_DIR%${BASE_DIR}%" -i $(find -name \*.ldif)
sed -e"s%BASE_DN%${BASE_DN}%" -i $(find -name \*.ldif)
sed -e"s%INITIAL_PASSWORD%${INITIAL_PASSWORD}%" -i $(find -name \*.ldif)

# Fix CRC32 checksums on configuration files

for FILE in $(find -name \*.ldif); do
CRC32=$(tail -n +3 ${FILE} |crc32 /dev/stdin)
sed -e"s/^# CRC32 [0-9a-f]*$/# CRC32 ${CRC32}/" -i ${FILE}
done

# Add Root DSE

DC=$(echo ${BASE_DN} |cut -d "," -f1 |cut -d "=" -f2)

cat <<EOF |/usr/sbin/slapadd -F "${BASE_DIR}/etc" -b ${BASE_DN}
dn: ${BASE_DN}
dc: ${DC}
objectClass: domain
objectClass: top
structuralObjectClass: domain
EOF

# Print instructions

cat <<EOF

Instructions
============

Launch slapd (debug level 0 - foreground mode)
$ /usr/sbin/slapd -h "ldap://${BIND_IP_ADDR}:${BIND_IP_PORT}/" -F "${BASE_DIR}/etc" -d 0

LDAPvi on cn=config
$ ldapvi -h "ldap://${BIND_IP_ADDR}:${BIND_IP_PORT}/" -D "cn=admin,cn=config" -b "cn=config"

LDAPvi on ${BASE_DN}
$ ldapvi -h "ldap://${BIND_IP_ADDR}:${BIND_IP_PORT}/" -D "cn=admin,${BASE_DN}" -b "${BASE_DN}"

Do not forget to update the intitial passwords for both identities:

cn=admin,cn=config
cn=admin,${BASE_DN}

EOF
</syntaxhighlight>

== Basis-Struktur ergänzen ==
Für viele Anwendungsfälle – wie eine Synchronisation mit [[Keycloak installieren|Keycloak]] – wird empfohlen noch zwei <code>Organizational Units</code> zu ergänzen:

'''Editor starten mit:'''
<syntaxhighlight lang=bash>ldapvi -h "ldap://127.0.0.1:12345/" -D "cn=admin,dc=example,dc=com" -b "dc=example,dc=com" </syntaxhighlight>

'''Oben die folgenden Zeilen ergänzen:'''
<syntaxhighlight lang=bash line>
add ou=users,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: users

add ou=groups,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: groups
</syntaxhighlight>
Nun den Editor schließen und noch mit <code>y</code> bestätigen.

== Autostart ==

Um den neuen LDAP-Dienst dauerhaft laufen zu lassen, sollte [[Systemd]] genutzt werden. Hier ein Beispiel dafür:

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

In das Verzeichnis die Datei <code>slapd.service</code> legen und mit beispielsweise den folgenden Inhalten befüllen:

<syntaxhighlight lang=ini line>
Description=Slapd2 Server

[Service]
Type=simple
Restart=on-abort
WorkingDirectory=/home/pacs/xyz00/users/ldap/

# eg -d 255 for higher loglevel
ExecStart=/usr/sbin/slapd -h ldap://127.0.0.1:12345/ -F /home/pacs/xyz00/users/ldap/slapd2/etc -d 0
PIDFile=/home/pacs/xyz00/users/ldap/slapd2/run/slapd.pid

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

Im Anschluss:
<syntaxhighlight lang=bash>
systemctl enable --user slapd
systemctl start --user slapd
</syntaxhighlight>

'''Hinweis:''' unter Umständen muss ein Administator diese Funktionalität erst für Sie freischalten. Ihr User benötigt womöglich außerdem die folgende Umgebungsvariable um die Befehle ausführen zu können:
<syntaxhighlight lang=bash>
export XDG_RUNTIME_DIR=/run/user/$UID
</syntaxhighlight>

== Pflege der LDAP Daten über die Kommandozeile ==
=== Benutzer anlegen ===

Datei adduser.ldif (entsprechende Werte ersetzen):

<syntaxhighlight lang=bash line>
dn: uid=mmustermann,ou=users,dc=example,dc=org
objectClass: inetOrgPerson
cn: Max
sn: Mustermann
uid: mmustermann
userPassword: TopSecret1234
mail: mmustermann@example.org
</syntaxhighlight>

Dann ausführen:
<syntaxhighlight lang=bash>
ldapadd -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f adduser.ldif
</syntaxhighlight>

=== Passwort von Benutzer ändern ===
<syntaxhighlight lang=bash>
export PORT=30389
export BASE_DN="dc=example,dc=org"
ldappasswd -H ldap://127.0.0.1:$PORT -x -D "cn=admin,$BASE_DN" -W -S "uid=mmustermann,ou=users,$BASE_DN"
</syntaxhighlight>

=== Nach Benutzern suchen ===

<syntaxhighlight lang=bash>
export PORT=30389
export BASE_DN="dc=example,dc=org"
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT # geht sogar ohne Benutzer
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT -D "cn=admin,cn=config" -W
</syntaxhighlight>

Was kann der normale Benutzer sehen:
<syntaxhighlight lang=bash>
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT -D "uid=mmustermann,ou=users,$BASE_DN" -W
</syntaxhighlight>

nach Personen mit bestimmter Klasse suchen:
<syntaxhighlight lang=bash>
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W "objectClass=inetOrgPerson"
</syntaxhighlight>

=== Eigenschaften aktualisieren ===

Datei modify_email.ldif:
<syntaxhighlight lang=ldap line>
dn: uid=mmustermann,ou=users,dc=example,dc=org
changetype: modify
replace: mail
mail: mmustermann2@example.org
</syntaxhighlight>

Dann ausführen:
<syntaxhighlight lang=bash>
ldapmodify -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f modify_email.ldif
</syntaxhighlight>

=== Neue Gruppe anlegen ===

Einmal vorbereiten, memberof overlay installieren:

Datei add-memberof-overlay.ldif:

<syntaxhighlight lang=bash line>
dn: olcOverlay=memberof,olcDatabase={1}mdb,cn=config
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcOverlay: memberof
olcMemberOfRefInt: TRUE
olcMemberOfDangling: ignore
olcMemberOfGroupOC: groupOfNames
olcMemberOfMemberAD: member
olcMemberOfMemberOfAD: memberOf
</syntaxhighlight>

Dann ausführen:

<syntaxhighlight lang=bash>
ldapadd -H ldap://127.0.0.1:$PORT -D "cn=admin,cn=config" -W -f add-memberof-overlay.ldif
</syntaxhighlight>

Datei addgroup.ldif (entsprechende Werte ersetzen):

<syntaxhighlight lang=bash line>
dn: cn=admins,ou=groups,dc=example,dc=org
cn: admins
objectclass: groupOfNames
member: uid=mmustermann,ou=users,dc=example,dc=org
</syntaxhighlight>

Dann ausführen:
<syntaxhighlight lang=bash>
ldapadd -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f addgroup.ldif
</syntaxhighlight>

=== Benutzer zu einer Gruppe hinzufügen ===

Datei addmember.ldif (entsprechende Werte ersetzen):

<syntaxhighlight lang=bash line>
dn: cn=admins,ou=groups,dc=example,dc=org
changetype: modify
add: member
member: uid=mmustermann,ou=users,dc=example,dc=org
</syntaxhighlight>

Dann ausführen:
<syntaxhighlight lang=bash>
ldapmodify -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f addmember.ldif
</syntaxhighlight>

=== Liste alle Benutzer einer Gruppe ===

<syntaxhighlight lang=bash>
export FILTER="(&(objectClass=inetOrgPerson)(memberof=CN=admins,OU=groups,DC=example,DC=org))"
ldapsearch -x -b "$BASE_DN" -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W $FILTER
</syntaxhighlight>

=== Benutzer aus einer Gruppe entfernen ===

Datei dropmember.ldif (entsprechende Werte ersetzen):

<syntaxhighlight lang=ldap>
dn: cn=admins,ou=groups,dc=example,dc=org
changetype: modify
delete: member
member: uid=mmustermann,ou=users,dc=example,dc=org
</syntaxhighlight>

Dann ausführen:

<syntaxhighlight lang=bash>
ldapmodify -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f dropmember.ldif
</syntaxhighlight>

=== Benutzer löschen ===

<syntaxhighlight lang=bash>
ldapdelete -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W "uid=mmustermann,ou=users,$BASE_DN"
</syntaxhighlight>

=== Gruppe löschen ===

Datei delete_group.ldif:

<syntaxhighlight lang=ldap>
dn: cn=Test,ou=groups,dc=example,dc=org
changetype: delete
</syntaxhighlight>

Dann ausführen:
<syntaxhighlight lang=bash>
ldapmodify -H ldap://127.0.0.1:$PORT -D "cn=admin,$BASE_DN" -W -f delete_group.ldif
</syntaxhighlight>

== Links ==
*[https://www.vincentliefooghe.net/content/openldap-setup-multiple-instances-server Ein Setup für mehrere OpenLDAP Instanzen auf einem Server]

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

Gitea

2025-03-03T15:01:30Z

Sib: updated link to Gitea admin page

== Gitea installieren ==

[https://gitea.io/en-us/ Gitea] ist ein einfacher, selbst gehosteter Git-Service wie GitHub oder GitLab. Die Software ist ein Fork von Gogs und ebenfalls in der Programmiersprache Go geschrieben. Gitea benötigt wenig Ressourcen. Um Gitea auf der Hostsharing Plattform nutzen zu können, benötigt man entweder einen Managed Server oder man muss für seinen Managed Webspace einen Daemon hinzubuchen.

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

=== Vorbereitung der Installation ===

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

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

Auf der Kommandozeile kann man dies folgendermaßen erledigen.

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

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

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

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

=== Installation von Gitea ===

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

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

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

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

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

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

Nun können wir Gitea testweise starten:

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

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

Der Server kann mit Ctrl-C beendet werden.

=== Konfiguration der Domain ===

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

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

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

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

Der Eintrag muss lauten:

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

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

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

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

Damit ist die Konfiguration von Apache abgeschlossen.

=== Konfiguration von Gitea ===

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

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

Die Konfigurationsdatei beginnt mit allgemeinen Einträgen:

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

Im Abschnitt [database] folgen die Angaben zur Datenbank:

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

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

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

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

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

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

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

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

Sie können nun Gitea starten:

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

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

=== Service einrichten ===

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

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

<syntaxhighlight lang=ini>
Description=Gitea

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

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

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

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

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

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

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

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

[Timer]
OnCalendar=1:51
Persistent=True

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

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

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

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

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

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

=== Anmeldung über LDAP einrichten ===

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

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

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

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

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

Hier noch ein Screenshot:

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

=== Default Branches ohne Force Push ===

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

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

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

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

Zeige die Regeln für die Hauptbranches:

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

== weiterführende Links ==

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

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

Umstellung von Daemon-Diensten auf systemd

2025-02-17T20:49:30Z

Sib: swap Systemd im Userspace with Prozessmanagement mit systemd im Userspace

== 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 [[Prozessmanagement mit 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 ===

==== Rückblick auf Bearbeitung von Cronjobs ====
Mit dem Befehl <code>crontab -l</code> können die eigenen Cronjobs aufgelistet werden.

Mit dem Befehl <code>crontab -e</code> bearbeiten wir unsere Hintergrundjobs.

Wenn am Anfang einer Zeile das Rautezeichen # eingesetzt wird, dann ist die Zeile deaktiviert.

Eine Übersicht über die Cronjobs der einzelnen Benutzer eines Webpaketes xyz00 lässt sich so ausgeben, wenn in der Shell des Paket-Benutzers xyz00 folgender Befehl ausgeführt wird:

<syntaxhighlight lang="bash">
cd users/; for U in *; do echo "=== $USER-$U"; sudo -u $USER-$U crontab -l | grep -v "#"; done
</syntaxhighlight>

Auf der Seite [[Cron]] werden weitere Einzelheiten beschrieben.

==== Umstellung auf systemd Timer ====

Hier ist eine schöne Übersicht mit Beispielen: https://documentation.suse.com/smart/systems-management/html/systemd-working-with-timers/index.html#systemd-timer-catchup

==== Beispiel: Nextcloud Hintergrund Job ====

Hier haben wir ein Beispiel für einen Nextcloud Hintergrund Job, der alle 5 Minuten läuft, und in der crontab eingetragen ist:

<syntaxhighlight lang="crontab">
*/5 * * * * /usr/bin/php $HOME/nextcloud/cron.php
</syntaxhighlight>

Wir deaktivieren diesen Cronjob, in dem wir ein # vor die Zeile setzen, wie oben beschrieben.

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den oneshot Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/nextcloud-job.service
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Nextcloud Hintergrundjob

[Service]
Type=oneshot
ExecStart=/usr/bin/php %h/nextcloud/cron.php
</syntaxhighlight>

{{Textkasten|gelb|Beachte|Statt $HOME muss %h benutzt werden!}}

Nun wird die Datei für den Timer angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/nextcloud-job.timer
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Timer für Nextcloud Hintergrundjob

[Timer]
OnCalendar=*:0/5
RandomizedDelaySec=30

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

Nun soll der Timer noch aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
systemctl --user enable nextcloud-job.timer --now
</syntaxhighlight>

==== Beispiel: Logrotate aufrufen ====

Hier haben wir ein Beispiel für einen Logrotate Job, der einmal in der Nacht aufgerufen wird, und in der crontab eingetragen ist:

<syntaxhighlight lang="crontab">
13 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate
</syntaxhighlight>

Wir deaktivieren diesen Cronjob, in dem wir ein # vor die Zeile setzen, wie oben beschrieben.

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den oneshot Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/logrotate-job.service
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Logrotate Job

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

{{Textkasten|gelb|Beachte|Statt $HOME muss %h benutzt werden!}}

Nun wird die Datei für den Timer angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/logrotate-job.timer
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang="ini">
[Unit]
Description=Timer für Logrotate Job

[Timer]
OnCalendar=01:13
RandomizedDelaySec=300
Persistent=true

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

Nun soll der Timer noch aktiviert und gestartet werden:

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
systemctl --user enable logrotate-job.timer --now
</syntaxhighlight>

=== Monit ===

==== Beispiel: Redis ====

Hier haben wir eine Datei <code>.monitrc</code>, mit der ein Redis Dienst betrieben wird:

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

Der Start von monit nach einem Reboot des Servers wird verhindert, indem die entsprechende Zeile gelöscht wird:

<syntaxhighlight lang="bash">
crontab -e

entferne diese Zeile:
@reboot /usr/bin/monit -c $HOME/.monitrc
</syntaxhighlight>

Die Dienste werden gestoppt:

<syntaxhighlight lang="bash">
killall -u $USER -KILL monit
killall -u $USER -KILL redis-server
</syntaxhighlight>

Nun muss ggfs. das Verzeichnis für systemd angelegt werden:

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

Nun wird die Datei für den Redis Dienst angelegt:

<syntaxhighlight lang="bash">
nano $HOME/.config/systemd/user/redis.service
</syntaxhighlight>

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

[Service]
WorkingDirectory=%h/redis/var
ExecStart=/usr/bin/redis-server %h/redis/etc/redis.conf
Restart=always
PrivateTmp=true
NoNewPrivileges=true
StandardOutput=append:%h/var/log/redis.log
StandardError=inherit

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

Es muss noch die folgende Zeile aus <code>redis/etc/redis.conf</code> entfernt werden:

<syntaxhighlight lang="conf">
daemonize yes
</syntaxhighlight>

Nun soll der Dienst aktiviert und gestartet werden:

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

==== Beispiel: Apache ====

Es wurden in der Vergangenheit Start- und Stoppskripte empfohlen. Die Startskripte wurden dann um verschiedene Aktionen ergänzt.

Da empfehlen wir, die sonstigen Aktionen in ein eigenes Skript auszulagern, das mit der Direktive <code>ExecStartPre=</code> gestartet wird.
Dann kann der eigentliche Prozess mit <code>ExecStart=</code> gestartet werden, und wird dann auch entsprechend beendet. Dann ist kein Stopp-Skript erforderlich.

Es kann aber auch mit <code>ExecStop</code> ein Stopp-Skript ausgeführt werden.

=== supervisor ===

Bei supervisor wird z.B. in der Datei <code>~/supervisor/etc/supervisord.conf</code> ein Redis Dienst konfiguriert:

<syntaxhighlight lang="ini">
[program:redis]
command=/usr/bin/redis-server /home/pacs/xyz00/test/loomio/redis/etc/redis.conf
stderr_logfile = /home/pacs/xyz00/users/test/supervisor/log/redis-stderr.log
stdout_logfile = /home/pacs/xyz00/users/test/supervisor/log/redis-stdout.log
</syntaxhighlight>

Das muss entsprechend durch einen systemd Dienst ersetzt werden, siehe der Abschnitt bei der Umstellung von monit auf systemd.

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

siehe [[Prozessmanagement_mit_systemd_im_Userspace#RAM_Kontingent_eines_Webspace|RAM Kontingent eines Webspace]]

----
[[Kategorie:Systemd]]

Nextcloud

2025-02-06T18:59:49Z

Sib: Erstellung der .ncdata Datei fuer HDD Storage hinzugegeben

= Nextcloud =

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

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

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

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

= Nextcloud installieren =

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:

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

Dann nacheinander anlegen:

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

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

== Nextcloud installieren ==

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

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

''htdocs'' Verzeichnis vorbereiten

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

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

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

Nextcloud herunterladen und entpacken.

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

== Nextcloud konfigurieren ==

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

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

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

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

Auf der ersten Seite sind anzugeben:

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

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

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

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

== Nextcloud beschleunigen ==

Dieser Teil ist optional.

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

=== Redis Cache ===

Redis ist auf den Hostsharing-Servern vorinstalliert und wird von den Nextcloud-Entwicklern empfohlen. '''In Verbindung mit einem Managed Webspace''' muss für Redis als eigener Serverdienst RAM gebucht werden und ist '''kostenpflichtig'''. Siehe zu Kosten im Webspace Konfigurator unter: https://www.hostsharing.net/angebote/managed-webspace/ – '''Arbeitsspeicher für eigene Serverdienste'''.

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

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

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

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

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

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

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

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

[Timer]
OnCalendar=1:1
Persistent=True

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

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

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

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

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

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

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

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

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

=== Nextcloud Push ===

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

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

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

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

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

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

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

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

== Nextcloud mit Online Office ==

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

== Nextcloud mit Nextcloud Talk ==

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

== Virenscanner ==

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

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

== Volltextsuche ==

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

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

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

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

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

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

Die anderen Einstellung nach den eigenen Vorstellungen vornehmen.

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

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

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

Zur Pflege des Indexes wird ein weiterer Hintergrundprozess gestartet:

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

Die Monit Konfiguration dafür sieht so aus:

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

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

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

== Integration mit LDAP ==

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

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

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

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

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

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

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

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

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

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

Folgende Änderungen können helfen:

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

== Default App einstellen ==

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

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

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

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

= Nextcloud Updates =

== Updater über die Shell starten ==

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

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

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

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

So können die Apps noch alle aktualisiert werden:

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

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

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

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

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

== Wartungsmodus per Shell ein- oder ausschalten ==

So kann der Wartungsmodus angeschaltet werden:

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

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

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

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

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

Aufgetreten nach erfolgtem Versionsupdate Nextcloud 19 auf Nextcloud 20

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

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

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

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

== Update per Skript ==

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

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

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

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

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

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

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

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

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

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

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

Seit mindestens Version 30 von Nextcloud führt diese Konfiguration zu diesem Fehler.

<syntaxhighlight lang=shell>
Your data directory is invalid.
Ensure there is a file called ".ncdata" in the root of the data directory. It should have the content: "# Nextcloud data directory"

An unhandled exception has been thrown:
Exception: Environment not properly prepared. in /home/pacs/sib03/users/nc/nextcloud/lib/private/Console/Application.php:137
Stack trace:
#0 /home/pacs/sib03/users/nc/nextcloud/console.php(81): OC\Console\Application->loadCommands()
#1 /home/pacs/sib03/users/nc/nextcloud/occ(11): require_once('...')
</syntaxhighlight>

Mit der folgenden Konfiguration umgehen wir diesen Fehler.

<syntaxhighlight lang=shell>
# Nextcloud in Wartungsmodus versetzen
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --on
xyz00-cloud@h00:~/nextcloud$ vi /home/storage/xyz00/users/cloud/data/.ncdata
# Den Text '# Nextcloud data directory' dazugeben
# Wartungsmodus beenden
xyz00-cloud@h00:~/nextcloud$ php occ maintenance:mode --off
</syntaxhighlight>

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

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

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

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

= weiterführende Links =

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

= Nextcloud Reseller bei HS =

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

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

Nextcloud

2025-01-30T14:42:52Z

Sib: add troubleshooting in case HTTP Redirect resolves to the domain instead of the subdomain

= Nextcloud =

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

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

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

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

= Nextcloud installieren =

== Vorbereitungen ==

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

''hsadmin''-Shell starten mit:

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

Dann nacheinander anlegen:

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

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

== Nextcloud installieren ==

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

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

''htdocs'' Verzeichnis vorbereiten

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

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

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

Nextcloud herunterladen und entpacken.

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

== Nextcloud konfigurieren ==

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

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

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

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

Auf der ersten Seite sind anzugeben:

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

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

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

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

== Nextcloud beschleunigen ==

Dieser Teil ist optional.

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

=== Redis Cache ===

Redis ist auf den Hostsharing-Servern vorinstalliert und wird von den Nextcloud-Entwicklern empfohlen. '''In Verbindung mit einem Managed Webspace''' muss für Redis als eigener Serverdienst RAM gebucht werden und ist '''kostenpflichtig'''. Siehe zu Kosten im Webspace Konfigurator unter: https://www.hostsharing.net/angebote/managed-webspace/ – '''Arbeitsspeicher für eigene Serverdienste'''.

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

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

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

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

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

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

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

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

[Timer]
OnCalendar=1:1
Persistent=True

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

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

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

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

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

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

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

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

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

=== Nextcloud Push ===

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

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

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

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

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

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

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

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

== Nextcloud mit Online Office ==

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

== Nextcloud mit Nextcloud Talk ==

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

== Virenscanner ==

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

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

== Volltextsuche ==

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

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

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

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

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

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

Die anderen Einstellung nach den eigenen Vorstellungen vornehmen.

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

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

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

Zur Pflege des Indexes wird ein weiterer Hintergrundprozess gestartet:

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

Die Monit Konfiguration dafür sieht so aus:

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

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

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

== Integration mit LDAP ==

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

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

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

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

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

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

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

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

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

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

Folgende Änderungen können helfen:

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

== Default App einstellen ==

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

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

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

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

= Nextcloud Updates =

== Updater über die Shell starten ==

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

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

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

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

So können die Apps noch alle aktualisiert werden:

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

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

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

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

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

== Wartungsmodus per Shell ein- oder ausschalten ==

So kann der Wartungsmodus angeschaltet werden:

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

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

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

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

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

Aufgetreten nach erfolgtem Versionsupdate Nextcloud 19 auf Nextcloud 20

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

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

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

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

== Update per Skript ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

= weiterführende Links =

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

= Nextcloud Reseller bei HS =

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

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

CAS Authentication Server

2024-09-04T13:15:37Z

Sib: adjust section Tomcat: secretRequired="true"

= CAS Authentication Server =

Der CAS Server ("Central Authentication Service" oder "CAS Authentication Server") ist eine SSO- ("Single Sign On") Lösung.

CAS ist für große, verteilte Deployments von Web-Anwendungen geeignet. Er stammt aus dem Universitätsumfeld in den USA. Er wurde bei der Yale Universität entwickelt und wird aktuell bei JA-SIG / Apereo als freie Software unter der Apache Lizenz gepflegt. [1], [2]

Die Hostsharing eG nutzt CAS seit Jahren als Login-Lösung insbesondere für die Administrationswerkzeuge von [[Hsadmin|HSAdmin]].

Dieser Beitrag erläutert die Installation von CAS in einem Hostsharing Webspace und die Konfiguration von Beispielanwendungen zum Login mit CAS. Als Nutzerdatenbank wird ein vorhandener Nutzerstamm in einer SQL-Datenbank benutzt.

== Erste Installation ==

Die aktuelle stabile Version des CAS Server ist v6.6.7 (Stand August 2024: v7.0.6). Diese Version erfordert Java 11. Die empfohlene Installation eines Standalone-CAS erfolgt über das WAR Overlay Projekt [3]. Eine ausführliche Deployment-Anleitung (leider noch für Version 5.x) findet sich bei [https://www.newschool.edu/ The New School] [4]. Eine Anleitung für die aktuelle Version 6.6.x ist unter [10] verfügbar.

=== Service-User und Domain ===

Zunächst werden mit HSAdmin ein User und eine Domain eingerichtet. Darauf achten, dass der User eine gültige Login-Shell erhält, hier die Bash (''/bin/bash'').

<syntaxhighlight lang="bash">
xyz00@h50:~$ hsscript -i
xyz00@hsadmin> user.add({set:{name:'xyz00-login',shell:'/bin/bash',password:'***'}})
xyz00@hsadmin> domain.add({set:{user:'xyz00-login',name:'login.hs-example.de'}})
xyz00@hsadmin> bye
</syntaxhighlight>

=== Einrichtung des Tomcat ===

Für den Apache Tomcat Webserver ist die Option "Eigener Daemon" im [https://www.hostsharing.net/paas/managed-webspace/ Hostsharing Webspace] notwendig ( im [https://www.hostsharing.net/paas/managed-server/ Managed Server] nicht). Bei der Anmeldung (bei service(at)hostsharing.net bitte den Service User ''xyz00-login'' und die gewüschte Anzahl IP-Ports angeben). Hier verwenden wir die Ports 31530, 31531 und 31532.

Weiter geht es als User ''xyz00-login''

Einrichten eines Apache Tomcat 9 (Stand August 2024: [[Tomcat Installieren|Apache Tomcat 10]]) im Userspace:

<syntaxhighlight lang="output">
xyz00-login@h50:~$ tomcat9-instance-create tomcat9
You are about to create a Tomcat instance in directory 'tomcat9'
Warning: HTTP port 8080 appears to be in use.
Type <ENTER> to continue, <CTRL-C> to abort.
</syntaxhighlight>

Mit <Enter> bestätigen, dann wird eine Tomcat-Konfiguration im neuen Verzeichnis $HOME/tomcat9 angelegt.

Die ''server.xml'' im Verzeichnis $HOME/tomcat9/conf wird angepasst:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="31530" shutdown="SHUTDOWN">

<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>

<Service name="Catalina">
<Connector address="localhost" port="31531" protocol="AJP/1.3" redirectPort="443" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
</Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Insbesondere die beiden Angaben ''port="31530"'' und ''port="31531"'' müssen angepasst werden!

In der Datei ''setenv.sh'' im Verzeichnis $HOME/tomcat9/bin ergänzenen wir den Pfad zur Java 11 Installation als Variable $JAVA_HOME (für 32-Bit bzw. für 64-Bit Systeme), dazu den Pfad für eine Datei mit der Prozess-ID Prozess-Id und eine System-Property in den Java-Opts mit dem Verzeichnis-Pfad, in dem wir später die CAS-Konfiguration ablegen:

<syntaxhighlight lang="bash">
# export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-i386
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export JAVA_OPTS="-Djava.awt.headless=true -Dcas.standalone.configurationDirectory=/home/pacs/xyz00/users/login/cas/conf"
</syntaxhighlight>

Ich kopiere zum Testen gern noch das Startskript ''catalina.sh'' in die Installation des Tomcat:

<syntaxhighlight lang="bash">
xyz00-login@h50:~$ cp /usr/share/tomcat9/bin/catalina.sh $HOME/tomcat9/bin/
xyz00-login@h50:~$ cd tomcat9/
xyz00-login@h50:~/tomcat9$ ./bin/catalina.sh run
Using CATALINA_BASE: /home/pacs/xyz00/users/login/tomcat9
Using CATALINA_HOME: /usr/share/tomcat9
Using CATALINA_TMPDIR: /home/pacs/xyz00/users/login/tomcat9/temp
Using JRE_HOME: /usr/lib/jvm/default-java
Using CLASSPATH: /usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar
<6>Server version name: Apache Tomcat/9.0.31 (Debian)
[...]
<6>Server startup in [75] milliseconds
</syntaxhighlight>

Tomcat läuft, abbrechen mit <Ctrl-C>

=== Konfiguration des Apache als Proxy ===

<syntaxhighlight lang="bash">
cd ~/doms/login.hs-example.de/
rm -rf subs/www subs-ssl/www
</syntaxhighlight>

Bearbeiten der ~/doms/login.hs-example.de/htdocs-ssl/.htaccess

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

Achtung: der Port 31531 ist wieder durch den Port des AJP-Listeners in der eigenen Tomcat-Konfiguration zu ersetzen.

=== CAS Basisinstallation ===

Auschecken des CAS Overlay Projektes (TODO: Warum nicht ```git checkout 6.6```? Typo?)

<syntaxhighlight lang="bash">
mkdir git
cd git
git clone https://github.com/apereo/cas-overlay-template.git
cd cas-overlay-template/
git fetch
git checkout 6.0
</syntaxhighlight>

Anlegen von Verzeichnissen für die spätere Konfiguration des CAS Server

<syntaxhighlight lang="bash">
cd
mkdir -p cas/conf
mkdir -p cas/services
</syntaxhighlight>

Ins Verzeichnis ''~/cas/conf'' legen wir eine Datei ''cas.properties'' mit folgendem Inhalt:

<syntaxhighlight lang="ini" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
</syntaxhighlight>

Die Datei ''log4j2.xml'' kopieren wir aus ''~/git/cas-overlay-template/etc/cas/config/''

<syntaxhighlight lang="bash">
cp ~/git/cas-overlay-template/etc/cas/config/ ~/cas/conf/
</syntaxhighlight>

In der log4j2.xml passen wir den Wert für die Variable ''baseDir'' (etwa Zeile 5) an:

<syntaxhighlight lang="xml">
<Property name="baseDir">/home/pacs/xyz00/users/login/tomcat9/logs</Property>
</syntaxhighlight>

Build und Deployment der Web-Applikation

<syntaxhighlight lang="bash">
./build.sh package
cd
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Nach einer erneuten Start des Tomcat ist das CAS-Login unter
https://login.hs-example.de/cas/ erreichbar.

Ein Login mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte erfolgreich sein.

== Erweiterte Konfiguration des CAS ==

Die Funktionalität des CAS Server ist modular erweiterbar. Im ersten Schritt erweitern wir den CAS um eine Service Registry. Für unsere einfache Standalone-Installation nutzen wir die JSON-File-Registry

=== JSON Service Registry ===

Erweiterungen werden in der Datei ''build.gradle'' im Abschnitt ''dependencies'' eingetragen. Die Datei liegt im Wurzelverzeichnis des Git-Repositories für unser CAS Overlay (''~/git/cas-overlay-template/'').

Der betreffende Ausschnitt der Datei:

<syntaxhighlight lang="java" line>
dependencies {
// [...] Teile ausgespart

/**
* CAS dependencies and modules may be listed here.
*
* There is no need to specify the version number for each dependency
* since versions are all resolved and controlled by the dependency management
* plugin via the CAS bom.
**/

// email notification, service registry
implementation "org.apereo.cas:cas-server-core-notifications"
implementation "org.apereo.cas:cas-server-support-json-service-registry"

// jdbc datasource
implementation "org.apereo.cas:cas-server-support-jdbc-drivers"
implementation "org.apereo.cas:cas-server-support-jdbc"

// password reset
implementation "org.apereo.cas:cas-server-support-pm-webflow"
implementation "org.apereo.cas:cas-server-support-pm-jdbc"

// openid-connect / oidc
implementation "org.apereo.cas:cas-server-support-oidc"

/**
* Do NOT modify the lines below or else you will risk breaking the build.
*/
implementation "org.apereo.cas:cas-server-core-api-configuration-model"
implementation "org.apereo.cas:cas-server-webapp-init"

// [...] Teile ausgespart
}
</syntaxhighlight>

Wir bauen das cas.war mit den folgenden Befehlen neu:

<syntaxhighlight lang="bash">
cd ~/git/cas-overlay-template
./build.sh package
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Der Pfad zur Service-Registry war in der oben erstellten ''cas.properties'' bereits enthalten.
Nun legen wir einen ersten Service an, in meinem Fall eine Nextcloud-Installation. Die Datei heißt
''hsexamplecloud-1000001.json'' und wird im Verzeichnis ''~/cas/services/'' abgelegt. Der Inhalt:

<syntaxhighlight lang="json" line>
{
"@class" : "org.apereo.cas.services.RegexRegisteredService",
"serviceId" : "^https://cloud.hs-example.de.*",
"name" : "hsexamplecloud",
"id" : 1000001,
"description" : "Nextcloud HS-Example",
"evaluationOrder" : 10000
}
</syntaxhighlight>

Der Name der Datei setzt sich aus Service-Name und Service-Id zusammen!

Die Konfiguration des CAS-Login in der Nextcloud erfolgt über die entsprechende "App" in Nextcloud.
Die Parameter sind wie folgt:

[[Datei:Cas-nextcloud-app.png]]

Die "Dienst-URL" im Screenshot ist: ''https://cloud.hs-example.de/index.php/apps/user_cas/login''

Die Anmeldung mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte nun von der Nextcloud-Loginseite über den Link zum CAS-Login möglich sein.

=== Authentifizierung gegen JDBC Datenbank ===

Wir erweitern wieder die Datei ''build.gradle'' im Abschnitt ''dependencies''.

<syntaxhighlight lang="java" line>
dependencies {
compile "org.apereo.cas:cas-server-webapp${project.appServer}:${casServerVersion}"
// Other CAS dependencies/modules may be listed here...
compile "org.apereo.cas:cas-server-support-json-service-registry:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc-drivers:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc:${project.'cas.version'}"
}
</syntaxhighlight>

''cas-server-support-jdbc-drivers'' liefert JDBC-Treiber für die gängigen Open-Source Datenbanksysteme. ''org.apereo.cas:cas-server-support-jdbc'' liefert das eigentliche CAS-Authentication Backend.

Zur Konfiguration wird die Datei ''cas.properties'' im Verzeichnis ''~/cas/conf/'' erweitert:

<syntaxhighlight lang="java" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
logging.level.org.apereo=DEBUG
cas.authn.jdbc.query[0].sql=SELECT * FROM USERS WHERE UID=?
cas.authn.jdbc.query[0].url=jdbc:postgresql://localhost/xyz00_cas
cas.authn.jdbc.query[0].dialect=org.hibernate.dialect.PostgreSQL92Dialect
cas.authn.jdbc.query[0].user=xyz00_cas
cas.authn.jdbc.query[0].password=Ein_schlechtes_Passwort
cas.authn.jdbc.query[0].driverClass=org.postgresql.Driver
cas.authn.jdbc.query[0].fieldPassword=PSW
cas.authn.jdbc.query[0].passwordEncoder.type=BCRYPT
cas.authn.jdbc.query[0].passwordEncoder.characterEncoding=UTF-8
cas.authn.accept.users=
</syntaxhighlight>

Hier ein Beispiel für eine PostgreSQL-Datenbank mit einer Tabelle ''USERS'' mit den Spalten ''UID'' und ''PSW''. Die Spalte ''UID'' enthält den Login-Namen des Users, die Spalte ''PSW'' das Passwort mit dem BCrypt-Algorithmus verschlüsselt.

Die Zeile ''cas.authn.accept.users='' deaktiviert das Default-Login als User ''casuser'' mit Passwort ''Mellon''.

Achtung: Das Spring-Security Framework erwartet das BCrypt-Passwort mit der Kennung ''$2a$'' als erste Zeichen des Passwortfeldes. Die PHP-Funktion ''password_hash'' schreibt ''$2y$'' Wenn eine PHP-Passwort-Datenbank genutzt wird, muss hier ggf. eine VIEW in der Datenbank helfen.

== Grafische Anpassung der CAS Login-Seiten ==

Die Anpassungen der Login-Seite und anderer Teile der Browser-Anwendung ist vorgesehen. Eine Anleitung findet sich unter Link [7] und [4].

== Links ==

[1] https://de.wikipedia.org/wiki/Central_Authentication_Service

[2] https://www.apereo.org/projects/cas

[3] https://github.com/apereo/cas-overlay-template

[4] https://dacurry-tns.github.io/deploying-apereo-cas/

[5] https://apereo.github.io/2017/02/22/cas51-dbauthn-tutorial/

[6] https://apereo.github.io/2017/02/02/cas51-authn-handlers/

[7] https://apereo.github.io/2018/06/10/cas-userinterface-customizations/

[8] https://apereo.github.io/tags/#CAS

[9] https://iam.uconn.edu/java-cas-client-installation-and-configuration/

[10] https://fawnoos.com/2022/08/06/cas66-gettingstarted-overlay/

[11] https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/cas Ansible Playbook

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

== Troubleshooting ==

=== CAS: Unterschiedliche Zeitstempel ===
Wenn wir das cas.war erneut bauen, wird Tomcat vermeintlich über unterschiedliche Zeitstempel meckern.

<syntaxhighlight lang="bash">
28-Aug-2024 15:30:32.976 INFO [main] org.apache.catalina.startup.ExpandWar.expand An expanded directory [/home/pacs/sib01/users/auth/tomcat/webapps/cas] was found with a last modified time that did not match the associated WAR. It will be deleted.
</syntaxhighlight>

In diesem Fall wird Tomcat den CAS-Dienst nur bedienen, wenn die alte Version komplett bereinigt ist.

<syntaxhighlight lang="bash">
cd ~/git/cas-overlay-template
./build.sh package
rm -rf ~/tomcat9/webapps/cas*
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Anschließend akzeptiert Tomcat das neue cas.war.

<syntaxhighlight lang="bash">
28-Aug-2024 15:50:34.904 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/home/pacs/sib01/users/auth/tomcat/webapps/cas.war]
</syntaxhighlight>

=== Tomcat: secretRequired="true" ===

Die Standard-Konfiguration der Datei ~/tomcat/conf/server.xml führt zu dieser Fehlermeldung.

<syntaxhighlight lang="bash">
cd ~/tomcat
./bin/catalina.sh run
...
The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "". This combination is not valid.
...
</syntaxhighlight>

Fazit: Ich habe

<syntaxhighlight lang="bash">
<Connector port="31531" protocol="AJP/1.3"
connectionTimeout="20000"
redirectPort="8443" secretRequired="false" />
</syntaxhighlight>

in dieser Konfiguration gesetzt. Damit überwinden wir den betreffenden Fehler und Tomcat startet wie erwartet.

<syntaxhighlight lang="bash">
...
04-Sep-2024 15:13:18.196 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [101] milliseconds
...
</syntaxhighlight>

Solange der AJP-Listener ausschließlich auf eine Localhost-IP konfiguriert ist, sollte diese Konfiguration (insbesondere auf einem Managed-Server) akzeptabel sein. Dann ist der AJP-Listener von extern nicht erreichbar.

CAS Authentication Server

2024-09-03T14:26:17Z

Sib: add section Tomcat: secretRequired="true"

= CAS Authentication Server =

Der CAS Server ("Central Authentication Service" oder "CAS Authentication Server") ist eine SSO- ("Single Sign On") Lösung.

CAS ist für große, verteilte Deployments von Web-Anwendungen geeignet. Er stammt aus dem Universitätsumfeld in den USA. Er wurde bei der Yale Universität entwickelt und wird aktuell bei JA-SIG / Apereo als freie Software unter der Apache Lizenz gepflegt. [1], [2]

Die Hostsharing eG nutzt CAS seit Jahren als Login-Lösung insbesondere für die Administrationswerkzeuge von [[Hsadmin|HSAdmin]].

Dieser Beitrag erläutert die Installation von CAS in einem Hostsharing Webspace und die Konfiguration von Beispielanwendungen zum Login mit CAS. Als Nutzerdatenbank wird ein vorhandener Nutzerstamm in einer SQL-Datenbank benutzt.

== Erste Installation ==

Die aktuelle stabile Version des CAS Server ist v6.6.7 (Stand August 2024: v7.0.6). Diese Version erfordert Java 11. Die empfohlene Installation eines Standalone-CAS erfolgt über das WAR Overlay Projekt [3]. Eine ausführliche Deployment-Anleitung (leider noch für Version 5.x) findet sich bei [https://www.newschool.edu/ The New School] [4]. Eine Anleitung für die aktuelle Version 6.6.x ist unter [10] verfügbar.

=== Service-User und Domain ===

Zunächst werden mit HSAdmin ein User und eine Domain eingerichtet. Darauf achten, dass der User eine gültige Login-Shell erhält, hier die Bash (''/bin/bash'').

<syntaxhighlight lang="bash">
xyz00@h50:~$ hsscript -i
xyz00@hsadmin> user.add({set:{name:'xyz00-login',shell:'/bin/bash',password:'***'}})
xyz00@hsadmin> domain.add({set:{user:'xyz00-login',name:'login.hs-example.de'}})
xyz00@hsadmin> bye
</syntaxhighlight>

=== Einrichtung des Tomcat ===

Für den Apache Tomcat Webserver ist die Option "Eigener Daemon" im [https://www.hostsharing.net/paas/managed-webspace/ Hostsharing Webspace] notwendig ( im [https://www.hostsharing.net/paas/managed-server/ Managed Server] nicht). Bei der Anmeldung (bei service(at)hostsharing.net bitte den Service User ''xyz00-login'' und die gewüschte Anzahl IP-Ports angeben). Hier verwenden wir die Ports 31530, 31531 und 31532.

Weiter geht es als User ''xyz00-login''

Einrichten eines Apache Tomcat 9 (Stand August 2024: [[Tomcat Installieren|Apache Tomcat 10]]) im Userspace:

<syntaxhighlight lang="output">
xyz00-login@h50:~$ tomcat9-instance-create tomcat9
You are about to create a Tomcat instance in directory 'tomcat9'
Warning: HTTP port 8080 appears to be in use.
Type <ENTER> to continue, <CTRL-C> to abort.
</syntaxhighlight>

Mit <Enter> bestätigen, dann wird eine Tomcat-Konfiguration im neuen Verzeichnis $HOME/tomcat9 angelegt.

Die ''server.xml'' im Verzeichnis $HOME/tomcat9/conf wird angepasst:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="31530" shutdown="SHUTDOWN">

<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>

<Service name="Catalina">
<Connector address="localhost" port="31531" protocol="AJP/1.3" redirectPort="443" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
</Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Insbesondere die beiden Angaben ''port="31530"'' und ''port="31531"'' müssen angepasst werden!

In der Datei ''setenv.sh'' im Verzeichnis $HOME/tomcat9/bin ergänzenen wir den Pfad zur Java 11 Installation als Variable $JAVA_HOME (für 32-Bit bzw. für 64-Bit Systeme), dazu den Pfad für eine Datei mit der Prozess-ID Prozess-Id und eine System-Property in den Java-Opts mit dem Verzeichnis-Pfad, in dem wir später die CAS-Konfiguration ablegen:

<syntaxhighlight lang="bash">
# export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-i386
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export JAVA_OPTS="-Djava.awt.headless=true -Dcas.standalone.configurationDirectory=/home/pacs/xyz00/users/login/cas/conf"
</syntaxhighlight>

Ich kopiere zum Testen gern noch das Startskript ''catalina.sh'' in die Installation des Tomcat:

<syntaxhighlight lang="bash">
xyz00-login@h50:~$ cp /usr/share/tomcat9/bin/catalina.sh $HOME/tomcat9/bin/
xyz00-login@h50:~$ cd tomcat9/
xyz00-login@h50:~/tomcat9$ ./bin/catalina.sh run
Using CATALINA_BASE: /home/pacs/xyz00/users/login/tomcat9
Using CATALINA_HOME: /usr/share/tomcat9
Using CATALINA_TMPDIR: /home/pacs/xyz00/users/login/tomcat9/temp
Using JRE_HOME: /usr/lib/jvm/default-java
Using CLASSPATH: /usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar
<6>Server version name: Apache Tomcat/9.0.31 (Debian)
[...]
<6>Server startup in [75] milliseconds
</syntaxhighlight>

Tomcat läuft, abbrechen mit <Ctrl-C>

=== Konfiguration des Apache als Proxy ===

<syntaxhighlight lang="bash">
cd ~/doms/login.hs-example.de/
rm -rf subs/www subs-ssl/www
</syntaxhighlight>

Bearbeiten der ~/doms/login.hs-example.de/htdocs-ssl/.htaccess

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

Achtung: der Port 31531 ist wieder durch den Port des AJP-Listeners in der eigenen Tomcat-Konfiguration zu ersetzen.

=== CAS Basisinstallation ===

Auschecken des CAS Overlay Projektes (TODO: Warum nicht ```git checkout 6.6```? Typo?)

<syntaxhighlight lang="bash">
mkdir git
cd git
git clone https://github.com/apereo/cas-overlay-template.git
cd cas-overlay-template/
git fetch
git checkout 6.0
</syntaxhighlight>

Anlegen von Verzeichnissen für die spätere Konfiguration des CAS Server

<syntaxhighlight lang="bash">
cd
mkdir -p cas/conf
mkdir -p cas/services
</syntaxhighlight>

Ins Verzeichnis ''~/cas/conf'' legen wir eine Datei ''cas.properties'' mit folgendem Inhalt:

<syntaxhighlight lang="ini" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
</syntaxhighlight>

Die Datei ''log4j2.xml'' kopieren wir aus ''~/git/cas-overlay-template/etc/cas/config/''

<syntaxhighlight lang="bash">
cp ~/git/cas-overlay-template/etc/cas/config/ ~/cas/conf/
</syntaxhighlight>

In der log4j2.xml passen wir den Wert für die Variable ''baseDir'' (etwa Zeile 5) an:

<syntaxhighlight lang="xml">
<Property name="baseDir">/home/pacs/xyz00/users/login/tomcat9/logs</Property>
</syntaxhighlight>

Build und Deployment der Web-Applikation

<syntaxhighlight lang="bash">
./build.sh package
cd
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Nach einer erneuten Start des Tomcat ist das CAS-Login unter
https://login.hs-example.de/cas/ erreichbar.

Ein Login mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte erfolgreich sein.

== Erweiterte Konfiguration des CAS ==

Die Funktionalität des CAS Server ist modular erweiterbar. Im ersten Schritt erweitern wir den CAS um eine Service Registry. Für unsere einfache Standalone-Installation nutzen wir die JSON-File-Registry

=== JSON Service Registry ===

Erweiterungen werden in der Datei ''build.gradle'' im Abschnitt ''dependencies'' eingetragen. Die Datei liegt im Wurzelverzeichnis des Git-Repositories für unser CAS Overlay (''~/git/cas-overlay-template/'').

Der betreffende Ausschnitt der Datei:

<syntaxhighlight lang="java" line>
dependencies {
// [...] Teile ausgespart

/**
* CAS dependencies and modules may be listed here.
*
* There is no need to specify the version number for each dependency
* since versions are all resolved and controlled by the dependency management
* plugin via the CAS bom.
**/

// email notification, service registry
implementation "org.apereo.cas:cas-server-core-notifications"
implementation "org.apereo.cas:cas-server-support-json-service-registry"

// jdbc datasource
implementation "org.apereo.cas:cas-server-support-jdbc-drivers"
implementation "org.apereo.cas:cas-server-support-jdbc"

// password reset
implementation "org.apereo.cas:cas-server-support-pm-webflow"
implementation "org.apereo.cas:cas-server-support-pm-jdbc"

// openid-connect / oidc
implementation "org.apereo.cas:cas-server-support-oidc"

/**
* Do NOT modify the lines below or else you will risk breaking the build.
*/
implementation "org.apereo.cas:cas-server-core-api-configuration-model"
implementation "org.apereo.cas:cas-server-webapp-init"

// [...] Teile ausgespart
}
</syntaxhighlight>

Wir bauen das cas.war mit den folgenden Befehlen neu:

<syntaxhighlight lang="bash">
cd ~/git/cas-overlay-template
./build.sh package
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Der Pfad zur Service-Registry war in der oben erstellten ''cas.properties'' bereits enthalten.
Nun legen wir einen ersten Service an, in meinem Fall eine Nextcloud-Installation. Die Datei heißt
''hsexamplecloud-1000001.json'' und wird im Verzeichnis ''~/cas/services/'' abgelegt. Der Inhalt:

<syntaxhighlight lang="json" line>
{
"@class" : "org.apereo.cas.services.RegexRegisteredService",
"serviceId" : "^https://cloud.hs-example.de.*",
"name" : "hsexamplecloud",
"id" : 1000001,
"description" : "Nextcloud HS-Example",
"evaluationOrder" : 10000
}
</syntaxhighlight>

Der Name der Datei setzt sich aus Service-Name und Service-Id zusammen!

Die Konfiguration des CAS-Login in der Nextcloud erfolgt über die entsprechende "App" in Nextcloud.
Die Parameter sind wie folgt:

[[Datei:Cas-nextcloud-app.png]]

Die "Dienst-URL" im Screenshot ist: ''https://cloud.hs-example.de/index.php/apps/user_cas/login''

Die Anmeldung mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte nun von der Nextcloud-Loginseite über den Link zum CAS-Login möglich sein.

=== Authentifizierung gegen JDBC Datenbank ===

Wir erweitern wieder die Datei ''build.gradle'' im Abschnitt ''dependencies''.

<syntaxhighlight lang="java" line>
dependencies {
compile "org.apereo.cas:cas-server-webapp${project.appServer}:${casServerVersion}"
// Other CAS dependencies/modules may be listed here...
compile "org.apereo.cas:cas-server-support-json-service-registry:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc-drivers:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc:${project.'cas.version'}"
}
</syntaxhighlight>

''cas-server-support-jdbc-drivers'' liefert JDBC-Treiber für die gängigen Open-Source Datenbanksysteme. ''org.apereo.cas:cas-server-support-jdbc'' liefert das eigentliche CAS-Authentication Backend.

Zur Konfiguration wird die Datei ''cas.properties'' im Verzeichnis ''~/cas/conf/'' erweitert:

<syntaxhighlight lang="java" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
logging.level.org.apereo=DEBUG
cas.authn.jdbc.query[0].sql=SELECT * FROM USERS WHERE UID=?
cas.authn.jdbc.query[0].url=jdbc:postgresql://localhost/xyz00_cas
cas.authn.jdbc.query[0].dialect=org.hibernate.dialect.PostgreSQL92Dialect
cas.authn.jdbc.query[0].user=xyz00_cas
cas.authn.jdbc.query[0].password=Ein_schlechtes_Passwort
cas.authn.jdbc.query[0].driverClass=org.postgresql.Driver
cas.authn.jdbc.query[0].fieldPassword=PSW
cas.authn.jdbc.query[0].passwordEncoder.type=BCRYPT
cas.authn.jdbc.query[0].passwordEncoder.characterEncoding=UTF-8
cas.authn.accept.users=
</syntaxhighlight>

Hier ein Beispiel für eine PostgreSQL-Datenbank mit einer Tabelle ''USERS'' mit den Spalten ''UID'' und ''PSW''. Die Spalte ''UID'' enthält den Login-Namen des Users, die Spalte ''PSW'' das Passwort mit dem BCrypt-Algorithmus verschlüsselt.

Die Zeile ''cas.authn.accept.users='' deaktiviert das Default-Login als User ''casuser'' mit Passwort ''Mellon''.

Achtung: Das Spring-Security Framework erwartet das BCrypt-Passwort mit der Kennung ''$2a$'' als erste Zeichen des Passwortfeldes. Die PHP-Funktion ''password_hash'' schreibt ''$2y$'' Wenn eine PHP-Passwort-Datenbank genutzt wird, muss hier ggf. eine VIEW in der Datenbank helfen.

== Grafische Anpassung der CAS Login-Seiten ==

Die Anpassungen der Login-Seite und anderer Teile der Browser-Anwendung ist vorgesehen. Eine Anleitung findet sich unter Link [7] und [4].

== Links ==

[1] https://de.wikipedia.org/wiki/Central_Authentication_Service

[2] https://www.apereo.org/projects/cas

[3] https://github.com/apereo/cas-overlay-template

[4] https://dacurry-tns.github.io/deploying-apereo-cas/

[5] https://apereo.github.io/2017/02/22/cas51-dbauthn-tutorial/

[6] https://apereo.github.io/2017/02/02/cas51-authn-handlers/

[7] https://apereo.github.io/2018/06/10/cas-userinterface-customizations/

[8] https://apereo.github.io/tags/#CAS

[9] https://iam.uconn.edu/java-cas-client-installation-and-configuration/

[10] https://fawnoos.com/2022/08/06/cas66-gettingstarted-overlay/

[11] https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/cas Ansible Playbook

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

== Troubleshooting ==

=== CAS: Unterschiedliche Zeitstempel ===
Wenn wir das cas.war erneut bauen, wird Tomcat vermeintlich über unterschiedliche Zeitstempel meckern.

<syntaxhighlight lang="bash">
28-Aug-2024 15:30:32.976 INFO [main] org.apache.catalina.startup.ExpandWar.expand An expanded directory [/home/pacs/sib01/users/auth/tomcat/webapps/cas] was found with a last modified time that did not match the associated WAR. It will be deleted.
</syntaxhighlight>

In diesem Fall wird Tomcat den CAS-Dienst nur bedienen, wenn die alte Version komplett bereinigt ist.

<syntaxhighlight lang="bash">
cd ~/git/cas-overlay-template
./build.sh package
rm -rf ~/tomcat9/webapps/cas*
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Anschließend akzeptiert Tomcat das neue cas.war.

<syntaxhighlight lang="bash">
28-Aug-2024 15:50:34.904 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/home/pacs/sib01/users/auth/tomcat/webapps/cas.war]
</syntaxhighlight>

=== Tomcat: secretRequired="true" ===

Die Standard-Konfiguration der Datei ~/tomcat/conf/server.xml führt zu dieser Fehlermeldung.

<syntaxhighlight lang="bash">
cd ~/tomcat
./bin/catalina.sh run
...
The AJP Connector is configured with secretRequired="true" but the secret attribute is either null or "". This combination is not valid.
...
</syntaxhighlight>

Fazit: Ich habe

<syntaxhighlight lang="bash">
<Connector port="31531" protocol="AJP/1.3"
connectionTimeout="20000"
redirectPort="8443" secretRequired="false" />
</syntaxhighlight>

in dieser Konfiguration gesetzt. Damit überwinde ich den betreffenden Fehler. Solange der AJP-Listener ausschließlich auf eine Localhost-IP konfiguriert ist, sollte diese Konfiguration (insbesondere auf einem Managed-Server) akzeptabel sein. Dann ist der AJP-Listener von extern nicht erreichbar.

CAS Authentication Server

2024-08-28T13:54:08Z

Sib: add Troubleshooting section

CAS Authentication Server

2024-08-22T12:31:49Z

Sib: Typo: ```git checkout 6.0``` ?

CAS Authentication Server

2024-08-22T11:54:35Z

Sib: adjust instruction order for CAS base installation

= CAS Authentication Server =

Der CAS Server ("Central Authentication Service" oder "CAS Authentication Server") ist eine SSO- ("Single Sign On") Lösung.

CAS ist für große, verteilte Deployments von Web-Anwendungen geeignet. Er stammt aus dem Universitätsumfeld in den USA. Er wurde bei der Yale Universität entwickelt und wird aktuell bei JA-SIG / Apereo als freie Software unter der Apache Lizenz gepflegt. [1], [2]

Die Hostsharing eG nutzt CAS seit Jahren als Login-Lösung insbesondere für die Administrationswerkzeuge von [[Hsadmin|HSAdmin]].

Dieser Beitrag erläutert die Installation von CAS in einem Hostsharing Webspace und die Konfiguration von Beispielanwendungen zum Login mit CAS. Als Nutzerdatenbank wird ein vorhandener Nutzerstamm in einer SQL-Datenbank benutzt.

== Erste Installation ==

Die aktuelle stabile Version des CAS Server ist v6.6.7 (Stand August 2024: v7.0.6). Diese Version erfordert Java 11. Die empfohlene Installation eines Standalone-CAS erfolgt über das WAR Overlay Projekt [3]. Eine ausführliche Deployment-Anleitung (leider noch für Version 5.x) findet sich bei [https://www.newschool.edu/ The New School] [4]. Eine Anleitung für die aktuelle Version 6.6.x ist unter [10] verfügbar.

=== Service-User und Domain ===

Zunächst werden mit HSAdmin ein User und eine Domain eingerichtet. Darauf achten, dass der User eine gültige Login-Shell erhält, hier die Bash (''/bin/bash'').

<syntaxhighlight lang="bash">
xyz00@h50:~$ hsscript -i
xyz00@hsadmin> user.add({set:{name:'xyz00-login',shell:'/bin/bash',password:'***'}})
xyz00@hsadmin> domain.add({set:{user:'xyz00-login',name:'login.hs-example.de'}})
xyz00@hsadmin> bye
</syntaxhighlight>

=== Einrichtung des Tomcat ===

Für den Apache Tomcat Webserver ist die Option "Eigener Daemon" im [https://www.hostsharing.net/paas/managed-webspace/ Hostsharing Webspace] notwendig ( im [https://www.hostsharing.net/paas/managed-server/ Managed Server] nicht). Bei der Anmeldung (bei service(at)hostsharing.net bitte den Service User ''xyz00-login'' und die gewüschte Anzahl IP-Ports angeben). Hier verwenden wir die Ports 31530, 31531 und 31532.

Weiter geht es als User ''xyz00-login''

Einrichten eines Apache Tomcat 9 (Stand August 2024: [[Tomcat Installieren|Apache Tomcat 10]]) im Userspace:

<syntaxhighlight lang="output">
xyz00-login@h50:~$ tomcat9-instance-create tomcat9
You are about to create a Tomcat instance in directory 'tomcat9'
Warning: HTTP port 8080 appears to be in use.
Type <ENTER> to continue, <CTRL-C> to abort.
</syntaxhighlight>

Mit <Enter> bestätigen, dann wird eine Tomcat-Konfiguration im neuen Verzeichnis $HOME/tomcat9 angelegt.

Die ''server.xml'' im Verzeichnis $HOME/tomcat9/conf wird angepasst:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="31530" shutdown="SHUTDOWN">

<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>

<Service name="Catalina">
<Connector address="localhost" port="31531" protocol="AJP/1.3" redirectPort="443" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
</Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Insbesondere die beiden Angaben ''port="31530"'' und ''port="31531"'' müssen angepasst werden!

In der Datei ''setenv.sh'' im Verzeichnis $HOME/tomcat9/bin ergänzenen wir den Pfad zur Java 11 Installation als Variable $JAVA_HOME (für 32-Bit bzw. für 64-Bit Systeme), dazu den Pfad für eine Datei mit der Prozess-ID Prozess-Id und eine System-Property in den Java-Opts mit dem Verzeichnis-Pfad, in dem wir später die CAS-Konfiguration ablegen:

<syntaxhighlight lang="bash">
# export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-i386
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export JAVA_OPTS="-Djava.awt.headless=true -Dcas.standalone.configurationDirectory=/home/pacs/xyz00/users/login/cas/conf"
</syntaxhighlight>

Ich kopiere zum Testen gern noch das Startskript ''catalina.sh'' in die Installation des Tomcat:

<syntaxhighlight lang="bash">
xyz00-login@h50:~$ cp /usr/share/tomcat9/bin/catalina.sh $HOME/tomcat9/bin/
xyz00-login@h50:~$ cd tomcat9/
xyz00-login@h50:~/tomcat9$ ./bin/catalina.sh run
Using CATALINA_BASE: /home/pacs/xyz00/users/login/tomcat9
Using CATALINA_HOME: /usr/share/tomcat9
Using CATALINA_TMPDIR: /home/pacs/xyz00/users/login/tomcat9/temp
Using JRE_HOME: /usr/lib/jvm/default-java
Using CLASSPATH: /usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar
<6>Server version name: Apache Tomcat/9.0.31 (Debian)
[...]
<6>Server startup in [75] milliseconds
</syntaxhighlight>

Tomcat läuft, abbrechen mit <Ctrl-C>

=== Konfiguration des Apache als Proxy ===

<syntaxhighlight lang="bash">
cd ~/doms/login.hs-example.de/
rm -rf subs/www subs-ssl/www
</syntaxhighlight>

Bearbeiten der ~/doms/login.hs-example.de/htdocs-ssl/.htaccess

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

Achtung: der Port 31531 ist wieder durch den Port des AJP-Listeners in der eigenen Tomcat-Konfiguration zu ersetzen.

=== CAS Basisinstallation ===

Auschecken des CAS Overlay Projektes

<syntaxhighlight lang="bash">
mkdir git
cd git
git clone https://github.com/apereo/cas-overlay-template.git
cd cas-overlay-template/
git fetch
git checkout 6.0
</syntaxhighlight>

Anlegen von Verzeichnissen für die spätere Konfiguration des CAS Server

<syntaxhighlight lang="bash">
cd
mkdir -p cas/conf
mkdir -p cas/services
</syntaxhighlight>

Ins Verzeichnis ''~/cas/conf'' legen wir eine Datei ''cas.properties'' mit folgendem Inhalt:

<syntaxhighlight lang="ini" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
</syntaxhighlight>

Die Datei ''log4j2.xml'' kopieren wir aus ''~/git/cas-overlay-template/etc/cas/config/''

<syntaxhighlight lang="bash">
cp ~/git/cas-overlay-template/etc/cas/config/ ~/cas/conf/
</syntaxhighlight>

In der log4j2.xml passen wir den Wert für die Variable ''baseDir'' (etwa Zeile 5) an:

<syntaxhighlight lang="xml">
<Property name="baseDir">/home/pacs/xyz00/users/login/tomcat9/logs</Property>
</syntaxhighlight>

Build und Deployment der Web-Applikation

<syntaxhighlight lang="bash">
./build.sh package
cd
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Nach einer erneuten Start des Tomcat ist das CAS-Login unter
https://login.hs-example.de/cas/ erreichbar.

Ein Login mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte erfolgreich sein.

== Erweiterte Konfiguration des CAS ==

Die Funktionalität des CAS Server ist modular erweiterbar. Im ersten Schritt erweitern wir den CAS um eine Service Registry. Für unsere einfache Standalone-Installation nutzen wir die JSON-File-Registry

=== JSON Service Registry ===

Erweiterungen werden in der Datei ''build.gradle'' im Abschnitt ''dependencies'' eingetragen. Die Datei liegt im Wurzelverzeichnis des Git-Repositories für unser CAS Overlay (''~/git/cas-overlay-template/'').

Der betreffende Ausschnitt der Datei:

<syntaxhighlight lang="java" line>
dependencies {
// [...] Teile ausgespart

/**
* CAS dependencies and modules may be listed here.
*
* There is no need to specify the version number for each dependency
* since versions are all resolved and controlled by the dependency management
* plugin via the CAS bom.
**/

// email notification, service registry
implementation "org.apereo.cas:cas-server-core-notifications"
implementation "org.apereo.cas:cas-server-support-json-service-registry"

// jdbc datasource
implementation "org.apereo.cas:cas-server-support-jdbc-drivers"
implementation "org.apereo.cas:cas-server-support-jdbc"

// password reset
implementation "org.apereo.cas:cas-server-support-pm-webflow"
implementation "org.apereo.cas:cas-server-support-pm-jdbc"

// openid-connect / oidc
implementation "org.apereo.cas:cas-server-support-oidc"

/**
* Do NOT modify the lines below or else you will risk breaking the build.
*/
implementation "org.apereo.cas:cas-server-core-api-configuration-model"
implementation "org.apereo.cas:cas-server-webapp-init"

// [...] Teile ausgespart
}
</syntaxhighlight>

Wir bauen das cas.war mit den folgenden Befehlen neu:

<syntaxhighlight lang="bash">
cd ~/git/cas-overlay-template
./build.sh package
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Der Pfad zur Service-Registry war in der oben erstellten ''cas.properties'' bereits enthalten.
Nun legen wir einen ersten Service an, in meinem Fall eine Nextcloud-Installation. Die Datei heißt
''hsexamplecloud-1000001.json'' und wird im Verzeichnis ''~/cas/services/'' abgelegt. Der Inhalt:

<syntaxhighlight lang="json" line>
{
"@class" : "org.apereo.cas.services.RegexRegisteredService",
"serviceId" : "^https://cloud.hs-example.de.*",
"name" : "hsexamplecloud",
"id" : 1000001,
"description" : "Nextcloud HS-Example",
"evaluationOrder" : 10000
}
</syntaxhighlight>

Der Name der Datei setzt sich aus Service-Name und Service-Id zusammen!

Die Konfiguration des CAS-Login in der Nextcloud erfolgt über die entsprechende "App" in Nextcloud.
Die Parameter sind wie folgt:

[[Datei:Cas-nextcloud-app.png]]

Die "Dienst-URL" im Screenshot ist: ''https://cloud.hs-example.de/index.php/apps/user_cas/login''

Die Anmeldung mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte nun von der Nextcloud-Loginseite über den Link zum CAS-Login möglich sein.

=== Authentifizierung gegen JDBC Datenbank ===

Wir erweitern wieder die Datei ''build.gradle'' im Abschnitt ''dependencies''.

<syntaxhighlight lang="java" line>
dependencies {
compile "org.apereo.cas:cas-server-webapp${project.appServer}:${casServerVersion}"
// Other CAS dependencies/modules may be listed here...
compile "org.apereo.cas:cas-server-support-json-service-registry:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc-drivers:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc:${project.'cas.version'}"
}
</syntaxhighlight>

''cas-server-support-jdbc-drivers'' liefert JDBC-Treiber für die gängigen Open-Source Datenbanksysteme. ''org.apereo.cas:cas-server-support-jdbc'' liefert das eigentliche CAS-Authentication Backend.

Zur Konfiguration wird die Datei ''cas.properties'' im Verzeichnis ''~/cas/conf/'' erweitert:

<syntaxhighlight lang="java" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
logging.level.org.apereo=DEBUG
cas.authn.jdbc.query[0].sql=SELECT * FROM USERS WHERE UID=?
cas.authn.jdbc.query[0].url=jdbc:postgresql://localhost/xyz00_cas
cas.authn.jdbc.query[0].dialect=org.hibernate.dialect.PostgreSQL92Dialect
cas.authn.jdbc.query[0].user=xyz00_cas
cas.authn.jdbc.query[0].password=Ein_schlechtes_Passwort
cas.authn.jdbc.query[0].driverClass=org.postgresql.Driver
cas.authn.jdbc.query[0].fieldPassword=PSW
cas.authn.jdbc.query[0].passwordEncoder.type=BCRYPT
cas.authn.jdbc.query[0].passwordEncoder.characterEncoding=UTF-8
cas.authn.accept.users=
</syntaxhighlight>

Hier ein Beispiel für eine PostgreSQL-Datenbank mit einer Tabelle ''USERS'' mit den Spalten ''UID'' und ''PSW''. Die Spalte ''UID'' enthält den Login-Namen des Users, die Spalte ''PSW'' das Passwort mit dem BCrypt-Algorithmus verschlüsselt.

Die Zeile ''cas.authn.accept.users='' deaktiviert das Default-Login als User ''casuser'' mit Passwort ''Mellon''.

Achtung: Das Spring-Security Framework erwartet das BCrypt-Passwort mit der Kennung ''$2a$'' als erste Zeichen des Passwortfeldes. Die PHP-Funktion ''password_hash'' schreibt ''$2y$'' Wenn eine PHP-Passwort-Datenbank genutzt wird, muss hier ggf. eine VIEW in der Datenbank helfen.

== Grafische Anpassung der CAS Login-Seiten ==

Die Anpassungen der Login-Seite und anderer Teile der Browser-Anwendung ist vorgesehen. Eine Anleitung findet sich unter Link [7] und [4].

== Links ==

[1] https://de.wikipedia.org/wiki/Central_Authentication_Service

[2] https://www.apereo.org/projects/cas

[3] https://github.com/apereo/cas-overlay-template

[4] https://dacurry-tns.github.io/deploying-apereo-cas/

[5] https://apereo.github.io/2017/02/22/cas51-dbauthn-tutorial/

[6] https://apereo.github.io/2017/02/02/cas51-authn-handlers/

[7] https://apereo.github.io/2018/06/10/cas-userinterface-customizations/

[8] https://apereo.github.io/tags/#CAS

[9] https://iam.uconn.edu/java-cas-client-installation-and-configuration/

[10] https://fawnoos.com/2022/08/06/cas66-gettingstarted-overlay/

[11] https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/cas Ansible Playbook

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

CAS Authentication Server

2024-08-22T10:39:18Z

Sib: add link to Apache Tomcat 10

= CAS Authentication Server =

Der CAS Server ("Central Authentication Service" oder "CAS Authentication Server") ist eine SSO- ("Single Sign On") Lösung.

CAS ist für große, verteilte Deployments von Web-Anwendungen geeignet. Er stammt aus dem Universitätsumfeld in den USA. Er wurde bei der Yale Universität entwickelt und wird aktuell bei JA-SIG / Apereo als freie Software unter der Apache Lizenz gepflegt. [1], [2]

Die Hostsharing eG nutzt CAS seit Jahren als Login-Lösung insbesondere für die Administrationswerkzeuge von [[Hsadmin|HSAdmin]].

Dieser Beitrag erläutert die Installation von CAS in einem Hostsharing Webspace und die Konfiguration von Beispielanwendungen zum Login mit CAS. Als Nutzerdatenbank wird ein vorhandener Nutzerstamm in einer SQL-Datenbank benutzt.

== Erste Installation ==

Die aktuelle stabile Version des CAS Server ist v6.6.7 (Stand August 2024: v7.0.6). Diese Version erfordert Java 11. Die empfohlene Installation eines Standalone-CAS erfolgt über das WAR Overlay Projekt [3]. Eine ausführliche Deployment-Anleitung (leider noch für Version 5.x) findet sich bei [https://www.newschool.edu/ The New School] [4]. Eine Anleitung für die aktuelle Version 6.6.x ist unter [10] verfügbar.

=== Service-User und Domain ===

Zunächst werden mit HSAdmin ein User und eine Domain eingerichtet. Darauf achten, dass der User eine gültige Login-Shell erhält, hier die Bash (''/bin/bash'').

<syntaxhighlight lang="bash">
xyz00@h50:~$ hsscript -i
xyz00@hsadmin> user.add({set:{name:'xyz00-login',shell:'/bin/bash',password:'***'}})
xyz00@hsadmin> domain.add({set:{user:'xyz00-login',name:'login.hs-example.de'}})
xyz00@hsadmin> bye
</syntaxhighlight>

=== Einrichtung des Tomcat ===

Für den Apache Tomcat Webserver ist die Option "Eigener Daemon" im [https://www.hostsharing.net/paas/managed-webspace/ Hostsharing Webspace] notwendig ( im [https://www.hostsharing.net/paas/managed-server/ Managed Server] nicht). Bei der Anmeldung (bei service(at)hostsharing.net bitte den Service User ''xyz00-login'' und die gewüschte Anzahl IP-Ports angeben). Hier verwenden wir die Ports 31530, 31531 und 31532.

Weiter geht es als User ''xyz00-login''

Einrichten eines Apache Tomcat 9 (Stand August 2024: [[Tomcat Installieren|Apache Tomcat 10]]) im Userspace:

<syntaxhighlight lang="output">
xyz00-login@h50:~$ tomcat9-instance-create tomcat9
You are about to create a Tomcat instance in directory 'tomcat9'
Warning: HTTP port 8080 appears to be in use.
Type <ENTER> to continue, <CTRL-C> to abort.
</syntaxhighlight>

Mit <Enter> bestätigen, dann wird eine Tomcat-Konfiguration im neuen Verzeichnis $HOME/tomcat9 angelegt.

Die ''server.xml'' im Verzeichnis $HOME/tomcat9/conf wird angepasst:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="31530" shutdown="SHUTDOWN">

<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>

<Service name="Catalina">
<Connector address="localhost" port="31531" protocol="AJP/1.3" redirectPort="443" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
</Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Insbesondere die beiden Angaben ''port="31530"'' und ''port="31531"'' müssen angepasst werden!

In der Datei ''setenv.sh'' im Verzeichnis $HOME/tomcat9/bin ergänzenen wir den Pfad zur Java 11 Installation als Variable $JAVA_HOME (für 32-Bit bzw. für 64-Bit Systeme), dazu den Pfad für eine Datei mit der Prozess-ID Prozess-Id und eine System-Property in den Java-Opts mit dem Verzeichnis-Pfad, in dem wir später die CAS-Konfiguration ablegen:

<syntaxhighlight lang="bash">
# export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-i386
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export JAVA_OPTS="-Djava.awt.headless=true -Dcas.standalone.configurationDirectory=/home/pacs/xyz00/users/login/cas/conf"
</syntaxhighlight>

Ich kopiere zum Testen gern noch das Startskript ''catalina.sh'' in die Installation des Tomcat:

<syntaxhighlight lang="bash">
xyz00-login@h50:~$ cp /usr/share/tomcat9/bin/catalina.sh $HOME/tomcat9/bin/
xyz00-login@h50:~$ cd tomcat9/
xyz00-login@h50:~/tomcat9$ ./bin/catalina.sh run
Using CATALINA_BASE: /home/pacs/xyz00/users/login/tomcat9
Using CATALINA_HOME: /usr/share/tomcat9
Using CATALINA_TMPDIR: /home/pacs/xyz00/users/login/tomcat9/temp
Using JRE_HOME: /usr/lib/jvm/default-java
Using CLASSPATH: /usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar
<6>Server version name: Apache Tomcat/9.0.31 (Debian)
[...]
<6>Server startup in [75] milliseconds
</syntaxhighlight>

Tomcat läuft, abbrechen mit <Ctrl-C>

=== Konfiguration des Apache als Proxy ===

<syntaxhighlight lang="bash">
cd ~/doms/login.hs-example.de/
rm -rf subs/www subs-ssl/www
</syntaxhighlight>

Bearbeiten der ~/doms/login.hs-example.de/htdocs-ssl/.htaccess

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

Achtung: der Port 31531 ist wieder durch den Port des AJP-Listeners in der eigenen Tomcat-Konfiguration zu ersetzen.

=== CAS Basisinstallation ===

Anlegen von Verzeichnissen für die spätere Konfiguration des CAS Server

<syntaxhighlight lang="bash">
cd
mkdir -p cas/conf
mkdir -p cas/services
</syntaxhighlight>

Ins Verzeichnis ''~/cas/conf'' legen wir eine Datei ''cas.properties'' mit folgendem Inhalt:

<syntaxhighlight lang="ini" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
</syntaxhighlight>

Die Datei ''log4j2.xml'' kopieren wir aus ''~/git/cas-overlay-template/etc/cas/config/''

<syntaxhighlight lang="bash">
cp ~/git/cas-overlay-template/etc/cas/config/ ~/cas/conf/
</syntaxhighlight>

In der log4j2.xml passen wir den Wert für die Variable ''baseDir'' (etwa Zeile 5) an:

<syntaxhighlight lang="xml">
<Property name="baseDir">/home/pacs/xyz00/users/login/tomcat9/logs</Property>
</syntaxhighlight>

Auschecken des CAS Overlay Projektes

<syntaxhighlight lang="bash">
mkdir git
cd git
git clone https://github.com/apereo/cas-overlay-template.git
cd cas-overlay-template/
git fetch
git checkout 6.0
</syntaxhighlight>

Build und Deployment der Web-Applikation

<syntaxhighlight lang="bash">
./build.sh package
cd
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Nach einer erneuten Start des Tomcat ist das CAS-Login unter
https://login.hs-example.de/cas/ erreichbar.

Ein Login mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte erfolgreich sein.

== Erweiterte Konfiguration des CAS ==

Die Funktionalität des CAS Server ist modular erweiterbar. Im ersten Schritt erweitern wir den CAS um eine Service Registry. Für unsere einfache Standalone-Installation nutzen wir die JSON-File-Registry

=== JSON Service Registry ===

Erweiterungen werden in der Datei ''build.gradle'' im Abschnitt ''dependencies'' eingetragen. Die Datei liegt im Wurzelverzeichnis des Git-Repositories für unser CAS Overlay (''~/git/cas-overlay-template/'').

Der betreffende Ausschnitt der Datei:

<syntaxhighlight lang="java" line>
dependencies {
// [...] Teile ausgespart

/**
* CAS dependencies and modules may be listed here.
*
* There is no need to specify the version number for each dependency
* since versions are all resolved and controlled by the dependency management
* plugin via the CAS bom.
**/

// email notification, service registry
implementation "org.apereo.cas:cas-server-core-notifications"
implementation "org.apereo.cas:cas-server-support-json-service-registry"

// jdbc datasource
implementation "org.apereo.cas:cas-server-support-jdbc-drivers"
implementation "org.apereo.cas:cas-server-support-jdbc"

// password reset
implementation "org.apereo.cas:cas-server-support-pm-webflow"
implementation "org.apereo.cas:cas-server-support-pm-jdbc"

// openid-connect / oidc
implementation "org.apereo.cas:cas-server-support-oidc"

/**
* Do NOT modify the lines below or else you will risk breaking the build.
*/
implementation "org.apereo.cas:cas-server-core-api-configuration-model"
implementation "org.apereo.cas:cas-server-webapp-init"

// [...] Teile ausgespart
}
</syntaxhighlight>

Wir bauen das cas.war mit den folgenden Befehlen neu:

<syntaxhighlight lang="bash">
cd ~/git/cas-overlay-template
./build.sh package
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Der Pfad zur Service-Registry war in der oben erstellten ''cas.properties'' bereits enthalten.
Nun legen wir einen ersten Service an, in meinem Fall eine Nextcloud-Installation. Die Datei heißt
''hsexamplecloud-1000001.json'' und wird im Verzeichnis ''~/cas/services/'' abgelegt. Der Inhalt:

<syntaxhighlight lang="json" line>
{
"@class" : "org.apereo.cas.services.RegexRegisteredService",
"serviceId" : "^https://cloud.hs-example.de.*",
"name" : "hsexamplecloud",
"id" : 1000001,
"description" : "Nextcloud HS-Example",
"evaluationOrder" : 10000
}
</syntaxhighlight>

Der Name der Datei setzt sich aus Service-Name und Service-Id zusammen!

Die Konfiguration des CAS-Login in der Nextcloud erfolgt über die entsprechende "App" in Nextcloud.
Die Parameter sind wie folgt:

[[Datei:Cas-nextcloud-app.png]]

Die "Dienst-URL" im Screenshot ist: ''https://cloud.hs-example.de/index.php/apps/user_cas/login''

Die Anmeldung mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte nun von der Nextcloud-Loginseite über den Link zum CAS-Login möglich sein.

=== Authentifizierung gegen JDBC Datenbank ===

Wir erweitern wieder die Datei ''build.gradle'' im Abschnitt ''dependencies''.

<syntaxhighlight lang="java" line>
dependencies {
compile "org.apereo.cas:cas-server-webapp${project.appServer}:${casServerVersion}"
// Other CAS dependencies/modules may be listed here...
compile "org.apereo.cas:cas-server-support-json-service-registry:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc-drivers:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc:${project.'cas.version'}"
}
</syntaxhighlight>

''cas-server-support-jdbc-drivers'' liefert JDBC-Treiber für die gängigen Open-Source Datenbanksysteme. ''org.apereo.cas:cas-server-support-jdbc'' liefert das eigentliche CAS-Authentication Backend.

Zur Konfiguration wird die Datei ''cas.properties'' im Verzeichnis ''~/cas/conf/'' erweitert:

<syntaxhighlight lang="java" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
logging.level.org.apereo=DEBUG
cas.authn.jdbc.query[0].sql=SELECT * FROM USERS WHERE UID=?
cas.authn.jdbc.query[0].url=jdbc:postgresql://localhost/xyz00_cas
cas.authn.jdbc.query[0].dialect=org.hibernate.dialect.PostgreSQL92Dialect
cas.authn.jdbc.query[0].user=xyz00_cas
cas.authn.jdbc.query[0].password=Ein_schlechtes_Passwort
cas.authn.jdbc.query[0].driverClass=org.postgresql.Driver
cas.authn.jdbc.query[0].fieldPassword=PSW
cas.authn.jdbc.query[0].passwordEncoder.type=BCRYPT
cas.authn.jdbc.query[0].passwordEncoder.characterEncoding=UTF-8
cas.authn.accept.users=
</syntaxhighlight>

Hier ein Beispiel für eine PostgreSQL-Datenbank mit einer Tabelle ''USERS'' mit den Spalten ''UID'' und ''PSW''. Die Spalte ''UID'' enthält den Login-Namen des Users, die Spalte ''PSW'' das Passwort mit dem BCrypt-Algorithmus verschlüsselt.

Die Zeile ''cas.authn.accept.users='' deaktiviert das Default-Login als User ''casuser'' mit Passwort ''Mellon''.

Achtung: Das Spring-Security Framework erwartet das BCrypt-Passwort mit der Kennung ''$2a$'' als erste Zeichen des Passwortfeldes. Die PHP-Funktion ''password_hash'' schreibt ''$2y$'' Wenn eine PHP-Passwort-Datenbank genutzt wird, muss hier ggf. eine VIEW in der Datenbank helfen.

== Grafische Anpassung der CAS Login-Seiten ==

Die Anpassungen der Login-Seite und anderer Teile der Browser-Anwendung ist vorgesehen. Eine Anleitung findet sich unter Link [7] und [4].

== Links ==

[1] https://de.wikipedia.org/wiki/Central_Authentication_Service

[2] https://www.apereo.org/projects/cas

[3] https://github.com/apereo/cas-overlay-template

[4] https://dacurry-tns.github.io/deploying-apereo-cas/

[5] https://apereo.github.io/2017/02/22/cas51-dbauthn-tutorial/

[6] https://apereo.github.io/2017/02/02/cas51-authn-handlers/

[7] https://apereo.github.io/2018/06/10/cas-userinterface-customizations/

[8] https://apereo.github.io/tags/#CAS

[9] https://iam.uconn.edu/java-cas-client-installation-and-configuration/

[10] https://fawnoos.com/2022/08/06/cas66-gettingstarted-overlay/

[11] https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/cas Ansible Playbook

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

CAS Authentication Server

2024-08-22T10:26:24Z

Sib: Unterscheidung Webspace/Managed Server fuer Tomcat eingefuegt

= CAS Authentication Server =

Der CAS Server ("Central Authentication Service" oder "CAS Authentication Server") ist eine SSO- ("Single Sign On") Lösung.

CAS ist für große, verteilte Deployments von Web-Anwendungen geeignet. Er stammt aus dem Universitätsumfeld in den USA. Er wurde bei der Yale Universität entwickelt und wird aktuell bei JA-SIG / Apereo als freie Software unter der Apache Lizenz gepflegt. [1], [2]

Die Hostsharing eG nutzt CAS seit Jahren als Login-Lösung insbesondere für die Administrationswerkzeuge von [[Hsadmin|HSAdmin]].

Dieser Beitrag erläutert die Installation von CAS in einem Hostsharing Webspace und die Konfiguration von Beispielanwendungen zum Login mit CAS. Als Nutzerdatenbank wird ein vorhandener Nutzerstamm in einer SQL-Datenbank benutzt.

== Erste Installation ==

Die aktuelle stabile Version des CAS Server ist v6.6.7 (Stand August 2024: v7.0.6). Diese Version erfordert Java 11. Die empfohlene Installation eines Standalone-CAS erfolgt über das WAR Overlay Projekt [3]. Eine ausführliche Deployment-Anleitung (leider noch für Version 5.x) findet sich bei [https://www.newschool.edu/ The New School] [4]. Eine Anleitung für die aktuelle Version 6.6.x ist unter [10] verfügbar.

=== Service-User und Domain ===

Zunächst werden mit HSAdmin ein User und eine Domain eingerichtet. Darauf achten, dass der User eine gültige Login-Shell erhält, hier die Bash (''/bin/bash'').

<syntaxhighlight lang="bash">
xyz00@h50:~$ hsscript -i
xyz00@hsadmin> user.add({set:{name:'xyz00-login',shell:'/bin/bash',password:'***'}})
xyz00@hsadmin> domain.add({set:{user:'xyz00-login',name:'login.hs-example.de'}})
xyz00@hsadmin> bye
</syntaxhighlight>

=== Einrichtung des Tomcat ===

Für den Apache Tomcat Webserver ist die Option "Eigener Daemon" im [https://www.hostsharing.net/paas/managed-webspace/ Hostsharing Webspace] notwendig ( im [https://www.hostsharing.net/paas/managed-server/ Managed Server] nicht). Bei der Anmeldung (bei service(at)hostsharing.net bitte den Service User ''xyz00-login'' und die gewüschte Anzahl IP-Ports angeben). Hier verwenden wir die Ports 31530, 31531 und 31532.

Weiter geht es als User ''xyz00-login''

Einrichten eines Apache Tomcat 9 im Userspace:

<syntaxhighlight lang="output">
xyz00-login@h50:~$ tomcat9-instance-create tomcat9
You are about to create a Tomcat instance in directory 'tomcat9'
Warning: HTTP port 8080 appears to be in use.
Type <ENTER> to continue, <CTRL-C> to abort.
</syntaxhighlight>

Mit <Enter> bestätigen, dann wird eine Tomcat-Konfiguration im neuen Verzeichnis $HOME/tomcat9 angelegt.

Die ''server.xml'' im Verzeichnis $HOME/tomcat9/conf wird angepasst:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="31530" shutdown="SHUTDOWN">

<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>

<Service name="Catalina">
<Connector address="localhost" port="31531" protocol="AJP/1.3" redirectPort="443" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
</Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Insbesondere die beiden Angaben ''port="31530"'' und ''port="31531"'' müssen angepasst werden!

In der Datei ''setenv.sh'' im Verzeichnis $HOME/tomcat9/bin ergänzenen wir den Pfad zur Java 11 Installation als Variable $JAVA_HOME (für 32-Bit bzw. für 64-Bit Systeme), dazu den Pfad für eine Datei mit der Prozess-ID Prozess-Id und eine System-Property in den Java-Opts mit dem Verzeichnis-Pfad, in dem wir später die CAS-Konfiguration ablegen:

<syntaxhighlight lang="bash">
# export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-i386
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export JAVA_OPTS="-Djava.awt.headless=true -Dcas.standalone.configurationDirectory=/home/pacs/xyz00/users/login/cas/conf"
</syntaxhighlight>

Ich kopiere zum Testen gern noch das Startskript ''catalina.sh'' in die Installation des Tomcat:

<syntaxhighlight lang="bash">
xyz00-login@h50:~$ cp /usr/share/tomcat9/bin/catalina.sh $HOME/tomcat9/bin/
xyz00-login@h50:~$ cd tomcat9/
xyz00-login@h50:~/tomcat9$ ./bin/catalina.sh run
Using CATALINA_BASE: /home/pacs/xyz00/users/login/tomcat9
Using CATALINA_HOME: /usr/share/tomcat9
Using CATALINA_TMPDIR: /home/pacs/xyz00/users/login/tomcat9/temp
Using JRE_HOME: /usr/lib/jvm/default-java
Using CLASSPATH: /usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar
<6>Server version name: Apache Tomcat/9.0.31 (Debian)
[...]
<6>Server startup in [75] milliseconds
</syntaxhighlight>

Tomcat läuft, abbrechen mit <Ctrl-C>

=== Konfiguration des Apache als Proxy ===

<syntaxhighlight lang="bash">
cd ~/doms/login.hs-example.de/
rm -rf subs/www subs-ssl/www
</syntaxhighlight>

Bearbeiten der ~/doms/login.hs-example.de/htdocs-ssl/.htaccess

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

Achtung: der Port 31531 ist wieder durch den Port des AJP-Listeners in der eigenen Tomcat-Konfiguration zu ersetzen.

=== CAS Basisinstallation ===

Anlegen von Verzeichnissen für die spätere Konfiguration des CAS Server

<syntaxhighlight lang="bash">
cd
mkdir -p cas/conf
mkdir -p cas/services
</syntaxhighlight>

Ins Verzeichnis ''~/cas/conf'' legen wir eine Datei ''cas.properties'' mit folgendem Inhalt:

<syntaxhighlight lang="ini" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
</syntaxhighlight>

Die Datei ''log4j2.xml'' kopieren wir aus ''~/git/cas-overlay-template/etc/cas/config/''

<syntaxhighlight lang="bash">
cp ~/git/cas-overlay-template/etc/cas/config/ ~/cas/conf/
</syntaxhighlight>

In der log4j2.xml passen wir den Wert für die Variable ''baseDir'' (etwa Zeile 5) an:

<syntaxhighlight lang="xml">
<Property name="baseDir">/home/pacs/xyz00/users/login/tomcat9/logs</Property>
</syntaxhighlight>

Auschecken des CAS Overlay Projektes

<syntaxhighlight lang="bash">
mkdir git
cd git
git clone https://github.com/apereo/cas-overlay-template.git
cd cas-overlay-template/
git fetch
git checkout 6.0
</syntaxhighlight>

Build und Deployment der Web-Applikation

<syntaxhighlight lang="bash">
./build.sh package
cd
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Nach einer erneuten Start des Tomcat ist das CAS-Login unter
https://login.hs-example.de/cas/ erreichbar.

Ein Login mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte erfolgreich sein.

== Erweiterte Konfiguration des CAS ==

Die Funktionalität des CAS Server ist modular erweiterbar. Im ersten Schritt erweitern wir den CAS um eine Service Registry. Für unsere einfache Standalone-Installation nutzen wir die JSON-File-Registry

=== JSON Service Registry ===

Erweiterungen werden in der Datei ''build.gradle'' im Abschnitt ''dependencies'' eingetragen. Die Datei liegt im Wurzelverzeichnis des Git-Repositories für unser CAS Overlay (''~/git/cas-overlay-template/'').

Der betreffende Ausschnitt der Datei:

<syntaxhighlight lang="java" line>
dependencies {
// [...] Teile ausgespart

/**
* CAS dependencies and modules may be listed here.
*
* There is no need to specify the version number for each dependency
* since versions are all resolved and controlled by the dependency management
* plugin via the CAS bom.
**/

// email notification, service registry
implementation "org.apereo.cas:cas-server-core-notifications"
implementation "org.apereo.cas:cas-server-support-json-service-registry"

// jdbc datasource
implementation "org.apereo.cas:cas-server-support-jdbc-drivers"
implementation "org.apereo.cas:cas-server-support-jdbc"

// password reset
implementation "org.apereo.cas:cas-server-support-pm-webflow"
implementation "org.apereo.cas:cas-server-support-pm-jdbc"

// openid-connect / oidc
implementation "org.apereo.cas:cas-server-support-oidc"

/**
* Do NOT modify the lines below or else you will risk breaking the build.
*/
implementation "org.apereo.cas:cas-server-core-api-configuration-model"
implementation "org.apereo.cas:cas-server-webapp-init"

// [...] Teile ausgespart
}
</syntaxhighlight>

Wir bauen das cas.war mit den folgenden Befehlen neu:

<syntaxhighlight lang="bash">
cd ~/git/cas-overlay-template
./build.sh package
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Der Pfad zur Service-Registry war in der oben erstellten ''cas.properties'' bereits enthalten.
Nun legen wir einen ersten Service an, in meinem Fall eine Nextcloud-Installation. Die Datei heißt
''hsexamplecloud-1000001.json'' und wird im Verzeichnis ''~/cas/services/'' abgelegt. Der Inhalt:

<syntaxhighlight lang="json" line>
{
"@class" : "org.apereo.cas.services.RegexRegisteredService",
"serviceId" : "^https://cloud.hs-example.de.*",
"name" : "hsexamplecloud",
"id" : 1000001,
"description" : "Nextcloud HS-Example",
"evaluationOrder" : 10000
}
</syntaxhighlight>

Der Name der Datei setzt sich aus Service-Name und Service-Id zusammen!

Die Konfiguration des CAS-Login in der Nextcloud erfolgt über die entsprechende "App" in Nextcloud.
Die Parameter sind wie folgt:

[[Datei:Cas-nextcloud-app.png]]

Die "Dienst-URL" im Screenshot ist: ''https://cloud.hs-example.de/index.php/apps/user_cas/login''

Die Anmeldung mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte nun von der Nextcloud-Loginseite über den Link zum CAS-Login möglich sein.

=== Authentifizierung gegen JDBC Datenbank ===

Wir erweitern wieder die Datei ''build.gradle'' im Abschnitt ''dependencies''.

<syntaxhighlight lang="java" line>
dependencies {
compile "org.apereo.cas:cas-server-webapp${project.appServer}:${casServerVersion}"
// Other CAS dependencies/modules may be listed here...
compile "org.apereo.cas:cas-server-support-json-service-registry:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc-drivers:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc:${project.'cas.version'}"
}
</syntaxhighlight>

''cas-server-support-jdbc-drivers'' liefert JDBC-Treiber für die gängigen Open-Source Datenbanksysteme. ''org.apereo.cas:cas-server-support-jdbc'' liefert das eigentliche CAS-Authentication Backend.

Zur Konfiguration wird die Datei ''cas.properties'' im Verzeichnis ''~/cas/conf/'' erweitert:

<syntaxhighlight lang="java" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
logging.level.org.apereo=DEBUG
cas.authn.jdbc.query[0].sql=SELECT * FROM USERS WHERE UID=?
cas.authn.jdbc.query[0].url=jdbc:postgresql://localhost/xyz00_cas
cas.authn.jdbc.query[0].dialect=org.hibernate.dialect.PostgreSQL92Dialect
cas.authn.jdbc.query[0].user=xyz00_cas
cas.authn.jdbc.query[0].password=Ein_schlechtes_Passwort
cas.authn.jdbc.query[0].driverClass=org.postgresql.Driver
cas.authn.jdbc.query[0].fieldPassword=PSW
cas.authn.jdbc.query[0].passwordEncoder.type=BCRYPT
cas.authn.jdbc.query[0].passwordEncoder.characterEncoding=UTF-8
cas.authn.accept.users=
</syntaxhighlight>

Hier ein Beispiel für eine PostgreSQL-Datenbank mit einer Tabelle ''USERS'' mit den Spalten ''UID'' und ''PSW''. Die Spalte ''UID'' enthält den Login-Namen des Users, die Spalte ''PSW'' das Passwort mit dem BCrypt-Algorithmus verschlüsselt.

Die Zeile ''cas.authn.accept.users='' deaktiviert das Default-Login als User ''casuser'' mit Passwort ''Mellon''.

Achtung: Das Spring-Security Framework erwartet das BCrypt-Passwort mit der Kennung ''$2a$'' als erste Zeichen des Passwortfeldes. Die PHP-Funktion ''password_hash'' schreibt ''$2y$'' Wenn eine PHP-Passwort-Datenbank genutzt wird, muss hier ggf. eine VIEW in der Datenbank helfen.

== Grafische Anpassung der CAS Login-Seiten ==

Die Anpassungen der Login-Seite und anderer Teile der Browser-Anwendung ist vorgesehen. Eine Anleitung findet sich unter Link [7] und [4].

== Links ==

[1] https://de.wikipedia.org/wiki/Central_Authentication_Service

[2] https://www.apereo.org/projects/cas

[3] https://github.com/apereo/cas-overlay-template

[4] https://dacurry-tns.github.io/deploying-apereo-cas/

[5] https://apereo.github.io/2017/02/22/cas51-dbauthn-tutorial/

[6] https://apereo.github.io/2017/02/02/cas51-authn-handlers/

[7] https://apereo.github.io/2018/06/10/cas-userinterface-customizations/

[8] https://apereo.github.io/tags/#CAS

[9] https://iam.uconn.edu/java-cas-client-installation-and-configuration/

[10] https://fawnoos.com/2022/08/06/cas66-gettingstarted-overlay/

[11] https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/cas Ansible Playbook

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

CAS Authentication Server

2024-08-22T10:05:29Z

Sib: fixing typos

= CAS Authentication Server =

Der CAS Server ("Central Authentication Service" oder "CAS Authentication Server") ist eine SSO- ("Single Sign On") Lösung.

CAS ist für große, verteilte Deployments von Web-Anwendungen geeignet. Er stammt aus dem Universitätsumfeld in den USA. Er wurde bei der Yale Universität entwickelt und wird aktuell bei JA-SIG / Apereo als freie Software unter der Apache Lizenz gepflegt. [1], [2]

Die Hostsharing eG nutzt CAS seit Jahren als Login-Lösung insbesondere für die Administrationswerkzeuge von [[Hsadmin|HSAdmin]].

Dieser Beitrag erläutert die Installation von CAS in einem Hostsharing Webspace und die Konfiguration von Beispielanwendungen zum Login mit CAS. Als Nutzerdatenbank wird ein vorhandener Nutzerstamm in einer SQL-Datenbank benutzt.

== Erste Installation ==

Die aktuelle stabile Version des CAS Server ist v6.6.7 (Stand August 2024: v7.0.6). Diese Version erfordert Java 11. Die empfohlene Installation eines Standalone-CAS erfolgt über das WAR Overlay Projekt [3]. Eine ausführliche Deployment-Anleitung (leider noch für Version 5.x) findet sich bei [https://www.newschool.edu/ The New School] [4]. Eine Anleitung für die aktuelle Version 6.6.x ist unter [10] verfügbar.

=== Service-User und Domain ===

Zunächst werden mit HSAdmin ein User und eine Domain eingerichtet. Darauf achten, dass der User eine gültige Login-Shell erhält, hier die Bash (''/bin/bash'').

<syntaxhighlight lang="bash">
xyz00@h50:~$ hsscript -i
xyz00@hsadmin> user.add({set:{name:'xyz00-login',shell:'/bin/bash',password:'***'}})
xyz00@hsadmin> domain.add({set:{user:'xyz00-login',name:'login.hs-example.de'}})
xyz00@hsadmin> bye
</syntaxhighlight>

=== Einrichtung des Tomcat ===

Für den Apache Tomcat Webserver ist die Option "Eigener Daemon" notwendig. Bei der Anmeldung (bei service(at)hostsharing.net bitte den Service User ''xyz00-login'' und die gewüschte Anzahl IP-Ports angeben). Hier verwenden wir die Ports 31530, 31531 und 31532.

Weiter geht es als User ''xyz00-login''

Einrichten eines Apache Tomcat 9 im Userspace:

<syntaxhighlight lang="output">
xyz00-login@h50:~$ tomcat9-instance-create tomcat9
You are about to create a Tomcat instance in directory 'tomcat9'
Warning: HTTP port 8080 appears to be in use.
Type <ENTER> to continue, <CTRL-C> to abort.
</syntaxhighlight>

Mit <Enter> bestätigen, dann wird eine Tomcat-Konfiguration im neuen Verzeichnis $HOME/tomcat9 angelegt.

Die ''server.xml'' im Verzeichnis $HOME/tomcat9/conf wird angepasst:

<syntaxhighlight lang="xml" line>
<?xml version="1.0" encoding="UTF-8"?>
<Server port="31530" shutdown="SHUTDOWN">

<Listener className="org.apache.catalina.startup.VersionLoggerListener" />
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

<GlobalNamingResources>
<Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase"
description="User database that can be updated and saved"
factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
pathname="conf/tomcat-users.xml" />
</GlobalNamingResources>

<Service name="Catalina">
<Connector address="localhost" port="31531" protocol="AJP/1.3" redirectPort="443" />
<Engine name="Catalina" defaultHost="localhost">
<Realm className="org.apache.catalina.realm.LockOutRealm">
<Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/>
</Realm>
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">
</Host>
</Engine>
</Service>
</Server>
</syntaxhighlight>

Insbesondere die beiden Angaben ''port="31530"'' und ''port="31531"'' müssen angepasst werden!

In der Datei ''setenv.sh'' im Verzeichnis $HOME/tomcat9/bin ergänzenen wir den Pfad zur Java 11 Installation als Variable $JAVA_HOME (für 32-Bit bzw. für 64-Bit Systeme), dazu den Pfad für eine Datei mit der Prozess-ID Prozess-Id und eine System-Property in den Java-Opts mit dem Verzeichnis-Pfad, in dem wir später die CAS-Konfiguration ablegen:

<syntaxhighlight lang="bash">
# export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-i386
export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export JAVA_OPTS="-Djava.awt.headless=true -Dcas.standalone.configurationDirectory=/home/pacs/xyz00/users/login/cas/conf"
</syntaxhighlight>

Ich kopiere zum Testen gern noch das Startskript ''catalina.sh'' in die Installation des Tomcat:

<syntaxhighlight lang="bash">
xyz00-login@h50:~$ cp /usr/share/tomcat9/bin/catalina.sh $HOME/tomcat9/bin/
xyz00-login@h50:~$ cd tomcat9/
xyz00-login@h50:~/tomcat9$ ./bin/catalina.sh run
Using CATALINA_BASE: /home/pacs/xyz00/users/login/tomcat9
Using CATALINA_HOME: /usr/share/tomcat9
Using CATALINA_TMPDIR: /home/pacs/xyz00/users/login/tomcat9/temp
Using JRE_HOME: /usr/lib/jvm/default-java
Using CLASSPATH: /usr/share/tomcat9/bin/bootstrap.jar:/usr/share/tomcat9/bin/tomcat-juli.jar
<6>Server version name: Apache Tomcat/9.0.31 (Debian)
[...]
<6>Server startup in [75] milliseconds
</syntaxhighlight>

Tomcat läuft, abbrechen mit <Ctrl-C>

=== Konfiguration des Apache als Proxy ===

<syntaxhighlight lang="bash">
cd ~/doms/login.hs-example.de/
rm -rf subs/www subs-ssl/www
</syntaxhighlight>

Bearbeiten der ~/doms/login.hs-example.de/htdocs-ssl/.htaccess

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

Achtung: der Port 31531 ist wieder durch den Port des AJP-Listeners in der eigenen Tomcat-Konfiguration zu ersetzen.

=== CAS Basisinstallation ===

Anlegen von Verzeichnissen für die spätere Konfiguration des CAS Server

<syntaxhighlight lang="bash">
cd
mkdir -p cas/conf
mkdir -p cas/services
</syntaxhighlight>

Ins Verzeichnis ''~/cas/conf'' legen wir eine Datei ''cas.properties'' mit folgendem Inhalt:

<syntaxhighlight lang="ini" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
</syntaxhighlight>

Die Datei ''log4j2.xml'' kopieren wir aus ''~/git/cas-overlay-template/etc/cas/config/''

<syntaxhighlight lang="bash">
cp ~/git/cas-overlay-template/etc/cas/config/ ~/cas/conf/
</syntaxhighlight>

In der log4j2.xml passen wir den Wert für die Variable ''baseDir'' (etwa Zeile 5) an:

<syntaxhighlight lang="xml">
<Property name="baseDir">/home/pacs/xyz00/users/login/tomcat9/logs</Property>
</syntaxhighlight>

Auschecken des CAS Overlay Projektes

<syntaxhighlight lang="bash">
mkdir git
cd git
git clone https://github.com/apereo/cas-overlay-template.git
cd cas-overlay-template/
git fetch
git checkout 6.0
</syntaxhighlight>

Build und Deployment der Web-Applikation

<syntaxhighlight lang="bash">
./build.sh package
cd
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Nach einer erneuten Start des Tomcat ist das CAS-Login unter
https://login.hs-example.de/cas/ erreichbar.

Ein Login mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte erfolgreich sein.

== Erweiterte Konfiguration des CAS ==

Die Funktionalität des CAS Server ist modular erweiterbar. Im ersten Schritt erweitern wir den CAS um eine Service Registry. Für unsere einfache Standalone-Installation nutzen wir die JSON-File-Registry

=== JSON Service Registry ===

Erweiterungen werden in der Datei ''build.gradle'' im Abschnitt ''dependencies'' eingetragen. Die Datei liegt im Wurzelverzeichnis des Git-Repositories für unser CAS Overlay (''~/git/cas-overlay-template/'').

Der betreffende Ausschnitt der Datei:

<syntaxhighlight lang="java" line>
dependencies {
// [...] Teile ausgespart

/**
* CAS dependencies and modules may be listed here.
*
* There is no need to specify the version number for each dependency
* since versions are all resolved and controlled by the dependency management
* plugin via the CAS bom.
**/

// email notification, service registry
implementation "org.apereo.cas:cas-server-core-notifications"
implementation "org.apereo.cas:cas-server-support-json-service-registry"

// jdbc datasource
implementation "org.apereo.cas:cas-server-support-jdbc-drivers"
implementation "org.apereo.cas:cas-server-support-jdbc"

// password reset
implementation "org.apereo.cas:cas-server-support-pm-webflow"
implementation "org.apereo.cas:cas-server-support-pm-jdbc"

// openid-connect / oidc
implementation "org.apereo.cas:cas-server-support-oidc"

/**
* Do NOT modify the lines below or else you will risk breaking the build.
*/
implementation "org.apereo.cas:cas-server-core-api-configuration-model"
implementation "org.apereo.cas:cas-server-webapp-init"

// [...] Teile ausgespart
}
</syntaxhighlight>

Wir bauen das cas.war mit den folgenden Befehlen neu:

<syntaxhighlight lang="bash">
cd ~/git/cas-overlay-template
./build.sh package
cp ~/git/cas-overlay-template/build/libs/cas.war ~/tomcat9/webapps/
</syntaxhighlight>

Der Pfad zur Service-Registry war in der oben erstellten ''cas.properties'' bereits enthalten.
Nun legen wir einen ersten Service an, in meinem Fall eine Nextcloud-Installation. Die Datei heißt
''hsexamplecloud-1000001.json'' und wird im Verzeichnis ''~/cas/services/'' abgelegt. Der Inhalt:

<syntaxhighlight lang="json" line>
{
"@class" : "org.apereo.cas.services.RegexRegisteredService",
"serviceId" : "^https://cloud.hs-example.de.*",
"name" : "hsexamplecloud",
"id" : 1000001,
"description" : "Nextcloud HS-Example",
"evaluationOrder" : 10000
}
</syntaxhighlight>

Der Name der Datei setzt sich aus Service-Name und Service-Id zusammen!

Die Konfiguration des CAS-Login in der Nextcloud erfolgt über die entsprechende "App" in Nextcloud.
Die Parameter sind wie folgt:

[[Datei:Cas-nextcloud-app.png]]

Die "Dienst-URL" im Screenshot ist: ''https://cloud.hs-example.de/index.php/apps/user_cas/login''

Die Anmeldung mit der Kennung ''casuser'' und dem Passwort ''Mellon'' sollte nun von der Nextcloud-Loginseite über den Link zum CAS-Login möglich sein.

=== Authentifizierung gegen JDBC Datenbank ===

Wir erweitern wieder die Datei ''build.gradle'' im Abschnitt ''dependencies''.

<syntaxhighlight lang="java" line>
dependencies {
compile "org.apereo.cas:cas-server-webapp${project.appServer}:${casServerVersion}"
// Other CAS dependencies/modules may be listed here...
compile "org.apereo.cas:cas-server-support-json-service-registry:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc-drivers:${project.'cas.version'}"
compile "org.apereo.cas:cas-server-support-jdbc:${project.'cas.version'}"
}
</syntaxhighlight>

''cas-server-support-jdbc-drivers'' liefert JDBC-Treiber für die gängigen Open-Source Datenbanksysteme. ''org.apereo.cas:cas-server-support-jdbc'' liefert das eigentliche CAS-Authentication Backend.

Zur Konfiguration wird die Datei ''cas.properties'' im Verzeichnis ''~/cas/conf/'' erweitert:

<syntaxhighlight lang="java" line>
cas.server.name=https://login.hs-example.de
cas.server.prefix=${cas.server.name}/cas
cas.serviceRegistry.json.location=file:/home/pacs/xyz00/users/login/cas/services
logging.config=file:/home/pacs/xyz00/users/login/cas/conf/log4j2.xml
logging.level.org.apereo=DEBUG
cas.authn.jdbc.query[0].sql=SELECT * FROM USERS WHERE UID=?
cas.authn.jdbc.query[0].url=jdbc:postgresql://localhost/xyz00_cas
cas.authn.jdbc.query[0].dialect=org.hibernate.dialect.PostgreSQL92Dialect
cas.authn.jdbc.query[0].user=xyz00_cas
cas.authn.jdbc.query[0].password=Ein_schlechtes_Passwort
cas.authn.jdbc.query[0].driverClass=org.postgresql.Driver
cas.authn.jdbc.query[0].fieldPassword=PSW
cas.authn.jdbc.query[0].passwordEncoder.type=BCRYPT
cas.authn.jdbc.query[0].passwordEncoder.characterEncoding=UTF-8
cas.authn.accept.users=
</syntaxhighlight>

Hier ein Beispiel für eine PostgreSQL-Datenbank mit einer Tabelle ''USERS'' mit den Spalten ''UID'' und ''PSW''. Die Spalte ''UID'' enthält den Login-Namen des Users, die Spalte ''PSW'' das Passwort mit dem BCrypt-Algorithmus verschlüsselt.

Die Zeile ''cas.authn.accept.users='' deaktiviert das Default-Login als User ''casuser'' mit Passwort ''Mellon''.

Achtung: Das Spring-Security Framework erwartet das BCrypt-Passwort mit der Kennung ''$2a$'' als erste Zeichen des Passwortfeldes. Die PHP-Funktion ''password_hash'' schreibt ''$2y$'' Wenn eine PHP-Passwort-Datenbank genutzt wird, muss hier ggf. eine VIEW in der Datenbank helfen.

== Grafische Anpassung der CAS Login-Seiten ==

Die Anpassungen der Login-Seite und anderer Teile der Browser-Anwendung ist vorgesehen. Eine Anleitung findet sich unter Link [7] und [4].

== Links ==

[1] https://de.wikipedia.org/wiki/Central_Authentication_Service

[2] https://www.apereo.org/projects/cas

[3] https://github.com/apereo/cas-overlay-template

[4] https://dacurry-tns.github.io/deploying-apereo-cas/

[5] https://apereo.github.io/2017/02/22/cas51-dbauthn-tutorial/

[6] https://apereo.github.io/2017/02/02/cas51-authn-handlers/

[7] https://apereo.github.io/2018/06/10/cas-userinterface-customizations/

[8] https://apereo.github.io/tags/#CAS

[9] https://iam.uconn.edu/java-cas-client-installation-and-configuration/

[10] https://fawnoos.com/2022/08/06/cas66-gettingstarted-overlay/

[11] https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/cas Ansible Playbook

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

Gitea

2022-12-02T08:00:59Z

Sib: Ordner zum Speichern der Log-Dateien von Gitea ergaenzt

== Gitea installieren ==

[https://gitea.io/en-us/ Gitea] ist ein einfacher, selbst gehosteter Git-Service wie GitHub oder GitLab. Die Software ist ein Fork von Gogs und ebenfalls in der Programmiersprache Go geschrieben. Gitea benötigt wenig Ressourcen. Um Gitea auf der Hostsharing Plattform nutzen zu können, benötigt man entweder einen Managed Server oder man muss für seinen Managed Webspace einen Daemon hinzubuchen.

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

=== Vorbereitung der Installation ===

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

1. Anlegen eines Domain-Benutzers. In unserem Beispiel <code>xyz00-gitea</code>.

2. Anlegen einer Domain. In unserem Beispiel <code>gitea.hs-example.de</code>.

3. Anlegen eines Datenbank-Benutzers. Hier <code>xyz00_giteadbuser</code>.

4. Anlegen einer Datenbank. Hier <code>xyz00_giteadb</code>.

Auf der Kommandozeile kann man dies folgendermaßen erledigen.

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

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

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

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

=== Installation von Gitea ===

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

sudo -u xyz00-gitea -i

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

wget -O gitea https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64
chmod +x gitea

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

wget https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64.asc
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
gpg --verify gitea-1.7.0-linux-amd64.asc gitea

Nun können wir Gitea testweise starten:

./gitea web

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

Der Server kann mit Ctrl-C beendet werden.

=== Konfiguration der Domain ===

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

rm -rf subs/www
rm -rf subs-ssl/www

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

vi htdocs/.htaccess

Der Eintrag muss lauten:

Redirect permanent / https://gitea.hs-example.com/

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

DirectoryIndex disabled
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) http://localhost:31580/$1 [proxy,last]

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

Damit ist die Konfiguration von Apache abgeschlossen.

=== Konfiguration von Gitea ===

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

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

Die Konfigurationsdatei beginnt mit allgemeinen Einträgen:

APP_NAME = Gitea: Git with a cup of tea
RUN_USER = xyz00-gitea
RUN_MODE = prod

Im Abschnitt [database] folgen die Angaben zur Datenbank:

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

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

[repository]
ROOT = /home/pacs/xyz00/users/gitea/gitea-repositories

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

Sie können nun Gitea starten:

./gitea web

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

=== Start- und Stopp-Skripte einrichten ===

Zum Schluss müssen Sie noch Start- und Stoppskripte einrichten und Monit konfigurieren.

Das Startskript speichern Sie unter dem Pfad <code>~/bin/gitea-start.sh</code> ab.
Es hat folgenden Inhalt:

#!/bin/bash
export HOME=/home/pacs/xyz00/users/gitea
export PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
export PID=$HOME/.gitea.pid
cd $HOME
exec $HOME/gitea web >$HOME/custom/logs/gitea.log 2>&1 &
echo $! > $PID

Das Stoppskript speichern Sie unter dem Pfad <code>~/bin/gitea-stop.sh</code> an.
Es hat folgenden Inhalt:

#!/bin/bash
export HOME=/home/pacs/xyz00/users/gitea
export PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
export PID=$HOME/.gitea.pid
cd $HOME

if [ -f $PID ] ; then
kill $( cat $PID );
sleep 20 ;
kill -9 $( cat $PID ) >/dev/null 2>&1 ;
rm $PID ;
fi

'''ACHTUNG''': Bitte prüfen Sie, ob die Skripte vom Nutzer xzy00 ausführbar sind. Bei Bedarf passen Sie die Berechtigungen entsprechend an.

ls -lha ~/bin/
chmod 744 ~/bin/gitea-st*

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

mkdir -p /home/pacs/xyz00/users/gitea/custom/logs

Monit ist ein Programm zur Überwachung eines Servers oder eines Dienstes.
Das Programm erwartet im Verzeichnis des Domain-Benutzers die Datei <code>~/.monitrc</code> mit der entsprechenden Konfiguration.
Legen Sie die Datei mit folgendem Inhalt an:

set daemon 600
set logfile /home/pacs/xyz00/users/gitea/custom/logs/monit.log
set mailserver localhost
set alert webmaster@gitea.hs-example.de
#
check process gitead with pidfile /home/pacs/xyz00/users/gitea/.gitea.pid
start program "/home/pacs/xyz00/users/gitea/bin/gitea-start.sh"
stop program "/home/pacs/xyz00/users/gitea/bin/gitea-stop.sh"

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

/home/pacs/xyz00/users/gitea/custom/logs/gitea.log {
copytruncate
daily
rotate 7
compress
missingok
}
/home/pacs/xyz00/users/gitea/custom/logs/monit.log {
copytruncate
monthly
rotate 2
compress
missingok
}

Damit gitea auch nach einem Server-Neustart neu gestartet wird und auch die Konfiguration für logrotate und monit eingelesen werden, müssen Sie folgenden Eintrag in der crontab der Domain-Benutzers machen:

# m h dom mon dow command
HOME=/home/pacs/xyz00/users/gitea
PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PID=$HOME/.gitea.pid
@reboot /usr/bin/monit -c $HOME/.monitrc > /dev/null
@reboot $HOME/gitea-start.sh
51 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate

Wichtig sind die @reboot-Einträge, die automatisch nach einem Neustart des Hosts ausgeführt werden.
Die Uhrzeit für die Logrotation können Sie beliebig einstellen.

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

~/bin/gitea-start.sh

== weiterführende Links ==

* [https://gitea.io/ Gitea Webseite]
* [https://docs.gitea.io/ Dokumentation von Gitea]
* [https://github.com/tpokorra/Hostsharing-Ansible-Gitea Ansible Playbook für Hostsharing]

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

Gitea

2022-11-21T12:53:40Z

Sib: Benutzer hatten bisher keine Berechtigung die Skripte fuer Start und Stop auszuführen

== Gitea installieren ==

[https://gitea.io/en-us/ Gitea] ist ein einfacher, selbst gehosteter Git-Service wie GitHub oder GitLab. Die Software ist ein Fork von Gogs und ebenfalls in der Programmiersprache Go geschrieben. Gitea benötigt wenig Ressourcen. Um Gitea auf der Hostsharing Plattform nutzen zu können, benötigt man entweder einen Managed Server oder man muss für seinen Managed Webspace einen Daemon hinzubuchen.

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

=== Vorbereitung der Installation ===

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

1. Anlegen eines Domain-Benutzers. In unserem Beispiel <code>xyz00-gitea</code>.

2. Anlegen einer Domain. In unserem Beispiel <code>gitea.hs-example.de</code>.

3. Anlegen eines Datenbank-Benutzers. Hier <code>xyz00_giteadbuser</code>.

4. Anlegen einer Datenbank. Hier <code>xyz00_giteadb</code>.

Auf der Kommandozeile kann man dies folgendermaßen erledigen.

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

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

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

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

=== Installation von Gitea ===

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

sudo -u xyz00-gitea -i

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

wget -O gitea https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64
chmod +x gitea

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

wget https://dl.gitea.io/gitea/1.7.0/gitea-1.7.0-linux-amd64.asc
gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
gpg --verify gitea-1.7.0-linux-amd64.asc gitea

Nun können wir Gitea testweise starten:

./gitea web

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

Der Server kann mit Ctrl-C beendet werden.

=== Konfiguration der Domain ===

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

rm -rf subs/www
rm -rf subs-ssl/www

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

vi htdocs/.htaccess

Der Eintrag muss lauten:

Redirect permanent / https://gitea.hs-example.com/

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

DirectoryIndex disabled
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) http://localhost:31580/$1 [proxy,last]

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

Damit ist die Konfiguration von Apache abgeschlossen.

=== Konfiguration von Gitea ===

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

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

Die Konfigurationsdatei beginnt mit allgemeinen Einträgen:

APP_NAME = Gitea: Git with a cup of tea
RUN_USER = xyz00-gitea
RUN_MODE = prod

Im Abschnitt [database] folgen die Angaben zur Datenbank:

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

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

[repository]
ROOT = /home/pacs/xyz00/users/gitea/gitea-repositories

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

Sie können nun Gitea starten:

./gitea web

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

=== Start- und Stopp-Skripte einrichten ===

Zum Schluss müssen Sie noch Start- und Stoppskripte einrichten und Monit konfigurieren.

Das Startskript speichern Sie unter dem Pfad <code>~/bin/gitea-start.sh</code> ab.
Es hat folgenden Inhalt:

#!/bin/bash
export HOME=/home/pacs/xyz00/users/gitea
export PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
export PID=$HOME/.gitea.pid
cd $HOME
exec $HOME/gitea web >$HOME/custom/logs/gitea.log 2>&1 &
echo $! > $PID

Das Stoppskript speichern Sie unter dem Pfad <code>~/bin/gitea-stop.sh</code> an.
Es hat folgenden Inhalt:

#!/bin/bash
export HOME=/home/pacs/xyz00/users/gitea
export PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
export PID=$HOME/.gitea.pid
cd $HOME

if [ -f $PID ] ; then
kill $( cat $PID );
sleep 20 ;
kill -9 $( cat $PID ) >/dev/null 2>&1 ;
rm $PID ;
fi

'''ACHTUNG''': Bitte prüfen Sie, ob die Skripte vom Nutzer xzy00 ausführbar sind. Bei Bedarf passen Sie die Berechtigungen entsprechend an.

#!/bin/bash
ls -lha ~/bin/
chmod 744 ~/bin/gitea-st*

Monit ist ein Programm zur Überwachung eines Servers oder eines Dienstes.
Das Programm erwartet im Verzeichnis des Domain-Benutzers die Datei <code>~/.monitrc</code> mit der entsprechenden Konfiguration.
Legen Sie die Datei mit folgendem Inhalt an:

set daemon 600
set logfile /home/pacs/xyz00/users/gitea/custom/logs/monit.log
set mailserver localhost
set alert webmaster@gitea.hs-example.de
#
check process gitead with pidfile /home/pacs/xyz00/users/gitea/.gitea.pid
start program "/home/pacs/xyz00/users/gitea/bin/gitea-start.sh"
stop program "/home/pacs/xyz00/users/gitea/bin/gitea-stop.sh"

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

/home/pacs/xyz00/users/gitea/custom/logs/gitea.log {
copytruncate
daily
rotate 7
compress
missingok
}
/home/pacs/xyz00/users/gitea/custom/logs/monit.log {
copytruncate
monthly
rotate 2
compress
missingok
}

Damit gitea auch nach einem Server-Neustart neu gestartet wird und auch die Konfiguration für logrotate und monit eingelesen werden, müssen Sie folgenden Eintrag in der crontab der Domain-Benutzers machen:

# m h dom mon dow command
HOME=/home/pacs/xyz00/users/gitea
PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
PID=$HOME/.gitea.pid
@reboot /usr/bin/monit -c $HOME/.monitrc > /dev/null
@reboot $HOME/gitea-start.sh
51 1 * * * /usr/sbin/logrotate -s $HOME/.logrotate.state $HOME/.logrotate

Wichtig sind die @reboot-Einträge, die automatisch nach einem Neustart des Hosts ausgeführt werden.
Die Uhrzeit für die Logrotation können Sie beliebig einstellen.

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

~/bin/gitea-start.sh

== weiterführende Links ==

* [https://gitea.io/ Gitea Webseite]
* [https://docs.gitea.io/ Dokumentation von Gitea]
* [https://github.com/tpokorra/Hostsharing-Ansible-Gitea Ansible Playbook für Hostsharing]

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