diff --git a/content/pl/administration/installation.md b/content/pl/administration/installation.md index a53269ed..fb8dd2d2 100644 --- a/content/pl/administration/installation.md +++ b/content/pl/administration/installation.md @@ -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: diff --git a/content/pl/administration/migrating.md b/content/pl/administration/migrating.md new file mode 100644 index 00000000..e9928bf8 --- /dev/null +++ b/content/pl/administration/migrating.md @@ -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. diff --git a/content/pl/administration/troubleshooting.md b/content/pl/administration/troubleshooting.md new file mode 100644 index 00000000..fd312114 --- /dev/null +++ b/content/pl/administration/troubleshooting.md @@ -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. \ No newline at end of file diff --git a/content/pl/usage/decentralization.md b/content/pl/usage/decentralization.md index b527c7a0..7d450259 100644 --- a/content/pl/usage/decentralization.md +++ b/content/pl/usage/decentralization.md @@ -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