It seems that the part you used to create teh component is extended object which is using the WAS6Nodes.sh script, but the script does not exist. Can you check it (open teh extended object and see to which script it refers and whether teh script exists in the specified location)?
Run a “distribute CO” job against that server to distribute the Unix Users object.
It’s missing an EO, not a CO – they need to find the Extended Object: Unix Services. That is not the CO.
Ohp, so it is.
There is a Daemons CO, but that’s not this ☺
Thats right... whenever i try to access Extended Object: Unix Services on the server which has issue i get the WAS6Nodes.sh error. What needs to be done, in this case?
Is it possible to copy that EO:UNIX services from the working server to the server with issue.
Or can a new EO:Unix Services be created, if yes, how? please let me know...
1 of 1 people found this helpful
- Some background - the Extended Object is kind of command which uses the grammar file to parse the results and add it as an object of the server. Your specific extended object executes another sh script WAS6Nodes.sh which probably doesn't exist. The EO is an object in the Config Object Dictionary and it exists on all the servers with the OS of the EO (if the EO is for Linux OS, all you Linux targets will have this EO).
- What needs to be done?
- Open your config Object Dictionary (Configuration > Config Object Dictionary view)
- In the Config Object Dictionary view select Extended Objects to see the list of all your EOs. You can further filter by selecting the OS (if you know it - probably Linux).
- Click on WAS6Nodes.sh and check the command/script field in the right pane (the EO details). This one should have a reference to nsh script. Make sure the required nsh script (WAS6Nodes.sh) will be in that location. See in the attached screenshot.
Thanks Nimrod, that explains reasonably... In the EO-UNIX services i do not find anything like WAS6nodes.sh.
When i run the compliance job on few of the servers i get was6nodes.sh and on few was7nodes.sh... where could that script be?
I looked in the servers workspace and expanded the server objects... servername>live>extended objects>unix services... here on few servers(which are working fine, for which report is being generated) i am able to find few entries.... on the issue servers if i click on unix services after navigating with the same path... i get error "error reading info for service WAS6nodes.sh: no such file or directory"
Can these EO's be found on sever? Is it possible to copy the EO from one server to other?
1 of 1 people found this helpful
The EO is using scriptutil command which copies and executes scripts on remote servers, this means that the script unis_svcs_status is being copied from the script libraray to the remote servers (??TARGET.NAME??) and then executed. The script unis_svcs_status probably needs WAS6nodes.sh and he can't find it on some of the servers. I guess that what you need is to open unis_svcs_status and see whether it needs WAS6nodes.sh and in which location on the target he is looking for it. Then you can copy it from a server which the compliance runs OK to the server on which it fails (copy to the same location).
There is the brute force solution - search on the servers where the compliance runs successfully the WAS6nodes.sh and copy it to the same location on the servers where the compliance fails (you can use the command find / -name WAS6nodes.sh).
Per your question on the was6nodes.sh or was7nodes.sh, it might be due to a property on the specific server which is different if it has WAS 6 or WAS 7 and according to this property the relevant script is executed.
I could not find WAS6nodes.sh, WAS7nodes.sh nor unis_svcs_status on any server
Can you look for it in the app server(s) or in the file server?
Maybe the files ae being copied and once the script execution is completed the files are deleted.
I thougt of another option why the EO fails - maybe the location to which the files are being copied does not allow this (missing permissions), but to verify this we still need to know the location of the script in the target server.