Dear Maintainer,

   * What led up to the situation?
   My 2nd attempt to install bacula after initial failure of
   Bug#1000174.
   Because of that, configuration asks lower-priority questions.
   I requested password based login and gave a FQDN for the PG server.
   I get to this screen
 │ Please provide the password for the postgres account with which this package should perform administrative actions.       │
 │                                                                                                                           │
 │ For a standard PostgreSQL installation, a database password is not required, since authentication is done at the system   │
 │ level.                                                                                                                    │
 │                                                                                                                           │
 │ Password of your database's administrative user:

   * What exactly did you do (or not do) that was effective (or
     ineffective)?
   Left the password field blank.  That's my only choice, since I
   never set it during PG setup (that is, when I installed PG, months
     ago).  I hit OK.

   * What was the outcome of this action?
   | Empty passwords unsupported with PostgreSQL |
   with the only choice being OK, which takes me back to prior screen.

   * What outcome did you expect instead?
   That the configuration would accept my omission of the password
   since the earlier step recommended it!  And that the omission
   would be possible, since I do have the standard setup in which it
   is not set.

Comment: The host name I set for the PG database is an alias for the
same machine on which I'm installing bacula.  It's unclear to me if
that will confuse the installer and subsequent operations about
whether it's the same.  I did accept the default tcp/ip communication
with the database.

Next step: I'm not sure.  Several alternatives:
1. tell the setup not to use dbconfig and clean things up afterward.
2. enter a bogus password to get past this step and hope it will be
ignored.
3. set a real password for the postgres user and then enter that.

Hi Paul,

these two bugs happen during the dbconfig actions, so I'm reassigning
them there.

Regards

Carsten

Dear Ross,

Your bug report below was just reassigned to dbconfig-pgsql which I
maintain.

So, you ask for password based login.

And then you don't provide one.

That sound normal because "For a standard PostgreSQL installation, a
database password is not required, since authentication is done at the
system" which means you shouldn't have picked "password" but rather
"indent". I agree that the text in your case may have been a bit
confusing, but it didn't meant "empty password", it meant "don't use
password" (but that a bit superfluous as the previous screen also said
that: 'For a standard PostgreSQL installation running on the same host,
  "ident" is recommended.'

I think your conflating two things here, which we can *maybe* fix with
improved texts. You were asked what kind of authentication you wanted to
do, "indent" or "password". You choose "password", went on not providing
a password, but that's not supported by psql. If you wanted
password-less authentication you should instead have chosen "indent".

I'm not totally sure I follow as I'm not totally fluent with psql server
setup. I *think* that with tcp/ip, you can't use local machine "ident",
so then without password you'd get 'With "ident" authentication to
remote hosts, RFC-1413-based ident is used (which can be considered a
security risk).' Because of the security risk, I think you *don't* want
to use "ident", or really setup psql as a local machine and use local
"ident", or use passwords of tcp/ip. But with the first or third option
  you are not "a standard PostgreSQL installation" so that text doesn't
apply and you have to use a password if you choose to use "password" setup.

Paul

Thanks for your response. It's not clear to me  what more information
you want; you seem to be following what I did pretty well.

On rereading, I notice an additional ambiguity.  I believe I read
"postgres account with which this package should perform
administrative actions." as meaning the sql account *named* postgres
(or, more generally, the overall sql admin account, which defaults to
be postgres), which has overall admin rights for all postgres
databases.  Partly this is because the setup clearly needs to start
from there in order to create the bacula user!  I now suspect the
intended meaning is the account this package will use, i.e., bacula.
There is also some ambiguity in whether account refers to a database
account (so postgres is an adjective describing the account type) or a
linux account, though in context it seemed to me all references were
to database accounts.

So I think I was attempting to navigate the responses when I had set a
password for bacula but not postgres, and interpreting various
questions as referring to one or the other.  I interpreted the first
question as being about the bacula sql account (password) and the
second as being about the postgres sql account (no password).

My hope is that the setup questions not lead to a dead end, or the
revelation in question #2 of information necessary to answer question
#1 properly.  And I also hope the installer can cope with this split
situation of a password for one account (bacula) but not the other
(postgres).  I know I did eventually get it all working.

Some bacula-specific context may be relevant: there needs to be remote
access to the bacula database since clients may be on different
machines.  Since ident is insecure on a network, that means the bacula
database should have a password, as well as the necessary
configuration to permit remote access using passwords.  So this hybrid
situation (ident only for posgres db user and no password; password
for bacula) seems likely to arise in practice.

