@nicram Hej, super robota! Odpalilem skrypt na czystym Debianei 11 i kilka skromnych uwag ode mnie, co bym zmienil/dodal:

1. Zrobiłeś Apache + mod_php, nie rozumiem czemu nie Apache + php-fpm? We współczesnych LAMP stackach stosuje się php-fpm wszędzie, w Enterprise Linux to defaultowy setup.
   

2. Certbot rejestruje bez emaila, Twój kod:
   

certbot --register-unsafely-without-email

Moze warto byloby dodac opcje, zeby zapytal o email? Albo w początkowej komendzie dodać opcję:

./twoj_skrypt.sh moja.domena.com moj@email.com

3. Skrypt nie ustawia 'vm.overcommit_memory = 1', spojrz na logi redisa:
   

overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

4. Skrypt nie wylacza THP, spojrz na logi redisa:
   

33787:M 30 Jan 2023 2119.476 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo madvise > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled (set to 'madvise' or 'never').

5. /var/www/nextcloud ma permissions 777 ;-( - bardzo nieladnie, 775 w zupelnosci Ci wystarczy, wszystko (Apache + mod_php) biegaja pod www-data.
   

6. Config nextclouda - dlaczego dales Redis dla memcache.local? Dokumentacja sugeruje APCu dla malych domowych serwerow nextclouda, ale tez dla wiekszych organizacji albo klastrow: https://docs.nextcloud.com/server/latest/admin_manual/configuration_server/caching_configuration.html Ja bym to zmienil na:
   

'memcache.local' => '\OC\Memcache\APCu',

'memcache.distributed' => '\OC\Memcache\Redis',

'memcache.locking' => '\OC\Memcache\Redis',

7. Dodajesz reguly do "ufw" ale nie startujesz ufw, brakuje:
   

ufw enable

8 ) Usunalbym string "index.php" z URL, np: https://serverfault.com/questions/835665/remove-index-php-from-nextcloud-urls-using-apachefastcgi

Good shit! Grzmot! Co prawda nie korzystam z Debiana i lepiej by się to sprawdziło u nie na rhel'o podobnych dystrybucjach, ale zawsze można przepisać skrypt! ᕦ( ͡° ͜ʖ ͡°)ᕤ Piękne dzięki dobry człowieku!

@nicram I tak musisz gdzieś dołączyć część o chociaż puszczeniu portów, dyn/static IP, bo bez tego to tak:

-Ludzie w LANie i tak pchają na NASy czy nawet na lokalne shary widoczne w sieci

-Ludzie w internecie się nie dobiją do swoich rzeczy, więc na kij im to

No i tak jak pisze @maybe, daj maila do certbota, bo potem przychodzą Ci powiadomienia, żebyś pamiętał o tym (wiem że jest autorenew, ale jednak) + 777 to odważne ustawienie współdzielonego share

@maybe Uo, dzięki za odpowiedź, się nie spodziewałem że ktoś od razu będzie się tym bawił. Dzięki za analizę tego bo zwykle mało kogo interesują takie rzeczy Postaram się udzielić odpowiedzi:

1 - sam u siebie mam też php-fpm, i z tego powodu swego czasu wykrywałem dużo problemów z przesyłaniem plików (dużej ilości np. 2TB), w celu rozwiązania twórcy zalecali stosowanie mod_php po prostu co faktycznie część problemów wtedy rozwiązało. Chodzi jedynie o ograniczenie problemów tego typu. Co prawda było to dość dawno (koło wersji 14 czy 18, już nie pamiętam), ale pozostawiłem to na wszelki wypadek. Mimo szybkiej zmiany numerów wersji, to tak naprawdę niektóre błędy w NC są naprawiane latami i często wracają (ostatnio potwierdzałem wieszanie klienta w momencie używania ograniczeń prędkości przesyłania),

2 - to jest warte rozważenia, dodatkowy argument nic nie kosztuje a zainteresowani mieli by łatwiej. Przemyślę to.

3 i 4 - to są domyślne ustawienia redisa i faktycznie warto to zrobić.

5 - to też ustawione z powodu jakichś problemów z przeszłości (ten skrypt przed publikacją 1 wersji miał już parę lat ;-)) poprawi się

