Lynis – narzędzie do audytu bezpieczeństwa systemów Linux

Czasem zdarza się, że znajdę jakieś stare, fajne narzędzie, którego nie znałem wcześniej. Tak jest w przypadku Lynis – programu open source napisanego przez CISOfy służącego do audytu bezpieczeństwa systemu na podstawie bieżących ustawień. Przypadkiem, na komórce w tramwaju mignął mi wpis o nim gdzieś w sieci, opis był ciekawy, więc postanowiłem dać szansę, choć od dłuższego czasu nie interesowałem się podobnymi programami. Kiedyś, na początku przygody z Linuksem bawiłem się Bastille Linux i to w zasadzie wszystko, jeśli chodzi o automaty.

Działanie Lynis sprawdzałem tylko na Debianie i Ubuntu – działa bardzo sprawnie, generuje sensowne raporty z uwzględnieniem specyfiki dystrybucji. Przy każdym raporcie jest link do krótkiego opisu z wytłumaczeniem danej opcji. Dla początkujących jest to dobra okazja do poczytania nt. ustawień i ich wpływu na bezpieczeństwo systemu, dla zaawansowanych automat, który sprawdzi, czy czegoś nie przeoczyliśmy lub nie zapomnieliśmy włączyć np. po testach.

Program jest dostępny jako pakiet, więc instalacja sprowadza się do:

apt-get install lynis

Uruchomienie audytu również jest proste:

lynis audit system

Polecam dodanie przełącznika -Q. Program jedynie generuje raport, niczego nie zmienia w systemie, więc uruchomienie jest bezpieczne. Wynik wyświetla na ekran oraz do logu, znajdziemy tam zarówno znalezione błędy, ostrzeżenia, jak i wskazówki do hardeningu systemu.

Narzędzie ma zastosowanie raczej dla systemów, prywatnych,  utrzymywanych ręcznie – te konfigurowane automatycznie raczej nie mają miejsca na powstanie błędu, a forma raportu jest raczej przyjazna dla ludzi, niż maszyn.

Oczywiście przy domyślnej konfiguracji zgłosi także odstępstwa od normy, które są zamierzone albo nieistotne, więc wynik będzie nieco przegadany. Mimo to polecam wypróbowanie samodzielnie.

Polecenie su – zmiany

Jakiś czas temu zauważyłem, że mój Debian unstable na domowym desktopie zmienił zachowanie. Na koncie root przestał działać skrypt do aktualizacji systemu i usypianie.

Szybko sprawdziłem i oczywiście chodziło o PATH. Dopisałem pełne ścieżki do poleceń i prawie zapomniałem o sprawie, przypuszczając, że chodzi o jakiś chwilowy błąd w którymś z pakietów.

Jednak problem nie zniknął, więc postanowiłem sprawdzić dokładnie, co się wydarzyło. Na pierwszy ogień poszło sprawdzenie /etc/profile, w którym znalazłem spodziewane:

if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"

Również w /etc/login.defs wszystko wyglądało poprawnie:

# *REQUIRED* The default PATH settings, for superuser and normal users.
#
# (they are minimal, add the rest in the shell startup files)
ENV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Skończyły mi się pomysły, więc udałem się na kanał #debian-next z pytaniem, czy to błąd, czy może były ostatnio jakieś zmiany. I okazuje się, że zmiany były, grubsze, dotyczące polecenia su.

Uprzednio, wydanie „gołego” polecenia su zmieniało użytkownika na root oraz ustawiało należną mu ścieżkę. Obecnie należy podawać su – (forma niezalecana) lub, lepiej, su -l, aby osiągnąć ten efekt.

I jeszcze co ciekawsze fragmenty dokumentacji (man su). Było:

The current environment is passed to the new shell. The value of $PATH is reset to /bin:/usr/bin for normal users, or /sbin:/bin:/usr/sbin:/usr/bin for the
superuser. This may be changed with the ENV_PATH and ENV_SUPATH definitions in /etc/login.defs.
[...]
-, -l, --login
Provide an environment similar to what the user would expect had the user logged in directly.

Aktualnie jest:

For backward compatibility, su defaults to not change the current directory and to only set the environment variables HOME and SHELL (plus USER and LOGNAME
if the target user is not root). It is recommended to always use the --login option (instead of its shortcut -) to avoid side effects caused by mixing envi-
ronments.
[...]
-, -l, --login
Start the shell as a login shell with an environment similar to a real login:
o clears all the environment variables except TERM
o initializes the environment variables HOME, SHELL, USER, LOGNAME, and PATH
o changes to the target user's home directory
o sets argv[0] of the shell to '-' in order to make the shell a login shell

Więc gdyby komuś w jakiejś debianopodobnej dystrybucji niebawem su przestało ustawiać PATH, to najprawdopodobniej chodzi o tę zmianę.

3 powody dla których nie kupię Raspberry Pi 3

