baseciq.org » pld http://www.baseciq.org Just another WordPress weblog Sat, 17 Jul 2010 20:43:55 +0000 en hourly 1 http://wordpress.org/?v=3.0 Konfiguracja Exima http://www.baseciq.org/2006/04/26/konfiguracja-exima http://www.baseciq.org/2006/04/26/konfiguracja-exima#comments Wed, 26 Apr 2006 10:00:02 +0000 Baseciq http://www.baseciq.org/?p=119 Szef kuchni poleca ;)

Domeny lokalne
Zapasowy MX
Relaying
Budowa pliku konfiguracyjnego
Hostname, banner i inne bajery
Aliasy

Autoryzacja
Autoryzacja tylko dla SSL
Exim i SSL
Exim i SSL na porcie 465
Quota i okolice
Manualroute czyli przekazywanie poczty do konkretnego MX’a

Tak więc skompilowaliśmy i zainstalowaliśmy Exim’a. Teraz należy go jakoś skonfigurować.

Domeny lokalne

Domeny lokalne, to takie które Exim ma traktować jako ‘swoje’ domeny. Mail zadresowany @jakas.domena.lokalna który dotrze do Exim’a zostanie dostarczony lokalnie. Domeny takie definuje w dyrektywie ‘domainlist local_domains’. Standardowo, przyjmowana jest poczta wysyłana do domeny identycznej jak hostname serwera:

domainlist local_domains = @

Znak ‘@’ oznacza właśnie ‘moja nazwa’. Aby dopisać kolejne domeny wystarczy dodać je do tej listy rodzielając je dwukropkami:

domainlist local_domains = @ : domena.pl : baseciq.org

Oczywiście cały czas mówię o zmianach w pliku konfiguracyjnym Exim’a (czyli jeżeli kompilowaliście go wg. mojego opisu albo macie Exim4 z PLD – /etc/mail/exim.conf). Oczywiście nie muszę mówić, iż każda zmiana w pliku konfiguracyjnym wymaga restartu Exim’a. Można także to zrobić w inny sposób:

domainlist local_domains = @ : domena.pl : baseciq.org : /etc/mail/local_domains

Poza domena.pl, baseciq.org, Exim będzie teraz także akceptował domeny wypisane w pliku /etc/mail/local_domains. Domeny tam należy wpisywać w oddzielnych linijkach. Exim o tyle fajnie działa, że po dopisaniu ścieżki do pliku, wystarczy go raz zrestartować. Jakiekolwiek kombinacje w /etc/mail/local_domains nie będą wymagały restartu. Tak więc najwygodniej będzie dopisać do pliku konfiguracyjnego:

domainlist local_domains = @ : /etc/mail/local_domains

I poprostu powpisywać wszystkie domeny do /etc/mail/local_domains.

Domeny dla których mamy być zapasowym MX’em

Jest to wbrew pozorm łatwe. Linijkę pod ‘domainlist local_domains’ jest ‘domainlist relay_to_domains’. Działa to w taki sam sposób jak konfiguracja domen lokalnych, czyli, piszemy:

domainlist relay_to_domains = /etc/mail/relay_to_domains

Od teraz, Exim będzie akceptował każdą pocztę zaadresowaną do domen zawartych w pliku ‘/etc/mail/relay_to_domains’. A co z nią zrobi? Jak wiadomo, jeżeli domena ma kilka MX’ów, to Exim będzie starał się ją dostarczyć do serwera o najniższym priorytecie MX. Chyba że on ma najniższy, to wygeneruje błąd.

Relaying

Czyli określenie kto może przez nasz serwer wysyłać pocztę. I tutaj, listę adresów i hostów buduje się w podobny sposób do local_domains i relay_to_domains. Wystarczy stworzyć listę o nazwie ‘relay_from_hosts’:

hostlist   relay_from_hosts = 127.0.0.1 : 192.168.0.0/16

Budowa pliku konfiguracyjnego

Na chwilę przystopujmy. Plik konfiguracyjny Exim’a wygląda mniej więcej tak:

# głowna sekcja ...

opcje i dyrektywy sekcji głównej

begin sekcja1

opcje i dyrketywy sekcji1

begin sekcja3

...

Tak więc plik ten jest zbudowany z sekcji które rozpoczyna się słowem ‘begin nazwa’, z wyjątkiem sekcji głównej, która jest na samym początku pliku i nie posiada swojego begina. Sekcje również nie mają żadnych słów kluczowych któe by je zamykały – poprostu początek (begin) nowej sekcji oznacza zakończenie poprzedniej. I tak, standardowo mamy następujące sekcje:

- główna – odpowidzialna za podstawowe ustawienia Exim’a;
- acl – listy kontroli dostępu, filtrowania, odrzucania i akceptowania poczty;
- routers – hm, najprościej jest to przetłumaczyć jako routery, czyli reguły kierowania wiadomości do odpowiednich transporterów;
- transports – tutaj tworzymy sposoby doręczenia poczty;

- retry – ustawienia ponowień;
- rewrite – reguły do przepisywania nagłówków;
- authenticators – reguły do autoryzacji;

Co to są te całe ‘transportery’ i ‘routery’? Właściwie to serce Exima. Jeżeli Exim dostaje jakiegoś maila to najpierw puszcza go przez routery, które można porównać do reguł ipchains/iptables – jeżeli mail załapie się na jakąś regułę (router) to jest przekazywany do transportu określonego przez ten router. Inaczej mówiąc router w Eximie kieruje maila do odpowiedniego transportera. Transporter natomiast robi już z mailem co należy – doręcza go lokalnie, albo przekierowywuje gdzieś indziej albo odsyła do innego serwera. Wiem że w tym momencie może wydawać się to skomplikowane, ale nie przejmujcie się, to tylko wiedza teoretyczna która na początku nie będzie wam potrzebna. Musiałem natomiast wam wytłumaczyć że są sekcje i że musicie nauczyć się tego że jak napiszę ‘dopisać w sekcji głównej’ to należy coś dopisać na początku pliku ;-)

Hostname, banner i inne bajery

Czasami (czytaj: gdy mamy sieczę w /etc/hosts) Exim zgłasza się nie jako serwer.domena.pl a jako sam ‘serwer’. Jeżeli zmiana wpisów w /etc/hosts nie pomaga, albo gdy chcemy aby nasze MTA przedstawiało się inaczej niż hostname maszyny na którym stoii wystarczy ustawić (bądź dodać gdy jej nie ma) opcję ‘primary_hostname’ w głównej sekcji (nie wiesz gdzie to? jazda czytać ‘Budowa pliku konfiguracyjnego powyżej):

primary_hostname = serwer.domena.pl

W czasach zabawy z sendmailem podawałem także sposób na ograniczenie bannera który się pojawiał po telnecie na port 25. W Eximie nie jest to skomplikowane i służy do tego opcja ‘smtp_banner’ w sekcji głównej:

smtp_banner = $primary_hostname ESMTP $tod_full

Spowoduje to wyświetlanie następującego tekstu jako bannera:

220 serwer.domena.pl ESMTP Wed, 23 Jul 2003 15:18:04 +0200

Chyba nie muszę tłumaczyć że aby usunąć datę, należy wywalić ‘$tod_full’.

Aliasy

Jeżeli kompilowaliście Exima według mojego opisu, aliasy powinny być w /etc/mail/aliases. Jest to czysty plik tekstowy, tak więc zmiany w nim wprowadzone nie wymagają żadnego ‘newaliases’ czy restartu demona. Jeżeli jednak nie macie pewności czy tam powinien być plik z aliasami, w sekcji routers odszukajcie ciągu ‘system_aliases:’ – jest definicja routera odpowiedzialnego za rozwiązywanie aliasów. Tam też, w linijce data widać ścieżkę do pliku z aliasami:

system_aliases:
   driver = redirect
   allow_fail
   allow_defer
   data = ${lookup{$local_part}lsearch{/etc/mail/aliases}}
   file_transport = address_file
   pipe_transport = address_pipe

Autoryzacja

Jeżeli z naszego SMTP korzystają użytkownicy mobilni (dial-up’y) przyda nam się autoryzacja. O samej autoryzacji, oraz o tym jak ją sprawdzać pisałem już przy okazji autoryzacji w sendmailu. W tym wypadku, sprawa w Eximie jest dosyć zawiła. Otóż Exim zbyt wcześnie zrzuca uprawnienia root’a, tak że opisywany na wielu stronach opis zrobienia autoryzacji via PAM najczęściej nie działa. Z pomocą przyjdzie nam pakiet cyrus-sasl, a dokładniej pwcheck daemon (w PLD cyrus-sasl-saslauthd, a w przypadku źródeł należy dodać do ./configure parametr –with-pwcheck). Jeżeli posiadamy cyrusa w wersji 1.5.x, w sekcji ‘AUTHENTICATORS’ wpisujemy następujące linijki:

plain:
  driver = plaintext
  public_name = PLAIN
  server_prompts = :

  server_condition = ${if pwcheck{$2:$3}{1}{0}}
  server_set_id = $2

login:
  driver = plaintext
  public_name = LOGIN
  server_prompts = "Username:: : Password::"
  server_condition = ${if pwcheck{$1:$2}{1}{0}}
  server_set_id = $1

Uwaga! Podczas robienia autoryzacji na Exim’ie zauważyłem pewne dziwne zachowanie. Otóż autoryzować się poprzez PLAIN można w dwa sposoby. Pierwszy to ‘AUTH PLAIN

Po restarcie serwera autoryzacja powinna chodzić. Sprawdzamy ją w stary, dobry, sprawdzony sposób:

[baseciq@viper baseciq]$ printf 'login\0login\0haslo'|mimencode
bG9naW4AbG9naW4AaGFzbG8=
[baseciq@viper baseciq]$ telnet localhost 25
Trying localhost.25...
Connected to localhost
Escape character is '^]'.
220 viper.rulez.pl ESMTP Exim 4.20 Sun, 10 Aug 2003 03:49:55 +0200
EHLO localhost
250-viper.rulez.pl Hello baseciq at localhost [127.0.0.1]
250-SIZE 52428800
250-PIPELINING
250-AUTH PLAIN LOGIN
250-STARTTLS
250 HELP
AUTH PLAIN bG9naW4AbG9naW4AaGFzbG8=
235 Authentication succeeded

Sprawa się nieco komplikuje w przypadku cyrus-sasl 2.x, gdzie demon autoryzacji działa trochę inaczej. W tym wypadku Exim (4.20 i starszy potrzebuje łatki do obsługi saslauthd dostępnej pod tym adresem (kopia tutaj). Uwaga! Exim od wersji 4.21 nie potrzebuje już tej łaty i wspiera saslauthd w sposób opisany niżej! Po nałożeniu tej łaty, ustawieniu CYRUS_SASLAUTHD_SOCKET w Makefile i przebudowaniu Exima możemy dopisać do sekcji ‘authenticators’ następujący wpis:

plain:
  driver = plaintext
  public_name = PLAIN
  server_prompts = :

  server_condition = ${if saslauthd{$2:$3:smtp}{1}{0}}
  server_set_id = $2

login:
  driver = plaintext
  public_name = LOGIN
  server_prompts = "Username:: : Password::"
  server_condition = ${if saslauthd{$1:$2:smtp}{1}{0}}
  server_set_id = $1

A dla Exim-4.22 (i nowszych oczywiście) ten wpis wygląda tak:

plain:
  driver = plaintext
  public_name = PLAIN
  server_condition = ${if saslauthd{{$2}{$3}}{1}{0}}
  server_prompts = :
  # powyższy wpis zadziała przy saslauthd -a shadow, jeżeli
  # uruchomicie saslauthd -a pam (np. PLD) wpiszcie wtedy:
  # server_condition = ${if saslauthd{{$2}{$3}{smtp}}{1}{0}}
  server_set_id = $2

login:
  driver = plaintext
  public_name = LOGIN
  server_prompts = "Username:: : Password::"

  server_condition = ${if saslauthd{{$1}{$2}}{1}{0}}
  # powyższy wpis zadziała przy saslauthd -a shadow, jeżeli
  # uruchomicie saslauthd -a pam (np. PLD) wpiszcie wtedy:
  # server_condition = ${if saslauthd{{$1}{$2}{smtp}}{1}{0}}
 server_set_id = $1

Ostnią rzeczą przy saslauthd (odpalonym z -a pam) jaką trzeba stworzyć to plik /etc/pam.d/smtp:

#%PAM-1.0
#
# example PAM file for saslauthd - place it as /etc/pam.d/service
# (e.g. /etc/pam.d/smtp if you want to use saslauthd for SMTP AUTH)
#
auth	required	/lib/security/pam_listfile.so item=user sense=deny file=/etc/security/blacklist onerr=succeed
auth	required	/lib/security/pam_unix.so
auth	required	/lib/security/pam_tally.so file=/var/log/faillog onerr=succeed no_magic_root
auth	required	/lib/security/pam_nologin.so
account	required	/lib/security/pam_tally.so deny=0 file=/var/log/faillog onerr=succeed no_magic_root
account	required	/lib/security/pam_unix.so session	required	/lib/security/pam_unix.so

Pozostaje mi tylko wam przypomnieć, że przed sprawdzaniem autoryzacji należy także odpalić pwcheck/saslauthd ;)

Autoryzacja tylko poprzez SSL

martii <martii@obgyn.edu.pl> podesłał mi info jak ograniczyć autoryzację by była dostępna tylko dla klientów którzy uruchomili SSL. Wystarczy w sekcji głównej dopisać:

auth_advertise_hosts = ${if eq{$tls_cipher}{}{}{*}}

Podobną rzecz da się również zrobić w tpop3d.

Exim i SSL

Exim sobie bardzo dobrze radzi sobie z połączeniami szyfrowanymi przy użyciu protokołu SSL (wspiera metodę STARTTLS). O ile został skompilowany z odpowiednimi bilbiotekami, wystarczy wygenerować odpowiednie certyfikaty:

[baseciq@viper baseciq]$ openssl genrsa -out /etc/mail/exim.key 1024
Generating RSA private key, 1024 bit long modulus
.......++++++
..............................++++++
e is 65537 (0x10001)
[baseciq@viper baseciq]$ openssl req -new -x509 -days 365 -key /etc/mail/exim.key -out /etc/mail/exim.crt
Using configuration from /var/lib/openssl/openssl.cnf
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:PL
State or Province Name (full name) [Some-State]:Mazowsze
Locality Name (eg, city) []:Warsaw
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Baseciq Ltd.
Organizational Unit Name (eg, section) []:Baseciq's Mail Server
Common Name (eg, YOUR name) []:viper.baseciq.org
Email Address []:baseciq@baseciq.org

Oczywiście na pytania odpowiadajcie podając swoje dane… Po takim zabiegu do sekcji głównej Exim’a dopiszcie:

tls_certificate = /etc/mail/exim.crt
tls_privatekey = /etc/mail/exim.key
tls_advertise_hosts = *

Po tym zabiegu i restarcie Exim powinien bez problemu komunikować się po SSL, co zresztą widać w logach:

2003-09-07 01:48:36 19vmnC-0006EG-27 <= bensonzow@beer.com H=plug.atn.pl
[217.8.186.28] U=exim P=esmtp X=TLSv1:DES-CBC3-SHA:168 S=2909 id=ebb601c374e2$80dace00$cab00a12@fv

Warto by było, żeby także pop3d obsługiwał SSL’a natywnie ssl’a (bez jakichś stunneli i innych wynalazków). Ja osobiście polecam opisany w tekście Exim i MySQL demonik tpop3d, którego konfiguracja jest bardzo prosta. Wystarczy że standardowe ‘listen-address’ na takie:

listen-address: 0.0.0.0;tls=stls,/etc/mail/exim.crt,/etc/mail/exim.key \
                0.0.0.0;tls=immediate,/etc/mail/exim.crt,/etc/mail/exim.key

Jeżeli chcecie wymusić korzystanie z SSL to pewnie was zainteresuje informacja że dopisanie tej linijki:

apop-only: yes

Od teraz tpop3d na porcie 110 będzie obsługiwał SSL po wykonaniu komendy ‘STLS’ (np. TheBat potrafi tak zacząć sesję SSL) a na porcie 995 będzie odrazu używał SSL’a (TheBat, Outlook Express). Za pomoc w tpop3d+ssl chciałbym w tym miejscu podziękować Arkadiuszowi Miśkiewiczowi ;-) Dzięki Arek! :)

powoduje że w trybie bez TLS wymagana jest autoryzacja APOP inaczej nie odbierzemy maili. Natomiast przy połączeniu kodowanym ta reguła przestaje obowiązywać. I można po udanym STARTLS można autoryzować się plainem.

Exim i SSL na porcie 465

W nowszych wersjach Exim’a (dokładnie nie pamiętam w których, ale napewno 4.5x i 4.6x) należy poza operacjami podanymi powyżej dodać następujące wpisy w sekcji głównej pliku konfiguracyjnego:

daemon_smtp_ports = 25 : 465
tls_on_connect_ports = 465

Pierwsza opcja powoduje że poza portem 25 Exim zacznie nasłuchiwać także na 465, natomiast druga instruuje go żeby port 465 był od razu wykorzystywany jako port z szyfrowaniem połączenia. Natomiast w starszych wersjach Exim’a można to jedynie osiągnąć przy użyciu inetd (normalny Exim jako daemon, Exim po SSLu z inetd). Oto przykładowe konfiguracje dla poszczególnych inetd:

rlinetd:

service "exim-ssl" {
	protocol	tcp;
	port		"465";
	user		"root";
	tcpd		{ exit; }
	exec		"/usr/bin/exim -bs -tls-on-connect";
	}

xinetd:

service exim-ssl
{
	socket_type= stream
	protocol	= tcp
	port		= 465
	user		= root
	server		= /usr/bin/exim
	server_args	= -bs -tls-on-connect
	wait		= no
	}

inetd: (sprawdzone przez kflis’a – dzięki!)

465	stream	tcp	nowait	root	/usr/sbin/tcpd	/usr/bin/exim -bs -tls-on-connect

rc-inetd (PLD): (należy utworzyć plik /etc/sysconfig/rc-inetd/smtps i wstawić tam to co poniżej)

SERVICE_NAME=smtps
SOCK_TYPE=stream
PROTOCOL=tcp
PORT=465
FLAGS=nowait
USER=root
SERVER=tcpd
DAEMON=/usr/bin/exim
DAEMONARGS="-bs -tls-on-connect"

Quota i okolice

Generalnie nie ma sensu męczyć kernela i filesystemu żeby pilnował quoty na pocztę. Szczególnie gdy MTA samo sobie może z tym poradzić. Służy do tego parametr ‘quota’ w konfiguracji transportów (hint: poczytaj wyżej co to są transportery, routery itp.). I tak, w najprostszy sposób można lokalną quotę per user ustawić w konfiguracji transportu ‘local_delivery’ (odpowiedzialnego za lokalne dostarczanie poczty):

local_delivery:
	driver = appendfile
	file = /var/mail/$local_part
	delivery_date_add
	envelope_to_add
	return_path_add
	# A tutaj dodajemy quotę w wysokości 20MB:
	quota = 20M

