2:12 a.m.
Hi All,
I have configured two servers with multi master replication. Below is my
configuration for synrepl on both servers.
Server One
------------
serverID 001
overlay syncprov
syncprov-checkpoint 100 10
syncrepl rid=000
provider=ldap://192.168.10.100
type=refreshAndPersist
retry="5 5 300 +"
searchbase="dc=example,dc=com"
attrs="*,+"
bindmethod=simple
binddn="cn=syncuser,dc=example,dc=com"
credentials=password
mirrormode TRUE
Server Two
--------------
serverID 002
overlay syncprov
syncprov-checkpoint 100 10
syncrepl rid=000
provider=ldap://192.168.10.25
type=refreshAndPersist
retry="5 5 300 +"
searchbase="dc=example,dc=com"
attrs="*,+"
bindmethod=simple
binddn="cn=syncuser,dc=example,dc=com"
credentials=password
mirrormode TRUE
Today one of user said that he was not able to login. So i checked in the
servers in one server i was able to login but on another server i was not
able to login with the same password. I have checked the contextCSN on
both server they are equal. In the log it is showing this
syncrepl_entry: rid=000 entry unchanged, ignored
(uid=user,ou=People,dc=example,dc=com)
Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000
uid=user,ou=People,dc=example,dc=com
Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add
uid=user,ou=People,dc=example,dc=com (68)
Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have identical
CSN uid=user,ou=People,dc=example,dc=com
20100422132507.789242Z#000000#002#000000
Can anyone help me why above message is showing in the log files and why
the user is not able to login.
Rgds,
Aravind M D
9:40 a.m.
Hi Aravind,
did you copy over your /var/lib/ldap/* db-files from one node to the other?
Just a guess into the blue.
More information are neccessary.
Bye.
On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran <
aravind.divakaran(a)yukthi.com> wrote:
Hi All,
I have configured two servers with multi master replication. Below is my
configuration for synrepl on both servers.
Server One
------------
serverID 001
overlay syncprov
syncprov-checkpoint 100 10
syncrepl rid=000
provider=ldap://192.168.10.100
type=refreshAndPersist
retry="5 5 300 +"
searchbase="dc=example,dc=com"
attrs="*,+"
bindmethod=simple
binddn="cn=syncuser,dc=example,dc=com"
credentials=password
mirrormode TRUE
Server Two
--------------
serverID 002
overlay syncprov
syncprov-checkpoint 100 10
syncrepl rid=000
provider=ldap://192.168.10.25
type=refreshAndPersist
retry="5 5 300 +"
searchbase="dc=example,dc=com"
attrs="*,+"
bindmethod=simple
binddn="cn=syncuser,dc=example,dc=com"
credentials=password
mirrormode TRUE
Today one of user said that he was not able to login. So i checked in the
servers in one server i was able to login but on another server i was not
able to login with the same password. I have checked the contextCSN on
both server they are equal. In the log it is showing this
syncrepl_entry: rid=000 entry unchanged, ignored
(uid=user,ou=People,dc=example,dc=com)
Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000
uid=user,ou=People,dc=example,dc=com
Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add
uid=user,ou=People,dc=example,dc=com (68)
Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have identical
CSN uid=user,ou=People,dc=example,dc=com
20100422132507.789242Z#000000#002#000000
Can anyone help me why above message is showing in the log files and why
the user is not able to login.
Rgds,
Aravind M D
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is
to do -- Sartre | Do be do be do -- Sinatra
12:20 a.m.
Hi Benjamin,
I have copied the dit from one system to another using slapcat and
slapadd, because of the change in contextCSN. I have not copied the
database files.
Rgds,
Aravind M D
Hi Aravind,
did you copy over your /var/lib/ldap/* db-files from one node to the
other?
Just a guess into the blue.
More information are neccessary.
Bye.
On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran <
aravind.divakaran(a)yukthi.com> wrote:
> Hi All,
>
> I have configured two servers with multi master replication. Below is my
> configuration for synrepl on both servers.
>
> Server One
> ------------
>
> serverID 001
>
> overlay syncprov
> syncprov-checkpoint 100 10
>
> syncrepl rid=000
> provider=ldap://192.168.10.100
> type=refreshAndPersist
> retry="5 5 300 +"
> searchbase="dc=example,dc=com"
> attrs="*,+"
> bindmethod=simple
> binddn="cn=syncuser,dc=example,dc=com"
> credentials=password
>
> mirrormode TRUE
>
> Server Two
> --------------
>
> serverID 002
>
> overlay syncprov
> syncprov-checkpoint 100 10
>
> syncrepl rid=000
> provider=ldap://192.168.10.25
> type=refreshAndPersist
> retry="5 5 300 +"
> searchbase="dc=example,dc=com"
> attrs="*,+"
> bindmethod=simple
> binddn="cn=syncuser,dc=example,dc=com"
> credentials=password
>
> mirrormode TRUE
>
> Today one of user said that he was not able to login. So i checked in
> the
> servers in one server i was able to login but on another server i was
> not
> able to login with the same password. I have checked the contextCSN on
> both server they are equal. In the log it is showing this
>
> syncrepl_entry: rid=000 entry unchanged, ignored
> (uid=user,ou=People,dc=example,dc=com)
> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000
> uid=user,ou=People,dc=example,dc=com
> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add
> uid=user,ou=People,dc=example,dc=com (68)
> Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have identical
> CSN uid=user,ou=People,dc=example,dc=com
> 20100422132507.789242Z#000000#002#000000
>
> Can anyone help me why above message is showing in the log files and why
> the user is not able to login.
>
> Rgds,
>
> Aravind M D
>
>
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is
to do -- Sartre | Do be do be do -- Sinatra
8:51 a.m.
Hi,
thats pretty the same like copying the database. Because data and metadata
are completely copied over from one host to the other.
Please delete your db files completely on one master (backup first!) and let
it sync the files from the other one.
Good luck and have phun :)
Benjamin.
On Thu, Apr 29, 2010 at 09:20, Aravind Divakaran <
aravind.divakaran(a)yukthi.com> wrote:
Hi Benjamin,
I have copied the dit from one system to another using slapcat and
slapadd, because of the change in contextCSN. I have not copied the
database files.
Rgds,
Aravind M D
> Hi Aravind,
>
> did you copy over your /var/lib/ldap/* db-files from one node to the
> other?
> Just a guess into the blue.
>
> More information are neccessary.
>
> Bye.
>
> On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran <
> aravind.divakaran(a)yukthi.com> wrote:
>
>> Hi All,
>>
>> I have configured two servers with multi master replication. Below is my
>> configuration for synrepl on both servers.
>>
>> Server One
>> ------------
>>
>> serverID 001
>>
>> overlay syncprov
>> syncprov-checkpoint 100 10
>>
>> syncrepl rid=000
>> provider=ldap://192.168.10.100
>> type=refreshAndPersist
>> retry="5 5 300 +"
>> searchbase="dc=example,dc=com"
>> attrs="*,+"
>> bindmethod=simple
>> binddn="cn=syncuser,dc=example,dc=com"
>> credentials=password
>>
>> mirrormode TRUE
>>
>> Server Two
>> --------------
>>
>> serverID 002
>>
>> overlay syncprov
>> syncprov-checkpoint 100 10
>>
>> syncrepl rid=000
>> provider=ldap://192.168.10.25
>> type=refreshAndPersist
>> retry="5 5 300 +"
>> searchbase="dc=example,dc=com"
>> attrs="*,+"
>> bindmethod=simple
>> binddn="cn=syncuser,dc=example,dc=com"
>> credentials=password
>>
>> mirrormode TRUE
>>
>> Today one of user said that he was not able to login. So i checked in
>> the
>> servers in one server i was able to login but on another server i was
>> not
>> able to login with the same password. I have checked the contextCSN on
>> both server they are equal. In the log it is showing this
>>
>> syncrepl_entry: rid=000 entry unchanged, ignored
>> (uid=user,ou=People,dc=example,dc=com)
>> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000
>> uid=user,ou=People,dc=example,dc=com
>> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add
>> uid=user,ou=People,dc=example,dc=com (68)
>> Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have identical
>> CSN uid=user,ou=People,dc=example,dc=com
>> 20100422132507.789242Z#000000#002#000000
>>
>> Can anyone help me why above message is showing in the log files and why
>> the user is not able to login.
>>
>> Rgds,
>>
>> Aravind M D
>>
>>
>
>
> --
> To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be
is
> to do -- Sartre | Do be do be do -- Sinatra
>
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is
to do -- Sartre | Do be do be do -- Sinatra
4:06 a.m.
Hi
I have deleted the db from one server and synced the db from the other.
Now my contextCSN is same on both the system. But still in my log files it
showing
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0)
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
uid=user,ou=People,dc=example,dc=com
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128
20100610110242.236793Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa212db0 20100610110242.236793Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128
20100610110242.236793Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
sid 001
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa202b60 20100610110242.236793Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: do_syncrep2:
cookie=rid=000,sid=002,csn=20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 10 16:32:42 mails slapd[23253]: dn_callback : new entry is older than
ours uid=user,ou=People,dc=example,dc=com ours
20100610110242.266299Z#000000#001#000000, new
20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0)
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
uid=user,ou=People,dc=example,dc=com
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80
20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa1f8920 20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80
20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
sid 001
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa212e88 20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: do_syncrep2:
cookie=rid=000,sid=002,csn=20100610110242.266299Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 10 16:32:42 mails slapd[23253]: dn_callback : entries have identical
CSN uid=user,ou=People,dc=example,dc=com
20100610110242.266299Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0)
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
uid=sudhiryr,ou=People,dc=avasarala,dc=com
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878
20100610110242.266299Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa212cb8 20100610110242.266299Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878
20100610110242.266299Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
sid 001
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa0be008 20100610110242.266299Z#000000#001#000000
Why i am getting this error "dn_callback : entries have identical CSN"
Hi,
thats pretty the same like copying the database. Because data and metadata
are completely copied over from one host to the other.
Please delete your db files completely on one master (backup first!) and
let
it sync the files from the other one.
Good luck and have phun :)
Benjamin.
On Thu, Apr 29, 2010 at 09:20, Aravind Divakaran <
aravind.divakaran(a)yukthi.com> wrote:
> Hi Benjamin,
>
> I have copied the dit from one system to another using slapcat and
> slapadd, because of the change in contextCSN. I have not copied the
> database files.
>
>
> Rgds,
>
> Aravind M D
>
>
> > Hi Aravind,
> >
> > did you copy over your /var/lib/ldap/* db-files from one node to the
> > other?
> > Just a guess into the blue.
> >
> > More information are neccessary.
> >
> > Bye.
> >
> > On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran <
> > aravind.divakaran(a)yukthi.com> wrote:
> >
> >> Hi All,
> >>
> >> I have configured two servers with multi master replication. Below is
> my
> >> configuration for synrepl on both servers.
> >>
> >> Server One
> >> ------------
> >>
> >> serverID 001
> >>
> >> overlay syncprov
> >> syncprov-checkpoint 100 10
> >>
> >> syncrepl rid=000
> >> provider=ldap://192.168.10.100
> >> type=refreshAndPersist
> >> retry="5 5 300 +"
> >> searchbase="dc=example,dc=com"
> >> attrs="*,+"
> >> bindmethod=simple
> >> binddn="cn=syncuser,dc=example,dc=com"
> >> credentials=password
> >>
> >> mirrormode TRUE
> >>
> >> Server Two
> >> --------------
> >>
> >> serverID 002
> >>
> >> overlay syncprov
> >> syncprov-checkpoint 100 10
> >>
> >> syncrepl rid=000
> >> provider=ldap://192.168.10.25
> >> type=refreshAndPersist
> >> retry="5 5 300 +"
> >> searchbase="dc=example,dc=com"
> >> attrs="*,+"
> >> bindmethod=simple
> >> binddn="cn=syncuser,dc=example,dc=com"
> >> credentials=password
> >>
> >> mirrormode TRUE
> >>
> >> Today one of user said that he was not able to login. So i checked in
> >> the
> >> servers in one server i was able to login but on another server i was
> >> not
> >> able to login with the same password. I have checked the contextCSN
> on
> >> both server they are equal. In the log it is showing this
> >>
> >> syncrepl_entry: rid=000 entry unchanged, ignored
> >> (uid=user,ou=People,dc=example,dc=com)
> >> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000
> >> uid=user,ou=People,dc=example,dc=com
> >> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add
> >> uid=user,ou=People,dc=example,dc=com (68)
> >> Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have
> identical
> >> CSN uid=user,ou=People,dc=example,dc=com
> >> 20100422132507.789242Z#000000#002#000000
> >>
> >> Can anyone help me why above message is showing in the log files and
> why
> >> the user is not able to login.
> >>
> >> Rgds,
> >>
> >> Aravind M D
> >>
> >>
> >
> >
> > --
> > To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
> be
> is
> > to do -- Sartre | Do be do be do -- Sinatra
> >
>
>
>
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is
to do -- Sartre | Do be do be do -- Sinatra
Rgds,
Aravind M D
4:34 a.m.
Hey buddy,
havn't you seen some time around here.
I compared your slapd config to one of my own and to this one:
https://help.ubuntu.com/9.10/serverguide/C/openldap-server.html (see down at
"LDAP Replication")
From that point I see you're using the same rid for both servers,
so both
servers are in the ldap way are the "same" and that's a
problem because the
both DBs have to be unique even if they hold the same data.
Please consider to change the rid on one of your servers and repeat the step
to replicate the database.
Maybe rid=000 to rid=001.
Bye.
On Thu, Jun 10, 2010 at 13:06, Aravind Divakaran <
aravind.divakaran(a)yukthi.com> wrote:
Hi
I have deleted the db from one server and synced the db from the other.
Now my contextCSN is same on both the system. But still in my log files it
showing
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0)
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
uid=user,ou=People,dc=example,dc=com
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128
20100610110242.236793Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa212db0 20100610110242.236793Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128
20100610110242.236793Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
sid 001
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa202b60 20100610110242.236793Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: do_syncrep2:
cookie=rid=000,sid=002,csn=20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 10 16:32:42 mails slapd[23253]: dn_callback : new entry is older than
ours uid=user,ou=People,dc=example,dc=com ours
20100610110242.266299Z#000000#001#000000, new
20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0)
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
uid=user,ou=People,dc=example,dc=com
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80
20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa1f8920 20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80
20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
sid 001
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa212e88 20100610110242.255828Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: do_syncrep2:
cookie=rid=000,sid=002,csn=20100610110242.266299Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 10 16:32:42 mails slapd[23253]: dn_callback : entries have identical
CSN uid=user,ou=People,dc=example,dc=com
20100610110242.266299Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search (0)
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
uid=sudhiryr,ou=People,dc=avasarala,dc=com
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878
20100610110242.266299Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa212cb8 20100610110242.266299Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878
20100610110242.266299Z#000000#001#000000
Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
sid 001
Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
0xa0be008 20100610110242.266299Z#000000#001#000000
Why i am getting this error "dn_callback : entries have identical CSN"
> Hi,
> thats pretty the same like copying the database. Because data and
metadata
> are completely copied over from one host to the other.
> Please delete your db files completely on one master (backup first!) and
> let
> it sync the files from the other one.
>
> Good luck and have phun :)
>
> Benjamin.
>
> On Thu, Apr 29, 2010 at 09:20, Aravind Divakaran <
> aravind.divakaran(a)yukthi.com> wrote:
>
>> Hi Benjamin,
>>
>> I have copied the dit from one system to another using slapcat and
>> slapadd, because of the change in contextCSN. I have not copied the
>> database files.
>>
>>
>> Rgds,
>>
>> Aravind M D
>>
>>
>> > Hi Aravind,
>> >
>> > did you copy over your /var/lib/ldap/* db-files from one node to the
>> > other?
>> > Just a guess into the blue.
>> >
>> > More information are neccessary.
>> >
>> > Bye.
>> >
>> > On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran <
>> > aravind.divakaran(a)yukthi.com> wrote:
>> >
>> >> Hi All,
>> >>
>> >> I have configured two servers with multi master replication. Below is
>> my
>> >> configuration for synrepl on both servers.
>> >>
>> >> Server One
>> >> ------------
>> >>
>> >> serverID 001
>> >>
>> >> overlay syncprov
>> >> syncprov-checkpoint 100 10
>> >>
>> >> syncrepl rid=000
>> >> provider=ldap://192.168.10.100
>> >> type=refreshAndPersist
>> >> retry="5 5 300 +"
>> >> searchbase="dc=example,dc=com"
>> >> attrs="*,+"
>> >> bindmethod=simple
>> >> binddn="cn=syncuser,dc=example,dc=com"
>> >> credentials=password
>> >>
>> >> mirrormode TRUE
>> >>
>> >> Server Two
>> >> --------------
>> >>
>> >> serverID 002
>> >>
>> >> overlay syncprov
>> >> syncprov-checkpoint 100 10
>> >>
>> >> syncrepl rid=000
>> >> provider=ldap://192.168.10.25
>> >> type=refreshAndPersist
>> >> retry="5 5 300 +"
>> >> searchbase="dc=example,dc=com"
>> >> attrs="*,+"
>> >> bindmethod=simple
>> >> binddn="cn=syncuser,dc=example,dc=com"
>> >> credentials=password
>> >>
>> >> mirrormode TRUE
>> >>
>> >> Today one of user said that he was not able to login. So i checked in
>> >> the
>> >> servers in one server i was able to login but on another server i was
>> >> not
>> >> able to login with the same password. I have checked the contextCSN
>> on
>> >> both server they are equal. In the log it is showing this
>> >>
>> >> syncrepl_entry: rid=000 entry unchanged, ignored
>> >> (uid=user,ou=People,dc=example,dc=com)
>> >> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000
>> >> uid=user,ou=People,dc=example,dc=com
>> >> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add
>> >> uid=user,ou=People,dc=example,dc=com (68)
>> >> Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have
>> identical
>> >> CSN uid=user,ou=People,dc=example,dc=com
>> >> 20100422132507.789242Z#000000#002#000000
>> >>
>> >> Can anyone help me why above message is showing in the log files and
>> why
>> >> the user is not able to login.
>> >>
>> >> Rgds,
>> >>
>> >> Aravind M D
>> >>
>> >>
>> >
>> >
>> > --
>> > To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
>> be
>> is
>> > to do -- Sartre | Do be do be do -- Sinatra
>> >
>>
>>
>>
>
>
> --
> To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be
is
> to do -- Sartre | Do be do be do -- Sinatra
>
Rgds,
Aravind M D
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is
to do -- Sartre | Do be do be do -- Sinatra
5:58 a.m.
Hi,
Now i have changed the rid of one of my server, now both servers have
unique rid and sid. After changing the rid i have deleted and db and
replicated from the other. Now when i change the password of the user it
says successfully changed. But when i try to login with that password i
was not able to login. Below is my log files
Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0xb67cdbf2
20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing
0x9e513a0 20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: syncprov_sendresp: to=001,
cookie=rid=001,sid=001,csn=20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: do_syncrep2:
cookie=rid=000,sid=002,csn=20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 10 18:25:16 mails slapd[30896]: dn_callback : entries have identical
CSN uid=user,ou=People,dc=example,dc=com
20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 be_search (0)
Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000
uid=titus,ou=People,dc=avasarala,dc=com
Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0x9f92c48
20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 entry
unchanged, ignored (uid=titus,ou=People,dc=avasarala,dc=com)
Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing
0x9f93d68 20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0x9f92c48
20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: syncprov_matchops: skipping original
sid 001
Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing
0x9f94880 20100610125516.236254Z#000000#001#000000
Can you please help me why i was not able to login with the new password.
Hey buddy,
havn't you seen some time around here.
I compared your slapd config to one of my own and to this one:
https://help.ubuntu.com/9.10/serverguide/C/openldap-server.html (see down
at
"LDAP Replication")
From that point I see you're using the same rid for both servers, so both
servers are in the ldap way are the "same" and that's a problem because
the
both DBs have to be unique even if they hold the same data.
Please consider to change the rid on one of your servers and repeat the
step
to replicate the database.
Maybe rid=000 to rid=001.
Bye.
On Thu, Jun 10, 2010 at 13:06, Aravind Divakaran <
aravind.divakaran(a)yukthi.com> wrote:
> Hi
>
> I have deleted the db from one server and synced the db from the other.
> Now my contextCSN is same on both the system. But still in my log files
> it
> showing
>
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search
> (0)
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
> uid=user,ou=People,dc=example,dc=com
> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128
> 20100610110242.236793Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
> unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
> 0xa212db0 20100610110242.236793Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128
> 20100610110242.236793Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
> sid 001
> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
> 0xa202b60 20100610110242.236793Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: do_syncrep2:
> cookie=rid=000,sid=002,csn=20100610110242.255828Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
> Jun 10 16:32:42 mails slapd[23253]: dn_callback : new entry is older
> than
> ours uid=user,ou=People,dc=example,dc=com ours
> 20100610110242.266299Z#000000#001#000000, new
> 20100610110242.255828Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search
> (0)
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
> uid=user,ou=People,dc=example,dc=com
> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80
> 20100610110242.255828Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
> unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
> 0xa1f8920 20100610110242.255828Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80
> 20100610110242.255828Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
> sid 001
> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
> 0xa212e88 20100610110242.255828Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: do_syncrep2:
> cookie=rid=000,sid=002,csn=20100610110242.266299Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
> Jun 10 16:32:42 mails slapd[23253]: dn_callback : entries have identical
> CSN uid=user,ou=People,dc=example,dc=com
> 20100610110242.266299Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search
> (0)
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
> uid=sudhiryr,ou=People,dc=avasarala,dc=com
> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878
> 20100610110242.266299Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
> unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
> 0xa212cb8 20100610110242.266299Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878
> 20100610110242.266299Z#000000#001#000000
> Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
> sid 001
> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
> 0xa0be008 20100610110242.266299Z#000000#001#000000
>
> Why i am getting this error "dn_callback : entries have identical CSN"
>
>
> > Hi,
> > thats pretty the same like copying the database. Because data and
> metadata
> > are completely copied over from one host to the other.
> > Please delete your db files completely on one master (backup first!)
> and
> > let
> > it sync the files from the other one.
> >
> > Good luck and have phun :)
> >
> > Benjamin.
> >
> > On Thu, Apr 29, 2010 at 09:20, Aravind Divakaran <
> > aravind.divakaran(a)yukthi.com> wrote:
> >
> >> Hi Benjamin,
> >>
> >> I have copied the dit from one system to another using slapcat and
> >> slapadd, because of the change in contextCSN. I have not copied the
> >> database files.
> >>
> >>
> >> Rgds,
> >>
> >> Aravind M D
> >>
> >>
> >> > Hi Aravind,
> >> >
> >> > did you copy over your /var/lib/ldap/* db-files from one node to
> the
> >> > other?
> >> > Just a guess into the blue.
> >> >
> >> > More information are neccessary.
> >> >
> >> > Bye.
> >> >
> >> > On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran <
> >> > aravind.divakaran(a)yukthi.com> wrote:
> >> >
> >> >> Hi All,
> >> >>
> >> >> I have configured two servers with multi master replication. Below
> is
> >> my
> >> >> configuration for synrepl on both servers.
> >> >>
> >> >> Server One
> >> >> ------------
> >> >>
> >> >> serverID 001
> >> >>
> >> >> overlay syncprov
> >> >> syncprov-checkpoint 100 10
> >> >>
> >> >> syncrepl rid=000
> >> >> provider=ldap://192.168.10.100
> >> >> type=refreshAndPersist
> >> >> retry="5 5 300 +"
> >> >> searchbase="dc=example,dc=com"
> >> >> attrs="*,+"
> >> >> bindmethod=simple
> >> >> binddn="cn=syncuser,dc=example,dc=com"
> >> >> credentials=password
> >> >>
> >> >> mirrormode TRUE
> >> >>
> >> >> Server Two
> >> >> --------------
> >> >>
> >> >> serverID 002
> >> >>
> >> >> overlay syncprov
> >> >> syncprov-checkpoint 100 10
> >> >>
> >> >> syncrepl rid=000
> >> >> provider=ldap://192.168.10.25
> >> >> type=refreshAndPersist
> >> >> retry="5 5 300 +"
> >> >> searchbase="dc=example,dc=com"
> >> >> attrs="*,+"
> >> >> bindmethod=simple
> >> >> binddn="cn=syncuser,dc=example,dc=com"
> >> >> credentials=password
> >> >>
> >> >> mirrormode TRUE
> >> >>
> >> >> Today one of user said that he was not able to login. So i checked
> in
> >> >> the
> >> >> servers in one server i was able to login but on another server i
> was
> >> >> not
> >> >> able to login with the same password. I have checked the
> contextCSN
> >> on
> >> >> both server they are equal. In the log it is showing this
> >> >>
> >> >> syncrepl_entry: rid=000 entry unchanged, ignored
> >> >> (uid=user,ou=People,dc=example,dc=com)
> >> >> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000
> >> >> uid=user,ou=People,dc=example,dc=com
> >> >> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000 be_add
> >> >> uid=user,ou=People,dc=example,dc=com (68)
> >> >> Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries have
> >> identical
> >> >> CSN uid=user,ou=People,dc=example,dc=com
> >> >> 20100422132507.789242Z#000000#002#000000
> >> >>
> >> >> Can anyone help me why above message is showing in the log files
> and
> >> why
> >> >> the user is not able to login.
> >> >>
> >> >> Rgds,
> >> >>
> >> >> Aravind M D
> >> >>
> >> >>
> >> >
> >> >
> >> > --
> >> > To be or not to be -- Shakespeare | To do is to be -- Nietzsche |
> To
> >> be
> >> is
> >> > to do -- Sartre | Do be do be do -- Sinatra
> >> >
> >>
> >>
> >>
> >
> >
> > --
> > To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
> be
> is
> > to do -- Sartre | Do be do be do -- Sinatra
> >
>
>
> Rgds,
>
> Aravind M D
>
>
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is
to do -- Sartre | Do be do be do -- Sinatra
Rgds,
Aravind M D
6:35 a.m.
Hi,
I have no clue what the problem is in your configuration.
Did you really started with a blank backend database (bdb/hdb)?
Did you read about the differences of replication type "RefreshOnly" or
"RefreshAndPersist"?
Try to avoid changing replication settings while both hosts are replicating,
this could have a strange impact on your database.
Bye and good luck.
On Thu, Jun 10, 2010 at 14:58, Aravind Divakaran <
aravind.divakaran(a)yukthi.com> wrote:
Hi,
Now i have changed the rid of one of my server, now both servers have
unique rid and sid. After changing the rid i have deleted and db and
replicated from the other. Now when i change the password of the user it
says successfully changed. But when i try to login with that password i
was not able to login. Below is my log files
Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0xb67cdbf2
20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing
0x9e513a0 20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: syncprov_sendresp: to=001,
cookie=rid=001,sid=001,csn=20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: do_syncrep2:
cookie=rid=000,sid=002,csn=20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Jun 10 18:25:16 mails slapd[30896]: dn_callback : entries have identical
CSN uid=user,ou=People,dc=example,dc=com
20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 be_search (0)
Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000
uid=titus,ou=People,dc=avasarala,dc=com
Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0x9f92c48
20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: syncrepl_entry: rid=000 entry
unchanged, ignored (uid=titus,ou=People,dc=avasarala,dc=com)
Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing
0x9f93d68 20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: slap_queue_csn: queing 0x9f92c48
20100610125516.236254Z#000000#001#000000
Jun 10 18:25:16 mails slapd[30896]: syncprov_matchops: skipping original
sid 001
Jun 10 18:25:16 mails slapd[30896]: slap_graduate_commit_csn: removing
0x9f94880 20100610125516.236254Z#000000#001#000000
Can you please help me why i was not able to login with the new password.
> Hey buddy,
>
> havn't you seen some time around here.
>
> I compared your slapd config to one of my own and to this one:
> https://help.ubuntu.com/9.10/serverguide/C/openldap-server.html (see
down
> at
> "LDAP Replication")
>
> From that point I see you're using the same rid for both servers, so both
> servers are in the ldap way are the "same" and that's a problem
because
> the
> both DBs have to be unique even if they hold the same data.
> Please consider to change the rid on one of your servers and repeat the
> step
> to replicate the database.
> Maybe rid=000 to rid=001.
>
> Bye.
>
> On Thu, Jun 10, 2010 at 13:06, Aravind Divakaran <
> aravind.divakaran(a)yukthi.com> wrote:
>
>> Hi
>>
>> I have deleted the db from one server and synced the db from the other.
>> Now my contextCSN is same on both the system. But still in my log files
>> it
>> showing
>>
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search
>> (0)
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
>> uid=user,ou=People,dc=example,dc=com
>> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128
>> 20100610110242.236793Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
>> unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
>> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
>> 0xa212db0 20100610110242.236793Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa200128
>> 20100610110242.236793Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
>> sid 001
>> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
>> 0xa202b60 20100610110242.236793Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: do_syncrep2:
>> cookie=rid=000,sid=002,csn=20100610110242.255828Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
>> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
>> Jun 10 16:32:42 mails slapd[23253]: dn_callback : new entry is older
>> than
>> ours uid=user,ou=People,dc=example,dc=com ours
>> 20100610110242.266299Z#000000#001#000000, new
>> 20100610110242.255828Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search
>> (0)
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
>> uid=user,ou=People,dc=example,dc=com
>> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80
>> 20100610110242.255828Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
>> unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
>> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
>> 0xa1f8920 20100610110242.255828Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa1fde80
>> 20100610110242.255828Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
>> sid 001
>> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
>> 0xa212e88 20100610110242.255828Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: do_syncrep2:
>> cookie=rid=000,sid=002,csn=20100610110242.266299Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
>> LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
>> Jun 10 16:32:42 mails slapd[23253]: dn_callback : entries have identical
>> CSN uid=user,ou=People,dc=example,dc=com
>> 20100610110242.266299Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 be_search
>> (0)
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000
>> uid=sudhiryr,ou=People,dc=avasarala,dc=com
>> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878
>> 20100610110242.266299Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: syncrepl_entry: rid=000 entry
>> unchanged, ignored (uid=user,ou=People,dc=example,dc=com)
>> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
>> 0xa212cb8 20100610110242.266299Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: slap_queue_csn: queing 0xa20e878
>> 20100610110242.266299Z#000000#001#000000
>> Jun 10 16:32:42 mails slapd[23253]: syncprov_matchops: skipping original
>> sid 001
>> Jun 10 16:32:42 mails slapd[23253]: slap_graduate_commit_csn: removing
>> 0xa0be008 20100610110242.266299Z#000000#001#000000
>>
>> Why i am getting this error "dn_callback : entries have identical
CSN"
>>
>>
>> > Hi,
>> > thats pretty the same like copying the database. Because data and
>> metadata
>> > are completely copied over from one host to the other.
>> > Please delete your db files completely on one master (backup first!)
>> and
>> > let
>> > it sync the files from the other one.
>> >
>> > Good luck and have phun :)
>> >
>> > Benjamin.
>> >
>> > On Thu, Apr 29, 2010 at 09:20, Aravind Divakaran <
>> > aravind.divakaran(a)yukthi.com> wrote:
>> >
>> >> Hi Benjamin,
>> >>
>> >> I have copied the dit from one system to another using slapcat and
>> >> slapadd, because of the change in contextCSN. I have not copied the
>> >> database files.
>> >>
>> >>
>> >> Rgds,
>> >>
>> >> Aravind M D
>> >>
>> >>
>> >> > Hi Aravind,
>> >> >
>> >> > did you copy over your /var/lib/ldap/* db-files from one node to
>> the
>> >> > other?
>> >> > Just a guess into the blue.
>> >> >
>> >> > More information are neccessary.
>> >> >
>> >> > Bye.
>> >> >
>> >> > On Wed, Apr 28, 2010 at 11:12, Aravind Divakaran <
>> >> > aravind.divakaran(a)yukthi.com> wrote:
>> >> >
>> >> >> Hi All,
>> >> >>
>> >> >> I have configured two servers with multi master replication.
Below
>> is
>> >> my
>> >> >> configuration for synrepl on both servers.
>> >> >>
>> >> >> Server One
>> >> >> ------------
>> >> >>
>> >> >> serverID 001
>> >> >>
>> >> >> overlay syncprov
>> >> >> syncprov-checkpoint 100 10
>> >> >>
>> >> >> syncrepl rid=000
>> >> >> provider=ldap://192.168.10.100
>> >> >> type=refreshAndPersist
>> >> >> retry="5 5 300 +"
>> >> >> searchbase="dc=example,dc=com"
>> >> >> attrs="*,+"
>> >> >> bindmethod=simple
>> >> >> binddn="cn=syncuser,dc=example,dc=com"
>> >> >> credentials=password
>> >> >>
>> >> >> mirrormode TRUE
>> >> >>
>> >> >> Server Two
>> >> >> --------------
>> >> >>
>> >> >> serverID 002
>> >> >>
>> >> >> overlay syncprov
>> >> >> syncprov-checkpoint 100 10
>> >> >>
>> >> >> syncrepl rid=000
>> >> >> provider=ldap://192.168.10.25
>> >> >> type=refreshAndPersist
>> >> >> retry="5 5 300 +"
>> >> >> searchbase="dc=example,dc=com"
>> >> >> attrs="*,+"
>> >> >> bindmethod=simple
>> >> >> binddn="cn=syncuser,dc=example,dc=com"
>> >> >> credentials=password
>> >> >>
>> >> >> mirrormode TRUE
>> >> >>
>> >> >> Today one of user said that he was not able to login. So i
checked
>> in
>> >> >> the
>> >> >> servers in one server i was able to login but on another
server i
>> was
>> >> >> not
>> >> >> able to login with the same password. I have checked the
>> contextCSN
>> >> on
>> >> >> both server they are equal. In the log it is showing this
>> >> >>
>> >> >> syncrepl_entry: rid=000 entry unchanged, ignored
>> >> >> (uid=user,ou=People,dc=example,dc=com)
>> >> >> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000
>> >> >> uid=user,ou=People,dc=example,dc=com
>> >> >> Apr 28 12:14:17 mails slapd[16595]: syncrepl_entry: rid=000
be_add
>> >> >> uid=user,ou=People,dc=example,dc=com (68)
>> >> >> Apr 28 12:14:17 mails slapd[16595]: dn_callback : entries
have
>> >> identical
>> >> >> CSN uid=user,ou=People,dc=example,dc=com
>> >> >> 20100422132507.789242Z#000000#002#000000
>> >> >>
>> >> >> Can anyone help me why above message is showing in the log
files
>> and
>> >> why
>> >> >> the user is not able to login.
>> >> >>
>> >> >> Rgds,
>> >> >>
>> >> >> Aravind M D
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >> > --
>> >> > To be or not to be -- Shakespeare | To do is to be -- Nietzsche |
>> To
>> >> be
>> >> is
>> >> > to do -- Sartre | Do be do be do -- Sinatra
>> >> >
>> >>
>> >>
>> >>
>> >
>> >
>> > --
>> > To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To
>> be
>> is
>> > to do -- Sartre | Do be do be do -- Sinatra
>> >
>>
>>
>> Rgds,
>>
>> Aravind M D
>>
>>
>
>
> --
> To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be
is
> to do -- Sartre | Do be do be do -- Sinatra
>
Rgds,
Aravind M D
--
To be or not to be -- Shakespeare | To do is to be -- Nietzsche | To be is
to do -- Sartre | Do be do be do -- Sinatra
9:03 a.m.
New subject: Posix group with /etc/ldap.conf read priv
I don't like having the /etc/ldap.conf world readable because then anyone who has
shell access can see our general ldap login credentials (without which you cannot see
anything in the ldap tree). So I have added a posixgroup in ldap, added our shell users
to it and did:
chown root:usergroup /etc/ldap.conf && chmod 640 /etc/ldap.conf
But when logging in to the shell, users still get the "I have no name!" problem
because they cannot read the /etc/ldap.conf and cannot map their uid / guid numbers to
names from the ldap tree.
Advice?
10:33 a.m.
New subject: Posix group with /etc/ldap.conf read priv
On Mon, 14 Jun 2010, Ariel wrote:
I don't like having the /etc/ldap.conf world readable [...]
Advice?
And you didn't chmod /etc/passwd and /etc/group too? What if people get
valuable information out of those? You can't do this and be POSIX
multi-user; getgr*/getpw* are unprivileged operations. Your users should
be able to get some output with getent(1), and your users should be able
to get the same output with "cat /etc/ldap.conf" and a bit of thought, and
any attempts to make that harder will be a waste of time on your part.
Change back the permissions, or change your OS.
Now, with all this said, if your users can get *more* information with
"cat /etc/ldap.conf" and thought than getent(1) provides, that may well be
a configuration error on your part, which would be appropriate to discuss
on this list...
2:53 p.m.
New subject: Posix group with /etc/ldap.conf read priv
On Monday, 14 June 2010 17:03:29 Ariel wrote:
I don't like having the /etc/ldap.conf world readable because
then anyone
who has shell access can see our general ldap login credentials (without
which you cannot see anything in the ldap tree). So I have added a
posixgroup in ldap, added our shell users to it and did:
chown root:usergroup /etc/ldap.conf && chmod 640 /etc/ldap.conf
But when logging in to the shell, users still get the "I have no name!"
problem because they cannot read the /etc/ldap.conf and cannot map their
uid / guid numbers to names from the ldap tree.
Advice?
nss_ldap already caters to this, by the 'rootbinddn' option, and the
/etc/ldap.secret file. If rootbinddn is used, then process which are running as
root use this DN, and the password from the /etc/ldap.secret file (which can
thus be protected from non-root users).
In order to make effective use of this, you probably need to run nscd (as root,
thus it is able to contact the LDAP server as rootbinddn).
Of course, you need to consider:
1)The fact that users who would have access to credentials already have access
to the information you are trying to protect
2)The identity you use for nss_ldap should be least-privilege in any case
Finally, you may also want to consider per-host credentials ... easiest in a
Kerberos environment.
Did you read the nss_ldap documentation?
(Aaron already replied, but the fact that nss_ldap supports what you wanted
originally was not covered).
Regards,
Buchan
1:01 a.m.
New subject: Posix group with /etc/ldap.conf read priv
Buchan Milne wrote:
On Monday, 14 June 2010 17:03:29 Ariel wrote:
> I don't like having the /etc/ldap.conf world readable because then anyone
> who has shell access can see our general ldap login credentials (without
> which you cannot see anything in the ldap tree). So I have added a
> posixgroup in ldap, added our shell users to it and did:
>
> chown root:usergroup /etc/ldap.conf && chmod 640 /etc/ldap.conf
>
> But when logging in to the shell, users still get the "I have no name!"
> problem because they cannot read the /etc/ldap.conf and cannot map their
> uid / guid numbers to names from the ldap tree.
>
> Advice?
>
nss_ldap already caters to this, by the 'rootbinddn' option, and the
/etc/ldap.secret file. If rootbinddn is used, then process which are running as
root use this DN, and the password from the /etc/ldap.secret file (which can
thus be protected from non-root users).
The rootbinddn is just usefull/used in case of privileged (e.g. password
reset by root) operations (which is normally done by root) therefore the
file system permissions of /etc/ldap.secret can (should!) be protected.
rootbinddn and /etc/ldap.secret have no effect on standard nss
operations invoked by unprivileged users.
In order to make effective use of this, you probably need to run nscd
(as root,
thus it is able to contact the LDAP server as rootbinddn).
Of course, you need to consider:
1)The fact that users who would have access to credentials already have access
to the information you are trying to protect
2)The identity you use for nss_ldap should be least-privilege in any case
I've a question in regard to the exactly representation of
"least-privilege" (hardening of slapd) to operate with nss_ldap. But
first let me try to summarize my investigations:
The problem I see is that [nss|pam]_ldap's configuration file
/etc/ldap.conf needs to be world readable to support a directory listing
like for example "ls -al /home" wherein all the uidNumbers get resolved
into names (uid/cn).
In my opinion there are two kind of approaches in regard to slapd's
privilege configuration (ACLs) which both result in nearly the same
behavior:
1.) don't use a bindDn in /etc/ldap.conf and allow anonymous read in
slapd (limited to posix account objectClass' attributes)
2.) use a bindDn in /etc/ldap.conf which also requires a "bindPw". Thus
/etc/ldap.conf needs to be world readable this approach also results in
some kind of "quasi-anonymous" access (in case a logged in user uses the
bindDn/bindPw for his own experiments ;-))
To limit the possible side-effects (information disclosure) slapd's ACL
settings need to be very restrictive but there are not many
possibilities to further restrict queries without "damaging" the
standard nss behavior (e.g. resolving uidNumber and so on).
Even in case the ACLs are strictly limited to deliver only
posixAccount/shadowAccount relevant attributes, in most commonly ldap
driven environments the nss|pam_ldap deployments disclose more security
relevant information than the previous (non-ldap) /etc/passwd
/etc/shadow approach:
Regardless whether approach 1.) or 2.) (which you are forced to in case
your directory does not support anonymous binds - e.g. MS AD) is
deployed a simple ldapsearch (anonymous or by use of bindDn/bindPw)
delivers the /etc/passwd similar content to satisfy/achieve the unix
system's standard nss behavior:
"user:uidNumber:gidNumer:gecos: ...."
That's fine, but how about ldapsearch "+" (querying for operational
attributes)?
By querying the operational attributes any interested user could get for
example "helpful" additional information in comparison to /etc/passwd to
narrow valuable attacks:
- createTimestamp could be a good indicator for "old" and might be
higher privileged users?
- modifyTimestamp could be used to identify users who have not changed
their passwords for years...
- and many more ideas regarding the other operational attributes
Summary: In my opinion the only (theoretical?) chance left to further
"harden" nss|pam_ldap deployments (by further restricting slapd's ACLs)
is to suppress delivery of some operational attributes (for the
nss|pam_ldap's proxy-user bindDn!) to a minimum.
I've (just for fun) already experimented with this. And all I can say
nss|pam_ldap and slapd are still working fine but - and now let me come
to the question:
I'm completely unsure whether suppressing operational attributes could
harm slapd's internal operations in any kind? Ok thinking of denying
contextCSN in replicated environments - hehe - the answer seems clear to
me but what about the entryDN, hasSubordinates, and all the others...
are they needed by slapd to operate correctly (possibly the operational
attributes need is backend depending)?
Finally, you may also want to consider per-host credentials ...
easiest in a
Kerberos environment.
Using sasl external or kerberos in combination with nss|pam_ldap's
/etc/ldap.conf does not seem to improve security: the certificate's key
needs to be world readable so any interested user can take the key and
the certificate to bind "-Y EXTERNAL" to investigate the posixAccount
users (and - I'm not sure - the same should apply to kerberos
system/server tickets which needs to be world readable, too).
Did you read the nss_ldap documentation?
(Aaron already replied, but the fact that nss_ldap supports what you wanted
originally was not covered).
In my opinion that's not sure.
BTW and in regard to the "just for fun section", mentioned above:
nss|pam_ldap has obvious design deficits therefore "nss_ldapd" has been
developed and the related "slapo-nssov" is currently in development.
These two approaches represent another level of indirection and seem to
solve the above described general problems regarding the
"quasi-anonymous" access because the nss part can be run in privileged
user context where the bindDn/bindPw is probably kept more secure.
nss_ldapd seems to be quite stable. nssov is in the contrib branch of
slapd and need to be compiled manually. Possibly one should give them a
try instead of betting on a dead horse (nss_ldap)...
3:19 a.m.
New subject: Posix group with /etc/ldap.conf read priv
On Tuesday, 15 June 2010 09:01:13 Daniel wrote:
Buchan Milne wrote:
> On Monday, 14 June 2010 17:03:29 Ariel wrote:
>> I don't like having the /etc/ldap.conf world readable because then
>> anyone who has shell access can see our general ldap login credentials
>> (without which you cannot see anything in the ldap tree). So I have
>> added a posixgroup in ldap, added our shell users to it and did:
>>
>> chown root:usergroup /etc/ldap.conf && chmod 640 /etc/ldap.conf
>>
>> But when logging in to the shell, users still get the "I have no
name!"
>> problem because they cannot read the /etc/ldap.conf and cannot map
>> their uid / guid numbers to names from the ldap tree.
>>
>> Advice?
>
> nss_ldap already caters to this, by the 'rootbinddn' option, and the
> /etc/ldap.secret file. If rootbinddn is used, then process which are
> running as root use this DN, and the password from the /etc/ldap.secret
> file (which can thus be protected from non-root users).
The rootbinddn is just usefull/used in case of privileged (e.g. password
reset by root) operations (which is normally done by root) therefore the
file system permissions of /etc/ldap.secret can (should!) be protected.
No, this is not the only reason for the rootbindd option. In this case, I have
no binddn/bindpw (I usually use SASL):
Without rootbinddn, getent passwd as root:
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 fd=34 ACCEPT from
IP=127.0.0.1:58579 (IP=0.0.0.0:389)
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=0 BIND dn="" method=128
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=0 RESULT tag=97 err=0 text=
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=1 SRCH
base="dc=ranger,dc=dnsalias,dc=com" scope=2 deref=0
filter="(objectClass=posixAccount)"
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=1 SRCH attr=uid userPassword
uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 op=1 SEARCH RESULT tag=101 err=0
nentries=32 text=
Jun 15 11:06:02 tiger slapd[4884]: conn=3144 fd=34 closed (connection lost)
With rootbinddn, getent passwd as root:
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 fd=35 ACCEPT from
IP=127.0.0.1:37331 (IP=0.0.0.0:389)
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=0 BIND dn="uid=LDAP
Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com" method=128
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=0 BIND dn="uid=LDAP
Admin,ou=System Accounts,dc=ranger,dc=dnsalias,dc=com" mech=SIMPLE ssf=0
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=0 RESULT tag=97 err=0 text=
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=1 SRCH
base="dc=ranger,dc=dnsalias,dc=com" scope=2 deref=0
filter="(objectClass=posixAccount)"
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=1 SRCH attr=uid userPassword
uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 op=1 SEARCH RESULT tag=101 err=0
nentries=32 text=
Jun 15 11:02:01 tiger slapd[4884]: conn=3140 fd=35 closed (connection lost)
rootbinddn and /etc/ldap.secret have no effect on standard nss
operations invoked by unprivileged users.
Sure, but it *does* have an effect on any nss operations by a process running
as root.
> In order to make effective use of this, you probably need to run
nscd (as
> root, thus it is able to contact the LDAP server as rootbinddn).
>
> Of course, you need to consider:
> 1)The fact that users who would have access to credentials already have
> access to the information you are trying to protect
> 2)The identity you use for nss_ldap should be least-privilege in any case
I've a question in regard to the exactly representation of
"least-privilege" (hardening of slapd) to operate with nss_ldap. But
first let me try to summarize my investigations:
The problem I see is that [nss|pam]_ldap's configuration file
/etc/ldap.conf needs to be world readable to support a directory listing
like for example "ls -al /home" wherein all the uidNumbers get resolved
into names (uid/cn).
By design, it should be world readable. If you want credentials to be
protected, use rootbinddn and /etc/ldap.secret, and e.g. nscd to ensure
lookups end up being done by root.
In my opinion there are two kind of approaches in regard to
slapd's
privilege configuration (ACLs) which both result in nearly the same
behavior:
1.) don't use a bindDn in /etc/ldap.conf and allow anonymous read in
slapd (limited to posix account objectClass' attributes)
2.) use a bindDn in /etc/ldap.conf which also requires a "bindPw". Thus
/etc/ldap.conf needs to be world readable this approach also results in
some kind of "quasi-anonymous" access (in case a logged in user uses the
bindDn/bindPw for his own experiments ;-))
3)Use rootbinddn and /etc/ldap.secret with nscd or similar, with or without
binddn/bindpw.
To limit the possible side-effects (information disclosure)
slapd's ACL
settings need to be very restrictive but there are not many
possibilities to further restrict queries without "damaging" the
standard nss behavior (e.g. resolving uidNumber and so on).
Even in case the ACLs are strictly limited to deliver only
posixAccount/shadowAccount relevant attributes, in most commonly ldap
driven environments the nss|pam_ldap deployments disclose more security
relevant information than the previous (non-ldap) /etc/passwd
/etc/shadow approach:
Only if you use ldap for shadow ... if you don't, you will disclose less.
Regardless whether approach 1.) or 2.) (which you are forced to in
case
your directory does not support anonymous binds - e.g. MS AD
AD supports anonymous binds, but it is disabled by default, but then again SSL
isn't available by default ...
) is
deployed a simple ldapsearch (anonymous or by use of bindDn/bindPw)
delivers the /etc/passwd similar content to satisfy/achieve the unix
system's standard nss behavior:
"user:uidNumber:gidNumer:gecos: ...."
That's fine, but how about ldapsearch "+" (querying for operational
attributes)?
They are subject to ACLs, just like any other attributes.
By querying the operational attributes any interested user could get
for
example "helpful" additional information in comparison to /etc/passwd to
narrow valuable attacks:
- createTimestamp could be a good indicator for "old" and might be
higher privileged users?
- modifyTimestamp could be used to identify users who have not changed
their passwords for years...
- and many more ideas regarding the other operational attributes
So, don't allow access to these attributes by your proxy DN or anonymous, in
either of the 2 cases above.
Summary: In my opinion the only (theoretical?) chance left to
further
"harden" nss|pam_ldap deployments (by further restricting slapd's ACLs)
is to suppress delivery of some operational attributes (for the
nss|pam_ldap's proxy-user bindDn!) to a minimum.
I've (just for fun) already experimented with this. And all I can say
nss|pam_ldap and slapd are still working fine but - and now let me come
to the question:
I'm completely unsure whether suppressing operational attributes could
harm slapd's internal operations in any kind? Ok thinking of denying
contextCSN in replicated environments - hehe - the answer seems clear to
me but what about the entryDN, hasSubordinates, and all the others...
are they needed by slapd to operate correctly (possibly the operational
attributes need is backend depending)?
'Needed by slapd to operate' is orthogonal to 'needed by nss_ldap to
operate'.
> Finally, you may also want to consider per-host credentials ...
easiest
> in a Kerberos environment.
Using sasl external or kerberos in combination with nss|pam_ldap's
/etc/ldap.conf does not seem to improve security: the certificate's key
needs to be world readable
Not necessarily.
so any interested user can take the key and
the certificate to bind "-Y EXTERNAL" to investigate the posixAccount
users (and - I'm not sure - the same should apply to kerberos
system/server tickets which needs to be world readable, too).
Not necessarily. See 'use_sasl' and 'root_use_sasl' options. If users are
getting tickets on login, and you have 'use_sasl', user lookups will use their
own privileges (if you have appropriate mapping from the SASL identity to
their DN on the LDAP server).
> Did you read the nss_ldap documentation?
>
> (Aaron already replied, but the fact that nss_ldap supports what you
> wanted originally was not covered).
In my opinion that's not sure.
BTW and in regard to the "just for fun section", mentioned above:
nss|pam_ldap has obvious design deficits therefore "nss_ldapd" has been
developed and the related "slapo-nssov" is currently in development.
These two approaches represent another level of indirection and seem to
solve the above described general problems regarding the
"quasi-anonymous" access because the nss part can be run in privileged
user context where the bindDn/bindPw is probably kept more secure.
But, using nscd with nss_ldap achieves the same. Now, using nscd (or, maybe
nss_ldap with nscd ...) does come with its own issues ...
nss_ldapd seems to be quite stable. nssov is in the contrib branch
of
slapd and need to be compiled manually. Possibly one should give them a
try instead of betting on a dead horse (nss_ldap)...
But, the privilege issue isn't the biggest reason.
Regards,
Buchan
4:58 a.m.
On 10/06/2010 14:58, Aravind Divakaran wrote:
Hi,
Now i have changed the rid of one of my server, now both servers have
unique rid and sid. After changing the rid i have deleted and db and
replicated from the other. Now when i change the password of the user it
says successfully changed. But when i try to login with that password i
was not able to login. Below is my log files
Are you sure that the ACLs allow the replication user to read the
userPassword attribute? And, of course, bind using it?
Jonathan
--
--------------------------------------------------------------
Jonathan Clarke - jonathan(a)phillipoux.net
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------
5:17 a.m.
Hi
Now the problem is resolved. While i was trying to debug i have noticed
that when changing the password using ldappasswd command i was able to
login. But when i am changing the password using a php frontend it is not
allowing me to login again with the new password. Problem will happen only
when i am using any special characters in the new password. So i created a
new interface in python for changing the ldap password. Now everything is
working fine.
I am very much thankful for all the people in the mailing list who helped
me to debug and solve my issue.
On 10/06/2010 14:58, Aravind Divakaran wrote:
> Hi,
>
> Now i have changed the rid of one of my server, now both servers have
> unique rid and sid. After changing the rid i have deleted and db and
> replicated from the other. Now when i change the password of the user it
> says successfully changed. But when i try to login with that password i
> was not able to login. Below is my log files
Are you sure that the ACLs allow the replication user to read the
userPassword attribute? And, of course, bind using it?
Jonathan
--
--------------------------------------------------------------
Jonathan Clarke - jonathan(a)phillipoux.net
--------------------------------------------------------------
Ldap Synchronization Connector (LSC) - http://lsc-project.org
--------------------------------------------------------------
Rgds,
Aravind M D
4846
days inactive
4900
days old
openldap-technical@openldap.org
14 comments
7 participants
participants (7)
-
Aaron Richton -
Aravind Divakaran -
Ariel -
Benjamin Griese -
Buchan Milne -
Daniel -
Jonathan Clarke