IT-Service GmbH

Installation vtiger

Allgemeines zu Debian, PHP und vtiger

Hier eine Übersicht, welche PHP Versionen unter welcher Debianversion mitgeliefert werden:

Debian (Version)	PHP
lenny (5)	5.2
squeeze (6)	5.3
wheezy (7)	5.4
jessie (8)	5.6
stretch (9)	7.0
buster (10)	7.3

und hier eine Tabelle, welche vtiger Versionen mit welche PHP Versionen laufen, soweit ich das gefunden und probiert habe.

vtiger	PHP
5.4	5.2-5.3 mit Tricks: - 5.6 !
6.0	5.3-5.6
6.1	5.4-5.6
6.2	5.5-5.6
6.3	?-5.6
6.4	?-5.6
6.5	?-5.6
7.0	?-5.6
7.1	?-5.6 (7.0 mit Warnings)
7.2	?-7.0

Unter jessie habe ich /var/www/vtigercrm von der squeeze Installation kopiert und die Datenbank angelegt. Anschliessend wieder "install.php" im Browser gestartet.
jessie ist zum Upgrade von Vtiger 5.4 bis 7.1 bestens geeignet, es bringt PHP 5.6 mit, unter dem alle vtiger ab 6.0 problemlos funktionieren. Und die Tricks, um vtiger 5.4 unter PHP 5.6 zum Laufen zu bringen, werden hier beschrieben.
kurz zur Direktinstallation von vtiger 5.4 unter jessie/PHP 5.6:
Voraussetzungen installieren und vtiger 5.4.0 selbst auspacken. Das habe ich unter squeeze durchgeführt und das funktioniert unter wheezy und jessie prinzipiell genauso. Mit dem Unterschied, dass das bei wheezy installierte PHP 5.4 die Direktive allow_call_time_pass_reference = On in der php.ini nicht mehr unterstützt und deshalb immer ein Fehler entsteht, der aber durch die Direktive error_reporting unterdrückt wird.

# aptitude install apache2 mysql-server php5 php5-gd libapache2-mod-auth-mysql php5-mysql
# /etc/init.d/apache2 restart
# tar xzvf vtiger*.tar.gz -C /var/www

Nun müssen einige Rechte angepasst werden, die Installationsseite unter http://wega.ulm.go-itservice.de/vtigercrm zeigt alle noch fehlenden Rechte und fehlende Einstellungen in der /etc/php5/apache/php.ini aber an, so eigentlich nichts schiefgehen kann. Ich hatte vorher alle chmods in ein shellskript installvtiger.sh gepackt.
Einstellungen in der php.ini anpassen:

Directive 	Recommended PHP.ini value
display_errors 	On
max_execution_time 	600
error_reporting 	E_WARNING & ~E_NOTICE & ~E_DEPRECATED		# unter jessie siehe siehe Apache 2 
allow_call_time_pass_reference 	On                              # unter jessie egal, siehe siehe Apache 2 
log_errors 	Off

Datenbank anlegen, entweder via phpmyadmin oder auf der Kommandozeile:

> CREATE DATABASE `vtiger` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
> GRANT ALL PRIVILEGES ON vtiger.* TO vtiger@localhost IDENTIFIED BY 'DBPASSWD';

Vor der Konfiguration müssen beim derzeit aktuellen vtiger 5.4.0 einige Codezeilen geändert werden, was ich im Internet herausfand. Das ist natürlich auch nötig, wenn vtiger von einem anderen Rechner kopiert wurde.
1. die Datei INSTALLDIR/include/utils/CommonUtils.php
alle Vorkommnisse der Variablen $_FILES. Diese einfach durch $FILES ersetzen.
2. die Datei installdir/modules/Users/Authenticate.php
ab ca Zeile 70 folgendes ersetzen

//Security related entries end
session_unregister('login_password');
session_unregister('login_error');
session_unregister('login_user_name');

durch:

//Security related entries end
session_unset($_SESSION['login_password']);
session_unset($_SESSION['login_error']);
session_unset($_SESSION['login_user_name']);

Erstaunlicherweise scheinen das die einzigen kritischen Stellen zu sein!
CRM Configuration im Browser starten (falls nicht kopiert), analog hierzu:

http://wega.ulm.go-itservice.de/vtigercrm

