opcnode -chg_id cocpeca1.somecompany.lan id=xxx <ovcoreid>

The node label cocpeca1 must already exist, check first by using:

opcnode -list_nodes node_list=cocpeca1.somecompany.lan

It is also better to disable the node first by using:

opcnode -chg_nodetype node_list=cocpeca1.somecompany.lan node_type=DISABLED

After granting (opccsa), it can be re-enabled by:

opcnode -chg_nodetype node_list=cocpeca1.somecompany.lan node_type=CONTROLLED

(Here is related post on forcing OVCoreID)

Under complete deinstallation, the following directories are removed by

• rm -Rf /etc/OV/
• rm -Rf /var/opt/OV/

Hence, installing again in that managed node will give new OVCoreID. After activation, certificate request (ovcert -certreq) will appear in management server. A mismatch then occurs (due to similar host name [?]) from previous registration.

In management server we must delete previous information. At least the previously added node:

opcnode -del_node node_name=tikanga3.internal.mycompany.lan net_type=NETWORK_IP

There is a way to force previously-registered OVCoreID from the management server:

1. Copy the core ID from the managed node (check ovcoreid)
2. On management server: opccsacm -issue -file [some file to save to] -pass [password] -name [fqdn hostname] -coreid [coreid of node]
3. FTP above file to managed node
4. On managed node:

• ovconfchg -ns sec.cm.client -set CERTIFICATE_DEPLOYMENT_TYPE MANUAL
• ovc -stop
• ovcert -importcert -file [FTP'd file]
• ovc -start

Actually the pointers is written in Arsena – OVO Admin Guide v1.0a, but it wasn’t emphasized visually as being significant (so I missed it). There are three common install situation:

• Clean. OVCoreID and node mapping is triggered by agent (usually fresh install)
• Messy. Node mapping is not exist
• More Messy. OVCoreID mismatch (usually there was previous ID from previous deinstallation)

How to find which trouble I’m into?

opccsa -list_pending_cr

The problem is: it’d take some time for the pending-list to appear in the management server. I did restart (ovc -restart) the server, but it only helped a little (inconsistent). The server may have too much load at that time as the pending-list is appearing completely in the following day:

 Hostname  |                         Request ID  |                  Mapped Host  |
-------------------------------------------------------------------------------------------------------
localhost.localdomain  d936333e-f6a4-7537-0376-8e055989b35e
localhost.localdomain  e8087476-f686-7537-16ba-c77d2fc599e3
rhel-arif.internal.mycompany.lan  6e73e0a6-f57c-7537-1622-b0d28f73264c
tikanga3.internal.mycompany.lan  <strong>bc0a2506-f8d2-7537-1416-e692e27b7af0</strong>  tikanga3.internal.mycompany.lan
tikanga3.internal.mycompany.lan  d1f8b5b2-d14a-7537-0325-c7ed4464fe55

In Messy situation. We need to map the node through command line or Motif GUI.

Once, I do it through GUI:.

In the 2nd attempt I mix: adding node in GUI: Actions > Add Node and then map using command line:

opccsa -map_node bc0a2506-f8d2-7537-1416-e692e27b7af0=tikanga3

Those numbers are request ID listed in list_pending_cr. tikanga3 is the name of the node that we’ve added.

To add node through command line (instead of GUI) do:

opcnode -add_node node_name=tikanga3.internal.mycompany.lan node_label=tikanga3 net_type=NETWORK_IP mach_type=MACH_BBC_LX26RPM_X86 comm_type=COMM_BBC group_name=Linux layout_group=MenaraDuta

If layout_group isn’t included by default the added node will be in layout group HoldingArea.