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

Petr Viktorin pviktori at redhat.com
Fri Apr 12 10:25:56 UTC 2013


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

-- 
Petr³




More information about the Freeipa-devel mailing list