K-NET s.c.

Macierz RAID1 i problemy z GRUB2

Powszechnie wiadomo, że nie jest szczególnie trudno zbudować macierz programową RAID1 używając systemu operacyjnego Debian. Przy instalacji jest to jedna z najczęściej wybieranych opcji, w celu zabezpieczenia się przed niespodziewaną utratą danych. Większość tak zwanych software’owych raidów, oferowanych przez producentów płyt głównych, opiera się właśnie o pakiet mdadm, czyli w zasadzie jest to dokładnie takie samo rozwiązanie jak w przypadku zwyczajnej instalacji. Przyznam się, że często wyłączam raid na płycie głównej, bo wolę panować do końca nad systemem, i po prostu instaluję oprogramowanie ręcznie. I wszystko było by dobrze gdyby nie jeden, nie zrozumiały przeze mnie fakt. Otóż do tej pory, przy składaniu raidu, instalator modyfikuje konfigurację bootloadera grub tylko dla pierwszego dysku (np. /dev/sda). Co oznacza, że w przypadku uszkodzenia drugiego dysku (np. /dev/sdb) twardego komputer przeżyje awarię, jednak jeżeli zostanie uszkodzony pierwszy dysk można mieć sporo kłopotów z jego uruchomieniem. Internet jest pełen takich historii, jak również mnóstwo jest porad jak zapobiegać lub usunąć ten błąd. Ja gorąco będę namawiał do przygotowania się zawczasu i skonfigurowania prawidłowo systemu na samym początku. W tym celu zaraz po instalacji systemy wystarczy skorzystać z trzech prostych poleceń (wydawanych z konta root)):

mv /boot/grub/device.map /boot/grub/device.map.old
grub-mkdevicemap
update-grub2 && grub-install /dev/sda && grub-install /dev/sd

Czasami naprawdę niewiele wystarczy, żeby zabezpieczyć się na przyszłość.

MG

Debian Jessie – sshd i obsługa PAM

W najnowszej wersji Debiana (Jessie), nie wiedzieć skąd pojawił się błąd związany z obsługą sesji SSH. Do tej pory, wykonując typowe prace administracyjne takie jak aktualizacje, w szczególności wymianę jądra systemu na nowszą wersję, nie było żadnego problemu kiedy trzeba było wydać polecenie reboot. Serwer prawidłowo kończył sesję SSH i po krótkiej chwili można było znowu się połączyć. O ile oczywiście dał radę podnieść się po naszych zabiegach. Tym razem jest inaczej. Krótko mówiąć sesja SSH zawiesza się i bez siłowego zamknięcia terminala nie ma mowy o kontynuowaniu pracy. Związane jest to z obsługą biblioteki PAM. Żeby pozbyć się opisanej niedogodności konieczna jest instalacja dodatkowych bibliotek, które nie są dostarczane w standarowej wersji:

apt-get install libpam-systemd dbus

Na tym nie koniec. Musimy upewnić się, że nasz daemon sshd ma włączoną obsługę PAM. Tak inaczej wystarczy wydać polecenie:

 grep -i UsePAM /etc/ssh/sshd_config

i ewentualnie odkomentować w pliku /etc/ssh/sshd_config wspomnianą linię. Na koniec restartujemy sshd:

/etc/init.d/ssh restart

MG

Time has been changed – co oznacza ten komunikat

Jednym z problemów w administracji serwerami (nie tylko inuxowymi) jest synchronizacja czasu. Praktycznie każda usługa systemowa może odmówić posłuszeństwa jeżeli nie zadbamy o prawidłową podstawę czasu. Z pozoru zadanie to jest dość proste. Wystarczy zainstalować pakiet ntp:

apt-get install ntp

i od razu wszystko powinno działać. Osobiście polecam takie rozwiązanie na każdym sewerze z Linuxem aby właśnie zadbać o zsynchronizowanie naszej skali czasu z serwerami źródłowymi dostępnymi w Internecie. Musimy jednak pamiętać, że oprócz zegara systemowego, każdy komputer wyposażony jest w zegar sprzętowy. Funkcjonowanie tego ostatniego, a raczej jego zła praca, na pewno będzie miała wpływ na stabilność zegara systemowego. Są to bardzo rzadkie przypadki ale zdarzają się. Np. w Debianie Jessie aby zrealizować synchornizację wykorzystywane są kolejno usługi i funkcje systemd, swdate i w konsekwencji Slow Clock Adjuster. Co w moim przypadku, przy korzystaniu z maszyny VirtualBox, i zapewne błędnej obsłudze czasu przez środowisko wirtualne, zaowocowało komunikatami systemowymi (rsyslogd):

host systemd[1]: Time has been changed

Jak wspomniałem, jest to błąd oprogramowania i aby pozbyć się powyższych komunikatów trzeba je po prostu odfiltorwać na poziomie logu systemowego. W tym celu logujemy do konsoli roota i zakładmy plik time_msgs.conf:

touch /etc/rsyslog.d/time_msgs.conf

Następnie edytujemy plik:

vi /etc/rsyslog.d/time_msgs.conf

i dodajemu linijkę:

:msg, contains, "Time has been changed" stop

Po wszystkim musimy ponownie uruchomić usługę:

/etc/init.d/rsyslog stop
/etc/init.d/rsyslog start

Tym samym pozbyliśmy się niepotrzebnych komunikatów z logów systemowych.

MG

Conky – integracja z Fetchmail

Conky to potężny i popularny pakiet wśród użytkowników desktopowych Linuxów. Wyróżnia się przede wszystkim niesamowitą elastycznością pozwalając zastąpić dowolne applety pulpitu i przygotować spersonalizowany wygląd desktopu. Przyznam, że również jestem jego zagorzałym zwolennikiem jednak ostanio przy zmianie systemu z poczciwego Ubuntu 12.04 na wersję 14.04 czekała mnie niemiła niespodzianka. Jako właściciel kilku kont pocztowych lubię wyświetlać informację o liczbie nowych wiadomości bezpośrednio na pulpicie. Do tej pory radziłem sobie za pomocą dodatku conkyemail. Niestety nie jest on dalej rozwijany a dla Ubuntu 14.04 istnieje wiele niespełnionych zależności podczas instalacji dlatego musiałem z niego zrezygnować. Po kilku godzinach poszukiwań czym można zastąpić wspomniany pakiet zdecydowałem się zainstalować sprawdzony Fetchmail. Integracja z Conky nie jest w tym przypadku prosta i oczywista ale efekt końcowy wygląda całkiem dobrze.

Po pierwsze, jak wspomniałem, musimy zainstalować pakiet Fetchmail. Po drugie należy utworzyć specjalny plik konfiguracyjny .netrc w katalogu domowym. Plik będzie zawierał nazwę użytkownika oraz hasło dla konta pocztowego, dla którego sprawdzamy nowe wiadomośc

machine serwer.pocztowy.pl
    login nazwa_użytkownika
    password hasło_użytkownika

Ze względu na bezpieczeństwo powinniśmy zmienić uprawnienia dla pliku:

chmod 600 ~/.netrc

Warto również wspomnieć, że możemy skonfigurować dowolną liczbę kont, Fetchmail podczas połączenia będzie przeszukiwał listę żeby odnaleźć pasujący wzorzec.

Teraz możemy zająć się plikiem konfiguracyjnym .conkyrc. W przypadku opisywanego rozwiązania powinniśmy w nim umieścić następującą linijkę:

pocztowy.pl: ${execi 300 fetchmail -c -p pop3 -u nazwa_użytkownika →
serwer.pocztowy.pl | sed -e 's/fetchmail: //' | sed -e 's/for.*$//'}

Jej działanie polega na okresowym wywoływaniu Fetchmail w celu sprawdzenia czy są nowe wiadomości – opcja -c. Zaś aby usunąć niepotrzebne informacje z komunikatu zwrotnego zastosowałem filtrowanie w potoku za pomocą sed. Efektem końcowym będzie wyświetlenie na pulpicie liczby nieprzeczytanych wiadomości email.

MG

Postfix main.cf czyli kolejność ma jednak znaczenie

Przez wiele lat konfigurowałem rozmaite serwery poczty opierając się o sprawdzony serwer Postfix w tandemie z Debianem. Były to konfiguracje bardzo proste, średnio złożone i takie, które wymagają posiedzenia nad problemem dłużej. Wykorzystywałem Postfix natywnie i w połączeniu z gotowymi skryptami (np. polecanym iRedMail). Przyznam, że nigdy nie zawiódł i wydawał się być dość prosty w obsłudze przy jednocześnie rozbudowanych opcjach ustawień. Do czasu aż trafiłem na problem, który zatrzymał mnie w miejscu na parę godzin. O co chodzi? Otóż w każdej sieci znajdzie się urządzenie, komputer, router może termometr IP, które będzie chciało wysyłać emaile z komunikatami. I zazwyczaj mają one wbudowaną obsługę autoryzacji dla połączeń SMTP. Jedna raz na jakiś czas trafi się egzamplarz, który za żadne skarby świata nie potrafi się kulturalnie przedstawić naszemu Postfixowi. Wówczas nie pozostaje nic innego jak zrobić małe obejście i dopuścić urządzenie do wysyłania emaili bez żadnych ograniczeń. Wiem, że nie powinniśmy tak nigdy robić ale czasem trzeba. W Postfixie służy do tego opcja (na przykładzie adresu 10.10.10.10):

mynetworks = 127.0.0.1 10.10.10.10

która spowoduje, że wymienione po kolei hosty stają się uprzywilejowane. Czy zawsze to zadziała? W tym właśnie tkwi sedno sprawy, że nie! Otóż jeżeli w naszej konfiguracji stosujemy różne ograniczenia (a jak wspomniałem Postfix jest bogaty w możliwości) czyli np. zastosujemy dyrektywę smtpd_recipient_restrictions to kolejność jej atrybutów zaczyna mieć znaczenie. Czyli np. kod:

smtpd_recipient_restrictions =
  permit_mynetworks
  reject_unknown_recipient_domain
  reject_non_fqdn_recipient

jest prawidłowy bo atrybut permit_mynetworks jest pierwszy na liście. Jednak ten sam kod zapisany:

smtpd_recipient_restrictions =
  reject_unknown_recipient_domain
  reject_non_fqdn_recipient
  permit_mynetworks

jest już nieprawidłowy bo kolejność ma jednak duże znaczenie. Reguła ta obowiązuje dla wszystkich dyrektyw, dla których możemy użyć atrybutu permit_mynetworks.

MG

Budowa serwera SFTP na bazie SSH i Debiana

Jak powszechnie wiadomo nie wynaleziono jeszcze bardziej popularnej usługi do transferu plików niż FTP. Być może większość administratorów wolałaby korzystać z innych rozwiązań ale tak się składa, że znają prawie wszyscy użytkownicy i to oni z reguły wymuszają stosowanie FTP. Podstawowy problem w tym przypadku to brak szyfrowania transmisji co przede wszystkim oznacza przesyłanie haseł jawnym tekstem. Jednak mając gotowy serwer z Linuxem oraz dostępem zdalnym po SSH można pokusić się o przygotowanie serwera SFTP, który zachowując większość funkcji FTP będzie zabezpieczał odpowiednio nasze połączenia. Co więcej jeśli ktoś dotychczas korzystał z bardzo popularnych programów typu WinSCP czy FileZilla to zasadniczo nie powinien mieć żadnych problemów z korzystaniem z SFTP bowiem obsługa tego ostatniego została już zaimplementowana w tych windowsowych klientach. Zatem do dzieła.

Po pierwsze sprawdzamy czy obsługa SFTP została włączona w konfiguracji serwera OpenSSH. Plik /etc/ssh/sshd_config powinien zawierać wpis:

Subsystem sftp internal-sftp

Teraz, na końcu pliku możemy dodać sekcje dla nowego konta z dostępem SFTP:

Match User KontoSFTP
  ChrootDirectory /home
  AllowTCPForwarding no
  X11Forwarding no
  ForceCommand internal-sftp

Oczywiście zakładam, że wcześniej założyliśmy sobie takie konto w systemie. Po ponownym uruchomieniu serwera SSH wszystko powinno zacząć działać… oprócz dwóch drobnostek.

Na pewno warto zadbać aby użytkownik KontoSFTP nie miał dostępu shellowego do systemu. W tym celu musimy zmienić mu domyślny shell. Najpierw sprawdzamy czy możemy użyć shella typu sftp-server:

cat /etc/shells

Jeśli nie zostanie wyświetlona nazwa sftp-server powinniśmy użyć polecenia:

echo '/usr/lib/openssh/sftp-server' >> /etc/shells

Teraz możemy już zmodyfikować konto naszego użytkownika:

usermod -s /usr/lib/openssh/sftp-server KontoSFTP

Druga sprawa to powinniśmy zmienić prawa dostępu do tych podkatalogów w /home, do których chcemy zabezpieczyć dostęp. W ten sposób nasz użytkownik nie będzie mógł zwiedzać innych podkatalogów. Dla każdego z zabezpieczanych katalogów należy wydać polecenie:

chmod 700 /home/NazwaZabezpieczanegoKatalogu

Po wykonaniu powyższych czynności możemy cieszyć się nowym serwerem SFTP. Powyższe uwagi dotyczą rzecz jasna mojego ulubionego Debiana.

MG

update.rc-d vs rc.local vs @reboot

Tym razem chciałem przedstawić krótki i treściwy wpis na temat uruchamiana aplikacji w trakcie startu serwerowego systemu operacyjnego. Sprawa dotyczy mojego ulubionego Debiana. Właściwie najabardziej elegancką i zgodną z regułami metodą jest umieszczenie skryptu startowego w katalogu /etc/init.d/, nadanie mu praw wykonywalnych i wywołanie polecenia:

update-rc.d nasz_skrypt defaults 99

Niemniej z różnych przyczyn nie zawsze się to udaje. Trzeba podejść do tematu inaczej. Od razu zaznaczam, że poniższe metody, jakkolwiek spełniające swój cel, są po prostu bardzo nieeleganckie i nie świadczą najlepiej o umiejętnościach administratora. Czasami jednak trzeba się ugiąć – chociażby pod presją czasu.

Druga metoda polega na dopisaniu skryptu do pliku /etc/rc.local. Generalnie tym sposobem można rozwiązać dużo problemów ale osobiście stosuje go tylko doraźnie. Polecam to jako rozwiązanie tymczasowe.

Trzecia metoda, kiedy zawiodą dwie poprzednie, to umieszczenie skryptu startowego w cronie systemowym dla konta root. Wywołujemy go poleceniem:

crontab -e

a następnie na końcu pliku dopisujemy linijkę:

@reboot /ścieżka_dostępu/nasz_skrypt

Od tego momentu, za każdym razem podczas uruchamiania się systemu, automatycznie będzie wykonywał się skrypt. Mało elegancko ale skutecznie.

MG

ssl error weak server ephemeral dh key

Od miesiąca, po zainstalowaniu najnowszej aktualizacji przeglądarki Firefox można napotkać błąd połączenia z niektórymi szyfrowanymi stronami (chodzi o protokół HTTPS):

ssl error weak server ephemeral dh key

W dużym skrócie wynika to stąd, że pojawiła się nowa metoda ataku o nazwie Logjam, która wymusza zmiane długości klucza szyfrującego do 512 bitów (w miejsce np. 2048). Jak powszechnie wiadomo osłabia to znacząco odporność szyfrowanego kanału transmisji. Autorzy Firefoxa słusznie postanowili wzmocnić swoją przeglądarkę uniemożliwiając połączenie ze serwerami podatnymi na taki mechanizm. Z jednej strony jest to rozsądne działanie ale z drugiej co mają zrobić np. użytkownicy domowych urządzeń sieciowych zarządzanych przez HTTPS. O ile w przypadku serwerów zawsze można liczyć na administratorów o tyle domowy router wcale nie musi dostać wsparcia od producenta w postaci nowego firmware’u. Można wybrać inną przeglądarke ale myślę, że za miesiąc pozostałe również zablokują wspomniane połączenia. Okazuje się jednak, że w Firefoxie można wyłączyć to zabezpieczenie. Nie namawiam nikogo aby robił to na stałe. Poniższe kroki proponuję stosować wyłącznie tymczasowo np. aby skonfigurować swój router domowy:

• Jako adres w Firefoxie podajemy “about:config”
• Wyszukujemy paramter “security.ssl3.dhe_rsa_aes_128_sha” i ustawiamy jego wartość na “false”
• Wyszukujemy parametr “security.ssl3.dhe_rsa_aes_256_sha” i ustawiamy jego wartość na “false”

Pamiętajmy jednak o tym, żeby na koniec przywrócić wartość “true” dla wspomnianych parametrów po zakończeniu konfiguracji przykładowego routera.

MG

Ultra Fast Boot zbyt szybki?

