Linux dla leworęcznych

Nauczyłem się obsługiwać myszkę lewą ręką. Prawa czasem pobolewa mnie po pracy, więc pomyślałem, że czas na zmianę. Wszystko generalnie działa, ale skróty klawiszowe, których Gnome ma coś około osiemdziesięciu i są naprawdę przydatne, są zaprojektowane pod używanie ich lewą ręką. Z pomocą przyszły stare, dobre Xsy. Podawany przeze mnie sposób nie zadziała na Waylandzie.

Najpierw sprawdzam jak wygląda moja klawiatura w Xsach:

xmodmap -pke

Następnie zmapowałem klawisze:

  • NUM7 jako F4,
  • NUM8 jako lewy ALT,
  • NUM4 jako TAB,
  • NUM0 jako WINDOWS,
  • NUM2 jako c,
  • NUM3 jako v.

Zapisałem to sobie w krótkim skrypcie shella, który z czasem będzie pewnie rozbudowywany:

#!/usr/bin/sh
# mapowanie klawiatury dla lewej reki
xmodmap -e "keycode 79 = F4 F4 F4 F4 F4 F4 XF86Switch_VT_4"
xmodmap -e "keycode 90 = Super_L"
xmodmap -e "keycode 88 = c"
xmodmap -e "keycode 89 = v"
xmodmap -e "keycode 80 = Alt_L"
xmodmap -e "keycode 83 = Tab ISO_Left_Tab Tab ISO_Left_Tab"

Po dwóch dniach przyzwyczajania pracuje mi się z tym wspaniale. Lewa ręka jest na myszcze, a prawa na klawiaturze numerycznej. Jednego, czego brakuje to lewego CRTL, którego chcę mieć pod jedynką, ale nie mogę go prawidłowo zmapować. Dopiszę, kiedy mi się to uda.

Wyzwanie RHCE #6

W tej części bierzemy się za Kerberosa, czyli logowanie domenowe. Na razie działa logowanie bez haseł trzymanych lokalnie. Resztę trzeba będzie zostawić za później, bo czas leci i chcę zrobić jak najwięcej przed kolejną miesięczną opłatą za kurs.

Wpisy o VPSach, o których coś tam na końcu mówiłem:

MacPi Log 5

Miałem trochę czasu na ustawianie Raspbiana. Najbardziej pasuje mi wersja Lite, do której doinstalowuję potrzebne rzeczy, ale tym razem skusiłem się na pełne iso z pulpitem, które odchudziłem ze zbędnych aplikacji i nieco dostosowałem pod siebie.

Ekipa Raspberry stworzyła swego czasu zupełnie nowy (tak, jeszcze jeden) Linuksowy pulpit o nazwie Pixel. Jest zrobiony na GTK2, jest bardzo lekki, estetyczny i całkiem miły w obsłudze. Bardzo wiele rzeczy da się wyklikać i w miarę szybko zrobiłem z nim, co chciałem. Jak pisałem wcześniej, będzie tutaj kilka programików graficznych, które chcę mieć zawsze pod ręką.

Przy okazji sprawdzam co jakiś czas temperaturę i wyniki są bardzo zadowalające:

sudo vcgencmd measure_temp
temp=45.1'C

Duża, metalowa obudowa bardzo dobrze radzi sobie z niewielką ilością ciepła, wytwarzanego przez Malinki. Płytka włożona w oryginalną, maleńką obudowę nagrzewa się nieco szybciej.

MacPi Log 4

No i działa. 🙂 Na razie jest skromnie: dwie Malinki (w wersji drugiej i trzeciej), switch, zasilacze i terabajtowy dysk. Do obudowy jeszcze trochę by weszło, ale trzeba by było listwę zasilającą wymienić. Po kolei. Najpierw przygotowałem obudowę i rozplanowałem położenie wszystkich rzeczy:

