Red Hat Bugzilla – Bug 1176034
More validation required on ipa-restore's options
Last modified: 2015-03-05 05:19:09 EST
This bug is created as a clone of upstream ticket: https://fedorahosted.org/freeipa/ticket/4797 (1)Restore from data backup without --data option {{{ [root@dhcp207-214 backup]# ipa-restore -p xxxxxxxx /var/lib/ipa/backup/ipa-data-2014-12-10-17-47-50/ -U Preparing restore from /var/lib/ipa/backup/ipa-data-2014-12-10-17-47-50/ on dhcp207-214.testrelm.test 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. Disabling replication agreement on dhcp207-133.testrelm.test to dhcp207-214.testrelm.test Stopping IPA services Restoring from userRoot in TESTRELM-TEST Restoring from ipaca in TESTRELM-TEST Starting IPA services Restarting SSSD The ipa-restore command was successful [root@dhcp207-214 backup]# }}} Here restore is happening similar to restore from full backup but actually from data backup and that too without --data option. I am expecting that restore should fail and prompt an error message (or atleast a warning message) that --data option must be used with restore data backup. Related one with --online option {{{ [root@dhcp207-214 backup]# ipa-restore -p xxxxxxxx --online /var/lib/ipa/backup/ipa-data-2014-12-10-17-47-50/ -U Preparing restore from /var/lib/ipa/backup/ipa-data-2014-12-10-17-47-50/ on dhcp207-214.testrelm.test 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. Disabling replication agreement on dhcp207-133.testrelm.test to dhcp207-214.testrelm.test Stopping IPA services Restoring from userRoot in TESTRELM-TEST Unable to bind to LDAP server: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-TESTRELM-TEST.socket': Restoring from ipaca in TESTRELM-TEST Unable to bind to LDAP server: cannot connect to 'ldapi://%2fvar%2frun%2fslapd-TESTRELM-TEST.socket': Starting IPA services Restarting SSSD The ipa-restore command was successful [root@dhcp207-214 backup]# }}} Here expecting an error message that --online option can only provided along with --data option. (2)Restore with --no-logs option from data backup {{{ [root@dhcp207-214 backup]# ipa-restore -p xxxxxxxx --data /var/lib/ipa/backup/ipa-data-2014-12-10-17-38-58/ --no-logs -U Preparing restore from /var/lib/ipa/backup/ipa-data-2014-12-10-17-38-58/ on dhcp207-214.testrelm.test 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. Disabling replication agreement on dhcp207-133.testrelm.test to dhcp207-214.testrelm.test Stopping Directory Server Restoring from userRoot in TESTRELM-TEST Restoring from ipaca in TESTRELM-TEST Starting Directory Server The ipa-restore command was successful [root@dhcp207-214 backup]# }}} Here restore should fail prompting an error message (or warning message at least) that --no-logs option can not be used with --data (3)Non-existent ds instance in --instance {{{ [root@dhcp207-214 ~]# ipa-restore --data -p xxxxxxxx --instance=TESTRELM-TEST1 /var/lib/ipa/backup/ipa-full-2014-12-11-13-17-59/ Preparing restore from /var/lib/ipa/backup/ipa-full-2014-12-11-13-17-59/ on dhcp207-214.testrelm.test No instances to restore to [root@dhcp207-214 ~]# }}} Expecting error message : "Instance TESTRELM-TEST1 does not exist" Similarly for --backend option {{{ [root@dhcp207-214 ~]# ipa-restore --data -p xxxxxxxx --backend=userRoot1 /var/lib/ipa/backup/ipa-full-2014-12-11-13-17-59/ Preparing restore from /var/lib/ipa/backup/ipa-full-2014-12-11-13-17-59/ on dhcp207-214.testrelm.test No instances to restore to [root@dhcp207-214 ~]# }}} Expecting error message : "Backend userRoot1 does not exist"
Fixed upstream master: https://fedorahosted.org/freeipa/changeset/10fe918acd8f7428588f2dff52f64070a9328c29 ipa-4-1: https://fedorahosted.org/freeipa/changeset/6950e7b14f87bbe0e922f54b76f2c8319ae6c3fd Note that issue (2) was not addressed upstream as it is benign.
Master branch regression fixed: master: * 35c4fa2e36a83ad80c79a21ac8e495985f38dbde Fix IPA_BACKUP_DIR path name No change is needed for the ipa-4-1 branch.
Verified. IPA Version: ============ [root@master ~]# rpm -q ipa-server ipa-server-4.1.0-16.el7.x86_64 [root@master ~]# For scenario (1) and (2) of description, now we see that on console it is displayed that what kind of restore from what kind of backup is performed. In this case, following is displayed. "Performing DATA restore from DATA backup" [root@master ~]# ipa-restore -p xxxxxxxx /var/lib/ipa/backup/ipa-data-2015-01-27-21-09-30/ -U Preparing restore from /var/lib/ipa/backup/ipa-data-2015-01-27-21-09-30/ on master.testrelm.test Performing DATA restore from DATA backup 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. Stopping Directory Server Restoring from userRoot in TESTRELM-TEST Restoring from ipaca in TESTRELM-TEST Starting Directory Server The ipa-restore command was successful [root@master ~]# Scenario (3) of description fixed with expected error messages now. [root@master ~]# ipa-restore -p xxxxxxxx --data --instance=TESTRELM-TEST1 /var/lib/ipa/backup/ipa-data-2015-01-27-21-09-30/ -U Preparing restore from /var/lib/ipa/backup/ipa-data-2015-01-27-21-09-30/ on master.testrelm.test Instance TESTRELM-TEST1 does not exist [root@master ~]# ipa-restore -p xxxxxxxx --data --backend=userRoot1 /var/lib/ipa/backup/ipa-data-2015-01-27-21-09-30/ -U Preparing restore from /var/lib/ipa/backup/ipa-data-2015-01-27-21-09-30/ on master.testrelm.test Backend userRoot1 does not exist [root@master ~]#
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0442.html