[Freeipa-devel] [PATCH] WIP backup and restore

[Petr Viktorin]

On 04/10/2013 08:27 PM, Rob Crittenden wrote:
> Petr Viktorin wrote:
>> On 04/09/2013 11:21 PM, Rob Crittenden wrote:
>>> Petr Viktorin wrote:
>>>> On 04/05/2013 10:54 PM, Rob Crittenden wrote:
>>>>> Petr Viktorin wrote:
>>>>>> On 04/04/2013 03:04 PM, Rob Crittenden wrote:
>>>>>>> Rob Crittenden wrote:
>>>>>>>> Petr Viktorin wrote:
[...]
>>>>>>>>> And for production, please have the commands log by default (set
>>>>>>>>> log_file_name).
>>>>>>>>
>>>>>>>> Yes, I plan on adding that in the future.

One more comment here, shouldn't the log file be /var/log/iparestore.log 
rather than /var/log/ipa_restore.log, to match all the other IPA logs?

[...]
>>>>>> Could backup without --logs save which directories are there, and
>>>>>> restore create empty directories if they don't exist? To me
>>>>>> re-initializing a completely wiped machine looks like a big gain for
>>>>>> the
>>>>>> extra effort.
>>>>>
>>>>> I went ahead and made this change, it wasn't a lot of work.

Another issue: if a CA was never installed on the host, pkiuser doesn't 
exist, and ipa-restore will fail on pwd.getpwnam(PKI_USER). And since 
/etc/passwd is restored, the obvious workaround of adding the user 
doesn't work.

We need to mention in the docs that ipa-restore overwrites files we 
don't fully control (/etc/passwd, /ect/group, /etc/pki/nssdb/).
We also restore named configuration even if IPA DNS is not installed, 
and smb.conf without AD trusts.

[...]
>>>> I found a bug with the following topology:
>>>>
>>>> [IPA 2.2] <-> [IPA 3.2 upgraded from 2.2] <-> [IPA 3.2]
>>>>
>>>> Running ipa-restore on the 3.2 instance tries to disable the CA
>>>> replication agreement between the other two.
>>>> However, deep in ReplicationManager.agreement_dn it uses its own DS
>>>> instance name instead of the Dogtag-9-DS one, so the agreement isn't
>>>> found and the restore fails.
>>>>
>>>>
>>>
>>> Yeah, I'm not 100% sure how to address that either. Is it safe to assume
>>> that if the port is 7389 then the instance is pki-ca?
>>
>> The port was hardcoded so it is.
>
> Ok, just thanks for the other set of eyes. Updated patch attached.

Yup, this is fixed, thanks.

>>> Or should we test
>>> for the existence of the instance name like we do master/clone?
>>>
>>> I've also figured out why Update in Progress loops forever. It is
>>> because the older ipa-replica-manage do not re-enable the replication
>>> agreement, so replication can't continue. I'm not entirely sure how we
>>> will need to go about fixing this, except through documentation.

Documentation works, but note that it'll affect anyone with a bunch of 
upgraded (Dogtag-9 style) instances. It may be a pretty common case in 
the wild.
Maybe we need to recommend reinstalling replicas entirely, rather than 
re-initializing, just to be on the safe side.

-- 
Petr³