Re: Debian 13 bacula install failed on dbconfig

Please note this weird quirk I discovered some time back: postgres < v14
cannot accept a password > 99 characters.

I think the error you showed indicated that user bacula wasn't even
created. Perhaps debian repo maintainers adjusted the user under which
bacula would run?

Another strange thing: because it uses peer authentication by default,
bacula shouldn't even need a password to interact with postgres... If
bacula runs as the user that created the db.

Props to the Debian maintainers for updating bacula in their repo to v
15.0.3. I understand the usual stability arguments for leaving old packages
in a repo, but bacula 15.x has some new features that are quite relevant
for today.

Robert Gerber
402-237-8692
[email protected]

On Sat, Aug 30, 2025, 9:14 AM Gary Dale <[email protected]> wrote:

> On 2025-08-29 22:02, Rob Gerber wrote:
>
> Did you install bacula from the debian repos, or from the bacula community
> repos? I strongly recommend the bacula community repos. The latest version
> is 15.0.3.
>
> https://www.bacula.org/bacula-binary-package-download/
>
> You will need a key to access the repo. on the above linked page, complete
> the name and email address fields, and click continue. your key should be
> in the email, as part of the url. it will also be in the key request page
> linked above after entering your information, in a hyperlink in the middle
> of the page, directing you to click 'here'.
>
> There is also this bacula community edition installation guide. It is
> somewhat outdated, but the fundamentals are there.
> https://bacula.org/whitepapers/CommunityInstallationGuide.pdf
>
> Given the circumstances, I do recommend a purge uninstall. I also advise
> caution to avoid accidentally installing a mixture of packages from the
> distro repositories and the bacula community repositories. In my own (EL9)
> based installs, I have blacklisted the bacula packages from system repos to
> prevent such issues.
>
> On to your actual error:
> I find it strange that you are encountering this error. bacula uses 'peer'
> authentication with postgres sql, which to my understanding means that as
> long as the database is created by user bacula, it can be accessed by user
> bacula. Was bacula running as user bacula?
>
> Crucially, *the bacula SD and dir must not be ran as root.* This will
> create a number of bacula PID and state files, which bacula ran by a user
> other than root cannot modify, and as such, will have problems. Log files
> and such may have their permissions altered by bacula running as root as
> well. Generally, I recommend avoiding this. The PID and state files are
> located in /opt/bacula/working by default, though their location may vary
> based on your repo of choice.
>
> By default, bacula SD and dir should be running as user 'bacula'. The FD
> runs as root. This is normal, and expected.
>
> Can you do the following?
> sudo systemctl start postgresql.service
> sudo su bacula -
> psql -d bacula
>
> The above commands, with psql ran as user bacula, should drop you to a
> 'bacula=>' postgres sql prompt. ('\q' to exit). If that works, then the
> postgres database is working correctly, and bacula isn't running as user
> bacula, or is otherwise misconfigured.
>
> Aaaaaaaaaaalso, did you run the bacula postgres setup scripts? Here is the
> relevant snippet from my EL9-focused bacula installation runbook. The
> scripts paths given are located in their default locations as used by the
> bacula community repo. Actual location on your system may vary. Please note
> that in my experience the postgres user has not had sufficient permission
> to browse to the relevant paths using tab autocomplete / ls to find the
> correct scripts, so it is necessary to determine the correct path, and
> paste it into the shell once su'd as the postgres user.
>
> sudo systemctl start postgresql.service
> su - postgres
> /opt/bacula/scripts/create_postgresql_database
> /opt/bacula/scripts/make_postgresql_tables
> /opt/bacula/scripts/grant_postgresql_privileges
> exit
>
> Setting up bacula for the first time can be brutal. I really recommend
> throwing together a basic VM with your OS of choice, and putting your
> bacula installation together in there. Frequent snapshotting, and careful
> documentation can make it easier to find the correct path forward.
> Reverting said snapshots to undo whoopsies or test your documentation is
> golden. I've used virtualbox, synology virtual machine manager, and
> proxmox. Barring an existing virtualization stack in your environment, I
> can heartily recommend virtualbox for this use case. Once your installation
> runbook works correctly from start to finish, then you can return to your
> real server and slap bacula into place.
>
> I can't underline the value of the snapshot feature enough. I set bacula
> up on bare metal for the first time, and it was a real bear. Subsequently I
> revisited it, and redid my configuration and process using a VM. I
> then deployed bacula on bare metal. Much better result, and I've had
> several successful deployments since. Notes have saved my butt so hard, you
> have no idea.
>
> Fortunately, you have previous bacula experience, so you won't be as green
> as I was the first time. :)
>
> Once you have bacula running, come back and we can talk about bacularis,
> if you're interested in a gui for bacula.
>
> Thanks for the advice. Bacula is installed from the Debian sources and is
> 15.0.3-3. I tend to trust Debian sources for my servers where stability is
> important.
>
> Since the dbconfig didn't finish, I get errors when I try to do your test
> - the service is running as I previously demonstrated:
>
> # su bacula -
> This account is currently not available.
> # psql -d bacula
> psql: error: connection to server on socket
> "/var/run/postgresql/.s.PGSQL.5432" failed: FATAL:  role "root" does not
> exist
>
>
> Your second set of instructions gave me problems too. After su - to
> postgresql user, I get:
>
> $ /usr/share/bacula-director/create_postgresql_database
> CREATE DATABASE
> ALTER DATABASE
> Creation of XXX_DBNAME_XXX database succeeded.
>
> Database encoding bad. Do not use this database
>
> I'm probably looking for what could cause dbconfig to fail, and the one
> thing that comes to mind is an inability to process some passwords
> correctly. I'm going to do a purge then try again with more normal
> passwords.
>
> Thanks.
>

_______________________________________________
Bacula-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users