1. Software in the Data Protector Architecture
The crs, mmd, and rds processes & the associated
management commands (in /opt/omni/sbin on UNIX).
Includes the internal database & cell configuration information.
Cell Server
On UNIX, the /opt/omni/databases
directory tree, containing all the
necessary utils.tar & packet.Z files
for managing client components
installation & checking remotely.
On Windows, the depot
directory tree & associated
OmniBack share.
Installation Server
Core
Oracle8
The various client components
(functionality) which can be
installed on the clients. CORE
is required on all systems.
Disk Agent
Informix
Media Agent
SAP
Command Console
(User Interface)
Note, the cell server and installation server are only supported on HP-UX, Solaris, and Windows.

2. Systems in the Data Protector Architecture
Cell
Manager
(with
Installation
Server)
Cell Server
Core
Disk Agent
Installation Server
Command Console
(User Interface)
Media Agent
Cell
Client
(with
Installation
Server)
Core
Disk Agent
Installation Server
Command Console
(User Interface)
Media Agent
Standalone
Installation
Server
required piece
Core
Installation Server
optional piece
Standalone
Command
Console
Core
Command Console
(User Interface)
Any of the optional client components
can be installed on the manager
or a client, just not all shown here.

3. Patching in the Data Protector Architecture
Patches are released only for the cell server and the installation server, not for the client components themselves.
1. CS packet patch – this patch patches the cell server (the red box). On UNIX, Data Protector should be down before swinstall/patchadd this patch. On Windows, simply run this patch after running the latest CORE patch on that system.
2. All other packet patches – all other patches (except the two noted below) patch the installation server (the green box).
3. NOVELL & OpenVMS packet patches – different in that they deliver the patched files to be copied to clients on those operating systems, because those operating systems cannot be maintained via the installation server push process. These patches are under “Windows” because they are self-extracting Windows binaries, which expand into the files to be copied manually to the clients.
Note, no patches directly patch the installed client components, the blue boxes. The blue boxes are updated by Upgrading that client using a patched installation server.
Also note that this concept breaks down on Windows. You cannot Upgrade a Windows client which has the installation server installed. So the installation server patches have to also patch the related client component (blue box) if installed on that system. As a side effect, the patches can be executed on a Windows client which does not have an installation server installed, and the patch will patch the related client component directly.

4. Patching with the UNIX Installation Server
When Upgrading a UNIX client, files are copied from the installation server and installed:
Copy utils.tar to the client and untar to extract the installer utilities
Copy the packet.Z for the component being updated to the client and install it using omni_rinst.sh
Repeat step 2 for each component installed on the client
So the installation server patches do nothing more than put updated packet.Z files on the installation server. They don’t know of or deal with the actual binaries present in bin,sbin,lbin.
The UNIX installation server is nothing more than the /opt/omni/databases directory tree. There are two primary directories below that: utils and vendor. And under vendor is a directory for each client component.
/opt/omni/databases/utils/<platform>/utils.tar
/opt/omni/databases/vendor/<component>/<platform>/<version>/packet.Z
<component> will be something such as da, ma, cc, omnicf (“omni core files”), oracle8, etc.
<platform> is of the form <vendor>/<architecture>/<operating system>, such as hp/s800/hp-ux-11
<version> will be A or A.05.10

5. Components in the UNIX Installation Server
Patch Component Description
CORE omnicf core component
CORE integ integration support component, necessary before integrations can function on the client
CC cc command console / user interface component
CC momgui Manager of Managers GUI component
DA da disk agent component
MA ma media agent component
MA acs media agent component with support for STK ACS library management
MA das media agent component with support for ADIC DAS library management
MA fxma media agent component with support for EMC Fastrax backups
MA ndmp media agent component with support for NAS NDMP backups
(Note, only *1* media agent component can be present on a client at any one time)
DB2 db2 DB2 database integration
INFORMIX informix Informix database integration
LOTUS lotus Lotus Domino database integration
OMNIST omnist OmniStorage application integration
ORACLE oracle Oracle 7 database integration
ORACLE8 oracle8 Oracle 8, 8i, 9i database integration
OV ov OpenView Network Node Manager solid database integration
SAP sap SAP database (Oracle only) integration
SYBASE sybase Sybase database integration
EMC emc EMC Symmetrix disk array integration integration
EVAA evaa HP EVA disk array integration
FASTRAX fastrax EMC Fastrax backup solution integration
SNAPA snapa HP VA disk array integration
SSEA ssea HP XP disk array integration

