Pokud provider vyžaduje autentifikaci pomocí PAP nebo CHAP, vyhodíme řádky zaNahození PPP: ============= pppd connect 'chat -v -f /etc/ppp/pppscript' Soubor: /etc/ppp/options ======================== lock defaultroute noipdefault modem /dev/ttyS1 115200 crtscts debug passive Soubor: /etc/ppp/pppscript ================ TIMEOUT 10 ABORT ERROR ABORT BUSY ABORT "NO CARRIER" ABORT "NO DIAL TONE" REPORT "CARRIER" REPORT "CONNECT" "" "ATQ0H0" OK "atdt29" TIMEOUT 45 CONNECT "" ogin: huzva ssword: tajneheslo luto:~> "ppp default"
CONNECT
až do konce a vytvoříme příslušné
soubory /etc/ppp/pap-secrets
nebo
/etc/ppp/chap-secrets
.
Diskuzí kolem modemů se zabývá stránka: Modemy - zajímavý hardware
/etc/resolv.conf
. Pokud DNS server poběží přímo
na našem počítači, může jeho obsah vypadat třeba takto:
Pokud používáme novější systémové knihovny (glibc), je důležitý následující řádek souborudomain moje.domena.cz search moje.domena.cz domena.cz nameserver 127.0.0.1
/etc/nsswitch.conf
Starší knihovní funkce využívají souborhosts: files dns
/etc/host.conf
,
který by měl vypadat takto:
Oba soubory stanovují, jak se bude převádět jméno na IP adresu a obráceně. V obou případech se nejprve prohledá soubororder hosts,bind multi on
/etc/hosts
a teprve pak se provede dotaz na DNS server. Do
tohoto souboru se nevyplatí ukládat příliš mnoho záznamů. protože v
případě změny bychom je museli neustále opravovat. Může vypadat
například takto:
127.0.0.1 localhost localhost.localdomain 192.168.0.1 linux.moje.domena.cz linux
fetchmail
fetchmail
stahuje poštu pomocí protokolů
POP3 nebo IMAP. Jeho konfigurace je velmi variabilní a umožňuje
tak obvykle dosáhnout potřebných výsledků bez vynaložení větší
námahy. Konfigurační soubor ~/.fetchmailrc
je
možno psát téměř jako obyčejné anglické věty. Záznamy jsou dvojího
druhu: pool
a skip
. První je prováděn
automatikcy při každém spustění programu, druhý jen když o to
parametrem na příkazovém řádku požádáme:
Při spuštění programu je kontaktován server pop.provider.cz a protokolem POP3 je vyzvednuta pošta z účtů rene.huzva a jane, přičemž pošta z účtu rene.huzva je doručena v lokálním systému uživateli huzva a pošta uživatele jane skončí na našem počítači u stejnojmenného uživatele.poll pop.provider.cz proto pop3 user rene.huzva with pass TajneHeslo is huzva here user jane with pass TajneHeslo2
Zde ovšem vzniká problém. Některé poštovní zprávy (typicky pošta z
konferencí nebo když dostaneme nějakou zprávu jako BCC:) neobsahují ve
svých hlavičkách naše jméno (je tam například: To: "Linuxová
konference"
Směrování pošty do UUCP fronty provedeme pomocí definice maileru
uucp-dom v sendmailu. Konkrétní podoba souboru /etc/mail/mailertable:
Do definičního souboru m4 pro generování konfiguračního souboru
sendmailu doplníme řádky:
Konfigurace sendmailu na straně klienta se sestává pouze z přidání
těchto řádků do souboru m4:
Adresy přidělujeme z privátních rozsahů, které jsou pro tato
použití vyčleněny:
Konfigurační soubor
Příklad konfigurace pro Squid verze 2.1:
fetchmail
přesvědčit, že pošta z jedné schránky bude rozdělena mezi více
lokálních uživatelů:
Více informací najtete na manuálové stránce příkazu
pool pop.provider.cz proto pop3
localdomains mojefirma.cz envelope 1 "Received"
user firma password TajneHeslo to *
fetchmail
.
Konfigurace UUCP
Provider:
Nejprve je potřeba vytvořit příslušné systémy v konfiguraci UUCP.
Definice systému zsles může vypadat třeba takto:
Konfiguraci si můžeme ověřit příkazem uuchk -s zsles.
/etc/uucp/config
================
nodename ratbert
sysfile zsles
/etc/uucp/passwd
================
zsles TajneHeslo
/etc/uucp/zsles
===============
called-login zsles
system zsles
Uvedený řádek způsobí, že pošta pro doménu zsles bude
zařazena do UUCP fronty stejného jména, jak je uvedeno v pravé časti
souboru. Zmíněný systém musí být UUCP systému znám.
zsles.edulib.cz uucp-dom:zsles
define(`UUCP_MAX_SIZE', 10000000)
FEATURE(mailertable, `hash /etc/mail/mailertable')
MAILER(uucp)
Klient:
Klient si poštu vyzvedává kdykoliv a odkudkoliv (může používat
dynamicky přidělovanou IP adresu). Prokazuje se jménem a heslem.
V každé relaci jsou přesunuty čekající soubory na druhý systém
(je odeslána čekající pošta a zároveň přitažena nová). Pošta
čekající ve frontě není ovlivňována žádnými timeouty, může ležet
na serveru třeba 14 dní nebo rok, dokud není vyzvednuta. Další
výhodou je, že pošta nevypadne z přepravního systému, takže
jsou zachovány i informace z obálek.
Konfigurace UUCP systému bude vypadat takto:
define(`SMART_HOST', `uucp-dom:ratbert')
define(`UUCP_MAX_SIZE', 10000000)
Vlastní stažení obsahu fronty provedeme příkazem:
/etc/uucp/config
================
nodename zsles
sysfile ratbert
/etc/uucp/ratbert
=================
system ratbert
call-login *
call-password *
time any
port type tcp
address ratbert.provider.cz
/etc/uucp/port
==============
port tcpip
type tcp
/etc/uucp/call
==============
ratbert zsles TajneHeslo
uucico -f -s ratbert -D
Konverze poštovních schránek do formátu pro Pegasus Mail
Pokud chceme ve své síti využívat centrálně konfigurovaný
poštovní program, padne volba zřejmě jednoznačně na Pegasus.
Emulaci Novellovského serveru lze snadno zajistit programem
Mars.
Zbývá jen konvertovat příchozí poštu z Unix-style do formátu
čitelného pro Pegasus (*.CNM soubory) a odchozí poštu
strkat do poštovního systému. Příchozí (tedy novou)
poštu můžeme velmi snadno konvertovat po každém stažení
od providera následujícím skriptem v Perlu, který vezme soubory
z /var/spool/mail/jmeno.uzivatele
, rožvýká je na jednotlivé
dopisy do *.CNM souborů a uloží je do adresáře SYS:MAIL/_ID_, který
distribuuje Mars uživatelům.
Odchozí poštu nejlépe zpracujeme tak, že nastavíme Pegasus
programem PCONFIG.EXE tak, aby veškerou odchozí poštu posílal
do tiskové fronty (tj., aby odchozí poštu "tisknul").
V Marsu pak přiřadíme této tiskové
frontě skript, který dopis předá sendmailu (jinou variantou
je vytváření souborů s odchozí poštou ve speciálním adresáři
a následném periodickém spouštění tohoto mírně upraveného
skriptu).
#!/usr/bin/perl
$mail_dir = "/home/sys/mail/user";
$spoll_dir = "/var/spool/mail";
sub cnm_from_file {
$number = 0;
$close = 0;
while ( $line = <VSTUP> ) {
chop ($line);
if ( $line =~ /^From / ) {
while ( -e "${mail_dir}/${user_name}/${number}.cnm" ) {
$number++;
}
if ( $close != 0 ) {
close (VYSTUP);
} else {
$close = 1;
}
if (! open (VYSTUP, ">${mail_dir}/${user_name}/${number}.cnm") ) {
print "can't write to file ${mail_dir}/${user_name}/${number}.cnm\n";
return 1;
} else {
print " vytvarim ${user_name}/${number}.cnm ...\n";
}
}
print VYSTUP "$line\r\n";
}
close (VYSTUP);
return 0;
}
opendir(SPOOL, $spoll_dir) || \
die "can't read from directory $spoll_dir";
while ( $user_name = readdir(SPOOL) ) {
if ( -f "${spoll_dir}/${user_name}" && -s "${spoll_dir}/${user_name}") {
rename ("${spoll_dir}/${user_name}", "${spoll_dir}/${user_name}.lock") || \
die "can't rename file ${spoll_dir}/${user_name}";
open (VSTUP, "${spoll_dir}/${user_name}.lock") || \
die "can't open ${spoll_dir}/${user_name}.lock";
if ( &cnm_from_file ) {
close (VSTUP);
rename ("${spoll_dir}/${user_name}.lock", "${spoll_dir}/${user_name}");
} else {
close (VSTUP);
unlink ("${spoll_dir}/${user_name}.lock") || \
die "can't delete file ${spoll_dir}/${user_name}.lock";
}
}
}
exit 0;
#!/bin/sh
PATH="/bin:/usr/bin:/usr/local/bin:/sbin:/usr/sbin"
TMPFILE=`mktemp /tmp/mail-out.XXXXXX`
cat - > $TMPFILE
FROM=`grep "^From:" $TMPFILE | head -1 | sed -e 's/.*<//' -e 's/>.*//'`
TO=`fromdos < $TMPFILE | sed -n '2,/^$/p'`
fromdos < $TMPFILE | sed '1,/^$/d' | sendmail $TO
rm $TMPFILE
Předávání pošty jinému stroji
Někdy je výhodné mít poštovní schránky na jiném počítači, než
který zajišťuje spojení s Internetem. Klasickým příkladem
je síť, ve které již funguje Novellovský server, na kterém
již mají všichni uživatelé účty. V takovém případě by zakládání
dalších účtů bylo zbytečným. Na Novellovském serveru spustíme
NLM modul Mercury, který je schopen přijímat poštu a vhazovat
ji do poštovních schránek uživatelům systému. Náš Linux
nastavíme tak, aby veškerou poštu, která je určena pro naší doménu,
předával tomuto serveru. Toho dosáhneme pomocí následujících
voleb v souboru m4, ze kterého generujeme konfigurační
soubor pro sendmail:
V souboru /etc/mail/mailertable nadefinujeme, že veškerá pošta
pro naši doménu bude předávána na Novellovský server:
define(`confTRY_NULL_MX_LIST', True)
FEATURE(mailertable, `hash -o /etc/mail/mailertable')
Mercuryho nastavíme tak, aby veškerou odchozí poštu předával
nám (tzv. relay host nebo smart host). V našem sendmailu
budeme muset povolit relaying pro tento Novellovský server.
moje.domena.cz esmtp:novell.moje.domena.cz
Přidělování IP adres v lokální síti
Pokud chceme využívat služby, které vyžadují protokol TCP/IP,
musíme svým lokálním počítačům přidělit IP adresy. Existuje několik
způsobů, jak toho dosáhnout:
Statické přidělování znamená, že do konfigurace každé stanice
uvedeme její IP adresu. Znamená to, že musíme obejít všechny stanice
a IP adresy, masky, adresu DNS serveru a další všude naklepat.
To je poměrně náročná činnost, ve které se může objevit mnoho chyb,
zejména, pokud jsou stanice občas "přeinstalovány či upraveny" nezkušeným
uživatelem. Z tohoto důvodu obvykle používáme druhý způsob,
kdy sice rozdělíme IP adresy mezi stanice napevno, ale
uložíme toto rozdělení na server, který pak stanicím tyto
informace pomocí protokolu BOOTP nebo DHCP distribuuje. Výhodou
tohoto řešení je, že změny provádíme na jednom místě, nemusíme
obcházet stanice, omezíme možný výskyt chyb a zjednodušíme
konfiguraci stanic. IP adresy přidělujeme podle hardwarové
adresy síťové karty (MAC adresa) a spolu s IP je zapisujeme
do konfiguračního souboru BOOTP nebo DHCP démona na serveru.
BOOTP démon umí odpovídat i na DHCP dotazy stanic a jeho
konfigurační soubor může vypadat třeba takto:
Pokud bychom chtěli využít poslední možnosti (dynamické
přidělování dynamických IP adres), použijeme démona DHCP. Ten
umí dotazy stanic obsloužit tak, že přidělí na dotaz
stanice nějakou volnou IP adresu ze stanoveného rozsahu.
To znamená pro správce méně starostí, ovšem znemožnujě
vytváření různých statistických vyhodnocení provozu
lokální sítě (stanice mají různé IP adresy podle toho, jak
se na ně dotazují serveru). Obě zmíněné metody lze samozřejmě
kombinovat.
.allhost: ht=ethernet:\
:ds=10.0.1.1:\
:sm=255.255.255.0:\
:dn=zsles.edulib.cz:
.net1: tc=.allhost: gw=10.0.1.1:
# ************** NET1 ***************
salome: tc=.net1: ha=00608C92C53B:ip=10.0.1.1:
sekretariat: tc=.net1: ha=006008AB5D6D:ip=10.0.1.10:
pc1: tc=.net1: ha=00C06C241711:ip=10.0.1.101:
pc2: tc=.net1: ha=00C06C237693:ip=10.0.1.102:
pc3: tc=.net1: ha=00C06C240911:ip=10.0.1.103:
----------------------------------------------------------
| Network | Netmask | Network Addresses |
| Class | | |
----------------------------------------------------------
| A | 255.0.0.0 | 0.0.0.0 - 127.255.255.255 |
| B | 255.255.0.0 | 128.0.0.0 - 191.255.255.255 |
| C | 255.255.255.0 | 192.0.0.0 - 223.255.255.255 |
|Multicast| 240.0.0.0 | 224.0.0.0 - 239.255.255.255 |
----------------------------------------------------------
Zprovoznění DNS pro lokální počítače
Je více, než vhodné, nastavit DNS pro všechny počítače z vnitřní sítě.
Ušetříte si starosti s timeouty DNS u různých služeb, logy budou jasné
a budete moci vytvářet přehledné statistiky. Démon, který zajišťuje
DNS, se jmenuje BIND. V následujícím příkladu je nadefinována doména
zsles.edulib.cz, přidělené IP adresy jsou ze sítě 10.0.1.0 (1, 101 a
102). Démon je nastaven tak, aby veškeré dotazy směroval
na DNS servery providera (147.230.16.1 a 192.108.150.100) a umožnil
tak v co největší míře uplatnění cachování a tím zrychlení
odezev.
Soubor /etc/dns/named.root najdeme na URL:
ftp://ftp.rs.internic.net/domain/named.root
/etc/named.conf
===============
options {
directory "/etc/dns";
forwarders {
147.230.16.1;
192.108.150.10;
};
};
zone "." {
type hint;
file "named.root";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "named.local";
};
zone "zsles.edulib.cz" {
type master;
file "zsles.hosts";
};
zone "1.0.10.in-addr.arpa" {
type master;
file "zsles.rev";
};
/etc/dns/named.local
====================
@ IN SOA localhost. root.localhost. (
1997022700 ; Serial
28800 ; Refresh
14400 ; Retry
3600000 ; Expire
86400 ) ; Minimum
IN NS localhost.
1 IN PTR localhost.
/etc/dns/zsles.hosts
====================
@ IN SOA salome.zsles.edulib.cz. kerslage.zsles.edulib.cz. (
97031600
86400
3600
3600000
3600
)
IN NS salome.zsles.edulib.cz.
IN TXT "Zakladni skola Lesni Liberec"
; loopback address
localhost IN A 127.0.0.1
; Aliases
www IN CNAME salome.zsles.edulib.cz.
ftp IN CNAME salome.zsles.edulib.cz.
cache IN CNAME salome.zsles.edulib.cz.
salome IN A 10.0.1.1
IN MX 0 salome.zsles.edulib.cz.
pc1 IN A 10.0.1.101
pc2 IN A 10.0.1.102
/etc/dns/zsles.rev
==================
@ IN SOA salome.zsles.edulib.cz. salome.zsles.edulib.cz. (
97031600
86400
3600
3600000
3600
)
IN NS salome.zsles.edulib.cz.
1 IN PTR salome.zsles.edulib.cz.
101 IN PTR pc1.zsles.edulib.cz.
102 IN PTR pc2.zsles.edulib.cz.
Diald
Diald je démon, který umožňuje automatické navazování spojení
s providerem, když se vyskytne požadavek na vytvoření spojení.
Nejjednodušší je, když použijeme již funkční navazování
spojení pomocí pppd. Podmínky pro vytáčení a ukončení spojení
definujeme ve zvláštním souboru, kde lze rozepsat jednotlivé
typy datagramů a závislosti v chování diald na ně. Například
ignorovat nebo po průchodu tohoto datagramu držet ještě
další 3 minuty linku v provozu. Pokud se diald nechová tak,
ja bychom potřebovali, můžeme použít na sledování program tcpdump,
který připojíme k rozhraní sl0. Diald totiž vytváří speciální
default route do tohoto rozhraní, kde odchytává pokusy o odeslání
datagramů do Intenetu.
/etc/diald.conf
může vypadat třeba takto:
Chatovací skript použijeme z již funkční pppd konfigurace, local a
remote adresy mohou být libovolné, protože se nakonec použijí adresy
dohodnuté v rámci PPP komunikace se serverem. Soubor
mode ppp
connect "/usr/sbin/chat -f /etc/sysconfig/network-scripts/chat-ppp0"
device /dev/modem
speed 19200
modem
lock
crtscts
local 192.168.250.1
remote 192.168.250.2
dynamic
#dslip-mode remote-local
mtu 576
defaultroute
include /usr/lib/diald/standard.filter
standard.filter
je již zmíněný soubor pravidel, je vhodné
vycházet ze standardně dodávaného. Menší MTU může zvýšit
interaktivitu, ale naopak způsobuje problémy s navazováním komunikace,
když se protější strana nechová korektně.
Squid
Squid je výborná proxy cache pro WWW klienty. Má velmi široké
možnosti konfigurace. Za nejhlavnější můžeme považovat možnost
spolupráce s dalšími proxy. Pokud používáme Squid za modemovou linkou,
je vhodné vypnout digesty, popřípadě i ICMP (Squid pinká na své
sousedy, aby zjistil, zda jsou na živu), které jen generují
provoz, který může naší linku v horším případě i zahltit.
Dlužno dodat, že Squid v nové řadě stadardně poskytuje své služby
jen požadavkům vycházejícím z jedné a té samé mašiny, na které běží.
Povolení využívat proxy definuje acl nasesit. Acl local-servers
zajišťuje direct přístup k lokálním serverům bez generování
zbytečných dotazů na okolní spolupracující proxy. Rozumné hodnoty
bude potřeba nastavit u položek cache_dir a cache_mem.
Squid umí pomocí CGI skriptu cachemgr.cgi poskytovat za běhu
užitečné informace. Přístup k nim zajišťují položky
cache_mgr.
cache_peer cache.li.cesnet.cz parent 3128 3130 weight=100
cache_peer cache.cesnet.cz parent 3128 3130 weight=50
cache_peer cache2.cesnet.cz parent 3128 3130 weight=40
cache_mem 48 MB
cache_dir /var/cache 1800 75 256
ftp_user Squid@spsselib.hiedu.cz
dns_children 10
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl all src 0.0.0.0/0.0.0.0
acl nasesit src 194.108.45.0/255.255.255.0
acl local-servers dst 194.108.45.0/255.255.255.0
acl SSL_ports port 443 563
acl Safe_ports port 80 21 443 563 70 210 1025-65535
acl CONNECT method CONNECT
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow nasesit
http_access deny all
icp_access allow all
miss_access allow all
cache_mgr webmaster@spsselib.hiedu.cz
cache_effective_user squid
cache_effective_group squid
visible_hostname cache.spsselib.hiedu.cz
logfile_rotate 20
append_domain .spsselib.hiedu.cz
cachemgr_passwd tajneheslo all
cachemgr_passwd none client_list
always_direct allow local-servers
error_directory /etc/squid/errors/Czech
Sendmail
Příklad konfigurace uzlu, který veškerou příchozí poštu předává
na počítač PRUM s Mercurym.
neptun.m4 - definiční soubor pro RedHat (sendmail 8.9.3)
========================================================
divert(-1)
include(`/usr/lib/sendmail-cf/m4/cf.m4')
define(`confDEF_USER_ID',``8:12'')
define(`PROCMAIL_MAILER_PATH', `/usr/bin/procmail')
define(`confEBINDIR', `/usr/sbin/smrsh')
define(`confTRY_NULL_MX_LIST', True)
OSTYPE(`linux')
undefine(`UUCP_RELAY')
undefine(`BITNET_RELAY')
FEATURE(relay_entire_domain)
FEATURE(redirect)
FEATURE(always_add_domain)
FEATURE(use_cw_file)
FEATURE(local_procmail)
FEATURE(smrsh)
FEATURE(access_db, `hash -o /etc/mail/access')
FEATURE(blacklist_recipients)
FEATURE(rbl)
FEATURE(mailertable, `hash -o /etc/mail/mailertable')
MAILER(procmail)
MAILER(smtp)
mailertable - pošta pro doménu spsselib.hiedu.cz je předávána na PRUM
=====================================================================
spsselib.hiedu.cz esmtp:prum.spsselib.hiedu.cz
access - konfigurace antispamových a antirelayingových pravidel
===============================================================================
#
# Neptun /etc/mail/access file
#
holecek.cz 550 You are a known spammer
194.108.45 RELAY
194.212.146.66 RELAY
194.212.146.129 RELAY
Makefile - automatická výroba (po změně zadej "make")
=====================================================
# autom. vyroba souboru
WHAT = access.db mailertable.db sendmail.cf
all: $(WHAT)
access.db: access
makemap hash access < access
mailertable.db: mailertable
makemap hash mailertable.db < mailertable
sendmail.cf: neptun.m4
m4 neptun.m4 > sendmail.cf
cp -i sendmail.cf /etc
/etc/rc.d/init.d/sendmail restart