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

[Rob Crittenden]

Petr Viktorin wrote:
> On 04/11/2013 11:43 PM, Rob Crittenden wrote:
>> Petr Viktorin wrote:
>>> 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?
>>
>> Sure. I did it because it kept conflicting with ipareplica-install.log
>> and I like easy tabbing :-)
>>
>>> [...]
>>>>>>>>> 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 should only call this if CA is in one of the services to be restored.
>> I went ahead and added a try/except around getting the name to make it
>> more bullet-proof.
>>>
>>> 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.
>>
>> Added. I suppose we could eventually add additional excludes based on
>> the restored features.
>>
>>> [...]
>>>>>>> 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.
>>>
>>
>> Added.
>>
>> I also added a FILES section to both man pages to point out the log
>> files and where the backups are saved.
>>
>> rob
>
> Thanks!
> And that's all the issues I found. Let's set the beast free, so it gets
> some wider testing.
>
> ACK
>

pushed ot master