Bug 953653 - freeipa 3.2 replication problems in fedora 19
Summary: freeipa 3.2 replication problems in fedora 19
Alias: None
Product: Fedora
Classification: Fedora
Component: freeipa
Version: 19
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rob Crittenden
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-04-18 19:47 UTC by Scott Poore
Modified: 2015-01-09 13:51 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-05-24 10:51:28 UTC
Type: Bug

Attachments (Terms of Use)
logs from master (4.09 MB, application/x-tar)
2013-04-18 19:57 UTC, Scott Poore
no flags Details
logs from replica (4.18 MB, application/x-tar)
2013-04-18 19:58 UTC, Scott Poore
no flags Details
sosreport from master (541.71 KB, application/x-xz)
2013-04-18 20:10 UTC, Scott Poore
no flags Details
sosreport from replica (531.25 KB, application/x-xz)
2013-04-18 20:11 UTC, Scott Poore
no flags Details

Description Scott Poore 2013-04-18 19:47:48 UTC
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):

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= -U

2.  On MASTER: Prepare Replica file

ipa-replica-prepare --ip-address= 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" > /etc/resolv.conf

5.  On REPLICA: Install/Setup FreeIPA

ipa-replica-install -p PASSWORD -w PASSWORD \
    --setup-dns --forwarder= \
    /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.

Comment 1 Rob Crittenden 2013-04-18 19:53:10 UTC
This may be related to https://bugzilla.redhat.com/show_bug.cgi?id=923909

Comment 2 Scott Poore 2013-04-18 19:57:29 UTC
Created attachment 737403 [details]
logs from master

Comment 3 Scott Poore 2013-04-18 19:58:01 UTC
Created attachment 737404 [details]
logs from replica

Comment 4 Scott Poore 2013-04-18 20:10:52 UTC
Created attachment 737407 [details]
sosreport from master

Comment 5 Scott Poore 2013-04-18 20:11:16 UTC
Created attachment 737409 [details]
sosreport from replica

Comment 6 Nathan Kinder 2013-04-18 20:47:54 UTC
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.

Comment 7 Scott Poore 2013-04-18 22:46:37 UTC
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.


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?


Comment 8 Martin Kosek 2013-04-19 07:07:39 UTC
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?

Comment 9 Nathan Kinder 2013-04-19 15:13:32 UTC
(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.

Comment 10 Rob Crittenden 2013-04-19 15:52:56 UTC
Upstream ticket:

Comment 11 Martin Kosek 2013-05-16 11:04:48 UTC
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?

Comment 13 Rob Crittenden 2013-05-23 14:13:13 UTC
Yes, I reproduced this replication from F-19 to F-18. My F-19 box isn't exactly up-to-date though.

Comment 14 Martin Kosek 2013-05-24 10:51:28 UTC
I tested F18 to F19 (also with Trusts) and I did not hit this error. I use 389-ds-base-

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.

Note You need to log in before you can comment on or make changes to this bug.