Blisko trzy lata temu (ależ ten czas leci) pisałem, dlaczego nie kupię Raspberry Pi. Parę dni temu opublikowana została specyfikacja Raspberry Pi 3. I też widzę, że nie kupię, choć cieszę się na płytkę z 64 bit ARM. Powody są trzy:

  1. Brak portu SATA. Najmniej istotny, bo można podłączyć dysk po USB (i raczej tak zrobię), ale nadal trochę boli.
  2. Tylko 1 GB RAM. Mało. Na desktop – przeraźliwie mało. IMO minimum dla desktopa na dzień dzisiejszy to 2 GB RAM. Zresztą skoro mocniejszy procesor, to i serwer można by bardziej obciążyć, a tu RAM też się przydaje.
  3. 100 Mbps ethernet. Dla rozwiązań typu NAS 100 Mbps to zdecydowanie za mało.

Co zamiast Raspberry Pi 3? Czaję się na najwyższy model Pine 64 czyli PINE64+ 2GB. Co prawda też nie ma SATA, ale ma 1Gbps kartę sieciową oraz 2 GB pamięci RAM. I ma kosztować przy tym 29 dolarów + 12 dolarów za wysyłkę do Polski.

Wady Pine64? Wspomniany brak SATA, jeśli ktoś potrzebuje USB i bluetooth, to musi dołożyć kolejnych 10 dolarów, albo kupić wersje na USB (2,5 w Chinach) i zająć oba porty. No i trzeba poczekać do maja.

UPDATE To wszystko oczywiście z mojego punktu widzenia, który można streścić „małe, tanie, mocne i Linux działa”. Z punktu widzenia kogoś, kogo bardziej interesuje zabawa elektroniką będzie to wyglądało zupełnie inaczej, bo w grę wchodzi choćby łatwość supportu czy dostępność rozszerzeń.

Warto też przeczytać komentarz Piotra (pierwszy) – Odroid wygląda nieźle (jak zwykle zresztą), choć jest nieco droższy (jak zwykle zresztą). Patrz porównanie. Czyli ciekawych alternatyw dla Raspberry Pi 3 jest więcej.

Dowiedziałem się też o istnieniu dystrybucji Armbian. Autorzy nie piszą niestety zbyt wiele, ale wygląda interesująco i wspiera wiele płytek. Oferuje świeży kernel i wspiera Debiana (Wheezy, Jessie) oraz Ubuntu Trusty.

Ubuntu 14.04 LTS, apt-dater i restart usług

Jakiś czas temu zachwalałem apt-dater jako narzędzie do aktualizacji większej ilości systemów. Jak pisałem w późniejszych uwagach, apt-dater nieźle integruje się z programem needrestart. Tyle teorii…

Niestety, o ile na Debianie Jessie wyglądało to naprawdę dobrze i sprawdzenie przez checkrestart (inne polecenie realizujące podobne zadanie) dawało spójne wyniki z needrestart, o tyle na Ubuntu 14.04 LTS needrestart pokazywał często, że do restartu nic nie ma, o tyle checkrestart był zupełnie innego zdania... I – co gorsza – miał rację.

Przyczyną okazała się różnica w wersji needrestart. W Jessie jest to 1.2, w Ubuntu 14.04 LTS – 0.5. Ponieważ to skrypt perlowy, to dałem szansę i wrzuciłem wersję z Debiana (stable). Instaluje się czysto, działa bardzo dobrze – w połączeniu z apt-dater wykrywa więcej usług do restartu i także tu wyniki needrestart są teraz spójne z checkrestart.

Nawiasem, checkrestart w Jessie ma problem z mysql i zawsze pokazuje, że należy go zrestartować. Jest na to zgłoszony bug. Ale to tak nawiasem, kto korzysta, ten wie, zresztą można dopisać mysql do wyjątków w konfigu.

Microsoft kupi Canonical?

Dziś przy porannej kawie natknąłem się na ten artykuł i postanowiłem skrobnąć szybką notkę. Sprawa nie jest wcale taka nieprawdopodobna.

Po pierwsze, wiadomo, że Microsoft interesuje się coraz bardziej rozwiązaniami opartymi o Linuksa. Uważam to za zupełnie naturalne, bo Linux w wielu zastosowaniach radzi sobie równie dobrze, albo i lepiej, niż Windows. Poczynając od nietypowych architektur (typu ARM), przez zastosowania serwerowe, po chmurę i wirtualizację. Jeśli chodzi o desktopy i łatwość obsługi (IMO pozorną, ale…), to oczywiście wygrywa Windows, choć nie ukrywajmy, że Ubuntu miało ambicje tu powalczyć, i miało trochę podobną filozofię, co Windows. Ze wszystkimi jej wadami i zaletami, ale także dodatkowymi wadami Linuksa.

Po drugie, Ubuntu to nie tylko kolejna dystrybucja Linuksa. Jest o tym w artykule, ale ponieważ ostatnio „trochę” siedzę w OpenStacku, to widzę, co mają w tej dziedzinie. A mają sporo, poczynając od dystrybucji w wersji LTS, z gwarantowanym wsparciem przez ok. 5 lat, co jest wartością przyzwoitą i akceptowalną, co niekoniecznie można powiedzieć o debianowym wariancie. Mają też sporo narzędzi ułatwiających tworzenie i zarządzanie chmurą (na różnych poziomach, od hardware’u, po wirtualizację (OpenStack)). Większość instalacji OpenStacka w tej chwili jest właśnie oparta o Ubuntu. Dochodzi do tego specyficzne podejście – Ubuntu ma tendencję do własnych rozwiązań, które niby są opensource, ale w praktyce nie bardzo jest sens używania ich bez Ubuntu. Z perspektywy wieloletniego użytkownika Debiana, Ubuntu jawi mi się trochę jako państwo w państwie…

Dlatego uważam, że jeśli Microsoft poważnie myśli o Linuksie, to kupno Canonical nie tylko jest możliwe, ale wręcz jest jedną z niewielu sensownych opcji pojawienia się na tym rynku. Niechęć części użytkowników do MS i tak pozostanie, ale z drugiej strony i tak musieliby z nią walczyć, jeśli chcą mieć swoją dystrybucję, community i pozycję na linuksowym rynku… Kupno Canonical (lub podobnej firmy) zapewniłoby dostęp do wiedzy, technologii i bazy „oswojonych” użytkowników. Bez tego są skazani na wymyślanie koła od nowa i eksperymenty, a wygląda mi na to, że Microsoft w ogóle nie grokuje Linuksa, więc mieliby trudne zadanie…

Zatem, choć wiele przemawia za tym, że plotka niekoniecznie jest prawdziwa, to raczej po prostu nie tym razem, a nie rzecz zupełnie nie do pomyślenia.

Shutter, czyli Linux i screenshoty

Przyznaję, że jeśli chodzi o zrzuty ekranu pod Linuksem, to nie znałem do tej pory dobrego narzędzia. Znaczy jest scrot[1], który jest prosty, bardzo mały, lekki i wywoływany z CLI, i którego użycie w wersji podstawowej, czyli cd /tmp && scrot -d 8 było proste do zapamiętania, ale… jak lubię CLI, tak w przypadku grafiki to zdecydowanie nie jest to, co tygrysy lubią najbardziej. Tym bardziej, że zwykle robię zrzuty przeglądarki, więc trzeba było dodatkowo przyciąć, wymazać, wykadrować… Czyli w ruch szedł GIMP.

Zrzuty ekranu robię na tyle rzadko, że nigdy nie szukałem dokładniej programu do screenshotów i przypuszczałem, że po prostu takiego nie ma. Okazuje się, że się myliłem. Kumpel z pracy pokazał mi genialny program o nazwie shutter[2]. Nie jest lekki (łącznie z zależnościami pobrał kilkadziesiąt MB danych), ale za to jest w pełni graficzny, minimalizuje się do traya, pozwala na robienie screenshotów zarówno całego pulpitu, tylko wybranego okna programu jak i wcześniej zaznaczonego obszaru (odpada konieczność kadrowania).

Po wykonaniu zrzutu ekranu, można go zapisać na dysku (wspierane wszystkie popularne formaty grafiki), wysłać na jeden z wielu dostępnych serwisów do publikowania obrazków, zapisać na zdalnym hoście przy pomocy FTP lub wysłać do innego programu do dalszej obróbki. Jeśli zajdzie potrzeba, bo sporo funkcji jest wbudowanych np. w postaci pluginów. Jest też wsparcie dla sesji screenshotów podobno z automatycznym numerowaniem, ale nie używam, więc nie testowałem.

W zasadzie, gdyby działało wszystko, co jest opisane na stronie, to nie potrzebowałbym nie potrzebuję niczego innego do robienia i obróbki screenshotów. 🙂 , niestety, w mojej wersji (0.88.3, Debian Wheezy) nie widzę narzędzia do cenzurowania/ukrywania danych, a czasami z tego korzystam. Możliwe, że pojawiło się dopiero w nowszej wersji Tak czy inaczej Polecam zapoznanie się z programem shutter każdemu, kto potrzebuje robić screenshoty pod Linuksem – zdecydowanie interesujący i dopracowany kawałek softu.

UPDATE: Aby działała edycja screenshotów (w tym cenzurowanie), konieczne jest jeszcze doinstalowanie biblioteki Perla: apt-get install libgoo-canvas-perl.

[1] Instalacja przez apt-get install scrot.

[2] Instalacja (Debian) to oczywiście apt-get install shutter.

Narzekanie na laptopy Della

Mógłbym napisać, że narzekam po prostu na mojego laptopa, czy tam model, ale będzie ciut szerzej. Kiedyś napisałem recenzję Della Vostro 1440. Od tego czasu minęło półtora roku. Ostatnio bateria zaczęła gwałtownie tracić pojemność. Czas pracy na baterii spadł ze wspomnianych ~3h do 1h, a ostatnio do 30 minut. Niby akumulatory li-ion nie mają efektu pamięci, ale raz testowo rozładowałem do zera i… po naładowaniu było kilka minut więcej. Bateria niezbyt szanowana (co widać w komentarzach wcześniejszych wpisów), ale u młodej w laptopie o rok starszym FS Esprimo nadal jest 2h czy nawet więcej. Coś szybko zeszła.

Dziś zrobiłem kolejną próbę „reanimacji”, czyli pełnego rozładowania i skończyło się tak, że baterii w ogóle nie ładuje. Niby li-ion nie powinno się do zera rozładowywać, ale c’mon… W każdym razie dowiedziałem się ciekawych rzeczy o ogniwach w bateriach do laptopów, możliwości ich wymiany, koszcie tej operacji (markowe ogniwa do DIY w Polsce to ok. 70 zł z wysyłką) i ogólnie rynku nieoryginalnych baterii. Brr.

Przy okazji zerknąłem na stronę Della, czy nie ma nowszego BIOSu. Owszem, jest A03. U mnie jest A01. I ciekawostka: na stronie z BIOSem nie ma wersji do upgrade’u spod Linuksa. Dla sprzętu, który jest sprzedawany z samym Linuksem. Brawo. Live CD od producenta z Free DOS OSLT też nie ma.

Ponieważ zepsułem baterię, to ogólnie miałem wenę do psucia. Poszukałem możliwości upgrade’u bez Windows. Z poziomu BIOSu się nie da. Dobrzy ludzie podpowiedzieli Hirens Boot CD. Niestety, nie mam wolnego USB pod ręką. W końcu trafiłem na stronę opisującą flashowanie BIOS dla Delli spod Linuksa. Tamże dowiedziałem się, że Dell porzucił support dla Linuksa (przynajmniej, jeśli chodzi o BIOS).

Najpierw wypróbowałem metodę Updating the BIOS without without using biosdisk. Niestety, w momencie uruchamiania pliku wykonywanego w dosemu otrzymywałem komunikat o błędzie. Następnie spróbowałem Upgrading the BIOS using Dell’s „biosdisk” and „syslinux memdisk”. Wszystko dobrze, udało mi się włączyć DOSa. Po uruchomieniu V1440A03.EXE i pytaniu, czy flashować (sure!) zwis. Zero informacji na ekranie i zero zmian przez kilka minut. Ctrl-c nie działa. Niezbyt pewnie robię ctrl-alt-del… Wstał. Ze starym BIOSem.

Jak dorzucę do tego wszystkiego rzeźbę z touchpadem w innym modelu Della (Vostro 3360), to jestem praktycznie pewien, że następny laptop jaki kupię pod Linuksa, nie będzie miał znaczka Dell.

UPDATE: Tak gwoli ścisłości, z upower –dump:

vendor: Samsung SDI
model: DELL JXFRP21

Debian Wheezy i Zabbix.

Dziś nieco się zdziwiłem, a raczej rozczarowałem. Okazuje się, że w nadchodzącym stabilnym wydaniu Debiana nie będzie Zabbiksa. W ogóle. Co prawda bardzo łatwo zrobić paczkę z publikowanych źródeł – i tak właśnie robię, bo serwer Zabbiksa czyli zabbix-server warto mieć w najnowszej wersji – ale wersja zabbix-agent  ma już niewielkie znaczenie, gdyż starsze wersje agenta zwykle współpracują ze znacznie nowszymi serwerami bez żadnych problemów. A jednak jest wygodnie było mieć agenta dostępnego w oficjalnym repozytorium pakietów.

Rozwiązań jest kilka: można pakiety robić samodzielnie, być może pojawią się też w backportach, ale dziś dowiedziałem się, że istnieje też repozytorium pakietów prowadzone przez twórców Zabbiksa. Znaleźć w nim można wersje dla Debiana (tylko stable), Ubuntu oraz RHEL.

Nowy laptop.

Dell 1440

Źródło zdjęcia (i recenzja, co prawda trochę inny model, bez grafiki AMD, ale reszta się zgadza): http://www.laptopreviews.com/dell-vostro-1440-review-2011-12

W końcu, po latach kupiłem sobie laptopa. Ostatnio jakoś cały czas korzystałem albo ze służbowego, albo z różnych starych. Nie da się ukryć, że stary laptop spisywał się dobrze do zadań podstawowych, ale… tłumaczenie dla FSF z użyciem virtaal było ciut mało komfortowe, a zupełnie irytujące, gdy dorzuciłem do tego muzykę z YT. Zresztą YT ogólnie średnio działało, przynajmniej w przeglądarce. Bo z użyciem minitube to i owszem, ale jednak znowu – nie ten komfort. Tak więc po dwóch latach przyszła pora na zakup.

Po krótkim wyszukiwaniu w porównywarkach cen stanęło na Dellu Vostro 1440. Czemu tak? Matowy ekran (czemu, ach czemu nie ma tego do wyboru jako kryterium w żadnej porównywarce?!), jest mniejszy niż 15″ (tu miałem dylemat – albo 17″ i całkiem stacjonarnie, albo jednak trochę z zachowaniem mobilności – wybrałem to drugie rozwiązanie). Dużo – szczególnie jak na moje standardy – RAM, duży dysk. Chwilę wahałem się, czy wybrać wersję ze znienawidzoną kartą ATI (obecnie AMD), czy Intel. Ostatecznie stwierdziłem, że ATI gorzej tj. wolniej od Intela działać nie powinien, nawet na otwartych sterownikach, więc wziąłem tę z AMD. No i była wersja bez systemu. Znaczy z Linuksem.