Im Browser:

Currency Name: EURO	
DB:		127.0.0.1
user:		vtiger
pass:		DBPASSWD
name:		vtiger
User Configuration
Username:	admin
Password: 	ADMINPASSWD
Email: 		admin@domain.de
Installieren: Language Packs ausser GERMAN abwählen

So, Basiskonfiguration steht, im Admin Interface admin - Konfiguration den Mail Server einrichten.
in der Shell mit crontab -e einen cron-Job fuer vtigercron.sh einrichten

0,15,30,45 * * * * sh /var/www/vtigercrm/cron/vtigercron.sh

Aus Sicherheitsgründen sollten die install-Dateien umbenannt werden und der Zugriff via .htaccess eingeschränkt werden

# cd /var/www/vtigercrm
# mv install.php installVT540if.php
# mv install installVT540if
# cp htaccess.txt .htaccess

in der apache Konfiguration für die Domain oder das Unterverzeichnis von vtiger muss "AllowOverride All" gesetzt sein, damit die .htaccess berücksichtigt wird notfalls Options -Indexes in der Apache-Konfiguration setzten, das verhindert das Schlimmste.
So, jetzt wirds harzig. Im Releasepaket von vtiger 5.4.0 fehlten die deutschen Sprachdateien, diese habe ich aus dem älteren Release Candidate herauskopiert und anschliessend in meine Installation eingefügt. Hoffentlich ist das Problem inzwischen wieder behoben! Das Vorgehen kann ich nicht genau beschreiben, hat eine Weile gedauert. Wer es selber nicht hinbekommt, mail an mich!
Dann in der Weboberfläche: User anlegen
Organisationen, Personen anlegen
Ich baute eine Importseite für die alte Exceldatei des Kunden, um mehrere Standorte und Ansprechpartner unter einer Organisation zu abbilden zu können und ein Modul zur Übergabe von Org-Einheiten nebst Unterobjekten an einen anderen Mitarbeiter.
Inzwischen erweiterte ich das Modul so, das der admin Kommentare aus vTiger löschen kann.
Doku, Anleitungen: https://wiki.vtiger.com/
Dokus zur Entwicklung: https://wiki.vtiger.com/index.php/Developers_How_To's
Doku, Tips: https://help.vtiger.com
Diskussion, Tips: https://discussions.vtiger.com
Videodukus: http://youtube.com/vtigercrm
Dateirechte: https://it-solutions4you.com/tipstricks/vtiger-system-requirements/

Falls man das Passwort vom vtiger admin vergessen hat: Via mysql oder phpmyadmin auf die vtiger-Datenbank verbinden, dort folgendes SQL-Statement absetzen:

SQL> UPDATE vtiger_users SET user_hash=NULL,confirm_password=NULL,crypt_type='',accesskey=NULL,user_password='adpexzg3FUZAk' WHERE id=1;

Nun kann man sich als admin mit Passwort "admin" wieder anmelden. Der Tip stammt in abgewandelter Form aus dem vtiger-Forum und funktioniert auch bei 5.4.0 noch.

Vtiger upgrade

Um von vtiger 5.4.0 auf die derzeit aktuelle 7.2 zu aktualisieren, muß nacheinander auf alle Zwischenreleases aktuallisiert werden: 5.4 -> 6.0 -> 6.1 -> 6.2 -> 6.3 -> 6.4 -> 6.5 -> 7.0 -> 7.1 -> 7.2. Schon der erste Schritt, von 5.4.0 auf 6.0 war eine Herausforderung!
Um das nicht beim Kunden vor Ort das erste Mal zu machen, kopierte ich die dortige Installation und konfigurierte das so erzeugte Abbild für mein Netz vach (192.168.40.0)

Testrechner kopieren

Das eigentliche Kopieren ist hier, in der Dokumentation zu stretch beschrieben.
Umstellung deneb.if -> enif.vach
IP von 192.168.100.13 -> 192.168.40.42
grub.conf: Umstellung von Boot von md0-Software Raid auf Single-SSD
Passwd auf Standard
da ich die Kopie mit rsync dummerweise ohne die Option "--numeric-ids" remote auf ein anderes Zielsystem erzeugte, musste ich auf der Zielplatte noch die relevanten Verzeichnisse den richtigen Usern übergeben:

