Hi Christoph(s),

On 23-08-16 10:55, Christoph Berg wrote:
> I was on vacation last week and couldn't answer earlier here.

No problem (of course, I hope you enjoyed it).

> Re: Paul Gevers 2016-08-19 <b29cd791-b782-80d1-af06-2587dd2a4...@debian.org>
>> 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:

I agree.

> simple mode: assume a default config cluster, i.e. OS user "postgres",
> database user "postgres", unix socket in /var/run/postgresql/.

Sure, this works for setting up things and is what is being done, but
most programs will not be the postgres user when connecting (and mapping
to postgres also sounds like a bad idea). So the simple mode has to
still set things up correctly for the final (system) user. Currently it
uses TCP/IP and password authentication as default because (quoting the
template): "typically the system username doesn't match the database
username". It seems this default works OK(ish). I haven't seen complains
on this front yet.

> 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.

The current implementation of dbconfig is pretty close to your proposal.
As mentioned, it needs to provide the right database user and it
defaults to password authentication as that is easier, i.e. it doesn't
require the installing package to tell me what the system user will
(probably) be. I think I need to update the template for the hostname to
include some hint that an UNIX socket can also be entered (for PostgreSQL).

> If you unconditionally run the database commands as OS user
> "postgres", you don't even need to prompt the user for that variable.

On local systems, postgres it detected and used (by default). However, I
need the prompt because the database may be on a different host. Or do
you mean to say that even for remote connections, I could just make the
connection as postgres user. How about (yes unsafe) ident authentication?

> 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.

Yes, this was the reason of my e-mail, it seems like there are redundant
questions in the flow. Now I need to figure out if this is generic, or
only for the PostgreSQL case.

Thanks for you answers.

Paul

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to