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³
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
