Re: slurpd replication problem.

[Buchan Milne <bgmilne@staff.telkomsa.net>]

On Tuesday 28 October 2008 01:58:02 Choi, Justin wrote:
> I am seeing invalid credential error logs a lot.
>
> Could you guys let me know how to solve this issue?

In future, don't send screenshots of text that you could just have easily 
copied from Putty and pasted into your mail instead of sending everyone > 
100kB of screenshots they don't need. (The HTML format is also unnecessary 
...)

It would also help if you could list the version of OpenLDAP that you are 
suing, and the platform you are running on.

Note that in modern (2.3 or later) versions of OpenLDAP, slurpd is deprecated, 
and in the current (2.4) versions, is no longer available. 

>
> Thanks.
>
>
>
>
>
>
>
> Server Log(slurpd -d 2)
>
>
>
>
>
>
>
> Replicated Log (/usr/sbin/slapd -u ldap -d 2 -h ldap:///)
>
>
>
> Slapd.conf
>
> database        bdb
>
> suffix          "dc=ijji,dc=com"
>
> rootdn          "cn=Manager,dc=ijji,dc=com"
>
> rootpw          {SSHA}EpkPadkANDlpX7yfcsa2WbA+bSssh0S4
>
> # Cleartext passwords, especially for the rootdn, should
>
> # be avoided.  See slappasswd(8) and slapd.conf(5) for details.
>
> # Use of strong authentication encouraged.
>
> # rootpw                secret
>
> # rootpw                {crypt}ijFYNcSNctBYg
>
>
>
> # The database directory MUST exist prior to running slapd AND
>
> # should only be accessible by the slapd and slap tools.
>
> # Mode 700 recommended.
>
> directory       /var/lib/ldap/ijji.com
>
>
>
> # Indices to maintain for this database
>
> index objectClass                       eq,pres
>
> index ou,cn,mail,surname,givenname      eq,pres,sub
>
> index uidNumber,gidNumber,loginShell    eq,pres
>
> index uid,memberUid                     eq,pres,sub
>
> index nisMapName,nisMapEntry            eq,pres,sub
>

The following two lines really need to be uncommented for replication to work.

> #updatedn cn=Replication Manager,dc=ijji,dc=com
>
> #updateref ldap://ca1xc115.ijji.com
>
> access to attrs=userPassword
>
>         by self write
>
>                 by anonymous auth
>
>                 by dn.base="cn=Manager,dc=ijji,dc=com" write
>
>                 by * none
>
> access to *
>
>                 by self write
>
>                 by dn.base="cn=Manager,dc=ijji,dc=com" write
>
>                 by * read
>
>

The following rule will not apply, as the target has already been matched, by 
the first rule.

>
> access to attrs=userPassword
>
>                 by self write
>
>                 by anonymous auth
>
>                 by dn.base="cn=Replication Manager,dc=ijji,dc=com" write
>
>                 by * none
>

The following rule will also not apply, for the same reason.

> access to *
>
>                 by self write
>
>                 by dn.base="cn=Replication Manager,dc=ijji,dc=com" write
>
>                 by * read
>



> # Replicas of this database
>
> replogfile /var/lib/ldap/openldap-master-replog
>
> replica host=ca1xc115.ijji.com:389
>
>         binddn="cn=Replication Manager,dc=ijji,dc=com"
>
>         bindmethod=simple credentials=skdltmwkq
>
> loglevel -1
>

Have you tested whether the account works correctly, e.g. using the OpenLDAP 
command line client utilities? E.g.:

$ ldapwhoami -x -h ca1xc115.ijji.com -D "cn=Replication 
Manager,dc=ijji,dc=com" -w skdltmwkq

(or, if you have a really old version that does not have ldapwhoami:

$ ldapsearch -x -h ca1xc115.ijji.com -D "cn=Replication 
Manager,dc=ijji,dc=com" -w skdltmwkq -s base -b '' namingContexts


Regards,
Buchan