HOWTO

Wcześniej czy później zawsze pojawia się potrzeba zoptymalizowania naszej bazy MySQL. Przedstawię kilka zmian w konfiguracji, które powinny zwiększyć wydajność w większości przypadków. MyISAM - key_buffer_size Najprostszą optymalizacją baz/tabel z mechanizmem MyISAM jest odpowiednie dobranie bufora na cache dla kluczy i indeksów (dane nigdy nie są cachowane). Poniższe zapytanie pozwala oszacować zalecany rozmiar cache’u: SELECT CONCAT(ROUND(KBS/POWER(1024, IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.4999), SUBSTR(' KMG',IF(PowerOf1024<0,0, IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_key_buffer_size FROM (SELECT LEAST(POWER(2,32),KBS1) KBS FROM (SELECT SUM(index_length) KBS1 FROM information_schema.tables WHERE engine='MyISAM' AND table_schema NOT IN ('information_schema','mysql')) AA ) A, (SELECT 2 PowerOf1024) B; Wynik określa zalecany rozmiar bufora (parametr key_buffer_size w pliku /etc/mysql/my.cnf) dla bieżącego stanu bazy - warto ciut dodać na zapas. Na systemach 32 bitowych parametr key_buffer_size może przyjmować maksymalnie 4GB, na 64 bitowych maksymalnie 8GB. ...

Domyślna konfiguracja fail2ban’a (na Debianie) nie zawiera reguł pozwalających na blokowanie prób włamań na skrzynki POP/IMAP dla dovecota (no chyba że korzystamy z saslauthd). Można szybko utworzyć własny zestaw filtrów co przedstawię poniżej. Tworzymy plik: /etc/fail2ban/filter.d/dovecot.conf [Definition] failregex = (?: pop3-login|imap-login): .*(?:Authentication failure|Aborted login \(auth failed|Aborted login \(tried to use disabled|Disconnected \(auth failed|Aborted login \(\d+ authentication attempts).*rip=(?P<host>\S*),.* ignoreregex = Później dopisujemy na końcu pliku: /etc/fail2ban/jail.conf [dovecot] enabled = true filter = dovecot port = pop3,pop3s,imap,imaps logpath = /var/log/mail.log maxretry = 20 # te dwa poniżej wedle uznania - ja mam dobrze ustawione default'y #findtime = 1200 #bantime = 1200 Zostało zrestartować fail2ban’a: ...

Gdy już ustawimy reverse proxy przed Apache szybko można zauważyć że w logach zamiast adresów IP zdalnych użytkowników pojawia się tylko jeden adres: adres naszego proxy. Również z poziomu php’a jako adres klienta widać IP naszego proxy. By poradzić sobie z tym problemem trzeba na serwerze reverse proxy ustawić przekazywanie informacji o oryginalnym adresie IP klienta w nagłówku X-Forwarded-For. W przypadku gdy reverse proxy działa na nginx’e wystarczy dodać taki wpis: ...

Przez pewien czas korzystałem z eAcceleratora do przyspieszenia działania stron pisanych w PHP’ie ale czasem bywał niestabilny. Aktualizacje pojawiały się rzadko a od czasu do czasu miewałem problemy ze stabilnością tej wtyczki na kilku bardziej skomplikowanych aplikacjach. Zdarzało się że pomimo zmiany kodu w skrypcie php, eAccelerator serwował wciąż stary plik - konieczny był restart Apache’go by wszystko działało jak trzeba. Zacząłem szukać alternatywy i trafiłem na dwa moduły: APC  external link (czyli Alternative PHP Cache), który ma być nawet domyślnie wbudowany w PHP od wersji 5.4, XCache  external link - projekt rozwijany przez jednego z programistów lighttpd. Byłem ciekaw wydajności poszczególnych rozwiązań względem siebie, więc przygotowałem małe środowisko testowe składające się z 4 maszyn wirtualnych (działających pod kontrolą VirtualBox’a): ...

Administrowałem do tej pory głównie darmowymi distro, ale gdzieś tam ukradkiem wkradło się kilka “siusiaków” (aka SUSE Linux Enterprise Server). Żyłem w utopijnym przekonaniu że skoro się za nie płaci to powinno się z nimi łatwiej współpracować… w przypadku instalacji aktualizacji (a w szczególności SP) nie było to aż takie proste. Przywykłem w darmowych dystrybucjach że gdy pojawiała się nowszą “większa wersja” to po prostu można było jednym poleceniem zaktualizować wszystkie pakiety. Źródła aktualizowały się automatycznie (lub prawie automatycznie) - później trzeba było połatać ewentualne zmiany w plikach konfiguracyjnych. W SUSE jest ciut inaczej… 😉 ...

Bardzo często konfigurując usługi dostępne publicznie poświęca się sporo czasu na maksymalne zwiększenie bezpieczeństwa przez “dopieszczanie” konfiguracji (certyfikaty z mocnym szyfrowaniem, ochronę pewnych stron hasłem, dostęp do SSH tylko kluczami, itd.) ale całkowicie pomija się przygotowanie systemu aktywnie monitorującego błędne próby autoryzacji. Oczywiście nie można umniejszać wagi pierwszego z wymienionych etapów ale zdecydowanie nie powinno pomijać się też tego drugiego. Przecież każdy admin chciałby wiedzieć gdy ktoś próbuje włamać się na jego serwer (FTP, HTTP, SSH, itp.) - tylko ilu z Nas zadaje sobie trud by uruchomić taki system? ...

If you administer even a small mail server, you are surely aware that you cannot monitor logs in real-time. It is difficult to catch, for instance, a problem in communication with a certain domain. It is also hard to estimate the scale of traffic on the server in terms of both the number and volume of emails. It’s challenging to choose the domains for which it would be worthwhile to disable greylisting, etc… ...

Miałem ostatnio dziwną przygodę: pewien serwer do backupu gdzie ląduje dużo małych plików i dodatkowo tworzonych jest sporo hardlinków zaliczył pada. Co prawda starałem się go grzecznie położyć z pomocą Magic SysRq ale ponieważ nie wiedziałem co było przyczyną awarii fsck wydawał się wskazany. Podczas próby uruchomienia fsck.ext4 na systemie plików o rozmiarze ok 14TB z kilkuset milionami plików po kilkudziesięciu sekundach otrzymywałem komunikat: Błąd podczas przydzielania struktury icount: Memory allocation failed ...

Pomimo iż Linux uchodzi za stabilne środowisko to raz na jakiś czas trafi się ciężka zwiecha - z powodu przeciążenia, awarii sprzętu… nieistotne… Załóżmy że licho wzięło za cel główny serwer plików lub bazę danych dla wielu, wielu stron internetowych. Dostać się po ssh nie możemy bo lecą timeout’y, a siedząc bezpośrednio przy klawiaturze konsola nie reaguje. Mimo to coś ostro daje po dyskach, więc ewentualny twardy reset to na bank utrata części plików… jeśli system po nim w ogóle wstanie… 😑 ...

Wielu administratorów gdy zaczyna swoją przygodę zarządza jedną/dwoma maszynami… Po pewnym czasie jest ich już kilka… W którymś momencie dostrzega się zalety wirtualizacji i na kilku maszynach fizycznych działa kilkanaście czy kilkadziesiąt maszyn wirtualnych. W takiej sytuacji pobieranie aktualizacji dla wszystkich maszyn potrafi mocno zabić łącze. I w tym momencie zaczynamy się zastanawiać czy może nie warto byłoby zrobić własnego mirror’a paczek dla naszego ulubionego distro… do prywatnego użytku… synchronizowanego w nocy by nikomu nie przeszkadzać… i dostępnego nawet gdy będziemy offline… Zaczynamy liczyć miejsce i okazuje się że repozytorium Debiana dla architektury i386 to prawie 60GB (sic!), no ale mamy kilka maszynek z arch amd64 i tutaj też prawie 60GB - auć. W tym miejscu wielu dochodzi do wniosku że to jeszcze nie pora na własnego mirror’a 😃 ...