systemd

Uwierzytelnianie odpowiedzi z serwerów czasu NTP przy pomocy NTS

Przepisując ostatnio stare artykuły dotyczące zabezpieczenia zapytań DNS za sprawą wdrożenia na linux dnsmasq i dnscrypt-proxy, natknąłem się na informację, że nie tylko komunikacja DNS w obecnych czasach w sporej mierze nie jest zaszyfrowana. W zasadzie każda maszyna podłączona do internetu potrzebuje dysponować w miarę dokładnym czasem. By ten czas był dokładny, wymyślono mechanizm synchronizacji czasu przez wysyłanie zapytań do serwerów NTP (Network Time Protocol). Niemniej jednak, odpowiedzi z tych serwerów czasu nie są w żaden sposób zabezpieczone i praktycznie każdy na drodze tych pakietów może nam zmienić ustawienia czasu w systemie (MITM). W taki sposób możemy zostać cofnięci w czasie, co z kolei może oznaczać, że system zaakceptuje certyfikaty SSL/TLS czy też klucze/bilety sesji (używane do wznawiania sesji TLS), które już dawno temu wygasły lub/i zostały w jakiś sposób skompromitowane. Pchnięcie nas do przodu w czasie również oznacza problemy, bo możemy zaakceptować certyfikat, który jeszcze nie zaczął być ważny. To z kolei otwiera drogę do odszyfrowania połączeń z serwisami WWW, a przecie nie po to szyfrujemy ruch, by go ktoś bez większego problemu odszyfrował. Dlatego też powinniśmy zadbać o to, by informacje o aktualnym czasie otrzymywane z sieci docierały do nas z wiarygodnego źródła i były w jakiś sposób uwierzytelnione. Na Debianie standardowo do synchronizacji czasu wykorzystywany jest systemd-timesyncd ale nie wspiera on póki co protokołu NTS. Trzeba będzie zatem się go pozbyć i zastąpić go demonem ntpd z pakietu ntpsec .

Jak zalogować błędy podczas zamykania systemu Debian Linux

By wyłączyć komputer, jego system operacyjny musi pierw zatrzymać (lub też ubić siłowo) wszystkie działające usługi za wyjątkiem tego mającego PID z numerkiem 1. Zwykle proces zamykania się systemu Debian Linux nie trwa więcej niż parę sekund ale czasami pojawiają się dziwne problemy, które mogą to zadanie utrudnić lub też całkowicie uniemożliwić. Nawet jeśli system będzie się w stanie zresetować, to zanim to nastąpi, to na konsoli mogą pojawić się komunikaty mogące pomóc nam w zdiagnozowaniu dolegliwości, która doskwiera naszej maszynie. Problem w tym, że część tych wiadomości nie zostanie nigdy zalogowana do pliku, gdzie moglibyśmy ich poszukać. Dzieje się tak dlatego, że w pewnym określonym momencie zamykania się systemu trzeba wyłączyć usługę logowania, co zwykle widać w logu jako systemd-journald[]: Journal stopped . Gdy dziennik zostanie zatrzymany, żadna wiadomość, która od tego momentu pojawi się na ekranie, nie zostanie już zalogowana do pliku. Jeśli teraz pojawią nam się ostrzeżenia lub błędy, a po chwili komputer się zresetuje, to możemy mieć nie lada problem z ustaleniem przyczyny mimo, że system nam ją zgłasza. Przydałoby się zapisać te komunikaty, tylko jak to zrobić, skoro usługa logowania jest już nieaktywna?

Konfiguracja DDNS dla OpenDNS

Ludzkość w dalszym ciągu siedzi na przestarzałym już od prawie 20 lat protokole IPv4. Nie widać, też by w najbliższym czasie coś miało się w tej kwestii zmienić. Można, co prawda, wykupić sobie stały adres IP ale to kosztuje, no i płacimy za coś co powinniśmy mieć w standardzie, gdyby ludzie w końcu zaczęli korzystać z IPv6. Niemniej jednak, by te wszystkie nasze maszyny podłączyć jakoś do sieci, potrzebne nam są prywatne adresy IP + NAT lub też dynamicznie zmieniające się adresy publiczne. Bywają też przypadki, że mamy przydzielane dynamicznie adresy z puli prywatnej, np. w wyniku dbania o prywatność w sieciach WiFi przez generowanie sobie przy każdym połączeniu losowego adresu MAC. Zwykle w takiej sytuacji zmienia nam się adres zewnętrzny (publiczny), który wskazuje na jeden z adresów naszego ISP. Taki zmieniający się adres powoduje problemy przy konfiguracji poszczególnych usług sieciowych, np. gdy w grę wchodzi konfiguracja filtra DNS, który jest zapewniany przez OpenDNS. By tego typu niedogodności rozwiązać, możemy posłużyć się DDNS (dynamic DNS). Za każdym razem, gdy adres IP ulega zmianie, klient DDNS informuje o tym fakcie skonfigurowane usługi. W tym artykule przyjrzymy się nieco bliżej temu mechanizmowi.

Mechanizm inhibitor lock w systemd

Hibernacja w przypadku komputerów, zwłaszcza laptopów, to bardzo użyteczny wynalazek. Na linux'ach wymaga ona czasem lekkiej konfiguracji ale generalnie można powiedzieć, że działa OOTB. Po migracji szeregu dystrybucji na systemd, proces hibernacji zdaje się przebiegać nieco inaczej niż to miało miejsce w przeszłości. Bardzo często możemy się spotkać z sytuacjami, gdzie przy próbie zahibernowania czy wyłączenia systemu, ten zwyczajnie ignoruje nasze żądanie i pracuje dalej jak gdyby nigdy nic. W tym przypadku nie mamy do czynienia z bug'iem ale ficzerem. Okazuje się bowiem, że systemd dysponuje mechanizmem zwanym inhibitor lock, który ma na celu powstrzymanie systemu od dokonania hibernacji, uśpienia lub wyłączenia w pewnych określonych sytuacjach. W tym wpisie przyjrzymy się nieco bliżej temu mechanizmowi.

Konfiguracja jasności ekranu w laptopie (backlight)

Linux nigdy nie był popularnym systemem operacyjnym na stacjach klienckich. Może i cieszy się sporym wzięciem wśród środowisk serwerowych ale jego niezbyt prosta obsługa nie przemawia do przeciętnego użytkownika komputera. Wraz z rozwojem technologi, zmienił się też rodzaj urządzeń na jakich obecnie pracujemy. W dzisiejszych czasach liczy się przede wszystkim mobilność i praktycznie każdy z nas miał już prawdopodobnie do czynienia z laptopami. Producenci tych urządzeń lubią nam wciskać windowsa z dopiskiem, że ten laptop bez niego nie będzie w ogóle nam działał. Już od dość dawna szereg laptopów jest w stanie pracować pod linux'em ale, jakby nie patrzeć, sporo rzeczy w nich nie działa OOTB i trzeba poświęcić trochę czasu, by tę maszynę doprowadzić do porządku. W tym wpisie zajmiemy się zagadnieniem podświetlania matrycy (backlight), tak by system był w stanie bez problemu zapisać ustawienia jasności ekranu przy wyłączaniu komputera oraz, by potrafił je także wczytać podczas fazy rozruchu.

Temperatura dysku twardego (hddtemp)

Obecnie dyski twarde nie są potrzebne do prawidłowego działania komputera. Mając sporo pamięci operacyjnej oraz system live, możemy bez problemu korzystać z takiego sprzętu. Niemniej jednak, systemy live są nieco ograniczone. Najdotkliwszą ich wadą jest brak zapisywania wprowadzanych zmian. W pewnych przypadkach ta cecha może być bardzo pożądana ale jeśli chodzi o przeciętnego użytkownika, to chciałby on raczej mieć możliwość zapisu swojej pracy. Dlatego też zewnętrzny magazyn danych w postaci dysku twardego nie prędko wyjdzie z użytku. Te urządzenia, jak i większość tych, które podłączamy do naszego komputera, wydzielają ciepło. Temperatura jest wrogiem numer 1 w przypadku maszyn i musi stale być monitorowana, tak by czasem nie doszło do przegrzania sprzętu. Dyski HDD mają ten problem, że im wyższa jest temperatura, tym obszar magnetyczny się bardziej rozszerza, a to powoduje błędy odczytu i zapisu. Podobnie jest ze zbyt niską temperaturą, gdzie ścieżki i sektory ulegają skurczeniu. Taki dysk musi pracować w odpowiednich warunkach termalnych. W tym wpisie postaramy się ustalić aktualną temperaturę dysku oraz spróbujemy ją monitorować, tak by wiedzieć czy czynnik temperaturowy nie zagraża czasem dyskom podpiętym do naszego PC.

Jak skonfigurować bonding w Debian linux (eth0+wlan0)

W artykule poświęconym konfiguracji sieci WiFi na Debianie z wykorzystaniem narzędzia wpa_supplicant wspomniałem parę słów na temat interfejsu bond. Bonding na linux wykorzystywany jest w zasadzie do spięcia kilku interfejsów sieciowych, w tym przewodowych ( eth0 ) i bezprzewodowych ( wlan0 ) w jeden (zwykle bond0 ). Takie rozwiązanie sprawia, że w przypadku awarii któregoś z podpiętych interfejsów, my nie tracimy połączenia z siecią i nie musimy nic nigdzie przełączać, by to połączenie przywrócić. To rozwiązanie jest o tyle użyteczne, że w przypadku, gdy podepniemy przewód do gniazda RJ-45 w naszym laptopie, to komunikacja będzie odbywać się po kablu. Natomiast jeśli przewód zostanie odłączony, to system automatycznie przejdzie na komunikację bezprzewodową. W tym wpisie spróbujemy zaprojektować sobie właśnie tego typu mechanizm zarówno za sprawą pakietu ifupdown , gdzie konfiguracja interfejsów sieciowych jest zarządzana przez plik /etc/network/interfaces , jak i przy pomocy natywnego rozwiązania jakie oferuje systemd/networkd.

Odszyfrowanie kontenerów LUKS w systemd

Osoby, które wykorzystują pełne szyfrowanie dysku, wiedzą, że nie zawsze da radę tak skonfigurować swój system, by upchnąć go na jednej partycji. Nawet jeśli korzystamy z LVM wewnątrz kontenera LUKS, to i tak zwykle możemy posiadać inne zaszyfrowane partycje, które są odrębną całością i montowane osobno przy starcie systemu. W takim przypadku zwykle jesteśmy zmuszeni do podawania hasła do każdego z tych dysków z osobna, co zajmuje czas. Ten problem opisałem po części przy okazji implementacji kontenera LUKS na potrzeby Dropbox'a, jak i we wpisie poświęconym przejściu z kontenerów TrueCrypt'a na te linux'owe, które są wspierane natywnie przez sam kernel. Niemniej jednak, tamto rozwiązanie było oparte głównie o starszy init (sysvinit), co wymagało dodatkowej konfiguracji, tak by system otworzył się po podaniu tylko jednego hasła. W tym wpisie postaramy się wdrożyć mechanizm, który jest oferowany przez systemd.

Kształtowanie ruchu sieciowego (Traffic Control)

Każdy z nas chciałby, aby jego sieć działała możliwie szybko i bezproblemowo. W przypadku, gdy łącze nie jest zbytnio obciążone, a my jesteśmy jedynym użytkownikiem internetu, to nie doświadczymy raczej żadnych problemów z połączeniem. Rzecz w tym, że im więcej użytkowników ma nasza sieć, tym większe prawdopodobieństwo, że zostanie ona przeciążona, tj. będziemy chcieli przesyłać więcej danych niż sieć jest w stanie obsłużyć. W ten sposób zaczną pojawiać się kolejki pakietów na interfejsach, których obsługa zajmuje trochę czasu. Rosą zatem opóźnienia, które są bardzo odczuwalne w momencie, gdy ktoś lubi sobie pograć w różnego rodzaju gry online. Innym problemem może być sieć P2P, gdzie pojedynczy host z naszej sieci może nawiązywać dziesiątki czy nawet setki połączeń i tym samym zapychać łącze nie dając szansy innym użytkownikom na komfortowe korzystanie z internetu. W obu przypadkach może nam pomóc kształtowanie ruchu sieciowego (Traffic Control), która jest w stanie nadać pakietom odpowiedni priorytet, tak by część z nich nie musiała czekać zbyt długo w kolejce. W tym wpisie przyjrzymy się bliżej temu mechanizmowi.

Ograniczanie zasobów procesom przez cgroups

Nasze komputery obecnie mają dość pokaźne zasoby obliczeniowe. Jeszcze nie tak dawno temu wyposażenie maszyny w 32 GiB pamięci RAM, czy też 8 rdzeni było czystą abstrakcją. Wydawałoby się, że te powyższe parametry zaspokoją każdego. Niemniej jednak, nie ważne jak szybki i rozbudowany będzie nasz PC, to nam zawsze będzie mało. Mamy dwa rdzenie, to chcemy cztery. Mamy cztery, to chcemy osiem, itd. Poza tym, szereg aplikacji realizuje co raz więcej zadań i staje się bardziej wymagająca z każdym mijającym rokiem. Jeśli nie przeprowadzamy modernizacji sprzętu, to może się okazać, że w niedługim czasie zabraknie nam pamięci albo pewne operacje będą wykonywane bardzo wolno. W sporej części przypadków nie obędzie się bez wymiany podzespołów ale nawet w przypadku, gdy mamy spory zapas zasobów systemowych, to poszczególne procesy rywalizują o nie ze sobą. Często bywa tak, że chcielibyśmy, aby konkretny proces wykonał się szybciej, a to pociąga za sobą, np. zmianę priorytetów w dostępie do rdzeni procesora. W linux'ie jest mechanizm zwany cgroups, który potrafi ograniczyć zasoby całym aplikacjom bez względu na to ile ona by miała procesów. W tym wpisie postaramy się przebrnąć przez proces konfiguracji tego mechanizmu i spróbujemy wyprofilować sobie nasz system.