cancel
Showing results for 
Search instead for 
Did you mean: 

bpgetconfig/bpsetconfig from Media server

areznik
Level 5

We have a few clients that are missing the correct server list entries for the master server, but connect just fine to one of the media servers. In most cases we know the way to fix this is to add the correct entries for the master's cluster nodes to the bp.conf / registry. However, it seems that even when run from a media server, the bpgetconfig and bpsetconfig commands by default try to connect to the client through the master and end up failing with "server not allowed access."

Here's what i've tried:

bpgetconfig -M <client> from media server fails with 'server not allowed access'

bpgetconfig -s <client> from media server succeeds but only reports back the most basic data. (same with -g)

bpsetconfig -h <client> from media server fails with "server not allowed access" 

nbgetconfig/nbsetconfig - same as above

 

Does anyone know if there's any way to get these commands working from a media server? We're trying to avoid having to get someone to manually log on to each client to add a couple of entries. Shell/vb scripting this wont work too well because of departmental subdivisions and access restrictions.

The bpgetconfig -M would be nice to get working so we can pull back configurations before we change them, but bpsetconfig is the one we really need. 

 

(running NB 7.6.0.4 on RHEL master, 7.6.0.4 Solaris media server)

1 ACCEPTED SOLUTION

Accepted Solutions

sdo
Moderator
Moderator
Partner    VIP    Certified

A bit more devious thinking for Windows clients...

1) On a.n.other Windows client, logon and create a file named:

    C:\temp\bpstart_notify.MY_FIX_FOR_CLIENTX.bat

2) And put in this file something along the lines of the following:

@echo off

setlocal enabledelayedexpansion

set z_path=%~dp0

set z_name=%~n0

set z_file_log=!z_path!!z_name!.log

reg query "HKLM\Software\Veritas\NetBackup\CurrentVersion\Config" /v "Server" >>"!z_file_log!" 2>&1

reg add "HKLM\Software\Veritas\NetBackup\CurrentVersion\Config" /v "Server" /t REG_MULTI_SZ /f /d master\0media1\0media2 >>"!z_file_log!" 2>&1

reg query "HKLM\Software\Veritas\NetBackup\CurrentVersion\Config" /v "Server" >>"!z_file_log!" 2>&1

REM update the BPRES file so that the caller thinks this script succeeded.

echo 0 >>"%~6"

exit /b 0

3) Backup this file to the media server.

4) Perform a redirected restore of this file to the binaries path of the NetBackup Client installation path on the client.  If bpgetconfig, and bptestbpcd cannot be used to identify where NetBackup Client is installed, then you'll have to browse in the restore GUI a full backup of the problem client to locate which drive/folder the NetBackup Client is installed upon - the folder part of the path will likely be standard, but the drive letter might not be C:

5) Create a backup policy named (from above) MY_FIX_FOR_CLIENTX, and select only one file from somewhere to backup, so that the backup is quick and small.

6) Run the backup, which will execute the bpstart_notify script as 'NT_System_Authority' which should update the 'Server' entry in the registry of the client.

7) You should then be able to backup the log file that got created and restore it to the media server to see whether it worked.

8) And the good thing is that because your bpstart_notify script, which is forever left behind on the client, has a goofy name, then the normal backup policy/policies will never cause it to be called again.

.

Again, this is probably a single shot process.

View solution in original post

11 REPLIES 11

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified
Interested to see bpcd log on the client to see why exactly connection request is failing.

Ashok_J
Level 3

Run the below command from the master to update bp.conf on all the clients 

cd /usr/openv/netbackup/bin 

add_media_server_on_clients

areznik
Level 5

I'll see what I can do, but if I had that kind of access to the clients, you wouldnt see this post since i'd probably be sitting here logging in to each to change this stuff :)

 

EDIT:  I was able to reproduce the error on one of my test servers. I'll post what i see in the log but first some background. 

The master is a 2-node cluster, so the clients need to have the Virtual Name and the 2 physcal nodes in their bp.conf to talk to it. 

Server = MasterClusterVIP
Server = MasterClusterNode1
Server = MasterClusterNode2

What's happening in some cases is that the client was not updated for some reason during the last HW refresh and will have old entries for the cluster nodes, but the correct entry for the VIP (that didnt change)

Server = MasterClusterVIP
Server = OLD_MasterClusterNode1
Server = OLD_MasterClusterNode2

What im seeing in the bpcd log on the client is that when I issue a 'bpgetconfig -M <client>' or 'bpsetconfig -h <client>' from anywhere (even a media server) the request that comes in on the client is from MasterClusterNode1 which the client rejects because its not in the list. As expected, 'bpgetconfig -s <client>' is coming from a media server which is on the list and gets through.

