View Issue Details

IDProjectCategoryView StatusLast Update
0001400bareos-coreGeneralpublic2022-01-27 16:25
Reporteramodia Assigned Tobruno-at-bareos  
Status closedResolutionunable to reproduce 
PlatformLinuxOSDebianOS Version10
Product Version20.0.2 
Summary0001400: psql: Fehler: FATAL: Peer-Authentifizierung für Benutzer »bareos« fehlgeschlagen
DescriptionNach einem Upgrade von 16.2 auf 20 kommt die folgende Fehlermeldung:
psql: Fehler: FATAL: Peer-Authentifizierung für Benutzer »bareos« fehlgeschlagen
Folgende Schritte haben nicht geholfen:
- ein anschließender Aufruf von /usr/lib/bareos/scripts/update_bareos_tables
- ein neues Passwort für user bareos (!!!) via postgres$ psql -> ALTER ROLE bareos WITH PASSWORD 'geheim';
- erneute GRANT-Vergabe via /usr/lib/bareos/scripts/grant_bareos_privileges

Was kann man tun, um das Problem zu lösen?
Falls noch Informationen fehlen: Welche?
Tagsdebian 10




2021-11-10 09:52

manager   ~0004321

What are the contain of previously working pg_hba.conf and actually used
You didn't indicate what other piece have been updated (because Bareos 16.2 had never been available for Debian 10)
You didn't indicate how the catalog database has been upgraded

Did you check and make all step necessary to migrate your user from md5 hash to new sha256sum default in PostgreSQL ?


2021-11-10 12:11

reporter   ~0004329

Content of pg_hba.conf files:
# grep -v ^# /etc/postgresql/11/main/pg_hba.conf |uniq

local all postgres peer

local all all peer
host all all md5
host all all ::1/128 md5
local replication all peer
host replication all md5
host replication all ::1/128 md5

# grep -v ^# /etc/postgresql/13/main/pg_hba.conf |uniq

local all postgres peer

local all all peer
host all all md5
host all all ::1/128 md5
local replication all peer
host replication all md5
host replication all ::1/128 md5

History to "create" this problem:
1. Installed bareos long ago
All backup messages have the line: "Build OS: x86_64-pc-linux-gnu debian Debian GNU/Linux 9.3 (stretch)"
2. Upgraded Debian to buster and now bullseye
Debian kept bareos as a maintained package in buster, so I overlooked that the expected upgrade of bareos did not follow (my fault).
3. With the upgrade to bullseye comes the upgrade of PostgreSQL v11 to v13
4. After this Debian upgrade bareos 16.2 seems to have worked under PostgreSQL v13 (!)
5. Than I noteced that bareos did not upgrade, so I tried to upgrade bareos 16.2 to 20
6. Upgrade of bareos from 16.2 to 20 was performed with the command '/usr/lib/bareos/scripts/update_bareos_tables'
It seemed to work without errors, but after that command the error described occured:
# psql -U bareos bareos -W
psql: Fehler: FATAL: Peer-Authentifizierung für Benutzer »bareos« fehlgeschlagen

I did not migrate explicitly from md5 hash to new sha256sum for PostgreSQL. Did this happen implicitly with the PostgreSQL

Further notice:
1. The attempt to create a new (empty) database (bareos2) with (modified) files

shows differences in the Collate and Ctype columns:

# su postgres -c psql
could not change directory to "/root": Keine Berechtigung
psql (13.4 (Debian 13.4-0+deb11u1))
Type "help" for help.

postgres=# \l
                                  List of databases
   Name | Owner | Encoding | Collate | Ctype | Access privileges
 bareos | bareos | SQL_ASCII | C | C |
 bareos2 | postgres | SQL_ASCII | de_DE.UTF-8 | de_DE.UTF-8 |
 postgres | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 |
 template0 | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 | =c/postgres +
           | | | | | postgres=CTc/postgres
 template1 | postgres | UTF8 | de_DE.UTF-8 | de_DE.UTF-8 | postgres=CTc/postgres+
           | | | | | =c/postgres
