Debian posiada bardzo rozbudowany system robienia pakietów. Generalnie rzecz biorąc, to wszystkie z nich musiały przejść przez ten proces zanim trafiły do głównego repozytorium dystrybucji. Dzięki takiemu stanu rzeczy, nie musimy ręcznie powielać pracy szeregu innych osób i odpada nam własnoręczna kompilacja pakietów, a wszyscy wiemy, że zajmuje ona cenny czas i zasoby. Paczki .deb są tworzone ze źródeł i instalowane przy pomocy menadżera pakietów aptitude/apt/dpkg . Nic jednak nie stoi na przeszkodzie by daną aplikację skompilować sobie ręcznie i zainstalować ją przy pomocy make install . Problem w tym, że w taki sposób robi się śmietnik w naszym systemie i śledzenie wszystkich zainstalowanych w ten sposób pakietów w pewnym momencie stanie się wręcz niemożliwe. Dlatego też przydałby nam się mechanizm, który ułatwiłby nam nieco to zadanie. Debian udostępnia szereg narzędzi, które są w stanie w pełni zautomatyzować cały ten proces budowy pakietów. Ten poradnik zaś ma na celu zebranie wszystkich istotniejszych informacji związanych z obsługą narzędzi takich jak dh_make , dpkg-buildpackage , pbuilder , quilt czy lintian , tak by tworzyć pakiety w prosty sposób i przy tym równając do najwyższych standardów debiana.

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.

Przeglądając sobie FAQ dotyczący urządzeń USB natknąłem się na punkt, który opisywał parametr max_sectors . Niby nic wielkiego, w linux'ie jest przecie pełno przeróżnych opcji, przy pomocy których jesteśmy w stanie zmienić szereg aspektów pracy naszego systemu operacyjnego. Rzecz w tym, że parametr max_sectors potrafi nawet dość znacznie poprawić wydajność urządzeń USB, w tym tych wszystkich pendrive'ach, w których prędkość zapisu pozostawia wiele do życzenia. W tym wpisie postaramy się nieco dostosować ten parametr, tak by przyśpieszyć transfer kopiowanych plików.

Budowanie samych profili dla AppArmor'a nie jest jakoś szczególnie trudne, zwłaszcza, gdy do tego celu wykorzystujemy narzędzia dostępne w pakiecie apparmor-utils . Dobrze jest jednak prześledzić sobie manual AppArmor'a oraz to, co twórcy piszą na swojej stronie w oficjalnej dokumentacji projektu. Poniższy wpis powstał w celu zrozumienia składni profili AppArmor'a, tak by jeszcze bardziej uprościć proces ich budowania.

Opis składni znajdujący się poniżej został zaczerpnięty z wiki AppArmor'a. Część z poniższych informacji może nie mieć zastosowania w przypadku starszych wersji samego AppArmor'a.

Całkowite usuwanie plików (shred) jak i zerowanie całych nośników ma na celu nieodwracalne zniszczenie danych. W tych podlinkowanych artykułach próbowaliśmy zatrzeć ślady po skasowanych plikach. W tym wpisie zaś prześledzimy sobie co tak naprawdę się dzieje po utworzeniu i skasowaniu pliku, a także spróbujemy odzyskać te z nich, które już nie istnieją w naszym systemie. Ten artykuł będzie dotyczył jedynie systemu plików z rodziny ext , głównie ext4 .

Chciałem dziś wypakować sobie kilka plików, które były zebrane w paczkę .zip . Problem w tym, że ta osoba, co te pliki pakowała, najwyraźniej robiła to na widnowsie no i nie użyła standardowego kodowania, które jest wykorzystywane na każdym innym systemie, tj. UTF-8. Wobec tego, wszystkie pliki mają w swoich nazwach znaczek � w miejscu polskich liter. Jako, że tych plików jest dość dużo, to odpada ręczna edycja nazw i trzeba pomyśleć nad jakimś innym rozwiązaniem. Zmiana kodowania nazw plików, to nie jest to samo co zmiana kodowania zawartości tych plików. Na szczęście w linux'ie mamy do dyspozycji narzędzie convmv , które jest w stanie, jak sama nazwa mówi, przepisać nazwy plików ustawiając przy tym odpowiednie kodowanie.

