X-Git-Url: http://wagnertech.de/gitweb/gitweb.cgi/mfinanz.git/blobdiff_plain/63eaebf1acf18c476fa10e0a564b550edfc7054d..HEAD:/doc/html/ch02s04.html diff --git a/doc/html/ch02s04.html b/doc/html/ch02s04.html index b272eeac5..8a3745434 100644 --- a/doc/html/ch02s04.html +++ b/doc/html/ch02s04.html @@ -1,78 +1,69 @@
-In kivitendo gibt es nur noch eine Konfigurationsdatei,
- die benötigt wird: config/kivitendo.conf (kurz:
- "die Hauptkonfigurationsdatei"). Diese muss bei der Erstinstallation
- von kivitendo bzw. der Migration von älteren Versionen angelegt
- werden.
Als Vorlage dient die Datei
- config/kivitendo.conf.default (kurz: "die
- Default-Datei"):
$ cp config/kivitendo.conf.default config/kivitendo.conf
Die Default-Datei wird immer zuerst eingelesen. Werte, die in - der Hauptkonfigurationsdatei stehen, überschreiben die Werte aus der - Default-Datei. Die Hauptkonfigurationsdatei muss also nur die - Abschnitte und Werte enthalten, die von denen der Default-Datei - abweichen.
![]() | Anmerkung |
|---|---|
- Vor der Umbenennung in kivitendo hieà diese Datei noch |
Diese Hauptkonfigurationsdatei ist dann eine - installationsspezifische Datei, d.h. sie enthält bspw. lokale - Passwörter und wird auch nicht im Versionsmanagement (git) - verwaltet.
Die Konfiguration ist ferner serverabhängig, d.h. für alle - Mandaten, bzw. Datenbanken gleich.
Die Konfigurationsdatei besteht aus mehreren Teilen, die - entsprechend kommentiert sind:
- authentication (siehe Abschnitt "Abschnitt 2.8, âBenutzerauthentifizierung und Administratorpasswortâ" in diesem Kapitel)
- authentication/database
-
- authentication/ldap
-
- system
-
- paths
-
- mail_delivery (siehe Abschnitt "E-Mail-Versand über einen SMTP-Server)
- applications
-
- environment
-
- print_templates
-
- task_server
-
- periodic_invoices
-
- self_tests
-
- console
-
- testing
-
- testing/database
-
- debug
-
Die üblicherweise wichtigsten Parameter, die am Anfang - einzustellen oder zu kontrollieren sind, sind:
[authentication] -admin_password = geheim +2.4. Manuelle Installation des Programmpaketes \ No newline at end of file +[meine_aenderungen 1d89e41] juhu tolle ändernungen + 4 files changed, 380 insertions(+) + create mode 100644 templates/mein_druck/img/webdav/tesla.png + create mode 100644 templates/mein_druck/mahnung.tex + create mode 100644 templates/mein_druck/zahlungserinnerung_zwei.tex + create mode 100644 templates/mein_druck/zahlungserinnerung_zwei_invoice.tex + +# 5 Jahre später ... +# webserver abschalten! + +$ git checkout master +$ git pull # oder git fetch und danach ein stable release tag auswählen (s.o.) +$ git checkout meine_eigenen_änderungen +$ git rebase master + +Zunächst wird der Branch zurückgespult, um Ihre Ãnderungen +darauf neu anzuwenden ... +Wende an: juhu tolle änderungen +$ service apache2 restart # webserver starten! +Wir empfehlen eine Installation mittels des Versionsmanager + git. Hierfür muss ein git-Client installiert sein. Damit ist man sehr + viel flexibler für zukünftige Upgrades. Installations-Anleitung (bitte + die Pfade anpassen) bspw. wie folgt:
cd /var/www/ +git clone https://github.com/kivitendo/kivitendo-erp.git +cd kivitendo-erp/ +git checkout `git tag -l | egrep -ve "(alpha|beta|rc)" | tail -1`+ Erläuterung: Der Befehl wechselt zur letzten Stable-Version (git tag + -l listet alle Tags auf, das egrep schmeisst alle Einträge mit alpha, + beta oder rc raus und das tail gibt davon den obersten Treffer + zurück). Sehr sinnvoll ist es, direkt im Anschluss einen eigenen + Branch zu erzeugen, um bspw. seine eigenen Druckvorlagen-Anpassungen + damit zu verwalten. Hierfür reicht ein simples
git checkout -b meine_eigenen_änderungen+ nach dem letzten Kommando (weiterführende Informationen + Git Magic).
Ein beispielhafter Workflow für Druckvorlagen-Anpassungen von + 3.4.1 nach 3.5:
+$ git clone https://github.com/kivitendo/kivitendo-erp.git +$ cd kivitendo-erp/ +$ git checkout release-3.4.1 # das ist ein alter release aus dem wir starten ... +$ git checkout -b meine_eigene_änderungen # unser lokaler branch - unabhängig von allen anderen +$ git add templates/mein_druck # das sind unsere druckvorlagen inkl. produktbilder +$ git commit -m "juhu tolle änderungen" -[authentication/database] -host = localhost -port = 5432 -db = kivitendo_auth -user = postgres -password =Nutzt man wiederkehrende Rechnungen, kann man unter -
[periodic_invoices]den Login eines Benutzers - angeben, der nach Erstellung der Rechnungen eine entsprechende E-Mail - mit Informationen über die erstellten Rechnungen bekommt.kivitendo bringt eine eigene Komponente zur zeitgesteuerten Ausführung bestimmter Aufgaben mit, den Taskserver. Er wird u.a. für Features wie die wiederkehrenden Rechnungen benötigt, erledigt aber auch andere erforderliche Aufgaben - und muss daher in Betrieb genommen werden. Der Taskserver benötigt zwei Konfigurationseinstellungen, die unter -
[task_server]anzugeben sind: ein Mandant (entweder der Mandantenname oder eine Datenbank-ID, Variable -client), aus dem die Datenbankkonfiguration entnommen wird, sowie ein Login (Variablelogin) - eines Benutzers, der für gewisse Dinge wie die Rechnungserstellung als Verkäufer eingetragen wird.Für Entwickler finden sich unter
[debug]- wichtige Funktionen, um die Fehlersuche zu erleichtern.In älteren kivitendo Versionen gab es im Verzeichnis -
configdie Dateien -authentication.plund -lx-erp.conf, die jeweils Perl-Dateien waren. Es - gab auch die Möglichkeit, eine lokale Version der Konfigurationsdatei - zu erstellen (lx-erp-local.conf). Dies ist ab - 2.6.3 nicht mehr möglich, aber auch nicht mehr nötig.Beim Update von einer kivitendo-Version vor 2.6.3 auf 2.6.3 oder - jünger müssen die Einstellungen aus den alten Konfigurationsdateien - manuell übertragen und die alten Konfigurationsdateien anschlieÃend - gelöscht oder verschoben werden. Ansonsten zeigt kivitendo eine - entsprechende Fehlermeldung an.
+
Der aktuelle Stable-Release, bzw. beta Release wird bei github + gehostet und kann hier + heruntergeladen werden.
Das aktuelleste kivitendo ERP-Archiv
+ (kivitendo-erp-*.tgz) wird dann im
+ Dokumentenverzeichnis des Webservers (z.B.
+ /var/www/html/,
+ /srv/www/htdocs oder
+ /var/www/) entpackt:
cd /var/www +tar xvzf kivitendo-erp-*.tgz
Wechseln Sie in das entpackte Verzeichnis:
cd kivitendo-erp
Alternativ können Sie auch einen Alias in der + Webserverkonfiguration benutzen, um auf das tatsächliche + Installationsverzeichnis zu verweisen.
Die folgenden Schritte müssen nach der Installation mittels git + oder der Github Website angewendet werden.
Bei einer Neuinstallation von Version 3.1.0 oder später muss das + WebDAV Verzeichnis derzeit manuell angelegt werden:
mkdir webdav
Die Verzeichnisse users,
+ spool und webdav müssen für
+ den Benutzer beschreibbar sein, unter dem der Webserver läuft. Die
+ restlichen Dateien müssen für diesen Benutzer lesbar sein. Die Benutzer-
+ und Gruppennamen sind bei verschiedenen Distributionen unterschiedlich
+ (z.B. bei Debian/Ubuntu www-data, bei Fedora
+ apache oder bei openSUSE
+ wwwrun).
Der folgende Befehl ändert den Besitzer für die oben genannten + Verzeichnisse auf einem Debian/Ubuntu-System:
chown -R www-data users spool webdav
Weiterhin muss der Webserver-Benutzer in den Verzeichnissen
+ templates und users
+ Unterverzeichnisse für jeden neuen Benutzer anlegen dürfen, der in
+ kivitendo angelegt wird:
chown www-data templates