Warsztaty są darmowe. Odbędą się w Rozbracie na ulicy Pułaskiego 21 a:

View Larger Map

Spotkanie zostało podzielone na dwie części. Wpierw, o godzinie siedemnastej, nastąpi projekcja filmu “Hackers are people too”, nakręcony przez hakerów i mający w założeniu łamać stereotyp hakera – komputerowego przestępcy. Godzinę później, o osiemnastej, rozpoczną się warsztaty, podczas których uczestnicy nauczą się instalować Fedorę 12, dowiedzą się o najczęściej używanych programach, o prawach do plików i katalogów, o pracy w sieci (OpenVPN, tor, ssh). Podczas warsztatów omówiona zostanie także podstawowa struktura katalogów Linuksa oraz instalacja programów ze źródeł. Zalecane jest przyniesienie własnego laptopa – są to warsztaty typu BYOL (Bring Your Own Laptop).

Więcej informacji można uzyskać na stronie unixy.pl.

Konfiguracja podstatowych repozytorium z pakietami, które są instalowane wraz z systemem oraz dodatkowych które można dodać w zalezności od własnego upodobania. Dodatkowymi repozytorium są Rpmfusion, Adobe, PlayOnLinux, Compiz Fusion.

Podstawowa konfiguracja

Podstawowa konfiguracja repozytorium z oprogramowaniem to fedora, fedora-updates, fedora-updates-testing, fedora-rawhide. Poniżej opis repozytorium.

• fedora – tutaj są wszystkie główne pakiety, bez poprawek. Domyślnie włączone.
• fedora-updates – to repo zawiera wszelkie uaktualnienia, które się ukazują. Domyślnie włączone.
• fedora-updates-testing – to repo zawiera uaktualnienia, które są testowane (jak nazwa wskazuje). Domyślnie wyłączone ponieważ pakiety testowane mogą wpłynąć na stabilność systemu. Jeśli jednak posiadasz włączone warto zainteresować się https://admin.fedoraproject.org/updates/, miejscem gdzie możesz dać znać czy poprawka rozwiązuje zgłoszone problemy.
• fedora-rawhide – repozytorium zawierające pakiety wchodzące w skład nowszej, rozwijanej wersji Fedory (w tej chwili jest to F13). Wyłączone domyślnie z powodu tego, że nie osiąga nigdy statusu wersji stabilnej. W momencie osiągniecia pojawia sie kolejne wydanie a rawhide staje się nowym wydaniem.

Repozytorium można włączać poprzez edycję plików z katalogu /etc/yum.repos.d/. Pokażę na przykładzie fedora-updates-tesing.repo

1. sudo nano /etc/yum.repos.d/fedora-updates-testing.repo
2. Linijkę enabled=0 należy zamienić na enabled=1.

Jeśli używasz yumex`a to należy przejść od opcji Repository Selection View (taka kula ziemska lub planeta) i zaznaczyć te które są interesujące, następnie Profiles i Save. Ostatnia rzecz to Refresh i dostaniemy listę dostępnych poprawek.

Dodatkowe repozytorium

RPMFusion

Instalacja graficzna wyglada następująco. Wybierz i kliknij link do twojej dystrybucji Fedora 10, 11 i 12; Fedora Alpha, Beta, Rawhide, RC, Snapshot lub Preview; RHEL5 lub inna kompatybilna z CentOS. Potem należy zainstalować używając domyslnego wyboru Fedory (zostanie odpalony PackageKit) lub zapisać a potem zainstalować (sudo rpm -ihv nazwa_paczki). W ten sposób instalujemy wersję free, do repozytorum nonfree służą te linki: Fedora 10, 11 i 12; Fedora Alpha, Beta, Rawhide, RC, Snapshot lub Preview; RHEL5 lub inna kompatybilna z CentOS.

Instalacja tesktowa wygląda w taki sposób.

• Fedora 10, 11 i 12
  su -c 'rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-stable.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-stable.noarch.rpm'
• Fedora Alpha, Beta, Rawhide, RC, Snapshot lub Preview
  su -c 'rpm -Uvh http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-rawhide.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-rawhide.noarch.rpm'
• RHEL5 lub inna kompatybilna z CentOS
  su -c 'rpm -Uvh http://download1.rpmfusion.org/free/el/updates/testing/5/i386/rpmfusion-free-release-5-0.1.noarch.rpm http://download1.rpmfusion.org/nonfree/el/updates/testing/5/i386/rpmfusion-nonfree-release-5-0.1.noarch.rpm'

Adobe

Repo zawiera paczki z flashem, jeśli nie chcesz używać gnash`a (wolna wersja flasha), zainstaluj to repo. Instalacja graficzna polega na kliknięciu linka do paczki i pozwolenie na instalację za pomocą PackageKit.

