1 2 Previous Next 15 Replies Latest reply on Jan 30, 2013 11:56 AM by Bill Robinson

    NSH Script Behaviour

    Mike Jones

      Can anyone explain why an NSH script job executed against two BSA application servers will pass on one and fail on the other in a seemingly random fashion with no access to host.

       

      I can see from the rscd logs that on the server it fails on it is comming through as SYSTEM and therefore does not have access. "(SYSTEM): nsh: Failed to map user" and on the other server it comes through as the user and role running the job.

       

      I can also fix the error by either:

           1. Adding an entry for SYSTEM into the user.local

           2. Configuring the application servers to use an NSH proxy

       

      What I do not understand is what makes the script run as SYSTEM rather than the user and role executing the job

       

      Thank You

        • 1. Re: NSH Script Behaviour

          It seems like the user using which you are trying to execute the job is not having the necessary permission to run it which the system user has the permission to do..and also check if proper ACL have been pushed with the user which is failing to execute the job..

          • 2. Re: NSH Script Behaviour
            Mike Jones

            The user does have the permissions because one time it will work on one application server and the next time not.

             

            The time that it fails the rscd log shows it comming through as SYSTEM rather than the user

             

            Thanks

            • 3. Re: NSH Script Behaviour

              Hi Mike,

                       Can you check if any string is there like nouser in your user.local file..??

               

              have you gone though the initial checklist..I mean application to target connectivity..agent status etc..??

               

               

              Regards,

              Avisekh Das

              • 4. Re: NSH Script Behaviour
                Mike Jones

                Avishekh

                 

                yes all done, and yes there is nouser entry in the users.local

                 

                The issue is and the question is what causes the job to come through as SYSTEM one time and as the user:role another.

                • 5. Re: NSH Script Behaviour
                  R V

                  Hi Mike,

                   

                  to get things a bit more clear I assume your environment is like the following:

                  - you have two application servers running BBSA (version? arch?) both connected to the same database and fileserver?

                  - you have ONE target host running the rscd-agent

                  - you have ONE nsh-script job once running on appserver1 and once running appserver2

                  - running on appserver1 (e.g.) always succeeds

                  - running on appserver2 it sometimes succeeds and sometimes fails

                   

                  Am I right? If not, please describe your configuration exactly.

                   

                  Regards,

                  Reinhard

                  • 6. Re: NSH Script Behaviour
                    Mike Jones

                    Reinhard,

                     

                    - There are two application servers running BBSA (8.2 SP3 on Windows) both connected to the same database and file server

                    - The application servers themselves are the targets as it is a script to dsync the extended_objects from the fileserver to a local directory

                    - Sometimes it will works on app1 and fail on app2, and sometime the other way round. It always fails on one

                    - On the server that fails the entry in the rscd.log show it is comming through as SYSTEM rather than the role/user

                     

                    Thanks

                    • 7. Re: NSH Script Behaviour
                      R V

                      I see - interesting scenario

                       

                      Is any of the two applicatioin servers also the fileserver? That's the only thing I associate with a System-account. And if so, is System:System included in the users.local-file of the FileServer-AppServer (see:https://docs.bmc.com/docs/display/public/bsa82/File+server+requirements)? A you mentioned that such an entry would fix the problem, maybe we could proceed with this.

                       

                      Regards

                      • 8. Re: NSH Script Behaviour
                        Mike Jones

                        No the file server is separate

                         

                        The SYSTEM entry that I mentioned to fix this is on both of the application servers.

                         

                        So I have added (exact case required) - SYSTEM     rw,map=localadminaccount

                        to both of the application servers and the job always completes sucessfully.

                         

                        What I am trying to understand is why I need to do that

                         

                        Thanks

                        • 9. Re: NSH Script Behaviour
                          R V

                          Just in case - please post the output of:

                           

                          # blasadmin -a show fileserver name

                          and

                          # blasadmin -a show fileserver location

                           

                          from both appservers.

                          • 10. Re: NSH Script Behaviour
                            Mike Jones

                            Both are

                             

                            location:/e/Data/storage

                            name:bsafileservername.fulldns.com

                            • 11. Re: NSH Script Behaviour
                              R V

                              Another idea:

                               

                              The job runs normally on one of the two jobservers running on the corresponding appserver (or do you have more than one jobserver configured per appserver?). Is there any "rule" that the job succeeds or fails according to the possible jobserver/target-combinations?

                              • 12. Re: NSH Script Behaviour
                                Bill Robinson

                                can you paste in the line from the rscd.log on the failed server that shows the failed job?

                                 

                                also - you are using UPM, not AP for the user mapping ?

                                • 13. Re: NSH Script Behaviour
                                  Mike Jones

                                  Back from a long Christmas break so I can add a bit more information now

                                   

                                  I have had a look at this a bit more and I forgot that we have added the following JVM arg to the application servers:  -Duser.name=SYSTEM

                                   

                                  I think that we need to do this for the application servers to use the certificates correctly when we change all the managed servers to encryption_and_auth. Is this still the case ?

                                   

                                  So it looks like when an application server talks to a remote server with the JVM arg it comes through as SYSTEM but when it is running against itself it will use the role/account that is running the job.

                                   

                                  This is the entry you see in the rscd log

                                   

                                  WARN     rscd -  IPADDRESS 2884 SYSTEM (SYSTEM): nsh: Failed to map user to local user

                                  • 14. Re: NSH Script Behaviour
                                    Mike Jones

                                    I think I have answered my own question.

                                     

                                    There was one job server without the -Duser.name=SYSTEM JVM arg configured and if the job ran on that job server it would map through as the user running the job othersie it would map through as SYSTEM and fail (unless I add a SYSTEM entry to users.local)

                                     

                                    Maybe I should start a new post but ...

                                     

                                    1. The JVM arg -Duser.name=SYSTEM is required if you use certificate authentication - or is there another way ?

                                    2. If you configure 1. it seems that NSH jobs run as SYSTEM rather than the user/role the job is executing as - is there a way round this apart from configuring the application servers to use an NSH proxy ?

                                    1 2 Previous Next