I am trying to use redirection to load a SQL database schema using:
system("mysql -p -h db.server.local -u admin -D some_db < schema.sql")
I expect it to prompt for a password, and it works correctly when run from IRB. However, when run via Rails' runner it fails
as if I had hit the Enter key at the password prompt. In Rails console it looks like this:
pry(main)> system("mysql -p -h db.server.local -u admin -D some_db < schema.sql")
Enter password: ERROR 1045 (28000): Access denied for user 'admin'#'mylocalpc' (using password: NO)
It did not give me a chance to enter the password. When I removed the redirection (<), it correctly prompts for a password. So it appears that somehow, when run via Rails, the STDIN redirection is disrupting the password prompt. I tried with backticks and had the same issue.
I assume that the mysql executable must be using some magic so that the STDIN redirection does not disrupt the password prompt, but it appears to be broken when the executable is launched via Rails.
Is Rails overriding System() and if so, is there some way to call the real System()?
Does anyone have other ideas of how to work around this, or what could be happening here?
The mysql executable is skipping the request for a password because in order to except stdin for the password, the command needs to be executed with TTY enabled. Ruby system command and backticks do not execute the command using a TTY enabled interface to the underlying system. There are a couple gems that allow for TTY enabled execution on the command line, I would check out the tty-command gem if you’d like to force the command prompt to ask for the password.
Though for the ideal solution that I would suggest, since you’re executing the command from within Rails, you should have access to Rails.credentials. I would store the necessary credentials (username and password) for the database within the credentials store, and use this to populate the -u and -P flag values for the mysql command. This will avoid the need to prompt for the password entirely.
I have installed influxdb. But in the server every user can login when ther type inlux.
Why is it like that? Is not it a security problem. And how can I solve it?
I want to login with spesific admin user and its admin password.
The "why"
Different databases have used reasonings with minor differences over the years, but basically, it goes like this:
In its most simple install, <insert DBMS here> should just run - for integration tests, simple evaluation purposes etc. We could generate a root/admin/superhoncho user password, but more often than not, this is not going to be changed, and that is a Bad Thing™.
And since nobody sane would run a database in production without authentication and authorisation enabled, providing easy access in the default installation is not a problem anyway, is it?
I tend to agree with this reasoning, though I am off the opinion that in the case the DBMS has authentication and authorisation disabled per default, it should bind to localhost by default, too. You make your DBMS accessible to the outside world, and be it only your company's network? You surely have thought about the implications!
The "how"
Authentication
I am going to use docker to illustrate it and it is quite obvious what you have to do in a non-docker environment.
First, we pull the influxdb docker image and create a default config file in one go:
$ docker run --rm influxdb influxd config > influxdb.conf
Unable to find image 'influxdb:latest' locally
latest: Pulling from library/influxdb
...
Digest: sha256:0aa7fea5336b5e5cc1c80e16062865821ec772e06519c138947ef5ebd9b34907
Status: Downloaded newer image for influxdb:latest
Merging with configuration at: /etc/influxdb/influxdb.conf
Now we change the authentication parameter in the [http] section of our influxdb.conf to true:
...
[http]
auth-enabled = true
...
Next, we start our InfluxDB using this modified config file:
$ docker run -d --name influxdb -p 8086:8086 \
-v $PWD/influxdb.conf:/etc/influxdb/influxdb.conf:ro \
influxdb -config /etc/influxdb/influxdb.conf
1987f962c331d2404a2564bb752d971553b13181dbbbb1e38cf50d345b3191c4
(The hash sum you get will be different.)
Now, we connect to our influxdb and create the admin user
$ docker exec -it influxdb influx
Connected to http://localhost:8086 version 1.7.8
InfluxDB shell version: 1.7.8
> create user admin with password 'secret' with all privileges;
From this point on, credentials are needed for pretty much everything
> show users
ERR: unable to parse authentication credentials
Warning: It is possible this error is due to not setting a database.
Please set a database with the command "use <database>".
> auth
username: admin
password:
> show users
user admin
---- -----
admin true
Authorization
Simple mnemonic: "Users are granted permissions per database." So, in order to grant something to a user, that user must first exist:
> create user berkancetin with password 'supersecret';
> create database foobar
> grant read on foobar to berkancetin
> show users
user admin
---- -----
admin true
berkancetin false
> show grants for "berkancetin"
database privilege
-------- ---------
foobar READ
Further reading (!!!)
Ignore at your own risk. You. Have. Been. Warned.
InfluxDB authentication
InfluxDB docs on Authorization
I have a system where I'm trying to run the docker logincommand, it is a headless linux system, but unfortunately only the Docker Credentials Helper docker-credential-secretservice is installed.
This means that I get the following error:
Error saving credentials: error storing credentials - err: exit status 1, out: `Cannot autolaunch D-Bus without X11 $DISPLAY`
It makes sense that I get this as:
By default, Docker looks for the native binary on each of the
platforms, i.e. “osxkeychain” on macOS, “wincred” on windows, and
“pass” on Linux. A special case is that on Linux, Docker will fall
back to the “secretservice” binary if it cannot find the “pass”
binary. If none of these binaries are present, it stores the
credentials (i.e. password) in base64 encoding in the config files
described above.
And since secretservice helper uses a GUI credentials store it tries to open a window, which it can't on the headless system.
I've no control over the system, so I can't remove the /usr/bin/docker-credential-secretservice file to force docker login to fall back to the config file rather than using the secretservice helper.
What I can do is create and list files in my user's home folder. I've tried to run the command as such:
docker --config ./docker login -u <user-name> -p <password> <repository>
I was under the impression that the login command would then create a config.json in the ./docker (I've noticed docker login will create the folder if it doesn't exist). This works on a system that doesn't have any helpers installed, but not on the system in question.
I've also tried to create a ~/.docker/config.json with something like:
echo '{"credStore":""}' > ~/.docker/config.json
Hoping that docker login would get the hint not to use any helpers for the credential store.
Is there a way for a non-admin to force docker login to fall back to:
stores the credentials (i.e. password) in base64 encoding in the config files described above.
Without deleting the credentials helper?
(as a side note, I'll of course ask to have the /usr/bin/docker-credential-secretservice removed but, in case it's not possible or for future reference, are there any alternative solutions?)
Logging out the current user, before logging in with a different user name worked for me. Logging out removed the saved docker credentials.
docker logout <reponame>
docker login <reponame>
To avoid using a credsStore and to store a plaintext auth token in your docker config (e.g. ~/.docker/config.json), delete the "credsStore" key from your docker config file and rerun docker login.
When you run docker login, it will give a warning but will save the auth token into the file.
$ docker login
Username: someuser
Password:
WARNING! Your password will be stored unencrypted in ~/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
The resulting docker config file should look like this:
{
"auths": {
"your.docker.registry": {
"auth": "dXNlcm5hbWU6cGFzc3dvcmQK="
}
}
}
The auth token is simply a base64 encoded string of the form username:password.
This worked for Docker Engine versions 19 and 20.
Unfortunately, Docker (as of 18.06) first looks for the docker-credential-* binaries, and if it finds any of them, it will automatically overwrite the "credsStore" value in ~/.docker/config.json.
Your only workaround would be to install docker-credential-pass in your home directory so that Docker will use that instead of docker-credential-secretservice. docker-credential-pass does not require a GUI.
Steps to install docker-credential-pass:
docker login fails on a server with no X11 installed
You can just ignore all the output by sending everything to /dev/null like:
echo $TOKEN|docker login -u=user --password-stdin myregistry.com > /dev/null 2>&1
where $TOKEN will be your previously exported token or password.
This will be useful as well with CI's when using some automation
I've looked through the code and there appears to be no way to generally disable the use of credential helpers. But you can skip the code path on a per-registry basis.
https://github.com/docker/cli/blob/25eee83d6b8c475548254b2decc9c8e0490d229c/cli/config/configfile/file.go#L308 will look up the helper to use (just the suffix after docker-credential-) in credHelpers from the registry host name. If it is "" it will use the normal unencrypted file store. As far as I can tell, this is undocumented and likely unintended behavior.
With that, in order to bypass the credential helpers for a specific registry, do
mkdir ./docker
echo "{\"credHelpers\": {\"$REGISTRY_HOST\": \"\"}}" > ./docker/config.json
docker --config ./docker login -u $USERNAME -p $PASSWORD $REGISTRY_HOST
I believe the cause why {"credsStore":""} isn't working is the omitempty serialization tag on that field. Setting it to empty is the same as not setting it.
Not an answer to the question, but maybe to the problem:
We can launch dbus ourselves then unlock/lock/query the keyring from the cli.
These are the bash functions I use:
function unlock-keyring () {
export $(dbus-launch)
read -rsp "Password: " pass
export $(echo -n "$pass" | gnome-keyring-daemon --unlock)
unset pass
}
function lock-keyring () {
dbus-send --dest=org.gnome.keyring --print-reply /org/freedesktop/secrets org.freedesktop.Secret.Service.LockService
}
function query-keyring-locked () {
busctl --user get-property org.freedesktop.secrets /org/freedesktop/secrets/collection/login org.freedesktop.Secret.Collection Locked
}
https://unix.stackexchange.com/questions/473528/how-do-you-enable-the-secret-tool-command-backed-by-gnome-keyring-libsecret-an
https://superuser.com/questions/700826/how-to-lock-a-unlocked-gnome-keyring
https://superuser.com/questions/1618970/query-status-of-gnome-keyring
https://unix.stackexchange.com/questions/602313/unlock-gnome-keyring-daemon-from-command-line
Simply rename ~/.docker/config.json to something different, or remove it if you won't need it anymore.
mv ~/.docker/config.json ~/.docker/backup-config.json
The version I use is neo4j-enterprise-2.2.0-M02
My question is :
How can I configure a user (like add a new user, change the password ,etc) in backend or browser, instead of REST API? Can I do it via neo4j-shell? imagine that I am a DBA, it is not very convenient to do this by REST API.
Any help will be greatly appreciated!
You can use the browser instead of the API. Just go to http://localhost:7474 (or whatever IP to which the web console is bound) and you will be prompted to change the password. Once authenticated, use the command :server change-password to change the password again.
It is not yet possible to create multiple user accounts within the system.
You can use the command :help server to see available authentication commands.
Although still utilizing the REST API, I'll throw the cURL option out there to anyone who doesn't have access to a web browser (AWS instance, for example):
$ curl -H "Content-Type: application/json" -X POST -d '{"password":"WHATEVER THE PASSWORD IS"}' -u neo4j:neo4j http://localhost:7474/user/neo4j/password
Another option is to modify the auth file directly and restart neo. Doing this, you can even change the username!
Run
find / -name dbms
For me this gave one hit:
/var/lib/neo4j/data/dbms/auth
Save this code as build_auth_string.sh:
#!/bin/bash
DEFAULT_IFS="$IFS"
SALT_LEN=32
# either read from stdin or use the argument
if [ -z "$1" ]; then
read INPUT
else
INPUT="$1"
fi
if [ -z "$INPUT" ]; then
echo "correct format <uname:pass>"
exit
fi
IFS=':'
read -a UNAME_PASS <<< "$INPUT"
UNAME="${UNAME_PASS[0]}"
PASS="${UNAME_PASS[1]}"
# representing the password in hex format like \xAB\x0C etc
# HEX_PASS=$(echo -n $PASS | xxd -p | awk '{print toupper($1);}' | sed -r 's/(.{2})/\\x\1/g')
HEX_PASS=$(echo -n $PASS | hexdump -v -e '"\\\x" 1/1 "%02X"')
# echo $HEX_PASS
# create the salt and store it in hex format
SALT=$(cat /dev/urandom | tr -dc 'a-f0-9' | fold -w $SALT_LEN | head -n 1)
# SALT="28FD26AD92D6D2D8820E969F3F3732B4"
HEX_SALT=$(echo -n $SALT | sed -r 's/(.{2})/\\x\1/g')
# calculate the sha256 sum of the salt and password value
# need to split the output because the output ends with a hyphen
IFS=' '
read -a PASSWORD_HASH_ARRAY <<< $(printf $HEX_SALT$HEX_PASS | sha256sum)
PASSWORD_HASH="${PASSWORD_HASH_ARRAY[0]}"
# echo "$UNAME;$PASS;$SALT"
# echo "$PASSWORD_HASH"
# and print out the auth string
COMBINED=$(echo -n "$PASSWORD_HASH,$SALT" | awk '{print toupper($1);}')
echo "$UNAME:SHA-256,$COMBINED:"
IFS="$DEFAULT_IFS"
The code for the above came from https://github.com/artsince/docker-neo4j-auth/blob/master/build_auth_string.sh - im posting it here just encase..
And then just run the above script like
build_auth_string.sh myUsername:myP#ssw0rd
Copy/paste that into your auth file replacing whatever was there before, and restart neo4j :)
A fresh install of Neo4j 2.2.x has a user 'neo4j', with an initial password 'neo4j'. You are required to change the password before you can do anything.
It's easy to do this from the command line, by calling httpie to interact with the REST API. For example, to set a new password of 'foobar', run this command:
http -a neo4j:neo4j POST http://localhost:7474/user/neo4j/password password=foobar
If you want to reset the password and you dont know the old password :
then for Windows user
go to this path:
C:\Users\xyz\Documents\Neo4j\default.graphdb\dbms
and delete that auth file.
Restart the neo4j they will again ask to set the username and password!!
by default
username:neo4j
password:neo4j
Currently it's not possible to configure authorization using neo4j-shell. As you've mentioned the REST API is the way to go. Using a convenient REST client this is very easy.
My tools of choice is either postman (a plugin for chrome browser) or httpie for the command line. E.g. with httpie changing the password for a user is as simple as:
http localhost:7474/user/neo4j/password password=neo4j new_password=mypass
Be aware that password (and other authorization settings) are not automatically distributed in a cluster, see the manual how to copy over settings between instances.
For Mac users, version 2.3.1 of Neo4J, best way to reset credentials is to remove the file with credential information and start the service again.
Steps to follow
Find where the file that contains credentials is located from the browser console (localhost:7474). Go to Star (Favourites)->System->Server configuration
Search for dbms.security.auth_store.location property to see where it points to. In my case it was /Users/felipe/Documents/Neo4j/default.graphdb/./dbms/auth
Delete that file.
Start the service again and go to the console again (localhost:7474).
By default you will be asked to set the password for the user neo4j.
I hope it helps.
To elaborate on felipe's response (since I do not have enough rep points to comment):
I stopped the server, I deleted the auth files in BOTH:
DBROOT\data\auth
DBROOT\dbms\auth
Restarted the server, and connected to it via the localhost:7474, used the default username/password (neo4j/neo4j) and then it prompted me for a new password.
On Neo4j 4.0+, you can run:
$ cypher-shell
If it's the first time you connect, you can enter neo4j as user and password and you will be prompted to set a new password.
If you want to change the password afterwards, you can write in the Cypher shell:
:server change-password
I'm getting the error:
FATAL: Peer authentication failed for user "postgres"
when I try to make postgres work with Rails.
Here's my pg_hba.conf, my database.yml, and a dump of the full trace.
I changed authentication to md5 in pg_hba and tried different things, but none seem to work.
I also tried creating a new user and database as per Rails 3.2, FATAL: Peer authentication failed for user (PG::Error)
But they don't show up on pgadmin or even when I run sudo -u postgres psql -l.
Any idea where I'm going wrong?
The problem is still your pg_hba.conf file*.
This line:
local all postgres peer
Should be:
local all postgres md5
After altering this file, don't forget to restart your PostgreSQL server. If you're on Linux, that would be sudo systemctl restart postgresql (on older systems: sudo service postgresql restart).
Locating hba.conf
Note that the location of this file isn't very consistent.
You can use locate pg_hba.conf or ask PostgreSQL SHOW hba_file; to discover the file location.
Usual locations are /etc/postgresql/[version]/main/pg_hba.conf and /var/lib/pgsql/data/pg_hba.conf.
These are brief descriptions of the peer vs md5 options according to the official PostgreSQL docs on authentication methods.
Peer authentication
The peer authentication method works by obtaining the client's
operating system user name from the kernel and using it as the allowed
database user name (with optional user name mapping). This method is
only supported on local connections.
Password authentication
The password-based authentication methods are md5 and password. These
methods operate similarly except for the way that the password is sent
across the connection, namely MD5-hashed and clear-text respectively.
If you are at all concerned about password "sniffing" attacks then md5
is preferred. Plain password should always be avoided if possible.
However, md5 cannot be used with the db_user_namespace feature. If the
connection is protected by SSL encryption then password can be used
safely (though SSL certificate authentication might be a better choice
if one is depending on using SSL).
After installing Postgresql I did the below steps.
Open the file pg_hba.conf. For Ubuntu, use for example /etc/postgresql/13/main$ sudo nano pg_hba.conf and change this line at the bottom of the file, it should be the first line of the settings:
local all postgres peer
to
local all postgres trust
Side note: If you want to be able to connect with other users as well, you also need to change:
local all all peer
to
local all all md5
If you used nano editor, exit with double Escape, x, y, Enter to save the config file.
Restart the server
$ sudo service postgresql restart
Output: * Restarting PostgreSQL 13 database server
Login into psql and set your password
$ psql -U postgres
db> ALTER USER postgres with password 'your-pass';
Output: ALTER ROLE
Side note: If you have other users, they will need a password as well:
db> ALTER USER my_user with password 'your-pass';
Then enter:
exit
Finally change the pg_hba.conf from
local all postgres trust
to
local all postgres md5
Restart the server again
$ sudo service postgresql restart
Output: * Restarting PostgreSQL 13 database server
Login at psql with postgres user
After restarting the postgresql server, the postgres user accepts the password that you chose:
psql -U postgres
Output:
Password for user postgres:
psql (13.4 (Ubuntu 13.4-1.pgdg20.04+1))
Type "help" for help.
And you are in psql:
postgres=#
Side note: Same now works for my_user if you added the user and password:
psql -d YOUR_DB_NAME -U my_user
Which will ask you for the new password of my_user.
Authentication methods details:
trust - anyone who can connect to the server is authorized to access the database
peer - use client's operating system user name as database user name to access it.
md5 - password-base authentication
for further reference check here
If you connect over localhost (127.0.0.1) you shouldn't experience that particular issue. I wouldn't muck much with the pg_hba.conf but instead I would adjust your connection string:
psql -U someuser -h 127.0.0.1 database
where someuser is your user you're connecting as and database is the database your user has permission to connect to.
Here is what I do on Debian to setup postgres:
http://www.postgresql.org/download/linux/debian/ (Wheezy 7.x)
as root …
root#www0:~# echo "deb http://apt.postgresql.org/pub/repos/apt/ wheezy-pgdg main" >> /etc/apt/sources.list
root#www0:~# wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add -
root#www0:~# apt-get update
root#www0:~# apt-get install postgresql-9.4
root#www0:~# su - postgres
postgres#www0:~$ createuser --interactive -P someuser
Enter password for new role:
Enter it again:
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create databases? (y/n) y
Shall the new role be allowed to create more new roles? (y/n) n
postgres#www0:~$ createdb -O someuser database
postgres#www0:~$ psql -U someuser -h 127.0.0.1 database
Enjoy!
This has worked for me !!
sudo -u postgres psql
sudo psql --host=localhost --dbname=database-name --username=postgres
This solved my issue
If you have an issue, you need to locate your pg_hba.conf. The command is:
find / -name 'pg_hba.conf' 2>/dev/null
and after that change the configuration file:
Postgresql 9.3
Postgresql 9.4
The next step is: Restarting your db instance:
service postgresql-9.3 restart
If you have any problems, you need to set password again:
ALTER USER db_user with password 'db_password';
Go to this /etc/postgresql/9.x/main/ and open pg_hba.conf file
In my case:
$> sudo nano /etc/postgresql/9.3/main/pg_hba.conf
Replace peer with md5
So this will be changed to:
Database administrative login by Unix domain socket
local all postgres peer
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 md5
This:
Database administrative login by Unix domain socket
local all postgres md5
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all md5
# IPv4 local connections:
host all all 127.0.0.1/32 md5
Then restart pg server:
$> sudo service postgresql restart
Below is list of METHODS used to connect with postgres:
# METHOD can be "trust", "reject", "md5", "password", "gss", "sspi",
# "krb5", "ident", "peer", "pam", "ldap", "radius" or "cert". Note that
# "password" sends passwords in clear text; "md5" is preferred since
# it sends encrypted passwords.
Note: If you have not create you postgres user yet. Create that and now you can access postgres server using that user credentials.
TIP: If it does not work after postgres restart then close terminal and open again.
Simplest solution without changing configs. (ubuntu)
Change user, then connect to database cli.
sudo -i -u postgres
psql
taken from https://www.digitalocean.com/community/tutorials/how-to-install-and-use-postgresql-on-ubuntu-18-04
I was moving data directory on a cloned server and having troubles to login as postgres. Resetting postgres password like this worked for me.
root# su postgres
postgres$ psql -U postgres
psql (9.3.6)
Type "help" for help.
postgres=#\password
Enter new password:
Enter it again:
postgres=#
I had the same problem.
The solution from depa is absolutely correct.
Just make sure that u have a user configured to use PostgreSQL.
Check the file:
$ ls /etc/postgresql/9.1/main/pg_hba.conf -l
The permission of this file should be given to the user you have registered your psql with.
Further. If you are good till now..
Update as per #depa's instructions.
i.e.
$ sudo nano /etc/postgresql/9.1/main/pg_hba.conf
and then make changes.
If you want to keep the default config but want md5 authentication with socket connection for one specific user/db connection, add a "local" line BEFORE the "local all/all" line:
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local dbname username md5 # <-- this line
local all all peer
# IPv4 local connections:
host all all 127.0.0.1/32 ident
# IPv6 local connections:
host all all ::1/128 ident
Most of the solutions are suggest editing the pg_hba.conf.
For you who don't want to edit the configuration file, you basically just need to log in to the postgres user. If you are using/in Linux server, use this command
sudo -i -u postgres
It'll create user postgres and then log in to it. Now try your psql command again.
You can also add postgres user a password with the command: (you should be in root user)
passwd postgres
This is works because according to this PostgreSQL's Documentation,
Peer Authentication
The peer authentication method works by obtaining the client's
operating system user name from the kernel and using it as the allowed
database user name (with optional user name mapping). This method is
only supported on local connections.
The edits above worked for me, after I figured out that I needed to restart the postgres server after making them.
For ubuntu:
sudo /etc/init.d/postgresql restart
Changing METHOD peer to trust in pg_hba.conf (/etc/postgresql/9.1/main/pg_hba.conf | line 85) solves the issue. Adding md5 asks for a password, hence if there is a requirement to avoid using passwords, use trust instead of md5.
Use host=localhost in connection.
PGconn *conn = PQconnectdb(
"host=localhost user=postgres dbname=postgres password=123"
);
Please follow the below steps
1). First, navigate to the /etc/postgresql/{your pg version}/main directory.
My version is 10 Then:
cd /etc/postgresql/10/main
2). Here resides the pg_hba.conf file needs to do some changes here you may need
sudo access for this.
sudo nano pg_hba.conf
3). Scroll down the file till you find this –
# Database administrative login by Unix domain socket
local all postgres peer
4). Here change the peer to md5 as follows.
# Database administrative login by Unix domain socket
local all all md5
peer means it will trust the authenticity of UNIX user hence does not
prompt for the password. md5 means it will always ask for a password,
and validate it after hashing with MD5.
5).Now save the file and restart the Postgres server.
sudo service postgresql restart
Now it should be ok.
This error may occur when you do not provide the host. The following scenario resembles it.
user#homepc:~$ psql -d test_db -U test_user
psql: error: FATAL: Peer authentication failed for user "test_user"
user#homepc:~$ psql -h localhost -d test_db -U test_user
Password for user test_user:
Providing host resolved my issue in psql command line. Try providing host in connection configuration for postgress in rails.
the below command works for me:
psql -d myDb -U username -W
You need just set METHOD to trust.
#TYPE DATABASE USER ADDRESS METHOD
local all all trust
And reload postgres server.
# service postgresql-9.5 reload
Changes in pg_hba.conf dont require RESTART postgres server. just RELOAD.
pg_config is for compliation information, to help extensions and client programs compile and link against PostgreSQL. It knows nothing about the active PostgreSQL instance(s) on the machine, only the binaries.
pg_hba.conf can appear in many other places depending on how Pg was installed. The standard location is pg_hba.conf within the data_directory of the database (which could be in /home, /var/lib/pgsql, /var/lib/postgresql/[version]/, /opt/postgres/, etc etc etc) but users and packagers can put it wherever they like. Unfortunately.
The only valid ways find pg_hba.conf is to ask a running PostgreSQL instance where it's pg_hba.conf is, or ask the sysadmin where it is. You can't even rely on asking where the datadir is and parsing postgresql.conf because an init script might passed a param like -c hba_file=/some/other/path when starting Pg.
What you want to do is ask PostgreSQL:
SHOW hba_file;
This command must be run on a superuser session, so for shell scripting you might write something like:
psql -t -P format=unaligned -c 'show hba_file';
and set the environment variables PGUSER, PGDATABASE, etc to ensure that the connection is right.
Yes, this is somewhat of a chicken-and-egg problem, in that if the user can't connect (say, after screwing up editing pg_hba.conf) you can't find pg_hba.conf in order to fix it.
Another option is to look at the ps command's output and see if the postmaster data directory argument -D is visible there, e.g.
ps aux | grep 'postgres *-D'
since pg_hba.conf will be inside the data directory (unless you're on Debian/Ubuntu or some derivative and using their packages).
If you're targeting specifically Ubuntu systems with PostgreSQL installed from Debian/Ubuntu packages it gets a little easier. You don't have to deal with hand-compiled-from-source Pg that someone's initdb'd a datadir for in their home dir, or an EnterpriseDB Pg install in /opt, etc. You can ask pg_wrapper, the Debian/Ubuntu multi-version Pg manager, where PostgreSQL is using the pg_lsclusters command from pg_wrapper.
If you can't connect (Pg isn't running, or you need to edit pg_hba.conf to connect) you'll have to search the system for pg_hba.conf files. On Mac and Linux something like sudo find / -type f -name pg_hba.conf will do. Then check the PG_VERSION file in the same directory to make sure it's the right PostgreSQL version if you have more than one. (If pg_hba.conf is in /etc/, ignore this, it's the parent directory name instead). If you have more than one data directory for the same PostgreSQL version you'll have to look at database size, check the command line of the running postgres from ps to see if it's data directory -D argument matches where you're editing, etc.
https://askubuntu.com/questions/256534/how-do-i-find-the-path-to-pg-hba-conf-from-the-shell/256711
Many of the other answers pertain to settings in the various config files, and the ones pertaining to the pg_hba.conf do apply and are 100% correct. However, make sure you are modifying the correct config files.
As others have mentioned the config file locations can be overridden with various settings inside the main config file, as well as supplying a path to the main config file on the command line with the -D option.
You can use the following command while in a psql session to show where your config files are being read (assuming you can launch psql). This is just a troubleshooting step that can help some people:
select * from pg_settings where setting~'pgsql';
You should also make sure that the home directory for your postgres user is where you expect it to be. I say this because it is quite easy to overlook this due to the fact that your prompt will display '~' instead of the actual path of your home directory, making it not so obvious. Many installations default the postgres user home directory to /var/lib/pgsql.
If it is not set to what it is supposed to be, stop the postgresql service and use the following command while logged in as root. Also make sure the postgres user is not logged into another session:
usermod -d /path/pgsql postgres
Finally make sure your PGDATA variable is set correctly by typing echo $PGDATA, which should output something similar to:
/path/pgsql/data
If it is not set, or shows something different from what you expect it to be, examine your startup or RC files such as .profile or .bash.rc - this will vary greatly depending on your OS and your shell. Once you have determined the correct startup script for your machine, you can insert the following:
export PGDATA=/path/pgsql/data
For my system, I placed this in /etc/profile.d/profile.local.sh so it was accessible for all users.
You should now be able to init the database as usual and all your psql path settings should be correct!
If you are facing this issue with rails and you know that you already have created that user-name with password along with correct rights then you just need to put following at the end of your database.yml file.
host: localhost
overall file will look like below
development:
adapter: postgresql
encoding: unicode
database: myapp_development
pool: 5
username: root
password: admin
host: localhost
You do not need to touch you pg_hba.conf file at all. Happy coding
My issue was that I did not type any server. I thought it is a default because of placeholder but when I typed localhost it did work.
If you are trying to locate this file in Cloud 9, you can do
sudo vim /var/lib/pgsql9/data/pg_hba.conf
Press I to edit/insert, press ESC 3 times and type :wq will save the file and quit
In my case, I was not even able to edit or see the content of pg_hba.conf file.
What worked was:
/etc/postgresql/14/main$ sudo vi pg_hba.conf
Vi editor with sudo permission.
On CentOS 7, PG 10, the file path is
/var/lib/pgsql/10/data/pg_hba.conf
Also, If you don't have access to the script from postgres account you can use the approach below.
$ cat ./init-user-db.sh | sudo -i -u postgres bash