Software in the Data Protector Architecture Cell Server

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 Omni. Back share. Oracle 8 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 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 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 & Open. VMS 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”), oracle 8, etc. <platform> is of the form <vendor>/<architecture>/<operating system>, such as hp/s 800/hp-ux-11 <version> will be A. 05. 00 or A. 05. 10

Components in the UNIX Installation Server Patch Component Description 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 acs das fxma ndmp 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) DB 2 INFORMIX LOTUS OMNIST ORACLE 8 OV SAP SYBASE db 2 informix lotus omnist oracle 8 ov sap sybase DB 2 database integration Informix database integration Lotus Domino database integration Omni. Storage application integration Oracle 7 database integration Oracle 8, 8 i, 9 i database integration Open. View 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 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/osf 1 -4 dec/alpha/osf 1 -5 gpl/i 386/linux-60 gpl/ia 64/linux-ia 64 hp/s 800/hp-ux-1020 hp/s 800/hp-ux-11 hp/sia 64/hp-ux-1122 ibm/rs 6000/aix-43 ibm/rs 6000/aix-51 sun/sparc/solaris-26 sun/sparc/solaris-7 Tru 64 4. x (& 5. x for DP 5. 0) Tru 64 5. x (DP 5. 1 Linux 32 -bit on x 86 -32 Linux 64 -bit on Itanium HP-UX 10. 20 (DP 5. 0 HP-UX 11. 00 & 11. 11 HP-UX 11. 2 x 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) Others, not further discussed in this document: ncr/i 386/mp-ras sco/i 386/sco_sv sco/i 386/unixware sequent/i 386/dynix sgi/mips/irix-62 siemens/r 400/sinix MP-RAS v 4_3. 0 on x 86 -32 (DP 5. 0 only) SCO Open. Server 5. 0. x on x 86 -32 SCO UNIXWare 7. x on x 86 -32 Dynix 4. 4. 2 on x 86 -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 9150 KB, 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, Tru 64, & Linux: uncompress packet. Z mv packet /usr/omni cd /usr/omni tar ABC packet (ABC would be –xf on AIX; xpf on Tru 64; –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, Tru 64, & Linux. For <cell_server>, it’s the name in /etc/opt/omni/cell_server or /usr/omni/config/cell_server. For <inet_port>, the default and typical value is 5555.