Topic: ldap problems - v7 restore

[d6hq]

Restored v7 server has a broken ldap schema.

The problem - had to build a new server with a diff hostname and then restore data by hand from a failing server - all well except LDAP directory is now out of sync. Users created on the "old" server are not in the LDAP directory but "new" users (created on the new server) are.

home/e-smith/db/accounts is correct i.e. both "old" & "new" users are there but the ldap-update (what has happened to rebuild-ldap?) does not correct the error.

LOG Extract
"failed to modify entry for uid=user,dc=domain,dc=co,dc=uk: No such object at /etc/e-smith/events/ldap-update/S80ldap-update line 159, <DATA> line 283."

Ideas anyone ?

[edtest]

Hi,

This might not help you, but:

we had a problem with the LDAP database not being searchable (mostly an Outlook 2003 problem, solved with a reg-hack).

Before I discovered that Outlook was the problem, I thought it was because, like you, we had installed a new v.7 server and uploaded the data. So, I did some monkeying around with permissions and things, to the point LDAP was completely borked. Lots of freaky errors in the syslog.

Then we got the notifcation to do a set of upgrades.

Post upgrade, LDAP works beautifully.

What's in those upgrades? I don't know, but it fixed LDAP.

And yes, where is the rebuild-ldap of yore?

[CharlieBrady]

Ideas anyone ?

As it says at the top every time you post in the forum - "Please post bugs and potential bugs in the bug tracker - Thank You".

[d6hq]

To Charlie - I am not saying that this is likely to be a bug at all.

We handballed the data transfer due to hardware issues and my thinking is we haven't handballed all that is necessary to properly restore LDAP and I am looking for other peoples points of view on the matter and suggestions as to what might have been missed.

Do you think its a bug ?

To Edtest - Thanks for the input. We had fun with M$ Outlook LDAP lookups also. M$'s Knowledgebase contains the wrong info about the registry hack that is required but it is there if you dig around - I have posted the correct URL in this forum fairly recently.

[CharlieBrady]

We handballed the data transfer ...

Sorry, I missed that bit.

due to hardware issues and my thinking is we haven't handballed all that is necessary to properly restore LDAP and I am looking for other peoples points of view on the matter and suggestions as to what might have been missed.

If you describe exactly what you have done somebody might notice what you may have missed.

[d6hq]

The missing files were the contents of var/lib/ldap

We handballed the data transfer based upon the files backed up in Backup2's 911 Disaster Recovery - these are missing from that backup. If anyone has a contact address for the author of that contrib please pass this on.

[CharlieBrady]

The missing files were the contents of var/lib/ldap

We handballed the data transfer based upon the files backed up in Backup2's 911 Disaster Recovery - these are missing from that backup.
/quote]

The contents of /var/lib/ldap are not required for a recovery. They should be restored from the ldif file in /home/e-smith/db/ldif.

Did you do "signal-event pre-restore" before importing your restore data? If not, you can expect problems.

[m]

what has happened to rebuild-ldap?

/etc/e-smith/events/actions/ldap-rebuild from SME6 works on SME7 after changing "objectClass: group" to "objectClass: posixGroup" in line 104.

service ldap stop
rm -f /home/e-smith/db/ldap/*ldif
rm /var/lib/ldap/*
./ldap-rebuild
service ldap start