Przejdź do głównej zawartości

Czym jest rekord PTR i dlaczego nie można ustawić go samodzielnie?

· 2 min aby przeczytać
Customer Care Engineer

ptr-record-co-to-jest-i-jak-skonfigurować

Wprowadzenie

Jeśli kiedykolwiek konfigurowałeś serwer pocztowy lub miałeś do czynienia z odwrotną weryfikacją DNS, prawdopodobnie spotkałeś się z rekordami PTR. Ale czym one właściwie są? Dlaczego często nie można samodzielnie skonfigurować rekordów PTR? Przyjrzyjmy się temu bliżej!

Co to jest rekord PTR?

PTR (Pointer) — to typ rekordu DNS, który umożliwia konwersję adresu IP na odpowiadającą mu nazwę domeny. W przeciwieństwie do standardowych rekordów A, które mapują domenę na adres IP, rekordy PTR wskazują, do jakiej domeny przypisany jest dany adres IP.

Jak działa rekord PTR?

Gdy serwer odbiera połączenie przychodzące, może zapytać odwrotny DNS (rDNS) o adres IP nadawcy. Jeśli rekord PTR jest skonfigurowany, otrzyma odpowiednią nazwę domeny. Jest to ważne dla:

  • Konfigurowania serwerów pocztowych (serwery SMTP często wymagają PTR, aby poprawnie wysyłać wiadomości e-mail i nie zostać wrzuconym do spamu);
  • Rozpoznawania adresów IP w logach i zwiększenia bezpieczeństwa;
  • poprawnego działania niektórych usług zależnych od rDNS.

Dlaczego nie mogę samodzielnie skonfigurować rekordu PTR?

Wielu użytkowników, którzy mają dostęp do zarządzania rekordami DNS, oczekuje, że będą w stanie utworzyć rekord PTR, tak jak rekord A lub CNAME. Jednak tu pojawia się kluczowy problem: Rekordy PTR nie są konfigurowane w hostingu DNS, lecz u dostawcy adresu IP (ISP, centrum danych lub dostawcy usług hostingowych).

Główne powody:

  1. Kontrola nad adresem IP – Rekordy PTR należą do właściciela puli adresów IP. Jeśli korzystasz z serwera dedykowanego lub VPS, właścicielem adresu IP jest twój dostawca hostingu, który powinien skonfigurować rekord PTR.
  2. Brak dostępu do zarządzania rDNS – Nawet jeśli masz pełną kontrolę nad DNS swojej domeny, odwrotna strefa DNS (in-addr.arpa) jest zarządzana przez właściciela zakresu IP.
  3. Wymagania dostawcy – Niektórzy dostawcy hostingu pozwalają na konfigurację PTR wyłącznie poprzez zgłoszenie do pomocy technicznej, a nie poprzez panel sterowania.
  4. Dynamiczne adresy IP – Jeśli twój adres IP jest dynamiczny (np. w domowym połączeniu internetowym), twój dostawca prawdopodobnie nie pozwoli ci ustawić własnego rekordu PTR.

Jak skonfigurować rekord PTR?

1. Skontaktuj się z dostawcą

Aby stworzyć lub zmienić rekord PTR, należy skontaktować się z dostawcą hostingu lub ISP, który przypisał ci adres IP. Zwykle robi się to poprzez zgłoszenie do pomocy technicznej.

2. Podaj odpowiednią domenę

Zazwyczaj dostawca wymaga, aby rekord PTR wskazywał na rzeczywistą domenę, która jest już skonfigurowana i rozwiązana w rekordzie A.

3. Sprawdź konfigurację

Po zmianie rekordu PTR warto sprawdzić jego działanie za pomocą poniższej komendy:

Windows:

nslookup 123.123.123.123

Linux i MacOS:

dig -x 123.123.123.123
notatka

Powyższe adresy IP są przykładowe. W celu weryfikacji należy użyć rzeczywistego adresu IP, dla którego zmieniono rekord PTR.

Podsumowanie

Rekord PTR jest kluczowym elementem DNS, zwłaszcza dla serwerów pocztowych. Niemniej jednak, nie można go skonfigurować bez zgody właściciela adresu IP. Jeśli potrzebujesz utworzyć rekord PTR, skontaktuj się ze swoim dostawcą usług hostingowych, aby sprawdzić, czy istnieje możliwość jego konfiguracji. Prawidłowe ustawienie rekordu pomoże uniknąć problemów z dostarczaniem wiadomości e-mail i zwiększy wiarygodność twojego serwera.

Przekierowanie 301: prosty przewodnik po konfiguracji za pomocą htaccess lub nginx

· 2 min aby przeczytać
Customer Care Engineer

jak-skonfigurować-przekierowanie-301-nginx-i-htaccess

Chcesz skutecznie przekierować użytkowników i wyszukiwarki na nowy adres URL? Przekierowanie 301 to twój najlepszy przyjaciel! Pomaga zachować pozycje SEO i uniknąć błędów 404. W tym artykule pokażemy, jak szybko i łatwo skonfigurować przekierowanie 301 w plikach .htaccess i na serwerach nginx.


Czym jest przekierowanie 301 i dlaczego jest potrzebne?

Przekierowanie 301 to stałe przeniesienie z jednego adresu URL na inny. Jest niezbędne, gdy:

  • Zmieniasz adres strony i chcesz zachować dotychczasowe pozycje w wyszukiwarkach.
  • Łączysz kilka adresów URL w jeden.
  • Chcesz uniknąć błędów 404 i utraty ruchu.

Jak skonfigurować przekierowanie 301 w .htaccess (Apache)

  1. Znajdź lub utwórz plik.htaccess

Plik.htaccess zazwyczaj znajduje się w katalogu głównym (roboczym) twojej strony. Jeśli go nie ma, utwórz nowy.

  1. Dodaj następujący kod przekierowania
  • Dla jednego URL:
Redirect 301 /old-page https://yoursite.com/new-page
  • Dla przekierowania całej strony:
RewriteEngine On

RewriteCond %{HTTP_HOST} ^oldsite\.com$ [NC]

RewriteRule ^(.*)$ https://newsite.com/$1 [L,R=301]

Zamień oldsite.com i newsite.com na odpowiednio starą i nową domenę twojej strony. 

  1. Zapisz plik

