Hostsharing Wiki - Benutzerbeiträge [de]

Mnogosearch installieren

2024-12-03T14:51:29Z

Cds09: /* Cronjob zum Update der Suchdatenbank in der Nacht */

== Die Suchmaschine für die eigene Webseite ==

[http://www.mnogosearch.org/ Mnogosearch] ist eine Suchmaschine, die für die eigene Webseite verwendet werden kann. Sie ist für Webseiten bis einige tausend Seiten und Traffic, wie er auf einem Shared-Webserver vorkommt, gut geeignet. Die Software muss aus den Sourcen selbst [[#Kompilieren der Mnogosearch aus den Sourcen|kompiliert]] werden und kann mit Datenbanken wie Sqlite3, Mysql oder Postgresql eingesetzt werden.

Hier wird eine Grundinstallation beschrieben. Mnogosearch ist eine sehr umfangreiche Software mit mannigfaltigen Konfigurationsmöglichkeiten. Für die weitergehende Konfiguration muss auf die Dokumentation von [http://www.mnogosearch.org/ Mnogosearch] verwiesen werden.

Mnogosearch ist sehr mächtig und kann vor allen Dingen mit Unicode umgehen, es können viele Dinge eingestellt werden. In dieser Konfiguration funktioniert der indexer als "Crawler", er surft die eigene Webseite ab und speichert die Einträge für spätere Suchergebnisse. Dabei beachtet er die /robots.txt.

Es können aber auch das Dateisystem und verschiedene Dokumentarten durchsucht werden, es können Bereiche der Webseite ausgeschlossen werden und es können Sektionen in Webseiten definiert werden, die für die Auflistung der Suchergebnisse als wichtiger gewertet werden. Diese Dinge müssen zusätzlich konfiguriert werden. Dies ist nur eine Grundkonfiguration, die aber in den meisten Fällen ausreichen dürfte.

== Konfiguration ==

Für die Datenbank und die Konfigurationsdatei wird am besten pro Domain ein Verzeichnis "mnogosearch" eingerichtet und da die Konfigurationsdatei indexer.conf erstellt. Diese Datei kann auch von /etc/mnogosearch/indexer.conf kopiert werden und muss dann entsprechend geändert werden.

<syntaxhighlight lang=bash>
cd /home/doms/example.com
mkdir mnogosearch
cd mnogosearch
touch indexer.conf
edit indexer.conf
</syntaxhighlight>

=== Inhalt von indexer.conf ===

Dies ist die stark gekürzte und auf Notwendiges reduzierte Fassung. Ganz zu Beginn wird die Datenbankdatei und am Ende der zu indizierende Webserver definiert:

<syntaxhighlight lang=bash line>
###########################################################################
# DBAddr <URL-style database description>
# Options (type, host, database name, port, user and password)
# to connect to SQL database.
# Should be used before any other commands.
# Has global effect for whole config file.
# Format:
#DBAddr <DBType>:[//[DBUser[:DBPass]@]DBHost[:DBPort]]/DBName/[?dbmode=mode]

DBAddr sqlite://mnogo:@/home/doms/example.com/mnogosearch/mnogosearch.db/?dbmode=multi

# Default LocalCharset is iso-8859-1 (latin1).

# Full UNICODE
# Folgendes auskommentieren für iso-8859-1
LocalCharset UTF-8

###########################################################################
# StopwordFile <filename>
# Load stop words from the given text file. You may specify either absolute
# file name or a name relative to mnoGoSearch /etc directory. You may use
# several StopwordFile commands.
#
StopwordFile stopwords/de.sl

#######################################################################
# HTTPHeader <header>
# You may add your desired headers in indexer HTTP request.
# You should not use "If-Modified-Since","Accept-Charset" headers,
# these headers are composed by indexer itself.
# "User-Agent: mnoGoSearch/version" is sent too, but you may override it.
# Command has global effect for all configuration file.
#
HTTPHeader "User-Agent: example.com-indexer"

##########################################################################
# Section 2.
# URL control configuration.

# Allow Configuration
# Examples
# Allow everything:
#Allow *
# Allow everything but .php .cgi .pl extensions case insensitively using regex:
#Allow NoMatch Regex \.php$|\.cgi$|\.pl$
# Allow .HTM extension case sensitively:
#Allow Case *.HTM

Allow *.html

##########################################################################
#Disallow [Match|NoMatch] [NoCase|Case] [String|Regex] <arg> [<arg> ... ]
#
# Examples:
# Disallow URLs that are not in udm.net domains using "string" match:
#Disallow NoMatch *.udm.net/*
# Disallow any except known extensions and directory index using "regex" match:
#Disallow NoMatch Regex \/$|\.htm$|\.html$|\.shtml$|\.phtml$|\.php$|\.txt$
# Exclude cgi-bin and non-parsed-headers using "string" match:
#Disallow */cgi-bin/* *.cgi */nph-*
# Exclude anything with '?' sign in URL. Note that '?' sign has a
# special meaning in "string" match, so we have to use "regex" match here:
#Disallow Regex \?

# Exclude some known extensions using fast "String" match:
Disallow *.b *.sh *.md5 *.rpm
Disallow *.arj *.tar *.zip *.tgz *.gz *.z *.bz2
Disallow *.lha *.lzh *.rar *.zoo *.ha *.tar.Z
Disallow *.gif *.jpg *.jpeg *.bmp *.tiff *.tif *.xpm *.xbm *.pcx
Disallow *.vdo *.mpeg *.mpe *.mpg *.avi *.movie *.mov *.wmv
Disallow *.mid *.mp3 *.rm *.ram *.wav *.aiff *.ra
Disallow *.vrml *.wrl *.png *.ico *.psd *.dat
Disallow *.exe *.com *.cab *.dll *.bin *.class *.ex_
Disallow *.tex *.texi *.xls *.doc *.texinfo
Disallow *.rtf *.pdf *.cdf *.ps
Disallow *.ai *.eps *.ppt *.hqx
Disallow *.cpt *.bms *.oda *.tcl
Disallow *.o *.a *.la *.so
Disallow *.pat *.pm *.m4 *.am *.css
Disallow *.map *.aif *.sit *.sea
Disallow *.m3u *.qt

# Exclude Apache directory list in different sort order using "string" match:
Disallow *D=A *D=D *M=A *M=D *N=A *N=D *S=A *S=D

# More complicated case. RAR .r00-.r99, ARJ a00-a99 files
# and UNIX shared libraries. We use "Regex" match type here:
Disallow Regex \.r[0-9][0-9]$ \.a[0-9][0-9]$ \.so\.[0-9]$

################################################################
# Section 3.
# Mime types and external parsers.

################################################################
#AddType [String|Regex] [Case|NoCase] <mime type> <arg> [<arg>...]
# This command associates filename extensions (for services
# that don't automatically include them) with their mime types.
# Currently "file:" protocol uses these commands.
# Use optional first two parameter to choose comparison type.
# Default type is "String" "NoCase" (case sensitive string match with
# '?' and '*' wildcards for one and several characters correspondingly).
#
AddType image/x-xpixmap *.xpm
AddType image/x-xbitmap *.xbm
AddType image/gif *.gif

AddType text/plain *.txt *.pl *.js *.h *.c *.pm *.e
AddType text/html *.html *.htm

AddType text/rtf *.rtf
AddType application/pdf *.pdf
AddType application/msword *.doc
AddType application/vnd.ms-excel *.xls
AddType text/x-postscript *.ps

# Default unknown type for other extensions:
AddType application/unknown *.*

# Use ParserTimeOut to specify amount of time for parser execution
# to avoid possible indexer hang.

ParserTimeOut 300

#######################################################################
# Section 5.
# Servers configuration.

#######################################################################
# Document sections.
#
# Format is:
#
# Section <string> <number> <maxlen> [clone] [sep] [{expr} {repl}]
#
# where <string> is a section name and <number> is section ID
# between 0 and 255. Use 0 if you don't want to index some of
# these sections. It is better to use different sections IDs
# for different documents parts. In this case during search
# time you'll be able to give different weight to each part
# or even disallow some sections at a search time.
# <maxlen> argument contains a maximum length of section
# which will be stored in database.
# "clone" is an optional parameter describing whether this
# section should affect clone detection. It can
# be "DetectClone" or "cdon", or "NoDetectClone" or "cdoff".
# By default, url.* section values are not taken in account
# for clone detection, while any other sections take part
# in clone detection.
# "sep" is an optional argument to specify a separator between
# parts of the same section. It is a space character by default.
# "expr" and "repl" can be used to extract user defined sections,
# for example pieces of text between the given tags. "expr" is
# a regular expression, "repl" is a replacement with $1, $2, etc
# meta-characters designating matches "expr" matches.

# Standard HTML sections: body, title

Section body 1 256
Section title 2 128

# META tags
# For example <META NAME="KEYWORDS" CONTENT="xxxx">
#

Section meta.keywords 3 128
Section meta.description 4 128

# HTTP headers example, let's store "Server" HTTP header
#
#
#Section header.server 5 64

# Document's URL parts

Section url.file 6 0
Section url.path 7 0
Section url.host 8 0
Section url.proto 9 0

# CrossWords

Section crosswords 10 0

#
# If you use CachedCopy for smart excerpts (see below),
# please keep Charset section active.
#
Section Charset 11 32

Section Content-Type 12 64
Section Content-Language 13 16

# Uncomment the following lines if you want tag attributes
# to be indexed

#Section attribute.alt 14 128
#Section attribute.label 15 128
#Section attribute.summary 16 128
#Section attribute.title 17 128
#Section attribute.face 27 0

# Uncomment the following lines if you want use NewsExtensions
# You may add any Newsgroups header to be indexed and stored in urlinfo table

#Section References 18 0
#Section Message-ID 19 0
#Section Parent-ID 20 0

# Uncomment the following lines if you want index MP3 tags.
#Section MP3.Song 21 128
#Section MP3.Album 22 128
#Section MP3.Artist 23 128
#Section MP3.Year 24 128

# Comment this line out if you don't want to store "cached copies"
# to generate smart excerpts at search time.
# Don't forget to keep "Charset" section active if you use cached copies.
# NOTE: 3.2.18 has limits for CachedCopy size, 32000 for Ibase and
# 15000 for Mimer. Other databases do not have limits.
# If indexer fails with 'string too long' error message then reduce
# this number. This will be fixed in the future versions.
#
Section CachedCopy 25 64000

# A user defined section example.
# Extract text between <h1> and </h1> tags:
#Section h1 26 128 "<h1>(.*)</h1>" $1

#########################################################################
#Server [Method] [SubSection] <URL> [alias]
# This is the main command of the indexer.conf file. It's used
# to describe web-space you want to index. It also inserts
# given URL into database to use it as a start point.
# You may use "Server" command as many times as a number of different
# servers or their parts you want to index.

# To index whole server "www.example.com":
Server http://www.example.com/
</syntaxhighlight>

'''Unbedingt im ganzen Dokument example.com durch den eigenen Domainnamen ersetzen!'''

=== Datenbank erstellen ===

Die Datenbank wird mit dem Programm '''indexer''' erstellt. Dabei muss indexer natürlich (und wie bei jedem Aufruf) der Pfad zur eigenen Konfiguration mitgeteilt werden.

<syntaxhighlight lang=bash>
/usr/sbin/indexer -Ecreate /home/doms/example.com/mnogosearch/indexer.conf
</syntaxhighlight>

==== Erster Indexlauf ====

<syntaxhighlight lang=bash>
/usr/sbin/indexer -a /home/doms/example.com/mnogosearch/indexer.conf
</syntaxhighlight>

Mit diesem Befehl wird die Datenbank gefüllt. Wir haben in der Konfigurationsdatei definiert, dass alle Seiten mit der Endung .html unter http://www.example.com/ durchsucht und indiziert werden.

Die Option -a ersetzt alle vorhandenen Einträge.

=== Die Suche auf der eigenen Webseite ===

Damit die Suche funktionieren kann, legen wir einen symbolischen Link zu dem Suchprogramm /usr/lib/cgi-bin/search.cgi in das eigene cgi-Verzeichnis:

<syntaxhighlight lang=bash>
ln -s /usr/lib/cgi-bin/search.cgi /home/doms/example.com/cgi/search.cgi
</syntaxhighlight>

Das zugehörige Suchformular kann entweder von /etc/mnogosearch/search.htm in das eigene Webverzeichnis kopiert (mit der Endung "zhtml" - siehe weiter unten) und anschließend editiert werden. Wichtig ist der Verweis auf die eigene Datenbankdatei in der Sektion "variables" ganz zu Beginn:

:'''DBAddr sqlite://mnogo:@/home/doms/example.com/mnogosearch/mnogosearch.db/?dbmode=multi'''

==== Minimales Suchformular in Deutsch ====

Folgendes Formular ist bereits eingedeutscht und kann direkt als /home/doms/example.com/subs/www/suche.zhtml abgespeichert werden (man beachte die Endung "zhtml"):

<syntaxhighlight lang=html>
# start



<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=$&(BrowserCharset)" />
<title>Suche: $&(q)</title>
<style type="text/css">
body { background-color: #fff; }
a { color: #00c; }
div.center { text-align: center; }
table.grey { background-color: #eee; width: 100%; }
table.white { background-color: #fff; width: 100%; }
img.logo { border: none; }
</style>
</head>

<body>

<div class="center">
<form method="get" action="">
<table class="grey" summary="">
<tr>
<td>
<br /> Suche nach:
<INPUT TYPE="text" NAME="q" VALUE="$&(q)" SIZE=50 />
<INPUT TYPE="submit" NAME="cmd" VALUE="Suche!" />
<br /><br />
</td>
</tr>
</table>
</form>
</div>




<table bgcolor=#EEEEEE width=100% border=0>
<tr>
<td>
<small>Suche nach <b>$&(q)</b>.</small>
<small>Gefunden: <b>$&(WE)</b>.</small>
</td>
<td>
<small>Ergebnisse <b>$(first)-$(last)</b> von <B>$(total)</B>.</small>
<small>Die Suche dauerte <b>$(SearchTime)</b> Sekunden</small>
</td>
</tr>
<tr><td colspan="2">
Sortieren:
<!IF NAME="s" CONTENT="DRP">
<a href="$(FirstPage)&s=RPD">Relevanz</a> | <b>Datum</b> | <a href="$(FirstPage)&s=SRPD&su=title">Titel</a>
<!ELSEIF NAME="s" CONTENT="SRPD">
<a href="$(FirstPage)&s=RPD">Relevanz</a> | <a href="$(FirstPage)&s=DRP">Datum</a> | <b>Titel</b>
<!ELSE>
<b>Relevanz</b> | <a href="$(FirstPage)&s=DRP">Datum</a> | <a href="$(FirstPage)&s=SRPD&su=title">Titel</a>
<!ENDIF>
</td></tr>
</table>
<br />




<DL>
<!IFNOT NAME="Alias" CONTENT=""><!COPY NAME="URL" CONTENT="Alias"><!ENDIF>
<!IF NAME="fmt" CONTENT="url">
<DT>$(Order).
<a href="$(URL)">$(URL:40)</a>
<small>[<b>$(Score)</b>]</small>
<!ELSEIF NAME="fmt" CONTENT="short">
<DT>$(Order).
<a href="$(URL)">
<!IF NAME="Title" CONTENT="">$(URL:40)<!ELSE>$&(Title)<!ENDIF>
</a>
<small>[<b>$(Score)</b>]</small>
<!ELSE>
<DT>$(Order).
<a href="$(URL)">
<!IF NAME="Title" CONTENT="">$(URL:40)<!ELSE>$&(Title)<!ENDIF>
</a>
<small>
[
<b>$(Score)</b>
<!IFNOT NAME="Pop_Rank" CONTENT="0.00000">Popularity: <b>$(Pop_Rank)</b><!ENDIF>
]
</small>
<DD>
<table width=60%>
<tr>
<td>
<small>$&(Body)...</small>
</td>
</tr>
<tr>
<td>
<UL>
<li>
<small>
<A HREF="$(URL)">$(URL:40)</A>
<font color="#008800">
- $(Content-Length) bytes [$(Content-Type)]
- $(Last-Modified)
<!IFNOT NAME="stored_href" CONTENT="">
<DD><small>[<a href="$(stored_href)">Cached copy</a>]</small></DD>
<!ENDIF>
<!IFNOT NAME="sitelimit_href" CONTENT="">
<!IFGT NAME="PerSite" CONTENT="0">
<DD><small>
[<a href="$(sitelimit_href)">More results from this site ($(PerSite) total) </a>]
</small></DD>
<!ENDIF>
<!ENDIF>
</font>
</small>
<BR>
$(CL)
</UL>
$(STORED)

</td>
</tr>
</table>

<!ENDIF>
</DL>



<table width=100% bgcolor=#FFFFFF>
<tr>
<td align=center>
<TABLE BORDER=0>
<TR><TD><small>Ergebnis Seiten: <TD> </TD></TD>$(NL)$(NB)$(NR)</TD></TR>
</TABLE>
</td>
</tr>
</table>



<!IFNOT NAME="Alias" CONTENT=""><!COPY NAME="URL" CONTENT="Alias"><!ENDIF>
<li>
<small>
<A HREF="$(URL)">$(URL:40)</A>
<font color="#008800">
- $(Content-Length) bytes
- $(Last-Modified)
</font>
</small>



<TD><small><A HREF="$(NH)"><< Vorherige</A></TD>



<TD><small><FONT COLOR=gray><< Vorherige</FONT></TD>



<TD><small><A HREF="$(NH)">$(NP)</A></TD>



<TD><small>$(NP)</TD>



<TD><small><A HREF="$(NH)">Nächste >></A></TD>



<TD><small><FONT COLOR=gray>Nächste >></FONT></TD>



<!IFNOT NAME="WS" CONTENT="">
Meinten Sie <b><a href="?q=$%(WS)">$(WS)</a></b>?
<!ENDIF>
<table bgcolor=#EEEEEE width=100%>
<tr>
<td>
<small>Suche nach <b>$&(q)</b>.</small>
<small>Suchergebnisse: <b>$&(WE)</b></small>
</td>
</tr>
</table>

<p>
Sorry, Ihre Suche nach <b>$&(q)</b> hat kein Ergebnis.<br>
Es wurden keine Dokumente gefunden, die <b>"$&(q)" enthalten</b>.<br>

<p>
Hinweise:
<UL>
<LI> Stellen Sie sicher, dass Ihre Wörter richtig geschrieben sind.
<LI> Versuchen Sie andere Suchworte.
<LI> Versuchen Sie allgemeinere Suchwörter.
</UL>



<div class="center">Bitte geben Sie eines oder mehrere Wörter ein und dücken Sie Suche.</div>



<CENTER>
<FONT COLOR="#FF0000">Es ist ein Fehler aufgetreten!</FONT>
<P><B>$(E)</B>
</CENTER>



<table class="grey" summary="">
<tr><td> </td></tr>
</table>

</body>
</html>



<BASE HREF="$(URL)">

<table border="1" cellpadding="2" cellspacing="0"><tr>
<td><b>Document ID:</b> $(ID)</td>
<td><b>Last modified:</b> $(Last-Modified)</td>
<td><b>Language:</b> $(Content-Language)</td>
<td><b>Charset:</b> $(Charset)</td>
<td><b>Size:</b> $(Content-Length)</td>
</tr></table>
<hr>



$^(document)





</syntaxhighlight>

==== suche.zhtml sucht search.cgi ====

Das Suchformular hat keine "action" definiert, es wird per .htaccess an '''search.cgi''' als Template übergeben:

Wenn noch nicht vorhanden, im gleichen Verzeichnis, in dem das Suchformulat liegt (in diesem Fall ~/doms/example.com/subs/www), eine Datei .htaccess erstellen und editieren:

<syntaxhighlight lang=bash>
touch .htaccess
edit .htaccess
</syntaxhighlight>

Und da folgendes reinschreiben (vorausgesetzt, das Formular heißt suche.zhtml):

<syntaxhighlight lang=apache>
AddType text/html .zhtml
AddHandler zhtml .zhtml
Action zhtml /home/doms/example.com/cgi/search.cgi
</syntaxhighlight>

Nun kann das Suchformular im Browser angezeigt und verwendet werden:

<nowiki>http://www.example.com/suche.zhtml</nowiki>

Es gibt etliche weitere Möglichkeiten, search.cgi zu benutzen, sie stehen in der Dokumentation.

=== Systemd Timer zum Update der Suchdatenbank in der Nacht ===

Sollten sich die Webseiten öfter mal ändern, ist es sinnvoll, die Suchdatenbank nachts zu aktualisieren. Dafür wird ein systemd Timer eingerichtet.

<code>~/.config/systemd/user/mnogosearch_update.service</code>
<syntaxhighlight lang=ini>
[Unit]
Description=update mnogosearch database

[Service]
Type=oneshot
ExecStart=nice indexer /home/doms/example.com/mnogosearch/indexer.conf
</syntaxhighlight>

<code>~/.config/systemd/user/mnogosearch_update.timer</code>
<syntaxhighlight lang=ini>
[Unit]
Description=update mnogosearch database

[Timer]
OnCalendar=23:19
Persistent=True

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

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

'''Bitte eine andere Uhrzeit wählen, damit nicht alle indexer-Jobs um 23:19 Uhr anlaufen!!!'''

== Kompilieren der Mnogosearch aus den Sourcen ==

{{Baustelle}}

Diese Anleitung ist sehr auf die Zusammenarbeit mit dem CMS TYPO3 ausgerichtet. So sind zum Beispiel die Konfigurationseinstellungen zum kompilieren aus dem Manual der TYPO3 Extension [http://typo3.org/documentation/document-library/extension-manuals/mnogosearch/2.2.2/view/1/3/ mnogosearch] entnommen.
Im Grunde bin ich einfach den Anweisungen dort gefolgt, mußte aber wegen HS-spezifischen Gründen an manchen Stellen einen anderen Weg gehen.

Ich habe Mnogosearch mit einem Domainuser kompiliert. Ich denke das das grundsätzlich auch mit einem Paketadmin funktioniert, aber eventuell zu unsicher ist.

=== Runterladen und auspacken ===
Zuerst wechseln wir ins Homeverzeichnis (~) des Users, laden uns den Quellcode runter und entpacken das Archiv.

<syntaxhighlight lang=bash>
cd ~
# stets die neueste Version benutzen
wget http://www.mnogosearch.org/Download/mnogosearch-3.3.9.tar.gz
tar xvf mnogosearch-3.3.9.tar.gz
</syntaxhighlight>

=== Anpassen der Dateien ===

Sollte man ausschließend eine MySQL Datenbank verwenden, muß vor dem kompilieren die Dateien ./configure.in und ./configure bearbeiten.
In beiden Dateien suchen wir nach dem String ''HAVE_PGSQL'' und ändern die ''1'' in eine ''0''.
<syntaxhighlight lang=bash>
cd mnogosearch-3.3.9
$yourEditor configure.in
AC_DEFINE([HAVE_PGSQL], [1], [Define if you want to use PostgreSQL])
</syntaxhighlight>

=== Configure ===
'''Hinweis:''' Hier gibt es zwei wichtige Änderungen gegenüber des Manuals.
* der Installationpfad muss angepasst werden, da wir keine Schreibrechte für /opt/ besitzen
* der Pfad zu der Datei mysql.h muss angegeben werden

<syntaxhighlight lang=bash>
./configure --prefix=/path/to/user/home/opt/mnogosearch --with-mysql=/usr --disable-mp3 --disable-news --without-debug --with-pgsql=no --with-freetds=no --with-oracle8=no --with-oracle8i=no --with-iodbc=no --with-unixODBC=no --with-db2=no --with-solid=no --with-openlink=no --with-easysoft=no --with-sapdb=no --with-ibase=no --with-ctlib=no --with-zlib --disable-syslog
</syntaxhighlight>

=== Kompilieren und Installation der Suchengine ===
Bevor es zum kompilieren kommen, müssen wir noch eine erzeugte Datei bearbeiten und ändern dort den String
''/* #undef HAVE_PGSQL */'' in ''#undef HAVE_PGSQL''.
<syntaxhighlight lang=bash>
cd mnogosearch-3.3.9
$yourEditor include/udm_autoconf.h
</syntaxhighlight>

Jetzt kompilieren und installieren wir Mnogosearch
<syntaxhighlight lang=bash>
make
make install
</syntaxhighlight>

=== Kompilieren und Installation der PHP Extension ===
'''Hinweis:'''
* der Pfad zur Suchengine muss angepasst werden (ist derselbe Pfad wie in dem --prefix Argument)

<syntaxhighlight lang=bash>
cd ~/mnogosearch-3.3.9/php
phpize
./configure --with-mnogosearch=/path/to/user/home/opt/mnogosearch
</syntaxhighlight>

Jetzt müssen wir die Datei ''php_mnogo.c'' editieren und den String ''#undef HAVE_PGSQL'' in eine neue Zeile unterhalb von ''#include "php.h"'' einfügen.

Jetzt können wir die Extension bauen.

<syntaxhighlight lang=bash>
make
</syntaxhighlight>

Die PHP Extension liegt jetzt in dem Ordner ~/mnogosearch-3.3.9/php/modules. Am Besten kopiert man sich die Extension in den CGI Ordner einer Domain oder ebenfalls nach ~/opt.

Um die Extension nun nutzen zu können, editieren wir die eigene ''php-cgi-fcgi.ini'' und fügen am Ende
<syntaxhighlight lang=ini>
extension=relativer/Pfad/vom/PHP-Extension/Verzeichnis/zu/mnogosearch.so
</syntaxhighlight>
ein.

Das aktuelle Extension Dir erhält man so:
<syntaxhighlight lang=bash>
php -i | grep extension_dir
</syntaxhighlight>

Von diesem Verzeichnis ausgehend hangelt man sich bis zu dem Verzeichnis, in das man eben die PHP Extension kopiert hat.
Das ist notwendig, da in PHP 5.2 keine multiplen Extension Dirs in der php.ini eingetragen werden können. Eigene Extensions können nur relativ referenziert werden.

Das Ergbnis sollte man noch in einer mittels phpinfo überprüfen. Wenn alles funktioniert hat, sollte in der Übersicht ''mnogosearch'' auftauchen. Ist dies nicht der Fall empfielt es sich das Errorlog von PHP anzuschalten und zu schauen, was schief läuft. Oft liegt das einfach an dem falschen relativen Pfad zur Extension.

Den weiteren Installationablauf entnimmt man am Besten dem Manual zur TYPO3 Extension.
nach dem Installieren der Extension in TYPO3 muss man den Pfad zu der Suchengine von /opt/mnogosearch entsprechend anpassen. In unserem Fall wäre das ''/path/to/user/home/opt/mnogosearch''

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

Taiga

2024-12-03T14:46:25Z

Cds09: /* Einrichtung der Benachrichtigungen per E-Mail */

= Taiga installieren =

Taiga ist eine Software für die agile Projektverwaltung. Es werden Scrum- und einfache Kanban-Projekte unterstützt. Weitere Komponenten sind ein Issue-Tracker und ein Wiki pro Projekt. User Stories können optional zu Epics zugeordnet werden.

Bei Hostsharing kann Taiga im Managed Webspace mit dem Apache Passenger Modul betrieben werden. Es wird eine PostgreSQL Datenbank benötigt.

Diese Installationsanleitung beschreibt ein minimales Setup und verzichtet auf die Komponenten "taiga-events" und "taiga-protected".

== Vorbereitung in HSAdmin ==

Mit Hilfe von HSAdmin werden angelegt:

* ein User mit der Shell '/bin/bash', im Beispiel "xyz00-taiga"
* beim User wird eine Domain aufgeschaltet, mein Beispiel ist: "projekte.hs-example.de"
* ein PostgreSQL-User und eine PostgreSQL-Datenbank, beide heißen hier: "xyz00_taiga"

== Installation des Backend ==

Das Backend ist eine Python-/Django-Anwendung. Die Sourcen werden aus dem Git-Repository bei Github ausgecheckt:

<syntaxhighlight lang=shell>
cd ~
git clone https://github.com/kaleidos-ventures/taiga-back
cd taiga-back
git checkout stable
</syntaxhighlight>

Dann wird im Projekt-Verzeichnis ein Python.Virtualenv angelegt:

<syntaxhighlight lang=shell>
cd ~/taiga-back
python3 -m venv .venv --prompt taiga-back
source .venv/bin/activate
(taiga-back) pip install --upgrade pip wheel
(taiga-back) pip install -r requirements.txt
(taiga-back) pip install git+https://github.com/kaleidos-ventures/taiga-contrib-protected.git@6.7.0#egg=taiga-contrib-protected
</syntaxhighlight>

Es folgt die Konfiguration der Django-Anwendung

<syntaxhighlight lang=shell>
cd ~/taiga-back
cp settings/config.py.prod.example settings/config.py
nano settings/config.py
</syntaxhighlight>

Folgende Einstellungen müssen angepasst werden:

In der Struktur "DATABASES" wird die angelegte PostgreSQL-Datenbank eingetragen.

<syntaxhighlight lang=python>
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql',
'NAME': 'xyz00_taiga',
'USER': 'xyz00_taiga',
'PASSWORD': 'das-passwort-von-xyz00_taiga',
'HOST': '127.0.0.1',
'PORT': '5432',
}
}
</syntaxhighlight>

Für die Variablen "SITES" und TAIGA_URL muss die richtige Domain eingetragen werden, als "SECRET_KEY" wird ein zufällige Zeichenkette eingetragen.

<syntaxhighlight lang=python>
SECRET_KEY = "xxxxxxxxxxxxxxxxxxxxxxx"
TAIGA_URL = "https://projekte.hs-example.de"
SITES = {
"api": {"domain": "projekte.hs-example.de", "scheme": "https", "name": "api"},
"front": {"domain": "projekte.hs-example.de", "scheme": "https", "name": "front"}
}
</syntaxhighlight>

Im Bereich "MEDIA AND STATIC" werden die bisher auskommentierten Variablen "MEDIA_ROOT" und "STATIC_ROOT" definiert.

<syntaxhighlight lang=python>
# MEDIA_ROOT = '/home/taiga/media'
MEDIA_ROOT = '/home/pacs/xyz00/users/taiga/data/media'
MEDIA_URL = f"{ TAIGA_URL }/media/"
DEFAULT_FILE_STORAGE = "taiga_contrib_protected.storage.ProtectedFileSystemStorage"
THUMBNAIL_DEFAULT_STORAGE = DEFAULT_FILE_STORAGE
# STATIC_ROOT = '/home/taiga/static'
STATIC_ROOT = '/home/pacs/xyz00/users/taiga/data/static'
STATIC_URL = f"{ TAIGA_URL }/static/"
</syntaxhighlight>

Für das Versenden von E-Mail ist der Bereich "EMAIL" anzupassen.

<syntaxhighlight lang=python>
DEFAULT_FROM_EMAIL = 'noreply@projekte.hs-example.de'
EMAIL_USE_TLS = True
EMAIL_HOST = '127.0.0.1'
EMAIL_PORT = 4587
EMAIL_HOST_USER = 'xyz00-taiga'
EMAIL_HOST_PASSWORD = 'passwort-von-xyz00-taiga'
</syntaxhighlight>

Alle Zeilen, die mit "EVENTS_PUSH" oder "CELERY" beginnen, können auskommentiert werden, lediglich

<syntaxhighlight lang=python>
CELERY_ENABLED = False
</syntaxhighlight>

sollte gesetzt werden.

Zum Schluss ist bei mir konfiguriert:

<syntaxhighlight lang=python>
PUBLIC_REGISTER_ENABLED = True
USER_EMAIL_ALLOWED_DOMAINS = "hs-example.de"
</syntaxhighlight>

und

<syntaxhighlight lang=python>
ENABLE_TELEMETRY = False
</syntaxhighlight>

Falls man aber auch Benutzer von anderen E-Mail Domains erlauben möchte, muss man diese in <code>USER_EMAIL_ALLOWED_DOMAINS</code> hinzufügen, oder wenn man gar keine Beschränkung möchte, diese Zeile ganz auskommentieren. Das macht zum Beispiel Sinn, wenn <code>PUBLIC_REGISTER_ENABLED</code> abgeschaltet ist.

Nun werden mit den folgenden Kommandos die Datenverzeichnisse angelegt

<syntaxhighlight lang=shell>
cd ~
mkdir data
mkdir data/static
mkdir data/media
</syntaxhighlight>

Und die initialen Daten in die Datenbank geladen

<syntaxhighlight lang=shell>
cd ~/taiga-back
source .venv/bin/activate
(taiga-back) DJANGO_SETTINGS_MODULE=settings.config python manage.py migrate --noinput
(taiga-back) CELERY_ENABLED=False DJANGO_SETTINGS_MODULE=settings.config python manage.py createsuperuser
(taiga-back) DJANGO_SETTINGS_MODULE=settings.config python manage.py loaddata initial_project_templates
(taiga-back) DJANGO_SETTINGS_MODULE=settings.config python manage.py compilemessages
(taiga-back) DJANGO_SETTINGS_MODULE=settings.config python manage.py collectstatic --noinput
</syntaxhighlight>

An dieser Stelle können wir den Server testweise starten

<syntaxhighlight lang=shell>
DJANGO_SETTINGS_MODULE=settings.config python manage.py runserver
</syntaxhighlight>

Und in einer anderen Shell die API abfragen. Das Kommando

<syntaxhighlight lang=shell>
curl http://localhost:8000/api/v1/
</syntaxhighlight>

liefert eine JSON-Datenstruktur mit der API-Definition. Den Server kann man mit "Ctrl-C" wieder beenden.

Nun wird die Anwendung im Apache Webserver konfiguriert. Im Domain-Verzeichnis "~/doms/projekte.hs-example.de/" wird eine Datei ".htaccess" mit der Passenger-Konfiguration abgelegt:

<syntaxhighlight lang=apache>
SetEnv PYTHONPATH /home/pacs/xyz00/users/taiga-back
SetEnv PATH /home/pacs/xyz00/users/taiga-back/.venv/bin:%{ENV:PATH}
SetEnv DJANGO_SETTINGS_MODULE settings.config
</syntaxhighlight>

Die Verzeichnisse "subs/www", "subs-ssl/www" und "htdocs-ssl" werden gelöscht.
In "app-ssl" wird eine Datei "passenger_wsgi.py" mit folgendem Inhalt abgelegt:

<syntaxhighlight lang=python>
from taiga.wsgi import application
</syntaxhighlight>

An dieser Stelle sollte sich die Backend-API auch im Browser unter der URL "https://projekte.hs-example.de/api/v1/" aufrufen lassen. Unter "https://projekte.hs-example.de/admin/" ist eine Anmeldung mit dem angelegten Admin-Account im Django-Backend möglich.

== Einrichtung der Benachrichtigungen per E-Mail ==
Es kann ein Systemd Timer eingerichtet werden, der alle paar Minuten prüft, ob Benachrichtigungen per E-Mail hinausgeschickt werden sollen.

<code>~/.config/systemd/user/taiga_mails.service</code>
<syntaxhighlight lang=ini>
[Unit]
Description=send mails from taiga

[Service]
WorkingDirectory=/home/pacs/xyz00/users/taiga/taiga-back
Type=oneshot
ExecStart=.venv/bin/python3 manage.py send_notifications --settings=settings.config
</syntaxhighlight>

<code>~/.config/systemd/user/taiga_mails.timer</code>
<syntaxhighlight lang=ini>
[Unit]
Description=send mails from taiga

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

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

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

Die Absenderadresse wird übrigens am besten in der Datei <code>taiga-back/settings/config.py</code> in der Variable <code>DEFAULT_FROM_EMAIL</code> eingetragen.

== Installation des Frontend ==

Auschecken von Github:

<syntaxhighlight lang=shell>
cd ~
git clone https://github.com/kaleidos-ventures/taiga-front-dist.git taiga-front-dist
cd ~/taiga-front-dist
git checkout stable
</syntaxhighlight>

Konfiguration

<syntaxhighlight lang=shell>
cd ~/taiga-front-dist/dist
cp conf.example.json conf.json
</syntaxhighlight>

In "conf.json" muss der Wert "api" angepasst werden, ggf. kann die Default-Sprache auf "de" geändert werden.

<syntaxhighlight lang=json>
"api": "https://projekte.hs-example.de/api/v1/",
"defaultLanguage": "de",
</syntaxhighlight>

Im Domainverzeichnis werden zum Abschluss Links für die statischen Inhalte gesetzt:

<syntaxhighlight lang=shell>
cd ~/doms/projekte.hs-example.de/
ln -s $HOME/taiga-front-dist/dist htdocs-ssl
cd htdocs-ssl
ln -s $HOME/data/media media
ln -s $HOME/data/static static
</syntaxhighlight>

Zum Schluss wird in diesem Verzeichnis "htdocs-ssl" noch eine Datei ".htaccess" mit dem folgenden Inhalt angelegt:

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

RewriteCond %{REQUEST_URI} !^/api(.*)
RewriteCond %{REQUEST_URI} !^/admin(.*)
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule ^(.*) /index.html
</syntaxhighlight>

== Theme anpassen ==

Falls ein paar Sachen über CSS abgeschaltet oder anders dargestellt werden sollen, gibt es die Möglichkeit, eine eigene CSS einzubinden. Dazu muss in der Datei <code>~/taiga-front-dist/dist/index.html</code> folgende Zeile eingefügt werden (diese Zeile muss nach einem Update von Taiga wieder erneut eingetragen werden):

<syntaxhighlight lang=html>
<link rel="stylesheet" href="/v-1618228552362/styles/mytheme.css">
</syntaxhighlight>
Die Datei <code>taiga-front-dist/dist/v-1618228552362/styles/mytheme.css</code> kann z.B. folgenden Inhalt haben:

<syntaxhighlight lang=css>
/* disable the search bar, and the empty highlighted project div on the discover page, before login */
section.discover tg-discover-search-bar, div.empty-highlighted-project {
display: None;
}

/* hide the "New Project Button" */
.navbar-dropdown a.create-project-btn, .project-list-wrapper .create-project-btn {
display: None;
}
</syntaxhighlight>

== Weitere Optionen zur Einrichtung ==
Falls die Registrierung von neuen Benutzern nicht jedem offen stehen sollte, müssen 2 Änderungen vorgenommen werden:
* in der Datei <code>taiga-back/settings/config.py</code> muss <code>PUBLIC_REGISTER_ENABLED = False</code> eingetragen werden.
* in der Datei <code>taiga-front-dist/dist/conf.json</code> muss <code>"publicRegisterEnabled": false,</code> eingetragen werden.
* siehe auch https://docs.taiga.io/setup-faqs.html#disable-registration

== Import von Trello Boards ==
siehe die Anleitung hier: https://docs.taiga.io/importers.html#_trello

In Kurzform:
* Bei Trello anmelden
* auf https://trello.com/power-ups/admin/ gehen
* dort eine neue Integration anlegen: https://trello.com/power-ups/admin/new
* die Namen sind nicht so wichtig, die Iframe-Konnektor-URL kann leer gelassen werden.
* Dann im Menü auf "API Schlüssel" gehen
* Dort den "API-Schlüssel" kopieren
* Dann bei "Erlaubte Ursprünge" die eigene URL (mit https://) von Taiga hinzufügen
* Und den Schlüssel unter "Geheim" kopieren

Dann mit dem nano Editor die folgende Datei bearbeiten:

<syntaxhighlight lang=shell>
nano taiga-back/settings/config.py
</syntaxhighlight>

Diese Zeilen einfügen:

<syntaxhighlight lang=python>
IMPORTERS["trello"] = {
"active": True,
"api_key": "dein-API-schlüssel",
"secret_key": "dein-geheimer-schlüssel"
}
</syntaxhighlight>

Dann Taiga neustarten:

<syntaxhighlight lang=shell>
~/bin/restart.sh
</syntaxhighlight>

Dann noch die folgende Datei bearbeiten:

<syntaxhighlight lang=shell>
nano taiga-front-dist/dist/conf.json
</syntaxhighlight>

und den Wert bei <code>enableTrelloImporter</code> auf <code>true</code> setzen.

= Taiga mit Ansible installieren =

Alternativ lässt sich Taiga auch mit einem Ansible Skript bei Hostsharing installieren.
Damit lassen sich die Installationsschritte automatisiert durchführen.

Die Quellen für das Ansible Skript können hier eingesehen werden: https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/taiga

Dort ist auch eine README Datei mit einer Anleitung.

= Links =

* [https://resources.taiga.io/ Taiga Support Seite]
* [https://www.taiga.io/ Taiga Homepage]
* [https://docs.taiga.io/setup-production.html#_introduction Installationsanleitung (from Source Code)]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/taiga Ansible Playbook für Hostsharing]

[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Python]]
[[Kategorie:Django]]
[[Kategorie:Passenger]]
[[Kategorie:Projektmanagement]]
[[Kategorie:Projektverwaltung]]

Mastodon bei Hostsharing

2024-12-03T14:37:45Z

Cds09: /* Cronjobs */

Mastodon ist ein verteilter Microblogging Dienst, der das ActivityPub-Protokoll verwendet.

Wenn man nur wenige Nutzer oder gar nur für sich selbst einen Einstiegspunkt ins "Fediverse" schaffen will, kann sich auch die Ressourcen-schonende Alternative [[Pleroma]] anbieten.

Diese Anleitung beschreibt, wie man Mastodon auf der Managed Hosting Plattform von Hostsharing installieren kann.

Hostsharing selbst nutzt die Hosting Plattform und betreibt zwei Mastodon Instanzen:
* https://geno.social
* https://hostsharing.coop

Der Autor dieser Seite betreibt:
* https://krefeld.life

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

== Vorbereitungen ==

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

Verwendete IP-Ports der Server-Dienste:
# Redis: localhost:32002
# Mastodon-Web: localhost:32003
# Mastodon-Streaming: localhost:32004

== Konfiguration des Redis Server ==

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

<syntaxhighlight lang="ini" line>
daemonize yes
pidfile /home/pacs/xyz00/users/mastodon/redis/var/redis-server.pid
requirepass <hierhin-gehoert-ein-redis-passwort>
port 32002
tcp-backlog 128
bind 127.0.0.1
timeout 300
loglevel notice
logfile /home/pacs/xyz00/users/mastodon/redis/var/redis.log
databases 16
save 900 1
save 300 10
save 60 10000
slave-serve-stale-data yes
appendonly no
dbfilename dump.rdb
dir /home/pacs/xyz00/users/mastodon/redis/var
</syntaxhighlight>

== Installation von NodeJS ==

Als User 'xyz00-mastodon'': Installation von ''nvm'' und ''nodejs'' (Version 20) nach der Anleitung [[NodeJS]]

Installation von ''yarn'' mit:

<syntaxhighlight lang="bash">
npm install -g yarn
</syntaxhighlight>

== Installation von Ruby ==

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

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

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

starte neue Shell:

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

Überprüfe rbenv-Installation

<syntaxhighlight lang="bash">
type rbenv
</syntaxhighlight>

Installiere ruby-build als rbenv-Plugin

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

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

<syntaxhighlight lang="bash">
rbenv install 3.2.3
</syntaxhighlight>

== Installation der Mastodon Software ==

Weiterhin Als User ''xyz00-mastodon'':

<syntaxhighlight lang="bash">
cd ~
git clone https://github.com/tootsuite/mastodon.git live
cd ~/live
</syntaxhighlight>

Die stabile Version auschecken:

<syntaxhighlight lang="bash">
git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)
</syntaxhighlight>

Ruby Pakete installieren:

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

Node.js Pakete installieren:

<syntaxhighlight lang="bash">
yarn install --pure-lockfile
</syntaxhighlight>

== Konfiguration der Mastodon Software ==

Anlegen einer Datei ''/home/pacs/xyz00/users/mastodon/live/.env.production'' mit dem folgenden Inhalt:

<syntaxhighlight lang=ini line>
REDIS_HOST=localhost
REDIS_PORT=32002
REDIS_PASSWORD=<hierhin-gehoert-ein-redis-passwort>
DB_HOST=localhost
DB_USER=xyz00_mastuser
DB_NAME=xyz00_mastdb
DB_PASS=meinPasswort
DB_PORT=5432
LOCAL_DOMAIN=beispiel.social
SECRET_KEY_BASE=12ab..
OTP_SECRET=34ef..
VAPID_PRIVATE_KEY=ABCD..
VAPID_PUBLIC_KEY=EFGH..
DEFAULT_LOCALE=de
SMTP_SERVER=localhost
SMTP_PORT=25
SMTP_FROM_ADDRESS=notifications@beispiel.social
SMTP_AUTH_METHOD=none
SMTP_OPENSSL_VERIFY_MODE=none
STREAMING_CLUSTER_NUM=1
</syntaxhighlight>

Die Zufallswerte für die Variablen SECRET_KEY_BASE und OTP_SECRET erzeugt man durch zwei Aufrufe des Kommandos

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

Die Werte für VAPID_PRIVATE_KEY und VAPID_PUBLIC_KEY erzeugt das Kommando

<syntaxhighlight lang="bash">
RAILS_ENV=production bundle exec rake mastodon:webpush:generate_vapid_key
</syntaxhighlight>

Initialisieren der Datenbank:

<syntaxhighlight lang="bash">
export SAFETY_ASSURED=1
RAILS_ENV=production bundle exec rails db:schema:load
RAILS_ENV=production bundle exec rails db:seed
</syntaxhighlight>

Erzeugen der Web-Resourcen

<syntaxhighlight lang="bash">
yarn set version classic
RAILS_ENV=production bundle exec rails assets:precompile
</syntaxhighlight>

== Starten der Dienste ==

Zum Start aller notwendigen Dienste wird in dieser Anleitung ''systemctl'' benutzt.

Die Datei <code>~/.config/systemd/user/redis.service</code> kann so aussehen:

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

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

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

Die Datei <code>~/.config/systemd/user/puma.service</code> kann so aussehen:

<syntaxhighlight lang=shell line>
[Unit]
Description=Mastodon Web Service Puma
After=redis.service

[Service]
WorkingDirectory=%h/live
Environment="RAILS_ENV=production"
ExecStart=%h/.rbenv/shims/bundle exec puma -C config/puma.rb -e production -b tcp://127.0.0.1:32003
StandardError=append:%h/var/log/puma.log
StandardOutput=append:%h/var/log/puma.log
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Die Datei <code>~/.config/systemd/user/sidekiq.service</code> kann so aussehen:

<syntaxhighlight lang=shell line>
[Unit]
Description=Mastodon Sidekiq Service
After=redis.service

[Service]
WorkingDirectory=%h/live
Environment="RAILS_ENV=production"
Environment="DB_POOL=5"
ExecStart=%h/.rbenv/shims/bundle exec sidekiq -c 5 -q default -q mailers -q pull -q push -q scheduler
StandardError=append:%h/var/log/sidekiq.log
StandardOutput=append:%h/var/log/sidekiq.log
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Die Datei <code>~/.config/systemd/user/streaming.service</code> kann so aussehen:

<syntaxhighlight lang=shell line>
[Unit]
Description=Mastodon Streaming Service
After=redis.service

[Service]
WorkingDirectory=%h/live
Environment="NVM_DIR=%h/.nvm"
Environment="NVM_BIN=%h/.nvm/versions/node/v20.14.0/bin"
Environment="NODE_ENV=production"
Environment="PORT=32004"
Environment="BIND=127.0.0.1"

ExecStart=%h/.nvm/versions/node/v20.14.0/bin/node streaming/index.js
StandardError=append:%h/var/log/streaming.log
StandardOutput=append:%h/var/log/streaming.log
Restart=always
PrivateTmp=true
NoNewPrivileges=true

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

Die Dienste werden dann aktiviert und gestartet:
<syntaxhighlight lang=shell line>
systemctl --user enable redis --now
systemctl --user enable puma --now
systemctl --user enable streaming --now
systemctl --user enable sidekiq --now
</syntaxhighlight>

== Einrichten des Apache VHost ==

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

Dann die ''htdocs-ssl/.htaccess'' mit dem Editor der Wahl öffnen und
folgende Konfiguration einfügen:

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_URI} ^/api/v1/streaming [NC]
RewriteRule .* ws://localhost:32004%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteRule .* http://localhost:32003%{REQUEST_URI} [proxy]
RequestHeader set X-Forwarded-Proto "https"
</syntaxhighlight>

== Systemd Timer ==

Mit einem systemd Timer werden alte Ressourcen aufgeräumt.

<code>~/.config/systemd/user/mastodon_cleanup.env</code>
<syntaxhighlight lang=bash line>
HOME=/home/pacs/xyz00/users/mastodon
MAILTO=mastodon@beispiel.social
RAILS_ENV=production
NUM_DAYS=31
</syntaxhighlight>

<code>~/.config/systemd/user/mastodon_cleanup.service</code>
<syntaxhighlight lang=ini line>
[Unit]
Description=fetch mail from remote server

[Service]
EnvironmentFile=/home/pacs/xyz00/users/mastodon/.config/systemd/user/mastodon_cleanup.env
WoringDirectory=/home/pacs/xyz00/users/mastodon/live
Type=oneshot
ExecStart=/home/pacs/xyz00/users/mastodon/live/bin/tootctl media remove
</syntaxhighlight>

<code>~/.config/systemd/user/mastodon_cleanup.timer</code>
<syntaxhighlight lang=ini line>
[Unit]
Description=fetch mail every five minutes

[Timer]
OnCalendar=4:18
Persistent=True

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

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

== Volltextsuche ==

In der installierten Version gibt es noch keine Volltextsuche. Es kann lediglich nach Nutzerkennungen und Hastags gesucht werden. Für die Volltextsuche kann optional Elasticsearch installiert werden.

* [[Elasticsearch]] bei Hostsharing
* https://docs.joinmastodon.org/admin/optional/elasticsearch/

== Instanz einrichten ==
Nach der Installation kann man sich auf https://beispiel.social einen Benutzer einrichten.

Auf der Kommandozeile:

<syntaxhighlight lang="bash">
RAILS_ENV=production bin/tootctl accounts create \
alice \
--email alice@example.com \
--confirmed \
--role Admin
</syntaxhighlight>

Weitere Einrichtung sollte vorgenommen werden, z.B. eine Beschreibung der Instanz hinterlegen, siehe https://docs.joinmastodon.org/admin/setup/

== Mastodon Updates ==

siehe:
* https://github.com/tootsuite/mastodon/releases

(hier für das Update auf die Mastodon Version v4.2.9 mit Ruby 3.2.3)

=== Ruby ===

<syntaxhighlight lang="bash">
cd ~/.rbenv
git pull
cd ~/.rbenv/plugins/ruby-build
git pull
cd
rbenv install -l
rbenv install 3.2.3
rbenv global 3.2.3
</syntaxhighlight>

=== Mastodon ===

<syntaxhighlight lang="bash">
cd ~/mastodon/live
git fetch
git checkout v4.2.9
gem update --system
bundle install
yarn install
RAILS_ENV=production bundle exec rails db:migrate
yarn set version classic
RAILS_ENV=production bundle exec rails assets:precompile
</syntaxhighlight>

Restart Mastodon!

== Links ==

* [https://joinmastodon.org/ Offizielle Webseite von Mastodon]
* im Archiv: https://github.com/mastodon/documentation/blob/archive/Running-Mastodon/Production-guide.md
* aktuell: https://docs.joinmastodon.org/admin/install/
* https://krinetzki.de/2017/04/installation-von-mastodon-auf-debian-8-jessie/
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/mastodon Ansible Playbook für Hostsharing]

[[Kategorie:Installationsanleitungen]]
[[Kategorie:Fediverse]]
[[Kategorie:Activitypub]]
[[Kategorie:Ansible Playbook]]

Tryton installieren

2024-12-03T14:16:03Z

Cds09: /* Einrichten des systemd Timers */

== Allgemein ==
=== Beschreibung ===
[https://www.tryton.org/ Tryton] ist eine freie Software für das Enterprise-Resource-Planning (ERP).

Tryton lässt sich über den Web-Browser bedienen, oder über einen Desktop Client (Windows, Linux, MacOS).

Tryton läuft mit Python und PostgreSQL oder SQLite, und lässt sich auf Linux, MacOS und Windows betreiben.

Tryton steht unter der GPLv3 Lizenz. Die Rechte an der Marke Tryton gehören der gemeinnützigen Tryton-Stiftung mit Sitz in Belgien.

== Installation ==

=== Design ===

Diese Installationsanleitung beschreibt, wie Tryton in einer eigens dafür [[Domainverwaltung#Lokale_Subdomains_durch_Aufschalten.3B_Delegieren|aufgeschalteten Subdomain]] über SSL betrieben wird.

Der Vorteil einer Installation in einer aufgeschalteten Subdomain ist, daß die Installation leicht von anderen Domaininhalten, Passenger-Konfigurationen, oder sogar von anderen Domain-Administratoren, isoliert werden kann.

=== Subdomain aufschalten ===

Im Folgenden werden folgende Domainkonfigurationsdaten als Beispiel verwendet:

{| class="wikitable"
|- class="hintergrundfarbe5"
! Typ !! Wert !! Beschreibung
|-
| Subdomain || <tt>tryton.example.org</tt> || Die Subdomain, unter der eine Tryton-Instanz laufen soll
|-
| Domain-Admin || <tt>xyz00-hans</tt> || Der User, dem die Subdomain delegiert wurde
|}

=== PostgreSQL vorbereiten ===

Tryton benötigt eine PostgreSQL-Datenbank sowie einen Datenbanknutzer.

Die Tabellen werden später vom Installations-Werkzeug von Tryton eigenständig angelegt.

==== Datenbank und Datenbanknutzer anlegen ====

In dieser Anleitung werden folgende Namen für die Datenbank und deren Nutzer verwendet. Das Paket-Kürzel <tt>xyz00</tt> ist natürlich durch das des betreffenden Pakets zu ersetzen.

{| class="wikitable"
|- class="hintergrundfarbe5"
! Typ !! Wert !! Beschreibung
|-
| DB-Nutzer || <tt>xyz00_tryton</tt> || Der PostgreSQL-Nutzer, dem die Datenbank gehört und der administrative Tätigkeiten durchführt und dann auch im Betrieb genutzt wird.
|-
|-
| Datenbank || <tt>xyz00_tryton</tt> || Die PostgreSQL-Datenbank, die die Daten von Tryton enthält.
|}

Der Nutzer und die Datenbank können über die Weboberfläche auf [https://admin.hostsharing.net/ https://admin.hostsharing.net] oder über die Kommandozeile mit [[Hsadmin]] angelegt werden. Siehe dazu die Anleitungen auf der Seite [[PostgreSQL]] und [[Datenbanken]]. Diese Schritte müssen ggf. vom Paket-Admin vorgenommen werden.

Einrichtung über die Kommandozeile:

Mit dem Paketbenutzer (xyz00, nicht xyz00-hans) diese Befehle ausführen:

<syntaxhighlight lang=bash>
xyz00$ hsscript -u xyz00 -e "postgresqluser.add ({set:{name:'xyz00_tryton',password:'TopSecret:@0815'}})"
xyz00$ hsscript -u xyz00 -e "postgresqldb.add ({set:{name:'xyz00_tryton',owner:'xyz00_tryton'}})"
xyz00$ exit
</syntaxhighlight>

Das PostgreSQL Passwort muss später url-kodiert in die tryton.ini eingefügt werden, damit die Sonderzeichen keine Probleme machen.

<syntaxhighlight lang=bash>
$ python
Python 3.7.3 (default, Jan 22 2021, 20:04:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.parse
>>> query = 'TopSecret:@0815'
>>> urllib.parse.quote(query)
'TopSecret%3A%400815'
>>> exit()
</syntaxhighlight>

=== Installation von Tryton Core und ERP Modulen ===

Als Domain-Admin <tt>xyz00-hans</tt> folgende Schritte ausführen:

<syntaxhighlight lang=bash>
xyz00-hans$ mkdir ~/tryton
xyz00-hans$ cd ~/tryton
xyz00-hans$ python3 -m venv .venv
xyz00-hans$ source .venv/bin/activate
(.venv) xyz00-hans$ pip install wheel
(.venv) xyz00-hans$ pip install trytond
(.venv) xyz00-hans$ # die Unterstützung für PostgreSQL installieren
(.venv) xyz00-hans$ pip install psycopg2
(.venv) xyz00-hans$ # ein ERP Module installieren
(.venv) xyz00-hans$ pip install trytond_sale
</syntaxhighlight>

Weitere ERP Module sind hier zu finden: [http://hg.tryton.org/modules Tryton Module]

=== Installation von Node ===

Für die Installation des Web Clients wird Node benötigt.

Als Domain-Admin <tt>xyz00-hans</tt> folgende Schritte ausführen:

<syntaxhighlight lang=bash>
xyz00-hans$ git clone https://github.com/OiNutter/nodenv.git ~/.nodenv
xyz00-hans$ echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.profile
xyz00-hans$ echo 'eval "$(nodenv init -)"' >> ~/.profile
xyz00-hans$ source ~/.profile
xyz00-hans$ git clone git://github.com/OiNutter/node-build.git ~/.nodenv/plugins/node-build
xyz00-hans$ nodenv install 12.18.4
xyz00-hans$ nodenv rehash
xyz00-hans$ nodenv global 12.18.4
</syntaxhighlight>

Ein Test mit ''node --version'' solte anzeigen: v12.18.4

=== Installation des Web Clients ===

Jetzt soll der Web Client eingerichtet werden.

Als Domain-Admin <tt>xyz00-hans</tt> folgende Schritte ausführen:

<syntaxhighlight lang=bash>
xyz00-hans$ cd ~/tryton
xyz00-hans$ git clone --single-branch --branch 6.2 https://github.com/tryton/sao.git
xyz00-hans$ cd sao
xyz00-hans$ source ~/.profile
xyz00-hans$ npm install bower --legacy-peer-deps
xyz00-hans$ npm install po2json --legacy-peer-deps
xyz00-hans$ npm install grunt-po2json --legacy-peer-deps
xyz00-hans$ npm install --production --legacy-peer-deps
xyz00-hans$ npm install grunt --legacy-peer-deps
xyz00-hans$ node_modules/grunt/bin/grunt
</syntaxhighlight>

=== Konfigurationsdateien einrichten ===

Nun muss noch eine Konfigurationsdatei angelegt werden:

<syntaxhighlight lang=bash>
xyz00-hans$ nano ~/tryton/tryton.ini
</syntaxhighlight>

Die Datei sollte diesen Inhalt haben. Hier muss das url-kodierte PostgreSQL Passwort von oben eingefügt werden.

<syntaxhighlight lang=ini line>
[database]
uri = postgresql://xyz00_tryton:TopSecret%3A%400815@localhost/
path = /home/pacs/xyz00/users/hans/tryton

[web]
root = /home/pacs/xyz00/users/hans/tryton/sao
hostname = tryton.example.org
</syntaxhighlight>

Des weiteren sollte eine Konfigurationsdatei für das Logging angelegt werden:

<syntaxhighlight lang=bash>
xyz00-hans$ nano ~/tryton/logging.ini
</syntaxhighlight>

Die Datei sollte diesen Inhalt haben:

<syntaxhighlight lang=ini line>
[formatters]
keys=simple

[handlers]
keys=rotate,console

[loggers]
keys=root

[formatter_simple]
format=%(asctime)s] %(levelname)s:%(name)s:%(message)s
datefmt=%a %b %d %H:%M:%S %Y

[handler_rotate]
class=handlers.TimedRotatingFileHandler
args=('/home/pacs/xyz00/users/hans/tryton/tryton.log', 'D', 1, 30)
formatter=simple

[handler_console]
class=StreamHandler
formatter=simple
args=(sys.stdout,)

[logger_root]
level=ERROR
handlers=rotate,console
</syntaxhighlight>

Weitere Logging Levels sind hier zu finden: [https://docs.python.org/3/library/logging.html#logging-levels Tryton Logging Levels], z.B. CRITICAL, ERROR, WARNING, INFO, DEBUG

=== Einrichten der Instanz ===

Jetzt kann die Instanz eingerichtet werden.

Hier muss man interaktiv für den Benutzer admin eine E-Mail Adresse angeben und das Passwort setzen, und es werden automatisiert die Tabellen in der Datenbank eingerichtet.

<syntaxhighlight lang=bash>
xyz00-hans$ cd ~/tryton
xyz00-hans$ source .venv/bin/activate
xyz00-hans$ python ./.venv/bin/trytond-admin -c tryton.ini -d xyz00_tryton --all
</syntaxhighlight>

=== Einrichten des systemd Timers ===

Falls geplante Aufgaben ausgeführt werden sollen, muss der systemd Timer folgendermaßen eingerichtet werden:
~/bin/tryton_planned.sh
<syntaxhighlight lang=bash>
#! /usr/bin/env bash

cd ~/tryton
source .venv/bin/activate
python .venv/bin/trytond-cron -c tryton.ini -d xyz00_tryton --once
</syntaxhighlight>

~/.config/systemd/user/tryton_planned.service
<syntaxhighlight lang=ini>
[Unit]
Description=tryton planned jobs

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/hans//bin/tryton_planned.sh
</syntaxhighlight>

~/.config/systemd/user/tryton_planned.timer
<syntaxhighlight lang=ini>
[Unit]
Description=tryton planned jobs

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

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

Timer aktivieren und starten:
<syntaxhighlight lang=bash>
$ chmod +x ~/bin/tryton_planned.sh
$ systemctl --user enable tryton_planned.timer
$ systemctl --user start tryton_planned.timer
</syntaxhighlight>

Das *:0/5 bedeutet, dass der Timer alle 5 Minuten ausgeführt wird.

=== Einrichten der Webseite ===

<syntaxhighlight lang=bash>
xyz00-hans$ cd ~/doms/tryton.example.org/
xyz00-hans$ rm -Rf htdocs-ssl
xyz00-hans$ ln -s ~/tryton/sao/ htdocs-ssl
</syntaxhighlight>

Es muss diese Datei .htaccess angelegt werden:

<syntaxhighlight lang=bash>
xyz00-hans$ nano ~/doms/tryton.example.org/.htaccess
</syntaxhighlight>

Die Datei sollte diesen Inhalt haben.

<syntaxhighlight lang=apache>
PassengerPython /home/pacs/xyz00/users/hans/tryton/.venv/bin/python
SetEnv PYTHONPATH /home/pacs/xyz00/users/hans/tryton/.venv/lib/python3.7/site-packages/trytond
SetEnv TRYTOND_CONFIG /home/pacs/xyz00/users/hans/tryton/tryton.ini
SetEnv TRYTOND_LOGGING_CONFIG /home/pacs/xyz00/users/hans/tryton/logging.ini
</syntaxhighlight>

Dann noch diese Datei anlegen:

<syntaxhighlight lang=bash>
xyz00-hans$ nano ~/doms/tryton.example.org/app-ssl/passenger_wsgi.py
</syntaxhighlight>

Mit diesem Inhalt:

<syntaxhighlight lang=python>
from trytond.application import app as application
</syntaxhighlight>

== Erste Schritte ==

Nun ist der Web Client von Tryton auf https://tryton.example.org erreichbar.

Die Datenbank xyz00_tryton ist voreingestellt.

Man meldet sich mit dem Benutzer <code>admin</code> und dem vorhin konfigurierten Passwort an.

Hier könnte noch beschrieben werden, wie man Benutzer anlegt, die Buchhaltung einrichtet usw. Aber das würde den Rahmen dieser Installationsanwendung sprengen...

== Tryton Fat Client ==

Neben dem Web Client gibt es auch den lokal laufenden Client (aka Fat Client).

Für Windows oder MacOS kann der Fat Client über einen Installer installiert werden, siehe https://www.tryton.org/download#desktop-client

Unter einem beliebigen Linux Desktop kann er über die folgenden Befehle installiert und gestartet werden:

<syntaxhighlight lang="bash">
python3 -m venv .venv
source .venv/bin/activate
pip install tryton
python .venv/bin/tryton
</syntaxhighlight>

Beim Fat Client muss man folgenden Wert beim Host angeben: <code>tryton.example.org:443</code>
und dann noch die entsprechende Datenbank: <code>xyz00_tryton</code>

== Links ==

*[https://www.tryton.org/ Tryton Webseite]
*[https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/tryton Ansible Playbook für Hostsharing]
----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:ERP]]
[[Kategorie:CRM]]
[[Kategorie:Python]]

Tryton installieren

2024-12-03T14:15:18Z

Cds09: /* Einrichten des Cronjobs */

== Allgemein ==
=== Beschreibung ===
[https://www.tryton.org/ Tryton] ist eine freie Software für das Enterprise-Resource-Planning (ERP).

Tryton lässt sich über den Web-Browser bedienen, oder über einen Desktop Client (Windows, Linux, MacOS).

Tryton läuft mit Python und PostgreSQL oder SQLite, und lässt sich auf Linux, MacOS und Windows betreiben.

Tryton steht unter der GPLv3 Lizenz. Die Rechte an der Marke Tryton gehören der gemeinnützigen Tryton-Stiftung mit Sitz in Belgien.

== Installation ==

=== Design ===

Diese Installationsanleitung beschreibt, wie Tryton in einer eigens dafür [[Domainverwaltung#Lokale_Subdomains_durch_Aufschalten.3B_Delegieren|aufgeschalteten Subdomain]] über SSL betrieben wird.

Der Vorteil einer Installation in einer aufgeschalteten Subdomain ist, daß die Installation leicht von anderen Domaininhalten, Passenger-Konfigurationen, oder sogar von anderen Domain-Administratoren, isoliert werden kann.

=== Subdomain aufschalten ===

Im Folgenden werden folgende Domainkonfigurationsdaten als Beispiel verwendet:

{| class="wikitable"
|- class="hintergrundfarbe5"
! Typ !! Wert !! Beschreibung
|-
| Subdomain || <tt>tryton.example.org</tt> || Die Subdomain, unter der eine Tryton-Instanz laufen soll
|-
| Domain-Admin || <tt>xyz00-hans</tt> || Der User, dem die Subdomain delegiert wurde
|}

=== PostgreSQL vorbereiten ===

Tryton benötigt eine PostgreSQL-Datenbank sowie einen Datenbanknutzer.

Die Tabellen werden später vom Installations-Werkzeug von Tryton eigenständig angelegt.

==== Datenbank und Datenbanknutzer anlegen ====

In dieser Anleitung werden folgende Namen für die Datenbank und deren Nutzer verwendet. Das Paket-Kürzel <tt>xyz00</tt> ist natürlich durch das des betreffenden Pakets zu ersetzen.

{| class="wikitable"
|- class="hintergrundfarbe5"
! Typ !! Wert !! Beschreibung
|-
| DB-Nutzer || <tt>xyz00_tryton</tt> || Der PostgreSQL-Nutzer, dem die Datenbank gehört und der administrative Tätigkeiten durchführt und dann auch im Betrieb genutzt wird.
|-
|-
| Datenbank || <tt>xyz00_tryton</tt> || Die PostgreSQL-Datenbank, die die Daten von Tryton enthält.
|}

Der Nutzer und die Datenbank können über die Weboberfläche auf [https://admin.hostsharing.net/ https://admin.hostsharing.net] oder über die Kommandozeile mit [[Hsadmin]] angelegt werden. Siehe dazu die Anleitungen auf der Seite [[PostgreSQL]] und [[Datenbanken]]. Diese Schritte müssen ggf. vom Paket-Admin vorgenommen werden.

Einrichtung über die Kommandozeile:

Mit dem Paketbenutzer (xyz00, nicht xyz00-hans) diese Befehle ausführen:

<syntaxhighlight lang=bash>
xyz00$ hsscript -u xyz00 -e "postgresqluser.add ({set:{name:'xyz00_tryton',password:'TopSecret:@0815'}})"
xyz00$ hsscript -u xyz00 -e "postgresqldb.add ({set:{name:'xyz00_tryton',owner:'xyz00_tryton'}})"
xyz00$ exit
</syntaxhighlight>

Das PostgreSQL Passwort muss später url-kodiert in die tryton.ini eingefügt werden, damit die Sonderzeichen keine Probleme machen.

<syntaxhighlight lang=bash>
$ python
Python 3.7.3 (default, Jan 22 2021, 20:04:44)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib.parse
>>> query = 'TopSecret:@0815'
>>> urllib.parse.quote(query)
'TopSecret%3A%400815'
>>> exit()
</syntaxhighlight>

=== Installation von Tryton Core und ERP Modulen ===

Als Domain-Admin <tt>xyz00-hans</tt> folgende Schritte ausführen:

<syntaxhighlight lang=bash>
xyz00-hans$ mkdir ~/tryton
xyz00-hans$ cd ~/tryton
xyz00-hans$ python3 -m venv .venv
xyz00-hans$ source .venv/bin/activate
(.venv) xyz00-hans$ pip install wheel
(.venv) xyz00-hans$ pip install trytond
(.venv) xyz00-hans$ # die Unterstützung für PostgreSQL installieren
(.venv) xyz00-hans$ pip install psycopg2
(.venv) xyz00-hans$ # ein ERP Module installieren
(.venv) xyz00-hans$ pip install trytond_sale
</syntaxhighlight>

Weitere ERP Module sind hier zu finden: [http://hg.tryton.org/modules Tryton Module]

=== Installation von Node ===

Für die Installation des Web Clients wird Node benötigt.

Als Domain-Admin <tt>xyz00-hans</tt> folgende Schritte ausführen:

<syntaxhighlight lang=bash>
xyz00-hans$ git clone https://github.com/OiNutter/nodenv.git ~/.nodenv
xyz00-hans$ echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.profile
xyz00-hans$ echo 'eval "$(nodenv init -)"' >> ~/.profile
xyz00-hans$ source ~/.profile
xyz00-hans$ git clone git://github.com/OiNutter/node-build.git ~/.nodenv/plugins/node-build
xyz00-hans$ nodenv install 12.18.4
xyz00-hans$ nodenv rehash
xyz00-hans$ nodenv global 12.18.4
</syntaxhighlight>

Ein Test mit ''node --version'' solte anzeigen: v12.18.4

=== Installation des Web Clients ===

Jetzt soll der Web Client eingerichtet werden.

Als Domain-Admin <tt>xyz00-hans</tt> folgende Schritte ausführen:

<syntaxhighlight lang=bash>
xyz00-hans$ cd ~/tryton
xyz00-hans$ git clone --single-branch --branch 6.2 https://github.com/tryton/sao.git
xyz00-hans$ cd sao
xyz00-hans$ source ~/.profile
xyz00-hans$ npm install bower --legacy-peer-deps
xyz00-hans$ npm install po2json --legacy-peer-deps
xyz00-hans$ npm install grunt-po2json --legacy-peer-deps
xyz00-hans$ npm install --production --legacy-peer-deps
xyz00-hans$ npm install grunt --legacy-peer-deps
xyz00-hans$ node_modules/grunt/bin/grunt
</syntaxhighlight>

=== Konfigurationsdateien einrichten ===

Nun muss noch eine Konfigurationsdatei angelegt werden:

<syntaxhighlight lang=bash>
xyz00-hans$ nano ~/tryton/tryton.ini
</syntaxhighlight>

Die Datei sollte diesen Inhalt haben. Hier muss das url-kodierte PostgreSQL Passwort von oben eingefügt werden.

<syntaxhighlight lang=ini line>
[database]
uri = postgresql://xyz00_tryton:TopSecret%3A%400815@localhost/
path = /home/pacs/xyz00/users/hans/tryton

[web]
root = /home/pacs/xyz00/users/hans/tryton/sao
hostname = tryton.example.org
</syntaxhighlight>

Des weiteren sollte eine Konfigurationsdatei für das Logging angelegt werden:

<syntaxhighlight lang=bash>
xyz00-hans$ nano ~/tryton/logging.ini
</syntaxhighlight>

Die Datei sollte diesen Inhalt haben:

<syntaxhighlight lang=ini line>
[formatters]
keys=simple

[handlers]
keys=rotate,console

[loggers]
keys=root

[formatter_simple]
format=%(asctime)s] %(levelname)s:%(name)s:%(message)s
datefmt=%a %b %d %H:%M:%S %Y

[handler_rotate]
class=handlers.TimedRotatingFileHandler
args=('/home/pacs/xyz00/users/hans/tryton/tryton.log', 'D', 1, 30)
formatter=simple

[handler_console]
class=StreamHandler
formatter=simple
args=(sys.stdout,)

[logger_root]
level=ERROR
handlers=rotate,console
</syntaxhighlight>

Weitere Logging Levels sind hier zu finden: [https://docs.python.org/3/library/logging.html#logging-levels Tryton Logging Levels], z.B. CRITICAL, ERROR, WARNING, INFO, DEBUG

=== Einrichten der Instanz ===

Jetzt kann die Instanz eingerichtet werden.

Hier muss man interaktiv für den Benutzer admin eine E-Mail Adresse angeben und das Passwort setzen, und es werden automatisiert die Tabellen in der Datenbank eingerichtet.

<syntaxhighlight lang=bash>
xyz00-hans$ cd ~/tryton
xyz00-hans$ source .venv/bin/activate
xyz00-hans$ python ./.venv/bin/trytond-admin -c tryton.ini -d xyz00_tryton --all
</syntaxhighlight>

=== Einrichten des systemd Timers ===

Falls geplante Aufgaben ausgeführt werden sollen, muss der systemd Timer folgendermaßen eingerichtet werden:
~/bin/tryton_planned.sh
<syntaxhighlight lang=bash>
#! /usr/bin/env bash

cd ~/tryton
source .venv/bin/activate
python .venv/bin/trytond-cron -c tryton.ini -d xyz00_tryton --once
</syntaxhighlight>

~/.config/systemd/user/tryton_planned.service
<syntaxhighlight lang=ini>
[Unit]
Description=tryton planned jobs

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/hans//bin/tryton_planned.sh
</syntaxhighlight>

~/.config/systemd/user/tryton_planned.timer
<syntaxhighlight lang=ini>
[Unit]
Description=tryton planned jobs

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

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

Timer aktivieren und starten:
<syntaxhighlight lang=bash>
$ chmod +x ~/bin/tryton_planned.sh
$ systemctl --user enable tryton_planned.timer
$ systemctl --user start tryton_planned.timer
</syntaxhighlight>

Das *:0/5 bedeutet, dass der Cronjob alle 5 Minuten ausgeführt wird.

=== Einrichten der Webseite ===

<syntaxhighlight lang=bash>
xyz00-hans$ cd ~/doms/tryton.example.org/
xyz00-hans$ rm -Rf htdocs-ssl
xyz00-hans$ ln -s ~/tryton/sao/ htdocs-ssl
</syntaxhighlight>

Es muss diese Datei .htaccess angelegt werden:

<syntaxhighlight lang=bash>
xyz00-hans$ nano ~/doms/tryton.example.org/.htaccess
</syntaxhighlight>

Die Datei sollte diesen Inhalt haben.

<syntaxhighlight lang=apache>
PassengerPython /home/pacs/xyz00/users/hans/tryton/.venv/bin/python
SetEnv PYTHONPATH /home/pacs/xyz00/users/hans/tryton/.venv/lib/python3.7/site-packages/trytond
SetEnv TRYTOND_CONFIG /home/pacs/xyz00/users/hans/tryton/tryton.ini
SetEnv TRYTOND_LOGGING_CONFIG /home/pacs/xyz00/users/hans/tryton/logging.ini
</syntaxhighlight>

Dann noch diese Datei anlegen:

<syntaxhighlight lang=bash>
xyz00-hans$ nano ~/doms/tryton.example.org/app-ssl/passenger_wsgi.py
</syntaxhighlight>

Mit diesem Inhalt:

<syntaxhighlight lang=python>
from trytond.application import app as application
</syntaxhighlight>

== Erste Schritte ==

Nun ist der Web Client von Tryton auf https://tryton.example.org erreichbar.

Die Datenbank xyz00_tryton ist voreingestellt.

Man meldet sich mit dem Benutzer <code>admin</code> und dem vorhin konfigurierten Passwort an.

Hier könnte noch beschrieben werden, wie man Benutzer anlegt, die Buchhaltung einrichtet usw. Aber das würde den Rahmen dieser Installationsanwendung sprengen...

== Tryton Fat Client ==

Neben dem Web Client gibt es auch den lokal laufenden Client (aka Fat Client).

Für Windows oder MacOS kann der Fat Client über einen Installer installiert werden, siehe https://www.tryton.org/download#desktop-client

Unter einem beliebigen Linux Desktop kann er über die folgenden Befehle installiert und gestartet werden:

<syntaxhighlight lang="bash">
python3 -m venv .venv
source .venv/bin/activate
pip install tryton
python .venv/bin/tryton
</syntaxhighlight>

Beim Fat Client muss man folgenden Wert beim Host angeben: <code>tryton.example.org:443</code>
und dann noch die entsprechende Datenbank: <code>xyz00_tryton</code>

== Links ==

*[https://www.tryton.org/ Tryton Webseite]
*[https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/tryton Ansible Playbook für Hostsharing]
----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:ERP]]
[[Kategorie:CRM]]
[[Kategorie:Python]]

Gitea

2024-12-03T14:06:12Z

Cds09: /* Service einrichten */

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

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

Gitea

2024-12-03T14:05:40Z

Cds09: /* Service einrichten */

== 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=fetch mail from remote server

[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=fetch mail every five minutes

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

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

Mlmmj

2024-12-03T14:00:17Z

Cds09: /* Einrichtung */

[http://www.mlmmj.org/ mlmmj], angeblich eine Abkürzung für "Mailing List Management Made Joyful", ist ein Programm, mit dem in einem Hostsharing Paket E-Mail-Verteiler realisiert werden kann.

Wer noch nicht weiß, was ein E-Mail-Verteiler machen soll oder wie, lese vielleicht auch den Wikipedia-Artikel:
[http://de.wikipedia.org/wiki/Mailingliste Mailingliste]

Eine leistungsfähigere Alternative zu mlmmj könnte [[Mailman_3_installieren|Mailman 3]] sein.

Diese Anleitung beschreibt die Einrichtung einer Mailingliste für eine Domain in einem Hostsharing-Webspace.

== Voraussetzungen ==

Das Debian Paket [http://packages.debian.org/search?keywords=mlmmj mlmmj] ist auf den Shared-Hosting-Servern bereits installiert. (Wer die Software selbst kompilieren möchte kann aktuellen Source-Code bei [https://codeberg.org/mlmmj/mlmmj codeberg.org] finden.)

Für den Betrieb der Mailingliste empfiehlt sich das Anlegen eines eigenen Users für diesen Zweck mit hsadmin.

In dieser Anleitung heißt das Paket ''xyz00'' und der für Mailinglisten eingesetzte User ''xyz00-list''.

Die E-Mail-Adresse der einzurichtende Mailing-Liste soll ''discuss@example.org'' sein. Den lokalen Teil dieser Adresse, ''discuss'', ist der Listenname. Der Listenname darf auf keinen Fall das Plus-Zeichen (+) enthalten, weil dies ein Sonderbedeutung für die Listensteuerung hat: ''mlmmj'' wird nämlich Befehle der Abonnenten über erweiterte Adressen annehmen, wie z.B. ''discuss+help@example.org''.

Die Domain ''example.org'' muss dazu bei einem beliebigen User im Paket ''xyz00'' [[aufgeschaltet]] sein. ("Aufgeschaltet" bedeutet, daß diese Domain bei Hostsharing gehostet wird und der Domainname als Verzeichnis /home/pacs/xyz00/*User*/doms/example.org/ erscheint.)

== Einrichtung ==

Ich melde mich über SSH auf der Hostsharing-Console als der Paketuser ''xyz00'' an.

Im Shell kann ich dann durch den Befehl ''hsscript -i'' das Verwaltungswerkzeug [[hsadmin]] interaktiv ausführen:

<syntaxhighlight lang=shell>
xyz00@h03:~$ hsscript -i
Password: *************
xyz00@hsadmin>
</syntaxhighlight>

In ''hsadmin'' werden User und E-Mail-Adresse angelegt.

<syntaxhighlight lang=shell>
xyz00@hsadmin> user.add({set:{name:'xyz00-list',comment:'Mailingliste Discuss',shell:'/bin/bash',password:'geheimnis'}})
xyz00@hsadmin> emailaddress.add({set:{target:'xyz00-list',localpart:'discuss',domain:'example.org'}})
xyz00@hsadmin> bye
</syntaxhighlight>

Mit dem Parameter "target" wird die für diese Adresse eingehende Post zunächst in das Postfach des Users xyz00-list abgelegt.

Für den User xyz00-list lege ich in seinem Heimat-Verzeichnis das Unterverzeichnis <tt>mlmmj</tt> an:

<syntaxhighlight lang=shell>
mkdir /home/pacs/xyz00/users/list/mlmmj
</syntaxhighlight>

Dann lege ich die Mailingliste mit folgendem Kommando an:

<syntaxhighlight lang=shell>
mlmmj-make-ml -L discuss -s /home/pacs/xyz00/users/list/mlmmj
</syntaxhighlight>

Das Skript ''mlmmj-make-ml'' fragt weitere Parameter der Mailingliste ab:

<syntaxhighlight lang=output line>
The Domain for the List? [] : example.org
The emailaddress of the list owner? [postmaster] : webmaster@example.org
For the list texts you can choose between the following languages or
give an absolute path to a directory containing the texts.
Available languages:
cz da de en es fr it nl ru
The path to texts for the list? [en] : de
</syntaxhighlight>

Das skript ''mlmmj-make-ml'' legt daraufhin unter "/home/pacs/xyz00/users/list/mlmmj" ein Verzeichnis "discuss" an, das die Datenstruktur zur Verwaltung der Mailingliste enthält.

Weitere Konfigurationen der Liste erfolgen durch das Anlegen von Dateien im
Verzeichnis "/home/pacs/xyz00/users/list/mlmmj/discuss/control".
Die Konfigurationsmöglichkeiten finden Sie auf der [http://mlmmj.org/TUNABLES.html Internetseite von mlmmj].

Damit mlmmj die Verteilung der Post übernimmt, muß ich im Heimat-Verzeichnis des users xyz00-list die Datei <tt>.forward</tt> mit folgenden Inhalt (INKLUSIVE der Anführungszeichen!) erstellen:

<syntaxhighlight lang=shell>
"|/usr/bin/mlmmj-recieve -L /home/pacs/xyz00/users/list/mlmmj/discuss/"
</syntaxhighlight>

(Ja, ''receive'' schreibt sich mit ''-ei-'', aber mlmmj hält einen symbolischen Link bereit für diejenigen, die in englischer Rechtschreibung unsicher sind:)

<syntaxhighlight lang=shell>
xyz00-list@h03:~$ ls -la /usr/bin/mlmmj-rec*
-rwxr-xr-x 1 root root 27104 Sep 25 2018 /usr/bin/mlmmj-receive
lrwxrwxrwx 1 root root 13 Sep 25 2018 /usr/bin/mlmmj-recieve -> mlmmj-receive
</syntaxhighlight>

Die <tt>.forward</tt>-Datei sorgt dafür, dass eingehende E-Mails an das User-Postfach an das Programm ''mlmmj-recieve'' übergeben werden.

Für regelmäßige Aufgaben der Listen-Managers definiere ich den systemd timer wie folgt (immer noch als ''xyz00-list''):

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

[Service]
Type=oneshot
ExecStart=/usr/bin/mlmmj-maintd -d /home/pacs/xyz00/users/list/mlmmj -F
</syntaxhighlight>

~/.config/systemd/user/mlmmj.timer
<syntaxhighlight lang=ini>
[Unit]
Description=mlmmj maintenance

[Timer]
OnCalendar=*/4:28
Persistent=True

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

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

Zum Schluss rufe ich das Skript mlmmj-sub auf, um die E-Mail-Adressen der gewünschten Abonnenten des Verteilers einzutragen:

<syntaxhighlight lang=shell>
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a klaus.muster@gmx.de -c
/usr/bin/mlmmj-sub -L /home/pacs/xyz00/users/list/mlmmj/discuss -a sabine.beispiel@arcor.de -c
</syntaxhighlight>

Dabei bewirkt "-c", dass der Abonnent eine Begrüßungs-Nachricht erhält. Alternativ kann man "-C" (großes C) angeben: dann muss der Abonnent das Abo durch Antworten auf die Nachricht bestätigen.

== weitere Optionen ==

Noch ein paar Dinge, die Sie möglicherweise einstellen wollen:

Ein Prefix in der Betreffzeile setzen, z.B.: "[discuss]".

<syntaxhighlight lang=shell>
echo "[discuss]" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/prefix
</syntaxhighlight>

Wenn die Liste nur E-Mails von eingetragenen Abonnenten weiterleiten soll:

<syntaxhighlight lang=shell>
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/subonlypost
</syntaxhighlight>

Damit der Listen-Owner weitere Abonnements bestätigen muss:

<syntaxhighlight lang=shell>
touch /home/pacs/xyz00/users/list/mlmmj/discuss/control/submod
</syntaxhighlight>

Einen "Reply-To:"-Header setzen, damit Antwort-Mails standardmäßig an die Mailing-Liste gehen:

<syntaxhighlight lang=shell>
echo "Reply-To:" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/delheaders
echo "Reply-To: discuss@example.org" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/customheaders
</syntaxhighlight>

Beim Massenversand, z.B. bei Newslettern, nutzen Sie bitte möglichst den dedizierten Postausgangsserver für den Massenversand. Dadurch tragen Sie dazu bei, die Reputation unserer regulären Ausgangsserver aufrechtzuerhalten.

Um dies zu tun, setzen Sie den SMTP-Port entsprechend:

<syntaxhighlight lang=shell>
echo "4025" > /home/pacs/xyz00/users/list/mlmmj/discuss/control/smtpport
</syntaxhighlight>

Weitere Konfigurationsvariante des Ausgangsserver sind unter https://www.hostsharing.net/doc/managed-operations-platform/email/ zu finden.

Weitere Möglichkeiten finden Sie (wie oben bereits angegeben)
auf der [http://mlmmj.org/docs/tunables/ Internetseite von mlmmj].

=== Achtung: DKIM ===

Mlmmj gibt die Möglichkeit, mit '''delheaders''' und '''customheaders''' die Header der durchgeleiteten Mail umfangreich zu ändern. Allerdings tragen Mails heute häufig kryptografische Signaturen der sendenden Mailserver. Eine DKIM-Signatur sichert damit in der Regel die Integrität des Body der Mail sowie der Header ''Subject:'', ''From:'', ''To:'', ''Date:'', ''From'', und oft auch ''Reply-To:''.

Wird zum Beispiel mit einem Prefix das Subject geändert oder ein Footer angehängt, macht dies die DKIM-Signatur ungültig. Das ist für viele Mailprovider ein Grund die Nachricht abzuweisen. (siehe auch Diskussions-Seite zum Artikel)

== Zur Konfiguration im Browser ==

Die Original-Distribution von ''mlmmj'' enthält ein paar einfache PHP- und Perl-Skripte. Das sind Beispiele für Subscribe-/Unsubscribe-Formulare, ein Admin-Formular zum Eintragen und Löschen von Abonnements und eine Seite mit der gesamten Listen-Konfiguration.

Wer es sich ansehen möchte:

Als Paket-Admin eine Domain aufschalten:
<syntaxhighlight lang=shell>
hsscript -u xyz00 -e "domain.add({set:{name:'lists.example.org',user:'xyz00-list'}})"
</syntaxhighlight>
Und weiter als "xyz00-list".

Download der neuesten Version der Sourcen von mlmmj von http://mlmmj.org/downloads/ (noch besser: Download des aktuellen Debian-Pakets von [https://packages.debian.org/bookworm/all/mlmmj-php-web-admin/download debian.org]: da sind einige veraltete PHP-Ausdrücke schon herausgepatcht) und diese in einem temporären Verzeichnis entpacken (mit tar oder dpkg-deb).

Unter "/mlmmj-$versionsnummer/contrib/web/php-admin/", oder beim .deb-Paket unter "usr/share/mlmmj-...", findet sich die PHP-Admin-Anwendung. Also ...

* den Inhalt diese Verzeichnisses nach "/home/pacs/xyz00/users/list/doms/lists.example.org/" packen;
* in "/home/pacs/xyz00/users/list/doms/lists.example.org/conf/config.php" die Variable "$topdir" anpassen;
* die Dateien aus "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs/" nach "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" verschieben;
* Beim .deb-Paket die config.php, die templates/ und die tunables.pl aus etc/ nach example.org/conf/ verschieben;
* in "/home/pacs/xyz00/users/list/mlmmj" und in "/home/pacs/xyz00/users/list/doms/lists.example.org/htdocs-ssl/" eine ".htaccess" mit folgendem Inhalt ablegen:
<syntaxhighlight lang=apache line>
Require valid-user
AuthType Basic
AuthName "mlmmj web-interface"
AuthUserFile /home/pacs/xyz00/users/list/doms/lists.example.org/etc/htpasswd
</syntaxhighlight>
* Und schließlich die "htpasswd"-Datei anlegen.

cd /home/pacs/xyz00/users/list/doms/lists.example.org/etc/
htpasswd -c htpasswd listadmin

* Ein Passwort angeben.

Nun enthält diese PHP-Anwendung, wenn man sie nicht dem Debian-Paket entnommen hat, leider noch eine Zeile, die schon seit PHP 7 nicht mehr lauffähig ist. Also muß man noch

* in <tt>.../htdocs-ssl/index.php</tt> folgende Änderung vornehmen:
<syntaxhighlight lang=diff line>
@@ -38,4 +38,5 @@
# use scandir to have alphabetical order
foreach (scandir($topdir) as $file) {
- if (!ereg("^\.",$file))
+# ereg obsolete!! Vormals: if (!ereg("^\.",$file))
+ if (!preg_match('/^\./',$file))
{
</syntaxhighlight>
und das Ergebnis auf https://lists.example.org anschauen.

== Mehrere Mailinglisten betreiben ==

Wenn mehrere Mailinglisten in einem Account und mit einer Admin-Oberfläche betrieben werden soll, empfiehlt sich die Nutzung von Procmail für den Aufruf von ''mlmmj'' für die jeweiligen Liste mit ihrem Daten-Verzeichnis.

Dazu trägt man in der Datei <tt>.forward</tt> statt des Aufrufs von ''mlmmj-recieve'' einen Aufruf von ''procmail'' ein:

<syntaxhighlight lang=shell>
|/usr/bin/procmail
</syntaxhighlight>

Die Konfiguration von Procmail kann generisch erfolgen. Dazu legt man eine Datei <tt>.procmailrc</tt> mit folgendem Inhalt ins $HOME des Users:

<syntaxhighlight lang=shell>
SHELL=/bin/sh
HOMEDIR=/home/pacs/xyz00/users/list
MAILDIR=/home/pacs/xyz00/users/list/Maildir
PMDIR=/home/pacs/xyz00/users/list
VERBOSE=yes
LOGFILE=/home/pacs/xyz00/users/list/var/procmail.log
DEFAULT

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH}/

:0
{ EXITCODE 67 }
</syntaxhighlight>

Bitte dafür sorgen, dass das Verzeichnis ''/home/pacs/xyz00/users/list/var'' existiert.

Der kryptische reguläre Ausdruck hinter dem Header ''X-Original-To:'' passt auf den Beginn der E-Mail-Adresse bis zum ersten ''@''- oder ''+''-Zeichen. In der Variable ''MATCH'' steht also der Name der Mailingliste, d.h. der Name der Verzeichnisses, in dem die Liste verwaltet wird.

Sehr wichtig ist die Zeile ''DEFAULT'' zu Beginn der ''.procmailrc''. Die Variable ''DEFAULT'' wird von ''procmail'' gesetzt. Wir sorgen mit dieser Zeile dafür, dass sie wieder undefiniert ist. Diese Variable wird intern von ''mlmmj'' benutzt, wenn sie gesetzt ist. Das führt in Kombination mit ''procmail'' zu Fehlfunktionen (vgl. Links).

===Groß- und Kleinschreibung===

Achtung, mit der Groß- und Kleinschreibung von Listennamen gibt es bei dieser Procmail-Lösung eine kleine Tücke. Procmail übernimmt in die Variable $MATCH genau die in der X-Original-To-Headerzeile vorgefundene Schreibweise, und diese kann denkbarerweise "Listen-Name" oder "listen-name" oder "Listen-name" sein. <tt>mlmmj</tt> hingegen wird diesen Wert in Unix-Manier mit dem genauen Verzeichnisnamen <tt>${HOME}/mlmmj/listen-name</tt> vergleichen, und bei unterschiedlicher Schreibweise die Mail nicht verteilen.

====Lösung 1====

Eine teilweise Lösung besteht darin, den Listennamen in dem <tt>mlmmj</tt>-Aufruf in der <tt>.procmailrc</tt> in Kleinbuchstaben umzuschreiben. Dann lautet das Rezept so:

<syntaxhighlight lang=shell>
:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/$(echo ${MATCH} | tr [:upper:] [:lower:])/
</syntaxhighlight>

Der Rest der Datei muß gleich bleiben, wie weiter oben angezeigt.

In diesem Fall müssen aber alle Mailing-Listen ohne Großbuchstaben im Namen angelegt werden!

(Man kann auch in <tt>${HOME}/mlmmj/</tt> durch kleingeschriebene Symlinks großgeschriebene Listennamen ansprechbar machen:

<syntaxhighlight lang=output>
xyz00-list@h02:~$ ls -lA mlmmj/
total 8
-rw-r--r-- 1 xyz00-list xyz00 148 Feb 1 16:56 .htaccess
lrwxrwxrwx 1 xyz00-list xyz00 10 Feb 2 18:01 mitglieder -> Mitglieder
drwxr-xr-x 15 xyz00-list xyz00 4096 Feb 2 16:53 Mitglieder
</syntaxhighlight>

====Lösung 2====

Bash kann bei der Auflösung von Variablen die Groß- und Kleinschreibung manipulieren. (Siehe dazu bei der Zeichenfolge <tt>,,</tt> in <tt>man bash</tt>.) Dann ist <tt>$(echo ${MATCH} | tr [:upper:] [:lower:])</tt> gleichbedeutend mit <tt>${MATCH,,}</tt>. Allerdings braucht procmail einige Überredung, um Bash zu verwenden.

<syntaxhighlight lang=shell>
SHELL=/bin/bash
SHELLMETAS=&|<>~;?*[{
HOMEDIR= ...

...

:0:
* ^X-Original-To: ()\/[^@+]+
|/usr/bin/mlmmj-receive -F -L /home/pacs/xyz00/users/list/mlmmj/${MATCH,,}/
</syntaxhighlight>

Die Tücke ist, daß procmail den in SHELL angegebenen Shell nur dann verwendet, wenn die Befehlszeile eines der in SHELLMETAS angegebenen Zeichen enthält. Und das '|' am Anfang der Zeile zählt dabei nicht! In diesem Beispiel ist es das Zeichen <tt>{</tt>, das den Einsatz von Bash auslöst.

Beide Lösungen scheinen zu funktionieren; Angabe ohne Gewähr.

== Links ==

* http://mlmmj.org/ Projektseite
* https://codeberg.org/mlmmj mlmmj auf Codeberg
* https://github.com/tchapi/mlmmj-simple-web-interface ein Admin-Interface in NodeJS
* [https://web.archive.org/web/20221228110514/https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ https://www.tablix.org/~avian/blog/archives/2010/04/the_faulty_default/ (via web.archive.org)] Nutzung von mlmmj in Verbindung mit Procmail
* [https://gist.github.com/kboss/7c9593f0fd9219406226c4f11256b98a Einfaches Python-Script zum Massenimport aus einem Texfile.] Geht bestimmt auch eleganter mit purem Bash
* Ein Self-Service zum Subscriben/Unsubscriben lässt sich in Form von Mail-to-Links in Webseiten einbinden. Beispiele gibt es bei Hostsharing für die öffentlichen "public"-Mailinglisten: https://www.hostsharing.net/lists/public-discussion/ . Alternativ auf https://github.com/hblasum/mlmmj-php-web-simplified ein Webfrontend mit dem sich Benutzerinnen und Benutzer selbst ein-/austragen können (Vereinfachung von mlmmj-php-web von Christoph Thiel).

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

Tomcat Installieren

2024-12-03T13:55:20Z

Cds09: /* Start des Tomcat Servers */

Apache Tomcat installieren

== Allgemein ==

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

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

== Spezielle Installation bei Hostsharing ==

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

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

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

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

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

== Installation ==

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

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

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

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

Ich bevorzuge das catalina.sh-Startskript zum Testen:

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

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

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

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

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

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

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

== Deployment einer Anwendung ==

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

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

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

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

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

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

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

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

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

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

== Start des Tomcat Servers ==

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[Timer]
OnCalendar=1:1
Persistent=True

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

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

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

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

[Timer]
OnCalendar=14:3
Persistent=True

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

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

Dann gehen wir daran unsere Anwendungen im Tomcat zu deployen.

== Links ==

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

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

Grouprise

2024-12-03T13:46:50Z

Cds09: /* Suchfunktion */

== Installation von Grouprise ==

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

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

==== Vorbereitungen in HSAdmin ====

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

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

==== Notizen zur Installation ====

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

Den Secret_Key kann man wie folgt erzeugen:

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

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

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

mailinglist_enabled: True

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Inhalt des Skriptes

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

Die Datei ".forward"

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

==== Suchfunktion ====

Aufbau des Suchindex für Artikel in Grouprise

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

Regelmäßige Updates des Suchindex per Systemd Timer:

~/.config/systemd/user/grouprise.env
<pre>
HOME=/home/pacs/xyz00/users/groups
VIRTUAL_ENV=/home/pacs/xyz00/users/stadt/stadtgestalten/build/venv
PATH=/home/pacs/xyz00/users/groups/stadtgestalten/build/venv/bin:/home/pacs/xyz00/users/groups/.nvm/versions/node/v10.21.0/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
MAILTO=webmaster@groups.hs-example.com
</pre>

~/.config/systemd/user/grouprise.service
<pre>
[Unit]
Description=rebuild grouprise search index

[Service]
EnvironmentFile=/home/pacs/xyz00/users/groups/.config/systemd/user/grouprise.env
WorkingDirectory=/home/pacs/xyz00/users/groups/stadtgestalten
Type=oneshot
ExecStart=/home/pacs/xyz00/users/stadt/stadtgestalten/build/venv/bin/python manage.py update_index
</pre>

~/.config/systemd/user/grouprise.timer
<pre>
[Unit]
Description=rebuild grouprise search index

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

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

Timer aktivieren und starten:
<pre>
$ systemctl --user enable grouprise.timer
$ systemctl --user start grouprise.timer
</pre>

== Links ==

=== Webseite ===

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

=== Grouprise Installationen ===

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

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

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

AWStats installieren

2024-12-03T13:34:45Z

Cds09: /* Cronjob für zukünftige automatische Ausführung einrichten */

== AWStats ==

AWStats ist ein Tool zur graphischen Auswertung von Logfiles.

mehr Infos unter http://www.awstats.org/

=== Vorarbeiten ===

Als Paketadmin die Logfiles per Eintrag in die config.ini auf die entsprechende Domain verteilen (http_log_directory = domain)

siehe [[Logging#Konfigurationsm.C3.B6glichkeiten|Traffic logs]].

In HSAdmin (https://admin.hostsharing.net) wird eine Domain mit dem Namen stats.example.com angelegt und bei "Apache-Scripting-Optionen" wird die Option "CGI-Funktion" aktiviert.

=== Download und Entpacken ===

Login als Domainadmin, in unserem Fall heißt dieser xyz00-doms. Auf http://www.awstats.org/#DOWNLOAD findet sich die aktuelle Version. In unserem Beispiel verwenden wir die Version 7.9 und laden sie direkt mit wget ins Home-Verzeichnis:
<syntaxhighlight lang=shell>
xyz00-doms:~$ wget http://prdownloads.sourceforge.net/awstats/awstats-7.9.tar.gz
</syntaxhighlight>
Datei entpacken:
<syntaxhighlight lang=shell>
xyz00-doms:~$ tar -xvzf awstats-7.9.tar.gz
</syntaxhighlight>
Die entpackten Ordner verteilen:
<syntaxhighlight lang=shell>
cd doms/stats.example.com
mv ~/awstats-7.9/wwwroot/cgi-bin/ cgi-ssl/awstats
mv ~/awstats-7.9/wwwroot/icon htdocs-ssl
mv ~/awstats-7.9/wwwroot/js htdocs-ssl
</syntaxhighlight>
Der Rest kann wieder gelöscht werden:
<syntaxhighlight lang=shell>
rm ~/awstats-7.9.tar.gz
rm -rf ~/awstats-7.9
</syntaxhighlight>
Verzeichnis anlegen, in das awstats seine Daten schreiben kann:
<syntaxhighlight lang=shell>
mkdir ~/aw_data
</syntaxhighlight>

=== Konfiguration ===
Config-Datei anlegen:
<syntaxhighlight lang=shell>
cd ~/doms/stats.example.com/cgi-ssl/awstats
cp awstats.model.conf awstats.example.com.conf
</syntaxhighlight>

Config-Datei zum Editieren öffnen, z.b. mit nano:
<syntaxhighlight lang=shell>
nano awstats.example.com.conf
</syntaxhighlight>

Folgende Einträge sind anzupassen:

* LogFile="gzip -cd /home/doms/example.com/var/web-example.com-%YYYY-0%MM-0%DD-0*|"
** oder wenn die Webseite über www läuft:
** LogFile="gzip -cd /home/doms/example.com/var/web-www.example.com-%YYYY-0%MM-0%DD-0*|"
* SiteDomain="example.com"
** oder wenn die Webseite über www läuft: SiteDomain="www.example.com"
* HostAliases="localhost 127.0.0.1 REGEX[example\.com$]"
* DirData="/home/pacs/xyz00/aw_data/"
* DirCgi="/cgi-bin/awstats"
* Lang="de"

Die wichtigsten weiteren Möglichkeiten:

* Um über den Browser eine Jahressortierung zu ermöglichen:
<syntaxhighlight lang=ini>
AllowFullYearView=3
</syntaxhighlight>
* Um Client-Informationen über Javascript auszulesen:
<syntaxhighlight lang=ini>
o MiscTrackerUrl="/js/awstats_misc_tracker.js"
o ShowScreenSizeStats=1
o ShowMiscStats=anjdfrqwp
</syntaxhighlight>
(Hinweis: dazu muss die Startseite (index.html) innerhalb des body-tags um folgenden Eintrag ergänzt werden:
<syntaxhighlight lang=html line>
<script language=javascript src="/js/awstats_misc_tracker.js"></script>
<noscript><img src="/js/awstats_misc_tracker.js?nojs=y" height=0 width=0 border=0 style="display: none"></noscript>
</syntaxhighlight>

Weiterführende Informationen zu den Einträgen in der Config-Datei sind hier zu finden: http://awstats.sourceforge.net/docs/awstats_config.html

Config-Datei unter cgi-ssl/awstats/awstats.example.com.conf abspeichern.

=== Rechtevergabe ===

Folgende Rechte müssen wir noch setzen:
<syntaxhighlight lang=shell>
Prüfen:
cd doms/example.com
chmod 755 cgi-ssl/awstats/lang
chmod 755 cgi-ssl/awstats/lib
chmod 755 cgi-ssl/awstats/plugins
chmod 755 cgi-ssl/awstats/awstats.pl
chmod 755 cgi-ssl/awstats/awredir.pl

Ändern:
chmod 644 cgi-ssl/awstats/awstats.example.com.conf
chmod 777 ~/aw_data
</syntaxhighlight>

=== Massen-Import der Tage vor Inbetriebnahme von awstats ===
<syntaxhighlight lang=shell>
mkdir ~/tmp
cd ~/tmp
cp ~/var/web-www.example.org-* .
for f in web*; do gunzip $f; done
for f in *.log; do export domain=example.org; $HOME/doms/example.com/cgi-ssl/awstats/awstats.pl -config=$domain -update -LogFile=$f; done
rm -Rf ~/tmp/*.log
</syntaxhighlight>
=== Seite einrichten ===

Die folgende index.html Datei ermöglicht einen einfachen Zugriff auf die AWStats Oberfläche:

<syntaxhighlight lang=shell>
nano ~/doms/stats.example.org/htdocs-ssl/index.html
</syntaxhighlight>

mit diesem Inhalt:
<syntaxhighlight lang=html line>
<html>
<body>
<h1>AWStats</h1>
<a href='/awstats/awstats.pl?config=example.com'>example.com</a><br/>
<a href='/awstats/awstats.pl?config=example2.com'>example2.com</a><br/>
</body>
</html>
</syntaxhighlight>

Im gleichen Verzeichnis sollte noch eine htaccess Datei liegen:
<syntaxhighlight lang=shell>
nano ~/doms/stats.example.com/htdocs-ssl/.htaccess
</syntaxhighlight>

mit diesem Inhalt:

<syntaxhighlight lang=apache line>
DirectoryIndex index.html
RewriteEngine on
RewriteBase /
RewriteRule ^awstats/(.*) https://stats.example.com/cgi-bin/awstats/$1 [proxy,last]
</syntaxhighlight>

=== Statistik Seite mit Passwort schützen ===

Dann sollte die Seite noch mit einem Passwort geschützt werden: siehe die Erklärung auf [[.htaccess#Passwortschutz_für_Dateien|.htaccess Passwortschutz für Dateien]]

=== Systemd Timer für zukünftige automatische Ausführung einrichten ===

Skript anlegen:

<syntaxhighlight lang=shell>
mkdir ~/bin
nano ~/bin/awstats.sh
</syntaxhighlight>

Diesen Inhalt einfügen, ggfs. mehrere Domains einfügen:

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

function processWebLogs
{
domain=$1
$HOME/doms/stats.example.com/cgi-ssl/awstats/awstats.pl -config=$domain -update
}

processWebLogs example.com
# processWebLogs example.org
</syntaxhighlight>

Dann das Skript ausführbar machen und den timer anlegen:

~/.config/systemd/user/awstats.service
<syntaxhighlight lang=ini>
[Unit]
Description=create web statistics

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz99/bin/awstats.sh
</syntaxhighlight>

~/.config/systemd/user/awstats.timer
<syntaxhighlight lang=ini>
[Unit]
Description=create web statistics

[Timer]
OnCalendar=3:33
Persistent=True

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

Es muss eine Zeit nach 2 Uhr Nachts genommen werden, weil gegen 1:45 Uhr die Log Dateien rotiert werden.

Timer aktivieren und starten:
<syntaxhighlight lang=shell>
$ chmod a+x ~/bin/awstats.sh
$ systemctl --user enable awstats.timer
$ systemctl --user start awstats.timer
</syntaxhighlight>

== Weitere WebStatistik Tools bei HS ==

* [[AWStats_installieren|AWStat]]
* [[Goaccess]]
* [[Matomo Installieren|Matomo]]

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

Mailman 3 installieren

2024-12-03T13:18:42Z

Cds09: /* Dienste starten und überwachen */

Die folgende Anleitung zur Installation von Mailman 3 auf Hostsharing geht davon aus, dass als Domäne ''lists.example.org'' und als Domänennutzer ''xyz00-lists'' verwendet wird. Es ist zu empfehlen, auszuführende Befehle und Konfigurationen vorab auf zu ersetzende Werte zu prüfen. Alle Befehle sind als Benutzer ''xyz00-lists'' zu starten. Damit mehrere aufeinander folgende Shell-Kommandos leichter kopiert werden können, wird nur vor das jeweils erste Kommando ein ''$'' gesetzt. Zum Verständnis mancher der folgenden Anweisungen kann es hilfreich sein, die [https://mailman.readthedocs.io/ Mailman-Dokumentation] gelesen und sich mit [https://pipenv.readthedocs.io/en/latest/ Pipenv] beschäftigt zu haben.

Achtung: Mailman 3 benötigt zahlreiche Hintergrundprozesse, was beim Managed Webspace zusätzliche Kosten verursacht.

== Datenbank ==
Zunächst muss eine PostgreSQL- oder MySQL-Datenbank angelegt werden. (Mailman läuft auch mit SQLite, ist aber für den Produktivbetrieb nicht empfohlen.) Je nach gewählter Datenbank unterscheiden sich manche Schritte geringfügig, was an den entsprechenden Stellen dokumentiert ist.

== Mailman Core ==
Für die Installation von Mailman Core sind folgende Kommandos auszuführen:

<syntaxhighlight lang="bash" line>
pip3 install --user pipenv
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.profile
source ~/.profile
mkdir ~/mailman
cd ~/mailman
pipenv install mailman
pipenv install mailman_hyperkitty
pipenv install psycopg2-binary # Für PostgreSQL
pipenv install pymysql # Für MySQL
</syntaxhighlight>

Hinweis: Das Kommando <code>pipenv</code> muss immer im Verzeichnis <code>~/mailman</code> ausgeführt werden.

Anschließend wird das Verzeichnis für die Konfigurationsdatei angelegt:
<syntaxhighlight lang="bash">
mkdir -p ~/mailman/etc
</syntaxhighlight>

Die Konfiguration wird in die Datei <code>~/mailman/core/etc/mailman.cfg</code> geschrieben:

<syntaxhighlight lang="ini" line>
[mailman]
site_owner: admin@example.org
default_language: de

[paths.here]
var_dir: $cwd/core

[database] # https://mailman.readthedocs.io/en/latest/src/mailman/docs/database.html
class: mailman.database.postgresql.PostgreSQLDatabase
url: postgresql://myuser:mypassword@mypghost/mailman
# Fallls MySQL verwendet:
#class: mailman.database.mysql.MySQLDatabase
#url: mysql+pymysql://myuser:mypassword@mymysqlhost/mailman?charset=utf8&use_unicode=1
# SQLite ist Standard, wenn nichts konfiguriert ist

[webservice] # REST Service von Mailman. Wird von [[#Web_Frontend|Web Frontend]] verwendet
port: 8001 # ändern, falls belegt
admin_user: restadmin
admin_pass: restpass

[mta]
smtp_host: xyz00.hostsharing.net
smtp_port: 4587
smtp_user: xyz00-lists
smtp_pass: secret
smtp_secure_mode: starttls
# https://mailman.readthedocs.io/en/latest/src/mailman/docs/mta.html
# NullMTA, da MTA nicht selbst konfiguriert werden kann
incoming: mailman.mta.null.NullMTA
lmtp_port: 8024 # ändern, falls belegt

[runner.nntp]
# Runner für [https://de.wikipedia.org/wiki/Network_News_Transfer_Protocol NNTP] Gateway ausschalten
start: no

[archiver.hyperkitty]
class: mailman_hyperkitty.Archiver
enable: yes
# $HOME muss durch den tatsächlichen Pfad zum Benutzerverzeichnis ersetzt werden
configuration: $HOME/mailman/core/etc/mailman-hyperkitty.cfg
</syntaxhighlight>

Zugriffsrechte einschränken:
<syntaxhighlight lang="bash">chmod 0600 ~/mailman/core/etc/mailman.cfg</syntaxhighlight>

Damit Hyperkitty als [[#Web_Frontend|Web Frontend]] für das Archiv verwendet werden kann, ist in die Datei <code>~/mailman/core/etc/mailman-hyperkitty.cfg</code> Foglendes zu schreiben:
<syntaxhighlight lang="ini" line>
[general]
base_url: https://lists.example.org/hyperkitty/
# Muss identisch mit Key in Hyperkitty sein (s.u.)
api_key: SecretArchiverAPIKey
</syntaxhighlight>

Zugriffsrechte einschränken:
<syntaxhighlight lang="bash">chmod 0600 ~/mailman/core/etc/mailman-hyperkitty.cfg</syntaxhighlight>

Kommando ''mailman'' anlegen:
<syntaxhighlight lang="bash" line>
cat <<'EOD' >~/.local/bin/mailman
#!/bin/sh

export MAILMAN_CONFIG_FILE=$HOME/mailman/core/etc/mailman.cfg
cd ~/mailman
pipenv run mailman "$@"
EOD

chmod +x ~/.local/bin/mailman
</syntaxhighlight>

Hinweis: Da in <code>mailman</code> das Verzeichnis gewechselt wird, funktionieren relative Pfadangaben als Argument nicht bzw. nur, wenn man sich bereits in <code>~/mailman</code> befindet.

Nun kann mit <code>mailman info</code> nochmal die aktuelle Konfiguration geprüft werden.
Danach kann Mailman gestartet werden:
mailman start

== Web Frontend ==
In diesem Abschnitt wird die Installation des Web Frontends beschrieben.

Zunächst werden die Redirects aus der <code>.htaccess</code> gelöscht:
<syntaxhighlight lang="bash">echo "" > ~/doms/lists.example.org/htdocs-ssl/.htaccess</syntaxhighlight>

Anschließend werden die erforderlichen Python-Pakete installiert:
<syntaxhighlight lang="bash">
cd ~/mailman
pipenv install mailman-web
</syntaxhighlight>

Um Plattenplatz freizugeben, kann optional der Pip Cache gelöscht werden:
<syntaxhighlight lang="bash">pipenv --clear</syntaxhighlight>

Zur Konfiguration von Hyperkitty wird die IP-Adresse benötigt, von der die Anfragen von Mailman Core kommen. Diese kann wie folgt ermittelt werden:
<syntaxhighlight lang="bash" line>
cat <<EOD >~/doms/lists.example.org/htdocs-ssl/ip.php
<?php
echo \$_SERVER['REMOTE_ADDR'] . "\n";
EOD

curl <nowiki>https://lists.example.org/ip.php</nowiki>
rm ~/doms/lists.example.org/htdocs-ssl/ip.php
</syntaxhighlight>

Die Konfiguration wird nun in Die Datei <code>~/mailman/web/settings.py</code> geschrieben:
<syntaxhighlight lang="python" line>
# See https://mailman-web.readthedocs.io/en/latest/settings.html

from mailman_web.settings.base import *
from mailman_web.settings.mailman import *

BASE_DIR = os.path.join(os.environ['HOME'], 'mailman', 'web')

# Default path where static files will be placed.
# 'collectstatic' command will copy all the static files here.
# Alias this location from your webserver to `/static`
STATIC_ROOT = os.path.join(BASE_DIR, 'static')

# Make sure that the directory is created or Django will fail on start.
LOGGING['handlers']['file']['filename'] = os.path.join(BASE_DIR, 'logs', 'mailmanweb.log')

# Change path of Whoosh index
HAYSTACK_CONNECTIONS['default']['PATH'] = os.path.join(BASE_DIR, 'whoosh_index')

# django-compressor
# https://pypi.python.org/pypi/django_compressor
COMPRESS_PRECOMPILERS = (
('text/x-scss', 'sass -t compressed {infile} {outfile}'),
('text/x-sass', 'sass -t compressed {infile} {outfile}'),
)

# https://django-q.readthedocs.io/en/latest/configure.html
# 1 worker is probably enough. (Default is 3.)
Q_CLUSTER['workers'] = 1

# Default list of admins who receive the emails from error logging.
# https://docs.djangoproject.com/en/dev/ref/settings/#admins
ADMINS = (
('Mailman Admin', 'admin@example.org'),
)
# Database setup.
# https://docs.djangoproject.com/en/dev/ref/settings/#databases
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.postgresql_psycopg2', # Für MySQL: django.db.backends.mysql
'HOST': 'localhost',
'NAME': 'database_name',
'USER': 'database_user',
'PASSWORD': 'database_password',
}
}

# Hosts/domain names that are valid for this site; required if DEBUG is False.
# https://docs.djangoproject.com/en/dev/ref/settings/#allowed-hosts
ALLOWED_HOSTS = [
'lists.example.org',
]

# A secret key for a particular Django installation. This is used to provide
# cryptographic signing, and should be set to a unique, unpredictable value.
# https://docs.djangoproject.com/en/dev/ref/settings/#secret-key
SECRET_KEY = 'change-this-on-your-production-server'

# Mailman Core default API Path
MAILMAN_REST_API_URL = 'http://localhost:8001'
# Mailman Core API user
MAILMAN_REST_API_USER = 'restadmin'
# Mailman Core API user's password.
MAILMAN_REST_API_PASS = 'restpass'
# Mailman Core Shared archiving key. This value is set in the
# mailman-hyperkitty's configuration file.
MAILMAN_ARCHIVER_KEY = 'SecretArchiverAPIKey'
# Host for Mailman Core, from where Hyperkitty will accept connections
# for archiving.
MAILMAN_ARCHIVER_FROM = ('<IP von Mailman Core>')

# Base URL where Django/Mailman-web would be listening for requests. Used by
# Mailman Core for fetching templates.
POSTORIUS_TEMPLATE_BASE_URL = 'https://lists.example.org'

# Sender in emails sent out by Postorius.
# https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-DEFAULT_FROM_EMAIL
DEFAULT_FROM_EMAIL = 'postorius@lists.example.org'

# If you enable email reporting for error messages, this is where those emails
# will appear to be coming from. Make sure you set a valid domain name,
# otherwise the emails may get rejected.
# https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SERVER_EMAIL
SERVER_EMAIL = 'django@lists.example.org'

# Configuration used to send emails.
# https://docs.djangoproject.com/en/dev/ref/settings/#email-host
EMAIL_HOST = 'xyz00.hostsharing.net'
EMAIL_PORT = 4587
EMAIL_USE_TLS = True
EMAIL_HOST_USER = 'xyz00-lists'
EMAIL_HOST_PASSWORD = 'secret'
EMAIL_TIMEOUT = 60

# A string representing the time zone for this installation.
# https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-TIME_ZONE
TIME_ZONE = 'Europe/Berlin'

# A string representing the language code for this installation.
# https://docs.djangoproject.com/en/dev/ref/settings/#language-code
LANGUAGE_CODE = 'de-de'

# Disable support for gravatars in HyperKitty and Postorius.
# https://docs.mailman3.org/projects/hyperkitty/en/latest/install.html#customization
HYPERKITTY_ENABLE_GRAVATAR = False

# Hinweis: In der derzeit aktuellen Version (1.3.5) der Komponente
# django-mailman3 wird obige Variable nicht berücksichtigt. Deshalb kann die
# folgende Direktive nur mit dem Entwicklungsstand aus git einkommentiert werden.
# django_gravatar is not required, anymore.
#INSTALLED_APPS.remove('django_gravatar')
</syntaxhighlight>

Zugriffsrechte einschränken:
<syntaxhighlight lang="bash">chmod 600 ~/mailman/web/settings.py</syntaxhighlight>

Hinweis: Wird die Konfiguration geändert, nachdem das Web Frontend aufgerufen wurde, muss es neu gestartet werden:
<syntaxhighlight lang="bash" line>
mkdir -p ~/doms/lists.example.org/app-ssl/tmp
touch ~/doms/lists.example.org/app-ssl/tmp/restart.txt
</syntaxhighlight>

Das für Logs definierte Verzeichnis anlegen:
<syntaxhighlight lang="bash">mkdir -p ~/mailman/web/logs</syntaxhighlight>

Damit per Django verfügbare Kommandos leicht ausgeführt werden können, wird der Befehl ''mailman-web'' eingerichtet:
<syntaxhighlight lang="bash" line>
cat <<'EOD' >~/.local/bin/mailman-web
#!/bin/sh

export MAILMAN_WEB_CONFIG=$HOME/mailman/web/settings.py
cd ~/mailman
pipenv run mailman-web "$@"
EOD
chmod +x ~/.local/bin/mailman-web
</syntaxhighlight>

Anschließend wird das Datenbankschema eingerichtet:
<syntaxhighlight lang="bash">mailman-web migrate</syntaxhighlight>

Mit dem folgenden Kommando werden statische Daten für das Web Frontend ins konfiguriete Verzeichnis geschrieben:
<syntaxhighlight lang="bash">mailman-web collectstatic</syntaxhighlight>

Nun müssen die statischen Dateien für das Web Frontend noch per HTTPS verfügbar gemacht werden:
<syntaxhighlight lang="bash">ln -s ~/mailman/mailman-suite/mailman-suite_project/static ~/doms/lists.example.org/htdocs-ssl/</syntaxhighlight>

Zum Anlegen des Administrators des Web Frontends wird dieser Befehl ausgeführt:
<syntaxhighlight lang="bash">mailman-web createsuperuser</syntaxhighlight>

Da die Übersetzungsdateien nur in Mailman Core, jedoch nicht bei den Web Frontend Komponenten im Binärformat enthalten sind, muss die Konvertierung nachgeholt werden:
<syntaxhighlight lang="bash" line>
for pofile in $(find $(pipenv --venv) -path '*/locale/*/LC_MESSAGES/*.po'); do
mofile=${pofile/.po/.mo}
if [ ! -f $mofile ] || [ $pofile -nt $mofile ]; then
echo $pofile
msgfmt $pofile -o $mofile -v
fi
done
</syntaxhighlight>

Damit das Web Frontend per [[Phusion_Passenger|Phusion Passenger]] geladen werden kann:

<syntaxhighlight lang="python" line>
cat <<EOD >~/doms/lists.example.org/app-ssl/passenger_wsgi.py
import os
import subprocess
import sys

os.environ['LANG'] = 'C.UTF-8'
os.environ['LC_ALL'] = 'C.UTF-8'

HOME = os.environ['HOME']
PIPENV = os.path.join(HOME, '.local', 'bin', 'pipenv')
PIPFILE_DIR = os.path.join(HOME, 'mailman')
PIPENV_PYTHON = subprocess.check_output([PIPENV, '--py'], cwd=PIPFILE_DIR).strip().decode('utf-8')
if sys.executable != PIPENV_PYTHON:
os.execl(PIPENV_PYTHON, PIPENV_PYTHON, *sys.argv)

os.environ['MAILMAN_WEB_CONFIG'] = os.path.join(HOME, 'mailman', 'web', 'settings.py')
from mailman_web.wsgi import application
EOD
</syntaxhighlight>

Nun steht das Web Frontend unter <code><nowiki>https://lists.example.org/</nowiki></code> zur Verfügung. Über die Django Administration sollte unter <code><nowiki>https://lists.example.org/admin/sites/site/1/change/</nowiki></code> die Domäne angepasst werden.

== Mails an Mailman weiterleiten ==
Da die MTA-Konfiguration nicht direkt angepasst werden kann, ist ein Hilfskonstrukt erforderlich: Mittels ''.forward-Datei'' werden eingehende Mails an das Programm <code>msmtp</code> weitergeleitet, welches diese per [https://de.wikipedia.org/wiki/Local_Mail_Transfer_Protocol LMTP] bei Mailman abliefert. msmtp ist auf den Managed Servern vorinstalliert.

MM_LMTP_PORT=8024 # In Mailman Core konfigurierter Port
cat <<EOD >.forward+mailman
"|/usr/bin/msmtp --host=localhost --port=$MM_LMTP_PORT --protocol=lmtp --read-envelope-from \$(echo \$ORIGINAL_RECIPIENT | sed 's/+.\+@/@/')"
EOD

Der <code>sed</code> Befehl ist erforderlich, damit Mails mit ''Plus Addressing'' mit der eigentlichen Empfängeradresse bei Mailman ankommen.

Für die Domain <code>lists.example.org</code> wird in HSAdmin oder per <code>hssscript</code> eine Catchall-Adresse mit <code>xyz00-lists+mailman</code> als Ziel eingerichtet. Bei einer Catchall-Adresse wird als <code>localpart</code> ein leerer String angegeben.

== Dienste starten und überwachen ==
Für die beiden benötigten Dienste kann ''monit'' wie folgt konfiguriert werden:

<syntaxhighlight lang="bash" line>
mkdir monit
cat <<EOD >~/.monitrc
set daemon 60
with start delay 90
set httpd unixsocket $HOME/monit/monit.sock
permission 600
allow mailman:monit
set mailserver localhost
set mail-format { from: monit@lists.example.org }
set alert admin@example.org
set logfile $HOME/monit/monit.log
set idfile $HOME/monit/monit.id
set pidfile $HOME/monit/monit.pid
set statefile $HOME/monit/monit.state

check process mailman
pidfile $HOME/mailman/core/master.pid
start program = "$HOME/.local/bin/mailman start"
stop program = "$HOME/.local/bin/mailman stop"
restart program = "$HOME/.local/bin/mailman restart"

check process mailman-web-qcluster
matching "mailman-web qcluster"
start program = "/bin/bash -c 'nohup $HOME/.local/bin/mailman-web qcluster >>$HOME/mailman/web/logs/qcluster.log 2>&1 &'"
stop program = "/usr/bin/pkill -f 'mailman-web qcluster'"
depends on mailman
EOD
</syntaxhighlight>

Dienste starten:
<syntaxhighlight lang="bash">monit</syntaxhighlight>

Für <code>mailman-web qcluster</code> kann alternativ ein minütlich laufender Systemd Timer verwendet werden.

== Logrotation ==
Die Rotation der Logdateien kann so konfiguriert werden:

<syntaxhighlight lang="bash" line>
cat <<EOD >~/logrotate.conf
compress
delaycompress
missingok
notifempty
dateext

$HOME/monit/monit.log {
rotate 1
weekly
maxsize 1M
}

$HOME/mailman/core/logs/*.log {
rotate 6
daily
sharedscripts
postrotate
$HOME/.local/bin/mailman reopen >/dev/null ||:
endscript
}

$HOME/mailman/web/logs/mailmanweb.log {
rotate 6
daily
}

$HOME/mailman/web/logs/qcluster.log {
rotate 1
size 100k
postrotate
/usr/bin/monit restart mailman-web-qcluster >/dev/null ||:
endscript
}
EOD
</syntaxhighlight>

Hinweis: <code>qcluster.log</code> wird hier nur bei Überschreiten der definierten Größe rotiert, um regelmäßige Mails von ''monit'' zu vermeiden.

== Cron Jobs ==
Für Mailman sind verschiedene Cron Jobs erforderlich. Zudem sollen nach einem Neustart die <code>monit</code> Dienste gestartet werden und täglich eine Logrotation erfolgen. Die Einrichtung kann so erfolgen (eine bereits existierende crontab wird überschrieben):

<syntaxhighlight lang="bash" line>
cat <<EOD | crontab -
MAILTO=admin@example.org
HOME=$HOME
PATH=$HOME/.local/bin:/usr/bin:/bin:/usr/sbin

@reboot rm -f \$HOME/monit/monit.pid \$HOME/mailman/core/master.pid && monit

@daily logrotate -s \$HOME/.logrotate_state \$HOME/logrotate.conf

# Send periodic digests.
@daily mailman digests --send

* * * * * mailman-web runjobs minutely
2,17,32,47 * * * * mailman-web runjobs quarter_hourly
@hourly mailman-web runjobs hourly
@daily mailman-web runjobs daily
@weekly mailman-web runjobs weekly
@monthly mailman-web runjobs monthly
@yearly mailman-web runjobs yearly
EOD
</syntaxhighlight>

Soll eine existierende crontab nicht überschrieben werden, muss das Kommando <code>crontab -e</code> ausgeführt und die crontab entsprechend angepasst werden. (Dabei <code>\$HOME</code> mit <code>$HOME</code> und <code>$HOME</code> mit dem Pfad des Benutzerverzeichnisses ersetzen.)

== Liste anlegen ==
Damit Mailman tatsächlich genutzt werden kann, muss natürlich eine Liste eingerichtet werden.
<syntaxhighlight lang=bash>mailman create meine-erste-liste@lists.example.org # Alternativ über Web Frontend</syntaxhighlight>

Außerdem müssen die E-Mail Adressen für die Mailingliste angelegt werden, im HSAdmin. Zum Beispiel für die Liste meine-erste-liste: meine-erste-liste, meine-erste-liste-join, meine-erste-liste-leave, meine-erste-liste-owner, für die Domain lists.example.org. Die E-Mails sollen in das Postfach gehen, wo mailman installiert ist.
Alternativ kann eine Catch-All Adresse eingerichtet werden, damit alle E-Mails an die Subdomain in das Postfach vom mailman gehen. Der Catch-All ist laut Postfix Regeln eine Adresse mit einem leeren lokalen Teil (siehe auch der Screenshot in der [[Sympa_installieren#Neue_Liste_einrichten|entsprechenden Anleitung von Sympa]]).

== Die Selbst-Registrierung von Benutzern verhindern ==

Per Default kann sich jede Person im Mailman3 ein Benutzerkonto anlegen. Wenn das nicht erwünscht ist, kann in der Datei <code>var/etc/settings.py</code> die folgende Zeile hinzugefügt werden:

<syntaxhighlight lang="python">
ACCOUNT_ADAPTER = 'django_mailman3.views.user_adapter.DisableSignupAdapter'
</syntaxhighlight>

Es können in diesem Fall im Django Backend durch den Administrator Benutzerkonten angelegt werden, auf https://lists.example.org/admin/auth/user/

== Update ==
Mailman lässt sich wie im Folgenden beschrieben aktualisieren.

Python-Pakete für die Aktualisierungen vorliegen ausgeben:

<syntaxhighlight lang="bash">
cd ~/mailman
pipenv update --outdated
</syntaxhighlight>

Vor dem eigentlichen Update empfiehlt es sich, die Release Notes (zumindest von [https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/docs/NEWS.html Mailman]) zu lesen und auf relevante Änderungen zu prüfen.

Mailman stoppen:
<syntaxhighlight lang="bash">
monit stop mailman
</syntaxhighlight>

Update der Pakete:

<syntaxhighlight lang="bash">
pipenv update
</syntaxhighlight>

Ggf. Pip Cache löschen:

<syntaxhighlight lang="bash">
pipenv --clear
</syntaxhighlight>

Datenbankmigrationen durchführen:
<syntaxhighlight lang="bash">
mailman-web makemigrations
mailman-web migrate
</syntaxhighlight>

Übersetzungen aktualisieren:
<syntaxhighlight lang="bash" line>
for pofile in $(find $(pipenv --venv) -path '*/locale/*/LC_MESSAGES/*.po'); do
mofile=${pofile/.po/.mo}
if [ ! -f $mofile ] || [ $pofile -nt $mofile ]; then
echo $pofile
msgfmt $pofile -o $mofile -v
fi
done
</syntaxhighlight>

Statische Dateien aktualisieren:
<syntaxhighlight lang="bash">mailman-web collectstatic -c</syntaxhighlight>

Abschließend die Dienste wieder starten:
<syntaxhighlight lang="bash">
monit start mailman
monit start mailman-web-qcluster
</syntaxhighlight>

Web Frontend neu starten:
<syntaxhighlight lang="bash">
mkdir -p ~/doms/lists.example.org/app-ssl/tmp
touch ~/doms/lists.example.org/app-ssl/tmp/restart.txt
</syntaxhighlight>

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

Mattermost Installieren

2024-12-03T13:17:37Z

Cds09: /* Start des Servers */

== Über Mattermost ==

Mattermost ist ein Chat-Server unter einer freien MIT Lizenz. Der Server ist in der Programmiersprache [https://de.wikipedia.org/wiki/Go_%28Programmiersprache%29 go] implementiert.

Mattermost ist eine selbst-gehostete Alternative zum Cloud-Dienst [https://de.wikipedia.org/wiki/Slack_(Software) Slack] oder zum proprietären [https://en.wikipedia.org/wiki/HipChat HipChat].

== Vorbereitungen ==

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "individuelle Serverdienste (1 Daemon)". Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/

Auf einem Managed Server melden Sie einfach die kostenlose Option "Eigener Daemon" an. Bei der Anmeldung geben Sie einen User an (dient als Admin/Service-User). Unter dieser User-Kennung läuft später der Mattermost-Server. Der User sollte vor der Anmeldung mit HSAdmin angelegt werden. Als User-Beispiel nutzen wir im Folgenden "xyz00-chat".

Ebenfalls mit HSAdmin muss eine (Sub-)Domain für den Chat-Dienst aufgeschaltet/angelegt werden. Die Domain muss dem User "xyz00-chat" zugeordnet werden. In dieser Anleitung nutze ich die Domain "beispiel-chat.de".

Weiterhin benötigt Mattermost eine MariaDB- oder eine PostgreSQL-Datenbank. Wir empfehlen PostgreSQL und legen also mit Hilfe von HSAdmin einen PostgreSQL-User ("xyz00_mm_user" mit Passwort "geheim") und eine Datenbank ("xyz00_mm_db" mit dem Eigentümer "xyz00_mm_user") an.

== Installation ==

Als User "xyz00-chat" lade ich die Software herunter (aktuelle Version siehe [https://github.com/mattermost/mattermost-server/releases]):

<syntaxhighlight lang=shell>
wget https://releases.mattermost.com/7.9.2/mattermost-7.9.2-linux-amd64.tar.gz
</syntaxhighlight>
Die tar.gz-Datei wird ausgepackt:

<syntaxhighlight lang=shell>
tar xzf mattermost-7.9.2-linux-amd64.tar.gz
</syntaxhighlight>

Dann finden wir im $HOME des Users "xyz00-chat" ein Unterverzeichnis "$HOME/mattermost"

== Konfiguration ==

Die Konfiguration von Mattermost nehmen wir in der Datei $"HOME/mattermost/config/config.json" vor:

Im Abschnitt "ServiceSettings" definieren wir die Parameter "SiteURL", "WebsocketURL" und "ListenAddress":

<syntaxhighlight lang=json line>
"ServiceSettings": {
"SiteURL": "https://beispiel-chat.de",
"WebsocketURL": "wss://beispiel-chat.de",
"ListenAddress": "127.0.0.1:34567",
...
</syntaxhighlight>

Dabei sei "https://beispiel-chat.de" die Domain, unter der der Chat betrieben werden soll und "34567" der Port,
der vom Hostsharing-Service für den "Eigenen Daemon" zugewiesen wurde.

Im Abschnitt "TeamSettings" kann für den Chat ein Name vergeben werden:

<syntaxhighlight lang=json line>
"TeamSettings": {
"SiteName": "Beispiel-Chat",
...
</syntaxhighlight>

Im Abschnitt "SqlSettings" wird die PostgreSQL Datenbank konfiguriert:

<syntaxhighlight lang=json line>
"SqlSettings": {
"DriverName": "postgres",
"DataSource": "postgres://xyz00_mm_user:geheim@127.0.0.1:5432/xyz00_mm_db?sslmode=disable\u0026connect_timeout=10",
...
</syntaxhighlight>

Weiter noch unter "FileSettings" und "EMailSettings":

<syntaxhighlight lang=json line>
"FileSettings": {
"MaxFileSize": 4096000,
"DriverName": "local",
"Directory": "./data/",
...

"EmailSettings": {
"EnableSignUpWithEmail": true,
"EnableSignInWithEmail": true,
"EnableSignInWithUsername": true,
"SendEmailNotifications": true,
"RequireEmailVerification": true,
"FeedbackName": "Beispiel-Chat",
"FeedbackEmail": "mattermost@beispiel-chat.de",
"FeedbackOrganization": "Beispiel",
"SMTPUsername": "",
"SMTPPassword": "",
"SMTPServer": "localhost",
"SMTPPort": "25",
...
</syntaxhighlight>

Im Verzeichnis "htdocs-ssl" unter "$HOME/doms/beispiel-chat.de" wird eine ".htaccess"-Datei abgelegt,
die dafür sorgt, dass alle Requests an den Mattermost-Server weitergegeben werden. Dabei verwendet Mattermost
auch Websocket-Verbindungen ("ws://"). Inhalt der ".htaccess":

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

RewriteCond %{REQUEST_URI} ^/api/v1/websocket [NC,OR]
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:34567%{REQUEST_URI} [proxy]

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

Im Verzeichnis "htdocs" wird eine ".htaccess"-Datei abgelegt, die für eine
Weiterleitung auf das https-Protokoll sorgt:

<syntaxhighlight lang=apache line>
Redirect permanent / https://beispiel-chat.de/
</syntaxhighlight>

== Start des Servers ==

Der Chat-Server lässt sich starten mit:

<syntaxhighlight lang=shell>
cd $HOME/mattermost
./bin/mattermost
</syntaxhighlight>

Ein kleines Start-Skript könnte so aussehen:

<syntaxhighlight lang=shell>
#!/bin/bash
export HOME=/home/pacs/xyz00/users/chat
cd $HOME/mattermost
rm -f running.pid
nohup ./bin/mattermost 1>/dev/null 2>&1 &
echo $! > running.pid
</syntaxhighlight>

Zum automatischen Start des Servers bei einem Reboot sollte
man einen systemd service einrichten:

~/.config/systemd/user/mattermost.service
<syntaxhighlight lang=ini>
[Unit]
Description=mattermost chat server

[Service]
Type=exec
ExecStart=/home/pacs/xyz00/users/chat/bin/mattermost
</syntaxhighlight>

Service aktivieren und starten:
<syntaxhighlight lang=shell>
$ systemctl --user enable mattermost.service
$ systemctl --user start mattermost.service
</syntaxhighlight>

== Links ==

*[https://about.mattermost.com/ Mattermost Homepage (Englisch)]
*[https://github.com/mattermost/platform git Repository bei Github]
*[https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/mattermost Ansible Playbook für Hostsharing]
----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Messenger]]
[[Kategorie:Eigene Daemons]]

Mattermost Installieren

2024-12-03T13:15:04Z

Cds09: /* Start des Servers */

== Über Mattermost ==

Mattermost ist ein Chat-Server unter einer freien MIT Lizenz. Der Server ist in der Programmiersprache [https://de.wikipedia.org/wiki/Go_%28Programmiersprache%29 go] implementiert.

Mattermost ist eine selbst-gehostete Alternative zum Cloud-Dienst [https://de.wikipedia.org/wiki/Slack_(Software) Slack] oder zum proprietären [https://en.wikipedia.org/wiki/HipChat HipChat].

== Vorbereitungen ==

Die hier beschriebene Installation benötigt bei Hostsharing die Paket-Option "individuelle Serverdienste (1 Daemon)". Im Managed Webspace ist diese Option kostenpflichtig: https://www.hostsharing.net/angebote/managed-webspace/

Auf einem Managed Server melden Sie einfach die kostenlose Option "Eigener Daemon" an. Bei der Anmeldung geben Sie einen User an (dient als Admin/Service-User). Unter dieser User-Kennung läuft später der Mattermost-Server. Der User sollte vor der Anmeldung mit HSAdmin angelegt werden. Als User-Beispiel nutzen wir im Folgenden "xyz00-chat".

Ebenfalls mit HSAdmin muss eine (Sub-)Domain für den Chat-Dienst aufgeschaltet/angelegt werden. Die Domain muss dem User "xyz00-chat" zugeordnet werden. In dieser Anleitung nutze ich die Domain "beispiel-chat.de".

Weiterhin benötigt Mattermost eine MariaDB- oder eine PostgreSQL-Datenbank. Wir empfehlen PostgreSQL und legen also mit Hilfe von HSAdmin einen PostgreSQL-User ("xyz00_mm_user" mit Passwort "geheim") und eine Datenbank ("xyz00_mm_db" mit dem Eigentümer "xyz00_mm_user") an.

== Installation ==

Als User "xyz00-chat" lade ich die Software herunter (aktuelle Version siehe [https://github.com/mattermost/mattermost-server/releases]):

<syntaxhighlight lang=shell>
wget https://releases.mattermost.com/7.9.2/mattermost-7.9.2-linux-amd64.tar.gz
</syntaxhighlight>
Die tar.gz-Datei wird ausgepackt:

<syntaxhighlight lang=shell>
tar xzf mattermost-7.9.2-linux-amd64.tar.gz
</syntaxhighlight>

Dann finden wir im $HOME des Users "xyz00-chat" ein Unterverzeichnis "$HOME/mattermost"

== Konfiguration ==

Die Konfiguration von Mattermost nehmen wir in der Datei $"HOME/mattermost/config/config.json" vor:

Im Abschnitt "ServiceSettings" definieren wir die Parameter "SiteURL", "WebsocketURL" und "ListenAddress":

<syntaxhighlight lang=json line>
"ServiceSettings": {
"SiteURL": "https://beispiel-chat.de",
"WebsocketURL": "wss://beispiel-chat.de",
"ListenAddress": "127.0.0.1:34567",
...
</syntaxhighlight>

Dabei sei "https://beispiel-chat.de" die Domain, unter der der Chat betrieben werden soll und "34567" der Port,
der vom Hostsharing-Service für den "Eigenen Daemon" zugewiesen wurde.

Im Abschnitt "TeamSettings" kann für den Chat ein Name vergeben werden:

<syntaxhighlight lang=json line>
"TeamSettings": {
"SiteName": "Beispiel-Chat",
...
</syntaxhighlight>

Im Abschnitt "SqlSettings" wird die PostgreSQL Datenbank konfiguriert:

<syntaxhighlight lang=json line>
"SqlSettings": {
"DriverName": "postgres",
"DataSource": "postgres://xyz00_mm_user:geheim@127.0.0.1:5432/xyz00_mm_db?sslmode=disable\u0026connect_timeout=10",
...
</syntaxhighlight>

Weiter noch unter "FileSettings" und "EMailSettings":

<syntaxhighlight lang=json line>
"FileSettings": {
"MaxFileSize": 4096000,
"DriverName": "local",
"Directory": "./data/",
...

"EmailSettings": {
"EnableSignUpWithEmail": true,
"EnableSignInWithEmail": true,
"EnableSignInWithUsername": true,
"SendEmailNotifications": true,
"RequireEmailVerification": true,
"FeedbackName": "Beispiel-Chat",
"FeedbackEmail": "mattermost@beispiel-chat.de",
"FeedbackOrganization": "Beispiel",
"SMTPUsername": "",
"SMTPPassword": "",
"SMTPServer": "localhost",
"SMTPPort": "25",
...
</syntaxhighlight>

Im Verzeichnis "htdocs-ssl" unter "$HOME/doms/beispiel-chat.de" wird eine ".htaccess"-Datei abgelegt,
die dafür sorgt, dass alle Requests an den Mattermost-Server weitergegeben werden. Dabei verwendet Mattermost
auch Websocket-Verbindungen ("ws://"). Inhalt der ".htaccess":

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

RewriteCond %{REQUEST_URI} ^/api/v1/websocket [NC,OR]
RewriteCond %{HTTP:UPGRADE} ^WebSocket$ [NC,OR]
RewriteCond %{HTTP:CONNECTION} ^Upgrade$ [NC]
RewriteRule .* ws://127.0.0.1:34567%{REQUEST_URI} [proxy]

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

Im Verzeichnis "htdocs" wird eine ".htaccess"-Datei abgelegt, die für eine
Weiterleitung auf das https-Protokoll sorgt:

<syntaxhighlight lang=apache line>
Redirect permanent / https://beispiel-chat.de/
</syntaxhighlight>

== Start des Servers ==

Der Chat-Server lässt sich starten mit:

<syntaxhighlight lang=shell>
cd $HOME/mattermost
./bin/mattermost
</syntaxhighlight>

Ein kleines Start-Skript könnte so aussehen:

''/home/pacs/xyz00/users/matter/bin/runmattermost.sh''
<syntaxhighlight lang=shell>
#!/bin/bash
export HOME=/home/pacs/xyz00/users/chat
cd $HOME/mattermost
rm -f running.pid
nohup ./bin/mattermost 1>/dev/null 2>&1 &
echo $! > running.pid
</syntaxhighlight>

Zum automatischen Start des Servers bei einem Reboot sollte
man einen systemd service einrichten:

~/.config/systemd/user/mattermost.service
<syntaxhighlight lang=ini>
[Unit]
Description=mattermost chat server

[Service]
Type=exec
ExecStart=/home/pacs/xyz00/users/matter/bin/runmattermost.sh
</syntaxhighlight>

Service aktivieren und starten:
<syntaxhighlight lang=shell>
$ systemctl --user enable mattermost.service
$ systemctl --user start mattermost.service
</syntaxhighlight>

== Links ==

*[https://about.mattermost.com/ Mattermost Homepage (Englisch)]
*[https://github.com/mattermost/platform git Repository bei Github]
*[https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/mattermost Ansible Playbook für Hostsharing]
----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:Messenger]]
[[Kategorie:Eigene Daemons]]

OpenProject installieren

2024-12-03T13:10:43Z

Cds09: /* Aufsetzen des Cronjobs für Hintergrundprozesse */

== Allgemein ==
OpenProject ist eine umfangreiche Projektmanagement-Software. Die Software ist multiprojektfähig; für jedes Projekt stehen unter anderem folgende Werkzeuge zur Verfügung:
* Wiki
* Vorgangsverfolgung (Ticketsystem, Issue Tracker)
* Zeiterfassung
* Dokument- und Dateiverwaltung

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

Die Anleitung wurde für OpenProject Version 11 erstellt.

== Ansible Skript ==

Alternativ zur manuellen Installation, die in diesem Wiki Artikel beschrieben wird, gibt es ein
Ansible Skript, das die Installationsschritte für OpenProject automatisiert durchführt.

Die Quellen für das Ansible Skript können hier eingesehen werden: https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/openproject

== Vorbereitungen ==

=== Service-User, Domain und Datenbank ===

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-project"
# Eine Domain mit ''xyz00-project'' als Domain-Administrator, zum Beispiel "prj.example.com"
# Einen Postgresql-User ''xyz00_dbuser'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_prjdb'' mit Datenbank-Owner ''xyz00_dbuser''

=== Vorbereitung des Webspace ===

Die "leichtgewichtige" Subdomain "www" wird gelöscht. Ebenso die ''.htaccess''-Datei mit der Weiterleitung dorthin.

<syntaxhighlight lang="bash">
xyz00@h20 $ sudo -u xyz00-project -i
xyz00-project@h20:~$ cd ~/doms/projekt.example.com/
xyz00-project@h20:~/doms/projekt.example.com$ rm -rf subs/www/ subs-ssl/www/ htdocs-ssl/.htaccess
</syntaxhighlight>

=== Installation von Ruby ===

Weiterhin benötigt OpenProject eine geeignete Version der Programmiersprache Ruby.

Die gewünschte Version kann hier abgelesen werden: https://github.com/opf/openproject/blob/stable/11/.ruby-version

Die Installation-Anleitung für OpenProject schlägt für die Installation ''rbenv'' vor.

<syntaxhighlight lang="bash">
xyz00-project@h20:~/doms/projekt.example.com$ cd
xyz00-project@h20:~$ git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
xyz00-project@h20:~$ touch .profile
xyz00-project@h20:~$ chmod u+x .profile
xyz00-project@h20:~$ echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
xyz00-project@h20:~$ echo 'eval "$(rbenv init -)"' >> ~/.profile
xyz00-project@h20:~$ source ~/.profile
xyz00-project@h20:~$ git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
xyz00-project@h20:~$ rbenv install 2.7.4
xyz00-project@h20:~$ rbenv rehash
xyz00-project@h20:~$ rbenv global 2.7.4
</syntaxhighlight>

Als Test bitte aufrufen: ''ruby -v''

Die Anzeige sollte etwa das Folgende enthalten:
ruby 2.7.4pXYZ (....) [x86_64-linux]

=== Installation von Node ===

Die Installation-Anleitung für OpenProject schlägt für die Installation ''nodenv'' vor.

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ git clone https://github.com/OiNutter/nodenv.git ~/.nodenv
xyz00-project@h20:~$ echo 'export PATH="$HOME/.nodenv/bin:$PATH"' >> ~/.profile
xyz00-project@h20:~$ echo 'eval "$(nodenv init -)"' >> ~/.profile
xyz00-project@h20:~$ source ~/.profile
xyz00-project@h20:~$ git clone git://github.com/OiNutter/node-build.git ~/.nodenv/plugins/node-build
xyz00-project@h20:~$ nodenv install 12.18.4
xyz00-project@h20:~$ nodenv rehash
xyz00-project@h20:~$ nodenv global 12.18.4
</syntaxhighlight>

Ein Test mit ''node --version'' solte anzeigen: v12.18.4

== Installation und Konfiguration ==

=== Installation von OpenProject ===

Wir installieren die OpenProject Community Edition. siehe https://github.com/opf/openproject

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ git clone https://github.com/opf/openproject.git --branch stable/11 --depth 1
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~$ gem update --system
xyz00-project@h20:~$ gem install bundler
xyz00-project@h20:~$ bundle update --bundler
xyz00-project@h20:~$ bundle config set deployment 'true'
xyz00-project@h20:~$ bundle config set without 'mysql2 sqlite development test therubyracer docker'
xyz00-project@h20:~$ bundle install
xyz00-project@h20:~$ npm install
</syntaxhighlight>

=== Konfiguration von OpenProject ===

Erstelle eine Konfiguration für den Datenbank-Zugriff in der Datei ''config/database.yml''

<syntaxhighlight lang="bash">
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ cp config/database.yml.example config/database.yml
</syntaxhighlight>

In der neuen Datei ''database.yml'' wird die mit HSAdmin angelegte PostgreSQL-Datenbank eingetragen:
<syntaxhighlight lang="yaml" line>
production:
adapter: postgresql
encoding: unicode
host: localhost
database: xyz00_prjdb (wie oben angegeben)
pool: 10
username: xyz00_dbuser (wie oben angegeben)
password: meinPasswort (wie oben angegeben)
</syntaxhighlight>

Die Einträge für ''development'' und ''test'' können gelöscht werden.

Dann wird die Datei ''configuration.yml'' angelegt:

<syntaxhighlight lang="yaml" line>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ cp config/configuration.yml.example config/configuration.yml
</syntaxhighlight>

Dort erfolgen die Einstellungen für ausgehende E-Mails:

<syntaxhighlight lang="yaml" line>
default:
log_level: info
email_delivery_method: :smtp
smtp_address: localhost
smtp_port: 25
smtp_domain: example.com
#smtp_authentication: :login
#smtp_user_name: "openproject@example.net"
#smtp_password: "my_openproject_password"
</syntaxhighlight>

Die Zeilen mit smtp_authentication, smtp_user_name und smtp_password können auskommentiert werden, sie werden in unserem Setup nicht benötigt.

Es muss außerdem vermieden werden, dass beim Hochladen von Dateien in /tmp geschrieben wird. Dazu wird das Verzeichnis $HOME/var/tmp angelegt, und die Datei <code>openproject/config/initializers/tmpdir.rb</code> mit folgendem Inhalt erstellt:

<syntaxhighlight lang="ruby" line>
class Dir
def self.tmpdir
"/home/pacs/xyz00/users/project/var/tmp/"
end
end
</syntaxhighlight>

=== Einen geheimen Schlüssel erzeugen ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ EDITOR=cat ./bin/rails credentials:edit
</syntaxhighlight>

=== Initialisiere Datenbank und erzeuge Web-Ressourcen ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ ./bin/rails db:prepare
xyz00-project@h20:~/openproject$ ./bin/rake assets:precompile
</syntaxhighlight>

=== Anlegen des Administrators ===

Es kann eine Demo Installation installiert werden:
<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ LOCALE=en ./bin/rake db:seed
</syntaxhighlight>

Damit wird ein Beispiel-Projekt angelegt, das man wieder löschen kann.

Wichtig ist aber, dass der Benutzer <code>admin</code> mit dem Passwort <code>admin</code> angelegt wird. Das Passwort muss bei der ersten Anmeldung geändert werden.

=== Konfiguration in Passenger ===

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/doms/prj.example.com
xyz00-project@h20:~/doms/prj.example.com$ rm -rf app-ssl htdocs-ssl
xyz00-project@h20:~/doms/prj.example.com$ ln -s $HOME/openproject app-ssl
xyz00-project@h20:~/doms/prj.example.com$ ln -s $HOME/openproject/public htdocs-ssl
</syntaxhighlight>

Weiterhin muss in einer .htaccess-Datei in diesem Verzeichnis die richtige Umgebung gesetzt sein:

<syntaxhighlight lang=apache>
# xyz00-project@h20:~/doms/prj.example.com$ cat .htaccess

SetEnv OPENPROJECT_STORAGE_TMP__PATH /home/pacs/xyz00/users/project/var/tmp/
SetEnv TMPDIR /home/pacs/xyz00/users/project/var/tmp/
PassengerRuby /home/pacs/xyz00/users/project/.rbenv/shims/ruby
</syntaxhighlight>

== Aufsetzen des systemd Timers für Hintergrundprozesse ==

Es werden Benachrichtigungs-E-Mails im Hintergrund verschickt. Dazu muss ein Prozess im Hintergrund gestartet werden. Um Probleme zu vermeiden, dass source nicht zur Verfügung steht, kann der Aufruf in einer eigenen Skriptdatei geschehen, die zwingend mit Bash ausgeführt wird, wo source verfügbar ist.

Datei ''/home/pacs/xyz00/users/project/emailjob.sh'':

<syntaxhighlight lang=bash line>
#!/bin/bash
source ~/.profile
cd ~/openproject
RAILS_ENV="production" ./bin/rake jobs:workoff
</syntaxhighlight>

Datei ''/home/pacs/xyz00/users/project/jobrestart.sh'':

<syntaxhighlight lang=bash line>
#!/bin/bash
source ~/.profile
cd ~/openproject
RAILS_ENV="production" ./bin/delayed_job restart
</syntaxhighlight>

Nun können die Timer eingerichtet werden:

''~/.config/systemd/user/openproject_emails.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject mails

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/project/emailjob.sh
</syntaxhighlight>

~/.config/systemd/user/openproject_emails.timer
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject mails

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

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

Damit wird der Hintergrundprozess alle 2 Minuten gestartet.

Es gibt noch einen Hintergrundjob, den ich einmal in der Stunde neu starte:

''~/.config/systemd/user/openproject_jobrestart.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject restart job

[Service]
Type=oneshot
ExecStart=/home/pacs/xyz00/users/project/jobrestart.sh
</syntaxhighlight>

~/.config/systemd/user/openproject_jobrestart.timer
<syntaxhighlight lang=ini line>
[Unit]
Description=openproject restart job

[Timer]
OnCalendar=*:22
Persistent=True

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

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

== Upgrade durchführen ==

Die gewünschte Ruby Version kann hier abgelesen werden: https://github.com/opf/openproject/blob/stable/11/.ruby-version

Für das Upgrade von OpenProject 11.2.4 auf 11.3.4, musste eine neue Version von Ruby installiert werden:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd ~/openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git -C $HOME/.rbenv/plugins/ruby-build pull
xyz00-project@h20:~/openproject$ rbenv install 2.7.4
xyz00-project@h20:~/openproject$ rbenv rehash
xyz00-project@h20:~/openproject$ rbenv global 2.7.4
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ rm -Rf $HOME/.rbenv/versions/2.7.3/ # alte Version kann gelöscht werden
</syntaxhighlight>

Weil das Git Repository bei der Erstinstallation nur einen Branch enthielt, muss nun das Repository vollständig geladen werden:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
xyz00-project@h20:~/openproject$ git fetch --unshallow
xyz00-project@h20:~/openproject$ git checkout --track remotes/origin/stable/11
</syntaxhighlight>

Generell müssen diese Schritte durchgeführt werden:

<syntaxhighlight lang=bash>
xyz00-project@h20:~$ cd openproject
xyz00-project@h20:~/openproject$ source ~/.profile
xyz00-project@h20:~/openproject$ git fetch
xyz00-project@h20:~/openproject$ git pull
xyz00-project@h20:~/openproject$ gem update --system
xyz00-project@h20:~/openproject$ bundle install
xyz00-project@h20:~/openproject$ npm install
xyz00-project@h20:~/openproject$ export RAILS_ENV="production"
xyz00-project@h20:~/openproject$ ./bin/rake db:migrate
xyz00-project@h20:~/openproject$ ./bin/rake assets:precompile
xyz00-project@h20:~/openproject$ touch ~/doms/prj.example.com/app-ssl/tmp/restart.txt
</syntaxhighlight>

== Referenzen ==

* [https://docs.openproject.org/installation-and-operations/installation/manual/ Anleitung für die manuelle Installation]
* [https://codeberg.org/tpokorra/hs.ansible/src/branch/main/playbooks/openproject Ansible Playbook für Hostsharing]
----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Ansible Playbook]]
[[Kategorie:Software]]
[[Kategorie:RubyOnRails]]
[[Kategorie:Passenger]]
[[Kategorie:Projektmanagement]]
[[Kategorie:Projektverwaltung]]

Loomio installieren

2024-12-03T13:01:26Z

Cds09: /* Cronjobs */

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

== Über ==
Loomio (https://www.loomio.com/) ist laut Wikipedia eine freie Software, geeignet um Gruppen im kollaborativen Entscheidungsfindungsprozess zu unterstützen.

Ein kurzes 2 Minuten Video auf Englisch beschreibt es ganz gut: What is Loomio? https://www.youtube.com/embed/Zlzuqsunpxc

Es ist in Ruby on Rails geschrieben.

Die von den Entwicklern empfohlene Installation von Loomio funktioniert mit Docker. Die Konzepte von Docker passen aber nicht zu Hostsharing.
Daher wird hier mit supervisor gearbeitet.

Weitere Links und Hinweise zur Entstehung dieser Anleitung siehe auf der [[Diskussion:Loomio_installieren|Diskussionsseite]].

== Vorbereitungen ==

=== Service-User, Domain und Datenbank ===

Mit Hilfe von HSAdmin werden angelegt:
# Ein User als Service-User mit ''/bin/bash'' als Shell, zum Beispiel Beispiel: ''xyz00-loomio"
# Eine Domain mit ''xyz00-loomio'' als Domain-Administrator, zum Beispiel "loomio.example.org"
# Einen Postgresql-User ''xyz00_loomio'' mit Passwort ''meinPasswort''
# Eine Postgresql-Datenbank ''xyz00_loomio'' mit Datenbank-Owner ''xyz00_loomio''

{{Textkasten|gelb|PostgreSQL Extensions|Die PostgreSQL-Datenbank braucht die [https://github.com/loomio/loomio/blob/master/db/schema.rb#L15 folgenden Extensions]: citext, hstore, pg_stat_statements, pgcrypto und plpgsql.
Diese müssen vom Hostsharing-Support installiert werden. Dazu einfach eine E-Mail an die service@ Adresse schreiben. }}

=== Installation von Ruby ===

Loomio benötigt eine geeignete Version der Programmiersprache Ruby:

Die Version ist in https://github.com/loomio/loomio/blob/master/.ruby-version zu finden.

<syntaxhighlight lang=shell>
git clone https://github.com/sstephenson/rbenv.git ~/.rbenv
touch ~/.profile
chmod u+x ~/.profile
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.profile
echo 'eval "$(rbenv init -)"' >> ~/.profile
source ~/.profile
git clone https://github.com/sstephenson/ruby-build.git ~/.rbenv/plugins/ruby-build
rbenv install 2.7.3
rbenv rehash
rbenv global 2.7.3
</syntaxhighlight>

Als Test bitte aufrufen: ''ruby -v''

Die Anzeige sollte etwa das Folgende enthalten:
ruby 2.7.3pXYZ (....) [x86_64-linux]

=== Installation von Node ===

Loomio benötigt eine geeignete Version von Node:

Die Version ist in https://github.com/loomio/loomio/blob/master/Dockerfile#L28 zu finden.

<syntaxhighlight lang=shell>
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash
export NVM_DIR="$HOME/.nvm"
source $NVM_DIR/nvm.sh
nvm install 14.0.0
nvm alias default 14.0.0
</syntaxhighlight>

== Installation ==
=== Installation der Anwendung ===

Wir benutzen nicht die [https://github.com/loomio/loomio/releases neueste Version von Loomio],
sondern die aktuelle Version aus dem stable Branch, genau wie die Docker Container.
Momentan ist das Version Loomio 2.7.5, siehe auf [https://github.com/loomio/loomio/blob/stable/lib/version.rb Github].

<syntaxhighlight lang=shell>
source ~/.profile
export NVM_DIR="$HOME/.nvm"
source $NVM_DIR/nvm.sh
git clone https://github.com/loomio/loomio.git
cd loomio
xyz00-loomio@h20:~/loomio$ git checkout --track remotes/origin/stable
xyz00-loomio@h20:~/loomio$ gem update --system
xyz00-loomio@h20:~/loomio$ bundle install
xyz00-loomio@h20:~/loomio$ cd vue && npm install && npm run build && cd ..
</syntaxhighlight>

=== Konfiguration von Loomio ===

Erstelle eine Konfiguration für den Datenbank-Zugriff in der Datei ''config/database.yml''

<syntaxhighlight lang=shell>
cd ~/loomio
xyz00-loomio@h20:~/loomio$ cp config/database.example.yml config/database.yml
</syntaxhighlight>

In der neuen Datei ''database.yml'' wird die mit HSAdmin angelegte PostgreSQL-Datenbank eingetragen:

<syntaxhighlight lang=yaml line>
production:
adapter: postgresql
encoding: unicode
host: localhost
database: xyz00_loomio (wie oben angegeben)
pool: 10
username: xyz00_dbuser (wie oben angegeben)
password: meinPasswort (wie oben angegeben)
</syntaxhighlight>

Bearbeite die Datei ''config/environments/production.rb'' und ergänze am Ende, vor dem ''end'':
<syntaxhighlight lang=ruby line>
config.force_ssl = false
config.action_mailer.default_url_options = { :host => 'loomio.example.org' }
config.action_mailer.raise_delivery_errors = true
config.action_mailer.perform_deliveries = true
config.action_mailer.delivery_method = :smtp
config.action_mailer.logger = ActiveSupport::Logger.new("/home/pacs/xyz00/users/loomio/supervisor/log/mailer.log")
config.action_mailer.logger.level = ActiveSupport::Logger::Severity::INFO
config.action_mailer.smtp_settings = {
:domain => 'example.org',
:authentication => nil,
:address => 'localhost',
:port => 25,
:openssl_verify_mode => :none,
:enable_starttls_auto => false
}
</syntaxhighlight>

=== Einen geheimen Schlüssel erzeugen ===

<syntaxhighlight lang=shell>
cd ~/loomio
xyz00-loomio@h20:~/loomio$ EDITOR=vim ./script/rails credentials:edit
</syntaxhighlight>

Den Editor vim mit Speichern verlassen: <code>Esc</code> Taste drücken, dann eingeben: <code>:wq</code> und Enter drücken

<syntaxhighlight lang=shell>
xyz00-loomio@h20:~/loomio$ export RAILS_ENV="production"
xyz00-loomio@h20:~/loomio$ echo "export SECRET_KEY_BASE=$(rake secret)" >> ~/.profile
</syntaxhighlight>

=== Initialisieren der Datenbank ===

<syntaxhighlight lang=shell>
cd ~/loomio
xyz00-loomio@h20:~/loomio$ export RAILS_ENV="production"
xyz00-loomio@h20:~/loomio$ source ~/.profile
xyz00-loomio@h20:~/loomio$ rake db:schema:load
xyz00-loomio@h20:~/loomio$ rake db:migrate
</syntaxhighlight>

=== Redis Service konfigurieren ===

<syntaxhighlight lang=shell>
cd
mkdir -p redis/etc redis/lib redis/log redis/run
</syntaxhighlight>
Anlegen einer Datei ''/home/pacs/xyz00/users/loomio/redis/etc/redis.conf'' mit folgendem Inhalt:

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

Zum Start aller notwendigen Dienste wird in dieser Anleitung supervisor benutzt.

<syntaxhighlight lang=shell>
mkdir -p ~/supervisor/log ~/supervisor/run ~/supervisor/etc
</syntaxhighlight>

Hier ein Beispiel für die Datei ~/supervisor/etc/supervisord.conf

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

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

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

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

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

[program:loomio-web]
directory=/home/pacs/xyz00/users/loomio/loomio
environment=RAILS_ENV="production",NOTIFICATIONS_EMAIL_ADDRESS="no-reply@example.org"
command=/home/pacs/xyz00/users/loomio/.rbenv/shims/bundle exec puma -C config/puma.rb -b tcp://127.0.0.1:3000
stderr_logfile = /home/pacs/xyz00/users/loomio/supervisor/log/loomio-web-stderr.log
stdout_logfile = /home/pacs/xyz00/users/loomio/supervisor/log/loomio-web-stdout.log

[program:loomio-sidekiq]
directory=/home/pacs/xyz00/users/loomio/loomio
environment=RAILS_ENV="production",NOTIFICATIONS_EMAIL_ADDRESS="no-reply@example.org"
command=/home/pacs/xyz00/users/loomio/.rbenv/shims/bundle exec sidekiq
stderr_logfile = /home/pacs/xyz00/users/loomio/supervisor/log/loomio-sidekiq-stderr.log
stdout_logfile = /home/pacs/xyz00/users/loomio/supervisor/log/loomio-sidekiq-stdout.log
</syntaxhighlight>

Die folgenden Skripte können zum Starten und zum Neustarten der Dienste verwendet werden:

''~/start.sh''

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

export RAILS_ENV="production"
source ~/.profile
cd ~/loomio
/usr/bin/supervisord -c $HOME/supervisor/etc/supervisord.conf
</syntaxhighlight>

''~/restart.sh''

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

if [ -f $HOME/supervisor/run/supervisord.pid ]
then
/bin/kill $( cat $HOME/supervisor/run/supervisord.pid )
fi
sleep 3
~/start.sh
</syntaxhighlight>

=== Systemd Serice und Timer ===

''Systemd'' wird genutzt, um nach dem Server reboot ''supervisord'' zu starten, und um regelmäßige Aufgaben von Loomio auszuführen.

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

[Service]
Type=exec
ExecStart=/usr/bin/supervisord -c /home/pacs/xyz00/users/loomio/supervisor/etc/supervisord.conf
</syntaxhighlight>

Service aktivieren und starten:
<syntaxhighlight lang=shell line>
$ systemctl --user enable supervisord.service
$ systemctl --user start supervisord.service
</syntaxhighlight>

''~/.config/systemd/user/loomio.service''
<syntaxhighlight lang=ini line>
[Unit]
Description=loomio recuring activities

[Service]
Type=oneshot
ExecStart=cd /home/pacs/xyz00/users/loomio/loomio && /home/pacs/xyz00/users/loomio/.rbenv/shims/bundle exec rake loomio:hourly_tasks
</syntaxhighlight>

~/.config/systemd/user/loomio.timer
<syntaxhighlight lang=ini line>
[Unit]
Description=loomio recuring activities

[Timer]
OnCalendar=*:55
Persistent=True

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

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

=== Log Dateien ===

Zum Debuggen können folgende Log Dateien hilfreich sein:

* ~/supervisor/log/loomio-web-stdout.log
* ~/supervisor/log/loomio-web-stderr.log
* ~/supervisor/log/loomio-sidekiq-stdout.log
* ~/supervisor/log/loomio-sidekiq-stderr.log
* ~/supervisor/log/mailer.log
* ~/supervisor/log/redis-stdout.log
* ~/supervisor/log/redis-stderr.log

=== Einrichten des Apache ===

Die originale .htaccess Datei zuerst löschen:

<syntaxhighlight lang=shell>
rm ~/doms/loomio.example.org/htdocs-ssl/.htaccess
</syntaxhighlight>
Neue Datei ''~/doms/loomio.example.org/htdocs-ssl/.htaccess''

<syntaxhighlight lang=apache line>
DirectoryIndex disabled
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) http://localhost:3000/$1 [proxy,last]
</syntaxhighlight>
----
[[Kategorie:HSDoku]]
[[Kategorie:Installationsanleitungen]]
[[Kategorie:Software]]
[[Kategorie:RubyOnRails]]

Mono bei Hostsharing

2024-12-03T12:50:16Z

Cds09: /* Mono und fastcgi Server im Produktiveinsatz */

== Allgemein ==

Mono [https://www.mono-project.com/] ist ein Open Source .NET Framework und ermöglicht es, .NET Anwendungen in C# unter Linux auszuführen.

== Mono bei Hostsharing ==

Momentan ist Mono nicht zentral auf den Hostsharing Servern installiert.

Mono wird als Debian Paket bereitgestellt, siehe https://packages.debian.org/de/buster/mono-complete

Das könnten wir bei Bedarf einrichten, allerdings ist die Version von Mono in unserem aktuell verwendeten Debian 10 (Buster) schon ziemlich alt (Mono 5.18).

Das ist ganz normal, bei nodejs/npm sieht es ähnlich aus, weil die Entwicklung solcher Projekte etwas schneller fortschreitet als die Debian Releases, die auf Stabilität bedacht sind.

== Mono lokal im Benutzer installieren ==

Es gibt aber einen Weg, ein binäres Paket im eigenen Benutzerverzeichnis zu installieren,
welches die gewünschte Funktionalität einer ziemlich aktuellen Mono Version (Mono 6.8) bietet.

Das binäre Paket kann hier heruntergeladen werden: https://download.solidcharity.com/tarballs/tpokorra/mono/mono-6.8.0.105.bin.debian10.tar.gz

Es enthält eine env.sh Datei, die ausgeführt werden muss, um die entsprechenden Pfade zu aktivieren.

Beispiel:

<syntaxhighlight lang=shell>
cd ~
wget https://download.solidcharity.com/tarballs/tpokorra/mono/mono-6.8.0.105.bin.debian10.tar.gz

echo "Prüfen der Hash Summe sollte OK zeigen:"
echo "f2c27f11141f81a131b6417084c31ab3ae9d050aab8f13d75b406b377a7a1c670bdfc386f276317115e791af0ad34842 *mono-6.8.0.105.bin.debian10.tar.gz" | sha384sum --check

tar xzf mono-6.8.0.105.bin.debian10.tar.gz
ln -s mono-6.8.0.105 mono
source mono/env.sh
mono --version
Mono JIT compiler version 6.8.0.105 (Debian 6.8.0.105+dfsg-3 Sun Dec 13 21:52:01 CET 2020)
Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
TLS: __thread
SIGSEGV: altstack
Notifications: epoll
Architecture: amd64
Disabled: none
Misc: softdebug
Interpreter: yes
LLVM: supported, not enabled.
Suspend: hybrid
GC: sgen (concurrent by default)
</syntaxhighlight>

=== Beschreibung zur Erstellung des binären Pakets ===

Natürlich muss man immer hinterfragen, ob man fremden binären Paketen vertraut. Alternativ kann man anhand der folgenden Anleitung das binäre Paket gegebenenfalls selber herstellen:

Zuerst werden aktuelle Mono Pakete für Debian Buster benötigt. Diese können aus den Quellen der Mono Pakete von Debian Bullseye für Debian Buster gebaut werden.
Die entsprechenden Skripte liegen hier: https://github.com/tpokorra/lbs-mono/tree/master/mono und https://github.com/tpokorra/lbs-mono/tree/master/xsp
Beim XSP wurde allerdings eine neuere Version verwendet (4.7.1) als momentan von Debian bereitgestellt wird (4.2, siehe https://packages.debian.org/de/bullseye/mono-xsp).

Es gibt ein Bash Skript [https://github.com/tpokorra/lbs-mono/blob/master/mono2bintarball/setup.sh] und ein Python Skript [https://github.com/tpokorra/lbs-mono/blob/master/mono2bintarball/mono2bintarball.py].
Diese werden auf einem Build Server ausgeführt, und es werden die folgenden Schritte ausgeführt:

* Es werden die Namen der aktuell installierten Pakete auf dem Hostsharing Server heruntergeladen.
* Dann wird eine Liste angefertigt von Paketen, die wir lokal installieren wollen für Mono.
* Dann werden lokal die gewünschten Mono Pakete installiert.
* Dann werden die Pakete, die installiert worden sind, mit den Paketen auf dem Hostsharing Server abgeglichen. Die Inhalte der zusätzlichen Pakete werden in das binäre Paket gepackt.
* Auch einige spezifische Mono Dateien, die teilweise erst mit den Installationsskripten installiert wurden (z.B. aot Cache, config Dateien), werden in das binäre Paket gepackt.
* Die Pfade in den bash Skripten zum Starten von Mono werden angepasst, damit es im Benutzerverzeichnis ausgeführt werden kann.
* Es wird eine env.sh Datei dazu gepackt.

== Mono Anwendung mit xsp debuggen ==

Man kann eine Mono Anwendung direkt mit xsp ausführen, ohne den Umweg über den Apache. Das kann beim Debuggen nützlich sein.

Beispiel:

index.aspx
<syntaxhighlight lang=html>
<%@ Page Language="C#" %>
<html xmlns="www.w3.org/1999/xhtml">
<%@ Import Namespace="System" %>
<head runat="server">
<title></title>
</head>
<body>
<div>
<%
Response.Write( "Hello World<br/>");
Response.Write( String.Format("Current Time is {0}<br/>", DateTime.Now));
%>
</div>
</body>
</syntaxhighlight>

Um Kompilierfehler im Browser zu sehen, diese Datei anlegen:

web.config
<syntaxhighlight lang=html>
<configuration>
<system.web>
<customErrors mode="Off"/>
</system.web>
</configuration>
</syntaxhighlight>

Eigene IP Adresse herausfinden:
<syntaxhighlight lang=shell>
ping -4 xyz00.hostsharing.net
</syntaxhighlight>
Nun kann der Server mit dieser IP Adresse gestartet werden:
<syntaxhighlight lang=shell>
xsp4 --port=8080 --address=aa.bbb.cc.ddd
</syntaxhighlight>
Die Seite ist nun über http://xyz00.hostsharing.net:8080 erreichbar.

== Mono und fastcgi Server im Produktiveinsatz ==

Für den produktiven Einsatz benutzt man den fastcgi Server.

Dazu muss man im Shared Hosting den zusätzlichen Dienst für den fastcgi Server buchen, und beim Service um einen freien Port bitten. Wir benutzen im Beispiel den Port 4001.

bin/start-mono.sh
<syntaxhighlight lang=shell>
#!/bin/bash

cd $HOME/aspnetapp
. $HOME/mono/env.sh
exec fastcgi-mono-server4 \
/socket=tcp:127.0.0.1:4001 \
/applications=/:$HOME/aspnetapp \
--logfile=$HOME/var/log/monoserver.log \
--loglevels=All \
--verbose \
> /dev/null 2>&1 &
echo $! > $HOME/var/run/mono.pid
</syntaxhighlight>

bin/stop-mono.sh
<syntaxhighlight lang=shell>
#!/bin/bash

kill -QUIT $( cat $HOME/var/run/mono.pid )
</syntaxhighlight>

.monitrc
<syntaxhighlight lang=shell>
set daemon 60 with start delay 10
set logfile /home/pacs/xyz00/users/meinuser/var/log/monit.log
set idfile /home/pacs/xyz00/users/meinuser/var/run/monit.id
set statefile /home/pacs/xyz00/users/meinuser/var/run/monit.state
set mailserver localhost
set mail-format { from: monit@xyz00.hostsharing.net }
check process mono with pidfile /home/pacs/xyz00/users/meinuser/var/run/mono.pid
start program "/home/pacs/xyz00/users/meinuser/bin/start-mono.sh"
stop program "/home/pacs/xyz00/users/meinuser/bin/stop-mono.sh"
</syntaxhighlight>

Es sollten die entsprechenden leeren Verzeichnisse erstellt werden, und die Rechte für .monitrc geändert werden:
<syntaxhighlight lang=shell>
mkdir -p $HOME/var/log
mkdir -p $HOME/var/run
chmod 600 .monitrc
</syntaxhighlight>

Und dann noch einen systemd service für Monit anlegen:

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

[Service]
Type=exec
ExecStart=rm -f $HOME/var/run/monit.id && /usr/bin/monit -c "$HOME/.monitrc"
</syntaxhighlight>

Service aktivieren und starten:

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

Nun muss noch dem Apache mitgeteilt werden, wie er auf den fastcgi Server zugreift:

doms/meine-domain.de/subs-ssl/www/.htaccess
<syntaxhighlight lang=apache>
DirectoryIndex index.aspx
RewriteEngine on
RewriteBase /
RewriteRule ^(.*) fcgi://127.0.0.1:4001/$1 [proxy,last]
</syntaxhighlight>

Dann sollte unter https://www.meinedomain.de/ die Mono Applikation erreichbar sein!

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

TLS Zertifikat mit LEGO

2024-12-03T12:38:12Z

Cds09: /* regelmäßige Verlängerung */

= TLS Zertifikat mit LEGO =

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

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

== Einrichtung ==

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

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

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

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

Das erste Zertifikat wird mit dem folgenden Befehl erzeugt:

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

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

Die Daten des Zertifikates kann man wie folgt auslesen:

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

== regelmäßige Verlängerung ==

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

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

Die Ausführung des Skriptes wird über einen systemd timer gesteuert:

''~/.config/systemd/user/lego_certificate.service''

[Unit]
Description=renew lego certificate

[Service]
Type=oneshot
ExecStart=php8.2 /home/pacs/xyz00/users/mumble/bin/lego-renew

''~/.config/systemd/user/lego_certificate.timer''

[Unit]
Description=timer for lego certificate

[Timer]
OnCalendar=Thu 4:34
Persistent=True

[Install]
WantedBy=timers.target

Den Timer aktivieren und starten:

$ systemctl --user enable lego_certificate.timer
$ systemctl --user start lego_certificate.timer

Fetchmail

2024-12-03T12:13:28Z

Cds09:

Die [[Freie Software]] '''fetchmail''' ist ein [[Mail Retrieval Agent]] (MRA) und holt in dieser Eigenschaft [[E-Mail]]s von [[Post Office Protocol|POP]]-, [[Internet Message Access Protocol|IMAP]]-, [[ETRN]]-, oder [[On-Demand Mail Relay|ODMR]]-fähigen [[Mailserver]]n und leitet sie an [[Simple Mail Transfer Protocol|(E)SMTP]]- oder [[LMTP]]-fähige [[Mailserver]] oder ein [[Mail Delivery Agent|lokales Zustellprogramm]] weiter.

== Installierte Version ==
Auf den Hostsharing-Servern wurde fetchmail als Bestandteil der [[Debian]]-Distribution installiert.
Die aktuelle Version kann von jedem Benutzer abgefragt werden:

<syntaxhighlight lang=bash>
fetchmail -V
</syntaxhighlight>

== Ausführung ==

Fetchmail kann als systemd timer regelmäßig ausgeführt werden, z.B. alle 5 Minuten:

''~/.config/systemd/user/fetchmail.service''
<syntaxhighlight lang=ini>
[Unit]
Description=fetch mail from remote server

[Service]
Type=oneshot
ExecStart=fetchmail -s
</syntaxhighlight>

''~/.config/systemd/user/fetchmail.timer''
<syntaxhighlight lang=ini>
[Unit]
Description=fetch mail every five minutes

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

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

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

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

Nextcloud

2024-12-03T12:05:53Z

Cds09: /* Redis Cache */

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

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

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>

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 Redis als eigener Server '''Daemon''' angemeldet werden und ist '''kostenpflichtig'''. Siehe zu Kosten im Webspace Konfigurator unter: https://www.hostsharing.net/angebote/managed-webspace/ – '''1 individueller Serverdienst''' (Daemons).

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. <strong>aus diesem Grund ist das automatische Setup durch das Plugin bei Hostsharing nicht möglich!</strong>

==== 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)<br>
2. falls noch nicht erstellt: <code>mkdir -p ~/.config/systemd/user</code><br>
3. mit Lieblingseditor die Datei <code>~/.config/systemd/user/notify_push.service</code> anlegen:<br>
<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:<br><code>export XDG_RUNTIME_DIR=/run/user/$UID</code><br>
6. den neuen systemd-Dienst automatisch bei Systemstart, sowie jetzt sofort starten:<br><code>systemctl enable --now --user notify_push</code><br>
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><br>
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. <br><br>

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