Config archive issue

nawas · ‎08-19-2008

What does this error mean? I'm on Solaris 9 and RME 4.0.6. If devices is not reachable as this error says then why it was able to fetch the config? Can someone explain the error and possible fix?

CM0057 PRIMARY RUNNING Config fetch SUCCESS, archival failed for 10.1.15.5 Cause: CM0002: Could not archive config Cause: Device may not be reachable, may be in suspended state or credentials may be incorrect. Action: Verify that device is managed, credentials are correct and file system has correct permissions. Increase timeout value, if required. Action: Verify that archive exists for device.

Joe Clarke · ‎08-19-2008

This typically indicates some kind of archive damage. For example, a file was deleted from the file system without a corresponding database update. The solution is usually to remove the device from RME, then re-add it.

nawas · ‎08-19-2008

I would think so too, but what kind of archive damage would that be? is it fixable?

It is very painful to delete/add devices, any workaround or any patch that can fix the archive damage problem? Can I prevent it from occuring in the future. Lates changes were made that I installed RME care package and ever since I have seen the issue. Any help to this would be great.

Thanks.

Joe Clarke · ‎08-19-2008

The only workaround is to restore a known good backup. Beyond that, if a file is deleted, it's deleted.

Very rarely, the error in this case is correct, and the file system either has the wrong permissions, or the job took longer than the job results timeout. You should check these things before resigning to deleting a re-adding the device.

The best preventative for archive deletions is regular backups.

nawas · ‎08-19-2008

I have checked device credentials and all the credential are correct but archive still fails. I even increased the time out but that didn't help. Latest archive is seen from the date when I originally installed the RME care package. Only WO I find is to delete/add devices. Will RME4.0.7 help fix this issue?

Joe Clarke · ‎08-19-2008

There will most likely not be an RME 4.0.7. And my RME care package has nothing to do with this. We have not been able to reproduce this locally without someone physically deleting one of the archive files, so there is no bug that describes this. You can scan the dcamservice.log for any past errors which may have contributed to this problem, but if something happened to the archive outside of RME, it would not be documented there.

nawas · ‎08-19-2008

so you are saying that files under /var/adm/CSCOpx/files/rme/dcma/shadow may have been deleted? when I go under this directory I see the archive file for the devices that are giving me errors and they date a month old again, the date when I installed care package. I have logroation enabled but it only rotates the logfiles. No one has access to CiscoWOrks files system but me so I doubt if someone deleted the archive file. When I check the dcmaservice.log file I see some errors that says "Version does not exist in archive $1 Cause: Version may have been deleted" Could this be that system is just not recognizing the existing file in the folder?

Joe Clarke · ‎08-19-2008

The shadow directory has nothing to do with this. The files in question are found under /var/adm/CSCOpx/files/rme/dcma/devfiles. The directories there are indexed by RME device ID. One of those files must have been deleted.