Wake on LAN i wybór systemu multiboot

Dlaczego?

Ostatnio zauważyłem pewien problem z wykorzystaniem Wake On LAN. Włączanie systemu przez sieć przy użyciu telefonu komórkowego jest bardzo wygodne zwłaszcza jeśli mogę to zrobić będąc jeszcze przed domem 😉 Dyskretnie omijając temat tego czy to zdrowe (zarówno fizycznie jak i psychicznie) przejdę od razu do rzeczy.

Problem nie jest zbyt skomplikowany. Uruchamiając komputer przez Wake On LAN (dalej WOL) chciałbym jednocześnie określić, który system ma się uruchomić. Pierwsze pobieżne próby i internetowe poszukiwania gotowych rozwiązań pokazały mi, że nie da się tego zrobić. Bardziej wnikliwe spojrzenie na sprawę pozwoliło znaleźć na pewne rozwiązanie (niestety nie udało mi się ponownie znaleźć tego linka :(), które działało następująco:

  1. Uruchomienie domyślnego systemu
  2. Zmodyfikowanie w nim domyślnego systemu wybranego w GRUBie
  3. Zrestartowanie maszyny

Nie trzeba być biegłym w technice komputerowej żeby zrozumieć, że takie rozwiązanie jest mało satysfakcjonujące. Chociażby dlatego, że uruchomienie maszyny trwa o wiele dłużej niż normalnie. Innym problemem jest też dostęp do konfiguracji GRUB. Zazwyczaj jest on na partycji EXT2, a w Windows (zwłaszcza nowszych) niełatwo znaleźć oprogramowanie pozwalające modyfikować takie partycje.

Pomyślałem więc:

Obrazek

i zacząłem zgłębiać temat. Początkowo naiwnie wierzyłem, że skoro GRUBv2 jest taki świetny i tak wiele potrafi to zapewne da się z niego jakoś pogadać z siecią lub coś w tym stylu. Byłoby to rozwiązanie najprostsze. Niestety po przejrzeniu znakomitej większości jego dokumentacji stwierdziłem, że jednak takiej możliwości nie ma.

Ostatecznie zwróciłem swój wzrok na PXE. Nie ukrywam, że byłem już nieco zrezygnowany ponieważ pomyślałem, że skoro nie znalazłem wzmianki o takim jego wykorzystaniu do tej pory to zapewne i z tego niewiele wyjdzie.

Ku mojemu zaskoczeniu PXELINUX wchodzący w skład projektu Syslinux podołał temu zadaniu. Należy jednak wspomnieć, że do korzystania z PXE potrzebne są działające i odpowiednio skonfigurowane serwery DHCP oraz TFTP. Te do działania potrzebują pewnego sprzętu. DHCP co prawda każdy ma w domu działające na jego routerze, ale rzadko daje się je konfigurować w odpowiednim stopniu. Co do TFTP to jest ono chyba praktycznie niespotykane w domowych routerach.

Na moje szczęście sam posiadam router z wgranym oprogramowaniem DD-WRT. Jest to router oparty na Linuksie więc możemy się na niego zalogować poprzez SSH i konfigurować wszystkie usługi wedle uznania. Można także uruchomić na nim serwer TFTP, ale ja nie skorzystałem z tej opcji ze względu na to, że mój biedny router posiada jedynie 16MB pamięci RAM. Nie chciałem go obciążać dodatkowymi usługami więc do tego celu wykorzystałem zakupione całkiem niedawno Raspberry Pi. Po moim przydługim wstępie proponuję przyjrzeć się następnej sekcji by zobaczyć „jak to jest zrboione”.

Konfiguracja

Wykorzystany sprzęt:

  • Komputer docelowy
  • Raspberry Pi
  • Router z oprogramowaniem DD-WRT

Zacząć należy od poprawnej konfiguracji serwera DHCP. Najpierw ustawiłem serwer w taki sposób aby Raspberry Pi zawsze otrzymywało adres IP 192.168.0.98. W DD-WRT można to zrobić łatwo poprzez stronę konfiguracyjną routera. Następną rzeczą było dodanie do konfiguracji opcji potrzebnych do uruchomienia PXE. Na DD-WRT działa uproszczony serwer udhcpd, który posiada niestety zupełnie inną składnię pliku ustawień niż znany i lubiany dhcpd. Tak czy inaczej wszystko sprowadza się do podania pewnych wartości poprzedzonych odpowiednimi słowami kluczowymi. W tym przypadku znów można było użyć strony konfiguracyjnej DD-WRT aby wpisać następujące wartości:

boot_file pxelinux.0
siaddr 192.168.0.98
sname rpi

Ostatecznie strona z konfiguracją wygląda tak:

Obrazek

Kolejną rzeczą jest odpowiednie ustawienie serwera TFTP. W tym celu zalogowałem się na Raspberry Pi i wykonałem polecenia:

root@raspberrypi# apt-get install tftpd xinetd rcconf
root@raspberrypi# rcconf

W ten sposób zainstalowałem serwer tftpd, superserwer (jak go nazywają) xinet.d, oraz narzędzie do konfiguracji autostartu usług. Drugie polecenie wyświetli nam listę wszystkich usług, które startują razem z systemem. Jeśli przy xinet.d nie ma gwiazdki to należy spacją sprawić aby była i zapisać zmiany.

Następnie należy skonfigurować xinet.d tak aby obsługiwał tftpd. W tym celu należy utworzyć plik: /etc/xinet.d/tftpd i wpisać do niego treść:

service ftp {
disable = no
socket_type = stream
protocol = tcp
wait = yes
user = nobody
server = /usr/sbin/in.ftpd
server_args = /tftpboot
port = 69
}

Ostatecznie pozostaje już tylko zrestartować superserwer i utworzyć katalog główny dla tftpd:

root@raspberrypi# service xinet.d restart
root@raspberrypi# mkdir /tftpboot
root@raspberrypi# chown pi:users /tftpboot

Po przygotowaniu serwerów przyszedł czas na dodanie infrastruktury PXE. Na początek należy pobrać najnowszą paczkę z Syslinux. Można to zrobić pod tym adresem, ale dla mnie o wiele wygodniej było po prostu zainstalować paczkę syslinux w moim Archu:

morti@radon$ sudo pacman -S syslinux

Jestem pewien, że dla Ubuntu i wszystkich pozostałych dystrybucji również taka paczka będzie. Polecenie zaowocowało utworzeniem katalogu /usr/lib/syslinux wraz z interesującą zawartością, choć mnie interesowały tylko niektóre pliki które skopiowałem na Raspberry Pi do katalogu /tftpboot:

morti@radon$ cd /usr/lib/syslinux
morti@radon$ scp pxelinux.0 vesamenu.c32 chain.c32 pi@rpi:/tftpboot/

Pierwszy ze skopiowanych plików (pxelinux.0) jest wymagany, żeby PXE w ogóle wystartowało. Kolejne dwa to obiekty com (przynajmniej tak się do nich odnoszą na wiki syslinuxa). Pierwszy z nich pozwoli nam oglądać piękne graficzne menu (zupełnie jak przy GRUBie), a drugi – załadować Windowsa (o czym za chwilkę).

Pójdźmy teraz z powrotem na Raspberry Pi i utwórzmy podstawowy plik konfiguracyjny. (Dla ułatwienia pracy do testów serwera PXE wykorzystuję maszynę wirtualną o adresie MAC: 08:00:27:6E:6B:99):

pi@raspberrypi$ mkdir /tftpboot/pxelinux.cfg
pi@raspberrypi$ cd /tftpboot/pxelinux.cfg
pi@raspberrypi$ touch 01-08-00-27-6e-6b-99
pi@raspberrypi$ touch default.virtual
pi@raspberrypi$ touch graphics.conf

Powyżej utworzyłem katalog, a w nim trzy pliki. Pierwszy z nich to plik konfiguracyjny dla mojej wirtualnej maszyny. Jak widać nazwa to po prostu adres MAC poprzedzony 01 na początku. Istotnym okazał się fakt, że cyfry szesnastkowe muszą być literkami małymi.  Drugi plik będzie modyfikowany przez zewnętrzne skrypty i będzie zawierał wpis dotyczący tego, który z systemów zostanie wybrany domyślnie. Ostatni z plików to już tylko konfiguracja wyglądu, którą włączymy sobie do pliku głównego.

Zaczynając ponownie od początku zdefiniujmy zawartość pliku o dziwnej nazwie:

PROMPT 0
UI vesamenu.c32
TIMEOUT 100

MENU TITLE Moje cudowne menu!
MENU AUTOBOOT System wystartuje za # sekund…

MENU INCLUDE  pxelinux.cfg/graphics.conf
MENU INCLUDE pxelinux.cfg/default.virtual

label localhdd
menu label ^Pierwszy dysk twardy
kernel chain.c32
append hd0

label windows
menu label ^Windows 7
kernel chain.c32
append hd0 2

Na początku ustawiamy aby system nie pytał użytkownika, który system uruchomić. Opcja PROMPT sprawiła mi trochę problemów. Przecież chciałem mieć ewentualnie wybór manualny. Później okazało się, że działa nieco inaczej niż zakładałem. Na początku użytkownik nie jest pytany i uruchamiany jest zdefiniowany niżej moduł vesamenu.c32, który wyświetla menu graficzne, w którym z kolei można już bez problemu wybrać żądany system. Dalej ustawiany jest timeout na 10 sekund (tak to jest wartość 100). Oczywiście określa to ilość czasu jaką użytkownik ma na ewentualną reakcję. Dalej zdefiniowane są mało istotne w tym wypadku tytuł menu oraz tekst informujący za ile sekund zostanie wybrana opcja domyślna, a po nich załączane są pliki z konfiguracją wyglądu ekranu bootloadera oraz domyślnie wybraną opcją do uruchomienia.

Prawdziwie interesujące rzeczy znajdują się niżej. Zdefiniowane są tutaj dwa wpisy. Pierwszy uruchamia bootloader z pierwszego dysku twardego, który w moim przypadku wywołuje GRUBa domyślnie ustawionego na start Arch Linuksa. Drugi wpis uruchamia system Windows bezpośrednio z drugiej partycji pierwszego dysku twardego. Oba wpisy zrealizowane są w podobny sposób i korzystają z modułu chain.c32, który pozwala po prostu przekazać sterowanie dalej.

W tej chwili wystarczy do pliku /tftpboot/pxelinux.cfg/default.virtual wpisać zawartość default localhdd lub default windows i oczywiście ustawić w maszynie wirtualnej aby uruchamiała się przy użyciu PXE. Naszym oczom powinno ukazać się menu zezwalające na wybór jednej z dwóch opcji z jedną z nich oznaczoną jako domyślną. Ostatecznie, żeby nie biły nas po oczach domyślne, bardzo niefortunnie dobrane kolory, pxelinuxa możemy wypełnić treścią plik /tftpboot/pxelinux.cfg/graphics.conf:

MENU COLOR tabmsg 37;40      #80ffffff #00000000
MENU COLOR hotsel 30;47      #40000000 #20ffffff
MENU COLOR sel 30;47      #40000000 #20ffffff
MENU COLOR scrollbar 30;47      #40000000 #20ffffff
MENU BACKGROUND blue.png
MENU MASTER PASSWD yourpassword
MENU WIDTH 80
MENU MARGIN 22
MENU PASSWORDMARGIN 26
MENU ROWS 6
MENU TABMSGROW 15
MENU CMDLINEROW 15
MENU ENDROW 24
MENU PASSWORDROW 12
MENU TIMEOUTROW 13
MENU VSHIFT 6
MENU PASSPROMPT Podaj haslo:
NOESCAPE 1
ALLOWOPTIONS 0

Powyższa konfiguracja zakłada istnienie pliku /tftpboot/blue.png o wymiarach 640×480 pikseli.

Jedyne co pozostało to utworzyć analogiczną konfigurację dostosowaną do każdego komputera wymagającego takich zabiegów i przestawienie ich w tryb bootowania przez PXE. Zapewne pomocnym byłoby utworzenie dodatkowo skryptów, które zmieniają plik /tftpboot/pxelinux.cfg/default.virtual (lub podobny – dla każdej maszyny inny) oraz wysyłają magiczny pakiet WOL do sieci lokalnej.

W taki sposób utworzyłem sobie konfigurację, która pozwala uruchomić jeden z zainstalowanych lokalnie systemów operacyjnych. Zaletą takiego rozwiązania jest to, że w przypadku gdy zepsuję sobie na przykład bootloader to wystarczy, że przez PXE uruchomię np. Tiny Core Linux i będę mógł bez problemów wszystko naprawić. Nigdy więcej poszukiwań LiveCD 😉 Choć zapewne lepiej nic nie psuć…

Dalsze plany

Nie trzeba być specjalnie bystrym, żeby zobaczyć, że takie rozwiązanie jest dalekie od ideału. Musiałbym się zalogować na Raspberry Pi za każdym razem kiedy chcę uruchomić odpowiedni system operacyjny. Nie jest to zbyt wielkie ułatwienie w stosunku do tego co było wcześniej 🙂 Z tego powodu planuję rozszerzyć funkcjonalność tego zestawu o dwie rzeczy.

Pierwszą z nich będą dwa fizyczne przyciski podpięte pod Raspberry Pi. Oba będą włączać mój komputer stacjonarny, ale każdy z nich będzie ustawiał inny system operacyjny do uruchomienia. To już będzie duży zysk dla mnie ze względu na to, że przycisk włączania komputera mam głęboko pod biurkiem, a oczekiwanie na pojawienie się GRUBa w celu wyboru systemu po prostu mnie nie cieszy 😉 Nie raz już zdarzyło się, że restartowałem system dlatego, że uruchomił się nie ten, który chciałem. (Oczywiście po tym znów odchodziłem od komputera i ponownie włączał się ten, którego nie chciałem ;))

