I followed these steps to install PostgreSQL with Homebrew (first time using Homebrew): http://dhilipsiva.blogspot.se/2013/02/install-postgresql-on-os-x-using.html
The last step didn't work. I assume it is supposed to start the server. However, I think I successfully created a database cluster and started the database server following the official documentation (17.2 and 17.3): http://www.postgresql.org/docs/9.2/interactive/runtime.html
My problem is that when I try to create a database using createdb mydb in the terminal, I get the message:
createdb: could not connect to database postgres: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/pgsql_socket/.s.PGSQL.5432"?
I'm very confused since a lot of the concepts being thrown around here (like sockets, path variables etc) are new to me. I'm also confused about the directory structure in Mac OS X, since I recently migrated from Windows. If anyone could just point me in the right direction it'd be much appreciated.
Update
As always, once you post, you find the answer. Well almost: the accepted answer in this post leads me to the conclusion that my Unix domain socket (whatever that is) is located in a place that Postgres doesn't expect.
Can't get Postgres started
Using the -h flag, it works. So the question is, how do I configure Postgres to look for the socket in the right place?
You are apparently running the default OS X supplied PostgreSQL client, which expects the Unix-domain socket in a different location than the Homebrew version. Basically,
/usr/bin/{createdb,psql,...} ---> /var/pgsql_socket/.s.PGSQL.5432
/usr/local/bin/{createdb,psql,...} ---> /tmp/.s.PGSQL.5432
So make sure your path is set correctly so that you are calling the right one.
Alternatively, you can override the socket location like this:
createdb -h /tmp ...
Related
I've been having a bit of trouble trying to install PostgreSQL 14 for the first time.
I would like to apologize in advance if this question has been asked in the manner that I am about to ask it, but I do not think it has. If it has been, please direct me to the appropriate location!
I've done a fair amount of Googling on the matter, and all the information that I find seems to be rather fragmented, or I end up following a spaghetti trail of hyperlinks (a la-do-this-and-follow-this-other-link-with-more-information-than-you-need-to-understand-this-other-required-portion).
Personally, I don't want to jump around to 50 different locations on the web to try and conjure up a piecemeal solution that I believe works, only to be proven wrong later. I want to know what to do and why it works. I've tried reading the documentation, and have given up on it, because to me, it seems to assume that the server has already been set up by a database administrator.
Instead of articulating my problem directly (as I seem to be having more trouble than I would like by trying to do so), I believe it would be easier to articulate my problem indirectly by stating what my expectations would be after installing PostgreSQL for the first time.
So to start, I will mention that I'm running Ubuntu 18.04.6 LTS, and am installing PostgreSQL 14.1 with the following command:
sudo apt install postgresql-14
Before continuing, I would like to add a side note in advance, that I do not want suggestions for an alternative OS or install method. I just want to be able to get "up and running" in a common-sense fashion from this exact point.
Moving on, I know that the aforementioned command creates a *nix user called postgres.
From here, I can now indirectly state my problem using an outline of what my goals and expectations are immediately after installing the software via that command.
After installing PostgreSQL via apt, these are my expected goals:
I want any client to be able to connect to the database server from any computer where a route exists from the client to the server.
For the sake of simplicity with these stated goals, when it is directly or implicitly stated that I am trying to connect a client to the database server, I am making the assumption that the client is able to, at a minimum, ping the machine that the server is running on, and vice versa.
For now, I'm not completely worried about the database being accessible from the public Internet.
I expect to be able to access the database from any computer on my LAN, whether it is an actual LAN, or some sort of logical LAN (like a WAN or a VPN).
If I change the PostgreSQL password of the postgres user, I expect that any client logging into the database server via the postgres user will require the password.
This means if I want to change the password to some_password via \password postgres or ALTER USER postgres WITH PASSWORD 'some_password'; (I am assuming this is how you change the login password of a PostgreSQL user), then...
I expect running psql [-h host] -U postgres -W from any host...
That when I am prompted to enter the password...
I can only log in by entering the exact password of some_password.
Entering any other arbitrary text for the password should not allow me to log in.
I am adding this as a requirement because previous install attempts have shown me that this is NOT the case.
I expect to be able to create a PostgreSQL user account other than postgres (e.g. db_user) with a password and have it be subject to the same requirements as the postgres user.
i.e. once the new account is given permission to log in, the same common-sense login requirements to log in must be imposed, i.e. you can't get in if you don't have the correct username/password combination.
If the process to achieve the aforementioned can be explained in such a way that it can be understood with minimal mental friction, I would be extremely grateful.
Feel free to assume that my knowledge is on par with that of a undergraduate CS student who just completed their first year of university, who also understands Linux filesystems and basic computer networking. I just want the answer to be as accessible to as many people as possible, as I am sure I'm not the only person who has struggled with installing PostgreSQL, in spite of having a power user's level of computer literacy.
sudo apt install postgresql
sudo -u postgres psql
Set a password for this user with \password or the other method you mention
sudo vi /etc/postgresql/10/main/pg_hba.conf
Make the only uncommented nonblank line in this file be host all all all md5
sudo vi /etc/postgresql/10/main/postgresql.conf
uncomment listen_addresses line and set it to '*'
sudo service postgresql restart
When you make a new user, you should also make a new database which has the same spelling as the user does. Otherwise you will need to specify the database name when you try to log in with psql -U, such as psql -U newname -d postgres -h[hhh]. Should you actually be running 14 not 10, then you will need to change the paths of the config files you need to edit accordingly.
I'm setting up a server, with postgresql running as a service. I can use nmap to get current postgresql version
nmap -p 5432 -sV [IP]
It returns:
PORT STATE SERVICE VERSION
5432/tcp open postgresql PostgreSQL DB 9.3.1
Is there a way to hide the postgresql version from nmap scanning? I've searched but it's all about hiding the OS detection.
Thank you.
There's only one answer here: Firewall it.
If you have your Postgres port open, you will be probed. If you can be probed, your service can be disrupted. Most databases are not intended to be open like this to public, they're not hardened against denial-of-service attacks.
Maintain a very narrow white-list of IPs that are allowed to connect to it, and whenever possible use a VPN or an SSH tunnel to connect to Postgres instead of doing it directly. This has the additional advantage of encrypting all your traffic that would otherwise be plain-text.
You have a few options, but first understand how Nmap does it: PostgreSQL database server responds to a malformed handshake with an error message containing the line number in the source code where the error occurred. Nmap has a list of possible PostgreSQL versions and the line number where the error happens in that particular version. The source file in question changes frequently enough that Nmap can usually tell the exact version in use, or at least a range of 2 or 3 version numbers.
So what options do you have?
Do nothing. Why does it matter if someone can tell what version of PostgreSQL you are running? Keep it up to date and implement proper security controls elsewhere and you have nothing to worry about.
Restrict access. Use a firewall to limit access to the database system to only trusted hosts. Configure PostgreSQL to listen only on localhost if network communication is not required. Isolate the system so that unauthorized users can't even talk to it.
Patch the source and rebuild. Change PostgreSQL so that it does not return the source line where the error happened. Or just add a few hundred blank lines to the top of postmaster.c so Nmap's standard fingerprints can't match. But realize you'll have to do this every time there's a new version or security patch.
I have installed the DSP(Dreamfactory Service Platform) locally on my Mac Book Pro using Bitnani.
I have a PostGreSQL server running locally on my Macbook, which I want to connect to using the DSP.
I am successfully able to connect to my PostGreSQL server from other applications, which essentially means that there is no problem with the setup.
However, on trying to connect the same from DSP I get the error:- "Failed to launch service "sql": CDbConnection failed to open the DB connection."
My connection string is :- "pgsql:host=localhost;dbname=Pinu"
Also, the password has been correctly entered.
The port is default as 5432. Whether or not I enter the same in the connection string, the connection always fails.
Even though I am trying to add the service as Remote SQL DB, I know that it's actually on the same local host. Not sure if that is the issue.
I also tried entering - 127.0.0.1 in place of localhost, but still I see the same issue.
Any help in this regard would be highly appreciated!
After talking to you via email, it looks like the root issue here is that you haven't successfully upgraded your DSP to the latest version. We are releasing DreamFactory version 1.8 on Bitnami tomorrow, so you should upgrade to the latest version.
As far as your PostgreSQL issue let's explore some options:
1) Connection strings:
a) pgsql:host=localhost;dbname=Pinu
b)
pgsql:host=localhost:5432;dbname-Pinu
c)
pgsql:host=localhost;port=5432;dbname=Pinu
2) If these don't work, try substituting your localhost with
127.0.0.1 (as you've tried previously, but test this in all scenarios).
3)
pgsql:host=localhost;port=5432;dbname=series1;schema=schema_name_here
Typically, Option A should work without a problem.
Give these a try if you would, and if you need some help upgrading then reach out to me again via email.
--Thanks,
Mark
Good day,
Currently I use MS Access at home for several Databases (for personal use).
At work, I use PostgreSQL, which is infinity times better. I want to start using postgres for my personally used databases, but I don't know where to start.
I've tried reading the documentation, but still don't know how to start. I don't have a server at home; is it possible I can just make a local database/tablespace? Or would I have to host a virtual server?
Note that I am willing to use other open source databases if there is an easy option out there - MS access is just so... terrible.
Thanks,
So, it seems you have Windows at home. You just need to download full installer for PostgreSQL:
http://www.postgresql.org/download/windows/
After installation it will automatically add starting postgres server as a service on local machine. That means, server will always run in background, but you can disable that later, or just uninstall.
After that, you can use pgAdmin (included in default installation package) or other client tools to access the DB engine.
UPD in pgadmin, create connection with this settings:
'localhost' as hostname;
port - 5432;
user, database - postgres (for testing purpose only - you should create your own user and tables with restricted rights later).
Password for postgres (that is DB admin user) must be entered during installation process.
Server settings are stored somewhere here:
"C:\Program Files\PostgreSQL\9.3\data"
pg_hba.conf - Client Authentication Configuration File
postgresql.conf - Configuration File
When I try to connect to my Postgres.app db using dbext, I get the following error:
dbext:PostgreSQL requires a '$HOME/.pgpass' file in order to authenticate. This file is
missing. The binary 'psql' does not accept commandline passwords.
Other programs connect just fine by using a "local" connection. (Postgres.app runs with my userid.)
In vim :!which psql correctly prints /opt/local/bin/psql (which I have symlinked to the one in the Postgres.app bin directory). And Postgres.app is set up to use "local" authentication and there's no clear sense of where a pg_hba.conf file would go (there is no etc directory in the app bundle). Moreover, Postgres.app doesn't have anything in its documentation about changing access configuration.
I've tried using dbext's :DBPromptForBufferParameters directly, as well as #tpope's vim-rails plugin (which returns without comment from dbext setup via :Rdbext.
So what do I do to get dbext to connect using a "local" connection?
Note - I spent a LOT of time trying to figure this out without trying the obvious, thus the post even when I already have the answer. I'm also curious to see if anyone else has a different approach.
It turns out you can just make an empty ~/.pgpass file (restricting read-write permissions to your userid only to avoid warnings). This was counterintuitive for me (since there is in fact no password), but I suppose in retrospect it's obvious I should have tried it.
I'll point this out on the dbext issue tracker.