Proste, prawda? Tak naprawdę ma to zastosowanie w systemach poczty wirtualnej gdzie możemy w bazie danych przechowywać quotę użytkownika i można skonstruować zapytanie SQL do odpytania ile miejsca ma dany użytkownik. Ale jeżeli nie możecie sobie poradzić z quotą systemową, możecie zamiast ‘quota = 20M’ dopisać coś takiego:

quota = ${lookup{$local_part}lsearch{/etc/mail/quota.conf}{$value}{0M}}

Od tego momentu w pliku /etc/mail/quota.conf możesz trzymać wielkości skrzynek dla poszczególnych użytkowników. Jeżeli ktoś nie zostanie tam wymieniony, to nie będzie miał żadnych limitów na swoją skrzynkę pocztową. Plik taki powinien wyglądać mniej-więcej tak:

lukasz:	100M
kflis:	5M
ania:	20M

I tak oto ja mam 100mb na pocztę, kubuś tylko 5, a siostra 20 MB ;) Podobnym paramterem każdego transportera jest ‘message_size_limit’. Wystarczy wpisać:

message_size_limit = 10M

Podobnie jak powyżej, można zrobić to na bazie pliku – wystarczy zamiast /etc/mail/quota.conf użyć np. /etc/mail/size_limits.conf ;-) BTW. na końcu linijki z quotą, gdzie mamy ’0M’ możemy wstawić np. ’20M’. Wtedy, osoby nie dopisane do /etc/mail/quota.conf będą miały 20MB limitu (limit domyślny).

Oczywiście jak na Exim’a przystało, od quoty jest więcej bajerków. Chyba najbardziej pożądanym ‘gwizdkiem’ będzie opcja ‘quota_warn_message’. Jest to nic innego jak mail ostrzegający usera o tym że skrzynka jest zapchana po same brzegi. Zanim jednak polecisz to wdrażać, zainteresuj się jak to działa. Otóż po dostarczeniu każdego maila Exim będzie sprawdzał czy został przekroczony konkretny próg (podany w megabajtach, lub w procentowo). Jeżeli tak, wygeneruje on odpowiednią wiadomość. I tak, dodajemy do molestowanego przez nas ‘local_delivery’ następujące opcje:

quota_warn_message = "\
Content-Type: text/plain; charset=ISO-8859-2\n\
To: $local_part@$domain\n\
Reply-to: Administratorzy sieci

Manualroute czyli przekazywanie poczty do konkretnego MX’a

Exim jak pisałem sam stara się znaleźć adres MX’a do którego ma przekazywać pocztę. Jednak czasami musimy przekazywać tą pocztę do konkretnego hosta, niekoniecznie wpisanego jako MX w DNS’ach. W takim wypadku, w sekcji ‘ROUTERS’ przed ‘dnslookup’ dopisujemy:

manual_route:
	transport = remote_smtp
	driver = manualroute
	domains = ! +local_domains : +relay_to_domains
	route_data = ${lookup{$domain} lsearch{/etc/mail/manual_routes}}

Po tym zabiegu, jeżeli dopiszemy pocztę do relay_to_domains możemy w pliku /etc/mail/manual_routes wpisać gdzie poczta z danej domeny ma być przekazywana, np:

baseciq.org:	mx2.baseciq.org

W powyższym przykładzie poczta dla ‘baseciq.org’ będzie przekazywana do ‘mx2.baseciq.org’.

Określanie dozwolonych nadawców dla pojedyńczego adres e-mail.

Typowo – zrobiliśmy aliasa prowadzącego do 50 osób, np. ‘wszyscy@domena.pl’. Jak łatwo zgadnąć, każdy może na ten adres wysłać, po pewnym czasie adres taki znajduje się już na listach spamerskich i jesteśmy załatwieni. Najlepiej, zrobić filtr osób które mogą na ten adres wysyłać. Tak więc, odszukujemy ‘acl_check_rcpt’ w pliku konfiguracyjnym i piszemy:

deny       message         = Nie jestes uprawniony aby wysylac poczte na ten adres
        condition       = ${if exists{/etc/mail/senderslists/${local_part}@${domain}}{1}{0}}
	senders         = ! /etc/mail/senderslists/${local_part}@${domain}

Teraz, w pliku /etc/mail/senderslists/wszyscy@domena.pl dopisujemy po jednym w każdej linijce adresy e-mail które mają prawo wysyłać maile do wszyscy@domena.pl. Oczywiście, w ten sposób nie chronimy tylko aliasów, a cały ruch na naszym serwerze. Dla przykładu – można w ten sposób chronić adresy nie znajdujące się na naszym serwerze, ale także te znajdujące się na innych serwerach, oczywiście ochrona ta będzie działać tylko na osoby przesyłające przez nasz serwer.

]]> http://www.baseciq.org/2006/04/26/konfiguracja-exima/feed 2 Przypowieść samobójcza o migracji z Slackware do PLD :) http://www.baseciq.org/2003/06/22/przypowiesc-samobojcza-o-migracji-z-slackware-do-pld http://www.baseciq.org/2003/06/22/przypowiesc-samobojcza-o-migracji-z-slackware-do-pld#comments Sun, 22 Jun 2003 10:00:19 +0000 Baseciq http://www.baseciq.org/?p=114 Migracja ze Slackware do PLD

… czyli 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 zacząłem generować patch z zestawem łat jakich używam na co dzień (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 stoi 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 architektur 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 5×86, AMD K5 (te na socket7) i K6. Pozostałe procesory tj, 386, 486 oraz AMD 5×86 (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.

Skąd to wszystko ściągnąć? Najlepiej odwiedzić ftp://ftp.pld-linux.org/

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]

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/i686/PLD/RPMS/packages.dir.mdd...
Pobieranie ftp://ftp.pld-linux.org/dists/ra/PLD/i686/PLD/RPMS/packages.dir.gz...
.................................................. 100.0% [3.6M]
Weryfikacja ftp://ftp.pld-linux.org/dists/ra/PLD/i686/PLD/RPMS/packages.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/i586/PLD/RPMS/packages.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/i586/PLD/RPMS/packages.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/i686/PLD/RPMS/packages.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/i686/PLD/RPMS/m4-1.4n-4.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/epic4-1.0.1-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.2 $, $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, pakiety zbudowane leżą sobie w /home/users/lukasz/rpm/RPMS.

]]> http://www.baseciq.org/2003/06/22/przypowiesc-samobojcza-o-migracji-z-slackware-do-pld/feed 1 Linux i SDI http://www.baseciq.org/2003/06/02/linux-i-sdi http://www.baseciq.org/2003/06/02/linux-i-sdi#comments Mon, 02 Jun 2003 10:00:30 +0000 Baseciq http://www.baseciq.org/?p=113 SDI w linuksie

Terminal HIS/SDI jest niczym innym jak bardzo fajnym modemem, a jego konfiguracja pod Linuxem jest bardzo prosta.

1) Na pierwszy ogień idzie plik /etc/sysconfig/network-scripts/chat-ppp0. Jeżeli go nie ma, polecam go stworzyć komendą touch /etc/sysconfig/network-scripts/chat-ppp0. Później edytujemy go jakimś edytorem (mcedit, vi, pico, joe) i wstawiamy do niego dwa apostr ofy. Nie wiem jak w innych dystrybucjach, ale w RedHat 6.0, 6.2 i 7.0 nie musiałem tego pliku tworzyć ;)

2) Następna ofiara naszego edytora tekstowego to: /etc/ppp/pap-secrets. Wyrzucamy tam wszystko i wpisujemy:

login * hasło adres_ip