Druga funkcjonalność będzie o wiele zabawniejsza ponieważ mam zamiar utworzyć Jabberowego bota, któremu będę mógł przez komunikator internetowy z innego komputera lub z telefonu wywołać procedurę uruchamiania odpowiedniego systemu.

Myślę, że takie ustawienie będzie dość wygodne w użytkowaniu. Jeśli kogoś to nie przekonuje i nie widzi potrzeby takiego cudowania, by po prostu uruchomić system operacyjny to… trudno 😉 Różni ludzie mają różne potrzeby 🙂

Jak już uda mi się stworzyć opisane powyżej rozszerzenia to zapewne zaprezentuję je w jakimś kolejnym wpisie, ale nie spodziewałbym się tego zbyt szybko ^^.

Ubuntu – dwa monitory na nowo

Po obejrzeniu statystyk oglądania mojego bloga zauważyłem, że znaczna większość odwiedzających przychodzi tu z zapytania „ubuntu dwa monitory”. Kiedyś pisałem już o tym ale tamto rozwiązanie jest już co najmniej nieaktualne. Dzisiaj istnieje o wiele lepsze rozwiązanie – stworzone z myślą o laptopach, ale ja sam używam go na komputerze stacjonarnym z dwoma monitorami.

Wspomniane rozwiązanie nazywa się disper i jego strona domowa znajduje się tutaj: http://willem.engen.nl/projects/disper/. Aktualnie najnowsza wersja opatrzona jest numerem 0.3.0, ale działa już bardzo poprawnie. Cały projekt napisany jest w pythonie więc nie ma problemów z kompilacją i miliardem zależności do rozwiązania. Cała instalacja składa się z upewnienia się, że mamy Pythona i narzędzie make. Możemy to zrobić na przykład tak:

$ sudo apt-get install build-essential python2.7

Następnie ściągamy, makeujemy i instalujemy najnowszą wersję dispera (w moim przypadku 0.3.0):

$ wget http://ppa.launchpad.net/disper-dev/ppa/ubuntu/pool/main/d/disper/disper_0.3.0.tar.gz
$ tar zxvf disper_0.3.0.tar.gz
$ cd dispercur
$ make
$ sudo make install

To tyle jeśli chodzi o instalację. Teraz jak tego używać? Zacznijmy może od wyświetlenia pomocy programu, która już sama mówi wszystko co trzeba wiedzieć:

$ disper -h

Jeśli bardziej lubisz czytać strony man lub info to też są dostępne.

Poniżej przedstawię podstawowe komendy dispera wraz z krótkim opisem:

  • disper -l  – powoduje wyświetlenie wszystkich dostępnych monitorów oraz ich rozdzielczości
  • disper -s – wykorzystywany jest jedynie pierwszy monitor
  • disper -S – wykorzystywany jest jedynie drugi monitor
  • disper -e – wykorzystane oba monitory, jeden z nich jest rozszerzeniem ekranu (xinerama)
  • disper -c – klonowanie obrazu – na obu monitorach jest to samo
  • disper -C – przełącza cyklicznie pomiędzy powyższymi trybami (coś jak Fn+Fx w laptopach [x to liczba od 1 do 12 😉 ] )

Dodatkowo możemy też wyeksportować nasze ustawienia do pliku:

$ disper -p > ekran.conf

Lub zaimportować te ustawienia:

$ cat ekran.conf | disper -e

Jedną poważną zaletą używania dispera jest to, że zmieniamy tryby graficzne i nie musimy restartować serwera Xów. To znaczy po prostu tyle, że uruchomione programy nie zostają ubite w tym procesie i po zmianie ekranu możemy po prostu pracować dalej.

Mam nadzieję, że ten wpis pomoże ludziom trafiającym tu codziennie z problemami dotyczącymi obsługi dwóch monitorów. Oczywiście disper będzie działał w dowolnym innym Linuxie. Wystarczy mieć pythona oraz make’a, a to jest wszędzie.

Z tym postem muszę stwierdzić z zadowoleniem (ale też z lekkim smutkiem), że czasy kiedy siedziało się tygodniami przed Linuxem, żeby coś w nim uruchomić powoli się kończą. Powoli 😉

PS. Jeśli kogoś interesuje dlaczego „z lekkim smutkiem” to spieszę z odpowiedzią. Otóż może i siedzenie i grzebanie było czasami nużące i frustrujące, ale ostateczny sukces dawał ogromny zastrzyk samozadowolenia 😉

[Aktualizacja]

W moim opisie przy instalacji były błędy. Z niewiadomych przyczyn po ściągnięciu paczki zupełnie pominąłem krok rozpakowywania i przejścia do katalogu źródeł. Dlatego niektórym prezentowane  rozwiązanie mogło nie działać! 😉

[Aktualizacja 2]

Dodałem nowy wpis o bardziej zaawansowanym wykorzystaniu narzędzia disper: https://moriturius.wordpress.com/2012/03/09/ubuntu-dwa-monitory-disper-starcie-drugie/

Szybkie wybranie utworu w MPD

W ostatnim wpisie pokazałem jak można szybko włączyć ulubioną listę utworów. Pod koniec napisałem, że można też pokombinować trochę i zrobić skrypt do wyboru konkretnego utworu z załadowanej już listy.

Okazało się to nieco bardziej kombinatorskie ale w końcu się udało 🙂 Poniżej daję skrypt który pokazuje listę utworków i po wyborze jakiegoś zaczyna go odtwarzać:

#!/bin/bash

if [ -z `pgrep mpd` ]
then
 echo "MPD nie jest uruchomione!"
 exit 1
fi

UTWORY=$(mpc playlist | sed 's/\(.*\)/"\1"/' | awk '{print NR,$0}' )

CMD="zenity --title='Wybór utworu' --width=600 --height=600
 --list --column '#' --column 'Utwór' $UTWORY"
NUM=$(eval $CMD)

if [ -z $NUM ]
then
 exit 0
fi

mpc play $NUM

Szybkie włączanie playlist MPD

Korzystając z dzisiejszego dnia wolnego postanowiłem pogrzebać trochę w systemie. Uporządkowałem więc problemy z dźwiękiem, które pojawiły się po zainstalowaniu KDE. Problem był taki, że dźwięk mogła odtwarzać tylko jedna aplikacja w danej chwili. Rozwiązanie było dość proste bo wystarczyło zainstalować PulseAudio i przekierować na niego cały dźwięk.

Tak czy inaczej pomyślałem sobie, że fajnie byłoby móc szybko wybrać sobie szybko playlistę utworów i zacząć ją odtwarzać najszybciej jak się da. Kto lubi czekać aż włączy się program do odtwarzania muzyki? Jasną jest sprawą, że prędkość zależy od programu 🙂 W tej sprawie Music Player Daemon [MPD] jest nie do pobicia. Głównie dlatego, że jest to jedynie serwer dźwięku bez żadnego graficznego zatem nie ładuje żadnych zbędnych bibliotek. Prawdę mówiąc to działa dokładnie jako serwer i jedyna możliwość jego obsługi to podłączenie się do niego poprzez program klienta. Klientów jest bardzo wiele. W większości są to programy używające jakiegoś ładnego GUI co sprawia, że są wygodne i działają w sumie podobnie do zwykłych programów do odtwarzania audio jak Windows Media Player, Amarok czy Rhythmbox [oraz wiele innych :)].

Najbardziej interesujące jest jednak narzędzie konsolowe do obsługi tegoż serwera. Działa natychmiastowo zatem włączenie serwera i rozpoczęcie odtwarzania muzyki to kwestia kilku poleceń. Ale co szybszego jest w odpalaniu konsoli i wklepywaniu poleceń? NIC! Dlatego trzeba to trochę zautomatyzować by było lepiej i wygodniej. Prowadzi do tego bardzo długa droga składająca się z dwóch kroków:

  1. Utworzenie pliku uruchamiającego demona mpd (jeśli jeszcze nie działa) oraz wyświetlającego wszystkie nasze playlisty.
  2. Dodanie globalnego (dla systemu) skrótu klawiszowego do uruchomienia tego skryptu.

Najpierw należy utworzyć skrypt gdzieś na domyślnej ścieżce wyszukiwania systemu. Ja dodałem do zmiennej PATH katalog ~/.bin dzięki czemu wystarczyło utworzyć plik:

touch ~/.bin/mpdplaylist
chmod +x ~/.bin/mpdplaylist

Do pliku wpiszmy kilka poleceń:

#!/bin/bash

MPDPID=`pgrep mpd`
if [ ! -z $MPDPID ]
then
 echo Uruchamiam mpd...
 mpd
fi

LISTY=`mpc lsplaylists`
LISTA=`zenity --list --text "Proszę wybrać listę:" --column "Listy" $LISTY`

if [ -z $LISTA ]
then
 exit
fi

mpc clear
mpc load $LISTA

mpc shuffle
mpc play

W powyższym skrypcie najpierw sprawdzamy czy jest uruchomiony MPD. Jeśli nie to go uruchamiamy. Jeśli tak to pobieramy wszystkie playlisty oraz wyświetlamy okienko, w którym będziemy mogli wybrać tę do odtwarzania. Jeżeli lista nie zostanie wybrana to nic nie zmieniamy i kończymy skrypt.

Później czyścimy aktualną listę odtwarzania i ładujemy wybraną. Na koniec mieszamy utwory (aby nie słuchać ich zawsze w tej samej kolejności) i uruchamiamy odtwarzanie.

Ostatnim krokiem do szczęścia jest ustawienie globalnego skrótu klawiszowego. W KDE4 należy uruchomić Ustawienia Systemowe > Skróty i gesty >Własne skróty i tam dodać odpowiedni skrót uruchamiający nasz skrypt.

W efekcie otrzymujemy okienko:

WAŻNE: do działania skrypt potrzebuje programu zenity!

Takie rozwiązanie sprawy pozwala niemalże natychmiast rozpocząć odtwarzanie ulubionych utworów. W razie gdybyśmy chcieli posłuchać innej playlisty wystarczy znów wcisnąć skrót i wybrać ją z proponowanych.

Można by jeszcze utworzyć podobny skrypt tylko do wyświetlania wszystkich utworów na danej playliście żeby skoczyć do odtwarzania go. Wówczas dałoby się powiedzieć, że sam system działa jak odtwarzacz multimediów… Zwłaszcza jeśli połączy się go z przełącznikiem utworów na pasku zadań  😉

Rozwiązane: Problem z restartem i wyłączaniem Gentoo

Ostatni przez podejrzanie długi czas nie pojawiły się w moim pięknym linuksie żadne problemy. Czasem jakieś drobne niedogodności po aktualizacji danego pakietu, ale nie było to nic specjalnie wyzywającego, ani tym bardziej pilnego.

Ostatnio jednak po aktualizacji „zepsuło” się wyłączanie systemu. Efekt był taki, że kiedy chciałem uruchomić ponownie, bądź wyłączyć komputer system wyłączał się w miarę normalnie, aż do pokazania komunikatu:

INIT: No more processes left in this runlevel.

Ten komunikat pojawia się zawsze i to nie jest problem. Problemem było to, że nie działo się nic później – normalnie powinno nastąpić uruchomienie ponowne/wyłączenie komputera. Jedyne co mi pozostawało to wyłączyć komputer „z palca” 😉

Jak się okazało – aktualizacja nic nie popsuła, ale nowa wersja oprogramowania wymagała specyficznych zapisów w odpowiednim pliku konfiguracyjnym i stąd wziął się problem.

