Best Practices: Upgrading to PGP Universal Server 3.2

Article:TECH171436  |  Created: 2011-10-10  |  Updated: 2013-04-29  |  Article URL http://www.symantec.com/docs/TECH171436
Article Type
Technical Solution


Subject

Issue



The objective of this article is to provide a series of validations (via a checklist) to be performed before performing an upgrade of the PGP Universal Server. Running these validations prior to upgrading should minimize issues with the upgrade process.

 
Note that this is not an exhaustive list, since client deployments vary widely, but does include general best practices.

 


Solution



PRE-UPGRADE STRATEGY
 
It is recommended that a test environment be set up so you can the upgrade process prior to upgrading a production server.
 
The test environment should focus on the validating the following areas:
 
1.                  Validate the network configuration.
2.                  Validate the effect of the migration on production backup data.
3.                  Validate the schema of the upgraded test server and generate repair scripts
4.                  Test new features.
 
The rest of this document provides specific steps needed to perform the above validations.
 
PRE-REQUISITES
 
This document assumes that:
 
1.                  Web access to the PGP Universal Server (administrative console) is functioning correctly.
2.                  SSH access to the PGP Universal Server has been set up.
 
NOTE: Some checklist points in this document require access to the administrative console while others require SSH access to the PGP Universal Server.  Therefore this checklist has been divided into two sections: one containing all points pertaining to the administrative console and the other containing points that would be executed on the PGP Universal Server via SSH.
 
SECTION 1: ADMINISTRATIVE CONSOLE CHECKLIST
 
NETWORK CONFIGURATION
 
In the administrative console, select System > Network
 
1.                 Interface – Physical Adapter:
It’s recommended that Interface 1 have eth0 as Physical Adapter value.
Most configurations, tested and deployed, have this configuration and any variation from this, results in potential risk.
 
2.                 Link Speed:
Ensure that every network interface is configured correctly.
 
The link speed is usually set to “Auto”. If it’s set to a configuration with suffix “Half” please make sure that there is a good reason to do so.
 
Incorrect settings might lead to the “Duplex Mismatch” problem
 
 
3.                  DNS Servers:
 
Every Ethernet interface must have at-least one fully qualified DNS server.
Both forward and reverse lookups (DNS A record and PTR record respectively) for the current PGP Universal Server must be correctly configured in the DNS server.
 
 
MISCELLANEOUS
 
1.              ORG-KEY BACKUP:
In the administrative console, select Keys > Organization Keys > Organization Key > Export > Export Keypair
 
Before you upgrade your PGP Universal Server, be sure back up the Organization key pair. Make sure that both the public and the private key portions of the Org key pair have been backed up (as opposed to exporting only the public key part).
 
2.              BROWSER SUPPORT:
Before the initiating the upgrade process, make sure that the browser used to access the administrative console is supported. There have been cases when unsupported browsers caused login problems after the upgrade was completed.
 
Refer to the PGP Universal Server documentation for the list of supported browsers.
 
3.              LDAP DIRECTORY:
In the administrative console, select Consumers > Directory Synchronization
 
When using LDAP (or Active directory), it is important to ensure these directories can be contacted by ALL PGP Universal Servers that are to be upgraded.
 
To verify communications, navigate to select Consumers > Directory Synchronization. Under the Name column, select the first directory and click the link. To test the settings, click Test Connection.
 
In case of error, the message “LDAP Test failed” is displayed.
Please verify your settings in this case.
 
Continuing with the test, click View Sample Records. A pop-up browser window will display the first five results obtained using the configured LDAP settings.
 
If the message “No records found” is displayed (the LDAP directory does contain valid records) then the LDAP settings need to be verified.
 
 
SECTION 2: SSH CHECKLIST
 
Network Configuration:
 
1.                  IP Address, Subnet Mask, Gateway:
 
Ensure that the assigned IP address, gateway and subnet mask are correctly configured. For the PGP Universal Server to operate correctly, it is imperative that the gateway be reachable from the server.
 
Run the following commands to ensure that default gateway is reachable.
 
[root@UN-SERVER ~]# /sbin/route
 
The Gateway column value associated with the row having value “Default” in the Destination column is the default Gateway.
 
[root@UN-SERVER ~]# /bin/ping –n –c 5 GATEWAY-IP-ADDRESS
 
If the message “Destination Host Unreachable” is displayed, then the default gateway setting needs to be reassessed.
 
 
2.                  DNS Settings:
It’s important to ensure that the DNS resolver is correctly configured for the PGP Universal Server. Executing the command:
 
[root@UN-SERVER ~]# cat /etc/resolv.conf
 
displays the “nameservers” (DNS servers).
 
The DNS resolution in forward and reverse directions can be verified as follows:
 
[root@UN-SERVER ~]# dig @DNS-SERVER UN-SERVER +short
 
displays the IP address of the PGP Universal Server
 
[root@UN-SERVER ~]# dig –x UN-SERVER-IP-ADDRESS +short
 
displays the host-name of the PGP Universal Server by performing a reverse DNS lookup.
 
3.                 Replication Settings:
 
If PGP Universal Servers operate in a cluster, it is important to ensure that clustering/replication is working correctly before attempting an upgrade.
 
The basic test is to ensure reachability of all PGP Universal Servers. This can be done using the pgprepctl topo command
 
For example:
                        Case I:
When clustered PGP Universal Servers can communicate with each other:
 
[root@UN-SERVER-1 ovid]# pgprepctl topo
 
10.172.117.37 -> 10.172.117.36
10.172.117.36 -> 10.172.117.37
Reachability:                     0    1
0 10.172.117.36:444
1 10.172.117.37:444
myUpstream: 10.172.117.36
myDownstream: 10.172.117.36
 
 
Case II:
When clustered PGP Universal Servers cannot communicate with each other:
[root@UN-SERVER-1 ovid]# pgprepctl topo
10.172.117.37 ->
10.172.117.36 ->
Reachability:                     0    1
0 10.172.117.36:444
1 10.172.117.37:444          
 
A further test is to run the pgprepctl info command to check the status of replication.
 
 
 
Miscellaneous:
 
If upgrading a host VMware ESX server, note that the VMware tools installed in the Guest PGP Universal Server would need to be upgraded as well. See TECH200495 for more information.

 





Article URL http://www.symantec.com/docs/TECH171436


Terms of use for this information are found in Legal Notices