This year's upgrade process will be in 6 parts.

1. Setup the read-only mode copy of Milwaukee's Voyager (outage early in the morning)
2. Patch Oracle to 10.0.2.4 and apply CPU
3. Upgrade Voyager to 7.2.0
4. Apply Voyager Service Pack to get to 7.2.1
5. Do all split server configuration work
6. Milwaukee library tests and customizes as needed, then switch back production (short outage).

Read Only Mode (completed 5:00am)
- Comment out cron jobs (completed)
- Take down production (completed 3:20am)
- Configure UPG zones on widener (completed 4:45am)
- Copy zones from production to UPG zones on widener (completed 4:45am)
- Copy backups to UPG zones (completed 4:45am)
- Bring up UPG zones as production (completed 4:45am)
- Verify all is well (completed 4:45am)
- Set Voyager read-only mode (completed 4:45am)
- set Oracle tablespace to read-only (completed 4:45am)
- Modify production zones to use UPG ip addresses and check firewall rules (completed)
- Oracle listener configuration (completed)
-- /oracle/app/oracle/product/10.2.0/db_1/network/admin/listener.ora backup and change (completed)
- /etc/inet/hosts files in each zone (completed)
- Make a backup copy of production web zone /m1/voyager/xxxdb to be referred to for customizations later (completed 5:30am)

bw - 5:32am - read-only copy is up and running, production zones are running as the upgrade IPs and are setup. Taking a break here for a couple of hours - picking up with Oracle update afterwards. Might have to allocate some extra disk space.

Patch Oracle to 10.0.2.4 and apply CPU (in progress - completed 11:30am)
- Copy oracle patch files to /m1/incoming/oracle (completed 9:40am)
- Uncompress (completed 9:45am)
- Pre-installation steps (completed)
- Install 10.2.0.4 update (completed 10:45am)
- Run upgrade script and recompile script (completed 11:30am)
- Install Oracle CPU (not doing at this time)

Install Voyager 7.2.0 upgrade (completed 8pm)
bw - 11:30am - Oracle update completed, eating something and starting on Voyager upgrade. Doing the full regen after the 7.2.0 upgrade and 7.2.1 service pack are installed.

