Difference between revisions of "2018/01/14"
(→step 4: installing Mastodon: saving work) |
|||
(4 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | {{page/date|nav=[no prev] .. [[2018/01/14|today]] .. [[2018/01/15|next]] }} | ||
==2018-01-14== | ==2018-01-14== | ||
My current plan is: | My current plan is: | ||
Line 5: | Line 6: | ||
# migrate the data there | # migrate the data there | ||
# install Mastodon under user "tootcat" | # install Mastodon under user "tootcat" | ||
+ | # configure nginx | ||
# run Mastodon's schema upgrade rake task | # run Mastodon's schema upgrade rake task | ||
# test the result as https://new.toot.cat (get it working) | # test the result as https://new.toot.cat (get it working) | ||
Line 14: | Line 16: | ||
====revisions==== | ====revisions==== | ||
* Decided it would simplify things if I went ahead and created the "tootcat" system user first. | * Decided it would simplify things if I went ahead and created the "tootcat" system user first. | ||
+ | * [https://github.com/tootsuite/documentation/blob/master/Running-Mastodon/Production-guide.md Instructions] wanted to configure nginx after installing Mastodon, and this did need to be looked into at some point, so added it as step 5. | ||
===Notes=== | ===Notes=== | ||
Upgrading Mastodon: | Upgrading Mastodon: | ||
Line 214: | Line 217: | ||
</pre> | </pre> | ||
...and then we move on to configuring Postgres (already done) and nginx, which I think I should add as step 5. | ...and then we move on to configuring Postgres (already done) and nginx, which I think I should add as step 5. | ||
− | ===step 5: configure nginx=== | + | ===step 5: configure nginx - ABANDONED for now=== |
+ | I made a copy of /etc/nginx/sites-available/default and called it toot-cat-new, then changed just a couple of things: | ||
+ | * The '''server_name''' was changed from <code>toot.cat</code> to <code>new.toot.cat</code> in two places. | ||
+ | |||
+ | ...and then I realized that this plan was going to require setting up extra instances of Puma and the media server (name?) on different ports from 3000 and 4000... which I think I know how to do, but this kinda crosses a threshold into territory uncertain enough that I decided to let a professional do it this time, and live to fight another day. |
Latest revision as of 19:10, 20 November 2022
Sunday, January 14, 2018 (#14)
2018-01-14My current plan is:
revisions
NotesUpgrading Mastodon: Work Logstep 1Created 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 2I'm calling the new db
step 3: migrate the dataDone earlier -- inside
Importing the data dump into the new db:
It was more or less at this point that I discovered that the There's no
Oh, but the actual
And then it finally occurred to me:
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 MastodonThe 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
rbenv ()
{
local command;
command="${1:-}";
if [ "$#" -gt 0 ]; then
shift;
fi;
case "$command" in
rehash | shell)
eval "$(rbenv "sh-$command" "$@")"
;;
*)
command rbenv "$command" "$@"
;;
esac
}
Skipping the bit about installing Ruby, since that is already installed on this server. chdir to
You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b <new-branch-name> HEAD is now at 35b8498... Skip ActivityPub Announces of non-public objects (#6230)
Your user account isn't allowed to install to the system RubyGems. You can cancel this installation and run: bundle install --path vendor/bundle to install the gems into ./vendor/bundle/, or you can enter your password and install the bundled gems to RubyGems using sudo. Password: Decided this was not the way to do it, and logged in as root:
Okay, so I guess it's back to the mastodon user...
> node-sass@4.7.2 install /home/tootcat/web/mastodon/node_modules/node-sass > node scripts/install.js node-sass build Binary found at /home/tootcat/web/mastodon/node_modules/node-sass/vendor/linux-x64-57/binding.node > node-sass@4.7.2 postinstall /home/tootcat/web/mastodon/node_modules/node-sass > node scripts/build.js Binary found at /home/tootcat/web/mastodon/node_modules/node-sass/vendor/linux-x64-57/binding.node Testing binary Binary is fine node-sass@4.7.2 /home/tootcat/web/mastodon/node_modules/node-sass ...and then we move on to configuring Postgres (already done) and nginx, which I think I should add as step 5. step 5: configure nginx - ABANDONED for nowI made a copy of /etc/nginx/sites-available/default and called it toot-cat-new, then changed just a couple of things:
...and then I realized that this plan was going to require setting up extra instances of Puma and the media server (name?) on different ports from 3000 and 4000... which I think I know how to do, but this kinda crosses a threshold into territory uncertain enough that I decided to let a professional do it this time, and live to fight another day. |