path: root/hu_HU.ISO8859-2/books/handbook/network-servers/chapter.xml

<?xml version="1.0" encoding="iso-8859-2"?>
<!--
     The FreeBSD Documentation Project

     $FreeBSD$
-->

<!-- The FreeBSD Hungarian Documentation Project
     Translated by: PALI, Gabor <pgj@FreeBSD.org>
     %SOURCE%	en_US.ISO8859-1/books/handbook/network-servers/chapter.xml
     %SRCID%	1.125
-->

<chapter id="network-servers" lang="hu">
  <chapterinfo>
    <authorgroup>
      <author>
	<firstname>Murray</firstname>
	<surname>Stokely</surname>
	<contrib>Átdolgozta: </contrib>
      </author>
    </authorgroup>
  </chapterinfo>

  <title>Hálózati szerverek</title>

  <sect1 id="network-servers-synopsis">
    <title>Áttekintés</title>

    <para>Ebben a fejezetben a &unix; típusú rendszerekben
      leggyakrabban alkalmazott hálózati
      szolgáltatások közül fogunk
      néhányat bemutatni.  Ennek során
      megismerjük a hálózati
      szolgáltatások különbözõ
      típusainak telepítését,
      beállítását, tesztelését
      és karbantartását.  A fejezet
      tartalmát folyamatosan példákkal
      igyekszünk illusztrálni.</para>

    <para>A fejezet elolvasása során
      megismerjük:</para>

    <itemizedlist>

      <listitem>
	<para>hogyan dolgozzunk az <application>inetd</application>
	  démonnal;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsuk be a hálózati
	  állományrendszereket;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsunk be egy
	  hálózati információs szervert a
	  felhasználói hozzáférések
	  megosztására;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsuk be automatikusan a
	  hálózati
	  hozzáférésünket a DHCP
	  használatával;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsunk be névfeloldó
	  szervereket;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsuk be az
	  <application>Apache</application> webszervert;</para>
      </listitem>

      <listitem>
	<para>hogyan állítsuk be az
	  állományok átviteléért
	  felelõs (FTP) szervert;</para>
      </listitem>

      <listitem>
	<para>a <application>Samba</application>
	  használatával hogyan állítsunk be
	  &windows;-os kliensek számára
	  állomány- és
	  nyomtatószervert;</para>
      </listitem>

      <listitem>
	<para>az NTP protokoll segítségével hogyan
	  egyeztessük az idõt és dátumot, hogyan
	  állítsunk be egy idõszervert;</para>
      </listitem>

      <listitem>
	<para>a szabványos naplózó démon, a
	  <command>syslogd</command>
	  beállítását hálózati
	  keresztüli naplózásra.</para>
      </listitem>
    </itemizedlist>

    <para>A fejezet elolvasásához ajánlott:</para>

    <itemizedlist>
      <listitem>
	<para>az <filename>/etc/rc</filename> szkriptek alapjainak
	  ismerete;</para>
      </listitem>

      <listitem>
	<para>az alapvetõ hálózati fogalmak
	  ismerete;</para>
      </listitem>

      <listitem>
	<para>a külsõ szoftverek
	  telepítésének ismerete (<xref
	  linkend="ports"/>).</para>
      </listitem>
    </itemizedlist>
  </sect1>

  <sect1 id="network-inetd">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Chern</firstname>
	  <surname>Lee</surname>
	  <contrib>Készítette: </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <contrib>A &os;&nbsp;6.1-RELEASE változatához
	    igazította: </contrib>
	  <othername>A &os; Dokumentációs
	    Projekt</othername>
	</author>
      </authorgroup>
    </sect1info>

    <title>Az <application>inetd</application>
      <quote>szuperszerver</quote></title>

    <sect2 id="network-inetd-overview">
      <title>Áttekintés</title>

      <para>Az &man.inetd.8; démont gyakran csak <quote>internet
	szuperszerverként</quote> nevezik, mivel a helyi
	szolgáltatások kapcsolatainak
	kezeléséért felelõs.  Amikor az
	<application>inetd</application> fogad egy csatlakozási
	kérelmet, akkor eldönti róla, hogy ez melyik
	programhoz tartozik és elindít egy
	példányt belõle, majd átadja neki a
	socketet (az így meghívott program a
	szabvány bemenetéhez, kimenetéhez és
	hibajelzési csatornájához kapja meg a
	socket leíróit).  Az
	<application>inetd</application> használatával
	úgy tudjuk csökkenteni a rendszerünk
	terhelését, hogy a csak alkalmanként
	meghívott szolgáltatásokat nem futtatjuk
	teljesen független önálló
	módban.</para>

      <para>Az <application>inetd</application> démont
	elsõsorban más démonok
	elindítására használjuk, de
	néhány triviális protokollt
	közvetlenül is képes kezelni, mint
	például a <application>chargen</application>,
	<application>auth</application> és a
	<application>daytime</application>.</para>

      <para>Ebben a fejezetben az <application>inetd</application>
	beállításának alapjait foglaljuk
	össze mind parancssoros módban, mind pedig az
	<filename>/etc/inetd.conf</filename> konfigurációs
	állományon keresztül.</para>

    </sect2>

    <sect2 id="network-inetd-settings">
      <title>Beállítások</title>

      <para>Az <application>inetd</application>
	mûködése az &man.rc.8; rendszeren
	keresztül inicializálható.  Az
	<literal>inetd_enable</literal> ugyan alapból a
	<literal>NO</literal> értéket veszi fel, vagyis
	tiltott, de a <application>sysinstall</application>
	használatával már akár a
	telepítés során bekapcsolható
	attól függõen, hogy a felhasználó
	milyen konfigurációt választott.  Ha
	tehát a:</para>

      <programlisting>inetd_enable="YES"</programlisting>

      <para>vagy</para>

      <programlisting>inetd_enable="NO"</programlisting>

      <para>sort tesszük az <filename>/etc/rc.conf</filename>
	állományba, akkor azzal az
	<application>inetd</application> démont
	indíthatjuk el vagy tilthatjuk le a rendszer
	indítása során.  Az</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/inetd rcvar</userinput></screen>

      <para>paranccsal lekérdezhetjük a pillanatnyilag
	érvényes beállítást.</para>

      <para>Emellett még az <application>inetd</application>
	démonnak az <literal>inetd_flags</literal>
	változón keresztül
	különbözõ parancssori paramétereket
	is át tudunk adni.</para>

    </sect2>

    <sect2 id="network-inetd-cmdline">
      <title>Parancssori paraméterek</title>

      <para>Hasonlóan a legtöbb szerverhez, az
	<application>inetd</application> viselkedését is
	befolyásolni tudjuk a parancssorban
	átadható különbözõ
	paraméterekkel.  Ezek teljes listája a
	következõ:</para>

      <para><command>inetd</command> <option>[-d] [-l] [-w] [-W] [-c
	maximum] [-C arány] [-a cím | név] [-p
	állomány] [-R arány] [-s maximum]
	[konfigurációs
	állomány]</option></para>

      <para>Ezek a paraméterek az
	<filename>/etc/rc.conf</filename> állományban az
	<literal>inetd_flags</literal> segítségével
	adhatóak meg az <application>inetd</application>
	részére.  Alapértelmezés szerint az
	<literal>inetd_flags</literal> értéke <literal>-wW
	-C 60</literal>, ami az <application>inetd</application>
	által biztosított szolgáltatások TCP
	protokollon keresztüli wrappelését kapcsolja
	be, illetve egy IP-címrõl nem engedi a
	felkínált szolgáltatások
	elérését percenként hatvannál
	többször.</para>

      <para>A kezdõ felhasználók örömmel
	nyugtázhatják, hogy ezeket az
	alapbeállításokat nem szükséges
	módosítaniuk.  A késõbbiekben majd
	fény derül arra, hogy a kiszolgálás
	gyakoriságának szabályozása remek
	védekezést nyújthat túlzottan nagy
	mennyiségû kapcsolódási kérelem
	ellen.  A megadható paraméterek teljes
	listája az &man.inetd.8; man oldalán
	olvasható.</para>

      <variablelist>
	<varlistentry>
	  <term>-c <replaceable>maximum</replaceable></term>

	  <listitem>
	    <para>Az egyes szolgáltatásokhoz egyszerre
	      felépíthetõ kapcsolatok
	      alapértelmezett maximális
	      számát adja meg.  Alapból ezt a
	      démont nem korlátozza.  A
	      <option>max-child</option>
	      beállítással ez akár
	      szolgáltatásonként külön is
	      megadható.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>-C <replaceable>arány</replaceable></term>

	  <listitem>
	    <para>Korlátozza, hogy egyetlen IP-címrõl
	      alapból hányszor hívhatóak meg
	      az egyes szolgáltatások egy percen
	      belül.  Ez az érték alapból
	      korlátlan.  A
	      <option>max-connections-per-ip-per-minute</option>
	      beállítással ez
	      szolgáltatásonként is
	      definiálható.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>-R <replaceable>arány</replaceable></term>

	  <listitem>
	    <para>Megadja, hogy egy szolgáltatást egy perc
	      alatt mennyiszer lehet meghívni.  Ez az
	      érték alapértelmezés szerint
	      256.  A 0 megadásával
	      eltöröljük ezt a típusú
	      korlátozást.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>-s <replaceable>maximum</replaceable></term>

	  <listitem>
	    <para>Annak maximumát adja meg, hogy egyetlen
	      IP-címrõl egyszerre az egyes
	      szolgáltatásokat mennyiszer tudjuk
	      elérni.  Alapból ez korlátlan.
	      Szolgáltatásonként ezt a
	      <option>max-child-per-ip</option> paraméterrel
	      tudjuk felülbírálni.</para>
	  </listitem>
	</varlistentry>
      </variablelist>
    </sect2>

    <sect2 id="network-inetd-conf">
      <title>Az <filename>inetd.conf</filename>
	állomány</title>

      <para>Az <application>inetd</application>
	beállítását az
	<filename>/etc/inetd.conf</filename> konfigurációs
	állományon keresztül végezhetjük
	el.</para>

      <para>Amikor az <filename>/etc/inetd.conf</filename>
	állományban módosítunk valamit, az
	<application>inetd</application> démont a
	következõ paranccsal meg kell kérnünk,
	hogy olvassa újra:</para>

      <example id="network-inetd-reread">
	<title>Az <application>inetd</application>
	  konfigurációs állományának
	  újraolvasása</title>

	<screen>&prompt.root; <userinput>/etc/rc.d/inetd reload</userinput></screen>
      </example>

      <para>A konfigurációs állomány minden
	egyes sora egy-egy démont ír le.  A
	megjegyzéseket egy <quote>#</quote> jel vezeti be.  Az
	<filename>/etc/inetd.conf</filename> állomány
	bejegyzéseinek formátuma az alábbi:</para>

      <programlisting><replaceable>szolgáltatás-neve</replaceable>
<replaceable>socket-típusa</replaceable>
<replaceable>protokoll</replaceable>
{wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]
<replaceable>felhasználó</replaceable>[:<replaceable>csoport</replaceable>][/<replaceable>bejelentkezési-osztály</replaceable>]
<replaceable>szerver-program</replaceable>
<replaceable>szerver-program-paraméterei</replaceable></programlisting>

      <para>Az IPv4 protokollt használó &man.ftpd.8;
	démon bejegyzése például így
	néz ki:</para>

      <programlisting>ftp     stream  tcp     nowait  root    /usr/libexec/ftpd       ftpd -l</programlisting>

      <variablelist>
	<varlistentry>
	  <term>szolgáltatás-neve</term>

	  <listitem>
	    <para>Ez az adott démon által képviselt
	      szolgáltatást nevezi meg, amelynek
	      szerepelnie kell az <filename>/etc/services</filename>
	      állományban.  Ez határozza meg, hogy
	      az <application>inetd</application> milyen porton figyelje
	      a beérkezõ kapcsolatokat.  Ha egy új
	      szolgáltatást hozunk létre, akkor azt
	      elõször az <filename>/etc/services</filename>
	      állományba kell felvennünk.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>csatlakozás-típusa</term>

	  <listitem>
	    <para>Ennek az értéke
	      <literal>stream</literal>, <literal>dgram</literal>,
	      <literal>raw</literal>, vagy <literal>seqpacket</literal>
	      lehet.  A <literal>stream</literal> típust
	      használja a legtöbb kapcsolat-orientált
	      TCP démon, miközben a <literal>dgram</literal>
	      típus az <acronym>UDP</acronym>
	      szállítási protokollt
	      alkalmazó démonok esetében
	      használatos.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>protokoll</term>

	  <listitem>
	    <para>Valamelyik a következõk
	      közül:</para>

	    <informaltable frame="none" pgwide="1">
	      <tgroup cols="2">
		<thead>
		  <row>
		    <entry>Protokoll</entry>
		    <entry>Magyarázat</entry>
		  </row>
		</thead>
		<tbody>
		  <row>
		    <entry>tcp, tcp4</entry>
		    <entry>TCP IPv4</entry>
		  </row>
		  <row>
		    <entry>udp, udp4</entry>
		    <entry>UDP IPv4</entry>
		  </row>
		  <row>
		    <entry>tcp6</entry>
		    <entry>TCP IPv6</entry>
		  </row>
		  <row>
		    <entry>udp6</entry>
		    <entry>UDP IPv6</entry>
		  </row>
		  <row>
		    <entry>tcp46</entry>
		    <entry>TCP IPv4 és v6</entry>
		  </row>
		  <row>
		    <entry>udp46</entry>
		    <entry>UDP IPv4 és v6</entry>
		  </row>
		</tbody>
	      </tgroup>
	    </informaltable>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>{wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]]</term>

	  <listitem>
	    <para>A <option>wait|nowait</option>
	      beállítás mondja meg, hogy az
	      <application>inetd</application> démonból
	      meghívott démon saját maga
	      képes-e kezelni kapcsolatokat.  A
	      <option>dgram</option> típusú kapcsolatok
	      esetében egyértelmûen a
	      <option>wait</option> beállítást kell
	      használni, miközben a <option>stream</option>
	      esetén, ahol általában több
	      szálon dolgozunk, a <option>nowait</option>
	      megadása javasolt.  A <option>wait</option>
	      hatására általában egyetlen
	      démonnak adunk át több socketet,
	      míg a <option>nowait</option> minden sockethez egy
	      újabb példányt indít
	      el.</para>

	    <para>Az <application>inetd</application> által
	      indítható példányokat a
	      <option>max-child</option> megadásával
	      korlátozhatjuk.  Ha tehát
	      például az adott démon
	      számára legfeljebb példány
	      létrehozását
	      engedélyezzük, akkor a <option>nowait</option>
	      után <literal>/10</literal>
	      beállítást kell megadnunk.  A
	      <literal>/0</literal> használatával
	      korlátlan mennyiségû
	      példányt
	      engedélyezhetünk.</para>

	    <para>A <option>max-child</option> mellett még
	      további két másik
	      beállítás jöhet
	      számításba az egyes démonok
	      által kezelhetõ kapcsolatok maximális
	      számának
	      korlátozásában.  A
	      <option>max-connections-per-ip-per-minute</option> az
	      egyes IP-címekrõl befutó
	      lekezelhetõ kapcsolatok percenkénti
	      számát szabályozza, így
	      például ha itt a tizes értéket
	      adjuk meg, akkor az adott szolgáltatáshoz
	      egy IP-címrõl percenként csak
	      tízszer férhetünk hozzá.  A
	      <option>max-child-per-ip</option> az egyes
	      IP-címekhez egyszerre elindítható
	      példányok számára ír
	      elõ egy korlátot.  Ezek a paraméterek
	      segítenek megóvni rendszerünket az
	      erõforrások akaratos vagy akaratlan
	      kimerítésétõl és a DoS
	      (Denial of Service) típusú
	      támadásoktól.</para>

	    <para>Ebben a mezõben a <option>wait</option> vagy
	      <option>nowait</option> valamelyikét
	      kötelezõ megadni.  A <option>max-child</option>,
	      <option>max-connections-per-ip-per-minute</option>
	      és <option>max-child-per-ip</option>
	      paraméterek ellenben elhagyhatóak.</para>

	    <para>A <option>stream</option> típusú
	      több szálon futó démonok a
	      <option>max-child</option>,
	      <option>max-connections-per-ip-per-minute</option> vagy
	      <option>max-child-per-ip</option>
	      korlátozása nélkül
	      egyszerûen csak így adhatóak meg:
	      <literal>nowait</literal>.</para>

	    <para>Ha ugyanezt a démont tíz kapcsolatra
	      lekorlátozzuk, akkor a következõt kell
	      megadnunk: <literal>nowait/10</literal>.</para>

	    <para>Amikor pedig IP-címenként 20 kapcsolatot
	      engedélyezünk percenként és
	      mindössze 10 példányt, akkor:
	      <literal>nowait/10/20</literal>.</para>

	    <para>Az iménti beállítások a
	      &man.fingerd.8; démon alapértelmezett
	      paramétereinél is
	      megtalálhatóak:</para>

	    <programlisting>finger stream  tcp     nowait/3/10 nobody /usr/libexec/fingerd fingerd -s</programlisting>

	    <para>Végezetül engedélyezzük 100
	      példányt, melyek közül
	      IP-címenként 5 használható:
	      <literal>nowait/100/0/5</literal>.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>felhasználó</term>

	  <listitem>
	    <para>Ezzel azt a felhasználót adjuk meg,
	      akinek a nevében az adott démon futni fog.
	      Az esetek túlnyomó részében a
	      démonokat a <username>root</username>
	      felhasználó futtatja.  Láthatjuk
	      azonban, hogy biztonsági okokból bizonyos
	      démonok a <username>daemon</username> vagy a
	      legkevesebb joggal rendelkezõ
	      <username>nobody</username> felhasználóval
	      futnak.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>szerver-program</term>

	  <listitem>
	    <para>A kapcsolat felépülésekor az itt
	      teljes elérési úttal megadott
	      démon indul el.  Ha ezt a
	      szolgáltatást maga az
	      <application>inetd</application> belsõleg
	      valósítja meg, akkor ebben a mezõben az
	      <option>internal</option> értéket adjuk
	      meg.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term>szerver-program-paraméterei</term>

	  <listitem>
	    <para>Ez a <option>szerver-program</option>
	      beállítással együtt
	      mûködik, és ebben a mezõben a
	      démon meghívásakor
	      alkalmazandó paramétereket tudjuk
	      rögzíteni, amelyet a démon
	      nevével kezdünk.  Ha a démont a
	      parancssorból a
	      <command><replaceable>sajátdémon</replaceable>
	      -d</command> paranccsal hívnánk meg, akkor a
	      <literal><replaceable>sajátdémon</replaceable>
	      -d</literal> lesz
	      <option>szerver-program-paraméterei</option>
	      beállítás helyes értéke
	      is.  Természetesen, ha a démon egy
	      belsõleg megvalósított
	      szolgáltatás, akkor ebben a mezõben is
	      az <option>internal</option> fog megjelenni.</para>
	  </listitem>
	</varlistentry>
      </variablelist>
    </sect2>

    <sect2 id="network-inetd-security">
      <title>Védelem</title>

      <para>Attól függõen, hogy a
	telepítés során mit választottunk,
	az <application>inetd</application> által
	támogatott szolgáltatások egyes
	része talán alapból engedélyezett
	is.  Amennyiben egy adott démont konkrétan nem
	használunk, akkor érdemes megfontolni a
	letiltását.  A kérdéses démon
	sorába tegyünk egy <quote>#</quote> jelet az
	<filename>/etc/inetd.conf</filename> állományba,
	majd <link linkend="network-inetd-reread">olvastassuk
	újra az inetd beállításait</link>.
	Egyes démonok, mint például az
	<application>fingerd</application> használata
	egyáltalán nem ajánlott, mivel a
	támadók számára hasznos
	információkat tudnak
	kiszivárogtatni.</para>

      <para>Más démonok nem ügyelnek a
	védelemre, és a kapcsolatokhoz rendelt
	lejárati idejük túlságosan
	hosszú vagy éppen nincs is.  Ezzel a
	támadónak lehetõsége van lassú
	kapcsolatokkal leterhelni az adott démont, ezáltal
	kimeríteni a rendszer erõforrásait.  Ha
	úgy találjuk, hogy túlságosan sok az
	ilyen kapcsolat, akkor jó ötletnek bizonyulhat a
	démonok számára a
	<option>max-connections-per-ip-per-minute</option>,
	<option>max-child</option> vagy
	<option>max-child-per-ip</option> korlátozások
	elrendelése.</para>

      <para>Alapértelmezés szerint a TCP kapcsolatok
	wrappelése engedélyezett.  A &man.hosts.access.5;
	man oldalon találhatjuk meg az
	<application>inetd</application> által
	meghívható különféle
	démonok TCP-alapú korlátozásainak
	lehetõségeit.</para>

    </sect2>

    <sect2 id="network-inetd-misc">
      <title>Egyéb lehetõségek</title>

      <para>A <application>daytime</application>,
	<application>time</application>,
	<application>echo</application>,
	<application>discard</application>,
	<application>chargen</application> és
	<application>auth</application> szolgáltatások
	feladatainak mindegyikét maga az
	<application>inetd</application> is képes
	ellátni.</para>

      <para>Az <application>auth</application>
	szolgáltatás a hálózati
	keresztül azonosítást teszi
	lehetõvé és bizonyos mértékig
	beállítható.  A többit egyszerûen
	csak kapcsoljuk ki vagy be.</para>

      <para>A témában az &man.inetd.8; man oldalán
	tudunk még jobban elmerülni.</para>

    </sect2>
  </sect1>

  <sect1 id="network-nfs">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Átdolgozta és javította:
	    </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Bill</firstname>
	  <surname>Swingle</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>A hálózati állományrendszer
      (NFS)</title>

    <indexterm><primary>NFS</primary></indexterm>

    <para>A &os; több állományrendszert ismer,
      köztük a hálózati
      állományrendszert (Network File System, <acronym
      role="Network File System">NFS</acronym>) is.  Az <acronym
      role="Network File System">NFS</acronym> állományok
      és könyvtárak megosztását teszi
      lehetõvé a hálózaton keresztül.  Az
      <acronym role="Network File System">NFS</acronym>
      használatával a felhasználók és
      a programok képesek majdnem úgy elérni a
      távoli rendszereken található
      állományokat, mintha helyben
      léteznének.</para>

    <para>Íme az <acronym>NFS</acronym> néhány
      legjelentõsebb elõnye:</para>

    <itemizedlist>
      <listitem>
	<para>A helyi munkaállomások kevesebb
	  tárterületet használnak, mivel a
	  közös adatokat csak egyetlen
	  számítógépen tároljuk
	  és megosztjuk mindenki között.</para>
      </listitem>

      <listitem>
	<para>A felhasználóknak nem kell a
	  hálózat minden egyes gépén
	  külön felhasználói
	  könyvtárral rendelkezniük.  Ezek ugyanis az
	  <acronym>NFS</acronym> segítségével
	  akár egy szerveren is
	  beállíthatóak és
	  elérhetõvé tehetõek a
	  hálózaton keresztül.</para>
      </listitem>

      <listitem>
	<para>A különbözõ
	  háttértárak, mint például a
	  floppy lemezek, CD-meghajtók és &iomegazip;
	  meghajtók a hálózaton több
	  számítógép között
	  megoszthatóak.  Ezzel csökkenteni tudjuk a
	  hálózatunkban szükséges
	  cserélhetõ lemezes eszközök
	  számát.</para>
      </listitem>
    </itemizedlist>

    <sect2>
      <title>Ahogy az <acronym>NFS</acronym> mûködik</title>

      <para>Az <acronym>NFS</acronym> legalább két fõ
	részbõl rakható össze: egy
	szerverbõl és egy vagy több kliensbõl.  A
	kliensek a szerver által megosztott adatokhoz
	képesek távolról hozzáférni.
	A megfelelõ mûködéshez mindössze csak
	néhány programot kell beállítani
	és futtatni.</para>

      <para>A szervernek a következõ démonokat kell
	mûködtetnie:</para>

      <indexterm>
	<primary>NFS</primary>
	<secondary>szerver</secondary>
      </indexterm>
      <indexterm>
	<primary>állományszerver</primary>
	<secondary>UNIX kliensek</secondary>
      </indexterm>

      <indexterm>
	<primary><application>rpcbind</application></primary>
      </indexterm>
      <indexterm>
	<primary><application>mountd</application></primary>
      </indexterm>
      <indexterm>
	<primary><application>nfsd</application></primary>
      </indexterm>

      <informaltable frame="none" pgwide="1">
	<tgroup cols="2">
	  <colspec colwidth="1*"/>
	  <colspec colwidth="3*"/>

	  <thead>
	    <row>
	      <entry>Démon</entry>
	      <entry>Leírás</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry><application>nfsd</application></entry>
	      <entry>Az <acronym>NFS</acronym> démon, amely
		kiszolgálja az <acronym>NFS</acronym>
		kliensektõl érkezõ
		kéréseket.</entry>
	    </row>
	    <row>
	      <entry><application>mountd</application></entry>
	      <entry>Az <acronym>NFS</acronym> csatlakoztató
		démonja, amely végrehajtja az &man.nfsd.8;
		által átküldött
		kéréseket.</entry>
	    </row>
	    <row>
	      <entry><application>rpcbind</application></entry>
	      <entry>Ez a démon lehetõvé teszi az
		<acronym>NFS</acronym> kliensek számára,
		hogy fel tudják deríteni az
		<acronym>NFS</acronym> szerver által
		használt portot.</entry>
	    </row>
	  </tbody>
	</tgroup>
      </informaltable>

      <para>A kliensen is futnia kell egy démonnak, amelynek a
	neve <application>nfsiod</application>.  Az
	<application>nfsiod</application> démon az
	<acronym>NFS</acronym> szerver felõl érkezõ
	kéréseket szolgálja ki.  A
	használata teljesen opcionális, csupán a
	teljesítményt hívatott javítani, de
	a normális és helyes mûködéshez
	nincs rá szükségünk.  Az &man.nfsiod.8;
	man oldalán errõl többet is
	megtudhatunk.</para>

    </sect2>

    <sect2 id="network-configuring-nfs">
      <title>Az <acronym>NFS</acronym>
	beállítása</title>

      <indexterm>
	<primary>NFS</primary>
	<secondary>beállítás</secondary>
      </indexterm>

      <para>Az <acronym>NFS</acronym> beállítása
	viszonylag egyértelmûen adja magát.  A
	mûködéséhez szükséges
	programok automatikus elindítása csupán
	néhány apró módosítást
	igényel az <filename>/etc/rc.conf</filename>
	állományban.</para>

      <para>Az <acronym>NFS</acronym> szerveren gondoskodjunk
	róla, hogy az alábbi
	beállítások szerepeljenek az
	<filename>/etc/rc.conf</filename>
	állományban:</para>

      <programlisting>rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"</programlisting>

      <para>A <application>mountd</application> magától el
	fog indulni, ha az <acronym>NFS</acronym> szervert
	engedélyezzük.</para>

      <para>A kliensen a következõ
	beállítást kell felvennünk az
	<filename>/etc/rc.conf</filename>
	állományba:</para>

      <programlisting>nfs_client_enable="YES"</programlisting>

      <para>Az <filename>/etc/exports</filename> állomány
	adja meg, hogy az <acronym>NFS</acronym> milyen
	állományrendszereket exportáljon (vagy
	másképpen szólva <quote>osszon
	meg</quote>).  Az <filename>/etc/exports</filename>
	állományban tehát a megosztani
	kívánt állományrendszereket kell
	szerepeltetnünk, és azt, hogy melyik
	számítógépekkel tudjuk ezeket
	elérni.  A gépek megnevezése mellett a
	hozzáférésre további
	megszorításokat írhatunk fel.  Ezek
	részletes leírását az
	&man.exports.5; man oldalon találjuk meg.</para>

      <para>Lássunk néhány példát az
	<filename>/etc/exports</filename> állományban
	megjelenõ bejegyzésekre:</para>

      <indexterm>
	<primary>NFS</primary>
	<secondary>példák
	  exportálásra</secondary>
      </indexterm>

      <para>A most következõ példákban az
	állományrendszerek
	exportálásának finomságait
	igyekszünk érzékeltetni, noha a
	konkrét beállítások gyakran a
	rendszerünktõl és a hálózati
	konfigurációtól függenek.
	Például, ha a <filename>/cdrom</filename>
	könytárat akarjuk három gép
	számára megosztani, akik a szerverrel
	megegyezõ tartományban találhatóak
	(ezért nem is kell megadnunk a tartományt) vagy
	mert egyszerûen megtalálhatók az
	<filename>/etc/hosts</filename> állományunkban.
	Az <option>-ro</option> beállítás az
	exportált állományrendszereket
	írásvédetté teszi.  Ezzel a
	beállítással a távoli rendszerek nem
	lesznek képesek módosítani az
	exportált állományrendszer
	tartalmát.</para>

      <programlisting>/cdrom -ro <replaceable>gép1 gép2 gép3</replaceable></programlisting>

      <para>A következõ sorban a <filename>/home</filename>
	könyvtárat három gép
	számára osztjuk meg, melyeket IP-címekkel
	adtunk meg.  Ez olyan helyi hálózat esetén
	hasznos, ahol nem állítottunk be
	névfeloldást.  Esetleg a belsõ
	hálózati neveket az
	<filename>/etc/hosts</filename> állományban is
	tárolhatjuk.  Ezzel utóbbival kapcsolatban a
	&man.hosts.5; man oldalt érdemes fellapoznunk.  Az
	<option>-alldirs</option> beállítás
	lehetõvé teszi, hogy az alkönyvtárak is
	csatlakozási pontok lehessenek.  Más
	szóval, nem fogja csatlakoztatni az
	alkönyvtárakat, de megengedi a kliensek
	számára, hogy csak azokat a
	könyvtárakat csatlakoztassák, amelyeket kell
	vagy amelyekre szükségünk van.</para>

      <programlisting>/home  -alldirs  10.0.0.2 10.0.0.3 10.0.0.4</programlisting>

      <para>A következõ sorban az <filename>/a</filename>
	könyvtárat úgy exportáljuk, hogy az
	állományrendszerhez két
	különbözõ tartományból is
	hozzá lehessen férni.  A
	<option>-maproot=root</option> beállítás
	hatására a távoli rendszer
	<username>root</username> felhasználója az
	exportált állományrendszeren szintén
	<username>root</username> felhasználóként
	fogja írni az adatokat.  Amennyiben a
	<literal>-maproot=root</literal> beállítást
	nem adjuk meg, akkor a távoli rendszeren hiába
	<username>root</username> az adott felhasználó, az
	exportált állományrendszeren nem lesz
	képes egyetlen állományt sem
	módosítani.</para>

      <programlisting>/a  -maproot=root  gep.minta.com doboz.haz.org</programlisting>

      <para>A kliensek is csak a megfelelõ engedélyek
	birtokában képesek elérni a megosztott
	állományrendszereket.  Ezért a klienst ne
	felejtsük el felvenni a szerver
	<filename>/etc/exports</filename>
	állományába.</para>

      <para>Az <filename>/etc/exports</filename>
	állományban az egyes sorok az egyes
	állományrendszerekre és az egyes
	gépekre vonatkoznak.  A távoli gépek
	állományrendszerenként csak egyszer
	adhatóak meg, és csak egy alapértelmezett
	bejegyzésük lehet.  Például
	tegyük fel, hogy a <filename>/usr</filename> egy
	önálló állományrendszer.  Ennek
	megfelelõen az alábbi bejegyzések az
	<filename>/etc/exports</filename> állományban
	érvénytelenek:</para>

      <programlisting># Nem használható, ha a /usr egy állományrendszer:
/usr/src   kliens
/usr/ports kliens</programlisting>

      <para>Egy állományrendszerhez, vagyis itt a
	<filename>/usr</filename> partícióhoz, két
	export sort is megadtunk ugyanahhoz a <hostid>kliens</hostid>
	nevû géphez.  Helyesen így kell megoldani az
	ilyen helyzeteket:</para>

      <programlisting>/usr/src /usr/ports  kliens</programlisting>

      <para>Az adott géphez tartozó egy
	állományrendszerre vonatkozó exportoknak
	mindig egy sorban kell szerepelniük.  A kliens
	nélkül felírt sorok egyetlen géphez
	tartozónak fognak számítani.  Ezzel az
	állományrendszerek megosztását
	tudjuk szabályozni, de legtöbbek
	számára nem jelent gondot.</para>

      <para>Most egy érvényes exportlista következik,
	ahol a <filename>/usr</filename> és az
	<filename>/exports</filename> mind helyi
	állományrendszerek:</para>

      <programlisting># Osszuk meg az src és ports könyvtárakat a kliens01 és kliens02 részére, de csak a
# kliens01 férhessen hozzá rendszeradminisztrátori jogokkal:
/usr/src /usr/ports -maproot=root    kliens01
/usr/src /usr/ports               kliens02
# A kliensek az /exports könyvtárban teljes joggal rendelkeznek és azon belül
# bármit tudnak csatlakoztatni. Rajtuk kívül mindenki csak írásvédetten képes
# elérni az /exports/obj könyvtárat:
/exports -alldirs -maproot=root      kliens01 kliens02
/exports/obj -ro</programlisting>

      <para>A <application>mountd</application> démonnal az
	<filename>/etc/exports</filename> állományt minden
	egyes módosítása után újra be
	kell olvastatni, mivel a változtatásaink csak
	így fognak érvényesülni.  Ezt
	megcsinálhatjuk úgy is, hogy küldünk egy
	HUP (hangup, avagy felfüggesztés) jelzést a
	már futó démonnak:</para>

      <screen>&prompt.root; <userinput>kill -HUP `cat /var/run/mountd.pid`</userinput></screen>

      <para>vagy meghívjuk a <command>mountd</command> &man.rc.8;
	szkriptet a megfelelõ paraméterrel:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/mountd onereload</userinput></screen>

      <para>Az <xref linkend="configtuning-rcd"/>ban tudhatunk meg
	részleteket az rc szkriptek
	használatáról.</para>

      <para>Ezek után akár a &os;
	újraindításával is
	aktiválhatjuk a megosztásokat, habár ez nem
	feltétlenül szükséges.  Ha
	<username>root</username> felhasználónként
	kiadjuk a következõ parancsokat, akkor azzal minden
	szükséges programot elindítunk.</para>

      <para>Az <acronym>NFS</acronym> szerveren tehát:</para>

      <screen>&prompt.root; <userinput>rpcbind</userinput>
&prompt.root; <userinput>nfsd -u -t -n 4</userinput>
&prompt.root; <userinput>mountd -r</userinput></screen>

      <para>Az <acronym>NFS</acronym> kliensen pedig:</para>

      <screen>&prompt.root; <userinput>nfsiod -n 4</userinput></screen>

      <para>Ezzel most már minden készen áll a
	távoli állományrendszer
	csatlakoztatására.  A példákban a
	szerver neve <hostid>szerver</hostid> lesz, valamint a kliens
	neve <hostid>kliens</hostid>.  Ha csak ideiglenesen akarunk
	csatlakoztatni egy állományrendszert vagy
	egyszerûen csak ki akarjuk próbálni a
	beállításainkat, a kliensen
	<username>root</username> felhasználóként
	az alábbi parancsot hajtsuk végre:</para>

      <indexterm>
	<primary>NFS</primary>
	<secondary>csatlakoztatás</secondary>
      </indexterm>

      <screen>&prompt.root; <userinput>mount szerver:/home /mnt</userinput></screen>

      <para>Ezzel a szerveren található
	<filename>/home</filename> könyvtárat fogjuk a
	kliens <filename>/mnt</filename> könyvtárába
	csatlakoztatni.  Ha mindent jól
	beállítottunk, akkor a kliensen most már be
	tudunk lépni az <filename>/mnt</filename>
	könyvtárba és láthatjuk a szerveren
	található állományokat.</para>

      <para>Ha a számítógép
	indításával automatikusan akarunk
	hálózati állományrendszereket
	csatlakoztatni, akkor vegyük fel ezeket az
	<filename>/etc/fstab</filename> állományba.  Erre
	íme egy példa:</para>

      <programlisting>szerver:/home	/mnt	nfs	rw	0	0</programlisting>

      <para>Az &man.fstab.5; man megtalálhatjuk az összes
	többi beállítást.</para>

    </sect2>

    <sect2>
      <title>Zárolások</title>

      <para>Bizonyos alkalmazások (például a
	<application>mutt</application>) csak akkor mûködnek
	megfelelõen, ha az állományokat a
	megfelelõ módon zárolják.  Az
	<acronym>NFS</acronym> esetében az
	<application>rpc.lockd</application> használható
	az ilyen zárolások
	megvalósítására.  Az
	engedélyezéséhez mind a szerveren és
	a kliensen vegyük fel a következõ sort az
	<filename>/etc/rc.conf</filename> állományba (itt
	már feltételezzük, hogy az
	<acronym>NFS</acronym> szervert és klienst
	korábban beállítottuk):</para>

      <programlisting>rpc_lockd_enable="YES"
rpc_statd_enable="YES"</programlisting>

      <para>A következõ módon indíthatjuk
	el:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/lockd start</userinput>
&prompt.root; <userinput>/etc/rc.d/statd start</userinput></screen>

      <para>Ha nincs szükségünk valódi
	zárolásra az <acronym>NFS</acronym> kliensek
	és az <acronym>NFS</acronym> szerver között,
	akkor megcsinálhatjuk azt is, hogy az
	<acronym>NFS</acronym> kliensen a &man.mount.nfs.8; programnak
	az <option>-L</option> paraméter
	átadásával csak helyileg
	végzünk zárolást.  Ennek
	további részleterõl a &man.mount.nfs.8; man
	oldalon kaphatunk felvilágosítást.</para>

    </sect2>

    <sect2>
      <title>Gyakori felhasználási módok</title>

      <para>Az <acronym>NFS</acronym> megoldását a
	gyakorlatban rengeteg esetben alkalmazzák.  Ezek
	közül most felsoroljuk a legelterjedtebbeket:</para>

      <indexterm>
	<primary>NFS</primary>
	<secondary>használata</secondary>
      </indexterm>

      <itemizedlist>
	<listitem>
	  <para>Több gép között megosztunk egy
	    telepítõlemezt vagy más
	    telepítõeszközt.  Ez így sokkal
	    olcsóbb és gyakorta kényelmes
	    megoldás abban az esetben, ha egyszerre több
	    gépre akarjuk ugyanazt a szoftvert
	    telepíteni.</para>
	</listitem>

	<listitem>
	  <para>Nagyobb hálózatokon sokkal
	    kényelmesebb lehet egy központi
	    <acronym>NFS</acronym> szerver használata, ahol a
	    felhasználók könyvtárait
	    tároljuk.  Ezek a felhasználói
	    könyvtárak aztán megoszthatóak a
	    hálózaton keresztül, így a
	    felhasználók mindig ugyanazt a
	    könyvárat kapják függetlenül
	    attól, hogy milyen
	    munkaállomásról is jelentkeztek
	    be.</para>
	</listitem>

	<listitem>
	  <para>Több géppel is képes így
	    osztozni az <filename>/usr/ports/distfiles</filename>
	    könyvtáron.  Ezen a módon sokkal
	    gyorsabban tudunk portokat telepíteni a
	    gépekre, mivel nem kell külön mindegyikre
	    letölteni az ehhez szükséges
	    forrásokat.</para>
	</listitem>
      </itemizedlist>

    </sect2>

    <sect2 id="network-amd">
      <sect2info>
	<authorgroup>
	  <author>
	    <firstname>Wylie</firstname>
	    <surname>Stilwell</surname>
	    <contrib>Készítette: </contrib>
	  </author>
	</authorgroup>
	<authorgroup>
	  <author>
	    <firstname>Chern</firstname>
	    <surname>Lee</surname>
	    <contrib>Újraírta: </contrib>
	  </author>
	</authorgroup>
      </sect2info>

      <title>Automatikus csatlakoztatás az
	<application>amd</application>
	használatával</title>

      <indexterm><primary>amd</primary></indexterm>
      <indexterm><primary>automatikus csatlakoztató
	démon</primary></indexterm>

      <para>Az &man.amd.8; (automatikus csatlakoztató
	démon, az automatic mounter daemon)
	önmûködõen csatlakoztatja a távoli
	állományrendszereket, amikor azokon belül
	valamelyik állományhoz vagy
	könyvtárhoz próbálunk
	hozzáférni.  Emellett az
	<application>amd</application> az egy ideje már
	inaktív állományrendszereket is
	automatikusan leválasztja.  Az
	<application>amd</application> használata egy remek
	alternatívát kínál az
	általában az <filename>/etc/fstab</filename>
	állományban megjelenõ állandóan
	csatlakoztatott állományrendszerekkel
	szemben.</para>

      <para>Az <application>amd</application> úgy
	mûködik, hogy kapcsolódik egy NFS szerver
	<filename>/host</filename> és <filename>/net</filename>
	könyvtáraihoz.  Amikor egy állományt
	akarunk elérni ezeken a könyvtárakon
	belül, az <application>amd</application> kikeresi a
	megfelelõ távoli csatlakoztatást és
	magától csatlakoztatja.  A
	<filename>/net</filename> segítségével egy
	IP-címrõl tudunk exportált
	állományrendszereket csatlakoztatni, miközben
	a <filename>/host</filename> a távoli gép
	hálózati neve esetében
	használatos.</para>

      <para>Ha tehát a <filename>/host/izemize/usr</filename>
	könyvtárban akarunk elérni egy
	állományt, akkor az <application>amd</application>
	démonnak ahhoz elõször az
	<hostid>izemize</hostid> nevû géprõl
	exportált <filename>/usr</filename>
	könyvtárat kell csatlakoztatnia.</para>

      <example>
	<title>Egy exportált állományrendszer
	  csatlakoztatása az <application>amd</application>
	  használatával</title>

	<para>Egy távoli számítógép
	  által rendelkezésre bocsátott
	  megosztásokat a <command>showmount</command> paranccsal
	  tudjuk lekérdezni.  Például az
	  <hostid>izemize</hostid> gépen elérhetõ
	  exportált állományrendszereket így
	  láthatjuk:</para>

	<screen>&prompt.user; <userinput>showmount -e izemize</userinput>
Exports list on izemize:
/usr                               10.10.10.0
/a                                 10.10.10.0
&prompt.user; <userinput>cd /host/izemize/usr</userinput></screen>
      </example>

      <para>Ahogy a példában látjuk is, a
	<command>showmount</command> parancs a <filename>/usr</filename>
	könyvtárat mutatja megosztásként.
	Amikor tehát belépünk a
	<filename>/host/izemize/usr</filename> könyvtárba,
	akkor <application>amd</application> magától
	megpróbálja feloldani az <hostid>izemize</hostid>
	hálózati nevet és csatlakoztatni az
	elérni kívánt exportált
	állományrendszert.</para>

      <para>Az <application>amd</application> az indító
	szkripteken keresztül az <filename>/etc/rc.conf</filename>
	alábbi beállításával
	engedélyezhetõ:</para>

      <programlisting>amd_enable="YES"</programlisting>

      <para>Emellett még az <varname>amd_flags</varname>
	használatával további paraméterek is
	átadható az <application>amd</application>
	felé.  Alapértelmezés szerint az
	<varname>amd_flags</varname> tartalmaz az alábbi:</para>

      <programlisting>amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map"</programlisting>

      <para>Az <filename>/etc/amd.map</filename> állomány
	adja meg az exportált állományrendszerek
	alapértelmezett beállításait.  Az
	<filename>/etc/amd.conf</filename> állományban az
	<application>amd</application> további
	lehetõségeit konfigurálhatjuk..</para>

      <para>Ha többet is szeretnénk tudni a
	témáról, akkor az &man.amd.8; és az
	&man.amd.conf.5; man oldalakat javasolt elolvasnunk.</para>

    </sect2>

    <sect2 id="network-nfs-integration">
      <sect2info>
	<authorgroup>
	  <author>
	    <firstname>John</firstname>
	    <surname>Lind</surname>
	    <contrib>Készítette: </contrib>
	  </author>
	</authorgroup>
      </sect2info>

      <title>Problémák más rendszerek
	használatakor</title>

      <para>Némely PC-s ISA buszos Ethernet
	kártyákra olyan korlátozások
	érvényesek, melyek komoly hálózati
	problémák keletkezéséhez
	vezethetnek, különösen az NFS esetében.
	Ez a nehézség nem &os;-függõ, de a &os;
	rendszereket is érinti.</para>

      <para>Ez gond általában majdnem mindig akkor
	merül fel, amikor egy (&os;-s) PC egy
	hálózatba kerül többek közt a
	Silicon Graphic és a Sun Microsystems által
	gyártott nagyteljesítményû
	munkaállomásokkal.  Az NFS csatlakoztatása
	és bizonyos mûveletek még hibátlanul
	végrehajtódnak, azonban hirtelen a szerver
	látszólag nem válaszol többet a kliens
	felé úgy, hogy a többi rendszertõl
	folyamatosan dolgozza felfele a kéréseket.  Ez a
	kliens rendszeren tapasztalható csak, amikor a kliens
	&os; vagy egy munkaállomás.  Sok rendszeren
	egyszerûen rendesen le sem lehet állítani a
	klienst, ha a probléma egyszer már
	felütötte a fejét.  Egyedüli
	megoldás gyakran csak a kliens
	újraindítása marad, mivel az NFS-ben
	kialakult helyzetet máshogy nem lehet megoldani.</para>

      <para>Noha a <quote>helyes</quote> megoldás az lenne, ha
	beszereznénk egy nagyobb teljesítményû
	és kapacitású kártyát a &os;
	rendszer számára, azonban egy jóval
	egyszerûbb kerülõút is
	található a kielégítõ
	mûködés eléréséhez.  Ha a
	&os; rendszer képviseli a <emphasis>szervert</emphasis>,
	akkor a kliensnél adjuk meg a <option>-w=1024</option>
	beállítást is a
	csatlakoztatásnál.  Ha a &os; rendszer a
	<emphasis>kliens</emphasis> szerepét tölti be, akkor
	az NFS állományrendszert az
	<option>-r=1024</option> beállítással
	csatlakoztassuk róla.  Ezek a
	beállítások az <filename>fstab</filename>
	állomány negyedik mezõjében is
	megadhatóak az automatikus csatlakoztatáshoz, vagy
	manuális esetben a &man.mount.8; parancsnak a
	<option>-o</option> paraméterrel.</para>

      <para>Hozzá kell azonban tennünk, hogy létezik
	egy másik probléma, amit gyakran ezzel
	tévesztenek össze, amikor az NFS szerverek és
	kliensek nem ugyanabban a hálózatban
	találhatóak.  Ilyen esetekben mindenképpen
	<emphasis>gyõzõdjünk meg róla</emphasis>,
	hogy az útválasztók rendesen
	továbbküldik a mûködéshez
	szükséges <acronym>UDP</acronym>
	információkat, különben nem sokat tudunk
	tenni a megoldás érdekében.</para>

      <para>A most következõ példákban a
	<hostid>gyorsvonat</hostid> lesz a
	nagyteljesítményû munkaállomás
	(felület) neve, illetve a <hostid>freebsd</hostid> pedig a
	gyengébb teljesítményû Ethernet
	kártyával rendelkezõ &os; rendszer
	(felület) neve.  A szerveren az
	<filename>/osztott</filename> nevû könyvtárat
	fogjuk NFS állományrendszerként
	exportálni (lásd &man.exports.5;), amelyet majd a
	<filename>/projekt</filename> könyvtárba fogunk
	csatlakoztatni a kliensen.  Minden esetben érdemes lehet
	még megadnunk a <option>hard</option> vagy
	<option>soft</option>, illetve <option>bg</option>
	opciókat is.</para>

      <para>Ebben a példában a &os; rendszer
	(<hostid>freebsd</hostid>) lesz a kliens, és az
	<filename>/etc/fstab</filename>
	állományában így szerepel az
	exportált állományrendszer:</para>

      <programlisting>gyorsvonat:/osztott /projekt nfs rw,-r=1024 0 0</programlisting>

      <para>És így tudjuk manuálisan
	csatlakoztatni:</para>

      <screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 gyorsvonat:/osztott /projekt</userinput></screen>

      <para>Itt a &os; rendszer lesz a szerver, és a
	<hostid>gyorsvonat</hostid> <filename>/etc/fstab</filename>
	állománya így fog kinézni:</para>

      <programlisting>freebsd:/osztott /projekt nfs rw,-w=1024 0 0</programlisting>

      <para>Manuálisan így csatlakoztathatjuk az
	állományrendszert:</para>

      <screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebsd:/osztott /projekt</userinput></screen>

      <para>Szinte az összes 16&nbsp;bites Ethernet kártya
	képes mûködni a fenti írási vagy
	olvasási korlátozások nélkül
	is.</para>

      <para>A kíváncsibb olvasók
	számára eláruljuk, hogy pontosan
	miért is következik be ez a hiba, ami egyben arra is
	magyarázatot ad, hogy miért nem tudjuk
	helyrehozni.  Az NFS általában 8&nbsp;kilobyte-os
	<quote>blokkokkal</quote> dolgozik (habár kisebb
	méretû darabkákat is tud
	készíteni).  Mivel az Ethernet által kezelt
	legnagyobb méret nagyjából 1500&nbsp;byte,
	ezért az NFS <quote>blokkokat</quote> több Ethernet
	csomagra kell osztani &mdash; még olyankor is, ha ez a
	program felsõbb rétegeiben osztatlan
	egységként látszik &mdash; ezt aztán
	fogadni kell, összerakni és
	<emphasis>nyugtázni</emphasis> mint egységet.  A
	nagyteljesítményû
	munkaállomások a szabvány által
	még éppen megengedett szorossággal
	képesek ontani magukból az egy egységhez
	tartozó csomagokat, közvetlenül egymás
	után.  A kisebb, gyengébb
	teljesítményû kártyák
	esetében azonban az egymáshoz tartozó,
	késõbb érkezõ csomagok ráfutnak a
	korábban megkapott csomagokra még pontosan
	azelõtt, hogy elérnék a gépet,
	így az egységek nem
	állíthatóak össze vagy nem
	nyugtázhatóak.  Ennek
	eredményeképpen a munkaállomás egy
	adott idõ múlva megint próbálkozik, de
	ismét az egész 8&nbsp;kilobyte-os blokkot
	küldi el, ezért ez a folyamat a
	végtelenségig ismétlõdik.</para>

      <para>Ha a küldendõ egységek
	méretét az Ethernet által kezelt csomagok
	maximális mérete alá csökkentjük,
	akkor biztosak lehetünk benne, hogy a teljes Ethernet
	csomag egyben megérkezik és
	nyugtázódik, így elkerüljük a
	holtpontot.</para>

      <para>A nagyteljesítményû
	munkaállomások természetesen
	továbbra is küldhetnek a PC-s rendszerek felé
	túlfutó csomagokat, de egy jobb
	kártyával az ilyen túlfutások nem
	érintik az NFS által használt
	<quote>egységeket</quote>.  Amikor egy ilyen
	túlfutás bekövetkezik, az érintett
	egységet egyszerûen újra elküldik,
	amelyet a rákövetkezõ alkalommal nagy
	valószínûséggel már tudunk
	rendesen fogadni, összerakni és
	nyugtázni.</para>

    </sect2>
  </sect1>

  <sect1 id="network-nis">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Bill</firstname>
	  <surname>Swingle</surname>
	  <contrib>Írta: </contrib>
	 </author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Eric</firstname>
	  <surname>Ogren</surname>
	  <contrib>Írta: </contrib>
	</author>
	<author>
	  <firstname>Udo</firstname>
	  <surname>Erdelhoff</surname>
	</author>
      </authorgroup>
    </sect1info>

    <title>Hálózati információs rendszer
      (NIS/YP)</title>

    <sect2>
      <title>Mi ez?</title>

      <indexterm><primary>NIS</primary></indexterm>
      <indexterm><primary>Solaris</primary></indexterm>
      <indexterm><primary>HP-UX</primary></indexterm>
      <indexterm><primary>AIX</primary></indexterm>
      <indexterm><primary>Linux</primary></indexterm>
      <indexterm><primary>NetBSD</primary></indexterm>
      <indexterm><primary>OpenBSD</primary></indexterm>

      <para>A hálózati információs
	szolgáltatást (Network Information Service, avagy
	<acronym role="Network Information System">NIS</acronym>) a Sun
	Microsystems fejlesztette ki a &unix; (eredetileg &sunos;)
	rendszerek központosított
	karbantartásához.  Mostanra már
	lényegében ipari szabvánnyá
	nõtte ki magát, hiszen az összes nagyobb
	&unix;-szerû rendszer (a &solaris;, HP-UX, &aix;, Linux,
	NetBSD, OpenBSD, &os; stb.) támogatja a <acronym
	role="Network Information System">NIS</acronym>
	használatát.</para>

      <indexterm>
	<primary>sárga oldalak</primary>
	<see>NIS</see>
      </indexterm>

      <para>A <acronym role="Network Information System">NIS</acronym>
	régebben sárga oldalak (Yellow Pages) néven
	volt ismert, de a különbözõ jogi
	problémák miatt késõbb ezt a Sun
	megváltoztatta.  A régi elnevezést
	(és a yp rövidítést) azonban
	még napjainkban is lehet néhol
	látni.</para>

      <indexterm>
	<primary>NIS</primary>
	<secondary>tartományok</secondary>
      </indexterm>

      <para>Ez egy RPC alapján mûködõ,
	kliens/szerver felépítésû rendszer,
	amely az egy NIS tartomány belül levõ
	számítógépek számára
	teszi lehetõvé ugyanazon konfigurációs
	állományok használatát.
	Segítségével a rendszergazda a NIS
	klienseket a lehetõ legkevesebb adat
	hozzáadásával,
	eltávolításával vagy
	módosításával képes egyetlen
	helyrõl beállítani.</para>

      <indexterm><primary>Windows NT</primary></indexterm>

      <para>Hasonló a &windowsnt; tartományaihoz,
	és habár a belsõ implementációt
	tekintve már akadnak köztük jelentõs
	eltérések is, az alapvetõ funkciók
	szintjén mégis összevethetõek.</para>

    </sect2>

    <sect2>
      <title>A témához tartozó fogalmak és
	programok</title>

      <para>A NIS telepítése számos fogalom
	és fontos felhasználói program kerül
	elõ &os;-n, akár egy NIS szervert akarunk
	beállítani, akár csak egy NIS
	klienst:</para>

      <indexterm><primary><application>rpcbind</application></primary></indexterm>
      <indexterm><primary><application>portmap</application></primary></indexterm>

      <informaltable frame="none" pgwide="1">
	<tgroup cols="2">
	<colspec colwidth="1*"/>
	<colspec colwidth="3*"/>

	  <thead>
	    <row>
	      <entry>Fogalom</entry>
	      <entry>Leírás</entry>
	    </row>
	  </thead>
	  <tbody>
	    <row>
	      <entry>NIS tartománynév</entry>
	      <entry>A NIS központi szerverei és az
		összes hozzájuk tartozó kliens
		(beleértve az alárendelt szervereket)
		rendelkezik egy NIS tartománynévvel.
		Hasonló a &windowsnt; által
		használt tartománynevekhez, de a NIS
		tartománynevei semmilyen kapcsolatban nem
		állnak a névfeloldással.</entry>
	    </row>

	    <row>
	      <entry><application>rpcbind</application></entry>
	      <entry>Az <acronym>RPC</acronym> (Remote Procedure Call, a
		NIS által használt egyik
		hálózati protokoll)
		engedélyezéséhez lesz rá
		szükségünk.  Ha az
		<application>rpcbind</application> nem fut, akkor sem
		NIS szervert, sem pedig NIS klienst nem tudunk
		mûködtetni.</entry>
	    </row>

	    <row>
	      <entry><application>ypbind</application></entry>
	      <entry>A NIS klienst <quote>köti össze</quote> a
		hozzá tartozó NIS szerverrel.  A NIS
		tartománynevet a rendszertõl veszi,
		és az <acronym>RPC</acronym>
		használatával csatlakozik a szerverhez.
		Az <application>ypbind</application> a NIS
		környezet kliens és szerver közti
		kommunikációjának magját
		alkotja.  Ha az <application>ypbind</application>
		leáll a kliens gépén, akkor nem
		tudjuk elérni a NIS szervert.</entry>
	    </row>

	    <row>
	      <entry><application>ypserv</application></entry>
	      <entry>Csak a NIS szervereken szabad futnia, mivel ez maga
		a NIS szerver programja.  Ha az &man.ypserv.8;
		leáll, akkor a szerver nem lesz képes
		tovább kiszolgálni a NIS
		kéréseket (szerencsére az
		alárendelt szerverek képesek
		átvenni ezeket).  A NIS bizonyos
		változatai (de nem az, amelyik a &os;-ben is
		megjelenik) nem próbálnak meg más
		szerverekhez csatlakozni, ha bedöglik az
		aktuális használt szerver.  Ezen gyakran
		egyedül csak a szervert képviselõ
		program (vagy akár az egész szerver)
		újraindítása segíthet,
		illetve az <application>ypbind</application>
		újraindítása a kliensen.</entry>
	    </row>

	    <row>
	      <entry><application>rpc.yppasswdd</application></entry>
	      <entry>Ez egy olyan program, amelyet csak a NIS
		központi szerverein kell csak futtatni.  Ez a
		démon a NIS kliensek számára a NIS
		jelszavaik megváltoztatását teszi
		lehetõvé.  Ha ez a démon nem fut,
		akkor a felhasználók csak úgy
		tudják megváltoztatni a jelszavukat, ha
		bejelentkeznek a központi NIS szerverre.</entry>
	    </row>
	  </tbody>
	</tgroup>
      </informaltable>

    </sect2>

    <sect2>
      <title>Hogyan mûködik?</title>

      <para>A NIS környezetekben háromféle gép
	létezik: a központi szerverek, az alárendelt
	szerverek és a kliensek.  A szerverek képezik a
	gépek konfigurációs
	információinak központi
	tárhelyét.  A központi szerverek
	tárolják ezen információk hiteles
	másolatát, míg ezt az alárendelt
	szerverek redundánsan tükrözik.  A kliensek a
	szerverekre támaszkodnak ezen információk
	beszerzéséhez.</para>

      <para>Sok állomány tartalma megosztható ezen
	a módon.  Például a
	<filename>master.passwd</filename>, a <filename>group</filename>
	és <filename>hosts</filename> állományokat
	meg szokták osztani NFS-en.  Amikor a kliensen
	futó valamelyik programnak olyan
	információra lenne szüksége, amely
	általában ezekben az állományokban
	nála megtalálható lenne, akkor helyette a
	NIS szerverhez fordul.</para>

      <sect3>
	<title>A gépek típusai</title>

	<itemizedlist>
	  <listitem>
	  <indexterm>
	    <primary>NIS</primary>
	    <secondary>központi szerver</secondary>
	  </indexterm>

	    <para>A <emphasis>központi NIS szerver</emphasis>.  Ez
	      a szerver, amely leginkább a &windowsnt;
	      elsõdleges
	      tartományvezérlõjéhez
	      hasonlítható tartja karban az összes,
	      NIS kliensek által használt
	      állományt.  A <filename>passwd</filename>,
	      <filename>group</filename>, és összes
	      többi ehhez hasonló állomány
	      ezen a központi szerveren található
	      meg.</para>

	    <note>
	      <para>Egy gép akár több NIS
		tartományban is lehet központi szerver.
		Ezzel a lehetõséggel viszont itt most nem
		foglalkozunk, mivel most csak egy viszonylag kis
		méretû NIS környezetet
		feltételezünk.</para>
	      </note>
	  </listitem>

	  <listitem>
	    <indexterm>
	      <primary>NIS</primary>
	      <secondary>alárendelt szerver</secondary>
	    </indexterm>

	    <para>Az <emphasis>alárendelt NIS
	      szerverek</emphasis>.  A &windowsnt; tartalék
	      tartományvezérlõihez
	      hasonlítanak, és az alárendelt NIS
	      szerverek feladata a központi NIS szerveren
	      tárolt adatok másolatainak
	      karbantartása.  Az alárendelt NIS szerverek
	      a redundancia megvalósításában
	      segítenek, aminek leginkább a fontosabb
	      környezetekben van szerepe.  Emellett a központi
	      szerver terhelésének
	      kiegyenlítését is elvégzik.  A
	      NIS kliensek elsõként mindig ahhoz a NIS
	      szerverhez csatlakoznak, amelytõl elõször
	      választ kapnak, legyen akár az egy
	      alárendelt szerver.</para>
	  </listitem>

	  <listitem>
	    <indexterm>
	      <primary>NIS</primary>
	      <secondary>kliens</secondary>
	    </indexterm>

	    <para>A <emphasis>NIS kliensek</emphasis>.  A NIS kliensek,
	      hasonlóan a &windowsnt;
	      munkaállomásokhoz, a NIS szerveren (amely a
	      &windowsnt; munkaállomások esetében a
	      tartományvezérlõ) keresztül
	      jelentkeznek be.</para>
	  </listitem>
	</itemizedlist>

      </sect3>
    </sect2>

    <sect2>
      <title>A NIS/YP használata</title>

      <para>Ebben a szakaszban egy példa NIS környezetet
	állítunk be.</para>

      <sect3>
	<title>Tervezés</title>

	<para>Tegyük fel, hogy egy aprócska egyetemi labor
	  rendszergazdái vagyunk.  A labor, mely 15 &os;-s
	  gépet tudhat magáénak, jelen pillanatban
	  még semmilyen központosított
	  adminisztráció nem létezik.  Mindegyik
	  gép saját <filename>/etc/passwd</filename>
	  és <filename>/etc/master.passwd</filename>
	  állománnyal rendelkezik.  Ezeket az
	  állományokat saját kezûleg kell
	  szinkronban tartani.  Tehát ha most felveszünk egy
	  felhasználót a laborhoz, akkor az
	  <command>adduser</command> parancsot mind a 15 gépen ki
	  kell adni.  Egyértelmû, hogy ez így nem
	  maradhat, ezért úgy döntöttük,
	  hogy a laborban NIS-t fogunk használni, és
	  két gépet kinevezünk szervernek.</para>

	<para>Az iméntieknek megfelelõen a labor most
	  valahogy így néz ki:</para>

	<informaltable frame="none" pgwide="1">
	  <tgroup cols="3">
	    <thead>
	      <row>
		<entry>A gép neve</entry>
		<entry>IP-cím</entry>
		<entry>A gép szerepe</entry>
	      </row>
	    </thead>
	    <tbody>
	      <row>
		<entry><hostid>ellington</hostid></entry>
		<entry><hostid role="ipaddr">10.0.0.2</hostid></entry>
		<entry>központi NIS</entry>
	      </row>
	      <row>
		<entry><hostid>coltrane</hostid></entry>
		<entry><hostid role="ipaddr">10.0.0.3</hostid></entry>
		<entry>alárendelt NIS</entry>
	      </row>
	      <row>
		<entry><hostid>basie</hostid></entry>
		<entry><hostid role="ipaddr">10.0.0.4</hostid></entry>
		<entry>tanszéki munkaállomás</entry>
	      </row>
	      <row>
		<entry><hostid>bird</hostid></entry>
		<entry><hostid role="ipaddr">10.0.0.5</hostid></entry>
		<entry>kliensgép</entry>
	      </row>
	      <row>
		<entry><hostid>cli[1-11]</hostid></entry>
		<entry><hostid
		  role="ipaddr">10.0.0.[6-17]</hostid></entry>
		<entry>a többi kliensgép</entry>
	      </row>
	    </tbody>
	  </tgroup>
	</informaltable>

	<para>Ha még nincs tapasztalatunk a NIS rendszerek
	  összeállításában, akkor
	  elõször jó ötlet lehet
	  végiggondolni, miként is akarjuk
	  kialakítani.  A hálózatunk
	  méretétõl függetlenül is akadnak
	  olyan döntések, amelyeket mindenképpen meg
	  kell hoznunk.</para>

	<sect4>
	  <title>A NIS tartománynév
	    megválasztása</title>

	  <indexterm>
	    <primary>NIS</primary>
	    <secondary>tartománynév</secondary>
	  </indexterm>

	  <para>Ez nem az a <quote>tartománynév</quote>,
	    amit megszokhattunk.  Ennek a pontos neve <quote>NIS
	    tartománynév</quote>.  Amikor a kliensek
	    kérnek valamilyen információt, akkor
	    megadják annak a NIS tartománynak a
	    nevét is, amelynek részei.  Így tud egy
	    hálózaton több szerver arról
	    dönteni, hogy melyikük melyik kérést
	    válaszolja meg.  A NIS által használt
	    tartománynévre tehát inkább
	    úgy érdemes gondolni, mint egy valamilyen
	    módon összetartozó gépek
	    közös nevére.</para>

	  <para>Elõfordul, hogy egyes szervezetek az interneten is
	    nyilvántartott tartománynevüket
	    választják NIS tartománynévnek.
	    Ez alapvetõen nem ajánlott, mivel a
	    hálózati problémák
	    felderítése közben
	    félreértéseket szülhet.  A NIS
	    tartománynévnek a hálózatunkon
	    belül egyedinek kell lennie, és lehetõleg
	    minél jobban írja le az általa
	    csoportba sorolt gépeket.  Például a
	    Kis Kft.  üzleti osztályát tegyük a
	    <quote>kis-uzlet</quote> NIS tartományba.  Ebben a
	    példában most a
	    <literal>proba-tartomany</literal> nevet
	    választottuk.</para>

	  <indexterm><primary>SunOS</primary></indexterm>

	  <para>A legtöbb operációs rendszer azonban
	    (köztük a &sunos;) a NIS tartománynevet
	    használja internetes
	    tartománynévként is.  Ha a
	    hálózatunkon egy vagy több ilyen
	    gép is található, akkor a NIS
	    tartomány nevének az internetes
	    tartománynevet <emphasis>kell</emphasis>
	    megadnunk.</para>

	</sect4>

	<sect4>
	  <title>A szerverek fizikai elvárásai</title>

	  <para>Nem árt néhány dolgot fejben
	    tartani, amikor a NIS szervernek használt
	    gépet kiválasztjuk.  Az egyik ilyen
	    szerencsétlen dolog az a szintû
	    függõség, ami a NIS kliensek felõl
	    megfigyelhetõ a szerverek felé.  Ha egy kliens
	    nem tudja a NIS tartományon belül felvenni a
	    kapcsolatot valamelyik szerverrel, akkor az a gép
	    könnyen megbízhatatlanná válhat.
	    Felhasználói- és
	    csoportinformációk nélkül a
	    legtöbb rendszer egy idõre le is merevedik.  Ennek
	    figyelembevételével tehát olyan
	    gépet kell szervernek választanunk, amelyet
	    nem kell gyakran újraindítani, és nem
	    végzünk rajta semmilyen komoly munkát.  A
	    célnak legjobban megfelelõ NIS szerverek
	    valójában olyan gépek, amelyek
	    egyedüli feladata csak a NIS kérések
	    kiszolgálása.  Ha a hálózatunk
	    nem annyira leterhelt, akkor még a NIS szerver
	    mellett más programokat is futtathatunk, de ne
	    feledjük, hogy ha a NIS szolgáltatás
	    megszûnik, akkor az az <emphasis>összes</emphasis>
	    NIS kliensen éreztetni fogja kedvezõtlen
	    hatását.</para>

	</sect4>
      </sect3>

      <sect3>
	<title>A NIS szerverek</title>

	<para>A NIS rendszerben tárolt összes
	  információ általános
	  példánya egyetlen gépen
	  található meg, amelyet a központi NIS
	  szervernek hívunk.  Az információk
	  tárolására szánt adatbázis
	  pedig NIS táblázatoknak (NIS map) nevezzük.
	  &os; alatt ezek a táblázatok a
	  <filename>/var/yp/<replaceable>tartománynév</replaceable></filename>
	  könyvtárban találhatóak, ahol a
	  <filename><replaceable>tartománynév</replaceable></filename>
	  a kiszolgált NIS tartományt nevezi meg.
	  Egyetlen NIS szerver egyszerre akár több
	  tartományt is kiszolgálhat, így itt
	  több könyvtár is található,
	  minden támogatott tartományhoz egy.  Minden
	  tartomány saját, egymástól
	  független táblázatokkal rendelkezik.</para>

	<para>A központi és alárendelt NIS szerverek
	  az <command>ypserv</command> démon
	  segítségével dolgozzák fel a NIS
	  kéréseket.  Az <command>ypserv</command>
	  felelõs a NIS kliensektõl befutó
	  kérések fogadásáért,
	  és a kért tartomány valamint
	  táblázat nevébõl meghatározza
	  az adatbázisban tárolt állományt,
	  majd innen visszaküldi a hozzá tartozó
	  adatot a kliensnek.</para>

	<sect4>
	  <title>A központi NIS szerver
	    beállítása</title>

	  <indexterm>
	    <primary>NIS</primary>
	    <secondary>szerver
	      beállítása</secondary>
	  </indexterm>

	  <para>A központi NIS szerver
	    beállítása viszonylag
	    magától értetõdõ, de a
	    nehézségét az igényeink
	    szabják meg.  A &os; alapból támogatja
	    a NIS használatát.  Ezért
	    mindössze annyit kell tennünk, hogy a
	    következõ sorokat betesszük az
	    <filename>/etc/rc.conf</filename> állományba,
	    és a &os; gondoskodik a többirõl.</para>

	  <procedure>
	    <step>
	      <para><programlisting>nisdomainname="proba-tartomany"</programlisting>
		Ez a sor adja meg a hálózati
		beállítások (vagy
		például az
		újraindítás) során a NIS
		tartomány nevét, amely a korábbiak
		szerint itt most a
		<literal>proba-tartomany</literal>.</para>
	    </step>

	    <step>
	      <para><programlisting>nis_server_enable="YES"</programlisting>
		Ezzel utasítjuk a &os;-t, hogy a
		hálózati alkalmazások
		következõ indításakor a NIS
		szervert is aktiválja.</para>
	    </step>

	    <step>
	      <para><programlisting>nis_yppasswdd_enable="YES"</programlisting>
		Ezzel engedélyezzük az
		<command>rpc.yppasswdd</command> démont, amely a
		korábban említettek szerint
		lehetõvé teszi a felhasználók
		számára, hogy a közvetlenül a
		kliensekrõl változtassák meg a NIS
		jelszavukat.</para>
	    </step>
	  </procedure>

	  <note>
	    <para>A konkrét NIS
	      beállításainktól
	      függõen további bejegyzések
	      felvételére is szükségünk
	      lehet.  Erre késõbb még <link
	      linkend="network-nis-server-is-client">az olyan NIS
	      szervereknél, amelyek egyben NIS kliensek</link>,
	      vissza fogunk térni.</para>
	  </note>

	  <para>Miután ezeket beállítottuk,
	    rendszeradminisztrátorként adjuk ki az
	    <command>/etc/netstart</command> parancsot.  Az
	    <filename>/etc/rc.conf</filename> állományban
	    szereplõ adatok alapján mindent
	    beállít magától.  Még
	    mielõtt inicializálnánk a NIS
	    táblázatokat, indítsuk el
	    manuálisan az <application>ypserv</application>
	    démont:</para>

	  <screen>&prompt.root; <userinput>/etc/rc.d/ypserv start</userinput></screen>
	</sect4>

	<sect4>
	  <title>A NIS táblázatok
	    inicializálása</title>

	  <indexterm>
	    <primary>NIS</primary>
	    <secondary>táblázatok</secondary>
	  </indexterm>

	  <para>A <emphasis>NIS táblázatok</emphasis>
	    lényegében a <filename>/var/yp</filename>
	    könyvtárban tárolt adatbázisok.  A
	    központi NIS szerver <filename>/etc</filename>
	    könyvtárában található
	    konfigurációs
	    állományokból
	    állítódnak elõ, egyetlen
	    kivétellel: ez az
	    <filename>/etc/master.passwd</filename>
	    állomány.  Ennek megvan a maga oka, hiszen nem
	    akarjuk a <username>root</username> és az összes
	    többi fontosabb felhasználóhoz
	    tartozó jelszót az egész NIS
	    tartománnyal megosztani.  Ennek megfelelõen a
	    NIS táblázatok
	    inicializálásához a
	    következõt kell tennünk:</para>

	  <screen>&prompt.root; <userinput>cp /etc/master.passwd /var/yp/master.passwd</userinput>
&prompt.root; <userinput>cd /var/yp</userinput>
&prompt.root; <userinput>vi master.passwd</userinput></screen>

	  <para>El kell távolítanunk az összes
	    rendszerszintû (<username>bin</username>,
	    <username>tty</username>, <username>kmem</username>,
	    <username>games</username>, stb), és minden olyan
	    egyéb hozzáférést, amelyeket nem
	    akarjuk közvetíteni a NIS kliensek felé
	    (például a <username>root</username> és
	    minden más nullás, vagyis
	    rendszeradminisztrátori azonosítóval
	    ellátott hozzáférést).</para>

	  <note>
	    <para>Gondoskodjunk róla, hogy az
	      <filename>/var/yp/master.passwd</filename>
	      állomány sem a csoport, sem pedig
	      bárki más számára nem
	      olvasható (600-as engedély)!  Ennek
	      beállításához
	      használjuk az <command>chmod</command> parancsot,
	      ha szükséges.</para>
	  </note>

	  <indexterm><primary>Tru64 UNIX</primary></indexterm>

	  <para>Ha végeztünk, akkor már
	    tényleg itt az ideje inicializálni NIS
	    táblázatainkat.  A &os; erre egy
	    <command>ypinit</command> nevû szkriptet ajánl
	    fel (errõl a saját man oldalán tudhatunk
	    meg többet).  Ez a szkript egyébként a
	    legtöbb &unix; típusú
	    operációs rendszeren
	    megtalálható, de nem az összesen.  A
	    Digital UNIX/Compaq Tru64 UNIX rendszereken ennek a neve
	    <command>ypsetup</command>.  Mivel most a központi NIS
	    szerver táblázatait hozzuk létre,
	    azért az <command>ypinit</command> szkriptnek
	    át kell adnunk a <option>-m</option> opciót
	    is.  A NIS táblázatok
	    elõállításánál
	    feltételezzük, hogy a fentebb ismertetett
	    lépéseket már megtettük, majd
	    kiadjuk ezt a parancsot:</para>

	  <screen>ellington&prompt.root; <userinput>ypinit -m proba-tartomany</userinput>
Server Type: MASTER Domain: proba-tartomany
Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.
Do you want this procedure to quit on non-fatal errors? [y/n: n] <userinput>n</userinput>
Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
At this point, we have to construct a list of this domains YP servers.
rod.darktech.org is already known as master server.
Please continue to add any slave servers, one per line. When you are
done with the list, type a &lt;control D&gt;.
master server   :  ellington
next host to add:  <userinput>coltrane</userinput>
next host to add:  <userinput>^D</userinput>
The current list of NIS servers looks like this:
ellington
coltrane
Is this correct?  [y/n: y] <userinput>y</userinput>

[ .. a táblázatok generálása .. ]

NIS Map update completed.
ellington has been setup as an YP master server without any errors.</screen>

	  <para>Az üzenetek fordítása:</para>

	  <screen>A szerver típusa: KÖZPONTI, tartomány: proba-tartomany
Az YP szerver létrehozásához meg kell válaszolni néhány kérdést az
eljárás megkezdése elõtt.
Szeretnénk, ha az eljárás megszakadna a nem végzetes hibák esetén is? [i/n: n] <userinput>n</userinput>
Rendben, akkor ne felejtsük el manuálisan kijavítani a hibát, ha
valamivel gond lenne.  Ha nem tesszük meg, akkor elõfordulhat, hogy
valami nem fog rendesen mûködni.  Most össze kell állítanunk egy listát
a tartomány YP szervereirõl.
Jelenleg a rod.darktech.org a központi szerver.
Kérjünk, adjon meg további alárendelt szervereket, soronként egyet.
Amikor ezt befejeztük, a &lt;control D&gt; lenyomásával tudunk
kilépni.
központi szerver : ellington
következõ gép    : <userinput>coltrane</userinput>
következõ gép    : <userinput>^D</userinput>
A NIS szerverek listája jelenleg a következõ:
ellington
coltrane
Ez megfelelõ?  [i/n: i] <userinput>i</userinput>

[ .. a táblázatok generálása .. ]

A NIS táblázatok sikeressen frissültek.
Az elligon szervert minden hiba nélkül sikerült központi szerverként
beállítani.</screen>

	  <para>Az <command>ypinit</command> a
	    <filename>/var/yp/Makefile.dist</filename>
	    állományból létrehozza a
	    <filename>/var/yp/Makefile</filename>
	    állományt.  Amennyiben ez
	    létrejött, az állomány
	    feltételezi, hogy csak &os;-s gépek
	    részvételével akarunk
	    kialakítani egy egyszerveres NIS környezetet.
	    Mivel a <literal>proba-tartomany</literal> még egy
	    alárendelt szervert is tartalmaz, ezért
	    át kell írnunk a
	    <filename>/var/yp/Makefile</filename>
	    állományt:</para>

	  <screen>ellington&prompt.root; <userinput>vi /var/yp/Makefile</userinput></screen>

	  <para>Ezt a sort kell megjegyzésbe tennünk:</para>

	  <programlisting>NOPUSH = "True"</programlisting>

	  <para>(ha még nem lenne úgy).</para>

	</sect4>

	<sect4>
	  <title>Az alárendelt NIS szerverek
	    beállítása</title>

	  <indexterm>
	    <primary>NIS</primary>
	    <secondary>alárendelt szerver</secondary>
	  </indexterm>

	  <para>Az alárendelt NIS szerverek
	    beállítása még a
	    központinál is egyszerûbb.
	    Jelentkezzünk be az alárendelt szerverre
	    és az eddigieknek megfelelõen írjuk
	    át az <filename>/etc/rc.conf</filename>
	    állományt.  Az egyetlen
	    különbség ezúttal csupán
	    annyi lesz, hogy az <command>ypinit</command>
	    lefuttatásakor a <option>-s</option> opciót
	    kell megadnunk (mint slave, vagyis alárendelt).  A
	    <option>-s</option> opció használatához
	    a központi NIS szerver nevét is át kell
	    adnunk, ezért a konkrét parancs valahogy
	    így fog kinézni:</para>

	  <screen>coltrane&prompt.root; <userinput>ypinit -s ellington proba-tartomany</userinput>

Server Type: SLAVE Domain: test-domain Master: ellington

Creating an YP server will require that you answer a few questions.
Questions will all be asked at the beginning of the procedure.

Do you want this procedure to quit on non-fatal errors? [y/n: n]  <userinput>n</userinput>

Ok, please remember to go back and redo manually whatever fails.
If you don't, something might not work.
There will be no further questions. The remainder of the procedure
should take a few minutes, to copy the databases from ellington.
Transferring netgroup...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byuser...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byhost...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring group.bygid...
ypxfr: Exiting: Map successfully transferred
Transferring group.byname...
ypxfr: Exiting: Map successfully transferred
Transferring services.byname...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.byname...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.byname...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring netid.byname...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring ypservers...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byname...
ypxfr: Exiting: Map successfully transferred

coltrane has been setup as an YP slave server without any errors.
Don't forget to update map ypservers on ellington.</screen>

	  <para>Most már lennie kell egy
	    <filename>/var/yp/proba-tartomany</filename> nevû
	    könyvtárunknak is.  A központi NIS szerver
	    táblázatainak másolata itt fognak
	    tárolódni.  Ezeket soha ne felejtsük el
	    frissen tartani.  Az alárendelt szervereken a
	    következõ <filename>/etc/crontab</filename>
	    bejegyzések pontosan ezt a feladatot
	    látják el:</para>

	  <programlisting>20      *       *       *       *       root   /usr/libexec/ypxfr passwd.byname
21      *       *       *       *       root   /usr/libexec/ypxfr passwd.byuid</programlisting>

	  <para>Ez a két sor gondoskodik róla, hogy az
	    alárendelt szerverek ne felejtsék el
	    egyeztetni a táblázataikat a központi
	    szerver táblázataival.  Ezek a
	    bejegyzések nem nélkülözhetetlenek a
	    megfelelõ mûködéshez, mivel a
	    központi szerver automatikusan feltölti az
	    alárendelt szerverekre a létrejött
	    változásokat.  Mivel azonban a jelszavak
	    létfontosságúak a szervertõl
	    függõ rendszerek számára,
	    ezért ajánlott explicit módon is
	    elõírni a frissítést.  Ez a
	    forgalmasabb hálózatokon nagyobb
	    jelentõséggel bír, mivel ott a
	    táblázatok frissítése nem mindig
	    fejezõdik be rendesen.</para>

	  <para>Most pedig futassuk le a
	    <command>/etc/netstart</command> parancsot az
	    alárendelt szervereken is, amivel így elindul
	    a NIS szerver.</para>

	</sect4>
      </sect3>

      <sect3>
	<title>A NIS kliensek</title>

	<para>A NIS kliens az <command>ypbind</command> démon
	  segítségével egy kötésnek
	  (bind) nevezett kapcsolatot épít ki egy adott
	  NIS szerverrel.  Az <command>ypbind</command> ellenõrzi a
	  rendszer alapértelmezett tartományát (ezt
	  a <command>domainname</command> paranccsal
	  állítottunk be), majd RPC
	  kéréseket kezd szórni a helyi
	  hálózaton.  Ezek a kérések annak a
	  tartománynak a nevét tartalmazzák,
	  amelyhez az <command>ypbind</command> megpróbál
	  kötést létrehozni.  Ha az adott
	  tartomány kiszolgálására
	  beállított szerver észleli ezeket a
	  kéréseket, akkor válaszol az
	  <command>ypbind</command> démonnak, amely pedig
	  feljegyzi a szerver címét.  Ha több szerver
	  is elérhetõ (például egy
	  központi és több alárendelt), akkor az
	  <command>ypbind</command> az elsõként
	  válaszoló címét fogja
	  rögzíteni.  Innentõl kezdve a kliens
	  közvetlenül ennek a szervernek fogja küldeni a
	  NIS kéréseit.  Az <command>ypbind</command>
	  idõnként <quote>megpingeli</quote> a szervert,
	  hogy meggyõzõdjön az
	  elérhetõségérõl.  Ha az
	  <command>ypbind</command> egy adott idõn belül nem
	  kap választ a ping kéréseire, akkor
	  megszünteti a kötést a tartományhoz
	  és nekilát keresni egy másik
	  szervert.</para>

	<sect4>
	  <title>A NIS kliensek beállítása</title>

	  <indexterm>
	    <primary>NIS</primary>
	    <secondary>a kliensek beállítása</secondary>
	  </indexterm>

	  <para>Egy &os;-s gépet NIS kliensként
	    meglehetõsen egyszerûen lehet
	    beállítani.</para>

	  <procedure>
	    <step>
	      <para>Nyissuk meg az <filename>/etc/rc.conf</filename>
		állományt és a NIS
		tartománynév
		beállításához, valamint az
		<command>ypbind</command>
		elindításához a
		következõket írjuk bele:</para>

	      <programlisting>nisdomainname="proba-tartomany"
nis_client_enable="YES"</programlisting>
	    </step>

	    <step>
	      <para>A NIS szerveren található jelszavak
		importálásához
		távolítsuk el az összes
		felhasználói
		hozzáférést az
		<filename>/etc/master.passwd</filename>
		állományunkból és a
		<command>vipw</command>
		segítségével adjuk hozzá az
		alábbi sort az állomány
		végéhez:</para>

	      <programlisting>+:::::::::</programlisting>

	      <note>
		<para>Ez a sor beenged bárkit a
		  rendszerünkre, akinek a NIS szervereken van
		  érvényes
		  hozzáférése.  A NIS klienseket
		  ezzel a sorral sokféle módon tudjuk
		  állítani.  A <link
		  linkend="network-netgroups">hálózati
		  csoportokról szóló
		  szakaszban</link> találunk majd errõl
		  több információt.  A téma
		  mélyebb megismeréséhez az
		  O'Reilly <literal>Managing NFS and NIS</literal>
		  címû könyvét
		  ajánljuk.</para>
	      </note>

	      <note>
		<para>Legalább helyi
		  hozzáférést (vagyis amit nem
		  NIS-en keresztül importálunk) azonban
		  mindenképpen hagyjunk meg az
		  <filename>/etc/master.passwd</filename>
		  állományunkban, és ez a
		  hozzáférés legyen a
		  <groupname>wheel</groupname> csoport tagja.  Ha valami
		  gond lenne a NIS használatával, akkor
		  ezen a hozzáférésen
		  keresztül tudunk a gépre
		  távolról bejelentkezni, majd innen
		  <username>root</username> felhasználóra
		  váltva megoldani a felmerült
		  problémákat.</para>
	      </note>
	    </step>

	    <step>
	      <para>A NIS szerverrõl az összes
		lehetséges csoport-bejegyzést az
		<filename>/etc/group</filename>
		állományban így tudjuk
		importálni:</para>

	      <programlisting>+:*::</programlisting>
	    </step>
	  </procedure>

	  <para>Miután elvégeztük ezeket a
	    lépéseket, képesek leszünk
	    futtatni az <command>ypcat passwd</command> parancsot,
	    és látni a NIS szerver jelszavakat
	    tartalmazó táblázatát.</para>

	</sect4>
      </sect3>
    </sect2>

    <sect2>
      <title>A NIS biztonsága</title>

      <para>Általában tetszõleges távoli
	felhasználó küldhet RPC
	kéréseket az &man.ypserv.8; számára
	és kérheti le a NIS táblázatok
	tartalmát, feltéve, hogy ismeri a tartomány
	nevét.  Az ilyen hitelesítés
	nélküli mûveletek ellen az &man.ypserv.8;
	úgy védekezik, hogy tartalmaz egy
	<quote>securenets</quote> nevû lehetõséget,
	amellyel az elérhetõségüket tudjuk
	leszûkíteni gépek egy csoportjára.  Az
	&man.ypserv.8; indításakor ezeket az
	információkat a
	<filename>/var/yp/securenets</filename>
	állományból próbálja meg
	betölteni.</para>

      <note>
	<para>Az elérési útvonala megadható
	  a <option>-p</option> opció
	  használatával.  Ez az állomány
	  olyan bejegyzéseket tartalmaz, amelyekben egy
	  hálózati cím és tõle
	  láthatatlan karakterekkel elválasztva egy
	  hálózati maszk szerepel.  A <quote>#</quote>
	  karakterrel kezdõdõ sorokat megjegyzésnek
	  nyilvánítjuk.  Egy minta securenets
	  állomány valahogy így nézne
	  ki:</para>
      </note>

      <programlisting># Engedélyezzük önmagunkról a csatlakozást -- kell!
127.0.0.1     255.255.255.255
# Engedélyezzük a 192.168.128.0 hálózatról érkezõ csatlakozásokat:
192.168.128.0 255.255.255.0
# Engedélyezzük a laborban található 10.0.0.0 és 10.0.15.255 közti
# címekkel rendelkezõ gépek csatlakozását:
10.0.0.0      255.255.240.0</programlisting>

      <para>Ha az &man.ypserv.8; olyan címrõl kap
	kérést, amely illeszkedik az elõírt
	címek valamelyikére, akkor a szokásos
	módon feldolgozza azt.  Ellenkezõ esetben a
	kérést figyelmen kívül hagyja
	és egy figyelmeztetést vesz fel hozzá a
	naplóba.  Ha a <filename>/var/yp/securenets</filename>
	állomány nem létezik, akkor az
	<command>ypserv</command> tetszõleges géprõl
	engedélyezi a csatlakozást.</para>

      <para>Az <command>ypserv</command> lehetõséget ad a
	Wietse Venema által fejlesztett <application>TCP
	Wrapper</application> csomag használatára is.
	Ezzel a rendszergazda a <filename>/var/yp/securenets</filename>
	állomány helyett a <application>TCP
	Wrapper</application> konfigurációs
	állományai alapján képes
	szabályozni az elérhetõséget.</para>

      <note>
	<para>Miközben mind a két módszer
	  nyújt valamilyen fajta védelmet, de a
	  privilegizált portok teszteléséhez
	  hasonlóan az <quote>IP
	  álcázásával</quote> (IP spoofing)
	  sebezhetõek.  Ezért az összes NIS-hez
	  tartozó forgalmat tûzfallal kell
	  blokkolnunk.</para>

	<para>Az <filename>/var/yp/securenets</filename>
	  állományt használó szerverek nem
	  képesek az elavult TCP/IP
	  implementációkat használó
	  érvényes klienseket rendesen kiszolgálni.
	  Egyes ilyen implementációk a címben a
	  géphez tartozó biteket nullára
	  állítják az
	  üzenetszóráshoz, és/vagy
	  ezért az üzenetszóráshoz
	  használt cím kiszámításakor
	  nem tudja észleli a hálózati maszkot.  A
	  legtöbb ilyen probléma megoldható a kliens
	  konfigurációjának
	  megváltoztatásával, míg más
	  problémák megoldása a
	  kérdéses kliensek
	  nyugdíjazását
	  kívánják meg, vagy a
	  <filename>/var/yp/securenets</filename>
	  használatának elhagyását.</para>

	<para>Egy régebbi TCP/IP implementációval
	  üzemelõ szerveren pedig a
	  <filename>/var/yp/securenets</filename> állomány
	  használata kifejezetten rossz ötlet, és a
	  hálózatunk nagy részében
	  képes használhatatlanná tenni a NIS
	  funkcióit.</para>

	<indexterm><primary>TCP wrapperek</primary></indexterm>

	<para>A <application>TCP Wrapper</application> csomag
	  alkalmazása a NIS szerverünk
	  válaszadáshoz szükséges
	  idejét is segít csökkenteni.  Az ilyenkor
	  jelentkezõ plusz késlekedés mellesleg
	  elég nagy lehet ahhoz, hogy a klienseknél
	  idõtúllépés következzen be,
	  különösen a terheltebb
	  hálózatokon vagy a lassú NIS szerverek
	  esetében.  Ha egy vagy több kliensünk is
	  ilyen tüneteket mutat, akkor érdemes a
	  kérdéses kliens rendszereket alárendelt
	  NIS szerverekké alakítani és
	  önmagukhoz rendelni.</para>
      </note>

    </sect2>

    <sect2>
      <title>Egyes felhasználók
	bejelentkezésének
	megakadályozása</title>

      <para>A laborunkban van egy <hostid>basie</hostid> nevû
	gép, amely a tanszék egyetlen
	munkaállomása.  Ezt a gépet nem akarjuk
	kivenni a NIS tartományból, de a központi NIS
	szerver <filename>passwd</filename> állománya
	mégis egyaránt tartalmazza a hallgatók
	és az oktatók eléréseit.  Mit lehet
	ilyenkor tenni?</para>

      <para>Adott felhasználók esetében le tudjuk
	tiltani a bejelentkezést a gépen még
	olyankor is, ha léteznek a NIS
	adatbázisában.  Ehhez mindössze a kliensen az
	<filename>/etc/master.passwd</filename> állomány
	végére be kell tennünk egy
	<literal>-<replaceable>felhasználónév</replaceable></literal>
	sort, ahol a
	<replaceable>felhasználónév</replaceable>
	annak a felhasználónak a neve, akit nem akarunk
	beengedni a gépre.  Ezt leginkább a
	<command>vipw</command> használatán keresztül
	érdemes megtennünk, mivel a <command>vipw</command>
	az <filename>/etc/master.passwd</filename>
	állomány alapján végez némi
	ellenõrzést, valamint a szerkesztés
	befejeztével magától
	újragenerálja a jelszavakat tároló
	adatbázist.  Például, ha a
	<username>bill</username> nevû felhasználót
	ki akarjuk tiltani a <hostid>basie</hostid> nevû
	géprõl, akkor:</para>

      <screen>basie&prompt.root; <userinput>vipw</userinput>
<userinput>[vegyük fel a -bill sort a végére, majd lépjünk ki]</userinput>
vipw: rebuilding the database...
vipw: done

basie&prompt.root; <userinput>cat /etc/master.passwd</userinput>

root:[jelszó]:0:0::0:0:The super-user:/root:/bin/csh
toor:[jelszó]:0:0::0:0:The other super-user:/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin
operator:*:2:5::0:0:System &amp;:/:/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin
news:*:8:8::0:0:News Subsystem:/:/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin
+:::::::::
-bill

basie&prompt.root;</screen>

    </sect2>

    <sect2 id="network-netgroups">
      <sect2info>
	<authorgroup>
	  <author>
	    <firstname>Udo</firstname>
	    <surname>Erdelhoff</surname>
	    <contrib>Készítette: </contrib>
	  </author>
	</authorgroup>
      </sect2info>

      <title>A hálózati csoportok
	alkalmazása</title>

      <indexterm><primary>hálózati
	csoportok</primary></indexterm>

      <para>Az elõzõ szakaszban ismertetett módszer
	viszonylag jól mûködik olyan esetekben, amikor
	nagyon kevés felhasználóra és/vagy
	számítógépre kell alkalmaznunk
	speciális megszorításokat.  A nagyobb
	hálózatokban szinte <emphasis>biztos</emphasis>,
	hogy elfelejtünk kizárni egyes
	felhasználókat az érzékeny
	gépekrõl, vagy az összes gépen
	egyenként kell ehhez a megfelelõ
	beállításokat elvégezni, és
	ezzel lényegében elvesztjük a NIS
	legfontosabb elõnyét, vagyis a
	<emphasis>központosított</emphasis>
	karbantarthatóságot.</para>

      <para>A NIS fejlesztõi erre a problémára a
	<emphasis>hálózati csoportokat</emphasis>
	létrehozásával válaszoltak.  A
	céljuk és mûködésük
	szempontjából leginkább a &unix;-os
	állományrendszerekben található
	csoportokhoz mérhetõek.  A legnagyobb
	eltérés a numerikus azonosítók
	hiányában mutatkozik meg, valamint a
	hálózati csoportokat a
	felhasználókon kívül további
	hálózati csoportok megadásával is ki
	lehet alakítani.</para>

      <para>A hálózati csoportok a nagyobb, bonyolultabb,
	többszáz felhasználós
	hálózatok számára jöttek
	létre.  Egy részrõl ez nagyon jó
	dolog, különösen akkor, ha egy ilyen helyzettel
	kell szembenéznünk.  Másrészrõl
	ez a mértékû bonyolultság szinte
	teljesen lehetetlenné teszi a hálózati
	csoportok egyszerû bemutatását.  A szakasz
	további részében használt
	példa is ezt a problémát igyekszik
	illusztrálni.</para>

      <para>Tételezzük fel, hogy laborunkban a NIS sikeres
	bevezetése felkeltette a fõnökeink
	figyelmét.  Így a következõ feladatunk
	az lett, hogy terjesszük ki a NIS tartományt az
	egyetemen található néhány
	másik gépre is.  Az alábbi két
	táblázatban az új
	felhasználók és az új
	számítógép neveit találjuk,
	valamint a rövid leírásukat.</para>

      <informaltable frame="none" pgwide="1">
	<tgroup cols="2">
	  <thead>
	    <row>
	      <entry>Felhasználók nevei</entry>
	      <entry>Leírás</entry>
	    </row>
	  </thead>

	  <tbody>
	    <row>
	      <entry><username>alpha</username>,
		<username>beta</username></entry>
	      <entry>az IT tanszék hétköznapi
		dolgozói</entry>
	    </row>

	    <row>
	      <entry><username>charlie</username>,
		<username>delta</username></entry>
	      <entry>az IT tanszék újdonsült
		dolgozói</entry>
	    </row>

	    <row>
	      <entry><username>echo</username>,
		<username>foxtrott</username>, <username>golf</username>,
		...</entry>
	      <entry>átlagos dolgozók</entry>
	    </row>

	    <row>
	      <entry><username>able</username>,
		<username>baker</username>, ...</entry>
	      <entry>ösztöndíjasok</entry>
	    </row>
	  </tbody>
	</tgroup>
      </informaltable>

      <informaltable frame="none" pgwide="1">
	<tgroup cols="2">
	  <thead>
	    <row>
	      <entry>Gépek nevei</entry>
	      <entry>Leírás</entry>
	    </row>
	  </thead>

	  <tbody>
	    <row>
	      <entry><hostid>haboru</hostid>, <hostid>halal</hostid>,
		<hostid>ehseg</hostid>, <hostid>szennyezes</hostid></entry>
	      <entry>A legfontosabb szervereink.  Csak az IT
		tanszék dolgozói férhetnek
		hozzájuk.</entry>
	    </row>
	    <row>
	      <entry><hostid>buszkeseg</hostid>,
		<hostid>kapzsisag</hostid>, <hostid>irigyseg</hostid>,
		<hostid>harag</hostid>, <hostid>bujasag</hostid>,
		<hostid>lustasag</hostid></entry>
		<entry>Kevésbé fontos szerverek.  Az IT
		tankszék összes tagja el tudja érni
		ezeket a gépeket.</entry>
	    </row>

	    <row>
	      <entry><hostid>egy</hostid>, <hostid>ketto</hostid>,
		<hostid>harom</hostid>, <hostid>negy</hostid>,
		...</entry>
	      <entry>Átlagos munkaállomások.
		Egyedül csak a <emphasis>valódi</emphasis>
		dolgozók jelentkezhetnek be ezekre a
		gépekre.</entry>
	    </row>

	    <row>
	      <entry><hostid>szemetes</hostid></entry>
	      <entry>Egy nagyon régi gép, semmi
		értékes adat nincs rajta.  Akár
		még az öszöndíjasok is
		nyúzhatják.</entry>
	    </row>
	  </tbody>
	</tgroup>
      </informaltable>

      <para>Ha ezeket az igényeket úgy
	próbáljuk meg teljesíteni, hogy a
	felhasználókat egyenként blokkoljuk, akkor
	minden rendszer <filename>passwd</filename>
	állományába külön fel kell
	vennünk a
	<literal>-<replaceable>felhasználó</replaceable></literal>
	sorokat a letiltott felhasználókhoz.  Ha csak
	egyetlen bejegyzést is kihagyunk, akkor könnyen
	bajunk származhat belõle.  Ez a rendszer kezdeti
	beállítása során még
	talán nem okoz gondot, de az új
	felhasználókat <emphasis>biztosan</emphasis> el
	fogjuk felejteni felvenni a megfelelõ csoportokba.
	Elvégre Murphy is optimista volt.</para>

      <para>A hálózati csoportok használata ilyen
	helyzetekben számos elõnyt rejt.  Nem kell az egyes
	felhasználókat külön felvenni, egy
	felhasználót felveszünk valamelyik csoportba
	vagy csoportokba, és a csoportok összes
	tagjának egyszerre tudjuk tiltani vagy
	engedélyezni a hozzáféréseket.  Ha
	hozzáadunk egy új gépet a
	hálózatunkhoz, akkor mindössze a
	hálózati csoportok bejelentkezési
	korlátozásait kell beállítani.  Ha
	új felhasználót veszünk fel, akkor a
	felhasználót kell vennünk egy vagy több
	hálózati csoportba.  Ezek a
	változtatások függetlenek
	egymástól, és nincs szükség
	<quote>minden felhasználó és minden
	gép összes
	kombinációjára</quote>.  Ha a NIS
	beállításainkat elõzetesen
	körültekintõen megterveztük, akkor egyetlen
	központi konfigurációs
	állományt kell módosítani a
	gépek elérésének
	engedélyezéséhez vagy
	tiltásához.</para>

      <para>Az elsõ lépés a hálózati
	csoportokat tartalmazó NIS táblázat
	inicializálása.  A &os; &man.ypinit.8; programja
	alapértelmezés szerint nem hozza létre ezt
	a táblázatot, de ha készítünk
	egy ilyet, akkor a NIS implementációja
	képes kezelni.  Egy ilyen üres
	táblázat
	elkészítéséhez ennyit kell
	begépelni:</para>

      <screen>ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput></screen>

      <para>Ezután elkezdhetjük felvenni a tartalmát.
	A példánk szerint legalább négy
	hálózati csoportot kell csinálnunk: az IT
	dolgozóinak, az IT új dolgozóinak, a
	normál dolgozóknak és az
	öszöndíjasoknak.</para>

      <programlisting>IT_DOLG       (,alpha,proba-tartomany)    (,beta,proba-tartomany)
IT_UJDOLG     (,charlie,proba-tartomany)  (,delta,proba-tartomany)
FELHASZNALO   (,echo,proba-tartomany)     (,foxtrott,proba-tartomany) \
              (,golf,proba-tartomany)
OSZTONDIJAS   (,able,proba-tartomany)     (,baker,proba-tartomany)</programlisting>

      <para>Az <literal>IT_DOLG</literal>, <literal>IT_UJDOLG</literal>
	stb.  a hálózati csoportok nevei lesznek.  Minden
	egyes zárójelezett csoport egy vagy több
	felhasználói hozzáférést
	tartalmaz.  A csoportokban szereplõ három mezõ
	a következõ:</para>

      <orderedlist>
	<listitem>
	  <para>Azon gépek neve, amelykre a következõ
	    elemek érvényesek.  Ha itt nem adunk meg
	    neveket, akkor a bejegyzés az összes
	    gépre vonatkozik.  Ha megadjuk egy gép
	    nevét, akkor jutalmunk a teljes
	    sötétség, a rettegetés és
	    totális megtébolyodás.</para>
	</listitem>

	<listitem>
	  <para>A csoporthoz tartozó
	    hozzáférés neve.</para>
	</listitem>

	<listitem>
	  <para>A hozzáféréshez
	    kapcsolódó NIS tartomány.  A csoportba
	    más NIS tartományokból is át
	    tudunk hozni hozzáféréseket, ha
	    netalán éppen olyan szerencsétlenek
	    lennénk, hogy több NIS tartományt is
	    felügyelnünk kell.</para>
	</listitem>
      </orderedlist>

      <para>A mezõk mindegyike tartalmazhat
	dzsókerkaraktereket.  Errõl részletesebben a
	&man.netgroup.5; man oldalon olvashatunk.</para>

      <note>
	<indexterm><primary>hálózati
	  csoportok</primary></indexterm>

	<para>A hálózati csoportoknak lehetõleg ne
	  adjunk 8 karakternél hosszabb nevet,
	  különösen abban az esetben, ha a NIS
	  tartományban más operációs
	  rendszereket is használunk.  A nevekben eltérnek
	  a kis- és nagybetûk.  Ha a hálózati
	  csoportokat nevét nagybetûkkel írjuk, akkor
	  könnyen különbséget tudunk tenni a
	  felhasználók, gépek és
	  hálózati csoportok nevei
	  között.</para>

	<para>Egyes (nem &os; alapú) NIS kliensek nem
	  képesek kezelni a nagyon sok bejegyzést
	  tartalmazó hálózati csoportokat.
	  Például a &sunos; néhány
	  korábbi verziója fennakad rajta, ha egy
	  hálózati csoport 15
	  <emphasis>bejegyzésnél</emphasis> többet
	  tartalmaz.  Az ilyen korlátozások alól
	  úgy tudunk kibújni, ha 15
	  felhasználónként újabb
	  hálózati csoportokat hozunk létre,
	  amelyekkel az eredeti hálózati csoportot
	  építjük fel:</para>

	<programlisting>NAGYCSP1  (,joe1,tartomany)  (,joe2,tartomany)  (,joe3,tartomany) [...]
NAGYCSP2  (,joe16,tartomany)  (,joe17,tartomany) [...]
NAGYCSP3  (,joe31,tartomany)  (,joe32,tartomany)
NAGYCSOPORT  NAGYCSP1 NAGYCSP2 NAGYCSP3</programlisting>

	<para>Ugyanez a folyamat javasolt olyan esetekben is, ahol 225
	  felhasználónál többre lenne
	  szükség egyetlen hálózati csoporton
	  belül.</para>
      </note>

      <para>Az így létrehozott új NIS
	táblázat szétküldése
	meglehetõsen könnyû feladat:</para>

      <screen>ellington&prompt.root; <userinput>cd /var/yp</userinput>
ellington&prompt.root; <userinput>make</userinput></screen>

      <para>Ez a parancs létrehoz három NIS
	táblázatot: <filename>netgroup</filename>,
	<filename>netgroup.byhost</filename> és
	<filename>netgroup.byuser</filename>.  Az &man.ypcat.1;
	paranccsal ellenõrizni is tudjuk az új NIS
	táblázatainkat:</para>

      <screen>ellington&prompt.user; <userinput>ypcat -k netgroup</userinput>
ellington&prompt.user; <userinput>ypcat -k netgroup.byhost</userinput>
ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput></screen>

      <para>Az elsõ parancs kimenete a
	<filename>/var/yp/netgroup</filename> állomány
	tartalmára emlékeztethet minket.  A második
	parancsnak nincs semmilyen kimenete, hacsak nem adtunk meg
	valamilyen gépfüggõ hálózati
	csoportot.  A harmadik parancs a hálózati
	csoportokat listázza ki a
	felhasználókhoz.</para>

      <para>A kliensek beállítása tehát
	nagyon egyszerû.  A <hostid>haboru</hostid> nevû
	szerver beállításához
	indítsuk el a &man.vipw.8; programot, és
	cseréljük a</para>

      <programlisting>+:::::::::</programlisting>

      <para>sort erre:</para>

      <programlisting>+@IT_DOLG:::::::::</programlisting>

      <para>Innentõl kezdve kizárólag csak az
	<literal>IT_DOLG</literal> csoportban található
	felhasználók fognak bekerülni a
	<hostid>haboru</hostid> jelszó
	adatbázisába, és csak ezek a
	felhasználók tudnak ide bejelentkezni.</para>

      <para>Sajnos ez a korlátozás a
	parancsértelmezõ <literal>~</literal>
	funkciójára és összes olyan rutinra is
	vonatkozik, amelyet a felhasználói nevek és
	azok numerikus azonosító között
	képez le.  Más szóval a <command>cd
	~<replaceable>felhasználó</replaceable></command>
	parancs nem fog mûködni, és az <command>ls
	-l</command> parancs kimenetében a
	felhasználói nevek helyett csak numerikus
	azonosítók jelennek meg, továbbá
	a<command>find .  -user joe -print</command> <errorname>No such
	user</errorname> (<errorname>Nincs ilyen
	felhasználó</errorname>) hibát fog
	visszaadni.  Ez úgy tudjuk megjavítani, ha
	úgy importáljuk a szerverre az összes
	felhasználó bejegyzését, hogy
	<emphasis>közben tiltjuk a
	hozzáférésüket</emphasis>.</para>

      <para>Ehhez vegyünk fel egy újabb sort az
	<filename>/etc/master.passwd</filename>
	állományba.  A sor valahogy így fog
	kinézni:</para>

      <para><literal>+:::::::::/sbin/nologin</literal>, amely annyit
	tesz, hogy <quote>importáljuk az összes
	bejegyzést, de a hozzájuk tartozó
	parancsértelmezõ a
	<filename>/sbin/nologin</filename> legyen</quote>.  A
	<literal>passwd</literal> állományban
	tetszõleges mezõ tartalmát le tudjuk úgy
	cserélni, ha megadunk neki egy alapértelmezett
	értéket az <filename>/etc/master.passwd</filename>
	állományban.</para>

      <warning>
	<para>Vigyázzunk, hogy a
	  <literal>+:::::::::/sbin/nologin</literal> sort az
	  <literal>+@IT_DOLG:::::::::</literal> sor után
	  írjuk.  Ha nem így teszünk, akkor a
	  NIS-bõl importált összes
	  felhasználói hozzáférés a
	  <filename>/sbin/nologin</filename>
	  parancsértelmezõt kapja.</para>
      </warning>

      <para>Miután elvégeztük ezt a
	változtatást, minden újabb dolgozó
	felvétele után csupán egyetlen
	táblázatot kell megváltoztatnunk.  Ugyanezt
	a taktikát követhetjük a kevésbé
	fontosabb szerverek esetében is, hogy ha a helyi
	<filename>/etc/master.passwd</filename>
	állományukban a korábbi
	<literal>+:::::::::</literal> bejegyzést valami
	ilyesmivel helyettesítjük:</para>

      <programlisting>+@IT_DOLG:::::::::
+@IT_UJDOLG:::::::::
+:::::::::/sbin/nologin</programlisting>

      <para>Az egyszerû munkaállomások
	esetében pedig ezekre a sorokra lesz
	szükségünk:</para>

      <programlisting>+@IT_DOLG:::::::::
+@FELHASZNALOK:::::::::
+:::::::::/sbin/nologin</programlisting>

      <para>Minden remekül üzemel egészen addig,
	amíg néhány hét múlva
	ismét változik a házirend: az IT
	tanszékre ösztöndíjasok érkeznek.
	Az IT ösztöndíjasai a
	munkaállomásokat és a kevésbé
	fontosabb szervereket tudják használni.  Az
	új IT dolgozók már a központi
	szerverekre is bejelentkezhetnek.  Így tehát
	létrehozunk egy új hálózati
	csoportot <literal>IT_OSZTONDIJAS</literal> néven, majd
	felvesszük ide az új IT
	ösztöndíjasokat, és nekilátunk
	végigzongorázni az összes gép
	összes konfigurációs
	állományát...  Ahogy azonban egy
	régi mondás is tartja: <quote>A
	központosított tervezésben ejtett
	hibák teljes káoszhoz vezetnek</quote>.</para>

      <para>A NIS az ilyen helyzeteket úgy igyekszik
	elkerülni, hogy megengedi újabb
	hálózati csoportok
	létrehozását más
	hálózati csoportokból.  Egyik ilyen
	lehetõség a szerep alapú
	hálózati csoportok kialakítása.
	Például, ha a fontosabb szerverek
	bejelentkezési korlátozásai
	számára hozzunk létre egy
	<literal>NAGYSRV</literal> nevû csoportot, valamint egy
	másik hálózati csoportot
	<literal>KISSRV</literal> néven a kevésbé
	fontosabb szerverekhez, végül
	<literal>MUNKA</literal> néven egy harmadik
	hálózati csoportot a
	munkaállomásokhoz.  Mindegyik ilyen
	hálózati csoport tartalmazza azokat a csoportokat,
	amelyek engedélyezik a gépek
	elérését.  A hálózati
	csoportok leírását tartalmazó NIS
	táblázat most valahogy így fog
	kinézni:</para>

      <programlisting>NAGYSRV  IT_DOLG IT_UJDOLG
KISSRV   IT_DOLG IT_UJDOLG IT_OSZTONDIJAS
MUNKA    IT_DOLG IT_OSZTONDIJAS FELHASZNALOK</programlisting>

      <para>A bejelentkezési megszorítások ilyen
	típusú megadása viszonylag jól
	mûködik, hogy ha azonos korlátozások
	alá esõ gépek csoportjait akarjuk
	felírni.  Bánatunk ez a kivétel, és
	nem a szabály.  Az esetek nagy
	többségében ugyanis a bejelentkezésre
	vonatkozó korlátozásokat
	gépenként kell egyesével megadni.</para>

      <para>A hálózati csoportok gépfüggõ
	megadása tehát az iménti házirendhez
	társuló igények
	kielégítésének egyik módja.
	Ebben a forgatókönyvben az
	<filename>/etc/master.passwd</filename> állomány
	minden számítógépen két
	<quote>+</quote>-os sorral kezdõdik.
	Közülük az elsõ a gépen
	engedélyezett hozzáféréseket
	tartalmazó hálózati csoportra vonatkozik, a
	második pedig az összes többi
	hozzáféréshez az
	<filename>/sbin/nologin</filename> parancsértelmezõt
	kapcsolja hozzá.  Itt jó ötlet, ha a
	gép nevének
	<quote>VÉGIG-NAGYBETûS</quote>
	változatát adjuk meg a hozzá tartozó
	hálózati csoport nevének:</para>

      <programlisting>+@<replaceable>GÉPNÉV</replaceable>:::::::::
+:::::::::/sbin/nologin</programlisting>

      <para>Miután elvégeztük ezt a feladatot minden
	egyes gépen, az <filename>/etc/master.passwd</filename>
	állomány helyi változatait soha
	többé nem kell módosítanunk.  Az
	összes többi változtatást a NIS
	táblázaton keresztül tudjuk keresztül
	vinni.  Íme a felvázolt
	forgatókönyvhöz tartozó
	hálózati csoportok
	kiépítésének egyik lehetséges
	változata, egy-két finomsággal
	kiegészítve:</para>

      <programlisting># Elõször a felhasználók csoportjait adjuk meg:
IT_DOLG         (,alpha,proba-tartomany)    (,beta,proba-tartomany)
IT_UJDOLG       (,charlie,proba-tartomany)  (,delta,proba-tartomany)
TANSZ1          (,echo,proba-tartomany)     (,foxtrott,proba-tartomany)
TANSZ2          (,golf,proba-taromany)      (,hotel,proba-tartomany)
TANSZ3          (,india,proba-taromany)     (,juliet,proba-tartomany)
IT_OSZTONDIJAS  (,kilo,proba-tartomany)     (,lima,proba-tartomany)
D_OSZTONDIJAS   (,able,proba-tartomany)     (,baker,proba-tartomany)
#
# Most pedig hozzunk létre csoportokat szerepek szerint:
FELHASZNALOK     TANSZ1   TANSZ2          TANSZ3
NAGYSRV          IT_DOLG  IT_UJDOLG
KISSRV           IT_DOLG  IT_UJDOLG       IT_OSZTONDIJAS
MUNKA            IT_DOLG  IT_OSZTONDIJAS  FELHASZNALOK
#
# Következzenek a speciális feladatokhoz tartozó csoportok:
# Az echo és a golf tudja elérni a vírusvédelemért felelõs gépet:
VEDELEM          IT_DOLG  (,echo,proba-tartomany)  (,golf,proba-tartomany)
#
# Gép alapú hálózati csoportok
# A fõ szervereink:
HABORU      NAGYSRV
EHSEG       NAGYSRV
# Az india nevû felhasználó hozzá szeretné ehhez férni:
SZENNYEZES  NAGYSRV  (,india,proba-tartomany)
#
# Ez valóban fontos és komolyan szabályoznunk kell:
HALAL       IT_DOLG
#
# Az elõbb említett vírusvédelmi gép:
EGY         VEDELEM
#
# Egyetlen felhasználóra korlátozzuk le ezt a gépet:
KETTO       (,hotel,proba-tartomany)
# [...és itt folytatódik a többi csoporttal]</programlisting>

      <para>Ha a felhasználói
	hozzáféréseinket valamilyen
	adatbázisban tároljuk, akkor a
	táblázat elsõ részét
	akár az adatbázis lekérdezésein
	keresztül is elõ tudjuk állítani.  Ezzel
	a módszerrel az új felhasználók
	automatikusan hozzáférnek a
	gépekhez.</para>

      <para>Legyünk viszont óvatosak: nem mindig javasolt
	gépeken alapuló hálózati csoportokat
	készíteni.  Ha a hallgatói laborokba
	egyszerre több tucat vagy akár több száz
	azonos konfigurációjú gépet
	telepítünk, akkor a gép alapú
	csoportok helyett inkább szerep alapú csoportokat
	építsünk fel, mivel így a NIS
	táblázatok méretét egy
	elfogadható méreten tudjuk tartani.</para>

    </sect2>

    <sect2>
      <title>Amit feltétlenül észben kell
	tartanunk</title>

      <para>Még mindig akad néhány olyan dolog,
	amit másképpen kell csinálnunk
	azután, hogy most már NIS környezetben
	vagyunk.</para>

      <itemizedlist>
	<listitem>
	  <para>Amikor egy új felhasználót akarunk
	    felvenni a laborba, akkor <emphasis>csak</emphasis> a
	    központi NIS szerverre kell felvennünk, és
	    <emphasis>újra kell generáltatnunk a NIS
	    táblázatokat</emphasis>.  Ha ezt
	    elfelejtjük megtenni, akkor az új
	    felhasználó a központi NIS szerveren
	    kívül sehova sem lesz képes
	    bejelentkezni.  Például, ha fel akarjuk venni
	    a <username>jsmith</username> nevû
	    felhasználót a laborba, akkor ezt kell
	    tennünk:</para>

	  <screen>&prompt.root; <userinput>pw useradd jsmith</userinput>
&prompt.root; <userinput>cd /var/yp</userinput>
&prompt.root; <userinput>make proba-tartomany</userinput></screen>

	  <para>Vagy a <command>pw useradd jsmith</command> parancs
	    helyett az <command>adduser jsmith</command> parancsot is
	    használhatjuk.</para>
	</listitem>
	<listitem>
	  <para><emphasis>A rendszergazdai szintû
	    hozzáféréseket ne tároljuk a NIS
	    táblázatokban</emphasis>.  Olyan
	    gépekre egyáltalán ne is
	    küldjünk olyan karbantartáshoz
	    használt hozzáféréseket,
	    amelynek a felhasználói hivatalosan nem is
	    férhetnének hozzájuk.</para>
	</listitem>
	<listitem>
	  <para><emphasis>A központi NIS szervert és az
	    alárendelt szervereket óvjuk minél
	    jobban, és igyekezzünk minimalizálni a
	    kieséseiket</emphasis>.  Ha valaki feltöri vagy
	    egyszerûen csak kikapcsolja ezeket a gépeket,
	    akkor ezzel lényegében mindenkit
	    megakadályoz abban, hogy be tudjon jelentkezni a
	    laborban.</para>

	  <para>Ezek a központosított
	    vezérlésû rendszerek legfõbb
	    gyengeségei.  Ha nem védjük kellõen
	    a NIS szervereinket, akkor azzal nagyon ellenséget
	    szerezhetünk magunknak!</para>
	</listitem>
      </itemizedlist>

    </sect2>

    <sect2>
      <title>Kompatibilitás a NIS elsõ
	változatával</title>

      <para>A &os;-ben megtalálható
	<application>ypserv</application> szolgáltatás
	valamennyire képes ellátni a NIS elsõ
	változatát használó klienseket is.
	A &os; NIS implementációja csak a NIS v2
	protokollt használja, azonban mivel más
	implementációk kompatibilisek
	kívánnak maradni a régebbi rendszerekkel,
	ismerik a v1 protokollt is.  Az ilyen rendszerekhez
	tartozó <application>ypbind</application> démonok
	még olyankor is megpróbálnak v1-es NIS
	szerverekhez kötést létrehozni, amikor
	valójában nincs is rá
	szükségük (és gyakran még akkor
	is ilyet keresnek, amikor az üzenetükre már
	válaszolt egy v2-es szerver).
	Hozzátennénk, hogy bár az
	<application>ypserver</application> ezen változata a
	normál klienshívásokat képes
	feldolgozni, a táblázatokat már nem tudja
	átküldeni a v1-es klienseknek.  Ebbõl
	következik, hogy a központi vagy alárendelt
	szerverek nem tudnak együttmûködni olyan NIS
	szerverekkel, amelyek csak a v1-es protokollt beszélik.
	Szerencsére ilyen szervereket manapság már
	alig használnak.</para>

    </sect2>

    <sect2 id="network-nis-server-is-client">
      <title>NIS szerverek, melyek egyben NIS kliensek</title>

      <para>Óvatosan kell bánnunk az
	<application>ypserv</application>
	elindításával olyan többszerveres
	tartományokban, ahol a szerverek maguk is NIS kliensek.
	Alapvetõen nincs abban semmi kivetnivaló, ha a
	szervereket saját magukhoz kötjük ahelyett,
	hogy engednénk nekik a kötési
	kérések küldését és
	így egymáshoz kötnénk ezeket.
	Különös hibák tudnak származni
	olyan helyzetekben, amikor az egyik szerver leáll,
	miközben a többiek pedig függenek tõle.
	Végül is ilyenkor minden kliens szépen
	kivárja a szükséges idõt, aztán
	megpróbál más szerverekhez
	kötõdni, de az itt fellépõ
	késlekedés jelentõs mennyiségû
	lehet, és ez a hibajelenség ismét
	fennállhat, mivel elõfordulhat, hogy a szerverek
	megint egymáshoz kapcsolódnak.</para>

      <para>A klienst úgy tudjuk egy adott szerverhez kötni,
	ha az <command>ypbind</command> parancsot a <option>-S</option>
	beállítással indítjuk.  Ha mindezt
	nem akarjuk manuálisan megtenni a NIS szerver minden
	egyes újraindításakor, akkor vegyük
	fel a következõ sorokat az
	<filename>/etc/rc.conf</filename>
	állományba:</para>

      <programlisting>nis_client_enable="YES"	# elindítjuk a klienst is
nis_client_flags="-S <replaceable>NIS tartomány</replaceable>,<replaceable>szerver</replaceable>"</programlisting>

      <para>Részletesebb lásd az &man.ypbind.8; man
	oldalát.</para>

    </sect2>

    <sect2>
      <title>A jelszavak formátuma</title>

      <indexterm>
	<primary>NIS</primary>
	<secondary>jelszavak formátuma</secondary>
      </indexterm>

      <para>A NIS rendszerek kiépítése során
	az emberek leggyakrabban a jelszavak formátumával
	kapcsolatban tapasztalnak nehézségeket.  Ha a
	szerverünk DES titkosítású jelszavakat
	használ, akkor csak olyan klienseket fog tudni
	támogatni, amelyek szintén így
	kódolják ezeket.  Például, ha a
	hálózaton vannak &solaris; rendszerû NIS
	klienseink, akkor szinte biztos, hogy DES
	titkosítást kell használnunk.</para>

      <para>A szerverek és a kliensek által
	használt formátumokat az
	<filename>/etc/login.conf</filename> állományba
	tekintve deríthetjük ki.  Ha a gépek
	többségén a DES titkosítást
	látjuk, akkor a <literal>default</literal>
	osztálynak egy ilyen bejegyzést kell
	tartalmaznia:</para>

      <programlisting>default:\
	:passwd_format=des:\
	:copyright=/etc/COPYRIGHT:\
	[a többit most nem mutatjuk]</programlisting>

      <para>A <literal>passwd_format</literal> tulajdonság
	további lehetséges értékei lehetnek
	a <literal>blf</literal> és az <literal>md5</literal>
	(melyek rendre a Blowfish és MD5
	titkosítású jelszavakat adják
	meg).</para>

      <para>Ha változtattunk valamit az
	<filename>/etc/login.conf</filename> állományban,
	akkor a bejelentkezési tulajdonságok
	adatbázisát is újra kell generálni,
	melyet <username>root</username>
	felhasználóként a következõ
	módon tehetünk meg:</para>

      <screen>&prompt.root; <userinput>cap_mkdb /etc/login.conf</userinput></screen>

      <note>
	<para>Az <filename>/etc/master.passwd</filename>
	  állományban jelenlevõ jelszavak
	  formátuma azonban nem frissítõdik
	  egészen addig, amíg a felhasználók
	  a bejelentkezési adatbázis
	  újragenerálása
	  <emphasis>után</emphasis> meg nem
	  változtatják a jelszavaikat.</para>
      </note>

      <para>Úgy tudjuk még biztosítani, hogy a
	jelszavak megfelelõ formátumban
	kódolódjanak, ha az
	<filename>/etc/auth.conf</filename> állományban
	megkeressük a <literal>crypt_default</literal> sort,
	amelyben a választható
	jelszóformátumok
	felhasználásái sorrendjét
	találhatjuk meg.  Itt tehát mindössze annyit
	kell tennünk, hogy a kiszemelt formátumot a lista
	elejére tesszük.  Például, ha a DES
	titkosítású jelszavakat akarunk
	használni, akkor ez a bejegyzés így fog
	kinézni:</para>

      <programlisting>crypt_default	=	des blf md5</programlisting>

      <para>Ha a fenti lépéseket követjük az
	összes &os; alapú NIS szervernél és
	kliensnél, akkor biztosra mehetünk abban, hogy a
	hálózatunkon belül ugyanazt a
	jelszóformátumot fogják használni.
	Ha gondunk akadna a NIS kliensek
	hitelesítésével, akkor itt érdemes
	kezdeni a hiba felderítését.  Ne
	felejtsük: ha egy NIS szervert egy heterogén
	hálózatba akarunk telepíteni, akkor
	valószínûleg az összes rendszeren a DES
	titkosítást kell választani, mivel
	általában ez a közös nevezõ ebben a
	tekintetben.</para>

    </sect2>
  </sect1>

  <sect1 id="network-dhcp">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Greg</firstname>
	  <surname>Sutter</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>A hálózat automatikus
      beállítása (DHCP)</title>

    <sect2>
      <title>Mi az a DHCP?</title>

      <indexterm>
	<primary>Dinamikus
	  állomáskonfigurációs
	  protokoll</primary>
	<see>DHCP</see>
      </indexterm>
      <indexterm><primary>internetes rendszerkonzorcium
	(ISC)</primary></indexterm>

      <para>A Dinamikus állomáskonfigurációs
	protokoll, avagy Dynamic Host Configuration Protocol (DHCP)
	annak eszközeit írja le, hogy egy rendszer
	miként tud csatlakozni egy hálózathoz
	és miként tudja azon belül megszerezni a
	kommunikációhoz szükséges
	információkat.  A &os;&nbsp;6.0 elõtti
	változatai az ISC (Internet Systems Consortium, vagyis
	az internetes rendszerkonzorcium) által kidolgozott DHCP
	kliens (&man.dhclient.8;) implementációját
	tartalmazzák.  A késõbbi verziókban
	pedig az OpenBSD&nbsp;3.7 verziójából
	átvett <command>dhclient</command> paranccsal
	dolgozhatunk.  Ebben a szakaszban a <command>dhclient</command>
	parancsra vonatkozó összes információ
	egyaránt érvényes az ISC és az
	OpenBSD által fejlesztett DHCP kliensekre.  A DHCP
	szerver az ISC-tõl származik.</para>

    </sect2>

    <sect2>
      <title>Mivel foglalkozik ez a szakasz</title>

      <para>Ebben a szakaszban az ISC és az OpenBSD DHCP
	klienseinek kliens- és szerver oldali komponsenseit
	mutatjuk be.  A kliens oldali program neve a
	<command>dhclient</command>, amely a &os;
	részeként érkezik, és a szerver
	oldali elem pedig a <filename
	  role="package">net/isc-dhcp31-server</filename> porton
	keresztül érhetõ el.  A lentebb említett
	hivatkozások mellett a témában még a
	&man.dhclient.8;, &man.dhcp-options.5; és a
	&man.dhclient.conf.5; man adhatnak bõvebb
	felvilágosítást a
	témában.</para>

    </sect2>

    <sect2>
      <title>Ahogyan mûködik</title>

      <indexterm><primary>UDP</primary></indexterm>

      <para>Amikor a <command>dhclient</command>, vagyis a DHCP kliens
	elindul egy kliensgépen, akkor a hálózaton
	üzenetszórással próbálja meg
	elkérni a konfigurációjához
	szükséges adatokat.  Alapértelmezés
	szerint ezek a kérések a 68-as UDP porton
	keresztül mennek.  A szerver ezekre a 67-es UDP porton
	válaszol, ahol visszaad a kliensnek egy IP-címet
	és a hálózat használatához
	szükséges további
	információkat, mint például a
	hálózati maszkot, az alapértelmezett
	átjáró és a
	névfeloldásért felelõs szerverek
	címét.  Az összes ilyen jellegû adat egy
	DHCP <quote>bérlet</quote> (lease)
	formájában érkezik meg, amely csak egy
	adott ideig érvényes (ezt a DHCP szerver
	karbantartója állítja be).  Így a
	hálózaton a kliens nélküli
	IP-címeket egy idõ után automatikusan
	visszanyerjük.</para>

      <para>A DHCP kliensek rengeteg információt
	képes elkérni a szervertõl.  Ezek teljes
	listáját a &man.dhcp-options.5; man oldalán
	olvashatjuk el.</para>

    </sect2>

    <sect2>
      <title>Használat a &os;-n belül</title>

      <para>A &os; teljes egészében tartalmazza az ISC
	vagy az OpenBSD DHCP kliensét, a
	<command>dhclient</command> programot (attól
	függõen, hogy a &os; melyik változatát
	használjuk).  A DHCP kliensek támogatása a
	telepítõben és az alaprendszerben is
	megtalálható, és ezzel
	mentesülünk minden konkrét
	hálózati beállítás
	alól a DHCP szervereket alkalmazó
	hálózatokon.  A <command>dhclient</command> a
	&os;&nbsp;3.2 változata óta
	megtalálható a rendszerben.</para>

      <indexterm><primary><application>sysinstall</application></primary></indexterm>

      <para>DHCP használatát a
	<application>sysinstall</application> is lehetõvé
	teszi.  Amikor egy hálózati felületet a
	<application>sysinstall</application> programon belül
	állítunk be, akkor a második
	kérdés mindig ez szokott lenni: <quote>Do you want
	to try DHCP configuration of the interface?</quote>
	(<quote>Megpróbáljuk DHCP
	használatával beállítani a
	felületet?</quote>) Ha erre igennel válaszolunk,
	akkor azzal lényegében a
	<command>dhclient</command> parancsot indítjuk el,
	és ha mindez sikerrel zárul, akkor szinte
	magától kitöltõdik az összes
	hálózati beállításunk.</para>

      <para>A DHCP használatához két dolgot kell
	beállítanunk a rendszerünkön:</para>

      <indexterm>
	<primary>DHCP</primary>
	<secondary>követelmények</secondary>
      </indexterm>

	<itemizedlist>
	  <listitem>
	    <para>Gondoskodjunk róla, hogy a
	      <devicename>bpf</devicename> eszköz része a
	      rendszermagunknak.  Ha még nem lenne benne, akkor a
	      rendszermag beállításait
	      tartalmazó állományba vegyük fel
	      a <literal>device bpf</literal> sort és
	      fordítsuk újra a rendszermagot.  A
	      rendszermagok fordításáról a
	      <xref linkend="kernelconfig"/>ben tudhatunk meg
	      többet.</para>

	    <para>A <devicename>bpf</devicename> eszköz
	      alapból megtalálható a
	      <filename>GENERIC</filename> rendszermagokban, így
	      ha ezt használjuk, akkor nem kell saját
	      verziót készítenünk a DHCP
	      használatához.</para>

	    <note>
	      <para>Azok számára viszont, akik
		biztonsági szempontból aggódnak a
		rendszerük miatt, meg kell említenünk,
		hogy a <devicename>bpf</devicename> egyben az az
		eszköz, amely a csomagok
		lehallgatását is lehetõvé
		teszi (habár az ilyeneket
		<username>root</username>
		felhasználóként lehet csak
		elindítani).  A <devicename>bpf</devicename>
		<emphasis>kell</emphasis> a DHCP
		használatához, azonban ha nagyon fontos
		nekünk a rendszerünk biztonsága, akkor
		a <devicename>bpf</devicename> eszközt
		érdemes kivennünk a rendszermagból,
		ha még pillanatnyilag nem használunk
		ilyet.</para>
	    </note>
	  </listitem>
	  <listitem>
	    <para>Az <filename>/etc/rc.conf</filename>
	      állományunkat az alábbiak szerint
	      kell módosítani:</para>

	    <programlisting>ifconfig_fxp0="DHCP"</programlisting>

	    <note>
	      <para>Az <literal>fxp0</literal> eszközt ne
		felejtsük el kicserélni arra a
		felületre, amelyet automatikusan akarunk
		beállítani.  Ennek mikéntje a <xref
		linkend="config-network-setup"/>ban
		olvasható.</para>
	    </note>

	    <para>Ha a <command>dhclient</command> a rendszerünkben
	      máshol található, vagy
	      egyszerûen csak további
	      beállításokat akarunk átadni a
	      <command>dhclient</command> parancsnak, akkor adjuk meg a
	      következõt is (változtassuk meg
	      igényeink szerint):</para>

	    <programlisting>dhclient_program="/sbin/dhclient"
dhclient_flags=""</programlisting>
	  </listitem>
	</itemizedlist>

	<indexterm>
	  <primary>DHCP</primary>
	  <secondary>szerver</secondary>
	</indexterm>

	    <para>A DHCP szerver, a <application>dhcpd</application> a
	      <filename role="package">net/isc-dhcp31-server</filename>
	      port részeként érhetõ el.  Az a
	      port tartalmazza az ISC DHCP szerverét és a
	      hozzá tartozó
	      dokumentációt.</para>

    </sect2>

    <sect2>
      <title>Állományok</title>

      <indexterm>
	<primary>DHCP</primary>
	<secondary>konfigurációs
	  állományok</secondary>
      </indexterm>

      <itemizedlist>
	<listitem>
	  <para><filename>/etc/dhclient.conf</filename></para>

	  <para>A <command>dhclient</command>
	    mûködéséhez szükség lesz
	    egy konfigurációs állományra,
	    aminek a neve <filename>/etc/dhclient.conf</filename>.  Ez
	    az állomány általában csak
	    megjegyzéseket tartalmaz, mivel az
	    alapértelmezett értékek többnyire
	    megfelelõek.  Ezt a konfigurációs
	    állományt a &man.dhclient.conf.5; man oldal
	    írja le.</para>
	</listitem>

	<listitem>
	  <para><filename>/sbin/dhclient</filename></para>

	  <para>A <command>dhclient</command> statikusan linkelt
	    és az <filename>/sbin</filename>
	    könyvtárban található.  A
	    &man.dhclient.8; man oldal tud róla
	    részletesebb felvilágosítást
	    adni.</para>
	</listitem>

	<listitem>
	  <para><filename>/sbin/dhclient-script</filename></para>

	  <para>A <command>dhclient-script</command> a &os;-ben
	    levõ DHCP kliens konfigurációs szkriptje.
	    Mûködését a &man.dhclient-script.8;
	    man oldal írja le, de a felhasználók
	    részérõl semmilyen
	    módosítást nem igényel.</para>
	</listitem>

	<listitem>
	  <para><filename>/var/db/dhclient.leases</filename></para>

	  <para>A DHCP kliens az érvényes
	    bérleteket tartja nyilván ezekben az
	    állományban és naplóként
	    használja.  A &man.dhclient.leases.5; man oldal ezt
	    valamivel bõvebben kifejti.</para>
	</listitem>
      </itemizedlist>
    </sect2>

    <sect2>
      <title>További olvasnivalók</title>

      <para>A DHCP protokoll mûködését az <ulink
	url="http://www.freesoft.org/CIE/RFC/2131/">RFC&nbsp;2131</ulink>
	mutatja be.  A témához kapcsolódóan
	<ulink url="http://www.dhcp.org/"> itt</ulink> tudunk még
	leírásokat találni.</para>

    </sect2>

    <sect2 id="network-dhcp-server">
	<title>A DHCP szerverek telepítése és
	  beállítása</title>

	<sect3>
	  <title>Mirõl szól ez a szakasz</title>

	  <para>Ebben a szakaszban arról olvashatunk, hogy
	    miként kell egy &os; típusú rendszert
	    DHCP szervernek beállítani, ha az ISC
	    (internetes rendszerkonzorcium) DHCP szerverét
	    használjuk.</para>

	  <para>Ez a szerver nem része a &os;-nek, ezért a
	    szolgáltatás
	    elindításához elõször fel
	    kell raknunk a <filename
	      role="package">net/isc-dhcp31-server</filename> portot.  A
	    Portgyûjtemény használatára
	    vonatkozóan a <xref linkend="ports"/> lehet
	    segítségünkre.</para>

	</sect3>

	<sect3>
	  <title>A DHCP szerver telepítése</title>

	  <indexterm>
	    <primary>DHCP</primary>
	    <secondary>telepítés</secondary>
	  </indexterm>

	  <para>Ha a &os; rendszerünket DHCP szerverként
	    akarjuk beállítani, akkor ehhez
	    elsõként a &man.bpf.4; eszköz
	    jelenlétét kell biztosítani a
	    rendszermagban.  Ehhez vegyük fel a <literal>device
	    bpf</literal> sort a rendszermagunk
	    beállításait tartalmazó
	    állományba, majd fordítsuk újra
	    a rendszermagot.  A rendszermag
	    lefordításáról a <xref
	    linkend="kernelconfig"/>ben olvashatunk.</para>

	  <para>A <devicename>bpf</devicename> eszköz a &os;-hez
	    alapból adott <filename>GENERIC</filename>
	    rendszermag része, ezért a DHCP
	    használatához nem kell feltétlenül
	    újat fordítanunk.</para>

	    <note>
	      <para>A biztonsági szempontok miatt
		aggódó felhasználók
		részére megjegyezzük, hogy a
		<devicename>bpf</devicename> eszköz egyben a
		csomagok lehallgatását is
		lehetõvé teszi (habár az ilyen
		témájú programok
		futtatásához megfelelõ jogokra is
		szükség van).  A
		<devicename>bpf</devicename> használata
		<emphasis>kötelezõ</emphasis> a DHCP
		mûködtetéséhez, de ha nagyon
		kényesek vagyunk a biztonságot
		illetõen, akkor minden olyan esetben, amikor nem
		használjuk ki ezt a lehetõséget,
		távolítsuk el a
		rendszermagból.</para>
	    </note>

	  <para>A következõ lépésben át
	    kell szerkesztenünk a mintaként mellékelt
	    <filename>dhcpd.conf</filename> állományt,
	    amelyet a <filename
	      role="package">net/isc-dhcp31-server</filename> port rakott
	    fel.  Ez alapértelmezés szerint a
	    <filename>/usr/local/etc/dhcpd.conf.sample</filename>
	    néven található meg, és
	    mielõtt bármit is változtatnánk
	    rajta, másoljuk le
	    <filename>/usr/local/etc/dhcpd.conf</filename>
	    néven.</para>

	</sect3>

	<sect3>
	  <title>A DHCP szerver beállítása</title>

	  <indexterm>
	    <primary>DHCP</primary>
	    <secondary>dhcpd.conf</secondary>
	  </indexterm>

	  <para>A <filename>dhcpd.conf</filename> az
	    alhálózatokat illetve a gépeket
	    érintõ deklarációkat tartalmazza,
	    és talán a legkönnyebben a
	    következõ példa alapján
	    mutatható be:</para>

	  <programlisting>option domain-name "minta.com";<co id="domain-name"/>
option domain-name-servers 192.168.4.100;<co id="domain-name-servers"/>
option subnet-mask 255.255.255.0;<co id="subnet-mask"/>

default-lease-time 3600;<co id="default-lease-time"/>
max-lease-time 86400;<co id="max-lease-time"/>
ddns-update-style none;<co id="ddns-update-style"/>

subnet 192.168.4.0 netmask 255.255.255.0 {
  range 192.168.4.129 192.168.4.254;<co id="range"/>
  option routers 192.168.4.1;<co id="routers"/>
}

host mailhost {
  hardware ethernet 02:03:04:05:06:07;<co id="hardware"/>
  fixed-address levelezes.minta.com;<co id="fixed-address"/>
}</programlisting>

	  <calloutlist>
	    <callout arearefs="domain-name">
	      <para>Ez a beállítás adja meg a
		kliensek számára az alapértelmezett
		keresési tartományt (search domain).  A
		&man.resolv.conf.5; tud ezzel kapcsolatban
		részletesebb információkat
		adni.</para>
	    </callout>

	    <callout arearefs="domain-name-servers">
	      <para>Ez a beállítás adja meg a
		kliensek által használt
		névfeloldó szerverek vesszõvel
		elválasztott felsorolását.</para>
	    </callout>

	    <callout arearefs="subnet-mask">
	      <para>A kliensekhez tartozó hálózati
		maszk.</para>
	    </callout>

	    <callout arearefs="default-lease-time">
	      <para>A kliens egy adott idõre kérhet
		bérleti jogot, egyébként a szerver
		dönt a bérlet lejárati
		idejérõl (másodpercekben).</para>
	    </callout>

	    <callout arearefs="max-lease-time">
	      <para>Ez az a maximális idõ, amennyire a
		szerver hajlandó bérbe adni
		IP-címet.  A kliens ugyan hosszabb idõre is
		kérheti és meg is kapja, de legfeljebb
		csak <literal>max-lease-time</literal>
		másodpercig lesz érvényes.</para>
	    </callout>

	    <callout arearefs="ddns-update-style">
	      <para>Ez a beállítás határozza
		meg, hogy a DHCP szervernek frissítse-e a
		névoldási információkat a
		bérlések
		elfogadásánál vagy
		visszamondásánál.  Az ISC
		implementációjánál ez a
		beállítás
		<emphasis>kötelezõ</emphasis>.</para>
	    </callout>

	    <callout arearefs="range">
	      <para>Ezzel adjuk meg milyen tartományból
		tudunk IP-címeket kiosztani a kliensek
		számára.  A kezdõ címet is
		beleértve, innen fogunk kiutalni egyet a
		klienseknek.</para>
	    </callout>

	    <callout arearefs="routers">
	      <para>A kliensek felé elküldött
		alapértelmezett átjáró
		címe.</para>
	    </callout>

	    <callout arearefs="hardware">
	      <para>A gép hardveres MAC-címe (így a
		DHCP szerver képes felismerni a
		kérés küldõjét).</para>
	    </callout>

	    <callout arearefs="fixed-address">
	      <para>Ennek megadásával a gépek
		mindig ugyanazt az IP-címet kapják.  Itt
		már megadhatunk egy hálózati nevet,
		mivel a bérlethez tartozó
		információk visszaküldése
		elõtt maga a DHCP szerver fogja feloldani a
		gép nevét.</para>
	    </callout>
	  </calloutlist>

	  <para>Miután befejeztük a
	    <filename>dhcpd.conf</filename>
	    módosítását, a DHCP szerver az
	    <filename>/etc/rc.conf</filename> állományban
	    tudjuk engedélyezni, vagyis tegyük bele a
	    következõt:</para>

	  <programlisting>dhcpd_enable="YES"
dhcpd_ifaces="dc0"</programlisting>

	  <para>A <literal>dc0</literal> felület nevét
	    helyettesítsük annak a felületnek (vagy
	    whitespace karakterekkel elválasztott
	    felületeknek) a nevével, amelyen keresztül
	    a DHCP szerver várni fogja a kliensek
	    kéréseit.</para>

	  <para>Ezután a következõ parancs
	    kiadásával indítsuk el a
	    szervert:</para>

	  <screen>&prompt.root; <userinput>/usr/local/etc/rc.d/isc-dhcpd start</userinput></screen>

	  <para>Amikor a jövõben valamit változtatunk a
	    konfigurációs állományon, akkor
	    ezzel kapcsolatban fontos megemlíteni, hogy ha csak
	    egy <literal>SIGHUP</literal> jelzést
	    küldünk a <application>dhcpd</application>
	    démonnak, akkor az a többi
	    démontól eltérõen
	    önmagában még <emphasis>nem</emphasis>
	    eredményezi a konfigurációs adatok
	    újraolvasását.  Helyette a
	    <literal>SIGTERM</literal> jelzéssel kell
	    leállítani a programot, majd
	    újraindítani a fenti paranccsal.</para>

	</sect3>

	<sect3>
	  <title>Állományok</title>

	  <indexterm>
	    <primary>DHCP</primary>
	    <secondary>konfigurációs
	      állományok</secondary>
	  </indexterm>

	  <itemizedlist>
	    <listitem>
	      <para><filename>/usr/local/sbin/dhcpd</filename></para>

	      <para>A <application>dhcpd</application> statikusan
		linkelt és a <filename>/usr/local/sbin</filename>
		könyvtárban található.  A
		porttal együtt felkerülõ &man.dhcpd.8;
		man oldal ad részletesebb
		útmutatást
		<application>dhcpd</application>
		használatáról.</para>
	    </listitem>

	    <listitem>
	      <para><filename>/usr/local/etc/dhcpd.conf</filename></para>

	      <para>Mielõtt a <application>dhcpd</application>
		megkezdhetné mûködését,
		egy konfigurációs állományra
		is szükségünk lesz, amely a
		<filename>/usr/local/etc/dhcpd.conf</filename>.  Ez az
		állomány tartalmazza az összes olyan
		információt, ami kell a kliensek
		megfelelõ kiszolgálásához
		valamint a szerver mûködéséhez.
		Ez a konfigurációs állomány
		porthoz tartozó &man.dhcpd.conf.5; man oldalon
		kerül ismertetésre.</para>
	    </listitem>

	    <listitem>
	      <para><filename>/var/db/dhcpd.leases</filename></para>

	      <para>A DHCP szerver ebben az állományba
		tartja nyilván a kiadott bérleteket, egy
		napló formájában.  A porthoz
		kapcsolódó &man.dhcpd.leases.5; man
		oldalon errõl többet is megtudhatunk.</para>
	    </listitem>

	    <listitem>
	      <para><filename>/usr/local/sbin/dhcrelay</filename></para>

	      <para>A <application>dhcrelay</application>
		állománynak olyan komolyabb
		környezetekben van szerepe, ahol a DHCP szerver a
		kliensektõl érkezõ
		kéréseket egy másik
		hálózaton található DHCP
		szerverhez továbbítja.  Ha
		szükség lenne erre a
		lehetõségre, akkor telepítsük
		fel a <filename
		  role="package">net/isc-dhcp31-relay</filename> portot.  A
		porthoz tartozó &man.dhcrelay.8; man oldal ennek
		részleteit taglalja.</para>
	    </listitem>
	  </itemizedlist>

	</sect3>
      </sect2>
  </sect1>

  <sect1 id="network-dns">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Chern</firstname>
	  <surname>Lee</surname>
	  <contrib>Készítette: </contrib>
	</author>

	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	</author>

	<author>
	  <firstname>Daniel</firstname>
	  <surname>Gerzo</surname>
	</author>
      </authorgroup>
    </sect1info>

    <title>Névfeloldás (<acronym>DNS</acronym>)</title>

    <sect2>
      <title>Áttekintés</title>

      <indexterm><primary>BIND</primary></indexterm>

      <para>A &os; alapértelmezés szerint a BIND (Berkeley
	Internet Name Domain) egyik verzióját tartalmazza,
	amely a névfeloldási (Domain Name System,
	<acronym>DNS</acronym>) protokoll egyik elterjedt
	implementációja.  A <acronym>DNS</acronym>
	protokollon keresztül tudunk az
	<acronym>IP</acronym>-címekhez neveket rendelni és
	fordítva.  Például a <hostid
	role="fqdn">www.FreeBSD.org</hostid> névre a &os; Projekt
	webszerverének <acronym>IP</acronym>-címét
	kapjuk meg, miközben a <hostid
	role="fqdn">ftp.FreeBSD.org</hostid> pedig a
	hozzá tartozó <acronym>FTP</acronym> szerver
	<acronym>IP</acronym>-címét fogja visszaadni.
	Ehhez hasonlóan a fordítottja is
	megtörténhet, vagyis egy
	<acronym>IP</acronym>-címhez is kérhetjük a
	hálózati név feloldását.  A
	névfeloldási kérések
	kiszolgálásához nem feltétlenül
	szükséges névszervert futtatni a
	rendszerünkön.</para>

      <para>A &os; jelen pillanatban alapból a
	<acronym>BIND</acronym>9 névszervert tartalmazza.  A
	benne szereplõ változata több biztonsági
	javítást, új
	állományrendszeri kiosztást és
	automatizált &man.chroot.8;
	beállítást is magában foglal.</para>

      <indexterm><primary>névfeloldás</primary></indexterm>

      <para>Az interneten keresztüli névfeloldást
	legfelsõ szintû tartományoknak (Top Level
	Domain, <acronym>TLD</acronym>) nevezett hitelesített
	tövek némileg bonyolult rendszerén alapszik,
	valamint más egyéb olyan névszervereken,
	amelyek további egyéni információkat
	tárolnak és táraznak.</para>

      <para>A BIND fejlesztését jelenleg az Internet
	Systems Consortium (<ulink url="http://www.isc.org/"></ulink>)
	felügyeli.</para>

    </sect2>

    <sect2>
      <title>Alapfogalmak</title>

      <para>A leírás megértéséhez be
	kell mutatnunk néhány névfeloldással
	kapcsolatos fogalmat.</para>

      <indexterm><primary>névfeloldó</primary></indexterm>
      <indexterm><primary>inverz DNS</primary></indexterm>
      <indexterm><primary>gyökérzóna</primary></indexterm>

      <informaltable frame="none" pgwide="1">
	<tgroup cols="2">
	  <colspec colwidth="1*"/>
	  <colspec colwidth="3*"/>

	  <thead>
	    <row>
	      <entry>Fogalom</entry>
	      <entry>Meghatározás</entry>
	    </row>
	  </thead>

	  <tbody>
	    <row>
	      <entry>Közvetlen névfeloldás (forward
		<acronym>DNS</acronym>)</entry>
	      <entry>A hálózati nevek
		leképezése IP-címekre.</entry>
	    </row>

	    <row>
	      <entry>õs (origin)</entry>
	      <entry>Egy adott zóna állományban
		szereplõ tartományra vonatkozik.</entry>
	    </row>

	    <row>
	      <entry><application>named</application>, BIND</entry>
	      <entry>A &os;-n belüli BIND névszerver
		különbözõ
		megnevezései.</entry>
	    </row>

	    <row>
	      <entry>Névfeloldó (resolver)</entry>
	      <entry>Az a program a rendszerben, amelyhez a
		hálózaton levõ gépek a
		zónák adatainak
		elérésével kapcsolatban
		fordulnak.</entry>
	    </row>

	    <row>
	      <entry>Inverz névfeloldás (reverse
		<acronym>DNS</acronym>)</entry>
	      <entry>Az <acronym>IP</acronym>-címek
		leképzése hálózati
		nevekre.</entry>
	    </row>

	    <row>
	      <entry>Gyökérzóna (root zone)</entry>
	      <entry>Az interneten található
		zónák hierarchiájának
		töve.  Minden zóna ebbe a
		gyökérzónába esik, ahhoz
		hasonlóan, ahogy egy
		állományrendszerben az
		állományok a
		gyökérkönyvtárba.</entry>
	    </row>

	    <row>
	      <entry>Zóna (zone)</entry>
	      <entry>Egy különálló
		tartomány, altartomány vagy a
		névfeloldás azon része, amelyet
		egyazon fennhatóság alatt tartanak
		karban.</entry>
	    </row>
	  </tbody>
	</tgroup>
      </informaltable>

      <indexterm>
	<primary>zónák</primary>
	<secondary>példák</secondary>
      </indexterm>

      <para>Példák zónákra:</para>

      <itemizedlist>
	<listitem>
	  <para>A gyökérzónára a
	    leírásokban általában
	    <hostid>.</hostid> néven szoktak hivatkozni.</para>
	</listitem>

	<listitem>
	  <para>A <hostid>org.</hostid> egy legfelsõ szintû
	    tartomány (<acronym>TLD</acronym>) a
	    gyökérzónán belül.</para>
	</listitem>

	<listitem>
	  <para>A <hostid role="domainname">minta.org.</hostid> a
	    <hostid>org.</hostid> <acronym>TLD</acronym>
	    tartomány alatti zóna.</para>
	</listitem>

	<listitem>
	  <para>A <hostid>1.168.192.in-addr.arpa</hostid> egy olyan
	    zóna, amelyek a <hostid
	    role="ipaddr">192.168.1.*</hostid>
	    <acronym>IP</acronym>-címtartományban
	    szereplõ összes címet jelöli.</para>
	</listitem>
      </itemizedlist>

      <para>Mint láthatjuk, a hálózati nevek
	balról kiegészülve pontosodnak.  Tehát
	például a <hostid
	role="domainname">minta.org.</hostid> sokkal pontosabb
	meghatározás, mint a <hostid>org.</hostid>, ahogy
	az <hostid>org.</hostid> magánál a
	gyökérzónánál jelent
	többet.  A hálózati nevek felosztása
	leginkább egy állományrendszerhez
	hasonlítható, például a <filename
	  class="directory">/dev</filename> könyvtár a
	gyökéren belül található,
	és így tovább.</para>

    </sect2>

    <sect2>
      <title>Miért érdemes névszervert
	futtatni</title>

      <para>A névszerverek általában két
	alakban jelennek meg.  Egyikük a hitelesített
	névszerver, a másikuk a
	gyorsítótárazó
	névszerver.</para>

      <para>Egy hitelesített névszerverre akkor van
	szükségünk, ha:</para>

      <itemizedlist>
	<listitem>
	  <para>a világ többi része felé
	    akarunk hiteles névfeloldási
	    információkat szolgáltatni;</para>
	</listitem>

	<listitem>
	  <para>regisztráltunk egy tartományt
	    (például <hostid
	    role="domainname">minta.org</hostid>) és az alatta
	    levõ hálózati nevekhez is
	    szeretnénk <acronym>IP</acronym>-címeket
	    rendeltetni;</para>
	</listitem>

	<listitem>
	  <para>a <acronym>IP</acronym>-címtartományunkban
	    szükség van inverz névfeloldási
	    bejegyzésekre (amely
	    <acronym>IP</acronym>-címbõl ad meg
	    hálózati nevet) is;</para>
	</listitem>

	<listitem>
	  <para>a kérések
	    teljesítéséhez egy tartalék
	    avagy második, alárendelt (slave)
	    névszerver kell.</para>
	</listitem>
      </itemizedlist>

      <para>A gyorsítótárazó
	névszerverre akkor van szükségünk,
	ha:</para>

      <itemizedlist>
	<listitem>
	  <para>egy helyi névfeloldó szerver
	    felhasználásával fel akarjuk
	    gyorsítani az egyébként a
	    külsõ névszerver felé
	    irányuló kérések
	    kiszolgálását.</para>
	</listitem>
      </itemizedlist>

      <para>Amikor valaki lekérdezi a <hostid
	role="fqdn">www.FreeBSD.org</hostid> címét, akkor
	a névfeloldó elõször
	általában a kapcsolatot rendelkezésre
	bocsátó internet-szolgáltató
	névszerverét kérdezi meg és onnan
	kapja meg a választ.  Egy helyi,
	gyorsítótárazó névszerver
	használata esetén azonban egy ilyen
	kérést csak egyszer kell kiadni a külsõ
	névszervernek.  Ezután már minden
	további ilyen kérés el sem hagyja a
	belsõ hálózatunkat, mivel a válasz
	szerepel a gyorsítótárban.</para>
    </sect2>

    <sect2>
      <title>Ahogyan mûködik</title>

      <para>&os; alatt a BIND démon nyilvánvaló
	okokból <application>named</application> néven
	érhetõ el.</para>

      <informaltable frame="none" pgwide="1">
	<tgroup cols="2">
	  <thead>
	    <row>
	      <entry>Állomány</entry>
	      <entry>Leírás</entry>
	    </row>
	  </thead>

	  <tbody>
	    <row>
	      <entry>&man.named.8;</entry>
	      <entry>A BIND démon.</entry>
	    </row>

	    <row>
	      <entry>&man.rndc.8;</entry>
	      <entry>A névszervert vezérlõ
		segédprogram.</entry>
	    </row>

	    <row>
	      <entry><filename class="directory">/etc/namedb</filename></entry>
	      <entry>A BIND által kezelt zónák
		adatait tároló
		könyvtár.</entry>
	    </row>

	    <row>
	      <entry><filename>/etc/namedb/named.conf</filename></entry>
	      <entry>A démon konfigurációs
		állománya.</entry>
	    </row>
	  </tbody>
	</tgroup>
      </informaltable>

      <para>Attól függõen, hogy miként
	állítjuk be az adott zónát a
	szerveren, a hozzá tartozó állományok
	a <filename class="directory">/etc/namedb</filename>
	könyvtáron belül a <filename
	  class="directory">master</filename>, <filename
	  class="directory">slave</filename> vagy <filename
	  class="directory">dynamic</filename> alkönyvtárban
	foglalnak helyet.  Az itt tárolt
	állományokban levõ névfeloldási
	információk alapján válaszol a
	névszerver a felé intézett
	kérésekre.</para>

    </sect2>

    <sect2>
      <title>A BIND elindítása</title>

      <indexterm>
	<primary>BIND</primary>
	<secondary>elindítás</secondary>
      </indexterm>

      <para>Mivel a BIND alapból elérhetõ a
	rendszerben, viszonylag könnyen be tudjuk
	állítani.</para>

      <para>A <application>named</application> alapértelmezett
	beállítása szerint egy &man.chroot.8;
	környezetben futó egyszerû
	névfeloldást végzõ szerver, amely a
	helyi IPv4 interfészen (127.0.0.1) fogadja a
	kéréseket.  Ezzel a
	beállítással a következõ
	parancson keresztül tudjuk elindítani:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/named onestart</userinput></screen>

      <para>Ha engedélyezni akarjuk a
	<application>named</application> démont minden egyes
	rendszerindításkor, tegyük a
	következõ sort az <filename>/etc/rc.conf</filename>
	állományba:</para>

      <programlisting>named_enable="YES"</programlisting>

      <para>Értelemszerûen az
	<filename>/etc/namedb/named.conf</filename> tele van olyan
	beállítási lehetõségekkel,
	amelyek meghaladják ennek a leírásnak a
	kereteit.  Ha viszont kíváncsiak vagyunk a
	&os;-ben a <application>named</application>
	indításához használt
	beállításokra, akkor az
	<filename>/etc/defaults/rc.conf</filename>
	állományban nézzük meg
	<literal>named_<replaceable>*</replaceable></literal>
	változókat és olvassuk át az
	&man.rc.conf.5; man oldalt.  Emellett még a <xref
	linkend="configtuning-rcd"/>t is hasznos lehet elolvasni.</para>
    </sect2>

    <sect2>
      <title>A konfigurációs
	állományok</title>

      <indexterm>
	<primary>BIND</primary>
	<secondary>konfigurációs
	  állományok</secondary>
      </indexterm>

      <para>A <application>named</application>
	beállításait tartalmazó
	állományok pillanatnyilag az <filename
	  class="directory">/etc/namedb</filename> könyvtárban
	találhatóak és hacsak nem egy egyszerû
	névfeloldóra tartunk igényt, akkor a
	használata elõtt módosítanunk is kell.
	Itt ejtjük meg a beállítások nagy
	részét.</para>

      <sect3>
	<title><filename>/etc/namedb/named.conf</filename></title>

	<programlisting>// &dollar;FreeBSD&dollar;
//
// Részletesebb leírást a named.conf(5) és named(8) man oldalakon, valamint
// a /usr/share/doc/bind9 könyvtárban találhatunk.
//
// Ha egy hitelesített szervert akarunk beállítani, akkor igyekezzünk
// a névfeloldás összes finom részletével pontosan tisztában lenni.
// Ugyanis még a legkisebb hibákkal is egyrészt elvághatunk gépeket az
// internet-lérésétõl, vagy másrészt felesleges forgalmat tudunk
// generálni
//

options {
	// A chroot könyvtárhoz relatív elérési út, amennyiben létezik
	directory	"/etc/namedb";
	pid-file	"/var/run/named/pid";
	dump-file	"/var/dump/named_dump.db";
	statistics-file	"/var/stats/named.stats";

// Ha a named démont csak helyi névfeloldóként használjuk, akkor ez
// egy biztonságos alapbeállítás. Ha viszont a named démon az egész
// hálózatunkat is kiszolgálja, akkor ezt a beállítást tegyük
// megjegyzésbe, vagy adjunk meg egy rendes IP-címet, esetleg
// töröljük ki.
	listen-on	{ 127.0.0.1; };

// Ha rendszerünkön engedélyezett az IPv6 használata, akkor a helyi
// névfeloldó használatához ezt a sort vegyük ki a megjegyzésbõl.
// A hálózatunk többi részérõl pedig úgy lehet elérni, ha itt megadunk
// egy IPv6 címet, vagy az "any" kulcsszót.
//	listen-on-v6	{ ::1; };

// Az alábbi zónákat már a lentebb található üres zónák eleve lefedik.
// Ha tehát a lenti üres zónákat kivesszük a konfigurációból, akkor
// ezeket a sorokat is tegyük megjegyzésbe.
	disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
	disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";
	disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA";

// Ha a szolgáltatónk névszervert is elérhetõvé tett számunkra, akkor
// itt adjuk meg annak az IP-címét és engedélyezzük az alábbi sort.
// Ezzel egyben kihasználjuk a gyorsítótárat is, így mérsékeljük az
// internet felé mozgó névfeloldásokat.
/*
	forwarders {
		127.0.0.1;
	};
*

// Ha a 'forwarders' rész nem üres, akkor alapértelmezés szerint a
// 'forward first' értékkel rendelkezik.  Ekkor a kérést a helyi szerver
// kapja abban az esetben, amikor a 'forwarders' részben megadott
// szerverek nem tudják megválaszolni.  Emellett a névszerverben a
// következõ sor hozzáadásával letilthatjuk, hogy önmagától ne
// kezdeményezzen kéréseket:
//     forward only;

// Ha a kérések továbbítását az /etc/resolv.conf állományban megadott
// bejegyzések mentén szeretnénk automatikusan konfigurálni, akkor vegyük
// ki a megjegyzésbõl az alábbi sort és adjuk hozzá az /etc/rc.conf
// állományhoz a name_auto_forward=yes sort.  Emellett használható még a
// named_auto_forward_only beállítás is (amely fentebb leírt funkciót
// valósítja meg).
//     include "/etc/namedb/auto_forward.conf";</programlisting>

	<para>Ahogy arról a megjegyzésekben is szó
	  esik, úgy tudjuk aktiválni a
	  gyorsítótárat, ha megadjuk a
	  <literal>forwarders</literal> beállítást.
	  Normális körülmények között
	  a névszerver az interneten az egyes
	  névszervereket rekurzívan fogja keresni
	  egészen addig, amíg meg nem találja a
	  keresett választ.  Az iménti
	  beállítás
	  engedélyezésével azonban
	  elõször a szolgáltató
	  névszerverét (vagy az általa
	  kijelölt névszervert) fogjuk megkérdezni, a
	  saját
	  gyorsítótárából.  Ha a
	  szolgáltató kérdéses
	  névszervere egy gyakran használt, gyors
	  névszerver, akkor ezt érdemes
	  bekapcsolnunk.</para>

	<warning>
	  <para>Itt a <hostid role="ipaddr">127.0.0.1</hostid>
	    megadása <emphasis>nem</emphasis> mûködik.
	    Mindenképpen írjuk át a
	    szolgáltatónk névszerverének
	    <acronym>IP</acronym>-címére.</para>
	</warning>

	<programlisting>	/*
	   A BIND legújabb változataiban alapértelmezés szerint minden egyes
	   kimenõ kérésnél más, véletlenszerûen választott UDP portot
	   használnak, ezáltal jelentõs mértékben csökkenthetõ a gyorsítótár
	   meghamisíthatóságának (cache poisoning) esélye.  Javasoljuk
	   mindenkinek, hogy használják ki ezt a lehetõséget és eszerint
	   állítsák be a tûzfalakat.

	   Ha nem sikerül a tûzfalat hozzáigazítani ehhez a
	   viselkedéshez AKKOR ÉS CSAK IS AKKOR engedélyezzük a lenti
	   beállítást.  Alkalmazásával sokkal kevésbé lesz ellenálló a
	   névszerver a különbözõ hamisítási kísérletekkel szemben,
	   ezért lehetõség szerint kerüljük el.

	   Az NNNNN helyére egy 49160 és 65530 közti számot kell
	   beírnunk.
	 */
	 // query-source address * port NNNNN;
};

// Ha engedélyezzük a helyi névszervert, akkor az /etc/resolv.conf
// állományban elsõ helyen megadni a 127.0.0.1 címet. Sõt, az
// /etc/rc.conf állományból se felejtsük ki.

// A hagyományos "root-hints" megoldás.  Használjuk ezt VAGY a lentebb
// megadott alárendelt zónákat.
zone "." { type hint; file "named.root"; };

/*	Több szempontból is elõnyös, ha a következõ zónákat alárendeljük a
	gyökér névfeloldó szervereknek:
	1. A helyi felhasználók kéréseit gyorsabban tudjuk feloldalni.
	2. A gyökérszerverek felé nem megy semmilyen hamis forgalom.
	3. A gyökérszerverek meghibásodása vagy elosztott DoS támadás
	   esetén rugalmasabban tudunk reagálni.

	Másfelöl azonban ez a módszer a "hints" állomány alkalmazásával
	szemben több felügyeletet igényel, mivel figyelnünk kell, nehogy
	egy váratlan meghibásodás mûködésképtelenné tegye a
	szerverünket.  Ez a megoldás leginkább a sok klienst kiszolgáló
	névszerverek esetén bizonyulhat jövedelmezõbbnek.  Óvatosan
	bánjunk vele!

	A módszer alkalmazásához vegyük ki a megjegyzésbõl a következõ
	bejegyzéseket és tegyük megjegyzésbe a fenti hint zónát.
*/

zone "." {
	type slave;
	file "slave/root.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
};

zone "arpa" {
	type slave;
	file "slave/arpa.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
}

zone "in-addr.arpa" {
	type slave;
	file "slave/in-addr.arpa.slave";
	masters {
		192.5.5.241;	// F.ROOT-SERVERS.NET.
	};
	notify no;
};
*/

/*	Az alábbi zónák helyi kiszolgálásával meg tudjuk akadályozni, hogy
	a belõlük indított kérések elhagyják a hálózatunkat és a elérjük
	a gyökér névfeloldó szervereket.  Ez a megközelítés két komoly
	elõnnyel rendelkezik:
	1. A helyi felhasználók kéréseit gyorsabban tudjuk
	   megválaszolni.
	2. A gyökérszerverek felé nem továbbítódik semmilyen hamis
	   forgalom.
*/
// RFC 1912
zone "localhost"	{ type master; file "master/localhost-forward.db"; };
zone "127.in-addr.arpa"	{ type master; file "master/localhost-reverse.db"; };
zone "255.in-addr.arpa"	{ type master; file "master/empty.db"; };

// A helyi IPv6 címek részére létrehozott RFC 1912-szerû zóna
zone "0.ip6.arpa"	{ type master; file "master/localhost-reverse.db"; };

// "Ez" a hálózat (RFC 1912 és 3330)
zone "0.in-addr.arpa"		{ type master; file "master/empty.db"; };

// Magáncélú hálózatok (RFC 1918)
zone "10.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "16.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "17.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "18.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "19.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "20.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "21.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "22.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "23.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "24.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "25.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "26.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "27.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "28.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "29.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "30.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "31.172.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "168.192.in-addr.arpa"	{ type master; file "master/empty.db"; };

// Helyi link/APIPA (RFC 3330 és 3927)
zone "254.169.in-addr.arpa"	{ type master; file "master/empty.db"; };

// Dokumentációs próbahálózat (RFC 3330)
zone "2.0.192.in-addr.arpa"	{ type master; file "master/empty.db"; };

// Útválasztási teljesítmény tesztelésére (RFC 3330)
zone "18.198.in-addr.arpa"	{ type master; file "master/empty.db"; };
zone "19.198.in-addr.arpa"	{ type master; file "master/empty.db"; };

// Az IANA részére fentartott - a régi E osztályú címtér
zone "240.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "241.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "242.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "243.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "244.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "245.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "246.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "247.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "248.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "249.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "250.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "251.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "252.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "253.in-addr.arpa"		{ type master; file "master/empty.db"; };
zone "254.in-addr.arpa"		{ type master; file "master/empty.db"; };

// Hozzárendelés nélküli IPv6-címek (RFC 4291)
zone "1.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "3.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "4.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "5.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "6.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "7.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "8.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "9.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "a.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "b.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "c.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "d.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "e.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "0.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "1.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "2.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "3.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "4.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "5.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "6.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "7.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "8.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "9.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "a.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "b.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "0.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "1.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "2.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "3.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "4.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "5.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "6.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "7.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };

// IPv6 ULA (RFC 4193)
zone "c.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "d.f.ip6.arpa"		{ type master; file "master/empty.db"; };

// IPv6 helyi link (RFC 4291)
zone "8.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "9.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "a.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "b.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };

// Elavult IPv6 helyi címek (RFC 3879)
zone "c.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "d.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "e.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };
zone "f.e.f.ip6.arpa"		{ type master; file "master/empty.db"; };

// Az IP6.INT már elavult (RFC 4159)
zone "ip6.int"			{ type master; file "master/empty.db"; };

// FONTOS: Ne használjuk ezeket az IP-címeket, mert nem valódiak,
// csupán illusztrációs és dokumentációs célokból adtuk meg!
//
// Az alárendelt zónák beállításaira vonatkozó bejegyzések. Érdemes
// ilyet beállítani legalább ahhoz a zónához, amelyhez a tartományunk is
// tartozik. Az elsõdleges névszerverhez tartozó IP-címet érdeklõdjük meg
// az illetékes hálózati rendszergazdától.
//
// Soha ne felejtsünk el megadni zónát az inverz kereséshez!  A neve az IP-cím
// tagjainak fordított sorrendjébõl // származik, amelyhez hozzátoldunk még egy
// ".IN-ADDR.ARPA" (illetve IPv6 esetén ".IP6.ARPA") részt.
//
// Mielõtt nekilátnánk egy elsõdleges zóna beállításának, gondoljuk
// végig, hogy tényleg a megfelelõ szinten ismerjük a névfeloldás és
// a BIND mûködését. Gyakran ugyanis egyáltalán nem nyilvánvaló
// csapdákba tudunk esni.  Egy alárendelt zóna beállítása általában sokkal egyszerûbb feladat.
//
// FONTOS: Ne kövessük vakon a most következõ példát :-) Helyette inkább
// valódi neveket és címeket adjunk meg.

/* Példa dinamikus zónára
key "mintaorgkulcs" {
	algorithm hmac-md5;
	secret "sf87HJqjkqh8ac87a02lla==";
};
zone "minta.org" {
	type master;
	allow-update {
		key "mintaorgkulcs";
	};
	file "dynamic/minta.org";
};
*/

/* Példa inverz alárendelt zónákra
zone "1.168.192.in-addr.arpa" {
	type slave;
	file "slave/1.168.192.in-addr.arpa";
	masters {
		192.168.1.1;
	};
};
*/</programlisting>

	<para>A <filename>named.conf</filename>
	  állományban tehát így adhatunk meg
	  közvetlen és inverz alárendelt
	  zónákat.</para>

	<para>Minden egyes újabb kiszolgált
	  zónához az egy új bejegyzést kell
	  felvenni a <filename>named.conf</filename>
	  állományban.</para>

	<para>Például a <hostid
	  role="domainname">minta.org</hostid> címhez
	  tartozó legegyszerûbb ilyen bejegyzés
	  így néz ki:</para>

	<programlisting>zone "minta.org" {
	type master;
	file "master/minta.org";
};</programlisting>

	<para>Ez egy központi zóna, ahogy arról a
	  <option>type</option> mezõ, vagyis a típusa is
	  árulkodik.  Továbbá a
	  <option>file</option> mezõben láthatjuk, hogy a
	  hozzá tartozó információkat az
	  <filename>/etc/namedb/master/minta.org</filename>
	  állományban tárolja.</para>

	<programlisting>zone "minta.org" {
	type slave;
	file "slave/minta.org";
};</programlisting>

	<para>Az alárendelt esetben a zónához
	  tartozó információkat a zóna
	  központi szerverétõl kapjuk meg és
	  megadott állományban mentjük el.  Ha
	  valamiért a központi szerver leáll vagy nem
	  érhetõ el, akkor az alárendelt szerver az
	  átküldött zóna
	  információk alapján képes helyette
	  kiszolgálni a kéréseket.</para>
      </sect3>

      <sect3>
	<title>A zóna állományok</title>

	<indexterm>
	  <primary>BIND</primary>
	  <secondary>zóna állományok</secondary>
	</indexterm>

	<para>A <hostid role="domainname">minta.org</hostid>
	  címhez tartozó példa központi
	  zóna állomány (amely az
	  <filename>/etc/namedb/master/néven.org</filename>
	  érhetõ el) tartalma az alábbi:</para>

	<programlisting>&dollar;TTL 3600        ; alapértelmezés szerint 1 óra
minta.org.      IN      SOA      ns1.minta.org. admin.minta.org. (
                                2006051501      ; sorozatszám
                                10800           ; frissítés
                                3600            ; ismétlés
                                604800          ; lejárat
                                300             ; TTL negatív válasz
                        )

; névszerverek
                IN      NS      ns1.minta.org.
                IN      NS      ns2.minta.org.

; MX rekordok
                IN      MX 10   mx.minta.org.
                IN      MX 20   levelezes.minta.org.

                IN      A       192.168.1.1

; a gépek nevei
localhost       IN      A       127.0.0.1
ns1             IN      A       192.168.1.2
ns2             IN      A       192.168.1.3
mx              IN      A       192.168.1.4
levelezes       IN      A       192.168.1.5

; álnevek
www             IN      CNAME   minta.org.</programlisting>

	<para>A <quote>.</quote>-ra végzõdõ
	  hálózati nevek abszolút nevek, míg
	  minden más <quote>.</quote> nélküli
	  név az õsére vezehetõ vissza
	  (tehát relatív).  Például az
	  <literal>ns1</literal> névbõl az
	  <literal>ns1.<replaceable>minta.org</replaceable></literal>
	  keletkezik.</para>

	<para>A zóna állományok
	  felépítése a következõ:</para>

	<programlisting>rekordnév      IN rekordtípus   érték</programlisting>

	<indexterm>
	  <primary>névfeloldás</primary>
	  <secondary>rekordok</secondary>
	</indexterm>

	<para>A névfeloldásban leggyakrabban alkalmazott
	  rekordok típusai:</para>

	<variablelist>
	  <varlistentry>
	    <term>SOA</term>

	    <listitem>
	      <para>a zóna fennhatóságának
		kezdete</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term>NS</term>

	    <listitem>
	      <para>egy hitelesített névszerver</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term>A</term>

	    <listitem>
	      <para>egy gép címe</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term>CNAME</term>

	    <listitem>
	      <para>egy álnév kanonikus neve</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term>MX</term>

	    <listitem>
	      <para>levélváltó</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term>PTR</term>

	    <listitem>
	      <para>mutató a tartománynévre (az
		inverz feloldás használja)</para>
	    </listitem>
	  </varlistentry>
	</variablelist>

	<programlisting>
minta.org. IN SOA ns1.minta.org. admin.minta.org. (
                        2006051501      ; sorozatszám
                        10800           ; 3 óránként frissítsünk
                        3600            ; 1 óra után próbálkozzunk újra
                        604800          ; 1 hét után jár le
                        300 )           ; TTL negatív válasz</programlisting>

	<variablelist>
	  <varlistentry>
	    <term><hostid role="domainname">minta.org.</hostid></term>

	    <listitem>
	      <para>a tartomány neve, amely egyben a zóna
		õse</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><hostid role="fqdn">ns1.minta.org.</hostid></term>

	    <listitem>
	      <para>a zóna elsõdleges/hitelesített
		névszervere</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><literal>admin.minta.org.</literal></term>

	    <listitem>
	      <para>a zónáért felelõs
		személy neve, akinek az e-mail
		címét a <quote>@</quote>
		behelyettesítésével kapjuk meg.
		(Tehát a <email>admin@example.org</email>
		címbõl <literal>admin.example.org</literal>
		lesz.)</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><literal>2006051501</literal></term>

	    <listitem>
	      <para>az állomány sorozatszáma.  Ezt
		a zóna állomány
		módosításakor mindig
		növelnünk kell.  Manapság a
		rendszergazdák a sorozatszámot
		<literal>ééééhhnnvv</literal>
		alakban adják meg.  A
		<literal>2006051501</literal> tehát azt jelenti,
		hogy az állományt 2006.  május
		15-én módosították
		utoljára, és a <literal>01</literal> pedig
		arra utal, hogy aznap elõször.  A
		sorozatszám megadása fontos az
		alárendelt névszerverek
		számára, mivel így tudják
		megállapítani, hogy a zóna mikor
		változott utoljára.</para>
	    </listitem>
	  </varlistentry>
	</variablelist>

	<programlisting>
                IN NS           ns1.minta.org.</programlisting>

	<para>Ez egy NS bejegyzés.  A zónához
	  tartozó minden hitelesített névszervernek
	  lennie kell legalább egy ilyen
	  bejegyzésének.</para>

	<programlisting>localhost       IN      A       127.0.0.1
ns1             IN      A       192.168.1.2
ns2             IN      A       192.168.1.3
mx              IN      A       192.168.1.4
levelezes       IN      A       192.168.1.5</programlisting>

	<para>Az A rekord egy gép nevét adja meg.  Ahogy a
	  fenti példából is kiderül, az
	  <hostid role="fqdn">ns1.minta.org</hostid> név a
	  <hostid role="ipaddr">192.168.1.2</hostid> címre
	  képzõdik le.</para>

	<programlisting>                IN      A       192.168.1.1</programlisting>

	<para>Ez a sor <hostid role="ipaddr">192.168.1.1</hostid>
	  címet rendeli az aktuális õshöz, amely
	  jelen esetünkben az <hostid
	  role="domainname">example.org</hostid>.</para>

	<programlisting>www             IN CNAME        @</programlisting>

	<para>A kanonikus neveket tároló rekordokat
	  általában egy gép álneveihez
	  használjuk.  Ebben a példában a
	  <hostid>www</hostid> a <quote>fõgép</quote> egyik
	  álneve, amely itt éppenséggel a <hostid
	    role="domainname">minta.org</hostid> (<hostid
	    role="ipaddr">192.168.1.1</hostid>) tartományneve.  A
	  CNAME rekordok mellé más típusú
	  rekordokat ugyanarra a hálózati névre
	  soha ne adjunk meg.</para>

	<indexterm><primary>MX rekord</primary></indexterm>

	<programlisting>                IN MX   10      levelezes.minta.org.</programlisting>

	<para>Az MX rekord adja meg, hogy milyen levelezõ szerverek
	  felelõsek a zónába érkezõ
	  levelek fogadásáért.  A <hostid
	  role="fqdn">levelezes.minta.org</hostid> a levelezõ
	  szerver hálózati neve, ahol a 10 az adott
	  levelezõ szerver prioritása.</para>

	<para>Több levelezõ szerver is megadható 10-es,
	  20-as stb.  prioritásokkal.  A <hostid
	  role="domainname">minta.org</hostid> tartományon
	  belül elõször mindig a legnagyobb MX
	  prioritással rendelkezõ levelezõ szervernek
	  próbáljuk meg továbbítani a
	  leveleket (a legkisebb prioritási
	  értékkel rendelkezõ rekord), majd
	  ezután a második legnagyobbnak stb.
	  egészen addig, amíg a levelet tovább nem
	  küldtük.</para>

	<para>Az in-addr.arpa zóna állományok
	  (inverz DNS) esetén ugyanez a
	  felépítés, kivéve, hogy a PTR
	  típusú bejegyzések szerepelnek az A
	  és CNAME helyett.</para>

	<programlisting>$TTL 3600

1.168.192.in-addr.arpa. IN SOA ns1.minta.org. admin.minta.org. (
                        2006051501      ; sorozatszám
                        10800           ; frissítés
                        3600            ; ismétlés
                        604800          ; lejárat
                        300 )           ; TTL negatív válasz

        IN      NS      ns1.minta.org.
        IN      NS      ns2.minta.org.

1       IN      PTR     minta.org.
2       IN      PTR     ns1.minta.org.
3       IN      PTR     ns2.minta.org.
4       IN      PTR     mx.minta.org.
5       IN      PTR     levelezes.minta.org.</programlisting>

	<para>Ez az állomány írja le tehát a
	  kitalált tartományunkon belül az
	  IP-címek és hálózati nevek
	  összerendelését.</para>

	<para>Érdemes megemlíteni, hogy a PTR rekordok
	  jobb oldalán álló nevek
	  mindegyikének teljes hálózati
	  névnek kell lennie (vagyis <quote>.</quote> karakterrel
	  kell végzõdnie).</para>
      </sect3>
    </sect2>

    <sect2>
      <title>A gyorsítótárazó
	névszerver</title>

      <indexterm>
	<primary>BIND</primary>
	<secondary>gyorsítótárazó
	  névszerver</secondary>
      </indexterm>

      <para>A gyorsítótárazó
	névszerver az a névszerver, amely elsõdleges
	feladata a rekurzív kérések
	kiszolgálása.  Egyszerûen
	továbbítja a beérkezõ
	kéréseket, majd megjegyzi azokat, így
	késõbb közvetlenül tud
	válaszolni.</para>
    </sect2>

    <sect2>
      <title>Biztonság</title>

      <para>Habár a névfeloldás
	szempontjából a BIND a legelterjedtebb, a
	biztonságosságával azért akadnak
	gondok.  Gyakran találnak benne potenciális
	és kihasználható biztonsági
	réseket.</para>

      <para>A &os; azonban a <application>named</application>
	démont automatikusan egy &man.chroot.8; környezetbe
	helyezi.  Emellett még léteznek további
	más védelmi mechanizmusok is, amelyek
	segítségével el tudjuk kerülni a
	névfeloldást célzó esetleges
	támadásokat.</para>

      <para>Sosem árt olvasgatni a <ulink
	url="http://www.cert.org/">CERT</ulink> által kiadott
	biztonsági figyelmeztetéseket és
	feliratkozni a &a.security-notifications; címére,
	hogy folyamatosan értesüljünk az interneten
	és a &os;-ben talált különbözõ
	biztonsági hibákról.</para>

      <tip>
	<para>Ha valamilyen gondunk támadna, akkor esetleg
	  próbálkozzunk meg a forrásaink
	  frissítésével és a
	  <application>named</application>
	  újrafordításával.</para>
      </tip>
    </sect2>

    <sect2>
      <title>Egyéb olvasnivalók</title>

      <para>A BIND/<application>named</application> man oldalai:
	&man.rndc.8; &man.named.8; &man.named.conf.5;</para>

      <itemizedlist>
	<listitem>
	  <para><ulink url="http://www.isc.org/software/bind">Az ISC
	    BIND hivatalos honlapja (angolul)</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink url="http://www.isc.org/software/guild">Az ISC BIND
	    hivatalos fóruma (angolul)</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink
	      url="http://www.oreilly.com/catalog/dns5/">O'Reilly DNS and
	    BIND 5th Edition</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink
	      url="http://www.rfc-editor.org/rfc/rfc1034.txt">RFC1034 -
	    Domain Names - Concepts and Facilities</ulink></para>
	</listitem>

	<listitem>
	  <para><ulink
	      url="http://www.rfc-editor.org/rfc/rfc1035.txt">RFC1035 -
	    Domain Names - Implementation and
	    Specification</ulink></para>
	</listitem>
      </itemizedlist>
    </sect2>
  </sect1>

  <sect1 id="network-apache">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Murray</firstname>
	  <surname>Stokely</surname>
	  <contrib>Készítette: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Az Apache webszerver</title>

    <indexterm>
      <primary>webszerverek</primary>
      <secondary>beállítása</secondary>
    </indexterm>

    <indexterm><primary>Apache</primary></indexterm>

    <sect2>
      <title>Áttekintés</title>

      <para>A &os; szolgálja ki a legforgalmasabb honlapok nagy
	részét szerte a világban.  A
	mögöttük álló webszerverek
	általában az <application>Apache
	webszervert</application> alkalmazzák.  Az
	<application>Apache</application> használatához
	szükséges csomagok megtalálhatóak a
	&os; telepítõlemezén is.  Ha a &os; elsõ
	telepítésekor még nem
	telepítettük volna az
	<application>Apache</application> szerverét, akkor a
	<filename role="package">www/apache13</filename> vagy <filename
	role="package">www/apache12</filename> portból tudjuk
	feltenni.</para>

      <para>Az <application>Apache</application> szervert sikeres
	telepítését követõen be kell
	állítanunk.</para>

      <note>
	<para>Ebben a szakaszban az <application>Apache
	  webszerver</application> 1.3.X változatát
	  mutatjuk be, mivel ezt használják a
	  legtöbben &os; alatt.  Az
	  <application>Apache</application>&nbsp;2.X rengeteg új
	  technológiát vezetett be, de ezekkel itt most
	  nem foglalkozunk.  Az
	  <application>Apache</application>&nbsp;2.X
	  változatával kapcsolatban keressük fel a
	  <ulink url="http://httpd.apache.org/"></ulink> oldalt.</para>
      </note>

    </sect2>

    <sect2>
      <title>Beállítás</title>

      <indexterm>
	<primary>Apache</primary>
	<secondary>konfigurációs
	  állományok</secondary>
      </indexterm>

      <para>Az <application>Apache webszerver</application>
	konfigurációs állománya &os; alatt
	<filename>/usr/local/etc/apache/httpd.conf</filename>
	néven található.  Ez az
	állomány egy szokványos &unix;-os
	szöveges konfigurációs
	állomány, ahol a megjegyzéseket egy
	<literal>#</literal> karakterrel vezetjük be.  Az itt
	használható összes lehetséges
	beállítási lehetõség
	átfogó ismertetése meghaladná az
	egész kézikönyv határait, ezért
	most csak a leggyakrabban módosított
	direktívákat fogjuk ismertetni.</para>

      <variablelist>
	<varlistentry>
	  <term><literal>ServerRoot <replaceable>"/usr/local"</replaceable></literal></term>

	  <listitem>
	    <para>Ez adja meg az <application>Apache</application>
	      számára az alapértelmezett
	      könyvtárat.  A binárisai ezen
	      belül a <filename class="directory">bin</filename>
	      és <filename class="directory">sbin</filename>
	      alkönyvtárakban, a konfigurációs
	      állományai pedig az <filename
	      class="directory">etc/apache</filename>
	      könyvtárban tárolódnak.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><literal>ServerAdmin <replaceable>saját@címünk.az.interneten</replaceable></literal></term>

	  <listitem>
	    <para>Erre a címre küldhetik nekünk a
	      szerverrel kapcsolatos hibákat.  Ez a cím
	      egyes szerver által generált oldalakon
	      jelenik meg, például hibák
	      esetében.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><literal>ServerName <replaceable>www.minta.com</replaceable></literal></term>

	  <listitem>
	    <para>A <literal>ServerName</literal>
	      segítségével meg tudjuk adni, hogy
	      milyen nevet küldjön vissza a szerver a
	      klienseknek olyankor, ha az nem egyezne meg a jelenlegivel
	      (vagyis a <hostid>www</hostid> nevet használjuk a
	      gépünk valódi neve helyett).</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><literal>DocumentRoot <replaceable>"/usr/local/www/data"</replaceable></literal></term>

	  <listitem>
	    <para>A <literal>DocumentRoot</literal> adja meg azt a
	      könyvtárat, ahonnan kiszolgáljuk a
	      dokumentumokat.  Alapértelmezés szerint az
	      összes kérés erre a
	      könyvtárra fog vonatkozni, de a szimbolikus
	      linkek és az álnevek akár más
	      helyekre is mutathatnak.</para>
	  </listitem>
	</varlistentry>
      </variablelist>

      <para>A változtatások végrehajtása
	elõtt mindig is jó ötlet biztonsági
	másolatot készíteni az
	<application>Apache</application> konfigurációs
	állományairól.  Ahogy sikerült
	összerakni egy számunkra megfelelõ
	konfigurációt, készen is állunk az
	<application>Apache</application>
	futtatására.</para>

    </sect2>

    <sect2>
      <title>Az <application>Apache</application>
	futtatása</title>

      <indexterm>
	<primary>Apache</primary>
	<secondary>indítása és
	  leállítása</secondary>
      </indexterm>

      <para>A többi hálózati szervertõl
	eltérõen az <application>Apache</application> nem az
	<application>inetd</application> szuperszerverbõl fut.  A
	kliensektõl érkezõ HTTP kérések
	minél gyorsabb kiszolgálásának
	érdekében úgy állítottuk be,
	hogy önállóan fusson.  Ehhez egy szkriptet is
	mellékeltünk, amellyel igyekeztünk a
	lehetõ legjobban leegyszerûsíteni a szerver
	indítását,
	leállítását és
	újraindítását.  Az
	<application>Apache</application> elsõ
	indításához adjuk ki a következõ
	parancsot:</para>

      <screen>&prompt.root; <userinput>/usr/local/sbin/apachectl start</userinput></screen>

      <para>Így pedig a szervert bármikor
	leállíthatjuk:</para>

      <screen>&prompt.root; <userinput>/usr/local/sbin/apachectl stop</userinput></screen>

      <para>Ha valamilyen okból megváltoztattuk volna a
	szerver beállításait, akkor ezen a
	módon tudjuk újraindítani:</para>

      <screen>&prompt.root; <userinput>/usr/local/sbin/apachectl restart</userinput></screen>

      <para>Ha a jelenleg megnyitott kapcsolatok felbontása
	nélkül akarjuk újraindítani az
	<application>Apache</application> szervert, akkor ezt
	írjuk be:</para>

      <screen>&prompt.root; <userinput>/usr/local/sbin/apachectl graceful</userinput></screen>

      <para>Mindezekrõl az &man.apachectl.8; man oldalon
	találunk bõvebb leírást.</para>

      <para>Amennyiben szükségünk lenne az
	<application>Apache</application>
	elindítására a rendszer
	indításakor, akkor a következõ sort
	vegyünk fel az <filename>/etc/rc.conf</filename>
	állományba:</para>

      <programlisting>apache_enable="YES"</programlisting>

      <para>Az <application>Apache</application>&nbsp;2.2
	esetében:</para>

      <programlisting>apache22_enable="YES"</programlisting>

      <para>Amikor az <application>Apache</application>
	<command>httpd</command> nevû programjának
	szeretnénk további paranccsori
	paramétereket átadni a rendszer
	indítása során, akkor ezeket így
	tudjuk megadni az <filename>rc.conf</filename>
	állományban:</para>

      <programlisting>apache_flags=""</programlisting>

      <para>Most, miután a webszerverünk mûködik,
	a böngészõnkkel mindezt ellenõrizni is
	tudjuk a <literal>http://localhost/</literal> cím
	beírásával.  Ilyenkor az
	alapértelmezés szerinti
	<filename>/usr/local/www/data/index.html</filename>
	állomány tartalmát láthatjuk.</para>

    </sect2>

    <sect2>
      <title>Virtuális nevek</title>

      <para>Az <application>Apache</application> a virtuális
	nevek használatának két
	különbözõ módját ismeri.  Ezek
	közül az elsõ módszer a név
	alapú virtualizáció (Name-based Virtual
	Hosting).  Ilyenkor a kliens HTTP/1.1
	fejlécébõl próbálja meg a
	szerver megállapítani a hivatkozási nevet.
	Segítségével több tartomány is
	osztozhat egyetlen IP-címen.</para>

      <para>Az <application>Apache</application> név alapú
	virtualizációjának
	beállításához az alábbi
	beállítást kell hozzátennünk a
	<filename>httpd.conf</filename>
	állományhoz:</para>

      <programlisting>NameVirtualHost *</programlisting>

      <para>Ha a webszerverünk neve <hostid
	role="fqdn">www.tartomany.hu</hostid>, és hozzá
	egy <hostid role="fqdn">www.valamilyenmasiktartomany.hu</hostid>
	virtuális nevet akarunk megadni, akkor azt a
	következõképpen tehetjük meg a
	<filename>httpd.conf</filename> állományon
	belül:</para>

      <screen>&lt;VirtualHost *&gt;
ServerName www.tartomany.hu
DocumentRoot /www/tartomany.hu
&lt;/VirtualHost&gt;

&lt;VirtualHost *&gt;
ServerName www.valamilyenmasiktartomany.hu
DocumentRoot /www/valamilyenmasiktartomany.hu
&lt;/VirtualHost&gt;</screen>

      <para>A címek és elérési utak
	helyére helyettesítsük be a használni
	kívánt címeket és
	elérési utakat.</para>

      <para>A virtuális nevek
	beállításának további
	részleteivel kapcsolatosan keressük fel az
	<application>Apache</application> hivatalos
	dokumentációját a <ulink
	url="http://httpd.apache.org/docs/vhosts/"></ulink> címen
	(angolul).</para>

    </sect2>

    <sect2>
      <title>Apache-modulok</title>

      <indexterm>
	<primary>Apache</primary>
	<secondary>modulok</secondary>
      </indexterm>

      <para>Az alap szerver képességeinek
	kiegészítéséhez több
	különbözõ <application>Apache</application>
	modul áll rendelkezésünkre.  A &os;
	Portgyûjteménye az <application>Apache</application>
	telepítése mellett lehetõséget ad a
	népszerûbb bõvítményeinek
	telepítésére is.</para>

      <sect3>
	<title>mod_ssl</title>

	<indexterm>
	  <primary>webszerverek</primary>
	  <secondary>biztonság</secondary>
	</indexterm>

	<indexterm><primary>SSL</primary></indexterm>
	<indexterm><primary>titkosítás</primary></indexterm>

	<para>A <application>mod_ssl</application> modul az OpenSSL
	  könyvtár használatával
	  valósít meg erõs titkosítást
	  a biztonságos socket réteg második,
	  illetve harmadik verziójával (Secure Sockets
	  Layer, SSL v2/v3) és a biztonságos
	  szállítási rétegbeli (Transport
	  Layer Security v1) protokoll
	  segítségével.  Ez a modul mindent
	  biztosít ahhoz, hogy a megfelelõ
	  hatóságok által aláírt
	  tanúsítványokat tudjunk kérni,
	  és ezáltal egy védett webszervert
	  futtassunk &os;-n.</para>

	<para>Ha még nem telepítettünk volna fel az
	  <application>Apache</application> szervert, akkor a <filename
	  role="package">www/apache13-modssl</filename> porton
	  keresztül a <application>mod_ssl</application> modullal
	  együtt is fel tudjuk rakni az
	  <application>Apache</application>&nbsp;1.3.X
	  változatát.  Az SSL támogatása
	  pedig már az <application>Apache</application>&nbsp;2.X
	  <filename role="package">www/apache22</filename> porton
	  keresztül elérhetõ változataiban
	  alapértelmezés szerint
	  engedélyezett.</para>

      </sect3>

      <sect3>
	<title>Kapcsolódás nyelvekhez</title>

	<para>Mindegyik nagyobb szkriptnyelvhez létezik egy
	  külön Apache-modul, amelyek
	  segítségével komplett
	  <application>Apache</application>-modulokat tudunk
	  készíteni az adott nyelven.  Gyakran a dinamikus
	  honlapok is így próbálják a
	  szerverbe épített belsõ
	  értelmezõn keresztül a külsõ
	  értelmezõ indításából
	  és benne a szkriptek
	  lefuttatásából fakadó
	  költségeket megspórolni, ahogy errõl a
	  következõ szakaszokban olvashatunk.</para>

      </sect3>
    </sect2>

    <sect2>
      <title>Dinamikus honlapok</title>

      <indexterm>
	<primary>webszerverek</primary>
	<secondary>dinamikus</secondary>
      </indexterm>

      <para>Az utóbbi évtizedben egyre több
	vállalkozás fordult az internet felé
	bevételeik és részesedéseinek
	növelésének reményében, amivel
	egyre jobban megnõtt az igény a dinamikus honlapokra
	is.  Miközben bizonyos cégek, mint
	például a &microsoft;, a saját
	fejlesztésû termékeikbe
	építettek be ehhez támogatást, addig
	a nyílt forrásokkal foglalkozó
	közösség sem maradt tétlen és
	felvette a kesztyût.  A dinamikus tartalom
	létrehozásához többek közt
	Django, Ruby on Rails, a <application>mod_perl</application>
	és a <application>mod_php</application> modulok
	használhatóak.</para>

      <sect3>
	<title>Django</title>

	<indexterm><primary>Python</primary></indexterm>
	<indexterm><primary>Django</primary></indexterm>

	<para>A Django egy BSD típusú licensszel
	  rendelkezõ keretrendszer, amelynek
	  használatával nagy
	  teljesítményû és elegáns
	  webes alkalmazásokat tudunk gyorsan kifejleszteni.
	  Tartalmaz egy objektum-relációs
	  leképezõt, így az adattípusokat
	  Python-objektumokként tudjuk leírni, és
	  ezekhez az objektumokhoz egy sokrétû, dinamikus
	  adatbázis hozzáférést
	  nyújtó alkalmazásfejlesztõi
	  felületet, így a fejlesztõknek egyetlen SQL
	  utasítást sem kell megírniuk.
	  Találhatunk még benne továbbá egy
	  bõvíthetõ sablonrendszert, amelynek
	  köszönhetõen az alkalmazás belsõ
	  mûködése elválasztható a
	  HTML-beli megjelenésétõl.</para>

	<para>A Django mûködéséhez a
	  <application>mod_python</application> modulra, az
	  <application>Apache</application> szerverre és egy
	  tetszõlegesen választott SQL alapú
	  adatbázisrendszerre van szükség.  A
	  hozzá tartozó &os; port mindezeket automatikusan
	  telepíti a megadott beállítások
	  szerint.</para>

	<example id="network-www-django-install">
	  <title>A Django telepítése az Apache,
	    mod_python3 és a PostgreSQL
	    használatával</title>

	  <screen>&prompt.root; <userinput>cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL</userinput></screen>
	</example>

	<para>Miután a Django és a hozzá
	  szükséges komponensek felkerültek
	  rendszerünkre, hozzunk létre egy
	  könyvtárat a leendõ Django projektünknek
	  és állítsuk be az Apache szervert, hogy
	  az oldalunk belül a megadott linkekre a saját
	  alkalmazásunkat hívja meg a beágyazott
	  Python-értelmezõn keresztül.</para>

	<example id="network-www-django-apache-config">
	  <title>Az Apache beállítása a Django
	    és mod_python használatához</title>

	  <para>A következõ sort kell hozzátennünk
	    a <filename>httpd.conf</filename> állományhoz,
	    hogy az Apache bizonyos linkeket a webes alkalmazás
	    felé irányítson át:</para>

	  <screen>&lt;Location "/"&gt;
    SetHandler python-program
    PythonPath "['<replaceable>/a/django/csomagok/helye/</replaceable>'] + sys.path"
    PythonHandler django.core.handlers.modpython
    SetEnv DJANGO_SETTINGS_MODULE <replaceable>azoldalam.beallitasai</replaceable>
    PythonAutoReload On
    PythonDebug On
&lt;/Location&gt;</screen>
	</example>

      </sect3>

      <sect3>
	<title>Ruby on Rails</title>

	<indexterm><primary>Ruby on Rails</primary></indexterm>

	<para>A Ruby on Rails egy olyan másik nyílt
	  forráskódú keretrendszer, amivel
	  lényegében egy teljes fejlesztõi
	  készletet kapunk és amelyet kifejezetten arra
	  élezték ki, hogy
	  segítségével a webfejlesztõk sokkal
	  gyorsabban tudjanak haladni és a komolyabb
	  alkalmazások gyorsabb elkészítése
	  se okozzon nekik gondot.  A
	  Portrgyûjteménybõl pillanatok alatt
	  telepíthetõ.</para>

	<screen>&prompt.root; <userinput>cd /usr/ports/www/rubygem-rails; make all install clean</userinput></screen>

      </sect3>

      <sect3>
	<title>mod_perl</title>

	<indexterm>
	  <primary>mod_perl</primary>
	  <secondary>Perl</secondary>
	</indexterm>

	<para>Az <application>Apache</application> és Perl
	  egyesítésén fáradozó
	  projekt a Perl programozási nyelv és az
	  <application>Apache webszerver</application> erejének
	  összehangolásán dolgozik.  A
	  <application>mod_perl</application> modulon keresztül
	  Perlben vagyunk képesek modulokat
	  készíteni az <application>Apache</application>
	  szerverhez.  Ráadásul a szerverben egy
	  belsõ állandó értelmezõ is
	  található hozzá, ezzel igyekeznek
	  megspórolni a külsõ értelmezõ
	  és a Perl indításából
	  keletkezõ többletköltségeket.</para>

	<para>A <application>mod_perl</application> több
	  különbözõ módon
	  állítható munkába.  A
	  <application>mod_perl</application>
	  használatához nem szabad elfelejtenünk,
	  hogy a <application>mod_perl</application> 1.0-ás
	  verziója csak az <application>Apache</application> 1.3
	  változatával mûködik, és a
	  <application>mod_perl</application> 2.0-ás
	  változata pedig csak az
	  <application>Apache</application>&nbsp;2.X
	  változataival.  A <application>mod_perl</application>
	  1.0 a <filename role="package">www/mod_perl</filename>
	  portból telepíthetõ, valamint a statikusan
	  beépített változata a <filename
	  role="package">www/apache13-modperl</filename> portban
	  található.  A
	  <application>mod_perl</application>&nbsp;2.0 a <filename
	  role="package">www/mod_perl2</filename> portból
	  rakható fel.</para>

      </sect3>

      <sect3>
	<sect3info>
	  <authorgroup>
	    <author>
	      <firstname>Tom</firstname>
	      <surname>Rhodes</surname>
	      <contrib>Írta: </contrib>
	    </author>
	  </authorgroup>
	</sect3info>

	<title>mod_php</title>

	<indexterm>
	  <primary>mod_php</primary>
	  <secondary>PHP</secondary>
	</indexterm>

	<para>A <acronym>PHP</acronym>, vagy másik nevén
	  <quote>PHP, a hipertext feldolgozó</quote> egy
	  általános célú szkriptnyelv,
	  amelyet kifejezetten honlapok fejlesztéséhez
	  hoztak létre.  A szabványos
	  <acronym>HTML</acronym> ágyazható nyelv
	  felépítésében a C, &java;
	  és Perl nyelveket ötvözi annak
	  elérése érdekében, hogy ezzel
	  segítse a fejlesztõket a dinamikusan
	  generált oldalak minél gyorsabb
	  megírásában.</para>

	<para>A <acronym>PHP</acronym>5 támogatását
	  úgy tudjuk hozzáadni az
	  <application>Apache</application> webszerverhez, ha
	  telepítjük a <filename
	  role="package">lang/php5</filename> portot.</para>

	<para>Ha a <filename role="package">lang/php5</filename> portot
	  most telepítjük elõször, akkor a vele
	  kapcsolatos beállításokat
	  tartalmazó <literal>OPTIONS</literal> menü
	  automatikusan megjelenik.  Ha ezzel nem
	  találkoznánk, mert például
	  valamikor korábban már felraktuk volna a
	  <filename role="package">lang/php5</filename> portot, akkor a
	  port könyvtárában következõ
	  parancs kiadásával tudjuk újra
	  visszahozni:</para>

	<screen>&prompt.root; <userinput>make config</userinput></screen>

	<para>A beállítások között
	  jelöljük be az <literal>APACHE</literal>
	  opciót, amelynek eredményeképpen
	  létrejön az <application>Apache</application>
	  webszerverhez használható
	  <application>mod_php5</application> betölthetõ
	  modul.</para>

	<note>
	  <para>A <acronym>PHP</acronym>4 modult még ma is
	    rengeteg szerver használja több
	    különbözõ okból
	    (például kompatibilitási
	    problémák vagy a már korábban
	    kiadott tartalom miatt).  Ha tehát a
	    <application>mod_php5</application> helyett inkább a
	    <application>mod_php4</application> modulra lenne
	    szükségünk, akkor a <filename
	    role="package">lang/php4</filename> portot
	    használjuk.  A <filename
	    role="package">lang/php4</filename> portnál is
	    megtalálhatjuk a <filename
	    role="package">lang/php5</filename> fordítási
	    idejû beállításainak nagy
	    részét.</para>
	</note>

	<para>Az iméntiek révén települnek
	  és beállítódnak a dinamikus
	  <acronym>PHP</acronym> alkalmazások
	  támogatásához szükséges
	  mouldok.  Az
	  <filename>/usr/local/etc/apache/httpd.conf</filename>
	  állományban ellenõrizni is tudjuk, hogy az
	  alábbi részek megjelentek-e:</para>

	<programlisting>LoadModule php5_module        libexec/apache/libphp5.so</programlisting>

	<programlisting>AddModule mod_php5.c
    &lt;IfModule mod_php5.c&gt;
        DirectoryIndex index.php index.html
    &lt;/IfModule&gt;
    &lt;IfModule mod_php5.c&gt;
        AddType application/x-httpd-php .php
        AddType application/x-httpd-php-source .phps
    &lt;/IfModule&gt;</programlisting>

	<para>Ahogy befejezõdött a mûvelet, a
	  <acronym>PHP</acronym> modul betöltéséhez
	  mindösszesen az <command>apachectl</command> paranccsal
	  kell óvatosan újraindítanunk a
	  webszervert:</para>

	<screen>&prompt.root; <userinput>apachectl graceful</userinput></screen>

	<para>A <acronym>PHP</acronym> jövõbeni
	  frissítéseihez már nem lesz
	  szükségünk a <command>make config</command>
	  parancsra, mivel a korábban kiválasztott
	  <literal>OPTIONS</literal> menün belüli
	  beállítasainkat a &os;
	  Portgyûjteményéhez tartozó
	  keretrendszer automatikusan elmenti.</para>

	<para>A <acronym>PHP</acronym> &os;-ben
	  megtalálható támogatása
	  kifejezetten moduláris, ezért az alap
	  telepítése igencsak korlátozott.  A
	  további elemek hozzáadásához a
	  <filename role="package">lang/php5-extensions</filename>
	  portot tudjuk használni.  A port egy
	  menüvezérelt felületet nyújt a
	  <acronym>PHP</acronym> különbözõ
	  bõvítményeinek
	  telepítéséhez.  Az egyes
	  bõvítményeket azonban a megfelelõ
	  portok használatával is fel tudjuk rakni.</para>

	<para>Például <acronym>PHP</acronym>5 modulhoz
	  úgy tudunk támogatást adni a
	  <application>MySQL</application> adatbázis szerverhez,
	  ha telepítjük a
	  <filename>databases/php5-mysql</filename> portot.</para>

	<para>Miután telepítettünk egy
	  bõvítményt, az
	  <application>Apache</application> szerverrel újra be
	  kell töltetnünk a megváltozott
	  beállításokat:</para>

	<screen>&prompt.root; <userinput>apachectl graceful</userinput></screen>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="network-ftp">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Murray</firstname>
	  <surname>Stokely</surname>
	  <contrib>Készítette: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Állományok átvitele (FTP)</title>

    <indexterm><primary>FTP szerverek</primary></indexterm>

    <sect2>
      <title>Áttekintés</title>

      <para>Az adatállomány átviteli protokoll
	(File Transfer Protocol, FTP) a felhasználók
	számára lehetõséget ad az ún.
	<acronym role="File Transfer Protocol">FTP</acronym> szerverekre
	állományokat feltölteni, illetve onnan
	állományokat letölteni.  A &os; alaprendszere
	is tartalmaz egy ilyen <acronym role="File Transfer
	Protocol">FTP</acronym> szerverprogramot,
	<application>ftpd</application> néven.  Ezért &os;
	alatt egy <acronym role="File Transfer Protocol">FTP</acronym>
	szerver beállítása meglehetõsen
	egyszerû.</para>

    </sect2>

    <sect2>
      <title>Beállítás</title>

      <para>A beállítás legfontosabb
	lépése, hogy eldöntsük milyen
	hozzáféréseken át lehet
	elérni az FTP szervert.  Egy hétköznapi &os;
	rendszerben rengeteg hozzáférés a
	különbözõ démonokhoz tartozik, de az
	ismeretlen felhasználók számára nem
	kellene megengednünk ezek használatát.  Az
	<filename>/etc/ftpusers</filename> állományban
	szerepelnek azok a felhasználók, akik semmilyen
	módon nem érhetik el az FTP
	szolgáltatást.  Alapértelmezés
	szerint itt találhatjuk az elõbb említett
	rendszerszintû hozzáféréseket is, de
	ide minden további nélkül felvehetjük
	azokat a felhasználókat, akiknél nem
	akarjuk engedni az FTP elérését.</para>

      <para>Más esetekben elõfordulhat, hogy csak
	korlátozni akarjuk egyes felhasználók FTP
	elérését.  Ezt az
	<filename>/etc/ftpchroot</filename> állományon
	keresztül tehetjük meg.  Ebben az
	állományban a lekorlátozni
	kívánt felhasználókat és
	csoportokat írhatjuk bele.  Az &man.ftpchroot.5; man
	oldalán olvashatjuk el ennek részleteit,
	ezért ennek pontos részleteit itt most nem
	tárgyaljuk.</para>

      <indexterm>
	<primary>FTP</primary>
	<secondary>anonim</secondary>
      </indexterm>

      <para>Ha az FTP szerverünkhöz névtelen (anonim)
	hozzáférést is engedélyezni akarunk,
	akkor ahhoz elõször készítenünk
	kell egy <username>ftp</username> nevû
	felhasználót a &os; rendszerünkben.  A
	felhasználók ezután az
	<username>ftp</username> vagy <username>anonymous</username>
	nevek, valamint egy tetszõleges jelszó (ez a
	hagyományok szerint a felhasználó e-mail
	címe) használatával is képesek
	lesznek bejelentkezni.  Az FTP szerver ezután a
	névtelen felhasználók esetében
	meghívja a &man.chroot.2; rendszerhívást,
	és ezzel lekorlátozza
	hozzáférésüket az
	<username>ftp</username> felhasználó
	könyvtárára.</para>

      <para>Két szöveges állományban adhatunk
	meg a becsatlakozó FTP kliensek számára
	üdvözlõ üzeneteket.  Az
	<filename>/etc/ftpwelcome</filename> állomány
	tartalmát még a bejelentkezés elõtt
	látni fogják a felhasználók, a
	sikeres bejelentkezést követõen pedig az
	<filename>/etc/ftpmotd</filename> állomány
	tartalmát látják.  Vigyázzunk, mert
	ennek az állománynak már a
	bejelentkezési környezethez képest
	relatív az elérése, ezért a
	névtelen felhasználók esetében ez
	konkrétan az <filename>~ftp/etc/ftpmotd</filename>
	állomány lesz.</para>

      <para>Ahogy beállítottuk az FTP szervert, az
	<filename>/etc/inetd.conf</filename> állományban
	is engedélyeznünk kell.  Itt mindössze annyira
	lesz szükségünk, hogy
	eltávolítsuk a megjegyzést jelzõ
	<quote>#</quote> karaktert a már meglevõ
	<application>ftpd</application> sor elõl:</para>

      <programlisting>ftp	stream	tcp	nowait	root	/usr/libexec/ftpd	ftpd -l</programlisting>

      <para>Ahogy arról már a <xref
	linkend="network-inetd-reread"/> szót ejtett, az
	<application>inetd</application>
	beállításait újra be kell
	olvastatnunk a konfigurációs
	állomány megváltoztatása
	után.  A <xref
	  linkend="network-inetd-settings"/> írja le az
	<application>inetd</application>
	engedélyezésének részleteit.</para>

      <para>Az <application>ftpd</application> önálló
	szerverként is elindítható.  Ehhez
	mindössze elegendõ csak a megfelelõ
	változót beállítani az
	<filename>/etc/rc.conf</filename>
	állományban:</para>

      <programlisting>ftpd_enable="YES"</programlisting>

      <para>Miután megadtuk az iménti
	változót, a szerver el fog indulni a rendszer
	következõ indítása során.
	Szükség esetén természetesen
	<username>root</username> felhasználóként a
	következõ paranccsal is közvetlenül
	elindítható:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/ftpd start</userinput></screen>

      <para>Most már be is tudunk jelentkezni az FTP
	szerverre:</para>

      <screen>&prompt.user; <userinput>ftp localhost</userinput></screen>

    </sect2>

    <sect2>
      <title>Karbantartás</title>

      <indexterm><primary>syslog</primary></indexterm>

      <indexterm>
	<primary>naplóállományok</primary>
	<secondary>FTP</secondary>
      </indexterm>

      <para>Az <application>ftpd</application> démon a
	&man.syslog.3; használatával naplózza az
	üzeneteket.  Alapértelmezés szerint a
	rendszernaplózó démon az FTP
	mûködésére vonatkozó
	üzeneteket az <filename>/var/log/xferlog</filename>
	állományba írja.  Az FTP naplóinak
	helyét az <filename>/etc/syslog.conf</filename>
	állományban tudjuk
	módosítani:</para>

      <programlisting>ftp.info      /var/log/xferlog</programlisting>

      <indexterm>
	<primary>FTP</primary>
	<secondary>anonim</secondary>
      </indexterm>

      <para>Legyünk körültekintõek a névtelen
	FTP szerverek üzemeltetésekor.  Azt pedig
	kétszer is gondoljuk meg, hogy
	engedélyezzük-e a névtelen
	felhasználók számára
	állományok feltöltését, hiszen
	könnyen azon kaphatjuk magunkat, hogy az FTP oldalunk
	illegális állománycserék
	színterévé válik vagy esetleg valami
	sokkal rosszabb történik.  Ha mindenképpen
	szükségünk lenne erre a
	lehetõségre, akkor állítsunk be olyan
	engedélyeket a feltöltött
	állományokra, hogy a többi névtelen
	felhasználó ezeket a tartalmuk tüzetes
	ellenõrzéséig ne is olvashassa.</para>

    </sect2>
  </sect1>

  <sect1 id="network-samba">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Murray</firstname>
	  <surname>Stokely</surname>
	  <contrib>Készítette: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Állomány- és nyomtatási
      szolgáltatások &microsoft.windows; kliensek
      számára (Samba)</title>

    <indexterm><primary>Samba szerver</primary></indexterm>
    <indexterm><primary>Microsoft Windows</primary></indexterm>
    <indexterm>
      <primary>állományszerver</primary>
      <secondary>windowszos kliensek</secondary>
    </indexterm>
    <indexterm>
      <primary>nyomtatószerver</primary>
      <secondary>windowszos kliensek</secondary>
    </indexterm>

    <sect2>
      <title>Áttekintés</title>

      <para>A <application>Samba</application> egy olyan elterjedt
	nyílt forráskódú szoftver, ami
	&microsoft.windows; kliensek számára tesz
	lehetõvé állomány- és
	nyomtatási szolgáltatásokat.  Az ilyen
	kliensek általa helyi meghajtóként
	képesek elérni a &os;
	állományrendszerét, vagy helyi
	nyomtatóként a &os; általt kezelt
	nyomtatókat.</para>

      <para>A <application>Samba</application> csomagja
	általában megtalálható a &os;
	telepítõeszközén.  Ha a &os;-vel
	együtt nem raktuk fel a <application>Samba</application>
	csomagját, akkor ezt késõbb <filename
	role="package">net/samba3</filename> port vagy csomag
	telepítésével pótolhatjuk.</para>

    </sect2>

    <sect2>
      <title>Beállítás</title>

      <para>A <application>Samba</application>
	konfigurációs állománya a
	telepítés után
	<filename>/usr/local/share/examples/samba/smb.conf.default</filename>
	néven található meg.  Ezt kell
	lemásolnunk <filename>/usr/local/etc/smb.conf</filename>
	néven, amelyet aztán a
	<application>Samba</application> tényleges
	használata elõtt módosítanunk
	kell.</para>

      <para>Az <filename>smb.conf</filename> állomány a
	<application>Samba</application> futásához
	használt beállításokat tartalmazza,
	mint például &windows; kliensek
	számára felkínált a nyomtatók
	és <quote>megosztások</quote> adatait.  A
	<application>Samba</application> csomagban ezen
	kívül találhatunk még egy
	<application>swat</application> nevû webes eszközt,
	amellyel egyszerû módon tudjuk az
	<filename>smb.conf</filename> állományt
	állítgatni.</para>

      <sect3>
	<title>A Samba webes adminisztrációs eszköze
	  (SWAT)</title>

	<para>A Samba webes adminisztrációs
	  segédeszköze (Samba Web Administration Tool, SWAT)
	  az <application>inetd</application> démonon
	  keresztül fut démonként.  Ennek
	  megfelelõn az <filename>/etc/inetd.conf</filename>
	  állományban a következõ sort kell
	  kivennünk megjegyzésbõl, mielõtt a
	  <application>swat</application>
	  segítségével megkezdenénk a
	  <application>Samba</application>
	  beállítását:</para>

	<programlisting>swat   stream  tcp     nowait/400      root    /usr/local/sbin/swat    swat</programlisting>

	<para>Ahogy azt a <xref linkend="network-inetd-reread"/> is
	  mutatja, az <application>inetd</application> démont
	  újra kell indítanunk a megváltozott
	  konfigurációs állományának
	  újbóli beolvasásához.</para>

	<para>Miután az <filename>inetd.conf</filename>
	  állományban a <application>swat</application>
	  engedélyezésre került, a
	  böngészõnk segítségével
	  próbáljunk meg a <ulink
	  url="http://localhost:901"></ulink> címre csatlakozni.
	  Elõször a rendszer <username>root</username>
	  hozzáférésével kell
	  bejelentkeznünk.</para>

	<para>Miután sikeresen bejelentkeztünk a
	  <application>Samba</application>
	  beállításait tárgyaló
	  lapra, el tudjuk olvasni a rendszer
	  dokumentációját, vagy a
	  <guimenu>Globals</guimenu> fülre kattintva
	  nekiláthatunk a beállítások
	  elvégzésének.  A
	  <guimenu>Globals</guimenu> részben
	  található opciók az
	  <filename>/usr/local/etc/smb.conf</filename>
	  állomány <literal>[global]</literal>
	  szekciójában található
	  változókat tükrözik.</para>

      </sect3>

      <sect3>
	<title>Általános
	  beállítások</title>

	<para>Akár a <application>swat</application>
	  eszközzel, akár a
	  <filename>/usr/local/etc/smb.conf</filename> közvetlen
	  módosításával dolgozunk, a
	  <application>Samba</application>
	  beállítása során a
	  következõkkel mindenképpen össze fogunk
	  futni:</para>

        <variablelist>
	  <varlistentry>
	    <term><literal>workgroup</literal></term>

	    <listitem>
	      <para>A szervert elérni kívánó
		számítógépek által
		használt NT tartomány vagy munkacsoport
		neve.</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><literal>netbios name</literal></term>

	    <listitem>
	      <indexterm><primary>NetBIOS</primary></indexterm>

	      <para>A <application>Samba</application> szerver NetBIOS
		neve.  Alapértelmezés szerint ez a
		név a gép hálózati
		nevének elsõ tagja.</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><literal>server string</literal></term>

	    <listitem>
	      <para>Ez a szöveg jelenik meg akkor, ha
		például a <command>net view</command>
		paranccsal vagy valamilyen más
		hálózati segédprogrammal
		kérdezzük le a szerver beszédesebb
		leírását.</para>
	    </listitem>
	  </varlistentry>
        </variablelist>
      </sect3>

      <sect3>
	<title>Biztonsági
	  beállítások</title>

	<para>A <filename>/usr/local/etc/smb.conf</filename>
	  állományban a két legfontosabb
	  beállítás a választott
	  biztonsági modell és a kliensek
	  felhasználói jelszavainak
	  tárolásához használt
	  formátum.  Az alábbi direktívák
	  vezérlik ezeket:</para>

        <variablelist>
	  <varlistentry>
	    <term><literal>security</literal></term>

	    <listitem>
	      <para>Itt a két leggyakoribb
		beállítás a <literal>security =
		share</literal> és a <literal>security =
		user</literal>.  Ha a kliensek a &os; gépen
		található felhasználói
		neveiket használják, akkor
		felhasználói szintû védelemre
		van szükségünk (tehát a user
		beállításra).  Ez az
		alapértelmezett biztonsági házirend
		és ilyenkor a klienseknek elõször be
		kell jelentkezniük a megosztott
		erõforrások
		eléréséhez.</para>

	      <para>A megosztás (share) szintû
		védelem esetében, a klienseknek nem kell a
		szerveren érvényes
		felhasználói névvel és
		jelszóval rendelkezniük a megosztott
		erõforrások eléréséhez.
		Ez volt az alapbeállítás a
		<application>Samba</application> korábbi
		változataiban.</para>
	    </listitem>
	  </varlistentry>

	  <varlistentry>
	    <term><literal>passdb backend</literal></term>

	    <listitem>
	      <indexterm><primary>NIS+</primary></indexterm>
	      <indexterm><primary>LDAP</primary></indexterm>
	      <indexterm><primary>SQL adatbázis</primary></indexterm>

	      <para>A <application>Samba</application> számos
		különbözõ hitelesítési
		modellt ismer.  A klienseket LDAP, NIS+, SQL
		adatbázis vagy esetleg egy
		módosított jelszó
		állománnyal is tudjuk hitelesíteni.
		Az alapértelmezett hitelesítési
		módszer a <literal>smbpasswd</literal>,
		így itt most ezzel foglalkozunk.</para>
	    </listitem>
	  </varlistentry>
	</variablelist>

	<para>Ha feltesszük, hogy az alapértelmezett
	  <literal>smbpasswd</literal> formátumot
	  választottuk, akkor a <application>Samba</application>
	  úgy fogja tudni hitelesíteni a klienseket, ha
	  elõtte létrehozzuk a
	  <filename>/usr/local/private/smbpasswd</filename>
	  állományt.  Ha a &windows;-os kliensekkel is el
	  akarjuk érni a &unix;-os felhasználói
	  hozzáféréseinket, akkor használjuk
	  a következõ parancsot:</para>

	<screen>&prompt.root; <userinput>smbpasswd -a <replaceable>felhasználónév</replaceable></userinput></screen>

	<note>
	  <para>A <application>Samba</application> a 3.0.23c
	    verziójától kezdõdõen a
	    hitelesítéshez szükséges
	    állományokat a <filename
	    class="directory">/usr/local/etc/samba</filename>
	    könyvtárban tárolja.  A
	    felhasználói hozzáférések
	    hozzáadására innentõl már a
	    <literal>tdbsam</literal> parancs használata
	    javasolt:</para>

	  <screen>&prompt.root; <userinput><command>pdbedit <option>-a</option> <option>-u</option> <replaceable>felhasználónév</replaceable></command></userinput></screen>
	</note>

	<para>A <ulink
	  url="http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/">
	  hivatalos Samba HOGYAN</ulink> ezekrõl a
	  beállításokról szolgál
	  további információkkal (angolul).
	  Viszont az itt vázolt alapok viszont már
	  elegendõek a <application>Samba</application>
	  elindításához.</para>

      </sect3>
    </sect2>

    <sect2>
      <title>A <application>Samba</application>
	elindítása</title>

      <para>A <filename role="package">net/samba3</filename> port a
	<application>Samba</application>
	irányítására egy új
	indító szkriptet tartalmaz.  A szkript
	engedélyezéséhez, tehát
	általa a <application>Samba</application>
	elindításának,
	leállításának és
	újraindításának lehetõvé
	tételéhez vegyük fel a következõ
	sort az <filename>/etc/rc.conf</filename>
	állományba:</para>

      <programlisting>samba_enable="YES"</programlisting>

      <para>Ha még finomabb irányításra
	vágyunk:</para>

      <programlisting>nmbd_enable="YES"</programlisting>
      <programlisting>smbd_enable="YES"</programlisting>

      <note>
	<para>Ezzel egyben a rendszer indításakor
	  automatikusan be is indítjuk a
	  <application>Samba</application>
	  szolgáltatást.</para>
      </note>

      <para>A <application>Samba</application> a következõkkel
	bármikor elindítható:</para>

      <screen>&prompt.root; <userinput>/usr/local/etc/rc.d/samba start</userinput>
Starting SAMBA: removing stale tdbs :
Starting nmbd.
Starting smbd.</screen>

      <para>Az rc szkriptekkel kapcsolatban a <xref
	linkend="configtuning-rcd"/>t ajánljuk
	elolvasásra.</para>

      <para>A <application>Samba</application> jelen pillanatban
	három különálló
	démonból áll.  Láthatjuk is, hogy az
	<application>nmbd</application> és
	<application>smbd</application> démonokat
	elindította a <filename>samba</filename> szkript.  Ha az
	<filename>smb.conf</filename> állományban
	engedélyeztük a <application>winbind</application>
	névfeloldási szolgáltatást is, akkor
	láthatjuk, hogy ilyenkor a
	<application>winbindd</application> démon is
	elindul.</para>

      <para>A <application>Samba</application> így
	állítható le akármikor:</para>

      <screen>&prompt.root; <userinput>/usr/local/etc/rc.d/samba stop</userinput></screen>

      <para>A <application>Samba</application> egy összetett
	szoftvercsomag, amely a &microsoft.windows;
	hálózatokkal kapcsolatos széles
	körû együttmûködést tesz
	lehetõvé.  Az általa felkínált
	alapvetõ lehetõségeken túl a többit
	a <ulink url="http://www.samba.org"></ulink> honlapon
	ismerhetjük meg (angolul).</para>

    </sect2>
  </sect1>

  <sect1 id="network-ntp">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Hukins</surname>
	  <contrib>Készítette: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Az órák egyeztetése az NTP
      használatával</title>

    <indexterm><primary>NTP</primary></indexterm>

    <sect2>
      <title>Áttekintés</title>

      <para>Idõvel a számítógép
	órája hajlamos elmászni.  A
	hálózati idõ protokoll (Network Time
	Protocol, NTP) az egyik módja az óránk
	pontosan tartásának.</para>

      <para>Rengeteg internetes szolgáltatás
	elvárja vagy éppen elõnyben
	részesíti a számítógép
	órájának pontosságát.
	Például egy webszervertõl
	megkérdezhetik, hogy egy állományt adott
	ideje módosítottak-e.  A helyi
	hálózatban az egyazon
	állományszerveren megosztott
	állományok ellentmondásmentes
	dátumozása érdekében szinte
	elengedhetetlen az órák
	szinkronizálása.  Az olyan
	szolgáltatások, mint a &man.cron.8; is komolyan
	építkeznek a pontosan járó
	rendszerórára, amikor egy adott pillanatban kell
	lefuttatniuk parancsokat.</para>

      <indexterm>
	<primary>NTP</primary>
	<secondary>ntpd</secondary>
      </indexterm>

      <para>A &os; alapból az &man.ntpd.8; <acronym role="Network
	Time Protocol">NTP</acronym> szervert tartalmazza, amellyel
	más <acronym role="Network Time Protocol">NTP</acronym>
	szerverek segítségével tudjuk
	beállítani gépünk
	óráját, vagy éppen idõvel
	kapcsolatos információkat szolgáltatni
	másoknak.</para>

    </sect2>

    <sect2>
      <title>A megfelelõ NTP szerverek
	kiválasztása</title>

      <indexterm>
	<primary>NTP</primary>
	<secondary>a szerverek kiválasztása</secondary>
      </indexterm>

      <para>Az óránk egyeztetéséhez egy vagy
	több <acronym role="Network Time Protocol">NTP</acronym>
	szerverre lesz szükségünk.  Elõfordulhat,
	hogy a hálózati rendszergazdánk vagy az
	internet-szolgáltatónk már
	beállított egy ilyen szervert erre a célra.
	Ezzel kapcsolatban olvassuk el a megfelelõ
	leírásokat.  A <ulink
	url="http://ntp.isc.org/bin/view/Servers/WebHome">nyilvánosan
	elérhetõ NTP szerverekrõl készült
	egy lista</ulink>, ahonnan könnyedén ki tudjuk
	keresni a számunkra leginkább megfelelõ
	(hozzánk legközelebbi) szervert.  Ne hagyjuk
	figyelmen kívül a szerverre vonatkozó
	házirendet és kérjünk engedélyt
	a használatához, amennyiben ez
	szükséges.</para>

      <para>Több, egymással közvetlen kapcsolatban nem
	álló NTP szerver
	választásával járunk jól, ha
	netalán az egyikük váratlanul
	elérhetetlenné vagy az órája
	pontatlanná válna.  Az &man.ntpd.8; a visszakapott
	válaszokat intelligensen használja fel, mivel
	esetükben a megbízható szervereket
	részesíti elõnyben.</para>

    </sect2>

    <sect2>
      <title>A gépünk
	beállítása</title>

      <indexterm>
	<primary>NTP</primary>
	<secondary>beállítása</secondary>
      </indexterm>

      <sect3>
	<title>Alapvetõ beállítások</title>

	<indexterm><primary>ntpdate</primary></indexterm>

	<para>Ha a számítógépünk
	  indításakor akarjuk egyeztetni az
	  óránkat, akkor erre az &man.ntpdate.8; nevû
	  programot használhatjuk.  Ez olyan asztali gépek
	  számára megfelelõ választás,
	  amelyeket gyakran indítanak újra és csak
	  idõnként kell szinkronizálnunk.  A
	  legtöbb gépnek viszont az &man.ntpd.8;
	  használatára van szüksége.</para>

	<para>Az &man.ntpdate.8; elindítása olyan
	  esetekben is hasznos, ahol az &man.ntpd.8; is fut.  Az
	  &man.ntpd.8; az órát fokozatosan
	  állítja, ellenben az &man.ntpdate.8; az
	  eltérés mértékétõl
	  és irányától függetlenül
	  egyszerûen átállítja a gép
	  óráját a pontos idõre.</para>

	<para>Az &man.ntpdate.8; elindítását
	  úgy tudjuk engedélyezni a rendszer
	  indításakor, ha az
	  <filename>/etc/rc.conf</filename> állományba
	  berakjuk az <literal>ntpdate_enable="YES"</literal> sort.
	  Emellett még <varname>ntpdate_flags</varname>
	  változóban meg kell adnunk az alkalmazott
	  beállítások mellett azokat a szervereket,
	  amelyekkel szinkronizálni akarunk.</para>

      </sect3>

      <sect3>
	<title>Általános
	  beállítások</title>

	<indexterm>
	  <primary>NTP</primary>
	  <secondary>ntp.conf</secondary>
	</indexterm>

	<para>Az NTP az <filename>/etc/ntp.conf</filename>
	  állományon keresztül
	  állítható, amelyek
	  felépítését az &man.ntp.conf.5;
	  man oldal tárgyalja.  Íme erre egy egyszerû
	  példa:</para>

	<programlisting>server ntplocal.minta.com prefer
server timeserver.minta.org
server ntp2a.minta.net

driftfile /var/db/ntp.drift</programlisting>

	<para>A <literal>server</literal> beállítás
	  adja meg az egyeztetéshez használt szervereket,
	  soronként egyet.  Ha egy szerver mellett szerepel
	  még a <literal>prefer</literal> paraméter is,
	  ahogy azt a példában a <hostid
	  role="fqdn">ntplocal.minta.com</hostid> mellett
	  láthattuk, akkor a többivel szemben azt a szervert
	  fogjuk elõnyben részesíteni.  Az így
	  kiemelt szervertõl érkezõ választ
	  abban az esetben viszont eldobjuk, hogy a többi
	  szervertõl kapott válasz jelentõs
	  mértékben eltér tõle.  Minden
	  más esetben a õ válasza lesz a
	  mérvadó.  A <literal>prefer</literal>
	  paramétert általában olyan NTP
	  szerverekhez használják, amelyek
	  közismerten nagy pontosságúak, tehát
	  például külön erre a célra
	  szánt felügyeleti eszközt is
	  tartalmaznak.</para>

	<para>A <literal>driftfile</literal>
	  beállítással azt az
	  állományt adjuk meg, amiben a rendszeróra
	  frekvencia eltolódásait tároljuk.  Az
	  &man.ntpd.8; program ezzel ellensúlyozza automatikusan
	  az óra természetes
	  elmászását, ezáltal
	  lehetõvé téve, hogy egy viszonylag pontos
	  idõt kapjuk még abban az esetben is, amikor egy
	  kis idõre külsõ idõforrások
	  nélkül maradnánk.</para>

	<para>A <literal>driftfile</literal>
	  beállítással egyben azt az
	  állományt jelöljük ki, amely az NTP
	  szervertõl kapott korábbi válaszokat
	  tárolja.  Ez az NTP mûködéséhez
	  szükséges belsõ adatokat tartalmaz,
	  ezért semmilyen más programnak nem szabad
	  módosítania.</para>

      </sect3>

      <sect3>
	<title>A szerverünk elérésének
	  szabályozása</title>

	<para>Alapértelmezés szerint az NTP
	  szerverünket bárki képes elérni az
	  interneten.  Az <filename>/etc/ntp.conf</filename>
	  állományban szereplõ
	  <literal>restrict</literal> beállítás
	  segítségével azonban meg tudjuk mondani,
	  milyen gépek érhetik el a
	  szerverünket.</para>

	<para>Ha az NTP szerverünk felé mindenféle
	  próbálkozást el akarunk utasítani,
	  akkor az <filename>/etc/ntp.conf</filename>
	  állományba a következõ sort kell
	  felvennünk:</para>

	<programlisting>restrict default ignore</programlisting>

	<note>
	  <para>Ezzel egyben azonban a helyi
	    beállításainkban szereplõ
	    szerverek elérését is
	    megakadályozzuk.  Ha külsõ NTP szerverekkel
	    is szeretnénk szinkronizálni, akkor itt is
	    engedélyezünk kell ezeket.  Errõl
	    bõvebben lásd az &man.ntp.conf.5; man
	    oldalon.</para>
	</note>

	<para>Ha csak a belsõ hálózatunkban levõ
	  gépek számára szeretnénk
	  elérhetõvé tenni az órák
	  egyeztetését, de sem a szerver
	  állapotának
	  módosítását nem
	  engedélyezzük, sem pedig azt, hogy a vele
	  egyenrangú szerverekkel szinkronizáljon, akkor
	  az iménti helyett a</para>

	<programlisting>restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap</programlisting>

	<para>sort írjuk bele, ahol a <hostid
	    role="ipaddr">192.168.1.0</hostid> a belsõ
	  hálózatunk IP-címe és a <hostid
	    role="netmask">255.255.255.0</hostid> a
	  hozzá tartozó hálózati
	  maszk.</para>

	<para>Az <filename>/etc/ntp.conf</filename> több
	  <literal>restrict</literal> típusú
	  beállítást is tartalmazhat.  Ennek
	  részleteirõl az &man.ntp.conf.5; man oldalon, az
	  <literal>Access Control Support</literal> címû
	  szakaszban olvashatunk.</para>

      </sect3>
    </sect2>

    <sect2>
      <title>Az NTP futtatása</title>

      <para>Úgy tudjuk az NTP szervert elindítani a
	rendszerünkkel együtt, ha az
	<filename>/etc/rc.conf</filename> állományban
	szerepeltetjük az <literal>ntpd_enable="YES"</literal>
	sort.  Ha az &man.ntpd.8; számára további
	beállításokat is át akarunk adni,
	akkor az <filename>/etc/rc.conf</filename>
	állományban adjuk meg az
	<varname>ntpd_flags</varname> paramétert.</para>

      <para>Ha a gépünk újraindítása
	nélkül akarjuk elindítani a szerver, akkor az
	<command>ntpd</command> parancsot adjuk ki az
	<filename>/etc/rc.conf</filename> állományban a
	<varname>ntpd_flags</varname> változóhoz megadott
	paraméterekkel.  Mint például:</para>

      <screen>&prompt.root; <userinput>ntpd -p /var/run/ntpd.pid</userinput></screen>

    </sect2>

    <sect2>
      <title>Az ntpd használati idõleges internet
	csatlakozással</title>

      <para>Az &man.ntpd.8; program megfelelõ
	mûködéséhez nem szükséges
	állandó internet kapcsolat.  Ha azonban
	igény szerinti tárcsázással
	építjünk fel ideiglenes kapcsolatot, akkor
	érdemes letiltani az NTP forgalmát, nehogy
	feleslegesen aktiválja vagy tartsa életben a
	vonalat.  Ha PPP típusú kapcsolatunk van, akkor az
	<filename>/etc/ppp/ppp.conf</filename> állományban
	a <literal>filter</literal> direktívával tudjuk
	ezt leszabályozni.  Például:</para>

      <programlisting> set filter dial 0 deny udp src eq 123
 # Nem engedjük az NTP által küldött adatoknak, hogy tárcsázást
 # kezdeményezzenek:
 set filter dial 1 permit 0 0
 set filter alive 0 deny udp src eq 123
 # Nem engedjük az NTP adatainak, hogy fenntartsák a kapcsolatot:
 set filter alive 1 deny udp dst eq 123
 set filter alive 2 permit 0/0 0/0</programlisting>

      <para>Mindenezekrõl részletesebb
	felvilágosítást a &man.ppp.8; man oldal
	<literal>PACKET FILTERING</literal> címû
	szakaszában és a
	<filename>/usr/share/examples/ppp/</filename>
	könyvtárban található
	példákban kaphatunk.</para>

      <note>
	<para>Egyes internet-szolgáltatók
	  blokkolják az alacsonyabb portokat, ezáltal az
	  NTP nem használható, mivel a válaszok nem
	  fogják elérni a gépünket.</para>
      </note>
    </sect2>

    <sect2>
      <title>További olvasnivalók</title>

      <para>Az NTP szerver dokumentációja HTML
	formátumban a <filename>/usr/share/doc/ntp/</filename>
	könyvtárban található.</para>
    </sect2>
  </sect1>

  <sect1 id="network-syslogd">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Készítette: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Távoli gépek naplózása
      <command>syslogd</command> használatával</title>

    <para>A rendszernaplókkal kapcsolatos mûveletek
      egyaránt fontosak a biztonság és a
      karbantartás szempontjából.  Ha közepes
      vagy nagyobb méretû, esetleg
      különbözõ típusú
      hálózatokban adminisztrálunk több
      gépet, akkor könnyen
      átláthatatlanná válhat a naplók
      rendszeres felügyelete.  Ilyen helyzetekben a távoli
      naplózás beállításával
      az egész folyamatot sokkal kényelmesebbé
      tehetjük.</para>

    <para>Némileg képesek vagyunk enyhíteni a
      naplóállományok kezelésének
      terhét, ha egyetlen központi szerverre
      küldjük át az adatokat.  Ekkor a &os;
      alaprendszerében megtalálható
      alapeszközökkel, mint például a
      &man.syslogd.8; vagy a &man.newsyslog.8;
      felhasználásával egyetlen helyen be tudjuk
      állítani a naplók
      összegyûjtését,
      összefésülését és
      cseréjét.  A most következõ példa
      konfigurációban az <hostid>A</hostid> gép, a
      <hostid role="fqdn">naploszerver.minta.com</hostid> fogja
      gyûjteni a helyi hálózatról
      érkezõ naplóinformációkat.  A
      <hostid>B</hostid> gép, a <hostid
	role="fqdn">naplokliens.minta.com</hostid> pedig a szervernek
      küldi a naplózandó adatokat.  Éles
      környezetben mind a két gépnek rendelkeznie
      kell megfelelõ <acronym>DNS</acronym> bejegyzésekkel,
      vagy legalább szerepelniük kell egymás
      <filename>/etc/hosts</filename> állományaiban.  Ha
      ezt elmulasztjuk, a szerver nem lesz hajlandó adatokat
      fogadni.</para>

    <sect2>
      <title>A naplószerver
	beállítása</title>

      <para>A naplószerverek olyan gépek, amelyeket
	úgy állítottunk be, hogy
	naplózási információkat tudjanak
	fogadni távoli
	számítógépekrõl.  A
	legtöbb esetben így egyszerûsíteni
	tudunk a konfiguráción, vagy olykor
	egyszerûen csak hasznos, ha ezt a megoldást
	alkalmazzuk.  Függetlenül attól, hogy
	miért használjuk, a
	továbblépés elõtt néhány
	elõkészületet meg kell tennünk.</para>

      <para>Egy rendesen beállított naplószervernek
	legalább a következõ követelményeknek
	kell eleget tennie:</para>

      <itemizedlist>
	<listitem>
	  <para>az 514-es <acronym>UDP</acronym> portot
	    engedélyezni kell mind a kliensen, mind pedig a
	    szerveren futó tûzfal
	    szabályrendszerében;</para>
	</listitem>

	<listitem>
	  <para>a &man.syslogd.8; képes legyen a távoli
	    kliens gépekrõl érkezõ üzeneteket
	    fogadni;</para>
	</listitem>

	<listitem>
	  <para>a &man.syslogd.8; szervernek és az összes
	    kliensnek rendelkeznie kell érvényes
	    <acronym>DNS</acronym> (közvetlen és inverz)
	    bejegyzésekkel vagy szerepelnie kell az
	    <filename>/etc/hosts</filename>
	    állományban.</para>
	</listitem>
      </itemizedlist>

      <para>A naplószerver
	beállításához mindegyik klienst fel
	kell vennünk az <filename>/etc/syslog.conf</filename>
	állományba, valamint meg kell adnunk a
	megfelelõ funkciót (facility):</para>

      <programlisting>+naplokliens.minta.com
*.*     /var/log/naplokliens.log</programlisting>

      <note>
	<para>A &man.syslog.conf.5; man oldalán
	  megtalálhatjuk a különbözõ
	  támogatott és elérhetõ
	  <emphasis>funkciókat</emphasis>.</para>
      </note>

      <para>Miután beállítottuk, az összes
	adott funkcióhoz tartozó üzenet az elõbb
	megadott állományba
	(<filename>/var/log/naplokliens.log</filename>) fog
	kerülni.</para>

      <para>A szerveren továbbá meg kell adnunk a
	következõ sort az <filename>/etc/rc.conf</filename>
	állományban:</para>

      <programlisting>syslogd_enable="YES"
syslogd_flags="-a naplokliens.minta.com -vv"</programlisting>

      <para>Az elsõ sorral engedélyezzük a
	<command>syslogd</command> elindítását a
	rendszerindítás során, majd a
	második sorral engedélyezzük, hogy a kliens
	naplózni tudjon a szerverre.  Itt még
	látható a <option>-vv</option> opció,
	amellyel a naplózott üzenetek
	részletességét tudjuk növelni.  Ennek
	nagyon fontos a szerepe a naplózási
	funkciók behangolásakor, mivel így a
	rendszergazdák pontosan láthatják milyen
	típusú üzenetek milyen funkcióval
	kerültek rögzítésre a
	naplóban.</para>

      <para>Befejezésképpen hozzuk létre a
	naplóállományt.  Teljesen mindegy, hogy erre
	milyen megoldást alkalmazunk, például a
	&man.touch.1; remekül megfelel:</para>

      <screen>&prompt.root; <userinput>touch /var/log/naplokliens.log</userinput></screen>

      <para>Ezután indítsuk újra és
	ellenõrizzük a <command>syslogd</command>
	démont:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput>
&prompt.root; <userinput>pgrep syslog</userinput></screen>

      <para>Ha válaszul megkapjuk a futó démon
	azonosítóját, akkor sikerült
	újraindítanunk, elkezdhetjük a kliens
	beállítását.  Ha valamiért
	nem indult volna újra a szerver, az
	<filename>/var/log/messages</filename>
	állományból próbáljuk meg
	kideríteni az okát.</para>
    </sect2>

    <sect2>
      <title>A naplókliens
	beállítása</title>

      <para>A naplókliens az a gép, amely egy helyi
	naplópéldány karbantartása mellett
	továbbküldni a naplózandó
	információkat egy naplószervernek.</para>

      <para>Hasonlóan a naplószerverekhez, a klienseknek
	is teljesítenie bizonyos alapvetõ
	elvárásokat:</para>

      <itemizedlist>
	<listitem>
	  <para>a &man.syslogd.8; démon küldjön
	    bizonyos típusú üzeneteket a
	    naplószervernek, amely ezeket pedig képes
	    legyen fogadni;</para>
	</listitem>

	<listitem>
	  <para>a hozzá tartozó tûzfal engedje
	    át a forgalmat az 514-es <acronym>UDP</acronym>
	    porton;</para>
	</listitem>

	<listitem>
	  <para>rendelkezzen mind közvetlen, mind pedig inverz
	    <acronym>DNS</acronym> bejegyzéssel, vagy
	    szerepeljenek az <filename>/etc/hosts</filename>
	    állományban.</para>
	</listitem>
      </itemizedlist>

      <para>A kliens beállítása sokkal
	egyszerûbb a szerverhez képest.  A kliensen adjuk
	hozzá a következõ sorokat az
	<filename>/etc/rc.conf</filename>
	állományhoz:</para>

      <programlisting>syslogd_enabled="YES"
syslogd_flags="-s -vv"</programlisting>

      <para>A szerver beállításaihoz
	hasonlóan itt is engedélyezzük a
	<command>syslogd</command> démont és
	megnöveljük a naplózott üzenetek
	részletességét.  A <option>-s</option>
	kapcsolóval pedig megakadályozzuk, hogy a kliens
	más gépekrõl is hajlandó legyen
	naplóüzeneteket elfogadni.</para>

      <para>A funkciók a rendszernek azon részét
	írják le, amelyhez létrejön az adott
	üzenet.  Tehát például az
	<literal>ftp</literal> és <literal>ipfw</literal>
	egyaránt ilyen funkciók.  Amikor keletkezik egy
	naplóüzenet valamelyikükhöz,
	általában megjelenik a nevük.  A
	funkciókhoz tartozik még egy prioritás vagy
	szint is, amellyel az adott üzenet
	fontosságát jelzik.  Ezek közül a
	leggyakoribb a <literal>warning</literal> (mint
	<quote>figyelmeztetés</quote>) és
	<literal>info</literal> (mint
	<quote>információ</quote>).  A
	használható funkciók és a
	hozzájuk tartozó prioritások teljes
	listáját a &man.syslog.3; man oldalán
	olvashatjuk.</para>

      <para>A naplószervert meg kell adnunk a kliens
	<filename>/etc/syslog.conf</filename>
	állományában.  Itt a <literal>@</literal>
	szimbólummal jelezzük, hogy az adatokat egy
	távoli szerverre szeretnénk
	továbbküldeni, valahogy így:</para>

      <programlisting>*.*               @naploszerver.minta.com</programlisting>

      <para>Ezután a beállítás
	érvényesítéséhez újra
	kell indítanunk a <command>syslogd</command>
	démont:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput></screen>

      <para>A &man.logger.1; használatával
	próbáljuk ki a kliensrõl a
	aplóüzenetek hálózaton keresztüli
	küldését, és küldjünk
	valamit a <command>syslogd</command> démonnak:</para>

      <screen>&prompt.root; <userinput>logger <replaceable>"Udvozlet a naplokliensrol"</replaceable></userinput></screen>

      <para>A parancs kiadása után az üzenetnek mind
	a kliens, mind pedig a szerver
	<filename>/var/log/messages</filename>
	állományában meg kell jelennie.</para>
    </sect2>

    <sect2>
      <title>Hibakeresés</title>

      <para>Elõfordulhat, hogy a naplószerver
	valamiért nem kapja meg rendesen az üzeneteket,
	ezért valamilyen módon meg kell keresnünk a
	hiba okát.  Ez több minden lehet, de
	általában két leggyakoribb ok valamilyen
	hálózati kapcsolódási vagy
	<acronym>DNS</acronym> beállítási hiba.
	Ezek teszteléséhez gondoskodjunk róla, hogy
	a gépek kölcsönösen elérhetõek
	egymásról az <filename>/etc/rc.conf</filename>
	állományban megadott hálózati
	nevük szerint.  Ha ezzel látszólag minden
	rendben van, akkor próbáljuk meg
	módosítani a <literal>syslogd_flags</literal>
	értékét az
	<filename>/etc/rc.conf</filename>
	állományban.</para>

      <para>A most következõ példában a
	<filename>/var/log/naplokliens.log</filename> teljesen
	üres, illetve a <filename>/var/log/messages</filename>
	állomány semmilyen hibára utaló okot
	nem tartalmaz.  A hibakereséshez még több
	információt a <literal>syslogd_flags</literal>
	átírásával tudunk
	kérni:</para>

      <programlisting>syslogd_flags="-d -a naploklien.minta.com -vv"</programlisting>

      <para>Természetesen ne felejtsük el
	újraindítani a szervert:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput></screen>

      <para>A démon újraindítása után
	közvetlenül az alábbiakhoz hasonló
	üzenetek árasztják el a
	képernyõt:</para>

      <screen>logmsg: pri 56, flags 4, from naploszerver.minta.com, msg syslogd: restart
syslogd: restarted
logmsg: pri 6, flags 4, from naploszerver.minta.com, msg syslogd: kernel boot file is /boot/kernel/kernel
Logging to FILE /var/log/messages
syslogd: kernel boot file is /boot/kernel/kernel
cvthname(192.168.1.10)
validate: dgram from IP 192.168.1.10, port 514, name naplokliens.minta.com;
rejected in rule 0 due to name mismatch.</screen>

      <para>A diagnosztikai üzeneteket végigolvasva
	nyilvánvaló válik, hogy azért dobja el
	az üzeneteket a szerver, mert nem megfelelõ a
	gép neve.  Miután átnézzük a
	beállításainkat, felfedezhetünk az
	<filename>/etc/rc.conf</filename> állományban egy
	apró hibát:</para>

      <programlisting>syslogd_flags="-d -a naploklien.minta.com -vv"</programlisting>

      <para>Láthatjuk, hogy ebben a sorban a
	<literal>naplokliens</literal> névnek kellene szerepelni,
	nem pedig a <literal>naploklien</literal> névnek.
	Miután elvégeztük a szükséges
	javításokat, indítsuk újra a
	szervert és vizsgáljuk meg az
	eredményt:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/syslogd restart</userinput>
logmsg: pri 56, flags 4, from naploszerver.minta.com, msg syslogd: restart
syslogd: restarted
logmsg: pri 6, flags 4, from naploszerver.minta.com, msg syslogd: kernel boot file is /boot/kernel/kernel
syslogd: kernel boot file is /boot/kernel/kernel
logmsg: pri 166, flags 17, from naploszerver.minta.com, msg Dec 10 20:55:02 &lt;syslog.err&gt; naploszerver.minta.com syslogd: exiting on signal 2
cvthname(192.168.1.10)
validate: dgram from IP 192.168.1.10, port 514, name naplokliens.minta.com;
accepted in rule 0.
logmsg: pri 15, flags 0, from naplokliens.minta.com, msg Dec 11 02:01:28 pgj: Masodik teszt uzenet
Logging to FILE /var/log/naplokliens.log
Logging to FILE /var/log/messages</screen>

      <para>Itt már minden üzenet rendben megérkezett
	és a megfelelõ állományokba
	került (a <filename>/var/log/messages</filename> a
	kliensen, és a
	<filename>/var/log/naplokliens.log</filename> a
	szerveren)).</para>
    </sect2>

    <sect2>
      <title>Biztonsági megfontolások</title>

      <para>Mint minden hálózati
	szolgáltatás esetén, ilyenkor is figyelembe
	kell vennünk bizonyos biztonsági
	megfontolásokat a tényleges
	konfiguráció kiépítése
	elõtt.  Olykor elõfordulhat, hogy a naplók
	különbözõ kényes
	információkat tartalmaznak, mint
	például a helyi rendszeren futó
	szolgáltatások nevei, felhasználói
	nevek vagy egyéb konfigurációs adatok.  A
	kliens és a szerver között
	hálózaton utazó adatok viszont se nem
	titkosítottak, se nem jelszóval védettek.
	Ha titkosítást szeretnénk használni,
	akkor javasoljuk például a <filename
	  role="package">security/stunnel</filename> portot, amellyel egy
	titkosított tunnelen keresztül tudunk adatokat
	küldeni a hálózaton.</para>

      <para>A helyi rendszer biztonságának
	szavatolása is fontos lehet.  A naplók sem a
	használat során, sem pedig a
	lecserélésük után nem kerülnek
	titkosításra.  Emiatt a helyi rendszerhez
	hozzáférõ felhasználók
	kedvükre nyerhetnek ki belõlük a
	rendszerünket érintõ
	konfigurációs információkat.
	Ezért ilyenkor nagyon fontos, hogy mindig a
	megfelelõ engedélyeket állítsuk be a
	naplókra.  A &man.newsyslog.8; segédprogrammal be
	tudjuk állítani a frissen létrehozott
	és a lecserélt naplók engedélyeit.
	Tehát könnyen megakadályozhatjuk a helyi
	felhasználók
	kíváncsiskodását, ha itt a
	naplók engedélyeit például a
	<literal>600</literal> kóddal adjuk meg.</para>
    </sect2>
  </sect1>
</chapter>