This is no longer an issue...at least in regards to *corrupted* data and
attempting to recover it. I've restored database files from a recent
backup. The users are now back as they were. I'm back to focusing on why
this is occurring after every reboot. I've setup a similar configuration on
another Linux server, rebooted it and all the users I created are there.
I'll resubmit more questions if I have any on that.
Thanks again,
Ryan
On 7/12/06, Ryan Ivey <[EMAIL PROTECTED]> wrote:
Kurt,
Thanks for the advice.
I first stopped ldap & slapd and then ran 'db_recover -v' while in the
directory for ldap (/var/lib/ldap) and received the following:
db_recover: Finding last valid log LSN: file: 1 offset 415705
db_recover: Recovery starting from [1][415564]
db_recover: Recovery complete at Wed Jul 12 07:32:44 2006
db_recover: Maximum transaction ID 800000da Recovery checkpoint
[1][415705]
I then restarted ldap & slapd, however nothing changed. I then attempted
to add a user that I knew was there before, using ldapadd and received a
statement that the user already exists. When using a GUI such as LDAP
Admin, I don't see the user(s) listed. I can grep the files in
/var/lib/ldap for users and I receive results back. For some reason these
files are not being read by the GUI, but are seen by ldapadd.
I tried using 'db_recover -c -v', but receive:
db_recover: Finding last valid log LSN: file: 1 offset 424467
db_recover: Recovery starting from [1][28]
db_recover: Log sequence error: page LSN 1 416496; previous LSN 1 558401
db_recover: Recovery function for LSN 1 416216 failed on forward pass
db_recover: PANIC: Invalid argument
db_recover: PANIC: fatal region error detected; run recovery
db_recover: PANIC: fatal region error detected; run recovery
db_recover: PANIC: fatal region error detected; run recovery
db_recover: PANIC: fatal region error detected; run recovery
db_recover: PANIC: fatal region error detected; run recovery
db_recover: PANIC: fatal region error detected; run recovery
db_recover: DB_ENV->open: DB_RUNRECOVERY: Fatal error, run database
recovery
Any further suggestions are very appreciated.
Thanks,
Ryan
On 7/11/06, Kurt D. Zeilenga <[EMAIL PROTECTED]> wrote:
>
> Sounds like someone didn't run db_recover after improperly
> shutting down slapd(8).
>
> - Kurt
>
> At 09:42 PM 7/10/2006, Ryan Ivey wrote:
> >I'm somewhat new to OpenLdap and not sure what to check here.
> >
> >After rebooting the server, all UserID's are being cleared and each are
> having to be readded. Only the uid set in /etc/openldap/slapd.conf under
> the 'access to attr' directive remains and is able to readd the other
> userid's. This is becoming a problem because more and more userid's are
> being added and each time the server is rebooted we have to readd them.
> All files in /var/lib/ldap are the same, including the id2entry.bdbfile,
which I've read is the main database file to be backed up. Are the
> userid's and password's cached somewhere and not being written to disk? Or
> is there a temporary file being cleared? I'm running ldap on a SLES9
> server.
> >
> >/etc/openldap/slap.d contains the following:
> >
> >include /etc/openldap/schema/core.schema
> >include /etc/openldap/schema/openldap.schema
> >
> >schemacheck on
> >
> >allow bind_v2 bind_anon_dn
> >
> >loglevel 256
> >
> >pidfile /var/run/slapd/slapd.pid
> >argsfile /var/run/slapd/slapd.args
> >
> >modulepath /usr/lib/openldap/modules
> >
> >password-hash {crypt}
> >
> >access to attr=userPassword
> > by self write
> > by self auth
> > by dn="uid=****,ou=*******,dc=********,dc=com" write
> > by * auth
> >
> >access to *
> > by dn="uid=****,ou=*******,dc=********,dc=com" write
> >
> >database bdb
> >checkpoint 1024 5
> >cachesize 10000
> >suffix "dc=********,dc=com"
> >rootdn "cn=root,dc=********,dc=com"
> >
> >rootpw ***********
> >
> >directory /var/lib/ldap
> >
> >index default sub
> >index uid eq
> >index cn,sn,givenName,ou pres,eq,sub
> >index objectClass pres,eq
> >
> >##EOF##
> >
> >
> >Any help is greatly appreciated.
> >
> >Thanks,
> >Ryan
>
>
