[Freeipa-users] Re: replication problem

2017-06-15 Thread Eric Renfro via FreeIPA-users 
So, this problem is still causing me unable to install/build any
replica servers.

Eric


-Original Message-

Date: Tue, 13 Jun 2017 12:11:57 -0400
Subject: Re: [Freeipa-users] Re: replication problem
Cc: Mark Reynolds <marey...@redhat.com>, Rob Crittenden <rcritten@redha
t.com>
To: Rob Crittenden via FreeIPA-users <freeipa-users@lists.fedorahosted.
org>
From: Eric Renfro <psi-j...@linux-help.org>
In my particular case, I'm not using the client installation prior to
the replica installation. Though I have tried that method as well,
resulting in the very same issues regardless.

I'm using this to do the installation currently:

ipa-replica-install --unattended \
--no-ntp --mkhomedir --skip-conncheck \
--ip-address ip.ad.re.ss \
--principal admin \
--admin-password "redacted" \
--server ipa1.home.ld \
--domain home.ld \
--realm HOME.LD

I'm going to try once again with the client install (that part works),
then promoting that to a replica, using kinit to gain admin privileges
and thus omitting the principal, admin-password, domain and realm
options to the replica-install command.

Eric


-Original Message-

Date: Tue, 13 Jun 2017 11:55:26 -0400
Subject: [Freeipa-users] Re: replication problem
Cc: Eric Renfro <psi-j...@linux-help.org>, Mark Reynolds <mareynol@redh
at.com>, Rob Crittenden <rcrit...@redhat.com>
To: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
Reply-to: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
From: Rob Crittenden via FreeIPA-users <freeipa-users@lists.fedorahoste
d.org>
Eric Renfro via FreeIPA-users wrote:
> Hmmm..
> 
> Well, in my case specifically, the failed ipa-replica-install does in
> fact have the nsslapd-rootpw entry, however, changing this in a
> recovery
> process does no good during an ipa-replica-install.

I think this is a red herring. The client promotion code happened after
my time but I seem to recall that some magic happens regarding the DM
password so it isn't required during the install. I'm pretty sure that
a
random one is set by the installer during initial configuration and at
the end it is replaced by the DM password in the master it is
replicating from.

So in other words it is expected to not match for some of the
installation.

rob

> Eric
> 
> -----Original Message-
> 
> *Date*: Tue, 13 Jun 2017 10:51:13 -0400
> *Subject*: [Freeipa-users] Re: replication problem
> *Cc*: Eric Renfro <psi-j...@linux-help.org
> <mailto:eric%20renfro%20%3cpsi-j...@linux-help.org%3e>>, Adrian HY
> <ayeja...@gmail.com <mailto:adrian%20hy%20%3cayeja...@gmail.com%3e>>,
> Mark Reynolds <marey...@redhat.com
> <mailto:mark%20reynolds%20%3cmarey...@redhat.com%3e>>
> *To*: FreeIPA users list <freeipa-users@lists.fedorahosted.org
> <mailto:FreeIPA%20users%20list%20%3cfreeipa-users@lists.fedorahosted.
> org%3e>>
> Reply-to: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
> *From*: Mark Reynolds via FreeIPA-users
> <freeipa-users@lists.fedorahosted.org
> <mailto:Mark%20Reynolds%20via%20FreeIPA-users%20%3cfreeipa-users@list
> s.fedorahosted.org%3e>>
> 
> 
> On 06/13/2017 10:34 AM, Eric Renfro via FreeIPA-users wrote:
> > Huh.. Well, who'da thunk it. I just literally reported the same
> > kind of
> > trouble I was having, which looks like it matches this same
> > situation,
> > with the ipa-replica-install failing to initiate replication
> > because of
> > Invalid password, because the password for some reason does not
> > seem to
> > be being set.
> 
> Sorry, replication does not use the Directory Manager account. 
> Typically some type of "replication manager" entry is used, and in
> IPA
> I'm pretty sure this account uses kerberos credentials (not a
> password).
> 
> Going back to the Directory Manager   To confirm if the password
> is
> set, look in /etc/dirsv/slapd-INSTANCE/dse.ldif, and under cn=config
> look for "nsslapd-rootpw" if this attribute is missing then it truly
> is
> not set.  If your directory manager account does not have a password,
> or
> there is a password but you don't know what it is, then you can reset
> it
> following this doc:
> 
> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.htm
> l
> <http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.ht
> ml>
> 
> > Eric
> > 
> > 
> > -Original Message-
> > 
> > Date: Tue, 13 Jun 2017 09:49:40 -0400
> > Subject: [Freeipa-users] Re: replication problem
> > Cc: FreeIPA users list <freeipa-users@lists.fedorahosted.org>,
> > Adrian
> > HY <ayeja...@gmail.com>
> >

[Freeipa-users] Re: replication problem

2017-06-13 Thread Eric Renfro via FreeIPA-users 
In my particular case, I'm not using the client installation prior to
the replica installation. Though I have tried that method as well,
resulting in the very same issues regardless.

I'm using this to do the installation currently:

ipa-replica-install --unattended \
--no-ntp --mkhomedir --skip-conncheck \
--ip-address ip.ad.re.ss \
--principal admin \
--admin-password "redacted" \
--server ipa1.home.ld \
--domain home.ld \
--realm HOME.LD

I'm going to try once again with the client install (that part works),
then promoting that to a replica, using kinit to gain admin privileges
and thus omitting the principal, admin-password, domain and realm
options to the replica-install command.

Eric

-Original Message-

Date: Tue, 13 Jun 2017 11:55:26 -0400
Subject: [Freeipa-users] Re: replication problem
Cc: Eric Renfro <psi-j...@linux-help.org>, Mark Reynolds <mareynol@redh
at.com>, Rob Crittenden <rcrit...@redhat.com>
To: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
Reply-to: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
From: Rob Crittenden via FreeIPA-users <freeipa-users@lists.fedorahoste
d.org>
Eric Renfro via FreeIPA-users wrote:
> Hmmm..
> 
> Well, in my case specifically, the failed ipa-replica-install does in
> fact have the nsslapd-rootpw entry, however, changing this in a
> recovery
> process does no good during an ipa-replica-install.

