Hello,
_My problem :_ I would like to have a replication server and i don't understand why all data are not copied to the replication server, i use rootdn to do sync...i should be able to copy all data...it start to copy but don't copy all data...
_LDAP version :_ Source and copy are the same server : openldap-2.3.27-8
see below for configuration files,
thks for your help ! Alain
_Source server :_
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/rfc822-MailMember.schema include /etc/openldap/schema/gosa/gofon.schema include /etc/openldap/schema/gosa/samba3.schema include /etc/openldap/schema/gosa/pureftpd.schema include /etc/openldap/schema/gosa/gohard.schema include /etc/openldap/schema/gosa/goto.schema include /etc/openldap/schema/gosa/gosa+samba3.schema include /etc/openldap/schema/gosa/gofax.schema include /etc/openldap/schema/gosa/goserver.schema include /etc/openldap/schema/sfe.schema
loglevel 256 password-hash {CRYPT}
allow bind_v2
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
access to * by * read
database bdb suffix dc=domain,dc=com rootdn cn=Manager,dc=domain,dc=com rootpw {SSHA}Lcrkf43J0AU3rXGtMRk5iHAMXHuweL4R
directory /var/lib/ldap/domain.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
*# Pour la replication avec syncrepl overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 sessionlog 123 500*
====================================================================
_Destination server :_
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema
loglevel 256 schemacheck off
allow bind_v2
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
####################################################################### # ldbm and/or bdb database definitions #######################################################################
database bdb suffix "dc=domain,dc=com" rootdn "cn=Manager,dc=domain,dc=com" rootpw {SSHA}Lcrkf43J0AU3rXGtMRk5iHAMXHuweL4R
directory /var/lib/ldap/domain.com
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
access to * by * read * syncrepl rid=123 provider=ldap://10.0.0.242:389 type=refreshOnly interval=00:00:05:00 searchbase="dc=domain,dc=com" filter="(objectclass=*)" attrs="*" scope=sub schemachecking=off updatedn="cn=Manager,dc=domain,dc=com" bindmethod=simple binddn="cn=Manager,dc=domain,dc=com" credentials=xxxx*
--- Antivirus avast! : message Sortant sain. Base de donnees virale (VPS) : 080216-0, 16/02/2008 Analyse le : 17/02/2008 13:54:14 avast! - copyright (c) 1988-2008 ALWIL Software. http://www.avast.com
Alain Siani asiani@free.fr writes:
Hello,
My problem : I would like to have a replication server and i don't understand why all data are not copied to the replication server, i use rootdn to do sync...i should be able to copy all data...it start to copy but don't copy all data...
LDAP version : Source and copy are the same server : openldap-2.3.27-8
see below for configuration files,
thks for your help ! Alain
Source server :
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/rfc822-MailMember.schema include /etc/openldap/schema/gosa/gofon.schema include /etc/openldap/schema/gosa/samba3.schema include /etc/openldap/schema/gosa/pureftpd.schema include /etc/openldap/schema/gosa/gohard.schema include /etc/openldap/schema/gosa/goto.schema include /etc/openldap/schema/gosa/gosa+samba3.schema include /etc/openldap/schema/gosa/gofax.schema include /etc/openldap/schema/gosa/goserver.schema include /etc/openldap/schema/sfe.schema
loglevel 256 password-hash {CRYPT}
Don't use crypt! Because you never know which crypt library is linked against your application, but this is only one of many reasons.
allow bind_v2
This is not recommended, LDAPv3 is out for more than 10 years now, LDAPv2 is historic!
pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args
access to * by * read
database bdb suffix dc=domain,dc=com rootdn cn=Manager,dc=domain,dc=com rootpw {SSHA}Lcrkf43J0AU3rXGtMRk5iHAMXHuweL4R
This is nonsens if you declare password hash crypt.
loglevel 256 schemacheck off
why do you want schema check disabled?
syncrepl rid=123 provider=ldap://10.0.0.242:389 type=refreshOnly interval=00:00:05:00 searchbase="dc=domain,dc=com" filter="(objectclass=*)" attrs="*" scope=sub schemachecking=off updatedn="cn=Manager,dc=domain,dc=com" bindmethod=simple binddn="cn=Manager,dc=domain,dc=com" credentials=xxxx
you need operational attributes and user attributes to be synchronized, that is, if you want to define a attribute filter it should be attrs="*","+", but read man slapd.conf(5) on syncrepl filters. updatedn is not required with syncrepl, never ever use rootdn to control synchonization, because no access control comes into effect. I'm missing a updateref declaration and a declaration of limits.
-Dieter
--On Sunday, February 17, 2008 8:32 PM +0100 Dieter Kluenter dieter@dkluenter.de wrote:
Alain Siani asiani@free.fr writes:
Hello,
My problem : I would like to have a replication server and i don't understand why all data are not copied to the replication server, i use rootdn to do sync...i should be able to copy all data...it start to copy but don't copy all data...
LDAP version : Source and copy are the same server : openldap-2.3.27-8
This is a very old 2.3 release. Many fixes to OL syncrepl mechanism have been made since then. I highly advise you to run a current release.
you need operational attributes and user attributes to be synchronized, that is, if you want to define a attribute filter it should be attrs="*","+", but read man slapd.conf(5) on syncrepl filters.
Just to note, *,+ is the default if no attrs= statement is specified, which generally should be used unless the user really knows what they are doing.
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
On Sunday 17 February 2008 21:32:07 Dieter Kluenter wrote:
password-hash {CRYPT}
Don't use crypt! Because you never know which crypt library is linked against your application, but this is only one of many reasons.
I'm sorry, but this doesn't belong in this thread IMHO. There *are* valid reasons to enforce a specific password hash, especially if devices in the environment in question only support crypt (yes, I have some).
allow bind_v2
This is not recommended, LDAPv3 is out for more than 10 years now, LDAPv2 is historic!
But, I also have some proprietary applications which are still LDAPv2.
Neither of these impact the issue at hand, so I don't see the point in evangelising them without caveats (like, "if you're sure you don't have applications which rely on these settings").
Regards, Buchan
Is the slave must have all schema defined like the master ? even if i put "schemacheck off" ?
thanks, Alain
Buchan Milne wrote:
On Sunday 17 February 2008 21:32:07 Dieter Kluenter wrote:
password-hash {CRYPT}
Don't use crypt! Because you never know which crypt library is linked against your application, but this is only one of many reasons.
I'm sorry, but this doesn't belong in this thread IMHO. There *are* valid reasons to enforce a specific password hash, especially if devices in the environment in question only support crypt (yes, I have some).
allow bind_v2
This is not recommended, LDAPv3 is out for more than 10 years now, LDAPv2 is historic!
But, I also have some proprietary applications which are still LDAPv2.
Neither of these impact the issue at hand, so I don't see the point in evangelising them without caveats (like, "if you're sure you don't have applications which rely on these settings").
Regards, Buchan
On Sunday 17 February 2008 14:54:13 Alain Siani wrote:
Hello,
_My problem :_ I would like to have a replication server and i don't understand why all data are not copied to the replication server, i use rootdn to do sync...i should be able to copy all data...it start to copy but don't copy all data...
How did you determine this? How many entries are in your database?
I note the following issues in your config: 1)updatedn in your syncrepl statement does not belong there, it is not a valid syncrepl parameter 2)You don't have the sycnrepl indexes (for entryCSN, entryUUID) configured 3)To see what syncrepl is doing, you may want to have 'loglevel stats sync', instead of 'loglevel 256'.
While improvements are made to syncrepl all the time, I have some servers that have been running 2.3.11/2.3.13 without problems for two years (they were upgraded to 2.3.40 a week ago). I would advocate fixing your configuration first, before considering whether you need to upgrade or not.
Regards, Buchan
On Monday 18 February 2008 10:01:12 asiani@free.fr wrote:
Is the slave must have all schema defined like the master ? even if i put "schemacheck off" ?
It is preferable. If your only reason not to is the effort involved, save yourself more effort and ensure the schemas are available.
(2.4 has configuration replication, which could do this for you, depending on your setup)
I look with phpldapadmin and i see :
Computers : nothing has been copied Domains : nothing has been copied DSA:ok Groups : 46 copied (50 on master) systems: Ok Users : 1 (50 on master)
I removed updatedn directive I added :" index entryUUID,entryCSN eq" on both servers I added: 'loglevel stats sync'
I don't understand why the system make the sync but not complete it ! it is mad !
thks, Alain
Buchan Milne wrote:
On Sunday 17 February 2008 14:54:13 Alain Siani wrote:
Hello,
_My problem :_ I would like to have a replication server and i don't understand why all data are not copied to the replication server, i use rootdn to do sync...i should be able to copy all data...it start to copy but don't copy all data...
How did you determine this? How many entries are in your database?
I note the following issues in your config: 1)updatedn in your syncrepl statement does not belong there, it is not a valid syncrepl parameter 2)You don't have the sycnrepl indexes (for entryCSN, entryUUID) configured 3)To see what syncrepl is doing, you may want to have 'loglevel stats sync', instead of 'loglevel 256'.
While improvements are made to syncrepl all the time, I have some servers that have been running 2.3.11/2.3.13 without problems for two years (they were upgraded to 2.3.40 a week ago). I would advocate fixing your configuration first, before considering whether you need to upgrade or not.
Regards, Buchan
On Monday 18 February 2008 11:48:02 asiani@free.fr wrote:
I look with phpldapadmin and i see :
Computers : nothing has been copied Domains : nothing has been copied DSA:ok Groups : 46 copied (50 on master) systems: Ok Users : 1 (50 on master)
I removed updatedn directive I added :" index entryUUID,entryCSN eq" on both servers
You would have to create the indexes themselves as well by running slapindex.
I added: 'loglevel stats sync'
I don't understand why the system make the sync but not complete it ! it is mad !
It's probably best to empty the database on the slave, and then see if it replicates the entire database or not. Only then will the extra logging be useful.
Regards, Buchan
i stopped slapd, i run slapindex, i restart slapd no change
i empty the database : stop slapd ; rm * dans /var/lib/ldap/mydomain/ ; start slapd the synchronisation stop at the same point !
i'm trying to put all schema like the master ...but not sure it is the solution
thks, Alain
Buchan Milne wrote:
On Monday 18 February 2008 11:48:02 asiani@free.fr wrote:
I look with phpldapadmin and i see :
Computers : nothing has been copied Domains : nothing has been copied DSA:ok Groups : 46 copied (50 on master) systems: Ok Users : 1 (50 on master)
I removed updatedn directive I added :" index entryUUID,entryCSN eq" on both servers
You would have to create the indexes themselves as well by running slapindex.
I added: 'loglevel stats sync'
I don't understand why the system make the sync but not complete it ! it is mad !
It's probably best to empty the database on the slave, and then see if it replicates the entire database or not. Only then will the extra logging be useful.
Regards, Buchan
It seems to be ok now !!!!! thks for your help ! I'm putting all schema on all server, i try too : su ldap;service ldap start before i started in root user...and i think now it is a very very bad thing !!!
All seems to be ok !
thanks, Alain
asiani@free.fr wrote:
i stopped slapd, i run slapindex, i restart slapd no change
i empty the database : stop slapd ; rm * dans /var/lib/ldap/mydomain/ ; start slapd the synchronisation stop at the same point !
i'm trying to put all schema like the master ...but not sure it is the solution
thks, Alain
Buchan Milne wrote:
On Monday 18 February 2008 11:48:02 asiani@free.fr wrote:
I look with phpldapadmin and i see :
Computers : nothing has been copied Domains : nothing has been copied DSA:ok Groups : 46 copied (50 on master) systems: Ok Users : 1 (50 on master)
I removed updatedn directive I added :" index entryUUID,entryCSN eq" on both servers
You would have to create the indexes themselves as well by running slapindex.
I added: 'loglevel stats sync'
I don't understand why the system make the sync but not complete it ! it is mad !
It's probably best to empty the database on the slave, and then see if it replicates the entire database or not. Only then will the extra logging be useful.
Regards, Buchan
On Monday 18 February 2008 12:36:41 asiani@free.fr wrote:
It seems to be ok now !!!!! thks for your help ! I'm putting all schema on all server, i try too : su ldap;service ldap start before i started in root user...and i think now it is a very very bad thing !!!
The init script supplied in the packages you are using already runs slapd as the user ldap with group ldap by default (e.g. 'slapd -u ldap -g ldap'), so running 'service ldap start' as root is not a problem.
Regards, Buchan
Yes it is ok now ! backup is samesize and phpldapadmin show all entry numbers. I think the source of problem could be i started in root users...and not ldap + schema
just onething obscur ... : to sync the schema i copied the schema : rfc822-MailMember.schema from my master server and i don't know if it is a good solution...
In what package this schema is ? may be it is better to install package of this schema ?
thks, Alain
asiani@free.fr wrote:
It seems to be ok now !!!!! thks for your help ! I'm putting all schema on all server, i try too : su ldap;service ldap start before i started in root user...and i think now it is a very very bad thing !!!
All seems to be ok !
thanks, Alain
asiani@free.fr wrote:
i stopped slapd, i run slapindex, i restart slapd no change
i empty the database : stop slapd ; rm * dans /var/lib/ldap/mydomain/ ; start slapd the synchronisation stop at the same point !
i'm trying to put all schema like the master ...but not sure it is the solution
thks, Alain
Buchan Milne wrote:
On Monday 18 February 2008 11:48:02 asiani@free.fr wrote:
I look with phpldapadmin and i see :
Computers : nothing has been copied Domains : nothing has been copied DSA:ok Groups : 46 copied (50 on master) systems: Ok Users : 1 (50 on master)
I removed updatedn directive I added :" index entryUUID,entryCSN eq" on both servers
You would have to create the indexes themselves as well by running slapindex.
I added: 'loglevel stats sync'
I don't understand why the system make the sync but not complete it ! it is mad !
It's probably best to empty the database on the slave, and then see if it replicates the entire database or not. Only then will the extra logging be useful.
Regards, Buchan
openldap-technical@openldap.org
-
Alain Siani -
asiani＠free.fr -
Buchan Milne -
Dieter Kluenter -
Michael Ströder -
Quanah Gibson-Mount