2015-09-29
A Case Study in How NOT To Process Orders
Home » Other »Notes on NetBackup Client Installs
2015-09-29
A Case Study in How NOT To Process Orders
2014-02-08
Reading email SMTP headers to trace the origin of the message.
2014-02-07
Rants about the pains of performing what should be a simple package upgrade.
Your IP address is
3.238.253.163
NetBackup Client upgrades have been the thorn chainsaw in my side for the last nine months.
The Windows NetBackup client installer is something of an abombination. It's an MSI file (so far, so good), which must be run using a setup.exe wrapper (whaaat?), and to install it silently, it must be called from the Symantec-provided silentpatch.cmd or silentclient.cmd batch files (no, really!!). Oh, and here's the real fun: their MSI file does not have a CAB file embedded in it, the data1.cab file exists outside of the MSI or setup wrapper.
So - why can't we just ignore the batch file, and copy the CAB, MSI and setup.exe program, and just run whatever command the batch file would have done? Well, we could, but that wouldn't be the supported method of perfoming a silent upgrade.
This makes it something of a pain to deploy. Many automation solutions will happily take an MSI file and know what to do with it. Or at the very least, they will take an EXE file and pass whichever parameters are needed to it. Something like this requires you to zip up all the files, which alters the kind of package it is, and introduces several limitations in terms of automation. I can tell our automation solution to pass certain parameters to an executable file, or to msiexec.exe, but I can't tell it to pass parameters to a non-executable zip file. For a start, ZIP files don't accept command line switches/parameters.
You can perform a "push" installation from the NetBackup master server. Well, you might be able to. This will only work on Windows if your NetBackup master server is also running Windows, and guess what? Mine are Solaris or Linux. Alternatively, Symantec recommend you deploy a LiveUpdate server to manage your NetBackup client updates. There is no way I'm getting approval to deploy > 50 LiveUpdate servers around the globe before I've updated a single client.
Another issue is that for Windows Server 2003, NetBackup Client 7.1 will install a driver called WimFltr.sys, with version 6.0.6001.18000 - suggesting it was intended for Windows Vista/Server 2008. Not a massive issue in and of itself, but the digital signature on the file expired in December 2008. This means that you cannot perform a silent, unattended installation of NetBackup 7.1 on Windows Server 2003. You will always get a dialog box appear at the console, warning you that the authenticode signature on the file is expired. Symantec claim that the "error can be safely ignored. The Certificate expiration will not impact functionality of the driver itself", but this is nonsense, as silent installations will hang, waiting for somebody to come along and click a button to continue.
That same article also says that "Symantec is in the process of working with Microsoft to either obtain an updated WimFltr.sys driver file with an updated Digital Signature Certificate, or obtain an alternate valid driver file to replace 'WimFltr.sys'", but that page hasn't been updated since it was written in 2011. It's 2014 now (at the time of writing). What's the hold-up? We're paying for an Enterprise product, and a working silent installation is absolutely vital if you're going to deploy it across an Enterprise.
Installing the client on Linux (we're all Red Hat-based distros, here), looks like it should be fairly simple. Unlike Windows, we don't have any external TAR files, setup wrappers or shell scripts that need to be used. We just have our RPM.
So far, so good.
But what happens when we come to install this RPM? Well, it all appears to complete OK, but when we check the installation, we find that no actual files have been installed, and (on version 6.5), all your xinetd daemons for NetBackup have been disabled. It also seems to have a nasty habit of removing some required lines from the /etc/services file.
Given this level of fail with RPM, I'm not sure I'd trust a Symantec MSI file for Windows, even if they did provide one.
On Linux, you can run rpm -i --freshen=SYMnbuclnt.rpm, which will usually put the missing files back in /usr/openv/netbackup, but you're still going to have to mess around with your services file and your xinetd configuration to get things working.
Installing NetBackup client for Windows is going to cause an outage for MS SQL (including Express) and Exchange services. Even if you're not actually using the SQL or Exchange agents, they'll still be installed, and they'll still get their filthy little hooks into the processes.
On Linux, you have similar worries with Oracle databases. In fact, you must stop your Oracle databases/listeners, and once the upgrade is completed (assuming all the files are there), you have to create a hard-link from your Oracle instance's lib directory, to a file in your NetBackup install.
Similar issues afflict Lotus Domino, DB2 and Sybase.
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.0 UK: England & Wales License.
Design by GetTemplate