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

RE: BDB recovery after power outage



Title: RE: BDB recovery after power outage

Frank -

Agreed and well said.

I'd like to add that often the response is:  get writing
or "write something" ..

My issue is here, I have seen enough HOWTOs that
look as if they created the document during their first
introduction and run through with the application/system.

I know from experience that my first (few) installs are
typically not optimal.  Maybe it could be argued that
the point is not to be optimal right away, but I argue
a novice writing a HOWTO can actually do more
damage spreading poor design / implementation.

An example of this are the HOWTOs that will tell
you EXACTLY what to put in a file to get EXACTLY
what the writer installed.  No flexibility - and no
real explanation WHY you are doing anything.

simply do this or else.  You will end up with this
functionality (maybe).

If we try to integrate LDAP and SASL, we're told
to go to the SASL list... if we try to integrate with
Kerberos, we're told to go to the kerberos list....
over there, if we mention ldap, we're told to go
here.  I'm giving this as an example of what
tends to happen, not what has happened to me
explicitly recently.

What we need is someone who can actually get
any of this cruft working to write a document that
states how to get the minimal application working...
how to test, how to verify... how to recover. etc.

Then add to this, how to put in, say, SSL...
how to verify that it's there... how to debug.
how to REMOVE.

for each part, etc.

Instead, we get documents that may have worked one
time with very specific versions, etc.


I think it's just that open software people are quite
use to their own world and maybe do not realize
that not everyone is an expert in what they are
an expert in.  Not everyone is a programmer.
Not everyone SHOULd be writing and supplying
patches.

I can understand someone not wanting to devote
time to this when the application is something like
a pager, or something simple... but when it's as
complicated and, in my opinion, overly obtuse as
LDAP/SASL/SSL/KERBEROS/ETC - there should
be VERY detailed documentation.

Case and point... I recently was working with a
PDA and an open source OS replacement.  I had,
of course, many many many issues with the PDA
and open source OS replacement.  I struggled to
find any resource and when I found a few, I asked
questions - so many so that I was quickly
admonished, no berated... and told to first read
(all the) FAQs and all the mailing list archives.

The mailing list archives were offline.  I then read
the FAQ.  As a complete newbie, I found error
or misleading statements in over 40% of the
FAQs... with as basic as like "Will OS replacement
support device MYDEVICE" ... answer : NO.
Of course, I was running OS replacement on
MYDEVICE.

I think I have gone on long enough - but I hope
everyone understands Frank's point.. and I hope
some people at least read this far to see what
my point was.

Scott


-----Original Message-----
From: Frank Swasey [mailto:Frank.Swasey@uvm.edu]
Sent: Monday, April 21, 2003 12:44 PM
To: Quanah Gibson-Mount
Cc: openldap-software@OpenLDAP.org
Subject: RE: BDB recovery after power outage

Today at 6:42am, Quanah Gibson-Mount wrote:

> To say that BDB is not a viable backend because one has not taken the time
> to investigate how to use the software is flawed.

I agree with your point.  I have not taken the time necessary to fully
understand BDB.  However, I have experimented with BDB backend.  I have
used it in test instances and have found it to not perform as well as
LDBM/Berkeley.  I do not have the time to read the programmer's
reference that Sleepycat has made available and figure out what a BDB
database admin needs to know.  Sleepycat has (to my knowledge) not made
a BDB DBA's guide available.  You are required to read the Programmer's
API reference and infer what a DBA needs to do.  I am not a DBA, I am a
systems administrator/programmer.  I don't have any interest in becoming
a DBA and all my DBA's have no interest in anything other than Oracle.

Therefore, I think the correct point is that unless you are a skilled
BDB DBA, you should not be using the BDB backend until someone who is a
skilled BDB DBA puts together a guide to what you need to know to use
BDB with OpenLDAP.

Now, Howard stated that the BDB backend originally did the db_recover
for you.  I haven't seen any mention that that had changed (prior to
Howard's announcement here over the weekend) and as I stated, there's no
mention of db_recover in any of the OpenLDAP documentation (nor based on
a find . -type f | xargs grep db_recover) in any of the OpenLDAP source
files -- so there isn't even a programmatical comment that it had been
removed.

My real concern here is that I see the BDB backend as being pushed but
there seems to be a refusal to even deal with the issue of putting
together a quick start document about what the beginning BDB backend DBA
needs to know.  Yes, I do feel that is something that needs to come out
of the OpenLDAP documentation because it is OpenLDAP that is using BDB.
Would it be nice if Sleepycat provided that documentation -- hell yes.
Are they going to?  I'm not going to hold my breath.

--
Frank Swasey                    | http://www.uvm.edu/~fcs
Systems Programmer              | Always remember: You are UNIQUE,
University of Vermont           |    just like everyone else.
                    === God Bless Us All ===


This mail message originated outside Commerzbank via the Internet. As a result, the sender's address is not verifiable.



**********************************************************************
This communication is confidential and is intended only for the person to whom it is addressed. If you are not that person you are not permitted to make use of the information and you are requested to notify Commerzbank Aktiengesellschaft, New York Branch immediately that you have received it and then to destroy the copy in your possession. Views expressed in this e-mail do not necessarily reflect the views of Commerzbank AG.
**********************************************************************