Archi

Co znaczy, że spieprzyłeś instalację bo mi certyfikaty LE działają nawet na nginxie i mojej egzotycznej instalacji z Debianem Testing na czele.

KeePass działa świetnie wraz z wtyczką http i rozszerzeniem chromeIPass do Chromium/Chrome. Zarówno super bezpieczne jak i bardzo wygodne rozwiązanie.

O czym my w ogóle dyskutujemy w takim razie.

Ja też lubię spać spokojnie, dlatego ilość segfaultów na apache i to co się działo zanim jako tako wersja 2.4 w ogóle została okrzyknięta stabilną dawno mnie sprowadziło do pokochania nginxa i w życiu do apache'a już nie wrócę. Nawet jednego razu nie miałem sytuacji, w której ta konkretna usługa by mnie zawiodła.

Osobno, jak chcesz autoinstallery dla ubogich to masz vestę. https://www.howtoforge.com/tutorial/perfect-server-debian-9-stretch-apache-bind-dovecot-ispconfig-3-1/ A jak chcesz to samo tyle że z nginx + php-fpm to sobie porównaj z https://www.howtoforge.com/tutorial/perfect-server-ubuntu-with-nginx-and-ispconfig-3/ i popraw kroki które trzeba.

Vesta jest zabugowana od cholery, nie wiem czy osoby które tutaj twierdzą, że nigdy się nie spotkały z problemami w ogóle się tego panelu dotykały bardziej niż postawienie pojedynczej domeny - nawet nie ma o czym mówić. ISPConfig 3 działa wręcz przecudownie z nginx + php-fpm. Jeszcze lepiej niż z apachem.

Konkretnych liczb Ci nie dam bo zależą od wielu czynników, w tym samego skryptu PHP jak i CPU, ale w kwestii throughput do prawidłowo skonfigurowanego i zoptymalizowanego nginx + php-fpm apachem nie dojedziesz, a przynajmniej ja nie dojeżdzałem jak testowałem 2.4, czy to na workerze czy evencie. Nie, liczby nie odstawały jakoś znacząco na evencie, z tego co pamiętam to było coś koło 85% tego co wyciagał nginx, ale jednak nie udało mi się nginxa przebić w żadnym teście poza wydajnością pojedynczego requesta vs apachowy mod_php. Poza tym FPM w wersji ondemand to coś cudownego jeśli chodzi o zasoby samego serwera. Skalowalność takiego rozwiązania jest dużo lepsza niż FPM w wersji dynamic czy worker/event z apache'a.

Nginx + php-fpm to obecnie najprzyjemniejsze i jednocześnie jedno z najwydajniejszych rozwiązań jakie są dostępne, oczywiście nie pod względem czasu wykonywania pojedynczego requesta, a liczbie wykonywanych requestów na sekundę. Jedyne co ma możliwość być szybsze to HHVM, ale to tak eksperymentalne rozwiązanie, że na dzień dzisiejszy nigdzie poza środowiskami testowymi bym nie stawiał.

Również nie zanotowałem żadnych, chociaż zanim nginx zaczął działać z LE poprawnie to działy się cuda, tyle że to było na długo przed stabilną wersją.

Tyle, że akurat to narzędzie to nie jest do odpalenia na raz i zapomnienia, a aktualna wersja w repozytorium apt zawsze jest bardziej wygodna niż manualna aktualizacja przed każdym użyciem. Trzeba znaleźć balans między jednym a drugim. Ja z kolei wychodzę z założenia, że jak jest coś czego używam w repo, to korzystam z repo.

ISPConfig to jest jedyny darmowy panel, który chociaż kwalifikuje się do bycia zarówno dobrym jak i na produkcję. Testowałem wiele innych, z takimi kobyłami jak Vesta na czele. Nic do ISPConfiga się nawet nie umywa, oczywiście z rozwiązań darmowych.

Jako host Debian Testing, ale wewnątrz VMware z Windows 10 i GPU passthrough do grania w gierki i używania tej niewielkiej ilości programów, których na Linuxa nie ma lub jeszcze nie ma.

