Installation of 6.5 client on Linux in non-standard paths (eg. not /usr)

[Mathieu1]

Hello all,

I'm looking for a tip or two on a business requirement I have here to integrate Netbackup 6.5 into an infrastructure where the installation location needs to change from the default /usr to one of my choice (eg. /foo/bar/usr).

If that's not possible, then Netbackup will be a no-go for my (very, very large) infrastructure, which has as a mainstay a policy of all third party software being installed on a central NFS mount, and run from that mount in a read-only fashion.  It's a little unique a requirement, but many other products can do it when coaxed, and I have a strong feeling it's possible with Netbackup too.  So here we go:

I started by looking at the contents of the NetBackup_6.5_CLIENTS2.tar.gz.  The first installation script ./install, is a no-go because it has hard-coded paths left and right to /usr.  It also requires being run as root, which I don't want to do just yet.  I proceed to the contents of one of the interest clienting directories, and I'm presented with a mish-mash of shell scripts that do installation tasks.  I'd love to write my own manual install script to fulfill my requirements, but before I can do that I need to understand what existing scripts I need to pay attention to if I'm just doing a local install.  I DON'T want to edit /etc/services, or any of that stuff, either, if you catch my drift.  I want to just untar the relevant binaries, which I can then run, and specify a bp.conf of my own choice, and voila, I'm done.   That directory listing is here, with my specific questions after it.

 35594175 2007-07-24 03:45 client_bin.tar.Z
  45790 2007-07-23 17:30 client_config
   43158 2007-07-23 17:30 cp_to_client
     8246 2007-07-23 17:30 extract_java
  61226 2007-07-23 17:30 fsanalyze
     14 2009-12-11 17:46 ftp_to_client -> install_client
    27760 2007-07-23 17:30 install_client
     20 2009-12-11 17:46 JRE.tar.Z -> ../SuSE2.4/JRE.tar.Z
     2975 2007-07-23 17:30 move_libs
   542 2007-07-23 17:30 nbj.conf
    14 2009-12-11 17:46 sftp_to_client -> install_client
    14 2009-12-11 17:46 ssh_to_client -> install_client
  592394 2007-07-23 17:30 tar
      24 2007-07-23 17:30 version

a) Which files do I need to extract from the tars, and which tars, and if there are necessary installation tasks (note: not configuration, just installation tasks),  like symlinking for example, which script should I be looking at?
b) Is there an easier way to install, and run from, a non-standard root path?  For example, I don't mind if it's /foo/bar/usr/openv/netbackup, I just don't want it to touch my /usr at all.

Thanks in advance

[Nicolai]

one way to do it:

Installing UNIX clients locally

• Install the client on one host - choose custom path
• Copy the path to new host(s)
• On the new host(s) edit bp.conf (the wrong client name is in it) and add the NBU services to /etc/services and xinetd
• do a kill -1 on the xinetd PID so xinetd re-read the config file.

[Mathieu1]

Thanks for the link.

This is a good step forward but I'd still like to be able to make the installation process as automated and customized as possible -- is there a way to run the installer non-interactively by specifying variables to it, or to just untar the relevant tars by hand?

[Mathieu1]

Is there a way for me to untar the files by hand, instead of relying on the installer?   I believe that is the only way I'll be able to accomplish the above.  I just need to know which installation scripts and tars are the relevant ones (see the first message in the thread).

Thanks

[lu]

If you create a bp.conf file before starting the install script, some questions will be skipped: echo "SERVER=serv1 SERVER=media1 CLIENT_NAME=`hostname`" > /usr/openv/netbackup/bp.conf

[Trevor_Jackson1]

Hi Mathieu,

There may be a way to do this, it may not be supported by Symantec though.

On the Master server (if it is also UNIX) there is a directory with all of the files associated with each client version /usr/openv/netbackup/client then a dir underneath each one. I asked a similar question previously, but it would seem that nobody would invite the possibility of changing the scripts supplied by Symantec.

However, I am much braver, as I can see you are, if there is a will, there is a way!! thats what I always say.

The installation script is easy to follow and edit, I believe it uses tar to extract things, and produces a link to the /usr/openv/netbackup/bin folder, which actually turns out to be installed on the /opt/openv/netbackup in the end. so all you need to do is search for this folder reference in the installation scripts. I am also unsure if there are switches that can be used to do this, so I suggest something like the following:

1) search for all scripts associated with the install
2) locate the scripts with reference to the installation directory or /usr/openv/netbackup/bin  or /opt/netbackup/bin
3) edit the script and change to the new location, still enable it to create the link, as I'm unsure of how the bin files are coded. Include params in the script
4) create a script which passes params to the other script and run them. You may be able to use RSH to install the files remotely too.

Good luck with your editing, may I suggest that you take a backup first ;p lol

Trevor

[Trevor_Jackson1]

As a bit of a FYI, here is a non-exhaustive list of things that may not work if you mess around with the installation folder settings:

• All NetBackup Live Update scripts
• Any or All of the upgrades and patches
• `jnbSA` (Java applet for restoring files/folders)

Basically, what I am saying is to talk to your local Symantec technical support and see if what you are proposing is supported. I am sure they will make it work to save losing out on installation of one of the best backup tools on the market.

[Mathieu1]

I just untarred client_bin.tar.Z and an initial glance at the libraries  and binaries suggests hard-coded paths (especially to /usr/openv/). Should I be worried?  Does this blow out of the water the ability to install this software in a non-standard path tree (like /mypath/usr/openv instead of /usr/openv)?

