X-Git-Url: http://wagnertech.de/git?a=blobdiff_plain;ds=sidebyside;f=doc%2Fhtml%2Fch02s07.html;h=456c85ab86d079815c4f04a9fe7b9a146131a40e;hb=f775b88a24af70fd667683ee235adc2d450e83b9;hp=cad0eb807eb128d90635ae6291a6ebbbac0d7a83;hpb=15f021a67aa7e26458a3fbac8efe89ef9c0b0657;p=kivitendo-erp.git diff --git a/doc/html/ch02s07.html b/doc/html/ch02s07.html index cad0eb807..456c85ab8 100644 --- a/doc/html/ch02s07.html +++ b/doc/html/ch02s07.html @@ -1,71 +1,66 @@
- -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.
Die Konfiguration erfolgt über den Abschnitt
+ [task_server]
in der Datei
+ config/kivitendo.conf
. Die dort verfügbaren
+ Optionen sind:
client
+ Name oder Datenbank-ID eines vorhandenen kivitendo-Mandanten, der benutzt wird, um die zu verwendende + Datenbankverbindung auszulesen. Der Mandant muss in der Administration angelegt werden. Diese Option muss angegeben + werden.
Diese Option kam mit Release v3.x.0 hinzu und muss daher in Konfigurationen, die von älteren Versionen aktualisiert + wurden, ergänzt werden.
login
+ gültiger kivitendo-Benutzername, der z.B. als Verkäufer beim Erzeugen wiederkehrender Rechnungen benötigt wird. Der + Benutzer muss in der Administration angelegt werden. Diese Option muss angegeben werden.
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 sinnvoll, hier denselben Systembenutzer einzutragen,
+ unter dem auch der Webserver läuft.
debug
+ Schaltet Debug-Informationen an und aus.
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-server
+ nach /etc/init.d/kivitendo-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 Core:
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).
Beim Task-Server werden der zu verwendende Mandant und Login-Name des Benutzers, unter dem der Task-Server laufen soll, in die + Konfigurationsdatei geschrieben. Hat man mehrere Mandanten, muss man auch mehrere Konfigurationsdateien anlegen.
Die Konfigurationsdatei ist eine Kopie der Datei kivitendo.conf, wo in der Kategorie [task_server]
die
+ gewünschten Werte für client
und login
eingetragen werden.
Der alternative Task-Server wird dann mit folgendem Befehl + gestartet:
./scripts/task_server.pl -c config/DATEINAME.conf