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
