Mastering Data Protector Architecture and Patching Process

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.05.00 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-1020 HP-UX 10.20 (DP 5.0 only) hp/s800/hp-ux-11 HP-UX 11.00 & 11.11 hp/sia64/hp-ux-1122 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 4.4.2 on x86-32 (DP 5.0 only) sgi/mips/irix-62 IRIX 6.4 & 6.5 on MIPS siemens/r400/sinix 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.

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. 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.