Merge branch 'master' into 'master'

update Polish translation

See merge request mastodon/docs!15
This commit is contained in:
Eugen Rochko 2019-01-22 01:27:27 +01:00
commit 9bec18acd8
4 changed files with 137 additions and 4 deletions

View File

@ -181,14 +181,20 @@ git clone https://github.com/rbenv/ruby-build.git ~/.rbenv/plugins/ruby-build
Po zakończeniu, możemy zainstalować prawidłową wersję Ruby:
```sh
RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install 2.5.1
rbenv global 2.5.1
RUBY_CONFIGURE_OPTS=--with-jemalloc rbenv install 2.5.3
rbenv global 2.5.3
```
Domyślna wersja gem dołączona do ruby_2.5.3 nie jest kompatybilna z najnowszym bundlerem, więc musimy zaktualizować gem:
```
gem update --system
```
Musimy też zainstalować bundler:
```sh
gem install bundler --no-ri --no-rdoc
gem install bundler --no-document
```
Wróćmy na konto root:

View File

@ -0,0 +1,98 @@
---
title: Migracja serwerów
description: Jak przenieść instancję Mastodona na inny serwer
menu:
docs:
parent: administration
weight: 6
---
Czasami, z różnych powodów, możesz potrzebować przenieść swoją instancję Mastodona z jednego serwera na drugi. Na szczęście, nie jest to trudny proces, choć może spowodować niedostępność serwera przez trochę czasu.
**Uwaga:** ten przewodnik został napisany z myślą o Ubuntu Server, proces ten może przebiegać inaczej na innych konfiguracjach.
Podstawowe kroki
----
1. Skonfiguruj nowy serwer Mastodona w oparciu o [przewodnika instalacji](/administration/installation/) (nie uruchamiaj jednak `mastodon:setup`).
2. Zatrzymaj Mastodona na starym serwerze (np. `systemctl stop 'mastodon-*.service'`).
3. Wykonaj zrzut bazy danych Postgres i załaduj ją korzystając z poniższych instrukcji.
4. Wykonaj kopię plików `system/` korzystając z poniższych instrukcji. (jeżeli korzystasz z S3, możesz pominąć ten krok.)
5. Skopiuj plik `.env.production`.
6. Uruchom `RAILS_ENV=production ./bin/tootctl feeds build`, aby wygenerować oś czasu dla każdego użytkownika.
7. Uruchom Mastodona na nowym serwerze.
8. Zaktualizuj ustawienia DNS, aby kierowały na nowy serwer.
9. Zaktualizuj lub przenieś kopię konfiguracji Nginx, uruchom ponownie LetsEncrypt jeżeli to potrzebne.
10. Ciesz się nowym serwerem!
Szczegółowe omówienie
----
### Jakie dane muszą zostać przeniesione
Przede wszystkim, musisz przenieść następujące:
- Katalog `~/live/public/system`, który zawiera zdjęcia i filmy wysłane przez użytkowników (jeżeli korzystasz z S3, nie potrzebujesz tego)
- Bazę danych Postgres (korzystając z [pg\_dump](https://www.postgresql.org/docs/9.1/static/backup-dump.html))
- Plik `~/live/.env.production`, zawierający ustawienia serwera i tajne kody
Oprócz tego, możesz też dla ułatwienia skopiować następujące:
Less crucially, you'll probably also want to copy the following for convenience:
- Konfiguracja nginx (`/etc/nginx/sites-available/default`)
- Pliki konfiguracji systemd (`/etc/systemd/system/mastodon-*.service`), mogące zawierać poprawki serwera
- Konfigurację pgbouncer w `/etc/pgbouncer` (jeżeli go używasz)
### Wykonaj i załaduj zrzut Postgres
Zamiast uruchamiania `mastodon:setup`, utworzymy pustą bazę danych Postgres korzystając z bazy danych `template0` (przydatne przy przywracaniu zrzutów Postgres
[jak to opisano w dokumentacji pg\_dump](https://www.postgresql.org/docs/9.1/static/backup-dump.html#BACKUP-DUMP-RESTORE)).
Uruchom następujące polecenie jako użytkownik `mastodon` na starym systemie:
```bash
pg_dump -Fc mastodon_production -f backup.dump
```
Przenieś plik `backup.dump` korzystając z `rsync` lub `scp`. Na nowym systemie utwórz nową bazę danych jako użytkownik `mastodon`:
```bash
createdb -T template0 mastodon_production
```
Później zaimportuj ją:
```bash
pg_restore -U mastodon -n public --no-owner --role=mastodon \
-d mastodon_production backup.dump
```
(jeżeli nazwą użytkownika na nowym serwerze nie jest `mastodon`, powinieneś(-naś) zmienić wartości `-U` i `--role` powyżej. Nazwa użytkownika może się różnić pomiędzy dwoma serwerami.)
(Note that if the username is not `mastodon` on the new server, you should change the
`-U` AND `--role` values above. It's okay if the username is different between the two servers.)
### Kopiowanie plików
Może to zająć trochę czasu, więc aby uniknąć niepotrzebnego kopiowania tego samego, zalecane jest użycie `rsync`.
Na poprzednim urządzeniu, jako użytkownik `mastodon`, wykonaj:
```bash
rsync -avz ~/live/public/system/ mastodon@example.com:~/live/public/system/
```
Musisz uruchomić to ponownie, jeżeli zmieni się jakiś z tych plików na poprzednim serwerze.
Powinieneś(-naś) też skopiować plik `.env.production` zawierający konfigurację i tajne kody.
Możesz skopiować pliki konfiguracyjne nginx, systemd i pgbouncer lub utworzyć je od nowa.
### Podczas migracji
Możesz zedytować stronę `~/live/public/500.html` na poprzednim serwerze, jeżeli chcesz wyświetlić informację powiadamiającą użytkowników o trwającej migracji.
Możesz też zmienić DNS TTL na małą wartość (30-60 minut) dzień wcześniej, aby serwery DNS szybko poznały nowy adres IP.
### Po migracji
Możesz użyć [whatsmydns.net](http://whatsmydns.net/), aby sprawdzić, jak przepiega proces propagacji DNS.
Aby przyspieszyć ten proces, możesz zedytować plik `/etc/hosts`, aby kierował na nowy serwer, dzięki czemu możesz zacząć korzystać z niego wcześniej.

View File

@ -0,0 +1,29 @@
---
title: Rozwiązywanie problemów
description: Jak określić, co złego stało się z instalacją Mastodona
menu:
docs:
parent: administration
weight: 99
---
**Widzę stronę informującą, że coś poszło nie tak. Jak mogę dowiedzieć się, co jest nie tak?**
Wszystkie informacje o błędach wraz ze „śladem stosu” zapisywane są w systemowym dzienniku. Jeżeli korzystasz z systemd, możesz uzyskać dziennik każdej usługi systemd używając `journalctl -u mastodon-web` (zamień na prawidłową nazwę usługi). Jeżeli korzystasz z Dockera, jest wygląda to podobnie: `docker logs mastodon_web_1` (zamień na prawidłową nazwę kontenera).
Szczegóły dotyczące błędów serwera *nigdy* nie są wyświetlane publicznie, ponieważ mogą one ujawnić jak wygląda konfiguracja od wewnątrz, mogące pomóc atakującym w dostaniu się do serwera lub bardziej skutecznym nadużywaniu systemu.
Każda odpowiedź z serwera Mastodona zawiera nagłówek z niepowtarzalnym identyfikatorem żądania, widocznym w logach. Sprawdzając nagłówek na stronie błędu, możesz łatwo odnaleźć odpowiedni ślad stosu w dzienniku.
**Po aktualizacji do nowej wersji, niektóre strony wyglądają dziwnie, jakby nie miały prawidłowego stylu. Dlaczego?**
Upewnij się, czy uruchomiłeś(-aś) `RAILS_ENV=production bin/rails assets:precompile` po aktualizacji i uruchomiłeś(-aś) ponownie proces sieciowy Mastodona, ponieważ prawdopodobnie serwer korzysta z nieaktualnych arkuszy stylów i skryptów. Możliwe też, że kompliacja nie powiodła się z powodu braku RAM-u, ponieważ webpack zużywa niestety ogromną ilość pamięci. Jeżeli jest to powodem, upewnij się, że serwer ma przydzielone trochę pamięci swap.
Możesz też skompilować te zasoby na innym urządzeniu i przenieść katalog `public/packs`.
**Po aktualizacji do nowej wersji, niektóre żądania kończą się niepowodzeniem lub zwracają informacje o brakujących kolumnach lub tablicach. Dlaczego?**
Upewnij się, że uruchomiłeś(-aś) `RAILS_ENV=production bin/rails db:migrate` po aktualizacji, ponieważ wygląda na to że kod Mastodona próbuje uzyskać dostęp do nowszego lub starszego schematu bazy danych. Jeżeli korzystasz z PgBouncera, upewnij się że to polecenie łączy się on bezpośrednio z PostgreSQL, ponieważ PgBouncer nie obsługuje rodzaju blokad tabeli używanych w trakcie migracji.
**Próbuję wykonać polecenie `tootctl` lub `rake`/`rails`, ale otrzymuję jedynie błąd dotyczący niezainicjalizowanych stałych. Co jest nie tak?**
Upewnij się, że określiłeś(-aś) prawidłowe środowisko używając `RAILS_ENV=production` przed poleceniem. Zwykle, polecenia te zakładają, że są uruchamiane w środowisku nieprodukcyjnym, więc kod próbuje załadować gemy przeznaczone dla programistów. W śtodowiskach produkcyjnych, unika się instalacji tych gemów, dlatego pojawiają się te błędy.

View File

@ -40,7 +40,7 @@ Mastodon korzysta ze standaryzowanego, otwartego protokołu aby zaimplementować
- Plume
- i wiele więcej
Fediwesum nie jest marką, więc częściej usłyszysz „obserwuj mnie na Mastodonie”, niż „obserwuj mnie w Fediwersum”, choć to drugie jest bardziej poprawne technicznie..
Fediwesum nie jest marką, więc częściej usłyszysz „obserwuj mnie na Mastodonie”, niż „obserwuj mnie w Fediwersum”, choć to drugie jest bardziej poprawne technicznie.
## Co to w praktyce oznacza
### Wspominanie o innych