# cd /usr/lib; chown -R mysql:mysql mysql/
# cd /var/www; chown -R www-data:www-data vtigercrm/

falls das Update zerschossen ist, kann es aus der im Filesystem gespeicherten Kopie des Rechners restauriert werden:

# rsync --numeric-ids --progress --delete -avrtHAX  root@spica:/home/go/enif.vach.540.ok/var/www/vtigercrm/ /var/www/vtigercrm/
# mysql -uvtiger -pDBPASSWD vtiger < vtiger.540.sql

Vtiger upgrade 5.4 auf 6.0

Alle Updatepatches findet man leicht auf der vtiger-Seite. Die heruntergeladene patch.zip auspacken, ein Ordner migrate und eine Datei vtiger6.zip wird erzeugt. Diese werden direkt in in den vtiger Ordner /var/www/vtigercrm/ kopiert. Möglicherweise Rechte anpassen (2.Zeile)

# rsync -avrt /root/vtiger.540/UPDATE.540_600/ /var/www/vtigercrm/
# cd /var/www; chown -R www-data:www-data vtigercrm/

Beim ersten Updateversuch im Browser mit http://192.168.40.42/vtigercrm/migrate kam zuerst ein Fehler, später der zweite. Der Aufruf der URL, beziehungsweise die Bestätigung mit Admin User und Passwort kopiert die php-Dateien der nächsten Version aus dem Archiv bereits an den richtigen Platz, ein "Zurück gibt es dann ausser mit dem restore der gesicherten Dateien nicht mehr.

Fatal error: Cannot redeclare getHistory() (previously declared in /var/www/vtigercrm/include/Webservices/Relation.php:19) in /var/www/vtigercrm/include/RelatedListView.php on line 420)

Ein weiterer Fehler entstand durch die geänderte URL im Browser, welche vtiger als CSRF-Attacke interpretiert und mit einer Illegal request Exception quitierte. Zur Behebung der Beiden:

