net-SNMP packages are required for Raddle to work on top of primarily snmpd.

yum install net-snmp net-snmp-utils

Prior to installation some rpm packages must be downloaded separately as my local repo (created from original RHEL CD images) may not contain them. They are installed as follow:

rpm -i perl-Carp-Clan-6.00-1.el4.rf.noarch.rpm
rpm -i perl-Bit-Vector-6.4-2.el5.rf.i386.rpm
rpm -i perl-Crypt-DES-2.05-3.2.el5.rf.i386.rpm
rpm -i perl-Digest-SHA1-2.11-1.el5.rf.i386.rpm
rpm -i perl-Digest-HMAC-1.01-2.2.el5.rf.noarch.rpm
rpm -i perl-Socket6-0.20-1.el5.rf.i386.rpm
rpm -i perl-Net-SNMP-5.2.0-1.2.el5.rf.noarch.rpm
rpm -i perl-Date-Pcalc-1.2-1.2.el5.rf.noarch.rpm
rpm -i perl-Date-Calc-5.4-1.el5.rf.i386.rpm

continued by installing net-snmp-perl from original repo

yum install net-snmp-perl

Uncompressing Raddle and successful make test will mean installation is good and can be finished by make install

cd Net-Raddle-0.08
perl Makefile.PL
make test
make install

Replaying SNMP Packets

The idea is to run snmpd which replays a specific prepared-SNMP-packets instead of our own real time system SNMP data (in this case the condition of RHEL 5.2 host). There are three files to do that, let’s name them r1.*:

1. r1.snmp
   A capture from i.e.
   snmpwalk -v 1 -c <community string> -OneU <device> > r1.snmp
2. r1.conf
snmpd will run this instead of the original OS default:
   snmpd -C -I vacm_vars -c /usr/local/etc/snmp-emulator/r1.conf
3. r1.pl
   the perl script where the most basic is to just replay the above r1.snmp

An official documentation to replay SNMP can be found here. I got hold back when trying to listen from other host, it turns out that I must remove the localhost section in r1.conf which will make it to use standard port 161 as well

# Listen on port 9501
#agentaddress    udp:localhost:9501,tcp:localhost:9501

It is also wise to always cut the r1.snmp first to see if the perl works (test with perl -w /usr/local/etc/snmp-emulator/r1.pl) either with warning or clean, meaning no problem with just some of the OIDs found inside the file.

Inside hijra-0.1.18 run $ sudo python setup.py install

It’d fail as it couldn’t find HijriApplet. Rename HijriApplet.py to HijriApplet to make it work. Now, it is in path (/usr/bin/) and can be called by HijriApplet command. We can copy hijra-autostart.desktop description to i.e. ~/.gnome2/panel2.d/default/launchers for shortcut launcher.

python-gnome2-extras must be installed or else it’d fail to launch saying can’t find egg.trayicon

$ sudo make install

After that I test tagsistant to organize /data/tags/

$ tagsistant /data/tags

The tagging works as expected but not too handy since no browser GUI is embedded. It is just like browsing through multiple OR and AND folders.

The installation process will also install tagman (a tag manager GUI) if libgtk2.0-dev and libglib2.0-dev are installed.

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

wget http://foo2zjs.rkkda.com/foo2zjs.tar.gz
wget http://foo2zjs.rkkda.com/firmware/sihpP1006.tar.gz

First, I remove foo2zjs that was installed by default. After (1) make and (2) copy the unpacked HP driver to foo2zjs directory. Do the (3) make install and make install-hotplug.

Run cups and the printer will be listed in the usual list (after a series of regular add new printer).

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.