Received: from peculiarweb.com ([209.203.233.5]) by hub.org (8.8.8/8.8.8) with ESMTP id JAA11588 for ; Thu, 17 Sep 1998 09:54:10 -0400 (EDT) (envelope-from mo@midwestonline.com) Received: from loonybin (mo@peculiar.sound.net [209.153.96.230]) by peculiarweb.com (8.8.7/8.8.5) with SMTP id IAA08264 for ; Thu, 17 Sep 1998 08:51:56 -0500 (CDT) Sender: mo@peculiarweb.com Message-ID: <360113DD.4514CF1@midwestonline.com> Date: Thu, 17 Sep 1998 08:51:25 -0500 From: Midwest Online X-Mailer: Mozilla 3.04 (X11; I; Linux 2.0.0 i586) MIME-Version: 1.0 To: pgsql-interfaces@postgreSQL.org Subject: Re: [INTERFACES] getting "fe_setauthsvc: invalid name" error References: <5019.905956199@sss.pgh.pa.us> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Tom Lane wrote: > > Ah, but Clint's real problem is that he's not calling libpq directly, > but via libpq++. And as far as I can see, libpq++ doesn't have any way > to open a connection except by calling plain old PQsetdb. This needs to > be fixed. (We should add an entry point to libpq++ that corresponds to > PQconnectdb, so that the connection parameters are passed through as a > single string and libpq++ doesn't have to know about each and every one > of 'em.) > > The short-term workaround is what you mention next: > > > It's so easy... If you should want to set environment variables anyway: > > environ(5), getenv(3) and putenv(3) tell you how. > > Setting PGUSER (and PGPASSWORD if needed) env. variables will provide a > way to pass these items to libpq despite the lack of any cooperation > from libpq++. Bingo! Tom, what you said about PGUSER triggered something I was wondering about: if running as a virtual web server was different (and how) from running at the command line. Here's the fix I used: I used some C code from the examples directory to make the same connection through the web server. I still wasn't getting connected, but at least the error message in the server's log was informative: it said it failed during a call to getprotobyname(). I had no clue what it was, but looked it up. It says that it reads /etc/protocols. I somehow "knew" that /etc/protocols didn't exist while running through the web server; our hosting company had mentioned before that the file permissions, etc. are different - more protected - from httpd. So, the easy fix was to copy /etc/protocols to ~/etc/protocols (a directory "readable" from our virtual server's httpd process. It worked like a charm. :) I have no clue if it's a "legitimate" fix, or if any harm can be done, but for now it's staying. :) Thanks go out to Tom Lane and everybody that offered help! Clint ---------------------------------------------------------------------------- Belinda & Clint Forgy Midwest Online PeculiarWeb Internet Designs http://www.midwestonline.com http://www.peculiarweb.com