- Copy the voyager upgrade files to /m1/incoming/v720 (completed 12:45pm)
- Run 7.2.0 upgrade (in progress)
- Prep - (completed)
- install new jdk from SHARED tarball in both web and db zones (completed)
- verify /m1/voyager/xxxdb/ini/voyager.env has JAVA_HOME set correctly (completed)
- move /m1/shared/apache2 to /m1/shared/httpd/2.2.6 and make a symlink from /m1/shared/httpd/2.2.6 to /m1/shared/apache2
- change /m1/voyager/xxxdb mountpoint so it's not a mountpoint for the upgrade.pl run (completed)
- Files upgrade.pl (completed 2:20pm)
- Verify /m1/voyager/xxxdb/tomcat/vxws/conf/server.xml entries -
-- <Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="128.104.22.*"/> (completed)
-- url="jdbc:oracle:thin:@HOSTNAME:PORT:VGER" (completed)
- RE-verify /m1/voyager/xxxdb/ini/voyager.env has JAVA_HOME set correctly (completed)
- Oracle schema update (completed 4pm)
-- Error - same renorm.exe Segmentation fault (coredump) as last year on the elink_index step. Waiting to hear back a definitive answer from Exlibris.
-- From Exlibris - "I think our conclusion in your case is to just ignore the issue and move on. Voyager has been running fine with the table as is for the last year, so failing to run convert on it successfully won't cause any new problems." Sounds good to me, certainly better than truncating the table and hoping the regen won't get the same segmentation fault.
- Post setup steps
-- UB (completed)
-- Media scheduler (completed)
-- Authorities Keyword stuff (completed - have to make sure it's tested - if broken do next step)
-- Run through full Authority Headings piece, including ctxsys recreation and running ./create_single_index.ksh $USERPASS (run if needed after testing)
-- recreate readonly user (completed)
- Service re-setup - make sure the /m1/voyager/xxxdb directories are only the valid ones or the voyager service setup will do funny things with the extras

Install Voyager 7.2.1 service pack (completed)
- Install service pack on DB server (completed 8:30pm)
- shut down zones and change /m1/voyager/xxxdb mountpoint so it is a mountpoint again and rsync the new xxxdb directory over to it (completed)

Run regen -
- export elink_index table in case the regen truncates it (completed)
- download 721 utility tarball (completed)
- untar (completed)
- vi REGEN.indexes (completed)
- run full regen (completed - started at 10:02pm - completed running at 3:37am, 5 1/2 hours runtime)

Post Service pack server splits (completed Wed - 9:20pm)
- Split web server - don't use maketomcatwebserver.ksh method (completed)
-- verify upgraded java jdk to 1.6 version (completed)
-- cleaned up older bin/lib/utility/sbin directories (completed)
-- built tarball with - (completed)
--- sudo tar cvf webserver.tar milwaukeedb/etc milwaukeedb/webvoyage milwaukeedb/ini milwaukeedb/tomcat/vwebv rescatdb/etc rescatdb/webvoyage rescatdb/ini rescatdb/tomcat/vwebv lib/2007.2.1 bin/2007.2.1/*exe bin/2007.2.1/*cgi (completed)
-- sudo vi *db/etc/webvoyage/voyager.ini (completed)
-- under xxxdb/tomcat/vwebv find the WEB-INF/web.xml and verify XServiceHost is pointing to the right place (completed)
-- start things up (completed)
-- milwaukeedb tomcat looks 'good' at https://millibupg.wisconsin.edu/ Can't test rescat OPAC at this point before switchover to production.

- Split z3950 server (completed 9:20pm)
-- with prod switch over, will need to modify for prod IPs and stop/start voyager on z3950
--- Build with their tar command - leave out voyager and oracle libraries - scp them over afterwards
--- as voyager ; cd /m1/voyager/lib/2007.2.1 (already done with first instance setup - Stout)
--- scp user@xxxdbupg.wisconsin.edu:/oracle/app/oracle/product/10.2.0/db_1/lib32/libnnz10.so .
--- scp user@xxxdbupg.wisconsin.edu:/oracle/app/oracle/product/10.2.0/db_1/lib32/libclntsh.so.10.1
--- scp user@xxxdbupg.wisconsin.edu:/oracle/app/oracle/product/10.2.0/db_1/lib32/libclntsh.so.9.0 .
--- modify /m1/voyager/stoutdb/etc/ascopac/opac.ini from localhost to xxxdbupg
--- /m1/voyager/stoutdb/ini/z3950svr.ini from localhost to xxxdbupg

- Split staff client server (not for Milwaukee, at least this year)
-- build zone/create users/groups/home directories, etc.

bw - completed upgrade - 9:20pm on Wednesday. webvoyage customizations at millibupg.wisconsin.edu - staff client test at milvoydbupg.wisconsin.edu. Please test authority headings searches (and e-links of course). Let me know if any problems.

Customize upgraded Webvoyage and test staff clients
- Use the millibupg.wisconsin.edu address for customizations
- Copy of pre-upgrade milwaukeedb and rescatdb directories should be /m1/v710-milwaukeed and /m1/v710-rescat
- Point upgraded staff client at milvoydbupg.wisconsin.edu address for testing upgraded
- Fix newbooks

Switch over
- Take down read-only production zones
- Reboot upgraded zones to come back up as production
-- take down read-only production zones (outage starts here)
-- for upgraded zones -
-- zone configuration files back into place
-- /etc/inet/hosts in each zone back to production values
-- /oracle/app/oracle/product/10.2.0/db_1/network/admin/listener.ora backup into place
-- apache configuration changes if anything has an IP address hard coded
-- shut down zones
-- boot zones (should come up as production)
-- uncomment cron jobs for voyager and nightly backups
-- update nightly backup scripts as needed
-- on z3950 update z3950svr.ini and xxxdb/etc/ascopac/opac.ini and stop/start voyager (z3950.wisconsin.edu brief downtime at this point)
- Do any cleanup needed


(completed 4:45am)