path: root/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.xml

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

     $FreeBSD$

     %SOURCE%	en_US.ISO8859-1/books/handbook/cutting-edge/chapter.xml
     %SRCID%	39752
-->

<chapter id="updating-upgrading">
  <chapterinfo>
    <authorgroup>
      <author>
	<firstname>Jim</firstname>
	<surname>Mock</surname>
	<contrib>Geherstructureerd, gereorganiseerd en delen bijgewerkt
	  door </contrib>
      </author>
      <!-- Mar 2000 -->
    </authorgroup>

    <authorgroup>
      <author>
	<firstname>Jordan</firstname>
	<surname>Hubbard</surname>
	<contrib>Origineel door </contrib>
      </author>

      <author>
	<firstname>Poul-Henning</firstname>
	<surname>Kamp</surname>
      </author>

      <author>
	<firstname>John</firstname>
	<surname>Polstra</surname>
      </author>

      <author>
	<firstname>Nik</firstname>
	<surname>Clayton</surname>
      </author>
    </authorgroup>

    <authorgroup>
      <author>
	<firstname>Remko</firstname>
	<surname>Lodder</surname>
	<contrib>Vertaald door </contrib>
      </author>

      <author>
	<firstname>Siebrand</firstname>
	<surname>Mazeland</surname>
      </author>

      <author>
	<firstname>René</firstname>
	<surname>Ladan</surname>
      </author>
    </authorgroup>
  </chapterinfo>

  <title>&os; updaten en upgraden</title>

  <sect1 id="updating-upgrading-synopsis">
    <title>Overzicht</title>

    <para>&os; wordt ontwikkeld tussen de verschillende versies in.
      Sommige mensen prefereren om de officieel uitgegeven versies te
      draaien, terwijl anderen gesynchroniseerd willen blijven met de
      nieuwste ontwikkelingen.  Zelfs officiële uitgaven echter
      worden vaak bijgewerkt met veiligheids- en andere kritieke
      reparaties.  Ongeacht de gebruikte versie biedt &os; alle
      noodzakelijke gereedschappen om uw systeem bijgewerkt te houden,
      en maakt &os; het upgraden tussen versies ook gemakkelijk.  Dit
      hoofdstuk helpt om een keuze te maken of het wenselijk is het
      ontwikkelsysteem te volgen of één van de uitgegeven
      versies.  De basisgereedschappen om uw systeem bijgewerkt te
      houden worden ook gepresenteerd.</para>

    <para>Na het lezen van dit hoofdstuk weet de lezer:</para>

    <itemizedlist>
      <listitem>
	<para>Welke gereedschappen gebruikt kunnen worden om het systeem
	  en de Portscollectie te updaten.</para>
      </listitem>

      <listitem>
	<para>Hoe een systeem bijgewerkt kan worden met
	  <application>freebsd-update</application>,
	  <application>CVSup</application>,
	  <application>CVS</application> of
	  <application>CTM</application>;</para>
      </listitem>

      <listitem>
	<para>Hoe de toestand van een geïnstalleerd systeem met een
	  bekende maagdelijke kopie te vergelijken.</para>
      </listitem>

      <listitem>
	<para>Hoe uw documentatie bijgewerkt te houden met
	  <application>CVSup</application> of documentatie-ports<!-- en
	  <application>Docsnap</application>-->.</para>
      </listitem>

      <listitem>
	<para>De verschillen tussen de ontwikkeltakken &os.stable; en
	  &os.current;;</para>
      </listitem>

      <listitem>
	<para>Hoe een basissysteem opnieuw te compileren en
	  te herinstalleren met <command>make buildworld</command>,
	  enzovoort.</para>
      </listitem>
    </itemizedlist>

    <para>Veronderstelde criteria:</para>

    <itemizedlist>
      <listitem>
	<para>Een juist ingesteld netwerk (<xref
	    linkend="advanced-networking"/>);</para>
      </listitem>

      <listitem>
	<para>Weten hoe software van derden te installeren (<xref
	    linkend="ports"/>).</para>
      </listitem>
    </itemizedlist>

    <note>
      <para>Door dit hoofdstuk heen wordt <command>cvsup</command>
	gebruikt om de broncode van &os; te verkrijgen en bij te werken.
	Om het te gebruiken, dient u de port of het pakket voor <filename
	  role="package">net/cvsup</filename> te installeren (als u niet de
	grafische <command>cvsup</command>-cliënt wilt installeren, kunt u
	de port <filename>net/cvsup-without-gui</filename> installeren.  U kunt
	ervoor kiezen om dit te vervangen door &man.csup.1; welke onderdeel is
	van het basissysteem.</para>
    </note>
  </sect1>

  <sect1 id="updating-upgrading-freebsdupdate">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Geschreven door </contrib>
	</author>
      </authorgroup>

      <authorgroup>
	<author>
	  <firstname>Colin</firstname>
	  <surname>Percival</surname>
	  <contrib>Gebaseerd op notities aangeleverd door </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>&os; Update</title>

    <indexterm><primary>updaten en upgraden</primary></indexterm>

    <indexterm>
      <primary>freebsd-update</primary>

      <see>updating-upgrading</see>
    </indexterm>

    <para>Het toepassen van beveiligingspatches is een belangrijk
      onderdeel van het beheren van computersoftware, met name het
      besturingssysteem.  Dit was voor een lange tijd geen gemakkelijk
      proces op &os;.  Er moesten patches op de broncode worden
      toegepast,  de code moest herbouwd worden tot binairen, en daarna
      moesten de binairen worden geherinstalleerd.</para>

    <para>Dit is niet langer het geval aangezien &os; nu een gereedschap
      heeft dat eenvoudigweg <command>freebsd-update</command> heet.
      Dit gereedschap biedt twee gescheiden functies.  Ten eerste
      voorziet het in het toepassen van binaire beveiligings- en
      errata-updates op het basissysteem van &os; zonder de eis om te
      bouwen en te installeren.  Ten tweede ondersteunt het gereedschap
      kleine en grote uitgave-upgrades.</para>

    <note>
      <para>Binaire updates zijn beschikbaar voor alle architecturen en
	uitgaveaankondigingen dienen gelezen te worden aangezien deze
	belangrijke informatie over de gewenste uitgave kunnen bevatten.
	De aankondigingen kunnen op de volgende koppelin bekeken worden:
	<ulink url="http://www.FreeBSD.org/releases/"></ulink>.</para>
    </note>

    <para>Als er een <command>crontab</command> bestaat die de
      mogelijkheden van <command>freebsd-update</command> gebruikt, moet
      het uitgeschakeld worden voordat aan de volgende operatie wordt
      begonnen.</para>

    <sect2 id="freebsdupdate-config-file">
      <title>Het configuratiebestand</title>

      <para>Sommige gebruikers willen het standaard configuratiebestand
	optimaliseren, waardoor het proces beter gecontroleerd kan
	worden.  De opties zijn goed gedocumenteerd, maar voor de
	volgenden is wat extra uitleg nodig:</para>

      <programlisting># Componenten van het basissysteem die bijgewerkt moeten blijven
Components src world kernel</programlisting>

      <para>Deze parameter bepaalt welke delen van &os; bijgewerkt
	blijven.  Standaard wordt de broncode bijgewerkt, het hele
	basissysteem, en de kernel.  Dezelfde componenten als tijdens de
	installatie zijn beschikbaar, het toevoegen van bijvoorbeeld
	<literal>world/games</literal> zou de spelpatches toepassen.  Het
	gebruik van <literal>src/bin</literal> zou de broncode in <filename
	  class="directory">src/bin</filename> bijgewerkt houden.</para>

      <para>Het beste kan dit op de standaardwaarde blijven aangezien
	het veranderen hiervan om specifieke items te bevatten de
	gebruiker dwingt om alle items die bijgewerkt dienen te worden
	op te noemen.  Dit kan rampzalige gevolgen hebben aangezien de
	broncode en de binairen asynchroon kunnen raken.</para>

      <programlisting># Paden die beginnen met iets wat overeenkomt met een regel in een IgnorePaths
# statement zullen genegeerd worden.
IgnorePaths</programlisting>

      <para>Voeg paden, zoals
	<filename class="directory">/bin</filename> of
	<filename class="directory">/sbin</filename> toe om deze
	specifieke mappen ongemoeid te laten tijdens het updateproces.
	Deze optie kan gebruikt worden om te voorkomen dat
	<command>freebsd-update</command> lokale wijzigingen
	overschrijft.</para>

      <programlisting># Paden die beginnen met iets wat overeenkomt met een regel in een UpdateIfUnmodified
# statement zullen alleen worden bijgewerkt als de inhoud van het bestand niet is
# gewijzigd door de gebruiker (tenzij veranderingen zijn samengevoegd; zie beneden).
UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile</programlisting>

      <para>Werk configuratiebestanden in de aangegeven mappen alleen
	bij als ze niet zijn gewijzigd.  Alle veranderingen die door de
	gebruiker zijn gemaakt maken het automatisch bijwerken van deze
	bestanden ongeldig.  Er is een andere optie,
	<literal>KeepModifiedMetadata</literal>, die
	<command>freebsd-update</command> instrueert om de veranderingen
	tijdens het samenvoegen te bewaren.</para>

      <programlisting># Wanneer naar een nieuwe uitgave van &os; wordt ge-upgraded, worden lokale veranderingen van bestanden die overeenkomen met MergeChanges
# samengevoegd in de versie van de nieuwe uitgave.
MergeChanges /etc/ /var/named/etc/</programlisting>

      <para>Lijst van mappen met instellingenbestanden waar
	<command>freebsd-update</command> moet proberen om in samen te
	voegen.  Het proces van bestanden samenvoegen is een serie
	van &man.diff.1;-patches die ongeveer gelijk is aan
	&man.mergemaster.8; met minder opties, de samenvoegingen worden
	ofwel geaccepteerd, of openen een tekstverwerker, of zorgen
	ervoor dat <command>freebsd-update</command> afbreekt.  Maak in
	geval van twijfel een reservekopie van <filename
	  class="directory">/etc</filename> en accepteer de
	samenvoegingen.  In <xref linkend="mergemaster"/> staat meer
	informatie over het commando <command>mergemaster</command>.</para>

      <programlisting># Map waarin de gedownloade updates en tijdelijke
bestanden
# die door een &os; Update worden gebruikt worden opgeslagen.
# WorkDir /var/db/freebsd-update</programlisting>

      <para>Dit is de map waarin alle patches en tijdelijke bestanden
	worden geplaatst.  In het geval dat de gebruiker een
	versie-upgrade uitvoert, dient deze locatie tenminste een
	gigabyte aan vrije schijfruimte te hebben.</para>

      <programlisting># Wanneer tussen uitgaven wordt ge-upgraded, dient de lijst van Componenten dan
# strikt gelezen te worden (StrictComponents yes) of slechts als een lijst van componenten

# die geïnstalleerd *kunnen* worden en waarvan &os; Update uit dient te zoeken
# welke daadwerkelijk zijn geïnstalleerd en die te upgraden (StrictComponents no)?
# StrictComponents no</programlisting>

      <para>Wanneer ingesteld op <literal>yes</literal>, zal
	<command>freebsd-update</command> aannemen dat de lijst
	<literal>Components</literal> compleet is en zal het niet
	proberen om wijzigingen buiten de lijst te maken.  Effectief zal
	<command>freebsd-update</command> proberen om elk bestand bij te
	werken dat op de lijst <literal>Components</literal> staat.</para>
    </sect2>

    <sect2 id="freebsdupdate-security-patches">
      <title>Beveiligingspatches</title>

      <para>Beveiligingspatches staan op een verre machine en kunnen met
	het volgende commando gedownload en geïnstalleerd
	worden:</para>

      <screen>&prompt.root; <userinput>freebsd-update fetch</userinput>
&prompt.root; <userinput>freebsd-update install</userinput></screen>

      <para>Als er kernelpatches zijn toegepast moet het systeem opnieuw
	opgestart worden.  Als alles goed is gegaan dient het systeem
	gepatcht te zijn en kan <command>freebsd-update</command> als
	een nachtelijke &man.cron.8;-taak gedraaid worden.  Een regel
	in <filename>/etc/crontab</filename> zou genoeg moeten zijn om
	deze taak te volbrengen:</para>

      <programlisting>@daily                                  root    freebsd-update cron</programlisting>

      <para>Deze regel verklaart dat eenmaal per dag het commando
	<command>freebsd-update</command> gedraaid zal worden.  Op deze
	manier, door het argument <option>cron</option> te gebruiken,
	zal het gereedschap <command>freebsd-update</command> alleen kijken of
	er updates bestaan.  Als er patches bestaan, zullen ze automatisch
	worden gedownload naar de plaatselijke schijf maar niet worden
	toegepast.  Er zal een email aan de gebruiker
	<username>root</username> worden verstuurd zodat ze handmatig
	geïnstalleerd kunnen worden.</para>

      <para>Als er iets misging, heeft <command>freebsd-update</command>
	de mogelijkheid om de laatste verzamelingen veranderingen terug
	te draaien met het volgende commando:</para>

      <screen>&prompt.root; <userinput>freebsd-update rollback</userinput></screen>

      <para>Eenmaal voltooid, dient het systeem herstart te worden als
	de kernel of enige kernelmodule is gewijzigd.  Dit stelt &os; in
	staat om de nieuwe binairen in het geheugen te laden.</para>

      <para>Het gereedschap <command>freebsd-update</command> kan alleen
	de kernel <filename>GENERIC</filename> automatisch bijwerken.  Als
	een eigen kernel wordt gebruikt, moet het herbouwd en
	geherinstalleerd worden nadat <command>freebsd-update</command>
	klaar is met het installeren de rest van de updates.
	<command>freebsd-update</command> zal echter de kernel
	<filename>GENERIC</filename> in <filename
	  class="directory">/boot/GENERIC</filename> detecteren en
	bijwerken (als het bestaat), zelfs als het niet de huidige
	(draaiende) kernel van het systeem is.</para>

      <note>
	<para>Het is een goed idee om altijd een kopie van de kernel
	  <filename>GENERIC</filename> in <filename
	    class="directory">/boot/GENERIC</filename> te bewaren.  Het
	  kan van pas komen bij het vaststellen van een keur aan
	  problemen, en bij het uitvoeren van versie-upgrades met
	  <command>freebsd-update</command> zoals beschreven in
	  <xref linkend="freebsdupdate-upgrade"/>.</para>
      </note>

      <para>Tenzij de standaardconfiguratie in
	<filename>/etc/freebsd-update.conf</filename> is gewijzigd, zal
	<command>freebsd-update</command> de bijgewerkte kernelbronnen
	samen met de rest van de updates installeren.  Het herbouwen en
	herinstalleren van uw nieuwe eigen kernel kan daarna op de
	gebruikelijke manier gedaan worden.</para>

      <note>
	<para>De updates die via <command>freebsd-update</command>
	  verspreid worden hebben niet altijd betrekking op de kernel.
	  Het is niet nodig om uw eigen kernel te herbouwen als de
	  kernelbronnen niet zijn aangepast door het uitvoeren van
	  <command>freebsd-update install</command>.
	  <command>freebsd-update install</command> zal echter altijd
	  het bestand <filename>/usr/src/sys/conf/newvers.sh</filename>
	  bijwerken.  Het huidige patchniveau (zoals aangegeven door het
	  <literal>-p</literal>-nummer gerapporteerd door <command>uname
	    -r</command>) wordt uit dit bestand gehaald.  Het herbouwen
	  van uw eigen kernel, zelfs als er niets veranderd is, stelt
	  &man.uname.1; in staat om het huidige patchniveau van het
	  systeem accuraat te rapporteren.  Dit is in het bijzonder
	  behulpzaam wanneer meerdere systemen onderhouden worden,
	  aangezien hierdoor snel de geïnstalleerde updates op elk
	  ervan kunnen worden nagegaan.</para>
      </note>
    </sect2>

    <sect2 id="freebsdupdate-upgrade">
      <title>Grote en kleine upgrades</title>

      <para>Dit proces ruimt oude objectbestanden en bibliotheken op
	waardoor de meeste applicaties van derde partijen kapot gaan.
	Het wordt aangeraden dat alle geïnstalleerde poorten ofwel
	verwijderd en geherinstalleerd worden of later ge-upgraded
	worden met het hulpmiddel <filename
	  role="package">ports-mgmt/portupgrade</filename>.  De meeste
	gebruikers zullen willen proefdraaien met het volgende
	commando:</para>

      <screen>&prompt.root; <userinput>portupgrade -af</userinput></screen>

      <para>Dit zorgt ervoor dat alles juist wordt geherinstalleerd.
	Merk op dat het instellen van de omgevingsvariabele
	<makevar>BATCH</makevar> op <literal>yes</literal> het antwoord
	<literal>yes</literal> zal geven op alle prompts tijdens dit
	proces, waardoor het niet nodig is om handmatig in het
	bouwproces in te grijpen.</para>

      <para>Als een eigen kernel wordt gebruikt, is het upgradeproces
	iets ingewikkelder.  Een kopie van de kernel
	<filename>GENERIC</filename> is nodig en dient in <filename
	  class="directory">/boot/GENERIC</filename> geplaatst te
	worden.  Als de kernel <filename>GENERIC</filename> niet reeds op
	het systeem aanwezig is, moet het met één van de
	volgende methoden verkregen worden:</para>

      <itemizedlist>
	<listitem>
	  <para>Als er slechts eenmaal een eigen kernel is gebouwd, dan
	    is de kernel in <filename
	      class="directory">/boot/kernel.old</filename> eigenlijk de
	    <filename>GENERIC</filename>.  Hernoem deze map naar <filename
	      class="directory">/boot/GENERIC</filename>.</para>
	</listitem>

	<listitem>
	  <para>Aannemende dat fysieke toegang tot de machine mogelijk
	    is, kan een kopie van de kernel <filename>GENERIC</filename>
	    van het CD-ROM-medium worden geïnstalleerd.  Laad de
	    installatieschijf en geef de volgende commando's:</para>

	  <screen>&prompt.root; <userinput>mount /cdrom</userinput>
&prompt.root; <userinput>cd /cdrom/<replaceable>X.Y-RELEASE</replaceable>/kernels</userinput>
&prompt.root; <userinput>./install.sh GENERIC</userinput></screen>

	  <para>Vervang <filename
	      class="directory"><replaceable>X.Y-RELEASE</replaceable></filename>
	    met de versie van de uitgave die u gebruikt.  De kernel
	    <filename>GENERIC</filename> zal standaard in <filename
	      class="directory">/boot/GENERIC</filename> worden
	    geïnstalleerd.</para>
	</listitem>

	<listitem>
	  <para>Als al het bovenstaande niet lukt, kan de kernel
	    <filename>GENERIC</filename> herbouwd en geherinstalleerd
	    worden vanaf de broncode:</para>

	  <screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>env DESTDIR=/boot/GENERIC make kernel</userinput>
&prompt.root; <userinput>mv /boot/GENERIC/boot/kernel/* /boot/GENERIC</userinput>
&prompt.root; <userinput>rm -rf /boot/GENERIC/boot</userinput></screen>

	  <para>Om deze kernel door <command>freebsd-update</command>
	    als <filename>GENERIC</filename> te laten herkennen, mag het
	    configuratiebestand voor <filename>GENERIC</filename> niet op
	    enige wijze veranderd zijn.  Het is ook aan te raden dat het
	    zonder andere speciale opties wordt gebouwd (bij voorkeur
	    met een leeg <filename>/etc/make.conf</filename>).</para>
	</listitem>
      </itemizedlist>

      <para>Opnieuw opstarten naar de kernel <filename>GENERIC</filename>
	is in dit stadium niet nodig.</para>

      <para>Updates van grote en kleine versies kunnen worden uitgevoerd
	door een uitgaveversie als doel aan
	<command>freebsd-update</command> op te geven, het volgende
	commando zal bijvoorbeeld updaten naar &os;&nbsp;8.1:</para>

      <screen>&prompt.root; <userinput>freebsd-update -r 8.1-RELEASE upgrade</userinput></screen>

      <para>Nadat het commando is ontvangen, zal
	<command>freebsd-update</command> het instellingenbestand en het
	huidige systeem evalueren in een poging om de benodigde
	informatie te verzamelen om het systeem te updaten.  Een lijst
	op het scherm zal aangeven welke componenten zijn gedetecteerd
	en welke niet.  Bijvoorbeeld:</para>

      <screen>Looking up update.FreeBSD.org mirrors... 1 mirrors found.
Fetching metadata signature for 8.0-RELEASE from update1.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.

The following components of FreeBSD seem to be installed:
kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games
src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue
src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin
world/base world/info world/lib32 world/manpages

The following components of FreeBSD do not seem to be installed:
kernel/generic world/catpages world/dict world/doc world/games
world/proflibs

Does this look reasonable (y/n)? y</screen>

      <para>Nu zal <command>freebsd-update</command> proberen om alle
	bestanden die nodig zijn voor de upgrade te downloaden.  In
	sommige gevallen kan de gebruiker worden gevraagd wat te
	installeren of hoe verder te gaan.</para>

      <para>Wanneer een eigen kernel wordt gebruikt, zal de bovenstaande
	stap een waarschuwing geven die lijkt op de volgende:</para>

      <screen>WARNING: This system is running a "<replaceable>MIJNKERNEL</replaceable>" kernel, which is not a
kernel configuration distributed as part of FreeBSD 8.0-RELEASE.
This kernel will not be updated: you MUST update the kernel manually
before running "/usr/sbin/freebsd-update install"</screen>

      <para>Deze waarschuwing kan op dit moment veilig worden
	genegeerd.  De bijgewerkte kernel <filename>GENERIC</filename>
	zal als tussenliggende stap in het upgradeproces worden
	gebruikt.</para>

      <para>Nadat alle patches zijn gedownload naar het plaatselijke
	systeem zullen ze worden toegepast.  Dit proces kan afhankelijk
	van de snelheid en werklast van de machine even duren.  Hierna
	zullen instellingenbestanden worden samengevoegd&nbsp;&mdash;
	voor dit gedeelte van het proces is enige tussenkomst van de
	gebruiker nodig aangezien een bestand kan worden samengevoegd of
	omdat er een tekstverwerker op het scherm kan verschijnen om het
	bestand handmatig samen te voegen.  Het resultaat van elke
	succesvolle samenvoeging zal aan de gebruiker worden getoond
	naarmate het proces verder gaat.  Een mislukte of genegeerde
	samenvoegpoging zal het proces afbreken.  Het is mogelijk voor
	gebruikers om een reservekopie van <filename
	  class="directory">/etc</filename> te maken en belangrijke
	bestanden, zoals <filename>master.passwd</filename> of
	<filename>group</filename>, later samen te voegen.</para>

      <note>
	<para>Het systeem is nog niet veranderd, al het patchen en
	  samenvoegen gebeurt in een andere map.  Wanneer alle patches
	  succesvol zijn toegepast, alle instellingenbestanden zijn
	  samengevoegd en het erop lijkt dat het proces soepel verloopt,
	  dienen de veranderingen verzegeld te worden door de
	  gebruiker.</para>
      </note>

      <para>Als dit proces eenmaal voltooid is, kan de upgrade aan de
	schijf toevertrouwd worden met het volgende commando.</para>

      <screen>&prompt.root; <userinput>freebsd-update install</userinput></screen>

      <para>De kernel en kernelmodules zullen als eerste gepatcht
	worden.  Nu moet de machine opnieuw opgestart worden.  Als het
	systeem een eigen kernel draaide, gebruik dan het commando
	&man.nextboot.8; om de kernel voor de volgende keer dat
	opgestart wordt in te stellen op <filename
	  class="directory">/boot/GENERIC</filename> (welke is
	bijgewerkt):</para>

      <screen>&prompt.root; <userinput>nextboot -k GENERIC</userinput></screen>

      <warning>
	<para>Voordat er met de kernel <filename>GENERIC</filename> wordt
	  opgestart, dient te worden gecontroleerd dat het alle
	  stuurprogramma's bevat om uw systeem juist te laten opstarten
	  (en met het netwerk te verbinden, als de machine die
	  bijgewerkt wordt van afstand wordt benaderd).  In het
	  bijzonder, als de vorige kernel die draaide ingebouwde
	  functionaliteit bevatte die normaalgesproken door
	  kernelmodules wordt geleverd, zorg er dan voor dat deze
	  modules tijdelijk in de kernel <filename>GENERIC</filename>
	  worden geladen door de faciliteit
	  <filename>/boot/loader.conf</filename> te gebruiken.  U kunt
	  er ook voor kiezen om niet-essentiële diensten, schijf-
	  en netwerkkoppelingen, enzovoorts uit te zetten totdat het
	  upgradeproces voltooid is.</para>
      </warning>

      <para>De machine dient nu te worden herstart met de bijgewerkte
	kernel:</para>

      <screen>&prompt.root; <userinput>shutdown -r now</userinput></screen>

      <para>Als het systeem weer actief is, moet
	<command>freebsd-update</command> nogmaals gestart worden.
	De toestand van het proces is opgeslagen en dus zal
	<command>freebsd-update</command> niet vooraan beginnen, maar
	zal het alle oude gedeelde bibliotheken en objectbestanden
	verwijderen.  Geef het volgende commando om verder te gaan op
	dit punt:</para>

      <screen>&prompt.root; <userinput>freebsd-update install</userinput></screen>

      <note>
	<para>Afhankelijk van het feit of er versienummers van
	  bibliotheken zijn opgehoogd, kunnen er slechts twee in plaats
	  van drie installatiefasen zijn.</para>
      </note>

      <para>Alle software van derde partijen dient nu opnieuw gebouwd en
	geïnstalleerd te worden.  Dit is nodig omdat
	geïnstalleerde software van bibliotheken afhankelijk kan
	zijn die tijdens het upgradeproces zijn verwijderd.  Het
	commando <filename
	  role="package">ports-mgmt/portupgrade</filename> kan gebruikt
	worden om dit proces te automatiseren.  Dit proces kan met de
	volgende commando's gestart worden:</para>

      <screen>&prompt.root; <userinput>portupgrade -f ruby</userinput>
&prompt.root; <userinput>rm /var/db/pkg/pkgdb.db</userinput>
&prompt.root; <userinput>portupgrade -f ruby18-bdb</userinput>
&prompt.root; <userinput>rm /var/db/pkg/pkgdb.db /usr/ports/INDEX-*.db</userinput>
&prompt.root; <userinput>portupgrade -af</userinput></screen>

      <para>Voltooi, nadat dit voltooid is, het upgradeproces met een
	laatste aanroep naar <command>freebsd-update</command>.  Geef
	het volgende commando om alle losse eindjes in het upgradeproces
	samen te knopen:</para>

      <screen>&prompt.root; <userinput>freebsd-update install</userinput></screen>

      <para>Als de kernel <filename>GENERIC</filename> tijdelijk werd
	gebruikt, is dit het moment om een nieuwe eigen kernel op de
	gebruikelijke manier te bouwen en installeren.</para>

      <para>Start de machine opnieuw op in de nieuwe &os;-versie.  Het
	proces is voltooid.</para>
    </sect2>

    <sect2 id="freebsdupdate-system-comparison">
      <title>Het vergelijken van systeemtoestanden</title>

      <para>Het gereedschap <command>freebsd-update</command> kan
	gebruikt worden om de toestand van de geïnstalleerde versie
	van &os; met een bekende goede kopie te vergelijken.  Deze optie
	evalueert de huidige versie van systeemgereedschappen,
	bibliotheken, en instellingenbestanden.  Geef het volgende
	commando om met de vergelijking te beginnen:</para>

      <screen>&prompt.root; <userinput>freebsd-update IDS &gt;&gt; uitvoerbestand.ids</userinput></screen>

      <warning>
	<para>Hoewel de commandonaam <acronym>IDS</acronym> is, is het
	  in geen geval een vervanging voor een indringdetectiesysteem
	  zoals <filename role="package">security/snort</filename>.
	  Aangezien <command>freebsd-update</command> gegevens op schijf
	  opslaat, is de mogelijkheid om te knoeien duidelijk.  Hoewel
	  deze mogelijkheid verminderd kan worden door de instelling
	  <varname>kern.securelevel</varname> te gebruiken en de
	  gegevens van <command>freebsd-update</command> op een
	  bestandssysteem dat alleen gelezen kan worden op te slaan
	  wanneer deze niet gebruikt worden, zou een betere oplossing
	  zijn om het systeem met een veilige schijf te vergelijken,
	  zoals een <acronym>DVD</acronym> of een veilig opgeslagen
	  externe <acronym>USB</acronym>-schijf.</para>
      </warning>

      <para>Het systeem zal nu geïnspecteerd worden, en er zal een
	lijst van hun &man.sha256.1;-hashwaarden, zowel de bekende
	waarde in de uitgave en de huidige geïnstalleerde waarde,
	afgebeeld worden.  Hierom wordt de uitvoer naar het bestand
	<filename>uitvoerbestand.ids</filename> gezonden.  Het scrollt
	te snel voorbij om het met het oog te vergelijken, en het vult
	al snel de gehele consolebuffer op.</para>

      <para>Deze regels zijn ook extreem lang, maar het uitvoerformaat
	kan vrij eenvoudig geparsed worden.  Geef, om bijvoorbeeld een
	lijst van alle bestanden te krijgen die verschillen van die in
	de uitgave, het volgende commando:</para>

      <screen>&prompt.root; <userinput>cat uitvoerbestand.ids | awk '{ print $1 }' | more</userinput>
/etc/master.passwd
/etc/motd
/etc/passwd
/etc/pf.conf</screen>

      <para>Deze uitvoer is afgekapt, er bestaan veel meer bestanden.
	Sommige van deze bestanden hebben natuurlijke veranderingen, het
	<filename>/etc/passwd</filename> is gewijzigd omdat er
	gebruikers aan het systeem zijn toegevoegd.  In sommige gevallen
	kunnen er andere bestanden zijn, zoals kernelmodules, die
	verschillen aangezien <command>freebsd-update</command> ze
	ge-updated kan hebben.  Voeg, om bepaalde bestanden of mappen
	uit te sluiten, deze toe aan de optie
	<literal>IDSIgnorePaths</literal> in
	<filename>/etc/freebsd-update.conf</filename>.</para>

      <para>Dit systeem kan gebruikt worden als deel van een uitgebreide
	upgrademethode, afgezien van de eerder besproken versie.</para>
    </sect2>
  </sect1>

  <sect1 id="updating-upgrading-portsnap">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Tom</firstname>
	  <surname>Rhodes</surname>
	  <contrib>Geschreven door </contrib>
	</author>
      </authorgroup>

      <authorgroup>
	<author>
	  <firstname>Colin</firstname>
	  <surname>Percival</surname>
	  <contrib>Gebaseerd op notities geleverd door </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Portsnap: een updategereedschap voor de Portscollectie</title>

    <indexterm><primary>updaten en upgraden</primary></indexterm>

    <indexterm>
      <primary>Portsnap</primary>

      <see>updaten en upgraden</see>
    </indexterm>

    <para>Het basissysteem van &os; bevat ook een gereedschap om de
      Portscollectie bij te werken:  het hulpmiddel &man.portsnap.8;.
      Wanneer het wordt uitgevoerd, zal het een verbinding maken met een
      verre site, de veilige sleutel controleren, en een nieuwe kopie
      van de Portscollectie downloaden.  De sleutel wordt gebruikt om de
      integriteit van alle gedownloade bestanden te controleren, om er
      zeker van te zijn dat ze niet tijdens het downloaden zijn
      gewijzigd.  Geef het volgende commando om de nieuwste versie van
      de bestanden van de Portscollectie te downloaden:</para>

    <screen>&prompt.root; <userinput>portsnap fetch</userinput>
Looking up portsnap.FreeBSD.org mirrors... 9 mirrors found.
Fetching snapshot tag from geodns-1.portsnap.freebsd.org... done.
Fetching snapshot metadata... done.
Updating from Tue May 22 02:12:15 CEST 2012 to Wed May 23 16:28:31 CEST 2012.
Fetching 3 metadata patches.. done.
Applying metadata patches... done.
Fetching 3 metadata files... done.
Fetching 90 patches.....10....20....30....40....50....60....70....80....90. done.
Applying patches... done.
Fetching 133 new ports or files... done.</screen>

    <para>Dit voorbeeld laat zien dat &man.portsnap.8; verscheidene
      patches heeft gevonden en deze met de huidige portsgegevens heeft
      gecontroleerd.  Het geeft ook aan dat het gereedschap eerder is
      gedraaid, als het voor de eerste keer was gedraaid, had het
      simpelweg de collectie gedownload.</para>

    <para>Wanneer &man.portsnap.8; succesvol een
      <command>fetch</command>-operatie afrondt, bestaan de
      Portscollectie en de vervolgpatches die de verificatie doorstaan
      hebben op het plaatselijke systeem.  Gebruik de eerste keer dat
      <command>portsnap</command> wordt uitgevoerd <literal>extract</literal>
      om de gedownloade bestanden te installeren:</para>

    <screen>&prompt.root; <userinput>portsnap extract</userinput>
/usr/ports/.cvsignore
/usr/ports/CHANGES
/usr/ports/COPYRIGHT
/usr/ports/GIDs
/usr/ports/KNOBS
/usr/ports/LEGAL
/usr/ports/MOVED
/usr/ports/Makefile
/usr/ports/Mk/bsd.apache.mk
/usr/ports/Mk/bsd.autotools.mk
/usr/ports/Mk/bsd.cmake.mk
<replaceable>...</replaceable></screen>

    <para>Om een reeds geïnstalleerde Ports Collectie te updaten kan
      er gebruik worden gemaakt van het commando
      <command>portsnap update</command>:</para>

    <screen>&prompt.root; <userinput>portsnap update</userinput></screen>

    <para>Het proces is nu compleet, en applicaties kunnen met de
      bijgewerkte Portscollectie worden geïnstalleerd of worden
      bijgewerkt.</para>

    <para>De bewerkingen <literal>fetch</literal> en <literal>extract</literal>
      of <literal>update</literal> kunnen achter elkaar uitgevoerd worden, zoals
      het volgende voorbeeld laat zien:</para>

    <screen>&prompt.root; <userinput>portsnap fetch update</userinput></screen>

    <para>Dit commando zal de laatste versie van de Ports Collectie downloaden
      en de lokale versie bijwerken in de
      <filename class="directory">/usr/ports</filename>.</para>
  </sect1>

  <sect1 id="updating-upgrading-documentation">

    <title>De documentatie bijwerken</title>

    <indexterm><primary>updaten en upgraden</primary></indexterm>

    <indexterm>
      <primary>documentatie</primary>

      <see>updaten en upgraden</see>
    </indexterm>

    <para>Naast het basissysteem en de Portscollectie is documentatie
      een integraal onderdeel van het besturingssysteem &os;.  Hoewel
      een actuele versie van de &os;-documentatie altijd beschikbaar is
      op de <ulink
	url="http://www.freebsd.org/doc/">&os; website</ulink>, hebben
      sommige gebruikers een langzame of helemaal geen permanente
      netwerkverbinding.  Gelukkig zijn er verschillende manieren om de
      documentatie die bij elke uitgave wordt geleverd bij te werken
      door een lokale kopie van de nieuwste &os;-documentatie bij te
      houden.</para>

    <sect2 id="dsvn-doc">
      <title><application>Subversion</application> gebruiken om de documentatie
	bij te werken</title>

      <para>De bronnen van de &os;-documentatie kunnen met
	<application>Subversion</application> worden bijgewerkt.  Deze sectie
	beschrijft:</para>

      <itemizedlist>
	<listitem>
	  <para>Hoe de documentatiegereedschappen, de gereedschappen die
	    nodig zijn om de &os;-documentatie vanuit de broncode te
	    herbouwen, te installeren.</para>
	</listitem>

	<listitem>
	  <para>Hoe een kopie van de documentatiebronnen in <filename
	      class="directory">/usr/doc</filename> te downloaden door
	    <application>Subversion</application> te gebruiken.</para>
	</listitem>

	<listitem>
	  <para>Hoe de &os;-documentatie vanuit de broncode te herbouwen
	    en onder <filename
	      class="directory">/usr/share/doc</filename> te
	    installeren.</para>
	</listitem>

	<listitem>
	  <para>Sommige bouwopties die door het bouwsysteem van de
	    documentatie ondersteund worden, i.e., de opties die slechts
	    enkele van de verschillende vertalingen van de documentatie
	    bouwen of de opties die een specifiek uitvoerformaat
	    selecteren.</para>
	</listitem>
      </itemizedlist>
    </sect2>

    <sect2 id="installing-documentation-toolchain">
      <title><application>Subversion</application> en de
	documentatiegereedschappen installeren</title>

      <para>Voor het herbouwen van de &os;-documentatie vanuit de
	broncode is een aardig grote verzameling gereedschappen nodig.
	Deze gereedschappen zijn geen deel van het basissysteem van &os;
	omdat ze een grote hoeveelheid schijfruimte nodig hebben en niet
	voor alle &os;-gebruikers nuttig zijn; ze zijn alleen nuttig
	voor die gebruikers die actief nieuwe documentatie voor &os;
	schrijven of regelmatig hun documentatie vanuit de broncode
	bijwerken.</para>

      <para>Alle benodigde gereedschappen zijn beschikbaar als deel van
	de Portscollectie.  De port <filename
	  role="package">textproc/docproj</filename> is een meester-port
	die door het &os; Documentatieproject is ontwikkeld om de
	installatie en toekomstige updates van deze gereedschappen
	makkelijker te maken.</para>

      <note>
	<para>Wanneer er geen &postscript;- of PDF-documentatie nodig
	  is, kan men overwegen om in plaats hiervan de port <filename
	    role="package">textproc/docproj-nojadetex</filename> te
	  installeren.  Deze versie van de documentatiegereedschappen
	  bevat alles behalve de typesetting-engine
	  <application>teTeX</application>.
	  <application>teTeX</application> is een erg grote verzameling
	  van gereedschappen, dus kan het zinvol zijn om de installatie
	  ervan achterwege te laten als PDF-uitvoer niet echt nodig
	  is.</para>
      </note>

      <para><application>Subversion</application> wordt geïnstalleerd met de
	port <filename role="package">textproc/docproj</filename>.</para>
    </sect2>

    <sect2 id="updating-documentation-sources">
      <title>De documentatiebroncode bijwerken</title>

      <para>Het programma <application>Subversion</application> kan een schone
	kopie van de documentatiebroncode ophalen door het volgende te
	typen:</para>

      <screen>&prompt.root; <userinput>svn checkout <literal>svn://svn.FreeBSD.org/doc/head</literal> <filename class="directory">/usr/doc</filename></userinput></screen>

      <para>De initiële download van de documentatiebroncode kan
	een tijd duren.  Laat het draaien totdat het voltooid is.</para>

      <para>Toekomstige updates van de documentatiebroncode kunnen
	opgehaald worden door het volgende commando te draaien:</para>

      <screen>&prompt.root; <userinput>svn update <filename class="directory">/usr/doc</filename></userinput></screen>

      <para>Nadat de broncode is uitgecheckt, wordt een alternatieve
	manier om de documentatie bij te werken ondersteund door
	<filename>Makefile</filename> van de map <filename
	  class="directory">/usr/doc</filename> door het volgende te
	draaien:</para>

      <screen>&prompt.root; <userinput>cd /usr/doc</userinput>
&prompt.root; <userinput>make update</userinput></screen>
    </sect2>

    <sect2 id="updating-documentation-options">
      <title>Instelbare opties van de documentatiebroncode</title>

      <para>Het bijwerk- en bouwsysteem van de &os;-documentatie
	ondersteunt enkele opties die het proces om de documentatie
	alleen gedeeltelijk bij te werken, of om specifieke vertalingen
	te bouwen, makkelijker maken.  Deze opties kunnen of als
	systeemwijde opties in het bestand
	<filename>/etc/make.conf</filename> worden ingesteld, of als
	opdrachtregelopties aan het hulpmiddel &man.make.1; worden
	doorgegeven.</para>

      <para>De volgende opties zijn er enkelen van:</para>

      <variablelist>
	<varlistentry>
	  <term><makevar>DOC_LANG</makevar></term>

	  <listitem>
	    <para>De lijst van te bouwen en te installeren talen en
	      coderingen, bijvoorbeeld
	      <literal>en_US.ISO8859-1</literal> voor alleen de Engelse
	      documentatie.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><makevar>FORMATS</makevar></term>

	  <listitem>
	    <para>Een enkel formaat of een lijst van uitvoerformaten die
	      gebouwd moeten worden.  Momenteel worden
	      <literal>html</literal>, <literal>html-split</literal>,
	      <literal>txt</literal>, <literal>ps</literal>,
	      <literal>pdf</literal>, en <literal>rtf</literal>
	      ondersteund.</para>
	  </listitem>
	</varlistentry>

	<varlistentry>
	  <term><makevar>DOCDIR</makevar></term>

	  <listitem>
	    <para>Waar de documentatie te installeren.  Dit staat
	      standaard op <filename
		class="directory">/usr/share/doc</filename>.</para>
	  </listitem>
	</varlistentry>
      </variablelist>

      <para>Bekijk &man.make.conf.5; voor meer make-variabelen die als
	systeemwijde opties in &os; worden ondersteund.</para>

      <para>Voor meer make-variabelen die door het bouwsysteem van
	de &os;-documentatie ondersteund worden, wordt naar het <ulink
	  url="&url.doc.langbase;/books/fdp-primer">&os; Documentation
	  Project Primer for New Contributors</ulink> verwezen.</para>
    </sect2>

    <sect2 id="updating-installed-documentation">
      <title>De &os;-documentatie vanuit de broncode installeren</title>

      <para>Wanneer er een actueel snapshot van de documentatiebroncode
	is opgehaald in <filename class="directory">/usr/doc</filename>,
	is alles gereed om de geïnstalleerde documentatie bij te
	werken.</para>

      <para>Het volledig bijwerken van alle talen die in de
	Makefile-optie <makevar>DOC_LANG</makevar> zijn gedefinieerd kan
	worden gedaan door te typen:</para>

      <screen>&prompt.root; <userinput>cd /usr/doc</userinput>
&prompt.root; <userinput>make install clean</userinput></screen>

      <para>Als alleen het bijwerken van een specifieke taal gewenst is,
	dan kan &man.make.1; worden aangeroepen in een taalspecifieke
	submap van <filename class="directory">/usr/doc</filename>,
	i.e.:</para>

      <screen>&prompt.root; <userinput>cd /usr/doc/en_US.ISO8859-1</userinput>
&prompt.root; <userinput>make update install clean</userinput></screen>

      <para>De te installeren uitvoerformaten kunnen worden
	gespecificeerd door de make-variabele <makevar>FORMATS</makevar>
	in te stellen, i.e.:</para>

      <screen>&prompt.root; <userinput>cd /usr/doc</userinput>
&prompt.root; <userinput>make FORMATS='html html-split' install clean</userinput></screen>
    </sect2>

    <sect2 id="doc-ports">
      <sect2info>
	<authorgroup>
	  <author>
	    <firstname>Marc</firstname>
	    <surname>Fonvieille</surname>
	    <contrib>Gebaseerd op het werk van </contrib>
	  </author>
	</authorgroup>
      </sect2info>

      <title>Documentatieports gebruiken</title>

      <indexterm><primary>Updaten en upgraden</primary></indexterm>

      <indexterm>
	<primary>documentatiepakket</primary>

	<see>Updaten en upgraden</see>
      </indexterm>

      <para>In de vorige sectie werd er een methode voor het bijwerken
	van de &os;-documentatie vanaf de broncode gepresenteerd.  Het
	bijwerken gebaseerd op broncode is echter niet voor alle
	&os;-systemen haalbaar of praktisch.  Voor het bouwen van de
	documentatiebronnen zijn een redelijk grote verzameling van
	gereedschappen, de <emphasis>documentatie
	  gereedschapskist</emphasis>, een bepaald niveau van bekendheid
	met <application>Subversion</application> en checkouts van broncode
	vanuit een reservoir nodig, en een aantal handmatige stappen om
	de uitgecheckte broncode te bouwen.  In deze sectie wordt een
	alternatieve manier beschreven om de geïnstalleerde
	kopiën van de &os;-documentatie bij te werken; een die de
	Ports&nbsp;Collectie gebruikt en het mogelijk maakt om:</para>

      <itemizedlist>
	<listitem>
	  <para>Voorgebouwde versies van de documentatie te downloaden
	    en te installeren, zonder iets lokaal te hoeven bouwen (op
	    deze manier wordt de noodzaak voor een installatie van de
	    gehele documentatie-gereedschapskist voorkomen).</para>
	</listitem>

	<listitem>
	  <para>De documentatiebronnen te bouwen en ze via het
	    ports-raamwerk te bouwen (de stappen van het uitchecken en
	    bouwen worden iets eenvoudiger gemaakt).</para>
	</listitem>
      </itemizedlist>

      <para>Deze twee methoden om de &os;-documentatie bij te werken
	worden ondersteund door een verzameling van
	<emphasis>documentatie-ports</emphasis> die maandelijks door
	het &a.doceng; worden bijgewerkt.  Deze zijn vermeld in de &os;
	Ports&nbsp;Collectie onder de virtuele categorie <ulink
	  url="http://www.freshports.org/docs/">docs</ulink>.</para>

      <sect3 id="doc-ports-install-make">
	<title>Documentatie-ports bouwen en installeren</title>

	<para>De documentatie-ports gebruiken het bouwraamwerk van de
	  ports om het bouwen van documentatie eenvoudiger te maken.  Ze
	  automatiseren het proces van het uitchecken van de broncode
	  van de documentatie, het draaien van &man.make.1; met de
	  juiste omgevingsinstellingen en opdrachtregelopties, en ze
	  maken de installatie of deïnstallatie van documentatie
	  net zo eenvoudig als de installatie van elke andere &os;-port
	  of -pakket.</para>

	<note>
	  <para>Als een extra eigenschap registreren de
	    documentatie-ports, wanneer ze lokaal zijn gebouwd, een
	    afhankelijkheid naar de ports van de
	    <emphasis>documentatie-gereedschapskist</emphasis>, zodat
	    de laatste ook automatisch is geïnstalleerd.</para>
	</note>

	<para>De organisatie van de documentatie-ports is als volgt:</para>

	<itemizedlist>
	  <listitem>
	    <para>Er is een <quote>meester-port</quote>, <filename
		role="package">misc/freebsd-doc-en</filename>, waar de
	      bestanden van de documentatie-ports gevonden kunnen worden.
	      Het is de basis van alle documentatie-ports.  Standaard
	      bouwt het alleen de Engelstalige documentatie.</para>
	  </listitem>

	  <listitem>
	    <para>Er is een <quote>alles-in-één
		port</quote>, <filename
		role="package">misc/freebsd-doc-all</filename>, en het
	      bouwt en installeert alle documentatie in alle beschikbare
	      talen.</para>
	  </listitem>

	  <listitem>
	    <para>Ten slotte is er een <quote>slaaf-port</quote> voor
	      elke vertaling, bijvoorbeeld <filename
		role="package">misc/freebsd-doc-hu</filename> voor de
	      documenten in het Hongaars.  Ze zijn allemaal afhankelijk
	      van de meester-port en installeren de vertaalde
	      documentatie van de respectievelijke taal.</para>
	  </listitem>
	</itemizedlist>

	<para>Gebruik de volgende commando's (als
	  <username>root</username>) om een documentatieport vanaf de
	  broncode te installeren:</para>

	<screen>&prompt.root; <userinput>cd /usr/ports/misc/freebsd-doc-en</userinput>
&prompt.root; <userinput>make install clean</userinput></screen>

	<para>Dit zal de Engelstalige documentatie in gesplitst
	  <acronym>HTML</acronym>-formaat (hetzelfde als dat op <ulink
	    url="http://www.FreeBSD.org"></ulink> wordt gebruikt) in de
	  map <filename
	    class="directory">/usr/local/share/doc/freebsd</filename>
	  bouwen en installeren.</para>

	<sect4 id="doc-ports-options">
	  <title>Algemene knoppen en opties</title>

	  <para>Er zijn vele opties om het standaardgedrag van de
	    documentatie-ports aan te passen.  Het volgende is slechts
	    een korte lijst:</para>

	  <variablelist>
	    <varlistentry>
	      <term><makevar>WITH_HTML</makevar></term>

	      <listitem>
		<para>Staat bouwen van het HTML-formaat toe: een enkel
		  HTML-bestand per document.  De opgemaakte documentatie
		  wordt naar gelang in een bestand genaamd
		  <filename>article.html</filename>, of
		  <filename>book.html</filename>, met afbeeldingen
		  opgeslagen.</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><makevar>WITH_PDF</makevar></term>

	      <listitem>
		<para>Staat bouwen van het &adobe; Portable Document
		  Format toe, te gebruiken met &adobe; &acrobat.reader;,
		  <application>Ghostscript</application>, of andere
		  PDF-lezers.  De opgemaakte documentatie wordt naar
		  gelang opgeslagen in een bestand genaamd
		  <filename>article.pdf</filename> of
		  <filename>book.pdf</filename> opgeslagen.</para>
	      </listitem>
	    </varlistentry>

	    <varlistentry>
	      <term><makevar>DOCBASE</makevar></term>

	      <listitem>
		<para>Waar de documentatie te installeren.  Standaard is
		  dit <filename
		    class="directory">/usr/local/share/doc/freebsd</filename>.</para>

		<note>
		  <para>Merk op dat de standaard doelmap afwijkt van de map die
		    door de <application>Subversion</application>-methode wordt
		    gebruikt.  Dit komt omdat er een port wordt
		    geïnstalleerd, en ports worden normaliter onder
		    de map <filename
		      class="directory">/usr/local</filename>
		    geïnstalleerd.  Dit kan veranderd worden door
		    de variabele <makevar>PREFIX</makevar> toe te
		    voegen.</para>
		</note>
	      </listitem>
	    </varlistentry>
	  </variablelist>

	  <para>Hier is een kort voorbeeld over hoe de bovengenoemde
	    variabelen te gebruiken om de Hongaarse documentatie in
	    Portable Document Format te installeren:</para>

	  <screen>&prompt.root; cd /usr/ports/misc/freebsd-doc-hu
&prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean</screen>
	</sect4>
      </sect3>

      <sect3 id="doc-ports-install-package">
	<title>Documentatiepakketten gebruiken</title>

	<para>Voor het bouwen van de documentatie-ports vanaf broncode,
	  zoals beschreven in de vorige sectie, is een lokale
	  installatie van de documentatie-gereedschapskist en wat
	  schijfruimte voor het bouwen van de ports nodig.  Wanneer de
	  bronnen voor het installeren van de documentatie-gereedschapskist
	  niet aanwezig zijn, of wanneer het bouwen vanaf broncode te
	  veel schijfruimte in beslag neemt, is het nog steeds mogelijk
	  om de vooraf gebouwde versies van de documentatie-ports te
	  installeren.</para>

	<para>Het &a.doceng; bereidt maandelijkse versies van de &os;
	  documentatiepakketten voor.  Deze binaire pakketten kunnen met
	  elk van de meegeleverde pakketgereedschappen, zoals
	  &man.pkg.add.1;, &man.pkg.delete.1;, enzovoorts gebruikt
	  worden.</para>

	<note>
	  <para>Wanneer binaire pakketten worden gebruikt, zal de &os;
	    documentatie in <emphasis>alle</emphasis> beschikbare
	    formaten voor de gegeven taal geïnstalleerd worden.</para>
	</note>

	<para>Het volgende commando bijvoorbeeld zal het nieuwste vooraf
	  gebouwde pakket van de Hongaarse documentatie installeren:</para>

	<screen>&prompt.root; <userinput>pkg_add -r hu-freebsd-doc</userinput></screen>

	<note>
	  <para>Pakketten hebben het volgende naamformaat welke afwijkt
	    van de naam van de overeenkomstige port:
	    <literal><replaceable>taal</replaceable>-freebsd-doc</literal>.
	    Hier is <replaceable>taal</replaceable> het korte formaat
	    van de taalcode, i.e., <literal>hu</literal> voor Hongaars,
	    of <literal>zh_cn</literal> voor Vereenvoudigd Chinees.</para>
	</note>
      </sect3>

      <sect3 id="doc-ports-update">
	<title>Documentatieports bijwerken</title>

	<para>Voor het bijwerken van een eerder geïnstalleerde
	  documentatieport is elk gereedschap voor het bijwerken van
	  ports geschikt.  Het volgende commando bijvoorbeeld werkt de
	  geïnstalleerde Hongaarse documentatie bij via het
	  gereedschap <filename
	    role="package">ports-mgmt/portupgrade</filename> door alleen
	  pakketten te gebruiken:</para>

	<screen>&prompt.root; <userinput>portupgrade -PP hu-freebsd-doc</userinput></screen>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="current-stable">
    <title>Een ontwikkelingstak volgen</title>

    <indexterm><primary>-CURRENT</primary></indexterm>

    <indexterm><primary>-STABLE</primary></indexterm>

    <para>Er zijn twee ontwikkeltakken voor &os;: &os.current; en
      &os.stable;.  Deze sectie licht beiden toe en beschrijft hoe een
      systeem bijgewerkt te houden met elke tak.  &os.current; wordt
      eerst behandeld, daarna &os.stable;.</para>

    <sect2 id="current">
      <title>Bijblijven met &os;</title>

      <para>Bedenk dat &os.current; het <quote>nieuwste van het
	  nieuwste</quote> is van &os; ontwikkeling.  Van &os.current;
	gebruikers wordt verwacht dat ze veel technische kennis hebben
	en capabel zijn om zelfstandig lastige systeemproblemen op te
	lossen.  Nieuwe gebruikers van &os; kunnen het beste twee keer
	nadenken alvorens het te installeren.</para>

      <sect3>
	<title>Wat is &os.current;?</title>

	<indexterm><primary>momentopname</primary></indexterm>

	<para>&os.current; is de laatste werkende set broncode voor
	  &os;.  Dit bevat werk in uitvoering, experimentele
	  wijzigingen en overgangsmechanismes die mogelijk wel of niet
	  meegenomen worden in de volgende officiële uitgave van
	  het besturingssysteem.  Alhoewel veel &os;-ontwikkelaars de
	  broncode van &os.current; dagelijks compileren, zijn er
	  periodes dat de broncode niet compileerbaar is.  Deze
	  problemen worden zo snel mogelijk gerepareerd, maar het is
	  mogelijk dat &os.current; een ramp veroorzaakt in plaats van
	  dat het de gewenste functionaliteit levert.  Dit ligt geheel
	  aan het moment waarop de broncode is opgehaald.</para>
      </sect3>

      <sect3>
	<title>Wie heeft &os.current; nodig?</title>

	<para>&os.current; is beschikbaar voor drie primaire
	  aandachtsgroepen:</para>

	<orderedlist>
	  <listitem>
	    <para>Leden van de &os;-gemeenschap die actief werken aan
	      een deel van de broncode voor wie <quote>current</quote>
	      een echte eis is.</para>
	  </listitem>

	  <listitem>
	    <para>Leden van de &os;-gemeenschap die actief testen en
	      tijd hebben om problemen op te lossen om zeker te stellen
	      dat &os.current; zo gezond als mogelijk is.  Er zijn ook
	      mensen die actuele suggesties maken over wijzigingen
	      en de algemene richting van &os; en die patches
	      opsturen om deze te implementeren.</para>
	  </listitem>

	  <listitem>
	    <para>Diegenen die alleen een oogje in het zeil willen
	      houden of de huidige bronnen gebruiken ter referentie
	      (bijvoorbeeld voor het <emphasis>lezen</emphasis> en
	      niet het draaien).  Deze mensen geven ook regelmatig
	      commentaar of dragen bij in de code.</para>
	  </listitem>
	</orderedlist>
      </sect3>

      <sect3>
	<title>Wat is &os.current; <emphasis>niet</emphasis>?</title>

	<orderedlist>
	  <listitem>
	    <para>Een snelle manier om pre-release versies te krijgen
	      omdat bekend is dat er een aantal leuke nieuwe
	      mogelijkheden in zitten en het leuk is deze als eerste te
	      gebruiken.  Het als eerste gebruiken van nieuwe
	      mogelijkheden betekent ook de eerste zijn die nieuwe bugs
	      ontdekt.</para>
	  </listitem>

	  <listitem>
	    <para>Een snelle manier om bugfixes te krijgen.  Elke
	      willekeurige versie van &os.current; heeft waarschijnlijk
	      net zoveel nieuwe bugs als dat er bugs opgelost
	      zijn.</para>
	  </listitem>

	  <listitem>
	    <para>Op welke manier dan ook
	      <quote>officieel ondersteund</quote>.  We doen onze best
	      om mensen echt te helpen in één van de drie
	      <quote>legitieme</quote> &os.current; groepen maar er is
	      simpelweg <emphasis>niet genoeg tijd</emphasis> om
	      technische ondersteuning te leveren.  Dit is niet omdat
	      we gemene en vervelende mensen zijn die anderen niet
	      willen helpen (we zouden niet eens aan &os; werken als
	      we dat durfden).  De ontwikkelaars kunnen simpelweg geen
	      honderd berichten per dag beantwoorden
	      <emphasis>én</emphasis> aan &os; werken.  Bij de
	      keuze tussen het verbeteren van &os; en vragen
	      beantwoorden over experimentele code, kiezen
	      ontwikkelaars voor het eerste.</para>
	  </listitem>
	</orderedlist>
      </sect3>

      <sect3>
	<title>&os.current; gebruiken</title>

	<indexterm>
	  <primary>-CURRENT</primary>

	  <secondary>gebruiken</secondary>
	</indexterm>

	<orderedlist>
	  <listitem>
	    <para>Neem een abonnement op de mailinglijsten
	      &a.current.name; en &a.svn-src-head.name;.  Dit is niet
	      alleen een goed idee, het is
	      <emphasis>essentieel</emphasis>.  Geen berichten ontvangen
	      van de lijst <emphasis>&a.current.name;</emphasis>
	      betekent geen commentaar zien dat mensen maken over de
	      huidige staat van het systeem en dus waarschijnlijk
	      struikelen over problemen die anderen al gevonden en
	      opgelost hebben.  Nog belangrijker is het missen van
	      belangrijke informatie die kritisch kan zijn voor een
	      systeem.</para>

	    <para>De lijst &a.svn-src-head.name; biedt de mogelijkheid
	      de wijzigingsboodschap te zien voor elke wijziging die
	      gemaakt wordt, samen met relevante informatie over
	      mogelijke bijwerkingen.</para>

	    <para>Ga om op deze lijsten of één van de
	      andere beschikbare lijsten te abonneren naar
	      &a.mailman.lists.link; en klik op de gewenste lijst.
	      Instructies over de rest van de procedure zijn daar
	      beschikbaar.  Als u geïnteresseerd bent in het volgen
	      van veranderingen voor de gehele broncodeboom, raden wij u
	      aan een abonnement te nemen op de lijst
	      &a.svn-src-all.name;.</para>
	  </listitem>

	  <listitem>
	    <para>Haal de broncode van een &os;
	      <link linkend=" mirrors">mirrorsite</link>.  Dit kan op
	      de volgende twee manieren:</para>

	    <orderedlist>
	      <indexterm><primary><command>cvsup</command></primary></indexterm>

	      <indexterm><primary><command>cron</command></primary></indexterm>

	      <indexterm>
		<primary>-CURRENT</primary>

		<secondary>Synchroniseren met
		  <application>CVSup</application></secondary>
	      </indexterm>

	      <listitem>
		<para>Gebruik het programma <link
		    linkend="cvsup">cvsup</link> met de
		  <filename>supfile</filename> genaamd
		  <filename>standard-supfile</filename> uit
		  <filename>/usr/share/examples/cvsup</filename>.  Dit
		  is de geadviseerde methode, omdat de gehele collectie
		  in één keer wordt binnengehaald en
		  daarna alleen hetgeen wat gewijzigd is.  Veel mensen
		  draaien <command>cvsup</command> vanuit de
		  <command>cron</command> en houden daarmee hun
		  broncode automatisch bijgewerkt.  De voorbeeld
		  <filename>supfile</filename> dient aangepast te
		  worden om <link linkend="cvsup">cvsup</link> in te
		  stellen voor uw omgeving.</para>

		<note>
		  <para>Het voorbeeld
		    <filename>standard-supfile</filename> is bedoeld om
		    een specifieke beveiligingstak van &os; te volgen,
		    niet &os.current;.  U moet dit bestand bewerken en
		    de volgende regel vervangen:</para>

		  <programlisting>*default release=cvs tag=RELENG_<replaceable>X</replaceable>_<replaceable>Y</replaceable></programlisting>

		  <para>door deze:</para>

		  <programlisting>*default release=cvs tag=.</programlisting>

		  <para>Voor een gedetailleerde uitleg over bruikbare
		    tags wordt naar de sectie <link
		      linkend="cvs-tags">CVS Tags</link> van het
		    Handboek verwezen.</para>
		</note>
	      </listitem>

	      <listitem>
		<para>Gebruik de faciliteit <application><link
		      linkend="ctm">CTM</link></application>.
		  Bij een <quote>slechte verbinding</quote>, dure
		  connecties of alleen e-mail toegang, is
		  <application>CTM</application> een optie.  Het werkt
		  echter lastig en geeft mogelijk corrupte bestanden.
		  Dit zorgt ervoor dat het zelden gebruikt wordt, dat
		  de kans verhoogt dat het niet werkt voor redelijk
		  lange periodes.  Het advies is
		  <application><link
		      linkend="cvsup">CVSup</link></application> te
		  gebruiken.</para>
	      </listitem>
	    </orderedlist>
	  </listitem>

	  <listitem>
	    <para>Als de broncode wordt opgehaald om te draaien en niet
	      alleen om naar te kijken, haal dan
	      <emphasis>alles</emphasis> op van &os.current; en niet
	      alleen geselecteerde delen.  De reden hiervoor is dat
	      verschillende delen van de code afhangen van updates
	      op andere plekken en het compileren van een onderdeel
	      gegarandeerd problemen oplevert.</para>

	    <indexterm>
	      <primary>-CURRENT</primary>

	      <secondary>compileren</secondary>
	    </indexterm>

	    <para>Voordat &os.current; gecompileerd wordt is het
	      raadzaam om de <filename>Makefile</filename> in
	      <filename>/usr/src</filename> aandachtig te bekijken.
	      Het is handig om de eerste keer op zijn minst <link
		linkend="makeworld">de kernel en de
		<quote>wereld</quote> opnieuw te bouwen</link> als
		onderdeel van het updateproces.  Via de
	      &a.current; en <filename>/usr/src/UPDATING</filename> is
	      het mogelijk op de hoogte te blijven van mogelijke
	      wijzigingen in de opstartprocedures die soms nodig zijn
	      tussen verschillende versies.</para>
	  </listitem>

	  <listitem>
	    <para>Wees actief!  Ervaringen van &os.current;-gebruikers
	      zijn belangrijk, zeker als het gaat om suggesties voor
	      verbeteringen of bugfixes.  Suggesties met bijbehorende
	      code worden enthousiast ontvangen!</para>
	  </listitem>
	</orderedlist>
      </sect3>
    </sect2>

    <sect2 id="stable">
      <title>&os; stabiel houden</title>

      <sect3>
	<title>Wat is &os.stable;?</title>

	<indexterm><primary>-STABLE</primary></indexterm>

	<para>&os.stable; is de ontwikkeltak waaruit grote releases
	  gemaakt worden.  Wijzigingen in deze tak gaan in een ander
	  tempo en met de algemene aanname dat ze eerst in &os.current;
	  worden ingebracht ter test.  Dit is <emphasis>nog
	    steeds</emphasis> een ontwikkeltak, echter dit betekent dat
	  op elk gegeven moment de code voor &os.stable; wel of niet
	  geschikt is voor een speciaal doel.  Het is simpelweg een
	  andere ontwikkelomgeving en geen bron voor
	  eindgebruikers.</para>
      </sect3>

      <sect3>
	<title>Wie heeft &os.stable; nodig?</title>

	<para>Bij interesse in het bijhouden van of bijdragen aan het
	  &os;-ontwikkelproces, speciaal als het gerelateerd is aan de
	  volgende versie van &os;, is het volgen van &os.stable; het
	  overwegen waard.</para>

	<para>Ondanks dat security fixes ook in de &os.stable;-tak
	  komen, hoeft dit <emphasis>niet</emphasis> per se.  In elke
	  beveiligingswaarschuwing voor &os; wordt uitgelegd uit hoe
	  het probleem opgelost kan worden voor de release die het
	  betreft.

	  <footnote>
	    <para>Dit is niet helemaal waar.  Oude releases van &os;
	      kunnen niet eeuwig ondersteund worden, ook al duurt
	      ondersteuning vele jaren.  Een volledige beschrijving van
	      het huidige beveiligingsbeleid voor oudere releases van
	      &os; staat op <ulink
		url="&url.base;/security/">http://www.FreeBSD.org/security/</ulink>.</para></footnote>

	  Het volgen van de volledige ontwikkeltak alleen om
	  veiligheidsredenen levert ongetwijfeld ongewenste wijzigingen
	  op.</para>

	<para>Ondanks het voornemen ervoor te zorgen dat de
	  &os.stable;-tak compileert en altijd draait, wordt dit niet
	  gegarandeerd.  Terwijl code ontwikkeld wordt in &os.current;
	  voordat die in &os.stable; verwerkt wordt, draaien meer
	  mensen &os.stable; dan &os.current;, dus het is onontkoombaar
	  dat bugs en randgevallen soms in &os.stable; gevonden worden
	  die niet in &os.current; bekend waren.</para>

	<para>Om deze redenen wordt <emphasis>niet</emphasis>
	  aangeraden &os.stable; blindelings te volgen en het is extra
	  belangrijk geen productieservers bij te werken naar
	  &os.stable; zonder de code te testen in een
	  testomgeving.</para>

	<para>Als de mogelijkheden om dit te doen niet beschikbaar
	  zijn, dan is het advies de meest recente release van &os; te
	  draaien en dan de binaire update methode te hanteren om bij
	  te werken tussen verschillende releases.</para>
      </sect3>

      <sect3>
	<title>&os.stable; gebruiken</title>

	<indexterm>
	  <primary>&os.stable;</primary>

	  <secondary>gebruiken</secondary>
	</indexterm>

	<orderedlist>
	  <listitem>
	    <para>Neem een abonnement op de lijst &a.stable.name;.
	      Deze biedt informatie over onderdelen van de build die
	      mogelijk verschijnen in &os.stable; of eventuele andere
	      kwesties die speciale aandacht vereisen.  Ontwikkelaars
	      kondigen in deze mailinglijst ook aan wanneer ze
	      overwegen om een controversiële fix of aanpassing
	      willen maken, waardoor de gebruikers een kans hebben om
	      te reageren als ze goede redenen hebben tegen de
	      voorgestelde wijziging.</para>

	    <para>Wordt lid van de relevante
	      <application>SVN</application>-lijst voor de tak die u
	      volgt.  Als u bijvoorbeeld de tak 7-STABLE volgt, wordt u
	      lid van de &a.svn-src-stable-7.name; lijst.  Dit stelt u
	      in staat om het commit-log-bericht te bekijken voor elke
	      verandering die is gemaakt, tezamen met relevante
	      informatie over mogelijke bijwerkingen.</para>

	    <para>Ga om te abonneren op deze lijsten, of
	      één van de andere beschikbare lijsten
	      naar &a.mailman.lists.link; en klik op de lijst waarop
	      een abonnement gewenst is.  Instructies over de rest van
	      de procedure zijn daar beschikbaar.  Als u
	      geïnteresseerd bent in het volgen van veranderingen
	      voor de gehele broncodeboom, raden wij u aan een
	      abonnement te nemen op de &a.svn-src-all.name;
	      lijst.</para>
	  </listitem>

	  <listitem>
	    <para>Kijk op de webpagina <ulink
		url="&url.base;/snapshots/">Snapshots</ulink> om een
	      systeem te installeren van een maandelijkse snapshot
	      van &os.stable;.  Het is ook mogelijk om de meest recente
	      &os.stable; release te installeren van de <link
		linkend="mirrors">mirrorsites</link>.  Volg de
	      onderstaande instructies om een systeem bij te werken
	      naar de meest recente &os.stable; broncode.</para>

	    <para>Als al een vorige release van &os; draait en
	      bijgewerkt moet worden via de broncodes dan kan dat via
	      de &os; <link linkend="mirrors">mirrorsites</link>.  Dit
	      kan op één van de twee volgende
	      manieren:</para>

	    <orderedlist>
	      <indexterm><primary><command>cvsup</command></primary></indexterm>

	      <indexterm><primary><command>cron</command></primary></indexterm>

	      <indexterm>
		<primary>&os.stable;</primary>

		<secondary>synchroniseren met
		  <application>CVSup</application></secondary>
	      </indexterm>

	      <listitem>
		<para>Gebruik het programma <link
		    linkend="cvsup">cvsup</link> met de
		  <filename>supfile</filename>
		  <filename>stable-supfile</filename> uit de map
		  <filename>/usr/share/examples/cvsup</filename>.
		  Dit is de aanbevolen methode omdat het hiermee
		  mogelijk is de volledige collectie te downloaden en
		  daarna alleen hetgeen wat veranderd is.  Veel mensen
		  draaien <command>cvsup</command> vanuit de
		  <command>cron</command> om de broncodes automatisch
		  bij te werken.  Het voorbeeld van de
		  <filename>supfile</filename> dient aangepast en
		  ingesteld te worden voor de omgeving waarin het
		  instellingenbestand gebruikt wordt.</para>
	      </listitem>

	      <listitem>
		<indexterm>
		  <primary>&os.stable;</primary>

		  <secondary>synchroniseren met CTM</secondary>
		</indexterm>

		<para>Gebruik <application><link
		      linkend="ctm">CTM</link></application> als er geen
		  snelle, goedkope verbinding is met internet.  Dan is
		  dit de methode om te gebruiken.</para>
	      </listitem>
	    </orderedlist>
	  </listitem>

	  <listitem>
	    <para>Als er snelle on-demand toegang nodig is tot de
	      broncode en bandbreedte is geen overweging, gebruik dan
	      <command>cvsup</command> of <command>ftp</command>.
	      Gebruik anders <application>CTM</application>.</para>
	  </listitem>

	  <listitem>
	    <indexterm>
	      <primary>&os.stable;</primary>

	      <secondary>compileren</secondary>
	    </indexterm>

	    <para>Lees alvorens &os.stable; te compileren goed de
	      <filename>Makefile</filename> in
	      <filename>/usr/src</filename>.  Het is handig om de
	      eerste keer op zijn minst <link linkend="makeworld">de
		kernel en de <quote>wereld</quote> opnieuw te
		bouwen</link> als onderdeel van het updateproces.  Via
	      de &a.stable; en <filename>/usr/src/UPDATING</filename>
	      is het mogelijk op de hoogte te blijven van mogelijke
	      wijzigingen in de opstartprocedures die soms nodig zijn
	      tussen verschillende releases.</para>
	  </listitem>
	</orderedlist>
      </sect3>
    </sect2>
  </sect1>

  <sect1 id="synching">
    <title>Broncode synchroniseren</title>

    <para>Er zijn verschillende manieren om een internet (of e-mail)
      verbinding te gebruiken om bij te blijven met elk onderdeel van
      de &os; projectbronnen of alle onderdelen, afhankelijk van
      het interessegebied.  De primaire diensten zijn <link
	linkend="anoncvs">Anonieme CVS</link> en
      <link linkend="ctm">CTM</link>.</para>

    <warning>
      <para>Ondanks dat het mogelijk is om alleen delen van de
	broncode bij te werken, is de enige ondersteunde methode
	de totale broncode bijwerken en zowel userland (alle
	programma's die in gebruikersruimte draaien, zoals
	programma's in <filename>/bin</filename> en
	<filename>/sbin</filename>) als de kernel opnieuw compileren.
	Als alleen delen van de broncode worden bijgewerkt, alleen de
	kernel of alleen het userland, resulteert dat vaak in
	problemen.  Deze problemen kunnen verschillen van
	compileerfouten tot kernel panics of corruptie van
	gegevens.</para>
    </warning>

    <indexterm>
      <primary>CVS</primary>

      <secondary>anoniem</secondary>
    </indexterm>

    <para><application>Anonieme CVS</application> en
      <application>CVSup</application> gebruiken het
      <emphasis>pull</emphasis> model om broncode bij te werken.  In
      het geval van <application>CVSup</application> start de gebruiker
      (of een <command>cron</command> script) het programma
      <command>cvsup</command> waarbij het communiceert met een
      <command>cvsupd</command> server om bestanden bij te werken.  De
      ontvangen updates zijn op de minuut nauwkeurig en ze komen alleen
      wanneer dat is ingesteld.  Updates kunnen eenvoudig beperkt
      worden tot specifieke bestanden of mappen uit een
      interessegebied.  Updates worden automatisch gegenereerd door een
      server, aan de hand van wat is ingesteld.
      <application>Anonieme CVS</application> is veel eenvoudiger dan
      <application>CVSup</application> omdat dat alleen een uitbreiding
      is van <application>CVS</application> die de mogelijkheid biedt
      om wijzigingen direct van een CVS repository op afstand te halen.
      <application>CVSup</application> kan dit veel efficiënter
      doen, maar <application>anonieme CVS</application> is makkelijker
      in het gebruik.</para>

    <indexterm><primary><application>CTM</application></primary></indexterm>

    <para><application>CTM</application> aan de andere kant maakt geen
      vergelijking tussen de aanwezige bronnen en die op de master
      server.  In plaats daarvan wordt een script uitgevoerd dat
      wijzigingen in bestanden ziet sinds de vorige keer dat is
      bijgewerkt en die meerdere keren per dag worden uitgevoerd op de
      master CTM machine.  Elke ontdekte wijziging wordt gecomprimeerd,
      krijgt een volgnummer toegekend en wordt gecodeerd voor
      verzending via e-mail (in leesbare ASCII).  Deze <quote>CTM
	delta's</quote> kunnen dan aangeleverd worden aan
      &man.ctm.rmail.1; die ze automatisch decodeert, controleert en
      toepast in de gebruikerskopie van de bronnen.  Dit proces is
      veel efficiënter dan <application>CVSup</application> en
      claimt minder systeembronnen omdat het model
      <emphasis>push</emphasis> in plaats van
      <emphasis>pull</emphasis> is.</para>

    <para>Er zijn andere nadelen.  Als per ongeluk een deel van het
      archief wordt verwijderd, kan <application>CVSup</application>
      dat detecteren en het beschadigde deel repareren.
      <application>CTM</application> doet dit niet en als een deel van
      de broncode wordt verwijderd (en er geen back-up is), dan moet er
      opnieuw begonnen worden (vanaf de meest recente CVS <quote>base
	delta</quote> en moet alles opnieuw opgebouwd worden
      met <application>CTM</application>.  Met
      <application>Anonymous CVS</application> kan simpelweg het
      slechte deel verwijderd worden alvorens weer te
      synchroniseren.</para>
  </sect1>

  <sect1 id="makeworld">
    <title>De <quote>wereld</quote> opnieuw bouwen</title>

    <indexterm><primary><quote>world</quote> opnieuw
	bouwen</primary></indexterm>

    <para>Zodra de lokale broncode gesynchroniseerd is met een
      bepaalde versie van &os; (&os.stable;, &os.current;, enzovoort)
      kan de broncode gebruikt worden om een systeem te
      herbouwen.</para>

    <warning>
      <title>Maak een back-up</title>

      <para>Het kan niet vaak genoeg verteld worden hoe belangrijk het
	is om een back-up te maken van een systeem
	<emphasis>vóór</emphasis> deze taak uit te
	voeren.  Ook al is het opnieuw bouwen van de wereld vrij simpel
	(als deze instructies gevolgd worden), er worden ongetwijfeld
	ooit fouten gemaakt, misschien zelfs in de broncode, die het
	onmogelijk maken om een systeem op te starten.</para>

      <para>Wees ervan verzekerd dat er een back-up gemaakt is en dat er
	een reparatiediskette of cd-rom bij de hand is.  Deze wordt
	waarschijnlijk nooit gebruikt maar <quote>better safe than
	  sorry</quote>.</para>
    </warning>

    <warning>
      <title>Abonneer op de juiste mailinglijsten</title>

      <indexterm><primary>mailinglijst</primary></indexterm>

      <para>De &os.stable; en &os.current; takken zijn van nature
	<emphasis>in ontwikkeling</emphasis>.  Mensen die bijdragen
	aan &os; zijn menselijk en foutjes ontstaan regelmatig.</para>

      <para>Soms zijn deze foutjes onschadelijk, ze geven dan hooguit
	een nieuwe diagnostische waarschuwing weer.  Maar de wijziging
	kan ook catastrofaal zijn en ervoor zorgen dat een systeem niet
	meer opstart of bestandssystemen vernietigt (of erger).</para>

      <para>Als problemen zoals deze voorkomen wordt er een
	<quote>heads up</quote> naar de juiste mailinglijst gestuurd,
	waarin uitgelegd wordt wat het probleem is en welke systemen
	het raakt.  Er wordt een <quote>all clear</quote> bericht
	gestuurd als het probleem is opgelost.</para>

      <para>&os.stable; of &os.current; volgen zonder de &a.stable; of
	&a.current; te volgen is vragen om problemen.</para>
    </warning>

    <warning>
      <title>Gebruik geen <command>make world</command></title>

      <para>Veel oudere documentatie raadt aan om <command>make
	  world</command> te gebruiken.  In dat geval worden er
	belangrijke stappen overgeslagen en gebruik het commando alleen
	als er voldoende kennis over aanwezig is.  In bijna alle
	omstandigheden is <command>make world</command> verkeerd en
	de procedure die hier beschreven is hoort in plaats daarvan
	gebruikt te worden.</para>
    </warning>

    <sect2 id="canonical-build">
      <title>De universele wijze om een systeem bij te werken</title>

      <para>Om uw systeem bij te werken, dient u
	<filename>/usr/src/UPDATING</filename> te controleren op
	eventuele pre-buildworld stappen die nodig zijn voor uw versie
	van de broncode en daarna de procedure te gebruiken die hier
	beschreven staat.</para>

      <para>Deze bijwerkstappen nemen aan dat u nu een oude versie van
	&os; gebruikt, die uit een oude compiler, een oude kernel, een
	oude wereld en oude instellingenbestanden bestaat.  Onder
	<quote>wereld</quote> worden de binairen, bibliotheken, en
	programmeerbestanden van het kernsysteem verstaan.  De compiler
	is deel van <quote>wereld</quote>, maar heeft enkele speciale
	aandachtspunten.</para>

      <para>We nemen ook aan dat u reeds de broncode van een nieuwer
	systeem heeft verkregen.  Bekijk, als de bronnen op een bepaald
	systeem ook oud zijn, <xref linkend="synching"/> voor uitgebreide
	hulp over het synchroniseren ervan naar een nieuwere
	versie.</para>

      <para>Het bijwerken van het systeem vanaf de broncode is wat
	subtieler dan het op het eerste gezicht lijkt, en de
	ontwikkelaars van &os; vonden het in de loop der jaren nodig om
	de aangeraden methode redelijk drastisch te veranderen met het
	aan het licht komen van nieuwe soorten onontwijkbare
	afhankelijkheden.  De rest van deze sectie beschrijft de
	rationale achter de huidige aanbevolen bijwerkmethode.</para>

      <para>Elke succesvolle bijwerkmethode krijgt te maken met de
	volgende punten:</para>

      <itemizedlist>
	<listitem>
	  <para>Het kan voorkomen dat de oude compiler de nieuwe kernel
	    niet kan compileren.  (Oude compilers bevatten soms bugs.)
	    De nieuwe kernel dient dus met de nieuwe compiler gebouwd te
	    worden.  In het bijzonder moet de nieuwe compiler gebouwd
	    worden voordat de nieuwe kernel gebouwd wordt.  Dit betekent
	    niet per se dat de nieuwe compiler
	    <emphasis>geïnstalleerd</emphasis> moet worden voordat
	    de nieuwe kernel gebouwd wordt.</para>
	</listitem>

	<listitem>
	  <para>De nieuwe wereld kan afhankelijk zijn van mogelijkheden
	    van de nieuwe kernel.  Dus moet de nieuwe kernel worden
	    geïnstalleerd voordat de nieuwe wereld wordt
	    geïnstalleerd.</para>
	</listitem>
      </itemizedlist>

      <para>De eerste twee gevallen zijn de basis voor de methode
	<maketarget>buildworld</maketarget>,
	<maketarget>buildkernel</maketarget>,
	<maketarget>installkernel</maketarget>,
	<maketarget>installworld</maketarget> die we in de volgende
	paragrafen beschrijven.  Dit is geen uitputtende lijst van alle
	redenen waarom het huidige aanbevolen bijwerkproces de voorkeur
	verdient.  Wat minder voor de hand liggende redenen worden
	hieronder genoemd:</para>

      <itemizedlist>
	<listitem>
	  <para>Het kan zijn dat de oude wereld niet correct draait op
	    de nieuwe kernel, dus moet de nieuwe wereld onmiddellijk na
	    het installeren van de nieuwe kernel geïnstalleerd
	    worden.</para>
	</listitem>

	<listitem>
	  <para>Sommige instellingen moeten veranderd worden voordat de
	    nieuwe wereld wordt geïnstalleerd, maar anderen kunnen
	    de oude wereld kapot maken.  Vandaar dat over het algemeen
	    twee verschillende bijwerkstappen voor de instellingen nodig
	    zijn.</para>
	</listitem>

	<listitem>
	  <para>Voor het grootste gedeelte houdt het bijwerkproces zich
	    alleen bezig met het vervangen of toevoegen van bestanden;
	    bestaande oude bestanden worden niet verwijderd.  Dit kan in
	    sommige gevallen problemen geven.  Als een gevolg zal de
	    bijwerkprocedure soms aangeven dat bepaalde bestanden
	    tijdens bepaalde stappen handmatig verwijderd dienen te
	    worden.  Dit kan in de toekomst eventueel geautomatiseerd
	    worden.</para>
	</listitem>
      </itemizedlist>

      <para>Deze zorgen hebben tot het volgende aanbevolen bijwerkproces
	geleid.  Merk op dat het gedetailleerde proces voor bepaalde
	updates aanvullende stappen nodig kan hebben, maar dit
	kernproces zou de komende tijd ongewijzigd moeten
	blijven:</para>

      <orderedlist>
	<listitem>
	  <para><command>make
	      <maketarget>buildworld</maketarget></command></para>

	  <para>Dit compileert eerst de nieuwe compiler en enkele
	    aanverwante gereedschappen, daarna wordt de nieuwe compiler
	    gebruikt om de rest van de nieuwe wereld te compileren.  Het
	    resultaat komt in <filename
	      class="directory">/usr/obj</filename> te staan.</para>
	</listitem>

	<listitem>
	  <para><command>make
	      <maketarget>buildkernel</maketarget></command></para>

	  <para>In tegenstelling tot de oude aanpak, die &man.config.8;
	    en &man.make.1; gebruikt, gebruikt dit de
	    <emphasis>nieuwe</emphasis> compiler die in <filename
	      class="directory">/usr/obj</filename> verblijft.  Dit
	    beschermt u tegen mismatches tussen de compiler en de
	    kernel.</para>
	</listitem>

	<listitem>
	  <para><command>make
	      <maketarget>installkernel</maketarget></command></para>

	  <para>Plaatst de nieuwe kernel en kernelmodules op de schijf,
	    waardoor het mogelijk wordt om met de nieuw bijgewerkte
	    kernel op te starten.</para>
	</listitem>

	<listitem>
	  <para>Start opnieuw op in enkele-gebruikersmodus.</para>

	  <para>De enkele-gebruikersmodus minimaliseert problemen met
	    het bijwerken van software die al draait.  Het minimaliseert
	    ook problemen die opduiken door een oude wereld op een
	    nieuwe kernel te draaien.</para>
	</listitem>

	<listitem>
	  <para><command>mergemaster <option>-p</option></command></para>

	  <para>Dit voert wat initiële updates aan
	    instellingenbestanden uit ter voorbereiding op de nieuwe
	    wereld.  Het kan bijvoorbeeld nieuwe gebruikersgroepen aan
	    het systeem, of nieuwe gebruikersnamen aan de
	    wachtwoorddatabase toevoegen.  Dit is vaak nodig wanneer er
	    nieuwe groepen of speciale accounts voor systeemgebruikers
	    zijn toegevoegd sinds de laatste keer bijwerken, zodat de
	    stap <maketarget>installworld</maketarget> zonder problemen
	    de nieuw geïnstalleerde namen van systeemgebruikers of
	    systeemgroepen kan gebruiken.</para>
	</listitem>

	<listitem>
	  <para><command>make
	      <maketarget>installworld</maketarget></command></para>

	  <para>Kopieert de wereld van <filename
	      class="directory">/usr/obj</filename>.  U heeft nu een
	    nieuwe kernel en een nieuwe wereld op schijf staan.</para>
	</listitem>

	<listitem>
	  <para><command>mergemaster</command></para>

	  <para>Nu kunt u de overgebleven instellingenbestanden
	    bijwerken, aangezien u een nieuwe wereld op schijf heeft
	    staan.</para>
	</listitem>

	<listitem>
	  <para>Start opnieuw op.</para>

	  <para>Een volledige nieuwe start van de machine is nodig om de
	    nieuwe kernel en de nieuwe wereld met nieuwe
	    instellingenbestanden te laden.</para>
	</listitem>
      </orderedlist>

      <para>Merk op dat als u van de ene uitgave van dezelfde tak van
	&os; bijwerkt naar een recentere uitgave van dezelfde tak, i.e.
	van 7.0 naar 7.1, dat deze procedure dan niet absoluut nodig is,
	aangezien het onwaarschijnlijk is dat u serieuze problemen
	krijgt met de compiler, kernel, gebruikersland en
	instellingenbestanden.  De oudere aanpak met <command>make
	  <maketarget>world</maketarget></command> gevolgd door het
	bouwen en installeren van een nieuwe kernel kan voor kleine
	updates goed genoeg zijn.</para>

      <para>Maar mensen die deze procedure niet volgen tijdens het
	bijwerken tussen grote uitgaven kunnen wat problemen
	verwachten.</para>

      <para>Het is ook goed om op te merken dat veel upgrades (i.e.
	4.<replaceable>X</replaceable> naar 5.0) wat specifieke
	aanvullende stappen nodig hebben (bijvoorbeeld het hernoemen of
	verwijderen van specifieke bestanden voorafgaand aan
	installworld).  Lees het bestand
	<filename>/usr/src/UPDATING</filename> zorgvuldig, met name het
	einde, waar het huidig aangeraden bijwerkproces expliciet wordt
	beschreven.</para>

      <para>Deze procedure is in de loop der tijd veranderd aangezien de
	ontwikkelaars zagen dat het onmogelijk was om bepaalde
	mismatch-problemen volledig te voorkomen.  Hopelijk blijft de
	huidige procedure voor een lange tijd stabiel.</para>

      <para>Samengevat is de huidige aanbevolen manier om &os; vanaf
	broncode bij te werken:</para>

      <screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make buildworld</userinput>
&prompt.root; <userinput>make buildkernel</userinput>
&prompt.root; <userinput>make installkernel</userinput>
&prompt.root; <userinput>shutdown -r now</userinput></screen>

      <note>
	<para>Er zijn een aantal zeldzame gevallen waarin
	  <command>mergemaster -p</command> nog een keer moet draaien
	  voor de stap met <maketarget>buildworld</maketarget>.  Deze
	  staan beschreven in <filename>UPDATING</filename>.  In het
	  algemeen kan deze stap echter zonder risico worden
	  overgeslagen als er niet tussen een of meer hoofdversies
	  wordt bijgewerkt.</para>
      </note>

      <para>Nadat <maketarget>installkernel</maketarget> succesvol is
	afgerond, dient er in single-user modus opgestart te worden
	(met <command>boot -s</command> vanaf de loaderprompt).  Draai
	dan:</para>

      <screen>&prompt.root; <userinput>mount -u /</userinput>
&prompt.root; <userinput>mount -a -t ufs</userinput>
&prompt.root; <userinput>adjkerntz -i</userinput>
&prompt.root; <userinput>mergemaster -p</userinput>
&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make installworld</userinput>
&prompt.root; <userinput>mergemaster</userinput>
&prompt.root; <userinput>reboot</userinput></screen>

      <warning>
	<title>Lees verdere uitleg</title>

	<para>De hierboven beschreven volgorde is alleen een korte
	  samenvatting.  Ook de volgende secties lezen geeft een beter
	  beeld van elke stap, met name als er een op maat gemaakte
	  kernelinstelling wordt gebruikt.</para>
      </warning>
    </sect2>

    <sect2 id="src-updating">
      <title><filename>/usr/src/UPDATING</filename> lezen</title>

      <para>Lees voor verder te gaan
	<filename>/usr/src/UPDATING</filename> (of het gelijknamige
	bestand waar de kopie van de broncode ook staat).  Dit bestand
	kan belangrijke informatie bevatten over mogelijke problemen of
	specificeert de volgorde waarin bepaalde commando's gestart
	moeten worden.  Als <filename>UPDATING</filename> tegenstrijdig
	is met wat hier wordt beschreven, heeft
	<filename>UPDATING</filename> voorrang.</para>

      <important>
	<para><filename>UPDATING</filename> lezen is geen acceptabele
	  vervanging voor het abonneren op de correcte mailinglijst
	  zoals eerder beschreven.  De twee vullen elkaar aan en zijn
	  niet exclusief.</para>
      </important>
    </sect2>

    <sect2 id="make-conf">
      <title><filename>/etc/make.conf</filename> controleren</title>

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

      <para>Controleer
	<filename>/usr/share/examples/etc/make.conf</filename>
	en <filename>/etc/make.conf</filename>.  Het
	eerste bestand bevat standaard definities, waarvan de meeste
	uitgecommentarieerd zijn.  Om hiervan gebruik te maken als het
	systeem opnieuw opgebouwd wordt vanuit de broncode, moeten ze
	toegevoegd worden aan <filename>/etc/make.conf</filename>.
	Bedenk dat alles wat toegevoegd wordt aan
	<filename>/etc/make.conf</filename> ook gebruikt wordt bij elk
	<command>make</command> commando.  Het is dus verstandig om
	daar redelijke waardes in te vullen voor een systeem.</para>

      <para>Een typische gebruiker wil waarschijnlijk de regel
	<makevar>NO_PROFILE</makevar> uit
	<filename>/usr/share/examples/etc/make.conf</filename>
	kopiëren naar <filename>/etc/make.conf</filename> en het
	commentaar verwijderen.</para>

      <para>Bekijk de andere definities, zoals <makevar>NOPORTDOCS</makevar> en
	bepaal of deze relevant zijn.</para>
    </sect2>

    <sect2 id="updating-etc">
      <title><filename>/etc</filename> bijwerken</title>

      <para>De map <filename>/etc</filename> bevat een groot deel van
	de systeeminstellingen en scripts die gestart worden tijdens de
	systeemstart.  Sommige van deze scripts verschillen van versie
	tot versie in &os;.</para>

      <para>Sommige van de instellingenbestanden worden dagelijks
	gebruikt voor het draaien van een systeem.  In het bijzonder
	<filename>/etc/group</filename>.</para>

      <para>Er zijn gevallen geweest waarbij het installatiegedeelte
	van <command>make installworld</command> een aantal
	gebruikersnamen of groepen verwachtte.  Als er een upgrade
	wordt uitgevoerd is het waarschijnlijk dat deze gebruikers of
	groepen niet bestaan.  Dit levert problemen op bij upgraden.
	In sommige gevallen controleert <command>make
	  buildworld</command> of deze gebruikers of groepen
	bestaan.</para>

      <para>Een voorbeeld hiervan is het toevoegen van de gebruiker
	<username>smmsp</username>.  Gebruikers hadden een falend
	installatieproces toen &man.mtree.8; probeerde om
	<filename>/var/spool/clientmqueue</filename> te
	creëren.</para>

      <para>&man.mergemaster.8; kan in voorbereidende modus gedraaid
	worden als de optie <option>-p</option> wordt meegegeven.  Dan
	worden alleen de bestanden vergeleken die essentieel zijn voor
	het succes van <maketarget>buildworld</maketarget> of
	<maketarget>installworld</maketarget>:</para>

      <tip>
	<para>In <quote>paranoide beheerdersmodus</quote> kan er
	  gecontroleerd worden welke bestanden op een systeem eigendom
	  zijn van de groep die wordt hernoemd of verwijderd:</para>

	<screen>&prompt.root; <userinput>find / -group <replaceable>GID</replaceable> -print</userinput></screen>

	<para>Dit commando toont alle bestanden die eigendom zijn van
	  de groep <replaceable>GID</replaceable> (een groepsnaam of
	  een numeriek groeps-ID).</para>
      </tip>
    </sect2>

    <sect2 id="makeworld-singleuser">
      <title>Systeem naar single-user modus brengen</title>

      <indexterm><primary>single-user modus</primary></indexterm>

      <para>Het kan zijn dat een systeem in single-user modus
	gecompileerd moet worden.  Buiten het duidelijke voordeel dat
	de operatie iets sneller verloopt, is het voordeel dat bij een
	herinstallatie van een systeem een aantal belangrijke
	systeembestanden waaronder binaire systeembestanden,
	bibliotheken, include bestanden, enzovoort, worden aangepast,
	iets wat op een actief systeem vragen om problemen is (zeker
	als er actieve gebruikers op een systeem aanwezig zijn).</para>

      <indexterm><primary>multi-user modus</primary></indexterm>

      <para>Een andere methode is het systeem compileren in multi-user
	modus en daarna naar single-user modus gaan voor de
	installatie.  Bij deze methode moeten de volgende stappen
	gevolgd worden.  Het overschakelen naar single-user modus kan
	uitgesteld worden tot en met
	<maketarget>installkernel</maketarget> of
	<maketarget>installworld</maketarget>.</para>

      <para>Een supergebruiker kan als volgt een draaiend systeem naar
	single-user modus overgeschakelen:</para>

      <screen>&prompt.root; <userinput>shutdown now</userinput></screen>

      <para>Als alternatief kan tijdens het opstarten de optie
	<option>single user</option> worden gekozen.  Het systeem start dan
	in single-user modus.  Op de shell prompt moet dan worden
	ingegeven:</para>

      <screen>&prompt.root; <userinput>fsck -p</userinput>
&prompt.root; <userinput>mount -u /</userinput>
&prompt.root; <userinput>mount -a -t ufs</userinput>
&prompt.root; <userinput>swapon -a</userinput></screen>

      <para>Hierdoor worden de bestandssystemen gecontroleerd,
	<filename>/</filename> met lees en schrijf rechten opnieuw
	gemount, worden alle andere UFS bestandssystemen die in
	<filename>/etc/fstab</filename> staan gemount en wordt swap
	ingeschakeld.</para>

      <note>
	<para>Als de CMOS-klok ingesteld is naar de lokale tijd en
	  niet naar GMT (dit is waar als het resultaat van
	  &man.date.1; niet de correcte tijd en zone weergeeft), dan
	  is het misschien handig om het volgende commando te
	  starten:</para>

	<screen>&prompt.root; <userinput>adjkerntz -i</userinput></screen>

	<para>Dit zorgt ervoor dat de lokale tijdzoneinstellingen
	  correct ingesteld worden.  Zonder deze instelling kunnen er
	  later problemen ontstaan.</para>
      </note>
    </sect2>

    <sect2 id="cleaning-usr-obj">
      <title><filename>/usr/obj</filename> verwijderen</title>

      <para>Als delen van een systeem opnieuw gebouwd worden, worden ze
	standaard geplaatst in mappen onder
	<filename>/usr/obj</filename>.  Deze mappen schaduwen de mappen
	onder <filename>/usr/src</filename>.</para>

      <para>Het proces <command>make buildworld</command> kan versneld
	worden en problemen met afhankelijkheden kunnen voorkomen
	worden als deze map wordt verwijderd.</para>

      <para>Sommige bestanden onder <filename>/usr/obj</filename>
	hebben mogelijk de optie <quote>niet aanpassen</quote>
	ingesteld (zie &man.chflags.1;) die eerst verwijderd moet
	worden:</para>

      <screen>&prompt.root; <userinput>cd /usr/obj</userinput>
&prompt.root; <userinput>chflags -R noschg *</userinput>
&prompt.root; <userinput>rm -rf *</userinput></screen>
    </sect2>

    <sect2 id="updating-upgrading-recompilebase">
      <title>Broncode van het basissysteem hercompileren</title>

      <sect3>
	<title>Uitvoer bewaren</title>

	<para>Het is een goed idee om de uitvoer van &man.make.1; te
	  bewaren in een ander bestand.  Als er iets misgaat is er een
	  kopie van de foutmelding aanwezig.  Hoewel dit misschien niet
	  helpt in de diagnose van wat er fout is gegaan, kan het
	  anderen helpen als het probleem wordt aangegeven in
	  een &os; mailinglijst.</para>

	<para>De makkelijkste manier om dit te doen is door het
	  commando &man.script.1; te gebruiken, met een parameter
	  die de naam specificeert waar de uitvoer naartoe moet.  Dit
	  moet direct gedaan worden vóór het herbouwen
	  van de wereld, zodat het proces klaar is moet
	  <userinput>exit</userinput> worden ingegeven:</para>

	<screen>&prompt.root; <userinput>script /var/tmp/mw.out</userinput>
Script started, output file is /var/tmp/mw.out
&prompt.root; <userinput>make TARGET</userinput>
<emphasis>&hellip; compile, compile, compile &hellip;</emphasis>
&prompt.root; <userinput>exit</userinput>
Script done, &hellip;</screen>

	<para>Bewaar de uitvoer in deze stap <emphasis>niet</emphasis>
	  in <filename>/tmp</filename>.  Deze map wordt mogelijk
	  opgeschoond tijdens de volgende herstart.  Een betere plaats
	  om dit bestand te bewaren is de map
	  <filename>/var/tmp</filename> (zoals in het vorige voorbeeld)
	  of in de thuismap van <username>root</username>.</para>
      </sect3>

      <sect3 id="make-buildworld">
	<title>Basissysteem compileren</title>

	<para>Ga naar de map <filename>/usr/src</filename>, tenzij de
	  broncode ergens anders staat, in welk geval naar die map
	  gegaan moet worden:</para>

	<screen>&prompt.root; <userinput>cd /usr/src</userinput></screen>

	<indexterm><primary><command>make</command></primary></indexterm>

	<para>Om de wereld opnieuw te bouwen moet het commando
	  &man.make.1; gebruikt worden.  Dit commando leest zijn
	  instructies uit het bestand <filename>Makefile</filename>,
	  dat beschrijft hoe de programma's die samen &os; vormen
	  moeten worden gebouwd, in welke volgorde ze gebouwd moeten
	  worden, enzovoort.</para>

	<para>Het algemene formaat van de commandoregel die gebruikt
	  moet worden is als volgt:</para>

	<screen>&prompt.root; <userinput>make -<replaceable>x</replaceable> -D<replaceable>VARIABELE</replaceable> <replaceable>doel</replaceable></userinput></screen>

	<para>In dit voorbeeld is de optie
	  <option>-<replaceable>x</replaceable></option> een optie die
	  wordt meegegeven aan &man.make.1;.  In de hulppagina voor
	  &man.make.1; staat een voorbeeld van de opties die meegegeven
	  kunnen worden.</para>

	<para><option>-D<replaceable>VARIABELE</replaceable></option>
	  geeft een variabele door aan <filename>Makefile</filename>.
	  Het gedrag van <filename>Makefile</filename> wordt
	  beïnvloed door deze variabele.  Dit zijn dezelfde
	  variabelen die ingesteld worden in
	  <filename>/etc/make.conf</filename>.  Deze optie biedt een
	  alternatief om deze opties in te stellen.</para>

	<screen>&prompt.root; <userinput>make -DNO_PROFILE <replaceable>doel</replaceable></userinput></screen>

	<para>Het bovenstaande commando is een andere manier om aan te
	  geven dat geprofileerde bibliotheken niet gebouwd moeten
	  worden en correspondeert met de onderstaande regel in
	  <filename>/etc/make.conf</filename>:</para>

	<programlisting>NO_PROFILE=    true	#    Avoid compiling profiled libraries</programlisting>

	<para><replaceable>doel</replaceable> geeft &man.make.1; aan
	  wat er gedaan moet worden.  Elke
	  <filename>Makefile</filename> definieert een aantal van
	  verschillende doelen en het gekozen doel bepaalt wat er
	  gebeurt.</para>

	<para>Sommige doelen staan vermeld in het bestand
	  <filename>Makefile</filename>, maar zijn niet geschikt om
	  direct te starten.  Integendeel, deze worden gebruikt door
	  het bouwproces om de benodigde stappen onder te
	  verdelen.</para>

	<para>In veel gevallen hoeven er geen parameters te worden
	  meegegeven aan &man.make.1; en dus ziet de commando regel er
	  als volgt uit:</para>

	<screen>&prompt.root; <userinput>make <replaceable>doel</replaceable></userinput></screen>

	<para>Waar <replaceable>doel</replaceable> een van de vele
	  bouw opties is.  De eerste target moet echter altijd
	  <makevar>buildworld</makevar> zijn.</para>

	<para>Zoals de namen impliceren bouwt
	  <maketarget>buildworld</maketarget> een compleet nieuwe boom
	  onder <filename>/usr/obj</filename> en
	  <maketarget>installworld</maketarget>, een andere target,
	  installeert deze boom op de huidige machine.</para>

	<para>Het hebben van verschillende opties is handig om twee
	  redenen.  Als eerste biedt het
	  de mogelijkheid om de bouw veilig te doen met de wetenschap
	  dat geen enkel draaiend onderdeel van een systeem geraakt
	  wordt.  De bouw is <quote>zelf ondersteunend</quote>.
	  Hierdoor kan veilig in multi-user modus
	  <maketarget>buildworld</maketarget> gedraaid worden.  Het
	  wordt echter nog steeds aangeraden om
	  <maketarget>installworld</maketarget> in single-user modus te
	  starten.</para>

	<para>Ten tweede geeft het de mogelijkheid om NFS-mounts te
	  gebruiken om meerdere machines in het netwerk bij te werken.
	  Als er drie machines zijn, <hostid>A</hostid>,
	  <hostid>B</hostid> en <hostid>C</hostid>, die bijgewerkt
	  moeten worden, dan kunnen <command>make buildworld</command>
	  en <command>make installworld</command> gedraaid worden op
	  <hostid>A</hostid> waarna <hostid>B</hostid> en
	  <hostid>C</hostid> een NFS-mount kunnen opzetten naar
	  <filename>/usr/src</filename> en
	  <filename>/usr/obj</filename> op machine <hostid>A</hostid>
	  waarna <command>make installworld</command> gedraaid kan
	  worden op <hostid>B</hostid> en <hostid>C</hostid> om de
	  resultaten de installeren.</para>

	<para>Alhoewel het doel <maketarget>world</maketarget> nog wel
	  bestaat wordt het gebruik ervan sterk
	  <emphasis>afgeraden</emphasis>.</para>

	<para>Voer het volgende commando uit:</para>

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

	<para>Het is mogelijk om de optie <option>-j</option> mee te
	  geven aan <command>make</command>, wat resulteert in meerdere
	  processen die tegelijkertijd draaien.  Dit heeft het meeste
	  effect op machines met meerdere processoren.  Echter, omdat
	  het compilatieproces meer IO-gericht is dan processorgericht,
	  kan het ook nuttig zijn op systemen met één
	  processor.</para>

	<para>Start als volgt op een systeem met één
	  processor:</para>

	<screen>&prompt.root; <userinput>make -j4 buildworld</userinput></screen>

	<para>&man.make.1; draait dan maximaal 4 processen
	  tegelijkertijd.  In het algemeen blijkt uit de mailinglijsten
	  dat dit de beste resultaten geeft.</para>

	<para>Als er meerdere processoren in een systeem zitten en
	  gebruik gemaakt wordt van een SMP kernel, probeer dan waardes
	  tussen de 6 en 10 en bekijk hoe het systeem reageert.</para>
      </sect3>

      <sect3>
	<title>Doorlooptijd</title>

	<indexterm>
	  <primary><quote>world</quote> opnieuw bouwen</primary>

	  <secondary>doorlooptijd</secondary>
	</indexterm>

	<para>Veel factoren bepalen de doorlooptijd van het bouwen van
	  een boom, maar redelijk recente machines doen er maar 1 tot
	  2 uur over om de &os.stable; boom te bouwen.
	  zonder extra trucjes.  Een &os.current; boom kan wat langer
	  duren.</para>
      </sect3>
    </sect2>

    <sect2 id="new-kernel">
      <title>Nieuwe kernel compileren en installeren</title>

      <indexterm>
	<primary>kernel</primary>

	<secondary>compileren</secondary>
      </indexterm>

      <para>Om volledig gebruik te maken van het nieuwe systeem moet de
	kernel opnieuw gecompileerd worden.  Dit is bijna altijd nodig
	omdat sommige geheugenstructuren mogelijkerwijs veranderd zijn
	en programma's als &man.ps.1; en &man.top.1; niet werken totdat
	de kernel en de broncode dezelfde versie hebben.</para>

      <para>De simpelste en makkelijkste manier om dit te doen is
	om een kernel te maken die gebaseerd is op
	<filename>GENERIC</filename>.  Ondanks dat
	<filename>GENERIC</filename> mogelijk niet alle benodigde
	apparaten heeft voor een systeem, hoort het alles te bevatten
	dat nodig is om een systeem te starten in single-user modus.
	Dit is een goede test op de correcte werking van een nieuw
	systeem.  Na het opstarten van <filename>GENERIC</filename> en
	een systeemcontrole kan erna een nieuwe kernel gebouwd worden
	gebaseerd op een aangepast kernelinstellingenbestand.</para>

      <para>Op &os; is het belangrijk om de
	<link linkend="make-buildworld">wereld opnieuw te bouwen</link>
	voordat een nieuwe kernel gebouwd wordt.</para>

      <note>
	<para>Als een aangepaste kernel gemaakt moet worden en er reeds
	  een instellingenbestand aanwezig is, gebruik dan
	  <literal>KERNCONF=<replaceable>MYKERNEL</replaceable></literal>
	  als volgt:</para>

	<screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make buildkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput>
&prompt.root; <userinput>make installkernel KERNCONF=<replaceable>MYKERNEL</replaceable></userinput></screen>
      </note>

      <para>Let op dat als <literal>kern.securelevel</literal> een
	waarde hoger dan 1 heeft <emphasis>of</emphasis>
	<literal>noschg</literal> of gelijksoortige opties geplaatst
	zijn op het binaire kernelbestand, is het misschien nodig om
	terug te gaan naar single-user modus om
	<maketarget>installkernel</maketarget> uit te voeren.  In
	andere gevallen moet het mogelijk zijn om deze commando's
	zonder problemen uit te voeren in multi-user modus.  Zie
	&man.init.8; voor meer informatie over
	<literal>kern.securelevel</literal> en &man.chflags.1; voor
	informatie over diverse bestandsopties.</para>
    </sect2>

    <sect2 id="new-kernel-singleuser">
      <title>Opnieuw opstarten in single-user modus</title>

      <indexterm><primary>single-user modus</primary></indexterm>

      <para>Start met de instructies in <xref
	  linkend="makeworld-singleuser"/> in single-user modus op om te
	testen of de nieuwe kernel werkt.</para>
    </sect2>

    <sect2 id="post-installworld-updates">
      <title>Nieuwe binaire systeembestanden installeren</title>

      <para>Na het draaien van <command>make buildworld</command> kan
	nu <maketarget>installworld</maketarget> gebruikt worden om de
	nieuwe binaire systeembestanden te installeren.</para>

      <para>Voer de volgende commando's uit:</para>

      <screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make installworld</userinput></screen>

      <note>
	<para>Als er variabelen gespecificeerd zijn op de commandoregel
	  van <command>make buildworld</command> moeten dezelfde
	  variabelen gebruikt worden op de commandoregel van
	  <command>make installworld</command>.  Dit is niet per se
	  waar voor opties zoals <option>-j</option>, die nooit
	  gebruikt mogen worden met
	  <maketarget>installworld</maketarget>.</para>

	<para>Als bijvoorbeeld het volgende commando is
	  uitgevoerd:</para>

	<screen>&prompt.root; <userinput>make -DNO_PROFILE buildworld</userinput></screen>

	<para>Dan moet het resultaat geïnstalleerd worden
	  met:</para>

	<screen>&prompt.root; <userinput>make -DNO_PROFILE installworld</userinput></screen>

	<para>Anders wordt geprobeerd geprofileerde bibliotheken te
	  installeren die niet gebouwd zijn tijdens de fase
	  <command>make buildworld</command>.</para>
      </note>
    </sect2>

    <sect2 id="make-installworld">
      <title>Bestanden bijwerken die niet bijgewerkt zijn door
	<command>make installworld</command></title>

      <para>Het herbouwen van de wereld werkt bepaalde mappen niet
	bij (in het bijzonder <filename>/etc</filename>,
	<filename>/var</filename> en <filename>/usr</filename>) met
	nieuwe of gewijzigde instellingenbestanden.</para>

      <para>De simpelste manier om deze bestanden bij te werken is door
	&man.mergemaster.8; te gebruiken, maar het is ook mogelijk
	dit handmatig te doen.  Welke manier er ook gekozen wordt, zorg
	er altijd voor dat een back-up van <filename>/etc</filename>
	beschikbaar is voor het geval er iets misgaat.</para>

      <sect3 id="mergemaster">
	<sect3info>
	  <authorgroup>
	    <author>
	      <firstname>Tom</firstname>
	      <surname>Rhodes</surname>
	      <contrib>Bijgedragen door </contrib>
	    </author>
	  </authorgroup>
	</sect3info>

	<title><command>mergemaster</command></title>

	<indexterm><primary><command>mergemaster</command></primary></indexterm>

	<para>Het hulpprogramma &man.mergemaster.8; is een Bourne script
	  dat helpt bij het bepalen van de verschillen tussen de
	  instellingenbestanden in <filename>/etc</filename> en de
	  instellingenbestanden in de broncodeboom
	  <filename>/usr/src/etc</filename>.  Deze methode wordt
	  aangeraden om instellingenbestanden van een systeem bijgewerkt
	  te houden met de bestanden die in de broncodeboom staan.</para>

	<para>Het programma wordt gestart met
	  <command>mergemaster</command> op de commandoregel en geeft dan
	  resultaten weer.  <command>mergemaster</command> bouwt dan een
	  tijdelijke root omgeving vanaf <filename>/</filename> en vult
	  deze met diverse instellingenbestanden voor een systeem.  Deze
	  bestanden worden vergeleken met de bestanden die
	  geïnstalleerd zijn op een systeem.  Op dit punt worden de
	  bestanden getoond die verschillen in het &man.diff.1;-formaat,
	  met een <option>+</option> voor toegevoegde of gewijzigde
	  regels en een <option>-</option> voor regels die verwijderd of
	  vervangen zijn.  In de hulppagina voor &man.diff.1; staat meer
	  informatie over de syntaxis van &man.diff.1; en hoe
	  bestandsverschillen getoond worden.</para>

	<para>&man.mergemaster.8; toont dan elk bestand dat verschilt en
	  op dit moment is er de mogelijkheid om of het nieuwe bestand te
	  verwijderen (ofwel het tijdelijke bestand), het tijdelijke
	  bestand te installeren zonder enige wijzigingen, het verwerken
	  van het oude bestand in het nieuwe bestand of de resultaten van
	  &man.diff.1; nogmaals te tonen.</para>

	<para>Als gekozen wordt om het tijdelijke bestand te verwijderen,
	  geeft dit &man.mergemaster.8; aan dat het huidige bestand niet
	  gewijzigd dient te worden en de nieuwe versie verwijderd kan
	  worden.  Deze optie wordt niet aangeraden, behalve als er geen
	  reden is om het huidige bestand aan te passen.  Op ieder moment
	  kunnen hulpteksten getoond worden door <keycap>?</keycap> in te
	  geven op de prompt van &man.mergemaster.8;.  Als een bestand
	  wordt overgeslagen, dan wordt het weer getoond als alle overige
	  bestanden verwerkt zijn.</para>

	<para>Bij de keuze om het ongewijzigde tijdelijke bestand te
	  installeren wordt het huidige bestand vervangen door het
	  nieuwe.  Voor de meeste ongewijzigde bestanden is dit de beste
	  optie.</para>

	<para>Als ervoor gekozen wordt om de wijzigingen te verwerken
	  wordt er een tekstverwerker gestart die de inhoud van beide
	  bestanden toont.  De verschillen kunnen verwerkt worden terwijl
	  beide bestanden naast elkaar op het scherm staan.  Hier kunnen
	  delen gekozen worden die gezamenlijk een nieuw bestand
	  opleveren.  Als de bestanden zij aan zij vergeleken worden,
	  wordt met de toets <keycap>l</keycap> de inhoud links
	  geselecteerd en met de toets <keycap>r</keycap> de inhoud
	  rechts geselecteerd.  Het eindresultaat bestaat uit delen van
	  beide bestanden die erna geinstalleerd kunnen worden.  Deze
	  optie wordt voornamelijk gebruikt voor bestanden die gewijzigd
	  zijn door de beheerder.</para>

	<para>Als ervoor gekozen wordt om de &man.diff.1; resultaten nog
	  een keer te tonen, worden dezelfde verschillen getoond
	  zoals &man.mergemaster.8; deed voordat een optie gevraagd
	  werd.</para>

	<para>Zodra &man.mergemaster.8; klaar is met de systeembestanden
	  worden er andere opties getoond.  &man.mergemaster.8; kan
	  vragen of het wachtwoordbestand opnieuw gebouwd moet worden.
	  Als laatste wordt een optie getoond om
	  alle overgebleven tijdelijke bestanden te verwijderen.</para>
      </sect3>

      <sect3>
	<title>Handmatig bijwerken</title>

	<para>Bij handmatig bijwerken kunnen de bestanden van
	  <filename>/usr/src/etc</filename> niet zomaar naar
	  <filename>/etc</filename> gekopieerd worden om een werkend
	  systeem te krijgen.  Sommige van deze bestanden moeten eerst
	  <quote>geïnstalleerd</quote> worden.  Dit omdat de map
	  <filename>/usr/src/etc</filename> <emphasis>geen</emphasis>
	  kopie is van <filename>/etc</filename>.  Daarnaast staan er
	  in <filename>/etc</filename> bestanden die niet in
	  <filename>/usr/src/etc</filename> staan.</para>

	<para>Als &man.mergemaster.8; gebruikt wordt (zoals
	  aangeraden), kan doorgegaan worden met het <link
	    linkend="updating-upgrading-rebooting">volgende
	    onderdeel</link>.</para>

	<para>De simpelste manier om met de hand bij te werken, is de
	  bestanden in een nieuwe map installeren en daarna naar
	  verschillen tussen de bestanden te zoeken.</para>

	<warning>
	  <title>Back-up maken van <filename>/etc</filename></title>

	  <para>Ondanks dat, in theorie, niets in deze map automatisch
	    wordt aangepast, is het altijd beter om daar zeker van te
	    zijn.  Dus kopieer de bestaande <filename>/etc</filename>
	    naar een veilige locatie.  Zoals bijvoorbeeld met het
	    volgende commando:</para>

	  <screen>&prompt.root; <userinput>cp -Rp /etc /etc.old</userinput></screen>

	  <para><option>-R</option> maakt een recursieve kopie,
	    <option>-p</option> bewaart tijden, eigenaarschap,
	    enzovoorts op bestanden.</para>
	</warning>

	<para>Er moet een dummyset van mappen gemaakt worden om de
	  nieuwe <filename>/etc</filename> en andere bestanden in te
	  installeren.  <filename>/var/tmp/root</filename> is een
	  redelijke keuze en er zijn hier een aantal benodigde
	  submappen aanwezig:</para>

	<screen>&prompt.root; <userinput>mkdir /var/tmp/root</userinput>
&prompt.root; <userinput>cd /usr/src/etc</userinput>
&prompt.root; <userinput>make DESTDIR=/var/tmp/root distrib-dirs distribution</userinput></screen>

	<para>Dit maakt de benodigde mappenstructuur en installeert de
	  bestanden.  Een groot deel van de submappen die gemaakt zijn
	  in <filename>/var/tmp/root</filename> zijn leeg en moeten
	  verwijderd worden.  De simpelste manier om dit te doen
	  is:</para>

	<screen>&prompt.root; <userinput>cd /var/tmp/root</userinput>
&prompt.root; <userinput>find -d . -type d | xargs rmdir 2&gt;/dev/null</userinput></screen>

	<para>Dit verwijderd alle lege mappen.  De standaardfout wordt
	  omgeleid naar <filename>/dev/null</filename> om
	  waarschuwingen te voorkomen over mappen die niet leeg
	  zijn.</para>

	<para><filename>/var/tmp/root</filename> bevat nu alle
	  bestanden die geplaatst zouden moeten worden op de juiste
	  locaties in <filename>/</filename>.  Er moet nu in de
	  bestanden gekeken worden om te bepalen of deze verschillen
	  met de huidige betanden.</para>

	<para>Let op dat sommige van de bestanden die
	  geïnstalleerd zijn in <filename>/var/tmp/root</filename>
	  beginnen met een <quote>.</quote>.  Op het moment van
	  schrijven hebben alleen shell opstartscripts in
	  <filename>/var/tmp/root</filename> en
	  <filename>/var/tmp/root/root</filename> dit, maar er kunnen
	  ook andere zijn.  Zorg ervoor dat <command>ls -a</command>
	  gebruikt wordt om deze bestanden te zien.</para>

	<para>De simpelste manier om twee bestanden te vergelijken is
	  &man.diff.1; gebruiken:</para>

	<screen>&prompt.root; <userinput>diff /etc/shells /var/tmp/root/etc/shells</userinput></screen>

	<para>Dit toont de verschillen tussen de huidige
	  <filename>/etc/shells</filename> en de nieuwe
	  <filename>/var/tmp/root/etc/shells</filename>.  Gebruik dit
	  om te bepalen of de wijzigingen gemigreerd moeten worden of
	  dat het oude bestand gekopieërd moet worden.</para>

	<tip>
	  <title>Voeg aan de naam van de nieuwe rootmap
	    (<filename>/var/tmp/root</filename>) een tijdsindicatie toe
	    zodat makkelijk verschillen tussen versies bepaald kunnen
	    worden</title>

	  <para>Als de wereld regelmatig wordt herbouwd moeten
	    bestanden in <filename>/etc</filename> ook regelmatig
	    bijgewerkt moeten worden, wat een vervelend werkje kan
	    zijn.</para>

	  <para>Dit proces kan versneld worden door een kopie te
	    bewaren van de bestanden die gemigreerd zijn naar
	    <filename>/etc</filename>.  De volgende procedure geeft een
	    idee over hoe dit gedaan kan worden.</para>

	  <procedure>
	    <step>
	      <para>Maak de wereld zoals normaal.  Als
		<filename>/etc</filename> en de andere mappen
		bijgewerkt moeten worden, geef dan de doelmap een naam
		gebaseerd op de huidige datum.  Op 14 februari 1998
		wordt dat als volgt gedaan:</para>

	      <screen>&prompt.root; <userinput>mkdir /var/tmp/root-19980214</userinput>
&prompt.root; <userinput>cd /usr/src/etc</userinput>
&prompt.root; <userinput>make DESTDIR=/var/tmp/root-19980214 \
    distrib-dirs distribution</userinput></screen>
	    </step>

	    <step>
	      <para>Migreer de wijzigingen van deze map zoals hierboven
		beschreven.</para>

	      <para>Verwijder de map
		<filename>/var/tmp/root-19980214</filename>
		<emphasis>niet</emphasis> na afronden.</para>
	    </step>

	    <step>
	      <para>Als de laatste versie van de broncode gedownload en
		opnieuw gemaakt is, volg stap 1.  Dit geeft een nieuwe
		map die wellicht
		<filename>/var/tmp/root-19980221</filename> heet (als
		er een week zit tussen het bijwerken).</para>
	    </step>

	    <step>
	      <para>De verschillen die gemaakt zijn in de
		tussenliggende week kunnen nu getoond worden door met
		&man.diff.1; een recursieve diff te maken tussen de
		twee mappen:</para>

	      <screen>&prompt.root; <userinput>cd /var/tmp</userinput>
&prompt.root; <userinput>diff -r root-19980214 root-19980221</userinput></screen>

	      <para>Vaak is dit een kleinere set aan verschillen dan
		tussen <filename>/var/tmp/root-19980221/etc</filename>
		en <filename>/etc</filename>.  Omdat de set
		verschillen kleiner is, is het makkelijker om deze te
		migreren naar de map <filename>/etc</filename>.</para>
	    </step>

	    <step>
	      <para>De oudste van de twee
		<filename>/var/tmp/root-*</filename>-mappen kan nu
		verwijderd worden:</para>

	      <screen>&prompt.root; <userinput>rm -rf /var/tmp/root-19980214</userinput></screen>
	    </step>

	    <step>
	      <para>Herhaal dit proces elke keer als er wijzigingen
		gemigreerd moeten worden naar
		<filename>/etc</filename>.</para>
	    </step>
	  </procedure>

	  <para>Met &man.date.1; kan het maken van de mappen
	    geautomatiseerd worden:</para>

	  <screen>&prompt.root; <userinput>mkdir /var/tmp/root-`date "+%Y%m%d"`</userinput></screen>
	</tip>
      </sect3>
    </sect2>

    <sect2 id="updating-upgrading-rebooting">
      <title>Herstarten</title>

      <para>Dit was het.  Na een controle of alles op de juiste plaats
	staat kan het systeem herstart worden.  Dan kan met een simpele
	&man.shutdown.8;:</para>

      <screen>&prompt.root; <userinput>shutdown -r now</userinput></screen>
    </sect2>

    <sect2>
      <title>Klaar</title>

      <para>Het &os; systeem is nu succesvol bijgewerkt.
	Gefeliciteerd!</para>

      <para>Als er dingen misgingen is het makkelijk om een deel van
	het systeem opnieuw te bouwen.  Als bijvoorbeeld per ongeluk
	<filename>/etc/magic</filename> verwijderd is als onderdeel
	van de upgrade of door het samenvoegen van
	<filename>/etc</filename>, dan werkt &man.file.1; niet meer.
	Dat kan als volgt opgelost worden:</para>

      <screen>&prompt.root; <userinput>cd /usr/src/usr.bin/file</userinput>
&prompt.root; <userinput>make all install</userinput></screen>
    </sect2>

    <sect2 id="updating-questions">
      <title>Vragen</title>

      <qandaset>
	<qandaentry>
	  <question>
	    <para>Moet de wereld opnieuw gemaakt worden voor elke
	      wijziging?</para>
	  </question>

	  <answer>
	    <para>Op deze vraag bestaat geen eenvoudig antwoord, omdat
	      dit afhangt van de aard van de wijziging.  Als
	      bijvoorbeeld net <application>CVSup</application> is
	      gedraaid en de onderstaande bestanden zijn bijgewerkt,
	      dan is het waarschijnlijk niet de moeite waard om de
	      volledige wereld te herbouwen:</para>

	    <screen><filename>src/games/cribbage/instr.c</filename>
<filename>src/games/sail/pl_main.c</filename>
<filename>src/release/sysinstall/config.c</filename>
<filename>src/release/sysinstall/media.c</filename>
<filename>src/share/mk/bsd.port.mk</filename></screen>

	    <para>Dan is het handiger om naar de juiste submappen te
	      gaan, daar <command>make all install</command> uit te
	      voeren en dat is het zo'n beetje.  Maar als er iets
	      wezenlijks is veranderd, bijvoorbeeld
	      <filename>src/lib/libc/stdlib</filename>, dan dient ofwel
	      de wereld herbouwd te worden of tenminste die delen die
	      statisch gelinkt zijn (en ook al het andere dat statisch
	      gelinkt is en onderdeel is van een systeem).</para>

	    <para>Uiteindelijk beslist een beheerder zelf.  Misschien
	      vindt die het prettig iedere twee weken de wereld te
	      herbouwen terwijl de wijzigingen in die twee weken
	      binnenkomen.  Een andere beheerder herbouwt alleen die
	      onderdelen die veranderd zijn en vertrouwt erop dat hij
	      alle afhankelijkheden in de gaten heeft.</para>

	    <para>Natuurlijk hangt het ook af van de keuze hoe vaak het
	      wenselijk is bij te werken en of &os.stable; of
	      &os.current; wordt bijgehouden.</para>
	  </answer>
	</qandaentry>

	<qandaentry>
	  <question>
	    <indexterm><primary>signal 11</primary></indexterm>

	    <para>Het compileren gaat fout met veel meldingen van
	      signal 11 (of andere signalnummers).  Wat is er aan de
	      hand?</para>
	  </question>

	  <answer>
	    <para>Dit wijst meestal op hardwareproblemen.  Het
	      (her)bouwen van de wereld is een prima manier om een
	      stresstest op hardware uit te voeren en hierdoor komen
	      vaak geheugenproblemen bovendrijven.  Die resulteren vaak
	      in een compiler die op mysterieuze wijze overlijdt na het
	      ontvangen van vreemde signalen.</para>

	    <para>Dit probleem is nog duidelijker als na het herstarten
	      van de make het proces opnieuw stopt op een ander
	      punt.</para>

	    <para>Hier biedt niets anders uitkomst dan componenten in
	      een systeem wisselen om uit te zoeken welk component er
	      faalt.</para>
	  </answer>
	</qandaentry>

	<qandaentry>
	  <question>
	    <para>Kan <filename>/usr/obj</filename> verwijderd worden
	      na afloop?</para>
	  </question>

	  <answer>
	    <para>Het korte antwoord is ja.</para>

	    <para><filename>/usr/obj</filename> bevat alle
	      objectbestanden die tijdens het compileren zijn gemaakt.
	      Normaliter is een van de eerste stappen in het
	      <command>make buildworld</command> proces deze map
	      verwijderen en een verse start maken.  In dit geval heeft
	      het behouden van <filename>/usr/obj</filename> na het
	      afronden weinig zin en geeft het ook nogal wat extra
	      vrije schijfruimte (ongeveer 2&nbsp;GB).</para>

	    <para>Als er veel kennis aanwezig is bij een beheerder, dan
	      kan <command>make buildworld</command> aangegeven worden
	      deze stap over te slaan.  Hierdoor draaien volgende
	      builds veel sneller, omdat veel broncode niet opnieuw
	      gecompileerd hoeft te worden.  De andere kant van de
	      medaille is dat er subtiele afhankelijkheidsproblemen
	      kunnen ontstaan, waardoor een build op bijzondere wijze
	      kan falen.  Hierdoor onstaat regelmatig ruis op &os;
	      mailinglijsten als er iemand klaagt dat zijn build faalt,
	      terwijl hij zich niet realiseert dat dit komt doordat hij
	      zijn updateproces niet volgens het boekje heeft
	      uitgevoerd.</para>
	  </answer>
	</qandaentry>

	<qandaentry>
	  <question>
	    <para>Kunnen onderbroken builds gecontinueerd
	      worden?</para>
	  </question>

	  <answer>
	    <para>Dit hangt af van hoever een systeem was voordat een
	      probleem gevonden werd.</para>

	    <para><emphasis>Normaal gesproken</emphasis> (en dit is
	      geen vaste regel) maakt het proces <command>make
		buildworld</command> nieuwe kopieën van essentiele
	      hulpprogramma's (zoals &man.gcc.1; en &man.make.1;) en de
	      systeembibliotheken.  Deze hulpprogramma's en
	      bibliotheken worden daarna geïnstalleerd.  De nieuwe
	      hulpprogramma's en bibliotheken worden daarna gebruikt om
	      zichzelf opnieuw op te bouwen en wederom te installeren.
	      Het complete systeem (nu met gewone programma's zoals
	      &man.ls.1; en &man.grep.1;) wordt daarna opnieuw gebouwd
	      met de nieuwe systeembestanden.</para>

	    <para>Als een systeem in de laatste fase zit (wat uit de
	      uitvoer blijkt) kan dit redelijk veilig gedaan
	      worden:</para>

	    <screen><emphasis>&hellip; fix the problem &hellip;</emphasis>
&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make -DNO_CLEAN all</userinput></screen>

	    <para>Dit maakt het werk van de vorige <command>make
		buildworld</command> niet ongedaan.</para>

	    <para>Als het onderstaande bericht in de uitvoer van
	      <command>make buildworld</command> staat, dan is het
	      redelijk veilig om het te doen:</para>

	    <screen>--------------------------------------------------------------
Building everything..
--------------------------------------------------------------</screen>

	    <para>Als dat bericht er niet is, of er is onzekerheid
	      over, dan is het altijd beter om de build opnieuw te
	      starten vanaf het begin.</para>
	  </answer>
	</qandaentry>

	<qandaentry>
	  <question>
	    <para>Kan kan de wereld bouwen versneld worden?</para>
	  </question>

	  <answer>
	    <itemizedlist>
	      <listitem>
		<para>Draai in single-user modus;</para>
	      </listitem>

	      <listitem>
		<para>Zet de mappen <filename>/usr/src</filename> en
		  <filename>/usr/obj</filename> op aparte
		  bestandssystemen die op aparte schijven staan.  Hang
		  deze schijven als mogelijk aan aparte
		  schijfcontrollers;</para>
	      </listitem>

	      <listitem>
		<para>Nog beter, verspreid de bestandssystemen over
		  meerdere schijven via het apparaat &man.ccd.4;
		  (concatenated disk driver);</para>
	      </listitem>

	      <listitem>
		<para>Zet profiling uit (voeg
		  <quote>NO_PROFILE=true</quote> toe aan
		  <filename>/etc/make.conf</filename>).  Het is zeer
		  waarschijnlijk niet nodig;</para>
	      </listitem>

	      <listitem>
		<para>Geef de optie
		  <option>-j<replaceable>n</replaceable></option> mee
		  aan &man.make.1; om meerdere processen parallel te
		  laten lopen.  Dit helpt in de meeste gevallen,
		  onafhankelijk of er gewerkt wordt op een systeem met
		  één of meerdere processoren;</para>
	      </listitem>

	      <listitem>
		<para>Het bestandssysteem dat
		  <filename>/usr/src</filename> bevat, kan (opnieuw)
		  gemount worden met de optie <option>noatime</option>.
		  Dit voorkomt dat het bestandssysteem de
		  toegangsmomenten registreert.  Deze informatie is
		  waarschijnlijk toch niet nodig.</para>

		<screen>&prompt.root; <userinput>mount -u -o noatime /usr/src</userinput></screen>

		<warning>
		  <para>In dit voorbeeld wordt aangenomen dat
		    <filename>/usr/src</filename> op zijn eigen
		    bestandssysteem staat.  Als dit niet het geval is
		    (bijvoorbeeld als het onderdeel is van
		    <filename>/usr</filename>), dan moet het mountpunt
		    voor dat bestandssysteem gebruikt moeten worden
		    en niet <filename>/usr/src</filename>;</para>
		</warning>
	      </listitem>

	      <listitem>
		<para>Het bestandssysteem dat
		  <filename>/usr/obj</filename> gevat kan (opnieuw)
		  worden gemount met de optie <option>async</option>.
		  Dit zorgt ervoor dat schrijfacties naar een schijf
		  asynchroon plaatsvinden.  In andere woorden: de
		  schrijfactie wordt direct uitgevoerd en de gegevens
		  worden later naar de schijf geschreven.  Dit stelt
		  het systeem in staat om data geclusterd weg te
		  schrijven, wat een grote prestatieverbetering kan
		  opleveren.</para>

		<warning>
		  <para>Houd er rekening mee dat deze optie het
		    bestandssysteem kwetsbaarder maakt.  Met deze optie
		    is er een vergrote kans dat, indien er een
		    stroomstoring optreed, het bestandssysteem in een
		    niet meer te herstellen staat komt als de machine
		    herstart.</para>

		  <para>Als op dit bestandssysteem alleen
		    <filename>/usr/obj</filename> staat, is dit geen
		    probleem.  Als er andere belangrijke gegevens op
		    hetzelfde bestandssysteem staan, zorg er dan voor
		    dat er verse back-ups zijn voordat deze optie
		    aangezet wordt.</para>
		</warning>

		<screen>&prompt.root; <userinput>mount -u -o async /usr/obj</userinput></screen>

		<warning>
		  <para>Zorg ervoor, zoals al eerder is aangegeven, dat
		    als <filename>/usr/obj</filename> niet op een eigen
		    bestandssysteem staat, het juiste mountpunt wordt
		    gebruikt.</para>
		</warning>
	      </listitem>
	    </itemizedlist>
	  </answer>
	</qandaentry>

	<qandaentry>
	  <question>
	    <para>Wat te doen als er iets mis gaat?</para>
	  </question>

	  <answer>
	    <para>Zorg ervoor dat het systeem geen rommel meer bevat
	      van eerdere builds.  Het volgende helpt daarbij:</para>

	    <screen>&prompt.root; <userinput>chflags -R noschg /usr/obj/usr</userinput>
&prompt.root; <userinput>rm -rf /usr/obj/usr</userinput>
&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make cleandir</userinput>
&prompt.root; <userinput>make cleandir</userinput></screen>

	    <para>Inderdaad, <command>make cleandir</command> moet twee
	      keer gedraaid worden.</para>

	    <para>Herstart daarna het complete proces vanaf
	      <command>make buildworld</command>.</para>

	    <para>Als er nog steeds problemen zijn, stuur dan de
	      foutmelding en de uitvoer van <command>uname -a</command>
	      naar de &a.questions;.  Wees bereid aanvullende vragen
	      over het systeem te beantwoorden!</para>
	  </answer>
	</qandaentry>
      </qandaset>
    </sect2>
  </sect1>

  <sect1 id="make-delete-old">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Antn</firstname>
	  <surname>Shterenlikht</surname>
	  <contrib>Gebaseerd op notities van </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Het verwijderen van overbodige bestanden, directories en
      bibliotheken</title>

    <indexterm>
      <primary>Verwijderen van overbodige bestanden, directories en
	bibliotheken</primary>
    </indexterm>

    <para>Als onderdeel van de &os; ontwikkel levenscyclus kan het van
      tijd tot tijd gebeuren dat bestanden en de inhoud ervan overbodig
      worden.  Dit kan komen doordat de functionaliteit ergens anders
      geïmplementeerd is, het versienummer van de bibliotheek
      veranderd is of hij is totaal van het systeem verdwenen.  Dit is
      inclusief oude bestanden, bibliotheken en directories welke
      verwijderd moeten worden bij het updaten van het systeem.  Het
      voordeel voor de gebruiker is dat het systeem niet vervuild wordt
      met oude bestanden die onnodig ruimte innemen op het opslag (en
      back-up) systeem.  Ook is het zo dat als de oude bibliotheek een
      beveiligings of stabiliteits probleem had, er moet worden geupdate
      naar de nieuwere bibliotheek om het systeem veilig te houden en te
      voorkomen dat er crashes komen door de oude implementatie van de
      bibliotheek.  De bestanden, directories en bibliotheken welke als
      overbodig worden gezien zijn beschreven in
      <filename>/usr/src/ObsoleteFiles.inc</filename>.  De volgende
      instructies zullen helpen om deze verouderde bestanden te verwijderen
      tijdens het systeem upgrade proces.</para>

    <para>Er wordt aangenomen dat de stappen gevolgd worden zoals uitgelegd
      in <xref linkend="canonical-build"/>.  Na het <command>make
      <maketarget>installworld</maketarget></command> commando en het daarop
      volgende <command>mergemaster</command> commando succesvol uitgevoerd zijn
      kan er op de volgende manier gecontroleerd worden voor verouderde
      bestanden en bibliotheken:</para>

    <screen>&prompt.root; <userinput>cd /usr/src</userinput>
&prompt.root; <userinput>make check-old</userinput></screen>

    <para>Als er verouderde bestanden gevonden worden kunnen deze verwijderd
      worden door het volgende commando:</para>

    <screen>&prompt.root; <userinput>make delete-old</userinput></screen>

    <tip>
      <para>Zie het <filename>/usr/src/Makefile</filename>
	bestand voor meer interessante targets.</para>
    </tip>

    <para>Er wordt een prompt getoond voordat elk verouderd bestand wordt
      verwijderd.  Deze prompt kan worden overgeslagen en het systeem deze
      bestanden automatisch laten verwijderen door gebruik te maken van de
      <makevar>BATCH_DELETE_OLD_FILES</makevar> make variabele als volgt:</para>

    <screen>&prompt.root; <userinput>make -DBATCH_DELETE_OLD_FILES delete-old</userinput></screen>

    <para>Dit kan ook worden gedaan door deze commando's door
      <command>yes</command> te pipen als volgt:</para>

    <screen>&prompt.root; <userinput>yes|make delete-old</userinput></screen>

    <warning>
      <title>Waarschuwing</title>

      <para>Het verwijderen van verouderde bestanden zal applicaties
	stuk maken die nog gebruik maken van de overbodige bestanden.
	Dit is zeker waar voor oude bibliotheken.  In de meeste gevallen
	moeten de programma's, ports of bibliotheken opnieuw gecompileerd
	worden voordat
	<command>make <maketarget>delete-old-libs</maketarget></command>
	wordt uitgevoerd.</para>
    </warning>

    <para>Gereedschappen om gedeelde bibliotheek afhankelijkheden te controleren
      zijn beschikbaar in de Ports Collectie in <filename
	role="package">sysutils/libchk</filename> of <filename
	role="package">sysutils/bsdadminscripts</filename>.</para>

    <para>Overbodige gedeelde bibliotheken kunnen conflicteren met
      nieuwere bibliotheken welke berichten zoals deze kunnen
      veroorzaken:</para>

    <screen>/usr/bin/ld: warning: libz.so.4, needed by /usr/local/lib/libtiff.so, may conflict with libz.so.5
/usr/bin/ld: warning: librpcsvc.so.4, needed by /usr/local/lib/libXext.so, may conflict with librpcsvc.so.5</screen>

    <para>Om deze problemen op te lossen moet bepaald worden welke port
      deze bibliotheek heeft geïnstalleerd:</para>

    <screen>&prompt.root; <userinput>pkg_info -W /usr/local/lib/libtiff.so</userinput>
/usr/local/lib/libtiff.so was installed by package tiff-3.9.4
&prompt.root; <userinput>pkg_info -W /usr/local/lib/libXext.so</userinput>
/usr/local/lib/libXext.so was installed by package libXext-1.1.1,1</screen>

    <para>Deïnstalleer, herbouw en herinstalleer de port.  De <filename
	role="package">ports-mgmt/portmaster</filename> en <filename
	role="package">ports-mgmt/portupgrade</filename> gereedschappen kunnen
      gebruikt worden om deze processen te automatiseren.  Nadat zeker is dat
      alle ports opnieuw gebouwd zijn, en de oude bibliotheken niet meer
      gebruikt worden, kunnen deze verwijderd worden met het volgende
      commando:</para>

    <screen>&prompt.root; <userinput>make delete-old-libs</userinput></screen>
  </sect1>

  <sect1 id="small-lan">
    <sect1info>
      <authorgroup>
	<author>
	  <firstname>Mike</firstname>
	  <surname>Meyer</surname>
	  <contrib>Bijgedragen door </contrib>
	</author>
      </authorgroup>
    </sect1info>

    <title>Meerdere machines bijwerken</title>

    <indexterm>
      <primary>NFS</primary>

      <secondary>meerdere machines installeren</secondary>
    </indexterm>

    <para>Als er meerdere machines zijn die dezelfde broncode
      bijhouden, lijkt het downloaden van alle broncode en alles overal
      opnieuw bouwen zonde van de bronnen: harde schijfruimte, netwerk
      bandbreedte, en processorbelasting.  Dit klopt en de oplossing is
      om alles op één machine te doen terwijl de overige
      machines het uitgevoerde werk benaderen via NFS.  Nu wordt een
      methode beschreven waarmee dit gedaan kan worden.</para>

    <sect2 id="small-lan-preliminaries">
      <title>Benodigdheden</title>

      <para>Als eerste moet er een groep van machines gekozen worden
	die dezelfde set aan binaire bestanden zal draaien, hier een
	<emphasis>bouwgroep</emphasis>.  Elke machine kan een eigen
	afwijkende kernel hebben maar moet dezelfde binaire
	gebruikersbestanden draaien.  Uit die groep moet een machine
	gekozen worden die de <emphasis>bouwmachine</emphasis> wordt.
	Dit wordt de machine waar de wereld en kernel op gebouwd
	worden.  In het meest ideale geval is dit een snelle machine
	die genoeg processorkracht vrij heeft om <command>make
	  buildworld</command> en <command>make buildkernel</command>
	te draaien.  Er moet ook een machine gekozen worden die de
	<emphasis>testmachine</emphasis> wordt waarop alle bijgewerkte
	software wordt test voordat die in productie wordt genomen.
	Dit <emphasis>moet</emphasis> een machine zijn die voor langere
	tijd down mag zijn.  Dit kan de bouwmachine zijn maar dat hoeft
	niet per se.</para>

      <para>Alle machines in deze bouwgroep moeten ingesteld worden om
	<filename>/usr/obj</filename> en <filename>/usr/src</filename>
	vanaf dezelfde machine te mounten op hetzelfde punt.  In het
	meest ideale geval zijn dit twee verschillende schijven op de
	bouwmachine, maar ze kunnen ook door middel van NFS op die
	machine gemount zijn.  Als er meerdere bouwgroepen zijn, dan
	moet <filename>/usr/src</filename> op één
	bouwmachine staan en door middel van NFS gemount worden op de
	overige machines.</para>

      <para>Zorg er als laatste voor dat
	<filename>/etc/make.conf</filename> en
	<filename>/etc/src.conf</filename> op alle machines in de
	bouwgroep het eens zijn met de bouwmachine.  Dat betekent dat
	de bouwmachine alle delen van het basissysteem moet bouwen die
	elke machine in de bouwgroep installeert.  Ook heeft elke
	bouwmachine zijn kernelnaam ingesteld met
	<makevar>KERNCONF</makevar> in
	<filename>/etc/make.conf</filename> en de bouwmachine moet ze
	allemaal hebben in <makevar>KERNCONF</makevar>, zijn eigen
	kernel eerst.  De bouwmachine moet de instellingenbestanden
	voor elke machine in
	<filename>/usr/src/sys/<replaceable>arch</replaceable>/conf</filename>
	hebben als deze machine de kernels voor de overige machines
	gaat bouwen.</para>
    </sect2>

    <sect2 id="small-lan-base-system">
      <title>Basissysteem</title>

      <para>Nu kan één systeem alles bouwen.  Bouw de
	kernel en wereld zoals beschreven in <xref
	  linkend="make-buildworld"/> op de bouwmachine, maar installeer
	niets.  Zodra de bouw klaar is, moet op de testmachine de
	kernel geïnstalleerd en getest worden.  Als deze machine
	<filename>/usr/src</filename> en <filename>/usr/obj</filename>
	mount via NFS, moet na een herstart in single-user modus het
	netwerk ingeschakeld worden zodat de mounts opnieuw gemaakt
	kunnen worden.  De makkelijkste manier om dit te doen is om te
	starten in multi-user modus en daar
	<command>shutdown now</command> starten om in single-user modus
	te komen.  Eenmaal daar aangekomen kunnen de nieuwe kernel en
	de wereld geïnstalleerd worden en kan daarna normaal
	<command>mergemaster</command> gestart worden.  Zodra dit klaar
	is, kan de machine opnieuw gestart worden om naar multi-user
	modus terug te keren.</para>

      <para>Nadat zeker is dat alles op de testmachine correct werkt,
	kan dezelfde procedure gebruikt worden om de nieuwe software op
	elke machine te installeren in de bouwgroep.</para>
    </sect2>

    <sect2 id="small-lan-ports">
      <title>Ports</title>

      <para>Dezelfde ideeën kunnen gebruikt worden voor de ports.
	De eerste kritieke stap is om <filename>/usr/ports</filename>
	te mounten op alle machines in de bouwgroep.  Daarna kan
	<filename>/etc/make.conf</filename> correct ingesteld worden
	om de distfiles te delen.  De variabele
	<makevar>DISTDIR</makevar> moet wijzen naar een gedeelde map
	waarin geschreven kan worden door de gebruiker waar
	<username>root</username> naar wijst in de NFS mounts.  Op elke
	machine moet <makevar>WRKDIRPREFIX</makevar> naar een lokale
	bouwmap wijzen.  Als er pakketten gebouwd en gedistribueerd
	worden moet <makevar>PACKAGES</makevar> naar een map wijzen
	gelijkvormig aan de instelling voor
	<makevar>DISTDIR</makevar>.</para>
    </sect2>
  </sect1>
</chapter>