On Thu, Jun 16, 2022 at 1:01 AM Paul Gevers <elb...@debian.org> wrote:
>
> Hi Ross,
>
> On 15-06-2022 23:46, Ross Boylan wrote:
> > 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.
>
> Correct.
>
> > Partly this is because the setup clearly needs to start
> > from there in order to create the bacula user!
>
> Indeed.
>
> > I now suspect the
> > intended meaning is the account this package will use, i.e., bacula.
>
> 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.
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.
>
> > 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.
>
> 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.
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.
>
> > 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).
>
> "administrative actions" means the postgres sql account.
>
> > 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.
>
> 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.
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?
>
> > And I also hope the installer can cope with this split
> > situation of a password for one account (bacula) but not the other
> > (postgres).
>
> Absolutely. Again, if that's not the case, that's a serious bug.
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).
>
> > 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 postgres db user and no password; password
> > for bacula) seems likely to arise in practice.
>
> 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 set up bacula.
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."
>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.
...
>
> > 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.
>
> 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.
>
> > 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.
>
> 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".
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
