[Freeipa-devel] [PATCH] 0036 Abort full backup restoration on not matching host.

[Jan Cholasta]

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