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

[David Kupka]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-dkupka-0036-5-Abort-backup-restoration-on-not-matching-host.patch
Type: text/x-patch
Size: 1656 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20150113/cb595f0b/attachment.bin>