2.3. Manuelle Installation des Programmpaketes

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.

Bei einer Neuinstallation von Version 3.1.0 oder später muß 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 users
[Anmerkung]Anmerkung

Wir empfehlen eine Installation mittels des Versionsmanagager 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 der aktuelle release, den wir wollen
$ git add templates/fullhouse    # das sind unsere druckvorlagen inkl. produktbilder
$ git commit -m "juhu tolle ändernungen"
[meine_aenderungen 1d89e41] juhu tolle ändernungen
 4 files changed, 380 insertions(+)
 create mode 100644 templates/fullhouse/img/webdav/tesla.png
 create mode 100644 templates/fullhouse/mahnung.tex
 create mode 100644 templates/fullhouse/zahlungserinnerung_zwei.tex
 create mode 100644 templates/fullhouse/zahlungserinnerung_zwei_invoice.tex

# 5 Jahre später ...

$ git fetch
$ git rebase --onto release-3.5.0 release-3.4.1 meine_aenderungen
Zunächst wird der Branch zurückgespult, um Ihre Änderungen
darauf neu anzuwenden ...
Wende an: juhu tolle ändernungen
$ service apache2 restart