Hello Hannes,
On Sun, May 7, 2006 23:57, Wagener, Johannes J wrote:
> Could it be that I am building our apps against a non ssl enabled libpq?
Sounds like it. IIRC you do need an SSL-enabled libpq, and you may also
need to link your application with the ssl library after linking to libpq.
Since you're linking statically, you'll need to rebuild libpqxx and your
application with the SSL-enabled libpq.
> Hence the "sslmode is not a valid connection option" message?
> The development machine that I compile our apps on had postgres 7.3
> installed from rpm during the initial Redhat 9 installation process.
> Since then we have moved to PostgreSQL version 8.
> I uninstalled version 7.3, renamed the libpq libraries in /usr/lib and
> created a soft link in /usr/lib to the libpq libs in
> /usr/local/pgsql/lib to try and ensure that they are from the version 8
> build. But this still did not resolve the problem.
Old libraries remaining installed somewhere is a typical problem. It
sounds to me like you did everything right--but try running "locate libpq"
to see what traces of that old library may remain on the system! Another
thing you can try is described below.
> Even if this is not the problem - How do I ensure that I build our app
> against the correct libraries from the version 8 build? (Our app is
> statically linked to libpq and libpqxx). I'm concerned that I have 2
> possible versions of the libraries on the machine. I saw several mails
> in lists that complained about SSL problems in version 7.
Yes, going to a pure 8.x setup sounds like a wise move. Also, make sure
that you have only one pg_config (there may be multiple copies or links
floating around your system, just so long as they're all identical).
Try running this in the shell:
for x in `which -a pg_config` ; do
echo -n "$x: "
"$x" | grep "^VERSION"
done
This should print only 8.x version numbers. If you see anything
different, root out the pg_config version that printed it, and run it with
its various options (--libs, --ldflags, --cppflags, --configure, ...) to
find out first: whether it is SSL-enabled and second: where its outdated
files are installed.
> I also suspected that my new iptables configuration on the database
> server might be causing the SSL connection problem.
> I flushed all the rules and changed the default policy to ACCEPT for all
> chains. But I still got the same result.
If your firewall rules got in the way, that would most likely result in
the connection being denied (you'd get an error message saying something
like "network unreachable" or "connection refused") or simply timing out.
> Is it something I have to do during the libpqxx build? (Checked the
> documentation - could not find anything related)
Nothing I can think of, no. But I haven't tried SSL connections myself.
I may be able to do that sometime in the coming day.
> Could it have something to do with my ssl certificates? I do not use
> the "root.crt" file, so the server should not request or check client
> certificates and should only use ssl for communication security
> (according to the documentation). The way I understand this is that a
> user's (apache) normal password will be used for authentication and that
> ssl will only be used to encrypt the communication between client and
> server. Is this assumption correct? (This did seem to apply when I
> tested the setup with PGAdmin3.)
I honestly don't know. It does seem to me that you'd be getting a
different error message if this were the problem--unless perhaps you're
missing something so essential that the server (or perhaps libpq)
concludes that there is no SSL support...
One thing that makes me curious though: whose password did you say was
being used? Do you mean that Apache is the user and uses its own
password, or that the user authenticates himself to Apache? In the former
case, I think you wouldn't normally use password authentication in the
first place.
> Hope I did not bore you guys too much with all the questions that are
> not even libpqxx related.
It's certainly not boring--but as you can see, it may not be the best
place to get good answers to those questions!
Jeroen
_______________________________________________
Libpqxx-general mailing list
Libpqxx-general@gborg.postgresql.org
http://gborg.postgresql.org/mailman/listinfo/libpqxx-general
