Skip to content

Instantly share code, notes, and snippets.

@stulentsev
Created July 24, 2016 14:40
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save stulentsev/68f448f1ad037b8ddd4b7be09706359c to your computer and use it in GitHub Desktop.
Save stulentsev/68f448f1ad037b8ddd4b7be09706359c to your computer and use it in GitHub Desktop.

When running this command for the first time

$ bundle exec rake db:create

you may get this error

Couldn't create database for {"adapter"=>"postgresql", "encoding"=>"unicode", "pool"=>5, "username"=>"tulenmenu", "password"=>"tulenmenu", "database"=>"tulenmenu_development"}

FATAL: role "tulenmenu" does not exist

This means that user that you specified in database.yml does not yet exist. In order to create databases, we need a user that is capable of that. Postresql installations include a command we can use for this, createuser

createuser --createdb --pwprompt tulenmenu

And that's it. This, of course, assumes that createuser can already log into posgresql server without password and with super-user privileges.

Setting up local super-user

The key here is to change auth mode for local users. By default, it's peer (users will only have access to database named same as their username, and they have to use a password). We change it to trust mode (no database name check, no password). Open up your pg_hba.conf. On OSX it might be at /usr/local/var/postgres/pg_hba.conf. Find a line which reads something like

local all all peer

And change "peer" to "trust"

local all all trust

From the documentation:

When trust authentication is specified, PostgreSQL assumes that anyone who can connect to the server is authorized to access the database with whatever database user name they specify (even superuser names). Of course, restrictions made in the database and user columns still apply. This method should only be used when there is adequate operating-system-level protection on connections to the server.

trust authentication is appropriate and very convenient for local connections on a single-user workstation. It is usually not appropriate by itself on a multiuser machine. However, you might be able to use trust even on a multiuser machine, if you restrict access to the server's Unix-domain socket file using file-system permissions. To do this, set the unix_socket_permissions (and possibly unix_socket_group) configuration parameters as described in Section 18.3. Or you could set the unix_socket_directory configuration parameter to place the socket file in a suitably restricted directory.

So use it only on localhost and not in production.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment