systemd

Jak wymusić sprawdzenie systemu plików w systemd

Jakiś czas temu opisywałem jak w systemach linux'owych przeprowadzić sprawdzenie systemu plików pod kątem ewentualnych błędów. Był tam poświęcony kawałek na temat ręcznego wymuszenia takiego skanowania. Ten sposób, który został opisany w tamtym wpisie działa wyśmienicie w przypadku sysvinit. Natomiast przy systemd mogą pojawić się pewne problemy, w efekcie czego nie będziemy w stanie wymusić skanowania pewnych partycji. Generalnie to rozchodzi się o tę główną, na której znajduje się system plików / . Postanowiłem się przyjrzeć nieco temu mechanizmowi i sprawdzić czy faktycznie nic nie da się zrobić i czy musimy czekać pełną ilość cykli startu systemu, by ten system plików został przez niego przeskanowany automatycznie.

Przewidywalne nazwy interfejsów sieciowych

Podczas jednej z aktualizacji systemu został mi zwrócony pewien komunikat. Oświadczał on bowiem, że od jakiegoś czasu nazewnictwo interfejsów sieciowych w systemie uległo zmianie, oraz, że w wersji 10 debiana, ten obecny system nazw nie będzie już wspierany. Rozchodzi się o coś co nazywa się Predictable Network Interface Names, czyli przewidywalne nazwy interfejsów sieciowych. Jako, że aktualne wydanie stabilnego debiana ma numerek 8 i w niedalekiej przyszłości zostanie wydana 9, to przydałoby się już zacząć migrować na ten nowy system nazw. W tym wpisie dokonamy takiej migracji i zobaczymy jakie zmiany musimy poczynić, by nie doświadczyć problemów związanych z tą migracją nazw.

Cache DNS, czyli włączenie buforowania zapytań

Większość z nas wie, że standardowe instalacje systemu linux nie buforują żadnych zapytań do serwerów DNS. Dzieje się tak dlatego, że te systemy domyślnie nie mają zainstalowanego żadnego oprogramowania, które by im to umożliwiało. Niesie to ze sobą zwiększenie opóźnień transakcji krótkoterminowych, np. tych w protokole http czy https. Za każdym razem gdy odwiedzamy jakiś serwis www, musimy wykonać szereg zapytań DNS, by rozwiązać nazwy domen na adresy IP. W przypadku gdybyśmy mieli cache DNS, to te nazwy nie musiałyby być za każdym każdym razem rozwiązywane na nowo, przynajmniej nie przez odpytywanie zdalnego serwera DNS, do którego RTT wynosi jakieś 20-40ms. Przydałoby się zatem nieco poprawić wydajność stron www i w tym wpisie postaramy się zaimplementować prosty cache DNS z wykorzystaniem narzędzia dnsmasq.

Czyszczenie konsoli TTY w systemd

Podczas uruchamiania się systemu, na ekranie zwykle widzimy szereg komunikatów. Informują nas one o tym jakie usługi są aktywowane oraz czy wystąpiły jakieś błędy. Po tym jak faza boot dobiegnie końca, wszystkie te informacje dalej są wyświetlane na konsoli TTY i możemy je podejrzeć po przyciśnięciu klawiszy Ctrl-Alt-F1 . W pewnych sytuacjach może to stwarzać zagrożenie bezpieczeństwa, bo są tam zawarte informacje o tym jakie usługi zostały uruchomione. Przydałoby się zatem wyczyścić tę konsolę TTY po załadowaniu się systemu i o tym będzie poniższy wpis.

Skrót Ctrl-Alt-Del w systemd

Po przesiadce z sysvinit na systemd okazało się, że system inaczej się zachowuje po przyciśnięciu kombinacji klawiszy Ctrl-Alt-Del . Niby za wiele nie zmieniałem w konfiguracji systemu ale w żaden sposób przy pomocy plików konfiguracyjnych nie szło zmienić zachowania tego powyższego skrótu. Okazuje się bowiem, że w systemd, akcję pod ten skrót przypisuje się w nieco innym miejscu niż to było robione w sysvinit. W tym wpisie postaramy się zmienić domyślne zachowanie tego skrótu, tak by po jego przyciśnięciu wyłączyć komputer.

Brak dźwięku przy nieaktywnej sesji logowania

Jeśli korzystamy z serwera dźwięku PulseAudio na swoim linux'ie, prawdopodobnie zdarzyła nam się już sytuacja, w której chcieliśmy zablokować lub wygasić ekran monitora mając jednocześnie odpalony jakiś odtwarzacz muzyki. Gdy tylko ekran zostanie zablokowany, możemy odnotować brak dźwięku, bo ten zwyczajnie natychmiast zamiera. Za to po odblokowaniu ekranu, dźwięk wraca. Podobnie sprawa ma się przy przejściu z trybu graficznego (Xorg) na jedną z konsol TTY.

Wyłączenie WoL w karcie sieciowej

WoL (Wake on LAN) to taki ficzer, który umożliwia włączenie komputera przez sieć. By tego typu sytuacja miała miejsce, zarówno karta sieciowa oraz płyta główna komputera musi wspierać WoL. Dodatkowo, BIOS maszyny musi mieć aktywowaną odpowiednią opcję. Obecnie WoL jest implementowany praktycznie w każdej płycie głównej i karcie sieciowej, także raczej możemy przyjąć, że nasz komputer może zostać wybudzony za pomocą kabla sieciowego. Stwarza to oczywiście zagrożenie bezpieczeństwa ale poza tym, w grę wchodzi także większy pobór energii. Jeśli nie korzystamy z WoL, to jest on dla nas zbędny i należałoby go wyłączyć.

Aplikowanie zmiennych sysctl przy pomocy udev'a

Kernele linux'owe mają dość sporo opcji, które możemy zmienić przy pomocy pliku /etc/sysctl.conf . Niby nic nadzwyczajnego ale co w przypadku tych zmiennych, które muszą być ustawione, z tym, że moduł, który stworzy odpowiednie ścieżki w katalogu /proc/sys/ , nie został załadowany z jakichś względów przy starcie systemu? Zmienne te nie zostaną ustawione, a w logu pojawi się komunikat informujący nas o nieodnalezieniu określonego pliku. Okazuje się, że jesteśmy w stanie aplikować określone ustawienia sysctl w momencie ładowania określonych modułów i temu mechanizmowi się przyjrzymy bliżej w tym wpisie.

Fragmentacja pakietu i zmiana wartości MTU

MTU (Maximum Transmission Unit) to maksymalna długość pakietu jaki może zostać przesłany przez sieć. Może ona wynosić do 64KiB ale większość punktów sieciowych, takich jak routery, wymusza o wiele mniejsze rozmiary pakietów. Domyślna wartość MTU dla protokołu Ethernet to 1500 bajtów, oczywiście bez nagłówka warstwy fizycznej, który ma dodatkowe 14 bajtów. Czasami te standardowe ustawienia mogą powodować problemy w przypadku pewnych konfiguracji sieci i gdy ich doświadczamy, przydałoby się zmienić rozmiar MTU przesyłanych pakietów.

PeerGuardian w oparciu o ipset i iptables

Wiele klientów torrent'a umożliwia ładowanie zewnętrznej listy z zakresami adresów IP i ta lista ma służyć jako swego rodzaju filtr połączeń chroniący nas przed różnego rodzaju organizacjami, które mogą zbierać i przetwarzać informacje na temat naszego IP i tego co on porabia w sieci p2p. Oczywiście, kwestia czy korzystać z takiego typu rozwiązania jest bardzo dyskusyjna i wiele osób jest zdania, że to tak naprawdę w niczym nie pomoże, a wręcz nawet przyczynia się do samounicestwienia sieci p2p. Także taki filter może czasem przynieść więcej szkody niż pożytku, zwłaszcza gdy się go używa lekkomyślnie, czyli na zasadzie, że ten co blokuje więcej adresów musi być lepszy. Poniżej opiszę wykorzystanie rozszerzenia ipset, przy pomocy którego zostanie zablokowany szereg klas adresów. Całość raczej nie skupia się na implementacji filtra, to tylko przykład do czego ipset może posłużyć, a że ja nie umiem teoretycznie pisać, to muszę na przykładach.