W pewnych skrajnych przypadkach może się nam zdarzyć tak, że zapomnimy hasła do konta administratora systemu. Jak wiadomo bez użytkownika root w naszych linux'ach nie da się zbytnio nic zrobić. Na pewno nie da się przeprowadzić żądnych prac administracyjnych. Zwykle w takim przypadku moglibyśmy przeinstalować system i ustawić nowe hasło ale to wydaje się lekką przesadą. Poza tym, co w przypadku gdy nie możemy zwyczajnie zainstalować na nowo systemu lub nie mamy akurat pod ręką płytki czy pendrive live? Czy w linux'ie jest w ogóle możliwość odzyskania hasła użytkownika root bez rozkręcania komputera biorąc pod uwagę te wszystkie mechanizmy bezpieczeństwa, które czynią ten system tak bezpiecznym? Oczywiście zmiana hasła do konta administratora jest możliwa i nawet nie trzeba się przy tym zbytnio wysilać.

Zerowanie dysku twardego ma na celu usunięcie wszystkich znajdujących się na nim danych. Generalnie chodzi o zapisanie całej powierzchni danego nośnika samymi zerami. Ten proces różni się znacząco of formatowania dysku, czyli utworzenia nowego systemu plików, gdzie praktycznie wszystkie dane można bez większego problemu odzyskać. Zerowanie dysku (czy też pendrive) może w pewnych przypadkach naprawić logiczne błędy sektorów na dysku. Niemniej jednak, nie usuniemy za jego pomocą fizycznych bad'ów. Generalnie rzecz biorąc, mamy do wyboru dwie techniki zerowania. Jedna jest dokonywana na poziomie programowym, np. przy pomocy dd , druga zaś na poziomie sprzętowym, np. w hdparm . W tym wpisie postaramy się wyzerować przykładowy dysk.

W przypadku, gdy musimy pozbyć się jakiegoś pliku, który znajduje się na dysku, to nie jest zalecane korzystanie z narzędzia rm . Usuwa ono jedynie odnośnik do pliku, który go identyfikuje w strukturze systemu plików, tzw. i-węzeł (i-node). To co uzyskujemy za pomocą takich narzędzi jak rm , to jedynie oznaczenie pewnych bloków (tych od pliku) jako wolne, w których system operacyjny będzie w stanie dokonać zapisu danych późniejszym czasie. Podczas tej operacji nie są usuwane żadne informacje z dysku, a mając na uwadze ten fakt, możemy bez problemu tak "usunięty" plik odzyskać. By mieć pewność, że plik zostanie trwale zniszczony, trzeba go ponownie napisać, np. przy pomocy shred, który standardowo jest dostępny w każdej dystrybucji linux'a i to jemu będzie poświęcony ten wpis.

W pliku /etc/passwd jest przechowywana baza danych kont użytkowników w systemie linux. Z kolei w /etc/group mamy wypisane wszystkie grupy oraz powiązanych z nimi użytkowników. Generalnie rzecz biorąc, to te dwa pliki odpowiadają za konfigurację kont. Problem jednak zaczyna się w momencie gdy w grę wchodzą hasła, zarówno do kont jak i do grup. Gdyby były one trzymane w tych plikach, nie byłyby one w żaden sposób szyfrowane. Dlatego też powstał inny mechanizm, który ma na celu przeniesienie zahashowanych haseł do plików /etc/shadow i /etc/gshadow . W debianie użytkownikami i grupami możemy zarządzać przy pomocy odpowiednich narzędzi, które automatycznie dostosują wszystkie powyższe pliki. Nic jednak nie stoi na przeszkodzie aby edytować każdy z nich ręcznie. Problemy mogą się pojawić w momencie, gdy te pliki będą zawierać różne wpisy, np. w pliku passwd będzie określony użytkownik, który jednocześnie nie będzie istniał w pliku shadow , podobnie z grupami. W tym wpisie postaramy się sprawdzić te pliki i upewnimy się czy aby na pewno jest z nimi wszystko w porządku.