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.
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 -# Nur bei Debian Squeeze und neuer: -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
Verlinken 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 (Zeile
- ExecStart=.... und
- ExecStop=...). Binden Sie das Script in den
- Boot-Prozess ein.
Alle hierzu benötigten Befehle sehen so aus:
cd /var/www/kivitendo-erp/scripts/boot/systemd -ln -s $(pwd)/kivitendo-task-server.service /etc/systemd/system/
Danach kann der Task-Server mit dem folgenden Befehl gestartet - werden:
systemctl start 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).
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.
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
+ 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.