Der aktuelle Stable-Release, bzw. beta Release wird bei github gehostet und kann hier heruntergeladen werden.
Die kivitendo ERP Installationsdatei
(kivitendo-erp-3.4.1.tgz) wird im
Dokumentenverzeichnis des Webservers (z.B.
/var/www/html/,
/srv/www/htdocs oder
/var/www/) entpackt:
cd /var/www tar xvzf kivitendo-erp-3.4.1.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]](system/docbook-xsl/images/note.png) | 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
|