No właśnie, laptop przyszedł z zainstalowanym Ubuntu (IIRC 10.10), które zrobiło naprawdę rewelacyjne wrażenie na pierwszy rzut oka – wszystko działa: i wifi, i grafika, i dźwięk, i hibernacja. I wyglądało całkiem elegancko. Przeszła mi myśl, czy nie zostawić tego systemu. Niestety, po bliższych oględzinach i próbie aktualizacji wyszły wady: synaptic zawiesił się na aktualizacji pythona (czy też jego modułów), program do testowania systemu uruchomiony w międzyczasie zawiesił się na sztywno, gdy odmówiłem mu podania hasła do roota i żadną miarą nie dawał się w cywilizowany sposób wyłączyć. W niecywilizowany (kill z konsoli) też nie, bo nie mogłem skorelować nazwy procesu z tymże programem. Czarę goryczy przepełnił Firefox w wersji 3.6 oraz zainstalowany Skype (i pewnie masa innego non-free syfu). Stwierdziłem, że mam gdzieś taki system, nad którym nie panuję, nagrałem płytę rescue na wszelki wypadek i zabrałem się za instalację Debiana przy pomocy debootstrap (stąd m.in. tamten wpis).

Sam zakup też nie jest trywialny w naszym pięknym kraju. Pierwszy sklep, po potwierdzeniu dostępności towaru, wymaganej obowiązkowej rejestracji (nie lubię) i złożeniu zamówienia skontaktował się… w celu poinformowania, że nie obsługują osób fizycznych, wyłącznie firmy i instytucje. Nie rozumiem idei takiego postępowania (przychodzi mi jedynie na myśl chęć uniknięcia 10 dni na zwrot towaru przy zakupie zdalnym), ale drugi sklep, z ceną o kilka zł wyższą nie miał takiego problemu. Warto jedynie odnotować, że w sumie zakup zajął mi tydzień.

Po dość długiej synchronizacji danych (uroki karty wifi bez anteny w starym laptopie, kabla nie chciało mi się szukać…) system w zasadzie działał. Istnieje parę przyjemniejszych rzeczy, niż migracja z 32 bit na 64 bit – chodzi o parę pakietów, którym zmieniają się nazwy i całkiem sporo pakietów (w tym Bloxer2), które nie są popaczkowane, a które trzeba było przeinstalować na wersję 64 bit, ale ostatecznie wszystko działało OK. Sprzęt działa praktycznie od kopa na kernelu 3.2.x , włączając wifi i hibernację (po konfiguracji, którą musiałem sobie odświeżyć). Akceleracja 3D w karcie AMD też działała po instalacji fglrx, ale stabilność pozostawiała nieco do życzenia. Znaczy raz się zwiesił (ale podczas gry w Nerdquiz!), więc fglrx poszły w odstawkę. Na chwilę, bo później do nich wróciłem i było OK.

Żeby nie było za fajnie – przy lspci okazało się, że laptop ma dwie karty graficzne. Wspomnianą AMD oraz… zintegrowanego Intela. Co ciekawe, domyślnie korzysta ze zintegrowanego Intela. I działa to całkiem wystarczająco – YT jest płynne. Tym bardziej wystarczająco, że zabawa z vgaswitcheroo to jakaś masakra i rzeźba. I nie działa. I są zwisy (podobnie, jak przy fglrx). Dowiedziałem się też, że kernele serii rt w ogóle z fglrx nie działają. A sterowanie prędkością wiatraka to zupełna abstrakcja. Niby i8kfan pozwala na coś, ale to coś działa po chwili mocno losowo i zupełnie niezgodnie z konfigiem. Nie wiem, czy ACPI się wdaje w paradę czy o co chodzi, ale ustawienie do którego przywykłem korzystając ze starego laptopa, czyli totalna cisza, a w okolicy bliskiej gotowania totalne wycie chwilowo wydaje mi się nieosiągalne. Przy okazji – osiągnięcie temperatury bliskiej gotowania nie było tam takie proste… Być może chodzi o kartę graficzną? W każdym razie będzie nad czym posiedzieć.

Z innych wad: spacja jest przesunięta trochę w prawo, co powoduje, że odruchowo naciskałem spację, zamiast prawego alt przy pisaniu pl-znaków. Na szczęście przesunięcie jest minimalne, a trochę głębsze podwijanie kciuka weszło mi już w krew. Dokładniejszy opis jak działa Debian na tym sprzęcie pewnie pojawi się za jakiś czas. Generalnie wygląda całkiem dobrze. No i skoro mam sprawną baterię, to mogę korzystać bardziej mobilnie. Ale jeszcze się nie przestawiłem mentalnie i nadal klikam przy biurku.

Jak zainstalować Debiana przy pomocy debootstrap – HOWTO.

Co prawda instalacja systemu przy pomocy debootstrap jest trywialna, opisów są setki, a i man debootstrap niby jest wystarczający, ale zawsze kończy się tak, że o czymś zapominam jak z głowy robię i muszę bootować powtórnie, więc postanowiłem spisać. Tym bardziej, że ostatnio jest to najpopularniejsza dla mnie metoda instalacji – instalator Debiana został wykastrowany z niewolnych firmware’ów, przez co instalacja Debiana na laptopach czy ultrabookach, gdy nie ma przewodowej karty sieciowej jest… powiedzmy delikatnie niefajna. No i parę instalacji znowu w ostatnim czasie było.

