Offline backups fails with message about sync plan with id 1. Our sync plan has id 2

Support
1

Problem: Trying to run an offline backup. It fails with

- re-enabling sync plans                                     [FAIL}
Could not update the sync plan:
  Could not find sync_plan resource with id 1.  Potential missing permissions: edit_sync_plans

Resolve the failed steps and rerun
the command.  In case the failures are false positives,
use --whitelist="sync-plans-enable"

hammer sync plan list shows the id of our daily sync plan to be 2. How do I tell the backup to look for sync plan with id 2 instead of 1.
Also, the whitelist option does not work. I believe there is an existing bugzilla for this.

Expected outcome: offline backup gets the correct sync plan id

Foreman and Proxy versions: foreman 3,0.101; katello4.2.1-1

Foreman and Proxy plugin versions:

Distribution and version: CentOS 7.9

Other relevant data:

2

The current releases are Foreman 3.6 and Katello 4.8.
I would suggest upgrading your versions first to get better support.
Thanks.

3

This is most probably Bug #36024: sync-plans not in sync with foreman-maintan data.yml - Foreman Maintain - Foreman which is fixed in foreman maintain 1.2.6+ and that’s in Foreman 3.5+

1 Like
4

I will work on updating our satellite servers, but not sure if the latest versions are supported on CentOS 7? Will have to check on the upgrade path.

Thanks!

5

hi @evgeni ,

Unfortunately we too have just hit this bug on Foreman 3.1 / Katello 4.3

Time is of the essence for us as we need to move this install to a new DC.

As a hack, I have deleted all Sync Plans and all Recurring Logics on the server.

I also have emptied out:

root@katello04-> cat /var/lib/foreman-maintain/data.yml

:default:
:sync_plans:
:enabled:
:disabled:

A full, offline backup does now complete without error.

My question is can we trust this backup when we restore it at the new Data Center? We don’t mind recreating the sync plans manually… that isn’t a lot of work.

My concern is will the newly created sync plans work or will there be some sort of problem with them because of Bug 36024?

Thank you,

Eledor

aka “Stressed in Seattle”

:slight_smile:

6

Yeah, a backup created after the above changes is fine.

To give a bit of background: to perform a maintenance task (like creating a backup) you want the system to not change itself while you do so, so foreman-maintain disables all sync tasks (so that no syncs happen during the backup) and then enables them after the action is done. The bug was that it would store the disabled tasks in a file (as some actions require multiple f-m invocations, so you can’t store it in memory), but not clear already absent tasks from previous disablings from that list.

7

ah ok, thank you for the clarification Evgeni

:vulcan_salute: