I also had issues installing a replica under 7.4. Here are my notes. krb4 is 
the new replica, krb1 and 2 the existing ones.

However a few things set up on krb4 didn't replicate to the krb1 and krb2. 
There were enough issues that I did a full comparison of dumps from krb1 and 
krb4. Use "/sbin/ipa-backup --online --data" to dump the data, untar the tar 
file, and look at CS-RUTGERS-EDU-userRoot.ldif. I used ldifsort.pl and 
ldifdiff.pl to compare the versions from krb1 and krb4, together with an awk 
script that normalizes entries. So I did a full comparison of ldif files (from 
a backup). I found three things:

dn: 
cn=krb4.cs.rutgers.edu<http://krb4.cs.rutgers.edu>,cn=masters,cn=ipa,cn=etc,dc=cs,dc=rutgers,dc=edu
changetype:modify
add:objectclass
objectClass: nsContainer
objectClass: ipaReplTopoManagedServer
objectClass: ipaConfigObject
objectClass: ipaSupportedDomainLevelConfig
-
add:ipaReplTopoManagedSuffix
ipaReplTopoManagedSuffix: dc=cs,dc=rutgers,dc=edu
-
add:ipaMinDomainLevel
ipaMinDomainLevel: 0
-
add:ipaMaxDomainLevel
ipaMaxDomainLevel: 1


dn: cn=ipa-http-delegation,cn=s4u2proxy,cn=etc,dc=cs,dc=rutgers,dc=edu
changetype:modify
add:memberprincipal
memberPrincipal: 
HTTP/krb4.cs.rutgers....@cs.rutgers.edu<mailto:HTTP/krb4.cs.rutgers....@cs.rutgers.edu>


dn: cn=ipa-ldap-delegation-targets,cn=s4u2proxy,cn=etc,dc=cs,dc=rutgers,dc=edu
changetype:modify
add:memberprincipal
memberPrincipal: 
ldap/krb4.cs.rutgers....@cs.rutgers.edu<mailto:ldap/krb4.cs.rutgers....@cs.rutgers.edu>



Perhaps a cleaner solution would have been to reinit the other two from krb4, 
but I wasn't sure that was safe.
In addition to this, "ipa topologysegment-find domain" showed that the link to 
krb4 was one-way. I later realized that the repliction agreement was actually 
there, so it was just the topology property that was wrong. I could have fixed 
it to changing the attribute from left-to-right to both, using ldapmodify. What 
I did was to delete the topology segement and put it back. But that ended up 
with two replication agreements from krb2 to krb4. So I deleted the topology 
segment, then manually deleted 
"cn=meTokrb4.cs.rutgers.edu<http://meTokrb4.cs.rutgers.edu>,cn=replica,cn=dc\3Dcs\2Cdc\3Drutgers\2Cdc\3Dedu,cn=mapping
 tree,cn=config changetype:delete" and added back the topology segment.
It's worth noting that reiniting ldap won't fix issues with replication, 
because only the user database is synced. Replication agreements are in 
cn=config. In theory deleting the topology segment and putting it back will fix 
a lot of issues, but not all of them.
[edit<http://klinzhai.rutgers.edu/mediawiki/index.php?title=Setting_up_backup_server&action=edit&section=4>]Diagnosing
 permission failures
First, make sure the directory server principals are recognized by the others. 
E.g. on krb3

kinit -k -t /etc/dirsrv/ds.keytab 
ldap/krb3.cs.rutgers....@cs.rutgers.edu<mailto:ldap/krb3.cs.rutgers....@cs.rutgers.edu>


Now do

ldapsearch -Y GSSAPI -h krb1.cs.rutgers.edu<http://krb1.cs.rutgers.edu> 
uid=hedrick


for both krb1 and 2, to make sure authentiction works. I'd do that on all 
servers to all servers. If it's working, then the other thing to check is that 
the principals are in the group "cn=replication 
managers,cn=sysaccounts,cn=etc,dc=cs,dc=rutgers,dc=edu".

ldapsearch -Y GSSAPI cn="replication managers"


If the data isn't syncing you may want to do that on all servers.
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to