Instalację przy pomocy debootstrap można zrobić z dowolnego systemu, nie musi być to Debian. Zwykle korzystam z Debiana live lub – ostatnio – Ubuntu w wersji live (jakoś lepiej sprzęt wykrywa, a nie mam czasu sklikać debianowego live z testing/unstable…), ale z bardziej pamiętnych zdarzało się i Gentoo. Cokolwiek co ma pakiet debootstrap się nada. Kolejne kroki wyglądają tak:

  • utworzenie i sformatowanie partycji, na którą ma być zrobiona instalacja
  • utworzenie punktu montowania, zamontowanie partycji – mkdir /chrooted; mount /dev/sda3 /chrooted
  • debootstrap właściwy – debootstrap squeeze /chrooted http://ftp2.de.debian.org/debian/
  • podmontowanie proc- mount proc /chrooted/proc -t proc
  • podmontowanie dev i sys – mount –bind /dev/ /chrooted/dev; mount –bind /sys/ /chrooted/sys
  • wejście do chroota – chroot /chrooted /bin/bash
  • edycja sources.list i aktualizacja listy pakietów
  • instalacja kernela, firmware’ów (także niewolne, jeśli wymagane), gruba
  • aktualizacja wpisów dla grub – update-grub2
  • instalacja dodatkowych programów – apt-get install wajig less mc wicd wpasupplicant wicd-curses
  • edycja /etc/fstab, /etc/network/interfaces, /etc/hosts (w sumie bez tego też działa)
  • zmiana hasła root, ew. dodanie użytkowników
  • wyjście z chroota – exit
  • reboot kontrolny – system powinien działać

Jest szansa,  że o czymś zapomniałem, więc pewnie będę uzupełniał.

UPDATE: Gdyby okazało się, że maszyna, która jest dostępna tylko po sieci (nie mamy monitora) po takiej instalacji nie pinguje się, a sieć została skonfigurowana, to warto sprawdzić okolice /etc/udev/rules.d/70-persistent-net.rules czy MAC nie został przypisany do kolejnego interfejsu.

Java-package z powrotem w Debianie.

Jakiś czas temu Sun zmienił politykę dotyczącą wydawania swojej wersji Javy, w wyniku czego wyleciała ona zarówno z Ubuntu, jak i Debiana. Użytkownicy zostali z niezaktualizowanymi wersjami, więc obie dystrybucje skierowały swoje zainteresowanie w stronę OpenJDK, która teoretycznie ma zapewnić wystarczającą funkcjonalność. Więcej o sprawie można poczytać tu w przypadku Debiana, oraz tu w przypadku Ubuntu. Ten drugi link zawiera instrukcję co zrobić, żeby mieć bezpieczny system, czyli opis migracji do OpenJDK na Ubuntu (IIRC dokładnie to samo należy zrobić w przypadku Debiana).

Fajnie, że jest wolne rozwiązanie, fajnie, że pewnie projekt OpenJDK dostanie niezłego kopa, jeśli chodzi o rozwój, ale jednak nie wszystkim w tej chwili wystarcza OpenJDK, które jest wolniejsze i… nie zawsze działa poprawnie (ja miałem problem z appletami VNC, które przydają się przy administracji sprzętem, zwłaszcza w przypadku rozwiązań typu KVM…). Wybór był trojaki: instalacja ręczna Javy od Sun, stara, dziurawa wersja albo niedziałanie aplikacji.

Pierwszy wybór jest męczący, jeśli ktoś lubi mieć wszystko w systemie spaczkowane (ja lubię), pozostałe dwa są niezbyt dopuszczalne w praktyce… Cieszy mnie więc reaktywacja projektu java-package (aktualnie dostępny w unstable, jeśli wszytko pójdzie dobrze, będzie we Wheezy), czyli prymitywnego skądinąd narzędzia pozwalającego na zrobienie w prosty sposób pakietu deb z Javą od Sun. Sam fakt spaczkowania oczywiście nie wpływa na działanie w żaden sposób, ale na pewno ułatwi utrzymanie porządku w systemach poprzez włącznie Javy od Sun do systemu zarządzania pakietami, wrzucenie do swojego repozytorium pakietów itp.

Oryginalny(?) sposób na przetestowanie ultrabooka Acer Aspire 3S

Acer Aspire 3S

Źródło: http://blox.blox.pl/2011/11/Zostan-testerem-i-wygraj-Ultrabooka-Acer-Aspire-S3.html

Gdybym miał możliwość wykonania dowolnego testu, w dowolnym czasie, to pewnie zaproponowałbym jakiś szalony test wyjazdowo-wakacyjny, albo wręcz wyprawę w jakieś ekstremalne miejsce typu biegun (chociaż żeby zniknąć na chwilę z zasięgu sieci GSM wystarczy wyprawa pociągiem do Szczecina), bo niska waga sprzętu i niewielkie rozmiary zachęcają do przetestowania mobilności.

Niestety, rzeczywistość skrzeczy, na test jest tylko jeden dzień, warunków na wyrwanie się gdzieś dalej nie ma, a na dodatek teraz, z racji chwilowo drastycznie ograniczonej mobilności, nawet po mieście nie pobiegam…

