Ericsson
[server] Lack of database password visually appears as if CodeChecker was asking for it, still failing connection
Describe the bug
Originally reported by @mcserep.
Not supplying a password for the config database connection results in the password being asked on the prompt, looking as if it was asked by CodeChecker when in reality it's only asked by a spawned subprocess and the password typed in never reaches CodeChecker, causing a connection error.
CodeChecker version 6.21 release from PyPI
To Reproduce Steps to reproduce the behaviour:
- Create a new PostgreSQL server, with an empty database
codechecker_config, user (role)codecheckerwith a custom password. -
CodeChecker server --postgresql --db-host localhost --db-port 5432 --db-username codechecker --db-name codechecker_config - Observe the error. It looks like CodeChecker is asking for the password, which, even after supplied correctly, still results in the failure of the connection.
[INFO 2023-02-23 11:22] - Checking configuration database ...
Password for user codechecker:
[INFO 2023-02-23 11:22] - Connection failed to the database server.
[ERROR 2023-02-23 11:22] - Failed to get product configurations from the database.
[ERROR 2023-02-23 11:22] - Please check your command arguments.
Expected behaviour
Either CodeChecker should say that the connection failed automatically (blocking on user input from a server is not a good idea if something is running in a headless mode...) or if it does ask for the password interactively, it should be done by CodeChecker in a way that all database operations are supplied with the user's password.
Having to type in the right password and still saying it's wrong is misleading.
Desktop (please complete the following information)
- OS: Debian 11 (equivalent to Ubuntu 22.04) LTS
Additional context
Inspecting the --verbose debug output shows that the ask for the password is done by an underlying spawned psql command, unrelated to CodeChecker's memory contents. Of course if I give the right password to psql only, CodeChecker will never know about it.
Maybe checking if psql properly throws an error, instead of a blocking input read, if the process is spawned without a STDOUT/STDIN attached?
[DEBUG][2023-02-23 15:42:11] {system} [2788254] <140692681430848> - webserver_context.py:102 __get_package_layout() - Reading config: /home/codechecker/venv/share/codechecker/config/package_layout.json
[DEBUG][2023-02-23 15:42:11] {system} [2788254] <140692681430848> - database.py:467 from_cmdline_args() - Using PostgreSQL:
[INFO][2023-02-23 15:42:11] {server} [2788254] <140692681430848> - server.py:811 server_init_start() - Checking configuration database ...
[DEBUG][2023-02-23 15:42:11] {system} [2788254] <140692681430848> - database.py:542 connect() - Connecting to database...
[DEBUG][2023-02-23 15:42:11] {system} [2788254] <140692681430848> - database.py:544 connect() - Checking if database is running at [localhost:5432]
[DEBUG][2023-02-23 15:42:11] {system} [2788254] <140692681430848> - database.py:40 call_command() - Run psql -h localhost -p 5432 -U codechecker -d codechecker_config -c SELECT version();
Password for user codechecker:
[DEBUG][2023-02-23 15:42:21] {system} [2788254] <140692681430848> - database.py:47 call_command() - version
---------------------------------------------------------------------------------------------------------------------------
PostgreSQL 13.9 (Debian 13.9-0+deb11u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
(1 row)
[DEBUG][2023-02-23 15:42:21] {system} [2788254] <140692681430848> - database.py:105 __enter__() - Connection error
[DEBUG][2023-02-23 15:42:21] {system} [2788254] <140692681430848> - database.py:106 __enter__() - (psycopg2.OperationalError) fe_sendauth: no password supplied
I'm getting this error as well. How did you get around it? I have followed this guide for setting up the postgres database: https://github.com/Ericsson/codechecker/blob/master/docs/web/postgresql_setup.md
@timskovjacobsen If you're only testing around and don't mind leaking your database password to other processes on the same machine, you can specify it on the command line. If you're in a more production-y environment, you need to create a .pgpass file in the home directory of the user running the server, and then have the PGPASSFILE environment variable set accordingly:
# PGPASSFILE environment variable should be set to a 'pgpass' file.
# For format and further information see PostgreSQL documentation:
# http://www.postgresql.org/docs/current/static/libpq-pgpass.html
echo "*:5432:*:codechecker:my_password" >> ~/.pgpass
chmod 0600 ~/.pgpass
Thanks for the quick reply. Hmm. Perhaps my issue is not with the password then. The error I get is this:
username@host:~$ PGPASSFILE=/home/username/.pgpass CodeChecker server --postgresql --db-host=localhost --db-port=5432 --db-username=codechecker --d
b-name=codechecker_config --host 0.0.0.0 -p 443 --verbose debug
[DEBUG][2023-06-28 12:00:10] {system} [16690] <140231736324096> - webserver_context.py:100 __get_package_layout() - Reading config: /home/user/.local/share/codechecker/config/package_layout.json
[DEBUG][2023-06-28 12:00:10] {system} [16690] <140231736324096> - database.py:467 from_cmdline_args() - Using PostgreSQL:
[INFO][2023-06-28 12:00:10] {server} [16690] <140231736324096> - server.py:818 server_init_start() - Checking configuration database ...
[DEBUG][2023-06-28 12:00:10] {system} [16690] <140231736324096> - database.py:542 connect() - Connecting to database...
[DEBUG][2023-06-28 12:00:10] {system} [16690] <140231736324096> - database.py:544 connect() - Checking if database is running at [localhost:5432]
[DEBUG][2023-06-28 12:00:10] {system} [16690] <140231736324096> - database.py:40 call_command() - Run psql -h localhost -p 5432 -U codechecker -d codechecker_config -c SELECT version();
[DEBUG][2023-06-28 12:00:10] {system} [16690] <140231736324096> - database.py:47 call_command() - version
----------------------------------------------------------------------------------------------------------------------------------------
PostgreSQL 14.8 (Ubuntu 14.8-0ubuntu0.22.04.1) on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0, 64-bit
(1 row)
[DEBUG][2023-06-28 12:00:10] {system} [16690] <140231736324096> - database.py:105 __enter__() - Connection error
[DEBUG][2023-06-28 12:00:10] {system} [16690] <140231736324096> - database.py:106 __enter__() - expected bytes, str found
[INFO][2023-06-28 12:00:10] {server} [16690] <140231736324096> - server.py:821 server_init_start() - Connection failed to the database server.
[DEBUG][2023-06-28 12:00:10] {server} [16690] <140231736324096> - server.py:877 server_init_start() - Status was not in the arguments.
[DEBUG][2023-06-28 12:00:10] {server} [16690] <140231736324096> - server.py:886 server_init_start() - Product upgrade was not in the arguments.
[DEBUG][2023-06-28 12:00:10] {server} [16690] <140231736324096> - server.py:482 check_product_db_status() - expected bytes, str found
[ERROR][2023-06-28 12:00:10] {server} [16690] <140231736324096> - server.py:483 check_product_db_status() - Failed to get product configurations from the database.
[ERROR][2023-06-28 12:00:10] {server} [16690] <140231736324096> - server.py:484 check_product_db_status() - Please check your command arguments.
It fails to get the configurations. But maybe the password is not the issue.
Edit: I managed to get the server up and running by downgrading pg8000 from the newest version 1.29.8 to version 1.15.0. I got down to that version by trial and error. The expected bytes, str found error was due to that.
I'm sorry I derailed the post a bit. But I agree that the behavior you describe should be looked at.