10-02-2008 10:32 AM
I did an update on Solaris 9 from LMS 3.0.1 to LMS 3.1 (server1)
The initial discovery runs without any problems;
To avoid the steps of adding all users manually I copied the cwpass file from another solaris server running LMS 3.0.1(server2) - but, as a mistake I forgot to remove the admin entry from that file which had another password as was configured on server1 for this user. After starting dmgtd again I did not see any errors and could login to server1 with admin user and the password form server2.
Now, the discovery process won't finish with this message in CSDiscovery.log:
[...]
,:CMF:DCR:Device$1266>,:CMF:DCR:Device$1012>,:CMF:DCR:Device$1813>,:CMF:DCR:Device$2612>,:CMF:DCR:Device$2731>,:CMF:DCR:Device$1034>,:CMF:DCR:Device$984>,:CMF:DCR:Device$768>,:CMF:DCR:Device$909>,:CMF:DCR:Device$1529>} {__VIRTUAL_ROOT=CS@FRANETLMS2, __GROUP_ID=CS$1, __GROUP_OWNER=System} 1210290925815 System null 0 1222971089509 admin CS$1
[ Thu Oct 02 20:11:29 MEST 2008 ] FATAL [CSDiscoveryAdaptor : updateOGSGroup] : exception5
com.cisco.nm.xms.ogs.util.OGSException$AccessDenied: User: admin cannot modify group: /CS@FRANETLMS2
at com.cisco.nm.xms.ogs.server.GroupList.getGroupForModification(GroupList.java:845)
at com.cisco.nm.xms.ogs.server.GroupList.replaceGroup(GroupList.java:899)
at com.cisco.nm.xms.ogs.server.OGSImpl.replaceGroup(OGSImpl.java:275)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.cisco.nm.xms.ctm.common.CTMRequestProcessor.executeCall(CTMRequestProcessor.java:546)
at com.cisco.nm.xms.ctm.common.CTMRequestProcessor.handleRequest(CTMRequestProcessor.java:240)
at com.cisco.nm.xms.ctm.server.CTMServer.execute(CTMServer.java:401)
at com.cisco.nm.xms.ctm.server.TCPChannel.executeTask(TCPChannel.java:87)
at com.cisco.nm.xms.ctm.server.ThreadPool.run(ThreadPool.java:72)
at java.lang.Thread.run(Thread.java:595)
I stopped and restarted dmgtd, reset the admin PW in 'Local Security Setup' to the one entered during the update;
I also retyped the password for the System Identity Account and the Peer Server Account to be identical and the same as enterd during the update. The Certificate Setup was also re-done and dmgtd was restarted.
The problem still persists....
10-02-2008 10:43 AM
And it will. This group is now owned by System. It makes me think you've configured Discovery incorrectly. What did you configure under the Discovery group (for adding new devices)?
10-02-2008 10:47 AM
I did not enabled the Group option...
I had a debug running and found the configured options correctly determined - I will lookup in the debug.
These are the current settings:
Modules Selected: CDP
Use DCR as Seed List: Yes
Preferred Management IP: Resolve By SysName
Preferred DCR Display Name: Host Name
Update DCR Display Name: Yes
Use DCR Default Credentials: Yes
E-mail:
Add Discovered Devices to a Group: No
Selected Group Name:
10-02-2008 10:48 AM
Hmmm, seeing the whole CSDiscovery.log would be useful, then.
10-02-2008 10:56 AM
I need to work on this next week as it is 9:00pm and I've got a long way home...
Hopefully I can come back to this issue on Tuesday; Thanks!
10-08-2008 06:16 AM
I have just opend SR 609765723 and will upload the log files...
10-08-2008 07:05 AM
I am currently producing a log that is better to read with full debugging enabled...
10-13-2008 07:37 AM
currently I've got the feeling that if a manual discovery cycle is started and running a scheduled discovery does not check for this cycle and starts its own cycle which could overwhelm the system...
anybody observed a similar issue on LMS 3.1 ?
10-13-2008 07:38 AM
This cannot happen. The CSDiscovery daemon is coded to prevent parallel runs.
11-05-2008 07:24 AM
Hi,
I was just wondering if the cause of this issue has been determined?
I got the same problem yesterday with LMS 3.1:
the last several lines in CSDiscovery.log:
DCR:Device$827>,:CMF:DCR:Device$366>,:CMF:DCR:Device$909>,:CMF:DCR:Device$955>,:CMF:DCR:Device$311>,:CMF:DCR:Device$245>,:CMF:DCR:Device$617>,:CMF:DCR:Device$503>,:CMF:DCR:Device$96>,:CMF:DCR:Device$364>,:CMF:DCR:Device$141>} {__VIRTUAL_ROOT=CS@mrkmcccws01, __GROUP_ID=CS$1, __GROUP_OWNER=System} 1197758323450 System null 0 1225889300879 admin CS$1
[ Wed Nov 05 07:48:21 EST 2008 ] FATAL [CSDiscoveryAdaptor : updateOGSGroup] : exception5
com.cisco.nm.xms.ogs.util.OGSException$AccessDenied: User: admin cannot modify group: /CS@mrkmcccws01
at com.cisco.nm.xms.ogs.server.GroupList.getGroupForModification(GroupList.java:845)
at com.cisco.nm.xms.ogs.server.GroupList.replaceGroup(GroupList.java:899)
at com.cisco.nm.xms.ogs.server.OGSImpl.replaceGroup(OGSImpl.java:275)
at sun.reflect.GeneratedMethodAccessor17.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at com.cisco.nm.xms.ctm.common.CTMRequestProcessor.executeCall(CTMRequestProcessor.java:546)
at com.cisco.nm.xms.ctm.common.CTMRequestProcessor.handleRequest(CTMRequestProcessor.java:240)
at com.cisco.nm.xms.ctm.server.CTMServer.execute(CTMServer.java:401)
at com.cisco.nm.xms.ctm.server.TCPChannel.executeTask(TCPChannel.java:87)
at com.cisco.nm.xms.ctm.server.ThreadPool.run(ThreadPool.java:72)
at java.lang.Thread.run(Thread.java:595)
Restarted the entire LMS and was able to manually start the discovery. The settings of the discovery also have Add Discovered Devices to a Group set to NO
Thanks
11-05-2008 10:12 AM
A bug, CSCsq42118, has been filed for this issue, but this error does not impact Discovery's functionality.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide