Alucard napisał(a):Ja mam jeszcze lepszy sposób na zabezpieczenie się. Zainstalować Linuxa. :P Jeśli chodzi o firewalla pod windę bardzo dobry jest Sygate Professional Firewall. :P
ja zeby uruchomic komputer wsiskam przycisk.
nie wiem jak ty :)
krótka historia samobójcza ;-) Dlaczego? Już widzę te listy pułapki o wadze gatunkowej 2kT oraz powybijane szyby w oknach przez maniaków Slackware, poprzednio przez mnie używanej dystrybucji. No ale nic to. Spróbować można.
Po co?
Po pierwsze aktualizacje. Pracując jako "informatyk" i administrując siedmioma niezależnymi od siebie maszynkami, mając do tego na głowie bycie helpdeskiem, sprzątaczką, monterem, konserwatorem okablowania oraz wiele innych rzeczy któregoś dnia można się złapać na tym, iż mimo dbania o aktualizację nagle znajdujemy jakiś bardzo stary element systemu. Nie musi to być jakaś krytyczna rzecz, wystarczy bzdura, chociażby stary wget, bash, ftp (mam na myśli klienta) i inne nie mające wpływu na bezpieczeństwo pakiety. Dobrze jeżeli to jest faktycznie jakiś program z którego tylko my korzystamy. Gorzej gdy zapomnimy o ssh, o którym ostatnio jest naprawdę głośno. W przypadku PLD aktualizacje są wykonywane przez developerów na bieżąco, przynajmniej jeżeli chodzi o popularne oprogramowanie z którego każdy korzysta (ale o tym później). Tak, wiem, są aktualizacje dla Slackware, są już ulepszone managery pakietów, jest nawet apt-get. W sumie nawet pakietami z PLD można karmić slackware, ale jak długo? :) Poza tym miło jednak korzystać z pakietów wytworzonych dla danej dystrybucji i wersji.
Inną zaletą Slackware jaką kiedyś ceniłem była czystość programów. Praktycznie żaden z nich nie miał łat dystrybucyjnych i był czysty jak łza. Jednak wykonując po raz n-ty kompilacje np. sendmaila aby miał autoryzację, czy też nawet named'a aby miał katalogi tak jak ja chcę staje się też uciążliwe (tak, dupa ze mnie nie admin jeżeli takie bzdury mi przeszkadzają). Podobnie jest w przypadku kernela. W slackware 8.0 był czyściutki 2.2.19, bez żadnych łat. To mi się kiedyś podobało. Później z konieczności zaczełem generować patch z zestawem łat jakich używam na codzień (sterowniki, openwall, parę dodatków, etc). Niby w sumie nic takiego strasznego. Można się do tego przyzwyczaić, pod warunkiem iż maszynki na których kompilujemy dany soft są odpowiednio wydajne. Ja niestety w większości administruje maszynami które dawno miały swoją pierwszą młodość, a to co teraz przeżywają nie można nazwać drugą. Teraz wystarczy że zmieni się coś w sprzęcie - załóżmy wymagającego sterownika/łaty/czegokolwiek. Więc teraz zaczyna się kompilacja kernela, trzeba pojechać na miejsce gdzie maszyna stoii co nie zawsze jest wykonalne, słowem horror. Podobnie przy wymianie kernela na nowszy. Wiadomo, może to być atrakcyjne i ciekawe dla kogoś kto się zajmuje linuksem nie zawodowo. Na początku nawału roboty z aktualizacjami próbowałem budować na szybkiej maszynie np. w domu wszystkie potrzebne programy, lecz tutaj pozostał się problem jakiegoś sensownego paczkowania wyników mojej pracy, a z czasem rozjeżdżanie się składników systemu mojego względem reszty maszyn.
PLD znałem z zachwalań i opowiadań jack'a i agarana. Bardzo zachwalali sobie tą dystrybucję i każdy z nich aktywnie się udzielał przy jej tworzeniu. Moja pierwsza próba instalacji (jeszcze na starym instalatorze) zakończyła się po godzinie dociągania pakietów z sieci, a i tak nie działało :) Później zaczeli mnie namiawiać gdy wyszedł nowy instalator. Udało im się. Na początku fascynacja apt'em, później poldkiem, oraz masą innych rzeczy. W tym momencie PLD używam na 50% maszyn którymi administruje.
RPM jest błe?
Fakt, za czasów pierwszych przygód z RedHatem co się naklełem na rpmy to moje. PLD posiada najlepiej dopracowane RPM'y jakie do tej pory widziałem. I nie mówię tego z przesadą, sam widzę jak developerzy dłubią do upadłego w spec'ach aby RPM był jak najlepszej jakości. Jeżeli natomiast nie lubisz binarnych pakietów, równie dobrze możesz ściągnąć źródłowego rpm'a, poprawić jego zawartość (chociażby wywalić zbędne łatki) i zbudować sam sobie paczkę. A po co paczki? Brak śmietnika w systemie. Dokładnie wiesz co masz zainstalowane - porządek jaki wprowadził u mnie rpm bardzo mi się spodobał. Skończyły się problemy z budowaniem pakietów na różne maszynki. Jeżeli wolę mieć zbudowany pakiet po swojemu, buduje go na szybszej maszynie na potrzebne mi architektury, a dalej już przerzucam gotową paczkę i instaluje. Inna sprawa do instalacja PLD tzw. Mini-ISO albo Base - ta druga to na tyle goły system że ciężko go wogóle używać, natomiast ta pierwsza to minimalny system pozwalający na odpalenie sieci (w tym także modemu albo sdi), poczytanie stron WWW, ściągnięcie czegoś poldkiem. I właśnie to jest dla mnie największy atut PLD - instaluje zestaw Mini-ISO i nie mam praktycznie nic. Po instalacji buduje dopiero docelowy system dokładając kolejne 'klocki' - Apache, MySQL, sendmail, named, etc... W taki sposób w cały system zajmuje poniżej 200MB a jest w pełni funkcjonalny jako serwer - czyli może świadczyć wszystkie najczęściej wymagane usługi, ale np. nie posiada kompilatorów, które akurat tam nie są potrzebne. Jak będę potrzebował sobie coś skompilować to zbuduje to na maszynce do tego przeznaczonej.
A jak to się instaluje?
Generalnie PLD nie ma oficjalnej wersji 1.0. To co jest aktualnie można nazwać snapshotami - obrazy iso płyt instalacyjnych są generowane około raz na miesiąc. Jednak nie wiem czy jest sens ich pobierania. Ja preferuje dwa sposoby instalacji. Pierwszy, to ściągnięcie bootdisk_net.img - obrazu dyskietki bootującej pozwalającej na instalacje przez sieć PLD i tam wybranie zestawu pakietów Mini-ISO. Na łączu 800kbps jakie mam w domu trwa to około 20-30 minut. Drugi, to ściągnięcie samych MiniISO z sieci (około 40MB) i zainstalowanie z nich. W obydwu przypadkach później rozbudowywuje system poldkiem.
Samo PLD jest tworzone na kilka architektur. Niestety iso w chwili obecnej są dostępne tylko dla architekur ia32 (normalnie mówiąc - x86, czyli Intel, AMD, Cyrix i reszta zgodnych). Dodatkowo jest podział na i386, i586 i i686. I tak, obrazy oraz pakiety i686 wymagają minimum procesorów takich jak Celeron, Pentium II, AMD K7 (Athlon, Duron). i586 wymaga minimum Pentium, Cyrix 5x86, AMD K5 (te na socket7) i K6. Pozostałe procesory tj, 386, 486 oraz AMD 5x86 (K5 na socket3) będą bardzo dobrze działać na pakietach i386. Jeżeli nie mamy pewności nadal co do typu architektury jaki powinniśmy zastosować, to radzę wykonać uname -a, albo w instalatorze spróbować zainstalować poprzez sieć, a instalator sam dobierze typ architektury o czym nas poinformuje podczas wyboru serwera ftp.
Koniec rc.inet1
Główną różnicą pomiędzy Slackware a PLD są skrypty startowe. W Slackware są one "BSD-Like", czyli proste skrypty shellowe. W PLD są skrypty SysV których nie modyfikujemy bezpośrednio, a poprzez pliki konfiguracyjne. I tak, instalacja karty sieciowej w PLD polega na dodaniu do /etc/modules.conf alias [urządzenie] [moduł]. Czyli np. jeżeli eth0 to karta sieciowa pracująca jako klasyczne NE2000 PCI (chipset RTL8029) piszemy:
alias eth0 ne2k-pci
Po tym wykonujemy komendę "depmod -ae" i tworzymy w katalogu /etc/sysconfig/interfaces plik ifcfg-eth0 wyglądający mniejwięcej tak:
#
# Urządzenie:
#
DEVICE=eth0
#
# Adres IP:
#
IPADDR=192.168.1.2/24
#
# Czyli 192.168.1.2 przy czym 24 to maska sieciowa 255.255.255.0, a 16 będzie
# oznaczało 255.255.0.0. Jeżeli chcemy mieć więcej adresów IP na tym
# interfejsie piszemy:
#
IPADDR1=192.168.1.3/24
IPADDR2=10.0.7.8/8
#
# Możemy wybrać podstawowy adres IP dla tego urządzenia jeżeli ma być inny niż
# ten w IPADDR:
#
#IP4_PRIM_IF="2" - w taki wypadku 10.0.7.8 będzie podstawowym adresem IP.
#
#
# Czy interfejs ma być aktywowany przy uruchamianiu systemu: yes lub no.
#
ONBOOT=yes
#
# Czy ma być użyte dhcp do uruchomienia tego interfejsu czy też nie
# (none - nie, dhcp - tak)
#
BOOTPROTO=none
Jeżeli posiadamy kilka kart sieciowych, wystarczy kolejny wpis do modules.conf, np. alias eth1 3c59x oraz plik ifcfg-eth1. Po tych wszystkich zmianach piszemy /etc/rc.d/init.d/network restart i nowe ustawienia sieci są zrobione.
Koniec z killall -9 sendmail && sendmail -bd -q5m (czyli koniec z rc.inet2)
W PLD jak już napisałem panuje SysV, którego kolejnym 'feature' jest przydzielenie skryptu startowaego dla każdego demona oddzielnie. Teraz zamiast killall -9 sendmail && sendmail -bd -q5m piszemy:
/etc/rc.d/init.d/sendmail restart
Standardowo mamy start, stop i restart. Sporo demonów używa także innych funkcji takich jak 'reload' czy 'init'. Zależne są one od demona, a ich listę można wyświetlić uruchamiając skrypt bez żadnych parametrów.
Całość pozwala zarządzać także kolejnością uruchamiania poszczególnych usług w systemie, ale o tym napiszę za jakiś czas. Generalnie aby wybierać które usługi są uruchamiane w danym runlevelu służy program chkconfig:
root@aurora:~# chkconfig --list
lstatd 0:--- 1:--- 2:*** 3:*** 4:*** 5:*** 6:---
saslauthd 0:--- 1:--- 2:*** 3:*** 4:*** 5:*** 6:---
squid 0:--- 1:--- 2:--- 3:--- 4:--- 5:--- 6:---
syslog-ng 0:--- 1:--- 2:*** 3:*** 4:*** 5:*** 6:---
ircd 0:--- 1:--- 2:*** 3:*** 4:*** 5:--- 6:---
Oczywiście to tylko fragment wyniku tej komendy. Na początku widzimy nazwę demona, a później kolejne runlevele. '---' oznacza iż w danym runlevelu dana usługa jest zatrzymywana (o ile oczywiście chodzi - np. przejście z runlevelu 3 na 5 nie spowoduje próby zatrzymania u mnie squida bo on już nie chodził). '***' oznacza uruchomienie danej usługi (o ile nie chodzi jeszcze oczywiście).
Polecenie chkconfig --add [usługa] służy do dodania danej usługi w standardowych runlevelach (3, 4 i 5), natomiast chkconfig --del [usługa] powoduje usunięcie danej usługi we wszystkich levelach i z katalogów konfiguracyjnych chkconfa:
root@aurora:~# chkconfig --list squid
squid 0:--- 1:--- 2:--- 3:--- 4:--- 5:--- 6:---
root@aurora:~# chkconfig --add squid
root@aurora:~# chkconfig --list squid
squid 0:--- 1:--- 2:--- 3:*** 4:*** 5:*** 6:---
root@aurora:~# chkconfig --del squid
root@aurora:~# chkconfig --list squid
squid 0:--- 1:--- 2:--- 3:--- 4:--- 5:--- 6:---
Działa to mniej więcej na takiej zasadzie, że jeżeli usuniemy (--del) jakąś usługę, to wtedy zmiana runlevelu nie spowoduje sprawdzenia czy dana usługa jest uruchomiona. Aby dokładniej zarządzać runlevelami możemy także wybierać które usługi są uruchomiane w którym runlevelu poprzez chkconfig [--level poziomy] [usługa] <on|off|reset> - gdzie on to oczywiście włączenie, off wyłączenie a reset przywrócenie do normalnego stanu (0,1,2,6 - off, 3,4,5 - on):
root@aurora:~# chkconfig --list squid
squid 0:--- 1:--- 2:--- 3:*** 4:*** 5:*** 6:---
root@aurora:~# chkconfig --level 2 squid on
root@aurora:~# chkconfig --list squid
squid 0:--- 1:--- 2:*** 3:*** 4:*** 5:*** 6:---
root@aurora:~# chkconfig squid reset
root@aurora:~# chkconfig --list squid
squid 0:--- 1:--- 2:--- 3:*** 4:*** 5:*** 6:---
root@aurora:~# chkconfig squid off
root@aurora:~# chkconfig --list squid
squid 0:--- 1:--- 2:--- 3:--- 4:--- 5:--- 6:---
Uf, mam nadzieje że nie zamotałem za bardzo a aurora przeżyje następny reboot ;)
No i co z tymi pakietami?!?
PLD'owego poldka zaczeli już nawet na zachodzie chwalić. Jest to bardzo słodki manager pakietów. Jeżeli mamy świeżo zainstalowany system wystarczy że uaktualnimy bazę pakietów:
root@aurora:~# poldek --up
Pobieranie ftp://ftp.pld-linux.org/dists/ra/PLD/i6 ... .dir.mdd...
Pobieranie ftp://ftp.pld-linux.org/dists/ra/PLD/i6 ... s.dir.gz...
.................................................. 100.0% [3.6M]
Weryfikacja ftp://ftp.pld-linux.org/dists/ra/PLD/i6 ... s.dir.gz... OK
3.6M to sporo? Prawda. Ale za następnym razem poldek ściągnie to co będzie potrzebował:
root@aurora:~# poldek --up
Pobieranie ftp://ftp.pld-linux.org/dists/ra/PLD/i5 ... .dir.mdd...
Pobieranie ftp://ftp.pld-linux.org/dists/[...]/packages.dir.diff.toc.gz...
.................................................. 100.0% [2.5K]
Pobieranie ftp://[...]/packages.dir.diff.2002.06.29-11.32.30.mdd...
Pobieranie ftp://[...]/packages.dir.diff.2002.06.29-11.32.30.gz...
.................................................. 100.0% [46.5K]
Weryfikacja ftp://[...]/packages.dir.diff.2002.06.29-11.32.30.gz... OK
Wczytywanie ftp://ftp.pld-linux.org/dists/ra/PLD/i5 ... s.dir.gz...
Nakładanie łaty packages.dir.diff.2002.06.29-11.32.30.gz...
Zapisywanie /var/cache/poldek/[...]/packages.dir.gz...
Zapisywanie sumy kontrolnej /var/cache/poldek/[...]/packages.dir.mdd...
Poldek ma dwa tryby pracy. Interaktwny w którym mamy linię poleceń poldka i z linii polceń. Opiszę ten interaktywny który jest wg. mnie o wiele przyjemniejszy:
root@aurora:~# poldek
Wczytywanie ftp://ftp.pld-linux.org/dists/ra/PLD/i6 ... s.dir.gz...
Przeczytano 4212 pakietów
Wczytywanie /var/cache/poldek-cache/packages.dir.dbcache.var.lib.rpm.gz...
Przeczytano 300 pakietów
Witaj w poldekowym trybie interaktywnym. Wpisz "help" aby otrzymać pomoc.
poldek>
Załóżmy, chcemy zainstalować sobie midnight commandera:
poldek> install mc
Przetwarzanie zależności...
Zaznaczono 1 pakiet do instalacji:
I mc-4.5.55-8
Pobieranie ftp://ftp.pld-linux.org/dists/ra/[...]/mc-4.5.55-8.i686.rpm...
.................................................. 100.0% [1.3M]
Uruchamianie rpm --upgrade -vh --root / --noorder...
Preparing... ########################################### [100%]
1:mc ########################################### [100%]
poldek>
Fajne co nie? :) Oczywiście czasami jakiś pakiet wymaga innego pakietu i zaczynają się makabryczne zależności w rpmach. Ale nie w poldku:
poldek> install sendmail
Przetwarzanie zależności...
sendmail-8.12.5-1 zaznaczył m4-1.4n-4 (wł. m4)
sendmail-8.12.5-1 zaznaczył procmail-3.22-2 (wł. procmail)
procmail-3.22-2 zaznaczył libnet-1.0.2a-5 (wł. libnet)
Zaznaczono 4 pakiety do instalacji (3 zaznaczone pośrednio):
I sendmail-8.12.5-1
D libnet-1.0.2a-5, m4-1.4n-4, procmail-3.22-2
Pobieranie http://ftp.pld-linux.org/[...]/sendmail-8.12.5-1.i686.rpm...
.................................................. 100.0% [770.9K]
Pobieranie http://ftp.pld-linux.org/dists/[...]/procmail-3.22-2.i686.rpm...
.................................................. 100.0% [228.9K]
Pobieranie http://ftp.pld-linux.org/dists/[...]/libnet-1.0.2a-5.i686.rpm...
.................................................. 100.0% [21.9K]
Pobieranie http://ftp.pld-linux.org/dists/ra/PLD/i ... i686.rpm...
.................................................. 100.0% [123.3K]
Uruchamianie rpm --upgrade -vh --root / --noorder...
Preparing... ########################################### [100%]
1:m4 ########################################### [ 25%]
2:libnet ########################################### [ 50%]
3:procmail ########################################### [ 75%]
4:sendmail ########################################### [100%]
Run "/etc/rc.d/init.d/sendmail start" to start sendmail daemon.
poldek>
No tak, ktoś krzyknie "ale do tego potrzebny jest dostęp do internetu a ja mam modem, a peelde mam na cdromie". Ja nie widzę problemów - w /etc/poldek.conf wpisujemy:
source = ra /mnt/cdrom/PLD/RPMS/
Zamiast source z ftp, wkładamy cdrom, montujemy && voila. Dobrze, to potrafimy już instalować. Teraz deinstalacja:
poldek> uninstall sendmail
Zaznaczono 1 pakiet do usunięcia:
R sendmail-8.12.5-1
Kontynuować? [y/N]
Uruchamianie rpm --erase --root /...
Zatrzymywanie uslugi sendmail......................................[ ZROBIONE ]
poldek>
Proste? No ja myślę :) A zależności przy deinstalacji? Też są przewidziane:
poldek> uninstall procmail
procmail-3.22-2 marks sendmail-8.12.5-1
Zaznaczono 2 pakiety do usunięcia (1 zaznaczony pośrednio):
R procmail-3.22-2
D sendmail-8.12.5-1
Kontynuować? [y/N]
Uruchamianie rpm --erase --root /...
poldek>
Taka mała uwaga, w pierwszym przykładzie dla tego został zatrzymany sendmail przed deinstalacją gdyż był wcześniej uruchomiony. Za drugim razem nie był więc poldek (a właściwie rpm) nie miał czego zatrzymywać.
Następna komenda dosyć przydatna administrtorowi to 'ls'. Powoduje ona domyślnie wyświetlenie pakietów z bazy pakietów, czyli tych które możemy zainstalować. Wykonanie jej spowoduje wyświetlenie listy ponad 4000 paczek dostępnych dla PLD. List na szczęście nie będzie nam latać przed nosem jak szalona a pozwoli nam na jej przwijanie strzałkami kursora i klawiszami PgUp i PgDown (tak jak less) lub jej przewijanie w dół o całą stronę spacją albo po linijce enterem (jak more). Wyjście z listy następuje albo po naciśnięciu klawisza 'q' albo po dojściu do końca listy. ls ma wiele opcji. Na przykład 'ls -u' spowoduje wyświetlenie pakietów które można zaktualizować. 'ls -I' spowoduje wyświetlenie tylko pakietów które już mamy zainstalowane. Dodanie parametru -l wzbogaci wyświetlane listy o daty zbudowania pakietów oraz ich rozmiary. Opcja -O dodaje krótkie opisy pakietów. Oczywiście można stosować maski do wyświetlania, np:
poldek> ls -l *ssh*
pakiet data zbudowania rozmiar
kdeutils-kdessh-2.2.2-6 2002/04/14 21:20 29.0k
openssh-3.2.3p1-3 2002/06/28 18:21 254.0k
openssh-clients-3.2.3p1-3 2002/06/28 18:21 442.0k
openssh-gnome-askpass-3.2.3p1-3 2002/06/28 18:21 7.0k
openssh-server-3.2.3p1-3 2002/06/28 18:21 402.0k
openssh-x11-askpass-1.2.4.1-1 2002/05/25 19:05 30.0k
6 pakietów, 1 MB
Przedtem pisałem iż wystarczy 'install nazwapakietu'. Poprostu poldek dokleji sobie sam wersję do nazwy pakietu. Poza tym liniia poleceń obsługuje klawisz TAB, czyli tak przez wszystkich kochane dopełnianie znane z basha, ekg czy też klientów do irca. Samo uaktualnianie pakietów jest bardzo proste. Służy do tego komenda 'install -F' lub 'upgrade':
poldek> ls -u -l
dostępny zainstalowany data zbudowania rozmiar
freetype-2.1.2-1 2.1.1-1 2002/06/29 20:48 332.0k
openssh-3.2.3p1-3 3.4p1-1 2002/06/28 18:20 255.0k
openssh-clients-3.2.3p1-3 3.4p1-1 2002/06/28 18:20 443.0k
openssh-server-3.2.3p1-3 3.4p1-1 2002/06/28 18:20 403.0k
rpm-4.0.2-78 4.0.2-77 2002/06/29 21:03 2.9m
setserial-2.17-9 2.17-7 2002/06/29 14:02 30.0k
6 pakietów, 4 MB
poldek> install -F rpm-4.0.2-78
Przetwarzanie zależności...
rpm-4.0.2-77 zostanie zastąpiony przez rpm-4.0.2-78
Zaznaczono 1 pakiet do instalacji, 1 do usunięcia:
I rpm-4.0.2-78
R rpm-4.0.2-77
Pobieranie ftp://ftp.pld-linux.org/dists/ra/[...]/rpm-4.0.2-78.i586.rpm...
.................................................. 100.0% [1.3M]
Uruchamianie /bin/rpm --upgrade -vh --root / --noorder...
Preparing... ########################################### [100%]
1:rpm ########################################### [100%]
poldek> upgrade setserial
Przetwarzanie zależności...
setserial-2.17-7 zostanie zastąpiony przez setserial-2.17-9
Zaznaczono 1 pakiet do instalacji, 1 do usunięcia:
I setserial-2.17-9
R setserial-2.17-7
Pobieranie ftp://ftp.pld-linux.org/dists/[...]/setserial-2.17-9.i586.rpm...
.................................................. 100.0% [30.5K]
Uruchamianie /bin/rpm --upgrade -vh --root / --noorder...
Preparing... ########################################### [100%]
1:setserial ########################################### [100%]
Tutaj też można stosować gwiazdki jak i w przypadku ls:
poldek> ls -u
freetype-2.1.2-1
openssh-3.2.3p1-3
openssh-clients-3.2.3p1-3
openssh-server-3.2.3p1-3
poldek> upgrade *ssh*
Przetwarzanie zależności...
openssh-server-3.4p1-1 zostanie zastąpiony przez openssh-server-3.2.3p1-3
openssh-clients-3.4p1-1 zostanie zastąpiony przez openssh-clients-3.2.3p1-3
openssh-3.4p1-1 zostanie zastąpiony przez openssh-3.2.3p1-3
Zaznaczono 3 pakiety do instalacji, 3 do usunięcia:
I openssh-3.2.3p1-3, openssh-clients-3.2.3p1-3, openssh-server-3.2.3p1-3
R openssh-3.4p1-1, openssh-clients-3.4p1-1, openssh-server-3.4p1-1
Pobieranie ftp://[...]/openssh-server-3.2.3p1-3.i586.rpm...
.................................................. 100.0% [171.9K]
Pobieranie ftp://[...]/openssh-clients-3.2.3p1-3.i586.rpm...
.................................................. 100.0% [199.5K]
Pobieranie ftp://ftp.pld-linux.org/dists/[...]/openssh-3.2.3p1-3.i586.rpm...
.................................................. 100.0% [140.1K]
Uruchamianie /bin/rpm --upgrade -vh --root / --noorder...
Preparing... ########################################### [100%]
1:openssh ########################################### [ 33%]
2:openssh-clients ########################################### [ 66%]
3:openssh-server ########################################### [100%]
Zatrzymywanie uslugi OpenSSH.......................................[ ZROBIONE ]
Uruchamianie uslugi OpenSSH........................................[ ZROBIONE ]
poldek>
Na koniec zanim wygonie was do wbudowanej w poldka komendy help napiszę tylko o parametrach z linii poleceń:
poldek -i [pakiet] - to samo co install pakiet.
poldek -e [pakiet] - deinstalacja pakietu (deinstall pakiet).
poldek -u [pakiet] - aktualizacja pakietu (upgrade pakiet).
poldek --upgrade-dist - to samo co upgrade * ;-).
A ja chce sam kompilować!
W sumie to nikt Ci tego nie zabrania, tylko nie zapomnij o instalacji kompilatorów i bibliotek ;). A tak na poważnie, jeżeli nie ufasz naszym binarkom zapraszamy do kompilacji ze źródeł na dwa sposoby.
Pierwszy to .src.rpm. Pod adresem ftp://ftp.pld-linux.org/pool/ znajdują się posortowane alfabetycznie pakiety. Np. epic znajduje się w katalogu ftp://ftp.pld-linux.org/pool/e/epic4/. Poza pakietami binarnymi znajduje się tam także plik .src.rpm. Ściągamy go, instalujemy i budujemy:
wget ftp://ftp.pld-linux.org/pool/e/epic4/ep ... -5.src.rpm
mkdir -p ~/rpm/{SPECS,SOURCES,BUILD,RPMS,SRPMS}
rpm -ivh epic4-1.0.1-5.src.rpm
cd ~/rpm/SPECS
rpm -ba epic4.spec
Jeżeli mieliśmy wszystkie potrzebne kompilatory to po paru minutach powinniśmy mieć w katalogu ~/rpm/RPMS/ pakiety binarne dla naszej architektury. Aby zbudować dla innej (np. mamy i686 a chcemy dla i586) dodajemy --target=i586.
Drugą metodą jest ściągnięcie wszystkich potrzebnych materiałów do zbudowania paczki z CVS...
CVS - mieć wszystko najświeższe
Repozytorium CVS w PLD służy do pracy nad pakietami. W większości wypadków materiały tam zawarte to wersje testowe nad którymi właśnie ktoś pracuje, więc istnieje bardzo duże prawdopodobieństwo iż kompilacja się nie powiedzie albo dany pakiet nie będzie spełniał waszych oczekiwań. Często także na skargę "coś mi nie działa" któryś z developerów może wam odpowiedzieć "ściągnij z cvs'a najnowszą wersję". Oczywiście jest możliwość ściągnięcia stabilnej wersji także z CVS ale nie widzę takiej potrzeby skoro jest to już w katalogu pool na ftp.
Na początek trzeba określić adres repozytorium:
export CVSROOT=":pserver:cvs@cvs.pld-linux.org:/cvsroot"
Później tworzymy odpowiednie katalogi dla rpm'a w których będziemy pracować:
mkdir -p ~/rpm/{SPECS,SOURCES,RPMS,SRPMS,BUILD}
lub:
rpm --install-build-tree
Teraz trzeba przygotować lokalne repozytorium. Nie wnikajcie co to jest, poprostu wykonajcie następujące czynnośći ;-):
lukasz@serv:~$ cd rpm/
lukasz@serv:~/rpm$ cvs get SPECS/builder SOURCES/kernel-i386.config
U SPECS/builder
U SOURCES/kernel-i386.config
Builder jest skryptem wspomagającym budowanie pakietów oraz ściąganie źródeł. Getsrc to skrypt pozwalający na ściągnięcie wszystkich źródeł potrzebnych przez danego specfile'a. Natomiast kernel-i386.config zaciągneliśmy po to, by w katalogu SOURCES cvs utworzył wszystkie potrzebne sobie pliki. Załóżmy że chcemy sobie zbudować teraz pakiet z ekg - klientem gadu-gadu pod konsolę:
lukasz@serv:~/rpm$ cvs get SPECS/ekg.spec
U SPECS/ekg.spec
lukasz@serv:~/rpm$ cd SPECS/
lukasz@serv:~/rpm/SPECS$ ./builder ekg.spec
U ekg.spec
# $Revision: 1.4 $, $Date: 2003/06/22 19:59:27 $
U ekg-20020629.tar.gz
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.32838
... tutaj następuje faza budowania pakietu ...
Zapisano: /home/users/lukasz/rpm/SRPMS/ekg-20020629-1.src.rpm
Zapisano: /home/users/lukasz/rpm/RPMS/ekg-20020629-1.i586.rpm
Zapisano: /home/users/lukasz/rpm/RPMS/libgadu-20020629-1.i586.rpm
Zapisano: /home/users/lukasz/rpm/RPMS/libgadu-devel-20020629-1.i586.rpm
Zapisano: /home/users/lukasz/rpm/RPMS/libgadu-static-20020629-1.i586.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.10772
+ umask 022
+ cd /home/users/lukasz/rpm/BUILD
+ _autoreqprov=n
+ [ n = y ]
+ cd ekg-20020629
+ rm -rf /tmp/ekg-20020629-root-lukasz
+ exit 0
... and voila
Użytkownicy przeglądający ten dział: Brak zidentyfikowanych użytkowników i 13 gości