Każdy z nas popełnia błędy. Niektóre z nich są błahe i w sporej części łatwe do poprawienia. Zwykle też nie niosą one ze sobą większych konsekwencji. Natomiast błędy, które popełniamy podczas pracy w systemie operacyjnym wykonując różne prace administracyjne mogą nas czasem słono kosztować. W linux'ach ogromną rolę odgrywają prawa do plików. O ile root ma dostęp do wszystkich plików, to w przypadku zwykłych użytkowników (czy tez usług systemowych) już tak nie jest. Przypadkowa zmiana tych uprawnień może zaowocować problemami związanymi z bezpieczeństwem takiego systemu, a w niektórych przypadkach może nawet uniemożliwić jego start. Na necie kilka razy obił mi się o oczy temat, gdzie ludzie przez przypadek (lub też całkiem świadomie) zmienili masowo uprawnienia w takich katalogach jak /usr/ czy /etc/ . Powiem nawet więcej, mi się raz taka sytuacja kiedyś przytrafiła. Co w takim przypadku można zrobić? Czy jedyną opcją, jaka nam pozostaje, to ponowna instalacja sytemu? Na szczęście nie, bo uprawnienia do plików możemy sobie zwyczajnie spisać i odtworzyć je w późniejszym czasie.

Pliki tekstowe w linux'ie są zakodowane w formacie UTF-8. Ta cyfra 8 może być jednak myląca, bo ilość bajtów potrzebnych do zakodowania pojedynczego znaku może się różnić i wynosi od 1 do 4. Tak czy inaczej, środowiska linux'owe już dawno zaimplementowały obsługę tego systemu kodowania i uczyniły go sobie domyślnym. Są jednak takie systemy operacyjne, które nie wykorzystują domyślnie UTF-8 do kodowania tekstu. Wobec czego, gdy spróbujemy otworzyć w edytorze taki plik, to w pewnych miejscach będziemy mieli krzaczki, zwykle tam gdzie są polskie znaki. To zjawisko jest bardzo charakterystyczne dla napisów w filmach. Niemniej jednak, zarówno edytory tekstu jak i player'y video są w stanie dokonać automatycznego doboru systemu kodowania i zwrócić nam czytelny plik. Nie zawsze jednak tak robią. Zamiast bawić się w tego typu automatyczne wynalazki, dużo lepszym rozwiązaniem jest zmiana kodowania plików, tak by przekonwertować je do formatu UTF-8 i w tym wpisie postaramy się to zrobić.

Każdy z nas odsłuchuje czasem pliki .mp3 . Niekoniecznie musi to być muzyka, np. mogą być to audycje radiowe, czy też inne materiały audio. W przypadku dłuższych nagrań problematyczne może być odnalezienie w nich tego kawałka, który akurat chcielibyśmy ponownie odsłuchać. Podobnie sprawa ma się w przypadku, gdy dany materiał chcemy komuś przesłać. Jeśli ślemy całe nagranie, to musimy dodać informację od którego momentu zaczyna się coś dziać w tym utworze. Nie prościej wyciąć ten interesujący nas kawałek i zapisać go w osobnym pliku?

Wielu ludzi nie lubi gdy maszyny monitorują każdy ich krok. W tym przypadku chodzi o pliki, które otwieramy czy zmieniamy podczas codziennej pracy na komputerze. Nasz system domyślnie tworzy listę i skrupulatnie dodaje do niej nowe pozycje. Ta lista jest przechowywana w pliku recently-used.xbel , który znajduje się w katalogu ~/.local/share/ . Gdy popatrzymy na tę funkcjonalność trochę pod inny kątem, możemy zauważyć, że w pewnych sytuacjach zagraża ona naszej prywatności. Skasowanie tego pliku nie rozwiązuje problemu, bo jest on tworzony na nowo, a nadawanie atrybutu odporności ( chattr +i ) nie jest żadnym rozwiązaniem. Na szczęście jest sposób na to by ten mechanizm dezaktywować i o tym będzie poniższy wpis.

Jeśli próbowaliśmy odnaleźć odpowiednią ścieżkę do urządzenia usb w linuxowym drzewie katalogów, to wiemy, że nie jest to łatwe zadanie. Mamy, co prawda, do dyspozycji polecenie lsusb ale ono nie daje nam precyzyjnych informacji na temat tego gdzie dokładnie w katalogu /sys/ znajdują się określone urządzenia. Na necie natrafiłem na FAQ dotyczący tego zagadnienia i postanowiłem napisać kilka zdań o tym jak zinterpretować ciągi typu 2-1.1.2:1.1 oraz jakie to może być urządzenie.

