I'm trying to deploy Mantis BT on Heroku, using PostgreSQL as the database, as a proof of concept and learning exercise (or perhaps more accurately, as a "climb up a steep learning curve," since I'm a total newbie to all three technologies).
The deploy of the PHP app to Heroku went fine, and accessing the app's URL brings up its admin/install.php page. Provisioning the PostgreSQL database went fine, and gave me a database URL that (obfuscated) looks like this:
postgres://useruseruser:passwordpasswordpassword#ec2-107-21-219-201.compute-1.amazonaws.com:5432/dbnamedbname
I'm able to access the database via psql using those credentials, and the user (predictably) doesn't have the 'usecreatedb' privilege. I can't really make sense of the output of the PostgreSQL \z command, which seems to say I have no privileges on a table I've created:
dbnamedbname=> \z foo;
Access privileges
Schema | Name | Type | Access privileges | Column access privileges
--------+------+-------+-------------------+--------------------------
public | foo | table | |
(1 row)
but I put that impression down to not really knowing PostgreSQL's idioms yet.
Empirically I've been able to determine that I have the privileges CREATE (for both tables & indexes), SELECT, INSERT, UPDATE, DELETE, ALTER and DROP, which seem to be what Mantis BT requires for its "high-privileged database account."
So, it would seem that I have everything I need to fill in the Mantis BT admin/install.php form:
Hostname: ec2-107-21-219-201.compute-1.amazonaws.com
Username: useruseruser
Password: passwordpasswordpassword
Database: dbnamedbname
Admin Username: useruseruser
Admin Password: passwordpasswordpassword
Two notes here:
Yes, I know the regular DB user should not have all the privileges the Admin user has, but Heroku has only given me one DB username, and (because this is for now just a proof of concept) I didn't want to start down a possible blind alley of trying -- and failing -- to create a second user just yet.
The Mantis BT form says that the Admin username and password are "to create Database if required." Since the database ("dbnamedbname") already exists, I initially thought I could leave these blank, but Mantis BT insists on having values for them (and the install documentation says that if they are not supplied, "the database user will be used").
Yet, when I fill in the form using the values above and click the "Install/Upgrade Database" button, I get a failure indicating that the app could not connect to the database with the credentials provided (the exact same credentials, BTW, that I used to connect to the database using psql):
(One suspicious thing in the above screenshot -- that I haven't yet steeled myself to go hunting for in the code: the obscured Admin password in the page returned by the form submission only shows six bullets, whereas the actual password I pasted was 30 characters long.)
So, questions to anyone who understands how Mantis BT database setup works.
Is it actually passing only six characters worth of password to the DB server, or is that just a UI glitch?
Even after I figure out why it's not connecting to the database -- if that's really true -- is the notation "to create Database if required" (on the Admin username and password entries) really significant? Or will the silly thing go and try to create the database even though the specified database already exists?
If the answer to 2 above is "Yes, it will try to create the database anyway," what's the recommended way to work around that, given how Heroku goes about provisioning PostgreSQL databases?
The "Database connection failed" results from an initial connection attempt in which no database name is specified.
Attempting to access the server in this way from psql causes the following error:
$ psql -h ec2-107-21-219-102.compute-1.amazonaws.com -U useruseruser
Password for user useruseruser:
psql: FATAL: database "useruseruser" does not exist
Adding the database name as an additional parameter to that Connect() call causes the connection attempt to succeed, and thereafter all table creation steps and checks succeed.
It's not clear to me whether the problem is with PostgreSQL 9.4.5 per se, or whether it's something in how Heroku in particular configures their PostgreSQL servers.
Issue filed: https://www.mantisbt.org/bugs/view.php?id=20589
So, with the code patched, the answers to the questions I asked are:
It passes all parameters as entered, no truncations.
It doesn't attempt to create the database if it already exists.
N/A: Mantis does the right thing.
As a bonus answer, it's apparently not possible to create a lower-privileged user in a Heroku-provisioned PostgreSQL database -- you're stuck with the one user they give you. Which kinda sucks.
Related
I have a firebird database in a .fdb file, but the database do not have the SYSDBA user and I don't remember the credentials to login into the database. Are there any way that could reset the database credentials?
Like said by Mark, it is not that the database "does not have SYSDBA user" - databases in Firebird 2.x never have users - but that old trick was used to create SYSDBA named role in order to trigger names collision on login.
After scanning through 2007 Security presentation I have two suggestions for you.
You can try some tool that opens Firebird databases without using Firebird itself to learn what username can pull you out of the deadlock.
One such tool is Database Explorer in the IBExpert. Full IBExpert is paid for non-USSR states and free IBExpert Personal probably does not have the tool. But I hope the tool works in IBExpert Trial. Another tool is IBSurgeon FirstAID. And probably there are more tools featuring data extraction from corrupt databases. You only need to find and read one specific row.
The query to create the blocking role is given on the 23rd page of the presentation.
INSERT INTO RDB$ROLES(RDB$ROLE_NAME, RDB$OWNER_NAME)
VALUES (‘SYSDBA’, ‘LOCKSMITH’);
So you would have to look into the said table, find the row with the said role, and learn the username that has authority over that role (in the example it was LOCKSMITH).
After that you connect to any other database on the same server and you create the user with the name you learnt. Then you use that name to login into the problematic database and to DROP ROLE SYSDBA; COMMIT;.
You also can use Firebird Embedded. All server-coded security checks are bypassed in the Embedded edition of FB 2.x (but if DB designer added some ad hoc security checks in triggers - they will work). So you login into the problematic database using Firebird Embedded edition, any username and any password, and after that you drop the access blocking role.
In Firebird database doesn't contain password (until v3.0 as mentioned by #Arioch'The). The password is used only for server. Another words, you can copy database file from existed server to another (with known password) and open the database file.
I am trying to setup Postgres 9.3 on an Ubuntu 14 server, and I'm feeling pretty demoralised at this point. I've previously used MySQL, so I'm happy with general database concepts, as well as client/server models etc.
I start with two users - 'root' and 'sam' (me). As 'sam' I install postgresql using apt-get. This also creates a third user called 'postgres'.
Fine.
I'm told that to use postgres you must be logged in as the postgres user, so I switch to that account. Apparently this comes with a postgres admin role (I think I'm fine with the concept of roles per se), and apparently all roles have an associated database of the same name (?). So now I have a Linux account called postgres, a role called postgres, and a database called postgres? This all seems needless but I'm assuming it's useful for reasons I don't know about (not meant sarcastically - this is usually the case when things seem overly complicated at first).
So, to create a database, do I login to the server as postgres, start postgres by typing 'psql' (which doesn't ask for a password - why doesn't the postgres account have a password?) and proceed from there? Or should I create a new role? Does that role need its own Linux user? Should the role be the same name as the database I want to create?
I appreciate this is a bit of a jumble, but my confusion is such that I'm not even sure I understand the fundamentals here. I miss MySQL.
I've been mainly using the DigitalOcean tutorial for this - which are usually very good - but it didn't really make any of this clear. I also read the postgres docs (specifically the installation and users/roles sections) which didn't help, and the google results for this are even less helpful.
This is my last hope before I go back to the safety blanket of MySQL. Any suggestions for making this click?
OS usernames and Postgres DB usernames are not related; they live in seperate universes.
one exception: if you connect from the same machine via the unix-domain socket, and you don't explicitely specify a username, your OS name is assumed to be your DB-username, too. (which in most cases is not correct)
second exception: the "postgres" username is used both as an OS-username (owner of the files, uid of the running processes) and as the DBMS superuser.
Note: "root" is a bad name for a DB-user.
I want to reduce the number of requirements to get started with my webapp. At the moment you need to run a "create database, create user, grant all" script before you can start debugging.
I'd like the code to be checked out and run straight away without requiring developers to have to read through lots of documentation and do lots of manual steps.
h2 allows you to specify a connection string and it will create the db if it doesn't already exist.
Is it possible to do that using PostgreSQL?
Or is my only option (to meet the requirements) to configure h2 for dev work and PostgreSQL for production?
A connection in Postgres is always to a particular database, but by default every install will have a postgres DB intended for running maintenance commands. The user will still need to supply some superuser login credentials, but assuming you have those, you can run your "create database, create user, grant all" script automatically when the webapp is first accessed.
For instance, have a generated config file which is ignored in source control; before loading the file, check if it exists; if it doesn't, run the install routine.
You can even load an HTML form allowing the user to provide the superuser credentials, choose a name for the DB, and any other commonly-changed configuration options. If these are all defaulted, the "manual step" is simply to glance that they are correct, and click "OK".
Changing the password is easily done through the console. Is there any way to change the master username after creation on RDS for PostgreSQL? If so, how?
You can't change username. You can check the following links that describe how to change master password and if Amazon adds the ability to change username you will find there:
Try to find at AWS CLI for RDS:
modify-db-instance --db-instance-identifier <value> --master-user-password (string)
--master-user-password (string)
The new password for the DB instance master user. Can be any printable
ASCII character except "/", """, or "#".
Changing this parameter does not result in an outage and the change is
asynchronously applied as soon as possible. Between the time of the
request and the completion of the request, the MasterUserPassword
element exists in the PendingModifiedValues element of the operation
response. Default: Uses existing setting
Constraints: Must be 8 to 41 alphanumeric characters (MySQL, MariaDB,
and Amazon Aurora), 8 to 30 alphanumeric characters (Oracle), or 8 to
128 alphanumeric characters (SQL Server).
The Amazon RDS Command Line Interface (CLI) has been deprecated. Instead, use the AWS CLI for RDS.
Via the AWS Management Console, choose the instance you need to reset the password for, click ‘Modify’ then choose a new master password.
If
you don’t want to use the AWS Console, you can use the
rds-modify-db-instance command (as per Amazon’s documentation for RDS)
to reset it directly, given the AWS command line tools:
rds-modify-db-instance instance-name --master-user-password
examplepassword
No. As of April 2019 one cannot reset the 'master username'.
You cannot do it directly. However you can use the database migration service from AWS:
https://aws.amazon.com/dms/
Essentially you define the current database instance as your source and the new database with the correct username as your target of the migration.
This way you migrate the data from one to another database instance. As such you can change all properties including the username.
This approach has some drawbacks:
You need to configure the migration. Which takes a bit of time.
The data is migrated. This may lead unexpected behavior since not everything is eventually migrated (e.g. views etc.)
It depends how you setup everything you may experience a downtime.
Though this may not be ideal for every use-case, I did find a workaround that allows for changing the username of the master user of an AWS RDS DB.
I am using PgAdmin4 with PostgreSQL 14 at the time of writing this answer.
Login with the master user you want to change the name of
Create a new user with the following privileges and membership
Privileges and Membership
Can login - yes
Superuser - no (not possible with a managed AWS RDS DB instance, if you need complete superuser access DO NOT use a managed AWS RDS DB)
Create roles - yes
Create databases - yes
Inherit rights from the parent roles - yes
Can initiate streaming replication and backups - no (again, not possible directly without superuser permission)
Be sure to note the password used, as you will need to access this new account at least 1 time to complete the name change
Register a server with the credentials created in step 2. Disconnect from the server but do NOT remove it! Connect to the new server created
Expand Login/Group Roles and click on the master user whom you are changing the name
Click the edit icon, edit the name, and save.
Right click the server with the master username, select Properties
Update the name under the General tab if desired
Update the username under the Connection tab to whatever you changed the master username above
Save and reconnect to the server with the master user
You have successfully updated the master user's name on a managed AWS RDS DB instance, proud of you!
As #tdubs's answer states, it is possible to change the master username for a Postgres DB instance in AWS RDS. Whether it is advisable – probably not.
Here are the SQL commands you need to issue:
Create a temporary user with the CREATEROLE privilege (while being logged in with the old master user)
CREATE ROLE temp_master PASSWORD '<temporary password>' LOGIN CREATEROLE;
Now connect to the database with the temp_master user
ALTER ROLE "<old_master_username>" RENAME TO "<new_master_username>";
-- NOTICE: MD5 password cleared because of role rename
ALTER ROLE "<new_master_username>" PASSWORD '<new password>';
Now connect to the database with the <new_master_username> user in order to clean up the temporary role
DROP ROLE temp_master;
And you're done!
Warning
AWS RDS does not know that the master username has been changed, so it will keep displaying the old one and assumes that is still the master username.
This means that if you use the AWS CLI or website to update the master password, it will have no effect.
And when connecting to the database with psql you'll see:
WARNING: role "<old_master_username>" does not exist
As I attempt to create my initial user account on postgresql, I am prompted for my password, though when I enter the correct one I recieve:
createdb: could not connect to database template1: FATAL: password authentication failed for user "thomasmurphy"
I am installing through brew. My thought is that somewhere along the line I've set a password different from my system one. How do I remove all users so I can reset this pass.
I get my permission denied even if I su to postgres. I have gone through every thread on stackoverflow on this issue, and have tried:
*modifying my pg hba_conf
*updating my gems and developer tools
*running brew doctor
*reinstalling postgres
*all the other command line ideas through the thread
My situation seems to not have cropped up before, which convinces me I've set a password at some point that is now tripping all of my attempts. Adding to this theory is that I have a postgres setup on my work computer, also on mavericks, function perfectly.
Note that unless you changed defaults, homebrew installs Postgres with you as the superuser rather than as the postgres user. The issue might be that you're trying to use postgres "as normal" whereas it doesn't need or event want the usual postgres user references.
You see the list of users on the system using cat /etc/passwd, and you can change an arbitrary password by running chpass as root.