I assume your references to "indent" were meant as "ident".

I'm pretty sure postgres allows multiple authentication mechanisms so
one could access accounts on the local machine using ident and access
the same accounts remotely using a password.  The configuration
includes restrictions on which hosts and can use which mechanisms.

My concern about multiple names was mostly that either the installer
or postgres itself would get confused about whether access was local
or remote if postgres is installed with a system name of, e.g.,
pg.me.org and bacula is installed with a name of bac.me.org, but those
are aliases for the same machine.

Ross

Hi Ross,

Correct.

Indeed.

I think your first reading was correct and this one isn't. When we talk
about "administrative actions" it's the `postgres` (or equivalent) psql
account.

We spent a lot of time getting the templates right. Improvements
suggestions are always welcome, but I'll have them reviewed by the
i18n-english list as I'm not a native speaker. At some moment, you also
run into problems when trying to use language that is to be understood
by both psql experts as well as "I don't care about psql, I just want to
get this package running that uses psql"-admins.

"administrative actions" means the postgres sql account.

The dbconfig-common questions build up a state machine and all questions
should have the option to go back IIRC. Upon failure, you should be
offered the option to answer all relevant questions again. If that isn't
the case, that's a serious bug.

Absolutely. Again, if that's not the case, that's a serious bug.

I would hope that the bacula Debian maintainer provides enough
information to the system admin to make the right choices if it isn't
obvious how to setup bacula. It's very well possible that the *defaults*
are not suitable for real use of bacula, but dbconfig-common is meant to
provide all the logic needed to do this such that individual packages
don't need to implement it by themselves. Database requiring packages
should not need to have the database server on the same host, so this is
more complex than normal package dependencies. It's good to have that
logic in one place.

Sure.

You may be right here, but I think if you want such complexity, you can
manage that manually. I believe this is beyond the scope of debconf
questions.

I can't comment on this at this moment because I don't currently
understand what it means that "$(package) is installed with a system name".

Paul

So, while the ambiguity of that wording may be a problem, it's
probably not what led
to the problem reported in this bug.

Was the first question about whether to use a password-based login
supposed to refer
to the postgres or  the bacula account?  I may have made the inverse
mistake with that earlier
question, assuming it was asking about bacula when it was about postgres.

I am a native speaker, but a confused one :(.

It really is a big, fat mess because there are so many terms that have
multiple meanings:

account  = database account (technically a role in postgres db, I
think), or an OS level
          account (as in /etc/passwd).  And I suppose it could be a
kerberos or Windows AD account too.
postgres = the name of a database, the software running the database,
the name of a user on that database,
         an adjective distinguishing a database account from an OS account
administrative = referring to the master user for the database cluster
(typically named postgres), the owner of a particular
         database (I think that's bacula for the bacula db), the
corresponding OS accounts, the OS root account,
         or a process operating with elevated privileges at the OS or
database level.
bacula = name of software, name of OS account, reference to the
running server (which is actually a bunch of servers),
        name of a postgres role, name of a postgres database, adjective.

I saw no way to go back; I just got stuck trying to answer a question
that had no acceptable answer.
Or maybe I went back, but didn't think the alternative response
(ident) was right?

Does it need to be asking 2 sets of questions about the 2 accounts then?

Since dbconfig in principle could be run for a bunch of different
packages, the ideal handling
seems different for the postgres and bacula sql accounts.  Ideally the
method of accessing the
master=admin=postgres account would be recorded when the database was set up
(potentially vulnerable to subsequent changes by the admin), or
inferred from the current
configuration, while each package would need to set up its own account(s).

I know I have had repeated problems with the setup, and I think I saw
lots of complaints about it for Ubuntu.
The Ubuntu complaints about bacula were mostly variations of "This
package (bacula) sucks, I can't even get
it to run."
...

My recollection is hazy, but bacula certainly asks for the name of the
host (for bacula and maybe for the database)
during setup, cautioning not to use localhost since the hostname is
sent to clients so they can
communicate back.  I think postgres also has some options to configure
the name of the
host, but I'm not sure about it and even less sure that the setup asks about it.

As you mention above, the database server and the bacula server may be
 on different machines.
Referring to the 2 with different hostnames provides potential future
proofing about
splitting them up.

Ross