(5 rows)

2. Besides the error reporting, the main interest is to get bareos running again asap.
For this a backup of the old database (with '/usr/lib/postgresql/11/bin/pg_dumpall --clean --if-exists ') is available.
A new bareos database ("bareos2") has already been generated according to the manual by
# su postgres -c /usr/lib/bareos/scripts/create_bareos2_database
# su postgres -c /usr/lib/bareos/scripts/make_bareos2_tables
# su postgres -c /usr/lib/bareos/scripts/grant_bareos2_privileges
(copies of the files with an altered database name)

How can I use the pg_dumpall file (db scheme of bareos 16.2) to fill the new database bareos2 (db scheme of bareos 20) correctly?

Thanks in advance!


2021-11-10 13:21

manager   ~0004330

I'm not sure if I understood correctly which packages from which source were installed and upgraded did both 16 and 20 came from ?

Your database bareos2 is not completely setup as previous one (see collate) which is unfortunately an open issue actually (PG support stop at 12) missing 13 and 14
check in /usr/lib/bareos/scripts/create_bareos_database
      case ${PSQLVERSION} in
you should edit and add |13.*|14.* after the 12.
do the same to the other script to be sure.

I would not use pg_dumpall (as it contain all other database) if your cluster 13 is up and running you just have to create a postgresql bareos user.
make it work with psql
create db table grant
use pg_dump (version 13) to dump previous bareos db, and then use pg_restore to the new created db.


2021-11-10 13:44

reporter   ~0004331

Thanks for the quick reply!

Initial setup of bareos was performed via the Debian package (stretch).
Upgrade to bareos 20 package was performed according to the manual:
 generate a "bareos.list" file in /etc/apt/source.list.d/ with the content:
 deb /

Next step is to edit the scripts to include PostgreSQL 13 and 14 and to re-create the bareos2 database.

In order to perform a pg_dump (v13) of the prevoius database I might have to restart the v11 cluster (trying to dpkg-reconfigure bareos-database-common has emptied the converted bareos databse).
You mentioned that a "postgresql bareos user" is necessary. Why is this step missing in the manual? (v. above: only "su postgres -c /usr/lib/bareos/scripts/...", no "su bareos ...") Or did I miss this issue?

Thanks again for the quick help!


2021-11-10 13:58

manager   ~0004332

Sorry if not clear I mean having a user "bareos" inside postgresql.
su postgres psql -c "\du" should show a bareos role.
that role should be able to connect to bareos database with the configured password coming from catalog configuration.


2021-11-11 10:03

reporter   ~0004335

Thanks for the clarification.

The bareos role exists with PostgreSQL v13:
postgres$ psql -c "\du"
                                      Liste der Rollen
 Rollenname | Attribute | Mitglied von
 bareos | Superuser, Rolle erzeugen, DB erzeugen | {}
 postgres | Superuser, Rolle erzeugen, DB erzeugen, Replikation, Bypass RLS | {}

The procedure to create a new backup of the old database was as follows:
- stopping cluster v13: root:~# systemctl stop postgresql@13-main.service
- starting cluster v11: root:~# systemctl start postgresql@11-main.service
- using the new version to perform the backup:
  postgres:~$ /usr/lib/postgresql/13/bin/pg_dump --file=bareos11_dump13_2021-11-10.sql bareos
- stopping cluster v11: root:~# systemctl stop postgresql@11-main.service
- starting cluster v13: root:~# systemctl start postgresql@13-main.service
- : postgres:~$ psql <bareos11_dump13_2021-11-10.sql

This created the database as owner postgres, which was correted by loggin into the database:
bareos=# ALTER DATABASE bareos OWNER TO bareos ;
bareos=# ALTER TABLE public.basefiles OWNER TO bareos ;
bareos=# ALTER TABLE public.version OWNER TO bareos ;

This still leaves the error while logging in from the prompt:
postgres:~$ psql -U bareos bareos -W
psql: Fehler: FATAL: Peer-Authentifizierung für Benutzer »bareos« fehlgeschlagen

