I have started to develop a Flask app using VSCode/WSL1 and have then migrated from WSL1 to WSL2.
Since then, I cannot connect to my the database running on windows using "localhost"
DATABASE_URI = 'postgresql://sysadmin:mypassword#localhost/db_dev'
I can only connect if use the ip address found in "cat /etc/resolv.conf"
DATABASE_URI = 'postgresql://sysadmin:mypassword#172.31.96.1:5432/db_dev'
But that IP address changes on every reboot, so that is not convenient at all.
It looks like networking has changed quite a bit between WSL and WSL2, but I cannot find an acceptable solution to this I would say rather basic issue.
There are no problems with my Postgres config, as I can connect using the ip address.
Related
Is it possible possible to connect to Fly.io Postgres from a NEXT.js API route served from a Vercel severless function, and if so, how?
I've read and reread the Fly.io Postgres docs, focusing especially on Connecting from outside Fly.io and (since my API routes use Prisma to connect to Postgres) Connecting with Prisma, but it seems I would need to either install flyctl or a set up a WireGuard Tunnel in Vercel, neither of which I could figure out how to do from web searches.
I found essentially the same question on the Fly.io community forum, but unfortunately, no one has answered it after 26 days (as of this writing).
To add a bit more detail, I'm familiar with Heroku Postgres, where a connection string is essentially all that's needed to connect, but it seems connecting to Fly.io Postgres requires a connection string plus a proxy created with flyctl. This was easy to get working on my local machine, but it's not clear how to do this on a remote host like Vercel.
One of the solutions is to allocate an ip address to your app with link here
fly ips allocate-v4 --app <pg-app-name>
Then add these service configurations to the fly.toml file
[[services]]
internal_port = 5432 # Postgres instance
protocol = "tcp"
[[services.ports]]
handlers = ["pg_tls"]
port = 5432
Redeploy your app with fly deploy
Go to your fly dashboard you will be able to see Ip Addresses that you can use as host to connect to the database
I'm running a composition of docker containers of a preexisting project on Ubuntu 20. One container for apache2, one for postresql. I can connect to the webserver through my browser and the webserver container establishes a connection to the postgresql container - so far everything works.
The problem is: I can't establish a connection from my host machine to the postgresql database using php. Whenever I try, I get an password authentication failed for user .. error.
I know that the php code, the username and the password are correct, as all three work when I execute them from within the webserver container.
$db_connection = pg_connect("host=db dbname=MYDB user=MYUSER password=MYPASS");
I configured /etc/hosts on my host to resolve "db" to 127.0.0.1 and also tried using host=localhost. Both didn't help.
Am I getting something wrong about how docker works? I found a couple of OSX solutions which were talking about docker containers running in virtual machines and therefore not being accessible from the host... Which is confusing, as apache2 is reachable from my host.
I did my research on stackoverflow tried solutions from e.g. Connecting to Postgresql in a docker container from outside but they didn't work for me.
I'm having big troubles connecting to PostgreSQL, installed in WSL2 Ubuntu, from the Windows 10 host.
Here is what I have done so far.
Set password for postgres user.
Set the following in pg_hpa.conf
local all postgres md5
host all all 0.0.0.0/0 md5
Set the following in postgresql.conf
listen_addresses = '*'
Tested successfully that I can connect with psql -U postgres - so password should be set correctly.
When I try to connect using either pgAdmin or psql from the Windows 10 host, I get the following error.
error: could not connect to server: FATAL: password authentication failed for user "postgres"
Anything else I can change in pg_hpa.conf or other PostgreSQL configurations which might help?
I'm thinking that I could have something to do with that WSL2 has its own IP, even tough that connections from the hosts are made appear coming from localhost. The connection seems to be made, but authentication failed for some reason when it is not made from within Ubuntu.
I later tested with nc -l 5432 and for some reason, port 5432 didn't reach WSL2 on local host, but did on WSL-2 IP. If I use any other free port e.g. 5434 (free both on Windows and WSL-2) it works fine and I can connect to the PostgreSQL service on WSl-2 through localhost on windows.
I didn't change any options since the original posted question - only the port.
Update: It turns out that there indeed was a process from an old install of postgres on Windows which was listening on port 5432. This of cause explains it all. ..:/
As was pointed out by the original poster, ensure that you do not have a Windows service already running and listening on that port. In my case it was a PostgreSQL instance installed as a Windows service. Whatever the underlying networking support, it seems you can have a process/service listening on port 5432 in Windows as well as a separate Linux process listening on port 5432 from WSL2.
It was not enough to stop the Windows PostgreSQL service. Connecting from the Windows pgAdmin4 installation program failed. I also disabled the service from Microsoft Services console.
I needed to also stop and start the WSL2 postgresql. Only then was I successfully able to connect from my Windows pgAdmin4 installation program to the WSL2 postgreSQL
I am running postgresql in WSL Ubuntu on windows. Everything is up to speed, my data is loaded and I wish to access the database through some graphical interface. I was thinking pgadmin4.
Is it possible to accomplish this through a windows install of pgadmin4? I installed pgadmin4 on windows and tried to connect the traditional way in the GUI through localhost but am not getting a connection. I figure there may be a special method here.
For everyone else stumbling across this: The best way to do this (that I know of) is to SSH into your local WSL and then configure the SSH in pgAdmin to that.
I have yet to figure out, how to use this remotely.
As long as postgres is running within your wsl2 instance (check with sudo service postgresql status) then within PgAdmin 4 (running in windows), all you need to do is click to "Register" a new server.
Then, while entering the Connection data, set host to localhost and port to 5432 (unless you specified unique port within your postgres instance when creating in wsl2.
See this answer for more detail
There is no special way needed, you should be able to get a connection. Just like your dev http ports are exposed to your browser on Windows, your db port should too.
I had to manually add localhost to pg admin though which is a bit weird.
Make sure your db service is up and running on Ubuntu, sometimes the db service is killed for no reason.
To see if your PostgresSQL service is up or not:
sudo service postgresql status
If it's not, start the service:
sudo service postgresql start
I've installed MongoDB on my Ubuntu 16.04 VPS and allowed connections through the firewall. When I run the server using the command (mongod), it starts without a problem and I can then connect to it (using RoboMongo as test application).
However, when I run the service automatically on startup (using systemctl), I cannot connect to it. I verified it was running, and could not run it myself as the address was already in use.
Does anyone have any experience with this, or any tips on how to solve the problem? The server will be running localhost only and I'm going to be using an SSH tunnel for testing purposes, so no authentication is necessary.
Anyone?
When you started mongod did you then provide a configuration file (using the --config or -f parameter)? If not then it defaults to listening on all interfaces.
The default configuration file which is used when starting the daemon with systemctl defaults to only listen on localhost preventing it from being available on the network. This is fine if you intend to connect to the server using a tunnel.