AuthzSVNAccessFile /home/services/subversion/groups
<Directory /home/services/subversion/>
     Order allow,deny
     Allow from all
</Directory>

Ja właśnie spędziłem kawałek nocy dochodząc do tego, bo cały czas otrzymywałem komunikat:

svn: Serwer wysłał nieoczekiwaną wartość powrotną (403 Forbidden) w odpowiedzi na żądanie OPTIONS
svn: Server sent unexpected return value (403 Forbidden) in response to OPTIONS request

Jedną z metod, na szybkie wykonywanie CGI, jest mechanizm FastCGI. Poza swoimi podstawowymi funkcjami, jest on w stanie także uruchomić jakiś proces i korzystać z niego jako z backendu do autoryzacji.

Co będziesz potrzebować?

• działającego Apache
• skompilowany i zainstalowany moduł FastCGI
• trochę wiedzy z konfiguracji Apache
• no i oczywiście pomysłu na backend autoryzacyjny

Z pierwszymi dwoma rzeczami powinieneś sobie poradzić bez większych problemów instalując PLD :) Pozycja nr. 3 rozumie się chyba sama przez siebie jeżeli tutaj zawitałeś. Z czwartym składnikiem rozwiązania, niestety musisz poradzić sobie sam. Ale i na to postaram się coś poradzić.

Let’s go

Kilka słów wstępu. Od czasów Apache 2.2, moduł auth (czy może powinienem go nazwać AuthBasic?) powoduje to, iż Apache wymaga podania „dostawcy” podstawowej autoryzacji za pomocą dyrektywy AuthBasicProvider. Niestety, z tego co mi wiadomo (pamiętaj: mogę się mylić), FastCGI nie rejestruje się w Apache jako dostawca tejże autoryzacji. Problem został zauważony, opisany i załatany w Debianie (więcej informacji tutaj) a także w PLD. Jeżeli posiadasz inną dystrybucję, na stronie z raportem błędu debiana jest link do łatki debianowej która łata także i ten problem. Niestety, ja nie posiadam nic innego niż PLD i Debian, więc nie poprowadzę Cię na piechotę.

Przejdźmy do rzeczy. Oto przykładowa konfiguracja Apache aby się autoryzował za pomocą zewnętrznego skryptu:

<Directory /home/cokolwiek>
                AuthType Basic
                AuthName "ProtectedRealm"
                AuthBasicProvider fastcgi
                FastCgiAuthenticator /usr/local/sbin/http-auth-lms.pl
                FastCgiAuthenticatorAuthoritative On
                require valid-user
</Directory>

Jak widać, konfiguracja w sumie zbyt dużo nie odbiega od normalnej autoryzacji, poza podaniem ścieżki do skryptu w perlu. W moim wypadku jest to skrypt który autoryzuje się w bazie LMS’a. Po co i dlaczego, piszę w tekście który też gdzieś tutaj jest :)

Skrypt znalazłem na jednej ze stron i go odpowiednio dostosowałem (czytaj: wykorzystałem tylko szkielet obsługi CGI), ale niestety nie pamiętam gdzie i u kogo. w perlu wygląda tak:

#!/usr/bin/perl -Tw

use FCGI;
use CGI (':standard');
use DBI;

# konfiguracja dostępu do bazy danych:

my $dbhost="localhost";
my $dbuser="mysql";
my $dbpw="p4ssw0rd";
my $dbname="lms";

my $dbport="3306";

# połączenie do bazy jako takiej:

my $dbh = DBI->connect(
		"DBI:mysql:database=$dbname:host=$dbhost:port=$dbport",
		$dbuser,
		$dbpw,
		{PrintError=>0}
);

# zapytanie o hasło:

my $verify_passwd = $dbh->prepare(
		'select passwd from users where login=?'
);

my $s200 = '200 OK';

my $s401 = '401 Authorization Required';

my $q = FCGI::Request();

while ($q->Accept >= 0) {
		my $u = '';
		my $p = '';

		if (exists $ENV{REMOTE_USER})   { $u = $ENV{REMOTE_USER}; }
		if (exists $ENV{REMOTE_PASSWD}) { $p = $ENV{REMOTE_PASSWD}; }

		if (not ($u and $p)) {
				spit($s401);
		} else {

				# na wszelki wypadek - jeżeli baza danych się rozłączyła,

				# połączmy się ponownie i przygotujmy zapytanie:

				unless(defined $dbh and defined $verify_passwd) {
						$dbh = DBI->connect("DBI:mysql:database=$dbname:host=$dbhost:port=$dbport",$dbuser,$dbpw,{PrintError=>0});
						$verify_passwd = $dbh->prepare('select passwd from users where login=?');
				}

				$verify_passwd->execute($u) if(defined $verify_passwd);

				my ($dp) = $verify_passwd->fetchrow_array;

				if (not ($dp)) {
						spit($s401);
				} elsif ($dp eq crypt($p, $dp)) {
						spit($s200);
				} else {
						spit($s401);
				}
		}
}

undef $verify_passwd;
$dbh->disconnect if(defined $dbh);
undef $dbh;
exit 0;

sub spit {
		my $s = shift;
		print header('text/plain', $s), $s;
}

Jak widać, skrypt ten autoryzuje się w bazie LMSa. Dzięki niemu, masz jakiś przykład jak to dalej pociągnąć i jak sobie z tym poradzić :)

Opis ten powstał w poście na forum pdaclub.pl i nie jest przeznaczony dla ludzi technicznych.

A! Chciałbym zaznaczyć, iż mimo tego że opis jest bardzo „windziany”, bez problemu sprawdzi się także i wśród miłośników drobiu arktycznego.

1) Pobieramy ffmpeg z adresu http://darusuna.sakura.ne.jp/src/fumiFFMpeg20060721.zip – jest to jedyna jak do tej pory wersja którą znalazłem w sieci skompilowaną pod windowsa która posiada support do XviD. Po ściągnięciu wrzucamy go do jakiegoś folderu, np. C:\ffmpeg.

2) Do rzeczonego katalogu wrzucamy ofiarę, czyli plik do skonwertowania, w moim przypadku jest to plik test.avi.

3) Zanim zaczniemy, musimy znać wymiary (rozdzielczość pliku źródłowego). W moim przypadku jest to 624 x 352.

4) O ile szerokość filmu jest oczywista (320) to jego wysokość pozostaje do ustalenia. Odpalamy windowsowy kalkulator i liczymy:

320 : 624 * 352 = 180…. z kawałkiem

Gdzie wiadomo że 624 to szerokość pliku avi, a 352 to jego wysokość.

5) Odpalamy menu start -> uruchom -> wpisujemy cmd i enter

6) Wchodzimy do katalogu z ffmpeg (cd C:\ffmpeg)

7) odpalamy ffmpega:

ffmpeg.exe -i test.avi -b 360k -s 320×180 -ar 44100 -ab 96 -ac 2 -acodec mp3 -vcodec xvid test-pda.avi

A teraz opcje:

-i – czyli plik wejściowy

-b – bitrate pliku, pokombinuj z różnymi wartościami i bądź świadom tego, że to co na pececie wygląda makabrycznie, na dużo mniejszym ekranie może wyglądać okej.

-s – wymiary pliku wynikowego, które już obliczyliśmy. Pamiętaj że ffmpeg nie plinuje aspect ratio!

-ar – audio rate, czyli jakość dźwięku

-ab – audio bitrate – 96kbps

-ac – ilość kanałów audio (2 to stereo, 1 to mono)

-acodec – kodek audio, może być mp3 lub ac3 lub wiele innych

-vcodec – kodek wideo do którego film ma być skonwertowany

a na końcu nazwa pliku wynikowego.

BTW. Ja używam tego akurat pod linuksem i działa okej, bez problemów i wszystkie filmiki TCMP otwiera. Pozostaje sobie załatwić subtitle workshop i skonwertować napisy (koniecznie z wczytanym filmem, żeby przy klatkowych bzdur nie narobił ).

HTH

Baset

A w trakcie pracy ffmpeg wygląda tak:

C:\ffmpeg>ffmpeg.exe -i test.avi -b 360k -s 320x180 -ar 44100 -ab 96 -ac 2 -acodec mp3 -vcodec xvid test-pda.avi

ffmpeg version CVS, build 3342336, Copyright (c) 2000-2004 Fabrice Bellard

configuration: --enable-memalign-hack --enable-mingw32 --enable-amr_nb --enable-amr_wb --enable-mp3lame --enable-faad --enable-faac --enable-xvid --enable-x264 --enable-a52 --enable-gpl --enable-libogg --enable-vorbis

built on Jul 21 2006 04:29:58, gcc: 3.2.3 (mingw special 20030504-1)

Input #0, avi, from 'test.avi':

Duration: 00:42:58.6, start: 0.000000, bitrate: 1137 kb/s

Stream #0.0, 23.98 fps(r): Video: mpeg4, yuv420p, 624x352

Stream #0.1: Audio: mp3, 48000 Hz, stereo, 112 kb/s

Output #0, avi, to 'test-pda.avi':

Stream #0.0, 23.98 fps(c): Video: xvid, yuv420p, 320x180, q=2-31, 360 kb/s

Stream #0.1: Audio: mp3, 44100 Hz, stereo, 96 kb/s

Stream mapping:

Stream #0.0 -> #0.0

Stream #0.1 -> #0.1

frame=61834 q=2.0 Lsize= 146633kB time=2578.7 bitrate= 465.8kbits/s

video:112550kB audio:30219kB global headers:0kB muxing overhead 2.706159%

"To co mam do powiedzenia na temat Twoich migracji (slack->pld, epic->irssi, sendmail->exim) nie nadaje się do publikacji."

Jakub Flis

A dnia 16 września roku pańskiego 2003, kflis rzekł:

Baseciq słuchaj, ale będzie poważny kłopot, będziesz musiał zmienić motto przewodnie artykułu, przynajmniej w części o eximie. ;) – czyli następny zadowolony konserwatysta.

Dlaczego Exim?

Bo zupa była za słona. A na poważnie rzecz biorąc:
- bo sendmail jest dziwny;
- bo qmail nie jest MTA;
- bo z postfiksem mam traumatyczne doświadczenia;
- autoryzacja to w nim jest domyślna;
- przystosowany jest do kombinacji alpejskich i slalomów gigantów;

- w PLD jest ładnie przygotowana paczka :-);
- umie gadać z MySQL’em;
- z Postgres’em zresztą też;
- i w dodatku standardowymi plikami tekstowymi też nie pogardzi;
- Tom Kistner napisał do Exim’a zaj***stą łatkę, rozbudowywującą Exim’a o obsługę programów antywirusowych, daemona SpamAssasin (skanera antyspamowego) oraz wykrywania błędów MIME – dzięki temu nie potrzebujemy wielkich i zasobożernych syfów w perlu;
- Za to Tomasz Kojm napisał zaj***sty program antywirusowy: Clam AntiVirus – darmowy, w dodatku rewelacyjnie współpracujący z Exiscanem;

Podsumowywując – Exim jest rewelacyjnym MTA. Jego możliwości konfiguracji pozwoliły mi na zbudowanie dosyć rozbudowanego serwera poczty obsługującego zarówno konta lokalne jak i konta zapisane w bazie danych MySQL. Dodatkowe ‘gwizdki’ to np. przeszukiwanie plików konfiguracyjnych serwera cvs w poszukiwaniu adresów docelowych dla aliasów w domenie cvs.rulez.pl. O rzeczach takich jak klasyfikowanie maili czy są spamem czy nie już nawet nie wspomnę. W dodatku Exim jest całkiem bezpiecznym MTA (wersja 4.x wg. securityfocus jak narazie dorobiła się jednego błędu – w końcu jakaś cena musi być za te wodotryski). Zresztą konstrukcja omawianego MTA na początku doprowadzała mnie do szału, gdyż Exim za cholerę nie może sobie poradzić z smtp-auth via PAM z racji braku uruchamiania autoryzacji z własnego uid/gid zamiast root’a ;-).

Jak to coś zainstalować?

Jako że w momencie gdy piszę te słowa nie mam jeszcze zabardzo gdzie zacząć budować Exim’a, pozwolę sobie opisać jak to zrobić w PLD. Zacznijmy od przygotowania miejsca na budowę paczek (jeżeli masz potworzone odpowiednie katalogi to możesz przejść akapit niżej):

[lukasz@serv lukasz]$ rpm --install-build-tree
[lukasz@serv lukasz]$ cd rpm/
[lukasz@serv rpm]$ export CVSROOT=":pserver:cvs@cvs.pld-linux.org:/cvsroot"
[lukasz@serv rpm]$ cvs -z9 get SPECS/builder SOURCES/kernel-i386.config
U SPECS/builder
U SOURCES/kernel-i386.config

Ci bardziej obeznani z CVS’em wiedzę po co ściągamy SOURCES/kernel-i386.config (musimy zainicjować lokalne repozytorium w katalogu SOURCES). Teraz wchodzimy do katalogu rpm/SPECS/ w naszym $HOME i działamy. Tutaj mała uwaga – przy ./builder parametr ‘-r RA-branch_general’ dodajemy tylko w wypadku gdy budujemy dla PLD-1.0 Ra. RA-branch_general jest branchem utworzonym specjalnie na potrzeby tego, by Exim budował się bezproblemowo pod Ra:

[lukasz@serv lukasz]$ cd ~/rpm/SPECS/
[lukasz@serv SPECS]$ ./builder -r RA-branch_general exim.spec
U exim.spec
# $Revision: 1.2 $, $Date: 2006-05-11 19:25:18 $

O ile mamy wszystkie potrzebne biblioteki do budowy za kilka(naście) minut powinniśmy ujrzeć radosne:

Zapisano: /home/users/lukasz/rpm/SRPMS/exim-4.32-1.src.rpm
Zapisano: /home/users/lukasz/rpm/RPMS/exim-4.32-1.i686.rpm
Zapisano: /home/users/lukasz/rpm/RPMS/exim-X11-4.32-1.i686.rpm

Pozostaje nam tylko zainstalować zbudowane paczki i przejść dalej.

No dobrze. A teraz przećwiczmy ze źródeł ;-)

Na początku musisz przemyśleć czy chcesz mieć exiscana czy nie. Pragnę Cię poinformować, iż połatanie Exim’a aby obsługiwał antywirusy wcale nie jest trudne i wcale nie jesteśmy zmuszeni do korzystania z antywirusa po połataniu. Oki. Kompilację z racji braku systemu pod ręką odpowiedniego przeprowadzałem na Debianie 3.0 uaktualnionym do unstable (tak, sam się dziwię że to działa). Zacznijmy od pobrania Exim’a. Jeżeli zdecydowałeś się na exiscana, pobierz także i jego. Po ściągnięciu rozpakowywujemy Exim’a, wchodzimy do jego katalogu i (opcjonalnie, przy czym w najnowszych wersjach ta łatka nie jest już potrzebna!) nakładamy łatkę od exiscana:

wget ftp://ftp.csx.cam.ac.uk/pub/software/email/exim/exim4/exim-4.34.tar.gz

wget http://duncanthrax.net/exiscan-acl/exiscan-acl-4.34-22.patch
tar -xzf exim-4.34.tar.gz
cd exim-4.34 patch -p1 < ../exiscan-acl-4.34-22.patch

Teraz należy przygotować Exim’a do budowy. Kopiujemy plik src/EDITME do Local/Makefile oraz exim_monitor/EDITME Local/eximon.conf:

cp src/EDITME Local/Makefile
cp exim_monitor/EDITME Local/eximon.conf

I teraz możemy się wziąść za jego ‘tuning’ ;-). Otwieramy Local/Makefile w ulubionym edytorze i zmieniamy:

• Odnajdujemy ‘BIN_DIRECTORY=/usr/exim/bin’ i zmieniamy na ‘BIN_DIRECTORY=/usr/bin’.
• Odnajdujemy ‘CONFIGURE_FILE=/usr/exim/configure’ i zmieniamy na ‘CONFIGURE_FILE=/etc/mail/exim.conf’ (nie jest to konieczne, ale jeżeli zmienisz tutaj ścieżkę dostępu do tego pliku będziesz musiał o tym pamiętać).
• Odnajdujemy ‘EXIM_USER=’, usuwamy ją i wpisujemy kolejno (w oddzielnych linijkach) ‘EXIM_UID=79′ i ‘EXIM_GID=79′. Nie zapomnijcie dodać później tego użytkownika i grupy w systemie:

  groupadd -g 79 exim
  useradd -g 79 -u 79 exim

• Usuwamy komentarz (znak ‘#’) przed linijką ‘TRANSPORT_LMTP=yes’.
• Usuwamy komentarze przed linijkami: ‘SUPPORT_MAILDIR=yes’, ‘SUPPORT_MAILSTORE=yes’ i ‘SUPPORT_MBX=yes’.
• Usuwamy komentarze przed linijkami: ‘LOOKUP_CDB=yes’ i ‘LOOKUP_WILDLSEARCH=yes’.
• Jeżeli chcemy mieć support do autoryzacji SMTP usuwamy komentarze przed linijkami: ‘AUTH_CRAM_MD5=yes’ i ‘AUTH_PLAINTEXT=yes’.
• Jeżeli chcemy mieć support do OpenSSL (do połączeń szyfrowanych) i mamy poprawnie zainstalowane biblioteki OpenSSL usuwamy komentarze przed linijkami ‘SUPPORT_TLS=yes’ i ‘TLS_LIBS=-lssl -lcrypto’.
• Odnajdujemy linijkę ‘# LOG_FILE_PATH=/var/log/exim_%slog’ i zmieniamy na ‘LOG_FILE_PATH=/var/log/exim/%s.log’ – w ten oto sposób exim będzie trzymał swoje logi w katalogu /var/log/exim/. Oczywiście, pamiętajmy o zrobieniu tego katalogu i nadaniu mu odpowiednich praw dostępu:

  mkdir -p /var/log/exim
  chown exim.exim /var/log/exim

• Jeżeli nasz system wspomaga PAM usuwamy komentarz przed linijką ‘SUPPORT_PAM=yes’ i niżej dopisujemy EXTRALIBS=-lpam -ldl. Jeżeli nie mamy obsługi PAM będziemy musieli dodać EXTRALIBS=-ldl.
• Aby móc prawidłowo obsługiwać autoryzację będziemy potrzebować pwcheck – demona autoryzacj z pakietu cyrus-sasl (W Debianie paczka sasl-bin, uruchamia się go /etc/init.d/pwcheck start, w PLD cyrus-sasl-saslauthd). Exim bardzo dobrze umie dzięki niemu sprawdzać autoryzację. Aby to działało, należy odnaleźć linijkę ‘CYRUS_PWCHECK_SOCKET=/var/pwcheck/pwcheck’ (CYRUS_SASLAUTHD_SOCKET jeżeli używamy saslauthd z pakietu Cyrus-2.x) usunąć komentarz z jej początku, oraz wpisać poprawną ścieżkę do socketu pwcheck’a (W Debianie jest to /var/state/pwcheck/pwcheck, w PLD jest /var/lib/sasl/mux, w innych dystrybucjach nie mam zielonego pojęcia, natomiast w slackware i tak będziesz musiał cyrus-sasl zbudować samemu więc pewnie nie będzie dla Ciebie problemem skąd wziąść socket).
• Odnajdujemy ‘SYSTEM_ALIASES_FILE=/etc/aliases’ na ‘SYSTEM_ALIASES_FILE=/etc/mail/aliases’.
• W linijkach zawierących ‘COMPRESS_COMMAND’ i ‘ZCAT_COMMAND’ zmieniamy ścieżki dostępu do programów zcat i gzip na te odpowiadające naszemu systemowi.
• Usuwamy komentarz w linijce zawierającej ‘EXIM_PERL=perl.o’.
• Usuwamy komentarz w linijce zawierającej ‘SUPPORT_MOVE_FROZEN_MESSAGES=yes’.
• Na koniec usuwamy tylko znaki komentarza z linijek ‘# PID_FILE_PATH=/var/lock/exim.pid’ oraz ‘# SPOOL_MODE=0640′ i możemy męczyć się dalej.
• Odnajdujemy ‘HEADERS_CHARSET’ i ustawiamy mu ‘ISO-8859-2′
• Komentujemy linijkę zawierającą ‘EXIM_MONITOR’ jeżeli nie chcemy pracującego pod X-Window monitora do Exim’a
• Jeżeli chcemy aby nasz Exim umiał dogadać się z MySQL’em, usuwamy komentarz przed linijką ‘LOOKUP_MYSQL=yes’, odnajdujemy linijkę zawierającą ‘LOOKUP_INCLUDE’ i zmieniamy ją by wyglądała: ‘LOOKUP_INCLUDE=-I /usr/include/mysql’. Poniżej znajduje się linijka ‘LOOKUP_LIBS’, którą modyfikujemy tak by miała wyglądała tak: ‘LOOKUP_LIBS=-lmysqlclient’. Uwaga! Ścieżka /usr/include/mysql może być zupełnie inna w Twoim systemie. Skontaktuj się z najbliższym powiatowym magikiem od Linuksa jeżeli nie będziesz mógł jej sam odgadnąć ;-)

Uff. Teraz klepiemy ‘make’ i czekamy. Jeżeli nic się nie wywaliło, to mamy szczęście. Jeżeli natomiast budowani się niepowiedzie proponowałbym zacząć od zmiany LOOKUP_INCLUDE w Local/Makefile. Pamiętać należy że po modyfikacji Local/Makefile należy wykonać ‘make makefile’.

Po skończeniu kompilacji oczywiście można wykonać make install i przejść do przyjemniejszej części zabawy, czyli konfiguracji naszego nowego lśniącego MTA ;-)

Uruchamianie i tym podobne.

Exima odpala się dosyć standardowo – ‘exim -bd -q15m’ – czyli praktycznie tak samo jak sendmaila. Komenda ‘mailq’ również zadziała. Aby wymusić opróżnienie kolejki uruchamiamy ‘exim -qf’ (lub -qf -d – wtedy zobaczymy debug) a pojedyńczego maila popychamy przy pomocy ‘exim -M <id>’, gdzie ID możemy wyczytać z komendy ‘mailq’.

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.

Bridge jest urządzeniem odzielającym dwa lub więcej fizyczne segmenty sieci będące w jednej sieci logicznej (w obrębie jednej klasy adresowej).

Bridge jest najczęściej umieszczany pomiędzy dwoma grupami komputerów w sieci, gdzie komputery w obrębie danej grupy komunikują się ze sobą bardzo często, lecz komputery pomiędzy tymi grupami komunikują się rzadziej. W takim wypadku bridge zminimalizuje obciążenie sieci.

Zadaniem bridge’a jest decyzja czy pakiety z jednego interfejsu sieciowego powinny być przeniesione na drugi interfejs sieciowy. Bridge działa podobnie jak switch sieciowy (switch warstwy drugiej) – jest przezroczystym komponentem sieci (są nimi także huby czy też switche). Różnica pomiędzy switchem a zwykłym hubem jest taka, że ten drugi pakiety zasłyszane na jednym porcie przenosi na wszyskie porty, a switch tylko na te na które trzeba. Niektórzy zaraz powiedzą "przecież tak działają także routery!". Nie do końca. Routery działają tylko dla protokołu IP, natomiast bridge nie przenosi pakietów patrząc na typ protokołu (IP, IPX/SPX, NetBeui), ale na adres MAC źródłowe i docelowe. Dlatego też dzięki uruchomieniu bridge’a możemy bezproblemowo korzystać z usługi netbios czy programów korzystających z protokołu IPX/SPX w sieciach połączonych serwerem Linuxowym. Po uruchomieniu bridge’a nadal możemy na serwerze uruchamiać jakiekolwiek usługi o ile chcemy.

Inne pożyteczne zastosowanie bridge’a to możliwość połączenie dwóch standardów sprzętu sieciowego np. 10-Base-T (sieć BNC) i 100-Base-TX (sieć na skrętce) – do tego wystarczy nam komputer klasy 486 ze stacją dyskietek i kością pamięci który leży niepotrzebny pod biurkiem. Efekt: nie musimy kupować huba z uplinkiem BNC a przy okazji bridge taki zmniejszy nam obciążenie sieci.

Jako że autor HOWTO na którym bazuje ten tekst podał swój prywatny powód dlaczego postawil bridge’a, zrobię tak i ja. W naszej sieci blokowej są trzy segmenty sieci na BNC. Każdy z nich miał swoją klasę C z puli 192.168.0.0/16. W jednym z nich (nazwijmy go segmentem nr. 1) stał serwer DHCP dla tego segmentu sieci. Wszystkie 3 segmenty zbiegały się w routerze Linuxowym. Na tymże routerze działał serwer DHCP dla segmentów 2 i 3. Należało oczywiście zainstalować także serwer samby z obsługą wins’a aby w windowsowym otoczeniu sieciowym komputery widziały się nawzajem pomiędzy segmentami. Niestety rozwiązanie to nie pomagało aby chodziły bezproblemowo w sieci programy do komunikacji w lanie a o graniu pomiędzy segmentami w gry wkorzystujące protokół IPX/SPX nie było wogóle mowy. Teraz wszystkie trzy segmenty są w obrębie jednej klasy adresowej, serwer WINS nie jest już potrzebny, DHCP działa jedno dla całej sieci, a i serwer ma tylko jeden adres IP.

Kilka pojęć o bridge.

- po przypisaniu karty sieciowej do bridge’a staje się ona jego portem i nie mamy nad nią już żadnej kontroli;
- port może być przypisany tylko do jednego bridge’a (na jednej maszynie może być kilka bridge’y);
- bridge nic nie wie na temat protokołów wyższych niż ARP, dlatego potrafi obsłużyć każdy możliwy protokół uruchomiony w Twojej sieci lokalnej;
- bridge może mieć dowolną ilość interfejsów (mimo iż się spotkałem z opiniami że bridge może mieć tylko dwa porty i po uruchomieniu bridge’a komputer staje się bezwartościowy jako maszyna tcp/ip);

- bridge działa jak interfejs sieciowy, może mieć swój adres IP;
- można uruchomić dowolną ilość bridge’y, np: bridge1 obsługuje sieci na eth0 i eth1 a bridge2 obsługuje sieci na eth2 i eth3, a pomiędzy bridge1 i bridge2 można uruchomić normalny routing tak jakby bridge1 i bridge2 były kartami sieciowymi;

Potrzebne pliki.

Wszystkie pliki potrzebne do postawienia bridge’a można znaleźć pod adresem http://bridge.sourceforge.net/download.html. Kernele serii 2.4.* posiadają wbudowaną obsługę bridge’a, natomiast by w kernelach 2.2.* wszystko sprawnie działało potrzebna jest ta łatka: http://bridge.sourceforge.net/patches/bridge-1.0.2-against-2.2.20.diff – powinna się znajdować na dole tamtego indeksu. Do zarządzania bridge’m potrzebny jeszcze jest program brctl: http://bridge.sourceforge.net/bridge-utils/. Obsługę bridge’a najlepiej wkompilować jako moduł (CONFIG_BRIDGE=m). Będzie ona działała poprawnie, natomiast przy kompilacji na stałe może ona wywołać problemy. Później przystępujemy do kompilacji i instalacji bridge-utils:

$ tar -xzf bridge-utils-0.9.3.tar.gz$ cd bridge-utils$ make$ cp brctl/brctl /sbin

Składnia brctl wygląda tak: brctl <komenda> [parametry]

Podstawowe komendy:

addbr [nazwa], delbr [nazwa] – odpowiednio dodanie bridge’a i usnięcie bridge’a o podanej nazwie. Nazwa może być prawie dowolna – np. mostek, most0, bridge7, br0. Uwaga. Usunięcie bridge jest możliwe tylko wtedy kiedy nie są przypisane do niego żadne interfejsy.

addif [nazwa] [iface], delif [nazwa] [iface] – odpowiednio dodanie interfejsu (portu) do bridge’a o nazwie ‘nazwa’ i jego usunięcie. Przykładowo: brctl addif br0 eth0 – to dodaje do bridge’a br0 port eth0.

showbr [nazwa] – pokazanie listy bridge’ów lub wyświetlenie ustawień jednego z nich.

showmacs [bridge] – pokazanie listy widocznych adresów sprzętowych kart (MAC) które widzi [bridge] oraz portów (kart sieciowych) przez które je widzi

Te kilka komend powyżej pozwolą nam uruchomić i kontrolować bridge’a. Jeżeli nasze karty sieciowe które chcemy włączyć do bridge’a mają już skonfigurowane adresy, należy te adresy im odebrać komendą: ifconfig eth0 0.0.0.0. W tym momencie po wyświetleniu listy interfejsów komendą ‘ifconfig’ powinniśmy widzieć karty sieciowe, ale bez przyznanych adresów IP. Cały skrypt do uruchamiania bridge’a wygląda tak:

#!/bin/sh
#
# Podnieśmy karty sieciowe.
# Oczywiście tych kart sieciowych może być więcej lub mniej (czyli dwie).
# Jeżeli ten skrypt jest już wywoływany po zainicjowaniu sieci (np. z
# rc.local) należy dopisać po każdym 'up' adres '0.0.0.0'
#

/sbin/ifconfig eth0 up
/sbin/ifconfig eth1 up
/sbin/ifconfig eth2 up

#
# Jeżeli mamy wkompilowaną obsługę bridge'a na stałe, możemy zahashować
# następną linijkę. W przeciwnym wypadku należy załadować moduł bridge.
#

/sbin/modprobe bridge

#
# Utwórzmy bridge o nazwie 'br0'.
#

/sbin/brctl addbr br0

#
# Dodajmy do bridge'a br0 karty sieciowe
#

/sbin/brctl addif br0 eth0
/sbin/brctl addif br0 eth1
/sbin/brctl addif br0 eth2

#
# Teraz przydzielmy bridge'owi adres ip, żebyśmy mogli używać serwera
# do normalnych celów
#

/sbin/ifconfig br0 up 192.168.1.1 netmask 255.255.255.0

#
# Powinno działać
#

Teraz, pakiety pomiędzy sieciami powinny przechodzić swobodnie. Jeżeli bridge został uruchomiony na komputerze robiącym maskradę, powinna ona nadal działać. Łaty na ipchains są jedynie potrzebne w momencie gdy chcemy ustawiać regułki pomiędzy sieciami (tj. zrobić przezroczystego firewalla).

A jak to zrobić w PLD? Musimy mieć kernel dystrybucyjny (2.2.20-6.2 na przykład). Tworzymy nowy plik /etc/sysconfig/interfaces/ifcfg-br0 który wygląda tak:

# Nazwa bridge'a

DEVICE=br0

# Adres IP bridge'a:

IPADDR=192.168.1.1/24

# Czy bridge ma być aktywowany podczas uruchamiania systemu:

ONBOOT=yes

# Urządzenia sieciowe które mają być częścią bridge'a:

BRIDGE_DEVS="eth0 eth1"

# Protokół STP (zalecane 'yes')

SPANNING_TREE=yes

Teraz /etc/rc.d/init.d/network restart i powinno chodzić ;). Podziękowania dla Jack’a za pomoc z bridge w PLD.

Masz dosyć spamerów? Pół europy może wysyłać przez Twojego sendmaila pocztę a Ty nie możesz tego zablokować bo masz klientów modemowych? Dobra, spróbujmy coś na to poradzić. Spróbujmy zrobić sendmaila który wymaga autoryzacji (obsługiwane przez M$ Outlook Express, Netscape Mail, TheBat! i pewnie jeszcze kilkanaście innych klientów do poczty, sprawdzane z sendmailami 8.11.* i 8.12.*). Niestety metody tylko login i plain, gdyż na pozostałe nie mam czasu.

Więcej przystępnych materiałów znajdziesz także pod adresem http://www.bloodman.one.pl/anti-spam/ u BloodMana :-)

Jeżeli czujesz się na siłach kompilować źródła i nie tylko, to zapraszam do lektury już teraz. W przypadku gdy boisz się źródeł i chcesz mieć idealny porządek w swoich pakietach rpm, zapraszam na sam dół tej strony.

Małe info dla osób które będą upgrade z sendmaila z 8.11.* do sendmaila 8.12.* – aby go zainstalować należy stworzyć w systemie konto ‘smmsp’ i grupę ‘smmsp’:

groupadd smmsp
useradd -g smmsp smmsp

1) Potrzebujemy Cyrus-SASL. W tutorialu na sendmail.org nie ma niestety opisu jak należy skompilować SASL. Znalazłem opis tego w faq o SMTP-AUTH w Postixie:

make distclean # jeżeli już kompilowaliśmy sasl
./configure --with-pwcheck --enable-login --prefix=/usr
make
make install
echo "pwcheck_method: shadow" > /usr/lib/sasl/Sendmail.conf

To powinno wystarczyć.

2) Potrzebujemy Sendmaila. Rozpakowywujemy go. Do pliku devtools/Site/site.config.m4 dopisujemy:

APPENDDEF(`confLIBDIRS', `-L/usr/lib/sasl')
APPENDDEF(`confINCDIRS', `-I/usr/include')
APPENDDEF(`confENVDEF', `-DSASL')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl')

Tworzymy plik Makefile.m4 i wpisujemy:

APPENDDEF(`confENVDEF', `-DSASL')
APPENDDEF(`conf_sendmail_LIBS', `-lsasl')

sh Build; sh Build install

Przyszykujmy plik konfiguracyjny:

cd cf/cf
cp generic-linux.mc sendmail.mc
# jeżeli chcemy wycinać spamerów, dopuszczać relaying dla konretnych IP.
cat ../feature/access_db.m4 >> sendmail.mc
# jeżeli chcemy obsługiwać wirtualne domeny na naszym serwerze
cat ../feature/virtusertable.m4 >> sendmail.mc
# jeżeli chcemy aby nasz sendmail pracował jako zapasowy mx
cat ../feature/mailertable.m4 >> sendmail.mc

Do pliku sendmail.mc dopisujemy:

define(`confAUTH_MECHANISMS',`LOGIN PLAIN')dnl
TRUST_AUTH_MECH(`LOGIN PLAIN')dnl

Kompilujemy plik cf:

sh Build sendmail.cf
sh Build install-cf
killall -9 sendmail
sendmail -bd -q15m

Te dwie ostatnie linijki to kolejno ubicie sendmaila i jego ponowne uruchomienie. Posiadacze redhatów, mandarynek i podobnych piszą grzecznie ‘/etc/rc.d/init.d/sendmail restart’ i widzą dwa ładne zielone napisy [ OK ].

UWAGA!!!

Często po instalacji sendmaila możecie mieć problemy z dostępem do kolejki, tj, sendmail normalnie udostępnia relaying, wysyła pocztę ale np. nie działają programy mail czy tez pine. Problem tutaj leży w prawach dostępu do katalogów kolejki, binarki sendmaila i jego plików konfiguracyjnych. Powinny one wyglądać tak

-r-xr-sr-x   1 root     smmsp      584057 Oct  1 21:37 /usr/sbin/sendmail
drwxrwx---   2 smmsp    smmsp         419 Dec 29 02:48 /var/spool/clientmqueue/
drwx------   2 root     wheel          35 Dec 29 02:48 /var/spool/mqueue/
-r--r--r--   1 root     wheel       55713 Dec 29 02:44 /etc/mail/sendmail.cf
-r--r--r--   1 root     wheel       38707 Dec 29 02:42 /etc/mail/submit.cf

Więc jeżeli nie masz pewności co do praw dostępu do tych plików, po instalacji wykonaj:

chown root.smmsp /usr/sbin/sendmail
chmod 2555 /usr/sbin/sendmail
mkdir -p /var/spool/clientmqueue
chown smmsp.smmsp /var/spool/clientmqueue
chmod 770 /var/spool/clientmqueue
chown root.wheel /var/spool/mqueue
chmod 700 /var/spool/mqueue
chown root.wheel /etc/mail/sendmail.cf
chown root.wheel /etc/mail/submit.cf
chmod 444 /etc/mail/sendmail.cf
chmod 444 /etc/mail/submit.cf

Jeżeli w naszym systemie nie ma grupy ‘wheel’, spokojnie można użyć root.root.

Warto by było sprawdzić czy autoryzacja działa. Robimy coś takiego: printf ‘user\0user\0hasło’|mimencode, gdzie user i hasło to faktyczny login i hasło konta na serwerze:

$ printf 'lukasz\0lukasz\0ljm300fpqa'|mimencode
bHVrYXN6AGx1a2FzegBsam0zMDBmcHFh
$ telnet 0 25
Trying 0.0.0.0...
Connected to 0.
Escape character is '^]'.
220 home.baseciq.org ESMTP Sendmail 8.12.3/8.12.3; Fri, 13 Apr 2001 23:18:42 +0200
HELO localhost
250 home.baseciq.org Hello baseciq@localhost [127.0.0.1], pleased to meet you
AUTH PLAIN bHVrYXN6AGx1a2FzegBsam0zMDBmcHFh
235 2.0.0 OK Authenticated
QUIT
221 2.0.0 home.baseciq.org closing connection
Connection closed by foreign host.
$

I po bólu ;-). Na koniec warto przerobić pliki access i virtusertable. Byłbym zapomniał, jeżeli dorzucimy podczas tworzenia configa access_db.m4 i virtusertable.m4 to sendmail nie będzie chciał działać bez plikóe /etc/mail/access.db i /etc/mail/virtusertable.db. Jeżeli chcesz mieć te funckje na przyszłość, ale tymczasowo nie wiesz co do tych plików wpisać, to poprostu zostaw je puste / utwórz je komendą touch. Stworzenie nowych baz access i virtusertable wykonuje się tak:

cd /etc/mail
rm access.db alises.db virtusertable.db
/usr/sbin/makemap hash access < access
/usr/sbin/makemap hash virtusertable < virtusertable
/usr/bin/newaliases

Jako że nie mam ochoty robić oddzielnego działu o konfiguracji sendmaila napiszę tutaj pokrótce jak powinny wyglądać powyższe pliki.

aliases

Jest to plik z aliasami systemowymi, w formacie user: faktycznyuser. Np. root: baseciq – to oznacza że poczta na root’a niezależnie od domeny idzie na konto baseciq. Alias może wskazywać na inny alias, na przykład webmaster: root, a później root: user. Standardowo powinny być w tym pliku takie wpisy:

MAILER-DAEMON:  postmaster
postmaster:     root
# Przekierowania dla kont systemowych:
bin:	root
daemon:	root
games:	root
ingres:	root
nobody:	root
system:	root
toor:	root
uucp:	root
# Powszechnie znane aliasy:
manager:	root
dumper:	root
operator:	root
decode:	root
abuse:	root
# Osoba która powinna otrzymywać pocztę dla root'a.
root:	someuser

Po jego edycji należy uruchomić komendę ‘newalises’.

access

Plik ten dopuszcza bądź zabrania dostępu konkretnym hostom, domenom, adresom pocztowym do relayingu bądź dostępu do serwera. Może również dopuszczać konkretne domeny lub hosty do relayingu, ale po co kiedy właśnie przed chwilą zrobiłeś autoryzację ? :^). Przykładowy plik:

# dwie sieci lan - 192.168.1.* i 192.168.4.* mogą wysyłać przez nas pocztę
192.168.1	RELAY
192.168.4	RELAY
# a ten oto pacjent nam wysyła jakiś spam:
from:misiek72123@kki.net.pl	ERROR:"550 We don't accept mail from spammers"

# tutaj takie jedno sdi nam wysyła śmieci więc też je wytnijmy:
px666.warszawa.sdi.tpnet.pl	ERROR:"550 We don't accept mail from spammers"
# o, właśnie Ci się przypomniało że z free.net.pl też są sami spamerzy,
# więc wytnijmy ich domenę ;-)
from:free.net.pl	ERROR:"550 We don't accept mail from spammers"

Typów wpisów tutaj może być wiele, polecam więc lekture dokumentacji (ja sam tych wpisów dobrze nie znam). Po modyfikacji tego pliku generujemy ponownie bazę danych przy pomocy ‘makemap hash access < access’.

virtusertable

Cytuje za virtusertable.sample: Plik ten mapuje jednego lub wszystkich użytkowników z danej domeny do podanego (lub tego samego) użytkownika na innej maszynie. Pamiętaj o dodaniu danej domeny do /etc/mail/local-host-names aby sendmail akceptował pocztę dla danej domeny. Przykładowy plik wygląda tak:

# Poczta dla uzytkownik@przykladowa.domena.pl jest dostarczana
# lokalnemuuzytkownikowi
uzytkownik@przykladowa.domena.pl	lokalnyuzytkownik
# Poczta dla uzytkownik2@przykladowa.domena.pl jest przesylana
# do ktostam@gdzies.pl
uzytkownik2@przykladowa.domena.pl	ktostam@gdzies.pl
# cala poczta dla domeny cala.domena.pl trafia na konto lokalnyuser
@cala.domena.pl	lokalnyuser
# poczta dla domeny inna.domena.pl jest przesylana do misio@gdzies.pl
@inna.domena.pl	misio@gdzies.pl
# poczta dla domeny jeszcze.inna.pl jest forwardowana do takiego samego
# uzytkownika w domenie tam.dalej.pl, np.:
# jan.kowalski@inna.domena.pl jest przesylane do jan.kowalski@tam.dalej.pl
@jeszcze.inna.pl	%1@tam.dalej.pl

mailertable

Plik ten służy do informowania gdzie sendmail relayować pocztę dla konkretnych domen. Aby sendmail działał jako zapasowy mx, do access dopisujemy: ‘domena.pl RELAY’, oraz dopisujemy go do mailertable:

domena.pl		SMTP:mx0.domena.pl

Ta linijka informuje sendmaila że pocztę adresowaną do domena.pl należy przekazać do hosta mx0.domena.pl. Równie dobrze można wpisać np. ‘SMTP:10.2.3.4′. Jak można to wykorzystać? Ustawiamy że podstawowym mxem dla domeny jest nasz serwer, a później go konfigurujemy żeby pocztę przesyłał do komputera w lanie. Oczywiście komputer w lanie musi mieć skonfigurowanego sendmaila lub inny demon pocztowy (np. Postfix, Qmail pod Linuxa, lub Mdaemon pod windows).

Uf… Pokręcone, prawda ? :^). Po modyfikacji tego pliku robimy ‘makemap hash virtusertable < virtusertable’. Uf. Done ;).

A teraz z pakietów…

Parę dni temu zostałem namówiony do instalacji u siebie PLD co uczyniłem i oczywiście odrazu na pierwszy rzut poszła instalacja podstawowych rzeczy z których musiałbym korzystać gdyby kiedyś mnie naszła ochota na postawienie serwera na tej dystybucji w pracy. Nie będę się rozpisywał o samej dystrybucji (slackware i tak rulez ;>>), która uważam jest jedną z lepszych i ciekawszych dystrybucji, a o samym sendmailu.

Spodziewałem się najgorszego, iż będę musiał kompilować przynajmniej sendmaila ale zostałem mile zaskoczony. Próba apt-get install sendmail poinformowała mnie grzecznie iż wymagany jest cyrus-sasl co z przyjełem z radością. Generalnie PLD jest wstępnie przygotowane do takowego zabiegu jak SMTP+AUTH a jedyne co trzeba to instalacja odpowiednich pakietów którymi są:

sendmail
cyrus-sasl

cyrus-sasl-login
cyrus-sasl-plain
cyrus-sasl-saslauthd (wymagany w przypadku sendmaila-8.12.9)

Po instalacji tych czterech pakietów pozostaje nam modyfikacja pliku /etc/mail/sendmail.mc.

Zamiast:

TRUST_AUTH_MECH(`PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5')
define(`confAUTH_MECHANISMS',`PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5')

Musi być:

TRUST_AUTH_MECH(`LOGIN PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5')
define(`confAUTH_MECHANISMS',`LOGIN PLAIN GSSAPI KERBEROS_V4 DIGEST-MD5 CRAM-MD5')

Uwaga! Zmiany te były w potrzebne w czasach sendmaila 8.12.2 (o ile dobrze pamiętam) i w stabilnej wersji PLD-1.0-Ra zostały już przeze mnie wprowadzone.

Wpisy te znajdują się w okolicach 23 linijki tegoż pliku. Poprostu należy dodać LOGIN jako jeden z mechanizmów autoryzacji. Po dokonaniu zmian w pliku sendmail.mc generujemy nowe sendmail.cf:

m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

Po tych zabiegach pozostaje tylko wpisać /etc/rc.d/init.d/sendmail restart i korzystać.

DNS jest systemem hierarchicznym – jak to wytłumaczyć hmmm… Są domeny główne – tzw. Top Level Domain’s – domeny najwyższego poziomu (chyba to będzie dobre tłumaczenie). TLD to jest np. ‘com’ (komercyjne), ‘net’ (networks – sieci), czy też ‘pl’ (polska) albo ‘de’ (niemcy). Są to domeny z góry określone przez odpowiednie postanowienia i są opisane w odpowiednich dokumentach, ale to nie tutaj będę o tym pisał. W TLD’s są poddomeny, np. com.pl, wp.pl, wiosenna.com (:->) czy też ahead.de. W poddomenach mogę być kolejne poddomeny albo hosty – np. slayer.wiosenna.com. I tak w kółko. Ale nie przejmuj się jak tego nie rozumiesz, przyjdzie Ci z czasem :-).

Konfiguracja DNS (Bind 8/9)

Według wszelakich norm, każda domena powinna mieć dwa nameservery – podstawowy i zapasowy. Podstawowy posiada wszelakie informacje o domenie, na nim dopisujemy hosty i wszelakie ustawienia, a poprawnie skonfigurowany zapasowy poprostu transferuje sobie plik strefy do siebie i go przechowuje wspomagając tego pierwszego.

/etc/named.conf

Jest to główny plik konfiguracyjny Binda 8.x/9.x – w tym pliku ustawiamy katalog w którym są pliki stref, nazwy domen jakie nasz dns utrzymuje. Plik ten wygląda mniej więcej tak:

options {        directory "/var/named";        // query-source address * port 53;};
zone "." {
        type hint;
        file "named.ca";
};
zone "0.0.127.in-addr.arpa" {
        type master;
        file "named.local";
};

Jak widać najpierw jest sekcja options – standardowo definiuje katalog /var/named (w PLD /var/lib/named – gdyż tam named jest chrootowany) aby był domyślnym katalogiem ze strefami. Później jest zdefiniowana strefa ‘.’ – wytłumaczenie tej strefy opiszę za parę dni – w każdym bądź razie plik /var/named/named.ca (named.ca jest zdefiniowane w sekcji zone – file „named.ca”, katalog wyżej, w options) musi się znajdować aby bind poprawnie działał. Czasami ma on nazwę root.cache, albo samo cache. Następny wpis to wpis domeny odwrotnej (rDNS) dla 127.0.0.* – czyli dla localhosta.

Ok, więc dopiszmy teraz jakąś domene. Zakładam że ona już jest wydelegowana na Twój nameserver i jest to podstawowy nameserver, a zapasowy użyczył Ci administrator z Twojej uczelni albo jakoś tak ;) Więc piszemy:

zone "naszadomena.pl" {
	type master;
	file "naszadomena.pl";
	allow-transfer { 213.25.209.97; };
	notify yes;
};

Pokoleji opisuje jeszcze raz co oznacza co:
- zone „naszadomena.pl” – to oznacza że ten wpis w configu będzie się odnosił do domeny naszadomena.pl;
- file „naszadomena.pl” – to oznacza że wszystkie wpisy co do tej domeny będą w pliku naszadomena.pl w katalogu /var/named – katalog ten ustawia się na samym początku configu;
- allow-transfer {ldelim} 213.25.209.97; {rdelim} – tutaj zamiast 213.25.209.97 wpisujemy adresy IP zapasowego serwera DNS; – notify yes – ta opcja włącza powiadamianie zapasowego serwera DNS o tym że zmieniliśmy jakieś wpisy w naszej domenie.

Teraz plik /var/named/naszadomena.pl…

Zaczynamy edycję. Tak w ramach uprzedzenia – wszystkie wpisy w plikach stref poprzedzone średnikami ‘;;’ są ignorowane i traktowane jako komentarz, więc postanowiłem na żywo komentować co oznaczają poszczególne wpisy. Będąc przy okazji katalogów – w PLD wszystkie pliki domen primary znajdują się w katalogu /var/lib/named/M a secondary w /var/lib/named/S. Takie są założenia nameda w PLD i warto się ich trzymać (czytaj: pamiętać o tym przy wpisach zone w named.conf ;)). Generalnie rekordy w takim pliku mają postać: [rekord] IN [typ] wartosc

Typy wpisów, najczęściej stosowane to:

- A – wpis wskazujący na adres IP – czyli że dany host w domenie ma podany adres IP:

komp1	IN	A	192.168.1.1

- NS – wpis informujący o tym że dany fragment domeny jest obsługiwany przez konkretne serwery DNS:

poddomena	IN	NS	dns1.jakasfirma.pl.
poddomena	IN	NS	dns2.jakasfirma.pl.

I tutaj mała uwaga. Jeżeli wpis dotyczy jakiegoś hosta w naszej domenie, np. tak jak przy przykładzie wpisu IN A użyłem hosta komp1, to domyślnie jest doklejana jest nazwa domeny do hosta, inaczej mówiąc jeżeli robimy wpis komp1 IN A 192.168.1.1 w pliku domeny naszadomena.pl, to w tym momencie przypisalismy nazwie komp1.naszadomena.pl adres IP 192.168.1.1. Natomiast jak widzicie na przykładzie rekordu IN NS na końcu dns*.jakasfirma.pl dodałem kropki. Dlaczego? Bo jak bym wpisał dns1.jakasfirma.pl bez kropki, to w tym momencie Bind dokleiłby na końcu dns*.jakasfirma.pl nazwe naszej domeny i przykladowo efekt bylby taki ze poddomena.naszadomena.pl jest obsługiwana przez dns*.jakasfirma.pl.naszadomena.pl ;-). Więc pamiętaj o tych kropkach jeżeli wpis jest spoza domeny. Tak btw. to przy wpisie komp1 można równierz wpisać komp1.naszadomena.pl. IN A 192.168.1.1, ale po co jeżeli można prościej samo komp1 ;-). Nadążasz? To dobrze, ja też nie, jest 4:15 nad ranem i sam się dziwie że jeszcze chce mi się kończyć ten tekst. Dobra. Jedziemy dalej ;-).

- MX – wpis informujący jaki serwer trzyma pocztę dla danej (pod)domeny:

poczta	IN	MX	5	listonosz

Taki wpis oznacza że wszystkie maile w formie użytkownik@poczta.naszadomena.pl będą kierowane na komputer który się zowie listonosz.naszadomena.pl. Oczywiście musimy mu jakiś adres IP przydzielić pisząc np. listonosz IN A 217.8.186.23. Ta cyferka między MX a listonosz definiuje priorytet z jakim ma być używany serwer listonosz.naszadomena.pl. Możemy naprzykład zdefiniować dwa serwery do poczty:

poczta	IN	MX	5	listonosz
poczta	IN	MX	10	poczta.jakasdomena.pl.

Efekt takiego wpisu jest taki, że jeżeli listonosz.naszadomena.pl sobie padnie, to w tym momencie cała poczta jest puszczana do poczta.jakasdomena.pl. Oczywiście obydwa serwery muszą być poprawnie skonfigurowane, a poczta.jakasdomena.pl powinna być wysyłana na listonosz.naszadomena.pl gdy ten powróci do życia. Ale tego zdeydowanie w bindzie się nie skonfiguruje tylko gdzie indziej. Jeżeli masz tylko jeden serwer pocztowy poprostu wpisz jeden z numerkiem np. 10.

- CNAME – tzw. alias:

www	IN	CNAME	superserwer
ftp	IN	CNAME	ftp.uczelnia.pl.

tak więc www.naszadomena.pl to alias dla superserwer.naszadomena.pl. Natomiast jak ktoś wbije się na ftp.naszadomena.pl to defacto połączy się z ftp.uczelnia.pl – tam jest dosyć duże i ładne archiwum niech tam sobie ludzie szukają ;-). I znowu uwaga co do kropek!

Te cztery wpisy są najczęściej używane. Do tego dochodzi jeszcze rekord SOA, ale o nim napiszę już poniżej, w przykładowym pliku sterfy:

$TTL 86400
$ORIGIN naszadomena.pl.

;; Te dwie linijki oznaczają jaki ma być domyślny czas
;; ważności rekordów w sekundach, oraz jaką domenę opisujemy.
;; 86400 = 1 dzień. Są to informacje dla bind'a które określają
;; co ma doklejić do rekordu jeżeli na jego końcu nie ma '.'

@	IN	SOA	naszserwer.pl. root.naszadomena.pl. (

;; Start Of Authority czyli rekord SOA - opisuje on kto
;; zarządza naszą domeną (root@naszadomena.pl) oraz czasy
;; ważności wpisów w domenie, odświeżania i
;; numer seryjny domeny. Zamiast @ w adresie e-mail
;; (root.naszadomena.pl) należy wpisać '.'! Podobnie znak
;; '(' jest konieczny gdyż na tym rekord SOA się nie kończy.
;; A co oznacza to @ na początku? '@' znaczy iż rekord
;; dotyczy naszadomena.pl samej w sobie.
;; Pierwsze pole (naszserwer.pl) oznacza iz pod tym adresem
;; znalezc mozna glowny DNS tej domeny - wpisuje sie tam nazwe
;; Primary DNS.

2001052501

;; Numer seryjny domeny - powinien być przy każdej modyfikacji
;; pliku strefy zwiększany, a w dobrym tonie jest utrzymywanie
;; go w formacie YYYYMMDDnn - czyli rok, miesiąc, dzień i
;; i numer modyfikacji danego dnia o ile jest to któraś
;; z koleji modyfikacja danego dnia

1200

;; refresh - To pole rekordu SOA definiuje jak często serwery
;; slave mają sprawdzać czy dane o domenie zmieniły się na
;; masterze. Według RFC, wartość ta powinna się zawierać
;; pomiędzy 1200 a 43200 (czyli od 20 minut do 12 godzin).
;; W praktyce, najlepsza wartość to 3600-7200 sekund.

1200

;; retry - Tutaj ustawiamy po jakim czasie secondary ma ponowić
;; próbę kontaktu z masterem gdy taka się nie powiedzie.
;; Zalecana wartość to 120-7200 sekund.

2419200

;; expire - Ta wartość określa po jakim czasie dane domeny mają
;; zostać uznane za nieaktualne gdy secondary nie będzie mógł
;; się dobić do primary dns'a. Zalecana wartość to od 1209600
;; do 2419200 sekund (od 2 do 4 tygodni).

86400 )

;; time-to-live - czyli TTL. Określa ile czasu informacja o
;; każdym rekordzie ma być ważna, czyli ile czasu nameserver
;; który gdzieś po drodze zcacheował jakiś rekord z naszej
;; domeny ma go pamiętać. Zalecana wartość to 86400 - 432000
;; (1 do 5 dni). Na końcu tego pola znajduje się znak ')'
;; oznaczający rekord SOA.

@	IN	NS	naszserwer.pl.
@	IN	NS	czyjsdns.innasiec.pl.

;; Tutaj zdefiniowalismy że domene obsługują w/w serwery dns.
;; No dobrze, a jak nasz komputer nie ma żadnej domeny jeszcze,
;; albo chcemy mieć ładne wpisy dns1.naszadomena.pl i
;; dns2.naszadomena.pl ? Osoba która nam wydelegowała domene
;; (w przypadku .pl to jest nask ale o tym poniżej)
;; prawdpopdobnie wzieła od nas adresy IP i odrazu je
;; definiowała ale my też powinniśmy to wpisać w taki sposób:
;;
;;	@	IN	NS	dns1
;;	@	IN	NS	dns2
;;	dns1	IN	A	192.168.1.1
;;	dns2	IN	A	192.168.1.2
;;
;; Oczywiście te adresy IP to nasz adres i adres zapasowego
;; DNS'a.

;; definiujemy że poczta@naszadomena.pl obsługiwana jest przez
;; serwer mail.naszadomena.pl:

@	IN	MX	10	mail

;; który musimy oczywiście jakoś stworzyć:

mail	IN	A	192.168.1.3

;; natomiast poczta@poczta.naszadomena.pl ma iść na serwer
;; mail2.naszadomena.pl:

poczta	IN	MX	5	mail2

;; chyba że mail2 padnie to wtedy ma iść na serwer mail:

poczta	IN	MX	10	mail

;; definiujemy jeszcze tylko mail2 (mail już wyżej
;; zdefiniowaliśmy):

mail2	IN	A	192.168.1.4

;; Generalnie chcemy aby przy użyciu naszadomena.pl był
;; podawany taki adres IP:

@	IN	A	192.168.1.10

;; będzie to nasz serwer www, więc dajmy mu takowy wpis:

www	IN	A	192.168.1.10

;; Jest to poprawne - kilka domen/hostów może wskazywać na
;; dany adres IP... Stwórzmy jeszcze wpisy na komputery w
;; naszej sieci:

komp1	IN	A	192.168.1.101
komp2	IN	A	192.168.1.102
komp3	IN	A	192.168.1.103
komp4	IN	A	192.168.1.104
komp5	IN	A	192.168.1.105

;; No tak, znajomemu się bardzo nazwa naszej domeny
;; spodobała i chciałby sobie cosik w niej pomajstrować,
;; więc wydelegujmy mu poddomene, która będzie obsługiwana
;; przez jego serwer DNS:

znajomy	IN	NS	znajomy.pl.

;; i zapasowy damy mu u siebie:

znajomy	IN	NS	dns

;; i przydzielmy hostowi dns.naszadomena.pl w końcu jakiś
;; adres:

dns	IN	A	192.168.1.7

;; Zróbmy jeszcze wpis ftp.naszadomena.pl. W sumie to więcej
;; oprogramowania jest u nas na uczelni i niech tam sobie
;; ludziki grzebią ;)

ftp	IN	CNAME	ftp.uczelnia.edu.pl.

;; Uf... To już chyba wszystko. Możemy zapisać plik z naszą
;; domeną.

Ok, domena stworzona, trzeba teraz uruchomić nasz serwer DNS. Jeżeli jest już uruchomiony, wystarczy poprostu rozkazać mu przeładować konfiguracje. Robi się to na kilka sposobów:
- komendą named.reload – spowoduje to wywołanie skryptu zmuszającego binda do przeładowania konfiguracji;
- komendą killall -HUP named – efekt ten sam jak wyżej;
- /etc/rc.d/init.d/named reload – efekt ten sam jak wyżej, komenda zadziała na RedHat’ach, Mandrake’ach i tym podobnych (nie wiem jak SuSe i Debian – jak ktoś by mógł mnie uświadomić…)
- /etc/rc.d/init.d/named restart – spowoduje to zatrzymanie pracy binda (o ile chodził już) i jego ponowne uruchomienie.

Jeżeli bind nie uruchamia się automatycznie podczas startowania sewera to są 3 sposoby na zmuszenie go do pracy:
- W Slackware modyfikacja pliku /etc/rc.d/rc.inet2;
- W RH, MDK, PLD, Gentusie, prawdopodobnie SuSE i podobnych: chkconfig –level 345 named on;
- echo „/usr/bin/named -u nobody -g nobody” >> /etc/rc.d/rc.local – metoda nieestetyczna ale skuteczna ;-). W tym momencie trzeba zmienić właścieciela katalogu bind’a: chown nobody.nobody /var/named (lub inny katalog ustalony w /etc/named.conf).

Jeżeli chcemy zmodyfikować jakiś wpis w domenie zmieniamy numer seryjny w pliku strefy przy każdej zmianie. Na tej podstawie serwery DNS rozpoznają.

Zapasowy DNS

A jeżeli chcemy postawić zapasowy DNS? To już jest o wiele prostsze. Wystarczy że ktoś wpisze adres IP w allow transfer w /etc/named.conf i w tym momencie nasz dns ma prawo tranferu sterfy. W tym momencie należy wykonać następujący wpis w /etc/named.conf na secondary dns:

zone "naszadomena.pl" IN {
        type slave;
        file "naszadomena.pl";
        masters { 195.116.163.58; };
};

W polu masters ustawiamy adres IP podstawowego DNS’a. Należy się upewnić czy użytkownik z którego pracuje bind (ps -aux|grep named) ma prawa do zapisu w katalogu z plikami stref. Po paru chwilach od wykonania killall -HUP named powinniśmy mieć w katalogu ze strefami ściągnięty plik strefy. Oczywiście zasady tworzenia strefy na podstawowym NS’ie są takie same jak opisałem powyżej.

Obydwa NS’y na jednym serwerze

Jeżeli posiadamy dwa adresy IP na jednym hoście możemy dns’a skonfigurować w taki sposób że on sam obsługuje odstawowy dns:

@	IN	NS	dns1.naszadomena.pl.
@	IN	NS	dns2.naszadomena.pl.
dns1	IN	A	192.168.1.30
dns2	IN	A	192.168.1.31

Oczywiście 192.168.1.30 i 31 to nasz serwer. W tym momencie ustawiamy opcje allow-transfer na none w /etc/named.conf i konfigurujemy dns’a tak jakby był to podstawowy dns.

Uf… No to w sumie by było na tyle. Mam nadzieje że o niczym nie zapomniałem. Uwagi mile widziane. Wszystko opisałem najprościej jak się dało – jeżeli nie rozumiesz tego co napisałem nie męcz mnie – nie mam nic więcej do powiedzenia w temacie DNS ;-)…

Uwaga! Tekst ten proszę traktować jako swoisty proof-of-concept i proszę, nie opierajcie na nim systemów produkcyjnych. Jeżeli zbudujecie na podstawie mojego opisu dokładnie go przetestujecie. Generalnie rozwiązania podane poniżej u mnie działają, ale nie gwarantuje że jest to wszystko bezpieczne i bezbłędne. Jeżeli tekst mój przyda się w budowie porządnego systemu zarządzania kontami mail, mam nadzieję że zostanie on udostępniony na licencji GPL.

Jestem absolutnie świadom że poniżej opisane rzeczy można zrobić dwadzieścia razy lepiej, estetyczniej, sprawniej, bezpieczniej i w ogóle cudownie. To ma być jedynie metoda na nauczenie kogoś jak to się robi!

Masz 300 użytkowników którzy korzystają tylko z poczty i sądzisz że nie potrzebują oni dostępu do shella? A może uważasz za upierdliwe logowanie się na ssh i zmiana parametrów konta? A może poprostu jesteś leniwy i chciałbyś aby to wsio było kilkane? :) Oki. Postaramy się coś z tym zrobić.

Główną ideą rozwiązania które będę wam tłumaczył jest to, żeby konta tylko pocztowe były kontami wyłącznie pocztowymi. Po co? Takich kont może być maksymalnie 65*1024. Dla większości jest to liczba wręcz przerażająco wielka. Dla średniej wielkości ISP jest to liczba raczej mała. Osobiście nie potrzebowałem obsługi nawet 100 kont, ale ilość kont to nie jedyna zaleta. Oparcie konfiguracji na bazie danych MySQL pozwola na łatwą integracje z innymi usługami opartymi na tej bazie danych, a co najważniejsze, łatwe tworzenie aplikacji internetowych w PHP do zarządzania tym systemem.

Założenia

- osoba która to instaluje ma mózg i go używa do myślenia a nie jako grzechotkę;
- posiadasz jakąś wiedzę o MySQL, umiesz tworzyć zapytania, wiesz czym się różni kolumna od tabeli i tabela od bazy;
- umiesz skompilować i zainstalować exima z MySQL’em – ten tekst napewno tych czynności nie opisze;
- Exim 4.x (testowane na 4.12 zbudowanym z CVS’u PLD)

Tak więc masz już Exima i MySQL’a odpalone. Zacznijmy od podstaw – czyli skonfigurowania połączenia do bazy. W głównej sekcji configa (np. na samej górze) dopisujemy:

hide mysql_servers = "localhost/poczta/mysql/haslo"

Gdzie localhost to każdy chyba wie co to znaczy, poczta to nazwa bazy danych, mysql to konto użytkownika MySQL a haslo to hasło ;) Zacznijmy od podstaw, czyli listy domen jakie ma nasz exim obsługiwać jako lokalne. Utwórzmy prostą tabelę zawierającą jedną kolumnę z nazwą domeny:

CREATE TABLE domeny (nazwa VARCHAR(64) NOT NULL);

Każda domena wpisana do tej tabeli będzie traktowana przez exima jako domena lokalna. Aby taką zachciankę wprowadzić w życie nauczmy exima korzystać z tej tabeli. Za listę domen które exim ma traktować jako lokalne służy opcja domainlist local_domains:

domainlist local_domains = @ : ${lookup mysql {SELECT nazwa FROM domeny WHERE nazwa="${domain}"}}

Znak @ oznacza w tej liście podstawowy hostname maszyny – czyli jeżeli nasza maszyna nazywa się "pepsi.netx.waw.pl" to poczta dochodząca do domeny pepsi.netx.waw.pl będzie przez exima traktowana jako lokalna. Jeżeli już Cię zżera ciekawość czy to działa, dodaj do mysql’a jakąś domenę:

INSERT INTO domeny (nazwa) VALUES ('dupa.pl');

Po takim zabiegu można odrazu spróbować wysłać pocztę na jakieś konto na naszym serwerku w domenie dupa.pl :) Tak więc domeny już mamy. Teraz trzeba jakoś zrobić skrzynki pocztowe. Stwórzmy zatem tabelę trzymającą dane o kontach:

CREATE TABLE skrzynki (nazwa VARCHAR(32) NOT NULL, domena VARCHAR(64) NOT NULL);

Następnym krokiem to znowu nauczenie exima korzystania z tej tabeli. W sekcji ROUTERS CONFIGURATION (czyli po ‘begin routers‘) dopisujemy nowy ‘router’. Ważna tutaj jest kolejność wpisów. Dopisanie nowego routera przed standardowymi ‘system_aliases’, ‘userforward’ i ‘localuser’ spowoduje to, iż exim najpierw będzie sprawdzał czy istnieje użytkownik w bazie danych i jeżeli nie dopiero po tym czy istnieje ‘prawdziwe’ takie konto. Tak więc tworzymy nowy router, najlepiej zaraz po routerze dnslookup:

mysql_localuser:
	driver = accept
	domains = +local_domains
	condition = ${if eq{}{${lookup mysql {SELECT nazwa FROM skrzynki WHERE \
		nazwa='${local_part}' AND domena='${domain}'}}}{no}{yes}}
	transport = mysql_delivery
	no_more

Jako transport (czyli określenie co odpowiada za dostarczenie poczty) określiliśmy mysql_delivery które zaraz również utworzymy. Istotną wadą powyższego wpisu jest także to, że będzie on także obejmował domeny ‘prawdziwe’, tj. te które nie są w bazie, co może nie każdemu adminowi odpowiadać. Aby to poprawić wracamy się do domainlist local_domains i tworzymy dodatkową listę domen:

domainlist mysql_local_domains = ${lookup mysql {SELECT nazwa FROM domeny WHERE nazwa="${domain}"}}

Teraz, w mysql_localuser zmieniamy tylko domains = +local_domains na domains = +mysql_local_domains. Kolejnym krokiem jest zdefiniowanie transportera (można to wytłumaczyć jako ‘urządzenie dostarczające pocztę’). Przed dopisaniem transportera, musimy zdecydować gdzie chcemy trzymać pocztę – czy w jakimś konkretnym katalogu, np. ‘/var/mail/virtual/nazwa_domeny/nazwa_skrzynki, czy np. chcemy katalog określić w bazie danych. Ja ograniczę się narazie do pierwszego rozwiązania. Odnajdujemy begin transports i dopisujemy:

mysql_delivery:
	driver = appendfile
	file = /var/mail/virtual/${domain}/${local_part}
	delivery_date_add
	envelope_to_add
	return_path_add

Jak widzicie w tej sekcji nie ma żadnego zapytania MySQL. Dlaczego? Otórz mysql_local_domains które zdefiniowaliśmy wcześniej sprawdza czy konto w domenie i domena istnieją. Tak więc jeżeli chcemy dostarczać pocztę do normalnych skrzynek pocztowych w formacie BSD (czyli takich jakie są w /var/spool/mail) tylko że w podkatalogach mających taką samą nazwę jak domena to nie potrzeba nic z MySQL’a pobierać. Tak więc zapisujemy zmodyfikowany plik konfiguracyjny, restartujemy exima i sprawdzamy co nam z tego wyszło :) Stwórzmy w MySQL’u domenę i konto w niej:

INSERT INTO domeny (nazwa) VALUES ('poczta.test');
INSERT INTO skrzynki (nazwa, domena) VALUES ('testowekonto','poczta.test');

Wysyłamy maila:

$ mail testowekonto@poczta.test -s "wiadomosc testowa" < /dev/null
Null message body; hope that's ok

Teraz po zajrzeniu do katalogu /var/mail/virtual/poczta.test ujrzymy pliczek testowekonto :) Oczywiście jest to bardzo proste dostarczanie. Nie ma na przykład jeszcze aliasów. Tak więc dodajmy kolumnę ‘alias’ do tabeli z userami. Zasada działania będzie taka, że jeżeli przy jakimś koncie w tej tabeli zostanie dopisany alias, to exim przekieruje pocztę na zawartość kolumny alias. Zmodyfikujmy więc tabelę dodając do niej kolejną kolumnę:

ALTER TABLE skrzynki ADD alias VARCHAR(64) DEFAULT '' NOT NULL;

Aby exim umiał korzystać z tych aliasów, należy zmodyfikować router mysql_localuser aby nie dostarczał poczty jeżeli istnieje coś w kolumnie alias (prosta zmiana w kwerendzie sql’a) oraz żeby dostarczał aliasy. Modyfikujemy więc mysql_localuser oraz dopisujemy przed nim router mysql_alias:

mysql_alias:
	driver = redirect
	domains = +mysql_local_domains
	allow_fail
	allow_defer
	data = ${lookup mysql {SELECT alias FROM skrzynki WHERE nazwa='${local_part}' \
	AND domena='${domain}' AND alias!='' AND alias!=CONCAT('${local_part}@','${domain}')}}

mysql_localuser:
	driver = accept
	domains = +mysql_local_domains
	condition = ${if eq{}{${lookup mysql {SELECT nazwa FROM skrzynki WHERE \
	nazwa='${local_part}' AND domena='${domain}' AND alias=''}}}{no}{yes}}
	transport = mysql_delivery
	no_more

Kwestii wyjaśnienia – te kombinacje z CONCATem mają na celu zapobiegnięcie sytuacji gdy konto ‘cos’ w domenie ‘domena.pl’ będzie wskazywało przez alias na ‘cos@domena.pl’ :) Przetestujmy to ‘udogodnienie’, dodając aliasa do bazy:

INSERT INTO skrzynki (nazwa, domena, alias) VALUES ('testalias','poczta.test','testowekonto@poczta.test');

Spróbujmy teraz wysłać maila pod adres testalias@poczta.test. Warto zauważyć, że exim bezbłędnie sobie poradzi, jeżeli komplet nazwa+domena będzie występował podwójnie wskazując na dwa różne aliasy – poprostu dostarczy maila do dwóch aliasów. Jeżeli natomiast będą istnieć aliasy dla jakiegoś konta, oraz będzie normalne konto bez aliasu, to poczta zostanie dostarczona tylko na aliasy, podobnie jak normalne aliasy np. w takim sendmailu. Kolejnym ‘feature’ będą aliasy domenowe. Co to ma być? Poprostu np. wysyłamy maila na adres konto@poczta.test, a adres jest przepisywany jako konto@innadomena. Ta ‘innadomena’ może być równie dobrze domeną lokalną, wirtualną, bądź domeną na zupełnie innym serwerze. Zmodyfikujmy więc tabelę z domenami:

ALTER TABLE domeny ADD alias VARCHAR(64) DEFAULT '' NOT NULL;

Zmodyfikujmy mysql_local_domains tak aby wskazywał na domeny które nie są aliasami, oraz utwórzmy listę mysql_alias_domain:

domainlist mysql_local_domains = ${lookup mysql {SELECT nazwa FROM domeny WHERE nazwa="${domain}" AND alias=''}}
domainlist mysql_alias_domains = ${lookup mysql {SELECT nazwa FROM domeny WHERE nazwa="${domain}" AND alias!=''}}

Dodajmy przed routerem mysql_alias kolejny router, mysql_domainalias:

mysql_domain_alias:
	driver = redirect
	domains = +mysql_alias_domains
	allow_fail
	allow_defer
	data = ${lookup mysql {SELECT CONCAT('${local_part}@', alias) FROM domeny WHERE \
	nazwa='${domain}' AND alias!=''}}

Teraz dodajmy aliasa domenowego:

INSERT INTO domeny (nazwa, alias) VALUE ('poczta.alias', 'poczta.test');

Teraz poczta wysłana na testowekonto@poczta.alias spowoduje dostarczenie maila do testowekonto@poczta.test.

Uf. Więc teoretycznie mamy już exim’a skonfigurowanego. Teraz pobawimy się, potestujemy i przejdziemy do konfiguracji serwera POP3, bo przecież samo dostarczanie to chyba nie do końca pełny system.

Serwer POP3

Mój wybór padł na tpop3d – całkiem miły i wydajny serwerek pop3. Podobnie jak i w przypadku exim’a, daruje sobie konfigurację i kompilacje (zresztą, w PLD jest dobry i sprawny ten tpop3d :)). Zacznijmy jednak od tego, by wzbogacić naszą bazę danych o hasła:

ALTER TABLE skrzynki ADD haslo VARCHAR(128) DEFAULT '' NOT NULL;

Trzeba oczywiście skonfigurować demon pop3d w /etc/tpop3d.conf:

# Słuchaj na każdym adresie IP:

listen-address: 0.0.0.0
max-children: 10
timeout-seconds: 30

# Domyślnie skrzynka jest w /var/mail/konto:

mailbox: /var/mail/$(user)

# Włączmy możliwość zalogowania się via PAM, czyli dla normalnych
# lokalnych kont:

auth-pam-enable: yes
auth-pam-facility: tpop3d
auth-pam-mail-group: mail

# Autoryzacja użytkowników z MySQL'a:

auth-mysql-enable: yes
auth-mysql-mail-group: mail
auth-mysql-hostname: localhost
auth-mysql-database: poczta
auth-mysql-username: mysql
auth-mysql-password: haslo
auth-mysql-pass-query: SELECT CONCAT('/var/mail/virtual/','$(domain)','/', '$(local_part)'), \
	CONCAT('{plaintext}', haslo), 'exim', 'bsd' FROM skrzynki WHERE \
	nazwa = '$(local_part)' AND domena = '$(domain)' AND alias=''

Jeżeli interesuje Cię support do SSL w tpop3d – zapraszam tutaj.

Ustawmy dla testu hasło:

UPDATE skrzynki SET haslo='haslodlatestu' WHERE nazwa='testowekonto' AND domena='poczta.test';

Teraz spróbujcie odebrać pocztę, używając użytkownika: testowekonto@poczta.test i hasła: haslodlatestu. Oczywiście w bazie możemy używać haseł md5 (takich jak shadow) wpisując w auth-mysql-pass-query zamiast {ldelim}plaintext{rdelim} słowo {ldelim}crypt_md5{rdelim} (takie hasło można uzyskać przy pomocy komendy crypt() z PHP na każdym w miarę nowym linuksie). Przykładowe takie hasło wygląda np. tak: $1$2sJSEoGq$rKMII73MsDYbcEd.cU55f..

Duplikowanie wpisów

Dosyć poważnym problemem którego do tej pory nie poruszyłem są zduplikowane wpisy w bazie danych. Od tego służą klucze w MySQL. Dla tabeli ze skrzynkami, klucz powinien obejmować komplet nazwa-domena-alias. Dlaczego? Pozowli to na utworzenie konta które jest aliasem i prowadzi na kilka innych kont. Niestety pozwoli to na jednoczesne utworzenie kilku aliasów oraz normalnego konta które wtedy nie będzie działać. Pozwalam sobie na taką sytuację gdyż w normalnych systemach pocztowych taka sytuacja też jest możliwa (istnieje konto w systemie, jednakże aliasy przechwytują poczte dla niego, np. konto root’a). W przypadku domen, klucz powiniene obejmować samą kolumnę ‘nazwa’. Oto więc komplety zrzut tabel z naszej bazy danych którą można wykorzystać w konfiguracji opisanej powyżej:

CREATE TABLE domeny (
  nazwa varchar(64) NOT NULL default '',
  alias varchar(64) NOT NULL default '',
  PRIMARY KEY  (nazwa)
) TYPE=MyISAM;

CREATE TABLE skrzynki (
  nazwa varchar(32) NOT NULL default '',
  domena varchar(64) NOT NULL default '',
  alias varchar(64) NOT NULL default '',
  haslo varchar(128) NOT NULL default '',
  PRIMARY KEY  (nazwa,domena,alias)
) TYPE=MyISAM;

Mam nadzieję że pozwoli to wam zbudować własny system poczty wirtualnej.

… 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.

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.

W normalnych wpisach DNS nazwy wskazują na adresy IP. Oczywiście adres IP może także wskazywać na nazwę. Takie coś nazywamy rDNS (reverse DNS – DNS odwrotny). Wpisy takie są zapisane w specjalnych domenach in-addr.arpa, i są w nich przechowywane w formie odwrotnej. Jak to by wytłumaczyć… Hm. Otóż reversdns dla adresu IP 213.25.100.23 jest zapisany w postaci 23.100.25.213.in-addr.arpa – czyli jak widać odwrotnej ;). No i oczywiście służy do tego specjalny typ rekordu – PTR. Czyli taki rekord to przykładowo:

23.100.25.213.in-addr.arpa	IN	PTR	netserv.baseciq.eu.org.

Dzięki takiemu rekordowi wiemy, że pod adresem IP 213.25.100.23 kryje się nazwa ‘netserv.baseciq.eu.org’. A jak z delegacją? Tutaj sprawa się komplikuje – minimalna domena w takim przypadku jaką można wydelegować to 100.25.213.in-addr.arpa, czyli 255 adresów. Jeżeli dostaliśmy od providera tak dużą ilość adresów IP to wtedy on nam deleguje takiego typu domene. Zasady jej tworzenia są tak jak w przypadku normalnych domen (napisałem już jak je się tworzy), z tym że możemy sobie darować rekordy IN MX, IN CNAME czy inne. Poprostu postępujemy tak jakby ktoś nam wydelegował (dla przykładu) domenę 100.25.213.in-addr.arpa. Oczywiśc można np. utworzyć host www.100.25.213.in-addr.arpa ale po co ? :-). Oto taka przykładowa domenka (dla 255 adresów z klasy 213.25.100.*):

$TTL	86400
$ORIGIN	100.25.213.in-addr.arpa.

;; Start of authority i czasy ...

@	IN	SOA	dns1.naszadomena.pl. hostmaster.naszadomena.pl. (
 2001073001 21600 7200 1209600 86400 )

;; Serwery dns dla tej domeny

@	IN	NS	dns1.naszadomena.pl.
@	IN	NS	secdns.provider.pl.

;; No i już konkretne hosty. Jako że są to hosty w tejże domenie,
;; piszemy kolejno 1 dla 213.25.100.1, 2 dla 213.25.100.2, itd..
;; Nie zapominajmy o kropkach na końcu wpisów. Jeżeli przy
;; 1 IN PTR napiszemy router.naszadomena.pl bez kropki,
;; to faktyczny rDNS dla 213.25.100.1 przyjmie wartość
;; router.naszadomena.pl.100.25.213.in-addr.arpa. - czyli te same
;; uwagi co wcześniej co do kropek.

1	IN	PTR	router.naszadomena.pl.
2	IN	PTR	netserv.baseciq.eu.org.
3	IN	PTR	www.baseciq.eu.org.
40	IN	PTR	komp40.naszadomena.pl.

;; i tak dalej...

Oki. Teraz kilka zasad. W sumie najważniejsze w dzisiejszych czasach wykorzystanie rDNS to IRC. Tak więc kilka zasad. Otóż poza tym że jest rekord PTR w rDNS’ie, potrzeba jeszcze aby host na który wkazuje adres IP, wskazywał na ten adres. Dobrze a jak provider nam daje mniejszą ilość adresów? Możemy albo jego poprosić o ustawienie rdns’a u siebie, albo o delegacje pojedyńczych hostów. Delegacje pojedyńczych hostów robi się poprzez wskazanie w domenie odwrotnej za pomocą rekordów IN CNAME na hosty w innej domenie (którą my możemy kontrolować) i ustawienie w tamtej domenie odpowiednich rekordów PTR. Oto przykład (zakładając że delegowane są adresy 213.25.100.0-7, a my możemy kontrolować domene naszadomena.pl):

;; W domenie 100.25.213.in-addr.arpa muszą być stworzone wpisy:
;; (oczywiście pamiętamy o kropkach na końcu!)

0	IN	CNAME	rdns0.naszadomena.pl.
1	IN	CNAME	rdns1.naszadomena.pl.
2	IN	CNAME	rdns2.naszadomena.pl.
3	IN	CNAME	rdns3.naszadomena.pl.
4	IN	CNAME	rdns4.naszadomena.pl.
5	IN	CNAME	rdns5.naszadomena.pl.

;; Hm, adres IP 213.25.100.6 należy do mojego prywatnego
;; servera i ja w swojej własnej domenie będę ustawiał
;; reverse-dns dla mnie ;-)))

6	IN	CNAME	revdns.dla.baseciq.eu.org.
7	IN	CNAME	rdns7.naszadomena.pl.

;; A w naszadomena.pl ustawiamy sobie już właściwy rDNS.

rdns0	IN	PTR	netaddr.naszadomena.pl.
rdns1	IN	PTR	router.naszadomena.pl.
rdns2	IN	PTR	netserv.naszadomena.pl.
rdns3	IN	PTR	dyrekcja.naszadomena.pl.
rdns4	IN	PTR	sekretariat.naszadomena.pl.
rdns5	IN	PTR	serwis.naszadomena.pl.
;; rdns6 nie ma bo go ustawiamy w innej domenie ;)))
rdns7	IN	PTR	broadcast.naszadomena.pl.

;; No i oczywiście muszę sobie ustawić reverse dns
;; dla mojego servera pod 213.25.100.6 w mojej domenie -
;; - baseciq.eu.org:

revdns.dla	IN	PTR	boski.baseciq.eu.org.

Powyższe zmiany należy wprowadzić w trzech plikach oczywiście (provider w strefie odwrotnej, my w domenie naszadomena.pl i ja sam dla siebie w baseciq.eu.org). Oczywiście i tutaj hosty które ustawimy w rekordzie PTR muszą posiadać rekord IN A.

A może by tak sobie ułatwić?

W sumie wpisywanie ‘[cyfra] IN CNAME r[cyfra].costam.pl.’ może być na dłuższą metę nużące. Równie dobrze, możemy powiedzieć binowi (z tego co wiem przynajmniej w wersji 9.x) aby zrobił coś z nas. Teoretycznie, chcemy wykonać wpisy ‘[cyferka] IN CNAME rev[cyferka].naszadomena.pl.’, gdzie cyferka jest od 0 do 7 (czyli pierwsze 8 adresów). Zamiast klepać kolejne rekordy można użyć:

$GENERATE 0-7 $ CNAME rev$.naszadomena.pl.

