W każdym systemie operacyjnym cała masa procesów rywalizuje ze sobą o zasoby, w skład których wchodzą min. pamięć operacyjna RAM, procesor i operacje I/O dysku twardego. Czasami zdarza się tak, że niektóre aplikacje są w stanie zdusić inne programy, bo mają zbyt duże wymagania co do zasobów systemowych. W takich przypadkach administrator systemu powinien zatroszczyć się o przydział zasobów konkretnym procesom. W linux'ie do tego typu prac przeznaczony jest mechanizm cgroups obecny w kernelu. Niemniej jednak, jeśli cgroups przerasta nasze umiejętności albo też z jakiegoś powodu nie możemy z niego korzystać, to istnieje inne rozwiązanie, które może nam pomóc ograniczyć zasoby przydzielane procesom przez nasz system. Chodzi generalnie o narzędzia nice/renice (procesor) , ionice (dysku twardy) , taskset (przypisanie procesu do konkretnego procesora) oraz trickle (sieć). W tym wpisie zobaczymy jak przy pomocy tych powyższych narzędzi limitować procesy systemowe.

Routery WiFi, zwłaszcza te na podzespołach firmy Qualcomm, mają zwykle bardzo dobre wsparcie w alternatywnym firmware OpenWRT. Te bezprzewodowe routery posiadają na pokładzie zwykle jedną lub dwie karty WiFi, w zależności od obsługiwanego pasma (2,4 GHz i/lub 5 GHz). Karty tych routerów działają standardowo w trybie AP (Access Point), czyli punktu dostępowego. W taki sposób jesteśmy w stanie bezprzewodowo połączyć szereg urządzeń w sieci domowej z internetem. Niemniej jednak, karta WiFi może pracować w kilku innych trybach. W tym wpisie zobaczymy jak przełączyć kartę WiFi routera w tryb MONITOR.

Ten poniższy artykuł ma na celu pokazanie w jaki sposób stworzyć infrastrukturę WiFi w oparciu o oprogramowanie freeradius (serwer RADIUS), które zostanie zainstalowane na przykładowym routerze TP-Link Archer C7 v2. Router ma wgrany firmware OpenWRT Chaos Calmer w wersji 15.05.1 (r49294). Zostanie tutaj opisane dokładnie jak wdrożyć protokół WPA2 Enterprise z obsługą trzech metod uwierzytelniania: EAP-TLS, EAP-TTLS oraz PEAP (v0) .

Jak wiele osób zapewne wie, szereg dystrybucji linux'a wykorzystuje dhclient w celu pobrania sieciowej konfiguracji hosta za sprawą protokółu DHCP. W zasadzie cała konfiguracja tego narzędzia sprowadza się do określenia szeregu opcji w pliku /etc/dhcp/dhclient.conf . W debianie nawet nie musimy dotykać tego pliku, by wszystko działało nam jak trzeba. Niemniej jednak, czasem konfiguracja interfejsów sieciowych może wymagać od nas dodatkowych zabiegów. W celu ułatwienia życia adminom dodano obsługę skryptów shell'owych (dhclient-script). Taki skrypt jesteśmy w stanie wywołać w zależności od zaistniałych zdarzeń protokołu DHCP. W tym wpisie zostanie pokazane w jaki sposób te skrypty możemy utworzyć i wykorzystać.

Konfiguracja maszyn w sieci za sprawą protokołu DHCP znacznie ułatwia życie administratorom. Cały ten proces jest nie tylko szybszy ale też eliminuje szereg błędów, które mogą pojawić się za sprawą czynnika ludzkiego. W przypadku, gdy nasza maszyna dysponuje kilkoma interfejsami sieciowymi, to każdy z nich możemy skonfigurować nieco inaczej. Oczywiście, nie chodzi o samą konfigurację adresacji ale o szereg parametrów, które klient przesyła do serwera DHCP. To dzięki nim host min. wie jak ustawić adresację na interfejsie i pod jaki adres słać zapytania DNS. Każdy interfejs może w ten sposób posiadać własne opcje, które klient DHCP będzie przesyłał do serwera. W tym artykule postaramy się konfigurować niezależnie dwa interfejsy sieciowe przy pomocy dhclient , czyli domyślnego klienta DHCP w linux'ie.

W linux'ie wszystko może być reprezentowane za pomocą pliku. Te pliki są tworzone, zmieniane i usuwane praktycznie non stop podczas pracy systemu operacyjnego. Zwykle też nie zwracamy uwagi na metadane opisujące pliki w systemie plików, bo przecie bardziej interesuje nas ich zawartość. Niemniej jednak, w pewnych sytuacjach te metadane mogą się okazać bardzo użyteczne. Weźmy sobie przykład partycji /home/ . Prawie zawsze po odpaleniu aplikacji są tworzone na niej nowe pliki lub zmieniane te już istniejące. Jako, że nie zawsze wiemy na jakich plikach operuje dany program, to moglibyśmy przeszukać pliki w katalogu domowym użytkownika i poddać analizie ich czas modyfikacji. Taką operacje możemy przeprowadzić przy pomocy polecenia find i w tym wpisie zobaczymy jak tego dokonać.

cron to takie linux'owe narzędzie, które cyklicznie, co pewien ustalony interwał czasu, wykonuje jakieś zaplanowane zadania. Minimalna wartość tego interwału to jedna minuta. Niemniej jednak, bardzo wielu użytkowników linux'a zastanawia się w jaki sposób wywołać określone zadanie, np. co 5, 10, 15, 30 minut, czy nawet co 2, 6 albo 12 godzin. Dlatego właśnie powstał ten wpis, by nieco przybliżyć mechanikę samego cron'a.

Systemy plików, które wykorzystujemy na partycjach swoich dysków, zawierają metadane opisujące pliki. Domyślnym systemem plików w większości linux'ów (do nich zalicza się też debian) jest EXT4. Gdy listujemy pliki przy pomocy narzędzia ls , jesteśmy w stanie uzyskać szereg informacji opisujących konkretny plik. Mamy tam min. czas ostatniej modyfikacji i-węzła (i-node), czyli tzw. ctime . Narzędzia takie jak stat są w stanie podać również inne czasy, tj. atime (ostatni czas dostępu do pliku) oraz mtime (ostatni czas modyfikacji pliku). Jednak żaden z tych powyższych nie przekłada się na czas utworzenia pliku. Co prawda, po stworzeniu pliku, wszystkie te czasy są ze sobą zsynchronizowane ale po przeprowadzeniu szeregu różnych operacji na tym pliku, problematyczne może być ustalenie pierwotnej daty jego utworzenia. Celem tego artykułu jest pokazanie, jak przy pomocy debugfs uzyskać czas utworzenia dowolnie wskazanego pliku w systemie plików EXT4.

Jakiś czas temu pisałem o implementacji tmux'a na debianie. Dla tych, którzy nie za bardzo wiedzą czym tmux jest, to wyjaśniam, że jest to narzędzie, które min. potrafi dzielić okno terminala na kilka mniejszych okienek. W ten sposób możemy korzystać ze swojego ulubionego terminala i cieszyć się funkcjonalnością znaną choćby z terminatora. Ta umiejętność dzielenia okien w tmux idealnie współgra z FZF (fuzzy finder). Jest to narzędzie, które pomaga min. przeszukiwać historię poleceń shell'a. BASH czy ZSH są, jakby nie patrzeć, dość ograniczone pod tym względem. Może i ZSH nieco lepiej radzi sobie z odnajdywaniem poleceń w historii od BASH ale i tak jego umiejętności pozostają daleko w tyle za FZF. Dlatego też w tym artykule spróbujemy sobie zainstalować ten cały "fuzzy finder".

Na dużych dystrybucjach linux'a adres MAC można zmienić bez problemu. Podobnie sprawa ma się w przypadku automatycznego generowania takiego adresu MAC za każdym razem, gdy chcemy nawiązać połączenie z internetem. W OpenWRT rozwiązanie tego zadania nie jest tak oczywiste jak, np. na debianie, ale też znowu nie jest niemożliwe. W repozytorium OpenWRT mamy dostępny pakiet macchanger . Niemniej jednak, w przypadku routerów o małych pamięciach flash, instalowanie dodatkowych pakietów może nie być dobrym pomysłem. Przydałoby się zatem zaprojektować mechanizm generowania i zmiany adresu MAC interfejsu WAN za każdym razem, gdy będziemy resetować router i to zadanie postaramy się zrealizować w tym artykule.