I tried to make several scripts. Some were in conjunction used with another, some could be used individually. The problem is, they were made long ago without proper documentation, so I try to relate them first before building new ones to see if they’re still usable (at least in their conceptual work flow).

Script is temporary placed here. They are in bash. For HP-UX usage you’ll most likely change the first line from #!/bin/bash into #!/usr/local/bin/bash.

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)

A non-standard my-client will return e.g. (which are owned by root):

root      2555     1  0 Mar10 ?        00:00:08 /opt/OV/bin/ovcd
root      2569  2555  0 Mar10 ?        00:00:08 /opt/OV/bin/ovbbccb -nodaemon
root      2597  2555  0 Mar10 ?        00:00:07 /opt/OV/lbin/perf/coda
root      2660  2555  0 Mar10 ?        00:00:00 /opt/OV/lbin/conf/ovconfd
root      2823  2555  0 Mar10 ?        00:00:16 /opt/OV/lbin/eaagt/opcmsga
root      2826  2555  0 Mar10 ?        00:00:00 /opt/OV/lbin/eaagt/opcacta
root      2840  2555  0 Mar10 ?        00:00:00 /opt/OV/lbin/eaagt/opcmsgi
root      8083  2660  0 18:17 ?        00:00:00 /bin/sh -c ps -f | grep OV
root      8085  8083  0 18:17 ?        00:00:00 grep OV

Hence, we’ll have to alter the processes ownership as follows:

[@node as root]

/opt/OV/bin/ovdeploy -inv  && ps -ef | grep OV  /opt/OV/bin/ovc -kill && ps -ef | grep OV umask 02 && /opt/OV/bin/ovswitchuser.sh -existinguser opc_op -existinggroup opcgrp \ && chmod 4550 /opt/OV/bin/ovbbccb && /opt/OV/bin/ovconfchg -ns bbc.cb -set CHROOT_PATH / && su - opc_op

The last line ($ su - opc_op) switch user to opc_op, so it’ll continue in this user:

[@node as opc_op]

 /opt/OV/bin/ovc -start && /opt/OV/bin/ovc -status

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.