/var/tmp/netbackup/client/6.5.0/NB_65_CLIENTS2_20070723/NBClients/anb/Clients/usr/openv/netbackup/client/Linux/RedHat2.6/tmp/openv/netbackup/bin
-> readelf -d bp | grep RPATH
 0x0000000f (RPATH)                      Library rpath: [/usr/openv/lib]

-> ldd bp
        linux-gate.so.1 =>  (0xffffe000)
        libvxulST.so.1 => not found
        libvxexticuST.so.1 => not found
        libvxlisST.so.1 => not found
        libvxustdioST.so => not found
        libvxicui18nST.so => not found
        libvxicuucST.so => not found
        libvxicudataST.so => not found
        libncurses.so.5 => /usr/lib/libncurses.so.5 (0x008e9000)
        libnsl.so.1 => /lib/libnsl.so.1 (0xf7fdb000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x0066b000)
        libdl.so.2 => /lib/libdl.so.2 (0xf7fd6000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf7f0e000)
        libm.so.6 => /lib/tls/libm.so.6 (0xf7eeb000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7ee1000)
        libc.so.6 => /lib/tls/libc.so.6 (0x00786000)
        /lib/ld-linux.so.2 (0x00651000)

Seems to be true for other binaries too:

-> readelf -d bpbackup | grep -i rpath
 0x0000000f (RPATH)                      Library rpath: [/usr/openv/lib]

[Trevor_Jackson1]

I know that you may be bound to say no, but I thought I would ask.

Can I ask why you want to install the software in a different folder?

There seems to be no purpose I can relate to going through my head. Either way, hard codes are possibly directed from compile time, referring to an argument passed to make install --with-folder ....etc or something.

If you install it in the folder is requires, then make it hidden to everyone apart from root, why would there be a problem?

thanks

Trevor

[Marianne · Accepted solution]

Trevor - my experience is that NBU only installs to /opt on a Solaris Server (master/media).
ALL Unix clients install in /usr.

Mathieu - have you considered creating install dir ( /foo/bar/usr/openv) and then create a symbolic link to /usr/openv before doing the install?

Another option is using the client install files on the master sever under /usr/openv/netbackup/client (e.g /usr/openv/netbackup/client/Linux/RedHat2.4/*) as opposed to the installation media. You can manually copy these files to the client  and then either manually extract the *tar.Z files, update /etc/services and xinted.d manually  or run the client_config script to install the binaries and update the /etc/services and inetd.conf files or the xinetd.d directory, as appropriate.

[Mathieu1]

Trevor,

The problem I'm trying to solve is having one, single install of Netbackup on an NFS share, usable by any hosts that mount that share (with host-specific configuration files residing outside of that location).  Hard-coded compiled-in paths are really the only obstacle against that.  I'm trying to find out whether that's something that can be worked around in this case.

[Marianne]

"one, single install of Netbackup on an NFS share"??  The footprint is so small - why would you want to do that? How do you intend getting vnetd and bpcd added to xinetd? What about /etc/services and bp.conf?
You are IMHO creating unnecessary complications/headaches.....
10/10 for thinking 'out of the box'!

[Mathieu1]

Marianne, Trevor,

Thanks for the responses.  To answer your question, it's not about the footprint saving, it's about having binaries available on a non-local disk for stateless hosting purposes.  If you have thousands of hosts that need to be mostly identical, it doesn't scale well to have to install and maintain 100 software packages on all of them, especially if you want to provision and de-provision hosts on the fly.    I could go into a lot more detail but it's probably out of scope for this discussion - I'm fulfilling business requirements more than anything else.

That said, to your point about extracting manually the *.tar.Z files, I've tried this and I noticed that the .so files are expected to be found under /usr/openv.  For example, look at the RPATH setting for the bpbackup binary I exctracted from the .tar.Z:

-> readelf -d bpbackup | grep -i rpath
 0x0000000f (RPATH)                      Library rpath: [/usr/openv/lib]

This may be a deal-killer for me, as it means no matter what one specifies as the installation path, the binaries have been compiled to look for their supporting libaries in that /usr/openv/lib path.  Thus, my question has become more specific, is there a workaround for this?

[J_H_Is_gone]

cd to /foo/bar
mkdir openv

cd /usr

make a link of openv to /foo/bar/openv

this is mine

lrwxrwxrwx 1 root system 10 Feb 24 2009 /usr/openv -> /opt/openv


now when I cd to /usr/openv I actualy go to /opt/openv

From there you will have other issues of the unique stuff for each client but you are not installing in /usr.

but if you make the link then do the install it will install in /foo/bar/openv.

[Mathieu1]

Almost..

I can't use the symlink as suggested.  That would violate my stateless requirement of the binary+libary portion of this install.  I need the entire thing to be self-contained on a mounted location.

I'm relegated to attempting to use LD_LIBRARY_PATH overrides and other tricks to overcome that hard-coding, unless there are other suggestions.

[Trevor_Jackson1]

There are some good points made by Marrianne here though, why complicate things.

how about a share that contains a script which automatically installs the client upon login. 

Create a mounted drive, with mount point '/usr' 
install the client on the stateless drive
Verify installation with a quick backup/restore

You could automate this in a login and logout script in windows using Novell Zenworks back in the day, so why not get it working in a similar way.

All you need is a snapshot tool, which reviews the files/folders that are changed during installation, capture a script of what is changed. Make the modifications to the relevant files to alter the machine/user specific portion, such as bp.conf.

Of course, I am not sure if such a tool exists for linux, but take a look at this (http://www.epsilonsquared.com/) and see if it will capture the installation.

Hope this helps!

Trevor