Sprawa wyjaśniła się, gdy dzisiaj po raz kolejny zasiadłem aby pozbyć się tego denerwującego „błędu”. Rozwiązanie znalazłem zaledwie w kilka chwil,podczas gdy poprzednio przekopywałem tony stron.

Oczywiście nie byłem jedynym człowiekiem z tą dolegliwością więc nie powinno być dla nikogo zaskoczeniem, że instrukcje naprawy tego stanu rzeczy znalazłem tu: http://bugs.gentoo.org/show_bug.cgi?id=251024#c10.

Wychodzi na to, że brakowało mi po prostu dwóch linijek w /etc/inittab:

l0s:0:wait:/sbin/halt -dhip l6r:6:wait:/sbin/reboot -dk

Po ich dodaniu problem znikł i mam nadzieję, że już nigdy więcej nie wróci 🙂

Dystrybucje

Korzystając z wolnego czasu postanowiłem sprawdzić jak radzą sobie najbardziej znane (przynajmniej moim zdaniem) dystrybucje Linuksa. Pamiętam swoje początki z tym systemem operacyjnym – wówczas byla to dystrybucja RedHat 9. Od tamtego czasu sporo się zmieniło…

Fedora

Na pierwszy ogień postanowiłem puścić Fedorę. Po zainstalowaniu ładnie wykryła sieci bezprzewodowe co zasługuje niewątpliwie na ogromny plus gdyż nawet Ubuntu miał z moją kartą sieciową problemy, które znikły dopiero w najnowszej dystrybucji. Na początek chciałem zainstalować Gnome-Do. Świetne narzędzie do wszystkiego dla użytkowników środowiska GNOME. Po zainstalowaniu okazało się, że nie ma tam żadnych wtyczek (w Ubuntu były zainstalowane z programem). Postanowiłem więc poszukać wtyczek które mnie interesowały. Kilka godzin i milion prób później wciąż nie miałem wtyczek… Porzuciłem więc ten pomysł i postanowiłem przyjrzeć się reszcie systemu.

Zauważyłem, że w Fedorze bardzo duży nacisk kładziony jest na bezpieczeństwo. To cud, że aby ruszyć myszą nie trzeba wpisywać hasła root’a… Co prawda jest to trochę uciążliwe, ale w końcu bezpieczeństwo jest bardzo ważne…

Była jednak pewna rzecz (oprócz irytującego braku wtyczek do gnome-do), która sprawiła, że postanowiłem więcej nie dotykać tego systemu – instalator programów/pakietów. Mimo iż pomysł z kolejkowym dostępem do blokady operacji „na”programach” przypadł mi do gustu to wyszukanie pakietu, który mnie interesował w repozytoriach graniczyło niemalże z cudem – nawet jeśli mniejwięcej znałem nazwę samego pakietu…

Fedora początkowo zrobiła na mnie niezłe wrażenie, ale o przyjazności użytkownikowi chyba jeszcze niewiele słyszała (chociaż z drugiej strony ma interfejs grafizcny 😉 ). Jednak po kilku ładnych godzinach klikania i sprawdzania i kombinowania stwierdziłem, że nie jest to system z którym chciałbym żyć na codzień… Postanowiłem spróbować czegoś innego…

OpenSUSE

Następny w kolejce był znany mi już od jakiegoś czasu OpenSUSE. Od naszego ostatniego spotkania poczynił niesamowite postępy. Zaskoczyło mnie trochę, że i on nie miał problemów z rozpoznaniem mojej karty sieciowej i wykryciem sieci bezprzewodowych. Kiwając z uznaniem głową postanowiłem zainstalować sobie na początek sterowniki do karty graficznej. Przyznam się, że trochę się przy tym namęczyłem, ale wszystko przez mój niedobry pośpiech i niechęć do czytania instrukcji 😉 Gdyby nie to prawdopodobnie nie sprawiłoby mi to kłopotu. Tak czy inaczej po godzince czy dwóch miałem już zainstalowane sterowniki NVidii do mojej karty i z zapałem ruszyłem psuć inne rzeczy.

