Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1582310

Summary:	engine-backup --mode=verify fails on systems upgraded from 3.6 with a legacy ldap/kerberos conf
Product:	[oVirt] ovirt-engine	Reporter:	Yedidyah Bar David <didi>
Component:	Backup-Restore.Engine	Assignee:	Yedidyah Bar David <didi>
Status:	CLOSED WONTFIX	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	low	Docs Contact:
Priority:	low
Version:	4.2.3	CC:	bpelled, bugs, didi, jbelka, ylavi
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2018-06-18 07:42:58 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Integration	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Yedidyah Bar David 2018-05-24 20:30:04 UTC

Description of problem:

I am not fully certain about the details. Didn't try this myself, only got a report about a single system.

engine-backup --mode=verify fails on backups taken on it, with:

legacy kerberos/ldap directory integration was in use. Please migrate to ovirt-engine-extension-aaa-ldap and backup/restore again

This happens because due to a somewhat-weird sequence of events, systems that had such a legacy setup and upgraded to 4.0, still have a vdc option 'DomainName', which is what engine-backup checks for when deciding to fail as above. The option value should be empty, though, so a fix can be to fail only if it's not empty. Or we can decide that we can ignore it altogether in 4.2 (and 4.1), because it's irrelevant anymore.

So flow should be, more-or-less:

1. setup a 3.6 engine
2. configure a legacy kerberos/ldap directory
3. upgrade to 4.0 (should be done by a backup/restore, moving from el6 to el7)
4. upgrade to 4.1 (and 4.2 if you want)
5. engine-backup --mode=backup --file=f1 --log=backup.log
6. engine-backup --mode=verify --file=f1 --log=verify.log

Comment 1 Yedidyah Bar David 2018-05-24 20:32:59 UTC

A workaround: Manually delete the option. Connect to the engine database and run:

select fn_db_delete_config_value('DomainName','general');

Comment 2 Yaniv Kaul 2018-05-27 14:10:23 UTC

Severity...?

Comment 3 Yedidyah Bar David 2018-05-28 06:44:10 UTC

(In reply to Yaniv Kaul from comment #2)
> Severity...?

Not sure it's even worth fixing, perhaps it's enough that we have it documented. This is because AFAIK we never use directly 'engine-backup --mode=verify' (except for in CI, where it's "controlled"), nor do we tell users to do this.

Setting low for now.

Comment 4 Yaniv Kaul 2018-05-28 06:52:50 UTC

(In reply to Yedidyah Bar David from comment #3)
> (In reply to Yaniv Kaul from comment #2)
> > Severity...?
> 
> Not sure it's even worth fixing, perhaps it's enough that we have it
> documented. This is because AFAIK we never use directly 'engine-backup
> --mode=verify' (except for in CI, where it's "controlled"), nor do we tell
> users to do this.
> 
> Setting low for now.

Shouldn't we add instructions to actually run verify after backup?

Comment 5 Yedidyah Bar David 2018-05-28 07:14:55 UTC

(In reply to Yaniv Kaul from comment #4)
> Shouldn't we add instructions to actually run verify after backup?

Of course, generally speaking. In practice not sure how much this is worth.

IIRC it was added in the 3.6->4.0 upgrade/migration days, mainly to let the user know earlier (before engine-setup) that the old db has 4.0-incompatible data, specifically legacy kerbldap...

Of course we also verify that the content is not corrupted, which is not that relevant if you do this immediately (unless your machine is severely broken).

I guess most backup software verifies (optionally, if at all) by read-after-write  from the target long-term backup medium. Not sure exactly how to apply this to engine-backup or our docs, but we can.

Comment 6 Yaniv Lavi 2018-06-04 07:34:47 UTC

*** Bug 1583198 has been marked as a duplicate of this bug. ***

Comment 7 Yaniv Lavi 2018-06-18 07:42:58 UTC

Not critical, we do not have a large user base for 3.6 anymore and the docs are clear.

Comment 8 Jiri Belka 2018-06-18 08:15:29 UTC

(In reply to Yaniv Lavi from comment #7)
> Not critical, we do not have a large user base for 3.6 anymore and the docs
> are clear.

This is not relevant for existing 3.6 customer only. But IIUC it's relevant for all customers who used to have legacy AAA in the past and used to have 3.6 env.

Something did not remove this from DB and thus it caused verification of the backup to fail on 4.1/4.2. Thus IMO engine-setup should remove such record from DB automatically.

Comment 9 Yedidyah Bar David 2018-06-18 08:45:25 UTC

What Jiri said. I agree with Yaniv it's not critical, but only because no-one uses mode=verify. Also, not sure engine-setup should remove it - it's already empty. Leaving closed - not critical and we have a workaround.