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

RE: Openlap and BDB updates: update question



> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Ace Suares

> > This is has nothing to do with anything under our control;

> Do users of openldap expect you to 'control' things ?

Generally one raises a complaint because one is seeking a resolution. If a
complaint is raised on this forum, that implies that someone here ought to do
something about it. But a complaint directed to the wrong people serves no
purpose. I think Tony's a sharp guy. When he ends a post with

  > But it's not just Openldap: Other completely independent
  > services linked
  > with BDB have to be recompiled too. Hassle upon hassle.

that sounds to me like a complaint about BDB. If I thought it was a
meaningless post I would have just ignored it, but instead I responded with
advice to contact the folks who would know best - Sleepycat.

> Why are you so fed up with questions from users ?

If I were simply fed up, I would not bother posting at all. You seem to be
misinterpreting quite a bit of my post.

> > the OpenLDAP
> > build procedures in 2.1 and 2.2 are mostly unchanged and on
> > a frozen build
> > system, produce nearly identical results:
>
> So, on YOUR system it does what it's supposed to do. On mine
> and Tony's, it
> doesn't. Stop bitching about how stupid we are. Start
> thinking what could be
> the problem. Or divert your time to problems that you can
> understand...
>
> Why do you need to shun us ? What's the benefit in that, for Symas
> Incorporated, or for you personally ?
>
> What I am trying to say is

It looks to me like you're the one getting personal here. There was nothing
personal in any of my previous messages. Obviously I have nothing to gain on
any front by making personal attacks.

> > As Kurt already tried to point out on a previous posting to
> this list, if
> > you want to make effective use of the software and the
> resources available
> > to you, you have to pay attention to where the boundaries
> lie. If you have
> > a problem with any piece of code that is not part of the
> OpenLDAP source
> > distribution, then it's not under our control. Go to the people who
> > actually are responsible for that chunk of software.
>
> That is too easy said. I would never dream of downloading and
> compiling BDB if
> it weren't for openLDAP. BDB is, from the users point of
> view, an integral
> part of openLDAP. See the many discussions about ldbm vs bdb before.
>
> Maybe the users have a wrong view - I can't argue with that,
> but nevertheless, that's how most people will see it.

Whatever number of people hold a false perception doesn't make it right. If
you don't want correct information, we can all save ourselves a lot of time.

> Every user that asks about back-xxx gets the advice to use
> back-bdb (and I am
> sure soon users will be adviced to use back-hdb).

The question of back-ldbm vs back-bdb is interesting in its own right, but
not relevant here since both will use the BDB library. This just highlights
the point I've tried to make so many times before - without attention to
detail you get nowhere. back-bdb is not BerkeleyDB, much like SSL/TLS is not
StartTLS. You ignore the distinction to your own detriment.

> Users are NOT holding you or any developer resonsible for
> their problems.

Perhaps not. As a developer I hold myself responsible for problems that arise
in this code base. It's something to do with ego and professional pride.
Sometimes ego can be a pain. But usually it results in greater care being
taken and better quality resulting.

> But users want to know what went wrong. If something went wrong
> with compling
> openldap (like statically linking bdb) where's the first place I go ?
> To THIS list. Because it happened when compiling openldap.
> Not when compiling bdb!

Yes. And when people have trouble getting their LDAP-based Linux
authentication working, this seems to be the first place they go too, but
that doesn't mean it's right.

> Is my recent problem with ipv6 a problem of ipv6, SuSE,
> libtool, make, ls, or
> openldap ? I discovered it only when using openldap. I didn't
> change any
> thing with ipv6. I didn't even know it was enabeld. On top of
> that, it's an intermittent problem.
>
> So I go to the openLDAP list. Does that make sense ?

Sure, and that is an actual question about the behavior of the OpenLDAP
software.

> > When you see a "sudden" change in the code characteristics,
> you have to
> > take into account all the other possible changes that have
> occurred between
> > your "point A" and "point B" and these are things that you
> as a system
> > administrator are personally responsible for.
>
> Maybe the openldap developers forgot to mention that
> something changed ? Is
> that such an unlikely option ? You're logic is cyclic.

There's nothing cyclical in the previous statement.

> > It's not our job to tell you
> > or keep track for you "oh by the way, make sure the file
> permissions allow
> > the program to execute" or "oh make sure you have enough
> disk space and
> > memory" or "make sure your kernel has the latest patch" -
> these issues are
> > implicit in software/system management and are for you to
> take care of
> > yourself.

> Silly.
> Why would my kernel need patching for compiling openldap ?
> I mean, if openldap doesn't work on anything pre 2.7, I need
> to read that
> clearly in the openldap docs. If nothing is mentioned about
> kernels, I do NOT
> expect that I need 'the latest kernel patch'.

Indeed, why would you need an OS patch to use OpenLDAP? I can't think of a
good reason either, but then you run into RedHat 7, 9.0... The OpenLDAP docs
say essentially, "use the latest available version of all requisite
software." To be more specific would be unmanageable. You as sysadmin have to
maintain your base system in stable working order.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support