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.
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.