Can 1 Automic Agent communicates with Prd & Non Prd Automic Engine?

[Sunish Mittal]

Hi,

we have the requirement or a scenario where in we need to have 1 automic agent communicate & trigger jobs on both Automic (Prd & Non Prd). Can you please suggest how to handle this requirement?

[Carsten Schmitz]

Hi.

The answer is: Not at all.

The best you can do is start one set of agent​ binaries twice, once with an .ini file that connects to "prod" and once with a different .ini file that connects to "test". You will have two agent instances on the same machine that way, off of one agent binary on disk.

But you can not connect the same instance of one agent with the same .ini file to two environments. They need to talk to one control panel, and that is a monolithic/singular entry in the .ini file. Furthermore, there might also be licensing implications to consider.

Hth,

[Carsten Schmitz]

Dear Sunish,

Please kindly refrain from taking community threads to private messages, as this is a discussion that others may want to parttake in as well.

To answer your question, you can duplicate the agent directory whole, once for prod and once for dev/test, but the most minimal setup is to use one agent directory and only have two separate ini files.

The command you sent to me is how you start the service manager. I do not recommend two separate service managers, I recommmend one service manager per machine. So starting separate service managers for prod and test/dev is not my advise.

In that one service manager, you'll have a .smd file (smd = service manager definitions, presumably). In that .smd file, there's the command that starts the agent. Something like this:

DEFINE UNIX-Agent;/opt/agents/unix/bin/ucxjlx6 /opt/agents/unix/bin/ucxjlx6.ini;/opt/agents/unix/bin/

The first is the binary being started, the second (argument number 1 to that binary) is the .ini file being used, and the third is the working directory.

You can start the same agent instance with different .ini files like so:

DEFINE UNIX-Agent;/opt/agents/unix/bin/ucxjlx6 /opt/agents/unix/bin/ucxjlx6_number_one.ini;/opt/agents/unix/bin/
​DEFINE UNIX-Agent2;/opt/agents/unix/bin/ucxjlx6 /opt/agents/unix/bin/ucxjlx6_number_two.ini;/opt/agents/unix/bin/

Then have one ini file connect to the one engine, the second to the other (via cp=).

Hth

[Pete Wirfs]

We usually run two service managers when we want two AE's to have agents on the same server.  We give the service managers different phrases to uniquely identify which AE they are supposed to support.  And we usually clone the agent bin so the two agents can be upgraded independent of one-another.  We did this recently so we could run V11 and V12 in parallel for a shakedown period.


------------------------------
Pete
------------------------------

[Carsten Schmitz]

​I concur that running two independent agent directories is preferable, because of the ability for independent updates as you pointed out (and also, not absolutely neccessitated but often going along, the prevention of log file overwriting/confusion fubars because of, then, separated tmp/ and out/ directories). OP was initially asking for the most lightweight setup, but splitting agents has undeniable benefits over the most slim setup.

I'm not convinced on the value of two smgr yet. Yes, it can easily be done, but I guess you'd need two tcp ports, with firewall implications etc, multiple init scripts, more monitoring etc., and not 100% sure if smgr-dialog can connect to anything but tcp/8871?

We here treat smgr as the single instance starter for all Automic processes on one machine. What we do here (historically, not my original idea) is use the Phrase UC4P for prod, UC4T for test and UC4X (or just UC4) for "multi environment systems".

But yeah, I've seen varying setups that work, and that's also the result of Automic always leaving customers without a proper reference setup imho. But from the design of the smgr, I always gravitate towards one smgr, multiple agents myself.

n.b. Ultimately, I always considered smgr to be the eqvialent to Daniel J. Bernsteins daemon-tools: born mostly from "not invented here" syndrome with the init system :)

Br,

[Keld Mollnitz]

We use the same approach as @Pete Wirfs and we have one Service Manager per OS agent​​. Each Servie Manager uses its unique port, 8871, 8872, 8873 etc. Up to 10 port numbers are supported and the Service Manage port range can be specified with the SMGR_PORT_RANGE within UC_SYSTEM_SETTINGS.

[Brian Hudgins]

Hi,
When our clients require this type of cross DEV/PROD agent connectivity, we always remind them of the possibility of it being a security breach between DEV and PROD. If they insist, we always recommend 2 agent folders filled with their perspective SYSTEM specific configurations and log files, as pointed out below, there are multiple benefits of keeping them separated. 

The SMGR can be used for both as long as you label them clearly and entrust only qualified users access to the SMGRGui, as once they have access to the DEV, the user can simply change over to the PROD and bring it down.

I sometimes point out that keeping them separated makes my OCD happy, and as you all know OCD is a pre-requisite to Automation Administration.

KR, BKHudgins

------------------------------
Founder and Partner
Data Center Automation Consultants DCAC
------------------------------

[Carsten Schmitz]

​I sometimes point out that keeping them separated makes my OCD happy

I usually ask them if they've seen Monk freak out on TV and if they think they can handle this times a hundred, but yeah, same concept ... :)

[Pete Wirfs]

@Brian Hudgins

Brian said: "...SMGRGui, as once they have access to the DEV, the user can simply change over to the PROD and bring it down."​

This exposure is why I DISCOURAGE everyone from installing the ServiceManagerDialog onto their personal devices.  Instead, we only install it on the AE servers themselves where access is more restricted.   If someone were to accidentally do something wrong with it, we would at least have a history of when they logged onto the AE server as circumstantial evidence.  Yes, this is an OCD thing with me too... I would have made a good network security person i suppose.

------------------------------
Pete
------------------------------

[Carsten Schmitz]

​Brian said: "...SMGRGui, as once they have access to the DEV, the user can simply change over to the PROD and bring it down."​

Legitimate concern. And not the only one: I remember the day during 10.x when I accidentially discovered anyone could crash the Windows agent by telnetting to it from Windows telnet.exe and pressing "enter". And people wonder why I question Automics "roll your own crypto" until they provide independent audits ...

Besides, anyone can find smgr dialog on the web for download. If you truly want to secure Automic from this particular scenario, you need to firewall the ports down as strict as possible.