``git tag -l | sort -V | head -1`` will consider release candidates as the latest version, even if there's a stable release, due to how `sort -V` orders strings. Adding ``grep -v 'rc[0-9]*$'`` to filter out the release candidate tags fixes this.
* "gcc-6" should just be "gcc"
gcc-6 isn't a valid package name
* It was `adduser mastodon` for a reason
making it with `--system and --disabled-password` breaks the rest of the guide where `su - mastodon` is used.
I use this method as it makes maintaining the Mastodon instance easier.
* eval "$(rbenv init -)" should be in ~/.bashrc as well
otherwise the correct ruby version isn't used
* Use sudo su - instead
- Nginx duplication in packages installation
- Specify the user type for `mastodon` (--system and --disabled-password)
- Simplify services start-up
- Clearly write how to check services are running (or not) with `systemctl status`
* Complete re-write of Mastodon Production Guide
I re-wrote the Mastodon Production Guide so that it has a better structure.
Work on this re-write was done on my own repo:
https://github.com/staticsafe/mastodon-documentation
* Fix typo in a heading
* Change node.js Repository section to use curl|bash method.
For simplicity's sake
* Add an explanation of the dependencies
Added in the "Various Other Dependencies" section.
* Fix links to the Ruby project, was using the link to Rails previously.
* Add Let's Encrypt section with a short guide to certificate tool installation, certificate generation and automated renewal.
* Use systemctl instead of service in LE section
This is for consistency reasons.
This change will help users avoid unnecessary procedure to
complete `bundle install` outside the container.
The explanation
> To generate the PAPERCLIP_SECRET, SECRET_KEY_BASE, and
> OTP_SECRET, you may use:
>
> ```
> rake secret
> ```
gives users a false impression that secrets have to be filled in
before the image can be built. Here, with introduction of CLD3,
completion of `bundle install` became more involved procedure to
prepare tools and libraries as well as higher version of Ruby.
When a provider other than virtualbox is registered in Vagrant, `vagrant up` can not start Mastodon.
For example, it corresponds to the environment where Parallels Desktop is installed.
`assets` are now at `packs`. Unfortunately this change will permanently cache `stats.json` and `report.html`, but these aren't super critical since they're just for debugging. I confirmed that `manifest.json` is not affected and no other non-fingerprinted assets are affected.
Since the document specifies the `--pure-lockfile` flag, it seems inaccurate to say, "Similarly, installing JavaScript dependencies doesn't require any flags."
I've changed the text accordingly. I hope it's appropriate!
* Add a Debian 8 installation note
According to the conversation in f0a863feec, Debian 8 installs
an older version of nginx by default. This adds a note telling people
how to install a newer one.
* updating wording
* Create Serving_a_different_domain.md
Add extensive documentation for WEB_DOMAIN, as the feature is ill-documented and may be confusing.
* Fix Serving_a_different_domain.md
* Webfinger discovery workaround has made its way to v1.3.0
These tasks sometimes fail under non-Docker installations when the administrator tries to run them without explicitly requesting the production environment.
* Avoid hard-coding ciphers into configuration
This change allows OpenSSL to choose the most appropriate available cipher(s) from the HIGH cipher suite. This is sufficient to get an A on the SSLLabs.com tests suite. If MEDIUM is allowed as well, the grade drops to a B which is still more than adequate for most deployments.
This type of configuration would prevent problems such as the current inability of Tusky on Android 7 devices to connect to some Mastodon instances.
The main benefit though, is this delegates the decisions about which ciphers are "good" and which ciphers are "bad" to the experts; the distribution security teams and the OpenSSL developers. If a weakness is found in a particular cipher it will get moved from HIGH to one of the lower classes (or removed entirely) and this will get deployed just like any other security update. Similarly, if new stronger ciphers are standardized (such as Curve 25519) - these will immediately become available without needing to change the configuration.
Hope this helps!
Note: I have not been able to test this change with Mastodon myself. I am using these settings in production elsewhere though, and they work quite well. Alternately, if people don't want to trust the OpenSSL definitions, please consider taking a look at https://wiki.mozilla.org/Security/Server_Side_TLS and implementing the recommendations from there.
* Also avoid SHA1
As requested during review. :)
* Fix a typo in the ssl_ciphers line
I wrote !SHA1, should have written just !SHA. Very sorry about the noise.
* Avoid hard-coding ciphers into configuration
This change allows OpenSSL to choose the most appropriate available cipher(s) from the HIGH cipher suite. This is sufficient to get an A on the SSLLabs.com tests suite. If MEDIUM is allowed as well, the grade drops to a B which is still more than adequate for most deployments.
This type of configuration would prevent problems such as the current inability of Tusky on Android 7 devices to connect to some Mastodon instances.
The main benefit though, is this delegates the decisions about which ciphers are "good" and which ciphers are "bad" to the experts; the distribution security teams and the OpenSSL developers. If a weakness is found in a particular cipher it will get moved from HIGH to one of the lower classes (or removed entirely) and this will get deployed just like any other security update. Similarly, if new stronger ciphers are standardized (such as Curve 25519) - these will immediately become available without needing to change the configuration.
Hope this helps!
Note: I have not been able to test this change with Mastodon myself. I am using these settings in production elsewhere though, and they work quite well. Alternately, if people don't want to trust the OpenSSL definitions, please consider taking a look at https://wiki.mozilla.org/Security/Server_Side_TLS and implementing the recommendations from there.
* Also avoid SHA1
As requested during review. :)
To further increase security add a strong Diffie-Hellman group, which is standard practice when setting up ssl certs. Anyone who can setup letsencrypt can also setup a DH group.
* Add cost estimate column
To give interested admin an idea of what expected costs might be.
* Add estimate for mastodon.technology
based on blog post
* Fix missing header dashes
* Add docker guide from main repo readme
* Add maintenance tasks doc to running section
* Clean up markdown in prod guide
* Move guidance to use tagged releases to docs
* Move local domain and host config to docs repo
* Title of page
* Update Production-guide.md
Alda Marteau-Hardi