6 - Redis zamiast APCu z powodu błędów na jakie swego czasu natrafiłem (crashowało mi się w 2 różnych środowiskach). Podobno to poprawili ale ja tam jestem nieufny stąd redis.

7 - nie zauważyłem, dzięki!

8 - kosmetyka w sumie, jak mi się będzie nudziło to wstukam

Dzięki za pracę, fajnie że jeszcze się komuś chce czasami coś przejrzeć

@AndrzejZupa co ciekawe oryginalnie skrypt był na RHEL właśnie, ale z czasem ze względu na różne małe środowiska przepisałem na Debiana (bo zwyczajnie szybciej startuje na pudełkach jak terminale). Osobiście nadal na RHEL siedzę

@tellet No ja trochę liczę, że to nie jest rozwiązanie dla osób, co nie wiedzą zupełnie nic o sieci - skoro już Debiana używają to chyba jakaś wiedze tam mają (chociażby podstawową). Raczej myślałem tutaj o takim dużym ułatwieniu, że sobie odpalasz to, a później dopieszczasz po swojemu W przyszłości chcę do tego zrobić może jeszcze jakiś moduł i dokument (żeby się łączyć ze świata właśnie bez zewn. IP). Ale to kiedyś, w wolnym czasie tak jak to.

@nicram fajny tutek, warto promować Nextcloud, bo to bardzo fajne rozwiązanie. Zwłaszcza jak masz swojego VPSa, albo nawet raspberryPi wystawione na świat. Ja się przesiadłem po tym jak Dropbox po raz pięćsetny spuchł i kazał zmienić taryfę. Ostatnie przygody z np. Lastpass w ogóle skłaniają do podejścia self-hosted jako najbezpieczniejszego.

P.S. Kłóciłbym się z tym, że docker obniża wydajność, bo to nie jest dodatkowa warstwa (Kernel Linuksa wspiera wirtualizację, więc komunikacja kontenerów z nim jest bardzo zoptymalizowana), aczkolwiek rzeczywiście instalacja na kontenerach dla kogoś bez doświadczenia może przynieść problemy (choć w dłuższej perspektywie jest imo lepsza).

@size No ja większość rzeczy selfhosted. Oczywiście chmura jest fajna, ale trzeba pamiętać że to tylko cudzy komputer (co dobitnie pokazały ostatnie awarie w dostępie do usług MS na przykład). Co do dockera, to nadal mam koszmary o tym, jak wysypywał się stos sieciowy w jakiejś dystrybucji, bo generalnie sieć w dockerze jest dziwnie skonstruowana i bardzo zaawansowane rzeczy zwyczajnie niewygodnie się robi. Docker daje trochę wygody jak się coś 1 raz uruchamia i później tym zarządza w celu aktualizacji na przykład. Ale ja tam lubię znać położenie każdego pliku w systemie i wiedzieć co robi

Co do dockera, to nadal mam koszmary o tym, jak wysypywał się stos sieciowy w jakiejś dystrybucji, bo generalnie sieć w dockerze jest dziwnie skonstruowana i bardzo zaawansowane rzeczy zwyczajnie niewygodnie się robi

https://www.youtube.com/watch?v=bKFMS5C4CG0 - tutaj jest bardzo fajnie wytłumaczona cała architektura sieci w Dockerze. Do tego jak coś się "dziwnie sypie" to warto obniżyć MTU w usłudze Dockera ;). Jak robisz coś self-hosted używając kontenerów, to sprawdź sobie jeszcze to: https://k3s.io .

Docker daje trochę wygody jak się coś 1 raz uruchamia i później tym zarządza w celu aktualizacji na przykład. Ale ja tam lubię znać położenie każdego pliku w systemie i wiedzieć co robi

I każdy proces ma dostęp do procesów oraz systemu plików hosta, oprócz tego każda usługa współdzieli te same biblioteki w systemie (więc jak wymagają różnych wersji tej samej biblioteki lub platformy to pozdro). Do tego usunięcie / aktualizacja zostawia śmieci i starą konfigurację.

Poza tym przecież nie znasz położenia każdego pliku w systemie ani nie wiesz co robi, a trudność poznania tego w kontenerze wcale nie jest większa niż w systemie hosta.

