The unencrypted header is needed when doing a restore but the ill-named dirname value may hold the whole path to the file to restore. This causes the opening of the header to fail:
# ipa-restore /var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ipa-full.tar --gpg-keyring=/root/backup Directory Manager (existing master) password: Preparing restore from /var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ipa-full.tar on ipa.example.com [Errno 2] No such file or directory: '/var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ipa-full.tar/header'
The same command works if only the path is provided:
ipa-restore /var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ --gpg-keyring=/root/backup Directory Manager (existing master) password: Preparing restore from /var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ on grindle.greyoak.com Restoring data will overwrite existing live data. Continue to restore? [no]: y Each master will individually need to be re-initialized or re-created from this one. The replication agreements on masters running IPA 3.1 or earlier will need to be manually re-enabled. See the man page for details. Disabling all replication. Decrypting /var/lib/ipa/backup/ipa-full-2014-11-04-13-38-53/ipa-full.tar.gpg Stopping IPA services Restoring files Restoring from userRoot in EXAMPLE-COM Restoring from ipaca in EXAMPLE-COM Starting IPA services Restarting SSSD The ipa-restore command was successful
We just want to produce an error message here; we don't want to give people the idea that the tar file is the only thing needed for the restore.
To fix the usability we could make it so that all of the backup data actually is in one file, not in a directory.
IIRC I created the header as a future-proofing device in case we ever provide some sort of scanning tool to make it easier to select what to restore. This would allow us to quickly get a digest of the backups without having to decrypt anything.
I tested and restore fails in both cases (encrypted and not) when passed the tarball.
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=951581 (Red Hat Enterprise Linux 7)
Ticket is requested by a downstream RHEL release, bumping priority.
attachment freeipa-dkupka-0031-ipa-restore-Check-if-directory-is-provided-better-er.patch
attachment freeipa-dkupka-0031-2-ipa-restore-Check-if-directory-is-provided-better-er.patch
attachment freeipa-dkupka-0031-3-ipa-restore-Check-if-directory-is-provided-better-er.patch
Starting review
master:
ipa-4-1:
Metadata Update from @rcritten: - Issue assigned to dkupka - Issue set to the milestone: FreeIPA 4.1.2
Login to comment on this ticket.