path: root/hu_HU.ISO8859-2/books/handbook/config/chapter.sgml

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

     $FreeBSD$
-->

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

<chapter id="config-tuning" lang="hu">
  <chapterinfo>
    <authorgroup>
      <author>
	<firstname>Chern</firstname>
	<surname>Lee</surname>
	<contrib>Írta: </contrib>
      </author>
    </authorgroup>
    <authorgroup>
      <author>
	<firstname>Mike</firstname>
	<surname>Smith</surname>
	<contrib>Az alapjául szolgáló
	  bemutatást írta: </contrib>
      </author>
    </authorgroup>
    <authorgroup>
      <author>
	<firstname>Matt</firstname>
	<surname>Dillon</surname>
	<contrib>Valamint az alapját képzõ tuning(7)
	  oldalt írta: </contrib>
      </author>
    </authorgroup>
  </chapterinfo>

  <title>Beállítás és
    finomhangolás</title>

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

    <indexterm><primary>a rendszer
      beállítása</primary></indexterm>
    <indexterm><primary>a rendszer
      finomhangolása</primary></indexterm>

    <para>A &os; egyik fontos szempontja a rendszer megfelelõ
      beállítása, aminek
      segítségével elkerülhetjük a
      késõbbi frissítések során
      keletkezõ kellemetlenségeket.  Ez a fejezet a &os;
      beállítási folyamatából
      kíván minél többet bemutatni,
      köztük a &os; rendszerek finomhangolására
      szánt paramétereket.</para>

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

    <itemizedlist>
      <listitem>
	<para>hogyan dolgozzunk hatékonyan az
	  állományrendszerekkel és a
	  lapozóállományokkal;</para>
      </listitem>
      <listitem>
	<para>az <filename>rc.conf</filename>
	  beállításának alapjait és a
	  <filename class="directory">/usr/local/etc/rc.d</filename>
	  könyvtárban található
	  indítási rendszert;</para>
      </listitem>
      <listitem>
	<para>hogyan állítsunk be és
	  próbáljunk ki egy hálózati
	  kártyát;</para>
      </listitem>
      <listitem>
	<para>hogyan állítsunk be virtuális
	  címeket a hálózati
	  eszközeinken;</para>
      </listitem>
      <listitem>
	<para>hogyan használjuk az <filename
	    class="directory">/etc</filename> könyvtárban
	  megtalálható különféle
	  konfigurációs állományokat;</para>
      </listitem>
      <listitem>
	<para>hogyan hangoljuk a &os; mûködését
	  a <command>sysctl</command> változóinak
	  segítségével;</para>
      </listitem>
      <listitem>
	<para>hogyan hangoljuk a lemezek
	  teljesítményét és
	  módosítsuk a rendszermag
	  korlátozásait.</para>
      </listitem>
    </itemizedlist>

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

    <itemizedlist>
      <listitem>
	<para>a &unix; és a &os; alapjainak
	  megértése (<xref linkend="basics"/>);</para>
      </listitem>
      <listitem>
	<para>a rendszermag beállításához
	  és fordításához
	  kötõdõ alapok ismerete (<xref
	  linkend="kernelconfig"/>).</para>
      </listitem>
    </itemizedlist>
  </sect1>

  <sect1 id="configtuning-initial">
    <title>Kezdeti beállítások</title>

    <sect2>
      <title>A partíciók kiosztása</title>

      <indexterm><primary>partíciókiosztás</primary></indexterm>
      <indexterm><primary><filename class="directory">/etc</filename></primary></indexterm>
      <indexterm><primary><filename class="directory">/var</filename></primary></indexterm>
      <indexterm><primary><filename class="directory">/usr</filename></primary></indexterm>

      <sect3>
	<title>Alappartíciók</title>

	<para>Amikor a &man.bsdlabel.8; vagy a &man.sysinstall.8;
	  segítségével
	  állományrendszereket telepítünk, nem
	  szabad figyelmen kívül hagynunk a tényt,
	  hogy a merevlemezes egységekben a külsõ
	  sávokból gyorsabban lehet
	  hozzáférni az adatokhoz, mint a
	  belsõkbõl.  Emiatt a kisebb és gyakrabban
	  elérni kívánt
	  állományrendszereket a meghajtó
	  lemezének külsejéhez közel kell
	  létrehozni, míg például a
	  <filename class="directory">/usr</filename>
	  partícióhoz hasonló nagyobb
	  partíciókat annak belsõ része
	  felé.  A partíciókat a
	  következõ sorrendben érdemes
	  kialakítani: gyökér
	  (rendszerindító),
	  lapozóállomány, <filename
	    class="directory">/var</filename> és <filename
	  class="directory">/usr</filename>.</para>

	<para>A <filename class="directory">/var</filename>
	  méretének tükröznie kell a
	  számítógép
	  szándékolt használatát.  A
	  <filename class="directory">/var</filename>
	  partíción foglalnak helyet a
	  felhasználók postaládái, a
	  naplóállományok és a
	  nyomtatási sorok.  A postaládák és
	  a naplóállományok egészen
	  váratlan mértékben is képesek
	  megnövekedni attól függõen, hogy mennyi
	  felhasználónk van a rendszerben és hogy
	  mekkora naplókat tartunk meg.  Itt a legtöbb
	  felhasználónak soha nem lesz
	  szüksége egy gigabyte-nál több
	  helyre.</para>

	<note>
	  <para>Bizonyos esetekben a <filename
	      class="directory">/var/tmp</filename>
	    könyvtárban azért ennél
	    több tárterület szükségeltetik.
	    Amikor a &man.pkg.add.1; segítségével
	    egy friss szoftvert telepítünk a
	    rendszerünkre, akkor a program a <filename
	    class="directory">/var/tmp</filename> könyvtárba
	    tömöríti ki a hozzá tartozó
	    csomag tartalmát.  Ezért a nagyobb
	    szoftvercsomagok, mint például a
	    <application>Firefox</application> vagy az
	    <application>OpenOffice</application> esetén gondok
	    merülhetnek fel, ha nem rendelkezünk elegendõ
	    szabad területtel a <filename
	      class="directory">/var/tmp</filename>
	    könyvtárban.</para>
	</note>

	<para>A <filename class="directory">/usr</filename>
	  partíció tartalmaz számos, a rendszer
	  mûködéséhez elengedhetetlenül
	  fontos állományt, többek közt a portok
	  gyûjteményét (ajánlott, lásd
	  &man.ports.7;) és a forráskódot
	  (választható).  A portok és az
	  alaprendszer forrásai telepítés
	  során választhatóak, de
	  telepítésük esetén akkor ezen a
	  partíción legalább két
	  gigabyte-nyi hely ajánlott.</para>

	<para>Vegyük figyelembe a tárbeli igényeket,
	  amikor megválasztjuk a partíciók
	  méretét.  Igen kellemetlen lehet, amikor
	  úgy futunk ki az egyik partíción a szabad
	  helybõl, hogy a másikat alig
	  használjuk.</para>

	<note>
	  <para>Egyes felhasználók szerint
	    elõfordulhat, hogy a &man.sysinstall.8;
	    <literal>Auto-defaults</literal> opciója a <filename
	      class="directory">/var</filename> és <filename
	      class="directory">/</filename> partíciók
	    méretét túl kicsire választja.
	    Particionáljunk okosan és
	    nagylelkûen!</para>
	</note>
      </sect3>

      <sect3 id="swap-design">
	<title>A lapozóállomány
	  partíciója</title>

	<indexterm><primary>a lapozóállomány
	  mérete</primary></indexterm>
	<indexterm><primary>a lapozóállomány
	  partíciója</primary></indexterm>

	<para>Általános szabály, hogy a
	  lapozóállományt tároló
	  partíció mérete legyen a rendszer fizikai
	  memóriájának (RAM) kétszerese.
	  Például, ha a
	  számítógépünk
	  128&nbsp;megabyte memóriával rendelkezik, akkor
	  a lapozóállomány méretének
	  256&nbsp;megabyte-nak kell lennie.  Az ennél kevesebb
	  memóriát maguknak tudó rendszerek
	  több lapozóállománnyal jobban
	  teljesítenek.  256&nbsp;megabyte-nál kevesebb
	  lapozóállományt semmiképpen sem
	  ajánlunk, és inkább a fizikai
	  memóriát érdemes
	  bõvítenünk.  A rendszermag virtuális
	  memóriát kezelõ lapozási
	  algoritmusait úgy állították be,
	  hogy abban az esetben teljesítsenek a legjobban, ha a
	  lapozóállomány mérete
	  legalább kétszerese a központi
	  memória mennyiségének.  A túl
	  kicsi lapozóállomány
	  beállítása rontja a virtuális
	  memória lapkeresésési rutinjának
	  hatékonyságát és a memória
	  bõvítése esetén még
	  további gondokat is okozhat.</para>

	<para>A több SCSI-lemezzel (vagy a
	  különbözõ vezérlõkre
	  csatlakoztatott több IDE-lemezzel) bíró
	  nagyobb rendszerek esetében érdemes minden egyes
	  (de legfeljebb négy) meghajtóra
	  beállítani lapozóállományt.
	  A lapozóállományoknak közel azonos
	  méretûnek kell lenniük.  A rendszermag
	  tetszõleges méretûeket képes kezelni,
	  azonban a belsejében alkalmazott adatszerkezetek a
	  legnagyobb lapozóállomány
	  méretének négyszereséig
	  képesek növekedni.  Ha a
	  lapozóállományokat
	  nagyjából ugyanazon a méreten tartjuk,
	  akkor a rendszermag képes lesz a lapozáshoz
	  felhasznált területet optimálisan elosztani
	  a lemezek között.  A nagyobb
	  lapozóállományok használata
	  még akkor is jól jön, ha nem is
	  használjuk annyira.  Segítségével
	  sokkal könnyebben talpra tudunk állni egy
	  elszabadult program tombolásából,
	  és nem kell rögtön
	  újraindítanunk a rendszert.</para>
      </sect3>

      <sect3>
	<title>Miért particionáljunk?</title>

	<para>Egyes felhasználók úgy
	  gondolják, hogy egyetlen nagyobb méretû
	  partíció mindenre megfelel, ám ez a
	  gondolat több okból is helytelennek
	  tekinthetõ.  Elõször is, minden egyes
	  partíciónak eltér a
	  mûködési jellemzõje, és
	  különválasztásukkal
	  lehetõvé válik az
	  állományrendszerek megfelelõ
	  behangolása.  Például a
	  rendszerindításhoz használt és a
	  <filename class="directory">/usr</filename>
	  partíciókat többségében csak
	  olvasásra használják, és nem sokat
	  írnak rájuk.  Eközben a <filename
	    class="directory">/var</filename> és <filename
	    class="directory">/var/tmp</filename>
	  könyvtárakban zajlik az írások
	  és olvasások túlnyomó
	  része.</para>

	<para>A rendszer megfelelõ felosztásával a
	  kisebb, intenzívebben írt
	  partíciókon megjelenõ
	  töredezettség nem szivárog át a
	  többségében csak olvasásra
	  használt partíciókra.  Ha a sokat
	  írt partíciókat közel tartjuk a
	  lemez széléhez, akkor azokon a
	  partíciókon növekszik az I/O
	  teljesítménye, ahol az a leggyakrabban
	  megjelenik.  Mivel mostanság az I/O
	  teljesítményére inkább a nagyobb
	  partíciók esetén van szükség,
	  azzal nem érünk el ebben különösebb
	  mértékû növekedést, ha a
	  <filename class="directory">/var</filename>
	  partíciót a lemez szélére toljuk.
	  Befejezésképpen hozzátesszük, hogy
	  ennek vannak biztonsági megfontolásai is.  Egy
	  kisebb és takarosabb rendszerindító
	  partíció, ami többnyire
	  írásvédett, nagyobb eséllyel
	  él túl egy csúfos
	  rendszerösszeomlást.</para>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="configtuning-core-configuration">
    <title>A mag beállítása</title>

    <indexterm>
      <primary>rc állományok</primary>
      <secondary><filename>rc.conf</filename></secondary>
    </indexterm>

    <para>A rendszer beállításaira vonatkozó
      információk központi lelõhelye az
      <filename>/etc/rc.conf</filename> állomány.  Ez az
      állomány tartalmazza a
      beállításokra vonatkozó adatok
      széles körét, amelyet elsõsorban a
      rendszer indulása során a rendszer
      beállítására használnak.  Erre
      a neve is utal: ez az <filename>rc*</filename>
      állományok konfigurációs
      állománya.</para>

    <para>A rendszergazda az <filename>rc.conf</filename>
      állományban tudja felülbírálni az
      <filename>/etc/defaults/rc.conf</filename>
      állományban szereplõ alapértelmezett
      beállításokat.  Az
      alapértelmezéseket tartalmazó
      állományt nem szabad közvetlenül
      átmásolni az <filename
	class="directory">/etc</filename> könyvtárba, hiszen
      alapértelmezett értékeket tartalmaz, nem
      pedig mintákat.  Minden rendszerfüggõ
      beállítást magában az
      <filename>rc.conf</filename> állományban kell
      elvégezni.</para>

    <para>Számos stratégia létezik a tömegesen
      adminisztrált
      számítógépeknél a
      közös és rendszerfüggõ
      beállítások
      különválasztására, ezáltal a
      karbantartási költségek
      csökkentésére.  A közös
      beállításokat ajánlott egy
      másik helyre, például az
      <filename>/etc/rc.conf.site</filename> állományba
      rakni, majd hivatkozni erre a kizárólag csak
      rendszerfüggõ információkat
      tartalmazó <filename>/etc/rc.conf</filename>
      állományból.</para>

    <para>Mivel az <filename>rc.conf</filename> állományt
      az &man.sh.1; dolgozza fel, ezt elég könnyen el tudjuk
      érni.  Például:</para>

    <itemizedlist>
      <listitem><para>rc.conf:</para>
<programlisting>	. /etc/rc.conf.site
	hostname="node15.example.com"
	network_interfaces="fxp0 lo0"
	ifconfig_fxp0="inet 10.1.1.1"</programlisting></listitem>
      <listitem><para>rc.conf.site:</para>
<programlisting>	defaultrouter="10.1.1.254"
	saver="daemon"
	blanktime="100"</programlisting></listitem>
    </itemizedlist>

    <para>Az <filename>rc.conf.site</filename> állomány
      ezt követõen az <command>rsync</command> parancs
      használatával már
      szétszórható a rendszerben, miközben az
      <filename>rc.conf</filename> állomány
      mindenkinél egyedi marad.</para>

    <para>Ha a rendszert a &man.sysinstall.8; vagy a <command>make
      world</command> használatával
      frissítjük, akkor az <filename>rc.conf</filename>
      tartalma nem íródik felül, így a
      rendszer beállításairól
      szóló adatok nem vesznek el.</para>

  </sect1>

  <sect1 id="configtuning-appconfig">
    <title>Az alkalmazások
      beállítása</title>

    <para>A telepített alkalmazások
      általában saját konfigurációs
      állományokkal, azok pedig saját
      formátummal stb.  rendelkeznek.  Fontos, hogy ezeket az
      állományokat az alaprendszertõl
      elkülönítve tároljuk, ezáltal a
      csomagkezelõ eszközök könnyen rájuk
      tudjanak találni és dolgozni velük.</para>

    <indexterm><primary>/usr/local/etc</primary></indexterm>

    <para>Ezeket az állományokat általában a
      <filename class="directory">/usr/local/etc</filename>
      könyvtárban találjuk meg.  Amennyiben egy
      alkalmazáshoz több konfigurációs
      állomány is tartozik, akkor ahhoz ezen belül
      egy külön alkönyvtár jön
      létre.</para>

    <para>Normális esetben, amikor egy portot vagy csomagot
      telepítünk, minta konfigurációs
      állományokat is kapunk.  Ezek nevében
      többnyire a <filename>.default</filename> utótag
      szerepel.  Ha még nincs konfigurációs
      állomány az adott alkalmazáshoz, akkor a
      <filename>.default</filename> jelzésû
      állományokból ez
      létrehozható.</para>

    <para>Példaképpen most tekintsük a <filename
	class="directory">/usr/local/etc/apache</filename>
      könyvtár tartalmát:</para>

<literallayout class="monospaced">-rw-r--r--  1 root  wheel   2184 May 20  1998 access.conf
-rw-r--r--  1 root  wheel   2184 May 20  1998 access.conf.default
-rw-r--r--  1 root  wheel   9555 May 20  1998 httpd.conf
-rw-r--r--  1 root  wheel   9555 May 20  1998 httpd.conf.default
-rw-r--r--  1 root  wheel  12205 May 20  1998 magic
-rw-r--r--  1 root  wheel  12205 May 20  1998 magic.default
-rw-r--r--  1 root  wheel   2700 May 20  1998 mime.types
-rw-r--r--  1 root  wheel   2700 May 20  1998 mime.types.default
-rw-r--r--  1 root  wheel   7980 May 20  1998 srm.conf
-rw-r--r--  1 root  wheel   7933 May 20  1998 srm.conf.default</literallayout>

    <para>Az állományok mérete jól mutatja,
      hogy csak az <filename>srm.conf</filename> változott meg.
      Az <application>Apache</application> késõbbi
      frissítései ezt az állományt nem
      fogják felülírni.</para>
  </sect1>

  <sect1 id="configtuning-starting-services">
    <sect1info>
      <authorgroup>
        <author>
	<firstname>Tom</firstname>
	<surname>Rhodes</surname>
	<contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Szolgáltatások indítása</title>

    <indexterm><primary>szolgáltatások</primary></indexterm>

    <para>A felhasználók közül sokan
      választják a &os;
      Portgyûjteményében található
      külsõ szoftverek telepítését.  A
      telepített szoftvert ilyenkor gyakran úgy kell
      beállítani, hogy a rendszer
      indulásával együtt induljon.  Az olyan
      szolgáltatások, mint például a
      <filename role="package">mail/postfix</filename> vagy a <filename
	role="package">www/apache13</filename> csupán két
      olyan szoftvercsomag, amelyet a rendszerrel együtt kell
      elindítani.  Ebben a szakaszban a külsõ
      szoftverek indítására használatos
      eljárásokkal foglalkozunk.</para>

    <para>A &os;-ben megjelenõ legtöbb
      szolgáltatás, mint például a
      &man.cron.8;, a rendszerindító szkripteken
      keresztül kel életre.  Habár ezek a szkriptek a
      &os; egyes verziói vagy az egyes gyártók
      esetén különbözhetnek, azonban az
      mindegyikükben közös, hogy az
      elindításukra vonatkozó
      beállítások egyszerû
      indítószkriptekkel adhatóak meg.</para>

    <sect2>
      <title>Az alkalmazások részletesebb
	beállítása</title>

      <para>Most miután a &os; rendelkezik egy
	<filename>rc.d</filename> könyvtárral, az
	alkalmazások indításának
	beállítása is könnyebbé
	és ügyesebbé vált.  Az <link
	linkend="configtuning-rcd">rc.d</link>
	mûködésérõl szóló
	szakaszban megismert kulcsszavak
	segítségével az alkalmazások
	mostantól kezdve a többi szolgáltatás,
	például a <acronym>DNS</acronym> után
	indulnak el, és az <filename>rc.conf</filename>
	állományon keresztül a szkriptekbe
	huzalozottak helyett most már tetszõleges
	paramétereket is átadhatunk stb.  Egy
	egyszerû szkript ehhez hasonlóan néz
	ki:</para>

      <programlisting>#!/bin/sh
#
# PROVIDE: utility
# REQUIRE: DAEMON
# KEYWORD: shutdown

. /etc/rc.subr

name=utility
rcvar=utility_enable

command="/usr/local/sbin/utility"

load_rc_config $name

#
# NE VÁLTOZTASSUK MEG AZ ITT LÉVõ ALAPÉRTELMEZÉSEKET,
# INKÁBB AZ /etc/rc.conf ÁLLOMÁNYBAN ÁLLÍTSUK BE EZEKET
#
utility_enable=${utility_enable-"NO"}
pidfile=${utility_pidfile-"/var/run/utility.pid"}

run_rc_command "$1"</programlisting>

      <para>Ez a szkript gondoskodik arról, hogy a
	<application>utility</application> nevû alkalmazás a
	<literal>DAEMON</literal> szolgáltatás után
	induljon el.  Emellett még felkínál egy
	módszert a <acronym>PID</acronym> avagy futó
	programok azonosítójának
	beállítására és
	nyomonkövetésére is.</para>

      <para>Ezt követõen az <filename>/etc/rc.conf</filename>
	állományból az alkalmazás
	elindítható az alábbi sor
	hozzáadásával:</para>

      <programlisting>utility_enable="YES"</programlisting>

      <para>Ez a módszer megkönnyíti a parancssorban
	átadott paraméterek
	módosítását, az
	<filename>/etc/rc.subr</filename> állományban
	szereplõ alapértelmezett függvények
	használatát, az &man.rcorder.8;
	segédprogrammal szembeni kompatibilitást és
	az <filename>rc.conf</filename> állomány
	könnyebb beállítását.</para>
    </sect2>

    <sect2>
      <title>Szolgáltatások indítása
	szolgáltatásokkal</title>

      <para>Más szolgáltatások, mint
	például a <acronym>POP</acronym>3 vagy
	<acronym>IMAP</acronym> szerverek démonai stb.  az
	&man.inetd.8; segítségével
	indíthatóak el.  Ez a
	Portgyûjteménybõl telepített
	szolgáltatások esetén magával vonja
	az adott segédprogram felvételét vagy a
	hozzá tartozó sor
	engedélyezését az
	<filename>/etc/inetd.conf</filename> állományban.
	Az <application>inetd</application>
	mûködésével és annak
	beállításával
	mélyrehatóbban az <link
	linkend="network-inetd">inetd</link> szakasza
	foglalkozik.</para>

      <para>A legtöbb esetben a &man.cron.8; démon
	használata kézenfekvõ a rendszerszintû
	szolgáltatások elindításában.
	Ez a megközelítés számos elõnyt
	tartogat, mivel a <command>cron</command> ezeket a programokat a
	felhasználó <filename>crontab</filename>
	állománya alapján futtatja.  Ezzel a mezei
	felhasználók számára is
	lehetõvé válik, hogy elindítsanak
	és karbantartsanak alkalmazásokat.</para>

      <para>A <command>cron</command> segédprogramnak van egy
	olyan speciális lehetõsége, hogy az idõ
	helyett a <literal>@reboot</literal> értéket
	adhatjuk meg.  Ennek hatására a feladat a
	&man.cron.8; indításával együtt fut
	le, tehát megszokott esetben a rendszer
	indítása során.</para>
    </sect2>
  </sect1>

  <sect1 id="configtuning-cron">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>A <command>cron</command> segédprogram
      beállítása</title>

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

    <para>A &man.cron.8; a &os; egyik leghasznosabb
      segédprogramja.  A <command>cron</command>
      segédprogram a háttérben fut és
      folyamatosan figyeli az <filename>/etc/crontab</filename>
      állományt.  Emellett a <command>cron</command>
      új <filename>crontab</filename> állományok
      után kutatva folyamatosan ellenõrzi a
      <filename class="directory">/var/cron/tabs</filename>
      könyvtárat.  Ezek a <filename>crontab</filename>
      állományok olyan feladatokról tárolnak
      adatokat, amelyeket a <command>cron</command> programnak egy adott
      pillanatban el kell végeznie.</para>

    <para>A <command>cron</command> a konfigurációs
      állományok két külön
      fajtáját, a rendszer- és
      felhasználói crontabokat használja.  A
      két típus között levõ egyetlen
      különbség a hatodik mezõben
      található.  A rendszerszintû crontabok
      esetében a hatodik mezõ annak a
      felhasználónak a nevét tartalmazza, amivel a
      program fut.  Ezzel a rendszer szintjén
      mûködõ crontaboknak megadatott az a
      képesség, hogy tetszõleges
      felhasználó nevében futtassanak programokat.
      A felhasználók crontabjaiban a hatodik mezõ a
      futtatandó parancsot tartalmazza, és ilyenkor az
      összes parancs a crontabot létrehozó
      felhasználó nevében hajtódik
      végre.  Ez utóbbi egy fontos biztonsági
      jellemzõ.</para>

    <note>
      <para>A felhasználói crontabok lehetõvé
	teszik az egyes felhasználók
	számára, hogy a <username>root</username>
	felhasználó jogosultságai
	nélkül képesek legyenek feladatokat
	ütemezni, ugyanis a felhasználóhoz
	tartozó crontabban szereplõ parancsok mindegyike a
	tulajdonosának engedélyeivel fut.</para>

      <para>Az átlagos felhasználókhoz
	hasonlóan a <username>root</username>
	felhasználónak is lehet crontabja, ami nem
	ugyanaz, mint az <filename>/etc/crontab</filename> (a rendszer
	saját crontab állománya).  De mivel a
	rendszernek külön crontabja van, ezért a
	<username>root</username> felhasználónak nem kell
	külön crontabot létrehozni.</para>
    </note>

    <para>Vessünk egy pillanatást az
      <filename>/etc/crontab</filename> (a rendszer crontabjának)
      tartalmára:</para>

    <programlisting># /etc/crontab - a root crontabja &os; alatt
