# Przygotowanie wirtualnej maszyny
W VirtualBoxie na laptopie utworzyłem maszynę, na której będzie zainstalowany Debian w wersji 12, a na nim NextCloud. Do VM dorzuciłem dwa dyski (po 50 GB). Podczas instalacji spiąłem je w RAID 1 i właśnie na nim zainstalowałem system. W oddzielnym wpisie umieściłem instrukcję jak można podczas instalacji skonfigurować macierz RAID i na niej zainstalować system.
Po instalacji miałem problem, ponieważ system nie chciał się zbootować. Pomogła zamiana kolejności dysków w ustawieniach maszyny.
# Wstępna konfiguracja systemu
Gdy miałem już działający, zaktualizowany, czysty system utworzyłem migawkę maszyny. Będzie jakiś pierwszy punkt odwołania w przypadku problemów 😉 Po tym przyszła pora na ustawienie statycznego IP, a następnie na instalację i konfigurację SSH – dużo wygodniejsze od konsoli VirtualBox. Szybkie skopiowanie klucza publicznego do maszyny i można się łączyć przez ssh z poziomu laptopowego terminala. Pierwszą czynnością po zalogowaniu się na serwer była instalacja powłoki zsh w oparciu o skrypt, który napisałem jakiś czas temu w celu przyspieszenia/automatyzacji tej czynności.
To jest to miejsce do którego chcę wrócić po ewentualnych problemach z maszyną. Wywalenie starej migawki i utworzenie nowej.
# Instalacja webserwera
Mam już jedną instancję NextClouda uruchomioną jakiś czas temu na VPS. Wtedy jako webserwer wykorzystałem Apache (bo wtedy tylko jego znałem). W międzyczasie trochę się zmieniło w związku z tym teraz wybieram nginxa. Instaluję wersję extras dostępną w oficjalnym repo. Znalazłem w dokumentacji sekcje dotyczącą konfiguracji nginxa – na ten moment jednakże zostawiam czystą instalację i przechodzę do dorzucenia PHPa.
# PHP-FPM
Producenci NextClouda zalecają wykorzystanie PHP w wersji 8.2. Po przeszukaniu domyślnego repo (system to Debian 12.2) php-fpm występuje właśnie w tej wersji – extra :). Instaluję więc pakiet php-fpm. Utworzyło usługę php8.2-fpm.
Na podstawie wpisu „Serwer WWW w oparciu o NGINX” konfiguruję, aby nginx gadał z php po sockecie unixowym. Restart usługi, wrzucenie pliku z phpinfo(); i test. Działa 🙂
# Baza danych
Przyszedł czas na ostatni wymagany element – bazę danych. Ostatnio w kilku miejscach słyszałem, że PostgreSQL działa całkiem przyjemnie z NextCloudem. Większe doświadczenie jednakże mam z MariaDB i to właśnie ten system zainstaluję. Instaluję więc pakiet mariadb-server. Po zakończeniu instalacji oczywiście skrypt bezpieczeństwa: mysql_secure_installation
# Warunki wstępne do instalacji
W instrukcji instalacji chmury prywatnej na początku znajdziemy wymagane moduły PHP. Trzeba je wszystkie przejrzeć i ewentualnie doinstalować.
php -m | grep nazwa_modułu
Gdy nie ma: apt install php-nazwa_modułu.
Wszystko szło dobrze do momentu modułu SimpleXML. W systemie go nie znajduje, w repo znajduje tylko php-xml. Postanowiłem go zainstalować i w logach instalacji faktycznie pokazało moduł SimpleXML oraz kolejne zawierające również XML, jednakże php -m ich nie zwracał. Restart fpma też nie pomógł – php -m nie zwraca go. Sprawdziłem jednak w phpinfo() i wygląda, że moduł jest włączony. OK, na ten moment niech tak zostanie.
# Redis
W projekcie chciałbym wykorzystać cache w oparciu o Redisa. Instaluję redis-server. Po instalacji zmieniłem konfigurację, aby Redis korzystał z socketu unixowego zamiast TCP.
# Instalacja NextCloud
Wybieram opcję instalacji ręcznej. Z oficjalnej strony pobieram archiwum do katalogu /var/www/html. Po rozpakowaniu pojawił się katalog nextcloud. Trochę za długa ścieżka, chcę bezpośrednio to w html. (Tak wiem, że mogę to ustawić w nginx, ale wolę porządek 😉 ).
rm latest.tar.bz2 ; mv nextcloud/* . ; rm -r nextcloud
Zanim rozpocznę instalację przeglądam po kolei dokumentację. Wskazuje, aby skonfigurować jeszcze kilka rzeczy przed uruchomieniem. Edytuję sites-enabled/default zgodnie z instrukcją. Dodatkowo zmieniam właściciela katalogu /var/www/html
Według dokumentacji wymuszane jest HTTPS. Serwer chcę hostować jedynie po adresie IP, a do tego nie mam plików z certami. Próba dostępu do strony wywala błędem ERR_SSL_PROTOCOL_ERROR. Uruchomienie SSL bez certyfikatu wywala błąd o braku pliku. Po przekopaniu internetu przyszła pora na wygenerowanie własnego certyfikatu z wykorzystaniem OpenSSL dla adresu IP serwera. Podłączenie ich do konfiga nginx, reload usługi. Działa, instalacja ruszyła. Potrzebuje połączenia z bazą danych, więc szybkie podłączenie do mariadb i utworzenie bazy oraz usera. Wszystkie komendy oczywiście dostępne w dokumentacji 😀
Instalacja jest banalna – podanie loginu i hasła dla usera oraz konfiguracji z bazą danych. Chwila, moment i zainstalowane. Po zalogowaniu wydaje się, że działa. Na początku podepnę Redisa, aby przyspieszyć samego NextClouda. Jak się okazało w logach zaczęło wywalać RedisException: Permission denied. Okazało się, że problemem był brak uprawnień do socketu dla usera www-data. Pierwszy wynik z DuckDucka, który kierował na oficjalne forum rozwiązał problem 🙂 Mimo wszystko nie byłem pewien czy na pewno dobrze skonfigurowałem połączenie Redis-NC. Jest prosty sposób aby to zweryfikować: redis-cli -s /run/redis/redis-server.sock MONITOR . Po odświeżeniu strony dostaniemy logi dotyczące GETa.
# Ostrzeżenia bezpieczeństwa i konfiguracji
NextCloud udostępnia swój tester konfiguracji i zabezpieczeń. W moim przypadku zwrócił on kilka błędów.
Błędy dotyczące PHPa udało się skasować modyfikując pliki wewnątrz katalogu /etc/php/8.2/fpm.
Jak widzimy pierwszy błąd wyświetla tylko info odnośnie problemów z integralnością. Znalazłem komendę, która z poziomu CLI wyświetla informacje o konkretnych plikach: sudo -u www-data php ./occ integrity:check-core . Konieczne było doinstalowanie sudo. W moim przypadku problem jest z dwoma plikami:
Rozwiązanie znowu znalazło się na forum. Należało pobrać zipa z ostatnią wersją NC i po rozpakowaniu podmienić plik .htaccess oraz skopiować brakujący .user.ini. Po wykonaniu tych czynności i ponownym wykonaniu testu integralności nie zwrócił już żadnych błędów. Dzięki temu udało się skasować czerwone błędy. Przejrzałem białe problemy – one nie mają znaczenia w tej instancji, w związku z tym zostają. Pozostało jedynie rozwiązać dwa problemy żółte (? :P).
Pierwszy z nich udało się rozwiązać dodając nagłówek w konfiguracji nginxa, natomiast w drugim należało odkomentować zmienną w pliku www.conf zawierającym konfigurację php-fpma.
# Optymalizacja NextClouda
Pierwszy krok w kierunku optymalizacji został już wykonany wcześniej – integracja NC z Redisem.
Drugi również – uruchomienie, aby nginx obsługiwał HTTP w wersji 2.
Kolejnym krokiem była optymalizacja PHP. Skonfigurowałem PHP Opcache – wystarczyło odkomentować kilka linii w pliku php.ini. Dodatkowo zmodyfikowałem zmienne pm. w pliku pool.d/www.conf. Obecnie panel WWW działa dużo przyjemniej niż na czystej instalacji 🙂
Delikatnie zoptymalizowałem również MariaDB. Najpierw ustawiłem innodb_buffer_pool_size zgodnie z zaleceniami na wartość 80% pamięci RAM. Następnie dodałem query_cache_size=64M.
Po wykonaniu powyższych czynności przyszła pora na podpięcie się do serwera z wykorzystaniem aplikacji klienckiej, a następnie synchronizacja plików. Pobranie nastąpiło bezproblemowo. Przystąpiłem do uploadu plików na serwer. Małe pliki udało się bez problemu wrzucić. Problem się pojawił w przypadku pliku, który w moim przypadku ważył 8GB. Pierwszy wynik w wyszukiwarce kieruje do oficjalnej dokumentacji, w której nagłówek informuje o problemach z uploadem plików większych niż 512 MB.
Jako offtopic małe testy. Dwa puste pliki utworzone dzięki dd – jeden 511 MB drugi 513 MB. Próba uploadu na serwer… Upload obu zakończony sukcesem. No ok – a 1GB? Error. 800 MB poszło. Mniejsza… Czyli wartość graniczna jest gdzieś pomiędzy 800MB, a 1GB.
Wracając do naprawy. Dodałem fastcgi_request_buffering off; do głównego pliku konfiguracyjnego nginx. W konfiguracji php zwiększyłem max rozmiar uploadowanego pliku. Reload usług, próba wrzucenia gigabajtowego pliku i znowu error. Niestety nie utworzyło mi pliku z logami. Aktualizacji config.php, dorzucenie informacji o logowaniu, utworzenie pliku dla logów, zmiana właściciela, reload usługi. Jest:
Powrót do dokumentacji, modyfikacja trzech zmiennych w pliku php.ini, utworzenie katalogu tymczasowego. Nic nie dało. Przejrzałem logi nginx i faktycznie sieje błędem „client intended to send too large body„. Faktycznie w konfiguracji vhosta nginxa limit ustawiony na 512MB. Zmieniłem wartość na większą, nginx -t && nginx -s reload. Tym sposobem problem został rozwiązany 🙂
To jeszcze jeden test, spróbujmy wrzucić 10000 plików, każdy po 1MB – wartości totalnie z kosmosu, nie kalkulowałem. Po prostu… Pliki utworzone bezpośrednio w katalogu na kliencie: for ((i=1; i<=10000; i=i+1)); dd if=/dev/zero of=plik_$i bs=1M count=1. Synchronizuje się, więc czekam. Wskazuje, że zostało w granicach 40 minut. Load serwera max 2.6, średnio w okolicy 2 (przy 2-rdzeniowym procku – tak wiem, że na ten wynik nie wpływa tylko CPU), zużycie RAMu około 600MB. Dostęp przez WWW działa całkiem przyjemnie w tym czasie 🙂
Wszystkie pliku udało się wrzucić bezproblemowo.
W międzyczasie próbowałem również dostępu przez webdav – na Fedorze opcji „Połącz z serwerem…„. Wywalało cały czas błąd uwierzytelnienia. Jak się okazało należało utworzyć nowe hasło dla tej aplikacji w ustawieniach bezpieczeństwa danego konta.
Chciałbym wrócić jeszcze do logów – znalazłem w panelu administracyjnym NC zakładkę Dziennik zdarzeń. To właśnie w tym miejscu wyświetlane są logi. Po poprawnej instalacji chmury wyłączyłem logowanie do pliku w katalogu /var/log na rzecz wyświetlania logów właśnie w tej zakładce.