@PanPaweuDrugi Wbrew pozorom łatwo sobie wyobrazić jaki plik co robi Miałem na myśli raczej wiedzę co gdzie się znajduje, bez szukania. Co do tej sieci, to akurat crashował iptables wtedy, teraz pewnie już nie ma tego problemu, ale niesmak pozostał Ja osobiście unikam dockera o ile jest to możliwe. Problemu wersji bibliotek, czy pozostawiania śmieci docker nie rozwiązuje, a jedynie to maskuje w swoich kontenerach, ale te często zostają (zdarza się że jakiś soft nagle pobiera nowsza wersję jakiejś paczki bazy danych, stara jest wyłączona ale zostaje oczywiście, więc i tak trzeba samemu to wyłapywać i czyścić). Wolę odschoolowo - każdy serwis w osobnej maszynie (najlepiej hardware a nie VMki).

Co do tej sieci, to akurat crashował iptables wtedy, teraz pewnie już nie ma tego problemu, ale niesmak pozostał

Opiszesz coś więcej? Jestem ciekaw co tam się działo.

Wbrew pozorom łatwo sobie wyobrazić jaki plik co robi Miałem na myśli raczej wiedzę co gdzie się znajduje, bez szukania.

Baza danych znajduje się w kontenerze "postgresql", natomiast serwer www w kontenerze "nginx". Jak chcę zobaczyć co jest w środku, to wchodzę na githuba i patrzę w dockerfile z którego kontener jest zbudowany, potem już wiem.

zdarza się że jakiś soft nagle pobiera nowsza wersję jakiejś paczki bazy danych, stara jest wyłączona ale zostaje oczywiście, więc i tak trzeba samemu to wyłapywać i czyścić

Nie, nie zdarza się, dobrze przygotowany kontener z oprogramowaniem nie modyfikuje bibliotek ani plików wykonywalnych w środku. Jeśli chcesz nową wersję softu, zaciągasz obraz z nowego taga, a stare kontenery po prostu w całości usuwasz.

Wolę odschoolowo - każdy serwis w osobnej maszynie (najlepiej hardware a nie VMki)

Twoje prawo. Ja mam tak dobrze przygotowany workflow oparty o kontenery, że nie wyobrażam sobie sposobu wdrażania oprogramowania, który opisałeś. Wydaje mi się niewygodny, oporny w automatyzacji, trudny w zarządzaniu, kompletnie nieskalowalny i nieprzenaszalny, a do tego wszystkiego mało bezpieczny. Chociażby perspektywa konieczności rollbackowania aktualizacji wersji jakiegokolwiek komponentu w Twoim środowisku jest dla mnie niewyobrażalna. Ale co człowiek, to opinia.

Polecam jednak się lepiej z tym zapoznać, to jest zajebista technologia i jak już pokonasz trudności związane z jej stosowaniem, to nie sposób się w niej nie zakochać.

@PanPaweuDrugi Nie pamiętam kompletnie co to było, w jakich warunkach itp. Parę lat temu już, ale nawet nie pamiętam jakie distro to było. Dawniej głównie OpenBSD używałem, i nawet tam niechcący trafiłem na błąd w pfctl (się crashowało). Mam trochę pecha do przypadkowego trafiania na błędy, głównie wycieki pamięci to moja pasja Natomiast też niezły szok był po przejściu z BSD Na Linuxy (jaki to syf, jakie braki w dokumentacji i ile błędów się znajduje, na szczęście dzisiaj jest już dużo lepiej).

Nie umiem cytować niestety tutaj, odnośnie czytania plików dockera żeby wiedzieć co jest wcześniej, to zdecydowanie zrobić cd /lokalizacja i ls -a

Odnośnie pozostawiania syfu dockerowego, to nie chodziło mi o modyfikacje plików wewnętrznych, ale właśnie pobieranie nowych kontenerów, gdzie same jak napisałeś trzeba usuwać - samodzielnie pozostawione same sobie starsze wersje. Pół biedy kiedy to jest maszyna, do której masz normalnie dostęp - ale są rozwiązania gdzie to nie jest takie proste. Czasami testuje urządzenia (routery czy tam switche), które działają na własnych dystrybucjach i właśnie używają dockera. Często aktualizacje wtedy własnie zostawiają jakieś stare elementy, które spokojnie można by było usunąć, a tak leżą i marnują przestrzeń (najczęściej takie testowe urządzenia presale mają zwykle jakieś spore dyski zamontowane, ale finalne produkty to tam wiadomo, wszystko malutkie).

