DB Ownership / Wiping out Production

[pgr]

Hi. I’m trying to wipe out my production server, and I want to know what I am doing wrong (apart from “trying to wipe out my production server” which sounds really wrong, but it’s not really in production yet, I am just working on a migration).

I am using the Discourse Docker installation, which a colleague installed for me.

This is what I tried:

root@discourse:/docker-app/discourse# ./launcher enter app
root@discourse-app:/var/www/discourse# su - discourse

discourse@discourse-app:~$ cd /var/www/discourse
discourse@discourse-app:/var/www/discourse$ RAILS_ENV=production DISABLE_DATABASE_ENVIRONMENT_CHECK=1 bundle exec rake db:drop db:create db:migrate

PG::InsufficientPrivilege: ERROR:  must be owner of database discourse
: DROP DATABASE IF EXISTS "discourse"
Couldn't drop database 'discourse'
rake aborted!

So I went to check if this ownership was really like it says and I got this:

discourse@discourse-app:/var/www/discourse$ psql
psql (10.5 (Ubuntu 10.5-2.pgdg16.04+1))
Type "help" for help.

discourse=> SELECT d.datname as "Name",
pg_catalog.pg_get_userbyid(d.datdba) as "Owner"
FROM pg_catalog.pg_database d
WHERE d.datname = 'discourse'
ORDER BY 1;
   Name    |  Owner
-----------+----------
 discourse | postgres
(1 row)

discourse=>

So my questions would be…

1. Is it wrong not to have the database ownership set to discourse user?

2. Did I do this setup error? Or maybe my colleague. But what I mean to ask is: isn’t this something that comes with the Docker container provided?

3. How to go past this roadblock?

Thanks in advance for any help!

[pfaffman (Jay Pfaffman)]

If you want to blow away the database the easiest way is to delete the postgres stuff in /var/discourse/shared/standalone and then rebuild. (from outside the container). But this is simpler:

 cd /var/discourse 
./launcher stop app
rm -rf shared
./launcher rebuild app

[pgr]

Is there any difference in terms of what gets deleted?

I’d like to keep theme changes and settings, and delete only users, post data, etc. Does this method differ from the rake commands in terms of how much it recreates?

I don’t mind losing everything if necessary, I can redo the cosmetic changes, I am just asking.

[pfaffman (Jay Pfaffman)]

@pgr

I’d like to keep theme changes and settings, and delete only users, post data, etc.

That’s not what you asked for.

Themes are all in the database.

You can export the themes and reimport them on the new site. You can search here for ways to export and restore site settings.

[pgr]

I was willing to go ahead with the rake commands and then find out if I still had my custom theme.

But I have the necessary files to put it back in place.

Ok, so if your method is simple enough and equivalent to the other I will probably just try it.

Should I worry about my database ownership, for the future? Do I need to take any special care so it is created with the correct user as owner?

[pfaffman (Jay Pfaffman)]

If you use the launcher command it does the Right Thing. If you were to use an external database then it’d be more difficult.

[pgr]

Thank you Jay, you were very helpful as always.

[JamieLanger]

1. Is it wrong not to have the database ownership set to discourse user?
   A. NOt exactly
2. Did I do this setup error? Or maybe my colleague. But what I mean to ask is: isn’t this something that comes with the Docker container provided?
   A. yes, this is something that comes with the Docker container provided
3. How to go past this roadblock?
   A. Delete and rebuild

[pgr]

This image was installed months ago, in Sep 2018.

Now that I am rebuilding, should I do any updates/upgrades first? Can somebody point me to a nice tutorial for this, or at least tell what I should be searching for?

[zogstrip]

@pgr

Now that I am rebuilding, should I do any updates/upgrades first?

Rebuilding will take care of updating to latest

[pgr]

I did this procedure, and the rebuild went fine (and ran all the updates as promised - !).

BUT my data is still there. Deleting shared didn’t delete my data. Judging by the results of du I think my data is in standalone subdir, not in shared subdir…

root@discourse:/docker-app/discourse# du -h /docker-app/ --max-depth=1
2.6M    /docker-app/discourse
1.3G    /docker-app/standalone
1.3G    /docker-app/

So, can I delete docker-app/standalone? And did I delete anything important that I shouldn’t have in docker-app/discourse/shared?

P.S. - I did a snapshot of this VM before the delete, so I can go back in time if necessary

[pgr]

Just to leave some feedback here, since I had to re-do this today.

What eventually worked for me is to

• delete the full /docker-app/standalone directory
• no need to stop the container, the next command includes that in its script
• run ./launcher rebuild app
• the rebuild took about 10 minutes and included an update to the code by pulling it from GitHub.

I had some trouble on my next step, so I’ll also document it here in case it’s useful for someone. I needed to create a privileged database user that I could use from my DB Tool of choice (which is DB Weaver on Windows).

/launcher enter app
su postgres -c "psql discourse"

And then:

CREATE USER myadmin WITH PASSWORD 'xxxxxxxxx';
ALTER USER myadmin WITH SUPERUSER CREATEROLE CREATEDB;
GRANT ALL PRIVILEGES ON DATABASE discourse to myadmin;

Use \q to exit that shell.

I also created a Discourse admin with:
su discourse -c 'RAILS_ENV=production RAILS_DB=discourse bundle exec rake admin:create'

I hope this helps someone.