I have to run a simulation with several postgresql databases spread on different machines which all of them are running linux.
I successfully compiled and built postgresql from the source code and I can also run the server, but when I try to create a new db with this command:
./postgresql/bin/createdb db1
I get this error:
createdb: could not connect to database postgres: FATAL: role "giulio" does not exist
where giulio is my username to access all the machines.
On some machine it works while on other it does not. I really cannot figure out the root of the problem. I suppose it is something related with the access control of postgres.
I did several research on google but I was not able to found and to solve the problem.
Does anyone know how to get this work?
Thanks,
-Giulio
PostgreSQL has its own users and roles that are separate from that of your OS. Generally there is a dedicated super user, postgres. For user management info, look here:
http://www.postgresql.org/docs/9.1/interactive/user-manag.html
When executing postgres commands, you need to specify the user with the -U flag (unless you are already logged in as an existing db user). When you called the createdb script, because you didn't use the -U flag, the server assumed that the uid of the caller (giulo) should be used, but you didn't add a user "giulio" to the db, and hence the error message.
So execute the command as
./postgresql/bin/createdb -U postgres db1
and it should work. Then, later on, you may want to create other users and roles in your db rather than doing everything as the superuser.
I would assume that on the machines where the user "giulio" is already known, you executed initdb with exactly this user making him the DB superuser. A quote from inidb(1) (emphasis mine):
--username=username
Selects the user name of the database superuser. This defaults
to the name of the effective user running initdb. It is really
not important what the superuser's name is, but one might choose
to keep the customary name postgres, even if the operating sys‐
tem user's name is different.
On the other machines I assume you did execute initdb with another user, hopefully using postgres.
In order to get back on the standard track I propose, that you delete the database cluster on the machines where "giulio" is the superuser and setup a new database cluster using the standard postgres user. Then add another user "giulio". This will avoid more confusion down the road as some scripts/programs expect a superuser account named postgres.
My answer was more simple...I realized I needed to just run the following:
brew install postgresql
then to check if it worked I ran:
which createdb
to check the file path and if it worked, and it had ! Hope this helps.
Related
I couldn't find the answer in the docs, what exactly is a superuser in postgres?
Does the superuser have all privileges? Is it per database? Per instance?
https://www.postgresql.org/docs/current/static/sql-createrole.html
These clauses determine whether the new role is a "superuser", who can
override all access restrictions within the database.
yes - all privileges in all databases on the specified cluster
A superuser in PostgreSQL is a user who bypasses all permission checks.
Superusers can run commands that can destabilize or crash the database server (e.g., create C functions) and access the operating system.
Superuser is per database. From manual:
SUPERUSER
NOSUPERUSER
These clauses determine whether the new role is a "superuser", who can override all access restrictions within the database. Superuser status is dangerous and should be used only when really needed. You must yourself be a superuser to create a new superuser. If not specified, NOSUPERUSER is the default.
The superuser role bypasses all permission checks.
The term "cluster" in PostgreSQL is a historical and it is un-related to the PostgreSQL command CLUSTER, which is about organizing tables - you set user per-database, not per-cluster. A cluster is created when PostgreSQL is installed. The installation will usually do initdb - it will create a new cluster with one database in for you. Cluster is just data dir with databases inside. For location of that data dir look into manual.
I have an application that will be creating and dropping postgres databases. The application itself has its own sql server database. Kind of a bizarre architecture but it's not by choice.
I'm a little confused on how I should connect to the postgres server to execute these create table and drop table commands. Normally in an app.config or web.config, the connection string would specify the database. In this case, I just want to specify the server.
Can queries be run directly to a postgres server, without a particular database?
Should I use the postgres database that was created by the server? I tried this... select * from pg_database and then drop database DBNAME with a result from the first query, and it gave an error saying the database does not exist.
Or I could create an empty database to connect to and submit the queries to it, despite it not being used for anything.
Can queries be run directly to a postgres server, without a particular database?
No. PostgreSQL requires that you connect to a specific database.
It's possible that restriction could actually be relaxed eventually, so you could do things that only work on the shared catalogs from a connection to no particular database. It'd require changes to how authentication works and all sorts of things, though, and I don't think having an "admin database" like the usually-empty postgres database is really a problem.
Should I use the postgres database that was created by the server?
Generally, yes. It's possible to DROP the postgres database, but you should usually just leave it alone and use it as an admin database.
You could connect to the postgres database and then run drop database <DBNAME> from there, yes. Another option would be, say, template1. (I would avoid template0 since that's essentially the root template from which template1 was created, and you could always recreate template1 quickly from template0 if something happened to it, assuming you haven't modified template1 but not template0.)
I usually connect to postgres, myself, for server-level commands.
I ran DROP DATABASE droptest; via psql after creating an empty database and seeing it returned from a pg_database query, so that definitely works in general.
Perhaps it was somehow deleted via some other process in the interim between when you queried things and when you did the DROP....
Another option would be to shell out to the command line tool dropdb instead. This is a wrapper around drop database and is what I generally use both for manual and automated instances of database drops.
From what I read so far, the WL 6.1 documentation does not much care of this, and it's assumed that database user ID is SYSADM or something like that. Also, I did not see any explicit explanation what privileges the user ID must have.
While SYSADM is fine for development or staging environment, for production is desired to allow the DB user as less as possible, on the other hand I don't wish to get some exceptions related to weak permissions.
Is there any documentation or other source which explicitly mentions/explains what permissions DB2 user ID must have for Worklight 6.1 datasources?
UPDATE: My understanding is that for WL application work (not install) must be used a separate DB user (mostly for security reason, give as less as possible permissions in production). My question above refers to that "application" DB user. It's clear that create tables and schemas activity can do any DB ID, including SYSADM, which is overkill to further work.
I am asking about DB2 user which configured in WAS datasources, once someone else created DBs, schemas and tables.
The DB2 user used to connect to the datasources need not have any special privileges other than to be able to connect to the Worklight databases. The DB2 user that is used to actually create and initially populate the databases must have SYSADM or SYSCTRL privileges, but these are not needed once the database is set up.
There is more information in the documentation, here: Creating the DB2 databases
The documentation defines the privileges required for a user that can create the tables at install time, upgrade the tables for a new Worklight version and use them at runtime.
At runtime, you need, for each table created: SELECT, UPDATE, INSERT, DELETE. And you need to be able to select a SEQUENCE.
The list of tables and SEQUENCE for Worklight can be found in
/WorklightServer/databases/create-worklight-db2.sql and create--worklightreports-db2.sql
I installed postgreSQL by default with apt-get and I believe it has automatically added a user for me called "postgres".
I only have one database that I want to sort on postgres, so is
there any point creating another user account for this database or
should I just keep with the one which is installed with postgreSQL
"postgres"?
The user account postgres which is made for me, is it given some
kind of default password? Is it recommended that I put in my own
password?
EDIT: I misinterpreted the question, the OP is asking about internal users, not system users
Original Answer: System users for running servers
Most services running on a linux box are given their own independent user, as a standard security practice. In the off-chance that the postgreSQL server was compromised -- either you made a mistake, or there was a vulnerability in postgresql, or whatever -- the attacker can only gain access to the resources allowed to the user running the postgresql server. If that user is root, you lose the machine. If that user is your user, you lose not quite as much. If that user is postgres, which only has minimal access to anything.. you lose the database, and that's all.
So:
You merely need a single user for the postgreSQL server, regardless of what, exactly, that server process is hosting. If (it sounds like one was) a user was created for you automatically, you're all set with this step. If you need to make one manually (sounds like you don't), you would also have to change the permissions so that the new user can access only what it needs to.
That account very possibly cannot be directly logged into; if it has a password at all it's a lot of random data. In order to use the account, you need to start out as root, and then voluntarily "downgrade" yourself to postgres. In the case of the server, root starts the server "under the name of" postgres. I would advise leaving it alone.
Second Answer: Database users
Once you have a server running, the server will keep its own set of users, for the purposes of accessing the database. The simplest architecture you could use there is just having a base user with full permissions do everything. While this works, it is not advised if you are hosting this externally. A more preferable solution is to have a set of users, similar to how the OS is set up: a bunch of users to do specific tasks, and one admin user to rule them all. That said:
You don't have to, but if you are going to host this anywhere (if you're not just using it for personal things, and it's world-accessible), I would advise extra users with limited permissions.
http://archives.postgresql.org/pgsql-admin/2001-10/msg00192.php
There is no password by default; create one with ALTER USER.
Passwords do not take effect unless pg_hba.conf is set up to use them. If
it is, and you have not assigned a password to postgres, you will not be
able to connect as postgres.
re 1)
the default database user that is created during installation is a "superuser" and for the same reason you should not do your daily work as "root", you shouldn't work with a superuser in a DBMS. So the answer is a clear: yes, do create a second user. You can grant that role all privileges on the default database (also called postgres), so that you don't need a second database.
More details on how to create a user and how to grant privileges can be found in the manual:
http://www.postgresql.org/docs/current/static/sql-createuser.html
http://www.postgresql.org/docs/current/static/sql-grant.html
re 2)
I don't know Linux that well, but usually you should have been asked for a password during installation. At some point in the installation a new data directory is initialized using the command initdb which requires a password to run.
If you don't know the password, you log into the postgres linux account, then you can probably run psql without specifying a password. That enables you to reset the database password and create a new user.
More details about users and authentication are in the manual:
http://www.postgresql.org/docs/current/static/client-authentication.html
http://www.postgresql.org/docs/current/static/user-manag.html
Problem
Is it somehow possible to create a Windows Authentication login for a SQL database without performing a check for the user at creation time?
Example
Consider ServerA that exists in our DomainA, and ServerB that exists in the customer's DomainB. Being separate companies, DomainA and DomainB never share resources. But, if we backup from ServerB and restore to ServerA, we are able to see the existing SQL logins for users from DomainB, and even modify and code against these logins. This is good, because we are able to develop the database schema on ServerA and then publish to ServerB.
But, if I want to add a new user for this database, and am working on ServerA in DomainA, the following command produces an error:
CREATE USER [DomainB\User];
Windows NT user or group 'DomainB\User' not found. Check the name again. (Microsoft SQL Server, Error: 15401)
This is bad, because we're no longer able to develop on ServerA using the same schema as ServerB.
Backstory
I'm attempting to bring our database-driven application's database schema into source control using a Visual Studio 2010 Database Project. It's important to me to make this work well enough to convince the boss not to continue using 60-GB database backups in a zip file as a means of 'Version Control' (especially since this is just for schema, and not a backup routine). VS2010 DB Projects use scripting to create/modify databases, and so they can't create WinNT users for an unknown domain. In order to get the boss's buy-off, we're going to have to be able to match the capabilities of restoring a backup, and that means being able to re-create users for domains that we don't have access to.
Using SQL Server 2008 in my case.
Note - DBProjects are best suited to managing and versioning your SCHEMA, not your data.
If you want to keep rolling backups of your SQL databases as a whole, then I'd recommend a decent backup strategy.
If you want to better manage your databases' evolving schemas, then using DBProjects may well be your best bet.
FWIW, if you reverse-engineer a DB into a DBProj, you could then run a script to replace DomainB\known-user with DomainA\known-user prior to deploying within DomainA, no?
No, because SQL needs to know the windows SID (ugly GUID) of the user at the time it's created.
Note that you can, however create a SQL or Windows User with the same name and password as your remote SQL, Machine, or Domain user, and it will be able to log in.