Der aktuelle Stable-Release, bzw. beta Release wird bei github +
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
+ 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-3.4.1.tgz
Wechseln Sie in das entpackte Verzeichnis:
cd kivitendo-erp
Alternativ können Sie auch einen Alias in der +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,
@@ -17,7 +17,7 @@ tar xvzf kivitendo-erp-3.4.1.tgz
Wechseln Sie in das entpackte Verzeichn
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
+ 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
@@ -28,18 +28,16 @@ tar xvzf kivitendo-erp-3.4.1.tgz
Wechseln Sie in das entpackte Verzeichn 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 "(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 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
+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 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