YunoHost – self-hosting w przyjaznej formie

W poprzednim wpisie opisałem jak uzyskać darmowy dostęp do całkiem niezłego VPSa – Oracle Cloud Free Tier. Dzisiaj przedstawię jedną z moich propozycji co można z nim dalej zrobić, a konkretnie pokażę jak, w prosty sposób, zmienić taki serwer w centrum do uruchamiania rozwiązań self-hosted. Zainstalujemy na nim narzędzie, czy może raczej system, YunoHost, które służy do uruchamiania usług, a wyróżnia się tym, iż posiada bardzo przyjazny interfejs graficzny, który pozwala na zanurkowanie w świecie self-hosting’u choćby osobom niezbyt technicznym. YunoHost jest oprogramowaniem open-source, które pod przejrzystą oprawą wizualną posiada bardzo dobrze napisany kod, który sam zadba o prawidłowe skonfigurowanie od strony technicznej i bezpieczeństwo usług, które będą na nim uruchomione.

Przygotowanie

Tak jak wspomniałem we wstępie, w dalszej części tego wpisu będziemy potrzebować serwera w Oracle Cloud, o który pisałem we wpisie Darmowy VPS z 4 OCPU, 24GB RAMu i dyskiem 200GB. Pisząc ten poradnik zakładam, iż masz już, drogi Czytelniku, założone konto na Oracle Cloud, uruchomiłeś na nim instancję tak jak to opisałem, otworzyłeś jej porty 80 i 443, włączyłeś obsługę IPv6 oraz umiesz się połączyć poprzez SSH. Jak zawsze polecam do tego celu skorzystać z wygodnego i darmowego (w zakresie tego co jest nam potrzebne) narzędzia Termius.

Spełniając powyższe warunki możemy przystąpić do działania!

Instalacja Debiana na instancji Oracle

Jeżeli stworzona przez Ciebie instancja jest w 100% tak jak to opisałem to znaczy, iż masz na niej zainstalowany system Ubuntu. YunoHost działa jedynie na Debian’ie, którego nie ma na liście dostępnych systemów od Oracle. Nie jest to wielki problem, a jedynie dodatkowy krok do wykonania, w którym przekonwertujemy nasze Ubuntu właśnie w Debian’a. Wykorzystamy do tego gotowy skrypt dostępny na GitHub pod tym linkiem.

Połączmy się z naszym VPS poprzez SSH. Następnie pobierzmy w/w skrypt:

curl -fLO https://raw.githubusercontent.com/bohanyang/debi/master/debi.sh

Nadajmy mu uprawnienia do uruchamiania się:

chmod a+rx debi.sh

Teraz musimy wykonać istotny krok, który jest niezbędny do prawidłowego wykonania późniejszych działań. Chodzi o udostępnienie swojego publicznego klucza SSH, którego używamy do logowania na tym serwerze, a który będzie mógł być pobrany i wykorzystany przez instalator. Chodzi o to, iż musimy dostarczyć instalatorowi klucz, który wrzucony zostanie na nowo zainstalowany system Debian. Bez tego po zakończeniu instalacji i konwersji Ubuntu w Debiana utracilibyśmy dostęp do naszego serwera! Jest wiele sposobów aby to zrobić, ja jednak przedstawi taki, do którego będziemy potrzebowali jedynie konta na GitHub.

Instrukcja jak dodać na GitHub publiczny klucz SSH do swojego serwera:

• Jeżeli jeszcze nie masz konta na GitHub to należy je założyć.
• Następnie po zalogowaniu klikamy na nasz awatar w prawym górnym rogu i z rozwiniętej listy wybieramy Settings.
• Po lewej w sekcji Access wybieramy SSH and GPG keys po czym po prawej stronie znajdujemy zielony przycisk New SSH key i naciskamy go.
• W oknie, które wyskoczy w polu Title wpisujemy dowolną nazwę jaką ten klucz będzie się identyfikował, jako Key type zostawiamy Authentication Key, a w pole tekstowe Key wpisujemy nasz publiczny klucz SSH.
• Ważne: Upewnij się, iż wrzucasz swój publiczny, a NIE prywatny, klucz! Klucz publiczny może być jawny i udostępniony dla wszystkich w Internecie i nie jest to żadne zagrożenie bezpieczeństwa dla Twojego serwera. Natomiast klucza prywatnego należy strzec jak oka w głowie i nie udostępniać go nigdzie, gdyż to właśnie on jest niezbędny do uzyskania dostępu do Twojego serwera.
• Potwierdzamy zielonym przyciskiem Add SSH key.

Dla pewności przedstawiam poniżej wygląd przykładowego klucza publicznego:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAAAgQCvYkO7T45XKg95Jhj69xvzO+E74hdzO+KTeNLOsA2RwzAEeKkZCLGT1l3tWNZ57BuK0Umt5qbHOye/gTOAsY+kekIsyN27bzTlKx4O7GfmYIYNsByX0nj76JBCfcxazUwLCxIu6TC8Q+/1KGpwqfBV8rwLD0MEbFVm5ruSaEFDWw== blogtomaszdunia

Tak udostępniony klucz SSH będzie dostępny pod adresem:

https://github.com/<Twój_login_na_GitHub>.keys

Teraz gdy już udostępniliśmy nasz publiczny klucz SSH możemy kontynuować instalację Debian’a na naszym serwerze. Uruchamiamy skrypt:

sudo ./debi.sh --version 11 --authorized-keys-url https://github.com/<Twój_login_na_GitHub>.keys

Zwróć uwagę, iż musisz zmodyfikować treść tego polecenia zmieniając frazę <Twój_login_na_GitHub> na odpowiednią wartość odpowiadającą nazwie Twojego konta na GitHub.

Wszystko gotowe możemy rozpocząć instalację, a realizuje się to poprzez ponowne uruchomienie maszyny poleceniem:

sudo shutdown -r now

Zostaniemy oczywiście rozłączeni z serwerem. Proces może potrwać choćby kilka minut, więc zachowaj spokój, o ile nie od razu będzie można się do niego podłączyć. W międzyczasie będziemy musieli także zmienić jeszcze dane do logowania przez SSH, gdyż teraz będziemy logowali się do zupełnie innego systemu. Zmianie ulegnie nazwa użytkownika, na którego będziemy się logować. Stary użytkownik nazywał się ubuntu, a nowy to debian.

PS: o ile czujesz wewnętrzną potrzebę to po zakończeniu instalacji możesz już usunąć swój publiczny klucz SSH z GitHuba.

Instalacja YunoHost

Gdy konfiguracja Debian’a zostanie już zakończona to będziemy mogli połączyć się z serwerem. Od tego momentu instrukcja jest uniwersalna dla dowolnego urządzenia z zainstalowanym Debian’em. W pierwszej kolejności oczywiście aktualizacja systemu i jego pakietów:

sudo apt update sudo apt upgrade -y

Następnie instalujemy niezbędne składniki:

sudo apt install htop curl unzip tmux -y

Dalej skorzystamy z narzędzia tmux (Terminal Multiplexer), które w uproszczeniu pozwala na tworzenie i zarządzanie wieloma wirtualnymi terminalami. Uruchamiamy sesję tmux:

tmux new -s yuno

Przechodzimy na konto root:

sudo -i

Pobieramy skrypt instalacyjny YunoHost i rozpoczynamy instalację:

curl https://install.yunohost.org | bash

Proces instalacji jest banalny i praktycznie nic nie trzeba robić w jego trakcie, więc nie będę opisywał go szczegółowo. Po zakończeniu otrzymamy informację, iż dalsza konfiguracja będzie przebiegała już z poziomu przeglądarki po wejściu na adres:

https://<ip_serwera>/

Tak też robimy, czyli otwieramy przeglądarkę, wpisujemy stosowny adres i potwierdzamy. Naszym oczom powinno pojawić się ostrzeżenie o tym, iż połączenie może nie być bezpieczne. Jest to nam dobrze znane zachowanie przeglądarki, które podyktowane jest tym, iż nie mamy zainstalowanego certyfikatu SSL dla tej domeny. Na tym etapie nie jest to istotne. Przeklikujemy się przez to ostrzeżenie szukając przycisku Akceptuję ryzyko i mimo to chcę kontynuować lub coś w tym stylu, dokładna treść zależy od tego jakiej przeglądarki używasz.

Naszym oczom ukaże się ekran powitalny YunoHost, który gratuluje nam pomyślnej instalacji i zachęca do dalszej konfiguracji. Naciskamy zatem przycisk Rozpocznij [1]. W ustawieniach domeny głównej definiujemy pod jakim adresem dostępny będzie ten panel administracyjny (oraz panel użytkownika), czyli ustawiamy alias, który sprawi, iż nie będziemy musieli używać adresu IP serwera jako odnośnika do naszego YunoHost. Opcje są dwie: można podpiąć tutaj swoją domenę (lub subdomenę) zewnętrzną lub skorzystać z subdomen udostępnionych przez YunoHost. Mogą się one kończyć na:

• nohost.me
• noho.st
• ynh.fr

Żeby zbytnio nie komplikować sprawy skorzystamy właśnie z tego drugiego rozwiązania, a więc wybieramy opcję Nie posiadam domeny… [2], w pole tekstowe Nazwa domeny [3] wpisujemy wybrany przez nas ciąg znaków i potwierdzamy przyciskiem Dalej [4]. Na następnej stronie tworzymy konto administratora. Wypełniamy pola: nazwa użytkownika [5], Imię i nazwisko [6] i dwa razy podajemy hasło [7]. Zatwierdzamy przyciskiem Dalej [8]. Chyba nie muszę tutaj nikogo pouczać, iż hasło powinno być odpowiednio mocne, bo jest ono jedynym zabezpieczeniem naszego panelu administracyjnego przed nieuprawnionym dostępem, a cała ta infrastruktura jest dostępna w otwartym Internecie. Na koniec zostaniemy jeszcze poproszeni o finalne potwierdzenie przyciskiem OK [9]. Po tym wszystkim pozostaje nam już tylko czekać na zakończenie procesu, po czym zostaniemy przeniesieni do głównego panelu sterowania.

Istotne jest to, iż od dzisiaj do serwera należy łączyć się wykorzystując poświadczenia podane podczas tworzenia konta administratora. A więc nie logujemy się na użytkownika debian tylko nowoutworzonego i wykorzystujemy nowe hasło, a nie klucz SSH. Po pierwszym logowaniu dobrze jest z powrotem wrócić do logowania się przy użyciu kluczy SSH. Jak to zrobić opisałem tutaj. Istotne jest też, aby wyłączenie możliwości uwierzytelnienia hasłem wykonać z poziomu interfejsu webowego YunoHost poprzez wejście w (Główny panel sterowania) -> Narzędzia -> Ustawienia YunoHost -> sekcja SSH -> Password authentication -> zmienić na Nie, a nie poprzez edycję pliku sshd_config tak jak to opisałem w tym wpisie. Oczywiście obie formy zadziałają tak samo, z tym iż edytując plik z poziomu terminala sprawimy, iż YunoHost będzie nam później zgłaszał jako błąd, iż wykrył jego modyfikację, co może powodować konflikt w konfiguracji.

Podstawowa konfiguracja – przygotowanie do pracy

Po wejściu do głównego panelu sterowania YunoHost polecam w pierwszej kolejności wejść do Aktualizacja systemu. System zostanie od razu przeskanowany w poszukiwaniu pakietów, które można zaktualizować. Po zakończeniu skanowania potwierdzamy na dole zielonym przyciskiem Aktualizuj wszystkie pakiety. Po uruchomieniu pierwszych usług to właśnie z poziomu tego menu będzie można je również zaktualizować. Po zobaczeniu dwóch komunikatów – Wszystkie pakiety systemowe są aktualne! i Wszystkie programy są aktualne! – wracamy do panelu głównego.

Następnie miejsce, w które powinniśmy zajrzeć to Diagnostyka. Jest to sprytne narzędzie YunoHost, którego zadaniem jest przeskanowanie naszej konfiguracji i sprawdzenie czy wszystko jest ustawione prawidłowo. Po zakończeniu skanowania zobaczymy cztery rodzaje markerów:

• niebieskie – informacyjne, przedstawiające pewne istotne informacje, ale nie wymagające działania,
• zielone – potwierdzające, iż dany parametr jest ustawiony prawidłowo,
• żółte – wskazujące, iż coś nie jest ustawione prawidłowo, ale nie jest to kluczowa funkcja,
• czerwone – krytyczne, które określają, iż coś istotnego jest ustawione nieprawidłowo i tym samym coś przez to może działać nieprawidłowo.

Rozsądnym będzie zająć się w pierwszej kolejności problemami zaznaczonymi na czerwono. W moim przypadku narzędzie diagnostyczne zgłosiło problem z tym, iż prawidłowo otwarte mam porty 22, 80 i 443, jednak do poprawnego działania potrzebne pozostało otwarcie postów 25, 587, 993, 5222 i 5269. Pozostałe czerwone markery widniały w sekcji Email, ale nie będziemy się nimi teraz przejmować, bo są one spowodowane tym, iż port 25 jest na ten moment zamknięty.

Wskazano nam palcem, które porty należy otworzyć, więc zróbmy to. To jak to zrobić w Oracle Cloud opisałem dość szczegółowo tutaj (na przykładzie portów 80 i 443). Jedyna różnica jest taka, iż zmiany musimy wprowadzić jedynie od strony interfejsu Oracle (dodać odpowiednie Ingress Rules), bo od strony serwera wszystko załatwi za nas YunoHost. Pamiętaj, aby otworzyć również porty w zakresie adresacji IPv6. Po wprowadzeniu zmian zapuszczamy proces diagnostyki jeszcze raz.

W moim przypadku zostały jeszcze dwa czerwone markery związane z obsługą poczty. Oba wskazują na problem z wysyłaniem, bo pomimo otwarcia port 25 wydaje się zamknięty, a także jest problem z reverse DNS. Jest to prawdopodobnie spowodowane tym, iż część dostawców usług chmurowych blokuje możliwość wysyłania poczty z oferowanych przez siebie serwerów i wygląda na to, iż Oracle należy do tego grona. Da się to obejść poprzez skorzystanie z odpowiedniego przekaźnika (po ang. relay), ale nie będziemy dzisiaj się tym zajmować.

Skoro największe problemy mamy w miarę ogarnięte to zejdźmy poziom niżej i zwróćmy uwagę na żółte markery. W moim przypadku pierwszym problemem zgłaszanym na żółto był temat dopuszczenia repozytoriów backports (z ang. wsteczne porty) w menedżerze pakietów. Repozytoria backports to specjalne repozytoria, które zawierają nowsze wersje oprogramowania, które zostały pierwotnie opracowane dla nowszych wersji dystrybucji Linux’a. Są używane, aby zapewnić użytkownikom starszych wersji dystrybucji Linux’a dostęp do nowszego systemu bez konieczności aktualizacji całego systemu operacyjnego do nowszej wersji. Zainstalowanie systemu z repozytorium backports może prowadzić do niestabilności lub konfliktów, dlatego YunoHost podpowiada nam, aby ich nie stosować, a my posłuchamy tej rady i wyłączymy je z listy menedżera pakietów.

W pierwszej kolejności ustalmy, o które repozytoria chodzi:

sudo grep -nr backport /etc/apt/sources.list*

Ja w odpowiedzi na to polecenie otrzymałem następujący wynik:

/etc/apt/sources.list:10:# see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports /etc/apt/sources.list:14:# bullseye-backports, previously on backports.debian.org /etc/apt/sources.list:15:deb http://deb.debian.org/debian bullseye-backports main /etc/apt/sources.list:16:deb-src http://deb.debian.org/debian bullseye-backports main

Jak widać słowo najważniejsze backport, którego szukamy występuje czterokrotnie w pliku /etc/apt/sources.list w liniach 10, 14, 15 i 16, z czego pierwsze dwie są liniami zakomentowanymi, czyli niejako wyłączonymi, ale bez usuwania ich z listy. Pozostaje nam zrobić to samo z liniami 15 i 16 tego pliku. Wejdźmy zatem do pliku z listą repozytoriów menedżera pakietów i dodajmy znak # gdzie trzeba:

sudo nano /etc/apt/sources.list

Plik zapisujemy i wychodzimy z niego.

Dla pewności przeskanujmy system jeszcze raz przy użyciu narzędzia do diagnostyki. W moim przypadku wygląda na to, iż nie znaleziono więcej problemów, więc system wydaje się gotowy do dalszych działań.

Bazowa kopia zapasowa

Podstawowa konfiguracja zakończona. Na tym etapie dobrą praktyką będzie zrobienie sobie kopii zapasowej czystego systemu, którą w razie czego będzie można w łatwy sposób przywrócić. Ja zawsze robię taką kopię plus poza cyklicznymi backup’ami wykonuję jeszcze dodatkowe kopie przed uruchomieniem każdej nowej usługi (aplikacji).

Kopie zapasowe wykonuje się w (Główny panel sterowania) -> Kopia -> Lokalne archiwa (local) -> zielony przycisk po prawej +Nowa kopia. Tak utworzoną kopię można pobrać z poziomu graficznego interfejsu webowego lub z poziomu terminala np. poprzez jakąś automatyzację. Kopie znajdują się na serwerze pod ścieżką – /home/yunohost.backup/archives/<data_wykonania_kopii>.tar.

Co dalej?

O tym co dalej można zrobić korzystając z YunoHost opowiem przy innej okazji. Celem tego wpisu było jedynie pokazanie jak zainstalować YunoHost i jest to, wydaje mi się, dobra baza do kolejnych wpisów, w których już bardziej szczegółowo opiszę jak uruchamiać różne usługi na tak skonfigurowanym środowisku. Katalog aplikacji (usług) jakie można uruchomić przy użyciu YunoHost jest dostępny tutaj i trzeba przyznać, iż jest obszerny. Z ciekawszych pozycji wskazałbym:

• code-server – edytor kodu Virtual Studio Code w wersji self-hosted,
• Discourse – forum dyskusyjne,
• Domoticz – system do smarthome,
• FreshRSS – agregator RSS,
• Gitea – zarządzanie kodem źródłowym,
• Grafana – narzędzie analityczne,
• Home Assistant – system do smarthome,
• n8n – narzędzie do automatyzacji,
• Mastodon – sieć społecznościowa,
• Nextcloud – chmura na pliki,
• Nitter – alternatywny front-end dla Twittera,
• PeerTube – Youtube tylko self-hosted,
• phpMyAdmin – zarządzanie bazami MySQL,
• Pi-hole – serwer DNS,
• Pixelfed – Instagram tylko self-hosted,
• Roundcube – klient poczty e-mail,
• Transmission – klient torrent (P2P),
• Vaultwarden – menedżer haseł Bitwarden w wersji self-hosted,
• Wallabag – agregator trześci do przeczytanie później (po ang. read it later),
• WireGuard – serwer VPN,
• WordPress – platforma do blogowania,
• WriteFreely – platforma do blogowania jak WordPress ale w Fediverse.

I to są tylko wybrane wyrywkowo na szybko, bo jest tego dużo dużo więcej i pewnie pominąłem kilka naprawdę interesujących i/lub nieznanych mi usług. Jest też sporo ciekawych pozycji w waitlist’cie (z ang. liście oczekujących) do implementacji.