Hi, I was on vacation last week and couldn't answer earlier here.
Re: Paul Gevers 2016-08-19 <b29cd791-b782-80d1-af06-2587dd2a4...@debian.org> > Would you agree with me, i.e. do you know the following to be true, that > peer authentication requires Unix socket (localhost) This is true. > and that Unix socket requires peer identification for PostgreSQL? This is true in the default config (pg_createcluster), but can be set to various other authentication mechanisms, the most widely used next to "peer" being "md5", but it could also be "pam", "ldap", and others. > I tried the other day to have password authentication via the Unix > socket, but that failed: > root@sid:/# psql -U icinga234 -W > Password for user icinga234: > psql: FATAL: Peer authentication failed for user "icinga234" You can't force the use of password authentication, the server will always use the authentication method configured in pg_hba.conf, based on the client connection parameters (unix vs tcp/ip, user name, database name, IP address). The psql -W parameter is mostly useless in practise. > If this is true, I think it warrants some improved logic during config. > > By the way, I see that PostgreSQL has a lot more authentication > possibilities than when Sean invented dbconfig. I don't think I am going > to support this on the short/mid term, but it may warrant improved > messages here and there. I don't think you should be trying to implement too much logic on the dbconfig-common side here. I'd suggest this: simple mode: assume a default config cluster, i.e. OS user "postgres", database user "postgres", unix socket in /var/run/postgresql/. advanced mode: Ask the user for * database hostname, or blank for default "/var/run/postgresql" or a full path name for different UNIX socket * database (super)user (default postgres) * database password (default blank which suits peer authentication) * whatever other parameters dbconfig-common wants (DB to create, DB user to create if not existing) You can prompt the user which way they want; simple mode should be the default. If you unconditionally run the database commands as OS user "postgres", you don't even need to prompt the user for that variable. (The case of non-postgres clusters using peer UNIX socket authentication would be left unsupported, but that's rare, and the user can easily provide a password that works via TCP/IP on localhost.) Note that in the above scheme you don't need to know which authentication method the server is using, or if the connection is TCP/IP or a UNIX socket, everything should Just Work. Christoph
signature.asc
Description: PGP signature
