On 01/13/2015 02:57 PM, Jan Cholasta wrote:
Dne 13.1.2015 v 14:44 David Kupka napsal(a):
On 01/12/2015 04:50 PM, Rob Crittenden wrote:
Jan Cholasta wrote:
Dne 12.1.2015 v 16:30 Rob Crittenden napsal(a):
Jan Cholasta wrote:
Dne 12.1.2015 v 13:37 David Kupka napsal(a):
On 01/12/2015 01:14 PM, Jan Cholasta wrote:
Dne 12.1.2015 v 13:08 Martin Kosek napsal(a):
On 01/12/2015 12:53 PM, David Kupka wrote:
https://fedorahosted.org/freeipa/ticket/4823

Looking at this patch, are data-only backups supposed to work
properly
then?
Wouldn't for example Directory Server fail to start when cn=config
contain some
hostname-bound values?

Just checking...


IMO the error should be raised in both data-only and full restore,
if in
unattended mode or the user wishes not to continue.

Description of the problem in ticket states: "I tried to run
ipa-restore
(full kind) on replica from full backup taken on master and was
expecting an error message that restore can not proceed and only
data
restore possible."

I created the patch based on this request. Is it wrong and should
ipa-restore fail every time when hostnames does not match?

Yes, as Martin pointed out, the data may contain references to the
hostname.

Does it make
sense to allow user to force the restoration in this case?

Yes, if the users wish, they should be allowed to continue.

IIRC a data restore is just the data from the replicated tree so there
is nothing hostname-specific. It is probably worth investigating so we
don't go too far one way or the other.

There's at least cn=<fqdn>,cn=masters,cn=etc,<suffix>.

That's part of the replicated tree, but it does raise a question:

What would it mean if you did a data restore to a server that doesn't
exist as a master in the realm? Geez, I don't know, but it likely
wouldn't go well. Checking for that would be quite an issue and it would
surely exercise the python-ldap ldif module.

Is it illegal though? I don't know. Any keytabs would be bad b/c the
Kerberos master key is different. In all likelihood things would just go
south. I imagine someone might try this in an attempt to setup a
test/integration environment. It just wouldn't work.

In a replicated environment though, with hosts A and B, restoring the
data from B on A is probably not a big deal, though it does raise the
question of "why the heck would you do this?" It could be that you only
did backups on B and don't want to do a full re-init on A due to
size/time/moon phase.



A full restore definitely shouldn't be done on the wrong host as it
will
restore certificates and keytabs that are definitely host-specific.

Should the continue prompt be removed then?

Well, you've just about got me convinced we shouldn't allow it, at least
not without several "do you really want to do this?" prompts.

This seems to fall in the range of "yeah, it will work if you know what
you're doing, but why would you ever want to?" I think until that
question is answered it is safer to disallow it. I'd be ok with a ticket
into the deferred to investigate this later to see if it can be relaxed.

rob

Ok, changed to remove the prompt and raise error. We can bring it back
once some user comes with convincing reason.


The error doesn't need to be logged, raising a ScriptError is perfectly
sufficient (please use the message that includes both of the hostnames).

Updated patch attached.

--
David Kupka
From 81e4b3955ef0d401e35ba186c5ab60cffce35601 Mon Sep 17 00:00:00 2001
From: David Kupka <dku...@redhat.com>
Date: Sun, 11 Jan 2015 18:45:11 -0500
Subject: [PATCH] Abort backup restoration on not matching host.

When restoring backup on master other than it was created there is high risk
of unexpected and hard-to-debug behavior. Refuse such restore.

https://fedorahosted.org/freeipa/ticket/4823
---
 ipaserver/install/ipa_restore.py | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/ipaserver/install/ipa_restore.py b/ipaserver/install/ipa_restore.py
index 097703938a7ba3820f4acae2148760146464fa08..6bf651030910de7bb7e030d4b65eb3eb13fc368d 100644
--- a/ipaserver/install/ipa_restore.py
+++ b/ipaserver/install/ipa_restore.py
@@ -249,11 +249,9 @@ class Restore(admintool.AdminTool):
                 (options.instance or options.backend)):
                 raise admintool.ScriptError('Restore must be in data-only mode when restoring a specific instance or backend.')
             if self.backup_host != api.env.host:
-                self.log.warning('Host name %s does not match backup name %s' %
+                error_msg = ('Host name %s does not match backup name %s' %
                     (api.env.host, self.backup_host))
-                if (not options.unattended and
-                    not user_input("Continue to restore?", False)):
-                    raise admintool.ScriptError("Aborted")
+                raise admintool.ScriptError(error_msg)
             if self.backup_ipa_version != str(version.VERSION):
                 self.log.warning(
                     "Restoring data from a different release of IPA.\n"
-- 
2.1.0

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to