User:Woozle/toot.cat/2018/01/14

from HTYP, the free directory anyone can edit if they can prove to me that they're not a spambot
Jump to navigation Jump to search

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.