Albo --syn albo -m state --state NEW. State jest bardziej uniwersalne bo też działa na inne protokoły. W przypadku TCP to jedno i to samo.

Jak masz regułkę na ESTABLISHED/RELATED to warto wszystkie allowy do portów po TCP ustawić tylko na stan SYN. Wtedy ładnie blokujesz np. spam SYN/ACK, który w Twoim przypadku ładnie by przez iptables przeszedł.

A jeszcze prościej - główny serwer DNS tłumaczy domeny na adresy IP dla komputerów. Jeśli nagle przestanie działać, nikt po twojej domenie na twój serwer również się nie połączy, nawet jeśli on działa prawidłowo. Secondary DNS ma za zadanie robić dokładnie to samo co primary w przypadku jego awarii. A zabieg ten stosuje się w celu redundancji.

Zyski z używania HTTP/2 są bezpośrednio połączone z ilością połączeń jaką musi wykonać klient, żeby załadować stronę. Jeśli serwer zwraca jedynie czystego (może być przerobionego przez php) htmla, a wszystkie odnośniki wraz z cssami, javascriptami i innymi duperelami są np. na jakimś cdn, to zysku z używania HTTP/2 nie będzie żadnego lub będzie nawet ujemny w stosunku do połączenia HTTP/1.1. Jednak w przypadku ładowania dużej ilości danych, przede wszystkim obrazków, cssy i innych dupereli, zysk może być rzeczywiście znaczący z powodu braku potrzeby ustanawiania nowego połączenia dla każdej pobieranej rzeczy. Ustanawianie połączenia, a już przede wszystkim szyfrowanego po HTTPS jest bardzo kosztowną operacją całkowicie niewspółmierną do np. pobrania malutkiego pliku css. Inna sprawa to to, że na ogół wszystkie takie statyczne wieloelementowe rzeczy właśnie lądują na CDN, więc bardzo trudno będzie zauważyć rzeczywisty zysk. No chyba, że Twój klient ma wszystko hostowane na serwerze i nawet o CDN nie słyszał, ale wtedy to nie wiem o czym my w ogóle rozmawiamy.

Nie, nie lubię tej metody. O wiele lepszym jest postawienie lokalnego serwera bind i skonfigurowanie go w tryb forward. Wtedy twój resolv.conf wygląda o tak: nameserver 127.0.0.1 nameserver 8.8.8.8 Z kolei bind ma w forwarderach obydwa serwery googla i obydwa OpenDNS. Wpis 8.8.8.8 w resolv.conf jest jedynie na bardzo rzadki przypadek, gdyby jednak bindowi coś się stało i nie chciał się podnieść. To rozwiązanie ma od cholery stron pozytywnych, najważniejszą jest to, że potrafi cache'ować zapytania i nie odpytywać niepotrzebnie DNSa z każdym requestem. To się bezpośrednio przekłada na szybkość requestów opartych o domeny. Z mniej ważniejszych pozytywnych stron jest chociażby możliwość odpytywania wszystkich DNSów jednocześnie i akceptowanie najszybszej odpowiedzi, nie mówiąc już nic o reszcie funkcjonalności. W bardzo rzadkich przypadkach kiedy bind może się wydawać zbyt dużą kobyłą, stawiam dnsmasq. To dobre rozwiązanie na bardzo niewielkie (128 MB) VPSy. Na ogół jednak bind stoi zawsze, nawet jeśli ma być tylko forwarderem zapytań DNS.

