Gavin Henry wrote:

<quote who="Duncan Brannen">

...

Hi, I've got a slave that I think I missed out the -w on the slapadd when I rebuilt it recently and it's not picking up changes from the master.

What I'm seeing in the log is

slapd[11886]: [ID 502419 local4.debug] Entry reqStart=20080311204629.000002Z,cn=accesslog CSN 20080311204629.095387Z#000000#000#000000 older or equal to ctx 20080311204629.095387Z#000000#000#000000

Every 60 seconds or so. (My retry interval) type is RefreshAndPersist

Is there an easy way to reset the timestamp on the slave / master so this fires into life or do I need to reload it?

Slave is 2.4.7 and the master is 2.4.8 so it's due another upgrade soon anyway but I'd rather get then synced now and upgrade out of hours.

What size of db are we talking about?

Pretty small, files are around 300Mb total, 150K entries. It'll only take 20-30min to reload, but it's much longer to get it in/out of the dns round robin we use for load balancing.

Thanks, Duncan

Gavin Henry wrote:

<quote who="Duncan Brannen">

...

Gavin Henry wrote:

...

<quote who="Duncan Brannen">

...

Hi, I've got a slave that I think I missed out the -w on the slapadd when I rebuilt it recently and it's not picking up changes from the master.

What I'm seeing in the log is

slapd[11886]: [ID 502419 local4.debug] Entry reqStart=20080311204629.000002Z,cn=accesslog CSN 20080311204629.095387Z#000000#000#000000 older or equal to ctx 20080311204629.095387Z#000000#000#000000

Every 60 seconds or so. (My retry interval) type is RefreshAndPersist

Is there an easy way to reset the timestamp on the slave / master so this fires into life or do I need to reload it?

Slave is 2.4.7 and the master is 2.4.8 so it's due another upgrade soon anyway but I'd rather get then synced now and upgrade out of hours.

What size of db are we talking about?

Pretty small, files are around 300Mb total, 150K entries. It'll only take 20-30min to reload, but it's much longer to get it in/out of the dns round robin we use for load balancing.

Thanks, Duncan

Hi Duncan,

How did you get on? I never saw your reply until after 5, so presumed you did an upgrade out of hours.

Cheers.

Hi Gavin, Yes, thanks, I took the server out of the round robin and did an upgrade as well as the reload. I got a similar initial error message (maybe this is normal)

phantom slapd[11886]: [ID 502419 local4.debug] Entry reqStart=20080314081607.000003Z,cn=accesslog CSN 20080314081607.575746Z#000000#000#000000 older or equal to ctx 20080314081607.575746Z#000000#000#000000

but then it started syncing ok.

eg. phantom slapd[11886]: [ID 653192 local4.debug] syncprov_search_response: cookie=rid=001,csn=20080314112502.347110Z#000000#000#000000

Should it have been possible to do this without an outage, or should it have fixed itself as it seems to have this time (the impression I got from the manual)?

One point, test 008-Concurrency produces a lot of Invalid Credentials messages but doesn't actually fail. I don't recall this happening with 2.3.x is this due to the differing acl requirements?

I now have a different problem with the slave not recognising the master's certificate TLS trace: SSL3 alert write:fatal:unknown CA I'm wondering if I've a mix of ssl libraries in there someplace (debug looks like it's reading the correct directive and the other slaves work so it's not openldap) There goes my afternoon ;)

Cheers, Duncan

In case anyone else has this problem and had the same chair/keyboard breakdown I had,

I'd overwritten my ldap.conf file when I reinstalled and syncrepl (on the client side at least) would seem to get it's CA info from the /usr/local/etc/openldap/ldap.conf file rather than the TLSCACertificateFile option in slapd.conf

Oh dear :-(

On a related note, while the man page still mentions starttls for syncrepl, the online admin guide doesn't http://www.openldap.org/doc/admin24/slapdconfig.html#syncrepl Is this a hint to get people using sasl instead of simple?

No, they just need updating. I've just filed a ticket for myself:

http://www.openldap.org/its/index.cgi/Documentation?id=5425

Thanks,

Gavin.