nbdeployutil in 8.1

[Sid1987]

Hi Everyone,

With advent of 8.1, authentication has been focused profoundly. running nbdeployutil requires credentials. Now my master server isn't added to any domain so i used master server name itself, then domain type i used unixpwd but it doesn't allow my userid (with which i logged in) to run the command.

this is the error piece from the log

"Error occurred while getting data from web-service. HTTP Response Code = 401"

does it mean we need a user which has web service?

[Marianne]

As far as I know, NBU 8.1 introduced secure communications, not user authentication. 
NBAC and Enhanced Auditing is IMHO still something separate. See NetBackup Read This First for Secure Communications.

Is this perhaps an Appliance? 
Or 'regular' Linux master that 'expects' all commands to be run as root?

If Appliance, please have a look at this post: https://vox.veritas.com/t5/NetBackup-Appliance/nbdeployutil-in-8-1/m-p/846270#M6725

If 'regular' Linux master, and you are not logged on as root, can you run any other commands in admincmd (e.g. bpimagelist, bppllist, etc) ?

[Sid1987]

this is not an appliance, just a regular linux master. I can run all commands in admincmd with sudo.

I can also successfully authenticate my id for web service in nbat command. However when same id is used for nbdeployutil it gives below error.

"Error occurred while getting data from web-service. HTTP Response Code = 401"

[Sid1987]

It required root user credentials to work. Is this the way it should be? I don't think root user id is required anywhere. sudo templelate works fine, why in this npdeployutil root is required?

[nbritton]

I am seeing the same thing on one master, but not other home builts.   We also use sudo here, and do not have the ability to know the root password.   

[Marianne]

@Sid1987

I do not see anyone coming up with a solution.

Probably best to log a Support call with Veritas?
Please let us know the outcome.

[jnardello · Accepted solution]

So yes, on Server-class gear nbdeployutil requires root authentication to run a gather now. Yay. Nice of them to ask us first, eh ?

Potential workaround - use incremental reporting instead. From what I've seen so far this feature is still acting like a beta version, but it's what we've got.

Setup:

echo '[NBDEPLOYUTIL_INCREMENTAL]' > /usr/openv/var/global/nbdeployutilconfig.txt
echo '# MASTER_SERVERS=<server names>' >> /usr/openv/var/global/nbdeployutilconfig.txt
echo 'FREQUENCY_IN_DAYS=1' >> /usr/openv/var/global/nbdeployutilconfig.txt
echo '# PARENTDIR=<folder name with path>' >> /usr/openv/var/global/nbdeployutilconfig.txt
echo 'PURGE_INTERVAL=365' >> /usr/openv/var/global/nbdeployutilconfig.txt

Yes, you will need the config file. Yes, apparently these lines all seem to be required, Support didn't know why but when some where ommitted it failed to run an incremental gather more than the default of once a week.

These entries will tell NBU to generate an incremental deployment capture daily (which doesn't always happen daily anyway btw, reference ET3942369). With that happening you can then run the following and pull a report as-of that moment:

sudo /usr/openv/netbackup/bin/admincmd/nbdeployutil --report --capacity --incremental --parentdir /usr/openv/var/global/incremental --output="/usr/openv/var/global/reports/"

If it takes too long to generate or is too much of a mess to delete unwanted previous months or such in the xls file, you can always move unwanted reports first into the /usr/openv/var/global/incrementa/archive/ directory and then they won't be taken into account when running the command.

This whole thing is really a mess since we depend on this report to bill our customers every month and it's gone from a completely automated process to completely manual.

In case it's needed, the process is a little easier on an appliance although I wouldn't say cleaner. =)

1. Create a CLI user. No, "admin" will not work.

2. run a gather command like normal, but authenticating as the CLI user.

3. generate the report as-normal.

Enjoy.