My question is: when I create a PostgreSQL user different from the default postgres user, should I also create a new database for that user to connect to?
What's the point of a setup like that?
A few explanations:
Don't use the postgres database for user data. It is intended for administrative purposes, for example as a database to connect to if you want to run CREATE DATABASE.
This has nothing to do with users.
Users are cluster-wide, that is, all databases in a cluster share the same users. Note that that does not imply that every user can connect to each database.
PostgreSQL command line programs have two defaults:
If you don't specify a database user, the default is the database user that is called like the operating system user.
If you don't specify a database, the default is the database with the same name as the database user.
I assume that it is this last default that inspires your question.
This is just a default value and should not influence your database design.
Create one database for each separate body of data, like all the data that belong to one application.
Create users as your application and data maintenance procedures require. It is a good idea to use different users for different tasks. For example, the user that performs the backup should not be used by your application to connect to the database.
No. Even if it's a local admin user so you don't need to go through sudo, you should just add export PGDATABASE=postgres to your .bashrc or .profile. I always make a new superuser with the name of my local user, and configure pg_hba.conf to allow local connection if necessary.
Related
I would like to develop a specific app that can be used to access a database developed in PostgreSQL. The app performs calculations and asks for the required data from the database server.
The user can download the app from a website if he has registered. After starting the app, the user has to log in to be able to use it.
Now the question:
What would be the most sensible solution in this example?
To be honest, I don't want to create a separate role for each user.
My idea is that the app only accesses the database via a general role, for example with the name "usership". With this role, a user only has well-defined read access. It is possible that users should also be able to save their own settings or measured values under their user name in certain tables. Access would then only be possible with the correct user name and password, which are specified with each operation on the relevant tables (however, this effort would not be necessary for read-only access to other tables with general data).
The question is whether there are any limits to how many apps can communicate with the database at the same time via the same database credentials / username "usership".
I don't want to have to create a separate DB role for each customer. Somehow that doesn't seem right to me, if only because adding new employees or deleting them means major interventions in the database schema (create / drop role). Basically, the app should do nothing else than a website where several users are logged in at the same time, the only difference being that the app does not run in the browser and everything works either on the client side at the application level or on the database server.
I'm not aware of any limits on sharing of usernames + passwords in postgres. You can have hundreds or thousands of concurrent connections using the same username + password.
There can be issues with many hundreds or thousands of concurrent connections, depending on your database hardware, especially ram.
While Postgres supports thousands of concurrent connections in theory, in practice I've run into memory issues as the # of open connections increases. If this is a problem and a large % of your connections are idle at any one moment, you can add a layer of connection pooling with something like pgbouncer, but keep in mind that adds another process to monitor.
In general, however, I wouldn't recommend this approach. You'd be providing direct, essentially anonymous access to your shared database. I expect it would be difficult to secure your database credentials in the client, and with direct access it should be fairly easy to construct SQL queries that would take down your database server. This would be difficult to monitor or prevent against since all users would be the same and you'd have no way to revoke access in case of abuse (without changing the password for everyone that has access).
From a security standpoint I'd definitely recommend being able to identify your users, monitor their usage separately and revoke access individually. I don't know of any performance issues with having many thousands of separate postgres users/credentials.
-- Scalability --
Using a postgres cluster with read replicas and load balancing (e.g. https://aws.amazon.com/premiumsupport/knowledge-center/requests-rds-read-replicas/) you should be able to scale this horizontally fairly easily if the need arises.
I'm trying to export all my users from one identity server instance to another. This includes all the roles that these users are part of, their permissions and claims.
What is the best way to export these users in bulk, and then importing them in another WSO2IS instance? The WSO2IS documentation is very limited about this subject: https://docs.wso2.com/display/IS500/Configuring+Users#ConfiguringUsers-Importingusers
Both IS instances have a postgres jdbc DB and have it running as a primary user store.
I believe you have to use separate databases for different IS instances. Otherwise you can just configure the same database in the new IS instance.
If you want to use a separate database, exporting the database dump from current user store database and importing to the new one/ create new using the dump should work.
I want to write a C++ administrative app to simplify management of DBs I am in charge of. Currently, when I want to tell if there are users connected to multiple Firebird databases operated by 2 different instances of it, I have to connect to every single DB and check. That's ok, but I don't want to register every new database that is being created when i don't look, I want some way to list databases that are currently open or otherwise in use by the server. Current 2 uses of this functionality I can think of are:
Auto-inclusion in backup procedure
Application update, which require users to log off (one-look and I would be able to tell whom to kick or at least which department to call)
Firebird does not have an API to list all available databases. Technically Firebird simply doesn't know about the existence of a database until you actually connect to it.
You might be able to find all databases that are being connected to using the Trace API or the monitoring tables, but that does not exclude the possibility that other databases exist on your system.
Our new security policies require data access restriction for developers to the production database. Setting up -RO parameter does not work for several reasons (extracts from 'Startup command and Parameter reference' http://documentation.progress.com/output/OpenEdge102b/pdfs/dpspr/dpspr.pdf)
1) "If you use the -RO parameter when other users are updating the database, you might see invalid data, such as stale data or index entries pointing to records that have been deleted."
2) "A read-only session is essentially a single-user session. Read-only users do not share database resources (database buffers, lock table, index cursors)."
3) "When a read-only session starts, it does not check for the existence of a lock file for the database. Furthermore, a read-only user opens the database file, but not the log or before-image files.
Therefore, read-only user activity does not appear in the log file."
We would like to be able to access data on the production database from OpenEdge Architect, but not being able to edit data. Is it possible?
In most security conscious companies developers are not allowed to access production. Period. Full stop.
One thing that you could do as a compromise... if the need is to occasionally query data you could give them access to a replicated database via OpenEdge Replication Plus. This is a read-only db connection without the drawbacks of -RO. It is real-time, up to date and access is separately controlled -- you could, for instance, put the replicated db on a different server that is on a different subnet.
The short answer is no, they can't access it directly and read-only.
If you have an appserver, you could write some code which would provide a level of dynamic RO data access via appserver or webservice calls.
The other question I'd have is - what are your developers doing accessing the production database? That should be a big no-no.
To connect to the database I use this example. But I can't find lessons on how to create a database.
For example:
connect to server
create new database
do something
drop database
close connection
Can anybody show me how to do it?
Thanks!
Follow the manual on how to create a database cluster:
http://www.postgresql.org/docs/9.1/interactive/creating-cluster.html
The database and users are created only once and you can use the client applications for that. Or are you trying to do it automatically as part of a software install package? After that you connect to it as many times as needed.
Since you are creating a new database and then dropping it, why not use the built-in SQLite database? You can do a completely in-memory database that will be lightning fast (unless you fill up available RAM).
I believe you can create databases by issuing standard SQL commands just as you can create tables in a database, as long as you are using a user (e.g. admin or similarly entitled user) that has permissions to create new databases.
So, all you need is to connect to the DB with the right user and then issue SQL commands with db.SQLExecute, such as "create database newDBname".