Bug#1108272: [pkg-bacula-devel] Bug#1108272: bacula-director-pgsql: update_postgresql_tables script fails due to bad shell quoting
Carsten Leonhardt writes: > I've implemented it and it seems much more elegant - just a call to sed > instead of a patch that needs manual attention when things change. When > I have time I'll do a binary comparison of the resulting packages. > > It's in the branch unescape-shell-quoting. When we apply this, it also addresses Ubuntu bug 1882032.
Bug#1108272: bacula-director-pgsql: update_postgresql_tables script fails due to bad shell quoting
Control: severity -1 normal This bug does not fit the severity "important" as it does not have "a major effect on the usability" of the package.
Bug#1108272: [pkg-bacula-devel] Bug#1108272: bacula-director-pgsql: update_postgresql_tables script fails due to bad shell quoting
Sven Hartge writes: > I can see the correct quotation of $$ in the source for that script, > but this seems to get mangled during build. I wonder if I should rework the database stuff so that it will shell-unquote during the extraction process and not patch the upstream scripts, so that people can still use them as-is if they want. I think that would be better overall. (Some time later) I've implemented it and it seems much more elegant - just a call to sed instead of a patch that needs manual attention when things change. When I have time I'll do a binary comparison of the resulting packages. It's in the branch unescape-shell-quoting. - Carsten
Bug#1108272: [pkg-bacula-devel] Bug#1108272: bacula-director-pgsql: update_postgresql_tables script fails due to bad shell quoting
Hi Wouter, Wouter Verhelst writes: > So debconf-show bacula-director-pgsql shows me this, amongst others: > > * bacula-director-pgsql/dbconfig-upgrade: false > > Which indicates that perhaps, somehow, it is indeed disabled. This is > not what I wanted. > > I don't remember manually setting this option. When I run > "dpkg-reconfigure -plow bacula-director-pgsql" to correct it, it asks me > if I want to *reinstall* the database (which I read as "throw away > everything in your catalog away and start from scratch", which is a hard > "no"), but does not ask me the question about upgrading. > > This feels wrong on so many levels. I'm not sure whether this is decided > in dbconfig-common or in bacula, but if the latter, please fix that :-) I'd recommend that you use an editor to set dbc_upgrade='true' in /etc/dbconfig-common/bacula-director-pgsql.conf. That will make future upgrades work. In the debconf information included in the original bug report the corresponding line starts with an '*'. That probably means that it was set to deviate from the default via debconf. How that happened is a question that will be hard to answer. Which version of bacula did you start your deployment with originally? Groetjes, Carsten
Bug#1108272: bacula-director-pgsql: update_postgresql_tables script fails due to bad shell quoting
Hi Sven, On Thu, Jun 26, 2025 at 07:03:38AM +0200, Sven Hartge wrote: > On 24.06.25 18:18, Wouter Verhelst wrote: > > > I installed the bacula director from backports, so that my laptop (which > > runs unstable) can still be backed up to my server (which runs stable). > > > > After the upgrade to bacula 15, I noticed that my director was no longer > > running. Checking the logs, I found the following: > > > > 24-jun 18:00 bacula-dir JobId 0: Fatal error: Version error for database > > "bacula". Wanted 1026, got 1024 > > 24-jun 18:00 bacula-dir JobId 0: Fatal error: Could not open Catalog > > "MyCatalog", database "bacula". > > 24-jun 18:00 bacula-dir JobId 0: Fatal error: Version error for database > > "bacula". Wanted 1026, got 1024 > > 24-jun 18:00 bacula-dir ERROR TERMINATION > > Interesting that the Upgrade Script via dbconfig did not run. Have you > configured the bacula packages to not use dbconfig? Or has some sequence > caused it to fail? So debconf-show bacula-director-pgsql shows me this, amongst others: * bacula-director-pgsql/dbconfig-upgrade: false Which indicates that perhaps, somehow, it is indeed disabled. This is not what I wanted. I don't remember manually setting this option. When I run "dpkg-reconfigure -plow bacula-director-pgsql" to correct it, it asks me if I want to *reinstall* the database (which I read as "throw away everything in your catalog away and start from scratch", which is a hard "no"), but does not ask me the question about upgrading. This feels wrong on so many levels. I'm not sure whether this is decided in dbconfig-common or in bacula, but if the latter, please fix that :-) > Could you check apts history or term logs to check of anything related to > the upgrade? Given the above, I doubt it matters anymore, but regardless, the output of "grep bacula /var/lib/dpkg.log" on the machine follows. Note that it mentions "13.0.4-1", as I initially upgraded to the unstable version before there was a version in backports. I don't know whether this is relevant or not. 2025-06-22 15:29:27 upgrade bacula-director:amd64 13.0.4-1 15.0.3-1~bpo12+1 2025-06-22 15:29:27 status half-configured bacula-director:amd64 13.0.4-1 2025-06-22 15:29:27 status unpacked bacula-director:amd64 13.0.4-1 2025-06-22 15:29:27 status half-installed bacula-director:amd64 13.0.4-1 2025-06-22 15:29:27 status unpacked bacula-director:amd64 15.0.3-1~bpo12+1 2025-06-22 15:29:28 upgrade bacula-director-pgsql:all 13.0.4-1 15.0.3-1~bpo12+1 2025-06-22 15:29:28 status half-configured bacula-director-pgsql:all 13.0.4-1 2025-06-22 15:29:28 status unpacked bacula-director-pgsql:all 13.0.4-1 2025-06-22 15:29:28 status half-installed bacula-director-pgsql:all 13.0.4-1 2025-06-22 15:29:29 status unpacked bacula-director-pgsql:all 15.0.3-1~bpo12+1 2025-06-22 15:29:29 upgrade bacula-bscan:amd64 13.0.4-1 15.0.3-1~bpo12+1 2025-06-22 15:29:29 status half-configured bacula-bscan:amd64 13.0.4-1 2025-06-22 15:29:29 status unpacked bacula-bscan:amd64 13.0.4-1 2025-06-22 15:29:29 status half-installed bacula-bscan:amd64 13.0.4-1 2025-06-22 15:29:29 status unpacked bacula-bscan:amd64 15.0.3-1~bpo12+1 2025-06-22 15:29:29 upgrade bacula-common-pgsql:amd64 13.0.4-1 15.0.3-1~bpo12+1 2025-06-22 15:29:29 status half-configured bacula-common-pgsql:amd64 13.0.4-1 2025-06-22 15:29:29 status unpacked bacula-common-pgsql:amd64 13.0.4-1 2025-06-22 15:29:29 status half-installed bacula-common-pgsql:amd64 13.0.4-1 2025-06-22 15:29:29 status unpacked bacula-common-pgsql:amd64 15.0.3-1~bpo12+1 2025-06-22 15:29:29 upgrade bacula-sd:amd64 13.0.4-1 15.0.3-1~bpo12+1 2025-06-22 15:29:29 status half-configured bacula-sd:amd64 13.0.4-1 2025-06-22 15:29:30 status unpacked bacula-sd:amd64 13.0.4-1 2025-06-22 15:29:30 status half-installed bacula-sd:amd64 13.0.4-1 2025-06-22 15:29:30 status unpacked bacula-sd:amd64 15.0.3-1~bpo12+1 2025-06-22 15:29:30 upgrade bacula-tray-monitor:amd64 13.0.4-1 15.0.3-1~bpo12+1 2025-06-22 15:29:30 status half-configured bacula-tray-monitor:amd64 13.0.4-1 2025-06-22 15:29:30 status unpacked bacula-tray-monitor:amd64 13.0.4-1 2025-06-22 15:29:30 status half-installed bacula-tray-monitor:amd64 13.0.4-1 2025-06-22 15:29:30 status unpacked bacula-tray-monitor:amd64 15.0.3-1~bpo12+1 2025-06-22 15:29:31 upgrade bacula-fd:amd64 13.0.4-1 15.0.3-1~bpo12+1 2025-06-22 15:29:31 status half-configured bacula-fd:amd64 13.0.4-1 2025-06-22 15:29:31 status unpacked bacula-fd:amd64 13.0.4-1 2025-06-22 15:29:31 status half-installed bacula-fd:amd64 13.0.4-1 2025-06-22 15:29:31 status unpacked bacula-fd:amd64 15.0.3-1~bpo12+1 2025-06-22 15:29:31 upgrade bacula-console-qt:amd64 13.0.4-1 15.0.3-1~bpo12+1 2025-06-22 15:29:31 status half-configured bacula-console-qt:amd64 13.0.4-1 2025-06-22 15:29:31 status unpacked bacula-console-qt:amd64 13.0.4-1 2025-06-22 15:29:31 status half-installed bacula-console-qt:amd64 13.0.4-1 2025-06-22 15:29:31 status unpacked bacula-console-qt:amd64 15.0.3-1~bpo12+1 2025-06-22 15:29:31 upgrade bacula-co
Bug#1108272: bacula-director-pgsql: update_postgresql_tables script fails due to bad shell quoting
On 24.06.25 18:18, Wouter Verhelst wrote: I installed the bacula director from backports, so that my laptop (which runs unstable) can still be backed up to my server (which runs stable). After the upgrade to bacula 15, I noticed that my director was no longer running. Checking the logs, I found the following: 24-jun 18:00 bacula-dir JobId 0: Fatal error: Version error for database "bacula". Wanted 1026, got 1024 24-jun 18:00 bacula-dir JobId 0: Fatal error: Could not open Catalog "MyCatalog", database "bacula". 24-jun 18:00 bacula-dir JobId 0: Fatal error: Version error for database "bacula". Wanted 1026, got 1024 24-jun 18:00 bacula-dir ERROR TERMINATION Interesting that the Upgrade Script via dbconfig did not run. Have you configured the bacula packages to not use dbconfig? Or has some sequence caused it to fail? Could you check apts history or term logs to check of anything related to the upgrade? This surprised me, because obviously there's a script to handle this. So I ran it manually, and received errors about SQL syntax where it said "do ". Checking the script, I quickly found the problem. Here's a patch that solved it for me: --- update_postgresql_tables.orig 2025-06-24 18:14:43.055571381 +0200 +++ update_postgresql_tables2025-06-24 18:15:04.866426330 +0200 That is upstreams script that is not used directly by the packages, which use an extracted version via dbconfig, so that bug will not directly affect users using the Debian-way-of-things to maintain the database. I can see the correct quotation of $$ in the source for that script, but this seems to get mangled during build. Grüße, Sven.
Bug#1108272: bacula-director-pgsql: update_postgresql_tables script fails due to bad shell quoting
Package: bacula-director-pgsql Version: 15.0.3-1~bpo12+1 Severity: important X-Debbugs-Cc: [email protected] Hi, I installed the bacula director from backports, so that my laptop (which runs unstable) can still be backed up to my server (which runs stable). After the upgrade to bacula 15, I noticed that my director was no longer running. Checking the logs, I found the following: 24-jun 18:00 bacula-dir JobId 0: Fatal error: Version error for database "bacula". Wanted 1026, got 1024 24-jun 18:00 bacula-dir JobId 0: Fatal error: Could not open Catalog "MyCatalog", database "bacula". 24-jun 18:00 bacula-dir JobId 0: Fatal error: Version error for database "bacula". Wanted 1026, got 1024 24-jun 18:00 bacula-dir ERROR TERMINATION This surprised me, because obviously there's a script to handle this. So I ran it manually, and received errors about SQL syntax where it said "do ". Checking the script, I quickly found the problem. Here's a patch that solved it for me: --- update_postgresql_tables.orig 2025-06-24 18:14:43.055571381 +0200 +++ update_postgresql_tables2025-06-24 18:15:04.866426330 +0200 @@ -642,7 +642,7 @@ -- Need to add postgresql-contrib to the dependency list -do $$ +do \$\$ declare selected_ext pg_extension%rowtype; begin @@ -654,7 +654,7 @@ if not found then CREATE EXTENSION pg_trgm; end if; -end $$; +end \$\$; CREATE INDEX meta_emailowner on MetaEmail (EmailTenant, EmailOwner); CREATE INDEX meta_emailtime on MetaEmail (EmailTime); the "$$" is meant to be passed to the postgresql server, but unfortunately it's written unquoted in a here document, which is a context where the shell does variable expansion. The result is that the $$ part gets replaced by the shell into its PID, resulting in a line "do ", which is not a valid way to quote PL/PGSQL code (the thing that is being attempted here). Adding backslashes to avoid that variable expansion resolved the issue for me. I don't know whether this problem exists in trixie or unstable too, but thought I'd mention it. -- System Information: Debian Release: 12.11 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-34-amd64 (SMP w/1 CPU thread; PREEMPT) Locale: LANG=nl_BE.UTF-8, LC_CTYPE=nl_BE.UTF-8 (charmap=UTF-8), LANGUAGE not set 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: ii bacula-common-pgsql 15.0.3-1~bpo12+1 ii dbconfig-pgsql2.0.24 ii debconf [debconf-2.0] 1.5.82 ii postgresql-client 15+248 ii postgresql-client-13 [postgresql-client] 13.11-0+deb11u1 ii postgresql-client-15 [postgresql-client] 15.13-0+deb12u1 Versions of packages bacula-director-pgsql recommends: ii postgresql 15+248 Versions of packages bacula-director-pgsql suggests: pn gawk -- debconf information: * bacula-director-pgsql/pgsql/app-pass: (password omitted) bacula-director-pgsql/pgsql/admin-pass: (password omitted) * bacula-director-pgsql/app-password-confirm: (password omitted) bacula-director-pgsql/password-confirm: (password omitted) bacula-director-pgsql/pgsql/changeconf: false bacula-director-pgsql/db/dbname: bacula bacula-director-pgsql/pgsql/method: Unix socket * bacula-director-pgsql/dbconfig-reinstall: false bacula-director-pgsql/pgsql/authmethod-user: ident bacula-director-pgsql/pgsql/admin-user: postgres bacula-director-pgsql/install-error: abort bacula-director-pgsql/pgsql/manualconf: bacula-director-pgsql/upgrade-error: abort bacula-director-pgsql/pgsql/no-empty-passwords: bacula-director-pgsql/passwords-do-not-match: bacula-director-pgsql/remove-error: abort bacula-director-pgsql/purge: false bacula-director-pgsql/pgsql/authmethod-admin: ident bacula-director-pgsql/internal/reconfiguring: false bacula-director-pgsql/upgrade-backup: false * bacula-director-pgsql/dbconfig-upgrade: false bacula-director-pgsql/db/app-user: bacula@localhost bacula-director-pgsql/internal/skip-preseed: true bacula-director-pgsql/dbconfig-remove: true bacula-director-pgsql/remote/newhost: bacula-director-pgsql/remote/port: bacula-director-pgsql/missing-db-package-error: abort bacula-director-pgsql/database-type: pgsql bacula-director-pgsql/remote/host: localhost * bacula-director-pgsql/dbconfig-install: true
