Zakres techniczny
Konfiguracja dopasowana do aplikacji, nie do listy produktów
Serwer może obsługiwać aplikację WWW, API, bazę danych, pocztę, repozytorium plików, bramę sieciową lub środowisko wirtualizacji. Zaczynamy od zależności i odpowiedzialności, a nie od instalowania wszystkich popularnych usług.
Konfiguracja serwera Linux to w praktyce seria świadomych odstępstw od ustawień domyślnych. Pakiety z repozytorium startują tak, żeby w ogóle ruszyć na dowolnej maszynie: z ostrożnymi limitami, otwartym nasłuchem na wszystkich interfejsach i logowaniem, które po miesiącu zapełnia partycję. Naszym zadaniem jest przestawić to pod jeden konkretny profil pracy i zapisać, dlaczego akurat tak.
Konfiguracja serwera dedykowanego przejętego po kimś innym zaczyna się inaczej niż praca na czystej maszynie. Pierwszym produktem nie jest wtedy żadna zmiana, tylko spis stanu zastanego - dopiero on pozwala odróżnić ustawienie celowe od takiego, które ktoś kiedyś wkleił i zapomniał usunąć.
Trylobit realizuje prace jednorazowe i projektowe. Stałą opiekę, dyżury i SLA prowadzi LinuxAdmin by SysGroup, dzięki czemu instalacja nie udaje abonamentu, którego klient nie zamawiał.
Co możemy przygotować
Warstwa WWW
Nginx lub Apache z PHP-FPM, osobna pula procesów na witrynę, certyfikaty z automatycznym odnowieniem, kompresja, limity żądań, nagłówki bezpieczeństwa i przemyślana obsługa błędów bramy zamiast pustej strony.
Bazy danych
MariaDB, MySQL i PostgreSQL: dedykowani użytkownicy zamiast jednego roota do wszystkiego, nasłuch ograniczony do pętli zwrotnej lub sieci prywatnej, bufory dobrane do pamięci maszyny, kopia logiczna razem z dziennikiem pozwalającym odtworzyć stan sprzed awarii.
Poczta i DNS
Serwer pocztowy z uwierzytelnianiem, TLS i filtrem antyspamowym, komplet wpisów SPF, DKIM i DMARC oraz własny DNS tam, gdzie samodzielne utrzymanie ma uzasadnienie operacyjne i wskazanego właściciela.
Wirtualizacja i kontenery
Proxmox oraz QEMU/KVM: podział zasobów, sieć, magazyny danych, kopia konfiguracji hosta. Docker uruchamiamy tam, gdzie ułatwia wydania, a nie po to, by dołożyć warstwę do diagnozowania.
Dostęp
SSH na kluczach, konta imienne, sudo o zawężonym zakresie, wyłączone logowanie hasłem, zapora sieciowa i spisana zasada odbierania dostępów, gdy ktoś kończy współpracę.
Kopie zapasowe
Zakres, retencja, szyfrowanie, miejsce docelowe poza maszyną źródłową, monitorowanie wykonania i - najważniejsze - próbne odtworzenie przeprowadzone przy odbiorze, a nie obiecane na przyszłość.
Logi i porządek na dyskach
Rotacja, limity rozmiaru dziennika systemowego, oddzielenie danych od systemu, alarm na przyrost zamiast alarmu na brak miejsca. Pełna partycja potrafi zatrzymać bazę skuteczniej niż awaria dysku.
Sieć i zapora
Reguły ruchu przychodzącego i wychodzącego, translacja adresów, tunel do biura lub między lokalizacjami, ochrona przed zgadywaniem haseł oraz jawna lista portów wystawionych na świat.
Jak prowadzimy prace konfiguracyjne
Kolejność nie jest przypadkowa: każdy krok zamyka się czymś, co można pokazać, a przy każdym istnieje droga powrotu.
- 1
Spis stanu
Wersje, nasłuchujące porty, zadania cykliczne, punkty montowania, źródła pakietów, wiek ostatniej kopii. Wynik dostajesz nawet wtedy, gdy na tym poprzestaniemy.
- 2
Projekt ustawień
Ustalamy wartości docelowe i uzasadnienie każdej z nich, dzielimy prace na te bez przerwy w działaniu i te wymagające okna serwisowego.
- 3
Wdrożenie
Zmiany wchodzą partiami, z kopią plików konfiguracyjnych i testem składni przed przeładowaniem usługi. Każdą partię potwierdzamy działającym środowiskiem.
- 4
Odbiór
Lista testów: strona odpowiada, poczta wychodzi, kopia się wykonuje i daje się odtworzyć, alarm dociera. Do tego dokumentacja i lista ryzyk.
Co najczęściej zastajemy do poprawy
Poniższe punkty pochodzą z realnych przeglądów maszyn przekazanych nam po innych wykonawcach. Żaden z nich nie jest egzotyczny - i właśnie dlatego bywają niezauważone latami.
- Kopia leży na tym samym dysku. Awaria nośnika zabiera dane razem z ich kopią, a przy szyfrującym oprogramowaniu wymuszającym okup - jednocześnie oba komplety.
- Baza nasłuchuje na wszystkich interfejsach. Port 3306 albo 5432 widoczny z internetu to zaproszenie, nawet przy dobrym haśle.
- Brak rotacji logów. Katalog z dziennikami zapełnia partycję systemową, a usługa przestaje zapisywać dane w środku dnia.
- Jedna pula PHP-FPM dla wszystkich witryn. Jedna zamulona strona wysyca wszystkie procesy i kładzie pozostałe, choć z nimi nic się nie stało.
- Certyfikaty odnawiane ręcznie. Działa, dopóki osoba, która je odnawiała, jest w firmie i pamięta o terminie.
- Praca na koncie root. Brak śladu, kto co zmienił, i brak możliwości odebrania dostępu jednej osobie.
- Nieustawiona synchronizacja czasu. Rozjechany zegar psuje korelację logów, uwierzytelnianie i harmonogramy.
- Monitoring bez odbiorcy. System wysyła alarmy na adres, którego nikt nie czyta od dwóch lat.
Rezultat prac
- Działające usługiuruchomione według uzgodnionych kryteriów odbioru
- Lista dostępówbez haseł przesyłanych w dokumentacji otwartym tekstem
- Opis zależnościporty, domeny, certyfikaty, usługi i punkty krytyczne
- Kopie konfiguracjipliki ustawień w repozytorium albo archiwum przekazanym klientowi
- Plan utrzymaniaaktualizacje, backup, monitoring i działania po alarmie
- Lista ryzykelementy wymagające decyzji, testów albo dalszej modernizacji
Granica usługi
Infrastruktura pozostaje po stronie klienta
Doradzamy przy doborze serwera, operatora lub kolokacji, ale nie sprzedajemy dzierżawy ani hostingu pod marką Trylobit. Umowę na sprzęt, VPS lub centrum danych zawiera klient. Dzięki temu rekomendacja nie zależy od marży na konkretnym dostawcy.
Poza zakresem zostaje też programowanie aplikacji. Przygotujemy dla niej środowisko, uzgodnimy sposób wydania i pomożemy przy pierwszym wgraniu, natomiast za sam kod odpowiada Twój zespół lub dostawca oprogramowania.