We have tried to configure an agent which can communicate with 2 different instances and run the jobs on respective instances using feature –
How many WA MANAGER Will the agent communicate with?
So I choose 2 and given the 2 different instance details upon asking and it was configured correctly as we are able to run the jobs on both instance from same agent.
However, my question is:
Which scheduler are you using? Although it is not critical to know it will allow us to use the correct terminology.
Scheduler version – R11.3.0 INC 3
Agent version – R11.4
However, my questions:
Q1: Port 8507 is picked up automatically and is not configured or active on TEST INSTANCE, so how can the agent trigger the job on TEST when the port 8507 port is not open?
A1: The System Agent is listening on port 7520 and the scheduler on port 8507
When the scheduler triggers a job on the System Agent, it sends an AFM to the System Agent on port 7520
Then the System Agent sends the job status to the scheduler on port 8507
Q2: Can an agent communicate with both the instances with port 7520 simultaneously?
A2: Yes there is a single receiving port on the System Agent and all your schedulers are going to send AFMs to this port to trigger jobs. If for any reason, you prefer to have separate receiving ports on the System Agent for instances TEST and DEV, you can install another System Agent on the same machine listening to another port (for example 7530)
Q3: I was under assumption that for agent to communicate with server/scheduler, both should have same crypt key.Here in my case, ABC agent is already having one crypt key from DEV, so it means that DEV scheduler and ABC agent has right crypt key in place, but I didn’t copy the crypt key from TEST scheduler to ABC agent install directory, then
how and why the communication with ABC agent to TEST SCHEDULER worked?
A3: There is a single cryptkey.txt file on the System Agent and no way to have different keys for 2 two different instances.
It works because you are either using the Default AES encryption key or the SAME encryption key in the machine definition of this System Agent on these both instances
Q4: Can an Agent install directory holds 2 crypt keys related to 2 different instance? If yes, then how the security between agent and scheduler be maintained?
A4: No, this is not possible , see A3
Thanks Jean for your update.
Can you please help me on the following:
Q1: What is the bit version of AUTOSYS AGENTS version R11.3.x and R11.4? Is it 32bit and 64bit? Or either 32bit or 64bit?
A1: Bit version of R11.3.x can be either 32 or 64bit. Run cybAgent -v to get its bit version
Bit version of R11.4 is 64bit
Q2: Default Cryptkey.txt for Server of different versions (R11.3.0 SP1 and R11.3.6 SP7) is same or not?
A2: Default cryptkey.txt file of different Autosys versions R11.3 to 11.3.6 SP7 is the same
Q3: Default Cryptkey.txt for Agent of different versions (R11.3.x and R11.4) is same or different?
A3: It is different but as you know the default cryptkey.txt file sitting on the System Agent must be the same as the default Autosys cryptkey.txt file located in the $AUTOUSER directory in Autosys
Q4: When we do the agent upgrade from R11.3.x to R11.4, will the agent upgrade process also upgrade / insert / override the old cryptkey.txt of older version (R11.3.x) to R11.4 version?
A4: No, during the System Agent upgrade process the old cryptkey.txt file is preserved ( it does not change )
What does preserved means here? answer to q3 and q4 looks confusing to me,
By preserved, I meant that the original file is kept during the upgrade. It is not modified by the installer.
About answers to Q3: I ran two new installations (11.3 SP7 and 11.4) with the default encryption key and compare them with a Linux 'diff' command. There are different.
So where that file is kept? When I did the agent upgrade, I just found only 1 cryptkey file with the latest timestamp and date.
As you said that it is preserved, so can I reuse that file to copy amongst server and agents or restore the original one after upgrade.
When I tested an upgrade in place on Windows, the cryptkey.txt file had not been replaced and it was still present in the installation directory of the System Agent.
Furthermore, when I checked the installation log, the keygen utility had not been executed because I selected following options when I ran setup.exe to upgrade my System Agent from 11.3 SP7 to 11.4
- upgrade existing agent
- Selected the installation directory of the System Agent which needed to be upgraded
When the installation was done, the cryptkey.txt file had same time stamp as before the upgrade.
But this below rule always applies:
When using the default Autosys AES encryption key, the cryptkey.txt file which is in the system agent installation directory must be the same as the one coming from Autosys and located in the $AUTOUSER directory on Linux/Unix or in same directory structure on Windows.
If the old System Agent was already using this default cryptkey.txt file, you can copy it to your new installation ( System Agent 11.3 or 11.4 versions)