Zmiany zostaną zastosowane natychmiast.


Jak skonfigurować przekierowanie 301 w Nginx

  1. Otwórz plik konfiguracyjny nginx swojej strony

Połącz się z serwerem przez SSH i otwórz odpowiedni plik w edytorze tekstowym nano:

sudo nano /etc/nginx/sites-available/your-site.com.conf

Zamień yoursite.com na domenę swojej witryny. 

Jeśli nie można znaleźć takiego pliku, można znaleźć lokalizację pliku konfiguracyjnego za pomocą polecenia:

sudo grep -irl name /etc/nginx
  1. Dodaj reguły przekierowania do bloku server
  • Dla jednego URL:
server {

listen 80;

server_name oldsite.com;

return 301 https://newsite.com/new-page;

}
  • Dla przekierowania całej strony:
server {

listen 80;

server_name oldsite.com;

return 301 https://newsite.com$request_uri;

}
  1. Zapisz zmiany i zastosuj je

Zapisz plik za pomocą skrótu klawiaturowego "Ctrl + o" i zamknij edytor nano za pomocą "Ctrl + x". Następnie wprowadź zmiany poleceniem:

sudo systemctl reload nginx

Jak sprawdzić, czy przekierowanie działa?

Po skonfigurowaniu upewnij się, że przekierowanie 301 działa:

  • Otwórz stary URL w przeglądarce.

Przejdź na stary URL i upewnij się, że zostałeś przekierowany na nowy adres.

informacja

Test najlepiej wykonywać w trybie prywatnym przeglądarki, aby uniknąć wpływu pamięci podręcznej na wynik.

  • Skorzystaj z narzędzi online do testowania przekierowań, na przykład Redirect Checker.

HTTP/2 i HTTP/3: czy przyspieszenie jest warte zachodu? Zalety, wady i konfiguracja

· 3 min aby przeczytać
Customer Care Engineer

http2-vs-http3-speed-zalety-wady-konfiguracja

Nowoczesne protokoły HTTP/2 i HTTP/3 mogą znacząco przyspieszyć ładowanie stron, poprawić doświadczenie użytkowników i zwiększyć widoczność w wyszukiwarkach. Nie wszystko jest jednak takie proste: mają one zarówno plusy, jak i minusy. Przyjrzyjmy się, czym są, jakie zalety i wady niosą oraz jak je skonfigurować na swoim serwerze.


Czym są HTTP/2 i HTTP/3?

HTTP/2 to zaktualizowana wersja protokołu HTTP/1.1, która umożliwia równoczesne ładowanie zasobów witryny, a nie pojedynczo. Dzięki temu czas odpowiedzi jest krótszy, a obciążenie serwera mniejsze.

HTTP/3 to jeszcze bardziej zaawansowana wersja, oparta na protokole QUIC działającym na UDP. Umożliwia bardziej stabilne połączenia, szczególnie w trudnych warunkach sieciowych.


Zalety

  1. HTTP/2
  • Jednoczesne pobieranie zasobów strony (multipleksowanie).
  • Zmniejszenie opóźnień dzięki kompresji nagłówków.
  • Oszczędność transferu.
  1. HTTP/3
  • Szybkie nawiązywanie połączeń bez opóźnień.
  • Odporność na utratę pakietów (szczególnie istotne dla internetu mobilnego).
  • Świetna wydajność w niestabilnych sieciach.

Włączenie tych protokołów przyspieszy ładowanie strony, zwiększy jej wygodę dla użytkowników i przyniesie korzyści SEO.


Wady

  1. Kompatybilność
  • Protokoły HTTP/2 i HTTP/3 nie są obsługiwane przez starsze przeglądarki i urządzenia. Na przykład niektóre wersje przeglądarki Internet Explorer i starsze urządzenia z systemem Android nie będą w stanie korzystać z tych protokołów.
  • HTTP/3 korzysta z UDP, które może być blokowane przez niektóre firewalle lub filtry sieciowe.
  1. Złożoność konfiguracji
  • Nieprawidłowa konfiguracja HTTP/2 może obniżyć wydajność. Na przykład, jeśli nie używasz priorytetyzacji strumieni.
  • HTTP/3 wymaga najnowszej wersji Nginx, OpenSSL i obsługi protokołu QUIC, co może być problematyczne na starszych serwerach.
  1. Zasobożerność
  • HTTP/3 wymaga więcej zasobów serwera, zwłaszcza przy dużej liczbie połączeń.
  1. Zależność od HTTPS
  • HTTP/2 działa wyłącznie przez HTTPS, co zwiększa koszty związane z instalacją i utrzymaniem certyfikatów.
  1. HTTP/1.1 a wydajność HTTP/2/3
  • HTTP/2 i HTTP/3 nie wykluczają wsparcia dla HTTP/1.1. Chociaż może to nieznacznie obniżyć wydajność, nie powoduje poważnych problemów, ponieważ HTTP/1.1 jest używane tylko przez klientów, którzy nie obsługują nowszych protokołów.

Jak włączyć HTTP/2 i HTTP/3 w Nginx?

informacja

Jeśli korzystasz z panelu sterowania, takiego jak FASTPANEL, możesz aktywować protokoły HTTP/2 i HTTP/3 w ustawieniach witryny bez ręcznej ingerencji w jej plik konfiguracyjny.  

  1. Sprawdzenie kompatybilności

Połącz się z serwerem przez SSH.

Sprawdź aktualną wersję Nginx:

sudo nginx -v

Aby włączyć HTTP/3, potrzebna jest wersja 1.25.0 lub wyższa.

Sprawdź wersję OpenSSL:

openssl version

Do pracy z HTTP/3 wymagany jest OpenSSL w wersji 3.0.0 lub wyższej, ponieważ wcześniejsze wersje nie obsługują QUIC.

Ponadto przed wprowadzeniem jakichkolwiek zmian należy upewnić się, że konfiguracja nginx jest wolna od błędów:

nginx -t

Jeśli wszystko jest w porządku (wiadomości typu warn można zignorować), zobaczysz komunikaty:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

2.  Konfiguracja HTTP/2

Otwórz plik konfiguracyjny witryny w edytorze tekstowym:

sudo nano /etc/nginx/sites-available/your-site.conf

