Description of problem: Initial install of Replica for FreeIPA 3.2 on Fedora 19 appears to work but, not replicating data. After setting up a replica, I can add a user but do not see that new user on the other server. Version-Release number of selected component (if applicable): freeipa-server-3.2.0-0.2.beta1.fc19.x86_64 389-ds-base-1.3.0.5-1.fc19.x86_64 How reproducible: always in my environment anyway. Steps to Reproduce: 1. On MASTER: Install FreeIPA server on F19 ipa-server-install -a PASSWORD -p PASSWORD --domain=ipa.example.org \ --realm=IPA.EXAMPLE.ORG --hostname f19-1.ipa.example.org --setup-dns \ --forwarder=192.168.122.1 -U 2. On MASTER: Prepare Replica file ipa-replica-prepare --ip-address=192.168.122.192 f19-2.ipa.example.org 3. On MASTER: Copy Replica file to replica scp /var/lib/ipa/replica-info-f19-2.ipa.example.org.gpg f19-2:/var/lib/ipa 4. On REPLICA: Point resolv.conf to MASTER to be sure resolution as expected: echo "nameserver 192.168.122.191" > /etc/resolv.conf 5. On REPLICA: Install/Setup FreeIPA ipa-replica-install -p PASSWORD -w PASSWORD \ --setup-dns --forwarder=192.168.122.1 \ /var/lib/ipa/replica-info-f19-2.ipa.example.org.gpg -U 6. On REPLICA: Create user ipa user-add test --first=f --last=l 7. On MASTER: Check user ipa user-show test Actual results: Does not show user. Some digging appears to show that replication is not working. More info below and to be attached. Expected results: User data (and all other necessary data properly replicated). Additional info: Will attach logs from servers. On MASTER, I'm seeing this in dirsrv errors: sasl_io_recv failed to decode packet for connection And this in messages: encoded packet size too big (246395 > 65536) On REPLICA, I'm seeing can't contact ldap server errors.
This may be related to https://bugzilla.redhat.com/show_bug.cgi?id=923909
Created attachment 737403 [details] logs from master
Created attachment 737404 [details] logs from replica
Created attachment 737407 [details] sosreport from master
Created attachment 737409 [details] sosreport from replica
Does the problem go away if you increase nsslapd-sasl-max-buffer-size to be large enough for the encoded packet size? Our new default is 64k, but it looks like that is being exceeded.
Nathan, yeah, this seemed to fix my problem: On the MASTER: [root@f19-1 ~]# ldapmodify -x -D "cn=directory manager" -w PASSWORD dn: cn=config changetype: modify replace: nsslapd-sasl-max-buffer-size nsslapd-sasl-max-buffer-size: 262144 modifying entry "cn=config" Then ipa-replica-manage del the entry. On the REPLICA: ipa-server-install --uninstall -U Then re-run the ipa-replica-install. This time, I no longer see error messages and the replication from replica to server is working. I can create a user on one and see on the other now. Now, to figure out what to really do about this or if there is someone that can help us figure out why the sasl packet was so big? Thanks, Scott
I am not really an expert on SASL, but isn't this related to the change of default secprops.maxbufsize? Doesn't it also influence the sending party to produce bigger packets?
(In reply to comment #8) > I am not really an expert on SASL, but isn't this related to the change of > default secprops.maxbufsize? Doesn't it also influence the sending party to > produce bigger packets? We changed the default from 2k to 64k recently in 389 DS. My understanding is that there is some negotiation between the client and server about the buffer size, which would mean that the sending party would produce larger packets. That still doesn't explain why we are getting a 240k packet from the client when the server has a 64k secprops.maxbufsize.
Upstream ticket: https://fedorahosted.org/freeipa/ticket/3580
Upstream ticket was recently closed as it could not reproduced. I am wondering that the bug may have been caused by a bug during F19 development. In that case I would close it as well. Rob, didn't you reproduce this bug lately when testing F19?
Yes, I reproduced this replication from F-19 to F-18. My F-19 box isn't exactly up-to-date though.
I tested F18 to F19 (also with Trusts) and I did not hit this error. I use 389-ds-base-1.3.1.0-1.fc19.x86_64. Maybe you Rob used an older version of 389-ds-base in F19 and the issue is fixed now. I will close this BZ until it is reproduced with an up to date dirsrv.