Stawiamy własny serwer

Kupujemy domenę

Skorzystałem z NameSilo bo chciałem dziwaczną domenę, a w dodatku jak najtaniej – być może tylko na potrzeby tego wpisu. Liczę się z tym, że zostanę przy niej przez kilka lat, stąd wybór po cenie odnowienia domeny, nie interesowały mnie domeny za 0 zł. W każdym razie domenę można kupi w dowolnym miejscu (w dowolnym sklepie z domenami rzecz jasna), ważne jest aby mieć dostęp do panelu konfiguracyjnego domeny, a ten w NameSilo umożliwia wiele chociaż jest mało intuicyjny. Na razie tylko kupujemy i niczego nie robimy. Mamy, cieszymy się.

Kupujemy VPSa

Tutaj sprawa jest już trudniejsza. Nie będę zbytnio zanudzał: trzeba znaleźć serwer odpowiedni do swoich potrzeb. Najlepiej z możliwością łatwej rozbudowy. Może być 1 procesor (core), 1 GB RAMu i 10 GB dysku (mniej według mnie nie ma sensu – to co instalujemy w dzisiejszym odcinku zjada jakieś 8 GB dysku, a jest to gołe środowisko pracy), może być i takie f1.16xlarge z Amazona (64 core, 976 GB pamięci i 4x 940 dysku). Może być z Azure czy Google (takie na przykład 96 core, 624 GB pamięci, 8 GPU Tesla V100 i 3x 375 GB dysku) – bagatelka, jakieś 13.5 tys. dolarów miesięcznie w Google Cloud). Może być z OVH, wszystko jedno. Jedyne czego trzymamy się w tym wpisie to publiczne stałe IP, prawa roota i dostęp przez SSH.

Równie dobrze może to być goły Linux (tutaj: Ubuntu) zainstalowany na przykład na komputerze stojącym gdzieś w naszej piwnicy albo nawet jako maszyna wirtualna na laptopie (działająca wtedy, kiedy jest włączona. Rozwiązanie do nauki w sam raz, do pracy już raczej nie bardzo).

Ja skorzystałem z webh, czytając raczej dobre opinie w sieci i widząc atrakcyjną cenę. Jeśli się zdecydujesz na tego dostawcę skorzystaj proszę przy zakupie z podanego linku albo kodu promocyjnego PROMO25475.

Logowanie i SSH

W pierwszej kolejności potrzebujemy klienta SSH – dla Windows jest to na przykład PuTTy. Ściągamy, instalujemy, uruchamiamy, konfigurujemy połączenie do naszego serwera.

Update serwera

Warto na początek sprawdzić czy Ubuntu jest aktualne, a jeśli trzeba – niech się zaktualizuje:

W zależności od dostawcy VPSa może coś się zaktualizować, ale nie musi. W przypadku mojego dostawcy system był aktualny. Warto co jakiś (na przykład raz w miesiącu, można to wrzucić w crona) czas powtarzać powyższe komendy.

Ze względów bezpieczeństwa dobrze jest wyłączyć dostęp do serwera przez SSH dla użytkownika root. Logujemy się więc na nasz serwer (nowo utworzonym kontem) i przechodzimy do konfiguracji SSH:

Może okazać, się że nie mamy zainstalowanego nano (to edytor tekstu wygodny i dla laików prostszy w obsłudze niż na przykład vi) – wówczas go instalujemy:

Po ewentualnej instalacji możemy przejść do edycji. Aby zablokować dostęp dla roota po SSH odnajdujemy w pliku /etc/ssh/sshd_config linię

i zmieniamy na

Zapisujemy plik i restartujemy serwer SSH:

To wszystko. Jeśli zajdzie potrzeba zalogowania się na konto roota poprzez SSH zawsze możemy powtórzyć powyższe kroki i umożliwić logowanie (zmieniając PermitRootLogin na yes w pliku /etc/ssh/sshd_config i restartując SSH).

DNS

Konfiguracja DNS to nadanie naszemu serwerowi konkretnej nazwy (na razie mamy tylko IP) i umożliwienie dotarcia do serwera (w internecie) poprzez nazwę a nie numerek. W panelu domeny wskazujemy adres IP naszego serwera, a firma rejestrująca domeny zapewni nam, że ktoś wpisując nasza.domena na przykład w przeglądarce trafi na odpowiedni serwer. A co będzie pod tym numerkiem to już nasza sprawa. Ta cześć konfiguracji zależy od konkretnego dostawcy domeny. Robimy to dla każdej subdomeny, wszystkie kierujemy na jeden adres – rozdzieleniem ruchu zajmiemy się po swojej stronie. W dużym uproszczeniu:

• w rekord typu A wpisujemy nasz IP
• w rekordy typu CNAME wpisujemy z jednej strony subdomenę, a z drugiej – domenę (czyli np. rstudio i nasza.domena)
• w rekordy typy MX rzeczy związane z pocztą, ale można też (NameSilo to umożliwia) przekierować pocztę na poziomie DNSów, bez budowania serwera pocztowego

Wydelegowanie domeny na adres IP może trochę potrwać, więc nie przejmuj się jeśli kolejne kroki nie będą działać od razu. W NameSilo było to… kilkanaście minut (kiedyś to i dwa dni się czekało).

Możemy zmienić też nazwę hosta, czyli to pod jaką nazwą system widzi sam siebie. Wystarczy edycja pliku

Wpisana tam nazwa serwera nie powinna zawierać kropki – najlepiej niech będą to same literki i ewentualnie cyferki. Aby zmiany odniosły skutek resetujemy usługę hostname:

Serwer WWW – konfiguracja

Zaczynamy od zainstalowania serwera WWW – w tym przypadku będzie to Nginx.

Po chwili wpisanie w przeglądarce http://nasza.domena (o ile DNSy już kierują na nasz serwer – jeśli nie podaj numer IP) powinno wyświetlić coś na kształt:

Sam serwer jeszcze będziemy konfigurować, więc na razie przechodzimy dalej i instalujemy serwer MySQL, który będzie potrzebny na przykład WordPressowi. Sprawa znowu jest prosta:

To trochę większa rzecz, potrwa więc dłużej. Po drodze zostaniemy poproszeni na przykład o hasło roota dla bazy danych. Zapisz je sobie, bo zapomnisz i będzie problem. Ogólnie wszystkie hasła sobie zapisuj i niech każde będzie inne, mocno skomplikowane (z 15 znaków, duże i małe litery, cyfry i znaki specjalne).

Ostatni krok to PHP, w którym napisana jest duża cześć stron. Nginx nie posiada wewnętrznego procesora PHP trzeba więc zainstalować php-fpm. Przy okazji zainstalujemy dodatkowy pakiet dla PHP do komunikacji z MySQL oraz kilka innych przydatnych bibliotek.

Instalacja była prosta, z konfiguracją trochę więcej pracy. Przede wszystkim musimy skonfigurować PHP. W pliku /etc/php/7.0/fpm/php.ini potrzebujemy ustawić parametr cgi.fix_pathinfo na 0, co z poziomu konsoli robimy:

i znajdujemy odpowiednią linię w edytorze (będzie zakomentować średnikiem i z wartością ustawioną na 1), a później zapisujemy plik. Po poprawce resetujemy serwer PHP:

Teraz jeszcze musimy serwerowi WWW (nasz Nginx) powiedzieć co ma robić z plikami *.php. Najważniejsza cześć pliku /etc/nginx/sites-available/default (po usunięciu komentarzy) wygląda tak:

Na szczęście wszystko czego potrzebujemy jest wpisane w konfiguracji i wystarczy zdjąć komentarze. Docelowo interesujące nas fragmenty powinny wyglądać tak:

Restartujemy serwer Nginx (nie ostatni raz):

i PHP działa! Jak to sprawdzić? Stworzymy prosty plik info.php, który umieścimy w folderze serwera www, czyli /var/www/html (to wynika z konfiguracji wyżej)

Możemy wejść na http://nasza.domena/info.php i powinniśmy dostać informacje o PHP:

To co widać na stronie (wynik PHPowego phpinfo()) lepiej ukryć przed niepowołanymi osobami, zatem skasujmy ten plik:

Instalujemy R

Postępujemy zgodnie z instrukcją na CRANie:

• generujemy klucz szyfrujący

• dodajemy repozytorium dla apt-get

jeśli dostaniemy informację, że to polecenie nie jest znane trzeba doinstalować mały pakiecik:

i powtórzyć

A dalej już tylko pozostaje instalacja R – identyczna jak właściwie każdego programu na Ubuntu:

Teraz w konsoli możemy po prostu wpisać nasze ukochane R i…

Gotowe!

Instalujemy RStudio

RStudio nie znajdziemy w repozytoriach Ubuntu, musimy więc pobrać pakiet instalacyjny ze strony RStudio:

Po tych czterech linijkach możemy w przeglądarce wpisać http://nasza.domena:8787 i cieszyć się świeżym RStudio na własnym serwerze. Fragment rstudio-server-1.1.453-amd64.deb to odpowiednia wersja, która może się z czasem zmieniać – warto sprawdzi na stronie RStudio.com co tam jest aktualnie. To samo odnosi się do Shiny. Możemy również użyć wersji beta dziennych – linki znajdziecie na odpowiedniej stronie.

Instalujemy Shiny

W pierwszej kolejności musimy zainstalować pakiet shiny w R na prawach roota, zatem:

w drugiej kolejności – zainstalować sam serwer, znowu ściągając instalkę:

Po instalacji wchodzimy na http://nasza.domena:3838 i sprawdzamy czy wszystko działa. Jeśli nie działa – patrzymy w logi z folderu /var/log/shiny-server/ i zastanawiamy się co zrobić. Najczęściej przyczyną problemów są uprawnienia do folderów lub brak bibliotek. Serwer Shiny działa na użytkowniku shiny, ale możemy to zmienić w jego konfiguracji, w pliku /etc/shiny-server/shiny-server.conf

i zmieniamy

na naszego użytkownika:

gdzie lemur to nasz użytkownik. Ja używam sam swojego serwera, więc mogę sobie na to pozwolić. Ale jeśli mamy wielu użytkowników R, każdy z własnym kontem to musimy się na jakieś zdecydować. Albo zainstalować odpowiednie pakiety R-a dla użytkownika shiny. To jest niestety upierdliwe w systemach linuxowych.

Po zmianach w konfiguracji serwera trzeba go zrestartować, aby załapał nowe ustawienia:

Instalujemy Pythona

a może jest zainstalowany? Ubuntu 16.04 na dzień dobry przychodzi z Pythonem 2.7 oraz Pythonem 3.5 (w odpowiednich podwersjach):

Jeśli chcemy Pythona 3.6 to wykonujemy trzy kolejne linie:

W tym momencie mamy w systemie trzy wersje Pythona:

• python – uruchomi nam wersję 2.7,
• python3 – wersję 3.5,
• a python3.6 – 3.6

Jeśli chcemy móc wybierać z której wersji (3.5 czy 3.6) korzystać będzie polecenie python3 wykonujemy dwa polecenia:

Teraz możemy się przełączać między wersjami z użyciem

Ja wybrałem jako domyślną wersję 3.5, więc po

widzę Python 3.5.2. Uwaga – na wybranej wersji zainstalowany zostanie za kilka chwil Jupyter, więc wybierz mądrze :)

Instalujemy pip dla Pythona 3:

Kilka bibliotek systemowych może być koniecznych, zatem zainstalujmy je już teraz (podobnie jak w przypadku instalowania pakietów do R):

Instalujemy Jupyter

Jupyter to taka zubożona wersja RStudio. Lepsze to niż Python z konsoli – widać przynajmniej krok po kroku co się dzieje w kodzie. Poza tym wszyscy z niego korzystają ;)

Pierwszy krok przygotowania do normalnego funkcjonowania to zbudowanie domyślnego pliku konfiguracyjnego:

Teraz wygenerujemy hasło dostępu do Jupytera:

Uruchamiamy Jupytera

Wystarczy w tym momencie przejść na stronę http://nasza.domena:8888, zalogować się utworzonym hasłem i możemy działać w Pythonie!

Zamknijmy go jednak i zainstalujemy JupyterLab. Zamknąć można z konsoli (Ctrl-C) lub z przeglądarki (guzik Quit).

instalujemy JupyterLab

Po instalacji uruchamiamy JupyterLab:

Teraz po wejściu na http://nasza.domena:8888 powinien uruchomić się JupyterLab, a po wejściu na http://nasza.domena:8888/tree – Jupyter. Możemy ponownie zamknąć Jupytera i uruchomić go w tle:

Zwróć uwagę na & na końcu linii.

To jednak wymaga uruchamiania Jupytera ręcznie, po każdym restarcie serwera. Możemy to zmienić dopisując do pliku /etc/rc.local następującą linijkę (odpowiednio zmieniając ścieżki plików):

Ważne: to musi być dopisane przed linijką z exit 0. Dodanie tej linii spowoduje, że http://jupyter.nasza.domena otworzy Jupytera – aby korzystać z JupyterLab uruchamiamy http://jupyter.nasza.domena/lab. W miejsce wpisujemy oczywiście naszego użytkownika.

GitHub

Przyda nam się git chociażby po to, aby na GitHubie trzymać swoje pliki źródłowe.

gita musimy też skonfigurować:

W “user_name” i “email_id” wprowadzamy dane swojego konta na GitHubie.

PostgerSQL

Mamy zainstalowaną bazę MySQL, ale możemy z różnych powodów chcieć korzystać z PostgreSQL.

Instalacja jest prosta i analogiczna do wszystkich wcześniejszych:

PostgreSQL działa w oparciu o role, a po instalacji istnieje tylko rola postgres. Warto stworzyć nową – uruchamiamy psql dla istniejącej roli:

A następnie tworzymy bazę danych, użytkownika (razem z hasłem) i nadajemy mu uprawnienia do stworzonej bazy:

Teraz (działając na naszym standardowym loginie) możemy uruchomi psql łącząc się z nową bazą (na razie pustą):

Po połączeniu się z bazą, już z poziomu pqsl możemy utworzyć sobie stosowne tabele, od dla przykładu (z jakiegoś tutoriala):

Czy tabela powstała? Będąc nadal w psql sprawdzamy to wpisując \d co powinno dać wynik typu:

Wpisując \q możemy wyjść z PostgreSQL. Wcześniej możemy usunąć testową tabelę:

Oczywiście na bazę danych możemy mieć inny serwer niż na resztę – oszczędzamy wówczas miejsce na aplikacje. Podobnie z plikami statycznymi. Ale to już robi się małą farma ;)

Serwer FTP

Po co nam serwer FTP? Chociażby po to, aby w prosty sposób przekazywać pliki na serwer (lub z niego je pobierać). Konfiguracja jest szybka i dość prosta. Najpierw oczywiście instalacja:

Serwer już działa. Warto jeszcze ograniczyć dostęp dla użytkowników tylko do ich domowych folderów oraz pozwolić im na zapis plików, zatem zdejmujemy komentarz z linii:

oraz dodać

w pliku /etc/vsftpd.conf. Po zmianach oczywiście restart serwera:

Ograniczenie dostępu do folderów to zwiększenie bezpieczeństwa (na przykład żeby nikt nie skasował przez przypadek produkcyjnych plików z serwera www albo Shiny). Zawsze można pliki przerzucić do folderu w domku użytkownika, a następnie – już z konsoli – podmienić pliki.

Serwer działa w trybie passive – to może być istotne w konfiguracji klienta FTP.

rgdal

Jeśli chcemy wykorzystywać mapy i pliki SHP to przyda nam się biblioteka rgdal (w R). Ta zaś łatwo się nie zainstaluje bo najnowsza wersja wymaga gdal w wersji >= 1.11.4, a domyślnie w repozytoriach mamy wersję niższą. Podobnie jak wcześniej – trzeba zainstalować coś w systemie zanim zainstalujemy pakiet w R:

Teraz już rdgal uda się zainstalować – skorzystaliśmy z innego repozytorium, gdzie jest nowsza wersja biblioteki systemowej gdal. Przy okazji instalując co trzeba dla Pythona.

LaTeX/Pandoc

Jeśli chcesz generować raporty w plikach PDF korzystając z rmarkdown to potrzebujesz LaTeXa i pandoc. Do renderowania plików LaTeXa polecam xetex

W konfiguracji RStudio trzeba wybrać “Typeset LaTeX info PDF using: XaLaTeX”. Powinno zadziałać.

Teraz taki hint – rozwiązanie problemu, z którym walczyłem pół dnia próbując renderowac raporty skryptami odpalanymi cyklicznie z crona. W przypadku renderingu plików do LaTeXa/PDFa uruchamianych z konsoli (np. przez Rscript) odpowiednio musimy ustawić zmienną środowiskową RSTUDIO_PANDOC (domyślnie ma wartośc /usr/lib/rstudio-server/bin/pandoc). Zatem na początku skryptu R uruchamianego z konsoli wpisujemy:

i sprawa załatwiona – rmarkdown::render() działa jak należy.

WordPress

Przygotowane środowisko gotowe jest na przyjęcie na przykład WordPressa (na którym można postawić stronę www). Proces instalacji świetnie opisuje post w serwisie Hostovia.pl – całość jest prosta i sprowadza się do kilku (może dziesięciu) kroków.

Hugo

Zamiast pisać blogaska w WordPressie możemy zechcieć skorzystać np. z Hugo, czyli silnika do generowania stron statycznych, których całą treść można trzymać w plikach Markdown i renderować całe serwisy. To bardzo popularne w środowisku użytkowników R. Szczegóły instalacji znajdziecie na stronie GoHugo.io.