Login – login jaki nam przydzieliła tpsa. Gwiazdka to gwiazdka i ma tam być ;). Hasło – wpisz ‘ala^m4^k0tk4$!’ – może zadziała, a jak nie to wpisz swoje normalne hasło, natomiast pojęcia ‘adres_ip’ chyba nie muszę tłumaczyć. Powinien być na umowie o SDI. Teraz trzeba stworzyć plik startowy który będzie uruchamiał pppd. Wchodzimy do /etc/rc.d i tworzymy sobie plik rc.his (touch rc.his). Po czym wpisujemy w nim:

#!/bin/sh
pppd /dev/ttyS* 115200 modem defaultroute lock crtscts noauth user twój_login

W miejsce gwiazdki wstawiasz numer portu COM – 0 dla COM1, 1 dla COM2, itd. Wystarczy nadać prawa do wykonywania tego pliku (chmod u+x /etc/rc.d/r c.his) i możemy uruchomić komendą ‘/etc/rc.d/rc.his’. Teraz dopisujemy do /etc/rc.local:

if [ -x /etc/rc.d/rc.his ]; then
        /etc/rc.d/rc.his
fi

Spowoduje to automatyczne uruchamianie SDI podczas startu komputera. Połączenie z internetem mamy, przydało by się jeszcze DNS skonfigurować w pliku /etc/ resolv.conf:

search sdi.tpnet.pl
nameserver 194.204.159.1
nameserver 194.204.152.34

Powinno działać. Okej, skoro połączenie z netem mamy, to teraz sieć lokalna. Ale to już w inny tekście.

A co zrobić by zapobiec zrywaniu połączenia?

Są dwa sposoby – skrypt w crontabie pingujący np najbliższy router tpsa – ta metoda zapobiegnie temu gdy daemon pppd sobie nagle zdechnie z niewiadomych przyczyn. Druga metoda to odpowiednie parametry pppd by podtrzymywał połączenie za wszelką cenę i je ponownie uruchamiał gdy np. zostanie zerwane z przez TP S.A. (reset półki od SDI, awaria zasilania samego terminala itp.). Zamiast :

pppd /dev/ttyS* 115200 modem defaultroute lock crtscts noauth user twój_login

piszemy:

pppd /dev/ttyS* 115200 modem defaultroute noauth crtscts lock \
persist maxfail 0 lcp-echo-interval 10 lcp-echo-failure 10 user twój_login

A jak to zrobić w PLD?

Za irc.pld-linux.org: Jest to dość proste zadanie. Należy utworzyć plik nowego interfejsu w /etc/sysconfig/interfaces. Ja go nazwałem sdi, czyli tworzymy plik ifcfg-sdi w podanym wcześniej katalogu. Plik ten powinien zawierać mniej więcej takie dane:

DEVICE=ppp0
ONBOOT=yes
MODEMPORT=/dev/ttyS0

Oczywiście ttyS0 odpowiada portowi COM1, więc dla sdi na COM2 zmieniamy to na ttyS1. ONBOOT=yes uruchomi nam interfejs przy starcie systemu automagicznie. Drugim interesującym nas plikiem jest /etc/ppp/options.ttyS0 (opcje ppp tylko dla portu COM1, jeśli nie masz tego pliku w systemie to należy go utworzyć):

crtscts
defaultroute
lock
modem
115200
noauth
persist
noccp
user nazwa_naszego_usera_otrzymanego_od_tpsa

Ostatnim plikiem który musimy zmodyfikować jest /etc/ppp/pap-secrets w który wygląda mniej więcej tak:

nazwa_naszego_usera_otrzymanego_od_tpsa * password adres_ip

W tym momencie password to standardowe hasło jakie daje tpsa przy uruchomieniu usługi jeśli macie inne to również je należy zmienić. Po wydaniu komendy "ifup sdi", powinniśmy mieć już podłączenie do Internetu.

]]> http://www.baseciq.org/2003/06/02/linux-i-sdi/feed 0