Jak wyżej ;). Generalnie za najbardziej uniwersalny OS pod serwer nadal uważam Debiana. Najbardziej uniwersalny nie znaczy "jedyny słuszny", ale taki z największą ilością zastosowań. Jeśli serwer ma być tylko pod hosting, tylko pod bazę, tylko pod dnsy, tylko pod pocztę czy inne rozwiązania "tylko X", to można się zastanowić nad tym czy nie lepiej postawić tam np. CloudLinuxa czy Alpine właśnie, ale jeśli serwer ma służyć do wielu zastosowań, uruchamiać wiele usług czy nawet sami jeszcze nie wiemy co dokładnie, to Debian jest najlepszym wyborem. Na produkcję Testinga bardzo niechętnie ale też czasem upcham, z odpowiednim zapleczem lvm snapshotów. Nadal uważam go za najlepsze distro na serwer, które jest dostatecznie stabilne, żeby z nim nieco ostrożnie z bardzo niewielkim ryzykiem się obchodzić, ale jak chcę spać spokojnie to stable z backportami ląduje tak czy siak - testing tylko na niektórych wybranych specyficznych serwerach. Da się, działa świetnie, mój rekordowy produkcyjny testing aktualizuję od czasów gdy squeeze był stable, a wheezy instalowany jako testing właśnie i do dziś śmiga na busterze - przeżył nawet migrację z sysvinit na systemd. Tyle, że do takiego serwera trzeba odpowiednio podejść i się znać, bo jednak rozwalić go nie jest trudno. Generalnie wszystko zależy od zastosowania.

Backupy na bazie snapshotów możesz robić już w lvm, nawet jeśli pod spodem jest ext4. ZFS ma zalety i wady, swojego czasu testowałem naprawdę dużo file systemów i w zasadzie jedynie ext4 mogę z czystym sercem polecić jako coś produkcyjnego i nie cierpiącego na ubytki wydajności czy inne problemy. ZFS jest fajny i na pewno ma zastosowanie jeśli umiesz go przyrównać do ext4 i stwierdzić "tak, z tego na pewno będę korzystał", ale dla samego FSa jako takiego bym go nie wybierał.

W busterze będzie na pewno, już teraz jest w testingu, a nie zapowiada się, żeby z testinga cokolwiek miało wylecieć. Jednak do stable wydaje mi się, że tylko backporty będą.

Dużo tego o czym napisaliście już jest w planach, część sam wdrażałem wczoraj (np. obsługę tapatalka), będziemy powolutku wszystkie te pomysły realizować, jako że forum dopiero raczkuje i o ile funkcjonalne już jest i pisać można, to jest spora część rzeczy, które jeszcze od strony technicznej można zrobić/poprawić. Dzięki za wszystkie sugestie, śmiało podsyłajcie następne.

Warto też się upewnić, że korzysta się z aktualnej wersji. Twórcy mysql tunera cały czas go poprawiają, aktualne wersje są o wiele mniej podatne na właśnie takie błędy jak zwiększanie parametrów w nieskończoność, poza nowymi funkcjami które podpowiadają coraz to nowsze parametry dodane w aktualnych wersjach MySQL/MariaDB.

Faktura za kimsyfy nie musi być z FR - wszystko zależy jaki to kimsyf i kiedy go kupowałeś. Mój kimsyf z 2012r jest normalnie płacony w Polsce oddziałowi OVH z Wrocławia, płacę w złotówkach i nie ma mowy o żadnym przeliczaniu euro. Nie zakładajmy z góry jedynej słusznej faktury. Rozumiem, że OP ma taką, ale i bez VAT-EU niekoniecznie musi taką dostawać, chyba warto w supporcie księgowości podpytać.

Yup, nikt nie będzie na siłę programował czegoś bez sensu. Ext4 już jest długo z nami i nie zapowiada się, żeby był przez cokolwiek w najbliższej przyszłości zastąpiony, bo póki co nie ma drugiego filesystemu który jest tak bardzo wydajny, odporny na błędy, stabilny i zoptymalizowany jak ext4 - a to wszystko dzięki seriom poprawek, która w linuxie się odbywa praktycznie cały czas. Liczę jednak na to, że w przyszłości będzie coś co starego poczciwego ext4 wyprze, bo świat idzie jednak do przodu i chociażby przez porównanie z btrfs widać jak wiele poprawek możnaby do niego dorzucić.

A myślałeś o użyciu ich API i spięcia tego jako secondary? CF ma ten plus, że ma nie tylko ogrom możliwości, ale i naprawdę spore API i w zasadzie nic nie stoi na przeszkodzie, żeby je podpiąć u siebie i wykorzystać. Pewno będzie z tym nieco więcej roboty niż z innymi rozwiązaniami, ale CF to pierwsze co mi przychodzi na myśl jeśli chodzi o jakikolwiek hostowany DNS - imho warto.