Zatem, patrząc realnie, czasu na test Acera Aspre 3S jest mało (tylko 1 dzień), ale z racji zainteresowań sprawdziłbym przede wszystkim, jak sobie radzi pod kontrolą mniej popularnego systemu operacyjnego, czyli pod Linuksem. Nie wiem, czy liczy się to jako oryginalny test, ale Linux na desktopach to okolice 1%, więc na pewno nietypowy. Czyli standardowa instalacja Debiana (jeśli się uda,to stable) i szybka ocena działania poszczególnych komponentów, czego efektem byłaby strona dla projektu Linux on Laptops, podobnie jak miało to miejsce kiedyś w przypadku innego laptopa. Jeśli z Debianem byłyby problemy, to może popularniejsze na desktopach Ubuntu dostałoby szansę? Albo Mint? Ewentualnie, jeśli nie można instalować innego systemu, to szybki test z Debiana live, ale to już nie to samo…

Mobilność tyle, co po domu. W końcu może zdecydowałbym się nie siedzieć z kompem przy biurku, tylko potraktować go podobnie jak książkę – wziąć go do łóżka, połazić między pokojami, takie drobiazgi. Tradycyjnie sprawdzenie jakości wykonania i solidności (na oko, rzucać nie będę), układu klawiszy na klawiaturze (przy 13,3″ może być normalna, wygodna już chyba – na 10″ jest niestety troszeczkę za ciasno, przynajmniej dla mnie) i takie drobiazgi. Jeśli zadziała akceleracja 3D, to może szybka zabawa z jakąś grą. No i przede wszystkim obadam ekran. Nie cierpię błyszczących, ale może jakieś lepsze zaczęli robić, nie lusterka? Jak na jeden dzień chyba wystarczy wrażeń…

UnARMed.

Na procesorach ARM powstaje sporo sprzętu. Teoretycznie świetnego, bo i niski pobór mocy, i spore możliwości, i niewielka cena.

Przykłady sprzętu opartego o ARM:

  • Toshiba AC100 – smartbook od Toshiby oparty na chipsecie Nvidii Tegra2. Dwurdzeniowy procesor taktowany 1GHz, 512 MB RAM. 8-10h na baterii, możliwość odtwarzania filmów full HD (1080p). Ekran 10,1″. Do tego dysk SSD. Cena? W zależności od wariantu już od 800 zł (polski sklep internetowy).
  • Trim-Slice – Ten sam procesor i chipset, pobór prądu 2-6W wg producenta. 1GB RAM, gigabitowa karta sieciowa. Wersja bez SSD – 199 USD. Oczywiście też umie full HD, więc aż się prosi o dołożenie dysku i przerobienie na domowe media center (plus ew. router, NAS, a dla geeków serwer WWW i shell), albo nawet i desktop.
  • Seagate Freeagent Dockstar – opiszę, bo i mój pierwszy kontakt z ARM, i stosunkowo ciekawy. Tania (pierwotnie ~25 euro; potem podrożały, ale wydaje mi się, że w Polsce nadal do kupienia w okolicach ~45 euro) zabawka pierwotnie mająca służyć za NAS z serwerem WWW. Gigabitowa karta sieciowa, procesor 1GHz, 128 MB RAM. Na oko świetny zamiennik dla HP T5520, służącego mi za router, ale domowy serwerek WWW, shell czy – po dołożeniu karty dźwiękowej USB – player muzyki itp. też spokojnie można uruchomić. Minimalnie lepsze parametry, aktualnie podobna cena, mniejszy pobór prądu. Jak w końcu uruchomię, to dam znać jak się spisuje. Nietypowy także dlatego, że na Dockstar działa niemodyfikowany Debian.

Wady:

  • Niewygórowane parametry – nie ma co ukrywać, 512 MB czy nawet 1GB RAM to obecnie trochę mało, zwłaszcza, jeśli mówimy o desktopie (patrz poprzedni wpis o małej ilości RAM na desktopie). Procesor też nadmiarem mocy nie grzeszy. To raczej tani sprzęt, więc na komplet złącz i ich sporą ilość też nie ma co liczyć (np. Toshiba tylko 1 pełnowymiarowe USB, Dockstar brak czegokolwiek poza USB i ethernetem, nawet audio nie ma).
  • Brak możliwości rozbudowy – zarówno procesor, SSD, jak i RAM są niewymienne, wlutowane na płytę – SoC. W połączeniu z punktem pierwszym powoduje, że przy zwiększeniu wymagań czy awarii któregoś podzespołu trzeba się liczyć z wymianą całego sprzętu.
  • Słabe wsparcie Linuksa od strony producentów – ani Toshiba, ani Trim-Slice nie pozwolą na uruchomienie Linuksa tak po prostu. Instalacja zawsze jest większą lub mniejszą rzeźbą (Dockstar ma niezły, choć nieprzyjazny użytkownikowi instalator, na Trim-Slice niby udało uruchomić się Debiana, ale z kernelem z Ubuntu). Toshiba oficjalnie wspiera tylko Androida, niby da się na AC100 zainstalować Ubuntu 10.10 (oczywiście rzeźba), ale nie działa dźwięk.
  • Nie działają niektóre aplikacje – dobra, nie ma co ukrywać, chodzi głównie o Flasha. Niby nic, ale na tę chwilę niestety Flash jest furtką do multimediów i praktycznie niezbędny do przeglądania Internetu. Być może HTML5 coś w tym temacie zmieni, pytanie czy zmieni i, jeśli tak, to kiedy.