Dnia 2014-10-07 w Debianie była aktualizacja pakietu encfs , która to zawierała informację na temat audytu bezpieczeństwa jaki się dokonał parę miesięcy wstecz. Wyniki niezbyt dobrze wypadły, a nawet można powiedzieć, że wręcz katastrofalnie. Generalnie cały test został skwitowany słowami, że jeśli szyfrujemy pliki przy pomocy tego narzędzia, to jesteśmy relatywnie bezpieczni, nawet w przypadku jeśli ktoś te pliki przechwyci. Natomiast jeśli zaczniemy zmieniać/dodawać pliki i ten ktoś ponownie przechwyci nasz zaszyfrowany katalog, wtedy może on bez problemu odszyfrować całą jego zawartość. Jeśli wykorzystujemy encfs lokalnie, to być może nam nic nie grozi, nawet w przypadku raidu NSA na naszą chałupę. Problem w tym, że ogromna rzesza ludzi wykorzystuje encfs do zaszyfrowania plików w chmurze, np. na Dropbox'ie czy MEGA, a jak wiadomo, przy każdej synchronizacji, zmiany w danym katalogu są przesyłane do chmury i wszelkie zabezpieczenie jakie daje encfs diabli biorą. Może najwyższy czas zainteresować się ecryptfs?

Przy umieszczaniu zdjęć czy też różnego rodzaju grafik na blogu, możemy zauważyć, że owe fotki nie są umieszczane w postach w oryginalnych rozmiarach. Zamiast nich są używane miniaturki, które mają konfigurowalny rozmiar. Naturalnie możemy nakazać WordPressowi by umieszczał obrazki w pełnym ich wymiarze, choć jednak ze względów estetycznych lepiej zachować określone ich rozmiary i jeśli jakaś grafika wychodzi po za nie, to powinna zostać przycięta. Taka miniaturka powinna linkować do obrazka pełnowymiarowego, gdzie można zobaczyć więcej szczegółów. Taki jest przynajmniej schemat tego działania w WordPressie. Problem jest jednak z jakością samych miniaturek.

Obecnie technika podziału jednego pliku na szereg mniejszych nie jest już tak szeroko stosowana jak parę lat temu gdy internet dopiero zaczynał pojawiać się w naszych domach. Głównym powodem jest postęp technologii i dziś już mało kto posiada łącza 128Kbit/s, wobec czego przesłanie pliku, który waży nawet kilka GiB nie jest niczym niezwykłym i nie ma potrzeby go dzielić na części. Niemniej jednak, z jakichś powodów ludzie chcą mieć taką możliwość i zastanawiają się jak podzielić plik na kilka części na jednej maszynie i połączyć je na innym komputerze.

Suma kontrolna daje możliwość sprawdzenia czy dane zawarte w pliku nie zostały zmienione podczas transferu z jednego medium informacyjnego na inne. Jeśli weźmiemy przykład pakietów sieciowych, to pliki przesyłane między dwoma punktami są dzielone na mniejsze kawałki. W każdym z nich są zawarte sumy kontrole danych, które zawierają. Komputer odbierający taki pakiet generuje własną sumę kontrolą i porównuje ją z tą otrzymaną w pakiecie. W przypadku gdy suma kontrolna się nie zgadza, mamy do czynienia z błędami przesyłu, tj. pakiet został uszkodzony gdzieś po drodze. W tej sytuacji maszyna odbierająca dane prosi o ponowne przesłanie uszkodzonego segmentu. Ta sytuacja może się zdarzyć ale błędy są automatycznie naprawiane. Problem jest taki, że przy pobieraniu plików z internetu nie zawsze korzystamy z bezpiecznych połączeń, poza tym, zawsze ktoś może uzyskać dostęp do serwera i podmienić pliki. Czy możemy zatem mieć pewność, że dany plik trafił do nas w formie takiej jak powinien?

Struktura pliku .img czy .iso niczym nie odbiega od struktury przeciętnego dysku twardego. W obu przypadkach mamy dokładnie taki sam schemat budowy, tj. mamy obecny MBR i partycje, z których pierwsza zwykle jest wyrównana do 1MiB, zostawiając tym samym 2047 sektorów wolnego miejsca z początku pliku, tuż za MBR, tzw. MBR-GAP. Obraz .img można poddać edycji, np. utworzyć wewnątrz niego inne partycje, zmienić rozmiar ich systemu plików, a nawet można manipulować rozmiarem samego obrazu .img . Taki plik możemy również zamontować w systemie przy pomocy narzędzia mount ale też trzeba odpowiednio podejść do tego zadania, bo przez fakt, że mamy z początku MBR i trochę wolnego miejsca, to linux zwyczajnie nie potrafi rozpoznać systemu plików, który znajduje się w obrazie .img.