Od zawsze podobały mi się czcionki windosowskie ale po przejściu na linux'a okazało się, że tutaj fonty wyglądają zupełnie inaczej i co mogło zdziwić, nie było w standardzie tych moich ulubionych, tj. Arial, Times New Roman i Courier New. Przez szereg lat miałem obecną w systemie dość dziwną konfigurację dla fontconfig'a, która działała na takiej zasadzie, że te czcionki aplikacji były w prządku, natomiast te pobierane z serwisów www (np. w Firefox'ie) dość słabo się renderowały i bez przeprowadzania kilku zabiegów były one zwyczajnie nieczytelne. Postanowiłem w końcu poczytać trochę dokumentacji na temat tego jak wygląda konfiguracja czcionek w debianie i po kilku dniach udało mi się osiągnąć dość zadowalające efekty wizualne.

Podczas procesu kompilacji pakietów często zdarza się tak, że brakuje jakichś zależności, bez których dany pakietów nie chce się nam zbudować. W większości przypadków, system powinien nam podpowiedzieć jaki pakiet powinniśmy doinstalować. Nie zawsze jednak będzie to takie oczywiste i jedyne co nam zostanie zwrócone, to ścieżka danego pliku lub tylko jego nazwa. Nawet jeśli nie kompilujemy programów, to podczas zwykłego użytkowania komputera możemy potrzebować odnaleźć pakiet, który zawiera pewien określony plik binarny czy konfiguracyjny. Jak zatem odnaleźć się w gąszczu plików i katalogów by efektywnie ustalić pakiet, który zawiera interesujące nas pliki?

Wiele linux'owych klientów torrent'a umożliwia ładowanie zewnętrznej listy z zakresami adresów IP i ta lista ma służyć jako swego rodzaju filtr połączeń chroniący nas przed różnego rodzaju organizacjami, które mogą zbierać i przetwarzać informacje na temat naszego IP i tego, co on porabia w sieci p2p. Oczywiście, kwestia czy korzystać z takiego typu rozwiązania jest bardzo dyskusyjna i wiele osób jest zdania, że to tak naprawdę w niczym nie pomoże, a wręcz nawet przyczynia się do samounicestwienia sieci p2p. Także taki filtr może czasem przynieść więcej szkody niż pożytku, zwłaszcza gdy się go używa lekkomyślnie, czyli na zasadzie, że ten który blokuje więcej adresów IP musi być lepszy. Poniżej zostanie opisane rozwiązanie zakładające wykorzystanie rozszerzenia ipset , które w połączeniu z iptables da nam w pełni działający filtr połączeń p2p (coś na wzór popularnego oprogramowania PeerGuardian), dzięki któremu będziemy w stanie wyciąć dowolny ruch i to nie tylko przy korzystaniu z różnych klientów torrent, np. qbittorrent, ale także i przy zwykłym przeglądaniu stron www.

W dobie NSA, podsłuchów rządowych i wszelkiego rodzaju pogwałcenia prawa do prywatności, ludzie wymyślili VPN. VPN to nic innego jak tunel łączący dwie odległe od siebie maszyny, które chcą wymieniać ze sobą dane w sposób uniemożliwiający osobom trzecim podejrzenie całej tej komunikacji. Zalety korzystania z takiego dobrodziejstwa natury są oczywiste. Można obejść cenzorów, gdyż cały ruch z naszej maszyny jest przesyłany do serwera w postaci szyfrowanej, a dopiero z tego serwera sygnał idzie dalej w świat. Jest wiele komercyjnych usług, które za drobną opłatą mogą zapewnić nam tego tupu usługi ale ja nie będę tutaj się o nich rozpisywał. Bez problemu można je znaleźć w góglu. My tutaj za to zajmiemy się VPN jaki zapewnia riseup. By móc korzystać z ich usług, trzeba założyć na ich stronie konto, a to z kolei jest przyznawane tym, którzy w jakiś sposób działają na rzecz szeroko pojętej wolności. Ja wysłałem zgłoszenie i konto zostało mi przyznane. Dlatego też opiszę jak wygląda konfiguracja VPN na ich przykładzie.

Narzędzie gpg posiada swój własny plik konfiguracyjnych, który zwykle jest zlokalizowany w ~/.gnupg/gpg.conf . Można w nim sprecyzować większość z opcji, które zwykle są podawane w terminalu przy wywoływaniu polecenia gpg . Po zdefiniowaniu odpowiednich wpisów w pliku konfiguracyjnym, nie będziemy musieli już wyraźnie podawać tych parametrów ilekroć będziemy chcieli skorzystać z gpg . Przy okazji szukania info o kluczach GPG, natknąłem się na dość ciekawy artykuł na temat GnuPG. Jest tam sporo informacji, które są wielce użyteczne w procesie konfiguracji tego narzędzia poprawiając tym samym dość znacznie bezpieczeństwo komunikacji.

Zapuszczając się w coraz to i głębsze warstwy systemu podczas dążenia do zbadania jak on tak naprawdę działa, zacząłem się stykać z regułami udev'a (tymi umieszczanymi w katalogu /etc/udev/rules.d/ ). Jako, że nazbierało mi się już ich kilka, zaistniała potrzeba przebadania tego co ten katalog tak naprawdę zawiera. Na dobrą sprawę nigdy się nad tym nie zastanawiałem, jedynie kopiowałem rozwiązania z internetu i wklejałem je do odpowiedniego pliku i jeśli ono działało, to odznaczałem problem jako rozwiązany. Zwykle takich reguł się nie potrzebuje, temu praktycznie niewielu ludzi w ogóle się orientuje jak ogarnąć tego całego udeva. Są przypadki kiedy przepisanie nazw urządzeń czy wykonanie określonych akcji po podłączeniu jakiegoś sprzętu do komputera jest wielce niezbędne i nie ma innej opcji jak tylko zrozumieć co udev tak naprawdę robi.

Linuxy mają tę właściwość, że bardzo ciężko jest stracić do któregoś z nich dostęp, nawet w przypadku kompletnego zawału systemu. Jeżeli dysponujemy jakimś alternatywnym środowiskiem w postaci płytki live cd/dvd czy pendrive albo też posiadamy gdzieś zainstalowanego innego linuxa, to istnieje spore prawdopodobieństwo, że uda się nam reanimować nasz główny system. Wszystko za sprawą narzędzia jakim jest chroot , przy którego to pomocy możemy zmienić główny katalog systemu plików ( / ) dla wykonywanych procesów bez potrzeby przechodzenia całej skomplikowanej procedury uruchamiania systemu operacyjnego. Jeśli tylko uda nam się uzyskać dostęp do shella, to nie ma takiej możliwości by system nie stanął na nogi.

Systemy live mają jedną ale za to dość dającą się odczuć wadę, mianowicie chodzi o to, że po wypaleniu takiego obrazu, nie mamy możliwości zachowania zmian. Nawet jeśli doinstalujemy nowy pakiet czy wyedytujemy jakiś plik, to zmiany wprowadzone przez nas są jedynie tymczasowe, bo dokonywane w pamięci operacyjnej RAM. W efekcie jeśli uruchomimy taki system ponownie, będziemy zmuszeni przeprowadzać raz jeszcze wszystkie poprzednie czynności pod kątem jego dostosowania. W przypadku cd/dvd nie mamy praktycznie żadnego pola manewru. Inaczej jednak ma się sprawa jeśli chodzi o pendrive, bo tutaj możemy utworzyć osobną partycję, gdzie będą przechowywane wszystkie zmiany jakich dokonamy.

Jeśli zamierzamy kupić sprzęt, który dopiero co trafił na półki w sklepach, to prawdopodobnie zaraz po podłączeniu go do naszego komputera okaże się, że to urządzenie nie jest nawet wykrywane przez system operacyjny. W przypadku gdy jego producent zapewnia w miarę przyzwoity support, to być może problemy, których doświadczamy, zostaną rozwiązane wraz z instalacją najnowszego kernela. Co jednak w przypadku gdy nawet po aktualizacji kernela nie jesteśmy w stanie odpalić, np. nowo zakupionej karty WiFi? Jako, że te wszystkie sprzęty działają w oparciu określone moduły, wystarczy taki moduł pozyskać, skompilować i załadować w systemie. Problem w tym, że z każdą nową wersją jądra operacyjnego, która trafi do repo debiana, będziemy musieli ręcznie budować moduł na nowo i właśnie w tym artykule opiszę jak nauczyć system, by sam przeprowadzał tę mozolną czynność bez naszego udziału.