Is the path you note accessible via nsh/rscd ? what’s in the rscd.log on that server ?
yes, the path is accessible via nsh/rscd..
the target logs does not shows much..will you like a view on that so that I can attach that?
in 7.6 when the analysis runs there is a package and job created and run by the main nsh job, this gets deleted. there should be a bldeploy log in the Transactions/log folder in the agent install location on the target - can you post that?
also - for troubleshooting you can comment out the call to cleanup() in the nsh/patch/linuxpu/Scripts/jython/linux-analysis.py script (around line 1350) and it will leave the job and package behind in the 'scratchpad' workspace folder so we can run it manually.
I have checked with that above you mentioned.
There is no file is being created in the usr/lib/Transactions/log folder in the target server with the current time-stamp once I run the analysis job.
I hope you are asking me to change the content of below file
and the changed content is below
# collect all files generated on targets.
# cleanup all intermediate data
# main entry point
if __name__ == '__main__':
once changed I can see the deploy job has been created even after the analysis has failed and it is being saved under scratchpad folder, but deploy job has been failing with below error
java.lang.Exception: Unexpected NSH return code (2) from command: /opt/nsh/bin/du -s -k //source//BMC/blfileserver/blpackages/17701-source-blp-RHES56x86-2005867.1
so run that command manually ? does that work? is 'source' the actual path to the location of the flie server ?
I have resolved that issue. I am not sure why 'nouser' entry is getting created in user.local file in application server..thus I have hashed that one...so everything is working fine..
I am not sure why 'nouser' entry is getting hashed out again after two days..but I have again changed that part..now everything is working as expected..
Not sure how nouser entry in the user.local could be related to this issue.
Including the nouser entry instructs a server to allow a connection from a user only when that user has been explicitly defined in the users configuration file. When you use an ACL Push Job to push a users file to a server, BMC Server Automation places a
nouserentry in the users file if that server has a property called PUSH_ACL_NO_USERS_FLAG set to true.
looks like environmental issue could be from the network side.
you should have the nouser pushed to the target - it provides security so that only blade users will get mapped to a local account. if that entry is not there then the exports mapping will take effect.
what you probably need to do is make sure that the role:user running the patching job has permission (Server.Browse) on the helper server. probably there is no mapping and w/ the 'nouser' present they are not allowed access.
Thanks for further posting..there is no issue with the target server..no user entry there in the application server ..not sure why..
Also I am not sure what is called helper server..can you please elaborate once please..
Helper server and Repo-server are same
sorry - i meant helper.