Video Screencast Help

Which SSI socket is being used by which ACSLS robot?

Created: 11 Oct 2012 • Updated: 17 Oct 2012 | 11 comments
This issue has been solved. See solution.

Hil Folks,

 

I am currently developing a script which is supposed to set columes to scratch within the ACSLS once the medias are being deassigned. (I need this because we are working with a virtual tape library in our backend)

I have basically worked out how to do this. I start with using the media_deassign_notify skript. From this I get following info:

MEDIA_ID
BARCODE
ROBOT_NUMBER
ROBOT_TYPE

From here I can find almost everything I need to start acstest:

/usr/openv/volmgr/bin/acstest -rn 11 -r test-lsyvlp0.esc.fra.dlh.de -s 13741

Except for the SSI number. Now I know that the default for this is 13741 but we have some environments that have multiple ACSLS robots connected to it. We have not set anything in vm.conf (and I really don't feel like chaning this on our production system) Robtest is able to get the correct number for each robot, but I have no clue how that is being done.

So anybody knows how I can reliably find the correct SSI number?

Thanks for the help

 

Christoph

Comments 11 CommentsJump to latest comment

Nicolai's picture

Do you need to specifi the ssi number at all ?. If you don't specify one Netbackup seems to find one itself.

I can't test it on Netbackup system with multiple ACSLS host. I only have one ACSLS server

# acstest -r moldau -C qserver

 

SSI socket not specified... trying default (13741)
Server 0 with 2491 free cells is in state "STATE_RUN"
 
QUERY SERVER complete
 
Server 0 with 2491 free cells is in state "STATE_RUN"
 
QUERY SERVER complete
 

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

Christoph Maier's picture

No, this only works if you want to talk to the first robot (as this will ususally use 13741) When you try to contact the other acsls hosts you will need to specify the SSI number or else you will always end up on the first robot. (Even though you set the specs for the other robot)

Nicolai's picture

According to this TN you can specify what IP and port(s) ACS_SSI listen on in VM.conf. This way you should know exactly what SSI ports are used for acstes command.

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

Additional info:

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

 

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

Christoph Maier's picture

I know, but we haven't set anything there and I really don't feel like changing the configuration on all of our master servers. Just getting the ok to restart some of the masters would take me two weeks at least. (Not to mention the risk of actually something not working afterwards) There must be a way to get the number, after all robtest does get it, too.

Nicolai's picture

I don't think you have a option (sorry).

Why not test the SSI settings on a test server and then roll out the changes when you know how the sheetings work (I would do the same) ?

Alternative use the ROBOT_NUMBER to determine which ACSLS server to use and ssh using public keys (password less login).

Best Regards

Nicolai

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

Christoph Maier's picture

SSH wont do me any good since the firewall wont let me through and those guys will not let me ssh out of the DMZ no matter what (So it would not work on half my master servers). And even if I test it in our environment I'll still have to do a formal change on all systems which will take me at least two months all in all. Since this will get me into our christmas frozen zone I would have to delay it even further since no large changes are allowed. (And anything chaning on our main backup environments is considered a large change since it will affect a large number of customers)

I just don't understand why there is no way to do it since it must be set somehow, else robtest would fail also. If I would at least know for sure in which order the robots are assigned, then I could do simple math or add a secondary config file on each master that simply stores which robot has what connection. But this only works if I know for sure the order wont be changed each time NetBackup is started. (And of course I don't have a test system with multiple ACSLS hosts connected to test that theory)

Nicolai's picture

There properly isn't because acstest is a test/diagnostic command and never designed for automated production. 

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.

Christoph Maier's picture

So anybody has an idea? I mean it does work for robtest so there must be a way. I am already thinking about exploiting the fact that robtest can do it, overall it would be a very crude method however :(

Christoph Maier's picture

I did some testing in my environment and figured that the order in which the SSI numbers are chosen either coincides with the ACS robot numbers or with the range that the robots are displayed with the command

/usr/openv/volmgr/bin/vmoprcmd -devconfig

(Both currently return the same result, so I am not sure) The order in which the robots are entered in the vm.conf does not appear to matter. (Which surprised me, I thought that would be the deciding factor) Can anybody confirm or test this in an environment with multiple acsls' connected? I only have three different configurations over here and one of those has only one acsls configured and only one has three configured. (Luckily on that one I realized that the vm.conf was not the deciding factor) Some more data would be highly appreciated.

Christoph Maier's picture

Okay, sorry for keeping to update my own thread, but since I just found what looks like the solution I figured I share it with you folks. (I knew there must be a way!)

I found this by a pure coincidence because a colleague of mine ran nbsu and I saw that there was a file created:

/usr/openv/volmgr/misc/ltitables
once I looked in there I found this at the very end of it:

   AcsSsiHostList:
        [0] hostname = test-xxx.xx.de
        [0] sockname = 13741
        [0] ssipid = 34329

And sure enough the sockname is indeed the current SSI connector for the robot :) Now if you don't want to run all of nbsu there is a shortcut for this:

/usr/openv/volmgr/bin/ltid -tables

This will create the file on it's own. It doesn't take too long to execute either. (Less than 2 seconds) And since it's a part of nbsu I would deem it safe to use. (At least on our main production system it cause no issues at all during normal operations)

SOLUTION
Nicolai's picture

Power of nbsu smiley

Thanks for sharing the solution to the issue !!

Assumption is the mother of all mess ups.

If this post answered your'e qustion -  Please mark as a soloution.