X-Git-Url: http://wagnertech.de/gitweb/gitweb.cgi/mfinanz.git/blobdiff_plain/61a426f10f765ddac762292138959e1543d39e0f..refs/heads/master:/doc/html/ch02s07.html?ds=inline diff --git a/doc/html/ch02s07.html b/doc/html/ch02s07.html index ae69b2042..a47fcf9d6 100644 --- a/doc/html/ch02s07.html +++ b/doc/html/ch02s07.html @@ -1,79 +1,71 @@ - 2.7. Der Task-Server

2.7. Der Task-Server

Der Task-Server ist ein Prozess, der im Hintergrund läuft, in - regelmäßigen Abständen nach abzuarbeitenden Aufgaben sucht und diese zu - festgelegten Zeitpunkten abarbeitet (ähnlich wie Cron). Dieser Prozess - wird u.a. für die Erzeugung der wiederkehrenden Rechnungen und weitere - essenzielle Aufgaben benutzt.

Der Task-Server muss einmalig global in der Konfigurationsdatei - konfiguriert werden. Danach wird er für jeden Mandanten, für den er - laufen soll, in der Adminsitrationsmaske eingeschaltet.

Beachten Sie, dass der Task-Server in den Boot-Vorgang Ihres - Servers integriert werden muss, damit er automatisch gestartet wird. - Dies kann kivitendo nicht für Sie erledigen.

Da der Taskserver als Perlscript läuft, wird Arbeitsspeicher, der - einmal benötigt wurde, nicht mehr an das Betriebssystem zurückgegeben, - solange der Taskserver läuft. Dies kann dazu führen, dass ein länger - laufender Taskserver mit der Zeit immer mehr Arbeitsspeicher für sich - beansprucht. Es ist deshalb sinnvoll, dass der Taskserver in - regelmässigen Abständen neu gestartet wird.

2.7.1. Verfügbare und notwendige Konfigurationsoptionen

Die Konfiguration erfolgt über den Abschnitt - [task_server] in der Datei - config/kivitendo.conf. Die dort verfügbaren - Optionen sind:

- run_as -

Wird der Server vom Systembenutzer root - gestartet, so wechselt er auf den mit run_as - angegebenen Systembenutzer. Der Systembenutzer muss dieselben - Lese- und Schreibrechte haben, wie auch der Webserverbenutzer - (siehe see Manuelle Installation des Programmpaketes). Daher - ist es erforderlich, hier denselben Systembenutzer einzutragen, - unter dem auch der Webserver läuft.

- debug -

Schaltet Debug-Informationen an und aus.

2.7.2. Konfiguration der Mandanten für den Task-Server

Ist der Task-Server grundlegend konfiguriert, so muss - anschließend jeder Mandant, für den der Task-Server laufen soll, - einmalig konfiguriert werden. Dazu kann in der Maske zum Bearbeiten - von Mandanten im Administrationsbereich eine kivitendo-Benutzerkennung - ausgewählt werden, unter der der Task-Server seine Arbeit - verrichtet.

Ist in dieser Einstellung keine Benutzerkennung ausgewählt, so - wird der Task-Server für diesen Mandanten keine Aufgaben - ausführen.

2.7.3. Automatisches Starten des Task-Servers beim Booten

Der Task-Server verhält sich von seinen Optionen her wie ein - reguläres SystemV-kompatibles Boot-Script. Außerdem wechselt er beim - Starten automatisch in das kivitendo-Installationsverzeichnis.

Deshalb ist es möglich, ihn durch Setzen eines symbolischen - Links aus einem der Runlevel-Verzeichnisse heraus in den Boot-Prozess - einzubinden. Da das bei neueren Linux-Distributionen aber nicht - zwangsläufig funktioniert, werden auch Start-Scripte mitgeliefert, die - anstelle eines symbolischen Links verwendet werden können.

2.7.3.1. SystemV-basierende Systeme (z.B. ältere Debian, ältere - openSUSE, ältere Fedora)

