Checklist for upgrading production servers to 2.8

Sites to be upgraded on damocles.met.no:

• damocles (owns damocles_metadata and damocles_userbase)
• dokipy
• ipycoord
• gcwdemo

Other sites:

• arcticdata (separate server)

Using gcwdemo as an example in code.

sudo apt-get install metno-perl-webdev-ver1

cd /metno/metamod/metamod28
sudo svn co https://svn.met.no/metamod/trunk
sudo chown -R damocles.damocles trunk/ # needed for building

Use version 8.3, copy to

This should ideally be setup via https://svn.met.no/projects/metamodapps/, but will take too long to figure out. Instead will use existing generated master_config as starting point and backmerge changes to svn later.

Now that Egil is back we have backmerged the changes and is generating the code from his pc.

Must be repeated for each site. Custom styles ignored at this point - must be added later.

To avoid complications with existing instances, put the new sites in /metno/metamod/metamod28/* (the old sites are in /metno/metamod/*). This means webrun will not be corrupted by mixing old and new data.

Use /metno/metamod/SITE/metamod as target instead of /metno/metamod/SITE/r1. Other directories as before.

• upgrade staticdata/searchdata.xml
  • all <sc id=“x” type=“x”…> have change to <sc id=“1” idname=“activity_types” type=“basickey”…> (named ids + named rather than numeric types), see app/example for names and types
  • add dataset_file_location and dataset_file_size (see app/example)

cd /metno/metamod/metamod28/gcwdemo
sudo -u damocles mkdir app
sudo -u damocles cp /metno/metamod/gcwdemo/r1/master_config.txt app/

Compare old master_config to default:

cd ..
trunk/common/scripts/chk_conf.pl trunk/app/example/master_config.txt \
  gcwdemo/master_config.txt 

Upgrade master_config (see trunk/docs/upgrade/metamod_28.pod).

Postponed until Phase 5

Only done once.

Database setup requires scripts generated to target. This means the Generate Target part of Phase 3 for site damocles must be executed first.

The database is not on the damocles server, but on metamoddb.met.no. This contains among others the following databases:

To avoid conflicts and downtime, make two new databases for 2.8 instead:

• userdb data are not duplicated anywhere else
  • must dump 2.6 userdb and import into 2.8, then run upgradeuserdb_26-28.sh
  • see http://www.postgresql.org/docs/8.3/static/backup.html#BACKUP-DUMP

pg_dump -h metamoddb -U admin damocles_userbase > damocles_userbase.sql 
createdb -U admin -h metamoddb -E UTF-8 damocles28_userbase
cat damocles_userbase.sql | psql -h metamoddb -U admin damocles28_userbase
cd /metno/metamod/metamod28/damocles
target/userinit/upgradeuserdb_26-28.sh

[DONE]

• metadatadb must be generated from scratch using createdb.sh
• which xml files should be used to populate the DB?
  • /metno/metamod/damocles/webrun/XML/DAMOC ? (see damocles/master_config)
  • run import_dataset.pl on files
    • anything else to think of? (if so, probably best Heiko did this)

This will setup a generic Metamod 2.8 instance to test the system is running. Customization will be done afterwards, and the installation re-run.

Must be repeated for each site.

cd /metno/metamod/metamod28/gcwdemo
sudo -u damocles PERL5LIB=/opt/metno-perl-webdev-ver1/lib/perl5 ../trunk/update_target.pl app/

Note that Calalyst building tests during update_target will fail unless you have a working, up-to-date database; also, you cannot upgrade your database without running update_target. Chicken, meet egg. Suggest temporary commenting out the following on line 237 (+/-):

#
# install Catalyst files before $appdir to avoid clobbering custom files
#
&install_catalyst;

You will now get the following error message:

Configuring application '' with Metamod 2.8 (2.8.0)
Cannot write to target dir /metno/metamod/metamod28/damocles/target at ../trunk/update_target.pl line 189.

Time to take the weekend off and try again next week.

Create/update the runtime-environment:

sudo -u damocles ./target/prepare_runtime_env.sh

Remember each site must have its own dedicated port:

This server uses DNS-based virtual hosting, however each site already has an existing setup in sites-available. This means the generated httpd.conf in target/etc cannot be used directly; instead you must manually copy & paste the new config into the old file. (Perhaps later when the 2.6 versions are turned off we could use the generated config files directly.)

Do not run install_jobs.sh; instead install links manually.

Todo by someone else (have no idea what is required and how to implement it).

Must be repeated for each site.

— Geir Aalberg 2011/04/29 11:04