Rollbacki itp. sprawy załatwiają kopie zapasowe. Zarządzanie też nie problem jeżeli wie się, co chce się zrobić i jak. W dockerze po prostu jest dużo mniej opcji, więc łatwiej to usystematyzować - ale daje to dużo mniejsze pole manewru (np. kontener z apką, która jest skompilowana bez argumentu, który akurat potrzebujesz, możesz wtedy albo samemu budować kontenery, albo szukać i może coś gdzieś się jakoś znajdzie). Wszystko zależy imho od środowiska i potrzeb. Zakochac się raczej w dockerach nie dam rady, za duży syf, no i dodatkowy nakład czasu żeby je ogarniać wolę na inne rzeczy poświęcać Ale fajna w nich jest ta ułuda automatyzacji wszystkiego (aż nie pojawi się jakiś większy problem oczywiście).

pobieranie nowych kontenerów, gdzie same jak napisałeś trzeba usuwać - samodzielnie pozostawione same sobie starsze wersje. Pół biedy kiedy to jest maszyna, do której masz normalnie dostęp

@nicram dlatego na urządzeniach innych niż maszyna deweloperska powinno się stosować orkiestratory, takie jak choćby Kubernetes, one to wszystko (i znacznie, znacznie więcej) robią za Ciebie. K8S ma garbage collector, który dba o wywalanie wyłączonych kontenerów i osieroconych obrazów. W przypadku gołego dockera:

docker system prune -af

i po problemie, wszystkie śmieci usunięte, nieużywane obrazy, stare wyłączone kontenery - wszystko leci w niebyt.

Czasami testuje urządzenia (routery czy tam switche), które działają na własnych dystrybucjach i właśnie używają dockera. Często aktualizacje wtedy własnie zostawiają jakieś stare elementy, które spokojnie można by było usunąć, a tak leżą i marnują przestrzeń

Pytanie czemu producent nie wie, że to można czyścić, ale to przecież nie jest wina dockera, bo on ma do tego narzędzia, tylko producenta, który o to nie zadbał. Wystarczy przecież dodać prune do crontaba i po problemie.

Rollbacki itp. sprawy załatwiają kopie zapasowe

No jak masz jedną usługę na maszynę, to kopia zapasowa rzeczywiście załatwi Ci rollback, no chyba że to rollback wersji bazy danych, to wtedy już masz problem, bo chcesz cofnąć wersję serwera, ale zostawić nowe dane. Tylko że często usługa wymaga bardzo mało zasobów i trzymanie się założenia jednej maszyny fizycznej na usługę to wtedy straszne marnowanie zasobów. Ciekaw jestem jakbyś w swoim modelu wdrożył system tworzony w architekturze mikroserwisowej, który ma np. 40 mikroserwisów, z czego każdy zużywa 0,1 CPU i średnio 100 MB RAMu.

kontener z apką, która jest skompilowana bez argumentu, który akurat potrzebujesz, możesz wtedy albo samemu budować kontenery, albo szukać i może coś gdzieś się jakoś znajdzie

Oczywiście, budując środowisko oparte o kontenery, powinieneś sobie zapewnić jakiś system CI/CD, który Ci będzie budował obrazy, których nie ma w publicznych źródłach, inaczej jesteś zdany na dockerhuba albo samodzielne budowanie tego na kompie, a nie po to się wchodzi w takie technologie jak konteneryzacja żeby sobie na głowę sprowadzać manualną pracę w postaci budowania obrazów.

Zakochac się raczej w dockerach nie dam rady, za duży syf

Ja właśnie jestem kompletnie przeciwnego zdania, po obserwowaniu adminów robiących

ssh root@produkcja1

cd /var/produkcyjna-aplikacja

git pull

make build

uważam kontenery za nirwanę porządku i systematyzacji w zarządzaniu środowiskami.

Nie umiem cytować niestety tutaj

Załączam zrzut ekranu