I think this is a red herring. The client promotion code happened after
my time but I seem to recall that some magic happens regarding the DM
password so it isn't required during the install. I'm pretty sure that
a
random one is set by the installer during initial configuration and at
the end it is replaced by the DM password in the master it is
replicating from.

So in other words it is expected to not match for some of the
installation.

rob

> Eric
> 
> -Original Message-
> 
> *Date*: Tue, 13 Jun 2017 10:51:13 -0400
> *Subject*: [Freeipa-users] Re: replication problem
> *Cc*: Eric Renfro <psi-j...@linux-help.org
> <mailto:eric%20renfro%20%3cpsi-j...@linux-help.org%3e>>, Adrian HY
> <ayeja...@gmail.com <mailto:adrian%20hy%20%3cayeja...@gmail.com%3e>>,
> Mark Reynolds <marey...@redhat.com
> <mailto:mark%20reynolds%20%3cmarey...@redhat.com%3e>>
> *To*: FreeIPA users list <freeipa-users@lists.fedorahosted.org
> <mailto:FreeIPA%20users%20list%20%3cfreeipa-users@lists.fedorahosted.
> org%3e>>
> Reply-to: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
> *From*: Mark Reynolds via FreeIPA-users
> <freeipa-users@lists.fedorahosted.org
> <mailto:Mark%20Reynolds%20via%20FreeIPA-users%20%3cfreeipa-users@list
> s.fedorahosted.org%3e>>
> 
> 
> On 06/13/2017 10:34 AM, Eric Renfro via FreeIPA-users wrote:
> > Huh.. Well, who'da thunk it. I just literally reported the same
> > kind of
> > trouble I was having, which looks like it matches this same
> > situation,
> > with the ipa-replica-install failing to initiate replication
> > because of
> > Invalid password, because the password for some reason does not
> > seem to
> > be being set.
> 
> Sorry, replication does not use the Directory Manager account. 
> Typically some type of "replication manager" entry is used, and in
> IPA
> I'm pretty sure this account uses kerberos credentials (not a
> password).
> 
> Going back to the Directory Manager   To confirm if the password
> is
> set, look in /etc/dirsv/slapd-INSTANCE/dse.ldif, and under cn=config
> look for "nsslapd-rootpw" if this attribute is missing then it truly
> is
> not set.  If your directory manager account does not have a password,
> or
> there is a password but you don't know what it is, then you can reset
> it
> following this doc:
> 
> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.htm
> l
> <http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.ht
> ml>
> 
> > Eric
> > 
> > 
> > -Original Message-
> > 
> > Date: Tue, 13 Jun 2017 09:49:40 -0400
> > Subject: [Freeipa-users] Re: replication problem
> > Cc: FreeIPA users list <freeipa-users@lists.fedorahosted.org>,
> > Adrian
> > HY <ayeja...@gmail.com>
> > To: Mark Reynolds <marey...@redhat.com>
> > Reply-to: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
> > From: Adrian HY via FreeIPA-users <freeipa-users@lists.fedorahosted
> > .org
> > Hi Mark, my problem is during the replica installation. I can't use
> > ldapmodify because cn=directory manager  does not have the password
> > assigned.
> > 
> > Regards.
> &

[Freeipa-users] Re: replication problem

2017-06-13 Thread Rob Crittenden via FreeIPA-users 
Eric Renfro via FreeIPA-users wrote:
> Hmmm..
> 
> Well, in my case specifically, the failed ipa-replica-install does in
> fact have the nsslapd-rootpw entry, however, changing this in a recovery
> process does no good during an ipa-replica-install.

I think this is a red herring. The client promotion code happened after
my time but I seem to recall that some magic happens regarding the DM
password so it isn't required during the install. I'm pretty sure that a
random one is set by the installer during initial configuration and at
the end it is replaced by the DM password in the master it is
replicating from.

So in other words it is expected to not match for some of the installation.

rob

