On Tue, 5 Feb 2008, Andreas Hasenack wrote:
> > Yes. Nothing had changed on the server since the upgrade. There were
> > successful deletes before this one and some successful ones after.
>
> Was your OL 2.3.40 built with the same version of berkeley DB as the
> previous 2.3.35 one? (Sorry if you
On Mon, 4 Feb 2008, Howard Chu wrote:
> Paul's right - assuming the slapadd went well and nothing else was done,
> then a binary copy of the DB directory should have worked fine on another
> machine.
And it did, for about 10 months :). I can't imagine a problem with the
initial databases wouldn't
On Tuesday 05 February 2008 05:22:09 Paul B. Henson wrote:
> There's not much to slapadd, I'm not sure what could have been done
> wrong... I did use the -q option (otherwise it takes untractably long), but
> there were no errors or interruptions and the database created worked fine
> for 10 month
On Mon, 4 Feb 2008, Howard Chu wrote:
Paul B. Henson wrote:
...
I took another quick look at the BerkeleyDB documentation on the Oracle
site and did not see anything that seemed relevant to copying databases
between machines. Could I trouble you for a URL to see whether there is
anything in tho
On Seg, 2008-02-04 at 12:07 -0800, Paul B. Henson wrote:
> On Mon, 4 Feb 2008, [iso-8859-1] Michael Ströder wrote:
>
> > Paul B. Henson wrote:
> > > Feb 3 03:50:36 derp idmgmt[3722]: error deleting user cjlindsay: DN index
> > > delete failed (LDAP)
> >
> > Everything right with ownership/permis
--On Monday, February 04, 2008 8:24 PM -0800 Howard Chu <[EMAIL PROTECTED]>
wrote:
Quanah Gibson-Mount wrote:
--On February 4, 2008 7:22:09 PM -0800 "Paul B. Henson"<[EMAIL PROTECTED]>
wrote:
On Mon, 4 Feb 2008, Quanah Gibson-Mount wrote:
slapadd always creates at least one log file that
Quanah Gibson-Mount wrote:
--On February 4, 2008 7:22:09 PM -0800 "Paul B. Henson"<[EMAIL PROTECTED]>
wrote:
On Mon, 4 Feb 2008, Quanah Gibson-Mount wrote:
slapadd always creates at least one log file that would not be removed by
automatic removal. If you had no log files when you were done
On Mon, 4 Feb 2008, Quanah Gibson-Mount wrote:
> slapadd always creates at least one log file that would not be removed by
> automatic removal. If you had no log files when you were done, then
> something was done wrong.
There's not much to slapadd, I'm not sure what could have been done
wrong..
On Mon, 4 Feb 2008, Philip Guenther wrote:
> Or failed to perform catastrophic recovery instead of normal recovery.
> (I.e, db_recover must be invoked with the -c option.)
Well, while I won't discount the possibility I screwed up the copy, I still
think it's unlikely and also that theory doesn't
--On February 4, 2008 7:22:09 PM -0800 "Paul B. Henson" <[EMAIL PROTECTED]>
wrote:
On Mon, 4 Feb 2008, Quanah Gibson-Mount wrote:
slapadd always creates at least one log file that would not be removed by
automatic removal. If you had no log files when you were done, then
something was don
--On February 4, 2008 5:30:29 PM -0800 "Paul B. Henson" <[EMAIL PROTECTED]>
wrote:
Reviewing the backup/restore procedure, I don't really see anything I
might have missed. slapd was not running during the copy, so clearly any
updates were suspended. In fact, slapd had never been run -- the c
On Mon, 4 Feb 2008, Howard Chu wrote:
> That documentation is clearly obsolete, which is why it was removed.
slurpd is obsolete, which is why the section on slurpd was removed from the
2.4 manual. Considering OpenLDAP-2.3.39 is still marked as the stable
release, I can't really see that the 2.3 d
On Mon, 4 Feb 2008, Howard Chu wrote:
> You cannot copy the database files from one machine to another unless
> you're extremely careful and follow the procedures outlined in the
> BerkeleyDB documentation. It sounds like you didn't follow those
> procedures. Your problem isn't coincidental, it's
Paul B. Henson wrote:
On Mon, 4 Feb 2008, Howard Chu wrote:
You cannot copy the database files from one machine to another unless
you're extremely careful and follow the procedures outlined in the
BerkeleyDB documentation. It sounds like you didn't follow those
procedures. Your problem isn't co
Paul B. Henson wrote:
On Mon, 4 Feb 2008, Howard Chu wrote:
This basically says that somebody zeroed out/removed the transaction log
files.
Nothing ever touches the transaction log files in our configuration. I
have "set_flags DB_LOG_AUTOREMOVE" in the DB_CONFIG file. Transaction logs
are aut
On Mon, 4 Feb 2008, Howard Chu wrote:
> This basically says that somebody zeroed out/removed the transaction log
> files.
Nothing ever touches the transaction log files in our configuration. I
have "set_flags DB_LOG_AUTOREMOVE" in the DB_CONFIG file. Transaction logs
are automatically pruned as n
On Mon, 4 Feb 2008, Quanah Gibson-Mount wrote:
> Did you stop slapd and run db_recover before upgrading to 2.3.40?
I did not run db_recover. I stopped the existing version, install the new
version, and then simply started it. I thought recovery was automatically
performed by slapd now as needed?
On Mon, 4 Feb 2008, [iso-8859-1] Michael Ströder wrote:
> Paul B. Henson wrote:
> > Feb 3 03:50:36 derp idmgmt[3722]: error deleting user cjlindsay: DN index
> > delete failed (LDAP)
>
> Everything right with ownership/permissions on the data files?
Yes. Nothing had changed on the server since t
Quanah Gibson-Mount wrote:
--On Sunday, February 03, 2008 8:14 AM -0800 "Paul B. Henson"
<[EMAIL PROTECTED]> wrote:
What happened? It can't be local corruption, all three servers failed
exactly the same way. I didn't upgrade bdb, it's the exact same version
that's been running. I didn't think
--On Sunday, February 03, 2008 8:14 AM -0800 "Paul B. Henson"
<[EMAIL PROTECTED]> wrote:
What happened? It can't be local corruption, all three servers failed
exactly the same way. I didn't upgrade bdb, it's the exact same version
that's been running. I didn't think I needed to rebuild the db o
Paul B. Henson wrote:
Feb 3 03:50:36 derp idmgmt[3722]: error deleting user cjlindsay: DN index
delete failed (LDAP)
Everything right with ownership/permissions on the data files?
Ciao, Michael.
I've been running OpenLDAP 2.3.35 for almost a year with no problems
(Gentoo Linux, w/DB 4.5). I upgraded to 2.3.40 last week, and had a
meltdown this morning during an account purge.
There had been some updates to the directory after upgrading, but no
deletes. During my delete run, there were so
22 matches
Mail list logo
