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
