Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
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(
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
On 01/13/2015 03:07 PM, David Kupka wrote:
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.
Fixed indentation.
--
David Kupka
From b736db0a36a4bfe52a9cc5ae77ae1580a2b66ed0 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..3b4cf6a7c05245076abde7a9c13e53bc9636b69a 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' %
+raise admintool.ScriptError(
+'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)
if self.backup_ipa_version != str(version.VERSION):
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
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.
--
David Kupka
From 6e454fd3f78e19faa74d4a199588639ca3d9806c 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..e5c758f08103cffdf1aa351a9c37343d16e8a385 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' %
+self.log.error('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('Cannot restore backup on other host.')
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
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
Dne 13.1.2015 v 15:54 David Kupka napsal(a): On 01/13/2015 03:07 PM, David Kupka wrote: 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. Fixed indentation. Thanks, ACK. Pushed to: master: b6c58ff238eb335dcb2a80fc98ecfe8bce5e2422 ipa-4-1: 640a4b30c2475d7b62cc2407af358a8951c34121 -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
On 01/12/2015 01:41 PM, 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.
Thanks for
clarification.
Updated patch attached.
--
David Kupka
From a4ad08d0d637cfad92fd81fdacfbc033a4754731 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 in unattended
mode.
When restoring backup on master other than it was created there is high risk
of unexpected behavior. Perform such restore only if the process is attended
and the user insist on proceeding.
https://fedorahosted.org/freeipa/ticket/4823
---
ipaserver/install/ipa_restore.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ipaserver/install/ipa_restore.py b/ipaserver/install/ipa_restore.py
index 097703938a7ba3820f4acae2148760146464fa08..9d2ce387ed9ece31ab5a61cc2f8be66b1fe9d1ca 100644
--- a/ipaserver/install/ipa_restore.py
+++ b/ipaserver/install/ipa_restore.py
@@ -251,7 +251,7 @@ class Restore(admintool.AdminTool):
if self.backup_host != api.env.host:
self.log.warning('Host name %s does not match backup name %s' %
(api.env.host, self.backup_host))
-if (not options.unattended and
+if (options.unattended or
not user_input(Continue to restore?, False)):
raise admintool.ScriptError(Aborted)
if self.backup_ipa_version != str(version.VERSION):
--
2.1.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
https://fedorahosted.org/freeipa/ticket/4823
--
David Kupka
From f04a311b98c6db0bd19486e21dbe07addf2c0f87 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 full backup restoration on not matching host.
Full backup cannot be restored on other host than the one where it was created.
https://fedorahosted.org/freeipa/ticket/4823
---
ipaserver/install/ipa_restore.py | 3 +++
1 file changed, 3 insertions(+)
diff --git a/ipaserver/install/ipa_restore.py b/ipaserver/install/ipa_restore.py
index 097703938a7ba3820f4acae2148760146464fa08..d9a0383678004ecd04d621a4ce3fc1319e8d9ac9 100644
--- a/ipaserver/install/ipa_restore.py
+++ b/ipaserver/install/ipa_restore.py
@@ -251,6 +251,9 @@ class Restore(admintool.AdminTool):
if self.backup_host != api.env.host:
self.log.warning('Host name %s does not match backup name %s' %
(api.env.host, self.backup_host))
+if self.backup_type == 'FULL':
+self.log.error('Cannot restore full backup on a different host.')
+raise admintool.ScriptError(Aborted)
if (not options.unattended and
not user_input(Continue to restore?, False)):
raise admintool.ScriptError(Aborted)
--
2.1.0
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
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. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
On 01/12/2015 01:37 PM, David Kupka wrote: 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. That report does not discuss data-only backups at all. That does not mean they do not need to be taken care of. I created the patch based on this request. Is it wrong and should ipa-restore fail every time when hostnames does not match? Does it make sense to allow user to force the restoration in this case? Thanks for clarification. I think the behavior that Jan proposed is fine, i.e. warn and ask in attended mode, fail in unattended mode. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
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... ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
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. Thanks for clarification. -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
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? Does it make sense to allow user to force the restoration in this case? Thanks for clarification. -- David Kupka ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
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 ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
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. 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? rob -- Jan Cholasta ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.
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. A full restore definitely shouldn't be done on the wrong host as it will restore certificates and keytabs that are definitely host-specific. rob ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
