tmm1 / flyapp-mastodon Goto Github PK

Hello!

I tried using this repo to deploy Mastodon and one issue I had was that going to the URL caused it to hang/not show anything. It was a few days ago so I don't 100% remember what was the result, I remember it just hanging and doing nothing even if the monitoring page said that the "server started on 3000".

I was able to fix by removing the processes = ["rails"] in the [[services]] block (marcotteteam@2c1d5c3)

I wonder if anyone else had a similar problem and if removing this processes is the right fix?

I could not promote my own user to Owner and turns out the seeds were missing:

root@3d859385:/# tootctl accounts modify lubien --role Owner
Cannot find user role with that name
root@3d859385:/# tootctl accounts modify lubien --role owner
Cannot find user role with that name
root@3d859385:/# tootctl accounts modify lubien --confirm
OK
root@3d859385:/# tootctl accounts modify lubien --role Owner
Cannot find user role with that name
root@3d859385:/# tootctl accounts modify lubien --role Owner
Cannot find user role with that name
root@3d859385:/# tootctl accounts modify lubien --role 'Owner'
Cannot find user role with that name
root@3d859385:/# tootctl accounts modify lubien --role Owner
Cannot find user role with that name
root@3d859385:/# tootctl accounts modify lubien --role Admin
Cannot find user role with that name
root@3d859385:/# tootctl accounts modify lubien --role Admin

root@3d859385:/# cd opt/mastodon/
root@3d859385:/opt/mastodon# bundle exec rails db:seed
root@3d859385:/opt/mastodon# cd ..
root@3d859385:/opt# cd ..
root@3d859385:/# tootctl accounts modify lubien --role Owner

Need to revert this... whoops. Deployments now error with:

overmind: Can't find tmux. Did you forget to install it?

Originally posted by @mountainash in #22 (comment)

Mastodon contains a feature that creates a background job to retry if fetching remote media fails: mastodon/mastodon#11775.

Unfortunately, since Fly cannot mount the same volume in different process VMs, that means Sidekiq creates a valid database record and then writes the image into a container-only temporary file system. At that point Mastodon starts returning 404s for those images, but it has a valid DB record, so there's not any easy way to recover.

I think this means that Puma and Sidekiq have to run inside the same VM for this to work at all.