Nie ma tu wielkiej filozofii. Długość i „sprężystość” kabli nie bardzo pozwalały na inny układ, a mam w planach dokupienie co najmniej jeszcze jednego Raspi Zero W, który gdzieś się musi zmieścić.

Podłączyłem na próbę sprzęt i okazało się, że bez problemu zmieści się w obudowie. Trzeba było jednak odrobinę dostosować ją do moich potrzeb.

Przede wszystkim zadbałem o izolację pomiędzy obudową a twardym dyskiem oraz switchem. Nie, żeby była w tym wypadku bardzo konieczna, ale nie zaszkodzi. Pomaga na chłodzenie i ewentualne wibracje.

Po przegrzebaniu piwnicy oraz domowych półek ustalił się plan montażu komputerków: wybrałem piętrowe łóżko.

Pierwsze przymiarki do ustawienia sprzętu, jeszcze nic nie jest przymocowane na stałe.

No i tak lepiej. 🙂 Do montażu wykorzystano: dwa kawałki drewnianej mozaiki, pocięty, metalowy wieszak, koraliki oraz patyczki do baloników. Całość jest przyklejona do obudowy, ale założona w taki sposób, że komputerki można w każdej chwili wyjąć. RaspberryPi 3, jako odrobinę cieplejszy, znalazł się na górze.

Robimy mały bałagan. Jak widać kable są wszędzie, ale wymyślę jeszcze sposób, żeby je rozplątać.

Jeszcze tylko małe zabezpieczenie przed pająkami. Nie macie pojęcia ile tych małych cwaniaków potrafi się chować w cieplutkiej i suchej obudowie.

A tak wygląda nowy Macintosh Performa 6320 na półce. Jeden z najgorszych Maców w ogóle doczekał się wreszcie wnętrza na miarę tej ślicznej obudowy. Do czego teraz służy? Malina 2 ma sambę i podłączony dysk, z czego bardzo intensywnie korzystam. Nie trzymam już żadnych filmów, ani muzyki na innych komputerach. Malina 3 ma pulpit, na który dostaję się przez vnc. Zainstalowałem tam kilka drobiazgów, ale docelowo będzie mieć na biurku własny monitor i wyświetlać tam, między innymi. kanały RSS z różnych blogów, lub innych źródeł, które lubię czytać. Fajnie mieć te informacje pod ręką i mieć pierwszego komenta. 😛

Oczywiście to jeszcze nie koniec. Oprócz wybielenia obudowy zostało kilka spraw:

  • wymiana przedłużacza na taki, by zmieścił jeszcze jeden zasilacz,
  • potrzebny będzie jeszcze jeden twardy dysk,
  • chciałbym jeszcze Raspberry Zero W.

Najważniejsza różnica w porównaniu z moją poprzednią konfiguracją polega na tym, że sprzęt nie jest włączony przez cały czas. W związku z tym VPS od OVH zyskał nieco na wartości. Być może model Zero będzie włączony 24/7 i będzie obsługiwał irssi oraz kilka innych drobiazgów. Chciałbym, w miarę możliwości, mieć jak najwięcej prywatnych rzeczy u siebie w mieszkaniu, a nie we francuskiej serwerowni. 🙂 Jeszcze się zobaczy. c.d.n…

Mac 6320 Server

Mała zajawka: zakupiłem właśnie Macintosha 6320, mój wymarzony komputer późnego dzieciństwa. Szczęśliwie dla mnie pozostał w marzeniach, gdyż to jeden z najgorszych Maców w ogóle. Można mieć jednak dużą moc w pięknej, dla mnie, obudowie.

Mam za sobą rozbieranie tego potworka na części. Jedyne, co może się przydać, to zasilacz i pamięć, które oddam kolekcjonerom. Procesor PowerPC603 jest niestety zamocowany na płycie głównej. Rozkładanie zajęło mi nieco ponad godzinę, gdyż przypominało rozbieranie wieżyczki od czołgu: dużo tam rzeczy i niekoniecznie sensownie podłączonych. W środku jest sporo pustego miejsca, a kable są wszędzie.

W środku znajdą się cztery RapberryPi, trochę dysków, pięcioportowy switch oraz przedłużacz z zasilaczami. Wybrałem już stosowny sprzęt. TP-Link TL-SF1005D połączy je razem. Nie chcę robić oddzielnej podsieci, ale switch pozwoli na częściowe odizolowanie „wewnętrznego” ruchu. Dyski to WD My Passport. Mam już taki jeden i spisuje się bardzo dobrze. Nie zależy mi zbytnio na szybkości zapisu, ma być dużo miejsca na dane. Zastanwaiam się jeszcze czy Raspi będą w drugiej, czy trzeciej wersji. Trójka ponoć lubi się nagrzać przy większym obciążeniu. Na tył obudowy przygotuję drewnianą płytkę z otworami na wszystkie kable oraz dwa wentylatory podłączone do usb.

Najdłużej zejdzie mi się zapewne z przygotowaniem drewniano-plastikowego stelażu dla całego sprzętu, żeby nie latał w środku. Niby nie będę wszystkim podrzucał, ale dobrze by było, żeby stało stabilnie i miało odpowiednio dużo miejsca na przewiew.

Będę informował na bieżąco.

WindowMaker

Mam małego i niezbyt wydajnego laptopa „podróżnego”. Zabieram go prawie wszędzie i jeśli ktoś ukradnie, to mi nie szkoda. Partycje są zaszyfrowane i nie dałem za niego wiele pieniędzy. Co prawda Gnome działa na nim całkiem nieźle, ale pomyślałem, że pora na coś bardziej wyszukanego. Zwłaszcza, że jest tam Fedora Rawhide i aktualizacje zepsuły mi niedawno GDM na tyle, że Gnome przestał działać. 🙂 Wybór padł na jedne z moich ulubionych okienek: WindowMaker. Tak, to ten, który wygląda jak pulpit NeXTstation, albo Workbech Amigi, który swoją drogą też mi się podoba.

Żeby doprowadzić lekki pulpit do stanu używalności, trzeba chwilę nad nim spędzić. Konfiguracja WindowMakera zawarta jest w katalogu ~/GNUstep, można trochę też poustawiać rozbudowanym kreatorkiem. Osobiście wolę, kiedy wszystko jest w kilku prostych plikach konfiguracyjnych, jak w IceWM, albo Fluxboksie, ale trudno.

Dosyć ważne jest dla mnie szybkie włącznie i wyłączanie wifi oraz jasność ekranu. Mam więc skróty w bashrc:

# jasnosc ekranu
alias jasnosc='sudo /usr/local/bin/jasnienie'

# wifi
alias wifion='nmcli radio wifi on'
alias wifioff='nmcli radio wifi off'

# wylaczanie
alias wylaczanie='xterm -e /usr/local/bin/wylaczanie_dialog'

# przyspieszenie klawiatury
xset r rate 180 60

Jak to zazwyczaj w bashrc jest tutaj mały bałagan, więc po kolei. Jaśnienie jest niewielkim skryptem, ale pomagam sobie faktem, że przy sudo nie muszę wpisywać swojego hasła:

#!/usr/bin/bash

echo -n "Jest: "
cat /sys/class/backlight/radeon_bl0/brightness
echo -n "Ustaw na: "
read bright
sudo echo "$bright" > /sys/class/backlight/radeon_bl0/brightness
echo " "

W pliku brightness zapisana jest liczba pomiędzy 1 i 255 (albo 0 i 254, zapomniałem teraz), która odpowiada za jasność ekranu. Można więc bardzo precyzyjnie dostosować jasność do oświetlenia w autobusie, nie zużywając niepotrzebnie baterii. Wieczorem i w nocy można sobie pomóc ograniczając ilość niebieskiej barwy na ekranie:

xgamma -bgamma 0.8

Aliasy wifi odwołują się do nmcli, czyli narzędzia NetworkManagera, które coraz bardziej lubię. Co prawda dodawania nowej sieci to polecenie na dwie linijki, ale dorobię sobie kiedyś ułatwiacze w dialogu. wylaczanie_dialog to bardzo prosty mechanizm naśladujący gnomowe odliczanie do wyłączenia komputera:

#!/usr/bin/bash

echo " "
echo " W Y L A C Z A N I E   Z A   1 0   S E K U N D ."
echo " Nacisnij ctrl+c, zeby przerwac."
sleep 5

echo " "

echo " W Y L A C Z A N I E   Z A     5   S E K U N D ."
echo " Nacisnij ctrl+c, zeby przerwac."
sleep 5
sudo shutdown -h now

Tyle w bashrc. Trzeba się też zabrać za wygląd pulpitu. Żeby było mi łatwiej, szukam programów napisanych w GTK2 i konfiguracja jest w jednym miejscu, czyli pliku ~/.gtkrc-2.0:

gtk-icon-theme-name = "Cheser"
gtk-theme-name = "Adwaita"
gtk-font-name = "DejaVu Sans 11"

Do sprawdzania stanu baterii, pamięci i tym podobnych używam starego, dobrego Gtkrellm z moją ulubioną skórką Egan.

WindowMaker doczekał się też w ciągu lat kilku apletów, między innymi zegarka widocznego w prawodolnym rogu ekranu. Są też między innymi kontrolki głośności ALSY oraz kontrolki XMMS, ale nie cofam się aż tak. 🙂 Zdecydowana większość to ledwo cokolwiek robiące zabawki (jak zegar szesnastkowy), ale akurat klasyczny zegar jest przydatny.

Ostatnie miejsce, gdzie warto zajerzeć, to plik autostart w katalogu ~/GNUstep, gdzie (zgadliście) możemy owe zegarki oraz gkrellmy uruchamiać razem ze startem pulpitu. Szukałem też prostego i łatwego do ogarnięcia emulatora terminala. Wybór padł na LilyTerm, będący nieco dziwaczną mieszanką surowej prostoty oraz graficznego klikania w bardzo rozbudowanym menu kontekstowym. Do plików używam Thunara z Xfce, który nie został jeszcze przepisany na GTK3 oraz może łątwo montować udziały Samby, co dla mnie jest przydatne. Do logowania mam LightDM, a Xscreensaver robi za blokowanie ekranu po wybudzeniu.

Używam tego wszystkiego od jakiś dwóch miesięcy i wrażenia są jak najbardziej pozytywne. Przyjemnie jest wrócić do dawno nieużywanych aplikacji, a konieczność konfiguracji kilku rzeczy w terminalu dodaje mi przy okazji więcej możliwości.

Mój pierwszy VPS (2)

W poprzedniej części przekazaliśmy hojnie 5 dolarów dla Digital Ocean i mamy nasz VPS. Co teraz? Dostaliśmy ip oraz hasło roota, więc póki co jest to jedyny sposób, żeby się zalogować. Wpisujemy do terminala:

ssh root@ip.ip.ip.ip

i chwilę czekamy. Pojawi się dość nieprzyjemnie wyglądający komunikat o logowaniu po raz pierwszy do maszyny z naszego komputera.

The authenticity of host 'jakastamdomena.com (ip.ip.ip.ip)' can't be established.
RSA key fingerprint is [długa liczba].
Are you sure you want to continue connecting (yes/no)?

SSH nie ma możliwości sprawdzić czy nasz serwer jest nasz, czy tylko ktoś przypadkowo wysłał nam swoje IP. My wiemy swoje, wpisujemy więc yes i potwierdzamy enterem. Fajnie, mamy roota:

Wszystkie twoja baza są moja.

Jakkolwiek wszystko działa, warto ułatwić sobie życie i dodać na serwerze użytkownika z uprawnieniami sudo. Najlepiej o takiej samej nazwie, jak lokalny użytkownik na naszym komputerze w domu. Jestem Łukasz i moim kontem jest lukasz. Root poradzi sobie z tym bez żadnego problemu:

adduser lukasz
passwd lukasz

Co prawda nie będziemy używać hasła do logowania, ale warto wymyślić coś dobrego. Teraz dodajemy wspomnianego lukasza (czy innego użytkownika w twoim przypadku) do pliku /etc/sudoers, by uniknąć używania konta roota. Używamy do tego programu visudo i tak, to jest ten straszny vi. Wszystko, co musisz na razie o nim wiedzieć, to na początku wciśnij klawisz i. Teraz zjedź kursorami do tego fragmentu:


    103 
    104 ## Allows people in group wheel to run all commands
    105 %wheel  ALL=(ALL)       ALL
    106 
    107 ## Same thing without a password
    108 # %wheel        ALL=(ALL)       NOPASSWD: ALL
    109 

i zamień to na


    103 
    104 ## Allows people in group wheel to run all commands
    105 %wheel  ALL=(ALL)       ALL
    106 lukasz  ALL=(ALL)       ALL
    107 
    108 ## Same thing without a password
    109 # %wheel        ALL=(ALL)       NOPASSWD: ALL
    110 

Oczywiście jest to Linux i każdą rzecz można osiągnąć na co najmniej dwa sposoby. Jak napisano w komentarzu, mógłbym dodać siebie do grupy wheel, ale od zawsze dopisywałem się w tym miejscu. Takie stare nawyki. Teraz uwaga, będziemy wyłączać vi. 🙂 Jest o tym kilka dowcipów, ale zrobimy to porządnie. Najpierw wciśnij klawisz ESC, napisz :wq i potwierdź enterem. w oznacza zapisanie, q to wyjście. Visudo sam dopilnuje sprawdzenia składni i poinformuje nas o ewentualnych literówkach, mogących uniemożliwić logowanie się do systemu.

Czas wypróbować zmiany. Wyloguj się zupełnie z systemu, dokładnie tak, jak z okna terminala u siebie na komputerze. ctrl+d, exit, jak wolisz. Musimy przygotować klienta SSH po naszej stronie. Zamiast wpisywać hasło przy każdym logowaniu posłużymy się dwoma plikami zawierającymi (w dużym uproszczeniu) zahaszowane hasło. Jeden będzie na lokalnym komputerze, drugi na serwerku. Jeżeli pamiętasz tworzenie dropletu na Digital Ocean, mogła ci mignąć przed oczyma opcja dodania takiego klucza, ale zrobimy to ręcznie, co działa na każdym możliwym hostingu.

Najpierw wygenerujemy klucz u siebie. Robimy to tylko raz dla naszego konta. Kluczy nie trzeba odnawiać, czy tworzy ponownie dla każdego jednego serwera, którego używamy. Otwieramy okienko terminala i wpisujemy ssh-keygen.

Poziom hasła: silny.

Powyżej zamieściłem zrzut ekranu z losową maszyną wirtualną, na której nie zrobiłem jeszcze keygena. Program pyta o kilka rzeczy, ale najlepiej po prostu wciskać enter i pozostawić je domyślne. Czyli:

  • plik z hasłem zostaje w katalogu ~/.ssh,
  • nie wpisujemy hasła,
  • ponownie nie wpisujemy hasła.

Otrzymamy śmieszne literki oraz obrazek. Jest to „odcisk palca”, który może wygenerować jedynie nasz użytkownik i tylko na naszym komputerze. Są to dwa pliki: jeden z nich zawiera tylko i wyłącznie informacje jak zakodować nasze hasło, drugi tylko i wyłącznie je rozkodowuje. Ten drugi trzeba umieścić na naszym serwerze. Zanim weźmiemy się za myszkę, twórcy ssh zrobili wszystko za nas. Wystarczy:

ssh-copy-id ip.ip.ip.ip