6. Platforms in the UNIX Installation Server
dec/alpha/osf1-4 Tru64 4.x (& 5.x for DP5.0)
dec/alpha/osf1-5 Tru64 5.x (DP 5.1 only)
gpl/i386/linux-60 Linux 32-bit on x86-32
gpl/ia64/linux-ia64 Linux 64-bit on Itanium
hp/s800/hp-ux HP-UX (DP 5.0 only)
hp/s800/hp-ux-11 HP-UX & 11.11
hp/sia64/hp-ux HP-UX 11.2x
ibm/rs6000/aix-42 AIX 4.2.x & 4.3.x (DP 5.0 only)
ibm/rs6000/aix-43 AIX 4.3.x (DP 5.1 only)
ibm/rs6000/aix-51 AIX 5.x
sun/sparc/solaris-26 Solaris 2.6 on SPARC
sun/sparc/solaris-7 Solaris 7, 8, 9 on SPARC
Others, not further discussed in this document:
ncr/i386/mp-ras MP-RAS v4_3.0 on x86-32 (DP 5.0 only)
sco/i386/sco_sv SCO OpenServer 5.0.x on x86-32
sco/i386/unixware SCO UNIXWare 7.x on x86-32
sequent/i386/dynix Dynix on x (DP 5.0 only)
sgi/mips/irix-62 IRIX 6.4 & 6.5 on MIPS
siemens/r400/sinix Sinix & 5.4.4
The command console component is the user interface, consisting of the GUI and CLI. While many platforms are listed under the CC component, the GUI is only available on HP-UX, Solaris, and Windows. The CC component on all other platforms consists of the CLI only.
Not all platforms will be found under all components, as not all components are supported on all platforms.
Sometimes, a packet.Z will apply to multiple operating system versions. When so, the higher operating system directory will actually be a link to the lower operating system directory. E.g., da/sun/sparc/solaris-7 is actually a link to da/sun/sparc/solaris-26, because the same packet.Z is used for Solaris 2.6 though 9. While this can be seen on an installation server, it cannot be seen in the patches because only the real directories with packet.Z files are present.

7. Patching without a UNIX Installation Server
So what if you do not have a UNIX installation server? Then you must manually apply the client component packet.Z files from the installation server patch to the client(s). For this purpose, download the HP-UX installation server patches. The HP-UX patches are swinstall depots, which are just regular tar files which can be untar’ed to obtain the necessary files. The Solaris patches are pkgadd packages, and cannot be easily expanded on other operating systems to obtain the contained files.
The PHSS_????? files are shar files. You have to “sh PHSS_?????” to extract the PHSS_?????.depot and PHSS_?????.text files. Ignore the word count warnings if not doing the sh on HP-UX. After extracting the .depot and .text files, check the .text file for the size the .depot file should be, and then verify the .depot file is exactly the size it should be. For example, PHSS_29150 says the patch is 9150KB, so the .depot file should be exactly 9150*1024 bytes large.
Then remove the PHSS_????? file and tar –xvf the PHSS_?????.depot file. Now you will have a directory called PHSS_?????, under which will be one or more directories and under each will be the standard /opt/omni/databases/... tree. Simply “find PHSS_????? –name packet.Z” to find all the packet.Z files contained within that patch (or “find PHSS_????? –name utils.tar” if looking for utils.tar in the CORE patch).
Yet another thing to consider is that the files in the .depot tape archive (tar file) might be gzipped. It’s an option when creating SD-UX depot files to have all the files in the depot gzipped. Unfortunately, the gunzipping is not seen when swinstalling the patch. Since we’re not swinstalling the .depot file, we will have to
check manually to see if the utils.tar and packet.Z files are actually tar file / compressed file, or some random thing such as awk text or lex commands, etc.
file packet.Z -> if compressed file, then ok.
file utils.tar -> if tar file, then ok
Otherwise, gunzip the file and then rename it back to its original file name (for example, gunzip packet.Z will change the unzipped file to packet, but we have to rename it back to packet.Z because it’s a compressed file.

8. Manually install packet on HP-UX:
So what to do now that you have the utils.tar and packet.Z files from each of the relevant patches for the relevant platforms? Two options. Manually install the packet.Z (process varies with platform) or install the packet.Z using the omni_rinst script from the utils.tar.
Manually install packet on HP-UX:
uncompress packet.Z
swinstall –s /<wherever>/packet –x reinstall=true –x reinstall_files=true DATA-PROTECTOR
Manually install packet on Solaris:
pkgadd –n –a /<wherever>/admin -d /<wherever>/packet all
(Get the admin file from the utils.tar for solaris-X from the CORE patch)
Manually install packet on AIX, Tru64, & Linux:
mv packet /usr/omni
cd /usr/omni
tar ABC packet
(ABC would be –xf on AIX; xpf on Tru64; –xpf on Linux)
Install packet using omni_rinst.sh (best recommendation, but not the only way as seen above):
omni_rinst.sh packet.Z <component> <version> <platform> <home_dir> <cell_server> <inet_port>
For <component>, the one exception is it would be core for the omnicf packet, not omnicf.
For <version> and <platform>, it’s as in the directory tree of the installation server for the packet.Z.
For <home_dir>, it’s /opt/omni for HP-UX & Solaris, and /usr/omni for AIX, Tru64, & Linux.
For <cell_server>, it’s the name in /etc/opt/omni/cell/cell_server or /usr/omni/config/cell/cell_server.
For <inet_port>, the default and typical value is 5555.