Już od dłuższego czasu większość sprzedawanych płyt głównych wyposażona jest w opcje Ultra Fast Boot. W połączeniu z UEFI i Windows 8 daje ona możliwość bardzo szybkiego startu komputera, nawet na poziomie kilku sekund. Wyzwaniem jest jednak dostanie się do ustawień BIOS po jej włączeniu. W praktyce bootowanie odbywa się tak szybko, że nie można liczyć na ekran POST i wciśnięcie klawisza F2 lub DEL. Użytkownicy Windows otrzymują wraz ze sterownikami płyty głównej aplikację narzędziową. Pozwala ona uruchomić komputer z wejściem do BIOS przy następnym przeładowaniu systemu. Co jednak mają zrobić właściciele Linkusów? Najczęściej można usłyszeć poradę brzmiącą mniej więcej – zdjąć obudowę i wyjąć na kilka sekund baterie podtrzymująca CMOS. Ewentulanie należu skorzystać z odpowiedniej zworki na płycie. Tak czy inaczej jest to operacja ryzykowna. Zakładając na przykład, że mieliśmy skonfigurowany software-RAID w BIOS, możemy sprawić sobie problem. Jednak jak zwykle istnieje dużo prostsze rozwiązanie. Być może nie jest ono oczywiste ale zazwyczaj sprawdza się. Skoro otworzyliśmy już obudowe naszego komputera to wystarczy odpiąć dyski twarde. Po uruchomieniu, BIOS wykryje zmiane konfiguracji i umożliwi bezpośrednio konfiguracje swoich parametrów. Korzystając z okazji wyłączamy opcję Ultra Fast Boot i zapisujemy ustawienia. Po wyłączeniu komputera i ponownym podłączeniu dysków możemy uruchomić system. Tym razem ekran POST powinien być już widoczny a my powinniśmy mieć zawsze szanse dostać się do naszych ustawień w BIOS.

MG

Konfigurowanie autoodpowiedzi dla konta Gmail za pomocą Zapier

Każdy właściciel konta pocztowego na Gmailu wie, że możliwości jego konfiguracji są naprawde duże. Jedną z moich ulubionych opcji jest pobieranie poczty z innych serwerów przy pomocy protokołu POP3. Wynika to z mojej niechęci do automatycznego przekazywania poczty na inne konta (tzw. forward). Z doświadczenia bowiem wiem, że łatwo jest się wtedy stać przekaźnikiem spamu. Dlatego mam skonfigurowanych kilka kont POP3 na Gmailu.

Jak co roku mamy okres wakacyjny i właśnie wtedy pojawia się problem ze skrzynką GMAIL. Okazuje się, że autoodpowiedź wakacyjna dostępna w panelu administracyjnym nie działa dla poczty pobieranej z kont POP3. Czy można coś na to poradzić? Jak najbardziej. Od kiedy mamy dostępny serwis Zapier, możemy skonfigurować autooodpowiedź za jego pomocą. Wykonujemy po kolei następujące kroki:

1. Wybieramy opcje Create a Zap (wielki pomarańczowy guzik na głównej stronie)
2. Następnie w sekcji Pick your Trigger and Action for this Zap po obu stronach wybieramy Gmail i po kolei New Email (Legacy) oraz Send Email
3. W sekcji Select a Account (Trigger) podajemy swoją nazwe konta Gmail
4. W sekcji Select a Account (Action) postępujemy jak wyżej
5. Bardzo ważny krok – Filter your emails. Wybieramy filtrowanie tylko dla wiadomości wpadających do INBOX. Jeśli stosujemy już jakieś filtry na Gmailu (np. aby automatycznie odsiać pocztę, powiedzmy, z Allegro) to unikniemy w ten sposób generowania niepotrzebnych autoodpowiedzi. I najważniejsze, korzystamy z opcji ‘Search String’. Przykładowo, jeśli nasza autoodpowiedź będzie zawierać w temacie słowo ‘Autoodpowiedź’ to konieczne jest utworzenie filtru:

   subject: -Autoodpowiedz

   co spowoduje, że nie będą generowane autoodpowiedzi na wszystkie maile z w/w słowem w tytule. Pozwala to uniknąć zapętlenia wiadomości.

6. Ostatnim krokiem właściwej konfiguracji jest Create your  Email. Edytujemy następujące, wymagane, pola:
   1. To – gdzie wybieramy opcję From Address
   2. Subject – wpisujemy

      [Autoodpowiedz]

      i wybieramy opcje Subject. Zgodnie z tym co pisałem wcześniej, dzięki temu unikniemy zapętlenia maili, zaś temat w autoodpowiedzi będzie wyglądał następująco: [Autoodpowiedz] Oryginalny temat wiadomości.

   3. Body – tutaj wpisujemy treść naszej autoodpowiedzi
7. Pozostałe dwa kroki pozwalają przetestować naszą regułę (Try out your Zap) i włączyć ją (Enable your Zap).

Konto w serwisie można testować za darmo przez 14 dni co jest wystarczającym czasem na wakacje.

MG