Jakiś czas temu korzystałem z preload’a który sam uczył się jakie aplikacje odpalam i te programy ładował już podczas startu – przeważnie nieco spowalnia to start systemu ale gdy już się załaduje to programy, które uruchamiam jako pierwsze startują „z kopa”. Od jakiegoś czasu popularniejszy jest instalowany domyślnie w Ubuntu ureadahead – pełni on podobną funkcję jak preload.
Linux
Wszystkie posty z tagiem Linux
Objaw przeważnie jest taki: łączysz się po ssh podając klucz/hasło i czekasz nawet i 10 sekund aż pojawi się prompt. Po połączeniu wszystkie polecenia działają z normalną szybkością. Brzmi znajomo?
Taki objaw przeważnie jest skutkiem problemów z działaniem DNS’a po stronie klienta lub serwera. Warto sprawdzić poleceniami host/dig/nslookup po obu stronach jak dużo czasu potrzeba na rozwiązanie nazw. Najlepiej rozwiązać problem z DNS’em ustawiając szybkie serwery ale gdy nie mamy takiej możliwości to po stronie serwera można ustawić w /etc/sshd_config opcję:
UseDNS no
I restart ssh:
service ssh restart
Spowoduje to wyłączenie znacznej części zapytań DNS po stronie serwera (w tym sprawdzanie reverse DNS’a dla hosta klienta w momencie łączenia). Na kilku serwerach z kiepskim DNS’em opcja ta „daje niezłego kopa”.
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.
Czytaj dalej
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… ![]()
Czytaj dalej
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?
Czytaj dalej