Czyli: ‘wygeneruj od 0 do 7 i zrób podany rekord wstawiając kolejne cyfry w miejsce znaku $’. Działa to oczywiście także dla stref prostych. Np:

$GENERATE 0-255 komp$ A 192.168.1.$

Co w efekcie da name wpisy ‘komp0 IN A 192.168.1.0′ … ‘komp255 IN A 192.168.1.255′. Fajne? Mi się też to podoba.

I taka mała uwaga na koniec: nie, nie pomogę ci na zmiane revdns dla twojego łącza z SDI/Neostrada/chello czy innego ustrojstwa – dlaczego ci nie pomoge? Bo sie nie da. Providerzy tychże usług odmawiają zmiany rDNS jak i jego delegacji.

Dynamic Host Configuraton Protocol (dynamiczny protokół konfiguracji hostów) jest protokołem umożliwiającym zdalną konfiguracje protokołu TCP/IP. Praktycznie każdy system operacyjny posiadający obsługę TCP/IP oferuje możliwość pobrania konfiguracji TCP/IP poprzez DHCP, czyli ustalenia: adresu IP, maski podsieci, domyślnej bramy w sieci, serwerów DNS, domeny w jakiej hosty pracują, oraz wielu innych parametrów. W tym tekście opiszę jak skonfigurować prosty serwer DHCP, dzięki któremu będziemy mogli automatycznie przydzielać adresy IP w sieci lokalnej.

W praktyce DHCP jest przydatne chociażby do tego, iż M$ Windows po zainstalowaniu karty sieciowej automatycznie sobie pobieże parametry konfiguracji, albo będzie można sobie ustalać która osoba jaki adres IP ma posiadać w naszym lanie.

Zacznijmy konfigurować. Wbrew pozorom konfiguracja dhcp jest bardzo prosta. Plik konfiguracyjny (/etc/dhcpd.conf) nie jest skomplikowany.

Na początek zdefiniujmy podsieć na w której ma działać serwer DHCP – parametry te muszą się zgadzać z parametrami karty sieciowej na której ma pracować serwer. Jeżeli nasza sieć lokalna to 192.168.1.0/255.255.255.0 (adresy od 192.168.1.0 do 192.168.1.255) definujemy ją w taki sposób:

subnet 192.168.1.0 netmask 255.255.255.0 {
#
# Tutaj wstawiamy opcje tej podsieci, ale to zaraz ;-)
#
}

Tutaj mała uwaga – znakiem # poprzedzamy wszelakie komentarze. Oki teraz opcje tej podsieci:

range <adres ip startowy> <adres ip koncowy> – komendą range definujemy początkowy i końcowy adres ip jaki może przydzielić DHCP. Np. range 192.168.1.100 192.168.1.200 – spowoduje że serwer DHCP będzie przydzielał adresy od 192.168.1.100 do 192.168.1.200.

default-lease-time <czas w sekundach> – okres ważności dzierżawy adresu IP liczony w sekundach. Poinformuje to komputer który skorzysta z DHCP o tym ile czasu spokojnie może ten adres IP używać. Przykładowo dzierżawa na jeden dzień to: default-lease-time 86400.

option domain-name "domena" – ta opcja informuje o tym w jakiej domenie pracują komputery w naszej sieci. Przykładowy wygląd tej opcji to: option domain-name "wiosenna.com".

option domain-name-servers <adres ip> [, adres ip] – tutaj definiujemy adres ip serwerów DNS jakie mają używać komputery w naszej sieci lokalnej. Np. option domain-name-servers 192.168.1.1, lub option domain-name-servers 194.204.159.1, 194.204.152.34.

option subnet-mask <maska podsieci> – maska podsieci jaką ma ustawić sobie komputer kliencki. Np. option subnet-mask 255.255.255.0.

option broadcast-address <adres rozgłoszeniowy sieci> – adres rozgłoszeniowy sieci (broadcast). Np. dla sieci 192.168.1.0/255.255.255.0 wygląda to tak: option broadcast-address 192.168.1.255.

option routers <domyślna brama> – adres domyślnej bramy w podsieci (gateway’a). Np. u mnie jest to 192.168.1.1, więc wpisuje: option routers 192.168.1.1.

Jak widać są to bardzo podstawowe parametry które przydadzą się w normalnych nieskomplikowanych sieciach. Konfiguracja DHCP może być bardzo rozbudowana. Jeżeli szukacie bardziej wyszukanych opcji polecam poczytać dokumentacje od DHCP. Oki, teraz stwórzmy przykładowy plik konfiguracyjny który możemy napisać na podstawie powyższych parametrów (po każdej opcji podajemy średnik):

# sieć 192.168.1.0/255.255.255.0
subnet 192.168.1.0 netmask 255.255.255.0 {
    # domyślnie przydzielamy adresy 192.168.1.100-199:
    range 192.168.1.100 192.168.1.199;
    # na jeden dzień
    default-lease-time 86400;
    # poinformujmy że hosty będą korzystać z domeny ultra.net.pl
    option domain-name "ultra.net.pl";
    # niech używają naszego routera jako serwera DNS:
    option domain-name-servers 192.168.1.1;
    option routers 192.168.1.1;
    # i dodatkowe info:
    option subnet-mask 255.255.255.0;
    option broadcast-address 192.168.1.255;
}

Więc mamy już skonfigurowaną sieć. Ale jak stworzyć wpisy dla konkretnych kart sieciowych? Tworzymy w definicji podsieci definicje hosta:

subnet 192.168.1.0 netmask 255.255.255.0 {
    #
    # Tutaj opcje globalne jakie wpisaliśmy już
    #

    host ranger {
        hardware ethernet 52:54:05:E1:EE:97;
        fixed-address 192.168.1.6;
    }
}

hardware ethernet – tutaj wpisujemy adres sprzętowy karty – w Windowsie możemy go odczytać po uruchomieniu komendy winipcfg (Menu Start/Uruchom), w Linuxie komendą ifconfig (karty w komputerze) lub z root’a komenda arp (wyświetli wszystkie karty które "słyszy" w sieci nasz komputer). W opcji fixed-address podajemy adres ip dla danego komputera. Oczywiście w definicji hosta możemy także użyć którejś z opcji globalnych, np. możemy podać konkretnemu komputerowi żeby używał innego routera w sieci albo innego serwera DNS:

subnet 192.168.1.0 netmask 255.255.255.0 {
    range 192.168.1.100 192.168.1.199;
    default-lease-time 86400;
    option domain-name "ultra.net.pl";
    option domain-name-servers 194.204.159.1, 194.204.152.34;
    option routers 192.168.1.1;
    option subnet-mask 255.255.255.0;
    option broadcast-address 192.168.1.255;
    host ranger {
        hardware ethernet 52:54:05:E1:EE:97;
        fixed-address 192.168.1.6;
        option domain-name-servers 192.168.1.1;
        option routers 192.168.1.2;
    }
}

Uf. A co jeżeli mamy dwie karty sieciowe? Otóż wystarczy stworzyć poprostu drugą definicje podsieci.

Uruchamianie (w Slackware) DHCP polega na wpisaniu z root’a komendy ‘dhcpd’, ‘killall -9 dhcpd’ aby go zatrzymać. Jeżeli np. mamy w serwerze dwie karty sieciowe i tylko na jednej sieci chcemy uruchomić DHCP, to poprostu wpisujemy ‘dhcpd eth0′ czy też ‘dhcpd eth1′. Aby serwer DHCP się uruchamiał automagicznie podczas startu systemu wpisujemy do /etc/rc.d/rc.local:

/usr/sbin/dhcpd (tutaj ewentualnie parametry)

W RedHatach i jemu podobnych:

chkconfig –level 345 on; chkconfig –level 0126 off

A! W RH uruchamiamy DHCP w taki sposób:

/etc/rc.d/init.d/dhcpd (start|stop|restart)

W sumie to chyba wszystko tak na początek. Jeżeli chcesz więcej się nauczyć i rozumiesz do czego służy DHCP polecam komendę ‘man dhcpd.conf’ ;).

W sieciach bez maskarady komputery za maskaradą nie posiadają identa – czyli ciągu znaków identyfikującego danego użytkownika komputera. Identd jest zalecany przy korzystaniu z wielu usług, a jego brak np. na ircu może przysporzyć wielu kłopotów. Pomysłowi programiści wymyślili Oidentd. Jest to demon identd który podczas połączenia poza sprawdzaniem wśród zalogowanych użytkowników sprawdza wśród połączeń via. maskarada, i zależnie od ustawień albo forwarduje zapytanie do komputera w lanie, albo zwraca identa ustawionego w pliku konfiguracyjnym.

Instalujemy…

wget http://download.sourceforge.net/ojnk/oidentd-2.0.3.tar.gz
tar -xzf oidentd-2.0.3.tar.gz
cd oidentd-2.0.3
./configure --prefix=/usr
make
make install

Oczywiście musisz mieć uprawnienia root’a by wykonać te czynności. Teraz należy unieszkodliwić standardowego demona identd. W systemach bazowanych na RedHacie (nowszych) wystarczy wpisać: chkconfig –level 0123456 identd off, oraz wpisując /etc/rc.d/init.d/identd stop. W systemach bardziej ludzkich (czytaj: Slackware), czyli takich które posiadają uruchomionego demona identd z inetd wystarczy odnaleźć w pliku /etc/inetd.conf linijkę zaczynającą się od słowa ‘auth’ i ją wyhashować. W Slackware 7.1 linijka ta wygląda tak:

auth stream tcp nowait nobody /usr/sbin/in.identd in.identd -P/dev/null

Wystarczy wcisnąć hash (znak #) przed napis auth, zapisać plik konfiguracyjny i przeładować konfiguracje inetd wykonując komendę killall -HUP inetd.

Teraz uruchamiamy demona oidentd. Nas interesują dwa tryby działania oidentd’a:
- albo odczytuje on identy z pliku konfiguracyjnego;
- albo forwarduje on zapytania do hosta za maskaradą (np. program mIRC ma w sobie serwer identa);

Dopisujemy sobie do skryptów startowych (np. /etc/rc.d/rc.local) wywołanie oidentd’a:

# Uruchomienie oidentda bez forwardowania:

/usr/sbin/oidentd -m

# Uruchomienie oidentda z forwardowaniem zapytań do lanu:

/usr/sbin/oidentd -f -m

Niestety w wersji 2.x oidentd nie potrafi współpracować z serwerem inetd.

Po takim uruchomieniu niestety oidentd chodzi z prawami root’a, co nie jest zbytnio porządane. O ile nasz system nie ma ograniczeń w dostępie do /proc (tzn. komenda ‘ps -aux’ wykonana z konta zwykłego użytkownika pokazuje wszystkie procesy a nie tylko te należące do użytkownika) sprawa jest dziecinnie prosta (należy urchomić oidentd’a z dodatkowym parametrem ‘-u nobody), o tyle w systemach gdzie jest ograniczenie w dostępie do proc sprawa się komplikuje. W tym drugim wypadku pomaga przeważnie dodanie ‘-g proc’ i powinno być wszystko oki. Jeżeli to nie pomaga, należy wykonać ‘ls -ald /proc’ – wtedy zobaczymy użytkownika i grupę do którego należy /proc:

dr-xr-xr-x   54 root     procfs          0 maj 11 16:29 /proc/

Na tym przykładzie widzimy że /proc należy do użytkownika root i grupy procfs. Wtedy dodajemy do wywyołania oidentd ‘-g procfs’. Jak grupa i użytkownik to root, trzeba modyfikować wpisy w fstab, co odradzam początkującym (zaawansowani użytkonicy pewnie nie będą czytać tego artykułu), którym pozostanie uruchomienie oidenta z usera root.

Aby przypisać identy do adresów IP w lanie tworzymy plik /etc/oidentd_masq.conf który wygląda mniej-więcej tak:

192.168.3.79    piotrek    WIN32
192.168.10.4    darek    WIN32
192.168.1.2    ranger    UNIX

Czyli najpierw adres IP w lanie, ident, system operacyjny. Uf… No to chyba wszystko co można napisać o Oidentd.

Protokół HTTP, którego każdy z nas używa na codzień, pozwala nam na robienie wirtualnych hostów WWW, czyli na jednym serwerze WWW i jednym adresie IP umieszczenie kilku niezależnych od siebie stron WWW. Konfiguracja czegoś takiego jest bardzo prosta. Z góry jednak przepraszam za toporność tego tekstu – nie mam nastroju na lanie wody dzisiaj ;-)… Poza tym jak zwykle opisuje on najprostszy sposób wykonania vhostów jak i tylko podstawowe możliwości apache’a w tym zakresie.

Chciałbym przypomnieć także, iż każdy vhost (domena) musi być oczywiście skonfigurowana w danej domenie. Tzn. ja dzisiaj jeszcze kawy nie piłem i nie wiem jak to napisać aby każdy zrozumiał. Poprostu jeżeli wszystko skonfigurowałeś, a niestety nowe wychuchane i wypucowane vhosty Ci nie chodzą, wykonaj komendę „host mój.nowy.kochany.vhost.pl” – jeżeli ta komenda nie zwróci jakiejś nazwy albo adresu to już masz źródło swoich błędów. Jeżeli nie wiesz o czym tutaj bredzę, poprostu idź i poczytaj o dns i spróbuj ponownie ;)

Na początek musimy odnaleźć plik httpd.conf. Najczęściej jest to plik /etc/apache/httpd.conf (Slackware 8, Mandrake i Redhat) lub /etc/httpd/httpd.conf (PLD, starsze RH i MDK). Inne możliwe lokalizacje to: /etc/httpd.conf, /etc/www/httpd.conf, /var/lib/apache/conf/httpd.conf (Slackware 7.1, 7.0), /usr/local/apache/conf/httpd.conf (Apache ze źródeł). Domyślnie, apache ma zdefiniowany główny katalog www dyrektywą DocumentRoot, np:

DocumentRoot "/var/www/htdocs"

Zasada działania.

