Informationen über die Einrichtung der Benutzerauthentifizierung, - über die Verwaltung von Gruppen und weitere Einstellungen
kivitendo verwaltet die Benutzerinformationen in einer - Datenbank, die im folgenden âAuthentifizierungsdatenbankâ genannt - wird. Für jeden Benutzer kann dort eine eigene Datenbank für die - eigentlichen Finanzdaten hinterlegt sein. Diese beiden Datenbanken - können, müssen aber nicht unterschiedlich sein.
Im einfachsten Fall gibt es für kivitendo nur eine einzige - Datenbank, in der sowohl die Benutzerinformationen als auch die Daten - abgelegt werden.
Zusätzlich ermöglicht es kivitendo, dass die Benutzerpasswörter - entweder gegen die Authentifizierungsdatenbank oder gegen einen - LDAP-Server überprüft werden.
Welche Art der Passwortüberprüfung kivitendo benutzt und wie
- kivitendo die Authentifizierungsdatenbank erreichen kann, wird in der
- Konfigurationsdatei config/kivitendo.conf
- festgelegt. Diese muss bei der Installation und bei einem Upgrade von
- einer Version vor v2.6.0 angelegt werden. Eine
- Beispielkonfigurationsdatei
- config/kivitendo.conf.default existiert, die als
- Vorlage benutzt werden kann.
Das Passwort, das zum Zugriff auf das Aministrationsinterface
- benutzt wird, wird ebenfalls in dieser Datei gespeichert. Es kann auch
- nur dort und nicht mehr im Administrationsinterface selber geändert
- werden. Der Parameter dazu heiÃt admin_password im
- Abschnitt [authentication].
Die Verbindung zur Authentifizierungsdatenbank wird mit den
- Parametern in [authentication/database]
- konfiguriert. Hier sind die folgenden Parameter anzugeben:
host
- Der Rechnername oder die IP-Adresse des - Datenbankservers
port
- Die Portnummer des Datenbankservers, meist 5432
db
- Der Name der Authentifizierungsdatenbank
user
- Der Benutzername, mit dem sich kivitendo beim
- Datenbankserver anmeldet (z.B.
- "postgres")
password
- Das Passwort für den Datenbankbenutzer
Die Datenbank muss noch nicht existieren. kivitendo kann sie - automatisch anlegen (mehr dazu siehe unten).
kivitendo unterstützt Passwortüberprüfung auf zwei Arten: gegen
- die Authentifizierungsdatenbank und gegen einen externen LDAP- oder
- Active-Directory-Server. Welche davon benutzt wird, regelt der
- Parameter module im Abschnitt
- [authentication].
Sollen die Benutzerpasswörter in der Authentifizierungsdatenbank
- gespeichert werden, so muss der Parameter module
- den Wert DB enthalten. In diesem Fall können sowohl
- der Administrator als auch die Benutzer selber ihre Psaswörter in
- kivitendo ändern.
Soll hingegen ein externer LDAP- oder Active-Directory-Server
- benutzt werden, so muss der Parameter module auf
- LDAP gesetzt werden. In diesem Fall müssen
- zusätzliche Informationen über den LDAP-Server im Abschnitt
- [authentication/ldap] angegeben werden:
host
- Der Rechnername oder die IP-Adresse des LDAP- oder - Active-Directory-Servers. Diese Angabe ist zwingend - erforderlich.
port
- Die Portnummer des LDAP-Servers; meist 389.
tls
- Wenn Verbindungsverschlüsselung gewünscht ist, so diesen
- Wert auf â1â setzen, andernfalls auf
- â0â belassen
attribute
- Das LDAP-Attribut, in dem der Benutzername steht, den der
- Benutzer eingegeben hat. Für Active-Directory-Server ist dies
- meist âsAMAccountNameâ, für andere
- LDAP-Server hingegen âuidâ. Diese Angabe ist
- zwingend erforderlich.
base_dn
- Der Abschnitt des LDAP-Baumes, der durchsucht werden soll. - Diese Angabe ist zwingend erforderlich.
filter
- Ein optionaler LDAP-Filter. Enthält dieser Filter das Wort
- <%login%>, so wird dieses durch den vom
- Benutzer eingegebenen Benutzernamen ersetzt. Andernfalls wird
- der LDAP-Baum nach einem Element durchsucht, bei dem das oben
- angegebene Attribut mit dem Benutzernamen identisch ist.
bind_dn und
- bind_password
- Wenn der LDAP-Server eine Anmeldung erfordert, bevor er
- durchsucht werden kann (z.B. ist dies bei
- Active-Directory-Servern der Fall), so kann diese hier angegeben
- werden. Für Active-Directory-Server kann als
- âbind_dnâ entweder eine komplette LDAP-DN wie
- z.B. âcn=Martin
- Mustermann,cn=Users,dc=firmendomainâ auch nur der
- volle Name des Benutzers eingegeben werden; in diesem Beispiel
- also âMartin Mustermannâ.
Sollen auf einem Server mehrere kivitendo-Installationen
- aufgesetzt werden, so müssen die Namen der Session-Cookies für alle
- Installationen unterschiedlich sein. Der Name des Cookies wird mit dem
- Parameter cookie_name im Abschnitt
- [authentication]gesetzt.
Diese Angabe ist optional, wenn nur eine Installation auf dem - Server existiert.
Nachdem alle Einstellungen in
- config/kivitendo.conf vorgenommen wurden, muss
- kivitendo die Authentifizierungsdatenbank anlegen. Dieses geschieht
- automatisch, wenn Sie sich im Administrationsmodul anmelden, das unter
- der folgenden URL erreichbar sein sollte:
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 + +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-Job SetNumberRange akzeptiert zwei Variable nämlich digit_year sowieso multiplier.
+ digit_year kann 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.
+ multiplier ist 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