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