Kopieren Sie die Datei - scripts/boot/system-v/kivitendo-task-server - nach /etc/init.d/kivitendo-task-server. Passen - Sie in der kopierten Datei den Pfad zum Task-Server an (Zeile - DAEMON=....). Binden Sie das Script in den - Boot-Prozess ein. Dies ist distributionsabhängig:

  • Debian-basierende Systeme:

    update-rc.d kivitendo-task-server defaults
    -insserv kivitendo-task-server
  • Ältere openSUSE und ältere Fedora:

    chkconfig --add kivitendo-task-server

Danach kann der Task-Server mit dem folgenden Befehl gestartet - werden:

/etc/init.d/kivitendo-task-server start

2.7.3.2. Upstart-basierende Systeme (z.B. Ubuntu bis 14.04)

Kopieren Sie die Datei - scripts/boot/upstart/kivitendo-task-server.conf - nach /etc/init/kivitendo-task-server.conf. - Passen Sie in der kopierten Datei den Pfad zum Task-Server an (Zeile - exec ....).

Danach kann der Task-Server mit dem folgenden Befehl gestartet - werden:

service kivitendo-task-server start

2.7.3.3. systemd-basierende Systeme (z.B. neure openSUSE, neuere - Fedora, neuere Ubuntu und neuere Debians)

Kopieren Sie die Datei - scripts/boot/systemd/kivitendo-task-server.service - nach /etc/systemd/system/. Passen Sie in der - kopierten Datei den Pfad zum Task-Server an (Zeilen - ExecStart=.... und - ExecStop=...).

Machen Sie anschließend das Script systemd bekannt, und binden - Sie es in den Boot-Prozess ein. Dazu führen Sie die folgenden Befehl - aus:

systemctl daemon-reload
-systemctl enable kivitendo-task-server.service

Wenn Sie den Task-Server jetzt sofort starten möchten, anstatt - den Server neu zu starten, so können Sie das mit dem folgenden - Befehl tun:

systemctl start kivitendo-task-server.service

2.7.4. Wie der Task-Server gestartet und beendet wird

Der Task-Server wird wie folgt kontrolliert:

./scripts/task_server.pl Befehl

- Befehl ist dabei eine der folgenden - Optionen:

  • - start startet eine neue Instanz des - Task-Servers. Die Prozess-ID wird innerhalb des - users-Verzeichnisses abgelegt.

  • - stop beendet einen laufenden - Task-Server.

  • - restart beendet und startet ihn - neu.

  • - status berichtet, ob der Task-Server - läuft.

Der Task-Server wechselt beim Starten automatisch in das - kivitendo-Installationsverzeichnis.

Dieselben Optionen können auch für die SystemV-basierenden - Runlevel-Scripte benutzt werden (siehe oben).

\ No newline at end of file + 2.7. Webserver-Konfiguration

2.7. Webserver-Konfiguration

In diesem Abschnitt wird die Konfiguration des Apache-Webservers + beschrieben. kivitendo wird mittels FastCGI/FCGI ausgeführt.

Es ist empfehlenswert, SSL einzusetzen, um die Daten per HTTPS + verschlüsselt zwischen Browser und Webserver über das Netzwerk zu + übertragen. Eine Möglichkeit dazu ist das Erstellen eines self-signed + SSL Zertifikates, was unter Debian/Ubuntu durch Installieren des Pakets + ssl-cert geschehen kann.

Der Zugriff auf den Installationspfad von kivitendo im Dateisystem + muss in der Apache Webserverkonfigurationsdatei eingestellt werden, + welche beim Starten des Webservers eingelesen wird. Wird SSL/HTTPS + eingesetzt, so ist dies die Datei default-ssl.conf, + für unverschlüsseltes HTTP ist es die Datei + 000-default.conf.

Bitte konsultieren Sie die Dokumentation des Apache-Webservers und + Ihres Betriebssystems. Es kann erforderlich sein, das SSL-Modul und die + Webserverkonfigurationsdatei zu aktivieren:

a2enmod ssl
+a2ensite default-ssl

Unter Fedora und openSUSE müssen weiterhin in der Firewall die + Ports 80 (HTTP) bzw. 443 (HTTPS) geöffnet werden.

2.7.1. Konfiguration für FastCGI/FCGI

Mit FastCGI wird der kivitendo-Programmcode beim Start des + Webservers einmal geladen und danach wird nur die eigentliche + Programmlogik ausgeführt.