#
# &dollar;&os;: src/etc/crontab,v 1.32 2002/11/22 16:13:39 tom Exp &dollar;
# <co id="co-comments"/>
#
SHELL=/bin/sh
PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin <co id="co-env"/>
HOME=/var/log
#
#
#minute	hour	day	month	wday	who	command <co id="co-field-descr"/>
#
#
*/5	*	*	*	*	root	/usr/libexec/atrun <co id="co-main"/>
</programlisting>

    <calloutlist>
      <callout arearefs="co-comments">
	<para>A &os; legtöbb konfigurációs
	  állományához hasonlóan itt is a
	  <literal>#</literal> jelöli a megjegyzéseket.  Az
	  ilyen megjegyzések remekül
	  használhatóak annak feljegyzésére,
	  hogy mit és miért akarunk futtatni.  A
	  megjegyzések azonban nem szerepelhetnek a paranccsal
	  egy sorban, mivel máskülönben a parancs
	  részeként kerülnek
	  értelmezésre.  Tehát mindig új
	  sorba kell raknunk ezeket.  Az üres sorokat a program nem
	  veszi figyelembe.</para>
      </callout>

      <callout arearefs="co-env">
	<para>Elõször is meg kell adnunk egy környezetet.
	  Az egyenlõség (<literal>=</literal>) karakter
	  használatos a környezeti
	  beállítások
	  meghatározására, ahogy mindezt az itteni
	  példában is tapasztalhatjuk a
	  <envar>SHELL</envar>, <envar>PATH</envar> és
	  <envar>HOME</envar> értékek esetében.  Ha
	  nem adunk meg mást, akkor a <command>cron</command> az
	  alapértelmezés szerinti <command>sh</command>
	  parancsértelmezõt használja.  Ha nem adjuk
	  meg a <envar>PATH</envar> változó
	  értékét, akkor minden
	  állományra abszolút elérési
	  úttal kell hivatkoznunk, mivel ennek nincs
	  alapértelmezett értéke.  Ha nem
	  definiáljuk a <envar>HOME</envar> változó
	  értékét, akkor a <command>cron</command>
	  a parancshoz tartozó felhasználó
	  könyvtárából fog dolgozni.</para>
      </callout>

      <callout arearefs="co-field-descr">
	<para>Ez a sor írja le a megadható hét
	  mezõt.  Az itt szereplõ értékek a
	  <literal>minute</literal> (perc), <literal>hour</literal>
	  (óra), <literal>mday</literal> (a hónap napja),
	  <literal>month</literal> (hónap),
	  <literal>wday</literal> (a hét napja),
	  <literal>who</literal> (ki) és
	  <literal>command</literal> (mit).  A mezõk szinte
	  maguktól értetõdnek.  A
	  <literal>minute</literal> egy órán belül
	  adja meg azokat a perceket, amikor az adott parancsot le kell
	  futtatni.  A <literal>hour</literal> hasonló a
	  <literal>minute</literal> beállításhoz,
	  csak az itt szereplõ értékét
	  órákban kell értelmezni.  Az
	  <literal>mday</literal> a hónap napjaiban
	  számol.  A <literal>month</literal> hasonló a
	  <literal>minute</literal> és <literal>hour</literal>
	  opciókhoz, de ez hónapot jelöl.  A
	  <literal>wday</literal> a hét egy napját jelzi.
	  Ezeknek a mezõknek numerikus, valamint a
	  huszonnégy órás
	  idõformátumnak megfelelõ
	  értékeket kell tartalmazniuk.  A
	  <literal>who</literal> mezõ, a többiektõl
	  eltérõ módon, csak az
	  <filename>/etc/crontab</filename> állományban
	  jelenik meg.  Ez a mezõ adja meg, hogy a parancsot milyen
	  felhasználóval kell futtatni.  Ez az
	  opció nem jelenik meg a felhasználók
	  saját <filename>crontab</filename>
	  állományainak telepítésekor.  A
	  sor végén láthatjuk még a
	  <literal>command</literal> oszlopot is.  Ez az utolsó
	  mezõ, és ide kerül a
	  végrehajtandó parancs.</para>
      </callout>

      <callout arearefs="co-main">
	<para>Ez az utolsó sor a fentebb tárgyalt
	  értékeket határozza meg.
	  Észrevehetjük, hogy a sor egy
	  <literal>*/5</literal> alakú felírással
	  kezdõdik, amelyet további <literal>*</literal>
	  karakterek követnek.  A <literal>*</literal> karakterek
	  jelentése <quote>elsõ-utolsó</quote>, ami
	  arra utal, hogy <emphasis>mindig</emphasis>.  Ennek
	  megfelelõen úgy értelmezhetjük ezt a
	  sort, hogy a <username>root</username>
	  felhasználóval le kell futtatni az
	  <command>atrun</command> parancsot minden ötödik
	  percben, függetlenül attól, hogy milyen nap
	  vagy hónap van.  Az <command>atrun</command>
	  parancsról részletesebban az &man.atrun.8; man
	  oldalán kapunk
	  felvilágosítást.</para>

	<para>Az itt szereplõ parancsoknak tetszõleges
	  mennyiségû paraméter adható
	  át, azonban a több soron keresztül
	  átívelõ parancsok
	  tördelését a sor végén a
	  <quote>\</quote> karakterrel kell jelezni.</para>
      </callout>
    </calloutlist>

    <para>Ez mindegyik <filename>crontab</filename>
      állomány alapbeállítása,
      habár ettõl általában egy dologban
      eltérnek.  A hatodik mezõ, ahol a
      felhasználót adtuk meg, csak a rendszer
      <filename>/etc/crontab</filename>
      állományában jelenik meg.  Ez a mezõ a
      felhasználók <filename>crontab</filename>
      állományaiból kimarad.</para>

    <sect2 id="configtuning-installcrontab">
      <title>Egy crontab telepítése</title>

      <important>
	<para>Nem kötelezõ az itt ismertetésre
	  kerülõ módon szerkeszteni vagy
	  telepíteni a rendszer crontabját.
	  Egyszerûen nyissuk meg a kedvenc
	  szövegszerkesztõnkkel, és a
	  <command>cron</command> segédprogram majd
	  észreveszi, hogy az állomány
	  megváltozott, majd ennek megfelelõen neki is
	  lát a módosított változat
	  használatának.  Errõl <ulink
	  url="&url.books.faq.en;/admin.html#ROOT-NOT-FOUND-CRON-ERRORS">a
	  GYIK-ban (angolul)</ulink> többet is megtudhatunk.</para>
      </important>

      <para>Egy frissen készített
	felhasználói <filename>crontab</filename>
	telepítéséhez elõször a kedvenc
	szövegszerkesztõnk segítségével
	létre kell hoznunk a megfelelõ
	formátumú állományt, majd
	használnunk a <command>crontab</command>
	segédprogramot.  Ennek általános
	alakja:</para>

      <screen>&prompt.user; <userinput>crontab <replaceable>crontab_állomány</replaceable></userinput></screen>

      <para>Ebben a példában a
      <filename><replaceable>crontab_állomány</replaceable></filename>
	a korábban létrehozott
	<filename>crontab</filename> neve lesz.</para>

      <para>Lehetõségünk van lekérdezni a
	telepített <filename>crontab</filename>
	állományokat: egyszerûen adjuk át a
	<option>-l</option> kapcsolót a
	<command>crontab</command> parancsnak, és
	nézzük meg, mit ad vissza.</para>

      <para>A <command>crontab -e</command> használata olyan
	felhasználók számára
	ajánlott, akik sablon alkalmazása
	nélkül szeretnének teljesen maguktól
	megírni egy crontab állományt.  Ennek
	hatására a kiválasztott
	szövegszerkesztõ egy üres állományt
	kap.  Miután ezt az állományt
	elmentettük, a <command>crontab</command> programmal
	magától telepítésre
	kerül.</para>

      <para>Ha a késõbbiekben törölni akarjuk a
	felhasználónkhoz tartozó
	<filename>crontab</filename> állományt, akkor erre
	a célra használjuk a <command>crontab</command>
	<option>-r</option> kapcsolóját.</para>
    </sect2>
  </sect1>

  <sect1 id="configtuning-rcd">
    <sect1info>
      <authorgroup>
	<author>
	 <firstname>Tom</firstname>
	 <surname>Rhodes</surname>
	 <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Az rc használata &os; alatt</title>

    <para>A rendszer indítására a &os; 2002-ben
      átvette a NetBSD <filename>rc.d</filename>
      rendszerét.  Ezt a felhasználók könnyen
      felismerhetik az <filename class="directory">/etc/rc.d</filename>
      könyvtárban található
      állományokról.  A legtöbbjük olyan
      alapvetõ szolgáltatás, amelyet a
      <option>start</option>, <option>stop</option> és
      <option>restart</option> paraméterekkel lehet
      vezérelni.  Például az &man.sshd.8; az
      alábbi paranccsal indítható
      újra:</para>

    <screen>&prompt.root; <userinput>/etc/rc.d/sshd restart</userinput></screen>

    <para>Ez az eljárás hasonló a többi
      szolgáltatás esetén is.  Természetesen
      ezek a szolgáltatások általában
      maguktól indulnak el a rendszer indítása
      során az &man.rc.conf.5; állományban
      megadottak szerint.  Például ha a rendszerünk
      indulásakor szeretnénk aktiválni a
      hálózati címfordítással
      foglalatoskodó démont, akkor csak adjuk hozzá
      az <filename>/etc/rc.conf</filename> állományhoz a
      következõ sort:</para>

    <programlisting>natd_enable="YES"</programlisting>

    <para>Amennyiben a <option>natd_enable="NO"</option> sor már
      szerepel benne, akkor egyszerûen írjuk át a
      <option>NO</option> értéket <option>YES</option>-re.
      Ezután az rc szkriptek a rendszer következõ
      indításakor a lentieknek megfelelõen
      automatikusan elindítják a hozzá
      tartozó szolgáltatásokat is.</para>

    <para>Mivel az <filename>rc.d</filename> rendszert elsõsorban
      arra használják, hogy szolgáltatásokat
      indítsanak el vagy állítsanak le az
      operációs rendszerrel együtt, a
      szabványos <option>start</option>, <option>stop</option>
      és <option>restart</option> paraméterek csak abban
      az esetben látják el a feladatukat, ha a nekik
      megfelelõ változókat beállítottuk
      az <filename>/etc/rc.conf</filename> állományban.
      Tehát például az <command>sshd
      restart</command> csak abban az esetben fog bármit is
      csinálni, ha az <filename>/etc/rc.conf</filename>
      állományban az <varname>sshd_enable</varname>
      változót a <option>YES</option>
      értékre állítottuk.  Ha az
      <filename>/etc/rc.conf</filename>
      beállításaitól függetlenül
      kívánunk egy szolgáltatásnak
      <option>start</option>, <option>stop</option> vagy
      <option>restart</option> parancsot adni, akkor elé kell
      tennünk egy <quote>one</quote> szót.
      Például ha az <command>sshd</command>
      szolgáltatás
      újraindításához az
      <filename>/etc/rc.conf</filename> tartalmát figyelmen
      kívül akarjuk hagyni, akkor ezt a parancsot kell
      kiadnunk:</para>

    <screen>&prompt.root; <userinput>/etc/rc.d/sshd onerestart</userinput></screen>

    <para>Könnyen ellenõrizni tudjuk, hogy az adott
      szolgáltatás az <filename>/etc/rc.conf</filename>
      részérõl engedélyezett-e, ha a neki
      megfelelõ <filename>rc.d</filename> szkriptnek megadjuk az
      <option>rcvar</option> paramétert.  Ennek
      segítségével például a
      rendszergazda így képes ellenõrizni, hogy az
      <command>sshd</command> szolgáltatást
      engedélyezi-e az <filename>/etc/rc.conf</filename>:</para>

    <screen>&prompt.root; <userinput>/etc/rc.d/sshd rcvar</userinput>
