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 Task-Server als Perlscript läuft, wird Arbeitsspeicher, der - einmal benötigt wurde, nicht mehr an das Betriebssystem zurückgegeben, - solange der Task-Server läuft. Dies kann dazu führen, dass ein länger - laufender Task-Server mit der Zeit immer mehr Arbeitsspeicher für sich - beansprucht. Es ist deshalb sinnvoll, dass der Task-Server in - regelmässigen Abständen neu gestartet wird. Allerdings berücksichtigt der - Task-Server ein Memory-Limit, wenn dieses in der Konfigurationsdatei - angegeben ist. Bei Ãberschreiten dieses Limits beendet sich der - Task-Server. Sofern der Task-Server als systemd-Service mit dem - mitgelieferten Skript eingerichtet wurde, startet dieser danach - automatisch erneut.
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.
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.
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.
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
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
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
Ein so eingerichteter Task-Server startet nach Beendigung - automatisch erneut. Das betrifft eine Beendigung über die Oberfläche, - eine Beendingung über die Prozesskontrolle und eine Beendigung bei - Ãberschreiten des Memory-Limits. Soll der Task-Server nicht erneut - starten, so können Sie ihn mit folgendem Befehl stoppen:
systemctl stop kivitendo-task-server.service
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).
Wurde der Task-Server als systemd-Service eingerichtet (s.o.), - so startet dieser nach Beendigung automatisch erneut.
Hintergrund-Jobs werden über System -> Hintergrund-Jobs und Task-Server -> Aktuelle Hintergrund-Jobs anzeigen -> Aktions-Knopf 'erfassen' angelegt.
Nachdem wir über das Menü dort angelangt sind, legen wir unseren exemplarischen Hintergrund-Jobs "Erhöhung der Nummernkreise" mit folgenden Werten an:
- Aktiv: Hier ein 'Ja' auswählen
- Ausführungsart: 'wiederholte Ausführung' auswählen
- Paketname: 'SetNumberRange' auswählen
- Ausführungszeitplan: Hier entsprechend Werte wie in der crontab eingeben.
Syntax:
* * * * * -⬠⬠⬠⬠⬠-â â â â â -â â â â âââââ Wochentag (0-7, Sonntag ist 0 oder 7) -â â â âââââââ Monat (1-12) -â â âââââââââ Tag (1-31) -â âââââââââââ Stunde (0-23) -âââââââââââââ Minute (0-59)
Die Sterne können folgende Werte haben:
-1 2 3 4 5 +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-certgeschehen 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-sslUnter Fedora und openSUSE müssen weiterhin in der Firewall die + Ports 80 (HTTP) bzw. 443 (HTTPS) geöffnet werden.
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 fcgidDie Konfiguration für die Verwendung von kivitendo mit FastCGI + erfolgt durch Einfügen von
Alias- + undDirectory-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 -1 = Minute (0-59) -2 = Stunde (0-23) -3 = Tag (0-31) -4 = Monat (1-12) -5 = Wochentag (0-7, Sonntag ist 0 oder 7) -Um die Ausführung auf eine Minute vor Sylvester zu setzen, müssen die folgenden Werte eingetragen werden:
59 23 31 12 *-
Daten:In diesem Feld können optionale Parameter für den Hintergrund im JSON-Format gesetzt werden. Der Hintergrund-JobSetNumberRangeakzeptiert zwei Variable nämlichdigit_yearsowiesomultiplier.-
digit_yearkann zwei Werte haben entweder 2 oder 4, darüber wird gesteuert ob die Jahreszahl zwei oder vierstellig kodiert wird (für 2019, dann entweder 19 oder 2019). Der Standardwert ist vierstellig.-
multiplierist ein Vielfaches von 10, darüber wird die erste Nummer im Nummernkreis (die Anzahl der Stellen) wie folgt bestimmt:-multiplier Nummernkreis 2020 -10 -> 20200 -100 -> 202000 -1000 -> 2020000 -Wir gehen jetzt beispielhaft von einer letzten Rechnungsnummer von RE2019456 aus. Demnach sollte ab Januar 2020 die erste Nummer RE2020001 sein. Da der Task auch Präfixe berücksichtigt, kann dies mit folgenden JSON-kodierten Werten umgesetzt werden:
Daten:multiplier: 100 -digits_year: 4
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
+ 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>
+ +
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.
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.