> 
> Eric
> 
> -Original Message-
> 
> *Date*: Tue, 13 Jun 2017 10:51:13 -0400
> *Subject*: [Freeipa-users] Re: replication problem
> *Cc*: Eric Renfro <psi-j...@linux-help.org
> <mailto:eric%20renfro%20%3cpsi-j...@linux-help.org%3e>>, Adrian HY
> <ayeja...@gmail.com <mailto:adrian%20hy%20%3cayeja...@gmail.com%3e>>,
> Mark Reynolds <marey...@redhat.com
> <mailto:mark%20reynolds%20%3cmarey...@redhat.com%3e>>
> *To*: FreeIPA users list <freeipa-users@lists.fedorahosted.org
> <mailto:freeipa%20users%20list%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>
> Reply-to: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
> *From*: Mark Reynolds via FreeIPA-users
> <freeipa-users@lists.fedorahosted.org
> <mailto:mark%20reynolds%20via%20freeipa-users%20%3cfreeipa-us...@lists.fedorahosted.org%3e>>
> 
> 
> On 06/13/2017 10:34 AM, Eric Renfro via FreeIPA-users wrote:
>> Huh.. Well, who'da thunk it. I just literally reported the same kind of
>> trouble I was having, which looks like it matches this same situation,
>> with the ipa-replica-install failing to initiate replication because of
>> Invalid password, because the password for some reason does not seem to
>> be being set.
> Sorry, replication does not use the Directory Manager account. 
> Typically some type of "replication manager" entry is used, and in IPA
> I'm pretty sure this account uses kerberos credentials (not a password).
> 
> Going back to the Directory Manager   To confirm if the password is
> set, look in /etc/dirsv/slapd-INSTANCE/dse.ldif, and under cn=config
> look for "nsslapd-rootpw" if this attribute is missing then it truly is
> not set.  If your directory manager account does not have a password, or
> there is a password but you don't know what it is, then you can reset it
> following this doc:
> 
> http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
> <http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html>
> 
>> Eric
>>
>>
>> -Original Message-
>>
>> Date: Tue, 13 Jun 2017 09:49:40 -0400
>> Subject: [Freeipa-users] Re: replication problem
>> Cc: FreeIPA users list <freeipa-users@lists.fedorahosted.org>, Adrian
>> HY <ayeja...@gmail.com>
>> To: Mark Reynolds <marey...@redhat.com>
>> Reply-to: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
>> From: Adrian HY via FreeIPA-users <freeipa-users@lists.fedorahosted.org
>> Hi Mark, my problem is during the replica installation. I can't use
>> ldapmodify because cn=directory manager  does not have the password
>> assigned.
>>
>> Regards.
>>
>> On Mon, Jun 12, 2017 at 1:38 PM, Mark Reynolds <marey...@redhat.com>
>> wrote:
>>> On 06/11/2017 01:49 PM, Adrian HY via FreeIPA-users wrote:
>>>> I think I detected the problem. The error log in the replica
>>>> writes:
>>>>
>>>> [11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet length
>>>> exceeds maximum allowed limit (length=2483849, limit=2097152). 
>>>> Change the nsslapd-maxsasliosize attribute in cn=config to increase
>>>> limit.
>>>> [11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned
>>>>
>>>> According this: (https://access.redhat.com/documentation/en-US/Red_
>>>> Hat_Directory_Server/8.2/pdf/Configuration_and_Command-
>>>> Line_Tool_Reference/Red_Hat_Directory_Server-8.2-
>>>> Configuration_and_Command-Line_Tool_Reference-en-US.pdf)
>>>>
>>>> "When an incoming SASL IO packet is larger than the nsslapd-
>>>> maxsasliosize limit, the server  immediately disconnects the client
>>>> and logs a message to the error log, so that an administrator can
>>>> adjust the setting if necessary"
>>>>
>>>> The problem now is how can I change

[Freeipa-users] Re: replication problem

2017-06-13 Thread Eric Renfro via FreeIPA-users 
Hmmm..

Well, in my case specifically, the failed ipa-replica-install does in
fact have the nsslapd-rootpw entry, however, changing this in a
recovery process does no good during an ipa-replica-install.

Eric

-Original Message-

Date: Tue, 13 Jun 2017 10:51:13 -0400
Subject: [Freeipa-users] Re: replication problem
Cc: Eric Renfro <psi-j...@linux-help.org>, Adrian HY <ayeja...@gmail.co
m>, Mark Reynolds <marey...@redhat.com>
To: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
Reply-to: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
From: Mark Reynolds via FreeIPA-users <freeipa-users@lists.fedorahosted
.org>

  

  
  




On 06/13/2017 10:34 AM, Eric Renfro via
  FreeIPA-users wrote:




>   Huh.. Well, who'da thunk it. I just literally reported the same
> kind of
> trouble I was having, which looks like it matches this same
> situation,
> with the ipa-replica-install failing to initiate replication because
> of
> Invalid password, because the password for some reason does not seem
> to
> be being set.
> 

Sorry, replication does not use the Directory Manager account. 
Typically some type of "replication manager" entry is used, and in
IPA I'm pretty sure this account uses kerberos credentials (not a
password).



Going back to the Directory Manager   To confirm if the
password
is set, look in /etc/dirsv/slapd-INSTANCE/dse.ldif, and under
cn=config look for "nsslapd-rootpw" if this attribute is missing
then it truly is not set.  If your directory manager account does
not have a password, or there is a password but you don't know what
it is, then you can reset it following this doc:



http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.h
tml




>   
> Eric
> 
> 
> -Original Message-
> 
> Date: Tue, 13 Jun 2017 09:49:40 -0400
> Subject: [Freeipa-users] Re: replication problem
> Cc: FreeIPA users list <freeipa-users@lists.fedorahosted.org>, Adrian
> HY <ayeja...@gmail.com>
> To: Mark Reynolds <marey...@redhat.com>
> Reply-to: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
> From: Adrian HY via FreeIPA-users <freeipa-users@lists.fedorahosted.o
> rg
> 
>   
> > 
> >   
> 
>   Hi Mark, my problem is during the replica installation. I can't
> use
> ldapmodify because cn=directory manager  does not have the password
> assigned.
> 
> Regards.
> 
> On Mon, Jun 12, 2017 at 1:38 PM, Mark Reynolds <marey...@redhat.com>
> wrote:
> 
>   
> > On 06/11/2017 01:49 PM, Adrian HY via FreeIPA-users wrote:
> > 
> > 
> > >   I think I detected the problem. The error log in the
> > > replica
> > > writes:
> > > 
> > > [11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet
> > > length
> > > exceeds maximum allowed limit (length=2483849, limit=2097152). 
> > > Change the nsslapd-maxsasliosize attribute in cn=config to
> > > increase
> > > limit.
> > > [11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import
> > > abandoned
> > > 
> > > According this: (https://access.redhat.com/documentation/en-US/Re
> > > d_
> > > Hat_Directory_Server/8.2/pdf/Configuration_and_Command-
> > > Line_Tool_Reference/Red_Hat_Directory_Server-8.2-
> > > Configuration_and_Command-Line_Tool_Reference-en-US.pdf)
> > > 
> > > "When an incoming SASL IO packet is larger than the nsslapd-
> > > maxsasliosize limit, the server  immediately disconnects the
> > > client
> > > and logs a message to the error log, so that an administrator can
> > > adjust the setting if necessary"
> > > 
> > > The problem now is how can I change the value of the attribute
> > > during replication.
> > > 
> > > 
> > 
> >  You just use ldapmodify to change the value on each
> > replica:
> > 
> > # ldapmodify -D "cn=directory manager" -W
> > dn: cn=config
> > changetype: modify
> > replace: nsslapd-maxsasliosize
> > nsslapd-maxsasliosize:  YOUR_NEW_VALUE
> > 
> > 
> > 
> > >   Regards.
> > > 
> > > On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY <ayeja...@gmail.com>
> > > wrote:
> > > 
> > >   
> > > > Hi folks, I had a problem with replication and I
> > > > tried to add the
> > > > slave back to the replica. The process stops in the initial
> >

[Freeipa-users] Re: replication problem

2017-06-13 Thread Mark Reynolds via FreeIPA-users 


On 06/13/2017 10:34 AM, Eric Renfro via FreeIPA-users wrote:
> Huh.. Well, who'da thunk it. I just literally reported the same kind of
> trouble I was having, which looks like it matches this same situation,
> with the ipa-replica-install failing to initiate replication because of
> Invalid password, because the password for some reason does not seem to
> be being set.
Sorry, replication does not use the Directory Manager account. 
Typically some type of "replication manager" entry is used, and in IPA
I'm pretty sure this account uses kerberos credentials (not a password).

Going back to the Directory Manager   To confirm if the password is
set, look in /etc/dirsv/slapd-INSTANCE/dse.ldif, and under cn=config
look for "nsslapd-rootpw" if this attribute is missing then it truly is
not set.  If your directory manager account does not have a password, or
there is a password but you don't know what it is, then you can reset it
following this doc:

http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html
<http://www.port389.org/docs/389ds/howto/howto-resetdirmgrpassword.html>

>
> Eric
>
>
> -Original Message-
>
> Date: Tue, 13 Jun 2017 09:49:40 -0400
> Subject: [Freeipa-users] Re: replication problem
> Cc: FreeIPA users list <freeipa-users@lists.fedorahosted.org>, Adrian
> HY <ayeja...@gmail.com>
> To: Mark Reynolds <marey...@redhat.com>
> Reply-to: FreeIPA users list <freeipa-users@lists.fedorahosted.org>
> From: Adrian HY via FreeIPA-users <freeipa-users@lists.fedorahosted.org
> Hi Mark, my problem is during the replica installation. I can't use
> ldapmodify because cn=directory manager  does not have the password
> assigned.
>
> Regards.
>
> On Mon, Jun 12, 2017 at 1:38 PM, Mark Reynolds <marey...@redhat.com>
> wrote:
>> On 06/11/2017 01:49 PM, Adrian HY via FreeIPA-users wrote:
>>> I think I detected the problem. The error log in the replica
>>> writes:
>>>
>>> [11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet length
>>> exceeds maximum allowed limit (length=2483849, limit=2097152). 
>>> Change the nsslapd-maxsasliosize attribute in cn=config to increase
>>> limit.
>>> [11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned
>>>
>>> According this: (https://access.redhat.com/documentation/en-US/Red_
>>> Hat_Directory_Server/8.2/pdf/Configuration_and_Command-
>>> Line_Tool_Reference/Red_Hat_Directory_Server-8.2-
>>> Configuration_and_Command-Line_Tool_Reference-en-US.pdf)
>>>
>>> "When an incoming SASL IO packet is larger than the nsslapd-
>>> maxsasliosize limit, the server  immediately disconnects the client
>>> and logs a message to the error log, so that an administrator can
>>> adjust the setting if necessary"
>>>
>>> The problem now is how can I change the value of the attribute
>>> during replication.
>>  You just use ldapmodify to change the value on each replica:
>>
>> # ldapmodify -D "cn=directory manager" -W
>> dn: cn=config
>> changetype: modify
>> replace: nsslapd-maxsasliosize
>> nsslapd-maxsasliosize:  YOUR_NEW_VALUE
>>
>>> Regards.
>>>
>>> On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY <ayeja...@gmail.com>
>>> wrote:
>>>> Hi folks, I had a problem with replication and I tried to add the
>>>> slave back to the replica. The process stops in the initial
>>>> replication phase.
>>>>
>>>> The firewall and selinux are down and both servers are
>>>> synchronized with the time.
>>>>
>>>> Centos 7.3
>>>> Freeipa 4.4.0-14
>>>>
>>>> Master error log:
>>>>
>>>> 11/Jun/2017:01:11:45.690402715 -0400] NSMMReplicationPlugin -
>>>> agmt="cn=meTousuarios-replica.ipa.server.com" (usuarios-
>>>> replica:389): Replication bind with GSSAPI auth failed: LDAP
>>>> error 49 (Invalid credentials) ()
>>>> [11/Jun/2017:01:11:45.690877649 -0400] NSMMReplicationPlugin -
>>>> Warning: unable to acquire replica for total update, error: 49,
>>>> retrying in 1 seconds.
>>>> [11/Jun/2017:01:11:46.966060891 -0400] NSMMReplicationPlugin -
>>>> agmt="cn=meTousuarios-replica.ipa.server.com" (usuarios-
>>>> replica:389): Replication bind with GSSAPI auth resumed
>>>> [11/Jun/2017:01:11:47.095800971 -0400] NSMMReplicationPlugin -
>>>> Beginning total update of replica "agmt="cn=meTousuarios-
>>>> replica.ipa.server.com" (u

[Freeipa-users] Re: replication problem

2017-06-13 Thread Adrian HY via FreeIPA-users 
Hi Mark, my problem is during the replica installation. I can't use
ldapmodify because *cn=directory manager * does not have the password
assigned.

Regards.

On Mon, Jun 12, 2017 at 1:38 PM, Mark Reynolds  wrote:

>
>
> On 06/11/2017 01:49 PM, Adrian HY via FreeIPA-users wrote:
>
> I think I detected the problem. The error log in the replica writes:
>
> *[11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet length
> exceeds maximum allowed limit (length=2483849, limit=2097152).  Change the
> nsslapd-maxsasliosize attribute in cn=config to increase limit.*
>
> * [11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned *
> According this: (https://access.redhat.com/documentation/en-US/Red_Hat_
> Directory_Server/8.2/pdf/Configuration_and_Command-
> Line_Tool_Reference/Red_Hat_Directory_Server-8.2-
> Configuration_and_Command-Line_Tool_Reference-en-US.pdf)
>
> "When an incoming SASL IO packet is larger than the nsslapd-maxsasliosize
> limit, the server  immediately disconnects the client and logs a message to
> the error log, so that an administrator can adjust the setting if necessary"
>
> The problem now is how can I change the value of the attribute during
> replication.
>
> You just use ldapmodify to change the value on each replica:
>
> # ldapmodify -D "cn=directory manager" -W
> dn: cn=config
> changetype: modify
> replace: nsslapd-maxsasliosize
> nsslapd-maxsasliosize:  YOUR_NEW_VALUE
>
>
> Regards.
>
> On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY  wrote:
>
>> Hi folks, I had a problem with replication and I tried to add the slave
>> back to the replica. The process stops in the initial replication phase.
>>
>> The firewall and selinux are down and both servers are synchronized with
>> the time.
>>
>> Centos 7.3
>> Freeipa 4.4.0-14
>>
>> *Master error log:*
>>
>> 11/Jun/2017:01:11:45.690402715 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Replication
>> bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) ()
>> [11/Jun/2017:01:11:45.690877649 -0400] NSMMReplicationPlugin - Warning:
>> unable to acquire replica for total update, error: 49, retrying in 1
>> seconds.
>> [11/Jun/2017:01:11:46.966060891 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Replication
>> bind with GSSAPI auth resumed
>> [11/Jun/2017:01:11:47.095800971 -0400] NSMMReplicationPlugin - Beginning
>> total update of replica "agmt="cn=meTousuarios-replica.ipa.server.com"
>> (usuarios-replica:389)".
>> [11/Jun/2017:01:12:06.873713837 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Failed to
>> send extended operation: LDAP error -1 (Can't contact LDAP server)
>> [11/Jun/2017:01:12:06.874590112 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Received
>> error -1 (Can't contact LDAP server):  for total updat
>> e operation
>> [11/Jun/2017:01:12:06.874950648 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Warning:
>> unable to send endReplication extended operation (Can'
>> t contact LDAP server)
>> [11/Jun/2017:01:12:06.875217640 -0400] NSMMReplicationPlugin - Total
>> update failed for replica "agmt="cn=meTousuarios-replica.ipa.server.com"
>> (usuarios-replica:389)", error (-11)
>> [11/Jun/2017:01:12:06.894882383 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Replication
>> bind with GSSAPI auth resumed
>> [11/Jun/2017:01:12:06.905304992 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): The remote
>> replica has a different database generation ID than
>> the local database.  You may have to reinitialize the remote replica, or
>> the local replica.
>> [11/Jun/2017:01:12:09.912282245 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): The remote
>> replica has a different database generation ID than
>> the local database.  You may have to reinitialize the remote replica, or
>> the local replica.
>>
>> *Client ipareplica-install.log:*
>>
>> 2017-06-11T05:24:24Z DEBUG stderr=
>> 2017-06-11T05:24:24Z DEBUG wait_for_open_ports: localhost [389] timeout
>> 300
>> 2017-06-11T05:24:24Z DEBUG Fetching nsDS5ReplicaId from master [attempt
>> 1/5]
>> 2017-06-11T05:24:24Z DEBUG flushing ldap://usuarios.ipa.server.com:389
>> from SchemaCache
>> 2017-06-11T05:24:24Z DEBUG retrieving schema for SchemaCache url=ldap://
>> usuarios.ipa.server.com:389 conn=> instance at 0x86909e0>
>> 2017-06-11T05:24:24Z DEBUG Successfully updated nsDS5ReplicaId.
>> 2017-06-11T05:24:24Z DEBUG flushing 
>> ldapi://%2fvar%2frun%2fslapd-IPA.SERVER.COM.socket
>> from SchemaCache
>> 2017-06-11T05:24:24Z DEBUG retrieving schema for SchemaCache
>>

[Freeipa-users] Re: replication problem

2017-06-13 Thread Givaldo Lins via FreeIPA-users 
Could you inform OS, release, ipa-server version and domain level? 

Cheers, 

Givaldo Lins 

De: "Adrian HY" <ayeja...@gmail.com> 
Para: "FreeIPA users list" <freeipa-users@lists.fedorahosted.org> 
Cc: "Givaldo Lins" <giva...@lins.pro.br> 
Enviadas: Segunda-feira, 12 de junho de 2017 9:36:54 
Assunto: Re: [Freeipa-users] Re: replication problem 

Hi Givaldo, I tried to reinitialized the replica and I did not get results. 
On Mon, Jun 12, 2017 at 12:28 PM, Givaldo Lins via FreeIPA-users < 
freeipa-users@lists.fedorahosted.org > wrote: 



Hey Adrian, 

Not sure if it will resolve your problem, but have you tried to reinitialize 
the replica? 
You can run this on the replica: # ipa-replica-manage re-initialize --from= 
usuarios.ipa.server.com 

I hope this help you. 
Cheers, 

Givaldo Lins 

De: "Adrian HY via FreeIPA-users" < freeipa-users@lists.fedorahosted.org > 
Para: freeipa-users@lists.fedorahosted.org 
Cc: "Adrian HY" < ayeja...@gmail.com > 
Enviadas: Segunda-feira, 12 de junho de 2017 9:05:03 
Assunto: [Freeipa-users] Re: replication problem 

Hi everybody, any suggestions regarding this problem? 

On Sun, Jun 11, 2017 at 1:49 PM, Adrian HY < ayeja...@gmail.com > wrote: 

BQ_BEGIN

I think I detected the problem. The error log in the replica writes: 
[11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet length exceeds 
maximum allowed limit (length=2483849, limit=2097152). Change the 
nsslapd-maxsasliosize attribute in cn=config to increase limit. 
[11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned 
According this: ( 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/pdf/Configuration_and_Command-Line_Tool_Reference/Red_Hat_Directory_Server-8.2-Configuration_and_Command-Line_Tool_Reference-en-US.pdf
 ) 

"When an incoming SASL IO packet is larger than the nsslapd-maxsasliosize 
limit, the server immediately disconnects the client and logs a message to the 
error log, so that an administrator can adjust the setting if necessary" 

The problem now is how can I change the value of the attribute during 
replication. 

Regards. 

On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY < ayeja...@gmail.com > wrote: 

BQ_BEGIN

Hi folks, I had a problem with replication and I tried to add the slave back to 
the replica. The process stops in the initial replication phase. 
The firewall and selinux are down and both servers are synchronized with the 
time. 
Centos 7.3 
Freeipa 4.4.0-14 

Master error log: 

11/Jun/2017:01:11:45.690402715 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Replication bind 
with GSSAPI auth failed: LDAP error 49 (Invalid credentials) () 
[11/Jun/2017:01:11:45.690877649 -0400] NSMMReplicationPlugin - Warning: unable 
to acquire replica for total update, error: 49, retrying in 1 seconds. 
[11/Jun/2017:01:11:46.966060891 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Replication bind 
with GSSAPI auth resumed 
[11/Jun/2017:01:11:47.095800971 -0400] NSMMReplicationPlugin - Beginning total 
update of replica "agmt="cn= meTousuarios-replica.ipa.server.com " 
(usuarios-replica:389)". 
[11/Jun/2017:01:12:06.873713837 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Failed to send 
extended operation: LDAP error -1 (Can't contact LDAP server) 
[11/Jun/2017:01:12:06.874590112 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Received error -1 
(Can't contact LDAP server): for total updat 
e operation 
[11/Jun/2017:01:12:06.874950648 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Warning: unable 
to send endReplication extended operation (Can' 
t contact LDAP server) 
[11/Jun/2017:01:12:06.875217640 -0400] NSMMReplicationPlugin - Total update 
failed for replica "agmt="cn= meTousuarios-replica.ipa.server.com " 
(usuarios-replica:389)", error (-11) 
[11/Jun/2017:01:12:06.894882383 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Replication bind 
with GSSAPI auth resumed 
[11/Jun/2017:01:12:06.905304992 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): The remote 
replica has a different database generation ID than 
the local database. You may have to reinitialize the remote replica, or the 
local replica. 
[11/Jun/2017:01:12:09.912282245 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): The remote 
replica has a different database generation ID than 
the local database. You may have to reinitializ

[Freeipa-users] Re: replication problem

2017-06-12 Thread Mark Reynolds via FreeIPA-users 


On 06/11/2017 01:49 PM, Adrian HY via FreeIPA-users wrote:
> I think I detected the problem. The error log in the replica writes:
>
> *[11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet length
> exceeds maximum allowed limit (length=2483849, limit=2097152).  Change
> the nsslapd-maxsasliosize attribute in cn=config to increase limit.*
> *
> [11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned
>
> *
> According this:
> (https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/pdf/Configuration_and_Command-Line_Tool_Reference/Red_Hat_Directory_Server-8.2-Configuration_and_Command-Line_Tool_Reference-en-US.pdf)
>
> "When an incoming SASL IO packet is larger than the
> nsslapd-maxsasliosize limit, the server  immediately disconnects the
> client and logs a message to the error log, so that an administrator
> can adjust the setting if necessary"
>
> The problem now is how can I change the value of the attribute during
> replication.
You just use ldapmodify to change the value on each replica:

# ldapmodify -D "cn=directory manager" -W
dn: cn=config
changetype: modify
replace: nsslapd-maxsasliosize
nsslapd-maxsasliosize:  YOUR_NEW_VALUE

>
> Regards.
>
> On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY  > wrote:
>
> Hi folks, I had a problem with replication and I tried to add the
> slave back to the replica. The process stops in the initial
> replication phase.
>
> The firewall and selinux are down and both servers are
> synchronized with the time.
>
> Centos 7.3
> Freeipa 4.4.0-14
>
> *Master error log:*
>
> 11/Jun/2017:01:11:45.690402715 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Replication bind with GSSAPI auth failed:
> LDAP error 49 (Invalid credentials) ()
> [11/Jun/2017:01:11:45.690877649 -0400] NSMMReplicationPlugin -
> Warning: unable to acquire replica for total update, error: 49,
> retrying in 1 seconds.
> [11/Jun/2017:01:11:46.966060891 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Replication bind with GSSAPI auth resumed
> [11/Jun/2017:01:11:47.095800971 -0400] NSMMReplicationPlugin -
> Beginning total update of replica
> "agmt="cn=meTousuarios-replica.ipa.server.com
> " (usuarios-replica:389)".
> [11/Jun/2017:01:12:06.873713837 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Failed to send extended operation: LDAP
> error -1 (Can't contact LDAP server)
> [11/Jun/2017:01:12:06.874590112 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Received error -1 (Can't contact LDAP
> server):  for total updat
> e operation
> [11/Jun/2017:01:12:06.874950648 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Warning: unable to send endReplication
> extended operation (Can'
> t contact LDAP server)
> [11/Jun/2017:01:12:06.875217640 -0400] NSMMReplicationPlugin -
> Total update failed for replica
> "agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389)", error (-11)
> [11/Jun/2017:01:12:06.894882383 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): Replication bind with GSSAPI auth resumed
> [11/Jun/2017:01:12:06.905304992 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): The remote replica has a different
> database generation ID than
> the local database.  You may have to reinitialize the remote
> replica, or the local replica.
> [11/Jun/2017:01:12:09.912282245 -0400] NSMMReplicationPlugin -
> agmt="cn=meTousuarios-replica.ipa.server.com
> "
> (usuarios-replica:389): The remote replica has a different
> database generation ID than
> the local database.  You may have to reinitialize the remote
> replica, or the local replica.
>
> *Client ipareplica-install.log:*
>
> 2017-06-11T05:24:24Z DEBUG stderr=
> 2017-06-11T05:24:24Z DEBUG wait_for_open_ports: localhost [389]
> timeout 300
> 2017-06-11T05:24:24Z DEBUG Fetching nsDS5ReplicaId from master
> [attempt 1/5]
> 2017-06-11T05:24:24Z

[Freeipa-users] Re: replication problem

2017-06-12 Thread Givaldo Lins via FreeIPA-users 
Hey Adrian, 

Not sure if it will resolve your problem, but have you tried to reinitialize 
the replica? 
You can run this on the replica: # ipa-replica-manage re-initialize 
--from=usuarios.ipa.server.com 

I hope this help you. 
Cheers, 

Givaldo Lins 

De: "Adrian HY via FreeIPA-users" <freeipa-users@lists.fedorahosted.org> 
Para: freeipa-users@lists.fedorahosted.org 
Cc: "Adrian HY" <ayeja...@gmail.com> 
Enviadas: Segunda-feira, 12 de junho de 2017 9:05:03 
Assunto: [Freeipa-users] Re: replication problem 

Hi everybody, any suggestions regarding this problem? 

On Sun, Jun 11, 2017 at 1:49 PM, Adrian HY < ayeja...@gmail.com > wrote: 



I think I detected the problem. The error log in the replica writes: 
[11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet length exceeds 
maximum allowed limit (length=2483849, limit=2097152). Change the 
nsslapd-maxsasliosize attribute in cn=config to increase limit. 
[11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned 
According this: ( 
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/pdf/Configuration_and_Command-Line_Tool_Reference/Red_Hat_Directory_Server-8.2-Configuration_and_Command-Line_Tool_Reference-en-US.pdf
 ) 

"When an incoming SASL IO packet is larger than the nsslapd-maxsasliosize 
limit, the server immediately disconnects the client and logs a message to the 
error log, so that an administrator can adjust the setting if necessary" 

The problem now is how can I change the value of the attribute during 
replication. 

Regards. 

On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY < ayeja...@gmail.com > wrote: 

BQ_BEGIN

Hi folks, I had a problem with replication and I tried to add the slave back to 
the replica. The process stops in the initial replication phase. 
The firewall and selinux are down and both servers are synchronized with the 
time. 
Centos 7.3 
Freeipa 4.4.0-14 

Master error log: 

11/Jun/2017:01:11:45.690402715 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Replication bind 
with GSSAPI auth failed: LDAP error 49 (Invalid credentials) () 
[11/Jun/2017:01:11:45.690877649 -0400] NSMMReplicationPlugin - Warning: unable 
to acquire replica for total update, error: 49, retrying in 1 seconds. 
[11/Jun/2017:01:11:46.966060891 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Replication bind 
with GSSAPI auth resumed 
[11/Jun/2017:01:11:47.095800971 -0400] NSMMReplicationPlugin - Beginning total 
update of replica "agmt="cn= meTousuarios-replica.ipa.server.com " 
(usuarios-replica:389)". 
[11/Jun/2017:01:12:06.873713837 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Failed to send 
extended operation: LDAP error -1 (Can't contact LDAP server) 
[11/Jun/2017:01:12:06.874590112 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Received error -1 
(Can't contact LDAP server): for total updat 
e operation 
[11/Jun/2017:01:12:06.874950648 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Warning: unable 
to send endReplication extended operation (Can' 
t contact LDAP server) 
[11/Jun/2017:01:12:06.875217640 -0400] NSMMReplicationPlugin - Total update 
failed for replica "agmt="cn= meTousuarios-replica.ipa.server.com " 
(usuarios-replica:389)", error (-11) 
[11/Jun/2017:01:12:06.894882383 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): Replication bind 
with GSSAPI auth resumed 
[11/Jun/2017:01:12:06.905304992 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): The remote 
replica has a different database generation ID than 
the local database. You may have to reinitialize the remote replica, or the 
local replica. 
[11/Jun/2017:01:12:09.912282245 -0400] NSMMReplicationPlugin - agmt="cn= 
meTousuarios-replica.ipa.server.com " (usuarios-replica:389): The remote 
replica has a different database generation ID than 
the local database. You may have to reinitialize the remote replica, or the 
local replica. 

Client ipareplica-install.log: 

2017-06-11T05:24:24Z DEBUG stderr= 
2017-06-11T05:24:24Z DEBUG wait_for_open_ports: localhost [389] timeout 300 
2017-06-11T05:24:24Z DEBUG Fetching nsDS5ReplicaId from master [attempt 1/5] 
2017-06-11T05:24:24Z DEBUG flushing ldap:// usuarios.ipa.server.com:389 from 
SchemaCache 
2017-06-11T05:24:24Z DEBUG retrieving schema for SchemaCache url=ldap:// 
usuarios.ipa.server.com:389 conn= 
2017-06-11T05:24:24Z DEBUG Successfully updated nsDS5ReplicaId. 
2017-06-11T05:24:24Z DEBUG flushing 
ldapi://%2fvar%2frun%2fslapd-IPA.SERVER.

[Freeipa-users] Re: replication problem

2017-06-12 Thread Adrian HY via FreeIPA-users 
Hi everybody, any suggestions regarding this problem?

On Sun, Jun 11, 2017 at 1:49 PM, Adrian HY  wrote:

> I think I detected the problem. The error log in the replica writes:
>
> *[11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet length
> exceeds maximum allowed limit (length=2483849, limit=2097152).  Change the
> nsslapd-maxsasliosize attribute in cn=config to increase limit.*
>
> *[11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned*
> According this: (https://access.redhat.com/documentation/en-US/Red_Hat_
> Directory_Server/8.2/pdf/Configuration_and_Command-
> Line_Tool_Reference/Red_Hat_Directory_Server-8.2-
> Configuration_and_Command-Line_Tool_Reference-en-US.pdf)
>
> "When an incoming SASL IO packet is larger than the nsslapd-maxsasliosize
> limit, the server  immediately disconnects the client and logs a message to
> the error log, so that an administrator can adjust the setting if necessary"
>
> The problem now is how can I change the value of the attribute during
> replication.
>
> Regards.
>
> On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY  wrote:
>
>> Hi folks, I had a problem with replication and I tried to add the slave
>> back to the replica. The process stops in the initial replication phase.
>>
>> The firewall and selinux are down and both servers are synchronized with
>> the time.
>>
>> Centos 7.3
>> Freeipa 4.4.0-14
>>
>> *Master error log:*
>>
>> 11/Jun/2017:01:11:45.690402715 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Replication
>> bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) ()
>> [11/Jun/2017:01:11:45.690877649 -0400] NSMMReplicationPlugin - Warning:
>> unable to acquire replica for total update, error: 49, retrying in 1
>> seconds.
>> [11/Jun/2017:01:11:46.966060891 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Replication
>> bind with GSSAPI auth resumed
>> [11/Jun/2017:01:11:47.095800971 -0400] NSMMReplicationPlugin - Beginning
>> total update of replica "agmt="cn=meTousuarios-replica.ipa.server.com"
>> (usuarios-replica:389)".
>> [11/Jun/2017:01:12:06.873713837 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Failed to
>> send extended operation: LDAP error -1 (Can't contact LDAP server)
>> [11/Jun/2017:01:12:06.874590112 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Received
>> error -1 (Can't contact LDAP server):  for total updat
>> e operation
>> [11/Jun/2017:01:12:06.874950648 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Warning:
>> unable to send endReplication extended operation (Can'
>> t contact LDAP server)
>> [11/Jun/2017:01:12:06.875217640 -0400] NSMMReplicationPlugin - Total
>> update failed for replica "agmt="cn=meTousuarios-replica.ipa.server.com"
>> (usuarios-replica:389)", error (-11)
>> [11/Jun/2017:01:12:06.894882383 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Replication
>> bind with GSSAPI auth resumed
>> [11/Jun/2017:01:12:06.905304992 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): The remote
>> replica has a different database generation ID than
>> the local database.  You may have to reinitialize the remote replica, or
>> the local replica.
>> [11/Jun/2017:01:12:09.912282245 -0400] NSMMReplicationPlugin - agmt="cn=
>> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): The remote
>> replica has a different database generation ID than
>> the local database.  You may have to reinitialize the remote replica, or
>> the local replica.
>>
>> *Client ipareplica-install.log:*
>>
>> 2017-06-11T05:24:24Z DEBUG stderr=
>> 2017-06-11T05:24:24Z DEBUG wait_for_open_ports: localhost [389] timeout
>> 300
>> 2017-06-11T05:24:24Z DEBUG Fetching nsDS5ReplicaId from master [attempt
>> 1/5]
>> 2017-06-11T05:24:24Z DEBUG flushing ldap://usuarios.ipa.server.com:389
>> from SchemaCache
>> 2017-06-11T05:24:24Z DEBUG retrieving schema for SchemaCache url=ldap://
>> usuarios.ipa.server.com:389 conn=> instance at 0x86909e0>
>> 2017-06-11T05:24:24Z DEBUG Successfully updated nsDS5ReplicaId.
>> 2017-06-11T05:24:24Z DEBUG flushing 
>> ldapi://%2fvar%2frun%2fslapd-IPA.SERVER.COM.socket
>> from SchemaCache
>> 2017-06-11T05:24:24Z DEBUG retrieving schema for SchemaCache
>> url=ldapi://%2fvar%2frun%2fslapd-IPA.SERVER.COM.socket
>> conn=
>> 2017-06-11T05:24:46Z DEBUG Traceback (most recent call last):
>>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 449, in start_creation
>> run_step(full_msg, method)
>>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
>> line 439, in run_step
>> method()
>>   File

[Freeipa-users] Re: replication problem

2017-06-11 Thread Adrian HY via FreeIPA-users 
I think I detected the problem. The error log in the replica writes:

*[11/Jun/2017:13:36:06.360241021 -0400] SASL encrypted packet length
exceeds maximum allowed limit (length=2483849, limit=2097152).  Change the
nsslapd-maxsasliosize attribute in cn=config to increase limit.*

*[11/Jun/2017:13:36:06.361177815 -0400] ERROR bulk import abandoned*
According this: (
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/pdf/Configuration_and_Command-Line_Tool_Reference/Red_Hat_Directory_Server-8.2-Configuration_and_Command-Line_Tool_Reference-en-US.pdf
)

"When an incoming SASL IO packet is larger than the nsslapd-maxsasliosize
limit, the server  immediately disconnects the client and logs a message to
the error log, so that an administrator can adjust the setting if necessary"

The problem now is how can I change the value of the attribute during
replication.

Regards.

On Sun, Jun 11, 2017 at 2:20 AM, Adrian HY  wrote:

> Hi folks, I had a problem with replication and I tried to add the slave
> back to the replica. The process stops in the initial replication phase.
>
> The firewall and selinux are down and both servers are synchronized with
> the time.
>
> Centos 7.3
> Freeipa 4.4.0-14
>
> *Master error log:*
>
> 11/Jun/2017:01:11:45.690402715 -0400] NSMMReplicationPlugin - agmt="cn=
> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Replication
> bind with GSSAPI auth failed: LDAP error 49 (Invalid credentials) ()
> [11/Jun/2017:01:11:45.690877649 -0400] NSMMReplicationPlugin - Warning:
> unable to acquire replica for total update, error: 49, retrying in 1
> seconds.
> [11/Jun/2017:01:11:46.966060891 -0400] NSMMReplicationPlugin - agmt="cn=
> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Replication
> bind with GSSAPI auth resumed
> [11/Jun/2017:01:11:47.095800971 -0400] NSMMReplicationPlugin - Beginning
> total update of replica "agmt="cn=meTousuarios-replica.ipa.server.com"
> (usuarios-replica:389)".
> [11/Jun/2017:01:12:06.873713837 -0400] NSMMReplicationPlugin - agmt="cn=
> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Failed to
> send extended operation: LDAP error -1 (Can't contact LDAP server)
> [11/Jun/2017:01:12:06.874590112 -0400] NSMMReplicationPlugin - agmt="cn=
> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Received
> error -1 (Can't contact LDAP server):  for total updat
> e operation
> [11/Jun/2017:01:12:06.874950648 -0400] NSMMReplicationPlugin - agmt="cn=
> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Warning:
> unable to send endReplication extended operation (Can'
> t contact LDAP server)
> [11/Jun/2017:01:12:06.875217640 -0400] NSMMReplicationPlugin - Total
> update failed for replica "agmt="cn=meTousuarios-replica.ipa.server.com"
> (usuarios-replica:389)", error (-11)
> [11/Jun/2017:01:12:06.894882383 -0400] NSMMReplicationPlugin - agmt="cn=
> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): Replication
> bind with GSSAPI auth resumed
> [11/Jun/2017:01:12:06.905304992 -0400] NSMMReplicationPlugin - agmt="cn=
> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): The remote
> replica has a different database generation ID than
> the local database.  You may have to reinitialize the remote replica, or
> the local replica.
> [11/Jun/2017:01:12:09.912282245 -0400] NSMMReplicationPlugin - agmt="cn=
> meTousuarios-replica.ipa.server.com" (usuarios-replica:389): The remote
> replica has a different database generation ID than
> the local database.  You may have to reinitialize the remote replica, or
> the local replica.
>
> *Client ipareplica-install.log:*
>
> 2017-06-11T05:24:24Z DEBUG stderr=
> 2017-06-11T05:24:24Z DEBUG wait_for_open_ports: localhost [389] timeout 300
> 2017-06-11T05:24:24Z DEBUG Fetching nsDS5ReplicaId from master [attempt
> 1/5]
> 2017-06-11T05:24:24Z DEBUG flushing ldap://usuarios.ipa.server.com:389
> from SchemaCache
> 2017-06-11T05:24:24Z DEBUG retrieving schema for SchemaCache url=ldap://
> usuarios.ipa.server.com:389 conn= instance at 0x86909e0>
> 2017-06-11T05:24:24Z DEBUG Successfully updated nsDS5ReplicaId.
> 2017-06-11T05:24:24Z DEBUG flushing 
> ldapi://%2fvar%2frun%2fslapd-IPA.SERVER.COM.socket
> from SchemaCache
> 2017-06-11T05:24:24Z DEBUG retrieving schema for SchemaCache
> url=ldapi://%2fvar%2frun%2fslapd-IPA.SERVER.COM.socket
> conn=
> 2017-06-11T05:24:46Z DEBUG Traceback (most recent call last):
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 449, in start_creation
> run_step(full_msg, method)
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py",
> line 439, in run_step
> method()
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py",
> line 416, in __setup_replica
> repl.setup_promote_replication(self.master_fqdn)
>   File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
> line 1643, in setup_promote_replication
>