Upgrade notes

Here are some things you need when upgrading to Lab Management 2.3.4.

Prepare the environment before you get the release software.

Install these packages, new in Lab Management 2.3, on the manager node before you upgrade.
- mkisofs rpm -- you can get this from the /public/os/redhat/<version>/i386/Server directory.
- vSphere Remote CLI tool -- you can find this tool at /public/package/cubit/VMware-vSphere-CLI-4.0.0-140463.i386.tar.gz.
  Note: The installation process is interactive, and you need to install the tool into the /usr/local/vmware-vicli directory.
To install VMware-vSphere-CLI, use these commands:
```
# cd /tmp 
# tar zxfVMware-vSphere-CLI-4.0.0-140463.i386.tar.gz 
# cd vmware-vsphere-cli-distrib 
# vmware-install.pl --prefix=/usr/local/vmware-vicli --default
```
(Read and accept EULA.)
For ESX support, several things need to be in place:
- vSphere licenses, one for each ESX physical host, are required. These can be supplied by customers themselves, or purchased through CollabNet Operations.
- You need to manually install each ESX server using the CD image from VMWare (For now, use 4.0U1).
  Note: This is untested, but the 4.1 version has fully automated

Pre-upgrade steps

Before you run the upgrade script, you need to make some changes to the conf files.

Update cubit-runtime.conf -- modify the /etc/cubit/conf/cubit-runtime.conf file to comment out "portmap", "nfs", and "nfslock" entries from the [mgr_services] section so that it looks like following:
```
[mgr_services]
iptables = on 
httpd = on 
named = on 
autofs = off
httpd-toor = on 
dhcpd = on 
tftp = on
memcached = on 
smb = on 
ntpd = on
```

Modify at least the following sections in the site.conf file:

cubit_auth_scheme: If the site uses TeamForge for authentication, change "sfee" to "ctf":
```
cubit_auth_scheme = ctf
```

[sfee] section: Replace this section with the [ctf] section:

[ctf] 
ctf_domain = cu127.cloud.sp.collab.net 
ctf_version = <version of TeamForge server>, eg 5.4 | 6.0.2 | 6.1
ctf_scheme = <http or https> 
readonly_superuser_name = cubitadmin 
readonly_superuser_password = your-password

Add a new section [infrastructure:mgr]:

[infrastructure:mgr]
hostname = %(cubit_mgr_hostname)s 
profile_name = rhel5_base
install_mode = kickstart-net 
cubit_manager = %(cubit_mgr)s
mgr_public_gateway = %(cubit_mgr_gateway)s

Note: If the customer has not purchased a vSphere license, skip this step.

Add a new section: [infrastructure:wds]:

[infrastructure:wds] 
ip_address = 10.1.54.7 <- assign an IP 
parent_hostname = %(cubit_mgr_hostname)s 
hostname = wds.%(cubit_domain)s 
wds_server = True 
profile_name = Windows2k3stdR2_wds
                
memsize = 1024 
memsize_unit = MB 
disksize = 20
disksize_unit = GB 
mac_addr = 00:50:56:01:b2:c3 <- pick an unused MAC

Modify the existing section [primary_ad_server].

Replace this:

[primary_ad_server] 
ip_address = 192.168.204.2
parent_hostname = %(cubit_mgr_hostname)s 
hostname = ad.%(cubit_domain)s

with:

[infrastructure:primary_ad_server] 
ip_address = 192.168.204.2 
parent_hostname = %(cubit_mgr_hostname)s 
hostname = ad.%(cubit_domain)s 
mac_addr = use-its-original-MAC_ADDRESS

If the site is using TeamForge, verify the names of the Lab Management roles in their CUBIT projects. Some very old sites might still have roles called "CUBIT - *"; you must rename them to "Lab Management - *" in each project imported into Lab Management.

Post-upgrade steps

You have two choices when upgrading a customer from a pre-2.3 release to a release having WDS support:

Rebuild the AD server.
- Recreate the domain controller.
- Make sure all Windows nodes rejoin the domain -- go to each node and manually change to workgroup, reboot, change to domain, reboot.
Create a second Windows Infrastructure node to host WDS.
- You'll need another Windows license.
- You'll another virtual guest to host WDS (It takes about 60GB diskspace).
- TBD: new profile for this infrastructure node

Assuming your new WDS server is also hosted on the manager node, do the following:
1. Add the wds.<domain> into the DNS server running on AD.
2. Build the WDS server.
  - $ sudo vmcreate -n wds.<domain> (this step may take 10 minutes or more to complete)
  - $ sudo vmctl start wds.<domain>
3. Copy updated profiles to local Subversion repository.
  - $ cd /tmp
  - $ svn co http://localhost/svn/ai/profiles profiles
  - $ cd profiles
  - $ cp /usr/local/cubit-mgr/installation-support/default-data/ai/profiles/{rhel5*, centos5*, Win*, sles*, sol*} .
  - $ svn ci
4. Check and upgrade existing profiles if necessary.
  - RHEL/CentOS profiles: in LM 2.3, the os_release value in these profiles have to be started with a number, and any letters in it has to be in lower case:
    - 3U8 -> 3u8
    - cent5 -> 5
  - Use the latest rpm versions -- many rpms provided by CollabNet have newer versions available, so profiles still using older rpms should be upgraded. Here are the latest versions:
    - CNvmadm-1.0.0-24.i386.rpm
    - aiupdate-2-9.noarch.rpm
    - systatd-0.98-1.i386.rpm
    - VMware-server-1.0.10-203137.i386.rpm
    - VMwareTools-1.0.10-203137.i386.rpm
    Here are some commands to do this:
    - perl -pi -e "s/VMware-server-1.0.3-44356.i386.rpm/VMware-server-1.0.10-203137.i386.rpm/" *
    - perl -pi -e "s/VMwareTools-1.0.3-44356.i386.rpm/VMwareTools-1.0.10-203137.i386.rpm/" *
    - perl -pi -e "s/systatd-0.97-1.i386.rpm/systatd-0.98-1.i386.rpm/" *
    - perl -pi -e "s/aiupdate-2-{4,5,6,7,8}.noarch.rpm/aiupdate-2-9.noarch.rpm/" *
    - perl -pi -e "s/CNvmadm-1.0.0-2{123}.i386.rpm/CNvmadm-1.0.0-24.i386.rpm/" *