LDAP corruption?

[Vivarto]

Hi,

Part 1
-------
We've recently had an unplanned power outage. When the servers came back up Cognos was not starting and after a bit of digging around I found that the SunOne directory server (DS) we use as our 3rd party authentication source was not starting. I've tried going into the SunOne console and manually starting the server but get 'error: failed to read the config file successfully'.

My understanding is that the 'config file' is actually held in in the directory server itself. I have tried to open the DS to look at the configuration but get a 'Log into Directory' dialog that prompts me for the password to 'cn=Directory Manager'. I log into the server console using the Directory Manager password so I know it’s correct however I just get a 'Cannot connect to the LDAP server' message when I provide the password which I think says that the DS is corrupted.

There are other DS instances visible in the console and I have no problem opening them AND I'm not asked for a password so there is something different about this one.

Bottom line, I'm a bit stumped. Has anyone seen this problem before and found a solution or is this DS now unusable?


Part 2
------
If the DS is stuffed what are my options? I figured I should be able to create a new DS instance on a different port to hold the namespace information and then alter Cognos Configuration to point to this new DS instance. I should be able to reload the namespace information using Access Manager Batch Maintenance OR use the dse.ldif.startOK file from the original DS instance on port 389. I've created a new DS instance on port 387 and have it starting OK. I've specified the new port in Cognos Connection and then went into Access Manager to add a new connection so that I could see the namespace through that tool. However when I test the connection I get the message 'Authentication Data has not been found'. I've tried manually adding the user 'Administrator' through the SunOne console but this does not change anything.

I can't find anything in the documentation or KB that covers this (but then I might not be asking the right question) so I've reached the limits of my knowledge. I think the problem may be that the DS has not been configured for use with Cognos. I think that when installing for the first time the Cognos install utility configures the DS appropriately and I'm not sure how I would do this without reinstalling the LDAP

So, am I going down the right path? Does anyone have experience in this area?

All help gratefully appreciated,

cheers, Tom

 

[xs4citrix]

When using the Sun ONE ldap it is advised to always make a backup via access manager to a .lae file.
Such an export contains all information and is the easiest way to restore a broken Sun ONE system.

part2:
If you have such a(recent) .lae file, just deinstall sunone completely, reinstall and import the .lae via access manager.

In your cognos series 7 configuration you need to do an apply, when connecting to a new Sun ONE instance. it will then create the default namespace with the user administrator (no password) and the Root user Class to which you can connect with your access manager.

Stefan

http://www.printingsupport.com

 

[avitabj]

Hi! You can also use a .ldif to reinitialize the data if you've run the db2ldif.bat file. I would also suggest a reboot of the server between the deinstall and reinstall. Then you can reuse the port (389) and not have to change config. Also, have you run AM_NamespaceCorruptionDetect from the {install location}\bin folder? If yes, what were the results?

hth...jean

 

[Vivarto]

xs4citrix and avitabj

Thanks for your input. I've now discovered that the DS configuration is saved away in a series of LDIF files that are flat ASCII. I've looked at the main one in Notepad and found that it is completely blank, 109K of whitespace! I overwrote this file with the .ldif.StartOK version and problem fixed. I'm not sure if this is functionally the same as using the db2ldif.bat but I'll look into that for future reference.

We do backup the .LAE files regularly so the reinstall option was viable but luckily unnecessary. I think the bottom line is that the .ldif file was corrupted rather than the DS so I got of lightly

Thanks again for taking the time to reply

Cheers, Tom