Instalacja tekstowa
sudo rpm -ivh http://linuxdownload.adobe.com/adobe-release/adobe-release-i386-1.0-1.noarch.rpm

PlayOnLinux

PlayOnLinux to projekt wspomagający isntalację gier i programów na wine. Posiada sporą bazę skryptów konfigurujących wine pod odpowiednie tytuły. Instalacja graficzna to po prostu kliknięcie i zainstalowanie tego pakietu.

Instalacja tekstowa

sudo rpm -ihv http://mulx.playonlinux.com/rpm/playonlinux-yum-3-3.noarch.rpm

Compiz Fusion

Wszyscy wiedzą co to jest Compiz Fusion a jeśli nie to zapraszam do przeczytania krótkiej notki w Wikipedii. To repozytorium zawiera paczki compiz-fusion dla F9, F10, F11 i F12. Instalacja graficzna polega na kliknięciu w ten link i zainstalowaniu pakietu.

Instalacja tekstowa

sudo rpm -ivh http://leigh123linux.fedorapeople.org/compiz-fusion-release-1-8.noarch.rpm

Od zamierzchłych czasów dostępne były dwie wersje: stabilna i rozwojowa, zwana rawhide.
Parcie do przodu wersji deweloperskiej co pół roku było zwalniane, aby po serii zamrożeń wydać ją jako nową stabilną. Powodowało to nieprzyjemne efekty: z jednej strony zablokowanie rozwoju na miesiąc przed wydaniem kolejnej wersji stabilnej. Z drugiej — olbrzymią destabilizację tuż po wydaniu, kiedy programiści nadrabiali zaległości i wszyscy wrzucali nowości do repozytorium rawhide.

Teraz, zgodnie z propozycją No Frozen Rawhide, nastąpił podział. Na trzy:
- rawhide – wersja czysto rozwojowa. Nie będzie zamrażana, zmiany dokonywane będą bez hamulców. W tej chwili zawartość odpowiada Fedorze 14.
- branched – linia testowa. Wydzielana z rawhide na kilka miesięcy przed wydaniem kolejnej wersji stabilnej. Zmiany tutaj ograniczone będą do poprawek błędów i stabilizacji, nie jest to miejsce na rewolucje. W maju zostanie udostępniona jako Fedora 13.
- wersja stabilna, czyli aktualne wydanie. Fedora w wersji 12.

Wprawni czytelnicy dostrzegają pewnie analogię z Debianowymi repozytoriami niestabilnymi, testowymi i stabilnymi. Jak widać ten model sprawdza się. Nb. również jądro Linuksa rozwija się trzytorowo: przyszłościowe zmiany w -next, najbliższe wydanie dojrzewa w -linus, a linia stabilna to wydania oznaczone czterema cyframi.

Pozostaje tylko mieć nadzieję, że deweloperzy mając ciągle otwartą piaskownicę rawhide nie zapomną o stabilizowaniu i przygotowywaniu do wydania branched.

A co w samej Fedorze 13? Lista nowości znajduje się na stronie projektu, warte wzmianki są: kolejny etap pracy nad obsługą tzw. kamerek internetowych, uniwersalny instalator sieciowy (BFO), Moblin 2.2 i garść nowości w dziedzinie wirtualizacji. Domyślną stała się wersja czwarta NFS, zapewniono działanie tego protokołu po IPv6. Pojawiła się także obsługa DisplayPort i eksperymentalne wsparcie 3D w sterowniku do kart graficznych NVIDIA.

Wydanie wersji Alpha planowane jest na początek marca.

