Upgrade from WebGUI 6.2.11 to 7.3.33
apt-get install apache2-mpm-prefork apt-get install libapache2-mod-perl2 apt-get install perlmagick imagemagick
Don't bother with installation of perl modules from packages. Debian has modules which are sometimes a bit too old for cutting-edge WebGUI, so just let CPAN install it for you.
All operations on both hosts (mjesec, zemlja) are done as root user. This is not strictly necessery (especially for WebGUI tasks), but it's easier in combination with MySQL setup. We want to get running quickly, YMMV.
Comment out following in /etc/mysql/my.cnf
log_bin expire_logs_days max_binlog_size
To preserve disk space if you are not using replication!
And restart server:
/etc/init.d/mysql restart rm /var/log/mysql/mysql-bin.*
If this is not first installation attempt, you might want to cleanup target machine first.
# root@mjesec cd /data/WebGUI grep dsn etc/*.conf | cut -d: -f4- \ | xargs -i echo 'drop database {};' \ | ssh zemlja 'cat > /data/drop_all_dbs.sql'
Now switch to target machine and finish cleanup:
# root@zemlja cd /data xargs -i mysql -e '{}' < /data/drop_all_dbs.sql rm -Rf WebGUI
In this step, we will copy existing WebGUI 6.2.11 installation to new (virtual) host (zemlja) to test upgrade.
# root@mjesec cd /data/WebGUI grep dsn etc/*.conf | cut -d: -f4- \ | xargs mysqldump --databases \ | ssh zemlja mysql mysql
# root@mjesec cd /data tar cfp - WebGUI/ | ssh zemlja 'cd /data && tar xvfp -'
This is much faster than scp in my expirience...
Now, on zemlja, let's grant webgui user access to those databases:
# root@zemlja cd /data/WebGUI mysql -e 'create user webgui' grep dsn etc/*.conf | cut -d: -f4- \ | xargs -i mysql -e "grant all privileges on {}.* to webgui@localhost identified by 'password';" mysql -e "flush privileges"
First, test current enviroment for any mis-configuration:
# root@zemlja cd /data/WebGUI/sbin perl testEnvironment.pl
If there are missing perl libraries, install them. Some will have to be forced, but all-in-all it goes well.
And run upgrade...
# root@zemlja cd /data/WebGUI/sbin perl upgrade.pl --doit
Now, extract new version of webgui on which you want to upgrade (I'm assume that you downloaded required versions in /data):
cd /data/ ls tar xvfz webgui-6.6.4-beta.tar.gz cd /data/WebGUI/sbin/ perl testEnvironment.pl perl upgrade.pl --doit
This will take a while.
After that you might want to remove backup of databases:
rm /tmp/backups/*
Here are list of upgrade scripts:
Backup/restore whole WebGUI instance (data+database) so that you can re-try upgrade
This was probably one of most useful ideas enabling me to re-try upgrade until it finish without errors!
Here are some commands to help you with various changes which break WebGUI:
# root@zemlja cd /data/WebGUI rm lib/HTML/Template.pm cd /data/WebGUI/etc/ mv log.conf.original log.conf mv spectre.conf.original spectre.conf
My data has iso-8859-2 while MySQL thinks it's in latin-1.
mysqldump --all-databases --add-drop-database --default-character-set=latin1 > all.sql cat all.sql | sed \ -e 's/DEFAULT CHARSET=latin1/DEFAULT CHARSET=utf8/g' \ -e 's/character set latin1 collate latin1_bin/character set utf8 collate utf8_bin/' \ -e 's/DEFAULT CHARACTER SET latin1/DEFAULT CHARACTER SET utf8/' \ -e 's/SET NAMES latin1/SET NAMES utf8/' \ | iconv -f iso-8859-2 -t utf-8 \ | mysql --default-character-set=utf8 mysql
This should work, but it doesn't
So, we are using much simplier solution which keep encoding in database in wrong latin1 encoding, but it displays correctly in WebGUI:
cat all.sql | iconv -f iso-8859-2 -t utf-8 | mysql mysql
Upgrade procedure isn't still perfect. Here is a list of tweaks to fix configuraion:
cd /data/WebGUI/etc/ perl -p -i -n -e 's/WebGUI::Asset::Wobject::WebGUI::Asset::Wobject::Survey/WebGUI::Asset::Wobject::Survey/g' *.conf
You might want to replace WebGUI/lib/WebGUI which is result of upgrade with clean version from distribution. I have accumulated some cruft there, and it was spitting errors in /var/log/apache2/error.log and /var/log/webgui.log
cd /data/WebGUI sudo chown -R www-data */uploads
I didn't have spectre.conf after upgrade. Test connectivity with:
cd /data/WebGUI/sbin/ perl spectre.pl --test
Add following to /etc/rc.local
cd /data/WebGUI/sbin/ perl spectre.pl --daemon
Since I created few workflows which always returned commerr (because of mis-configuration) I needed to find way to manually erase them.
select tagId from assetVersionTag join WorkflowInstance on WorkflowInstance.instanceId = assetVersionTag.workflowInstanceId ;
delete from WorkflowInstance ;
This will erase all pending workflow instances. So, be sure to check if they are all stuck before running this command!
Make sure your nameserver entries point to existing servers. If you have one of DNS servers which doesn't respord (I had 127.0.0.1 for DNS and there wasn't any DNS server on machine running WebGUI) you will get Errors 500 from spectre without any indication where the problem is.
This part is obsoleted by scripts above which provide correct and workable upgrade path
last 6.6.x version required for upgrade to 6.7.0
Upgrade to this version will die at one point with:
Cannot open config file '../../etc/log.conf' at /usr/share/perl5/Log/Log4perl/Config.pm line 612.
# root@zemlja cd /data/WebGUI/etc/ cp log.conf.original log.conf cp spectre.conf.original spectre.conf
And then, re-run upgrade procedure:
cd /data/WebGUI/sbin/ perl upgrade --doit
Unit it succeeds.
this verison will convert config files to JSON format
First, install old JSON or you will be in pain: http://backpan.perl.org/authors/id/M/MA/MAKAMAKA/JSON-0.991.tar.gz
You might have problems upgrading to version 6.99.0 or later because scripts expect configuration in JSON format, and upgrade won't convert files for you (because it created config files from tar). So, change your upgrade.pl beginning to something like this:
## Find site configs. print "\nTesting site config versions...\n" unless ($quiet); opendir(DIR,"../etc"); my @files = readdir(DIR); closedir(DIR); foreach my $file (@files) { next unless ($file =~ m/\.conf$/); # next if ($file eq "spectre.conf" || $file eq "log.conf"); my $configFile = "../etc/".$file; open(FILE,"<".$configFile); my $line = <FILE>; close(FILE); unless ($line =~ m/JSON 1/) { print "\tConverting ".$file." from PlainConfig to JSON\n" unless ($quiet); convertPlainconfigToJson($configFile); } } exit;
Note commented out line and added exit.
Now you can run upgrade.pl once to convert configuration files to JSON, then run testEnvironment.pl and finally run upgrade.pl once more to do actual update.
requirement for upgrade to 7.4.0
To prevent perl upgrade.pl --doit die with:
Cannot open config file '../etc/log.conf' at /usr/share/perl5/Log/Log4perl/Config.pm line 612.
fix it:
cd /data/WebGUI/etc/ mv log.conf.original log.conf
and then run upgrade!
This are just notes. You can ignore them for normal upgrade described above.
Re-run upgrade procedure if it breaks
Attack of JSON again:
Can't locate object method "relaxed" via package "JSON"
Install http://backpan.perl.org/authors/id/R/RI/RIZEN/Config-JSON-1.1.0.tar.gz
It will install newer JSON and Config::JSON packages from CPAN
For testing, I created *.zemlja.example.com DNS entry, so that all sites become old.site.name.zemlja.example.com.