Superuser permission is required to create a geodatabase in PostgreSQL.
However, in AWS RDS instance we are receiving:
rds_superuser permission and rds_superuser is not superuser.
Is there a way to enable geodatabase in AWS RDS PostgreSQL with rds_superuser permission?
You need to create the database and the sde login manually using e.g. pgAdmin, and grant the rds_superuser group role to the sde login. Also create a schema named sde in your database, and make the sde login the owner of that schema.
Then you can create a .sde database connection in ArcCatalog using the sde login and, importantly, the *.rds.amazonaws.com hostname. Finally you can run the Enable Enterprise Geodatabase using this connection as your input.
This only works if you connect to the database using the *.rds.amazonaws.com hostname. Apparently, ESRI uses the hostname to determine if the database in question is an RDS server.
Once you've enabled the geodatabase you can connect to it with .sde connections using other dns aliases as well.
Refer to the ESRI documentation for further details: http://server.arcgis.com/en/server/latest/cloud/amazon/create-geodatabase-in-amazon-rds-for-postgresql.htm
Related
In order to execute a query on a local PostgreSQL database (v10.14; Amazon RDS) that fetches data from a remote database, also PostgreSQL (RDS), we're using the foreign data wrapper (FDW) postgres_fdw server and user mapping. Currently the user mapping contains user/password credentials for the remote RDS, stored with the user mapping in the local RDS. To become more secure we would like to get rid of the stored credentials.
One way of doing so that we could imagine is using the IAM role of the local RDS to connect to the remote RDS. The question is, is that possible with postgres_fdw, are there maybe other FDWs with the same feature set as postgres_fdw and allow IAM authentication?
Are there other ways to set up an FDW like this without storing the credentials inside the local RDS?
So, I've been looking around for more details, but can't find it.
I have a AWS RDS Postgresql cluster. In the typical sense, when I want to add a login to my database, I use the
create user xxxx with password 'yyy'
then I grant that user access to the tables and other rights.
Now, I tried to add another user with secrets manager linked to this RDS database.
I'm not sure what to do next....should that new user I only created in secrets, appear in the login for the database, because I don't see it? How would we grant access to the tables and other things for that user?
I would like to connect to a hosted remote mySQL DB (mariadb 10.1.39). I use the available fusionauth docker images (app and search) from docker hub and the published docker compose file. The db hosting provider does not grant superuser credentials. The assigned user rights should be sufficient to maintain the tables of the schema. Unfortunately, using the docker container mysql superuser credentials seems to be mandatory.
I imported the DB dump of a local (dockerized) mariadb (10.1.40) to the remote db. Username and schema name are the same local and remote. I tried not to provide DATABASE_ROOT_USER with the docker-compose yaml, but this approach ends in maintenance mode.
Is there an approach to connect to a remote mysql db without superuser credentials?
We will be enhancing our automated setup to better support external db service providers. See https://github.com/FusionAuth/fusionauth-issues/issues/95
Your current option is to create the schema manually. https://fusionauth.io/docs/v1/tech/installation-guide/fusionauth-app#advanced-installation
You may also try to use your user credentials in the superuser fields, it may work.
I am trying to run SET session_replication_role = 'replica'; in a GCP Cloud SQL Postgres 9.6 instance, however I'm encountering this error ERROR: permission denied to set parameter "session_replication_role" even if the postgres user is a cloudsql admin user. Do I have to spin up my own self managed instance to solve the problem or is there a way around it?
Unfortunately, it is not connected with the service is in Beta or not, you can't set session_replication_role in GCP Cloud SQL.
You need to have superuser privileges to do that operation, but GCP Cloud only allows to cloudsqlsuperuser privileges. It's features as follows:
When you create a new Cloud SQL for PostgreSQL instance, the default postgres user is already created for you, though you must set its password.
The postgres user is part of the cloudsqlsuperuser role, and has the following attributes (privileges): CREATEROLE, CREATEDB, and LOGIN. It does not have the SUPERUSER or REPLICATION attributes.
You can find much more information in this blog post.
From what I was looking at, since the service is currently in Beta, there are still some features that are not available, such as that. Therefore we would need to wait a bit more for Google to realease the final version of their product.
We also encountered same issue . This is because postgres user does not have Replication permission.
To resolve this issue:
a) Login with postgres user
b) Since postgres user has Create role permission. Now create a new user with below command:
CREATE USER <YOUR_USER> WITH PASSWORD '<YOUR_PASSWORD>' CREATEDB CREATEROLE REPLICATION IN GROUP cloudsqlsuperuser;
replace <YOUR_USER> with your user name and <YOUR_PASSWORD> with password.
c) Login with newly created user and run
SET session_replication_role = 'replica';
if you see response SET then you are good to go
For my application, I sometimes need to set session authorization to execute certain commands under a given user's permissions.
We're using an RDS behind the application, and our DB superuser on RDS keeps getting permission denied to set session authorization.
Is there a way to enable this on an RDS? Or is it just not a supported operation?
Thanks in advance!
alas, limitations of rds_superuser are not documented
The rds_superuser role is a pre-defined Amazon RDS role similar to the
PostgreSQL superuser role (customarily named postgres in local
instances), but with some restrictions. As with the PostgreSQL
superuser role, the rds_superuser role has the most privileges on your
DB instance
So if you get permission denied with rds_superuser, you probably just can't do it... (as some more better known limitations, like ownership override, fs related functions, limited extensions list and so on)