W dobie całego tego świata informatycznego zwykliśmy polegać na osobach, których nigdy w życiu na oczy nie wiedzieliśmy, nie wspominając o jakimkolwiek kontakcie fizycznym. Zaufanie to obecnie chyba najbardziej krytyczna luka bezpieczeństwa jeśli chodzi o oprogramowanie, z którego korzystamy na co dzień. My, którzy używamy debiana w swojej pracy, polegamy na mechanizmach jakie oferuje nam apt czy aptitude przy weryfikacji pakietów przed ich instalacją w systemie. Co się jednak by stało gdyby w tych menadżerach pojawił się błąd, który by uniemożliwiał poprawną weryfikację pakietów? Skąd wiemy czy te mechanizmy zabezpieczające w ogóle działają? Może one nam dają jedynie fałszywe poczucie bezpieczeństwa, a tak naprawdę przez niczym nas nie chronią? W tym wpisie postaramy się odpowiedzieć na te powyższe pytania i sprawdzimy czy manualna weryfikacja pakietu jest w ogóle możliwa

Obecnie systemy operacyjne stają się nieco bardziej stabilne i czasy, w których reinstalacja takiego systemu, czy też nawet format dysku, odchodzą powoli w niebyt. Data instalacji mojego linux'a wskazuje na prawie 2 lata wstecz. Jakby nie patrzeć jest to szmat czasu, w czasie którego przez mojego Debiana przetoczyła się ogromna ilość oprogramowania. Nie zawsze były to pakiety, które pochodziły z głównych repozytoriów tej dystrybucji. Niemniej jednak, każde repozytorium z pakietami jest podpisane i by móc z nich bezpiecznie korzystać, trzeba pozyskać klucz GPG i dokonać jego weryfikacji. Prędzej czy później przyjdzie czas, gdy takie klucze GPG przestaną być ważne lub też zmianie ulegną źródła pakietów. W ten sposób baza danych kluczy zawierać będzie szereg zbędnych pozycji. Może wielu ludziom nie przeszkadza ten fakt ale raz na jakiś czas przydałoby się oczyścić keyring ze śmieci, które są już nam do niczego niepotrzebne.

Bardzo wielu ludzi nie uświadamia sobie faktu, że w przypadku komputerów praktycznie wszystkie dane, z którymi mamy styczność, są zapisane za pomocą dwóch znaków, tj. 0 i 1. Mając to na względzie, nie ma chyba informacji, której by nie można było przesłać przez sieć. Serwer dźwięku, jak sama nazwa wskazuje, jest w stanie odbierać dane zawierają informacje dźwiękowe. Dlatego też jeśli jakiś komputer nie posiada karty muzycznej lub/i nie jest fizycznie podłączony do głośników, to nie stanowi to większego problemu by był on w stanie odtwarzać dźwięk, przynajmniej w tym sensie jakim my to rozumiemy. W tym wpisie sþróbujemy zrealizować przesyłanie dźwięku przez sieć wykorzystując do tego PulseAudio i zobaczymy czy sprawi nam to jakieś problemy.

W obecnych czasach powoli się odchodzi od stosowania technologi flash w przeglądarkach. Na dobra sprawę, po tym jak google w youtube przesiadł się na html5, to korzystanie z flash player'a nie ma już większego sensu. Są jednak serwisy, które nie nadążają za zmieniającą się rzeczywistością i w ich przypadku przejście z flash'a na html5 może jeszcze zająć kilka lat. Zatem nawet jeśli nie korzystamy z flash'a na co dzień, to i tak większość z nas będzie chciała go mieć w systemie, tak na wszelki wypadek, by nie być pozbawionym możliwości oglądania materiałów video na tych drugorzędnych serwisach. Jako, że wtyczka flash jest bardzo dziurawa, przydałoby się ją nieco skonfigurować i w tym wpisie zostanie przedstawionych szereg opcji, które można umieścić w pliku mms.cfg .

Jakiś czas temu opisywałem konfigurację dla menadżera pakietów apt i aptitude w pliku apt.conf. Ten wpis również tyczy się konfiguracji wspomnianych menadżerów, z tym, że zostanie tutaj opisana pewna funkcjonalność, która może nam zaoszczędzić trochę czasu przy aktualizacji systemu. Chodzi o to, że pakiety praktycznie zawsze muszą być pobrane na dysk przed ich instalacją. Gdy nie dysponujemy dobrym pod względem przepustowości łączem, proces pobierania pakietów jest zwykle dłuższy niż sama ich instalacja. Przydałoby się zatem zaprogramować pobieranie plików w tle, tak by nie musieć ich pobierać tuż przez przed procesem instalacyjnym.

Praktycznie każdy z nas korzysta z menadżera pakietów apt lub też jego nakładki aptitude . Operowanie na debianie bez tych narzędzi raczej by nam nieco utrudniło życie. Sporo osób ogranicza się jedynie do podstawowych poleceń, typu update , upgrade czy dist-upgrade , pomijając przy tym całą konfigurację w/w narzędzi. W tym wpisie zostanie zaprezentowanych szereg opcji, które można zdefiniować na stałe w pliku konfiguracyjnym /etc/apt/apt.conf , tak by nie trzeba było ich ciągle wpisywać w terminalu ilekroć tylko korzystamy któregoś menadżera pakietów.

Na forum DUG'a znów został poruszony ciekawy wątek, tym razem odnośnie usunięcia całego środowiska graficznego z systemu. Pozornie niby nic nadzwyczajnego, przecie każdy z nas potrafi odinstalować szereg pakietów via apt czy aptitude . Problematyczne za to mogą się okazać zależne pakiety, które nie zostaną automatycznie usunięte wraz z konkretnym metapakietem od środowiska graficznego. Jak zatem usunąć te pozostałości?

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

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 .