Github to serwis, w którym użytkownicy mogą pracować wspólnie nad różnymi projektami utrzymywanymi w systemie kontroli wersji GIT. Konto w w/w serwisie może być łakomym kąskiem dla przestępców, zwłaszcza gdy uczestniczymy w dość rozbudowanych projektach i przyczyniamy się do ich tworzenia w dużym stopniu. Z tego powodu github implementuje rozwiązania, które mają na celu poprawić bezpieczeństwo naszej pracy. Mamy już uwierzytelnianie dwuetapowe, obsługę kluczy SSH ale nadal brakowało odpornego systemu, który by uwierzytelnił osoby współdziałające z nami. Chodzi o to, że wszelkie zmiany w repozytorium GIT muszą być przez kogoś poczynione. Każdy commit ma zatem swojego właściciela ale my nigdy nie mamy pewności co do tego, kto tak naprawdę tej zmiany dokonał. Dlatego też github umożliwił ostatnio podpisywanie tagów i commit'ów przy pomocy kluczy GPG. To właśnie temu tematowi będzie poświęcony niniejszy wpis.

Dzisiaj system plików jednej z partycji mojego głównego dysku uległ awarii z niewiadomych przyczyn. Dałbym sobie nawet głowę uciąć, że wszystkie partycje zostały poprawnie odmontowane podczas wyłączania maszyny. Niemniej jednak, z jakiegoś powodu podczas startu systemu, ten wyrzuca szereg komunikatów dotyczących głównego systemu plików, tj. / . Sam komunikat brzmi mniej więcej tak: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY . Oznacza to, że błędy w systemie plików nie są łatwe do naprawy i wymagana jest nasza ingerencja w ten proces. Przy sprawdzaniu systemu plików w poszukiwaniu błędów przy pomocy fsck.ext4 można było dostrzec min. taką wiadomość: Inode 556975 has corrupt extent header . Co ona tak naprawdę oznacza i czy damy radę wybrnąć z tej sytuacji bez szwanku?

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.

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".

Sporo użytkowników lunux'a, zwłaszcza dystrybucji debian, korzysta z własnych skryptów firewall'a aplikujących reguły iptables . Tego typu rozwiązanie ma jednak swoje wady i zalety. Niewątpliwie do zalet można zaliczyć brak dodatkowego oprogramowania obsługującego zaporę sieciową. Jeśli chodzi zaś o wady, to niestety cały skrypt trzeba sobie dobrze przemyśleć przed zaaplikowaniem. Ludzie często zapominają tutaj o śledzeniu połączeń przez kernel. To właśnie na podstawie wpisów w /proc/net/ip_conntrack lub /proc/net/nf_conntrack system wie, które pakiety należy na zaporze przepuścić, a które zablokować. Jeśli teraz dodajemy reguły do filtra iptables , to nowa polityka zapory nie będzie odnosić się do tych nawiązanych już połączeń, które są określone w tablicy conntrack'a. By się upewnić, że tego typu scenariusz nigdy nas nie spotka, musimy tę tablicę opróżnić.