vi /var/www/vtigercrm/include/RelatedListView.php 	:Zeile 26 getHistory( => getHistoryxxx(
vi /var/www/vtigercrm/includes/http/Request.php 	:Zeile 212 auskommentieren: => // throw new Exception('Illegal request');

Dann im Browser "RELOAD" drücken, was die Migration der Datenbank startet. Please Wait und ein umlaufender Balken ist zu sehen. Wichtig: Im Browser muss Javascript für http://192.168.40.42 erlaubt sein. Die Migration dauerte auf dem betagten X201, in den ich das Image steckte, ca 15 Minuten. Mit top sieht man, dass der mysqld heftig Last verursacht und das Skript nicht einfach abgestürzt ist. Bei einer weiteren Installation lief die Webseite ewig weiter, obwohl die Migration der DB beendet war (top auf 0.01). Nach 10 Minuten drückte ich dann im Browser reload und die nächsten Schritte kamen dann auch. Am Ende muss man 3x weiter klicken und vtiger 6.0 ist fertig und testbereit.
Zur Sicherheit wird sofort ein Datenbankdump und ein Plattenimage erstellt:

# mysqldump -uvtiger -pDBPASSWD vtiger > /root/vtiger.600.sql
# /etc/init.d/mysql stop
# rsync --numeric-ids --progress --exclude /proc --exclude /sys --exclude /dev --exclude /home --exclude /tmp --exclude /run -avrtHAX / root@spica:/home/go/enif.vach.600/
# /etc/init.d/mysql start

Statt letzterem reicht wahrscheinlich auch eine Sicherung von /var/www/vtigercrm. Anschliessend testete ich vtiger kurz.

Vtiger upgrade 6.0 auf 6.1

Exakt das selbe wie beim Update von 5.4 auf 6.0: patch.zip auspacken, ein Ordner migrate und eine Datei vtiger6.zip wird erzeugt. Diese werden direkt in in den vtiger Ordner /var/www/vtigercrm/ kopiert. Rechte anpassen (2.Zeile)

# rsync -avrt /root/vtiger.540/UPDATE.600_610/ /var/www/vtigercrm/
# cd /var/www; chown -R www-data:www-data vtigercrm/

Im Browser mit http://192.168.40.42/vtigercrm/migrate starten und dann der identische Fehler (Nummer 2) wie beim letzten Update, ich könnte das wahrscheinlich in irgendeiner Konfigurationsdatei beheben, aber egal.

vi /var/www/vtigercrm/includes/http/Request.php 	:212 auskommentieren: => // throw new Exception('Illegal request');

Dann im Browser "RELOAD" drücken, was die Migration der Datenbank startet und diesmal nur etwa eine Minute dauert. Anschliessend sieht man mögliche Fehler im Log. Nach zwei "weiter" Buttons ist vtiger 6.1 startklar. Datenbank und Plattenimage erstellen:

# mysqldump -uvtiger -pDBPASSWD vtiger > /root/vtiger.610.sql
# /etc/init.d/mysql stop
# rsync --numeric-ids --progress --exclude /proc --exclude /sys --exclude /dev --exclude /home --exclude /tmp --exclude /run -avrtHAX / root@spica:/home/go/enif.vach.610/
# /etc/init.d/mysql start

Vtiger upgrade 6.1 auf 6.2

Exakt das selbe wie bisher. patch.zip auspacken, ein Ordner migrate und eine Datei vtiger6.zip wird erzeugt. Diese werden direkt in in den vtiger Ordner /var/www/vtigercrm/ kopiert. Rechte anpassen (2.Zeile)

# rsync -avrt /root/vtiger.540/UPDATE.610_620/ /var/www/vtigercrm/
# cd /var/www; chown -R www-data:www-data vtigercrm/

Im Browser mit http://192.168.40.42/vtigercrm/migrate starten und der identische Fehler (Nummer 2) erscheint wie immer

vi /var/www/vtigercrm/includes/http/Request.php 	:213 auskommentieren: => // throw new Exception('Illegal request');

Dann im Browser "RELOAD" drücken, was die Migration der Datenbank startet und diesmal sofort beendet ist. Im Log sind nur drei Einträge zu sehen. Nach einem "weiter" Button ist vtiger 6.2 startklar. Datenbank und Plattenimage erstellen:

# mysqldump -uvtiger -pDBPASSWD vtiger > /root/vtiger.620.sql
# /etc/init.d/mysql stop
# rsync --numeric-ids --progress --exclude /proc --exclude /sys --exclude /dev --exclude /home --exclude /tmp --exclude /run -avrtHAX / root@spica:/home/go/enif.vach.620/
# /etc/init.d/mysql start

Vtiger upgrade 6.2 auf 6.3

# rsync -avrt /root/vtiger.540/UPDATE.620_630/ /var/www/vtigercrm/
# cd /var/www; chown -R www-data:www-data vtigercrm/

Im Browser mit http://192.168.40.42/vtigercrm/migrate starten und - oh Wunder, kein Fehler! Die Migration der Datenbank dauert wieder nur wenige Sekunden. Im Log sind nur einige Dutzend mit "Success" quitierte Einträ zu sehen. Nach zwei "weiter" Buttons ist vtiger 6.3 startklar. Datenbank und Plattenimage erstellen:

# mysqldump -uvtiger -pDBPASSWD vtiger > /root/vtiger.630.sql
# /etc/init.d/mysql stop
# rsync --numeric-ids --progress --exclude /proc --exclude /sys --exclude /dev --exclude /home --exclude /tmp --exclude /run -avrtHAX / root@spica:/home/go/enif.vach.630/
# /etc/init.d/mysql start

Vtiger upgrade 6.3 auf 6.4

# rsync -avrt /root/vtiger.540/UPDATE.630_640/ /var/www/vtigercrm/
# cd /var/www; chown -R www-data:www-data vtigercrm/

Im Browser mit http://192.168.40.42/vtigercrm/migrate starten und wieder kein Fehler! Die Migration der Datenbank dauert wie beim letzten Update wenige Sekunden. Im Log sind nur einige Dutzend mit "Faulure" quitierte Einträ zu sehen, welche von einem anscheinend möglichen Update direkt von vtiger 6.2 auf 6.4 stammen. Die für das Update von 6.3 auf 6.4 zusätzlichen Log-Einträge (3 oder 4) zeigten "Success". Nach zwei "weiter" Buttons ist auch vtiger 6.4 startklar. Datenbank und Plattenimage erstellen:

# mysqldump -uvtiger -pDBPASSWD vtiger > /root/vtiger.640.sql
# /etc/init.d/mysql stop
# rsync --numeric-ids --progress --exclude /proc --exclude /sys --exclude /dev --exclude /home --exclude /tmp --exclude /run -avrtHAX / root@spica:/home/go/enif.vach.640/
# /etc/init.d/mysql start

Vtiger upgrade 6.4 auf 6.5

# rsync -avrt /root/vtiger.540/UPDATE.640_650/ /var/www/vtigercrm/
# cd /var/www; chown -R www-data:www-data vtigercrm/

Dann sofort in /var/www/vtigercrm/config.inc.php die Zeile

$site_URL = 'http://192.168.40.42/vtigercrm';

auf die IP des Server ändern. Dies ist bei einer normalen Installation vielleicht nicht nötig, wohl aber, wenn man die IP des Servers manuell geändert hat. Bei mir geschah folgendes:
Das Migrationskript leitet auf die in der /var/www/vtigercrm/config.inc.php codierte URL $site_URL weiter, auch wenn ich die 192.168.40.42 manuell im Browser eingebe. Also mache ich das, was ich am Besten schon am Anfang gemacht hätte, nachdem ich mit

# rsync --numeric-ids --progress --delete -avrtHAX  root@spica:/home/go/enif.vach.640.ok/var/www/vtigercrm/ /var/www/vtigercrm/

den vtiger 6.4 wieder restauriert und die Migrationsdateien wieder herkopiert habe. Ich ändere die Zeile 82 in /var/www/vtigercrm/config.inc.php zu:

$site_URL = 'http://192.168.40.42/vtigercrm';

so, diesmal läuft das Update anders ab: Sofort nach "start Migration" auf der Seite http://192.168.40.42/vtigercrm/migrate kommt der Anmeldebildschirm von vtiger 6.5, so als ob kein Update erfolgte. Aber diesmal startet die Migration der Datenbank erst nach dem Einloggen. Anscheinend sind die Änderungen von 6.3 auf 6.4 in diesem Patch ebenfalls enthalten, zumindest sah es bei mir danach aus. Nach zwei "weiter" Buttons ist auch vtiger 6.5 startklar. Datenbank und Plattenimage erstellen:

# mysqldump -uvtiger -pDBPASSWD vtiger > /root/vtiger.650.sql
# /etc/init.d/mysql stop
# rsync --numeric-ids --progress --exclude /proc --exclude /sys --exclude /dev --exclude /home --exclude /tmp --exclude /run -avrtHAX / root@spica:/home/go/enif.vach.650/
# /etc/init.d/mysql start

Vtiger upgrade 6.5 auf 7.0

Exakt das selbe wie bisher, allerdings war ich wegen dem Versionssprung natürlich gespannt. patch.zip auspacken, ein Ordner migrate, drei weitere(vtlib,modules,includes) und eine 35MB grosse Datei vtiger7.zip wird erzeugt. Diese werden direkt in in den vtiger Ordner /var/www/vtigercrm/ kopiert. Rechte anpassen (2.Zeile)

# rsync -avrt /root/vtiger.540/UPDATE.650_700/ /var/www/vtigercrm/
# cd /var/www; chown -R www-data:www-data vtigercrm/

Da im Migrationsleitfaden höhere Speicherlimits und Skriptlaufzeiten angegeben sind, habe ich dies in der /var/www/vtigercrm/config.inc.php angepasst:

ini_set('memory_limit','512M');		// in der Zeile 20 steht vorher 64MB
ini_set('max_execution_time', 600);

Sofort nach Eingabe auf der Seite migrate, kommt der Anmeldebildschirm von vtiger (6.5?), allerdings dauert es ca 30 Sekunden, bis im Hintergrund etwas abgelaufen ist und die Anmeldedaten eingegeben werden können, vermutlich wird da inzwischen das zip-Archiv ausgepackt.
Jetzt ist Geduld in Grossbuchstaben angesagt. Auf meinem X201 (i5-560, 4GB RAM, 128 GB SSD) musste ich 45 Minuten warten! Allerdings kann man an der sich immer wieder veränderten CPU-Auslastung sehen, dass ich noch was tut und der mysqld nicht einfach nur hohl dreht....
Nach drücken auf <weiter> begrüsst mich die PHP-Fehlermeldung:

Fatal error: Call to undefined method Settings_ExtensionStore_Extension_Model::getNews() in /var/www/vtigercrm/modules/Users/views/Login.php on line 39

Die habe ich ignoriert und sofort den Patch von 7.0 auf 7.1 eingespielt.

Vtiger upgrade 7.0 auf 7.1

Archiv auspacken ec wie immer, diesmal ist es wieder nur ein Ordner migrate und eine 8MB grosse Datei vtiger7.zip

# rsync -avrt /root/vtiger.540/UPDATE.700_710/ /var/www/vtigercrm/
# cd /var/www; chown -R www-data:www-data vtigercrm/

allerdings kommt da im Browser dieselbe Fehlermeldung, das "migrate" packt in den neueren vtiger Versionen das Archiv wohl nicht mehr aus. Dann bin ich kurzentschlossen mit dem vi auf die PHP-Datei losgegangen:

# vi /var/www/vtigercrm/modules/Users/views/Login.php

Zeile 39 kommentierte ich aus und setzte die Variable $news auf ein leeres Array:

              // $news = $modelInstance->getNews();
		 $news = array();

daraufhin konnte ich die Migration auf 7.1 vornehmen, musste mich wegen invalid credentials aber 2x in der Migrationsoberfläche neu anmelden. Erst beim zweiten Migration starten bekam ich endlich den Balken für die laufene Migration zu sehen. Diese dauerte wieder. Daten sichern!

# mysqldump -uvtiger -pDBPASSWD vtiger > /root/vtiger.710.sql
# /etc/init.d/mysql stop
# rsync --numeric-ids --progress --exclude /proc --exclude /sys --exclude /dev --exclude /home --exclude /tmp --exclude /run -avrtHAX / root@spica:/home/go/enif.vach.710/
# /etc/init.d/mysql start

möglicherweise kann man diesem Problem entkommen, indem man statt dem Update von 6.5.0 auf 7.0.0 einen im Internet ebenfalls verfügbaren von 6.5.0 auf 7.0.1 verwendet, in den Diskussionsforen zu vtiger bei discussions.vtiger.com gilt die 7.0.0 als extrem buggy und wird nur zum Testeinsatz empfohlen!
Nun testete ich einiges, z.B. das Anlegen neuer Organisationen und Dateiupload, welches bei Usern im Forum Ärger verursachte, bei mir aber problemlos lief!

Vtiger upgrade 7.1 auf 7.2

Archiv auspacken ec wie immer, diesmal ist es wieder nur ein Ordner migrate und eine 4MB grosse Datei vtiger7.zip. Diese wieder mit unzip nach /root/vtiger.540/UPDATE.710_720/ entpacken

# rsync -avrt /root/vtiger.540/UPDATE.710_720/ /var/www/vtigercrm/
# cd /var/www; chown -R www-data:www-data vtigercrm/

Im Browser http://192.168.40.42/vtigercrm/migrate/ aufrufen, dann

vi /var/www/vtigercrm/includes/runtime/Controller.php:  	:129 auskommentieren => // throw new AppException(vtranslate('LBL_PERMISSION_DENIED'));

Dann wurde es harzig, ich musste eine Tabelle in MYSQL anlegen:

# mysql -uvtiger -pDBPASSWD vtiger
> CREATE table vtiger_modtracker_basic_seq (`id` int(11) NOT NULL);

vi /etc/mysql/mysql.conf.d/vtiger.cnf

[mysqld]
sql_mode               = NO_ENGINE_SUBSTITUTION
default-storage-engine = InnoDB
collation-server       = utf8mb4_general_ci
character-set-server   = utf8mb4
innodb_file_per_table  = ON
innodb_flush_method    = O_DIRECT

Im Browser dann <reload> drücken.

Achtung: wenn man /var/www/vtigercrm/ von einem anderen Datenstand überspielt (da ist 5.4 - 7.1 kompatibel, bei 7.2 weiss ich es nicht), muss man die zur Datenbank passende Storage holen, sonst fehlen die Dokumente!

rsync --numeric-ids -avrtHAX --delete root@spica:/home/go/enif.vach.710/var/www/vtigercrm/storage/ /var/www/vtigercrm/storage/