On Wed, 2016-04-20 at 16:37 +0000, Job Cacka wrote:
Touch!
I check the error logs i mentioned before and they go back to October 4th, but
they don't indicate to me the change created the problem. My inclination is
that some change occurred that change a key. So how do I track that back?
Perhaps the server was never setup correctly to start with?
I tested this on my 389 DS server.
ldapsearch [-x] -D "cn=directory manager" -W -b
"cn=admin-serv-zigzag,cn=389
Administration Server,cn=Server
Group,cn=zigzag.ccbox.com,ou=ccbox.com,o=NetscapeRoot"
The result was:
# search result
search: 2
result: 0 Success
# numResponses: 31
# numEntries: 30
Then I tested this:
ldapsearch -H
ldaps://zigzag.ccbox.com [-x] -D "cn=directory manager" -W
"cn=admin-serv-zigzag,cn=389 Administration Server,cn=Server
Group,cn=zigzag.ccbox.com,ou=ccbox.com,o=NetscapeRoot"
The result was:
# search result
search: 2
result: 0 Success
# numResponses: 222
# numEntries: 221
Why do I get the populate error? Does the two tests above provide any
indication? I also ran these tests from another linux system and received the
same results. The error I am seeing at restarting the Admin server doesn't seem
to make sense if I am searching correctly. I think it should have the records
it needs to repopulate the server.
I think that at this point, if you have a damaged netscaperoot, there is other
things going. Some kind of admin failure or mistake.
I think that it may be worth investigating backup of your userRoot, and then re-
initialise the server.
Also, I think I found an old admin server backup that was taken before any of
these problems surfaced. Anyone have a link that would walk me through the
restore process? Is this a good idea?
It's not a good idea to restore the db4 directly into NetscapeRoot unless you
really, really, know what you are doing.
It's better to have backups as db2bak or db2ldif. I highly advise that you have
scheduled tasks to take these backups for the future.
--
Sincerely,
William Brown
Software Engineer
Red Hat, Brisbane