Big news! The community will be moving to a new platform April 21. Read more.
Big news! The community will be moving to a new platform April 21. Read more.
Micro Focus Contributor
Micro Focus Contributor
713 views

Node duplicated due to OA restarts

Jump to solution

Hello all

I have OMi with node (Windows/Unix) already defined: let's call these <existent_nodes> .
My new task is to switching OA primary manager from OMU to OMi: let's call these <migrated_nodes> .

Every <existent_nodes> has a PrimaryDnsName attribute set to FQDN , probably due to an old uCMDB push.
Every <migrated_nodes> , after primary manager swithing and after OPCMSGA(*) restart, create every time a new CI node with PrimaryDnsName with shortname (not FQDN) .

Due to this PrimaryDnsName mismatch, every node swithched as primary to OMi is duplicated, and if I try to fix this solution, this situation is replicated on every opcmsga restart.
(*)Probably this is due to the discovery data which OA sends to OMi on every opcmsga restart.

Which OA discovered data attribute is used by OMi to populate PrimaryDnsName ?
Is there any way to force the PrimaryDnsName sent from OA on every discovery ?
For example, customize 'Sys_SystemDiscovery' policy ?

Regards,
Francesco

Labels (4)
0 Likes
1 Solution

Accepted Solutions
Micro Focus Expert
Micro Focus Expert

Hello Francesco,

The agent uses the node name that your name resolution returns.

For example on Linux, you could check like this:

# getent hosts `hostname`

 

Ideally, that should return the FQDN first (plus potentially short node name and aliases).

If it returns the short node name first, then there is the reason for your issues.

There are two ways to fix that on the managed node:

1. Fix name resolution

That's easy said, but not so easy done, as you don't know if the other applications on the system will work well with the FQDN instead of short node name (usually they should, but who knows ...).

For example, if /etc/hosts is used, reversing the order will do the trick, e.g. from:

1.2.3.4 myname  myname.domain.com

To:

1.2.3.4 myname.domain.com myname

 

2. If changing the name service is not an option, you can convince the agent to use the name you want it to use:

ovc -kill
ovconfchg -ns xpl.net -set LOCAL_NODE_NAME myname.domain.com
ovconfchg -ns eaagt -clear OPC_NODENAME
ovc -start

 

Best regards,
Tobias

View solution in original post

7 Replies
Micro Focus Expert
Micro Focus Expert

Hello Francesco,

The agent uses the node name that your name resolution returns.

For example on Linux, you could check like this:

# getent hosts `hostname`

 

Ideally, that should return the FQDN first (plus potentially short node name and aliases).

If it returns the short node name first, then there is the reason for your issues.

There are two ways to fix that on the managed node:

1. Fix name resolution

That's easy said, but not so easy done, as you don't know if the other applications on the system will work well with the FQDN instead of short node name (usually they should, but who knows ...).

For example, if /etc/hosts is used, reversing the order will do the trick, e.g. from:

1.2.3.4 myname  myname.domain.com

To:

1.2.3.4 myname.domain.com myname

 

2. If changing the name service is not an option, you can convince the agent to use the name you want it to use:

ovc -kill
ovconfchg -ns xpl.net -set LOCAL_NODE_NAME myname.domain.com
ovconfchg -ns eaagt -clear OPC_NODENAME
ovc -start

 

Best regards,
Tobias

View solution in original post

Micro Focus Contributor
Micro Focus Contributor
Thank you Tobias

I'll try both approach.

A question:

in the second case (name service not fixed), OPC_NODENAME is not a "read-only" setting? 

Regards,

Farncesco
0 Likes
Micro Focus Expert
Micro Focus Expert

Hello Francesco,

OPC_NODENAME is overwritten by the agent, that's why that can't be used directly to define the used node name.

Clearing the value of OPC_NODENAME just makes sure that LOCAL_NODE_NAME is actually used. I've seen cases where agent didn't overwrite OPC_NODENAME when it was already set and thus old value was continued to be used.

Best regards,
Tobias

 

Fleet Admiral Fleet Admiral
Fleet Admiral

we got also a lot of trouble with this.

There is defect that setting  LOCAL_NODE_NAME in older Agent version doesnt work properly. I think it is fixed in 12.05 or 12.06 and newer.

Just in case it doesnt work, check agent version and open case with MF support to get a Hotfix if upgrade isnt possible.

Didnt know about clearing OPC_NODENAME is possible. But may be this fixes this issue in affected versions.

Micro Focus Contributor
Micro Focus Contributor

In fact, I tried , as second attempt, to work on xpl.net LOCAL_NODE_NAME, but it doesn't work.

Probably due to the issue you reported on 'oldest' agent versions.

0 Likes
Micro Focus Contributor
Micro Focus Contributor

Tobias

in my environment , only your first solution solved my issue (working with hostname resolution locally to OA).

 

In fact, I tried , as second attempt, to work on xpl.net LOCAL_NODE_NAME, but it doesn't work ,probably due to issues 'oldest' agent versions.

Thank you.

Francsco

0 Likes
Micro Focus Expert
Micro Focus Expert

Hello Francesco,

Good that the first way worked.

I don't know when LOCAL_NODE_NAME was introduced. But that indeed may not work with older agent versions.

Best regards,
Tobias

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.