Getting "DSO" failed to load when trying to access a DBM password file

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Getting "DSO" failed to load when trying to access a DBM password file

Tom Browder
I'm using locally built Apache 2.4.43 with Apr 1.7.0 and Apr-util 1.6.1 on Debian Buster. I'm trying to use DBM password files I built with an earlier version (approx 2.4.30ish) which worked fine. 

I got a complaint from a user he couldn't log in and I saw in the error logs that the password file couldn't be read. I discovered some gdbm dev packages missing, installed them, and rebuilt apr, apr-util, and httpd. I also discovered neither htdbm nor dbmmanage could not connect to a password file named x.y.dbm! I renamed them x.y.dat and dbmmanage can read it but htdbm cannot.

My current error logs still show the following error:

  DSO load failed: [client 1.2.3.4:56931] AH01754: could not open dbm (type DB) auth file:
    /opt/data/passwords/examplecom.dat, referer: https://example.com/
I'm out of airspeed and ideas.

Thanks.

-Tom

Reply | Threaded
Open this post in threaded view
|

Re: Getting "DSO" failed to load when trying to access a DBM password file

Tom Browder
On Sun, Jun 28, 2020 at 18:19 Tom Browder <[hidden email]> wrote:
I'm using locally built Apache 2.4.43 with Apr 1.7.0 and Apr-util 1.6.1 on Debian Buster. I'm trying to use DBM password files I built with an earlier version (approx 2.4.30ish) which worked fine. 
...

PROBLEM SOLVED

The problem was very subtle (at least to me). In the APU build config I needed to add:

    --enable-berkeley-db

and needed to install the obscure Debian package "libdb5.3-dev" to get the correct header and library.

So my password acess now works.

I now recall agonizing days years ago trying to get all the pieces to work. I think I may go back to dropping the apr and apr util source inside httpd and see if that helps.

Even though I got this problem solved, APU config still can't find my postgresql on the same server. But it can on its sister server!

The configure system is showing its age because it has lots of trouble finding db requirements (and always has, at least for the last ten years).

Cheers!

-Tom