Netbackup 6.5 Client on RHEL 2.6 Linux x86_64 w/ Windows Master Server

[brandonn]

I have a machine that is currenty running RHEL 2.6 x86_64 that needs the Netbackup 6.5 loaded and patched to 6.5.4

I have been running into problem after problem trying to perform this. I have the Linux clients CD and have copied over the files. Once extracted i have what looks like:

 # ls
# [NBClients]    install 

When I run the ./install script, it asks for master server name, then what i want the client to be called, and then abruptly failes with a message:

"Your current working directory must be the client/<hardware>/<os> directory" 

This leads me to beleive it's expecting that I am trying to push this install from a master server when I am infact just trying to move the install files locally, and install from there. I am not a Linux guy, so assume I've missed an obvious thinking.

EDIT: If I have a working install on another RHEL, can I just copy /usr/openv/* to the other server, and update xinetd manually? (and obviously reconfigure bp.conf) Or am I naive for thinking it'd be that simple?

[RiaanBadenhorst]

Does it pick up your O/S version correctly in the beginning of the install? You can check the install.trace file located in /tmp

[Nicolai]

Try starting the installer with full path

e.g.:

/tmp/nbu-client/install

If you start the installer while in /tmp/nbu-client you may recive the message you are refering to.

[brandonn]

It does pick the version correctly, it lists it very clearly. Good advice though. Any other ideas?

[brandonn]

Have tried both ways, error reports in the same exact spot both methods. Thanks though!

[RiaanBadenhorst]

Not at the moment, sorry. I could swear i got this at a client the other day but can't remember what I did. I did the install on my VMs quickly and I got no error. Was hoping I'd get it again.

I'm sure you can copy the files over and edit the relevant start files, inetd, and bp.conf.

There is no rpm installation on RHEL that I could see. I found this note, so logic dictates if these are the steps to uninstall, if you do them in reverse, you'll install :)

http://www.symantec.com/docs/TECH71923

[CRZ]

Any install logs in /tmp which could shed some more light?

You could add "-x" to the first line to enable some extra debugging and see if you can figure out where exactly it's breaking out:

#!/bin/sh -x

Of course, you may find that the script is calling some OTHER script on which you will need to perform the same edit. It's a bit of a rabbit hole, but you CAN get out of it. :)

A digression which may or may not apply to you:  In the past when I've dealt with cases where strange errors have shown up during install, it's almost always ended up with a corrupt unpacking.  Somebody's unpacked in Windows and then FTP'd over to Linux, dropping extra carriage returns into every line and mucking things up, or they used a funky unzipper/untar which didn't quite drop the distribution as we would have intended, &c.  I'd usually request output from ls -lR from the root of the distribution and check the file sizes against our master to make sure they matched up - if you have a known good CD somewhere, you could compare it to that.

Hope this helps - or at least leads to another question we can answer to get you closer!

[brandonn]

Thanks Chris, I am in the process of redownloading the package from fileconnect just to be overly confident I've got a clean package. I will let you know how it goes.