Po zdefiniowaniu konkretnego adresu IP jako adresu do wirtualek zaczyna on inaczej funkcjonować niż pozostałe adresy. Otóż w tym momencie dla tego adresu IP nie obowiązuje globalnie zdefiniowany DocumentRoot, tylko pierwsza zdefiniowana wirtualka. Czyli, jeżeli ktoś się odwoła do tego adresu IP do nazwy nie zdefiniowanej jako wirtualka, zostanie mu wyświetlona zawartość pierwszej wirtualki. Na pozostałych adresach nadal domyślną stroną www będzie ta z katalogu podanego w dyrektywie DocumentRoot. Teraz przykład. Mój serwer posiada adres IP 217.8.186.57. Chciałbym, aby każdy odwołujący się do tego adresu IP widział moją stronę, oraz chciałbym do tego dorzucić parę wirtualnych hostów. Robię więc tak:

#
# Definuje że 217.8.186.57 jest adresem ip na którym będę robił vhosty:
#

NameVirtualHost 217.8.186.57

#
# Teraz zdefiniujemy główną wirtualkę:
# Wirtualka ta się zowie www.baseciq.org, a jej główny katalog
# jest u mnie w katalogu domowym w public_html
#

<VirtualHost 217.8.186.57>
ServerName www.baseciq.org
DocumentRoot /home/users/baseciq/public_html
ServerAdmin baseciq@baseciq.org
</VirtualHost>

#
# Na swojej stronie mam trochę plików, udostępnie je pod
# adresem http://ftp.baseciq.org/
#

<VirtualHost 217.8.186.57>
ServerName ftp.baseciq.org
DocumentRoot /home/users/baseciq/public_html/files
ServerAdmin baseciq@baseciq.org
</VirtualHost>

#
# O, i jeszcze jeden taki malutki vhost ;>
#

<VirtualHost 217.8.186.57>
ServerName radded.baseciq.org
DocumentRoot /home/users/baseciq/public_html/radded
ServerAdmin baseciq@baseciq.org
</VirtualHost>

Oczywiście możemy zrobić teraz wirtualki na innych adresach ip o ile je posiadamy. Poprostu dopisujemy kolejne NameVirtualHost [adresip] i pod nim na takich samych zasadach wirtualki dla następnego adresu IP. Można także zdefiniować kilka nazw wskazujących na jeden katalog, na przykład chcemy zrobić writualkę www.domena.pl i domena.pl. Wtedy zamiast robienia kiku wpisów z wirtualkami tworzymy jeden z dyrektywą ServerAlias:

<VirtualHost 213.25.209.99>
ServerName domena.pl
ServerAlias www.domena.pl
DocumentRoot /var/www/vhosts/domena.pl
ServerAdmin webmaster@domena.pl
</VirtualHost>

Dzięki temu mamy jako taki porządek w httpd.conf

Opisany powyżej wycinek httpd.conf z mojego serwera można obejrzeć w akcji:

http://www.baseciq.org/ – podstawowa wirtualka,

http://ftp.baseciq.org/ – druga wymieniona wirtualka,

http://radded.baseciq.org/ – trzecia wirtualka.

Tych wirtualek nie ma, ale po wejściu na nie zostanie wam wyświetlona podstawowa strona tego adresu ip (poniższe hosty wskazują na 217.8.186.57):

http://217.8.186.57/ – tutaj oczywiście sam adres a nie host ;)

http://baseciq.zacisze.org/ (to Arek sobie dopisał :))

http://baseciq.drzwi.org/ (a to mam od Neas’a)

Generalnie 217.8.186.57 jest dodatkowym adresem serwera. Na pozostałych adresach tej maszyny (ma ona dwie karty sieciowe i co za tym idzie dwa adresy z sieci lan) obowiązuje normalne DocumentRoot.

Do VirtualHost można dorzucić kilka ciekawych rzeczy. Praktycznie każda dyrektywa główna apache’a da się zastosować lokalnie w ramach <VirtualHost IP> – </VirtualHost>. Zresztą te 3 dyrektywy których użyłem powyżej są normalnie wykorzystywane w „głównej” części konfiguracji. I tak, można na przykład dopisać w obrębie wirtualki:

CustomLog /home/users/baseciq/logi/www.log combined

Spowoduje to iż wywołania do wirtualki będą logowane do pliku www.log w moim katalogu domowym w podkatalogu ‘logi’.

ErrorDocument 404 /index.php?error=404
ErrorDocument 403 /error403.html
ErrorDocument 401 /error404.html
ErrorDocument 500 /error500.html

Spowoduje to iż zamiast ogólnych komunikatów błędów dla tej wirtualki będą wyświetlane pliki /home/users/baseciq/public_html/error???.html (zakładając że DocumentRoot wirtualki to /home/users/baseciq/public_html).

Opcji tych jest prawie tyle samo co głównych dyrektyw apache’a (niektórych poprostu nie da się użyć). Jednak uważam iż ten art nie jest miejscem na ich szczegółowe opisywanie.

Na koniec oczywiście pozostaje nam zrestartować apache’a. Użytkownicy RedHatów, Mandrakeów i innych podobnych dystrybucji piszą: /etc/rc.d/init.d/httpd restart (lub apache restart). W Slackware jest to /var/lib/apache/bin/apachectl restart (7.0, 7.1) lub /usr/sbin/apachectl restart.

Jeszcze taka mała uwaga na koniec. Nie denerwujcie się że wam czasami nie wychodzi wirtualka mimo poprawek… Poprostu wyłączcie proxy i wyczyśćcie cache przeglądarki, co nie sebek? :)))

search wiosenna.com
nameserver 127.0.0.1
nameserver 194.204.159.1
nameserver 194.204.152.34

Hm… Czyli najpierw lokalny bind, później "kochane" ns’y tpsy… A jak rozwiązuje sobie domeny spoza świata lokalny bind? Używa resolv.conf? Hm… Chyba nie… Oki, wycinamy z resolv.conf ipki, SIGHUP w named’a i jedziemy. # dig wiosenna.com @0 … Zadziałało, więc już mamy pewność że to nie resolv.conf. So what?

zone "." in {
        type hint;
        file "root.cache";
};

Czyli 13 ROOT-SERVERS… Popingujmy je. Wiem, mogą mieć zablokowane możliwości pingowania… Z 13 które ja miałem w fabrycznym root.cache odpowiedziało 5:

64 bytes from 192.33.4.12: icmp_seq=0 ttl=242 time=250.402 ms
64 bytes from 192.203.230.10: icmp_seq=0 ttl=53 time=311.281 ms
64 bytes from 192.5.5.241: icmp_seq=0 ttl=54 time=310.181 ms
64 bytes from 192.112.36.4: icmp_seq=0 ttl=240 time=280.216 ms
64 bytes from 198.32.64.12: icmp_seq=0 ttl=242 time=340.989 ms

W przypadku dns i dns2 tpsa.pl czasy te są około 30-40 ms… Więc 10 razy szybciej. Jaki z tego morał? Standardowy Bind skonfigurowany jest na ROOT-SERVERS, co w dzisiejszych czasach raczej nie wróży nam zbyt szybkiej pracy. Nie wierzącym polecam odpalenie iptrafa albo innego ustrojstwa i monitorowanie połączeń UDP. Bind ma głęboko w nosie resolv.conf, co w sumie jest bardzo logiczne. Więc należy jakoś zmusić by korzystał z bliższych ns’ów niż ROOT-SERVERS (naprawdę, dns.tpsa.pl wcale nie jest taki makabryczny). Zmodyfikować mu root.cache? Podobno można, u mnie to słabo pomogło. A może przedefiniować mu strefę "."? To już bardziej logiczne. Pół godziny studiowania wyniku komendy ‘man named.conf’ nasunął mi pewne wnioski. So, usuwamy strefę "." z /etc/named.conf i wpisujemy zamiast niej coś takiego:

zone "." IN {
        type forward;
        forward only;
        forwarders { 194.204.159.1; 194.204.152.34; };
        check-names ignore;
    // Uwaga! Opcja check-names jest obsługiwana tylko
    // przez Bind'a 8.x. W Bindzie 9.x nie jest ona wymagana!
};

Tak zupełnie BTW. ostatnio się zorientowałem że w Bind 9.x (dokładnie 9.2.1 z PLD) można to prościej. Wystarczy w sekcji options { } dopisać (bez konieczności defioniowania strefy ".":

options {
    forwarders { 194.204.159.1; 194.204.152.34; };
}

W miejsce 194.204… Należy wpisać IPki serwerów dns z których chcemy korzystać. Polecam ns1.ikp.pl – niestety nie wszystkich on lubi ;). Istnieje także dns.tpi.pl – działa jak narazie całkiem cacy. Dobra. Mniam! Mimo tego iż wygląda na to że bind nie cachuje nic z forwardowanych zapytań (przynajmniej ja tak wnioskowałem), to jednak pamięta wpisy o które się odpytywaliśmy :-). HUPnełem named’a znowu, odpytałem się któryś z root servers o domenkę unroutable.net: Total query time: 5319 msec – no i teraz sobie wyobraź(cie) ile czasu trwało odpytanie root-server’s… Błe… A później się dziwie że mi nie rozwiązuje domenek a przez modem jak ustawiam dns’y providera to prawie odrazu. A wogóle po co mi to? Otóż uparłem się iż w sieci lokalnej będę korzystał z DNS’a na serwerze od maskarady ;)… Po kilku chwilach namysłu z resolv.conf wyciełem wszystkie ipki poza 127.0.0.1 – po co lokalny resolver ma puszczać coś poza serwer?

Co to jest maskarada? Maskowanie adresów IP polega na ukryciu (zamaskowaniu) adresów IP komputerów w sieci przez router podłączony do internetu. Pozwala to na dostęp do internetu komputerom nie posiadającym publicznego adresu IP (192.168.*.* czy też 10.*.*.*), lub też na ochronę tychże komputerów nawet jeżeli mają publiczne adresy IP – maskarada jest jedną z odmian firewalla.

A do czego to mi w praktyce?

Tekst ten napisałem pod kątem głównie sieci amatroskich które posiadają łącze do internetu z jednym adresem IP, a wbrew pozorom udostępnienie takiego internetu nie jest wcale trudne. Zakładam także że masz już skonfigurowane połączenie z internetem (o SDI pisałem wyżej) i główny nacisk położę na tym jak zbudować maskaradę z komputerami z windows.

Zakładam że już udało Ci się postawić linuksa. Przede wszystkim musisz wiedzieć którą wersję kernela posiadasz – od tego jest uzależnione czy maskaradę należy wykonać przy użyciu komendy ipchains czy iptables. Wersję kernela możesz sprawdzić poprzez komendę ‘uname -a’. Przydała by się skonfigurowana także sieć lokalna (komputery mam nadzieje połączone są już w sieć) – jeżeli tego jeszcze nie zrobiłeś – niestety ja Ci tutaj nie pomogę. Poszukaj dokumentacji do swojej dystrybucji.

Teraz trzeba napisać skrypt który będzie włączał tą maskaradę:

1) Zaloguj się jako root, wejdź do katalogu /etc/rc.d i stwórz plik rc.masq, nadaj mu atrybuty pliku wykonywalnego:

cd /etc/rc.d && touch rc.masq && chmod +x rc.masq

2) Wyedytuj ten plik (możesz do tego użyć ulubionego edytora tekstowego, jeżeli nie masz takowego, użyj programu mc który wygląda i działa podobnie do Midnight Commandera), wpisz do niego odpowiednią treść zależnie od wersji kernela:

dla kerneli w wersjach 2.2.x:

#!/bin/sh

# włączenie forwardowania pakietów:
echo 1 > /proc/sys/net/ipv4/ip_forward

# parametry -F -X wyczyszczą aktualne reguły maskarady
ipchains -F
ipchains -X

# domyślne DENY przy próbie forwardowania pakietów
ipchains -P forward DENY

# uruchamiamy maskaradę
ipchains -A forward -s 192.168.0.0/255.255.0.0 -d 0/0 -j MASQ

# moduły wspomagające do maskarady
/sbin/modprobe ip_masq_irc
/sbin/modprobe ip_masq_ftp

Co to wszystko oznacza? Każdy pakiet pochodzący z komputera o adresie rozpoczynającym się od 192.168. (-s 192.168.0.0/255.255.0.0 – czyli 192.168.0.0 – 192.168.255.255) zadresowany gdziekolwiek (-d 0/0) ma zostać zmaskowany (-j MASQ). Jeżeli nadal tego nie rozumiesz – poczekaj parę minut i spróbuj jeszcze raz.

dla kerneli w wersjach 2.4.x i 2.6.x:

#!/bin/sh

# włączenie forwardowania pakietów:

echo 1 > /proc/sys/net/ipv4/ip_forward
# wyczyśćmy tablice iptables odpowiedzialne za nat i za filtrowanie pakietów:

iptables -F -t nat
iptables -X -t nat
iptables -F -t filter
iptables -X -t filter

# Domyślnie odrzucamy i nie zezwalany na forwardowanie pakietów

iptables -t filter -P FORWARD DROP

# Zezwalamy na by serwer przepuszczał pakiety które pochodzą z naszej sieci
# lokalnej lub są dla niej przeznaczone.

iptables -t filter -A FORWARD -s 192.168.0.0/255.255.0.0 -d 0/0 -j ACCEPT

iptables -t filter -A FORWARD -s 0/0 -d 192.168.0.0/255.255.0.0 -j ACCEPT

# Teraz nakazujemy by wszystkie pakiety pochodzące z lanu były maskowane

iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -d 0/0 -j MASQUERADE

# I doładujmy moduł do obsługi ftp i irc (moduł do irca zauważyłem dopiero
# w kernelu 2.4.14 dlatego się w końcu za niego wziąłem

/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_nat_irc

Jak widać iptables w Linuxie 2.4.* są o wiele bardziej zaawansowane niż ipchains w 2.2.*. Wiem także iż można zrobić maskaradę prościej/lepiej. Ale powyższy przykład działa i jest w miarę podobny do ipchains. Teraz, aby przy każdym uruchomieniu serwera był wykonywany ten skrypt, dopisujemy w pliku /etc/rc.local na końcu:

/etc/rc.d/rc.masq