Ctrlm 6.3 Agentless

Mbongs · Post by **Mbongs** » 19 Jul 2007 3:50

Hi

I just configure my remote host to use for ctrlm 63 agentless. It is configured succesfuly and the remote host is available. The problem is when I run the job it gives me this error "SUBMITTED TO ctrlmuat through ctrlmdev, FAILED TO SUBMIT JOB. Message from Agent follows Error: Server closed network connection"

Can anybody help me as to what do I need to check on the remote host or localy.

Thanks
Mbongeni
ControlM Administrator

mauriziog · Post by **mauriziog** » 19 Jul 2007 6:23

I think that can be problems of user rights.

Mbongs · Post by **Mbongs** » 25 Jul 2007 8:48

Furthermore

I'm getting the following info from fmouat, which has been configured as a remote host:

Jul 25 07:19:32 fmouat sshd[11479]: Accepted password for batch from 10.182.227.73 port 60035 ssh2

This shows that the user authentication is happening and that the password is being sent through on this server.

The following is obtained from the cm_bot local agent, I'm not sure if this is an error:

0725 07:25:18:21 AS:SshJob::checkPlatform: could not determine the OS type. Try #1

The NS log on ctrlmdev also produced the following:

0725 07:34:40.86 NS: TCP_COMM::connect: OS_SOCKET_connect Socket Error - 146
0725 07:34:40.86 NS: CTM6220 -> COMM_MNG_cl::connect_s failed to connect to client(ctrlmdev) at port (7036)
0725 07:34:40.86 NS: TCP_COMM::connect: OS_SOCKET_connect Socket Error - 146
0725 07:34:40.86 NS: CTM6220 -> COMM_MNG_cl::connect_s failed to connect to client(ctrlmdev) at port (7036)

Does this mean anything......

mauriziog · Post by **mauriziog** » 25 Jul 2007 2:43

Once the user can logon, than must have rights on the system, your errors seems be for this reason.
Interesting is for example the sysout, is created in the remote machine in the temporary directory, but at the end of the execution if moved to the server agent directory.

gglau · Post by **gglau** » 26 Jul 2007 12:43

I just got a problem with agentless remote host. Support confirmed that the remote host must be Windows 2003 or XP. Subsequently I located a line in EM documentation that vaguely says so. Does that apply to you?

Mbongs · Post by **Mbongs** » 26 Jul 2007 8:31

Hi

I haven't had a look at Window at the moment because my environment is Unix based (Solaris), but if I get time I might have a loof for you.

philmalmaison · Post by **philmalmaison** » 26 Jul 2007 2:32

did you define user/password for submission to the remote control-m server ?

Mbongs · Post by **Mbongs** » 26 Jul 2007 2:35

The reason for our problem is due to the first and second level user authentication methods that we adopted within our Bank.

This authentication works as follows:
- First level users have been created within our Unix environments, being the user that a process need to be run as. These users are referred to as the Application owners. These
application owner passwords expire on a daily basis.
- Second level users are assigned to the first level users or application users. These second level users are the normal user accounts, used for creating user sessions within our
Unix environments.

User management advantages exist with this type of a methodology. Our problem arise where we have implemented the agentless server option, but due to this restriction we are unable to use the functionality, mainly due to the fact that Control-M waits for the second-level authentication, meaning that it needs to log into the remote host before running the command specified within the job definition, as a result the following messages are produced within the /var/adm/messages file in the remote host:

Jul 26 11:26:31 ctrlmuat sshd[4002]: Accepted keyboard-interactive for cmsapps from 10.182.227.73 port 57253 ssh2
Jul 26 11:28:11 ctrlmuat sshd[5599]: Did not receive identification string from 10.182.227.73

We will still face this same problem even if we should use the ssh key authentication within Control-M.

The agentless server option works quite well when second level authentication is removed for the user.

Is there an alternative solution or recommendation that can be made without having to disable our second level authentication rules, that will allow us to still use the agentless option ?

mauriziog · Post by **mauriziog** » 26 Jul 2007 3:32

The controlm isnt a normal user but a system, an application. So for my point of view is logic that use only the application level authentication.

philmalmaison · Post by **philmalmaison** » 26 Jul 2007 3:35

i think so too

Henk Trumpie · Post by **Henk Trumpie** » 27 Jul 2007 3:59

The problem that you are facing can be related to a few things. You need to go and see where the actula prolem sit to solve this issue. I would like to suggest the following option for you. On you Server and Agent from where you do your agentless submitting of the task, please add the user that submits the task to the agent..This will help with your authentication methodology the you have in the bank. This will also most probably resolve your issue.

mauriziog · Post by **mauriziog** » 12 Sep 2007 6:27

Abount the compatible SO:

In unix: you must have SSH
In windows: you must have WMI

I prefer SSH: more flexible the definition of the user and how all works.
In windows works too, but you must set well the user that start the service of the ctmserver-agent and that run the job on the remote machine: is less clear.