On Fri, Apr 08, 2005 at 09:15:07PM +0100, Oliver Elphick wrote: > On Fri, 2005-04-08 at 09:54 -0700, Ross Boylan wrote: > ... > > Here's the fuller explanation I sent to debian-user: > > ------------------------------------------------------ > > I am trying to use a GUI to do some work on a local postgres database. > > I was using pgaccess a year ago, but recently found it couldn't > > connect because of an ident failure. I've tried a bunch of other > > tools (pgamdin3, knoda, mergeant, and gnome-db) with mostly the same > > problem. > > > > I have not messed with the default authorization and access settings > > for postgres. > > > > Since I can connect with psql, I developed a theory: the front ends > > only connect with tcp, not sockets (I have tried a blank hostname a > > few times). > > > > I needed to do all the following to make things work: > > * install a package providing identd (I used midentd) > > * Enable the service in /etc/inetd.conf > > In this case, I used > > auth stream tcp nowait identd /usr/sbin/midentd midentd > > > > The line in the file by default uses ident as the first field; I don't > > know if that matters. (I suspect it doesn't, because with both > > present I got an error about duplicate entries). > > > > The default specifies /usr/sbin/identd, but that wasn't present > > (should there be some /etc/alternatives going on so this works?). > > I tried several identd packages before I found one that worked > (pidentd). Others would fail for no apparent reason; once I found one > that worked, I never got to the bottom of why the others didn't. > > I think midentd was one of the ones that didn't work.
Oh, my. When even the maintainer has problems, you know you're in trouble :) I have a feeling a lot of people may hit this issue and just give up. As detailed in my message, I had to apply several tweaks to get midentd working. Neither the suggestion shipped with midentd nor the line in the standard inetd.conf worked; I had to combine and adjust to get something going. I've since found that a number of the clients do use sockets if you leave the host empty; I guess I had the misfortune of trying that trick on pgadmin3, which doesn't support it (there is a wishlist bug requesting that feature, and it sounds as if upstream has done it, or at least plans to). Kind of a bummer, as allowing the service to run increases security risks. Would a default using passwords for TCP from the localhost be a viable alternative? It sounds as if postgres may lack the permissions to compare against system passwords on its own. Maybe cyrus sasl authentication would work (though that's pretty tricky to set up, so it probably doesn't help)? This could be combined with database specific passwords, but that's kind of ugly, and another kind of security risk.... Failing that, a general message in the README "try to connect with Unix sockets. For many clients, this is done by leaving the host field blank." might help. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
