Ctrlm 6.3 Agentless
Ctrlm 6.3 Agentless
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
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
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......
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......
- philmalmaison
- Nouveau
- Posts: 1148
- Joined: 08 Jun 2007 12:00
- Location: Ile de France
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 ?
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 ?
- philmalmaison
- Nouveau
- Posts: 1148
- Joined: 08 Jun 2007 12:00
- Location: Ile de France
- Henk Trumpie
- Nouveau
- Posts: 22
- Joined: 27 Jul 2007 12:00
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.
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.
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.