Loading...
Loading...
manual/scheduled backups were failing the database integrity check [Tue Feb 2 14:48:25 2016][FATAL] [no revision for EO container]eo_type [IntrusionLayer], uuid [9d0017ac-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][FATAL] [no revision for EO container]eo_type [IntrusionLayer], uuid [9cbd5930-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][FATAL] [no revision for EO container]eo_type [IntrusionLayer], uuid [9ccf33d0-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][FATAL] [no revision for EO container]eo_type [IntrusionLayer], uuid [9da4ad6c-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][FATAL] [no revision for EO container]eo_type [IntrusionLayer], uuid [9d4fe872-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][FATAL] [no revision for EO container]eo_type [IntrusionLayer], uuid [9d6c0052-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][FATAL] [no revision for EO container]eo_type [IntrusionLayer], uuid [9d9395ae-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][FATAL] [no revision for EO container]eo_type [IntrusionLayer], uuid [9da87fb4-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][FATAL] [no revision for EO container]eo_type [IntrusionLayer], uuid [9cc4ea7e-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][WARNING][orphaned EO permissions] uuid [9c0e0002-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][WARNING][orphaned EO permissions] uuid [9c86aaa2-c8d0-11e5-a3df-857ace55accc] [Tue Feb 2 14:48:25 2016][WARNING][orphaned EO permissions] uuid [9c3c24f0-c8d0-11e5-a3df-857ace55accc] After Checking DB, Warnings: 4, Fatal Errors: 9
During Manual/Scheduled Backups.
A script to update the revision of the failing objects.
As per my understanding I believe all the IntrusionLayer objects were from user-created IPS policies. Looked at the source code, Every EO gets both a uuid and a revision uuid. The revision is changed every time the object is modified.So, Either the backup, or the restore process isn't populating the revision UUID in there or may be it seems, either that isn't getting backed-up properly, or the restore isn't populating that field in the EO store. As per my understanding on backup/restore, it's either supposed to store the same revision outright, or create a new revision. The other one, permissions, is part of the metadata for an EO. There are several fields in permissions. Looking at the src code, orphaned EO permissions means that we are storing permissions (think domain, user, group, etc. at an object level) for an object that doesn't exist. Looks like we store permissions separately from the object itself and stitch that together when loading the object. So, something didn't get properly removed from the permissions DB for an object that was deleted. But, that may or may not have occurred during the backup/restore. We would have to have a DB integrity check before and after the backup/restore there to know for sure. I'm thinking that it could have happened at any time an object was deleted.
Click on a version to see all relevant bugs
Cisco Integration
Learn more about where this data comes from
BugZero Plan
Streamline upgrades with automated vendor bug scrubs
BugZero Prevent
Wish you caught this bug sooner? Get proactive today.