Linux

Czasami odpalam klona jakiegoś systemu by później po drobnych zmianach uczynić go osobnym bytem. Jednym z kroków po odtworzeniu systemu jest wygenerowanie nowego zestawu kluczy dla serwera OpenSSH (by mój klient ssh nie siał warning’ami). Można to wykonać tak: Najpierw kasujemy obecne klucze: rm /etc/ssh/ssh_host_* Teraz generujemy nowe: dpkg-reconfigure openssh-server I na koniec restartujemy usługę by załadować nowy zestaw kluczy (nie powinno to zerwać obecnej sesji, ale dla pewności lepiej zadanie odpalić w screen’ie): ...

Jakiś czas temu korzystałem z preload’a  external link 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. ...

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ę: ...

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: ...

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 😃 ...