[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: UserID's clearing after reboot



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 <iveymr@gmail.com> 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 <Kurt@openldap.org> 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 > >