Commit 2efc21ca authored by Marcin Mikołajczak's avatar Marcin Mikołajczak

start Polish translation work

Signed-off-by: 's avatarMarcin Mikołajczak <>
parent 44281208
......@@ -13,6 +13,10 @@ enableGitInfo = true
contentDir = "content/en"
languageName = "English"
weight = 1
contentDir = "content/pl"
languageName = "Polski"
weight = 1
title: Dokumentacja Mastodona
Witaj w dokumentacji Mastodona!
<div style="margin-bottom: 26px">
{{< youtube "IPSbNdBmWKE" >}}
**Wybierz swoją drogę:**
- [Dowiedz się jak korzystać z Mastodona]({{< relref "usage/" >}})
- [Dowiedz się jak zainstalować Mastodona]({{< relref "administration/" >}})
- [Dowiedz się jak napisać aplikację dla Mastodona]({{< relref "api/" >}})
title: Configuration
description: Overview of Mastodon's configuration options
parent: administration
weight: 2
Mastodon uses environment variables as its configuration.
For convenience, it can read them from a flat file called `.env.production` in the Mastodon directory, but they can always be overridden by a specific process. For example, systemd service files can read environment variables from an `EnvironmentFile` or from inline definitions with `Environment`, so you can have different configuration parameters for specific services. They can also be specified when calling Mastodon from the command line.
## Basic
### Federation
### Secrets
### Deployment
- `PORT`
- `BIND`
### Scaling options
## Database connections
### PostgreSQL
### Redis
### ElasticSearch
### StatsD
## Limits
## E-mail
## File storage
### Local file storage
### Amazon S3 and compatible
### Swift
## External authentication
### LDAP
### PAM
### CAS
### SAML
## Hidden services
- `http_proxy`
## Other
title: Installation
description: How to install Mastodon on an Ubuntu 18.04 server
parent: administration
weight: 1
<img src="/setup.png" alt="" style="margin: 0; box-shadow: none">
## Basic server setup (optional)
If you are setting up a fresh machine, it is recommended that you secure it first. Assuming that you are running **Ubuntu 18.04**:
### Do not allow password-based SSH login (keys only)
First make sure you are actually logging in to the server using keys and not via a password, otherwise this will lock you out. Many hosting providers support uploading a public key and automatically set up key-based root login on new machines for you.
Edit `/etc/ssh/sshd_config` and find `PasswordAuthentication`. Make sure it's uncommented and set to `no`. If you made any changes, restart sshd:
systemctl restart ssh
### Update system packages
apt update && apt upgrade -y
### Install fail2ban so it blocks repeated login attempts
apt install fail2ban
Edit `/etc/fail2ban/jail.local` and put this inside:
destemail =
sendername = Fail2Ban
enabled = true
port = 22
enabled = true
port = 22
Finally restart fail2ban:
systemctl restart fail2ban
### Install a firewall and only whitelist SSH, HTTP and HTTPS ports
First, install iptables-persistent. During installation it will ask you if you want to keep current rules--decline.
apt install -y iptables-persistent
Edit `/etc/iptables/rules.v4` and put this inside:
# Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d -j REJECT
# Accept all established inbound connections
# Allow all outbound traffic - you can modify this to only allow certain traffic
# Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT
# Allow SSH connections
# The -dport number should be the same port number you set in sshd_config
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
# Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
# Reject all other inbound - default deny unless explicitly allowed policy
With iptables-persistent, that configuration will be loaded at boot time. But since we are not rebooting right now, we need to load it manually for the first time:
iptables-restore < /etc/iptables/rules.v4
## Pre-requisites
- A machine running **Ubuntu 18.04** that you have root access to
- A **domain name** (or a subdomain) for the Mastodon server, e.g. ``
- An e-mail delivery service or other **SMTP server**
You will be running the commands as root. If you aren't already root, switch to root:
sudo -i
### System repositories
Make sure curl is installed first:
apt install -y curl
#### Node.js
curl -sL | bash -
#### Yarn
curl -sS | apt-key add -
echo "deb stable main" | tee /etc/apt/sources.list.d/yarn.list
### System packages
apt update
apt install -y \
imagemagick ffmpeg libpq-dev libxml2-dev libxslt1-dev file git-core \
g++ libprotobuf-dev protobuf-compiler pkg-config nodejs gcc autoconf \
bison build-essential libssl-dev libyaml-dev libreadline6-dev \
zlib1g-dev libncurses5-dev libffi-dev libgdbm5 libgdbm-dev \
nginx redis-server redis-tools postgresql postgresql-contrib \
certbot yarn libidn11-dev libicu-dev libjemalloc-dev
### Installing Ruby
We will be using rbenv to manage Ruby versions, because it's easier to get the right versions and to update once a newer release comes out. rbenv must be installed for a single Linux user, therefore, first we must create the user Mastodon will be running as:
adduser --disabled-login mastodon
We can then switch to the user:
su - mastodon
And proceed to install rbenv and rbenv-build:
git clone ~/.rbenv
cd ~/.rbenv && src/configure && make -C src
echo 'export PATH="$HOME/.rbenv/bin:$PATH"' >> ~/.bashrc
echo 'eval "$(rbenv init -)"' >> ~/.bashrc
exec bash
git clone ~/.rbenv/plugins/ruby-build
Once this is done, we can install the correct Ruby version:
RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install 2.5.1
rbenv global 2.5.1
We'll also need to install bundler:
gem install bundler --no-ri --no-rdoc
Return to the root user:
## Setup
### Setting up PostgreSQL
#### Performance configuration (optional)
For optimal performance, you may use [pgTune]( to generate an appropriate configuration and edit values in `/etc/postgresql/9.6/main/postgresql.conf` before restarting PostgreSQL with `systemctl restart postgresql`
#### Creating a user
You will need to create a PostgreSQL user that Mastodon could use. It is easiest to go with "ident" authentication in a simple setup, i.e. the PostgreSQL user does not have a separate password and can be used by the Linux user with the same username.
Open the prompt:
sudo -u postgres psql
In the prompt, execute:
### Setting up Mastodon
It is time to download the Mastodon code. Switch to the mastodon user:
su - mastodon
#### Checking out the code
Use git to download the latest stable release of Mastodon:
git clone live && cd live
git checkout $(git tag -l | grep -v 'rc[0-9]*$' | sort -V | tail -n 1)
#### Installing the last dependencies
Now to install Ruby and JavaScript dependencies:
bundle install \
-j$(getconf _NPROCESSORS_ONLN) \
--deployment --without development test
yarn install --pure-lockfile
#### Generating a configuration
Run the interactive setup wizard:
RAILS_ENV=production bundle exec rake mastodon:setup
This will:
- Create a configuration file
- Run asset precompilation
- Create the database schema
The configuration file is saved as `.env.production`. You can review and edit it to your liking. Refer to the [documentation on configuration]({{< relref "" >}}).
You're done with the mastodon user for now, so switch back to root:
### Setting up nginx
Copy the configuration template for nginx from the Mastodon directory:
cp /home/mastodon/live/dist/nginx.conf /etc/nginx/sites-available/mastodon
ln -s /etc/nginx/sites-available/mastodon /etc/nginx/sites-enabled/mastodon
Then edit `/etc/nginx/sites-available/mastodon` to replace `` with your own domain name, and make any other adjustments you might need.
Reload nginx for the changes to take effect:
systemctl reload nginx
### Acquiring a SSL certificate
We'll use Let's Encrypt to get a free SSL certificate:
certbot certonly --webroot -d -w /home/mastodon/live/public/
You can now edit `/etc/nginx/sites-available/mastodon` to uncomment and adjust the `ssl_certificate` and `ssl_certificate_key` lines.
Then, reload nginx for the changes to take effect:
systemctl reload nginx
At this point you should be able to visit your domain in the browser and see the elephant hitting the computer screen error page. This is because we haven't started the Mastodon process yet.
### Setting up systemd services
Copy the systemd service templates from the Mastodon directory:
cp /home/mastodon/live/dist/mastodon-*.service /etc/systemd/system/
Then edit the files to make sure the username and paths are correct:
- `/etc/systemd/system/mastodon-web.service`
- `/etc/systemd/system/mastodon-sidekiq.service`
- `/etc/systemd/system/mastodon-streaming.service`
Finally, start and enable the new systemd services:
systemctl start mastodon-web mastodon-sidekiq mastodon-streaming
systemctl enable mastodon-*
They will now automatically start at boot time.
**Hurray! This is it. You can visit your domain in the browser now!**
title: Optional features
description: How to enable Mastodon's optional features
parent: administration
weight: 5
## Full-text search
## Hidden services
## Login via LDAP/PAM/CAS/SAML
title: Post-installation steps
description: What to do after the installation of Mastodon is complete
parent: administration
weight: 3
## Using the command-line interface
The command-line interface of Mastodon is an executable file called `tootctl` residing in the `bin` directory within the Mastodon root directory. You must specify which environment you intend to use whenever you execute it by specifying the `RAILS_ENV` environment variable. Unless you are a developer working on a local machine, you need to use `RAILS_ENV=production`. If you are sure that you will never need another environment (for development, testing, or staging), you can add it to your `.bashrc` file for convenience, e.g.:
echo "export RAILS_ENV=production" >> ~/.bashrc
If so, you won't need to specify it each time inline. Otherwise, calls to `tootctl` will usually go like this, assuming that the Mastodon code is checked out in `/home/mastodon/live`:
cd /home/mastodon/live
RAILS_ENV=production bin/tootctl help
## Creating an admin account
### In the browser
After signing up in the browser, you will need to use the command line to give your newly created account admin privileges. Assuming your username is `alice`:
RAILS_ENV=production bin/tootctl accounts update alice --role admin
### From the command line
You can create a new account using the command-line interface.
RAILS_ENV=production bin/tootctl accounts create \
alice \
--email \
--confirmed \
--role admin
A randomly generated password will be shown in the terminal.
## Filling in server information
After logging in, navigate to the **Site settings** page. While there are no technical requirements for filling in this information, it is considered crucial for operating a server for humans.
|Contact username|Your username so people know who owns the server|
|Business e-mail|An e-mail address so people locked out of their accounts, or people without accounts, can contact you|
|Instance description|Why did you start this server? Who is it for? What makes it different?|
|Custom extended information|You can put all sorts of information in here but a **code of conduct** is recommended|
After you fill these in, simply hit "Save changes".
## Setting up regular backups (optional, but not really)
For any real-world use, you should make sure to regularly backup your Mastodon server.
### Overview
Things that need to be backed up in order of importance:
1. PostgreSQL database
2. Application secrets from the `.env.production` file or equivalent
3. User-uploaded files
4. Redis database
### Failure modes
There are two failure types that people in general may guard for: The failure of the hardware, such as data corruption on the disk; and human and software error, such as wrongful deletion of particular piece of data. In this documentation, only the former type is considered.
A lost PostgreSQL database is complete game over. Mastodon stores all the most important data in the PostgreSQL database. If the database disappears, all the accounts, posts and followers on your server will disappear with it.
If you lose application secrets, some functions of Mastodon will stop working for your users, they will be logged out, two-factor authentication will become unavailable, Web Push API subscriptions will stop working.
If you lose user-uploaded files, you will lose avatars, headers, and media attachments, but Mastodon *will* work moving forward.
Losing the Redis database is almost harmless: The only irrecoverable data will be the contents of the Sidekiq queues and scheduled retries of previously failed jobs. The home and list feeds are stored in Redis, but can be regenerated with tootctl.
The best backups are so-called off-site backups, i.e. ones that are not stored on the same machine as Mastodon itself. If the server you are hosted on goes on fire and the hard disk drive explodes, backups stored on that same hard drive won't be of much use.
### Backing up application secrets
Application secrets are the easiest to backup, since they never change. You only need to store `.env.production` somewhere safe.
### Backing up PostgreSQL
PostgreSQL is at risk of data corruption from power cuts, hard disk drive failure, and botched schema migrations. For that reason, occassionally making a backup with `pg_dump` or `pg_dumpall` is recommended.
For high-availability setups, it is possible to use hot streaming replication to have a second PostgreSQL server with always up-to-date data, ready to be switched over to if the other server goes down.
### Backing up user-uploaded files
If you are using an external object storage provider such as Amazon S3, Google Cloud or Wasabi, then you don't need to worry about backing those up. The respective companies are responsible for handling hardware failures.
If you are using local file storage, then it's up to you to make copies of the sizeable `public/system` directory, where uploaded files are stored by default.
### Backing up Redis
Backing up Redis is easy. Redis regularly writes to `/var/lib/redis/dump.rdb` which is the only file you need to make a copy of.
This diff is collapsed.
title: Upgrading to a new release
description: How to upgrade Mastodon to a newer version
parent: administration
weight: 5
When a new version of Mastodon comes out, it appears on the [GitHub releases page]( Please mind that running unreleased code from the `master` branch, while possible, is not recommended.
Mastodon releases correspond to git tags. First, switch to the `mastodon` user:
su - mastodon
And navigate to the Mastodon root directory:
cd /home/mastodon/live