Quanah,

Thanks a lot!

The replication is just fine after loading the LDIF with operational attributes. No overload in consumer to sync database now.

Regards,

Rodrigo.

Quanah Gibson-Mount wrote:

--On Thursday, May 07, 2009 10:36 AM -0700 Rodrigo Costa rlvcosta@yahoo.com wrote:

...

Quanah,

My understanding is that attrs doesn't need to exist in config since by default all attributes are shared.

I think that is what I said. You should not specify the attrs= line in the syncrepl stanza on the replica, and just use the default. That way, the entire database is replicated in full to the replica.

...

My original plan was to remove some tasks from the provider, like backup, running a slapcat in the consumer(slave). Based in the requirement to load the consumer(slave) using a master LDIF dump I'm not sure if this is really feasible.

Why is it a requirement to use a master LDIF dump? I never said that. What I said, is that you are required to have a fully formed LDIF file to load LDAP servers that will be syncing (I.e., an LDIF file with the operational attributes, vs a generated LDIF file from a program that is missing them.). If you do a slapcat from an existing server, then it should be fully formed.

...

My idea was : 1)Have a provider/consumer running; 2)Execute LDIF and binary backups in the consumer(slave) 3)In a case of problem in the master just let a HA SW move the master to slave and then load "old master" using the slave LDIF file(recovering procedure).

Is this feasible?

Yes, this is pretty standard procedure, minus the binary backups. You could of course just set up mirror mode or multi-master, as well...

--Quanah

--

Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc

---

Zimbra :: the leader in open source messaging and collaboration