But there is good news: Now bareos seem to be able to access the database:
root:~# bconsole
Connecting to Director backup02-20:9101

A status check of the director yields:
*status director
Terminated Jobs:
 JobId Level Files Bytes Status Finished Name
 18979 Full 0 0 Error 09-Nov-21 21:02 backup-bareos-fd
 18980 Full 0 0 Error 09-Nov-21 21:10 BackupCatalog

BUT the bad news is that all information about the jobs seems to be gone:
*rerun jobid=18979
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
rerunning jobid 18979
You have messages.
11-Nov 09:13 backup02-20-dir JobId 0: Warning: Error getting Job record for Job rerun: ERR=cats/ No Job found for JobId 18979

Any ideas how to fix this?

P.S.: Bareos connects to the database regardless if catalog/MyCatalog.conf has an "ddbpassword" set or not.


2021-11-12 13:36

reporter   ~0004336


Good news:
1) The initial error seems to be solved: Bareos seems to get access to the database (bconsole logs in without error, gets status reports fom director and clients)

2) The (confusing) error reported in note 0004329:
root: # psql -U bareos bareos -W
psql: Fehler: FATAL: Peer-Authentifizierung für Benutzer »bareos« fehlgeschlagen

can be solved by adding "localhost" to the command line:
root: #psql -U bareos -h localhost bareos -W
psql (13.5 (Debian 13.5-0+deb11u1))
SSL-Verbindung (Protokoll: TLSv1.3, Verschlüsselungsmethode: TLS_AES_256_GCM_SHA384, Bits: 256, Komprimierung: aus)

Bad news:
The database (still) seems to hold no information about previous jobs (v. note 0004335):

*rerun jobid=18971
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
rerunning jobid 18971
You have messages.
12-Nov 11:26 backup02-20-dir JobId 0: Warning: Error getting Job record for Job rerun: ERR=cats/ No Job found for JobId 18971

So the database is accessible, but the information formerly stored in it is lost.
How can I restore this information, if only a "pg_dumpall" of the old configuration "PostgrSQL 11, Bareos-Scheme 16.2" is available?
Any help is welcome!


2021-11-15 12:05

manager   ~0004337

Hello, as you certainly know, pg_dumpall is a dump in plain text format.
I'm not sure what else you have into that dump from you previous cluster (roles, other databases etc)

You should normally be able to just open it into a text editor (like vim or similar) and just keep interesting part
from the \connect bareos to the next \connect.
Keep just those, and you will then have a bareos text dump of the database.
which can be restored with the psql < dump.sql like syntax.

Otherwise, you should also normally have a catalog backup into your installation, which is a dump of the bareos database.
take the last one and restore it.
See into the documentation and in certain case


2021-12-22 16:36

manager   ~0004409

Any news here ?


2022-01-27 16:25

manager   ~0004491

closing without news

Issue History

Date Modified Username Field Change
2021-11-08 17:48 amodia New Issue
2021-11-08 17:48 amodia Tag Attached: debian 10
2021-11-10 09:52 bruno-at-bareos Note Added: 0004321
2021-11-10 12:11 amodia Note Added: 0004329
2021-11-10 13:21 bruno-at-bareos Note Added: 0004330
2021-11-10 13:44 amodia Note Added: 0004331
2021-11-10 13:58 bruno-at-bareos Note Added: 0004332
2021-11-11 10:03 amodia Note Added: 0004335
2021-11-12 13:36 amodia Note Added: 0004336
2021-11-15 12:05 bruno-at-bareos Note Added: 0004337
2021-12-22 16:36 bruno-at-bareos Note Added: 0004409
2022-01-27 16:25 bruno-at-bareos Assigned To => bruno-at-bareos
2022-01-27 16:25 bruno-at-bareos Status new => closed
2022-01-27 16:25 bruno-at-bareos Resolution open => unable to reproduce
2022-01-27 16:25 bruno-at-bareos Note Added: 0004491