There are not a lot of these clients, and for most of them the backups are working because they dont actually have to talk to the master to get backed up. In some cases though we will try something like enabling multistreaming or someone tries to kick off a user initiated backup/restore and that fails. Also seems the newer versions of NB client need to talk to the master to report bpfis status. 

 

 

sdo
Moderator
Moderator
Partner    VIP    Certified

1) On the media server which typically backs-up the problem client(s), create a file on this media server, say:

   /home/myname/myfix/bp.conf

2) Edit this new file, and add the entries that you need on the problem client(s).

3) Backup this file to a storage unit on the media server itself.

4) Perform a re-directed restore to overwrite the bp.conf on the problem client(s).

.

N.B: This is probably a one shot exercise, you need to get it right first time.  If you goof, you'll may loose comms with the client altogether.

cruisen
Level 6
Partner Accredited

Hello Areznik,

You said:" bpgetconfig -M <client> from media server fails with 'server not allowed access'

===> The command specifies the master server (master) whose host configuration appears.

> apparently for the clients the master server entry is missing as you said before, so no configuration can be retrieved as the client has no acces rights to the master.

Please post about the server entries on the master server host properties for fuly understanding your server, and media server configuration.

Best regards,

Cruisen

areznik
Level 5

Hah, I like your style sdo - im going to give that a shot. Not going to work if its Windows though :(

areznik
Level 5

===> The command specifies the master server (master) whose host configuration appears.

This is actually incorrect or misleading in the documentation. This command and switch is the best way to pull back configuration info from any Netbackup server - master, media or client. 

To clarrify further: I'm not trying to run the command from the client to query the master, so the server entries on the master have no bearing on this. 

sdo
Moderator
Moderator
Partner    VIP    Certified

A bit more devious thinking for Windows clients...

1) On a.n.other Windows client, logon and create a file named:

    C:\temp\bpstart_notify.MY_FIX_FOR_CLIENTX.bat

2) And put in this file something along the lines of the following:

@echo off

setlocal enabledelayedexpansion

set z_path=%~dp0

set z_name=%~n0

set z_file_log=!z_path!!z_name!.log

reg query "HKLM\Software\Veritas\NetBackup\CurrentVersion\Config" /v "Server" >>"!z_file_log!" 2>&1

reg add "HKLM\Software\Veritas\NetBackup\CurrentVersion\Config" /v "Server" /t REG_MULTI_SZ /f /d master\0media1\0media2 >>"!z_file_log!" 2>&1

reg query "HKLM\Software\Veritas\NetBackup\CurrentVersion\Config" /v "Server" >>"!z_file_log!" 2>&1

REM update the BPRES file so that the caller thinks this script succeeded.

echo 0 >>"%~6"

exit /b 0

3) Backup this file to the media server.

4) Perform a redirected restore of this file to the binaries path of the NetBackup Client installation path on the client.  If bpgetconfig, and bptestbpcd cannot be used to identify where NetBackup Client is installed, then you'll have to browse in the restore GUI a full backup of the problem client to locate which drive/folder the NetBackup Client is installed upon - the folder part of the path will likely be standard, but the drive letter might not be C:

5) Create a backup policy named (from above) MY_FIX_FOR_CLIENTX, and select only one file from somewhere to backup, so that the backup is quick and small.

6) Run the backup, which will execute the bpstart_notify script as 'NT_System_Authority' which should update the 'Server' entry in the registry of the client.

7) You should then be able to backup the log file that got created and restore it to the media server to see whether it worked.

8) And the good thing is that because your bpstart_notify script, which is forever left behind on the client, has a goofy name, then the normal backup policy/policies will never cause it to be called again.

.

Again, this is probably a single shot process.

sdo
Moderator
Moderator
Partner    VIP    Certified

Also - maybe look at the nbgetconfig and nbsetconfig commands?  Maybe these will work instead of bpgetconfig and bpsetconfig?  This is a guess, apologies if it's a red herring.

{update} apologies just re-read your original post and saw that you tried the 'nb' variants already.

cruisen
Level 6
Partner Accredited

Can someone confirm what Areznik is saying. ===> This is actually incorrect or misleading in the documentation. This command and switch is the best way to pull back configuration info from any Netbackup server - master, media or client. <====

I expect the -M switch to be the one that gives me the bpconf from a masterserver point of view,  and as no master server entries are found on the bpconf of client no configuration can be retrieved. Is this correct??

Please advise.

sdo
Moderator
Moderator
Partner    VIP    Certified

Personally I have always used "bpgetconfig -M clientname" when querying clients.  Never had a problem with it - apart from instances of the same situation that the OP is experiencing.