Re: [Freeipa-users] IPA-Server v3.0 Replication Broken
Hi, Thank you once again for your reply. Increasing the nsslapd-sasl-max-buffer-size to 2M on both servers and restarting the IPA services seems to have resolved the issue. Best regards, Dan -Original Message- From: David Kupka [mailto:dku...@redhat.com] Sent: Thursday, January 29, 2015 8:55 AM To: Auerbach, Steven; IPA User Maillist (freeipa-users@redhat.com) Cc: Dan Ouellet Subject: Re: [Freeipa-users] IPA-Server v3.0 Replication Broken On 01/29/2015 02:43 PM, Auerbach, Steven wrote: > We have a pair of IPA Servers for our network. Our servers are Oracle Linux > 6 x86_64 with the ipa-server.3.0.X packages [up to date as distributed by > Oracle Linux]. > > Recently we noticed that the master (IPA01) is replicating fine to the > designated replicant. But changes that are made on the replicant do not get > back to the master. > > This is true when ipa-clients register (if the registration script grabs the > replicant for registration then the host enrollment and DNS will not make it > back to the master. > This is true when users make a password change. If the password process grabs > the master then replication to the replicant is fine, but if the change > process grabs the replicant it will not make it back to the master. Then the > user login is broken. > This is true when, in the IPA Admin Web Interface we delete a host entry or > DNS record. If done on the master the change replicates to the replicant. If > the change is made on the replicant it does not make it to the master. > > We have not found anything in the documentation that helps us understand > where to proceed or what to do to diagnose the replication problem. We have > tried removing the replicant from the IPA server configuration and powering > off the box, creating a new server and reconstructing a new replica on that > new server. The problem persists. We suspect the issue lies in some > configuration somewhere on the master, but know not where to go next. > > Anyone have a similar experience and overcome it? We will take any advice we > can get! > > With appreciation and respect; > > Steven Auerbach > Systems Administrator > State University System of Florida > Board of Governors > 325 West Gaines Street > Tallahassee, Florida 32399 > (850) 245-9592 | Fax (850) 245-0419 > www.flbog.edu > [BOG-wordmark-wideFOR EMAIL-color] > > > > Hi, this looks similar to: https://www.redhat.com/archives/freeipa-users/2015-January/msg00331.html and https://fedorahosted.org/freeipa/ticket/4807 Did you try to raise the nsslapd-sasl-max-buffer-size? -- David Kupka -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA-Server v3.0 Replication Broken
Thank you for your reply. An "ldapsearch" revealed that the buffer is set to 64k on both the master and the replica. I will increase to size to 2M and test to see if this resolves the problem. Best regards, Dan -Original Message- From: David Kupka [mailto:dku...@redhat.com] Sent: Thursday, January 29, 2015 8:55 AM To: Auerbach, Steven; IPA User Maillist (freeipa-users@redhat.com) Cc: Dan Ouellet Subject: Re: [Freeipa-users] IPA-Server v3.0 Replication Broken On 01/29/2015 02:43 PM, Auerbach, Steven wrote: > We have a pair of IPA Servers for our network. Our servers are Oracle Linux > 6 x86_64 with the ipa-server.3.0.X packages [up to date as distributed by > Oracle Linux]. > > Recently we noticed that the master (IPA01) is replicating fine to the > designated replicant. But changes that are made on the replicant do not get > back to the master. > > This is true when ipa-clients register (if the registration script grabs the > replicant for registration then the host enrollment and DNS will not make it > back to the master. > This is true when users make a password change. If the password process grabs > the master then replication to the replicant is fine, but if the change > process grabs the replicant it will not make it back to the master. Then the > user login is broken. > This is true when, in the IPA Admin Web Interface we delete a host entry or > DNS record. If done on the master the change replicates to the replicant. If > the change is made on the replicant it does not make it to the master. > > We have not found anything in the documentation that helps us understand > where to proceed or what to do to diagnose the replication problem. We have > tried removing the replicant from the IPA server configuration and powering > off the box, creating a new server and reconstructing a new replica on that > new server. The problem persists. We suspect the issue lies in some > configuration somewhere on the master, but know not where to go next. > > Anyone have a similar experience and overcome it? We will take any advice we > can get! > > With appreciation and respect; > > Steven Auerbach > Systems Administrator > State University System of Florida > Board of Governors > 325 West Gaines Street > Tallahassee, Florida 32399 > (850) 245-9592 | Fax (850) 245-0419 > www.flbog.edu > [BOG-wordmark-wideFOR EMAIL-color] > > > > Hi, this looks similar to: https://www.redhat.com/archives/freeipa-users/2015-January/msg00331.html and https://fedorahosted.org/freeipa/ticket/4807 Did you try to raise the nsslapd-sasl-max-buffer-size? -- David Kupka -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA-Server v3.0 Replication Broken
On 01/29/2015 02:43 PM, Auerbach, Steven wrote: We have a pair of IPA Servers for our network. Our servers are Oracle Linux 6 x86_64 with the ipa-server.3.0.X packages [up to date as distributed by Oracle Linux]. Recently we noticed that the master (IPA01) is replicating fine to the designated replicant. But changes that are made on the replicant do not get back to the master. This is true when ipa-clients register (if the registration script grabs the replicant for registration then the host enrollment and DNS will not make it back to the master. This is true when users make a password change. If the password process grabs the master then replication to the replicant is fine, but if the change process grabs the replicant it will not make it back to the master. Then the user login is broken. This is true when, in the IPA Admin Web Interface we delete a host entry or DNS record. If done on the master the change replicates to the replicant. If the change is made on the replicant it does not make it to the master. We have not found anything in the documentation that helps us understand where to proceed or what to do to diagnose the replication problem. We have tried removing the replicant from the IPA server configuration and powering off the box, creating a new server and reconstructing a new replica on that new server. The problem persists. We suspect the issue lies in some configuration somewhere on the master, but know not where to go next. Anyone have a similar experience and overcome it? We will take any advice we can get! With appreciation and respect; Steven Auerbach Systems Administrator State University System of Florida Board of Governors 325 West Gaines Street Tallahassee, Florida 32399 (850) 245-9592 | Fax (850) 245-0419 www.flbog.edu [BOG-wordmark-wideFOR EMAIL-color] Hi, this looks similar to: https://www.redhat.com/archives/freeipa-users/2015-January/msg00331.html and https://fedorahosted.org/freeipa/ticket/4807 Did you try to raise the nsslapd-sasl-max-buffer-size? -- David Kupka -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
