While taking a final look at instance.gen before releasing I noticed
that the release_env task outputs messages in broken english. Upon
further inspection it seems to have even more severe issues which, in
my opinion, warrant it's at least temporary removal:
- We do not explain what it actually does, anywhere. Neither the task
docs nor instance.gen, nor installation instructions.
- It does not respect FHS on OTP releases (uses /opt/pleroma/config even
though we store the config in /etc/pleroma/config.exs).
- It doesn't work on OTP releases, which is the main reason it exists.
Neither systemd nor openrc service files for OTP include it.
- It is not mentioned in install guides other than the ones for Debian
and OTP releases.
Since python doesn't have a way to lock deps for a particlar project
by default, I didn't bother with it. This resulted in mkdocs updating at
some point, bringing a breaking change to how tabs are declared and
broken tabs on docs-develop.pleroma.social. I've learned my lesson
and locked deps with pipenv in pleroma/docs!5. This MR updates Pleroma
docs to use the new tab style, fortunately my editor did most of it.
Closes#2045
* It was still written for From Source installs. Now it's both OTP and From Source
* I linked to the cheatsheet where it was about configuration
* I moved the mix tasks of the robot.txt section to the CLI tasks and linked to it
* i checked the code at https://git.pleroma.social/pleroma/pleroma/-/blob/develop/lib/mix/tasks/pleroma/robotstxt.ex and it doesn't seem to more than just this one command with this option
* I also added the location of robot.txt and an example to dissallow everything, but allow the fediverse.network crawlers
* The Thumbnail section still linked to distsn.org which doesn't exist any more. I changed it to a general statemant that it can be used by external applications. (I don't know any that actually use it.)
* Both the logo and TOS need an extra `static` folder. I've seen confusion about that in #pleroma so I added an Important note.
* Added "Migrate" to the title because these steps can also be used to migrate the instance to another server
* Added an optional step to reinstall pleroma (esp. for migrating servers)
* Currently the steps threw an error 'could not execute query: ERROR: function "activity_visibility already exists with the same argument types'
* I added a new step to drop and recreate an empty pleroma-database
* I played around with the `-c` and `-C` options of pg_restore, but dropping and recreating seemd to be the only way I got it working
* This was tested on Debian Stretch, psql (PostgreSQL) 9.6.15
Mark Felder