Co dalej? Nie ukrywam, że jestem kibicem energooszczędnych i stosunkowo tanich rozwiązań o dużych możliwościach, a taki właśnie jest ARM. Niestety, w tej chwili trudno rozważać ARM jako pełnowymiarową architekturę pod Linuska, dlatego – nie licząc Dockstara – jestem unARMed. Mam nadzieję, że rosnące zainteresowanie nią Ubuntu i Apple odbije się pozytywnie na wsparciu Linuksa.

Odzyskiwanie miejsca w systemie (Linux, Windows).

Używany system ma tendencję do powolnego gubienia miejsca. Niezależnie od tego czy mamy w systemie porządek, czy nie, z czasem przybywa rzeczy, których nie potrzebujemy. Z jednej strony są to bardzo potrzebne pliki, których po prostu szkoda skasować (chociaż tak naprawdę nigdy już ich nie otworzymy), z drugiej nieużywane pakiety, konfiguracje usuniętych pakietów, pliki tymczasowe itp.

O ile z pierwszymi nie bardzo można sobie poradzić inaczej, niż samodzielnie utrzymując porządek (sortowanie do katalogów, kasowanie zbędnych rzeczy) i ręcznie usuwając pliki, to w przypadku tych drugich można sobie pomóc w czyszczeniu systemu różnymi automatami i półautomatami.

Pierwszy złodziej miejsca w systemie to cache apt-a, czyli /var/cache/apt/archives. Leżą tu paczki deb instalowanych pakietów. We wszystkich wersjach, także tych starszych. Praktycznie nigdy nie będą potrzebne, więc z czystym sumieniem możemy je skasować: wajig clean (lub, bardziej kanonicznie apt-get clean).

Drugi popularny złodziej miejsca to locale, czyli różne wersje językowe dla danego programu. Zwykle nie potrzebujemy dokumentacji itp. po hiszpańsku, włosku czy chińsku. Rozwiązanie: localepurge (po uprzednim skonfigurowaniu, fajnie jakby coś jednak zostało…).

Potem można zobaczyć, czy nie zostały w systemie pliki konfiguracyjne po usuniętych pakietach. Przy okazji sprawdzimy, które pakiety zajmują najwięcej miejsca: wajig sizes. Status inny niż installed oznacza, że raczej możemy się pozbyć pakietu w całości, czyli z konfigami (wajig purge <pakiet>).

Na koniec jeszcze deborphan (albo wersja ładniejsza w curses czyli orphaner) i usuwamy zainstalowane na potrzeby spełnienia zależności niepotrzebne pakiety (głównie biblioteki).

Tu się zwykle sprzątanie kończy. No dobrze, można jeszcze skorzystać z jednego z przydatnych poleceń i spojrzeć, które katalogi zajmują najwięcej miejsca (du –max-depth=1 -b | sort -n) i ręcznie pousuwać zbędne rzeczy (typu cache googleearth).

Dłużej używane systemy mają tendencję do gromadzenia pakietów z poprzednich wersji (szczególnie, jeśli korzysta się z wersji niestabilnej lub miesza kilka wersji systemu). Można je łatwo wytropić (i usunąć) korzystając z opisanego sposobu: wajig versions | grep -v squeeze.

A dziś odkryłem wisienkę na czubek tortu: BleachBit. Narzędzie jest wieloplatformowe (Linux, Windows) z funkcjami typowo Debianowymi (bardziej Ubuntu pewnie) i zajmuje się takimi cichymi złodziejami miejsca jak cache różnych aplikacji. Poza tym, że sięga tam, gdzie inne automaty nie sięgają, umie też czyścić rzeczy typowo systemowe: wspomniany cache apta, nieużywane lokalizacje (twórcy BleachBit twierdzą, że robi to znacznie skuteczniej, niż localepurge, faktycznie znalazł więcej).

Posiada zarówno miłą klikalną wersję GUI (z której korzystałem) jak i interfejs CLI (nie próbowałem). Do tego dobre podpowiedzi do opcji (ostrzega przed opcjami powolnymi i potencjalnie niebezpiecznymi). Działa bardzo fajnie, więc zdecydowanie polecam, jeśli ktoś planuje porządki w systemie (a chyba każdy prędzej czy później staje przed pytaniem jak odzyskać miejsce w systemie?). Użycie jest proste: najpierw wybiera się, co chce się usunąć, potem jest podgląd plików do usunięcia (warto spojrzeć co będzie usuwane – wywala np. pliki bak i inne tymczasowe – czasami może tam być coś pożytecznego…). Program dba o prywatność użytkownika – jako opcja dostępne jest nadpisywanie zawartości kasowanych plików przed ich usunięciem.

Jedyne do czego można się przyczepić, to spolszczenie. Zapewne w oryginale był vacuum (bazy danych), a został… odkurzacz. I parę innych kwiatków tego typu, ale IMHO nie rzutuje na całość.