Kwestię konfiguracji serwera FTP na debianie w oparciu o vsftpd już przerabialiśmy. Została nam jeszcze do omówienia implementacja protokołu SSL/TLS. FTP nie jest bezpiecznym protokołem i wszelkie dane logowania są przesyłane przez sieć otwartym tekstem. W przypadku, gdy stawiamy lokalny serwer FTP w zaufanej sieci lub też będziemy korzystać jedynie z dostępu anonimowego, to raczej nie potrzebujemy szyfrować danych. Trzeba pamiętać, że każde szyfrowanie dość mocno obciąża procesor, który może stanowić wąskie gardło przy przesyle danych. W tym wpisie założenie jest takie, że bezpieczeństwo danych, które będziemy przesyłać za pomocą protokołu FTP, jest rzeczą najważniejszą i dlatego wdrożyć szyfrowanie.

Serwery FTP umożliwiają przesyłanie plików przez sieć za pomocą protokołu TCP. Raczej wszyscy mieliśmy z nimi już do czynienia. Może niekoniecznie zarządzaliśmy takimi serwerami ale na pewno zdarzyło nam się pobierać pliki za ich pomocą. W tym wpisie jednak postaramy się skonfigurować taki serwer FTP w oparciu o oprogramowanie vsftpd.

W 2006 roku, Mozilla przyczepiła się do debiana o to, że ten wykorzystuje ich znaki towarowe. Chodziło głównie o to, że debian wprowadzał swoje poprawki, które nie były zatwierdzone przez zespół Mozilli. W efekcie czego, debian pozmieniał nazwy szeregu produktów Mozilli i tak zamiast normalnego Firefox'a mamy Iceweasel, podobnie z Thunderbird'em i Icedove. Obecnie nie ma możliwości wgrania aplikacji Mozilli wykorzystując repozytorium debiana. Trzeba się trochę wysilić i paczki pobierać ręcznie z serwerów Mozilli. Takie rozwiązanie nie jest zbytnio praktyczne, bo przecie w linux'ie aplikacji nie aktualizuje się za pomocą ich interfejsów graficznych. Jeśli tak by było, to musielibyśmy uruchamiać przeglądarkę z uprawnieniami root w trybie graficznym, czego raczej nikt rozsądny nie próbowałby robić. Można, co prawda, napisać skrypt i całą operację aktualizacji nieco zautomatyzować. Problem w tym, że zarówno Firefox jak i Thunderbird ważą tak około 50 MiB każdy i taka aktualizacja polegająca na pobraniu całej aplikacji i zainstalowaniu jej na nowo zjadłaby trochę transferu. Istnieje jednak rozwiązanie, które zakłada wykorzystanie plików MAR. Ważą one zaledwie kilka MiB, bo zawierają jedynie aktualizację danej aplikacji. W tym wpisie spróbujemy się przyjrzeć procesowi aktualizacji z wykorzystaniem tych właśnie plików.

Zgodnie z informacją na tym blogu, Firefox wraca do debiana i zastępuje tym samym Iceweasel. Od tego momentu można już instalować pakiet firefox i cieszyć się normalnym produktem Mozilli. Niniejszy artykuł w dalszym ciągu znajduje zastosowanie ale nie można mieszać opisanego niżej sposobu aktualizacji Firefox'a z tym dostarczanym w ramach menadżera pakietów apt/aptitude . Zatem albo instalujemy Firefox'a bezpośrednio z repozytorium debiana, albo ściągamy pakiet z serwerów Mozilli.

Dyski talerzowe mają to do siebie, że zawierają elementy mechaniczne, np. ramię głowicy czy też sam napęd dysku. Te ruchome elementy się zużywają podczas eksploatacji dysku i trzeba mieć na uwadze, że prędzej czy później taki dysk ulegnie awarii. Statystycznie rzecz biorąc, około 5% dysków rocznie zdycha. Oczywiście to tylko statystyka i w sporej części przypadków dyski twarde ulegają awarii znacznie wcześniej. Niekoniecznie musimy mieć tutaj do czynienia z planowanym postarzaniem sprzętu i zwyczajnie możemy trafić na trefny model, którego wada fabryczna wyjdzie po 2-3 miesiącach użytkowania. Poza tym, producenci dysków implementują w nich te energooszczędne rozwiązania, które znacznie skracają żywotność nośników. Można o tym przekonać się analizując 193 parametr SMART (Load/Unload Cycle) odpowiadający za parkowanie głowicy w dyskach firmy Western Digital. Także na dobrą sprawę nie możemy być pewni kiedy nam ten dysk zwyczajnie odmówi posłuszeństwa. Dlatego też powinniśmy się zabezpieczyć na taką ewentualność robiąc kopię bezpieczeństwa (backup) danych zawartych na dysku. W tym wpisie postaramy się zrobić kompletny obraz dysku laptopa przy pomocy narzędzi dd i nc (netcat). Nie będziemy przy tym rozkręcać urządzenia czy też podłączać do portu USB zewnętrznego nośnika. Dane prześlemy zwyczajnie przez sieć.

Hibernacja w przypadku komputerów, zwłaszcza laptopów, to bardzo użyteczny wynalazek. Na linux'ach wymaga ona czasem lekkiej konfiguracji ale generalnie można powiedzieć, że działa OOTB. Po migracji szeregu dystrybucji na systemd, proces hibernacji zdaje się przebiegać nieco inaczej niż to miało miejsce w przeszłości. Bardzo często możemy się spotkać z sytuacjami, gdzie przy próbie zahibernowania czy wyłączenia systemu, ten zwyczajnie ignoruje nasze żądanie i pracuje dalej jak gdyby nigdy nic. W tym przypadku nie mamy do czynienia z bug'iem ale ficzerem. Okazuje się bowiem, że systemd dysponuje mechanizmem zwanym inhibitor lock, który ma na celu powstrzymanie systemu od dokonania hibernacji, uśpienia lub wyłączenia w pewnych określonych sytuacjach. W tym wpisie przyjrzymy się nieco bliżej temu mechanizmowi.

Ogromna cześć lokalnych ISP zdaje się nie nadążać za ciągle zmieniającą się rzeczywistością. Problem dotyczy implementacji protokołu IPv6, który jest już z nami od bardzo wielu lat. W przypadku mojego obecnego ISP raczej nie mam co liczyć na to, by w bliżej nieokreślonej przyszłości dodał on obsługę tego protokołu. Istnieje jednak mechanizm zwany tunelowaniem pakietów protokołu IPv6 wewnątrz pakietów protokołu IPv4 (w skrócie 6to4), którym warto się zainteresować. W ogromnym skrócie, część puli adresowej IPv6 jest zarezerwowana i zmapowana na adresy protokołu IPv4. Dzięki takiemu podejściu, każdy kto posiada stały zewnętrzny adres IPv4 ma również adres w puli IPv6. Mając zatem zarezerwowany adres, możemy pokusić się o utworzenie tunelu 6to4, co aktywuje w naszej infrastrukturze ten nowszy protokół obchodząc jednocześnie ograniczenia ISP. Trzeba jednak mieć na względzie, że nie jest to natywne wsparcie dla protokołu IPv6 i jest niemal pewne, że wystąpią mniejsze lub większe problemy z wydajnością.

Rozmiary obecnych dysków twardych zwykliśmy już liczyć w TiB. Jest to dość sporo ale ciągle zdarzają się sytuacje, gdzie zaczyna nam brakować miejsca na pliki. W takich przypadkach myślimy raczej o zmianie rozmiaru istniejących już partycji czy też dokupieniu nowego dysku. Pierwsza z powyższych opcji nie zawsze może wchodzić w grę, no chyba, że zaimplementowaliśmy sobie LVM. Jeśli tak, to możemy bez większego problemu zmieniać rozmiar każdego z tych voluminów LVM. Niemniej jednak, nawet jeśli już dostosujemy sobie te wirtualne dyski, to miejsce wciąż może nam się skończyć i raczej można przyjąć za pewne, że tak się stanie w bliżej nieokreślonej przyszłości. Gdy to nastąpi, czeka nas druga opcja wymieniona wyżej, tj. zaopatrzenie się w dodatkowy nośnik danych. Przy pomocy LVM jesteśmy w stanie ten nowy dysk dodać do istniejącej grupy voluminów i zwiększyć tym wirtualnym partycjom rozmiar bez potrzeby przerywania pracy systemu, czy też wykonywania dodatkowych czynności związanych z formatowaniem i instalowaniem systemu na nowo. W tym wpisie postaramy się przebrnąć przez ten proces.

Na forum DUG'a pojawił się ciekawy post, w którym autor wątku chciał wykonać coś co określił jako "display mirroring". Poszukałem trochę informacji na temat tego zagadnienia i okazało się, że to nic innego jak tylko wyświetlenie tej samej zawartości, np. na dwóch monitorach. Nie jest to nic zaawansowanego, bo przecie Xserver jest w stanie tego typu zadanie zrealizować. Niemniej jednak, oba monitory muszą być podłączone do tego samego komputera. W tym przypadku mamy dwie maszyny i dwa osobne monitory. Celem jest przesłanie obrazu z jednej maszyny na drugą za pomocą sieci. W tym podlinkowanym wątku została poruszona kwestia przechwycenia obrazu przy pomocy ffmpeg i przesłania go przez sieć za pomocą nc (netcat). Tak bardzo zainteresowało mnie to rozwiązanie, że postanowiłem zobaczyć jak wygląda ono w praktyce.

Na forum DUG'a po raz kolejny pojawił się post dotyczący unikalnych identyfikatorów, które są nadawane partycjom dysków twardych. Nie wiem jak sprawa ma się w przypadku windowsów ale linux na podstawie tych numerów UUID i (GUID) jest w stanie identyfikować konkretne urządzenia. Czasem się zdarza tak, że dwa dyski czy partycje mają taki sam identyfikator, co prowadzi zwykle do problemów. Kolizja numerów identyfikacyjnych może być wynikiem pozostałości po procesie produkcyjnym ale może także powstać za sprawą klonowania nośnika za pomocą narzędzia dd . Tak czy inaczej, przydałoby się wiedzieć jak ustalić, poprawnie wygenerować czy też zmienić UUID wszędzie tam, gdzie jest on wykorzystywany i o tym będzie ten wpis.

Wszystko zaczęło się od pewnego posta na forum DUGa, w którym to jeden użytkownik polecał innemu, aby ten zainteresował się programem o nazwie tmux . Nie wiem czy tamta osoba to zrobiła ale ja postanowiłem się przyjrzeć temu wynalazkowi zwanemu terminal multiplekser. Po niezbyt wnikliwym przejrzeniu strony projektu rzuciło mi się w oczy dzielenie okna jednego terminala na szereg mniejszych. Ten ficzer znany był mi min. z terminala terminator. Zasadniczą różnicą tych dwóch aplikacji jest to, że tmux może być uruchomiony również pod TTY, efektywnie dzieląc obszar jednej konsoli. Nie to bym ciągle siedział w trybie tekstowym ale skoro tmux potrafi to samo co terminator oraz działa zarówno w trybie graficznym jak i tekstowym przy zaznaczeniu, że zjada także mniej pamięci RAM, to czemu nie zaimplementować sobie jego obsługi? W trakcie użytkowania tmux'a okazało, że potrafi on sporo więcej i dlatego właśnie powstał ten wpis.