Następną rzeczą jaką musiałem zrobić było włączenie odtwarzacza muzyki. Tutaj domyślnym okazał się być mój ulubiony Banshee (zatem plus dla susła 🙂 ). Niestety okazało się, że nie chce mu się odtwarzać mp3. Okazało się, że brakowało mu codeców, które w Ubuntu są instalowane domyślnie. Nie było ich i pewnie nigdy nie będzie w domyślnej instalacji systemu ponieważ wówczas kolidowałoby to z częścią Open nazwy tegoż systemu 🙂 Po zgooglowaniu problemu okazało się, że wystarczy ściągnąć i uruchomić jeden mały pliczek i reszta zrobi się za mnie. Tak się stało i po restarcie komputera mogłem się cieszyć moimi ulubionymi utworami wypełniającymi przestrzeń.

Tak świetnie przygotowany do dalszej pracy rozpiąłem guzik pod szyją w moim T-Shirt’cie bez guzików i ruszyłem instalować Netbeansa. Tutaj troszeczkę się rozczarowałem. Netbeans w repozytoriach był w wersji 5.0 (najnowsza to 6.5 czy nawet 6.7) , a po instalacji i uruchomieniu straszliwie wolno pracował. Pomyślałem wówczas: „Hmm… OpenJDK”. Ściągnąłem więc i zainstalowałem najnowsze JDK od SUNa. Następnie ściągnąłem najnowszego Netbeansa z internetu i (po uprzednim odinstalowania tego z repów) zainstalowałem go na dysku. Po uruchomieniu śmiga równie pięknie jak pod znanym i lubianym przez wszystkich systemem.

Dalszych testów już właściwie nie robiłem bo postanowiłem, popracować trochę z tym systemem i przyjrzeć mu się dokładniej. Jeśli zauważę jakieś ogromne niedogodności czy coś godnego uwagi to napiszę o tym na tym blogu.

Podsumowanie

W podsumowaniu chciałbym przyrównać te systemy do najbardziej mi obecnie znanego Ubuntu. Wspomniana na początku Fedora nie ma szans aby równać się z łatwością użytkowania potomka Debiana, ale za to jest mnie idiotoodporny, a co za tym idzie – bardziej konfigurowalny. Właściwie nei ma co tu porównywać gdyż Fedora nigdy nie mówiła, że ma zamiar być najbardziej popularną i łatwą w użyciu dystrybucją. Polecam ją ludziom, którzy nie boją się wyzwań (a uważają, że Gentoo to trochę za głęboka woda 😉 ).

Jeśli chodzi o OpenSUSE to w łatwości użytkowania również przegra z Ubuntu i nie poleciłbym go całkowicie początkującym. Jest jedna rzecz, która ogromnie przypadła mi tutaj do gustu. Ustawianie zmiennych systemowych. O ile korzystając z Ubuntu męczyłem się z ustawieniem jednej zmiennej przez kilka dni przeszukując fora, na których każdy miał 100 pomysłów i żaden tak do końca nie skutkował to tutaj wszedłem zagooglowałem o ustawianiu zmiennych systemowych i zaraz dowiedziałem się, że jeśli chodzi o jednego użytkownika to wystarczy ustawić .bashrc w jego katalogu domowym, a globalnie – dodać exportowanie zmiennych w pliku /etc/bash.bashrc.local . Tak to na prawdę takie proste 😉

CommonLib dla Linuxa!

Postanowiłem ostatnio pouczyć się troszkę korzystanie z pakietu autotools i wpadłem na pomysł aby przy okazji zrobić coś dobrego dla ludzkości. Po złączeniu obu pomysłów w jeden wyszło na to, że zabrałem się za stworzenie paczek Linuxowych dla świetnej biblioteki autorstwa Regedita, służącej do najróżniejszych dość często wykonywanych czynności. Stąd też pewnie jej nazwa –  CommonLib.

Poniżej znajdują się linki do wersji z kodem źródłowym oraz do paczki pod Ubuntu/Debiana:

Instalacja pliku DEB nie powinna przysporzyć problemów natomiast jeśli chodzi o wersję źródłową to instaluje się ją standardowo:

tar -zxf commonlib-8.1.tar.gz
cd commonlib-8.1
./configure
make
sudo make install

UWAGA: Mam wrażenie, że w paczce DEB nie ma umieszczonych zależności. Moduł ZlibUtils wymaga biblioteki zlib-dev. Wersja źródłowa sama się o to upomni 🙂