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.

Wszystkie główne dystrybucje, a może raczej ich środowiska graficzne, wykorzystują do odtwarzania dźwięku serwer PulseAudio. Niektóre wręcz są tak z nim zżyte, że nie idzie ich oddzielić od siebie. Ja generalnie uważam, że ten kawałek oprogramowania jest jak najbardziej przydatny człowiekowi i potrafi realizować kilka kwestii, które bez niego, albo by nie były możliwe do osiągnięcia, albo trzeba by się natrudzić przy ich implementacji, np. przesyłanie dźwięku przez sieć. U siebie na debianie nigdy nie miałem większych problemów z PulseAudio, z kolei zaś te, które się przytrafiały na drodze jego użytkowania, szło w miarę prosty sposób wyeliminować. Jest jednak jeden problem, z którym prawdopodobnie spotkaliśmy się wszyscy, przynajmniej jeśli wykorzystujemy mikrofon w stopniu większym niż przeciętny użytkownik komputera. Chodzi o to, że po odpaleniu pewnych aplikacji (lub też i w trakcie ich działania), takich jak np. Skype, Mumble, czy TeamSpeak3, dźwięk we wszystkich pozostałych programach potrafi zwyczajnie zdechnąć.

Na stronie Apache jest kawałek ciekawego artykułu na temat zagrożeń jakie niesie ze sobą stosowanie pliku .htaccess w katalogach stron trzymanych na serwerze wwww. Oczywiście, w pewnych sytuacjach, takich jak np. hostingi, nie będziemy mieć innego wyboru jak zdać się na ten plik ale jeśli mamy bezpośredni dostęp do konfiguracji Apache, możemy przenieść wszystkie te wpisy z pliku .htaccess i poprawić tym bezpieczeństwo witryny jak i po części wydajność samego serwera www.

Mając na stronie www formularze logowania czy rejestracji (ewentualnie panele administracyjne), rozmyślnym krokiem jest implementacja protokołu SSL/TLS. Jeśli mamy potrzebę, możemy także pokusić się o zaszyfrowanie całego ruchu w obrębie naszej witryny. Problem w tym, że odwiedzający naszą stronę użytkownicy mogą korzystać z linków, czy wpisywać adresy, które nie rozpoczynają się od https:// , a jedynie od http:// . W takim przypadku, nawet jeśli szyfrujemy ruch w serwisie, to odwiedzenie tego typu adresu zwróci nam stronę kanałem nieszyfrowanym, co może godzić w bezpieczeństwo samej strony jak i również w naszą/czyjąś prywatność. W tym krótki artykule spróbujemy tak skonfigurować serwer Apache2, by przekierował tego typu zapytania i słał je szyfrowanym tunelem.

Jak donoszą ostatnio media, mamy kolejną dziurę (logjam) dotyczącą szyfrowania SSL/TLS, a konkretnie rozchodzi się o powszechnie stosowany na całym świecie protokół Diffiego-Hellmana . I znów jest podobny scenariusz, bo ten problem nie powinien mieć miejsca ale z powodu wstecznej kompatybilności, tj. zapewnienie wsparcia dla wszystkich tych przestarzałych szyfrów tak by te przedwieczne systemy/maszyny mogły działać, można doprowadzić do osłabienie mechanizmów, które powinny być wykorzystywane obecnie. OK, może nie tyle osłabić, co wykorzystać te słabsze odpowiedniki zamiast tych mocniejszych.

W tym artykule zostanie przedstawiony sposób na wykorzystanie kluczy GPG w przypadku przeprowadzanych działań w repozytorium GIT. Będziemy w ten sposób w stanie podpisać swoje commit'y czy tagi, by było wiadomo, że zmiany, które zostały poczynione pochodzą naprawdę od konkretnego użytkownika. Oczywiście to może się wydać przesadą dla wielu ludzi ale skoro mamy udostępnioną możliwość wykorzystania kluczy GPG, to czemu z tej opcji nie skorzystać? Potrzebne będą nam tylko klucze GPG. Sposób ich tworzenia jak i konfiguracja zdefiniowana w pliku gpg.conf nie zostaną tutaj opisane. Zamiast tego skupimy się jedynie na implementacji samych kluczy GPG.

W końcu przyszedł czas na eksperymenty z serwisem GitHub. Jakby nie patrzeć, do tej pory jedyne co potrafiłem zrobić w przypadku samego gita, to wydać jedno polecenie, którym było git clone . Wszelkie inne rzeczy, choć nie było ich wcale tak dużo, robiłem via panel www, co trochę było upierdliwe. Postanowiłem nauczyć się obsługi gita i nieco uprościć sobie życie. Jeśli chodzi o samą naukę, to tutaj jest dostępny dość obszerny pdf (prawie 500 stron). Nie będę tutaj przerabiał wyżej podlinkowanej książki, bo w sumie jeszcze jej nie przeczytałem, tylko zajmę się ciekawym tematem jakim jest implementacja kluczy SSH, tak by operować na gicie bez zbędnych haseł.

ZRAM to moduł kernela, który tworzy wirtualne urządzenia w pamięci operacyjnej komputera, a te z kolei można wykorzystać pod system plików lub też i pod przestrzeń wymiany SWAP. Dane w takim urządzeniu są kompresowane, dzięki czemu mamy do dyspozycji więcej miejsca w pamięci. Jeśli mamy niepierwszej jakości dysk twardy, lub też wykorzystujemy szyfrowanie i nie mamy przy tym procka ze wsparciem dla AES, to operacje zapisu/odczytu mogą zająć wieki. Możemy w dość znacznym stopniu odciążyć dysk przenosząc pliki do pamięci RAM, który jest o wiele szybszy, no i dane w nim nie podlegają szyfrowaniu. Jeśli mamy dużo pamięci operacyjnej, to ZRAM raczej będzie zbędny i tylko podniesie nam rachunek za prąd. Natomiast jeśli nasz komputer nie szasta zbytnio pamięcią, możemy rozszerzyć ją 2-3 krotnie.

Prawdopodobnie każdy z nas korzysta, lub też i korzystał, ze skrótu klawiszy Ctrl-Alt-Backspace do resetowania środowiska graficznego na linux'ie. Może i to jest wygodny sposób na szybki restart sesji graficznej Xserver'a ale nie do końca jest on bezpieczny. Nie mówię tutaj o samej utracie danych towarzyszącej takiej akcji ale o możliwości obejścia ekranu logowania o ile ta kombinacja klawiszy nie jest wyłączona. Jest też kilka innych rzeczy, które mogą skompromitować źle zabezpieczony Xserver i tej kwestii będzie poświęcony niniejszy wpis.