X-Git-Url: http://wagnertech.de/gitweb/gitweb.cgi/mfinanz.git/blobdiff_plain/35b746e48500af6da78e70a0a9c11b618c1cfde8..HEAD:/doc/html/ch02s04.html diff --git a/doc/html/ch02s04.html b/doc/html/ch02s04.html index 1efbfcaee..8a3745434 100644 --- a/doc/html/ch02s04.html +++ b/doc/html/ch02s04.html @@ -1,40 +1,69 @@ - - 2.4. Anpassung der PostgreSQL-Konfiguration

2.4. Anpassung der PostgreSQL-Konfiguration

PostgreSQL muss auf verschiedene Weisen angepasst werden.

2.4.1. Zeichensätze/die Verwendung von UTF-8

Lx-Office kann komplett mit UTF-8 als Zeichensatz verwendet - werden. Dabei gibt es zwei Punkte zu beachten: PostgreSQL muss in - Version 8.2 oder neuer benutzt werden, und der - PostgreSQL-Datenbankcluster muss ebenfalls mit UTF-8 als Locale - angelegt worden sein.

Dieses ist kann überprüft werden: ist das Encoding der Datenbank - “template1” “UTF8”, so kann auch Lx-Office mit UTF-8 betrieben werden. - Andernfalls ist es notwendig, einen neuen Datenbankcluster mit - UTF-8-Encoding anzulegen und diesen zu verwenden. Unter Debian und - Ubuntu kann dies z.B. für PostgreSQL 8.2 mit dem folgenden Befehl - getan werden:

pg_createcluster --locale=de_DE.UTF-8 --encoding=UTF-8 8.2 clustername

Die Datenbankversionsnummer muss an die tatsächlich verwendete - Versionsnummer angepasst werden.

Unter anderen Distributionen gibt es ähnliche Methoden.

Wurde PostgreSQL nicht mit UTF-8 als Encoding initialisiert und - ist ein Neuanlegen eines weiteren Clusters nicht möglich, so kann - Lx-Office mit ISO-8859-15 als Encoding betrieben werden.

Das Encoding einer Datenbank kann in psql mit - \l geprüft werden.

2.4.2. Änderungen an Konfigurationsdateien

In der Datei postgresql.conf, die je nach - Distribution in verschiedenen Verzeichnissen liegen kann (z.B. - /var/lib/pgsql/data/ oder - /etc/postgresql/, muss sichergestellt werden, - dass TCP/IP-Verbindungen aktiviert sind. Das Verhalten wird über den - Parameter listen_address gesteuert. Laufen - PostgreSQL und Lx-Office auf demselben Rechner, so kann dort der Wert - localhost verwendet werden. Andernfalls müssen - Datenbankverbindungen auch von anderen Rechnern aus zugelassen werden, - was mit dem Wert * geschieht.

In der Datei pg_hba.conf, die im gleichen - Verzeichnis wie die postgresql.conf zu finden - sein sollte, müssen die Berichtigungen für den Zugriff geändert - werden. Hier gibt es mehrere Möglichkeiten. Eine besteht darin, lokale - Verbindungen immer zuzulassen:

local all all trust
-host all all 127.0.0.1 255.0.0.0 trust

Besser ist es, für eine bestimmte Datenbank Zugriff nur per - Passwort zuzulassen. Beispielsweise:

local all lxoffice password
-host all lxoffice 127.0.0.1 255.255.255.255 password

2.4.3. Erweiterung für servergespeicherte Prozeduren

In der Datenbank template1 muss die - Unterstützung für servergespeicherte Prozeduren eingerichet werden. - Melden Sie sich dafür als Benutzer “postgres” an der Datenbank an, und - führen Sie die folgenden Kommandos aus:

create language 'plpgsql';

2.4.4. Datenbankbenutzer anlegen

Wenn Sie nicht den Datenbanksuperuser “postgres” zum Zugriff - benutzen wollen, so sollten Sie bei PostgreSQL einen neuen Benutzer - anlegen. Ein Beispiel, wie Sie einen neuen Benutzer anlegen - können:

su - postgres createuser -d -P lxoffice

Wenn Sie später einen Datenbankzugriff konfigurieren, verändern - Sie den evtl. voreingestellten Benutzer “postgres” auf “lxoffice” bzw. - den hier gewählten Benutzernamen.

\ No newline at end of file + + 2.4. Manuelle Installation des Programmpaketes

2.4. Manuelle Installation des Programmpaketes

2.4.1. Installation mit git

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"
+
+[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!
+

+

2.4.2. Installation über die Github Website

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.

2.4.3. Restliche Verzeichnisse ändern und bearbeiten

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
\ No newline at end of file