Ostatnimi czasy moją głowę zaprzątał problem stworzenia paczki rpm dla mojego programu SynapticsConfig. Długo walczyłem z jednego powodu, chciałem użyć distutils a nie ręcznie tworzyć plik spec. Poniżej przytoczę problemy z którymi się borykałem oraz rozwiązania tych problemów. Wg. mnie dokumentacja distutils i pythona dotycząca zagadnień które poruszam jest dosyć skromna i wszelkie próby znalezienia rozwiązania dawały mierne wyniki. Całe szczęście mamy listy dyskusyjne oraz od źródłowy (fuck you propietary software!).

1. Dołączanie %changelog

Część pliku spec odpowiedzialna za changelog jest wymagana, tak przynajmniej uważa rpmlint oraz tak stoi w dokumentacji Fedory. W dokumentacji distutils nie ma zbyt wielu informacji na ten temat. Jednak naprowadziła mnie ona na proste rozwiązanie a mianowicie

python setup.py bdist_rpm --help

Komenda wyświetla dokładnie to czego potrzeba czyli

--changelog          RPM changelog

To mogłoby załatwić sprawę gdyby nie brak informacji w jakiej postaci ma być changelog. Wszystko wskazuje, że to powinien być plik jednak domyślne formatowanie nie spełniało wymagań i ładnie wypluwało komunikat, że wiersz musi zaczynać się od “*”. Postanowiłem zerknąć do pliku odpowiedzialnego za generowanie paczek rpm /usr/lib64/python2.6/distutils/command/bdist_rpm.py. Na początku pliku wśród listy opcji pojawia się taki tekst

# More meta-data: too RPM-specific to put in the setup script,
# but needs to go in the .spec file — so we make these options
# to “bdist_rpm”.  The idea is that packagers would put this
# info in setup.cfg, although they are of course free to
# supply it on the command line.

No ładnie ale ja z lini poleceń nie mogłem dołączyć changelog więc z pomocą przyszedł plik setup.cfg. Do pustego pliku dodałem linijkę

[bdist_rpm]
changelog = #tutaj tekst changelog oczywiście zaczynający się od *

Należy pamiętać o gwiazdce ropoczynającej każdą wersję oraz o poprawnym formacie daty. Rpm jest bardzo wymagający w tym temacie. Tak przygotowany changelog powinen przejść proces budowania paczki.

2. Dodawanie %post_install i %post_uninstall

Kolejne rzeczy, które musiałem skonfigurować to sekcje kodu uruchamiane po zainstalowaniu paczki i jej odinstalowaniu. Wspomniany wcześniej bdist_rpm –help tak opisuje to

–post-install       Specify a script for the post-INSTALL phase of RPM

building

–post-uninstall     Specify a script for the post-UNINSTALL phase of RPM

building

W tym wypadku jednak nie używałem linii poleceń ani pliku setup.cfg. Te dwie opcje pozwoliły sie zgrabnie dołączyć do pliku setup.py jako argument funkcji setup

options={'bdist_rpm' : {'post_install'  : 'ścieżka_do_pliku', 'post_uninstall'  : 'ścieżka_do_pliku'}}

Bardzo możliwe, że zamiast podawania ścieżek do istniejących plików można wsadzić komendy. W wypadku skryptów mających parę linijek może pojawić się problem, ale nie testowałem.

To wydarzenie jest bardzo ciekawe w kontekście zaufania osoby sporządzającej paczkę do źródła z którego pobiera kod. Bez wątpienia może podkopać zaufanie do “bezpiecznego łańcucha” – “jeśli oprogramowanie jest wzięte z dystrybucji, to na pewno nie ma wbudowanego żadnego złośliwego kodu”, “kod open source jest sprawdzany przez tysiące ludzi”.

Możliwe są trzy scenariusze zakończenia audytu:
- zakończenie pozytywne 1 – złośliwy kod zostanie namierzony i usunięty
- zakończenie pozytywne 2 – złośliwy kod nie zostanie namierzony, bo nie został dodany do oprogramowania wymienionego na liście Setha
- zakończenie negatywne – złośliwy kod nie zostanie namierzony

Przypadek berlios jest również ciekawy w kontekście masowego wykorzystywania takich dużych repozytoriów przez deweloperów open source. Jest to bardzo atrakcyjny cel ataku dla włamywacza, ponieważ po udanym włamaniu jego “skala rażenia” może być bardzo duża.

Jak myślicie, co włamywacz zmajstrował na berlios, gdy przez 5 lat miał do niego dostęp?