2018/01/14
2018-01-14
My current plan is:
- create new system user "tootcat"
- create a new Postgres db for toot.cat's Mastodon
- migrate the data there
- install Mastodon under user "tootcat"
- run Mastodon's schema upgrade rake task
- test the result as https://new.toot.cat (get it working)
- write a script to automate the data migration
- in close succession:
- run the migration script
- 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.
- Apparently this operates relative to the
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....
- Oh! Sneaksy, having a home folder outside of the
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.