Zuerst muss das FastCGI-Modul aktiviert werden. Dies kann + unter Debian/Ubuntu z.B. mit folgendem Befehl geschehen:

a2enmod fcgid

Die Konfiguration für die Verwendung von kivitendo mit FastCGI + erfolgt durch Einfügen von Alias- + und Directory-Direktiven. Dabei wird zwischen + dem Installationspfad von kivitendo im Dateisystem + ("/path/to/kivitendo-erp") und der URL + unterschieden, unter der kivitendo im Webbrowser erreichbar ist + ("/url/for/kivitendo-erp").

Folgender Konfigurationsschnipsel funktioniert mit + mod_fcgid:

AliasMatch ^/url/for/kivitendo-erp/[^/]+\.pl /path/to/kivitendo-erp/dispatcher.fcgi
+Alias       /url/for/kivitendo-erp/          /path/to/kivitendo-erp/
+FcgidMaxRequestLen 10485760
+
+<Directory /path/to/kivitendo-erp>
+  AllowOverride All
+  Options ExecCGI Includes FollowSymlinks
+  Require all granted
+</Directory>
+
+<DirectoryMatch /path/to/kivitendo-erp/users>
+  Require all denied
+</DirectoryMatch>

Hierdurch wird nur ein zentraler Dispatcher gestartet. Alle + Zugriffe auf die einzelnen Scripte werden auf diesen umgeleitet. + Dadurch, dass zur Laufzeit öfter mal Scripte neu geladen werden, + gibt es hier kleine Performance-Einbußen.

Seit mod_fcgid-Version 2.3.6 gelten sehr kleine Grenzen für + die maximale Größe eines Requests. Mit folgender Zeile wird diese + Grenze hochgesetzt:

FcgidMaxRequestLen 10485760

2.7.2. Aktivierung von mod_rewrite/directory_match für git basierte Installationen

+ Aufgrund von aktuellen (Mitte 2020) Sicherheitswarnungen für git basierte Webanwendungen ist die mitausgelieferte .htaccess + restriktiver geworden und verhindert somit das Auslesen von git basierten Daten. + Für debian/ubuntu muss das Modul mod_rewrite einmalig so aktiviert werden: +

a2enmod rewrite

+ Alternativ und für Installationen ohne Apache ist folgender Artikel interessant: + git-lücke. + Anstelle des dort beschriebenen DirectoryMatch für Apache2 würden wir etwas weitergehend auch noch das Verzeichnis config miteinbeziehen + sowie ferner auch die Möglichkeit nicht ausschließen, dass es in Unterverzeichnissen auch noch .git Repositories geben kann. + Die Empfehlung für Apache 2.4 wäre damit: +

+        <DirectoryMatch "/(\.git|config)/">
+          Require all denied
+        </DirectoryMatch>

+ +

2.7.3. Weitergehende Konfiguration

Für einen deutlichen Sicherheitsmehrwert sorgt die Ausführung + von kivitendo nur über https-verschlüsselten Verbindungen, sowie + weiteren Zusatzmassnahmen, wie beispielsweise Basic Authentication. Die + Konfigurationsmöglichkeiten sprengen allerdings den Rahmen dieser + Anleitung, hier ein Hinweis auf einen entsprechenden Foreneintrag + (Stand Sept. 2015) und einen aktuellen (Stand Mai 2017) + SSL-Konfigurations-Generator.

2.7.4. Aktivierung von Apache2 modsecurity

Aufgrund des OpenSource Charakters ist kivitendo nicht "out of the box" sicher. + Organisatorisch empfehlen wir hier die enge Zusammenarbeit mit einem kivitendo Partner der auch in der +Lage ist weiterführende Fragen in Bezug auf Datenschutz und Datensicherheit zu beantworten. +Unabhängig davon empfehlen wir im Webserver Bereich die Aktivierung und Konfiguration des Moduls modsecurity für den Apache2, damit +XSS und SQL-Injections verhindert werden.

Als Idee hierfür sei dieser Blog-Eintrag genannt: + + Test Apache2 modsecurity for SQL Injection.

\ No newline at end of file