2018/01/14

2018-01-14

My current plan is:

1. create new system user "tootcat"
2. create a new Postgres db for toot.cat's Mastodon
3. migrate the data there
4. install Mastodon under user "tootcat"
5. run Mastodon's schema upgrade rake task
6. test the result as https://new.toot.cat (get it working)
7. write a script to automate the data migration
8. in close succession:
   1. run the migration script
   2. reconfigure nginx to point to the new instance

revisions

• Decided it would simplify things if I went ahead and created the "tootcat" system user first.

Notes

Upgrading Mastodon:

Work Log

step 1

Created user and group "tootcat" with /bin/bash as shell, no login allowed. I checked user "polymerwitch" (user for current Mastodon instance), and it has "sudo" membership -- but I'm not adding that, because it shouldn't be needed.

step 2

I'm calling the new db tootcat-masto-r1 (toot.cat Mastodon db revision 1).

root@tootcat:~# createdb --owner=tootcat tootcat-masto-r1

createdb: could not connect to database template1: FATAL: role "root" does not exist

Apparently pg assumes whatever the current system user is as its internal user as well.

root@tootcat:~# su - postgres -c 'createdb --owner=tootcat tootcat-masto-r1'

createdb: database creation failed: ERROR: role "tootcat" does not exist

root@tootcat:~# createuser --createdb tootcat

createuser: could not connect to database postgres: FATAL: role "root" does not exist - can't say I'm surprised

root@tootcat:~# su - postgres -c 'createuser --createdb tootcat'

Success.

root@tootcat:~# su - postgres -c 'createdb --owner=tootcat tootcat-masto-r1'

Success.

step 3: migrate the data

Done earlier -- inside /root/backups:

su - postgres -c 'pg_dump mastodon' > tootcat.sql

Importing the data dump into the new db:

root@tootcat:~# cd /root/scratch

root@tootcat:~/scratch# ls

tootcat.sql

root@tootcat:~/scratch# psql tootcat-masto-r1 < tootcat.sql

psql: FATAL: role "root" does not exist

I actually expected this, but just wanted to make sure.

root@tootcat:~/scratch# su - postgres -c 'psql tootcat-masto-r1 < tootcat.sql

-su: tootcat.sql: No such file or directory

Apparently this operates relative to the postgres user's home folder, or wherever you get put by default when logging in. Okay.

root@tootcat:~/scratch# su - postgres -c 'psql tootcat-masto-r1 < /root/scratch/tootcat.sql'

-su: /root/scratch/tootcat.sql: Permission denied

This is also unsurprising. Other users shouldn't have access to /root files.

It was more or less at this point that I discovered that the tootcat.sql file was zero bytes long, so apparently the export process wasn't happy either.

There's no /home/postgres, so we can't go there.

/root/scratch is already mode 777, so apparently that's insufficient.

Oh, but the actual tootcat.sql file is in /root/backups. Just to be sure, then:

root@tootcat:~/scratch# cd ../backups/

root@tootcat:~/backups# su - postgres -c 'psql tootcat-masto-r1 < /root/backups/tootcat.sql'

-su: /root/backups/tootcat.sql: Permission denied

As expected.

And then it finally occurred to me:

root@tootcat:~/backups# su - postgres -c 'pwd'

/var/lib/postgresql

Oh! Sneaksy, having a home folder outside of the /home folder. Just because /root does it doesn't make it okay; do as I say, not as I do....

root@tootcat:~/backups# cd /var/lib/postgresql/

root@tootcat:/var/lib/postgresql# mv /root/backups/tootcat.sql ./

root@tootcat:/var/lib/postgresql# chown postgres:postgres tootcat.sql

root@tootcat:/var/lib/postgresql# su - postgres -c 'psql tootcat-masto-r1 < tootcat.sql'

...and then stuff started happening that might have been the output of a successful import.

After taking a brief break, I come back to find that the process has completed... and a brief inspection shows that the db seems to be populated with data. I'm calling this step complete, then.

step 4: installing Mastodon

The official upgrade instructions mention that you should only ever use "tagged releases on production Mastodon instances", and therefore:

su - mastodon
cd ~/live
git pull
git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)

...except corrected for how things are set up here... and also I need to git clone instead of git pull since I'm doing the upgrade on a fresh deployment rather than in place on an existing one.

root@tootcat:/var/lib/postgresql# cd /home/tootcat

root@tootcat:/home/tootcat# su - tootcat

tootcat@tootcat:~$ mkdir web

tootcat@tootcat:~$ cd web

tootcat@tootcat:~/web$ mkdir mastodon

tootcat@tootcat:~/web$ cd mastodon

tootcat@tootcat:~/web/mastodon$ git clone https://github.com/rbenv/rbenv.git ~/.rbenv

Cloning into '/home/tootcat/.rbenv'...

remote: Counting objects: 2706, done.

remote: Total 2706 (delta 0), reused 0 (delta 0), pack-reused 2706

Receiving objects: 100% (2706/2706), 503.75 KiB 0 bytes/s, done.

Resolving deltas: 100% (1695/1695), done.

Checking connectivity... done.

tootcat@tootcat:~/web/mastodon$ cd ~/.rbenv && src/configure && make -C src

make: Entering directory '/home/tootcat/.rbenv/src'

gcc -fPIC -c -o realpath.o realpath.c

gcc -shared -Wl,-soname,../libexec/rbenv-realpath.dylib -o ../libexec/rbenv-realpath.dylib realpath.o

make: Leaving directory '/home/tootcat/.rbenv/src'

tootcat@tootcat:~/.rbenv$

tootcat@tootcat:~/.rbenv$ echo 'eval "$(rbenv init -)"' >> ~/.bashrc

tootcat@tootcat:~/.rbenv$ exec bash

tootcat@tootcat:~/.rbenv$ type rbenv

rbenv is a function

rbenv () 
{ 
    local command;
    command="${1:-}";
    if [ "$#" -gt 0 ]; then
        shift;
    fi;
    case "$command" in 
        rehash | shell)
            eval "$(rbenv "sh-$command" "$@")"
        ;;
        *)
            command rbenv "$command" "$@"
        ;;
    esac
}

tootcat@tootcat:~/.rbenv$ git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build

Cloning into '/home/tootcat/.rbenv/plugins/ruby-build'...

remote: Counting objects: 8588, done.

remote: Compressing objects: 100% (25/25), done.

remote: Total 8588 (delta 9), reused 24 (delta 3), pack-reused 8556

Receiving objects: 100% (8588/8588), 1.79 MiB 0 bytes/s, done.

Resolving deltas: 100% (5481/5481), done.

Checking connectivity... done.