Nasz klient SSH przyjmuje, że na serwerze mamy takiego samego użytkownika. Wystarczy teraz podać hasło. Może się zdarzyć, że serwer jakoś się akurat zamyśli (ponieważ jest już ostro atakowany przez boty, próbujące zalogować się na roota używając prostych haseł – taki urok serwera otwartego na świat), możemy dostać komunikat o przekroczeniu czasu oczekiwania na logowanie. W skrócie: próbujemy do skutku. Najwyżej za trzecim razem się uda.

Po udanym skopiowaniu pliku id_rsa.pub na nasz serwer możemy zalogować się bez hasła:

ssh ip.ip.ip.ip

W kolejnej części zajmiemy się wspomnianymi botami, żeby się za bardzo nie rozgościły. c.d.n…

spec dla jednoplikowego programu

Czasem napiszemy skrypt i chcielibyśmy się nim jakoś podzielić. Nie interesuje nas konto na githubie i nauka gita, po prostu chcemy udostępnić go innym, niekoniecznie z intencją dzielenia się kodem źródłowym. Jednym z możliwych rozwiązań jest spaczkowanie go za pomocą rpm i udostępnienie w swoim własnym repozytorium.

Pierwszym krokiem będzie sprawdzenie, czy nazwa naszego programu nie jest już „zajęta”. Najlepiej sprawdzić to na stronie rpm.pbone.net, starej jak świat wyszukiwarce pakietów. Nie wyobrażacie sobie jak ona kiedyś pomagała przy szukaniu zależności. Jeżeli nazwiemy program locate, to rpm odmówi instalacji pakietu z powodu konfliktu z istniejącymi plikami. Jeżeli nazwiemy program locate_plus (brzmi jak tania wersja ze sklepu Google Play, ale trudno), najprawdopodobniej unikniemy jakichkolwiek konfliktów. Mamy więc nasz rewelacyjny program locate_plus, wyglądający tak:

#!/usr/bin/bash
echo 'All your'
locate base
echo 'are belong to us.'
echo 'hahaha'

Przed pisaniem speca musimy zadbać o kilka rzeczy. Przede wszystkim nasz program powinien znajdować się w katalogu o nazwie locate_plus-0.1, a katalog ten w archiwum o nazwie locate_plus-0.1.tar.gz. Ułatwi to nam dalszą pracę:

$ tar -tf locate_plus-0.1.tar.gz 
locate_plus-0.1/
locate_plus-0.1/locate_plus

Teraz pora przygotować naszą piaskownicę do budowania pakietów. Potrzebujemy kilku pustych katalogów…

ls ~/rpmbuild/
BUILD  BUILDROOT  RPMS  SOURCES  SPECS  SRPMS

… oraz pliku ~/.rpmmacros (przy założeniu, że nasz login to jankowalski):

$ cat ~/.rpmmacros 
%_topdir /home/jankowalski/rpmbuild
%_tmppath /tmp
%packager Jan Kowalski <jankowalski@email.pl>

Teraz kopiujemy archiwum locate_plus-0.1.tar.gz do katalogu SOURCES. W katalogu SPECS zaś tworzymy takiego potworka:

$ cat locate_plus.spec 
Name:		locate_plus
Version:	0.1
Release:	1%{?dist}
Summary:	Base grabber

Group:		Amusements/Games
License:	Public Domain
URL:		http://www.jankowalski.pl/
Source0:	%{name}-%{version}.tar.gz

BuildArch:      noarch
Requires:	bash, locate

%description
locate_plus detects and grab all your base.

%description -l pl
locate_plus namierza i zabiera wszystkie twoja baza.

%prep
%setup -q

%install
rm -rf $RPM_BUILD_ROOT
%__mkdir_p $RPM_BUILD_ROOT%{_bindir}
%__install -m 755 locate_plus $RPM_BUILD_ROOT%{_bindir}

%files
%defattr(-,root,root)
%{_bindir}/locate_plus

%clean
rm -rf $RPM_BUILD_ROOT

%changelog
* Mon Nov 23 2015 Jan Kowalski <jankowalski@email.pl>
- Initial release

Sporo tego, ale postaramy się zaraz wszystko rozjaśnić. Rpmbuild korzysta z pokaźnego zestawu makr, do których odwołujemy się za pomocą %{nazwamakra}. Jest tam prawie wszystko: od nazwy i wersji paczkowanego programu, do definicji ścieżek dla plików binarnych, dokumentacji, itd… Do spaczkowania naszego spryptu nie potrzebujemy ich zbyt wiele.

Po kolei więc:

  • Name, Version, Release i Summary to podstawowe informacje o naszym programie. {?dist} zostanie przez rpmbuild automatycznie zastąpiony skróconą nazwą i wersją naszej dystrybucji, na przykład Fedora 23 to f23, CentOS 7 to c7, itp…
  • Group to grupa, do której należy program. Yum oraz dnf potrafią zrobić z tej informacji dobry użytek, jeżeli ktoś przeszukuje repozytoria w poszukiwaniu gier.
  • URL to twoja strona domowa projektu,
  • Source0 to plik z „kodem źródłowym” naszego programu. Korzystamy tu z makra, które pobiera nazwę i wersję z podanych wyżej danych i mamy z tą linijką spokój do końca świata.
  • Buildarch oznacza architekturę procesora, dla jakiej skompilowany jest program. W przypadku plików tektowych, takich jak skrypty Basha,  podajemy noarch.
  • Requires to zależności pakietu. W naszym wypadku potrzebujemy basha oraz locate.
  • description to krótki opis naszego programu oraz tego, co robi.

I to by był cały opis naszego pakietu. Teraz przechodzimy do sekcji speca, które są odpowiedzialne za umieszczenie odpowiednich plików w odpowiednim miejscu:

  • sekcja %prep odpowiada za rozpakowanie archiwum ze źródłami i przygotowanie zmiennej $RPM_BUILD_ROOT oznaczającej ścieżkę, na której mają pracować kolejne makra. Domyślnie jest to ~/rpmbuild/BUILD/%{name}-%{version} i dlatego właśnie w ten sposób nazwaliśmy katalog w naszym archiwum ze źródlami.
  • sekcja %install to kopiowanie plików. Najpierw kasujemy stare śmieci, które mogły się uchować po poprzednich próbach budowania pakietu. Następnie, korzystając z makra, tworzymy katalog $RPM_BUILD_ROOT/usr/bin i kopiujemy tam plik locate_plus, nadając mu przy okazji uprawienia.
  • w sekcji %files zapisujemy wszystkie pliki, jakie powinny znaleźć się w naszym pakiecie. %defattr określa kto będzie ich właścicielem po instalacji.
  • %clean to sprzątanie śmieci. Źródła w katalogu rpmbuild/BUILD nie są nam już do niczego potrzebne.
  • %changelog to opcjonalny dodatek, ale dobry obyczaj nakazuje go zamieścić. Może w przyszłości twój program będzie paczkował ktoś inny i dopisze się poniżej.

Gotowe? No to przechodzimy do katalogu ~/rpmbuild/SPECS i szykujemy pakiet źródłowy:

rpmbuild -bs locate_plus.spec

Najprawdopodobniej nie zobaczymy żadnych komunikatów o błędach. To po prostu przepakowanie archiwum i dodanie do niego pliku locate_plus.spec. Pozostało tylko jego przebudowanie. Przechodzimy do katalogu ~/rpmbuild/SRPMS i próbujemy:

rpmbuild --rebuild locate_plus-0.1-1.src.rpm

Tym razem rpmbuild bezlitośnie wykaże każdą literówkę w pliku spec. Dobrze dla nas, wiemy od razu co poprawiać. Jeżeli zobaczymy po chwili komunikat exit 0, to gratulacje! Mamy nasz błyszczący pakiet i pora wrzucić go do repozytorium. Ciąg dalszy nastąpi…