# sshd
$sshd_enable=YES</screen>

    <note>
      <para>A második sor (<literal># sshd</literal>) az
	<command>sshd</command> parancs kimenete, nem pedig a
	<username>root</username> parancssora.</para>
    </note>

    <para>A <option>status</option> paraméterrel
      kideríthetjük, hogy egy szolgáltatás
      aktív-e.  Ezzel például így tudjuk
      ellenõrizni az <command>sshd</command>
      szolgáltatás
      mûködését:</para>

    <screen>&prompt.root; <userinput>/etc/rc.d/sshd status</userinput>
sshd is running as pid 433.</screen>

    <para>Az üzenet:</para>

    <screen>Az sshd a 433-as azonosítóval fut.</screen>

    <para>Bizonyos esetekben a <option>reload</option> paraméter
      használatával lehetõségünk van a
      szolgáltatások
      újraindítására is.  Ilyenkor a
      rendszer megpróbál egy olyan jelzést
      küldeni a szolgáltatásnak, amivel a
      konfigurációs állományainak
      újraolvasását kéri.  A
      legtöbbször lényegében ez a
      <literal>SIGHUP</literal> jelzés
      kiküldését rejti magában.  Ez a
      lehetõség azonban nem mindegyik
      szolgáltatás esetén érhetõ
      el.</para>

    <para>Az <filename>rc.d</filename> rendszer nem csupán
      hálózati szolgáltatások esetén
      használatos, hanem nagyrészben
      hozzájárul a rendszer
      indításához is.  Erre vegyük
      példának a <filename>bgfsck</filename>
      állományt.  Amikor ez a szkript lefut, a
      következõ üzenetet jeleníti meg:</para>

    <screen>Starting background file system checks in 60 seconds.</screen>

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

    <screen>A háttérben 60 másodperc múlva megkezdõdik az állományrendszerek ellenõrzése.</screen>

    <para>Ennek megfelelõen tehát ezt az
      állományt az állományrendszerek
      háttérben folyó
      ellenõrzésére használják, ami
      pedig a rendszer indítása során fut
      le.</para>

    <para>Számos rendszerszolgáltatás
      igényel a mûködéséhez
      további szolgáltatásokat.
      Például a NIS és más egyéb
      távoli eljáráshíváson
      alapú szolgáltatások egészen addig nem
      képesek elindulni, amíg az
      <command>rpcbind</command> (portmapper)
      szolgáltatást el nem indítjuk.  Az ilyen
      jellegû gondok feloldására az
      indítószkriptek elején levõ
      megjegyzésekben található egy kevés
      metainformáció a szkript
      mûködéséhez szükséges elemekre
      (függõségeire) vonatkozóan.  A rendszer
      indítása közben az &man.rcorder.8; nevû
      program képes a megjegyzések közt ezeket az
      információkat feldolgozni és ebbõl
      megállapítani, hogy a függõségi
      viszonyok betartásával milyen sorrendben kell
      elindítani a rendszer által felkínált
      szolgáltatásokat.</para>

    <para>Ehhez a következõ kulcsszavakat kell megadni az
      egyes indító szkriptek elején (az
      &man.rc.subr.8; így tudja
      <quote>engedélyezni</quote> az indító
      szkriptet):</para>

    <itemizedlist>
      <listitem>
	<para><literal>PROVIDE</literal>:
	  segítségével megmondjuk, hogy ez az
	  állomány milyen szolgáltatásokat
	  nyújt.</para>
      </listitem>
    </itemizedlist>

    <para>A következõ kulcsszavak az egyes
      indítóállományok elején
      szerepelhetnek.  Nem kell feltétlenül
      használnunk ezeket, de velük az &man.rcorder.8;
      munkáját segíthetjük:</para>

    <itemizedlist>
      <listitem>
	<para><literal>REQUIRE</literal>: felsoroljuk azokat a
	  szolgáltatásokat, amelyek a
	  futásához kellenek.  Az állomány
	  tehát az itt megadott szolgáltatások
	  <emphasis>után</emphasis> fog lefutni.</para>
      </listitem>

      <listitem>
	<para><literal>BEFORE</literal>: felsoroljuk azokat a
	  szolgáltatásokat, amelyek
	  <emphasis>elõtt</emphasis> futtatni kell ezt az
	  állományt.</para>
      </listitem>
    </itemizedlist>

    <para>Az indító szkriptekben a kulcsszavak ügyes
      megválasztásával a rendszergazda nagyon
      finoman képes az indításkor
      végrehajtódó szkriptek sorrendjét
      szabályozni és a többi &unix; alapú
      operációs rendszerbõl ismert
      <quote>futtatási szintek</quote> használata
      nélkül vezérelni a rendszerben megjelenõ
      szolgáltatásokat.</para>

    <para>Az <filename>rc.d</filename> rendszerrõl bõvebben az
      &man.rc.8; és &man.rc.subr.8; man oldalakon olvashatunk.
      Ha szeretnénk saját <filename>rc.d</filename>
      szkripteket írni vagy javítani a már
      meglévõkön, akkor ez <ulink
      url="&url.articles.rc-scripting.en;">a cikk</ulink> (angolul)
      segítségünkre lehet.</para>
  </sect1>

  <sect1 id="config-network-setup">
    <sect1info>
      <authorgroup>
	<author>
	 <firstname>Marc</firstname>
	 <surname>Fonvieille</surname>
	 <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>A hálózati kártyák
      beállítása</title>

    <indexterm>
      <primary>hálózati kártyák</primary>
      <secondary>beállítása</secondary>
    </indexterm>

    <para>Manapság már el sem tudunk képzelni
      számítógépet hálózati
      csatlakozás nélkül.  A hálózati
      csatolókártyák hozzáadása
      és beállítása egy &os; rendszergazda
      mindennapos feladata.</para>

    <sect2>
      <title>A megfelelõ meghajtóprogram
	felderítése</title>

      <indexterm>
	<primary>hálózati kártyák</primary>
	<secondary>meghajtó</secondary>
      </indexterm>

      <para>Mielõtt bárminek is nekikezdenénk,
	érdemes tisztában lennünk azzal, hogy a
	rendelkezésünkre álló kártya
	milyen típusú, milyen chipet használ
	és hogy PCI vagy ISA buszon csatlakozik-e.  A &os; a PCI
	és ISA csatolós kártyák
	széles spektrumát ismeri.  Az egyes
	kiadásokhoz mellékelt <quote>Hardware
	Compatibility List</quote> (Hardverkompatibilitási lista)
	dokumentumokban tudjuk ellenõrizni, hogy a
	kártyákat ismeri a rendszer.</para>

      <para>Miután meggyõzõdtünk róla, hogy
	a kártyánkat ismeri a rendszer, meg kell
	keresnünk a hozzá tartozó meghajtót.
	A <filename>/usr/src/sys/conf/NOTES</filename> és a
	<filename>/usr/src/sys/<replaceable>arch</replaceable>/conf/NOTES</filename>
	állományok tartalmazzák a
	hálózati kártyák meghajtóinak
	rövid leírását, benne a
	támogatott chipsetek és kártyák
	típusaival.  Ha ez alapján nem tudjuk teljes
	biztosággal eldönteni, hogy melyik a
	számunkra megfelelõ meghajtó,
	nézzük meg a saját man oldalát.  Ezen
	a man oldalon megtaláljuk az általa ismert
	összes eszközt és a velük kapcsolatban
	elõforduló jellemzõ
	problémákat.</para>

      <para>Ha egy elterjedt típust sikerült
	beszereznünk, akkor nem kell különösebben
	sokáig keresnünk a neki megfelelõ
	meghajtót.  Az ismertebb hálózati
	kártyák meghajtói ugyanis alapból
	benne vannak a <filename>GENERIC</filename> rendszermagban,
	ezért a rendszer indítása során
	ehhez hasonlóan meg is jelennek a
	kártyák:</para>

<screen>dc0: &lt;82c169 PNIC 10/100BaseTX&gt; port 0xa000-0xa0ff mem 0xd3800000-0xd38
000ff irq 15 at device 11.0 on pci0
miibus0: &lt;MII bus&gt; on dc0
bmtphy0: &lt;BCM5201 10/100baseTX PHY&gt; PHY 1 on miibus0
bmtphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc0: Ethernet address: 00:a0:cc:da:da:da
dc0: [ITHREAD]
dc1: &lt;82c169 PNIC 10/100BaseTX&gt; port 0x9800-0x98ff mem 0xd3000000-0xd30
000ff irq 11 at device 12.0 on pci0
miibus1: &lt;MII bus&gt; on dc1
bmtphy1: &lt;BCM5201 10/100baseTX PHY&gt; PHY 1 on miibus1
bmtphy1:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
dc1: Ethernet address: 00:a0:cc:da:da:db
dc1: [ITHREAD]</screen>

      <para>Ebben a példában láthatunk is
	két olyan kártyát, amelyek a &man.dc.4;
	meghajtót használják.</para>

      <para>Ha a hálózati kártyánk
	meghajtója nem szerepel a <filename>GENERIC</filename>
	konfigurációban, akkor a
	mûködéséhez be kell tölteni a
	megfelelõ meghajtót.  Ezt alapvetõen
	kétféleképpen érhetjük
	el:</para>

      <itemizedlist>
	<listitem>
	  <para>Ennek legegyszerûbb módja, ha a
	    &man.kldload.8; használatával
	    alkalmanként vagy a
	    <filename>/boot/loader.conf</filename>
	    állományban a megfelelõ sor
	    hozzáadásával a rendszer
	    indításával együtt
	    betöltjük a hálózati kártya
	    meghajtójához tartozó modult.  Nem
	    mindegyik hálózati kártya
	    meghajtója érhetõ el modul
	    formájában.  Erre konkrét
	    például szolgálnak az ISA
	    kártyákhoz tartozó modulok.</para>
	</listitem>

	<listitem>
	  <para>Másik lehetõségünk, ha
	    statikusan beépítjük a
	    kártyánk támogatását a
	    rendszermagba.  A
	    <filename>/usr/src/sys/conf/NOTES</filename> és az
	    <filename>/usr/src/sys/<replaceable>arch</replaceable>/conf/NOTES</filename>
	    állományok, valamint a meghajtóhoz
	    tartozó man oldal elolvasásából
	    megtudhatjuk a rendszermag beállításait
	    tartalmazó állományban megadandó
	    paramétereket.  A rendszermag
	    újrafordítását lásd <xref
	    linkend="kernelconfig"/>.  Ha a rendszermag
	    (<filename>GENERIC</filename>) az indulás
	    során észlelte a kártyánkat, nem
	    kell újat készítenünk.</para>
	</listitem>
      </itemizedlist>

      <sect3 id="config-network-ndis">
	<title>A &windows; NDIS meghajtóinak
	  használata</title>

	<indexterm><primary>NDIS</primary></indexterm>
	<indexterm><primary>NDISulator</primary></indexterm>
	<indexterm><primary>&windows;
	  meghajtók</primary></indexterm>
	<indexterm><primary>Microsoft Windows</primary></indexterm>
	<indexterm>
	  <primary>Microsoft Windows</primary>
	  <secondary>eszközmeghajtók</secondary></indexterm>
	<indexterm><primary>KLD (a rendszermag betölthetõ
	  objektuma)</primary></indexterm>

	<para>Sajnos még mindig sok olyan gyártó
	  akad, akik a nyílt forrású
	  közösség számára nem
	  adják ki a meghajtóik
	  mûködésének alapjait, mivel az ilyen
	  adatokat szakmai titoknak tekintik.  Ebbõl
	  következik, hogy a &os; és más
	  operációs rendszerek fejlesztõi
	  számára két választás
	  marad: vagy a gyári meghajtók
	  visszafejtésének hosszú és
	  fájdalmas útján haladva fejlesztik ki a
	  saját meghajtójukat, vagy pedig a
	  &microsoft.windows; platformra kiadott meghajtók
	  binárisait hasznosítják.  A legtöbb
	  fejlesztõ, köztük a &os; fejlesztõi is, ez
	  utóbbi megközelítést
	  választották.</para>

	<para>Bill Paul (wpaul) jóvoltából a
	  &os;&nbsp;5.3-RELEASE változatában megjelent a
	  <quote>Network Driver Interface Specification</quote> (NDIS,
	  avagy hálózati meghajtók
	  szabványos felülete) <quote>natív</quote>
	  támogatása.  A &os; NDISulator
	  (másnéven Project Evil, a Gonosz terve)
	  nevû komponense fog egy &windows;-os meghajtót
	  és elhiteti vele, hogy a &windows;
	  operációs rendszerrel kommunikál.  Mivel
	  az &man.ndis.4; meghajtó &windows; binárisokat
	  használ fel, ezért csak &arch.i386; és
	  &arch.amd64; rendszerek esetén érhetõ
	  el.</para>

	<note>
	  <para>Az &man.ndis.4; meghajtó leginkább a PCI,
	    CardBus és PCMCIA csatolójú
	    eszközök támogatására lett
	    kitalálva, az USB eszközöket még nem
	    ismeri.</para>
	</note>

	<para>Az NDISulator használatához három
	  tényezõre van szükségünk:</para>

	<orderedlist>
	 <listitem>
	  <para>A rendszermag forrása</para>
	 </listitem>
	 <listitem>
	  <para>a &windowsxp; meghajtó binárisa
	    (<filename>.SYS</filename> a kiterjesztése)</para>
	 </listitem>
	 <listitem>
	  <para>a &windowsxp; meghajtó
	    konfigurációs állománya
	    (<filename>.INF</filename> a kiterjesztése)</para>
	 </listitem>
	</orderedlist>

	<para>Keressük meg az említett
	  állományokat az adott kártyához.
	  Ezeket általában a mellékelt CD-n vagy a
	  gyártó honlapján találjuk meg.  A
	  most következõ példákban a
	  <filename>W32DRIVER.SYS</filename> és a
	  <filename>W32DRIVER.INF</filename> neveket fogjuk
	  használni.</para>

	<note>
	  <para>A &windows; i386 architektúrájú
	    verziójához készült
	    meghajtóprogramokat nem tudjuk a &os;/amd64
	    verziójával használni.  A
	    mûködéshez amd64-re készült
	    &windows;-os meghajtókra van
	    szükség.</para>
	</note>

	<para>A következõ lépés a
	  meghajtó binárisainak betölthetõ
	  modulba fordítása.  Ennek
	  eléréséhez használjuk az
	  &man.ndisgen.8; parancsot a <username>root</username>
	  felhasználóval:</para>

	<screen>&prompt.root; <userinput>ndisgen <replaceable>/windowsos/meghajtó/W32DRIVER.INF</replaceable> <replaceable>/windowsos/meghajtó/W32DRIVER.SYS</replaceable></userinput></screen>

	<para>Az &man.ndisgen.8; egy interaktív
	  segédprogram, amely mûködése
	  közben még rákérdez
	  néhány szükséges
	  információra.  Az aktuális
	  könyvtárban létrehoz egy rendszermagmodult,
	  amelyet az alábbi módon tudunk
	  betölteni:</para>

	<screen>&prompt.root; <userinput>kldload <replaceable>./W32DRIVER_SYS.ko</replaceable></userinput></screen>

	<para>Az elõállított modul mellé be
	  kell töltenünk még az
	  <filename>ndis.ko</filename> és az
	  <filename>if_ndis.ko</filename> modulokat is.  Ez
	  általában minden olyan modul esetén
	  megtörténik magától, amely függ
	  az &man.ndis.4; használatától.
	  Kézileg a következõ parancsokkal tudjuk
	  ezeket betölteni:</para>

	<screen>&prompt.root; <userinput>kldload ndis</userinput>
&prompt.root; <userinput>kldload if_ndis</userinput></screen>

	<para>Itt az elsõ parancs betölti az NDIS miniport
	  meghajtó burkolására szánt
	  kódot, valamint a második a tényleges
	  hálózati csatolófelületet.</para>

	<para>Most pedig a &man.dmesg.8; kimenetében
	  ellenõrizzük, hogy történt-e valamilyen
	  hiba a betöltés során.  Ha minden
	  jól ment, akkor az alábbiakhoz hasonló
	  kimenetet produkált:</para>

	<screen>ndis0: &lt;Wireless-G PCI Adapter&gt; mem 0xf4100000-0xf4101fff irq 3 at device 8.0 on pci1
ndis0: NDIS API version: 5.0
ndis0: Ethernet address: 0a:b1:2c:d3:4e:f5
ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 36Mbps 48Mbps 54Mbps</screen>

	<para>Innentõl kezdve az <devicename>ndis0</devicename>
	  nevû eszközt úgy tudjuk használni,
	  mint bármelyik más hálózati
	  felületet (például
	  <devicename>dc0</devicename>).</para>

	<para>A többi modulhoz hasonló módon be
	  tudjuk állítani, hogy a rendszer
	  indulásával együtt betöltõdjenek
	  az NDIS modulok.  Ehhez elõször másoljuk az
	  imént létrehozott modult, az
	  <filename>W32DRIVER_SYS.ko</filename> állományt a
	  <filename class="directory">/boot/modules</filename>
	  könyvtárba.  Ezután adjuk hozzá a
	  következõ sort a
	  <filename>/boot/loader.conf</filename> állomány
	  tartalmához:</para>

	<programlisting>W32DRIVER_SYS_load="YES"</programlisting>
      </sect3>
    </sect2>

    <sect2>
      <title>A hálózati kártya
	beállítása</title>

      <indexterm>
	<primary>hálózati kártyák</primary>
	<secondary>beállítása</secondary>
      </indexterm>

      <para>Ahogy betöltõdött a megfelelõ
	meghajtó a hálózati
	kártyánkhoz, be is kell állítanunk a
	kártyát.  A hálózati
	kártyák sok más dologgal együtt
	beállíthatóak a telepítés
	során a <application>sysinstall</application>
	segítségével.</para>

      <para>A rendszerünkben beállított
	hálózati csatolófelületek
	megjelenítéséhez gépeljük be a
	következõ parancsot:</para>

<screen>&prompt.user; <userinput>ifconfig</userinput>
dc0: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500
        options=80008&lt;VLAN_MTU,LINKSTATE&gt;
        ether 00:a0:cc:da:da:da
        inet 192.168.1.3 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect (100baseTX &lt;full-duplex&gt;)
        status: active
dc1: flags=8843&lt;UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500
        options=80008&lt;VLAN_MTU,LINKSTATE&gt;
        ether 00:a0:cc:da:da:db
        inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
        media: Ethernet 10baseT/UTP
        status: no carrier
plip0: flags=8810&lt;POINTOPOINT,SIMPLEX,MULTICAST&gt; mtu 1500
lo0: flags=8049&lt;UP,LOOPBACK,RUNNING,MULTICAST&gt; metric 0 mtu 16384
        options=3&lt;RXCSUM,TXCSUM&gt;
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
        inet6 ::1 prefixlen 128
        inet 127.0.0.1 netmask 0xff000000
        nd6 options=8010&lt;POINTOPOINT,MULTICAST&gt; mtu 1500</screen>

      <para>Az elõbbi parancs kimenetében a
	következõ eszközök jelentek meg:</para>

      <itemizedlist>
	<listitem>
	  <para><devicename>dc0</devicename>: az elsõ Ethernet
	    felület</para>
	</listitem>

	<listitem>
	  <para><devicename>dc1</devicename>: a második Ethernet
	    felület</para>
	</listitem>

	<listitem>
	  <para><devicename>plilp0</devicename>: a párhuzamos
	    port felülete (amennyiben található
	    párhuzamos port a
	    számítógépben)</para>
	</listitem>

	<listitem>
	  <para><devicename>lo0</devicename>: a loopback
	    eszköz</para>
	</listitem>
      </itemizedlist>

      <para>A &os; a kártyához tartozó
	meghajtó nevével és egy sorszámmal
	azonosítja a rendszermag indulása során
	talált eszközöket.  Például az
	<devicename>sis2</devicename> a rendszerben
	található harmadik olyan eszköz, amely a
	&man.sis.4; meghajtót használja.</para>

      <para>A példában a <devicename>dc0</devicename>
	eszköz aktív és
	mûködõképes.  Ennek legfontosabb
	jelei:</para>

      <orderedlist>
	<listitem>
	  <para>Az <literal>UP</literal> szó mutatja, hogy a
	    kártyát sikerült beállítani
	    és készen áll a
	    használatra.</para>
	</listitem>

	<listitem>
	  <para>A kártya internet (<literal>inet</literal>)
	    címe (jelen esetünkben ez <hostid
	    role="ipaddr">192.168.1.3</hostid>).</para>
	</listitem>

	<listitem>
	  <para>Érvényes hálózati maszkkal
	    rendelkezik (<literal>netmask</literal>, ahol a <hostid
	    role="netmask">0xffffff00</hostid> a <hostid
	    role="netmask">255.255.255.0</hostid> címnek felel
	    meg).</para>
	</listitem>

	<listitem>
	  <para>Érvényes broadcast
	    (üzenetszóró) címmel rendelkezik
	    (ami itt most <hostid
	    role="ipaddr">192.168.1.255</hostid>).</para>
	</listitem>

	<listitem>
	  <para>A kártya MAC-címe
	    (<literal>ether</literal>) <hostid
	    role="mac">00:a0:cc:da:da:da</hostid>.</para>
	</listitem>

	<listitem>
	  <para>A hozzá tartozó fizikai eszköz
	    kiválasztása automatikus (<literal>media:
	    Ethernet autoselect (100baseTX
	    &lt;full-duplex&gt;)</literal>).  Láthatjuk, hogy a
	    <devicename>dc1</devicename> eszközt egy
	    <literal>10baseT/UTP</literal> típusú fizikai
	    eszközhöz állítottuk be.  Az egyes
	    meghajtókhoz tartozó fizikai
	    módokról a nekik megfelelõ man oldalakon
	    olvashatunk.</para>
	</listitem>

	<listitem>
	  <para>A kapcsolat állapota (<literal>status</literal>)
	    <literal>active</literal> értékû,
	    tehát van vonal.  A <devicename>dc1</devicename>
	    esetén láthatjuk, hogy a <literal>status: no
	    carrier</literal> (nincs vonal).  Ez teljesen
	    normálisnak tekinthetõ minden olyan esetben,
	    amikor a kártyába még nem dugtunk
	    Ethernet-kábelt.</para>
	</listitem>
      </orderedlist>

      <para>Amennyiben az &man.ifconfig.8; kimenete valami
	ilyesmi:</para>

      <screen>dc0: flags=8843&lt;BROADCAST,SIMPLEX,MULTICAST&gt; metric 0 mtu 1500
	        options=80008&lt;VLAN_MTU,LINKSTATE&gt;
	        ether 00:a0:cc:da:da:da
	        media: Ethernet autoselect (100baseTX &lt;full-duplex&gt;)
	        status: active</screen>

      <para>akkor az arra utal, hogy a kártyát nem
	állítottuk be.</para>

      <para>A kártya beállításához a
	<username>root</username> felhasználó
	jogosultságaira van szükségünk.  A
	hálózati kártyák
	beállítása az &man.ifconfig.8;
	segítségével elvégezhetõ
	parancssorból is, de a gép
	újraindításakor az így megadott
	értékek elvesznek.  Ezért az
	<filename>/etc/rc.conf</filename> állományba kell
	felvennünk a hálózati kártyák
	érvényes beállításait.</para>

      <para>A kedvenc szövegszerkesztõnkben nyissuk meg az
	<filename>/etc/rc.conf</filename> állományt.
	Minden egyes hálózati csatolóhoz fel kell
	vennünk benne egy sort, ennek megfelelõen most a
	példához tartozó módon az
	alábbiakat:</para>

      <programlisting>ifconfig_dc0="inet 192.168.1.3 netmask 255.255.255.0"
ifconfig_dc1="inet 10.0.0.1 netmask 255.255.255.0 media 10baseT/UTP"</programlisting>

      <para>A <devicename>dc0</devicename> és
	<devicename>dc1</devicename> neveket kell a rendszerünkben
	ténylegesen megtalálható eszközök
	neveire kicserélni, valamint megadni a nekik
	megfelelõ címeket.  A kártya
	meghajtójának és az &man.ifconfig.8; man
	oldalának elolvasásával
	kideríthetjük az itt megadható további
	beállításokat, valamint az &man.rc.conf.5;
	man oldalán részletesebben megismerhetjük az
	<filename>/etc/rc.conf</filename> formai
	követelményeit.</para>

      <para>Ha a telepítés során
	beállítottuk volna a hálózati
	kapcsolatokat, akkor tapasztalhatjuk, hogy egyes
	hálózati kártyák sorai itt
	már szerepelnek.  Ellenõrizzük az
	<filename>/etc/rc.conf</filename> tartalmát, mielõtt
	bõvítenénk!</para>

      <para>Mindezek mellett az <filename>/etc/hosts</filename>
	állományba is be kell írnunk a helyi
	hálózatunkon található
	különféle gépek neveit és
	IP-címeit, ha még nem szerepelnének ott.
	Errõl további részleteket a &man.hosts.5; man
	oldalról és az
	<filename>/usr/share/examples/etc/hosts</filename>
	állományból tudhatunk meg.</para>

      <note>
	<para>Ha a géppel szeretnénk majd csatlakozni az
	  internetre, akkor ne felejtsük el manuálisan
	  beállítani az alapértelmezett
	  átjárót és a
	  névfeloldáshoz szükséges
	  kiszolgálót:</para>

	<screen>&prompt.root; <userinput>echo 'defaultrouter="<replaceable>alapertelmezett_atjaro</replaceable>"' &gt;&gt; /etc/rc.conf</userinput>
&prompt.root; <userinput>echo 'nameserver <replaceable>DNS_kiszolgalo</replaceable>' &gt;&gt; /etc/resolv.conf</userinput></screen>
      </note>
    </sect2>

    <sect2>
      <title>Tesztelés és
	hibaelhárítás</title>

      <para>Miután az <filename>/etc/rc.conf</filename>
	állományban elvégeztük a
	szükséges változtatásokat,
	érdemes újraindítanunk a
	rendszerünket.  Ennek révén
	érvényesítjük a
	csatolófelületekkel kapcsolatos
	változtatásainkat és
	ellenõrizzük, hogy így a rendszer
	mindenféle hibaüzenet nélkül
	képes elindulni.  A másik lehetõség,
	ha csak magát a hálózati alrendszer
	konfigurációját indítjuk el
	újra:</para>

      <screen>&prompt.root; <userinput>/etc/rc.d/netif restart</userinput></screen>

      <note>
	<para>Ha az <filename>/etc/rc.conf</filename>
	  állományban már beállítottuk
	  az alapértelmezett átjárót, akkor
	  elegendõ csupán ez a parancs:</para>

	<screen>&prompt.root; <userinput>/etc/rc.d/routing restart</userinput></screen>
      </note>

      <para>Ahogy újrakonfiguráltuk a
	hálózati alrendszert, ki is tudjuk
	próbálni a hálózati
	felületeket.</para>

      <sect3>
	<title>Az Ethernet kártyák
	  tesztelése</title>

	<indexterm>
	  <primary>hálózati
	    kártyák</primary>
	  <secondary>tesztelése</secondary>
	</indexterm>

	<para>Az Ethernet kártyák helyes
	  beállításának
	  vizsgálatához két dolgot kell
	  kipróbálnunk.  Elõször is
	  pingeljük magát a felületet, majd
	  ezután pingeljünk meg a helyi
	  hálózaton egy másik
	  számítógépet.</para>

	<para>Elsõként tehát próbáljuk
	  meg a helyi felületet:</para>

	<screen>&prompt.user; <userinput>ping -c5 192.168.1.3</userinput>
PING 192.168.1.3 (192.168.1.3): 56 data bytes
64 bytes from 192.168.1.3: icmp_seq=0 ttl=64 time=0.082 ms
64 bytes from 192.168.1.3: icmp_seq=1 ttl=64 time=0.074 ms
64 bytes from 192.168.1.3: icmp_seq=2 ttl=64 time=0.076 ms
64 bytes from 192.168.1.3: icmp_seq=3 ttl=64 time=0.108 ms
64 bytes from 192.168.1.3: icmp_seq=4 ttl=64 time=0.076 ms

--- 192.168.1.3 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.074/0.083/0.108/0.013 ms</screen>

	<para>Most pedig pingeljünk meg egy másik
	  számítógépet a helyi
	  hálózaton:</para>

	<screen>&prompt.user; <userinput>ping -c5 192.168.1.2</userinput>
PING 192.168.1.2 (192.168.1.2): 56 data bytes
64 bytes from 192.168.1.2: icmp_seq=0 ttl=64 time=0.726 ms
64 bytes from 192.168.1.2: icmp_seq=1 ttl=64 time=0.766 ms
64 bytes from 192.168.1.2: icmp_seq=2 ttl=64 time=0.700 ms
64 bytes from 192.168.1.2: icmp_seq=3 ttl=64 time=0.747 ms
64 bytes from 192.168.1.2: icmp_seq=4 ttl=64 time=0.704 ms

--- 192.168.1.2 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.700/0.729/0.766/0.025 ms</screen>

	<para>Ha beállítottuk az
	  <filename>/etc/hosts</filename> állományt, akkor
	  a <hostid role="ipaddr">192.168.1.2</hostid> helyett a
	  gép nevét is megadhatjuk.</para>
      </sect3>

      <sect3>
	<title>A hibák elhárítása</title>

      <indexterm>
	<primary>hálózati kártyák</primary>
	<secondary>hibaelhárítása</secondary>
      </indexterm>

	<para>A hardverek és szoftverek
	  beállításaiban mindig is valódi
	  kín megtalálni a hibákat, és
	  ezeket a kínokat többnyire úgy tudjuk
	  enyhíteni, ha elõször az egyszerû
	  hibaforrásokat szûrjük ki.  Csatlakoztattuk a
	  hálózati kábelt?  Tisztességesen
	  beállítottuk a hálózati
	  szolgáltatásokat?  Jól
	  állítottuk be a tûzfalat?  A &os;
	  képes kezelni a kártyát?  A
	  hibajelentések elküldése elõtt mindig
	  bújjuk át a támogatott
	  hardvereszközök listáját.  A &os;
	  verziókat frissítsük a legújabb
	  STABLE változatra.  Olvassuk át a
	  levelezési listák archívumait vagy
	  legalább keressünk rá a
	  témára az interneten.</para>

	<para>Ha a kártya mûködik, de a
	  teljesítménye nem kielégítõ,
	  érdemes ennek utánanézni a &man.tuning.7;
	  man oldalon.  Ilyenkor érdemes ellenõrizni a
	  hálózati beállításainkat
	  is, mivel a helytelen beállítások gyakran
	  okoznak teljesítményvesztést.</para>

	<para>Bizonyos esetekben láthatunk egy vagy két
	  <errorname>device timeout</errorname> típusú
	  hibát is, ami a kártyák egyes
	  fajtáinál elfogadható.  Ha azonban
	  folyamatosan megjelennek vagy zavaróvá
	  válnak, érdemes utánanéznünk,
	  hogy az eszköz nem ütközik-e valamelyik
	  másikkal.  Mindenképpen
	  gyõzõdjünk meg a kábelek
	  épségérõl és
	  csatlakoztatásáról.  Még az is
	  elképzelhetõ, hogy egyszerûen csak egy
	  másik hálózati kártyára van
	  szükségünk.</para>

	<para>Néha felbukkanak <errorname>watchdog
	  timeout</errorname> jellegû hibák is.  Ilyenkor
	  elsõként mindig a hálózati
	  kábelt ellenõrizzük.  Egyes
	  kártyáknak olyan PCI foglalatra van
	  szükségük, ami támogatja a Bus
	  Mastering opciót.  Néhány régebbi
	  alaplapon csak ilyen PCI bõvítõhely
	  található (ami általában a 0.
	  foglalat).  Olvassunk utána a hálózati
	  kártya és az alaplap
	  dokumentációjában, hátha ezek
	  okozzák a problémát.</para>

	<para>A <errorname>No route to host</errorname> üzenet
	  akkor jelenik meg, ha a rendszer képtelen
	  megállapítani, milyen úton juttassa el a
	  csomagokat a megadott célhoz.  Ez többnyire
	  olyankor történik meg, amikor nem adtunk meg
	  alapértelmezett kézbesítési
	  irányt (default route) vagy nem dugtuk be a
	  hálózati kábelt.  A <command>netstat
	  -rn</command> kimenetébõl meg tudjuk
	  állapítani, hogy létezik-e
	  érvényes út az elérni
	  kívánt cél felé.  Ha nincs, akkor
	  haladjunk tovább a <xref
	  linkend="advanced-networking"/>re.</para>

	<para>A <errorname>ping: sendto: Permission denied</errorname>
	  jellegû üzeneteket többségében
	  egy helytelenül beállított tûzfal
	  okozza.  Ha az <command>ipfw</command>
	  mûködését engedélyeztük a
	  rendszermagban, de nem adtunk meg hozzá
	  szabályokat, akkor az alapértelmezett
	  házirend szerint minden forgalmat blokkolni fog,
	  tehát még a pingeket is!  Ezzel kapcsolatban a
	  <xref linkend="firewalls"/> elolvasását
	  ajánljuk.</para>

	<para>Elõfordulhat, hogy a kártya
	  teljesítménye igen gyenge vagy az átlagos
	  alatt van.  Ilyenkor a fizikai eszköz
	  <literal>autoselect</literal> (automatikus)
	  típusú kiválasztása helyett
	  érdemes megadnunk a konkrét eszköznek
	  megfelelõ típust.  Habár ez a legtöbb
	  hardver esetén beválik, nem mindenki
	  számára jelent megoldást.
	  Ismételten csak annyit tudunk ehhez hozzátenni,
	  hogy ellenõrizzük a hálózati
	  beállításainkat és olvassuk el a
	  &man.tuning.7; man oldalt.</para>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="configtuning-virtual-hosts">
    <title>Virtuális címek</title>

    <indexterm><primary>virtuális
      címek</primary></indexterm>
    <indexterm><primary>IP-álnevek</primary></indexterm>

    <para>A &os; alkalmazása során igen gyakori a
      virtuális címek használata, aminek
      segítségével egyetlen szerver több
      szerverként képes látszódni a
      hálózaton.  Ezt úgy érik el, hogy
      egyetlen felülethez több hálózati
      címet rendelnek hozzá.</para>

    <para>Az adott hálózati csatolófelületnek
      van egy <quote>valódi címe</quote> és
      tetszõleges számú
      <quote>álcíme</quote>.  Ezeket az
      álcímeket általában az
      <filename>/etc/rc.conf</filename> állományban kell
      feltüntetni.</para>

    <para>Az <devicename>fxp0</devicename> felület esetén az
      álcímek megadása valahogy így
      néz ki:</para>

    <programlisting>ifconfig_fxp0_alias0="inet xxx.xxx.xxx.xxx netmask xxx.xxx.xxx.xxx"</programlisting>

    <para>Figyeljük meg, hogy az álcímekhez
      tartozó bejegyzések az <literal>alias0</literal>
      névvel kezdõdnek és szám szerint
      növekvõleg következnek egymás után
      (például, <literal>_alias1</literal>,
      <literal>_alias2</literal> és így tovább).  A
      beállítás a sorozat elsõ kimaradó
      tagjánál megszakad.</para>

    <para>Az álcímek hálózati
      maszkjának pontos meghatározása nagyon
      fontos, de szerencsére nem különösebben
      bonyolult.  Minden felület esetén lennie kell egy
      olyan címnek, amely helyesen reprezentálja a
      hálózat hálózati maszkját.
      Minden egyéb olyan címnek, ami ugyanabba az
      alhálózatba esik, végig
      <literal>1</literal>-esekbõl álló
      hálózati maszkkal kell rendelkezniük (ami
      felírható <hostid
      role="netmask">255.255.255.255</hostid> vagy <hostid
      role="netmask">0xffffffff</hostid> formájában
      is).</para>

    <para>Például vegyük azt, hogy az
      <devicename>fxp0</devicename> felületen keresztül
      két hálózathoz csatlakozunk, melyek
      közül az egyik a <hostid
      role="ipaddr">10.1.1.0</hostid>, amelynek hálózati
      maszkja <hostid role="netmask">255.255.255.0</hostid>, és a
      <hostid role="ipaddr">202.0.75.16</hostid>, amelynek
      hálózati maszkja <hostid
      role="netmask">255.255.255.240</hostid>.  Azt szeretnénk
      elérni, hogy a rendszerünk a <hostid
      role="ipaddr">10.1.1.1</hostid> címtõl a <hostid
      role="ipaddr">10.1.1.5</hostid> címig, valamint a <hostid
      role="ipaddr">202.0.75.17</hostid> címtõl a <hostid
      role="ipaddr">202.0.75.20</hostid> címig jelenjen meg a
      nekik megfelelõ hálózatokon.  Ahogy arra
      már fentebb is utaltunk, az adott hálózati
      tartományban csak az elsõ címnek (ebben az
      esetben ez a <hostid role="ipaddr">10.0.1.1</hostid> és a
      <hostid role="ipaddr">202.0.75.17</hostid>) kell valódi
      hálózati maszkkal rendelkeznie.  Minden
      további címnek (a <hostid
      role="ipaddr">10.1.1.2</hostid> és <hostid
      role="ipaddr">10.1.1.5</hostid> között, valamint a
      <hostid role="ipaddr">202.0.75.18</hostid> és <hostid
      role="ipaddr">202.0.75.20</hostid> között) legyen
      <hostid role="netmask">255.255.255.255</hostid> a
      hálózati maszkja.</para>

    <para>Az alábbi <filename>/etc/rc.conf</filename>
      bejegyzések ennek az elrendezésnek megfelelõen
      állítják be a kártyát:</para>

    <programlisting>ifconfig_fxp0="inet 10.1.1.1 netmask 255.255.255.0"
ifconfig_fxp0_alias0="inet 10.1.1.2 netmask 255.255.255.255"
ifconfig_fxp0_alias1="inet 10.1.1.3 netmask 255.255.255.255"
ifconfig_fxp0_alias2="inet 10.1.1.4 netmask 255.255.255.255"
ifconfig_fxp0_alias3="inet 10.1.1.5 netmask 255.255.255.255"
ifconfig_fxp0_alias4="inet 202.0.75.17 netmask 255.255.255.240"
ifconfig_fxp0_alias5="inet 202.0.75.18 netmask 255.255.255.255"
ifconfig_fxp0_alias6="inet 202.0.75.19 netmask 255.255.255.255"
ifconfig_fxp0_alias7="inet 202.0.75.20 netmask 255.255.255.255"</programlisting>
  </sect1>

  <sect1 id="configtuning-configfiles">
    <title>Konfigurációs állományok</title>

    <sect2>
      <title>Az <filename class="directory">/etc</filename>
	felépítése</title>

      <para>A beállításokkal kapcsolatos
	információk számos könyvtárban
	tárolódnak.  Többek közt:</para>

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

	  <tbody>
	    <row>
	      <entry><filename class="directory">/etc</filename></entry>
	      <entry>Általános rendszerszintû
		beállítások.  Az itt levõ
		adatok a rendszer egészére
		vonatkoznak.</entry>
	    </row>
	    <row>
	      <entry><filename class="directory">/etc/defaults</filename></entry>
	      <entry>A rendszer konfigurációs
		állományainak alapértelmezett
		változatai.</entry>
	    </row>
	    <row>
	      <entry><filename class="directory">/etc/mail</filename></entry>
	      <entry>A &man.sendmail.8;
		beállításához tartozó
		további állományok, egyéb
		levélküldéshez használt
		adatok.</entry>
	    </row>
	    <row>
	      <entry><filename class="directory">/etc/ppp</filename></entry>
	      <entry>A felhasználói és rendszermag
		szintû ppp programok
		beállításai.</entry>
	    </row>
	    <row>
	      <entry><filename class="directory">/etc/namedb</filename></entry>
	      <entry>A &man.named.8; mûködéséhez
		szükséges adatok alapértelmezett
		helye.  Általában a
		<filename>named.conf</filename> és a
		zónák leírását
		tároló állományok
		kerülnek ide.</entry>
	    </row>
	    <row>
	      <entry><filename class="directory">/usr/local/etc</filename></entry>
	      <entry>A telepített alkalmazások
		konfigurációs állományai.
		Néha alkalmazásonként
		külön könyvtárakba kerülnek a
		benne található
		állományok.</entry>
	    </row>
	    <row>
	      <entry><filename class="directory">/usr/local/etc/rc.d</filename></entry>
	      <entry>A telepített alkalmazások
		indításával és
		leállításával kapcsolatos
		szkriptek.</entry>
	    </row>
	    <row>
	      <entry><filename class="directory">/var/db</filename></entry>
	      <entry>Automatikusan generált rendszerszintû
		adatbázisok a csomagokkal, a programok
		helyével stb.  kapcsolatosan.</entry>
	    </row>
	  </tbody>
	</tgroup>
      </informaltable>
    </sect2>

    <sect2>
      <title>Hálózati nevek</title>

      <indexterm><primary>hálózati
	név</primary></indexterm>
      <indexterm><primary>DNS</primary></indexterm>

      <sect3>
	<title><filename>/etc/resolv.conf</filename></title>

	<indexterm><primary><filename>resolv.conf</filename></primary></indexterm>

	<para>Az <filename>/etc/resolv.conf</filename> határozza
	  meg, hogy a &os; névfeloldója miként
	  fér hozzá az internet tartománynév
	  rendszeréhez (a DNS-hez).</para>

	<para>Az <filename>resolv.conf</filename>
	  állományban leggyakrabban a következõ
	  bejegyzések fordulnak elõ:</para>

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

	    <tbody>
	      <row>
		<entry><literal>nameserver</literal></entry>
		<entry>Annak a névszernek az IP-címe,
		  ahova a névfeloldó küldi a
		  kéréseit.  A névszervereket a
		  felírás sorrendjében
		  kérdezi meg, maximum hármat.</entry>
	      </row>
	      <row>
		<entry><literal>search</literal></entry>
		<entry>A hálózati nevek
		  keresõlistája.  Ezt
		  általában a helyi hálózati
		  nevek tartománya határozza meg.</entry>
	      </row>
	      <row>
		<entry><literal>domain</literal></entry>
		<entry>A helyi tartomány neve.</entry>
	      </row>
	    </tbody>
	  </tgroup>
	</informaltable>

	<para>Egy átlagos <filename>resolv.conf</filename>
	  tartalma:</para>

	<programlisting>search example.com
nameserver 147.11.1.11
nameserver 147.11.100.30</programlisting>

	<note>
	  <para>Csak egy <literal>search</literal> és
	    <literal>domain</literal> opciót szabad
	    megadni.</para>
	</note>

	<para>A DHCP használatakor a &man.dhclient.8; felül
	  szokta írni a <filename>resolv.conf</filename>
	  tartalmát a DHCP szervertõl kapott
	  információkkal.</para>
      </sect3>

      <sect3>
	<title><filename>/etc/hosts</filename></title>

	<indexterm><primary>hosts</primary></indexterm>

	<para>Az <filename>/etc/hosts</filename> az internet kezdeti
	  napjaira emlékeztetõ egyszerû szöveges
	  adatbázis.  A nevek és IP-címek
	  közti leképzéseket a DNS és NIS
	  rendszerekkel karöltve oldja fel.  Ide a helyi
	  hálózaton csatlakozó
	  számítógépek neveit lehet
	  beírni ahelyett, hogy erre a célra
	  beállítanánk egy külön
	  &man.named.8; szervert.  Ezenkívül még az
	  <filename>/etc/hosts</filename> állományba
	  internetes nevek rekordját is felvehetjük, amivel
	  így csökkenthetjük a gyakran használt
	  nevek feloldására irányuló
	  külsõ kéréseket.</para>

	<programlisting># &dollar;&os;&dollar;
#
#
# A hálózati nevek adatbázisa
#
# Ebbe az állományba rakjuk a helyi hálózaton található címeket és
# a hozzájuk tartozó hálózati neveket, ahol szinte ugyanez az
# adatbázis megtalálható.  A 'my.domain' helyére a saját gépünk
# nevét írjuk be.
#
# A DNS vagy NIS alkalmazása esetén ez az állomány nem feltétlenül kerül
# felhasználásra. A névfeloldás sorrendjét az /etc/nsswitch.conf
# állományban adhatjuk meg.
#
::1                     localhost localhost.my.domain
127.0.0.1               localhost localhost.my.domain

#
# Egy képzeletbeli hálózat.
#10.0.0.2               myname.my.domain myname
#10.0.0.3               myfriend.my.domain myfriend
#
# Az RFC 1918-nak megfelelõen a következõ IP-címekkel rendelkezõ
# alhálózatok sosem csatlakozhatnak közvetlenül az internetre:
#
#       10.0.0.0        -   10.255.255.255
#       172.16.0.0      -   172.31.255.255
#       192.168.0.0     -   192.168.255.255
#
# Amikor csatlakozunk az internethez, egy valódi, hivatalosan
# kiosztott számra lesz szükségünk.  Ne találjunk ki magunknak
# hálózati címeket, hanem használjuk az internetszolgáltatótól
# kapott címet (amennyiben rendelkezünk # ilyennel) vagy az
# regionális internetes nyilvántartásban szereplõ címek közül
# valamelyiket (ARIN, APNIC, LACNIC, RIPE NCC vagy AfriNIC).
</programlisting>

	<para>Az <filename>/etc/hosts</filename> formai
	  felépítése igen egyszerû:</para>

	<programlisting>[internetes cím] [hivatalos hálózati név] [álnév1] [álnév2] ...</programlisting>

	<para>Tehát például:</para>

	<programlisting>10.0.0.1 azEnValodiNevem.aHalozaton.hu azEnValodiNevem izemize1 izemize2</programlisting>

	<para>A részletekért keressük fel a
	  &man.hosts.5; man oldalt.</para>
      </sect3>
    </sect2>

    <sect2>
      <title>A naplóállományok
	beállítása</title>

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

      <sect3>
	<title><filename>syslog.conf</filename></title>

	<indexterm><primary>syslog.conf</primary></indexterm>

	<para>A <filename>syslog.conf</filename> állomány
	  a &man.syslogd.8; program beállításait
	  tartalmazza.  Segítségével megadhatjuk,
	  hogy a <command>syslog</command> által generált
	  üzenetek egyes típusait milyen
	  naplóállományokba mentsük.</para>

	<programlisting># &dollar;&os;&dollar;
#
# Ebben az állományban HASZNÁLHATÓAK szóközök a mezõk elválasztására,
# habár a többi *nix-típusú rendszer inkább tabulátorokat használ
# erre a célra. Ha több rendszeren is használni akarjuk ezt az
# állományt, akkor ne használjunk szóközöket.
#
# A többit lásd a syslog.conf(5) man oldalon.
#
.err;kern.debug;auth.notice;mail.crit           /dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages
security.*                                      /var/log/security
mail.info                                       /var/log/maillog
lpr.info                                        /var/log/lpd-errs
cron.*                                          /var/log/cron
*.err                                           root
*.notice;news.err                               root
*.alert                                         root
*.emerg                                         *
# Tegyük vissza ezt a sort, ha a /dev/console eszközre kiírt
# üzeneteket át akarjuk irányítani az /var/log/console.log állományba.
#console.info                                   /var/log/console.log
# Ha az összes üzenetet a /var/log/all.log állományba akarjuk menteni,
# akkor tegyük vissza ezt a sort.
#*.*                                            /var/log/all.log
# Ha egy "loghost" nevû gépre szeretnénk naplózni, akkor tegyük vissza
# ezt a sort.
#*.*                                            @loghost
# Az inn használatakor tegyük vissza ezeket a sorokat.
# news.crit                                     /var/log/news/news.crit
# news.err                                      /var/log/news/news.err
# news.notice                                   /var/log/news/news.notice
!startslip
*.*                                             /var/log/slip.log
!ppp
*.*                                             /var/log/ppp.log</programlisting>

	<para>A &man.syslog.conf.5; man oldalának
	  elolvasásával tudhatunk meg többet
	  ezekrõl.</para>
      </sect3>

      <sect3>
	<title><filename>newsyslog.conf</filename></title>

	<indexterm><primary>newsyslog.conf</primary></indexterm>

	<para>A <filename>newsyslog.conf</filename> a &man.newsyslog.8;
	  beállításait tároló
	  állomány.  Ez egy olyan program, amelyet
	  általában a &man.cron.8; futtat le.  A
	  &man.newsyslog.8; dönti el, hogy mikor van
	  szükség a naplók
	  archiválására és
	  átrendezésére.  Ennek során a
	  <filename>logfile</filename> állományból
	  <filename>logfile.0</filename> lesz, a
	  <filename>logfile.0</filename>
	  állományból pedig
	  <filename>logfile.1</filename> és így
	  tovább.  Beállíthatjuk úgy is,
	  hogy a naplóállományokat
	  archiválja &man.gzip.1; formátumban, aminek
	  megfelelõen ezek <filename>logfile.0.gz</filename>,
	  <filename>logfile.1.gz</filename> és ehhez
	  hasonló névvel jönnek létre.</para>

	<para>A <filename>newsyslog.conf</filename> megadja, hogy melyik
	  naplóállományokat kell felügyelni,
	  mennyi példányt tartsunk meg belõlük
	  és mikor kell velük foglalkozni.  A
	  naplóállományok
	  átrendezhetõek és/vagy
	  archiválhatóak egy adott méret
	  elérésekor vagy egy adott idõ eltelte
	  után.</para>

	<programlisting># A newsyslog konfigurációs állománya
# &dollar;&os;&dollar;
#
# állománynév     [tulajdonos:csoport]  mód  darab méret mikor [ZB] [/pid_állomány] [jelzés]
/var/log/cron                           600  3     100  *     Z
/var/log/amd.log                        644  7     100  *     Z
/var/log/kerberos.log                   644  7     100  *     Z
/var/log/lpd-errs                       644  7     100  *     Z
/var/log/maillog                        644  7     *    @T00  Z
/var/log/sendmail.st                    644  10    *    168   B
/var/log/messages                       644  5     100  *     Z
/var/log/all.log                        600  7     *    @T00  Z
/var/log/slip.log                       600  3     100  *     Z
/var/log/ppp.log                        600  3     100  *     Z
/var/log/security                       600  10    100  *     Z
/var/log/wtmp                           644  3     *    @01T05 B
/var/log/daily.log                      640  7     *    @T00  Z
/var/log/weekly.log                     640  5     1    $W6D0 Z
/var/log/monthly.log                    640  12    *    $M1D0 Z
/var/log/console.log                    640  5     100  *     Z</programlisting>

	<para>További információkat a
	  &man.newsyslog.8; man oldaláról
	  nyerhetünk.</para>
      </sect3>
    </sect2>

    <sect2 id="configtuning-sysctlconf">
      <title><filename>sysctl.conf</filename></title>

      <indexterm><primary>sysctl.conf</primary></indexterm>
      <indexterm><primary>sysctl</primary></indexterm>

      <para>A <filename>sysctl.conf</filename> állomány
	leginkább az <filename>rc.conf</filename>
	állományhoz hasonlít, benne az
	értékeket
	<literal>változó=érték</literal>
	párokban adhatjuk meg.  Az itt definiált
	értékek akkor kerülnek ténylegesen
	beállításra, amikor a rendszer
	többfelhasználós módba vált.
	Ezen a módon nem mindegyik változó
	értékét tudjuk
	átállítani.</para>

      <para>A <filename>sysctl.conf</filename> állományban
	az alábbi érték
	beállításával tudjuk
	beállítani, hogy a rendszer ne naplózza,
	amikor a programok végzetes jelzéssel
	fejezõdnek be, valamint azt, hogy a
	felhasználók láthassák egymás
	futó programjait:</para>

      <programlisting># Ne naplózzuk a végzetes jelzésekhez (például sig 11) tartozó kilépéseket.
kern.logsigexit=0

# Ne engedjük a felhasználóknak, hogy lássák egy másik felhasználó
# azonosítójával futó programokat.
security.bsd.see_other_uids=0</programlisting>
    </sect2>
  </sect1>

  <sect1 id="configtuning-sysctl">
    <title>Finomhangolás a sysctl
      használatával</title>

    <indexterm><primary>sysctl</primary></indexterm>
    <indexterm>
      <primary>finomhangolás</primary>
      <secondary>a sysctl használatával</secondary>
    </indexterm>

    <para>A &man.sysctl.8; egy olyan felület, amely
      lehetõséget biztosít egy mûködõ
      &os; rendszer megváltoztatására.
      Segítségével többek közt
      hozzáférhetünk a TCP/IP protokollkészlet
      és a virtuális memóriát kezelõ
      alrendszer rengeteg apró opciójához, melyek
      megfelelõ beállításával egy
      tapasztalt rendszergazda kezében drasztikusan
      növelhetõ a rendszer teljesítménye.  A
      &man.sysctl.8; alkalmazásával több mint
      ötszáz rendszerszintû változó
      kérdezhetõ le és állítható
      be.</para>

    <para>A &man.sysctl.8; két funkciót rejt
      magában: a rendszer beállításainak
      lekérdezését és
      módosítását.</para>

    <para>Így nézhetjük meg az összes
      lekérdezhetó változót:</para>

    <screen>&prompt.user; <userinput>sysctl -a</userinput></screen>

    <para>Így kérhetjük egy konkrét
      változó, például a
      <varname>kern.maxproc</varname>
      értékét:</para>

    <screen>&prompt.user; <userinput>sysctl kern.maxproc</userinput>
kern.maxproc: 1044</screen>

    <para>Egy adott változó értékének
      módosításához pedig használjuk
      a
      <replaceable>változó</replaceable>=<replaceable>érték</replaceable>
      felírást:</para>

    <screen>&prompt.root; <userinput>sysctl kern.maxfiles=5000</userinput>
kern.maxfiles: 2088 -&gt; 5000</screen>

    <para>A sysctl változók értékei lehetnek
      karakterláncok, számok és logikai
      értékek (ahol az <literal>1</literal> az igennek, a
      <literal>0</literal> a nemnek felel meg).</para>

    <para>Ha a számítógép
      indításakor automatikusan be akarunk
      állítani bizonyos változókat, akkor
      vegyük fel ezeket az <filename>/etc/sysctl.conf</filename>
      állományba.  Ennek pontosabb részleteit a
      &man.sysctl.conf.5; man oldalon és a <xref
      linkend="configtuning-sysctlconf"/>ban találhatjuk
      meg.</para>

  <sect2 id="sysctl-readonly">
    <sect2info>
      <authorgroup>
	<author>
	 <firstname>Tom</firstname>
	 <surname>Rhodes</surname>
	 <contrib>Írta: </contrib>
	</author>
      </authorgroup>
    </sect2info>

    <title>A &man.sysctl.8; írásvédett
      értékei</title>

    <para>Egyes esetekben szükséges lehet a &man.sysctl.8;
      írásvédett változóinak
      módosítása.  Habár gyakran
      elengedhetetlen, ezt kizárólag csak a rendszer
      (újra)indításakor tudjuk megtenni.</para>

    <para>Például egyes laptopoknál a
      &man.cardbus.4; eszköz nem próbálkozik
      több memóriaterület használatával,
      ezért egy ehhez hasonló hibával
      leáll:</para>

    <screen>cbb0: Could not map register memory
device_probe_and_attach: cbb0 attach returned 12</screen>

    <para>Az ilyen és ehhez hasonló esetekben gyakran
      olyan &man.sysctl.8; változók alapértelmezett
      értékeit kellene megváltoztatnunk, amelyek
      írásvédettek.  Ilyenkor tegyük az
      érintett &man.sysctl.8; változó
      <quote>objektumazonosítóját</quote> (OID)
      és a hozzá tartozó értéket a
      <filename>/boot/loader.conf</filename>
      állományunkba.  Az alapértelmezéseket
      a <filename>/boot/defaults/loader.conf</filename>
      állományban találjuk meg.</para>

    <para>A fentebb tárgyalt probléma
      megoldásához a felhasználónak a
      <option>hw.pci.allow_unsupported_io_range=1</option>
      értéket kell beállítania az elõbb
      említett állományban.  Ezután
      már a &man.cardbus.4; megfelelõen fog
      mûködni.</para>
    </sect2>
  </sect1>

  <sect1 id="configtuning-disk">
    <title>A lemezek finomhangolása</title>

    <sect2>
      <title>Sysctl változók</title>

      <sect3>
	<title><varname>vfs.vmiodirenable</varname></title>

	<indexterm><primary><varname>vfs.vmiodirenable</varname></primary></indexterm>

	<para>A <varname>vfs.vmiodirenable</varname> sysctl
	  változó értéke lehet 0 (ki) vagy 1
	  (be, és ez az alapértelmezés is).  Ez a
	  változó vezérli a könyvtárak
	  gyorsítótárazását a
	  rendszerben.  A könyvtárak többsége
	  kis méretû, így az
	  állományrendszerbõl csak egyetlen
	  (általában 1&nbsp;KB méretû)
	  darabkát használnak és még
	  ennél is kevesebbet (általában
	  512&nbsp;byte-ot) a pufferben.  A változó
	  kikapcsolt (avagy 0) értéke mellett a puffer
	  csak rögzített számú
	  könyvtárat táraz be még abban az
	  esetben is, amikor temérdek mennyiségû
	  memória áll a rendelkezésére.  Ha
	  viszont (az 1 értékkel)
	  engedélyezzük, akkor a rendszer a
	  könyvtárak tárazására
	  felhasználja a virtuális
	  memóriában pufferelt lapokat is, amivel
	  lényegében az összes elérhetõ
	  memóriát a könyvtárak
	  tárazására fordítja.  Ilyenkor
	  azonban az egyes könyvtárak
	  tárazására használt legkisebb
	  memóriaterület a fizikai lapmérettel
	  egyezik meg (ami általában 4&nbsp;KB) és
	  nem 512&nbsp;byte.  Abban az esetben javasoljuk ennek a
	  beállításnak a használatát,
	  ha olyan szolgáltatásokkal dolgozunk, amelyek
	  nagy számú állománnyal dolgoznak
	  egyszerre.  Ilyen szolgáltatások többek
	  közt a webes gyorsítótárak, nagyobb
	  levelezõrendszerek és hírrendszerek.  Az
	  opció engedélyezése alapvetõen nem
	  veti vissza a rendszer teljesítményét
	  még akkor sem, ha ezzel memóriát
	  pazarlunk el, de ezt igazából érdemes
	  kikísérletezni.</para>
      </sect3>

     <sect3>
	<title><varname>vfs.write_behind</varname></title>

	<indexterm><primary><varname>vfs.write_behind</varname></primary></indexterm>

	<para>A <varname>vfs.write_behind</varname> sysctl
	  változó alapértelmezett
	  értéke <literal>1</literal> (bekapcsolt).  Ez
	  arra utasítja az állományrendszert, hogy
	  csak akkor küldje ki az adatokat az eszközre, ha
	  belõlük teljes fürtök gyûltek
	  össze.  Ez jellemzõ módon nagyobb
	  szekvenciális állományok
	  írása esetén kedvezõ.  Arra
	  szolgál, hogy segítségével el
	  lehessen kerülni az I/O túlságosan gyakori
	  módosítások okozta
	  terhelését.  Bizonyos
	  körülmények közt ez azonban
	  lassíthatja a futó programok
	  mûködését, ezért ilyenkor
	  érdemes megfontolni a
	  kikapcsolását.</para>
       </sect3>

       <sect3>
	<title><varname>vfs.hirunningspace</varname></title>

	<indexterm><primary><varname>vfs.hirunningspace</varname></primary></indexterm>

	<para>A <varname>vfs.hirunningspace</varname> sysctl
	  változó értéke azt adja meg, hogy
	  tetszõleges számú
	  példánynál rendszerszinten mekkora
	  mértékû írási mûvelet
	  irányítható át a
	  lemezvezérlõk soraiba.  Az
	  alapértelmezés többnyire elegendõ, de
	  olyan gépeken, ahol sok lemez dolgozik egyszerre, ez az
	  érték négy vagy öt
	  <emphasis>megabyte-ra</emphasis> is felszökhet!
	  Hozzátennénk, hogy ha ezt az
	  értéket túlságosan nagyra
	  állítjuk (és így
	  túllépjük a puffer írási
	  küszöbértékét), akkor ezzel
	  hihetetlenül gyenge fürtözési
	  teljesítményt nyerünk.  Semmiképp se
	  állítsuk túlzottan nagy
	  értékre!  A nagyobb írási
	  értékek a velük párhuzamos
	  olvasások számára
	  késleltetést is jelentenek.</para>

	<para>Találhatunk még más egyéb
	  pufferelési és
	  gyorsítótárazási sysctl
	  változókat, azonban ezek
	  megváltoztatását egyáltalán
	  nem javasoljuk, mivel a virtuális memória
	  alrendszer kiválóan tudja
	  önállóan állítani ezeket a
	  paramétereit.</para>
       </sect3>

       <sect3>
	<title><varname>vm.swap_idle_enabled</varname></title>

	<indexterm><primary><varname>vm.swap_idle_enabled</varname></primary></indexterm>

	<para>A <varname>vm.swap_idle_enabled</varname> sysctl
	  változó módosítása olyan
	  nagyobb többfelhasználós rendszerekben
	  bizonyulhat hasznosnak, ahol sok felhasználó
	  lép be és lép ki a rendszerbe és
	  sok az üresjáratban futó program.  Az ilyen
	  jellegû rendszerek hajlamosak nagy mennyiségû
	  folyamatos terhelést mérni a tartalékolt
	  szabad memóriára.  A
	  beállítás
	  engedélyezésével, valamint a
	  <varname>vm.swap_idle_threshold1</varname> és a
	  <varname>vm.swap_idle_threshold2</varname>
	  változókon keresztül a kilapozás
	  <quote>reakcióidejének</quote> alkalmas
	  behangolásával a megszokottnál gyorsabban
	  lenyomhatjuk az üresjáratban dolgozó
	  programokhoz tartozó memórialapok
	  prioritását, amivel a kilapozásokat
	  vezérlõ démon kezére
	  játszunk.  Azonban tényleg csak akkor
	  engedélyezzük ezt a lehetõséget, ha
	  valóban szükségünk van rá,
	  mivel így a memóriát jóval
	  elõbb lapozzuk ki és ezzel több
	  lapozóállományt és
	  lemezteljesítményt emésztünk fel.
	  Kisebb rendszerekben jól behatárolható a
	  hatása, azonban a nagyobb rendszerekben, ahol
	  már eleve visszafogott mértékû
	  lapozás történik, ez a
	  beállítás lehetõvé teszi a
	  virtuális memóriát kezelõ alrendszer
	  számára, hogy könnyedén ki-
	  és be rakosgasson komplett futó programokat a
	  memóriába.</para>
       </sect3>

      <sect3>
	<title><varname>hw.ata.wc</varname></title>

	<indexterm><primary><varname>hw.ata.wc</varname></primary></indexterm>

	<para>A &os;&nbsp;4.3 egyszer már kacérkodott az
	  IDE-lemezek írási pufferének
	  kikapcsolásával.  Ez ugyan csökkentette az
	  IDE-lemezek írási
	  sávszélességét, azonban bizonyos
	  merevlemezgyártók
	  gondatlanságából eredõ súlyos
	  adatvesztések miatt szükséges volt a
	  használata.  A gond ezzel kapcsolatban ott van, hogy
	  egyes IDE-meghajtók hazudnak az írások
	  teljesítésérõl.  A lemezek
	  írási
	  gyorsítótárazásának
	  bekapcsolásával az IDE-meghajtók nem csak
	  az írások sorrendjét rendezik át,
	  hanem nagyobb terhelés esetén egyes blokkokat
	  jóval késõbb is rögzítenek.
	  Ezért a rendszer esetleges összeomlása vagy
	  egy áramkimaradás súlyos károkat
	  okozhat az állományrendszerben.  A &os;
	  úgy döntött, hogy a
	  megbízhatóságot választja.  Sajnos
	  ez olyan nagyságú
	  teljesítményvesztést okozott, hogy a
	  következõ kiadásban már
	  kénytelenek voltunk alapértelmezés
	  szerint is visszakapcsolni ezt a lehetõséget.  A
	  <varname>hw.ata.wc</varname> nevû sysctl
	  változó vizsgálatával
	  ellenõrizhetjük a rendszerünkön
	  érvényes alapértelmezett
	  beállítást.  Amennyiben az IDE
	  írások
	  gyorsítótárazása nem
	  engedélyezett, akkor ezt a változó
	  értékének 1-re
	  állításával
	  állíthatjuk vissza.  Ezt a rendszer
	  indításakor a rendszerbetöltõben
	  tehetjük meg.  A rendszermag indítása
	  után ennek már nincs hatása.</para>

	<para>A részleteket a &man.ata.4; man oldalon tudhatjuk
	  meg.</para>
      </sect3>

      <sect3>
	<title><literal>SCSI_DELAY</literal>
	  (<varname>kern.cam.scsi_delay</varname>)</title>

	<indexterm><primary><varname>kern.cam.scsi_delay</varname></primary></indexterm>

	<indexterm>
	  <primary>a rendszermag
	    beállításai</primary>
	  <secondary><literal>SCSI_DELAY</literal></secondary>
	</indexterm>

	<para>A rendszermag <literal>SCSI_DELAY</literal> nevû
	  beállítása a rendszer
	  indulásának idejét hivatott
	  mérsékelni.  Az alapértelmezett
	  értéke viszonylag magas, innen származik
	  a rendszer indítása során keletkezõ
	  <literal>15</literal> másodperces
	  csúszás.  Általában az is
	  megfelelõ, ha ezt visszavesszük az
	  <literal>5</literal> értékre (fõleg a
	  modernebb meghajtók számára).  A &os;
	  újabb (5.0 vagy késõbbi)
	  változataiban ez az érték már a
	  <varname>kern.cam.scsi_delay</varname> sysctl
	  változó értékével is
	  megadható a rendszer indításakor.
	  Azonban ügyeljünk rá, hogy mind a
	  finomhangoláshoz használt változó,
	  mind pedig rendszermag beállítása
	  <emphasis>ezredmásodpercben</emphasis> és
	  <emphasis>nem</emphasis>
	  <emphasis>másodpercben</emphasis> értelmezi ezt
	  az értéket.</para>
      </sect3>
    </sect2>

    <sect2 id="soft-updates">
      <title>Soft Updates</title>

      <indexterm><primary>Soft Updates</primary></indexterm>
      <indexterm><primary>tunefs</primary></indexterm>

      <para>A &man.tunefs.8; nevû program használható
	az állományrendszerek
	finomhangolására.  Nagyon sok opciót
	találhatunk benne, de itt most csak a <quote>Soft
	Updates</quote> ki- és bekapcsolásával
	foglalkozunk, amit a következõ módon
	tehetünk meg:</para>

      <screen>&prompt.root; <userinput>tunefs -n enable /allomanyrendszer</userinput>
&prompt.root; <userinput>tunefs -n disable /allomanyrendszer</userinput></screen>

      <para>Amíg egy állományrendszer
	csatlakoztatott állapotban van, addig nem
	módosítható a &man.tunefs.8; paranccsal.  A
	Soft Updates bekapcsolására ezért az a
	legalkalmasabb idõpont, amikor
	egyfelhasználós módban vagyunk és
	még egyetlen partíciót sem
	csatlakoztattunk.</para>

      <para>A Soft Updates beállítás
	engedélyezése a memóriában pufferelt
	gyorsítótáron keresztül jelentõs
	mértékben fokozza a metaadatok
	teljesítményét, elsõsorban az
	állományok létrehozását
	és törlését.  A Soft Updates
	használatát ezért minden
	állományrendszer esetén ajánljuk.  A
	Soft Updates alkalmazásának két rossz
	oldalára kell tekintettel lennünk.
	Elõször is a Soft Updates a rendszer
	összeomlása esetén ugyan garantálja az
	állományrendszer konzisztenciáját,
	de könnyen elképzelhetõ, hogy több
	másodperccel (vagy akár egy egész perccel!)
	hátrébb jár a fizikai lemez
	frissítésében.  Másodszor a Soft
	Updates késlelteti az állományrendszer
	blokkjainak felszabadítását.  Ha van egy
	olyan állományrendszerünk (mint
	például a rendszer
	indításához használt
	gyökér partíció), ami már
	majdnem betelt, akkor egy nagyobb frissítés,
	például a <command>make installworld</command>
	parancs kiadása, során az
	állományrendszer egyszerûen kifogy a
	helybõl és így a frissítés
	meghiúsul.</para>

      <sect3>
	<title>Bõvebben a Soft Updates
	  mûködésérõl</title>

	<indexterm>
	  <primary>Soft Updates</primary>
	  <secondary>részletei</secondary>
	</indexterm>

	<para>Két hagyományos
	  megközelítés létezik az
	  állományrendszerek metaadatainak
	  visszaírására.  (A metaadatok
	  módosításakor olyan nem adatot
	  tartalmazó blokkok változnak meg, mint
	  például az állományokra
	  vonatkozó információk vagy a
	  könyvtárak.)</para>

	<para>Eredetileg alapértelmezés szerint a
	  metaadatok változásait szinkron módon
	  írták ki.  Amikor egy könyvtár
	  megváltozott, a rendszer egészen addig
	  várt, amíg ez a változás a lemezre
	  nem íródott.  Ugyanekkor az
	  állományok adatait tartalmazó pufferek
	  (az állományok tartalma) átkerültek
	  a pufferelt gyorsítótárba, hogy majd
	  késõbb, aszinkron módon kerüljenek
	  kiírásra.  Ennek az
	  implementációnak a biztonságos
	  mûködés volt az elõnye, mivel így
	  a metaadatok még akkor is konzisztens állapotban
	  maradtak, amikor valamilyen hiba következett be.
	  Tehát egy állomány vagy teljesen
	  létrejött vagy egyáltalán nem.  Ha
	  az állományhoz tartozó blokkok már
	  nem tudtak kijutni a
	  gyorsítótárból az
	  összeomlás ideje elõtt, akkor az &man.fsck.8;
	  felismerte ezt a helyzetet és az
	  állományrendszer ilyen jellegû
	  hibáját úgy orvosolta, hogy az adott
	  állomány méretét nullára
	  állította.  Ezenkívül még az
	  implementációs részletek is
	  tiszták és egyszerûek maradtak.  Ennek
	  viszont hátránya, hogy a metaadatok
	  kezelése lassú.  Ha például
	  kiadunk egy <command>rm -r</command> parancsot, akkor az a
	  könyvtárban levõ állományokat
	  szekvenciálisan dolgozza fel, de minden egyes
	  változtatást (az állományok
	  törlését) csak szinkron módon
	  rögzíti a lemezre.  Ezek a
	  frissítések érintik magát a
	  könyvtárat, az állományokkal
	  kapcsolatos információkat tároló
	  táblázatot (az ún.  inode
	  táblát) és minden
	  valószínûség szerint az
	  állományok által lefoglalt blokkokat is
	  közvetve.  Hasonló megfontolások
	  élnek a nagyobb könyvtárszerkezetek
	  kibontása esetén is (<command>tar
	  -x</command>).</para>

	<para>A második lehetõség a metaadatok
	  aszinkron frissítése.  Ez az
	  alapértelmezés a Linux ext2fs és BSD-k
	  <command>mount -o async</command> opcióval
	  csatlakoztatott UFS állományrendszerei
	  esetén.  Ilyenkor minden metaadattal kapcsolatos
	  aktualizálás egyszerûen bekerült a
	  pufferelt gyorsítótárba, tehát az
	  állományok adatai és ezek a
	  típusú frissítések keverednek.
	  Ennek a megvalósításnak az az
	  elõnye, hogy nem kell megvárni, amíg a
	  metaadatok is kiíródnak a lemezre, ezért
	  a metaadatok óriási mennyiségû
	  változásával járó
	  mûveletek sokkal gyorsabban hajtódnak
	  végre, mint a szinkron esetben.  Sõt, maga az
	  implementáció is tiszta és egyszerû
	  marad, ezért a kódban megjelenõ
	  hibák beszivárgásának
	  kockázata alacsony.  A módszer
	  hátránya, hogy egyáltalán
	  semmilyen garanciát nem kapunk az
	  állományrendszer
	  konzisztenciájára.  Ha tehát egy rengeteg
	  metaadat megváltozásával
	  együttjáró mûvelet közben
	  történik valamilyen probléma
	  (áramkimaradás, vagy valaki egyszerûen
	  megnyomja a reset gombot), akkor az
	  állományrendszer elõre
	  kiszámíthatatlan állapotba kerül.  A
	  rendszer újbóli indításakor
	  ezért nincs lehetõségünk
	  megvizsgálni az állományrendszer
	  állapotát.  Elképzelhetõ, hogy az
	  állományokhoz tartozó adatok már
	  kikerültek a lemezre, miközben a rá
	  vonatkozó inode- vagy könyvtári
	  bejegyzések még nem.  Így
	  lényegében lehetetlen olyan
	  <command>fsck</command> implementációt
	  készíteni, ami képes lenne
	  eltüntetni ezt a káoszt (hiszen az ehhez
	  szükséges adatok nem állnak
	  rendelkezésre).  Ha az állományrendszer
	  helyrehozhatatlanul károsodott, akkor csak a
	  &man.newfs.8; és a biztonsági mentés
	  visszaállítása segíthet
	  rajta.</para>

	<para>Ezt általában úgy
	  küszöbölik ki, hogy az egészhez
	  hozzáteszik még a
	  <emphasis>módosított területek
	  feljegyzését</emphasis>, amit gyakran csak
	  <emphasis>naplózásnak</emphasis> (journaling)
	  neveznek, habár ezt az elnevezést nem mindenhol
	  ilyen értelemben használják, ezért
	  a tranzakciók naplózásának
	  más formáira is utalhat.  A metaadatok
	  frissítése ebben az esetben is csak szinkron
	  módon történik, de csak a lemez egy kisebb
	  területére.  Késõbb ez a
	  megfelelõ helyére kerül.  Mivel a lemez
	  naplózásra fordított része egy
	  viszonylag kis méretû, folytonos terület, a
	  lemez fejének még a megterhelõbb
	  mûveletek esetén sem kell sokat mozognia,
	  ezért valójában ez a megoldás
	  gyorsabb, mint a mezei szinkron frissítések.  Az
	  implementáció bonyolultsága
	  továbbra is jól behatárolható, a
	  velejáró hibalehetõségek
	  kockázata alacsony.  Hátránya, hogy
	  minden metaadat kétszer íródik ki
	  (egyszer a naplózási területre,
	  aztán a megfelelõ helyre), ezért a
	  hétköznapi használat során
	  <quote>visszaesés</quote> tapasztalható a
	  teljesítményben.  Másrészrõl
	  azonban egy összeomlás esetén a
	  naplózási terület
	  segítségével minden függõben
	  levõ metaadattal kapcsolatos mûvelet könnyen
	  visszafordítható vagy lezárható a
	  rendszer következõ indításakor,
	  így ezzel egy gyors
	  helyreállítást nyerünk.</para>

	<para>Kirk McKusick, a Berkeley FFS fejlesztõje ezt a
	  problémát a Soft Updates
	  segítségével hidalta át: a
	  metaadatokkal kapcsolatos minden függõben levõ
	  frissítést a memóriában tart, majd
	  ezeket rendezett sorrendben írja ki a lemezre (<quote>a
	  metaadatok rendezett frissítése</quote>).  Ennek
	  következményeképpen a metaadatok komolyabb
	  frissítése során a késõbb
	  érkezõ módosításoknak
	  lehetõségük van <quote>elkapni</quote> a
	  memóriában levõ korábbi
	  változataikat, ha azok még nem kerültek ki
	  a lemezre.  Így az összes, például
	  könyvtárakon végzett, mûvelet a
	  lemezre írás elõtt általában
	  elõször a memóriában
	  játszódik le (az adatblokkok a
	  pozíciójuknak megfelelõen kerülnek
	  rendezésre, ezért a rájuk
	  vonatkozó metaadatok elõtt nem jutnak ki a
	  lemezre).  Ha eközben a rendszer összeomlik, akkor
	  így implicit módon a <quote>napló
	  visszalapozását</quote> eredményezi:
	  minden olyan mûvelet, ami már nem tudott kijutni a
	  lemezre, meg nem történtnek számít.
	  Ezen a módon az állományrendszernek egy
	  30 és 60 másodperc közti korábbi
	  állapota marad fenn.  Az algoritmus garantálja,
	  hogy az összes használt erõforrás a
	  nekik megfelelõ bittérképekben helyesen
	  jelölõdik, a blokkokban és az inode-okban.
	  Az összeomlás után az
	  erõforrások kiosztásával
	  kapcsolatban csak egyetlen hiba léphet fel: amikor
	  olyan erõforrások jelölõdnek
	  <quote>használtnak</quote>, amelyek
	  igazából <quote>szabadok</quote>.  Az
	  &man.fsck.8; azonban képes felismerni ezeket a
	  helyzeteket és felszabadítani a nem
	  használt erõforrásokat.  A <command>mount
	  -f</command> parancs kiadásával minden
	  további következmény nélkül
	  figyelmen kívül hagyhatjuk az
	  állományrendszer félkész
	  állapotát és csatlakoztathatjuk az
	  állományrendszereket.  A használatban
	  már nem levõ erõforrások
	  felszabadításához az &man.fsck.8;
	  parancsot késõbb kell futtatni.  Ez az
	  alapötlet húzódik meg a
	  <emphasis>háttérben végzett
	  lemezellenõrzés</emphasis> mögött.  A
	  rendszer indításakor az
	  állományrendszernek csupán egy
	  <emphasis>pillanatképét</emphasis>
	  rögzítjük, és az
	  <command>fsck</command> tényleges
	  lefuttatását késõbbre toljuk.  Mivel
	  mindegyik állományrendszer
	  csatlakoztatható <quote>félkész</quote>
	  állapotban, ezért a rendszer képes
	  elindulni többfelhasználós módban.
	  Eközben a háttérben az
	  <command>fsck</command> beütemezhetõ minden olyan
	  állományrendszer számára, ahol
	  arra szükség van, hogy szabadítsa fel az
	  esetlegesen már nem használt
	  erõforrásokat.  (Így a Soft Updates
	  opciót nem alkalmazó
	  állományrendszerek esetén továbbra
	  is szükség van az elõtérben
	  elvégzett <command>fsck</command> parancsra.)</para>

	<para>A módszer elõnye, hogy így a
	  metaadatokkal kapcsolatos mûveletek közel olyan
	  gyorsak, mint az aszinkron módon végzett
	  frissítések (tehát gyorsabb, mintha
	  <emphasis>naplóznánk</emphasis>, ami ugye minden
	  metaadatot kétszer ír ki).  A
	  hátránya a bonyolultabb kód (ami miatt
	  növekszik az olyan hibák lehetõsége,
	  amelyek érzékenyen
	  befolyásolhatják a felhasználói
	  adatok elvesztését) és a nagyobb
	  memóriaigény.  Ezenkívül még
	  van néhány olyan egyéni jellemzõje,
	  amelyet meg kell szokni.  A rendszer összeomlása
	  után az állományrendszer valamivel
	  <quote>régebbi</quote> lesz.  Amikor pedig megszokott
	  szinkron megközelítés szerint az
	  <command>fsck</command> lefutása után nulla
	  méretû állományok
	  jönnének létre, ezek az
	  állományok a Soft Updates esetén
	  egyáltalán meg sem jelennek, mivel sem a
	  rájuk vonatkozó metaadatok, sem pedig a
	  tartalmuk nem került ki a lemezre.  Egy
	  <command>rm</command> lefuttatása után a
	  lemezterület addig nem kerül
	  felszabadításra, amíg a
	  frissítések teljesen rá nem kerülnek
	  a lemezre.  Ez nagyobb mennyiségû adat
	  telepítésekor gondokat okozhat egy olyan
	  állományrendszeren, ahol nincs elegendõ
	  hely az állományok kétszeri
	  tárolására.</para>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="configtuning-kernel-limits">
    <title>A rendszermag korlátainak
      finomhangolása</title>

    <indexterm>
      <primary>finomhangolás</primary>
      <secondary>a rendszermag korlátai</secondary>
    </indexterm>

    <sect2 id="file-process-limits">
      <title>Az állományok és a futó
	programok korlátozásai</title>

      <sect3 id="kern-maxfiles">
	<title><varname>kern.maxfiles</varname></title>

	<indexterm><primary><varname>kern.maxfiles</varname></primary></indexterm>

	<para>A <varname>kern.maxfiles</varname> értéke a
	  rendszerünk igényeinek megfelelõen
	  növelhetõ vagy csökkenthetõ.  Ez a
	  változó adja meg a rendszerünkben levõ
	  állományleírók maximális
	  számát.  Amikor az
	  állományleírókat
	  tároló táblázat megtelik, a
	  rendszer üzenetpufferében egy <errorname>file:
	  table is full</errorname> üzenet jelenik meg, amit a
	  <command>dmesg</command> paranccsal tudunk
	  megnézni.</para>

	<para>Minden megnyitott állomány,
	  csatlakozás vagy FIFO elhasznál egy
	  állományleírót.  Egy
	  nagyméretû szerver könnyen
	  felemészthet több ezernyi
	  állományleírót attól
	  függõen, hogy milyen és mennyi
	  szolgáltatást futtat egymás
	  mellett.</para>

	<para>A &os; korábbi kiadásaiban a
	  <varname>kern.maxfiles</varname> a rendszermag
	  beállításait tartalmazó
	  állomány <option>maxusers</option> (a
	  rendszerben egyszerre jelenlevõ
	  felhasználók maximumának)
	  értékébõl származott,
	  tehát a <varname>kern.maxfiles</varname> a
	  <option>maxusers</option> értékével
	  arányosan növekszik.  Amikor
	  készítünk egy saját rendszermagot,
	  mindig érdemes a rendszerünk
	  használatának megfelelõen
	  beállítani ezt az értéket, mivel a
	  rendszermag ebbõl a számból
	  határozza meg a legtöbb elõre
	  meghatározott korlátait.  Mivel még egy
	  komoly szerveren sem jelentkeznek be egyszerre 256
	  felhasználónál többen,
	  nagyjából ugyanannyi erõforrásra van
	  szüksége, mint egy nagyobb webszervernek.</para>

	<para>A <varname>kern.maxusers</varname> értéke a
	  rendelkezésre álló
	  memóriának megfelelõen
	  magától méretezõdik a rendszer
	  indításakor, és amit futás
	  közben csak a <varname>kern.maxusers</varname> sysctl
	  változó írásvédett
	  értékének
	  lekérdezésébõl tudhatunk meg.  Egyes
	  oldalak üzemeltetése a
	  <varname>kern.maxusers</varname> így
	  megállapított
	  értékétõl nagyobbat vagy
	  éppen kisebbet igényel, ezért a
	  betöltéskor minden gond nélkül
	  át lehet állítani 64, 128 vagy 256
	  értékûre.  Senkinek sem ajánljuk,
	  hogy 256 felé menjen, hacsak tényleg nincs
	  szüksége ekkora mennyiségû
	  állományleíróra.  A
	  <varname>kern.maxusers</varname>
	  függvényében beállított
	  alapértelmezett értékek tetszõleges
	  módon átállíthatóak a
	  rendszer indításakor vagy futás
	  közben a <filename>/boot/loader.conf</filename>
	  módosításával (az ide
	  kapcsolódó javaslatokról bõvebben
	  lásd a &man.loader.conf.5; man oldalt vagy a
	  <filename>/boot/defaults/loader.conf</filename>
	  állományt) illetve a leírás
	  más részén megadott módok
	  szerint.</para>

	<para>A korábbi kiadásokban úgy lehet
	  önszabályozóra állítani a
	  <literal>maxusers</literal> beállítást,
	  ha explicit módon <literal>0</literal>
	  értéket adtunk meg neki
	  <footnote>
	    <para>Az önszabályozó algoritmus a
	      <literal>maxusers</literal> értékét a
	      rendszerben található
	      memóriának megfelelõen legalább
	      32-re, legfeljebb 384-re állítja.</para>
	  </footnote>.  A <literal>maxusers</literal> paraméter
	  beállításakor érdemes
	  legalább 4-et megadni, különösen akkor,
	  ha használjuk az X Window Systemet vagy szoftvereket
	  fordítunk le.  Azért van erre
	  szükség, mert a <literal>maxusers</literal>
	  értéke által szabályozott
	  legfontosabb mennyiség az egyszerre futtatható
	  programok táblázatának maximális
	  mérete, amelyet így számolunk ki:
	  <literal>20 + 16 * maxusers</literal>.  Tehát ha a
	  <literal>maxusers</literal> értékét 1-re
	  állítjuk be, akkor az elõbbi képlet
	  értelmében csak 36 programunk futhat
	  egymással párhuzamosan, beleértve mindazt
	  a kb.  18 programot, amelyek a rendszerrel együtt
	  indulnak, illetve még azt a további 15
	  programot, amelyeket az X Window System
	  használatával indítunk el.  Még
	  egy olyan egyszerû dolog is, mint például
	  egy man oldal megnézése, legalább kilenc
	  programot indít el a szûréshez,
	  kitömörítéshez és
	  megnézéshez.  Azonban ha a
	  <literal>maxusers</literal> értékét 64-re
	  állítjuk, akkor egyszerre akár már
	  1044 programot futtathatunk, ami szinte mindenre
	  elegendõ.  Ha persze egy új program
	  indításakor kapunk egy <errortype>proc table
	  full</errortype> típusú üzenetet vagy nagy
	  számú konkurens felhasználóval
	  futtatunk szervert (ilyen például az <hostid
	  role="fqdn">ftp.FreeBSD.org</hostid>), akkor érdemes
	  növelni ezt a számot és
	  újrafordítani a rendszermagot.</para>

	<note>
	  <para>A <literal>maxusers</literal> <emphasis>nem</emphasis>
	    korlátozza a számítógépre
	    egyszerre bejelentkezni képes
	    felhasználók számát.
	    Egyszerûen csak beállítja
	    néhány táblázat
	    méretét és az egyszerre
	    futtatható programok mennyiségét a
	    rendszert egyidejûleg használni
	    kívánó felhasználók
	    maximális számának
	    figyelembevételével.</para>
	</note>
      </sect3>

      <sect3>
	<title><varname>kern.ipc.somaxconn</varname></title>

	<indexterm><primary><varname>kern.ipc.somaxconn</varname></primary></indexterm>

	<para>Az <varname>kern.ipc.somaxconn</varname> sysctl
	  változó a beérkezõ TCP kapcsolatokat
	  fogadó sor hosszát határozza meg.  Ennek
	  az alapértelmezett értéke
	  <literal>128</literal>, ami az új kapcsolatok
	  megbízható kezeléséhez
	  általában kevés egy erõsen leterhelt
	  webszerver számára.  Ilyen helyzetekben ezt az
	  értéket javasolt <literal>1024</literal>-re vagy
	  még annál is nagyobbra állítani.
	  Az egyes szolgáltatások démonai ugyan
	  szintén korlátozni szokták a
	  fogadósoruk méretét
	  (például a &man.sendmail.8; vagy az
	  <application>Apache</application>), de gyakran találunk
	  a beállításai között olyat,
	  amivel ennek a sornak a mérete növelhetõ.  A
	  nagyobb fogadósorok mellesleg jó
	  szolgálatot tesznek a Denial of Service
	  (<abbrev>DoS</abbrev>) típusú
	  támadásokkal szemben is.</para>
      </sect3>

    </sect2>
    <sect2 id="nmbclusters">
      <title>Hálózati korlátozások</title>

      <para>A rendszermag <literal>NMBCLUSTERS</literal> nevû
	beállítása szab határt a rendszer
	részére elérhetõ
	memóriapufferek mennyiségének.  Egy nagyobb
	forgalmú szerver esetén a pufferek alacsony
	száma gátat szabhat a &os;
	képességeinek.  Minden klaszter
	nagyjából 2&nbsp;KB memóriát takar,
	így az 1024-es érték azt jelenti, hogy a
	rendszermag memóriájából 2
	megabyte-ot fordítunk a hálózati
	pufferelésre.  Egyszerûen
	kiszámítható, mennyire is van
	szükségünk: ha van egy webszerverünk,
	amely egyszerre legfeljebb 1000 párhuzamos kapcsolatot
	fogad, és minden kapcsolat lefoglal 16&nbsp;KB-ot a
	fogadó-, valamint újabb 16&nbsp;KB-ot a
	küldõpuffer számára, akkor
	megközelítõleg 32&nbsp;MB-nyi
	hálózati pufferre lesz szükségünk
	a webszerver hatékony
	mûködéséhez.  Ezt az
	értéket gyakran még érdemes
	megszorozni kettõvel, így
	2&nbsp;x&nbsp;32&nbsp;MB&nbsp;/&nbsp;2&nbsp;KB&nbsp;=
	64&nbsp;MB&nbsp;/&nbsp;2&nbsp;KB&nbsp;= 32768.  Több
	memóriával rendelkezõ
	számítógépek esetén egy 4096
	és 32768 közti értéket javaslunk.
	Semmilyen körülmények között ne
	adjunk meg ennél nagyobb értéket, mert
	ezzel a rendszer már az indítása
	során összeomolhat.  A &man.netstat.1;
	<option>-m</option> beállításával
	ellenõrizhetjük a hálózati klaszterek
	kihasználtságát.</para>

      <para>A <varname>kern.ipc.nmbclusters</varname>
	változó értékét a rendszer
	indításakor érdemes megváltoztatni.
	A &os; korábbi változataiban ehhez a rendszermag
	<literal>NMBCLUSTERS</literal> nevû &man.config.8;
	paraméterének
	módosítására van
	szükségünk.</para>

      <para>Az olyan forgalmasabb szervereken, ahol sokat
	használják a &man.sendfile.2;
	rendszerhívást, szükségünk lehet
	a &man.sendfile.2; által használt pufferek
	számának növelésére a
	rendszermag <literal>NFSBUFS</literal> nevû
	konfigurációs paraméterén vagy a
	<filename>/boot/loader.conf</filename> állományon
	keresztül (lásd &man.loader.8;).  Amikor a
	futó programok közül sokan vannak
	<literal>sfbufa</literal> állapotban, akkor az
	egyértelmûen annak a jele, hogy ezen a
	paraméteren állítanunk kell.  A
	<varname>kern.ipc.nsfbufs</varname> egy
	írásvédett változót, amelyet
	a rendszermag állít be.  Ez a paraméter
	névlegesen a <varname>kern.maxusers</varname>
	változó értékének
	megfelelõen változik, de bizonyos esetekben
	ettõl függetlenül önállóan
	kell behangolni.</para>

      <important>
	<para>Annak ellenére, hogy egy socketet
	  blokkolásmentesnek jelöltünk meg, a
	  &man.sendfile.2; meghívása egy
	  blokkolásmentes socketre blokkolódást
	  eredményezhet egészen addig, amíg a
	  használatához elegendõ <literal>struct
	  sf_buf</literal> struktúra össze nem
	  gyûlik.</para>
      </important>

      <sect3>
	<title><varname>net.inet.ip.portrange.*</varname></title>

	<indexterm><primary>net.inet.ip.portrange.*</primary></indexterm>

	<para>A <varname>net.inet.ip.portrange.*</varname> sysctl
	  változók vezérlik a TCP és UDP
	  csatlakozásokhoz automatikusan hozzárendelt
	  portszámok tartományát.  Három
	  ilyen tartomány létezik: az alsó, az
	  alapértelmezett és a felsõ
	  tartomány.  A legtöbb hálózati
	  program a <varname>net.inet.ip.portrange.first</varname>
	  és <varname>net.inet.ip.portrange.last</varname>
	  változók által rendre az 1024-tõl
	  5000-ig kijelölt alapértelmezett tartományt
	  használja.  A kimenõ kapcsolatok is
	  rögzített porttartományokat követnek,
	  és adott körülmények mellett be lehet
	  állítani úgy a rendszerünket, hogy
	  ezen kívül osszon ki portokat.  Ez a
	  legtöbbször akkor fordul elõ, amikor egy
	  erõsen leterhelt webproxyt mûködtetünk.  A
	  porttartományok nem okoznak gondot olyan
	  szervereknél, ahol általában
	  bejövõ kapcsolatokra lehet számítani,
	  tehát például webszerverek esetén,
	  vagy ahol korlátozott a kimenõ kapcsolatok
	  száma, mint például a levelek
	  továbbításánál.  Ha olyan
	  helyzetbe keverednénk, ahol már kifutunk a
	  felhasználható portokból, a
	  <varname>net.inet.ip.portrange.last</varname>
	  mérsékelt növelésével
	  javasolt kitörni.  Ilyenkor a <literal>10000</literal>,
	  <literal>20000</literal> vagy <literal>30000</literal>
	  értékek elfogadhatóak.  Amikor
	  megváltoztatjuk a porttartományok
	  határait, elõtte mindig gondoljuk át,
	  milyen hatással lehet ez a tûzfalra.  Egyes
	  tûzfalak blokkolhatnak bizonyos tartományokat
	  (általában az alacsonyabbakat) és arra
	  számítanak, hogy a rendszerek a kimenõ
	  kapcsolatokhoz a nagyobb számú portokat
	  használják &mdash; ebbõl kifolyólag
	  nem ajánlott csökkenteni a
	  <varname>net.inet.ip.portrange.first</varname>
	  értékét.</para>
      </sect3>

      <sect3>
	<title>A TCP
	  sávszélesség-késletetés
	  szorzat</title>

	<indexterm>
	  <primary>A TCP
	    sávszélesség-késleltetés
	    szorzatának korlátozása</primary>
	  <secondary><varname>net.inet.tcp.inflight.enable</varname></secondary>
	</indexterm>

	<para>A TCP
	  sávszélesség-késleltetés
	  szorzat korlátozása hasonlít a NetBSD-ben
	  megtalálható TCP/Vegas
	  implementációhoz.  A
	  <varname>net.inet.tcp.inflight.enable</varname> sysctl
	  változó <literal>1</literal>-re
	  állításával lehet
	  engedélyezni.  A rendszer ilyenkor minden egyes
	  kapcsolathoz megpróbálja
	  kiszámítani a
	  sávszélesség-késleltetés
	  szorzatot és az optimális átviteli
	  sebesség fenntartásához illeszkedõen
	  korlátozni a hálózat felé
	  küldött adatok sorának hosszát.</para>

	<para>Ez a lehetõség még olyankor bizonyulhat
	  hasznosnak, amikor modemen, Gigabit Etherneten vagy
	  nagysebességû WAN (vagy bármilyen
	  más nagy
	  sávszélesség-késleltetés
	  szorzattal bíró)
	  összeköttetéseken keresztül
	  küldünk át adatokat, különösen
	  abban az esetben, amikor ablakméretezést is
	  használnunk vagy nagy küldési ablakot
	  állítottunk be.  Az
	  engedélyezésekor ne felejtsük el
	  <varname>net.inet.tcp.infligt.debug</varname>
	  változót sem beállítani
	  <literal>0</literal>-ra (amivel így kikapcsoljuk a
	  nyomkövetést),éles használat
	  esetén pedig elõnyös lehet a
	  <varname>net.inet.cp.inflight.min</varname>
	  változót legalább
	  <literal>6144</literal>-re állítani.  Azonban
	  hozzátesszük, hogy
	  összeköttetéstõl függõen a
	  nagy minimum értékek tulajdonképpen
	  kikapcsolják a
	  sávszélességkorlátozást.
	  Ez a korlátozási lehetõség
	  csökkenti a közbensõ út adatainak
	  és csomagváltásokhoz tartozó
	  soroknak a méretét, miközben csökkenti
	  a helyi számítógép
	  felületén felépülõ sorok
	  méretét is.  Ha kevesebb csomagot rakunk be a
	  sorba, akkor az interaktív kapcsolatok,
	  különösen a lassabb modemek esetében,
	  kisebb <emphasis>körbejárási
	  idõvel</emphasis> (Round Trip Time) mûködnek.
	  Továbbá megemlítenénk, hogy ez a
	  lehetõség csak az adatok
	  küldésére (feltöltésére,
	  szerveroldalra) van hatással.  Semmilyen
	  befolyása nincs az adatok fogadására
	  (letöltésére).</para>

	<para>A <varname>net.inet.tcp.inflight.stab</varname>
	  állítgatása <emphasis>nem</emphasis>
	  ajánlott.  A paraméter értéke
	  alapértelmezés szerint 20, ami legfeljebb 2
	  csomag hozzáadását jelenti a
	  sávszélesség-késleltetés
	  szorzat ablakának kiszámításakor.
	  Erre a kiegészítõ ablakra azért van
	  szükség, hogy stabilizálni tudjuk vele az
	  algoritmust és javítani tudjuk a
	  változó feltételekre adott
	  reakciót, de lassabb összeköttetések
	  esetében nagyobb ping idõket is
	  eredményezhet (habár ezek még így
	  kisebbek, mint ha nem használnánk az
	  algoritmust).  Ilyen esetekben megpróbálhatjuk
	  15-re, 10-re vagy esetleg 5-re visszavenni a paraméter
	  értékét, de ekkor a kívánt
	  hatás eléréséhez minden bizonnyal
	  a <varname>net.inet.tcp.inflight.min</varname>
	  értékét is redukálunk kell majd
	  (például 3500-ra).  Ezen paraméterek
	  megváltoztatását csak végsõ
	  esetben ajánljuk!</para>
      </sect3>
    </sect2>

    <sect2>
      <title>Virtuális memória</title>

      <sect3>
	<title><varname>kern.maxvnodes</varname></title>

	<para>A vnode egy állomány vagy
	  könyvtár belsõ
	  ábrázolása.  Ennek megfelelõen a
	  vnode-ok számának növelésével
	  az operációs rendszer spórolni tud a
	  lemezmûveletekkel.  Ezt általában maga az
	  operációs rendszer szabályozza, és
	  nincs szükség a finomhangolására.
	  Néhány esetben, amikor a lemezmûveletek
	  jelentik a rendszerben a szûk keresztmetszetet és
	  kezdenek elfogyni a vnode-ok, szükség lehet ennek
	  a számnak a növelésére.  Ehhez az
	  inaktív és szabad fizikai memória
	  mennyiségét kell számításba
	  vennünk.</para>

	<para>Így kérhetjük le a pillanatnyilag
	  használatban levõ vnode-ok
	  mennyiségét:</para>

	<screen>&prompt.root; <userinput>sysctl vfs.numvnodes</userinput>
vfs.numvnodes: 91349</screen>

	<para>Így tudhatjuk meg a vnode-ok maximális
	  számát:</para>

	<screen>&prompt.root; <userinput>sysctl kern.maxvnodes</userinput>
kern.maxvnodes: 100000</screen>

	<para>Ha a vnode-ok aktuális kihasználtsága
	  megközelíti a csúcsértéket,
	  nagyjából ezerrel javasolt megnövelni a
	  <varname>kern.maxvnodes</varname>
	  értékét.  Ezután figyeljük
	  továbbra is a <varname>vfs.numvnodes</varname>
	  változását.  Ha ismét
	  felkúszik a maximális értékre,
	  akkor növeljük megint egy keveset a
	  <varname>kern.maxvnodes</varname>
	  értékén.  Eközben a &man.top.1;
	  használatával figyelhetjük a memória
	  kihasználtságának
	  növekedését is, ilyenkor tehát
	  több memóriának kell használatban
	  lennie.</para>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="adding-swap-space">
    <title>A lapozóterület
      bõvítése</title>

    <para>Nem számít, mennyire tervezünk jól
      elõre, mindig elõfordulhat, hogy a rendszerünk
      mégsem teljesíti a kitûzött
      elvárásokat.  Amennyiben további
      lapozóterület hozzáadására lenne
      szükségünk, azt igen könnyen
      megtehetjük.  Háromféleképpen
      növelhetjük a lapozásra szánt
      területet: hozzáadunk a rendszerhez egy újabb
      merevlemezes meghajtót, NFS-en keresztül lapozunk,
      vagy egy már meglevõ partíción hozunk
      létre lapozóállományt.</para>

    <para>A lapozóterület
      titkosításával, valamint annak
      lehetõségeivel és okaival kapcsolatban lapozzuk
      fel a kézikönyv <xref
      linkend="swap-encrypting"/>át.</para>

    <sect2 id="new-drive-swap">
      <title>Lapozás egy új merevlemezre</title>

      <para>A lapozóterület
	bõvítésének legjobb módja
	természetesen remek indok egy új merevlemez
	beszerzésére is.  Elvégre egy
	merevlemezt mindig fel tudunk ilyen célra
	használni.  Ha ezt a megoldást választjuk,
	elõtte ajánlott (újra) elolvasni a
	kézikönyv <xref
	linkend="configtuning-initial"/>ában a
	lapozóterületek elrendezésére
	vonatkozó javaslatokat.</para>
    </sect2>

    <sect2 id="nfs-swap">
      <title>Lapozás NFS-en keresztül</title>

      <para>NFS-en keresztül csak akkor lapozzunk, ha ezt helyi
	lemezek segítségével nem tudjuk megtenni.
	Az NFS alapú lapozás
	hatékonyságát erõsen
	behatárolja a rendelkezésre álló
	hálózati sávszélesség
	és további terheket ró az NFS
	szerverünkre is.</para>
    </sect2>

    <sect2 id="create-swapfile">
      <title>Lapozóállományok</title>

      <para>Lapozóállománynak egy adott
	méretû állományt hozzunk létre.
	Ebben a példában erre egy
	<filename>/usr/swap0</filename> nevû, 64&nbsp;MB
	méretû állományt fogunk
	használni.  Természetesen bármilyen
	más nevet is választhatunk.</para>

      <example>
	<title>Lapozóállomány
	  létrehozása &os;-ben</title>

	<orderedlist>
	  <listitem>
	    <para>Gyõzõdjünk meg róla, hogy a
	      rendszermagunk beállításai
	      között megtalálható a
	      memórialemez meghajtójának (&man.md.4;)
	      használata.  Ez a <filename>GENERIC</filename>
	      rendszermag alapból tartalmazza.</para>

	    <programlisting>device   md   # Memória "lemezek"</programlisting>
	  </listitem>

	  <listitem>
	    <para>Hozzunk létre egy
	      lapozóállományt
	      (<filename>/usr/swap0</filename>):</para>

	    <screen>&prompt.root; <userinput>dd if=/dev/zero of=/usr/swap0 bs=1024k count=64</userinput></screen>
	  </listitem>

	  <listitem>
	    <para>Állítsuk be rá a megfelelõ
	      engedélyeket
	      (<filename>/usr/swap0</filename>):</para>

	    <screen>&prompt.root; <userinput>chmod 0600 /usr/swap0</userinput></screen>
	  </listitem>

	  <listitem>
	    <para>Adjuk meg a lapozóállományt az
	      <filename>/etc/rc.conf</filename>
	      állományban:</para>

	    <programlisting>swapfile="/usr/swap0"   # Állítsuk be swapfile értékét, ha külsõ lapozóállományra van szükségünk.</programlisting>
	  </listitem>

	  <listitem>
	    <para>Indítsuk újra a
	      számítógépünket, vagy a
	      lapozóállomány azonnali
	      használtba vételéhez írjuk
	      be:</para>

	    <screen>&prompt.root; <userinput>mdconfig -a -t vnode -f /usr/swap0 -u 0 &amp;&amp; swapon /dev/md0</userinput></screen>
	  </listitem>
	</orderedlist>
      </example>

    </sect2>
  </sect1>

  <sect1 id="acpi-overview">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Hiten</firstname>
	  <surname>Pandya</surname>
	  <contrib>Írta: </contrib>
	</author>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	</author>
      </authorgroup>
    </sect1info>

    <title>Energia- és
      erõforrásgazdálkodás</title>

    <para>Fontos a hardveres erõforrásaink hatékony
      kihasználása.  Az <acronym>ACPI</acronym>
      megjelenése elõtt az operációs
      rendszerek csak nehézkesen és rugalmatlanul
      tudták kezelni a rendszer
      energiafelhasználási és
      hõszabályzási lehetõségeit.  A
      hardvert a <acronym>BIOS</acronym> kezelte, ezért a
      felhasználó kevesebbet tudott látni és
      irányítani az energiagazdálkodási
      beállításokból.  Az <emphasis>Fejlett
      energiagazdálkodás (Advanced Power Management,
      APM)</emphasis> ehhez nyújtott egy erõsen
      korlátozott felületet.  Napjaink
      operációs rendszereiben az energia- és
      erõforráskezelés az egyik legfontosabb
      alkotóelem.  Például, ha az
      operációs rendszerrel folyamatosan figyelni akarjuk
      a rendszer hõmérsékletének
      váratlan növekedését (és
      errõl figyelmeztetést kérni).</para>

    <para>A &os; kézikönyvének ezen
      szakaszában az <acronym>ACPI</acronym>-rõl adunk egy
      átfogó áttekintést, a
      végén pedig összefoglaljuk a
      témához tartozó irodalmat.</para>

    <sect2 id="acpi-intro">
      <title>Mi az ACPI?</title>

      <indexterm><primary>ACPI</primary></indexterm>
      <indexterm><primary>APM</primary></indexterm>

      <para>A speciális energia- és
	konfigurációs illesztõ felület (Advanced
	Configuration and Power Interface, avagy
	<acronym>ACPI</acronym>) gyártók egy csoportja
	által létrehozott szabvány, amely a
	hardveres erõforrások és az
	energiagazdálkodás egységes
	felületét rögzíti (innen a neve).
	Döntõ szerepet játszik a
	<emphasis>Beállítások és az
	energiagazdálkodás operációs
	rendszerek áltai
	vezérlésében</emphasis>, vagyis
	segítségével az operációs
	rendszer még nagyobb mértékben és
	rugalmassággal tudja irányítani ezeket a
	lehetõségeket.  A modern operációs
	rendszerek az <acronym>ACPI</acronym>
	felbukkanásával <quote>kitolták</quote> a
	jelenleg meglevõ Plug and Play felületek
	korlátait.  Az <acronym>ACPI</acronym> az
	<acronym>APM</acronym> közvetlen
	leszármazottja.</para>
    </sect2>

    <sect2 id="acpi-old-spec">
      <title>A Fejlett energiagazdálkodás (APM)
	hiányosságai</title>

      <para>A <emphasis>Fejlett energiagazdálkodás
	(APM)</emphasis> a rendszer által felhasznált
	energiát annak elfoglaltsága alapján
	vezérli.  Az APM-et támogató BIOS-t a
	(rendszert) gyártó állítja elõ
	és az adott hardverplatformra jellemzõ.  Az APM
	operációs rendszerben levõ meghajtója
	hozzáférést biztosít az
	<emphasis>APM szoftveres felületéhez</emphasis>,
	amivel lehetõség nyílik az energiaszintek
	kezelésére.  Az APM-et 2000 elõtt és
	körül még mindig használták egyes
	rendszerek gyártásánál.</para>

      <para>Az APM használata négy nagyobb gondot rejt
	magában.  Elõször is, az
	energiagazdálkodást a
	(gyártófüggõ) BIOS végzi el,
	és az operációs rendszernek errõl
	semmilyen ismerete nincsen.  Ennek egyik példája
	az, amikor a felhasználó az APM-et ismerõ
	BIOS-ban beállítja a merevlemezek automatikus
	kikapcsolásának idejét, majd amikor ez
	letelik, a BIOS az operációs rendszer tudta
	nélkül egyszerûen leállítja a
	lemezt.  Másodszor: az APM
	mûködését a BIOS-ban programozták
	le, és teljesen az operációs rendszer
	hatáskörén túl tevékenykedik.
	Ez azt jelenti, hogy a felhasználó csak úgy
	tudja korrigálni az APM-es BIOS-ok
	problémáit, ha frissíti az alaplapi ROM-ot.
	Ez viszont egy nagyon kockázatos folyamat, amelynek
	hibája révén a rendszerünk
	helyrehozhatatlan állapotba kerülhet.  Harmadszor:
	az APM alapvetõen egy gyártófüggõ
	megoldás, ami azt vonja maga után, hogy sok az
	átfedés (ugyanazt valósítják
	meg több módon), és ha az egyik
	gyártó BIOS-ában hibát
	találnak, akkor a másikéban az nem
	feltétlenül javítható.
	Végül, de nem utolsósorban, az APM
	alapú BIOS-okban nincs elég hely az igazán
	kifinomult energiagazdálkodási sémák
	vagy bármi más kialakítására,
	amivel a felhasználók képesek
	lennének az igényeikhez alakítani a
	számítógépet.</para>

      <para>A <emphasis>Plug and Play BIOS (PNPBIOS)</emphasis> sok
	szempontból megbízhatatlannak bizonyult.  A
	PNPBIOS ráadásul egy 16 bites megoldás,
	ezért az operációs rendszereknek 16 bites
	emulációt kell használniuk a PNPBIOS
	eszközeinek
	<quote>eléréséhez</quote>.</para>

      <para>A &os; <acronym>APM</acronym> meghajtójának
	dokumentációját az &man.apm.4; man oldalon
	találjuk.</para>
    </sect2>

    <sect2 id="acpi-config">
      <title>Az <acronym>ACPI</acronym>
	beállítása</title>

      <para>Az <filename>acpi.ko</filename> meghajtó
	alapértelmezés szerint a &man.loader.8;
	segítségével töltõdik be,
	és <emphasis>ne</emphasis> is fordítsuk bele a
	rendszermagba.  Ezt azzal tudnánk magyarázni, hogy
	modulokkal könnyebb dolgozni, például ha a
	rendszermag újrafordítása
	nélkül egy másik <filename>acpi.ko</filename>
	modult akarunk használni.  Ezzel a
	lényegében a tesztelés is
	egyszerûbbé válik.  Másik
	magyarázat, hogy a rendszer <acronym>ACPI</acronym>
	támogatása nem minden esetben mûködik
	rendesen.  Ha a rendszer indítása során
	valamilyen problémát tapasztalunk, akkor
	próbálkozzunk meg az <acronym>ACPI</acronym>
	kikapcsolásával.  Ezt a meghajtót nem lehet
	és nem is szabad kidobni a
	memóriából, mivel a hardverrel a
	rendszerbuszon keresztül tartja a kapcsolatot.  Az
	<acronym>ACPI</acronym> a
	<literal>hint.acpi.0.disabled="1"</literal> sor
	megadásával kapcsolható a
	<filename>/boot/loader.conf</filename> állományban
	vagy a &man.loader.8; parancssorában.</para>

      <note>
	<para>Az <acronym>ACPI</acronym> és az
	  <acronym>APM</acronym> nem használató egyszerre.
	  Közülük a késõbb
	  betöltött magától kilép, ha
	  észreveszi, hogy a másikuk már
	  mûködésbe lépett.</para>
      </note>

      <para>Az <acronym>ACPI</acronym> és az &man.acpiconf.8;
	használatával a rendszerünk
	készenléti módba helyezhetõ az
	<option>-s</option> valamint az <literal>1-5</literal>
	paraméterek megadásával.  Ezek
	közül is a legtöbb felhasználó
	számára csak az <literal>1</literal> vagy a
	<literal>3</literal> (állapot mentése a fizikai
	memóriába) érdekes.  Az
	<literal>5</literal> opció egy szoftveres
	kikapcsolást eredményez, ehhez
	hasonlóan:</para>

      <screen>&prompt.root; <userinput>halt -p</userinput></screen>

      <para>A további opciók a &man.sysctl.8; man
	oldaláról érhetõek el.  Ezen
	kívül még olvassuk el az &man.acpi.4;
	és &man.acpiconf.8; man oldalakat is.</para>
    </sect2>
  </sect1>

  <sect1 id="ACPI-debug">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Nate</firstname>
	  <surname>Lawson</surname>
	  <contrib>Írta: </contrib>
	</author>
      </authorgroup>
      <authorgroup>
	<author>
	  <firstname>Peter</firstname>
	  <surname>Schultz</surname>
	  <contrib>Segítségére volt még:
	    </contrib>
	</author>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	</author>
      </authorgroup>
    </sect1info>

    <title>A &os; <acronym>ACPI</acronym>
      támogatásának használata és
      nyomonkövetése</title>

    <indexterm>
      <primary>ACPI</primary>
      <secondary>problémák</secondary>
    </indexterm>

    <para>Az <acronym>ACPI</acronym> az eszközök
      felderítésének,
      energiagazdálkodásának és a
      korábban a <acronym>BIOS</acronym> által kezelt
      hardverek szabványosított
      hozzáférésének alapjaiban új
      módja.  Az <acronym>ACPI</acronym> folyamatosan
      fejlõdik, de útját az egyes alaplapok
      <firstterm><acronym>ACPI</acronym> Machine Language</firstterm>
      (<acronym>AML</acronym>) bytekód
      implementációjában megjelenõ
      hibák, a &os; rendszermag alrendszereinek
      befejezetlensége és az &intel;
      <acronym>ACPI-CA</acronym> értelmezõjében
      levõ hibák lassítják.</para>

    <para>Ez a leírás azzal a szándékkal
      készült, hogy segítsünk a
      felhasználóknak megtalálni az általuk
      tapasztalt problémák gyökerét és
      ezzel segíteni az <acronym>ACPI</acronym> fejlesztõket
      a nyomonkövetésében és
      kijavításában.  A fejlesztõk
      köszönik, hogy ezt elolvassuk és
      segédkezünk a rendszerünkkel kapcsolatban
      felmerülõ problémák
      orvosolásában!</para>

    <sect2 id="ACPI-submitdebug">
      <title>A nyomkövetési információk
	beküldése</title>

      <note>
	<para>Mielõtt beküldenénk bármilyen
	  problémát is, gondoskodjunk róla, hogy a
	  <acronym>BIOS</acronym>-unk, és ha lehetséges,
	  akkor a beágyazott vezérlõk, legfrissebb
	  verzióját használjuk.</para>
      </note>

      <para>Megkérnénk azokat, akik hibát akarnak
	bejelenteni, hogy a következõ
	információkat küldjék a <ulink
	url="mailto:freebsd-acpi@FreeBSD.org">
	freebsd-acpi@FreeBSD.org</ulink> címre:</para>

      <itemizedlist>
	<listitem>
	  <para>A hibás mûködés
	    leírása, beleértve a rendszer
	    típusát és
	    gyártmányát, illetve minden olyat,
	    aminek köze lehet a hibához.  Ha eddig
	    még nem tapasztaltuk, igyekezzünk minél
	    pontosabban leírni a hiba
	    keletkezésének folyamatát.</para>
	</listitem>

	<listitem>
	  <para>A <command>boot -v</command> paranccsal indított
	    rendszer &man.dmesg.8; kimenetét, beleértve a
	    vizsgálni kívánt hiba által
	    okozott összes hibaüzenetet.</para>
</listitem>

	<listitem>
	  <para>A <command>boot -v</command> paranccsal és az
	    <acronym>ACPI</acronym> használata nélkül
	    indított rendszer &man.dmesg.8; kimenete abban az
	    esetben, ha ez segít megoldani a
	    problémát.</para>
	</listitem>

	<listitem>
	  <para>A <command>sysctl hw.acpi</command> parancs kimenete.
	    Ezzel egyébként kitûnõen
	    kideríthetõ, milyen lehetõségeket is
	    kínál fel a rendszerünk.</para>
	</listitem>

	<listitem>
	  <para>Az általunk használt
	    <firstterm><acronym>ACPI</acronym>
	    forrásnyelvének</firstterm>
	    (<acronym>ACPI</acronym> Source Language,
	    <acronym>ASL</acronym>) elérhetõsége az
	    interneten.  Mivel ezek akár igen nagyok is lehetnek,
	    ezért a listára közvetlenül ne
	    küldjünk <acronym>ASL</acronym> kódokat!
	    Az <acronym>ASL</acronym> másolatát az
	    alábbi parancs kiadásával hozhatjuk
	    létre:</para>

	  <screen>&prompt.root; <userinput>acpidump -dt &gt; <replaceable>név</replaceable>-<replaceable>rendszer</replaceable>.asl</userinput></screen>

	  <para>(Adjuk meg a <replaceable>név</replaceable>
	    helyett a bejelentkezéshez használt
	    nevünket, a <replaceable>rendszer</replaceable> helyett
	    pedig a gyártót/típust.
	    Például:
	    <filename>njl-FooCo6000.asl</filename>)</para>
	</listitem>
      </itemizedlist>

      <para>Habár a legtöbb fejlesztõ a &a.current;t
	figyeli, a problémáink
	leírását mindenképpen a
	&a.acpi.name; listára küldjük, hogy biztosan
	észrevegyék.  A fejlesztõk azt kérik,
	hogy legyünk türelmesek, hiszen emellett mindannyian
	teljes állásban is dolgoznak.  Ha az
	általunk felfedezett hiba nem teljesen
	egyértelmû, akkor a fejlesztõk
	valószínûleg meg fognak kérni arra,
	hogy a &man.send-pr.1; használatával hozzunk
	róla létre egy hivatalos hibajelentést.  A
	hibajelentés készítésekor
	lehetõleg a fentebb megadott információkat
	ugyanúgy adjuk meg.  Ez segít a probléma
	szemmel tartásában és
	elhárításában.  Az &a.acpi.name;
	lista kihagyása nélkül közvetlenül
	ne küldjünk hibajelentést, mivel a
	hibabejelentõ rendszert elsõsorban
	emlékeztetõnek használjuk, nem pedig a
	hibák tényleges bejelentésére.
	Gyakran elõfordul, hogy valaki korábban már
	találkozott az adott problémával.</para>
    </sect2>

    <sect2 id="ACPI-background">
      <title>Háttér</title>

      <indexterm><primary>ACPI</primary></indexterm>

      <para>Az <acronym>ACPI</acronym> minden olyan modern
	számítógépben
	megtalálható, mely megfelel az ia32 (x86), ia64
	(Itanium) vagy amd64 (AMD) architektúrának.  A
	teljes szabvány rengeteg lehetõséget
	biztosít, többek közt a processzor
	teljesítményének kezelését,
	az energiaszintek vezérlését,
	hõzónákat, különféle
	akkumulátor rendszereket, beágyazott
	vezérlõk és a buszok
	felsorolását.  A legtöbb rendszer
	általában nem a teljes szabványt
	valósítja meg.  Például egy asztali
	rendszer általában csak a buszok
	felsorolásával kapcsolatos részeket
	tartalmazza, miközben egy laptop felajánlhatja a
	hûtés és az akkumulátor
	kezelését is.  A laptopokban gyakorta
	találunk készenléti üzemmódot a
	maguk elbonyolított formájában.</para>

      <para>Egy <acronym>ACPI</acronym>-nak megfelelõ rendszert
	számos összetevõ alkot.  A
	<acronym>BIOS</acronym>-ok és chipkészletek
	gyártói a memóriában egy elõre
	rögzített ponton elhelyeznek bizonyos
	táblázatokat (például
	<acronym>FADT</acronym>), amelyekkel megadják
	például az <acronym>APIC</acronym>
	összerendeléseit (ezt az <acronym>SMP</acronym>
	rendszerek használják), a
	konfigurációs regisztereket és az
	egyszerûbb konfigurációs
	értékeket.  Itt ezenkívül még
	bytekódok egy táblázata (amit
	<firstterm>Differenciált rendszerleírtó
	táblának</firstterm>, Differentiated System
	Description Table, <acronym>DSDT</acronym> nevezünk) is
	megtalálható, ahol az eszközök és
	módszerek nevei szerepelnek faszerû
	elrendezésben.</para>

      <para>Az <acronym>ACPI</acronym>-hoz tartozó
	meghajtónak képesnek kell lennie értelmezni
	ezeket a rögzített táblázatokat,
	implementálni egy bytekód-értelmezõt,
	módosítani az eszközmeghajtókat
	és a rendszermagot az <acronym>ACPI</acronym>
	alrendszerbõl érkezõ információk
	befogadásához.  A Linuxszal és a NetBSD-vel
	közösen a &os; kapott egy ilyen értelmezõt
	az &intel;tõl (<acronym>ACPI-CA</acronym>).  Az
	<acronym>ACPI-CA</acronym> forráskódja a rendszer
	forrásai között, a <filename
	  class="directory">src/sys/dev/acpica</filename>
	könyvtárban található.  A <filename
	  class="directory">src/sys/dev/acpica/0sd</filename>
	könyvtárban található források
	pedig lehetõvé teszik, hogy az
	<acronym>ACPI-CA</acronym> mûködhessen &os;-n.
	Végezetül, az <acronym>ACPI</acronym>
	eszközöket megvalósító
	meghajtók a <filename
	  class="directory">src/sys/dev/acpica</filename>
	könyvtárban találhatóak.</para>
    </sect2>

    <sect2 id="ACPI-comprob">
      <title>Gyakori problémák</title>

      <indexterm>
	<primary>ACPI</primary>
	<secondary>problémák</secondary>
      </indexterm>

      <para>Az <acronym>ACPI</acronym> megfelelõ
	mûködéséhez minden
	alkotórésznek helyesen kell mûködnie.  A
	most következendõkben elõfordulásuk
	gyakorisága szerint felsorolunk néhány
	ismert problémát, valamint a hozzájuk
	tartozó javításokat vagy
	elkerülésük módszerét.</para>

      <sect3>
	<title>Gondok az egérrel</title>

	<para>Egyes esetekben felfüggesztett
	  állapotból visszatérve az egerünk
	  nem hajlandó mûködni.  Ezt úgy lehet
	  elkerülni, ha <filename>/boot/loader.conf</filename>
	  állományba beírjuk a
	  <literal>hint.psm.0.flags="0x3000"</literal> sort.  Ha ez nem
	  segít, akkor a fentieknek megfelelõen
	  küldjünk be egy hibajelentést.</para>
      </sect3>

      <sect3>
	<title>Felfüggesztés/Folytatás</title>

	<para>Az <acronym>ACPI</acronym> három
	  (<acronym>STR</acronym>) állapotban képes a
	  fizikai memória segítségével
	  készenléti módba váltani, ezek az
	  <literal>S1</literal>-<literal>S3</literal>, és egy
	  állapotban használja a lemezt
	  (<literal>STD</literal>), amelyet <literal>S4</literal>-nek
	  hívnak.  Az <literal>S5</literal> neve a
	  <quote>szoftveres kikapcsolás</quote>, ami egy olyan
	  állapotot takar, amikor a rendszerünk áram
	  alatt van, de még nem üzemel.  Az
	  <literal>S4</literal><acronym>BIOS</acronym> állapot a
	  <acronym>BIOS</acronym> segítségével a
	  lemezre menti a rendszert, az
	  <literal>S4</literal><acronym>OS</acronym> állapotot
	  pedig teljes egészében az
	  operációs rendszer valósítja
	  meg.</para>

	<para>A rendszerünk által ismert
	  készenléti módokat a <command>sysctl
	  hw.acpi</command> paranccsal ellenõrizhetjük.
	  Íme mindez egy Thinkpad esetén:</para>

	<screen>hw.acpi.supported_sleep_state: S3 S4 S5
hw.acpi.s4bios: 0</screen>

	<para>Ez azt jelenti, hogy az <command>acpiconf -s</command>
	  parancs kiadásával kipróbálhatjuk
	  az <literal>S3</literal>,
	  <literal>S4</literal><acronym>OS</acronym>, és
	  <literal>S5</literal> állapotokat.  Ha az
	  <option>s4bios</option> értéke egy
	  (<literal>1</literal>), akkor az
	  <literal>S4</literal><acronym>BIOS</acronym>
	  támogatása helyett az <literal>S4</literal>
	  <acronym>OS</acronym> állapotot kapjuk.</para>

	<para>A felfüggesztés és folytatás
	  kipróbálása során kezdjük az
	  <literal>S1</literal> állapottal, már amennyiben
	  az támogatott a rendszerünkön.  Ez az
	  állapot többnyire használható, mivel
	  nem igényel túlságosan sok
	  támogatást a meghajtó
	  részérõl.  Eddig még senki sem
	  implementálta az <literal>S2</literal>
	  állapotot, de ha ezt is tudja a rendszerünk, akkor
	  az <literal>S1</literal>-hez hasonlót nyerünk
	  vele.  A következõ próba az
	  <literal>S3</literal> állapoté.  Ez a
	  legmélyebb <acronym>STR</acronym> állapot,
	  és a hardver megfelelõ
	  újraélesztéséhez rengeteg
	  támogatás szükségeltetik a
	  meghajtó részérõl.  Ha gondjaink
	  lennének a rendszerünk
	  felébresztésével, nyugodtan írjunk
	  egy levelet a &a.acpi.name; listára, ám a
	  probléma gyors megoldódásában ne
	  reménykedjünk, hiszen ehhez még
	  temérdek meghajtón és hardveren kell
	  tesztelni és kell dolgozni.</para>

	<para>Felfüggesztés és folytatás
	  esetén gyakori probléma, hogy sok
	  eszközmeghajtó nem menti el, nem
	  állítja vissza vagy éppen nem hozza
	  újra rendesen mûködésbe az adott
	  eszközön található firmware-t, a
	  regisztereket vagy memóriát.  Az okok
	  felderítéséhez elõször
	  érdemes a következõket
	  kipróbálni:</para>

	<screen>&prompt.root; <userinput>sysctl debug.bootverbose=1</userinput>
&prompt.root; <userinput>sysctl debug.acpi.suspend_bounce=1</userinput>
&prompt.root; <userinput>acpiconf -s 3</userinput></screen>

	<para>Ezzel a módszerrel tesztelni tudjuk az összes
	  meghajtó felfüggesztési és
	  folytatási rutinjait anélkül, hogy
	  ténylegesen <literal>S3</literal> állapotba
	  helyeznénk az eszközt.  Bizonyos esetekben ezzel
	  könnyen elcsíphetõ a hiba
	  (például a firmware állapotának
	  elvesztése, watchdog time out, megállás
	  nélküli
	  újrapróbálkozások).  A rendszer
	  ilyenkor nem vált <literal>S3</literal>
	  állapotra, vagyis az eszköz nem kerül
	  energiatakarékos állapotba, és
	  eltérõen a valós <literal>S3</literal>
	  állapottól továbbra is mûködik
	  még abban az esetben is, amikor a szükséges
	  felfüggesztési és folytatási rutinok
	  teljesen hiányoznak.</para>

	<para>Komolyabb esetben további
	  segédeszközökre lesz
	  szükségünk, vagyis soros portra és
	  kábelre a soros vonali nyomkövetéshez, vagy
	  Firewire portra és kábelre a &man.dcons.4;
	  használatához, valamint némi
	  tapasztalatra a rendszermagon belüli
	  hibakeresésben.</para>

	<para>A problémát nagy mértékben
	  segíti különválasztani, ha
	  igyekszünk minél több meghajtót
	  kivenni a rendszermagból.  Ha így javul a
	  helyzet, akkor már könnyen le lehet
	  szûkíteni arra a meghajtóra a kört,
	  aminek betöltésével esetleg gondok
	  akadhatnak.  Általában ilyenek a bináris
	  meghajtók, mint például az
	  <filename>nvidia.ko</filename>, az X11
	  megjelenítésért felelõs és az
	  <acronym>USB</acronym> eszközök meghajtói,
	  miközben az Ethernet eszközök remekül
	  szoktak mûködni.  Ha különösebb gond
	  nélkül képesek vagyunk betölteni
	  és eltávolítani ezeket a
	  meghajtókat, akkor ezt a folyamatot
	  önállósítani is tudjuk úgy,
	  hogy az <filename>/etc/rc.suspend</filename> és
	  <filename>/etc/rc.resume</filename> szkriptekbe
	  beillesztjük az ehhez szükséges parancsokat.
	  Ezekben egyébként találunk is egy
	  megjegyzésbe rakott példát a
	  meghajtók betöltésérõl
	  és eltávolításáról.
	  Ha az ébresztés után elszemetelõdik
	  a képernyõ tartalma, akkor állítsuk
	  át a <option>hw.acpi.reset_video</option>
	  változó értékét
	  nullára (<literal>0</literal>).  Sokat segíthet
	  meg az is, ha a <option>hw.acpi.sleep_delay</option>
	  értékét csökkentjük vagy
	  növeljük.</para>

	<para>Megpróbálhatjuk azt is, hogy
	  elindítunk egy frissebb Linux
	  disztribúciót <acronym>ACPI</acronym>
	  támogatással és ugyanazon a hardveren
	  kipróbáljuk az általa
	  felkínált felfüggesztési és
	  folytatási lehetõséget.  Ha Linux alatt ez
	  megbízhatóan mûködik, akkor nagy a
	  valószínûsége, hogy ez &os; alatt az
	  egyik meghajtó hibájából
	  fakadóan nem használható.  Így
	  fokozatosan le is tudjuk szûkíteni, hogy pontosan
	  melyikkel lehet a gond, és ezzel a fejlesztõk
	  munkáját segítjük.
	  Megjegyeznénk, hogy az <acronym>ACPI</acronym>-t
	  karbantartó fejlesztõk általában nem
	  foglalkoznak más meghajtókkal
	  (például hangkártya vagy
	  <acronym>ATA</acronym> stb.), ezért az adott
	  meghajtóval kapcsolatos hibáról javasolt
	  értesíteni a &a.current.name; listát
	  és a meghajtóért felelõs
	  fejlesztõt is.  Ha van egy kis kedvünk és
	  idõnk, mi magunk is belebiggyeszthetünk a
	  meghajtóba néhány &man.printf.3;
	  függvényt annak kiderítésére,
	  pontosan hol is fagy le a folytatási
	  funkció.</para>

	<para>Végül megpróbálkozhatunk az
	  <acronym>ACPI</acronym> kikapcsolásával is,
	  és áttérhetünk helyette az
	  <acronym>APM</acronym> használatára.  Ha az
	  <acronym>APM</acronym>-mel mûködnek a
	  készenléti állapotok, akkor
	  érdemes inkább azzal dolgozni,
	  különösen a régebbi (2000 elõtti)
	  hardverek esetében.  A gyártóknak
	  eltartott egy ideig, amíg rendes
	  <acronym>ACPI</acronym> támogatást voltak
	  képesek adni, ezért a régebbi
	  hardvereknél inkább a
	  <acronym>BIOS</acronym>-nak akadnak gondjai az
	  <acronym>ACPI</acronym>-val.</para>
      </sect3>

      <sect3>
	<title>A rendszer lemerevedik (ideiglenesen vagy
	  teljesen)</title>

	<para>A legtöbb rendszer olyankor akad meg, amikor sok
	  megszakítás elveszik, vagy amikor éppen
	  sok megszakítás érkezik egyszerre.  A
	  chipkészleteknek számos baja származik
	  abból, hogy a <acronym>BIOS</acronym> milyen
	  módon állítja be a rendszer
	  indítása elõtt a
	  megszakításokat, mennyire helyes az
	  <acronym>APIC</acronym> (<acronym>MADT</acronym>)
	  táblázata és hogyan vezérli a
	  <firstterm>Rendszervezérlõ
	  megszakítást</firstterm> (System Control
	  Interrupt, <acronym>SCI</acronym>).</para>

	<indexterm><primary>megszakítás-viharok</primary></indexterm>

	<para>A megszakítás-viharok a <command>vmstat
	  -i</command> parancs kimenetében szereplõ
	  elveszett megszakításokból
	  azonosíthatók be, ahol keressünk rá
	  az <literal>acpi0</literal> sorra.  Ha ez a
	  számláló másodpercenként
	  kettõnél többel növekszik, akkor a
	  megszakításaink viharba keveredtek.  Ha a
	  rendszer látszólag lefagyott,
	  próbáljuk meg elõhívni a
	  <acronym>DDB</acronym>-t (konzolban a <keycombo
	  action="simul">
	  <keycap>CTRL</keycap><keycap>ALT</keycap><keycap>ESC</keycap>
	  </keycombo>) és gépeljük be, hogy
	  <literal>show interrupts</literal>.</para>

	<indexterm>
	  <primary>APIC</primary>
	  <secondary>kikapcsolása</secondary>
	</indexterm>

	<para>A megszakítási problémákkal
	  kapcsolatban egyetlen reményünk az
	  <acronym>APIC</acronym> támogatás
	  kikapcsolása lehet a <filename>loader.conf</filename>
	  állományban a
	  <literal>hint.apic.0.disabled="1"</literal> sor
	  hozzáadásával.</para>
      </sect3>

      <sect3>
	<title>Végzetes hibák</title>

	<para>Az <acronym>ACPI</acronym>-vel kapcsolatos végzetes
	  hibák viszonylag ritkák, és
	  javításuk a legfontosabb.  Ilyenkor az elsõ
	  teendõnk elkülöníteni a hiba
	  reprodukálásának egyes
	  lépéseit és (ha lehetséges)
	  lekérni a hívási láncot.
	  Kövessük az <literal>options DDB</literal> és
	  a soros vonali konzol
	  beállításához adott
	  tanácsokat (lásd <xref
	  linkend="serialconsole-ddb"/>) vagy hozzunk létre egy
	  &man.dump.8; partíciót.  A
	  <acronym>DDB</acronym>-ben a hívási
	  láncot a <literal>tr</literal> parancs
	  segítségével kérhetjük le.
	  Ha kézzel írjuk le láncot, akkor
	  legalább az alsó öt (5) és a
	  felsõ öt (5) sorát mindenképpen
	  jegyezzük fel!</para>

	<para>Ezután próbáljuk meg úgy
	  szûkíteni a probléma
	  lehetõségét, hogy az
	  <acronym>ACPI</acronym> használata nélkül
	  indítjuk a rendszert.  Ha ezzel nincs semmi gond, akkor
	  a <option>debug.acpi.disable</option> változó
	  értékének megfelelõ
	  beállításával egyenként meg
	  tudjuk figyelni az <acronym>ACPI</acronym> alrendszer egyes
	  részeit.  Ehhez példákat az &man.acpi.4;
	  man oldalon találunk.</para>
      </sect3>

      <sect3>
	<title>Felfüggesztés vagy
	  leállítás után elindul a
	  rendszer</title>

	<para>Elõször is próbáljuk meg a
	  <literal>hw.acpi.disable_on_poweroff</literal>
	  változó értékét
	  <literal>0</literal>-ra állítani a
	  &man.loader.conf.5; állományban.  Ezzel
	  távoltartjuk az <acronym>ACPI</acronym> alrendszert a
	  rendszer leállítási
	  folyamatától.  Egyes rendszereknek valamilyen
	  okból kifolyólag szükségük van
	  itt az <literal>1</literal> (az alapértelmezett)
	  értékre.  Ez többnyire megoldja a
	  problémát, amikor a rendszer váratlanul
	  elindul a készenléti mód
	  aktiválásákor vagy
	  kikapcsoláskor.</para>
      </sect3>

      <sect3>
	<title>Egyéb problémák</title>

	<para>Ha más gondjaink lennének az
	  <acronym>ACPI</acronym>-val (dokkoló
	  állomásunk van, egyes eszközöket nem
	  vesz észre stb.), akkor természetesen errõl
	  is küldjünk egy leírást a
	  levelezési listára.  Azonban vegyük
	  figyelembe, hogy egyes problémák a
	  <acronym>ACPI</acronym> alrendszer eddig még nem
	  implementált, befejezetlen részeihez
	  kötõdnek, ezért azok megoldása
	  még várat magára.  Kérünk
	  mindenkit, hogy legyen türelemmel és álljon
	  készen a kiküldött javítások
	  tesztelésére!</para>
      </sect3>
    </sect2>

    <sect2 id="ACPI-aslanddump">
      <title><acronym>ASL</acronym>, <command>acpidump</command>
	és <acronym>IASL</acronym></title>

      <indexterm>
	<primary>ACPI</primary>
	<secondary>ASL</secondary>
      </indexterm>

      <para>A problémák leggyakoribb forrása, hogy
	a <acronym>BIOS</acronym>-gyártók rossz (vagy
	kifejezetten hibás!) bytekódokat adnak.  Ez
	általában a következõhöz
	hasonló rendszerüzenetbõl derül ki:</para>

      <screen>ACPI-1287: *** Error: Method execution failed [\\_SB_.PCI0.LPC0.FIGD._STA] \\
(Node 0xc3f6d160), AE_NOT_FOUND</screen>

      <para>Az ilyen jellegû hibákat gyakran úgy
	lehet orvosolni, ha a <acronym>BIOS</acronym>-unkat
	frissítjük a legújabb verzióra.  A
	legtöbb ilyen üzenet teljesen ártalmatlan, de
	ha vannak más problémáink is,
	például az akkumulátor állapota nem
	olvasható le, akkor elõször az
	<acronym>AML</acronym> környékén
	érdemes kutakodnunk.  A bytekód, más
	néven <acronym>AML</acronym>, az <acronym>ASL</acronym>
	elnevezésû forrásnyelvbõl
	származik.  Az <acronym>AML</acronym> egy
	<acronym>DSDT</acronym> néven ismert
	táblázatban található meg.  Az
	<acronym>ASL</acronym> másolatát az
	&man.acpidump.8; paranccsal készíthetjük el.
	Paraméterként egyaránt adjuk meg a
	<option>-t</option> (megmutatja a rögzített
	táblák tartalmát) és
	<option>-d</option> (visszafejti az <acronym>AML</acronym>
	kódokat az <acronym>ASL</acronym> nyelvére)
	kapcsolókat.  A felírás pontos
	formátumát a <link linkend="ACPI-submitdebug">A
	nyomkövetési információk
	beküldése</link> címû szakaszban
	olvashatjuk.</para>

      <para>Elsõként próbáljuk meg
	újrafordítani az így nyert
	<acronym>ASL</acronym> programot és keressünk benne
	hibákat.  A figyelmeztetések
	általában nyugodtan figyelmen kívül
	hagyhatóak, azonban a hibák olyan
	implementációs hibákra utalnak, amelyek
	akadályozzák az <acronym>ACPI</acronym> helyes
	mûködését.  Az <acronym>ASL</acronym>
	újrafordítását az alábbi
	paranccsal tudjuk elvégezni:</para>

      <screen>&prompt.root; <userinput>iasl <replaceable>saját.asl</replaceable></userinput></screen>
    </sect2>

    <sect2 id="ACPI-fixasl">
      <title>Az <acronym>ASL</acronym> kijavítása</title>

      <indexterm>
	<primary>ACPI</primary>
	<secondary>ASL</secondary>
      </indexterm>

      <para>Végeredményben az a célunk, hogy az
	<acronym>ACPI</acronym> megfelelõ
	mûködéséhez senkinek se kelljen
	hozzányúlnia semmihez.  Azonban még mindig
	szükség van
	<acronym>BIOS</acronym>-gyártók által
	elkövetett gyakori hibák
	elkerülésének kifejlesztésére.
	A &microsoft; értelmezõje
	(<filename>acpi.sys</filename> és
	<filename>acpiec.sys</filename>) nem ellenõrzi
	szigorúan a szabvány szerinti megfelelést,
	ezért számos olyan
	<acronym>BIOS</acronym>-gyártó, akik csak
	&windows; alatt tesztelik az <acronym>ACPI</acronym>
	implementációjukat, soha nem fogják
	kijavítani a <acronym>ASL</acronym> kódjukban
	ejtett hibáikat.  Reménykedünk, hogy
	folyamatosan sikerül felderíteni és
	dokumentálni a &microsoft; értelmezõje
	által eltûrt szabványon kívüli
	viselkedést és leutánozni &os; alatt is,
	hogy így ne kelljen a felhasználóknak
	kézzel a saját <acronym>ASL</acronym>
	forrásaikat javítgatni.  Az ebbõl
	fakadó hibákat úgy tudjuk elkerülni
	és segíteni a fejlesztõknek
	azonosítani a hozzá társuló
	viselkedést, hogy magunk javítjuk az
	<acronym>ASL</acronym>-ben felfedezett hibákat.  Ha ez
	beválik, akkor küldjük el a régi
	és új <acronym>ASL</acronym> közti
	&man.diff.1;-et a fejlesztõknek, akik így majd az
	<acronym>ACPI-CA</acronym>-ban ki tudnak dolgozni egy
	megoldást a hibás viselkedésre, ezzel a
	javításunk szükségtelenné
	válik.</para>

      <indexterm>
	<primary>ACPI</primary>
	<secondary>hibaüzenetek</secondary>
      </indexterm>

      <para>Most pedig következzenek a legismertebb
	hibaüzenetek, az okaik és
	javításuk:</para>

      <sect3>
	<title>Operációs rendszeri
	  függõségek</title>

	<para>Néhány <acronym>AML</acronym> úgy
	  gondolja, hogy a világ csak a
	  különbözõ &windows;
	  verziókból áll.  A &os;-nek
	  megadható, hogy másik operációs
	  rendszernek adja ki magát, és ezzel talán
	  meg is szüntethetõ pár hiba.  Ezt a
	  legegyszerûbb úgy tudjuk megtenni, ha a
	  <filename>/boot/loader.conf</filename>
	  állományhoz hozzáfûzzük a
	  <literal>hw.acpi.osname="Windows 2001"</literal> sort, vagy
	  itt egy olyan karakterláncot adunk meg, amit az
	  <acronym>ASL</acronym> forrásban láttunk.</para>
      </sect3>

      <sect3>
	<title>Hiányzó visszatérési
	  érték</title>

	<para>Bizonyos módszerek a szabvány szerint
	  elvártaktól eltérõen nem adnak
	  vissza explicit módon értéket.  Mivel az
	  <acronym>ACPI-CA</acronym> ezt nem kezeli le, ezért a
	  &os; részérõl tartalmaz egy olyan
	  módosítást, amivel implicit módon
	  is vissza lehet adni értéket.  Ha biztosak
	  akarunk lenni a visszaadni kívánt
	  értékben, akkor helyezzünk el a
	  megfelelõ helyekre explicit Return
	  utasításokat.  Az <command>iasl</command> a
	  <option>-f</option> paraméterrel
	  kényszeríthetõ az ilyen
	  <acronym>ASL</acronym> források
	  lefordítására.</para>
      </sect3>

      <sect3>
	<title>Az alapértelmezett <acronym>AML</acronym>
	  felülbírálása</title>

	<para>Miután módosítottuk a
	  <filename><replaceable>saját.asl</replaceable></filename>
	  állományunkat, így tudjuk
	  lefordítani:</para>

	<screen>&prompt.root; <userinput>iasl <replaceable>saját.asl</replaceable></userinput></screen>

	<para>Az <option>-f</option> kapcsoló
	  megadásával
	  kikényszeríthetjük az
	  <acronym>AML</acronym> létrehozását
	  még abban az esetben is, amikor hibákat
	  tartalmaz.  Ügyeljünk rá, hogy bizonyos
	  hibákat (például a hiányzó
	  visszatérési értékeket) a
	  fordító magától
	  kikerül.</para>

	<para>Az <command>iasl</command> alapértelmezett kimenete
	  a <filename>DSDT.aml</filename> állomány.  A
	  <filename>/boot/loader.conf</filename>
	  átírásával így tudjuk ezzel
	  helyettesíteni a <acronym>BIOS</acronym>-unk
	  hibás változatát (ami még mindig
	  megtalálható a flash
	  memóriában):</para>

	<programlisting>acpi_dsdt_load="YES"
acpi_dsdt_name="/boot/DSDT.aml"</programlisting>

	<para>Ehhez ne felejtsük el a saját
	  <filename>DSDT.aml</filename> állományunkat
	  bemásolni a <filename
	    class="directory">/boot</filename>
	  könyvtárba.</para>
      </sect3>
    </sect2>

    <sect2 id="ACPI-debugoutput">
      <title>Nyomkövetési információk
	kinyerése az <acronym>ACPI</acronym>-bõl</title>

      <indexterm>
	<primary>ACPI</primary>
	<secondary>problémák</secondary>
      </indexterm>

      <indexterm>
	<primary>ACPI</primary>
	<secondary>nyomkövetés</secondary>
      </indexterm>

      <para>Az <acronym>ACPI</acronym> meghajtója nagyon rugalmas
	nyomkövetési lehetõségekkel rendelkezik.
	Ennek révén ugyanúgy megadhatjuk a
	nyomonkövetni kívánt alrendszert, mint ahogy
	annak mélységét is.  A nyomkövetni
	kívánt alrendszereket
	<quote>rétegekként</quote> adjuk meg, valamint
	ezek <acronym>ACPI-CA</acronym> komponensekre
	(ACPI_ALL_COMPONENTS) és <acronym>ACPI</acronym>
	hardvertámogatásra (ACPI_ALL_DRIVERS) bomlanak le.
	A nyomkövetéskor keletkezõ kimenet
	részletességét a
	<quote>szintként</quote> adjuk meg, ami az
	ACPI_LV_ERROR-tól (csak a hibák)
	ACPI_LV_VERBOSE-ig (minden) terjedhet.  A <quote>szint</quote>
	itt egy bitmaszk, ezért szóközzel
	elválasztva egyszerre több
	beállítás megadható.  Ha
	túlságosan sok üzenet érkezik a konzol
	üzenetpufferébe, akkor szükségünk
	lehet a soros konzol keresztüli nyomkövetésre
	is.  Az összes szint és réteg az &man.acpi.4;
	man oldalon található meg.</para>

      <para>A nyomkövetés alapértelmezés
	szerint nem engedélyezett.  Az
	engedélyezéséhez hozzá kell adnunk
	az <literal>options ACPI_DEBUG</literal> sort a rendszermagunk
	beállításait tartalmazó
	állományhoz, amennyiben a rendszermagba
	fordítjuk az <acronym>ACPI</acronym>
	támogatást.  Ha az
	<filename>/etc/make.conf</filename> állományba
	írjuk bele az <literal>ACPI_DEBUG=1</literal> sort, akkor
	azt globálisan engedélyezhetjük.  Ha
	modulként használjuk, elegendõ csak a
	következõ módon újrafordítani az
	<filename>acpi.ko</filename> modult:</para>

      <screen>&prompt.root; <userinput>cd /sys/modules/acpi/acpi
&amp;&amp; make clean &amp;&amp;
make ACPI_DEBUG=1</userinput></screen>

      <para>Telepítsük fel a <filename>acpi.ko</filename>
	modult a <filename class="directory">/boot/kernel</filename>
	könyvtárba és állítsuk be a
	számunkra megfelelõ szintet és réteget
	a <filename>loader.conf</filename> állományban.
	Az alábbi példában
	engedélyezzük az összes
	<acronym>ACPI-CA</acronym> komponens és az összes
	<acronym>ACPI</acronym> hardvermeghajtó (processzor,
	<acronym>LID</acronym> stb.) nyomkövetését.
	Csak a hibaüzeneteket írja ki
	részletesen.</para>

      <programlisting>debug.acpi.layer="ACPI_ALL_COMPONENTS ACPI_ALL_DRIVERS"
debug.acpi.level="ACPI_LV_ERROR"</programlisting>

      <para>Ha az általunk keresett információt egy
	adott esemény váltja ki (például egy
	felfüggesztés vagy egy ébresztés),
	akkor nem is fontos átírnunk hozzá a
	<filename>loader.conf</filename> állományt, hanem
	helyette a rendszer indítása után
	használjuk a <command>sysctl</command> parancsot a
	réteg és a szint megadására akkor,
	amikor a rendszert felkészítjük az
	eseményre.  A <command>sysctl</command>
	változókat ugyanúgy nevezték el,
	mint a <filename>loader.conf</filename>
	állományban található
	beállításokat.</para>
    </sect2>

    <sect2 id="ACPI-References">
      <title>Hivatkozások</title>

      <para>Az <acronym>ACPI</acronym>-rõl az alábbi
	helyeken találunk részletesebb
	információkat:</para>

      <itemizedlist>
	<listitem>
	  <para>A &a.acpi;</para>
	</listitem>

	<listitem>
	  <para>Az <acronym>ACPI</acronym> levelezési lista
	    archívuma: <ulink
	    url="http://lists.freebsd.org/pipermail/freebsd-acpi/"></ulink></para>
	</listitem>

	<listitem>
	  <para>A korábbi <acronym>ACPI</acronym>
	    levelezési lista archívuma: <ulink
	    url="http://home.jp.FreeBSD.org/mail-list/acpi-jp/"></ulink></para>
	</listitem>

	<listitem>
	  <para>Az <acronym>ACPI</acronym> 2.0
	    specifikációja: <ulink
	    url="http://acpi.info/spec.htm"></ulink></para>
	</listitem>

	<listitem>
	  <para>A &os; következõ man oldalai: &man.acpi.4;,
	    &man.acpi.thermal.4;, &man.acpidump.8;, &man.iasl.8;,
	    &man.acpidb.8;</para>
	</listitem>

	<listitem>
	  <para><ulink
	    url="http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt">
	    A <acronym>DSDT</acronym> nyomkövetése
	    (angolul)</ulink>.  (Példának a Compaqot hozza
	    fel, de általánosságban véve
	    hasznos.)</para>
	</listitem>
      </itemizedlist>
    </sect2>
  </sect1>
</chapter>