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

Rob Crittenden rcritten at redhat.com
Thu Apr 11 21:43:29 UTC 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: freeipa-rcrit-1093-5-backup.patch
Type: text/x-patch
Size: 80332 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20130411/edaa7b07/attachment.bin>


More information about the Freeipa-devel mailing list