Software in the Data Protector Architecture
Cell Server
Installation Server
Core
The crs, mmd, and rds processes & the associated
management commands (in /opt/omni/sbin on UNIX).
Includes the internal database & cell configuration information.
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.
Oracle8
Disk Agent
Informix
Media Agent
SAP
The various client components
(functionality) which can be
installed on the clients. CORE
is required on all systems.
Command Console
(User Interface)
Note, the cell server and installation server are only supported on HP-UX, Solaris, and Windows.
Systems in the Data Protector Architecture
Cell
Manager
(with
Installation
Server)
Cell
Client
(with
Installation
Server)
Standalone
Installation
Server
Cell Server
Core
Disk Agent
Installation Server
Command Console
(User Interface)
Media Agent
Core
Disk Agent
Installation Server
Command Console
(User Interface)
Media Agent
Core
Installation Server
required piece
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.
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.
Patching with the UNIX Installation Server
When Upgrading a UNIX client, files are copied from the installation server and installed:
1.
2.
3.
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.05.00 or A.05.10
Components in the UNIX Installation Server
Patch
Component Description
CORE
CORE
CC
CC
DA
omnicf
integ
cc
momgui
da
core component
integration support component, necessary before integrations can function on the client
command console / user interface component
Manager of Managers GUI component
disk agent component
MA
MA
MA
MA
MA
ma
acs
das
fxma
ndmp
media agent component
media agent component with support for STK ACS library management
media agent component with support for ADIC DAS library management
media agent component with support for EMC Fastrax backups
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
INFORMIX
LOTUS
OMNIST
ORACLE
ORACLE8
OV
SAP
SYBASE
db2
informix
lotus
omnist
oracle
oracle8
ov
sap
sybase
DB2 database integration
Informix database integration
Lotus Domino database integration
OmniStorage application integration
Oracle 7 database integration
Oracle 8, 8i, 9i database integration
OpenView Network Node Manager solid database integration
SAP database (Oracle only) integration
Sybase database integration
EMC
EVAA
FASTRAX
SNAPA
SSEA
emc
evaa
fastrax
snapa
ssea
EMC Symmetrix disk array integration integration
HP EVA disk array integration
EMC Fastrax backup solution integration
HP VA disk array integration
HP XP disk array integration
Platforms in the UNIX Installation Server
dec/alpha/osf1-4
dec/alpha/osf1-5
gpl/i386/linux-60
gpl/ia64/linux-ia64
hp/s800/hp-ux-1020
hp/s800/hp-ux-11
hp/sia64/hp-ux-1122
ibm/rs6000/aix-42
ibm/rs6000/aix-43
ibm/rs6000/aix-51
sun/sparc/solaris-26
sun/sparc/solaris-7
Tru64 4.x (& 5.x for DP5.0)
Tru64 5.x
(DP 5.1
Linux 32-bit on x86-32
Linux 64-bit on Itanium
HP-UX 10.20
(DP 5.0
HP-UX 11.00 & 11.11
HP-UX 11.2x
AIX 4.2.x & 4.3.x
(DP 5.0
AIX 4.3.x
(DP 5.1
AIX 5.x
Solaris 2.6 on SPARC
Solaris 7, 8, 9 on SPARC
only)
only)
only)
only)
Others, not further discussed in this document:
ncr/i386/mp-ras
sco/i386/sco_sv
sco/i386/unixware
sequent/i386/dynix
sgi/mips/irix-62
siemens/r400/sinix
MP-RAS v4_3.0 on x86-32 (DP 5.0 only)
SCO OpenServer 5.0.x on x86-32
SCO UNIXWare 7.x on x86-32
Dynix 4.4.2 on x86-32
(DP 5.0 only)
IRIX 6.4 & 6.5 on MIPS
Sinix 5.4.3 & 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.
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.
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:
uncompress packet.Z
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:
uncompress packet.Z
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.