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.edu@CS.RUTGERS.EDU<mailto:HTTP/krb4.cs.rutgers.edu@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.edu@CS.RUTGERS.EDU<mailto:ldap/krb4.cs.rutgers.edu@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_...
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.edu@CS.RUTGERS.EDU<mailto:ldap/krb3.cs.rutgers.edu@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.