Dodaj do linii listen 443 ssl dyrektywę http2 i dodaj linię http2 on do bloku server, aby uzyskać coś takiego jak poniżej:

server {

listen 443 ssl http2;

server_name example.com;



ssl_certificate /path/to/fullchain.pem;

ssl_certificate_key /path/to/privkey.pem;



http2 on;


rest of your config file

}
warning

Pamiętaj, że dla protokołów HTTPS i HTTP/2 wymagany jest ważny certyfikat SSL.

Zrestartuj serwer WWW, aby zastosować zmiany:

systemctl restart nginx
  1. Konfiguracja HTTP/3

Podobnie jak w poprzednim kroku, otwórz plik konfiguracyjny swojej witryny i zmodyfikuj go w następujący sposób:

server {

listen 443 ssl http2;

listen 443 quic reuseport;

server_name example.com;



ssl_certificate /path/to/fullchain.pem;

ssl_certificate_key /path/to/privkey.pem;



http2 on;



ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3;

add_header Alt-Svc 'h3=":443"; ma=86400';


rest of your config file

}

Gdzie:

  • listen 443 quic reuseport; — aktywuje HTTP/3 (QUIC) na porcie 443 i poprawia wydajność przy dużej liczbie połączeń.
  • ssl_protocols TLSv1.1 TLSv1.2 TLSv1.3; — określa wersje protokołu TLS.  Dla większego bezpieczeństwa zaleca się stosowanie tylko TLSv1.2 i TLSv1.3.
  • add_header Alt-Svc 'h3=":443"; ma=86400'; — informuje przeglądarki, że serwer obsługuje HTTP/3, i przechowuje tę informację przez 24 godziny.
warning

Parametr reuseport można zastosować tylko raz w konfiguracji serwera Nginx. Próba wielokrotnego użycia go w różnych dyrektywach listen spowoduje konflikty i błędy w działaniu serwera.

Po wprowadzeniu zmian należy przeprowadzić dodatkową weryfikację, aby sprawdzić zgodność wersji Nginx z użytymi dyrektywami oraz wykryć ewentualne błędy składni, używając polecenia:

nginx -t

Jeśli wszystko jest w porządku (wiadomości typu warn można zignorować), zobaczysz komunikaty:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Zrestartuj serwer Nginx, aby zastosować zmiany:

systemctl restart nginx

Podsumowanie

HTTP/2 i HTTP/3 to krok w przyszłość, który przyspiesza ładowanie stron, poprawia SEO i zwiększa komfort użytkowników. Pamiętaj jednak o kompatybilności, zasobożerności i ewentualnych trudnościach w konfiguracji.

Jeśli większość twoich użytkowników korzysta z nowoczesnych przeglądarek, rozpocznij od wdrożenia HTTP/2. HTTP/3 włącz, gdy będziesz gotów zaktualizować oprogramowanie serwera i upewnisz się, że twoja infrastruktura wspiera ten protokół.

Jeśli wolisz nie konfigurować tych protokołów ręcznie, możesz wybrać serwer z bezpłatnym panelem FASTPANEL, gdzie włączenie obsługi protokołów HTTP/2 i HTTP/3 dla Twojej witryny jest proste i wygodne.

HDD, SSD czy NVMe: jak wybrać rodzaj dysku podczas wynajmu serwera

· 2 min aby przeczytać
Customer Care Engineer

hdd-vs-ssd-vs-nvme-opcje-pamięci-dla-twojego-serwera

Podczas wynajmu serwera wybór dysku ma kluczowe znaczenie dla wydajności projektów, niezawodności przechowywania danych i kosztów wynajmu. Warto zrozumieć różnice między HDD, SSD i NVMe, aby dokonać najlepszego wyboru do swoich potrzeb.

HDD: trwałość i stabilność

Dyski twarde (HDD) to tradycyjne nośniki, które od lat stosuje się w centrach danych do przechowywania dużych ilości danych. Choć nie są tak szybkie jak SSD, zapewniają długą żywotność przy umiarkowanym obciążeniu.

HDD zazwyczaj mają żywotność wynoszącą od 20 000 do 25 000 godzin. W praktyce wiele HDD w centrach danych funkcjonuje przez około 3-5 lat, w zależności od stopnia intensywności użytkowania.

Dyski HDD charakteryzują się dużą wrażliwością na nagłe przerwy w zasilaniu, ponieważ zawierają ruchome części (np. głowice zapisu), co może prowadzić do uszkodzenia danych. W przypadku nieoczekiwanego wyłączenia ryzyko utraty danych jest większe niż w przypadku SSD.

Zalety HDD:

  • Trwałość: Możliwość pracy przez długi czas przy umiarkowanym obciążeniu.
  • Koszt: Tańsze od SSD i NVMe w przeliczeniu na 1 TB danych.
  • Duża pojemność: Świetne do przechowywania dużych ilości danych, gdy szybkość dostępu nie jest priorytetem.

SSD: szybciej, ale z ograniczonymi zasobami

Dyski półprzewodnikowe (SSD) to szybkie i niezawodne nośniki danych, idealne dla serwerów, gdzie kluczowa jest wydajność. Jednak żywotność SSD, mierzona liczbą cykli zapisu, jest ograniczona. Dla SATA SSD wynosi ona 300–500 pełnych cykli zapisu, co przy umiarkowanym użytkowaniu pozwala teoretycznie na pracę przez około 5 lat. Przy intensywnym zapisie, typowym dla wielu witryn internetowych, żywotność SSD znacznie się skraca.

Dyski SSD są bardziej odporne na nagłe przerwy w zasilaniu, ponieważ nie posiadają ruchomych części. Jednak intensywny zapis może szybko wyczerpać ich zasoby, zwłaszcza w przypadku tańszych modeli.

Zalety SSD:

  • Wysoka prędkość: Idealne dla serwerów wymagających dużej wydajności.
  • Odporność na nagłe przerwy w zasilaniu: Bardziej wytrzymałe na uszkodzenia sprzętowe przy niespodziewanym wyłączeniu.

NVMe: maksymalna szybkość, ale mniejsza trwałość

NVMe (Non-Volatile Memory Express) to nowoczesna alternatywa dla SATA SSD, charakteryzująca się jeszcze większą wydajnością. Oferują znacznie wyższe prędkości odczytu i zapisu, co czyni je doskonałym wyborem dla serwerów przetwarzających ogromne ilości danych lub realizujących złożone operacje obliczeniowe.

Jednak żywotność NVMe jest krótsza w porównaniu z dyskami SATA SSD. Wysokie prędkości zapisu sprawiają, że nośniki NVMe zużywają się szybciej, szczególnie w warunkach stałego obciążenia.

Chociaż, podobnie jak SSD, NVMe są mniej podatne na uszkodzenia podczas nagłych przerw w zasilaniu, ich trwałość jest mniejsza niż w przypadku HDD ze względu na intensywną eksploatację.

Zalety NVMe:

  • Maksymalna prędkość: Idealne rozwiązanie dla serwerów obsługujących duże ilości danych.
  • Wysoka wydajność: Odpowiedni do zadań wymagających dużego obciążenia.

Jaki typ dysku wybrać?

  • HDD: jeśli priorytetem są trwałość i niskie koszty, a intensywny zapis danych nie jest kluczowy, HDD będzie idealnym wyborem. To tańsze rozwiązanie, które zapewnia stabilną wydajność przez wiele lat.
  • SSD: gdy zależy ci na szybkim zapisie danych i umiarkowanym obciążeniu, postaw na dysk SSD. Oferuje on dobrą prędkość przy niższym zużyciu niż NVMe.
  • NVMe: dla serwerów o bardzo wysokich wymaganiach dotyczących prędkości idealnym wyborem będzie NVMe. Należy jednak pamiętać o krótszej żywotności i wyższej cenie.

Wybór dysku zależy od twoich potrzeb. Jeśli priorytetem są długowieczność i cena, zdecyduj się na HDD. Jeśli liczy się wysoka wydajność, najlepszym rozwiązaniem będzie SSD lub NVMe.

Ponadto oferujemy serwery dostosowane do Twoich potrzeb i budżetu, zapewniając idealne dopasowanie do każdego wymagania.

Certyfikaty SSL: jaka jest różnica między płatnymi a bezpłatnymi i który z nich wybrać?

· 3 min aby przeczytać
Customer Care Engineer

certyfikaty-ssl-płatne-czy-bezpłatne

