[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: slapd replication doesn't work



On Monday 09 October 2006 23:30, chechu chechu wrote:
> hiÂÂ
> I have working openldap, and I want to add replication, I follow hpwtos
> from many maillist but it doesn't works, my slapd.conf files are:

You don't supply version numbers, which may be useful when suggesting other 
changes. I assume it is Debian, thus 2.2.x if you use the shipped packages. 
Consider upgrading ...


>
> MASTER:




> sasl-realm              IRONMAN.ES
> sasl-host              shogun.ironman.es

[...]

>
>
> #################TLS/SSL####################
> # Certificado firmado de una entidad certificadora y
> # el certificado del servidor
>
> TLSCipherSuite HIGH:MEDIUM:+SSLv2
> TLSCertificateFile /etc/ldap/ssl/server.pem
> TLSCertificateFile /etc/ldap/ssl/server.pem
> TLSCertificateKeyFile /etc/ldap/ssl/server.pem
>
> # Si desea que el cliente necesite autentificaciï,
> # descomente la siguiente lïea
> #TLSVerifyClient demand
> # ... si no, descomente esta otra
>  TLSVerifyClient never

[...]

> #######################################################################
> # Specific Directives for database #1, of type ldbm:
> # Database specific directives apply to this databasse until another
> # 'database' directive occurs
> database        ldbm

Consider switching to bdb, and if you don't upgrade, at least enable the 
automatic database recovery in the Debain init script.


>
> # The base of your directory in database #1
> suffix          "dc=ironman,dc=es"
> rootdn          "cn=admin,dc=ironman,dc=es"
> rootpw          secret
>
>
> #########REPLICA#############
>
>
> replica 	host=shinobi.ironman.es:636
> 		tls=yes bindmethod=sasl
>
> binddn="cn=replicauser,dc=ironman,dc=es"
>
> saslmech=gssapi

All the configuration from replica to gssapi forms on configuration directive. 
You should have no lines without leading white space until the last one. I 
don't think binddn applies unless using simple as bindmethod.

>
> replogfile /var/lib/ldap/openldap-master-replog
>
> ##############################
>
>
> # Where the database file are physically stored for database #1
> directory       "/var/lib/ldap"



> # Include the access lists
> include                 /etc/ldap/slapd.access



> SLAVE

[...]

> sasl-realm              IRONMAN.ES
> sasl-host              shogun.ironman.es
>

This is not sufficient for SASL identity mapping (from your replica's SASL 
identity to a dn.



> database        ldbm

See above.

>
> # The base of your directory in database #1
> suffix          "dc=ironman,dc=es"
> rootdn          "cn=admin,dc=ironman,dc=es"
> rootpw          secret
>
>
> #########ESCLAVO#############
>
> updatedn        cn=replicauser,dc=ironman,dc=es
> updateref       ldaps://shogun.ironman.es
> ##############################
>
>
> # Where the database file are physically stored for database #1
> directory       "/var/lib/ldap"
>
> # Indexing options for database #1

[...]

>
> # Include the access lists
> #include                 /etc/ldap/slapd.access

It would be useful to see the contents of this file.

>  access to *
> by dn=cn=replicauser,dc=ironman,dc=es write
> by * read
>

This statement probable needs a "break" directive, otherwise all the ACLs that 
follow are useless.

> # Ensure read access to the base for things like
> # supportedSASLMechanisms.  Without this you may
> # have problems with SASL not knowing what
> # mechanisms are available and the like.
> # Note that this is covered by the 'access to *'
> # ACL below too but if you change that as people
> # are wont to do you'll still need this if you
> # want SASL (and possible other things) to work
> # happily.
> #access to dn.base="" by * read

You may want to consider uncommenting the line above, if your slapd.access 
file on the slave doesn't cater to this.

> I add user replicauser to ldap, and I add the key to kerberos database
> by:
>
> kadmin.local -q "addprinc -randkey replicauser@IRONMAN.ES"
>
> kadmin.local -q "ktadd -k /etc/krb5.keytab.slurpd replicauser"
> kinit -r 7d -k -t /etc/krb5.keytab.slurpd replicauser@IRONMAN.ES
>

Can you then bind (eg with ldapwhoami) with this SASL identity to the slave?

What errors are logged on the slave?

Regards,
Buchan


-- 
Buchan Milne
ISP Systems Specialist - Monitoring/Authentication Team Leader
B.Eng,RHCE(803004789010797),LPIC-2(LPI000074592)

Attachment: pgpKBH7SRKmlh.pgp
Description: PGP signature