Bug#1000176: bacula-director-pgsql: setup suggests no password and then rejects it
On Thu, Jun 16, 2022 at 1:01 AM Paul Gevers 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
Bug#1000176: bacula-director-pgsql: setup suggests no password and then rejects it
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. 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. 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. 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. 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 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. I assume your references to "indent" were meant as "ident". Sure. 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". Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#1000176: bacula-director-pgsql: setup suggests no password and then rejects it
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
Bug#1000176: bacula-director-pgsql: setup suggests no password and then rejects it
Control: tag -1 moreinfo Dear Ross, Your bug report below was just reassigned to dbconfig-pgsql which I maintain. On Thu, 18 Nov 2021 19:11:11 -0800 Ross Boylan wrote: Package: bacula-director-pgsql Version: 9.4.2-2+deb10u1 Severity: normal * 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. So, you ask for password based login. 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. And then you don't provide one. That's my only choice, since I never set it during PG setup (that is, when I installed PG, months ago). I hit OK. 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.' * 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. 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". 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. 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 OpenPGP_signature Description: OpenPGP digital signature
Bug#1000176: bacula-director-pgsql: setup suggests no password and then rejects it
Package: bacula-director-pgsql Version: 9.4.2-2+deb10u1 Severity: normal 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. -- System Information: Debian Release: 10.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-18-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE= (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bacula-director-pgsql depends on: iu bacula-common-pgsql 9.4.2-2+deb10u1 iu dbconfig-pgsql2.0.11+deb10u1 ii debconf [debconf-2.0] 1.5.71+deb10u1 iu postgresql-client 11+200+deb10u4 ii postgresql-client-11 [postgresql-client] 11.14-0+deb10u1 Versions of packages bacula-director-pgsql recommends: ii postgresql 11+200+deb10u4 Versions of packages bacula-director-pgsql suggests: ii gawk 1:4.2.1+dfsg-1 -- no debconf information