Certyfikat SSL — dziś niezbędne narzędzie dla każdej strony internetowej. Zapewnia bezpieczeństwo transmisji danych między serwerem a użytkownikiem. Istnieją różne typy certyfikatów, w tym darmowe (najczęściej oferowane przez dostawców takich jak Let's Encrypt i ZeroSSL) oraz płatne. Przyjrzyjmy się, czym się różnią i kiedy warto zdecydować się na certyfikat płatny.

Czym jest darmowy certyfikat SSL od Let's Encrypt lub ZeroSSL?

Let's Encrypt — darmowy, zautomatyzowany serwis, który oferuje certyfikaty SSL dla stron internetowych. Jest idealny dla prostych projektów, takich jak blogi czy małe sklepy.

ZeroSSL — podobne narzędzie, które również oferuje darmowe certyfikaty, ale z dodatkowymi opcjami.

Zalety darmowych certyfikatów:

  1. Bezpłatność: To ich największy plus. Let's Encrypt i ZeroSSL dostarczają certyfikaty SSL całkowicie za darmo, co czyni je świetnym rozwiązaniem dla większości użytkowników, którzy nie potrzebują zaawansowanego poziomu zaufania.
  2. Wsparcie dla współczesnych przeglądarek: Certyfikaty Let's Encrypt i ZeroSSL są akceptowane przez wszystkie nowoczesne przeglądarki. Dzięki temu użytkownicy nie zobaczą ostrzeżeń o braku zabezpieczeń przy odwiedzaniu strony.
  3. Certyfikaty typu Wildcard: Let's Encrypt i ZeroSSL obsługują certyfikaty typu Wildcard, które pozwalają chronić wszystkie subdomeny pojedynczej domeny.

Wady:

  1. Ograniczone wsparcie: W razie problemów z certyfikatem użytkownik musi je rozwiązywać samodzielnie, ponieważ darmowe certyfikaty nie oferują wsparcia technicznego.
  2. Krótki okres ważności: Certyfikaty Let's Encrypt i ZeroSSL są ważne tylko przez 90 dni. Wymagają ustawienia automatycznego odnawiania, co zazwyczaj wymaga znajomości terminala i podstawowych zasad działania serwerów.
  3. Poziom zaufania i niezawodności: W przeciwieństwie do płatnych certyfikatów, Let's Encrypt i ZeroSSL nie oferują rozszerzonej walidacji (EV), co może ograniczać poziom zaufania strony u niektórych użytkowników i wyszukiwarek.

Różnice między ZeroSSL a Let's Encrypt:

  • ZeroSSL oferuje bardziej przyjazny interfejs użytkownika oraz płatne certyfikaty z dodatkowymi funkcjami (np. przedłużenie ważności do 1 roku).
  • Let's Encrypt jest całkowicie darmowy, ale wymaga skonfigurowania automatyzacji odnawiania.

Czym są płatne certyfikaty SSL?

Płatne certyfikaty SSL są oferowane przez wielu dostawców, takich jak DigiCert, GlobalSign, Comodo i inni. Zawierają one dodatkowe funkcje i udogodnienia, które sprawdzają się w przypadku bardziej wymagających projektów, przetwarzających wrażliwe dane osobowe.

Zalety płatnych certyfikatów:

  1. Długoterminowe rozwiązanie: Płatne certyfikaty są zazwyczaj ważne od 1 do 3 lat. Jest to wygodne rozwiązanie, jeśli nie chcesz często odnawiać swojego certyfikatu i wolisz rozwiązanie długoterminowe.
  2. Rozszerzona walidacja (EV SSL): Certyfikaty płatne często oferują rozszerzoną weryfikację, która wymaga dokładniejszego sprawdzenia firmy kupującej certyfikat. Dzięki temu zwiększa się poziom zaufania użytkowników do strony.
  3. Wsparcie techniczne i gwarancje: W przypadku płatnych certyfikatów użytkownik otrzymuje wsparcie techniczne oraz ubezpieczenie na wypadek problemów z certyfikatem. Jeśli dane klientów zostaną skradzione z powodu błędów w certyfikacie, można liczyć na rekompensatę. 
  4. Lepsza optymalizacja SEO: Wiele wyszukiwarek promuje w wynikach wyszukiwania strony z certyfikatami SSL. Płatne certyfikaty mogą dodatkowo zwiększyć wiarygodność strony w oczach wyszukiwarek, co wspiera SEO.

Kiedy wybrać płatny certyfikat SSL?

  1. Jeśli twoja strona internetowa obsługuje poufne informacje lub płatności: Płatne certyfikaty z rozszerzoną walidacją (EV) są szczególnie przydatne w przypadku witryn obsługujących dane osobowe lub transakcje finansowe. Pomagają one budować zaufanie użytkowników.
  2. W przypadku projektów obejmujących wiele stron: Płatne certyfikaty mogą chronić wiele witryn lub subdomen, co jest idealnym rozwiązaniem dla witryn korporacyjnych lub dużych witryn komercyjnych.
  3. Jeśli potrzebujesz dodatkowego wsparcia: Dzięki płatnym certyfikatom można uzyskać pomoc od zespołu wsparcia, co jest ważne dla firm, które nie chcą samodzielnie zajmować się kwestiami technicznymi.
  4. Aby usprawnić SEO: Płatne certyfikaty mogą poprawić pozycje w wyszukiwarkach.
  5. Do długotrwałego użytku: Płatne certyfikaty działają dłużej i nie trzeba ich często odnawiać, co jest wygodne w przypadku dużych stron i projektów.

Podsumowanie

Certyfikaty darmowe od Let's Encrypt lub ZeroSSL stanowią doskonałe rozwiązanie dla większości małych stron internetowych i blogów. Zapewniają podstawowy poziom bezpieczeństwa i są idealne dla witryn, które nie potrzebują zaawansowanej weryfikacji ani dodatkowych funkcji.

Jeśli jednak twoja strona wymaga bardziej zaawansowanych opcji, takich jak ochrona wielu domen czy rozszerzone wsparcie techniczne, warto rozważyć wybór płatnego certyfikatu. W takiej sytuacji zapraszamy do zapoznania się z naszymi dostępnymi ofertami.

Podstawy pracy z journald

· 2 min aby przeczytać
Customer Care Engineer

przeczytaj-dzienniki-i-dowiedz-się-jak-je-wyczyścić

Journald — system rejestrowania używany w nowoczesnych systemach operacyjnych opartych na Linuksie do rejestrowania zdarzeń systemowych. Jego zadaniem jest zbieranie informacji o działaniu usług, aplikacji oraz procesów systemowych, co ułatwia administratorom monitorowanie stanu systemu i diagnozowanie problemów.  

W odróżnieniu od tradycyjnych dzienników tekstowych, journald zapisuje dane w formacie binarnym. Pozwala to na przechowywanie logów w bardziej kompaktowej formie i efektywne zarządzanie nimi, ale jednocześnie takich dzienników nie można po prostu otworzyć w edytorze tekstu. Do ich przeglądania i analizy potrzebne są specjalne narzędzia.

W tym artykule omówimy, jak przeglądać dzienniki zapisane przez journald oraz jak je wyczyścić, aby odzyskać miejsce na dysku.


Jak przeglądać logi journal?

Do odczytu logów użyj polecenia journalctl:

  • Wszystkie logi:
sudo journalctl
  • Logi od ostatniego uruchomienia:
sudo journalctl -b
  • Logi konkretnej usługi:
sudo journalctl -u nginx
  • Logi z określonego dnia:
sudo journalctl --since "2024-11-01" --until "2024-11-02"
  • Wyświetlanie ostatnich n-wpisów (np. ostatnich 100):
sudo journalctl -n 100
  • Filtrowanie według poziomów ważności (np. dla błędów):
sudo journalctl -p err
  • Podgląd logów w odwrotnej kolejności, zaczynając od najnowszych (przydatne, gdy chcesz szybko zobaczyć najnowsze wpisy dziennika):
sudo journalctl -r
  • Podgląd logów w czasie rzeczywistym (analogicznie do tail -f):
sudo journalctl -f

Te opcje można ze sobą łączyć. Na przykład, wyświetl wszystkie błędy usługi nginx dla 10 listopada 2024 r., pokazując tylko 10 ostatnich wpisów:

sudo journalctl -u nginx --since "2024-11-10" --until "2024-11-10 23:59:59" -n 10

Jak wyczyścić journal

Jeśli logi zajmują zbyt dużo miejsca, można je wyczyścić za pomocą następujących poleceń:

  • Czyszczenie starych logów (np. starszych niż 7 dni):
sudo journalctl --vacuum-time=7d
  • Czyszczenie logów, które przekraczają określoną wielkość (np. 1 GB):
sudo journalctl --vacuum-size=1G
  • Całkowite usunięcie wszystkich dzienników:
sudo journalctl --vacuum-files=0

Jak zmniejszyć rozmiar journal?

Domyślnie Journald może zajmować dużo miejsca na dysku, jeśli logi nie są ograniczone. Aby ograniczyć maksymalny rozmiar dziennika, otwórz plik konfiguracyjny journald.conf:

sudo nano /etc/systemd/journald.conf

W tym pliku możesz skonfigurować następujące parametry:

  • SystemMaxUse — maksymalny rozmiar dla wszystkich dzienników:
SystemMaxUse=1G
  • RuntimeMaxUse — maksymalny rozmiar dla tymczasowych dzienników:
RuntimeMaxUse=500M
  • MaxRetentionSec — maksymalny czas przechowywania dzienników:
MaxRetentionSec=1month

Ustaw odpowiednie wartości dla twojego systemu i potrzeb, a następnie zapisz plik za pomocą kombinacji klawiszy Ctrl + O i zamknij edytor klawiszami Ctrl + X. 

Aby zastosować zmiany, uruchom ponownie usługę journald:

sudo systemctl restart systemd-journald

Można także skonfigurować przechowywanie dzienników w pamięci RAM lub całkowicie je wyłączyć. Obie opcje jednak nie są zalecane w środowisku produkcyjnym, ponieważ dziennik zawiera kluczowe informacje diagnostyczne. Dbanie o jego aktualność i poprawność ma istotne znaczenie dla prawidłowego monitorowania oraz diagnozowania procesów na serwerze.

Jeśli nadal chcesz włączyć przechowywanie dziennika w pamięci RAM, ustaw następującą wartość w pliku /etc/systemd/journald.conf:

Storage=volatile

Aby całkowicie wyłączyć rejestrowanie, ustaw:

Storage=none

Nie marnuj zasobów swojego serwera: blokuj niechciane boty za pomocą Nginx

· 3 min aby przeczytać
Customer Care Engineer

blokowanie-niechcianych-botów-za-pomocą-nginx

Boty wyszukiwarek (crawlers) to specjalne programy, które indeksują strony w Internecie. Są one potrzebne wyszukiwarkom do znajdowania, indeksowania i wyświetlania stron w wynikach wyszukiwania. Jednak nie wszystkie boty są pożyteczne!

Niektóre niechciane boty mogą:

  • Zbierać dane bez twojej zgody.
  • Nadmiernie obciążać serwer, powodując spowolnienia.
  • Szukać luk w zabezpieczeniach twojej witryny.

Jeśli chcesz ochronić swoją witrynę przed takimi botami, czas skonfigurować Nginx! Pokażemy ci, jak szybko i skutecznie je zablokować, wykorzystując odpowiednie ustawienia.


Po co konfigurować Nginx, jeśli istnieje plik robots.txt?

Plik robots.txt to narzędzie umożliwiające kontrolowanie zachowania botów wyszukiwarek. Pozwala określić, które strony nie powinny być przez nie indeksowane. Korzystanie z tego pliku jest bardzo proste, wystarczy w katalogu głównym witryny utworzyć plik typu:

User-agent: BadBot  

Disallow: /  

Jest jednak istotny problem: zawartość pliku robots.txt ma jedynie charakter zalecenia, a nie obowiązującej reguły. Rzetelne boty respektują ten plik, ale wiele z nich po prostu go ignoruje.

Konfiguracja z Nginx, w przeciwieństwie do robots.txt, pozwala fizycznie zablokować dostęp niechcianym botom, co gwarantuje rezultaty w 100% przypadków. 


Jak Nginx blokuje niechciane boty: użycie odpowiedzi 444

W przeciwieństwie do pliku robots.txt, który jedynie sugeruje botom, jak się zachowywać, Nginx umożliwia fizyczne blokowanie ich dostępu. Jednym ze sposobów na osiągnięcie tego celu jest wykorzystanie specjalnej odpowiedzi serwera o kodzie 444.

Kod odpowiedzi 444 — to wewnętrzny mechanizm Nginx, który zamyka połączenie z klientem bez wysyłania żadnej odpowiedzi. Jest to skuteczna metoda ignorowania niechcianych zapytań i minimalizowania obciążenia serwera.


Konfiguracja blokady

Krok 1: Jak rozpoznać niechciane boty?

Niechciane boty można zidentyfikować na podstawie ich User-Agent, czyli parametru przesyłanego przez każdego klienta odwiedzającego stronę. Dla przykładu, niektóre z nich wyglądają tak:

    AhrefsBot     SemrushBot     MJ12bot

Aby znaleźć podejrzane User-Agent w logach dostępowych Nginx (jeśli twoja witryna korzysta z PHP-FPM), możesz użyć komendy:

sudo grep -i bot /var/log/nginx/access.log

W przypadku logów Apache (jeśli witryna używa modułu Apache lub FastCGI jako interpretera PHP), użyj:

  • Dla Ubuntu/Debian:
sudo grep -i bot /var/log/apache2/access.log
  • Dla CentOS/AlmaLinux/RockyLinux:
sudo grep -i bot /var/log/httpd/access.log

Jeśli korzystasz z panelu sterowania, takiego jak FASTPANEL, każda witryna będzie miała swój własny oddzielny plik logów. Można je analizować osobno lub wszystkie naraz za pomocą polecenia typu:

  • Jeśli witryna korzysta z modułu Apache lub FastCGI jako obsługi PHP:
sudo cat /var/www/*/data/logs/*-backend.access.log |  grep -i bot | tail -500
  • Jeśli twoja strona korzysta z PHP-FPM:
sudo cat /var/www/*/data/logs/*-frontend.access.log |  grep -i bot | tail -500

Powyższe polecenia wyświetlą 500 ostatnich zapytań do wszystkich twoich stron, gdzie parametr User-Agent zawiera słowo bot. Przykładowy wpis z logów może wyglądać tak:

IP - [03/Nov/2022:10:25:52 +0300] "GET link HTTP/1.0" 301 811 "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; [email protected])"

lub

IP - [24/Oct/2022:17:32:37 +0300] "GET link HTTP/1.0" 404 469 "-" "Mozilla/5.0 (compatible; BLEXBot/1.0; +http://webmeup-crawler.com/)"

User-Agent bota znajduje się pomiędzy fragmentami “compatible;” i “/numer.wersji“ w nawiasach. Tak więc w powyższych przykładach User-agent to „BLEXBot” i „DotBot”.

Przeanalizuj uzyskane informacje i zapisz User-agent najbardziej aktywnych botów w celu dalszych ustawień blokowania. 

Krok 2: Tworzenie pliku blokady botów

  1. Połącz się z serwerem przez SSH.
  2. Przed przystąpieniem do pracy upewnij się, że w bieżącej konfiguracji Nginx nie ma żadnych błędów:
nginx -t

Jeśli wszystko jest w porządku, otrzymasz odpowiedź:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Jeśli w danych wyjściowych występują błędy, zapoznaj się z ich zawartością i popraw je w pliku, na który wskazują.

  1. Utwórz osobny plik z listą botów do zablokowania:
sudo nano /etc/nginx/conf.d/block_bots.conf

Dodaj następujący kod do pliku:


    map $http_user_agent $block_bot {

        default 0;

        ~*AhrefsBot 1;

        ~*SemrushBot 1;

        ~*MJ12bot 1;

    }



    server {

        if ($block_bot) {

            return 444;

        }
    }

Tutaj tworzymy mapę, która określa, który bot powinien zostać zablokowany.

Analogicznie, wymień User-agent botów, które chcesz zablokować. Każdy bot powinien być wymieniony w nowym wierszu, a na końcu wiersza należy podać znak; jako separator.

Po zakończeniu tworzenia listy naciśnij skrót „Ctrl + O”, aby zapisać plik, a następnie „Ctrl + X”, aby wyjść z edytora nano. 

Krok 3: Zastosowanie zmian

Po wprowadzeniu zmian w konfiguracji należy sprawdzić poprawność konfiguracji Nginx, aby upewnić się, że nie zawiera błędów składniowych:

sudo nginx -t

Jeśli wszystko jest w porządku, otrzymasz odpowiedź:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok

nginx: configuration file /etc/nginx/nginx.conf test is successful

Jeśli w danych wyjściowych występują błędy, zapoznaj się z ich zawartością i popraw je w pliku, na który wskazują.

Następnie załaduj ponownie konfigurację Nginx, aby zastosować wprowadzone zmiany:

sudo systemctl reload nginx

Jeśli w przyszłości będziesz chciał dodać nowych botów do pliku block_bots.conf,musisz każdorazowo powtórzyć powyższy krok. 


Podsumowanie

Teraz wiesz, jak łatwo zablokować niechciane boty na swoim serwerze za pomocą Nginx!  Monitoruj logi i w razie potrzeby dodawaj nowe boty do pliku block_bots.conf.

Pamiętaj, aby blokować tylko szkodliwe boty, aby nie zaszkodzić indeksowaniu swojej witryny w użytecznych wyszukiwarkach, takich jak Google czy Bing.

Jak skonfigurować logrotate, aby automatycznie archiwizować logi i oszczędzać miejsce na serwerze

· 2 min aby przeczytać
Customer Care Engineer

Zarządzanie logami jest kluczowym aspektem administracji serwerem. Logi, które nie są regularnie rotowane, mogą szybko zapełnić dysk, spowalniając działanie serwera i powodując nieprzewidywalne błędy. W tym artykule wyjaśnimy, jak skonfigurować i używać logrotate do automatycznego czyszczenia i rotacji logów na serwerze.


Czym jest logrotate i dlaczego warto go używać?

Logrotate to narzędzie przeznaczone do automatycznego zarządzania logami. Pomaga w:

  • Czyszczeniu starych logów — automatycznie usuwa lub archiwizuje przestarzałe logi.
  • Oszczędzaniu miejsca na dysku — kompresuje i usuwa niepotrzebne logi.

Rotacja logów pozwala uniknąć sytuacji, w której logi gromadzą się, prowadząc do przepełnienia dysku, co może spowodować awarie systemu i utratę danych. Logrotate automatycznie archiwizuje stare logi i zwalnia miejsce na nowe dane.


Jak działa logrotate?

Kiedy logrotate jest aktywowany, automatycznie wykonuje następujące kroki:

  1. Rotacja logów — jest to proces, w którym stare logi są przemianowywane i zapisywane, a w ich miejsce tworzone są nowe pliki.
  2. Kompresja — stare logi mogą zostać skompresowane do formatu .gz, aby zaoszczędzić miejsce.
  3. Usuwanie — przestarzałe logi mogą zostać usunięte, jeśli nie są już potrzebne.

Przykład: plik dziennika o nazwie access.log może zostać przemianowany na access.log.1, następnie skompresowany do access.log.1.gz, a po upływie określonego czasu przechowywania, usunięty.


Jak skonfigurować logrotate?

1. Instalacja logrotate

Logrotate jest zwykle domyślnie instalowany na większości systemów Linux. Aby sprawdzić czy faktycznie już go masz, wpisz:

sudo logrotate --version

Jeśli logrotate nie jest zainstalowany, użyj menedżera pakietów.

  • Dla Debiana/Ubuntu użyj:
sudo apt update && sudo apt install logrotate
  • Dla CentOS/RockyLinux/AlmaLinux:
sudo yum install logrotate

2. Konfiguracja logrotate

Konfiguracja logrotate jest zwykle przechowywana w /etc/logrotate.conf. Plik ten określa ogólne parametry dla wszystkich logów na serwerze. Aby skonfigurować rotację poszczególnych logów, można utworzyć oddzielne pliki konfiguracyjne dla różnych serwisów w folderze /etc/logrotate.d/.

Przykład standardowej konfiguracji dla Nginx:

/var/log/nginx/*.log {
daily          # Logs are rotated daily
missingok      # Do not display an error if the log is missing
rotate 7       # Keep 7 archived files
compress       # Compress old logs
delaycompress  # Delay compression until the next rotation
notifempty     # Do not rotate empty files
create 0640 www-data adm  # Create new logs with specific permissions
}

3. Ważne parametry konfiguracyjne

  • daily/weekly/monthly — jak często log będzie rotowany (codziennie, co tydzień lub co miesiąc).
  • rotate [N] — liczba archiwów logów, które mają być przechowywane.
  • compress — kompresja archiwów logów (zwykle w formacie .gz).
  • missingok — brak logów nie powoduje pokazania błędu.
  • notifempty — nie rotuj pustych plików.
  • create — stwórz nowe logi z uprawnieniami.

4. Uruchamianie logrotate

Logrotate jest zwykle uruchamiany automatycznie za pomocą cron. Można jednak uruchomić go ręcznie, jeśli trzeba sprawdzić konfigurację lub wykonać rotację teraz:

sudo logrotate -f /etc/logrotate.conf

5. Sprawdzanie, czy logrotate działa

Aby upewnić się, że logrotate działa poprawnie, sprawdź ostatnie wpisy w logu:

sudo journalctl -u logrotate -n 10

Logi zajmują dużo miejsca na serwerze. Jak to naprawić?

· 2 min aby przeczytać
Customer Care Engineer
informacja

Większość logów jest przechowywana w katalogu /var/log, ale mogą również występować w innych miejscach. Zasady opisane poniżej dotyczą wszystkich plików *.log bez względu na ich lokalizację. 

Logi to pliki, które przechowują informacje o zdarzeniach na serwerze: aktywności aplikacji i systemu operacyjnego, różnych błędach, żądaniach użytkowników do stron itp. W miarę upływu czasu logi mogą zajmować dużo miejsca, szczególnie przy dużym ruchu na stronie lub błędach oprogramowania. 

Ważną cechą logów jest to, że w zdecydowanej większości przypadków ich usunięcie może prowadzić do nieprawidłowego działania programu, który je zapisuje, czy to serwera WWW, czy samego systemu operacyjnego. 

Dodatkowo, pliki te często zawierają istotne informacje diagnostyczne, które mogą pomóc w wykrywaniu awarii oprogramowania serwera i zapobiec poważniejszym problemom. Dlatego należy obchodzić się z nimi ostrożnie i świadomie.


Jak znaleźć logi, które można wyczyścić

Użyj ncdu do znalezienia największych logów na serwerze. Jeśli jakiś log wydaje się niepokojąco duży, sprawdź jego ostatnie wpisy:

sudo tail /path/to/log

Jeśli nie ma żadnych anomalii, sprawdź jego początek, aby upewnić się, że log stał się tak duży po prostu z upływem czasu (zwróć uwagę na datę utworzenia pierwszych wpisów):

sudo head /path/to/log

Następnie można przejść do czyszczenia.

informacja

Jeśli nie masz pewności, dlaczego plik dziennika jest tak duży, zapisz jego kopię i skontaktuj się z działem wsparcia technicznego dostawcy hostingu w celu uzyskania wyjaśnień.


Jak bezpiecznie wyczyścić logi

Użyj polecenia truncate, aby wyczyścić zawartość pliku bez jego usuwania:

sudo truncate -s 0 /var/log/nginx/error.log

Osobno należy zwrócić uwagę na pliki, które są logami pomimo braku rozszerzenia *.log:

  • /var/log/btmp
  • /var/log/syslog
  • /var/log/messeges
  • /var/log/secure
  • /var/log/maillog

Wszystkie te pliki można również bezpiecznie wyczyścić za pomocą polecenia truncate.

Wyjątkiem jest specjalny log, który znajduje się w katalogu /var/log/journal. O pracy z nim dowiesz się więcej z tego artykułu.   


Jak zapobiec zwiększaniu się rozmiaru logów

Analizując logi, mogłeś zauważyć, że niektóre z nich mają nazwy w formacie:

  • syslog.1
  • yoursite.access.log.1

Pojawiają się one, gdy stosowany jest proces rotacji logów, na przykład za pomocą programu logrotate. Podczas rotacji stare pliki mogą zostać usunięte lub skompresowane, co pozwala zaoszczędzić miejsce na dysku.

Więcej informacji na temat konfiguracji tego mechanizmu znajdziesz tutaj.

Jak znaleźć i usunąć pliki zajmujące dużo miejsca na serwerze

· 2 min aby przeczytać
Customer Care Engineer

Brakuje miejsca na serwerze? Może to prowadzić do awarii stron internetowych i baz danych. Aby zwolnić przestrzeń, należy znaleźć i usunąć pliki zajmujące najwięcej miejsca. W tym artykule wyjaśnimy, jak zrobić to szybko za pomocą narzędzia ncdu oraz jak bezpiecznie czyścić logi.


Krok 1: Instalacja i uruchomienie ncdu

ncdu — wygodne narzędzie do analizy wykorzystania przestrzeni na dysku. Wyświetla wszystkie foldery i pliki posortowane według rozmiaru w czytelnym interfejsie tekstowym.

Aby korzystać z tego programu, należy połączyć się z serwerem przez SSH.  

Instalacja

  • Debian/Ubuntu:
sudo apt update && sudo apt install ncdu
  • CentOS/AlmaLinux/RockyLinux:
sudo yum install ncdu

Uruchomienie analizy dysku

  • Aby przeskanować katalog główny /, uruchom polecenie:
sudo ncdu -x /

Opcja -x w ncdu ogranicza skanowanie do pojedynczego systemu plików, pomijając zamontowane wirtualne katalogi (np./proc, /dev, /sys) oraz inne woluminy podłączone przez oddzielne punkty montowania (na przykład dyski sieciowe lub zewnętrzne).

  • Aby przeskanować konkretny katalog:
sudo ncdu /path/to/directory

Przykładowo, aby przeskanować tylko katalog z logami, uruchom polecenie:

sudo ncdu /var/log

Krok 2: Analiza i usuwanie niepotrzebnych plików

Po uruchomieniu ncdu zobaczysz listę plików i folderów posortowanych według rozmiaru. Nawigacja jest prosta:

  • Strzałki ↑/↓ — poruszanie się po liście.
  • Klawisz Enter — wejście do katalogu.
  • Klawisz D — usunięcie wybranego pliku lub folderu.

Ncdu inctruction 1

ważne

Zachowaj ostrożność przy usuwaniu plików systemowych. Usuwaj tylko te pliki, których przeznaczenie znasz.

Kiedy usuwasz pliki w Linuksie, są one usuwane bezpowrotnie! Można je przywrócić wyłącznie z kopii zapasowej, o ile taka istnieje.

Bezpieczniej będzie sporządzić listę plików i katalogów zajmujących dużo miejsca (zaznaczyć je w ncdu i skopiować do notatnika na lokalnym komputerze), a następnie przeanalizować każdy z osobna i usunąć je z wiersza poleceń.

Aby usunąć plik, uruchom polecenie:

sudo rm -f /path/to/file

A żeby usunąć katalog:

sudo rm -rf /path/to/directory

Oto lista głównych katalogów, które zwykle zajmują dużo miejsca:

  1. /var/www/ - katalog z twoimi stronami

Najwięcej miejsca często zajmują katalogi upload i cache, które zawierają pliki przesłane przez użytkowników oraz pliki pamięci podręcznej stron internetowych. Na przykład:

/var/www/user/data/www/yoursite.com/upload/

Pliki w tych katalogach można bezpiecznie usuwać. Jako administrator swojej strony najlepiej wiesz, które pliki w katalogu upload są istotne, a które można usunąć bez obaw. Sam katalog lepiej zostawić, aby uniknąć zbędnych błędów. 

  1. /var/lib/mysql/

Katalog z bazami danych twoich stron. 

ważne

Nie usuwaj niczego z tego katalogu!

Jeśli zajmuje za dużo miejsca, skontaktuj się z dostawcą usług hostingowych w celu dokładniejszej analizy. 

  1. /var/log/

Katalog z logami działania oprogramowania na twoim serwerze. Ponieważ logi bywają specyficzne, szczegółowe informacje znajdziesz w dedykowanym artykule.


Krok 3: Finalizacja i weryfikacja

Po usunięciu niepotrzebnych plików sprawdź, ile miejsca udało się zwolnić, za pomocą polecenia:

df -h