cannot load module in agent because of OID assignment conflict
Hi.
I am working with sunmc 3.6.
I have a list 3 problems. Here we go :-)
1> I am trying to load a self developed module into my agents. It works fine on newly installed systems, but fails on a previously installed agent with the following message:
loadModule: module load failed -- /iso/org/dod/internet/private/enterprises/convergin/product/agent/base was assigned as 1, cannot reassign to 2
The failed agent has many modules installed on it (as opposed to the newly installed agents).
The "base" branch in the OID in the message is, in fact, really defined as 2 in the new module. It seems like the SunMC caches old OID values (the 1 value) somewhere in the system, but where? I've tried everything but to format the disk. Tried to initialize the DB (es-setup -F), reinstall sunMC, uninstall old modules, but nothing helps.
2> when trying to load or unload modules on agents that are not on the server system, I receive the following error message:
insufficient security privilege to unload/load module. Agent in remote server context.
3> when trying to add a remote agent - host to the server, i receive the following message:
Error occured during node create
There is a workaround to this problem which is to create the node as SNMP ping and then to modify it to an agent - host. This works fine, but is difficult when working with many agents and dosent look good to the customers.
Thanks in advance,
Michael
[1511 byte] By [
michaelkz] at [2007-11-26 9:00:42]
# 1
About your second problem.There is only a "read-only" connection when adding an agent in remote server context. If you want to load or unload modules you have to do that on the server which it's configured for...
# 2
Hi Michael,
> 1> I am trying to load a self developed module into
> my agents. It works fine on newly installed systems,
> but fails on a previously installed agent with the
> following message:
If you've been building modules and switching OIDs then you may be running into old cached values. You could either make sure to run the uninstall with the -X flag to ensure all the files under /var/opt/SUNWsymon/cfg get wiped as well (i.e. /opt/SUNWsymon/sbin/es-uninst -X"... or try stopping the Agent, move these files out of the way: /var/opt/SUNWsymon/cfg/agent*oid*, then restart. I haven't done this myself in a long time but I think those are the cache files, and they'll be recreated fresh if you remove them. If I'm wrong then simply restore them and restart the Agent again.
Quicksilver is right on the other points: that other Agent is reporting to a different Server (click on it's icon, then the Info tab, and you should see the IP/hostname of that second Server in the trap/event fields). And because it's sharing security with that other SunMC Server and not the one you logged your Console into it's treating all your requests as read-only (i.e. no module load/unload etc).
You don't hear of many people building their own SunMC modules. Do you mind me asking what you're building it for? Some custom in-house app or new piece of hardware?
Regards,
Mike.Kirk@HalcyonInc.com
http://www.HalcyonInc.com
# 3
Hi.
Thanks for the quick response.
> try stopping the Agent, move these files out of the way:
> /var/opt/SUNWsymon/cfg/agent*oid*, then restart.
This did the trick. thanks.
>
> Quicksilver is right on the other points: that other
> Agent is reporting to a different Server (click on
> it's icon, then the Info tab, and you should see the
> IP/hostname of that second Server in the trap/event
> fields).
Yes. It's just that we had problems redefining a new sunmc server for the agent:
The sunmc installation manual instructs to use es-setup -F in order to force a new server on the agent. The problem is that this dosent work if the server layer is also installed on the agent's machine, in which case the es-setup script simply dosen't ask about changing the server.
[BTW. I think that this is not the desired behaviour of es-setup. To my knowledge (please correct me if I'm wrong) it is common practice to install all sunmc layers (as factory defaults) on all hosts, and decide later which host should run as server. The server host may also have to change on the fly due to changing circumctances in the customer premises.]
Anyway, I've found a work around to this problem by deleting the LAYER.SERVER tag from:
/var/opt/SUNWsymon/install/Registry_sun25.xml
while running es-setup -F.
>
> You don't hear of many people building their own
> SunMC modules. Do you mind me asking what you're
> building it for? Some custom in-house app or new
> piece of hardware?
>
We're utilizing the SunMC as a framwork for an NMS/EMS system for the softswitch application we are developing.
Thanks again for the help.
Michael
p.s. if anyone knows a solution for problem 3, please update
# 4
Hi Michael,
> To my knowledge (please correct me if
> I'm wrong) it is common practice to install all
> sunmc layers (as factory defaults) on all hosts, and
> decide later which host should run as server.
That's not a common practice (in my experience) - installing a Server on every system will consume an extra 700MB -> 24GB disk space (depending on the options you choose to install, like PRM or SCM). Plus the Oracle database will configure itself by default to give itself half of your physical memory... and makes shared memory tweaks in /etc/system that may not play well with other apps you're running. Finally, a "Server" config isn't something you can automate with agent-update features, so you lose all the 99%-automated Agent quickinstall goodies.
Most places pick one (or 2 for HA) places for their Server(s), then make agent-update images so they can quickly roll out Agents just by typing in a couple commands on each system.
A Server on every box hasn't been common since the SunMC 2.0 series (called Sun Enterprise SyMON back then). And that was only because the Server used significantly fewer resources (no Oracle) and because it was the only "free" config. (Servers used to be free, and you paid per-Agent)
Regards,
Mike.Kirk@HalcyonInc.com
http://www.HalcyonInc.com
# 5
Hello Mike.
> That's not a common practice (in my experience) -
> installing a Server on every system will consume an
> extra 700MB -> 24GB disk space ...
This information is important to us, and we may indeed have to consider revising our installation policy. Nevertheless, I do believe there should be some easy way to redefine a server for an agent (even if the agent's machine happens to be installed with the server layer).
Regards,
Michael
