Add wiki contents to docs/ instead

2 files changed, 234 insertions, 0 deletions

diff --git a/docs/Running-Mastodon/Contribution-guide.md b/docs/Running-Mastodon/Contribution-guide.md
new file mode 100644
index 000000000..60f418dec
--- /dev/null
+++ b/docs/Running-Mastodon/Contribution-guide.md
@@ -0,0 +1,46 @@
+Development guide
+=================
+
+**Don't use Docker to do development**. It's a quick way to get Mastodon running in production, it's **really really inconvenient for development**. Normally in Rails development environment you get hot reloading of backend code and on-the-fly compilation of assets like JS and CSS, but you lose those benefits by compiling a Docker image. If you want to contribute to Mastodon, it is worth it to simply set up a proper development environment.
+
+In fact, all you need is described in the [production guide](Production-guide.md), **with the following exceptions**. You **don't** need:
+
+- Nginx
+- SystemD
+- An `.env.production` file. If you need to set any environment variables, you can use an `.env` file
+- To prefix any commands with `RAILS_ENV=production` since the default environment is "development" anyway
+- Any cronjobs
+
+The command to install project dependencies does not require any flags, i.e. simply
+
+    bundle install
+
+By default the development environment wants to connect to a `mastodon_development` database on localhost using your user/ident to login to Postgres (i.e. not a md5 password)
+
+You can run Mastodon with:
+
+    rails s
+
+And open `http://localhost:3000` in your browser. Background jobs run inline (aka synchronously) in the development environment, so you don't need to run a Sidekiq process.
+
+You can run tests with:
+
+    rspec
+
+You can check localization status with:
+
+    i18n-tasks health
+
+You can check code quality with:
+
+    rubocop
+
+## Development tips
+
+You can use a localhost->world tunneling service like ngrok if you want to test federation, **however** that should not be your primary mode of operation. If you want to have a permanently federating server, set up a proper instance on a VPS with a domain name, and simply keep it up to date with your own fork of the project while doing development on localhost.
+
+Ngrok and similar services give you a random domain on each start up. This is good enough to test how the code you're working on handles real-world situations. But as soon as your domain changes, for everybody else concerned you're a different instance than before.
+
+Generally, federation bits are tricky to work on for exactly this reason - it's hard to test. And when you are testing with a disposable instance you are polluting the databases of the real servers you're testing against, usually not a big deal but can be annoying. The way I have handled this so far was thus: I have used ngrok for one session, and recorded the exchanges from its web interface to create fixtures and test suites. From then on I've been working with those rather than live servers.
+
+I advise to study the existing code and the RFCs before trying to implement any federation-related changes. It's not *that* difficult, but I think "here be dragons" applies because it's easy to break.
diff --git a/docs/Running-Mastodon/Production-guide.md b/docs/Running-Mastodon/Production-guide.md
new file mode 100644
index 000000000..76964d995
--- /dev/null
+++ b/docs/Running-Mastodon/Production-guide.md
@@ -0,0 +1,188 @@
+Production guide
+================
+
+## Nginx
+
+Regardless of whether you go with the Docker approach or not, here is an example Nginx server configuration:
+
+```nginx
+map $http_upgrade $connection_upgrade {
+  default upgrade;
+  ''      close;
+}
+
+server {
+  listen 443 ssl;
+  server_name example.com;
+
+  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
+  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
+
+  keepalive_timeout    70;
+  sendfile             on;
+  client_max_body_size 0;
+  gzip off;
+
+  root /home/mastodon/live/public;
+
+  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
+
+  location / {
+    try_files $uri @proxy;
+  }
+
+  location @proxy {
+    proxy_set_header Host $host;
+    proxy_set_header X-Real-IP $remote_addr;
+    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
+    proxy_set_header X-Forwarded-Proto https;
+
+    proxy_pass_header Server;
+
+    proxy_pass http://localhost:3000;
+    proxy_buffering off;
+    proxy_redirect off;
+    proxy_http_version 1.1;
+    proxy_set_header Upgrade $http_upgrade;
+    proxy_set_header Connection $connection_upgrade;
+
+    tcp_nodelay on;
+  }
+
+  error_page 500 501 502 503 504 /500.html;
+}
+```
+
+## Running in production without Docker
+
+It is recommended to create a special user for mastodon on the server (you could call the user `mastodon`), though remember to disable outside login for it. You should only be able to get into that user through `sudo su - mastodon`.
+
+## General dependencies
+
+    curl -sL https://deb.nodesource.com/setup_4.x | sudo bash -
+    sudo apt-get install imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev nodejs
+    sudo npm install -g yarn
+
+## Redis
+
+    sudo apt-get install redis-server redis-tools
+
+## Postgres
+
+    sudo apt-get install postgresql postgresql-contrib
+
+## Rbenv
+
+It is recommended to use rbenv (exclusively from the `mastodon` user) to install the desired Ruby version. Follow the guides to [install rbenv][1] and [rbenv-build][2] (I recommend checking the [prerequisites][3] for your system on the rbenv-build project and installing them beforehand, obviously outside the unprivileged `mastodon` user)
+
+[1]: https://github.com/rbenv/rbenv#installation
+[2]: https://github.com/rbenv/ruby-build#installation
+[3]: https://github.com/rbenv/ruby-build/wiki#suggested-build-environment
+
+Then once `rbenv` is ready, run `rbenv install 2.3.1` to install the Ruby version for Mastodon.
+
+## Git
+
+You need the `git-core` package installed on your system. If it is so, from the `mastodon` user:
+
+    cd ~
+    git clone https://github.com/Gargron/mastodon.git live
+    cd live
+
+Then you can proceed to install project dependencies:
+
+    gem install bundler
+    bundle install --deployment --without development test
+    yarn install
+
+## Configuration
+
+Then you have to configure your instance:
+
+    cp .env.production.sample .env.production
+    nano .env.production
+
+Fill in the important data, like host/port of the redis database, host/port/username/password of the postgres database, your domain name, SMTP details (e.g. from Mailgun or equivalent transactional e-mail service, many have free tiers), whether you intend to use SSL, etc. If you need to generate secrets, you can use:
+
+    rake secret
+
+To get a random string.
+
+## Setup
+
+And setup the database for the first time, this will create the tables and basic data:
+
+    RAILS_ENV=production bundle exec rails db:setup
+
+Finally, pre-compile all CSS and JavaScript files:
+
+    RAILS_ENV=production bundle exec rails assets:precompile
+
+## Systemd
+
+Example systemd configuration for the web workers, to be placed in `/etc/systemd/system/mastodon-web.service`:
+
+```systemd
+[Unit]
+Description=mastodon-web
+After=network.target
+
+[Service]
+Type=simple
+User=mastodon
+WorkingDirectory=/home/mastodon/live
+Environment="RAILS_ENV=production"
+Environment="PORT=3000"
+ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb
+TimeoutSec=15
+Restart=always
+
+[Install]
+WantedBy=multi-user.target
+```
+
+Example systemd configuration for the background workers, to be placed in `/etc/systemd/system/mastodon-sidekiq.service`:
+
+```systemd
+[Unit]
+Description=mastodon-sidekiq
+After=network.target
+
+[Service]
+Type=simple
+User=mastodon
+WorkingDirectory=/home/mastodon/live
+Environment="RAILS_ENV=production"
+Environment="DB_POOL=5"
+ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 5 -q default -q mailers -q push
+TimeoutSec=15
+Restart=always
+
+[Install]
+WantedBy=multi-user.target
+```
+
+This allows you to `sudo systemctl enable mastodon-*.service` and `sudo systemctl start mastodon-*.service` to get things going.
+
+## Cronjobs
+
+I recommend creating a couple cronjobs for the following tasks:
+
+- `RAILS_ENV=production bundle exec rake mastodon:media:clear`
+- `RAILS_ENV=production bundle exec rake mastodon:push:refresh`
+- `RAILS_ENV=production bundle exec rake mastodon:feeds:clear`
+
+You may want to run `which bundle` first and copypaste that full path instead of simply `bundle` in the above commands because cronjobs usually don't have all the paths set. The time and intervals of when to run these jobs are up to you, but once every day should be enough for all.
+
+You can edit the cronjob file for the `mastodon` user by running `sudo crontab -e mastodon` (outside of the mastodon user).
+
+## Things to look out for when upgrading Mastodon
+
+You can upgrade Mastodon with a `git pull` from the repository directory. You may need to run:
+
+- `RAILS_ENV=production bundle exec rails db:migrate`
+- `RAILS_ENV=production bundle exec rails assets:precompile`
+
+Depending on which files changed, e.g. if anything in the `/db/` or `/app/assets` directory changed, respectively. Also, Mastodon runs in memory, so you need to restart it before you see any changes. If you're using systemd, that would be:
+
+    sudo systemctl restart mastodon-*.service