Informationen über die Einrichtung der Benutzerauthentifizierung, - über die Verwaltung von Gruppen und weitere Einstellungen
Lx-Office 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 Lx-Office nur eine einzige - Datenbank, in der sowohl die Benutzerinformationen als auch die Daten - abgelegt werden.
Zusätzlich ermöglicht es Lx-Office, dass die Benutzerpasswörter - entweder gegen die Authentifizierungsdatenbank oder gegen einen - LDAP-Server überprüft werden.
Welche Art der Passwortüberprüfung Lx-Office benutzt und wie
- Lx-Office die Authentifizierungsdatenbank erreichen kann, wird in der
- Konfigurationsdatei config/lx_office.conf
- festgelegt. Diese muss bei der Installation und bei einem Upgrade von
- einer Version vor v2.6.0 angelegt werden. Eine
- Beispielkonfigurationsdatei
- config/lx_office.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 Lx-Office beim
- Datenbankserver anmeldet (z.B.
- "postgres")
password
- Das Passwort für den Datenbankbenutzer
Die Datenbank muss noch nicht existieren. Lx-Office kann sie - automatisch anlegen (mehr dazu siehe unten).
Lx-Office 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
- Lx-Office ä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 Lx-Office-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/lx_office.conf vorgenommen wurden, muss
- Lx-Office 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 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.
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
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).