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.

Sieci bezprzewodowe w obecnych czasach to standard i nie ma chyba miejsca na ziemi gdzie nie dałoby rady ulokować routera WiFi, do którego można by podłączyć szereg urządzeń. Każdy kto próbował konfigurować sieć bezprzewodową na debianie, wie, że może to być bardzo upierdliwe, zwłaszcza jeśli mamy dostęp do wielu AP, które posiadają różne konfiguracje. Wynaleziono, co prawda, automaty, które mają pomagać w ogarnięciu tego całego bezprzewodowego zamieszania, np. network-manager czy wicd ale w przypadku lekkich stacji roboczych, które nie mają wgranego pełnego środowiska graficznego, a jedynie jakiś menadżer okien, np. Openbox, to instalacja tych powyższych narzędzi może zwyczajnie nie wchodzić w grę.

Ten wpis będzie poświęcony poprawie wydajności naszych systemów linux'owych. Okazuje się bowiem, że w pewnych aspektach ich pracy nie wszystko działa jak należy. Rozchodzi się o zmienną środowiskową TZ , w oparciu o którą to zwracane są, np. czasy utworzenia czy modyfikacji plików na dysku. Ten przypadek jest o tyle dziwny, że każdy z nas ma już na swojej maszynie skonfigurowany czas systemowy, za który odpowiada pakiet tzdata . Niby wyraźnie określiliśmy strefę czasową, w tym przypadku jest to Europe/Warsaw ale widać system operacyjny posiłkuje się odwołaniami do pliku /etc/localtime .

Poprzedni wpis był o sieciach bezprzewodowych, a konkretnie dotyczył on konfiguracji protokołu WPA Enterprise w oparciu o serwer freeradius. Ten post będzie w podobnym klimacie, z tym, że skupimy się tutaj na nieco innym podejściu to kwestii użytkowników, którzy mogą się łączyć do sieci WiFi. Ich konfiguracja nie zostanie praktycznie w żaden sposób ruszona, no może za wyjątkiem przeniesienia jej do bazy danych MySQL.

Poniższy wpis ma na celu stworzenie infrastruktury WiFi w oparciu o oprogramowanie freeradius zainstalowane na debianowym serwerze. Projekt zakłada wykorzystanie osobnego urządzenia NAS (AP), w tym przypadku jest to router TP-Link TL-WR1043N/ND v2, na którym jest zainstalowane oprogramowanie OpenWRT. W oparciu o te dwie maszyny spróbujemy skonfigurować protokół WPA2 Enterprise z obsługą trzech metod uwierzytelniania, tj. EAP-TLS, EAP-TTLS oraz PEAP (v0) . Będziemy również potrzebować kilku certyfikatów (w tym CA), bez których to pewne mechanizmy mogą nie działać.

Jakiś czas temu przedstawiłem manualny sposób na generowanie certyfikatów, które można z powodzeniem wykorzystać przy ssl, openvpn czy freeradius. Nie było tego znowu aż tak dużo ale jakby nie patrzeć trochę parametrów trzeba znać, a najlepiej mieć przygotowane odpowiednie linijki, by sam proces generowania certyfikatów przebiegł dość sprawnie. Jednak wychodzi na to, że nie trzeba się znowu aż tak wysilać, bo istnieją dedykowane narzędzia, które wygenerują nam wszystkie potrzebne pliki. Mowa o easy-rsa i to niego będzie dotyczył ten wpis.

Jakiś czas temu, na forum DUG'a wyczytałem coś o przesyłaniu logów systemowych przez sieć. W sumie, to nigdy mi to do głowy nie przyszło ale jeśli by się nad tym głębiej zastanowić, tego typu mechanizm może okazać się całkiem użyteczny. Na dobrą sprawę nie wiem jak to jest rozwiązane w debianie opartym o systemd, natomiast jeśli chodzi o inne init'y (openrc i sysvinit), to tego typu funkcjonalność można zaimplementować wykorzystując narzędzie rsyslog lub syslog-ng . W tym wpisie zostanie opisana konfiguracja debianowego serwera, na którym będzie nasłuchiwał daemon rsyslog . Dodatkowo, zostanie przedstawiona konfiguracja dwóch klientów, z których jeden będzie miał zainstalowanego syslog-ng , a drugi rsyslog . Z klientów logi zostaną przesłane do serwera. Dodatkowo, postaramy się zaszyfrować ruch przy pomocy kanału TLS.

Aktualizacja systemu to chyba jedna z bardziej podstawowych czynności, które przeprowadzamy niemalże codziennie. Tak się złożyło, że chwilę po zakończeniu tego procesu musiałem wyłączyć w pośpiechu komputer. Nie zdążyłem przy tym przeczytać uważnie informacji, które zwrócił mi terminal. Oczywiście mógłbym zahibernować maszynę i wrócić do logu instalacji w wolnej chwili ale nie zawsze hibernacja jest możliwa. Poza tym, na myśl przychodzą mi osoby, które często zakładają wątki na forach o tym, że aktualizacja uwaliła ich system. Zawsze w takiej sytuacji prosi się danego człowieka o podanie logu z aktualizacji systemu albo przynajmniej próbuje się wyciągnąć od takiego delikwenta informację na temat tego co było aktualizowane. W większości przypadków, taki człowiek nie ma o tym kompletnie pojęcia, a jak już, to podaje bardzo nieprecyzyjne dane. Ten post ma na celu ułatwienie znalezienia informacji o tym co było przedmiotem aktualizacji, tak by mieć nieco jaśniejszy obraz tego co mogło nawalić.

Ten kto tworzył kiedyś paczki .deb wie, że cały proces może w końcu człowieka nieco przytłoczyć. Paczka, jak to paczka, budowana jest ze źródeł i konfigurowana przez jej opiekuna. Z reguły ludzie instalują kompilowane programy via make install . Niektórzy idą o krok dalej i używają do tego celu narzędzi typu checkinstall . I wszystko jest w miarę w porządku, przynajmniej jeśli chodzi o utrzymywanie jednej paczki. Przeprowadzamy kompilację tylko raz, po czym instalujemy dany pakiet i zapominamy o nim. Niemniej jednak, tego typu postępowanie może doprowadzić nasz system na skraj niestabilności. W tym poście nie będziemy zajmować się zbytnio sposobem w jaki powinno się tworzyć paczki .deb , a jedynie tym jak je przechowywać. Do tego celu potrzebne jest nam repozytorium, które zbudujemy w oparciu o oprogramowanie reprepro .

W celu optymalizacji swojej pracy i poprawy wydajności przy transferze danych, dyski twarde często odczytują więcej sektorów niż było to określone w żądaniu. Chodzi o to, że odczytywany przez nas z dysku plik jest podzielony na sektory i gdy dysk odczytuje pierwszy sektor tego pliku, to wczytuje także kilka kolejnych sektorów zlokalizowanych za tym, którego żądanie odczytania zostało właśnie zrealizowane. Te dodatkowe sektory trafiają do wewnętrznego cache dysku twardego, z którego mogą zostać odczytane w późniejszym czasie, jeśli zajdzie taka potrzeba. Dostęp do danych w cache jest o wiele szybszy w porównaniu do repozycjonownia głowicy i odczytywania fizycznych sektorów na dysku. W efekcie czego mamy zwykle dość znaczny wzrost wydajności przy transferze danych. Ten mechanizm nosi nazwę readahead i w tym wpisie przyjrzymy mu się nieco bliżej.