---
title: 24. Fejezet - A FreeBSD frissítése és frissen tartása
part: III. Rész Rendszeradminisztráció
prev: books/handbook/l10n
next: books/handbook/dtrace
showBookMenu: true
weight: 28
params:
  path: "/books/handbook/cutting-edge/"
---

[[updating-upgrading]]
= A FreeBSD frissítése és frissen tartása
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 24
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/handbook/cutting-edge/

ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[[updating-upgrading-synopsis]]
== Áttekintés

A FreeBSD a kiadások közt is állandó fejlõdésben van. Vannak felhasználók, akik a hivatalosan kiadott változatokat használják, és vannak, akik szeretik folyamatosan nyomonkövetni a fejlesztéseket. Emellett viszont a hivatalos kiadások esetében szükség lehet bizonyos biztonsági frissítések és kritikus javítások alkalmazására. Függetlenül a pillanatnyilag használt változattól, a FreeBSD alaprendszerében megtalálható minden olyan eszköz, amellyel könnyedén frissíteni tudunk a különbözõ verziók között. Ebben a fejezetben segítünk dönteni a fejlesztõi változat és a kiadások használata között. Továbbá megismerhetjük a rendszer frissítéséhez használható alapvetõ eszközöket.

A fejezet elolvasása során megismerjük:

* milyen segédprogramokkal tudjuk frissíteni az alaprendszert és a Portgyûjteményt;
* hogyan tartsuk naprakészen rendszerünket a freebsd-update, CVSup, CVS vagy CTM használatával;
* hogyan vessük össze a telepített rendszerünk aktuális állapotát egy ismert eredeti változattal;
* hogyan frissítsük a dokumentációt CVSup vagy dokumentációs portok segítségével.
* a két fejlesztõi ág, a FreeBSD-STABLE és a FreeBSD-CURRENT közti különbséget;
* a `make buildworld` (stb.) segítségével hogyan fordítsuk és telepítsük újra az egész alaprendszert.

A fejezet elolvasásához ajánlott:

* a hálózati kapcsolatunk helyes beállítása (crossref:advanced-networking[advanced-networking,Egyéb haladó hálózati témák]);
* a külsõ szoftverek telepítésének ismerete (crossref:ports[ports,Alkalmazások telepítése. csomagok és portok]).

[NOTE]
====
A fejezetben a FreeBSD forrásainak frissítését a `cvsup` parancs segítségével fogjuk elvégezni. Ehhez telepítsük a package:net/cvsup[] portot vagy csomagot (ha a `cvsup` parancsot nem akarjuk grafikus felületen keresztül használni, akkor elegendõ csak a [.filename]#net/cvsup-without-gui# portot). Ha a FreeBSD 6.2-RELEASE vagy késõbbi változatával rendelkezünk, akkor elegendõ csak az alaprendszer részeként elérhetõ man:csup[1] programot használnunk.
====

[[updating-upgrading-freebsdupdate]]
== A FreeBSD frissítése

A biztonsági javítások telepítése minden számítógépes szoftver, különösen az operációs rendszerek számára lényeges mozzanat. Nagyon hosszú ideig ez a FreeBSD esetében nem volt könnyen megoldható: a javításokat közvetlenül a forráskódon kellett elvégezni, ezekbõl újrafordítani a rendszert, majd telepíteni.

Ez a nehézség mostanra viszont már elhárult, mivel a FreeBSD legfrissebb verziói már tartalmaznak egy `freebsd-update` nevû segédprogramot, amellyel mindez leegyszerûsödik. Ez a program két külön funkciót lát el. Elõször is, lehetõvé teszi, hogy a FreeBSD alaprendszer újrafordítása és -telepítése nélkül javítsunk biztonsági és egyéb apró hibákat, valamint másodsorban támogatja a kisebb és nagyobb verziójú kiadások közti váltást.

[NOTE]
====
Ezek a bináris frissítések azonban csak a FreeBSD biztonsági csapata által is felügyelt architektúrák és kiadások esetén érhetõek el. Emellett bizonyos lehetõségek használatához, például a FreeBSD verziói közti átállás támogatásához a man:freebsd-update[8] legújabb változata szükségeltetik. Ezért ne felejtsük el alaposan átolvasni a legújabb kiadásokról szóló bejelentéseket mielõtt frissítenénk rájuk, mivel ezzel kapcsolatban fontos információkat tartalmazhatnak. Az említett bejelentések a http://www.FreeBSD.org/releases/[http://www.FreeBSD.org/releases/] címen érhetõek el.
====

Ha a `crontab` már hivatkozik a `freebsd-update` programra, akkor a most következõ mûvelet elkezdése elõtt tiltsuk le.

[[freebsdupdate-config-file]]
=== A konfigurációs állományok

Ha változtatnénk szeretnénk a frissítési folyamaton, ekkor a programhoz tartozó, [.filename]#/etc/freebsd-update.conf# nevû konfigurációs állományt kell módosítanunk. Az opciók részletes ismertetéssel rendelkeznek, habár némelyiknél még további magyarázat kellhet:

[.programlisting]
....
# Az alaprendszerben frissíteni kívánt komponensek
Components src world kernel
....

Ezzel a paraméterrel határozhatjuk meg, hogy a FreeBSD mely részei kerüljenek frissítésre. Alapértelmezés szerint a program frissíti a forrásokat, a teljes alaprendszert és a rendszermagot. Komponensként a telepítésnél választható elemeket adhatjuk meg, például "world/games" hozzáadásakor a games kategória elemei is folyamatosan frissülni fognak. Az "src/bin" megadásakor pedig az [.filename]#src/bin# könyvtár tartalma frissül.

Ezt a beállítást a legjobb meghagyni az alapértelmezett értéken, mivel a további elemek megadásánál egyenként fel kell sorolni a frissítendõ komponenseket. Ha itt viszont kifelejtünk valamit, akkor könnyen megeshet, hogy a források és a binárisok verziója elcsúszik egymástól.

[.programlisting]
....
# Az IgnorePaths beállítás után megadott szövegre illeszkedõ összes
# bejegyzés frissítése kimarad
IgnorePaths
....

Ennél a beállításnál azokat a könyvtárakat kell megadnunk, amelyeket (és tartalmukat) ki szeretnénk hagyni a frissítés során. Ezek lehetnek például a [.filename]#/bin# vagy az [.filename]#/sbin#. Így meg tudjuk akadályozni, hogy `freebsd-update` esetleg felülírjon valamilyen helyi változtatást a rendszerünkben.

[.programlisting]
....
# Az UpdateIfUnmodified beállítás után megadott elérési útvonalakon csak
# a felhasználó által még nem módosított állományok fognak frissülni
# (hacsak a módosításokat össze nem fésüljük, lásd lentebb)
UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile
....

A megadott könyvtárakban csak azokat a konfigurációs állományokat fogja frissíteni, amelyeket nem változtattuk meg. Amennyiben bármelyikük eltér az eredetileg frissítendõ változattól, azt a program nem módosítja. Létezik egy másik hasonló beállítás, a `KeepModifiedMetadata`, amely hatására a `freebsd-update` az összefésülés során elmenti a változtatásokat.

[.programlisting]
....
# A MergeChanges beállításnál szereplõ állományok helyi módosításait
# automatikusan összefésüljük a FreeBSD újabb verziójára frissítése közben
MergeChanges /etc/ /var/named/etc/
....

Itt azokat a könyvtárakat adhatjuk meg, amelyekben a `freebsd-update` számára engedélyezzük a konfigurációs állományok új verziójának összefésülését a jelenlegi állapottal. Az összefésülés lényegében a man:mergemaster[8] használatánál már megszokott módon, man:diff[1] formátumban érkezõ módosítások sorozata alapján történik. Ekkor egy szövegszerkesztõ segítségével felügyelhetjük az összefésülés menetét vagy megállíthatjuk a `freebsd-update` futását. Ha kétségeink adódnak, akkor egyszerûen mentsük le az [.filename]#/etc# könyvtárat és fogadjuk el mindegyik összefésülés eredményét. A `mergemaster` mûködésérõl a <<mergemaster>> ad részletesebb tájékoztatást.

[.programlisting]
....
# A FreeBSD frissítésekor ezt a könyvtárat fogja a program használni a
# letöltött módosítások és az egyéb ideiglenes állományok tárolására
# WorkDir /var/db/freebsd-update
....

Az itt megadott könyvtárba fognak kerülni az elvégzendõ módosítások és az egyéb ideiglenesen keletkezõ állományok. A verziók közti váltás során ebben a könyvtárban ajánlott legalább 1 GB szabad tárterületnek lennie.

[.programlisting]
....
# A kiadások közti váltás során a Components beállításnál megadott
# elemek kerüljenek csak frissítésre (StrictComponents yes), vagy a
# program próbálja meg magától kitalálni, hogy milyen komponesek
# *lehetnek* fenn a rendszeren és azokat frissítse (StrictComponents
# no)?
# StrictComponents no
....

Ha ennél a beállításnál a `yes` értéket adjuk meg, akkor a `freebsd-update` feltételezni fogja, hogy a `Components` opciónál felsoroltunk minden frissítendõ komponenst és nem próbál meg mást is megváltoztatni. Ilyenkor tehát a `freebsd-update` tulajdonképpen egyedül csak a `Components` által meghatározott elemekhez tartozó állományokat fogja frissíteni.

[[freebsdupdate-security-patches]]
=== Biztonsági javítások

A biztonsági javítások mindig egy távoli gépen tárolódnak, a következõ parancsok használatával tölthetõek le és telepíthetõek:

[source,shell]
....
# freebsd-update fetch
# freebsd-update install
....

Amennyiben a rendszermagot is érintik javítások, úgy a rendszert a mûvelet befejezõdésével újra kell indítanunk. Ha minden a megfelelõ módon történt, akkor a rendszerünk már tartalmazni fogja a korábban letöltött és telepített javításokat, és a `freebsd-update` akár beállítható egy naponta végrehajtandó man:cron[8] feladatnak. Ehhez mindössze a következõ bejegyzést kell elhelyeznünk az [.filename]#/etc/crontab# állományban:

[.programlisting]
....
@daily                                  root    freebsd-update cron
....

A bejegyzés szerint naponta egyszer le fog futni a `freebsd-update`. Ilyenkor, vagyis a `cron` paraméter megadásakor a `freebsd-update` csak ellenõrzi, hogy vannak-e telepítendõ frissítések. Ha talál, akkor automatikusan letölti ezeket a lemezre, de nem telepíti. Helyette levélben értesíti a `root` felhasználót, aki ezután bármikor manuálisan kérheti a telepítést.

Probléma esetén az alábbi paranccsal megkérhetjük a `freebsd-update` programot a legutóbb telepített módosítások visszavonására:

[source,shell]
....
# freebsd-update rollback
....

Ha ez a visszavonás a rendszermagra vagy annak moduljaira is vonatkozott, akkor a rendszert újra kell indítanunk a parancs futásának befejezõdésével. A FreeBSD csak ilyenkor képes betölteni az új binárisokat betölteni a memóriába.

A `freebsd-update` önmagától csak a `GENERIC` típusú rendszermagokat képes frissíteni. Ha saját rendszermagot használunk, akkor azt a rendszer többi komponensének frissítését követõen újra kell fordítanunk és telepítenünk. A `freebsd-update` azonban még akkor is érzekelni és frissíteni fogja a `GENERIC` rendszermagot (amennyiben az létezik), ha az éppen nem az aktuális(an futó) rendszermag.

[NOTE]
====
Mindig érdemes tartani egy másolatot a `GENERIC` rendszermagról a [.filename]#/boot/GENERIC# könyvtárban. Rengeteg különbözõ probléma felderítésében tud segíteni, illetve ez a <<freebsdupdate-upgrade>> szakaszban leírt `freebsd-update` programmal végzett frissítéseknél is hasznos lehet.
====

Hacsak nem változtatjuk meg az [.filename]#/etc/freebsd-update.conf# állományt, a `freebsd-update` a rendszermag forrásait is frissíti a többivel együtt. A saját rendszermag újrafordítása és telepítése ezután a már a megszokott módon elvégezhetõ.

[NOTE]
====
A `freebsd-update` által terjesztett frissítések nem mindig érintik a rendszermagot. Ha a rendszermag forrásai nem változnak egy `freebsd-update install` parancs kiadása során, akkor nem kötelezõ újrafordítani a saját rendszermagot. A `freebsd-update` viszont mindig módosítani fogja a [.filename]#/usr/src/sys/conf/newvers.sh# állományt. Itt az aktuális hibajavítás sorszáma szerepel (amelyet a `-p` (mint "patch level" elõtaggal kapcsolnak a rendszer verziójához, és a `uname -r` paranccsal lehet lekérdezni). Ennek megfelelõen tehát a saját rendszermag újrafordítása után, még ha semmi más nem is változott, a man:uname[1] képes pontosan jelezni a rendszerhez készült hibajavítás sorszámát. Ez különösen fontos több rendszer karbantartása során, mivel így könnyen és gyorsan tájékozódhatunk azok naprakészségérõl.
====

[[freebsdupdate-upgrade]]
=== Váltás kisebb és nagyobb verziók között

Verziók közti váltás során a külsõ alkalmazások mûkõdését akadályozó régi tárgykódok és függvénykönyvtárak törlõdni fognak. Ezért javasoljuk, hogy vagy töröljük le az összes portot és telepítsük újra, vagy az alaprendszer frissítése után hozzuk ezeket is naprakész állapotba a package:ports-mgmt/portupgrade[] segédprogram segítségével. Elõször minden bizonnyal szeretnék kipróbálni a frissítést, ezt a következõ paranccsal tehetjük meg:

[source,shell]
....
# portupgrade -af
....

Ezzel gondoskodunk róla, hogy a minden a megfelelõen telepítõdjön újra. Ha a `BATCH` környezeti változót a `yes` értékre állítjuk, akkor a folyamat során megjelenõ összes kérdésre automatikusan a `yes` választ adjuk, ezáltal önállósítani tudjuk.

Ha saját rendszermagot használunk, akkor ennél valamivel azért több feladatunk van. Szükségünk lesz a `GENERIC` rendszermagot egy példányára, amelyet másoljunk a [.filename]#/boot/GENERIC# könyvtárba. Amennyiben nincs `GENERIC` típusú rendszermag a rendszerünkön, a következõ módok valamelyikén keresztül tudunk szerezni:

* Ha a saját rendszermagot még csak egyszer fordítottuk, akkor a [.filename]#/boot/kernel.old# könyvtárban még megtalálható a `GENERIC`. Ezt nevezzük át egyszerûen [.filename]#/boot/GENERIC# könyvtárra.
* Ha fizikailag hozzá tudunk férni az érintett géphez, akkor a `GENERIC` egy példányát akár CD-rõl is átmásolhatjuk. Helyezzük be a telepítõlemezt és adjuk ki a következõ parancsokat:
+
[source,shell]
....
# mount /cdrom
# cd /cdrom/X.Y-RELEASE/kernels
# ./install.sh GENERIC
....
+ 
Itt a [.filename]#X.Y-RELEASE# könyvtár nevében értelemszerûen helyettesítsük be az általunk használt változatot. A `GENERIC` rendszermag ekkor alapértelmezés szerint a [.filename]#/boot/GENERIC# könyvtárba kerül.
* Ha az elõbbiek közül egyik sem lehetséges, akkor a `GENERIC` rendszermagot közvetlenül akár forrásból is lefordíthatjuk és telepíthetjük:
+
[source,shell]
....
# cd /usr/src
# env DESTDIR=/boot/GENERIC make kernel
# mv /boot/GENERIC/boot/kernel/* /boot/GENERIC
# rm -rf /boot/GENERIC/boot
....
+ 
A `freebsd-update` akkor fogja ezt `GENERIC` rendszermagként felismerni, ha a hozzá tartozó konfigurációs állományt nem módosítjuk. Továbbá javasoljuk, hogy semmilyen speciális beállítást ne alkalmazzunk a fordítás során (érdemes üresen hagyni ehhez az [.filename]#/etc/make.conf# állományt).

Nem kötelezõ újraindítani a rendszert a `GENERIC` rendszermaggal.

A `freebsd-update` képes frissíteni rendszerünket egy adott kiadásra. Például a következõ paraméterek megadásával válthatunk a FreeBSD 6.4 használatára:

[source,shell]
....
# freebsd-update -r 6.4-RELEASE upgrade
....

A parancs elindulása után nem sokkal, a váltáshoz szükséges információk összegyûjtéséhez a `freebsd-update` elemzi a konfigurációs állományában megadott beállításokat és a rendszer jelenleg használt verzióját. A képernyõn ekkor sorban megjelennek a program részérõl érzékelt és nem érzékelt komponensek. Mint például ahogy itt látható:

[source,shell]
....
Looking up update.FreeBSD.org mirrors... 1 mirrors found.
Fetching metadata signature for 6.3-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
....

Ekkor a `freebsd-update` megpróbálja letölteni a verziók közti váltáshoz szükséges összes állományt. Bizonyos esetekben kérdésekkel fordul a felhasználó felé arra vonatkozóan, hogy miket telepítsen fel vagy mit csináljon.

A saját rendszermag használatakor az iménti lépés valamilyen ehhez hasonló figyelmeztetést fog adni:

[source,shell]
....
WARNING: This system is running a "SAJÁT RENDSZERMAG" kernel, which is not a
kernel configuration distributed as part of FreeBSD 6.3-RELEASE.
This kernel will not be updated: you MUST update the kernel manually
before running "/usr/sbin/freebsd-update install"
....

Ez a figyelmeztetés most nyugodtan figyelmen kívül hagyható. A folyamat során a frissített `GENERIC` rendszermagot fogjuk használni.

A javítások letöltését követõen megkezdõdik a telepítésük. A váltás ezen lépése az adott gép aktuális terhelésétõl és sebességétõl függõen változó hosszúságú lehet. Ezután a konfigurációs állományok összefésülése zajlik le - itt általában a emberi felügyeletre is szükség van az állományok összefésülésének irányításához, amelynek folyamatosan láthatóak az eredményei. A meghiúsult vagy kihagyott összefésülések a teljes frissítési folyamat leállását vonják maguk után. Az [.filename]#/etc# könyvtárban tárolt fontosabb állományokról, mint például a [.filename]#master.passwd# vagy [.filename]#group# javasolt elõzetesen biztonsági mentést készíteni és késõbb kézzel hozzájuk adni a változtatásaikat.

[NOTE]
====
A rendszerben ekkor még nem lesz jelen semmilyen konkrét változás, az összes említett javítás és összefésülés egy külön könyvtárban történik. A telepített javításokat és az összefésült konfigurációs állományokat a folyamat végén magának a felhasználónak kell véglegesíteni.
====

A frissítési eljárás végén a következõ parancs kiadásával tudjuk ténylegesen érvényesíteni az eddig elvégzett módosításokat:

[source,shell]
....
# freebsd-update install
....

Elõször mindig a rendszermag és a hozzá tartozó modulok cserélõdnek le. Ahogy ez végrehajtódott, újra kell indítanunk a rendszert. Ha saját rendszermagot használunk, akkor a man:nextboot[8] parancs segítségével állítsuk be a következõ rendszerindítás során betöltendõ rendszermagot a [.filename]#/boot/GENERIC# könyvtárban levõre (ezt frissítettük):

[source,shell]
....
# nextboot -k GENERIC
....

[WARNING]
====

Mielõtt újraindítanánk a gépünket a `GENERIC` rendszermaggal, gyõzõdjünk meg róla, hogy szerepel benne minden olyan meghajtó, amely elengedhetetlen a rendszer hiánytalan indításához (és képes lesz újra csatlakozni a hálózathoz, ha éppen távolról adminisztráljuk). Ez különösen olyan esetben fontos, amikor a saját rendszermagunkban beépítetten szerepeltek bizonyos modulok. Ilyenkor a `GENERIC` rendszermag használatakor ezeket a [.filename]#/boot/loader.conf# állományon keresztül töltethetjük be ideiglenesen. A frissítés befejezéséig érdemes viszont minden nem létfontosságú szolgáltatást leállítani, leválasztani lemezeket és hálózati megosztásokat stb.
====

A rendszerünk most már újraindítható a frissített rendszermaggal:

[source,shell]
....
# shutdown -r now
....

A rendszer sikeres újraindulása után ismét el kell indítanunk a `freebsd-update` programot, amely korábban már elmentette a frissítés állapotát, emiatt a legutóbbi pontról fog folytatódni, illetve törli az osztott könyvtárak és tárgykódok régebbi változatait. Innen az alábbi paranccsal léphetünk tovább:

[source,shell]
....
# freebsd-update install
....

[NOTE]
====
A függvénykönyvtárak verziói közti eltérések mértékétõl függõen elképzelhetõ, hogy a telepítés az említett három fázis helyett kettõben történik.
====

Most pedig újra kell fordítanunk vagy telepítenünk az összes általunk korábban használt külsõ alkalmazást. Erre azért van szükségünk, mert bizonyos alkalmazások a verziók közti váltás során törölt programkönyvtáraktól függtek. Ennek automatizálásában a package:ports-mgmt/portupgrade[] lesz segítségünkre. Az alkalmazások frissítésének elindításához a következõ parancsokat használjuk:

[source,shell]
....
# portupgrade -f ruby
# rm /var/db/pkg/pkgdb.db
# portupgrade -f ruby18-bdb
# rm /var/db/pkg/pkgdb.db /usr/ports/INDEX-*.db
# portupgrade -af
....

A parancsok lefutását követõen a `freebsd-update` utolsó hívásával zárjuk le a frissítést. Ezzel a paranccsal tudunk tehát pontot tenni a frissítési procedúra végére:

[source,shell]
....
# freebsd-update install
....

Ha a `GENERIC` rendszermagot csak átmenetileg használtuk, akkor most már a megszokott módon fordíthatunk és telepíthetünk magunk egy saját rendszermagot.

Indítsuk újra a rendszert a FreeBSD frissített változatával. A folyamat ezzel véget ért.

[[freebsdupdate-system-comparison]]
=== Rendszerek állapotainak összehasonlítása

A `freebsd-update` ragyogóan felhasználható a FreeBSD egy telepített változatának és egy általunk garantáltan megbízható példányának összevetésére. Ilyenkor a rendszerhez tartozó segédprogramokat, programkönyvtárakat és konfigurációs állományokat ellenõriztethetjük le. Az összehasonlítást ezzel a paranccsal kezdhetjük meg:

[source,shell]
....
# freebsd-update IDS >> eredmeny.idk
....

[WARNING]
====

Habár a parancs neve IDS (intrusion detection system), nem helyettesít semmilyen olyan behatolásjelzõ megoldást, mint amilyen például a package:security/snort[]. Mivel a `freebsd-update` adatokat tárol a lemezen, teljesen kézenfekvõ a hamisítás lehetõsége. Míg ennek eshetõsége adott mértékben visszaszorítható a `kern.securelevel` csökkentésével és a `freebsd-update` által használt adatok írásvédett állományrendszerre helyezésével, erre a problémára az ideális megoldást mégis egy teljes biztonságban tudható referencia rendszer jelentheti. Ennek tárolására alkalmas lehet például egy DVD vagy egy külsõ USB-egység.
====

A parancs kiadása után megkezdõdik a rendszer vizsgálata, és az ellenõrzés során folyamatosan jelennek meg az átvizsgált állományok a hozzájuk tartozó ismert és kiszámított man:sha256[1]-kódjukkal együtt. Mivel a képernyõn túlságosan gyorsan elúsznának az eredmények, ezért ezeket egy [.filename]#eredmeny.idk# nevû állományba mentjük a késõbbi elemzésekhez.

Az így keletkezõ állomány sorai ugyan meglehetõsen hosszúak, de szerencsére viszonylag könnyen értelmezhetõek. Például az adott kiadásban szereplõ állományoktól eltérõeket ezzel a paranccsal kérdezhetjük le:

[source,shell]
....
# cat eredmeny.idk | awk '{ print $1 }' | more
/etc/master.passwd
/etc/motd
/etc/passwd
/etc/pf.conf
....

A példában most csak az elsõ néhány állományt hagytuk meg, gyakran tapasztalhatunk viszont ennél többet. Ezek közül bizonyos állományok értelemszerûen eltérnek, mint itt például az [.filename]#/etc/passwd#, mert idõközben új felhasználókat adtunk a rendszerhez. Máskor egyéb állományok, például modulok nevei is felbukkanhatnak, mert tegyük fel, hogy a `freebsd-update` már frissítette ezeket. Ha ki szeretnénk zárni valamilyen állományokat vagy könyvtárakat az ellenõrzésbõl, egyszerûen csak soroljuk fel ezeket az [.filename]#/etc/freebsd-update.conf# állományban megjelenõ `IDSIgnorePaths` beállításnál.

A korábban tárgyaltaktól függetlenül ez a rendszer alkalmas bonyolultabb frissítési folyamatok kisegítésére is.

[[updating-upgrading-portsnap]]
== A Portgyûjtemény frissítése a Portsnap használatával

A FreeBSD alaprendszer a Portgyûjtemény frissítéséhez is tartalmaz egy man:portsnap[8] elnevezésû segédprogramot. Ez a program elindítása után csatlakozik egy távoli géphez, ellenõrzi a biztonsági kulcsát és letölti a portok legfrissebb változatait. A biztonsági kulcs feladata a frissítés közben letöltött állományok sértetlenségének szavatolása, ezzel gondoskodik róla, hogy az adatok átvitelük közben nem változtak meg. A Portgyûjtemény legújabb változatát így érhetjük el:

[source,shell]
....
# portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... 3 mirrors found.
Fetching snapshot tag from portsnap1.FreeBSD.org... done.
Fetching snapshot metadata... done.
Updating from Wed Aug  6 18:00:22 EDT 2008 to Sat Aug 30 20:24:11 EDT 2008.
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.
....

A példában látható, hogy a man:portsnap[8] eltéréseket talált a helyi és a távoli rendszerekben fellelhetõ portok között, majd azokat ellenõrizte. Emellett az is megfigyelhetõ, hogy korábban már futtatuk a programot, mivel ha most indítottuk volna az elsõ alkalommal, akkor egyszerûen letöltötte volna a teljes Portgyûjteményt.

Ahogy a man:portsnap[8] sikeresen befejezi az imént kiadott `fetch` mûvelet végrehajtását, a helyi rendszeren már telepítésre készen fognak várakozni a Portgyûjtemény és az hozzá tartozó ellenõrzött módosítások. A `portsnap` elsõ használatakor az `extract` parancs segítségével telepíthetjük a frissített állományokat:

[source,shell]
....
# portsnap extract
/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
...
....

Egy korábban már telepített Portgyûjteményt a `portsnap update` paranccsal tudunk frissíteni:

[source,shell]
....
# portsnap update
....

Ezzel lezárult a portok frissítése, innentõl már az aktualizált Portgyûjtemény felhasználásával tetszõlegesen telepíthetõek vagy frissíthetõek az alkalmazások.

A `fetch`, `extract` vagy `update` mûveletek egyetlen parancsba is összefûzhetõek, ahogy ezt az alábbi példában is láthatjuk:

[source,shell]
....
# portsnap fetch update
....

Ez a parancs letölti a Portgyûjtemény legfrissebb változatát, majd kitömöríti azt a helyi [.filename]#/usr/ports# könyvtárba.

[[updating-upgrading-documentation]]
== A dokumentáció frissítése

Az alaprendszer és a Portgyûjtemény mellett a dokumentáció is a FreeBSD operációs rendszer szerves részét képezi. Noha a FreeBSD dokumentációjának legfrissebb változata folyamatosan elérhetõ a http://www.freebsd.org/doc[FreeBSD honlapjáról], egyes felhasználók ezt csak lassan vagy nem képesek folyamatosan elérni. Szerencsére egy helyi másolat megfelelõ karbantartásával az egyes kiadásokhoz tartozó dokumentáció is frissíthetõ.

[[csup-doc]]
=== A dokumentáció frissítése CVSup használatával

A FreeBSD telepített dokumentációjának forrásai az alaprendszeréhez hasonlóan (lásd <<makeworld>>) a CVSup segítségével frissíthetõek. Ebben a szakaszban megismerhetjük:

* hogyan telepítsük a dokumentáció elõállításához szükséges eszközöket, amelyekkel a forrásokból újra tudjuk generálni a FreeBSD dokumentációját;
* hogyan töltsük le a dokumentáció forrását CVSup segítségével a [.filename]#/usr/doc# könyvtárba;
* a dokumentáció elõállításához alkalmazott rendszer milyen beállításokkal rendelkezik, vagyis hogyan korlátozzuk a generálást bizonyos nyelvekre vagy formátumokra.

[[installing-documentation-toolchain]]
=== A CVSup és a dokumentációs eszközök telepítése

Viszonylag sokféle eszközre lesz szükségünk, ha a FreeBSD dokumentációját a forrásokból akarjuk elõállítani. Ezek az segédprogramok nem részei a FreeBSD alaprendszerének, mivel alapvetõen nagyon sok helyet foglalnak el, és leginkább olyan FreeBSD felhasználók számára fontosak, akik folyamatosan a dokumentációval dolgoznak vagy gyakran frissítik azt forrásból.

A feladathoz szükséges összes eszköz elérhetõ a Portgyûjteménybõl. Ebben a FreeBSD Dokumentációs Projekt összeállított egy package:textproc/docproj[] nevû portot, amellyel az említett programok telepítését és frissítését igyekezték megkönnyíteni.

[NOTE]
====
Ha nem tartunk igényt a dokumentáció PostScript(R) vagy PDF változatára, akkor ehelyett inkább érdemes megfontolnunk a package:textproc/docproj-nojadetex[] port telepítését. Ebben a változatban a teTeX betûszedõ rendszer kivételével az összes segédprogram megtalálható. Mivel a teTeX önmagában nagyon sok segédeszköz telepítését jelenti, ezért amennyiben a PDF változat ténylegesen nem szükséges, érdemes eltekinteni a telepítésétõl.
====

A CVSup telepítésével kapcsolatban pedig részletesebb információkat a crossref:mirrors[cvsup,CVSup használatával] foglalkozó szakaszban olvashatunk.

[[updating-documentation-sources]]
=== A dokumentáció forrásának frissítése

A [.filename]#/usr/shared/examples/cvsup/doc-supfile# konfigurációs állomány segítségével a CVSup képes letölteni a dokumentáció forrásállományainak legfrissebb példányait. Itt a frissítést alapértelmezés szerint egy nem létezõ géptõl fogjuk kérni (mivel ezt kötelezõ kitölteni), azonban a man:cvsup[1] programnak egy parancssori paraméter segítségével megadhatjuk melyik CVSup szerverrõl töltse le a forrásokat:

[source,shell]
....
# cvsup -h cvsup.FreeBSD.org -g -L 2 /usr/shared/examples/cvsup/doc-supfile
....

Ne felejtsük el a _cvsup.FreeBSD.org_ helyére beírni a hozzánk földrajzilag legközelebb elhelyezkedõ CVSup szervert. Ezek teljes listáját a crossref:mirrors[cvsup-mirrors,CVSup oldalak] tartalmazza.

Egy ideig eltarthat, amíg elõször letöltjük a forrásokat. Várjuk meg türelmesen, amíg befejezõdik a mûvelet.

Késõbb a forrásokat ugyanezzel a paranccsal tudjuk frissíteni. A CVSup ugyanis mindig csak a legutóbbi futtatása óta történt változásokat tölti le, ezért késõbb már ez a lépés jelentõsen felgyorsulhat.

A források letöltése után a dokumentációt például az ekkor keletkezett [.filename]#/usr/doc# könyvtárban található [.filename]#Makefile# használatával állíthatjuk elõ. Tehát miután az [.filename]#/etc/make.conf# állományban beállítottuk a `SUP_UPDATE`, `SUPHOST` és `DOCSUPFILE` változókat, le tudjuk futtatni a következõ parancsot:

[source,shell]
....
# cd /usr/doc
# make update
....

Az elõbb említett man:make[1] változók jellemzõ értékei:

[.programlisting]
....
SUP_UPDATE= yes
SUPHOST?= cvsup.freebsd.org
DOCSUPFILE?= /usr/shared/examples/cvsup/doc-supfile
....

[NOTE]
====
Mivel a `SUPHOST` és a `DOCSUPFILE` változók értékét a `?=` szimbólummal állítottuk be, lehetõségünk van a parancssorból ezeknek más értékeket adni. Az [.filename]#/etc/make.conf# állományba általában így érdemes felvenni a változókat, így nem kell minden alkalommal módosítani, amikor valamilyen új beállítást akarunk kipróbálni.
====

[[updating-documentation-options]]
=== A dokumentáció különbözõ beállításai

A FreeBSD dokumentációjához tartozó, frissítést és elõállítást végzõ rendszernek van néhány olyan beállítása, amelyekkel kérhetjük kizárólag csak a dokumentáció egyes részeinek frissítését vagy bizonyos kimeneti formátumok használatát. Ezek vagy globálisan az [.filename]#/etc/make.conf# állományban, vagy pedig a parancssorból, a man:make[1] program paramétereként adhatóak meg.

Ízelítõül néhány közülük:

`DOC_LANG`::
Az elõállítandó és telepítendõ nyelvû dokumentáció felsorolása, tehát például csak az angol dokumentáció esetén ez `en_US.ISO8859-1`.

`FORMATS`::
Az elõállítandó dokumentáció kimeneti formátumainak felsorolása. Itt pillanatnyilag értékként a `html`, `html-split`, `txt`, `ps`, `pdf` és `rtf` jelenhet meg.

`SUPHOST`::
A frissítéshez használt CVSup szerver hálózati neve.

`DOCDIR`::
Az elkészült dokumentáció telepítésének helye. Ez alapértelmezés szerint a [.filename]#/usr/shared/doc#.

A folyamathoz kapcsolódóan további rendszerszintû man:make[1] változókról a man:make.conf[5] man oldalon olvashatunk.

A FreeBSD dokumentációjának elõállításáért felelõs rendszerben használható man:make[1] további változók bemutatásával kapcsolatban pedig olvassuk el az extref:{fdp-primer}[A FreeBSD Dokumentációs Projekt irányelvei kezdõknek] címû könyvet.

[[updating-installed-documentation]]
=== A FreeBSD dokumentációjának telepítése forrásból

Miután sikerült letöltenünk a [.filename]#/usr/doc# könyvtárba a dokumentáció legfrissebb forrásait, készen állunk a rendszerünkön telepített példány frissítésére.

A `DOCLANG` értékeként megadott nyelven készült dokumentációkat a következõ paranccsal tudjuk frissíteni:

[source,shell]
....
# cd /usr/doc
# make install clean
....

Ha a [.filename]#make.conf# állományban korábban már megadtuk a `DOCSUPFILE`, `SUPHOST` és `SUP_UPDATE` változók értékeit, akkor a telepítés fázisa könnyedén össze is vonatható a források frissítésével:

[source,shell]
....
# cd /usr/doc
# make update install clean
....

Ha pedig csak bizonyos nyelvekhez tartozó dokumentációt szeretnénk frissíteni, akkor a man:make[1] akár a [.filename]#/usr/doc# könyvtáron belül az egyes nyelvekhez tartozó alkönyvtárakon belül is meghívható, például:

[source,shell]
....
# cd /usr/doc/en_US.ISO8859-1
# make update install clean
....

A dokumentáció formátumát a `FORMATS` változó felhasználásával tudjuk meghatározni:

[source,shell]
....
# cd /usr/doc
# make FORMATS='html html-split' install clean
....

[[doc-ports]]
=== A dokumentációs portok használata

Ez elõzõ szakaszban megmutattuk hogyan lehet a FreeBSD dokumentációját a források felhasználásával frissíteni. A források használatával végzett frissítés azonban nem minden FreeBSD rendszer esetében lehetséges vagy hatékony. Ha ugyanis a dokumentációs forrásból akarjuk elõállítani, viszonylag sok eszköz és segédprogram, az ún. _dokumentációs eszközök_ használatával kell tisztában lennünk, valamint bizonyos mértékig ismernünk kell a CVS használatát, tudunk kell kikérni a legfrissebb változatot és elõállítatattnunk belõle a végleges változatot. Ezért ebben a szakaszban most szót ejtünk egy olyan módszerrõl, ahol a FreeBSD dokumentációját a Portgyûjteményen keresztül tudjuk frissíteni, ezáltal:

* anélkül le tudjuk tölteni és telepíteni a dokumentáció adott pillanatban generált változatát, hogy a rendszerünkön bármi további teendõre szükség lenne (ennek köszönhetõen nem kell telepítenünk a dokumentációs eszközöket);
* letölthetjük a dokumentáció forrását és a Portgyûjtemény eszközeivel elõállíthatjuk belõle a megfelelõ változatot (ez a források beszerzésében és feldolgozásában segít valamelyest).

A FreeBSD dokumentáció frissítésének fentebb említett módjait támogatják tehát a _dokumentációs portok_, amelyeket a {doceng} havi rendszerességgel tart karban. Ezek a portok a FreeBSD Portgyûjteményén belül a http://www.freshports.org/docs/[docs] nevû virtuális kategóriában találhatóak meg.

[[doc-ports-install-make]]
==== A dokumentációs portok fordítása és telepítése

A dokumentáció könnyebb elõállításához a dokumentációs portok a Portgyûjtemény lehetõségeit veszik igénybe. Segítségükkel automatikussá teszik a dokumentáció forrásának letöltését, a man:make[1] parancs meghívását a megfelelõ környezetben, beállításokkal és parancssori paraméterekkel. Rajtuk keresztül a dokumentáció eltávolítása ugyanolyan egyszerûen megtehetõ, mint akármelyik másik FreeBSD port vagy csomag esetében.

[NOTE]
====
Továbbá, amikor a dokumentációs portokat a saját rendszerünkön fordítjuk, a _dokumentációs eszközök_ függõségként automatikusan települni fognak.
====

A dokumentációs portok a következõ módon szervezõdnek:

* Létezik egy ún. "fõport", a package:misc/freebsd-doc-en[], ahol az összes fontosabb állomány megtalálható. Ez lényegében a dokumentációs portok közös õse. Alapértelmezés szerint kizárólag csak az angol nyelvû dokumentációt állítja elõ.
* Létezik egy "mindenes port", a package:misc/freebsd-doc-all[], amely az összes elérhetõ nyelven és formátumban elõállítja a dokumentációt.
* Végezetül minden nyelvhez létezik egy-egy "alport", ilyen például a magyar dokumentáció esetén a package:misc/freebsd-doc-hu[] port. Mindegyikük a fõporttól függ és az adott nyelvû dokumentációt telepítik.

Az eddigi összefoglaltaknak megfelelõen a dokumentációs portokat forrásból a következõ paranccsal lehet telepíteni (`root` felhasználóként):

[source,shell]
....
# cd /usr/ports/misc/freebsd-doc-en
# make install clean
....

Ennek hatására elõáll és telepítõdik a [.filename]#/usr/local/shared/doc/freebsd# könyvtárba az angol nyelvû dokumentáció állományokra bontott HTML formátumban (hasonlóan a http://www.FreeBSD.org[http://www.FreeBSD.org] tartalmához).

[[doc-ports-options]]
===== Gyakori beállítások

A dokumentációs portok alapértelmezett viselkedése több különbözõ opció segítségével is befolyásolható. Ezek közül most összefoglalunk néhányat:

`WITH_HTML`::
Minden dokumentum egyetlen HTML állományba kerüljön. A végeredmény ekkor az adott dokumentum típusának megfelelõen [.filename]#article.html# (cikk) vagy [.filename]#book.html# (könyv) néven keletkezik (képekkel együtt).

`WITH_PDF`::
Minden dokumentum Adobe(R) Portable Document Format típusú állományban jön létre. Ezek az állományok a Ghostscript vagy más egyéb PDF nézegetõkkel nyithatóak meg. Ekkor a dokumentáció konkrét típusától függõen az állományok [.filename]#article.pdf# (cikk) vagy [.filename]#book.pdf# (könyv) néven állítódnak elõ.

`DOCBASE`::
A dokumentáció telepítésének helye. Alapértelmezés szerint ez a [.filename]#/usr/local/shared/doc/freebsd# könyvtár.
+
[NOTE]
====
Ügyeljünk arra, hogy a telepítés alapértelmezett célkönyvtára eltér a CVSup módszerétõl. Ugyanis mivel ilyenkor egy portot telepítünk, a tartalma alapértelmezés szerint a [.filename]#/usr/local# könyvtáron belülre kerül. Ez azonban a `PREFIX` változó átállításával tetszõleges megváltoztatható.
====

Az elõbbieket most egy rövid példán keresztül összefoglaljuk. A következõ paranccsal tudjuk tehát a magyar nyelvû dokumentáció Portable Document Format változatát telepíteni:

[source,shell]
....
# cd /usr/ports/misc/freebsd-doc-hu
# make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean
....

[[doc-ports-install-package]]
==== A dokumentációs csomagok használata

A dokumentációs portok elõzõ szakaszban bemutatott forrásból telepítésével kapcsolatban már említettük, hogy szükséges hozzá a dokumentációs eszközök telepítése, valamint némi szabad tárterület. Ha a dokumentációs eszközök telepítéséhez nem elengedõek a rendelkezésre álló erõforrásaink vagy a források feldolgozása túlságosan sokat foglalna a rendszerünkön, akkor lehetõségünk van a dokumentációs portok elõre lefordított, csomagolt változatát használni.

A {doceng} minden hónapban elõkészíti a FreeBSD dokumentációs csomagok legfrissebb változatát. Az így karbantartott bináris csomagok azután tetszõlegesen használhatóak a szabványos csomagkezelõ eszközökkel, mint amilyen például a man:pkg_add[1], man:pkg_delete[1] és így tovább.

[NOTE]
====
A bináris csomagok használata esetén a FreeBSD dokumentációja az adott nyelvhez az _összes_ elérhetõ formátumban telepítésre kerül.
====

Például az alábbi paranccsal a magyar nyelvû dokumentációhoz tartozó legfrissebb bináris csomagot tudjuk telepíteni:

[source,shell]
....
# pkg_add -r hu-freebsd-doc
....

[NOTE]
====
A csomagok elnevezése eltér a hozzá tartozó port nevétõl. Alakja a következõ: `nyelv-freebsd-doc`, ahol a _nyelv_ az adott nyelv rövid kódja, vagyis a magyar esetén a `hu`, illetve az egyszerûsített kínai esetén a `zh_ch`.
====

[[doc-ports-update]]
==== A dokumentációs portok frissítése

Az elõzetesen telepített dokumentációs portok bármilyen portok frissítésére alkalmas eszközzel frissíthetõek. Például a telepített magyar nyelvû dokumentáció a package:ports-mgmt/portupgrade[] eszközön keresztül így frissíthetõ csomagok használatával:

[source,shell]
....
# portupgrade -PP hu-freebsd-doc
....

[[current-stable]]
== A fejlesztõi ág követése

A FreeBSD-nek két fejlesztési ága van: a FreeBSD.current és a FreeBSD-STABLE. Ebben a szakaszban mindegyikükrõl monduk pár szót, és megmutatjuk, miként lehet az adott ághoz igazítani a rendszerünk frissítését. Elõször a FreeBSD-CURRENT, majd a FreeBSD-STABLE változata kerül tárgyalásra.

[[current]]
=== A FreeBSD friss változatának használata

Ahogy arról már az imént is szó esett, nem szabad elfelejtenünk, hogy a FreeBSD-CURRENT a FreeBSD fejlesztésének "frontvonala". Emiatt a FreeBSD-CURRENT használóinak szakmailag jólképzetteknek kell lenniük, és sosem szabad visszariadniuk a használat közben felmerülõ rendszerszintû problémák önálló megoldásától. Ha korábban még nem foglalkoztunk FreeBSD-vel, kétszer is gondoljuk meg a telepítését!

==== Mi a FreeBSD-CURRENT?

A FreeBSD-CURRENT a FreeBSD mögött álló legfrissebb forráskódot képviseli. Itt találkozhatunk különféle olyan fejlesztés alatt álló részekkel, kísérletezésekkel és átmeneti megoldásokkal, amelyek nem feltétlenül kerülnek bele a szoftver következõ hivatalos kiadásába. Noha a FreeBSD fejlesztõi a FreeBSD-CURRENT forráskódját naponta fordítják, adódhatnak olyan idõszakok, amikor a források mégsem használhatóak maradéktalanul. Az ilyen gondokat általában a lehetõ leggyorsabban igyekeznek megoldani, azonban attól függõen, hogy éppen a forráskód melyik verzióját sikerült kifogni, a FreeBSD-CURRENT használata kész katasztrófa vagy akár a fejlõdésben igazi továbblépés is lehet.

==== Kinek van szüksége a FreeBSD-CURRENT-re?

A FreeBSD-CURRENT használata elsõsorban az alábbi 3 csoportot érinti:

. A FreeBSD közösség azon tagjait, akik aktívan dolgoznak a forrásfa valamelyik részén, és mindazokat, akik számára a "legfrissebb" verzió használata feltétlen elvárás.
. A FreeBSD közösség azon tagjait, akik aktívan tesztelnek, és a FreeBSD-CURRENT kordában tartásához hajlandóak idõt áldozni a menet közben felbukkanó problémák megoldására. Vannak olyanok is, akik a FreeBSD változásaival és fejlesztési irányával kapcsolatban kívánnak javaslatokat tenni, melyeket javítások és módosítások formájában tesznek közzé.
. Mindazokat, akik pusztán kíváncsiak a fejlesztésben zajló eseményekre, vagy hivatkozási szándékkal töltik le a legfrissebb forrásokat (például csak _nézegetik_, de nem futtatják). Az ilyen emberek esetenként megjegyzéseket fûznek a fejlesztéshez vagy kódot küldenek be.

==== Mi _nem_ a FreeBSD-CURRENT?

. Az olyan kiadás elõtt álló funkciók kipróbálásának egyszerû módja, amelyekrõl hallottunk, hogy milyen remek újdonságokat hoznak és mi akarunk lenni az elsõk, akik ezt használni is fogják. Ne feledjük azonban, hogy amikor mindenki elõtt kezdünk el használni egy újítást, mi leszünk egyben az elsõk is, akik szembesülnek a benne rejlõ hibákkal.
. A gyors hibajavítások eszköze. A FreeBSD-CURRENT szinte bármelyik változata pontosan ugyanakkora valószínûséggel hoz magával új hibákat, mint ahogy eltünteti a régieket.
. Akármilyen értelemben is "hivatalosan támogatott". Képességeinktõl függõen õszintén igyekszünk a lehetõ legtöbbet megtenni a 3 "törvényes" FreeBSD-CURRENT csoportba tartozó emberekért, azonban egyszerûen _nincs idõnk_ komolyabb segítségnyújtást adni. Ez viszont nem azt jelenti, hogy komisz és fukar emberek vagyunk, akik utálnak segíteni a másiknak (de máskülönben nem tudna fejlõdni a FreeBSD). Csupán a FreeBSD fejlesztése _közben_ fizikailag képtelenek vagyunk a naponta érkezõ ezernyi üzenetet rendre megválaszolni! A FreeBSD elõremozdítása és a kísérleti stádiumban álló kóddal kapcsolatos kérdések megválaszolása közül a fejlesztõk általában az elsõt részesítik elõnyben.

==== A FreeBSD-CURRENT használata

. Iratkozzunk fel az {freebsd-current} és {svn-src-head} listákra. Ez nem egyszerûen hasznos, hanem _elengedhetetlen_. Ha nem vagyunk a _{freebsd-current}_ listán, akkor nem fogjuk látni a rendszer aktuális állapotára vonatkozó megjegyzéseket, és így esetleg feleslegesen öljük az idõnket olyan problémák megoldásába, amelyeket mások már korábban megoldottak. Ami viszont ennél is fontosabb, hogy így elszalasztjuk a rendszerünk folyamatos életbentartására vonatkozó létfontosságú bejelentéseket.
+ 
Az {svn-src-head} listán láthatjuk az a forráskód egyes változtatásaihoz tartozó naplóbejegyzéseket, a hozzájuk tartozó esetleges mellékhatások ismertetésével együtt.
+ 
A listákra vagy a {mailing-lists-url} oldalon található többi lista valamelyikére úgy tudunk feliratkozni, ha rákattintunk a nevére. A további lépésekrõl ezt követõen itt kapunk értesítést. Amennyiben a teljes forrásfa változásai érdekelnek minket, javasoljuk az {svn-src-all} lista olvasását.
. A crossref:mirrors[mirrors,tükrözések] egyikérõl töltsük le a FreeBSD forrását. Erre két mód is kínálkozik:
.. Használjuk a crossref:mirrors[cvsup,cvsup] programot a [.filename]#/usr/shared/examples/cvsup# könyvtárban található [.filename]#standard-supfile# állománnyal. Ez a leginkább ajánlott módszer, hiszen így csak egyszer kell letölteni az egész gyûjteményt, majd ezután már csak a változásokat. Sokan a `cvsup` parancsot a `cron` parancson keresztül adják ki, és ezzel mindig automatikusan frissítik a forrásaikat. A crossref:mirrors[cvsup,cvsup] mûködését a fentebb említett minta [.filename]#supfile# állomány megfelelõ módosításával tudjuk a saját környezetünkhöz igazítani.
+
[NOTE]
====
Az említett [.filename]#standard-supfile# állomány eredetileg nem a FreeBSD-CURRENT, hanem inkább a FreeBSD biztonsági problémáit érintõ javítások követésére használatos. A FreeBSD-CURRENT forrásainak eléréséhez a következõ sort kell kicserélnünk ebben az állományban:

[.programlisting]
....
*default release=cvs tag=RELENG_X_Y
....

Erre:

[.programlisting]
....
*default release=cvs tag=.
....

A `tag` paramétereként megadható egyéb címkékrõl a kézikönyv crossref:mirrors[cvs-tags,CVS címkék] szakaszában olvashatunk.
====

.. Használjuk a CTM alkalmazás nyújtotta lehetõségeket. Amennyiben nagyon rossz netkapcsolattal rendelkezünk (drága vagy csak levelezésre használható) a CTM megoldást jelenthet számunkra. Legyünk azonban tekintettel arra, hogy helyenként zûrös lehet a használata és néha hibás állományokat gyárt. Emiatt viszont csak ritkán használják, így elõfordulhat, hogy hosszabb ideig nem is mûködik. A 9600 bps vagy annál nagyobb sebességû kapcsolatok esetén ezért inkább a CVSup használatát javasoljuk.

. Ha nem csak böngészésre, hanem fordításra is szedjük a forrásokat, mindig töltsük le a FreeBSD-CURRENT _egészét_, ne csak egyes részeit. Ez azzal magyarázandó, hogy a forráskód bizonyos részei más helyeken található részektõl is függenek, és ezért az önálló fordításuk szinte garantáltan gondot fog okozni.
+ 
A FreeBSD-CURRENT lefordítása elõtt figyelmesen olvassuk át a [.filename]#/usr/src# könyvtárban található [.filename]#Makefile# állományt. A frissítési folyamat részeként elõször mindenképpen érdemes <<makeworld,telepíteni egy új rendszermagot és újrafordítani az alaprendszert>>. Olvassuk el a {freebsd-current} üzeneteit és a [.filename]#/usr/src/UPDATING# állományt, ahol megtalálhatjuk az ezzel kapcsolatos legújabb információkat, melyek egy-egy újabb kiadás közeledtével egyre fontosabbá válnak.
. Foglalkozzunk vele! Ha már a FreeBSD-CURRENT változatát használjuk, ne legyünk restek véleményt formálni róla, különösen abban az esetben, ha továbbfejlesztésekrõl vagy hibákra van szó. Leginkább a forráskóddal együtt érkezõ javaslatoknak szoktak örülni a fejlesztõk!

[[stable]]
=== A FreeBSD stabil változatának használata

==== Mi a FreeBSD-STABLE?

A FreeBSD-STABLE az a fejlesztési ág, ahonnan az egyes kiadások származnak. Ebbe az ágba már más ütemben kerülnek a változások, mivel általánosan elfogadott, hogy ide a korábban már kipróbált módosítások vándorolnak át a FreeBSD-CURRENT ágból. Ez azonban _még mindig_ csak egy fejlesztési ág, ami arra utal, hogy a FreeBSD-STABLE által adott pillanatban képviselt források nem feltétlenül felelnek meg bizonyos célokra. Ez csupán egy újabb fejlesztési nyomvonal, nem pedig a végfelhasználók kenyere.

==== Kinek van szüksége a FreeBSD-STABLE-re?

Ha szeretnénk figyelemmel kísérni vagy valamilyen módon kiegészíteni a FreeBSD fejlesztési folyamatát, különösen a FreeBSD következõ "nagyobb" kiadását illetõen, akkor érdemes követnünk a FreeBSD-STABLE forrásait.

Habár a FreeBSD-STABLE ágba is bekerülnek a biztonsági jellegû javítások, ettõl még nem kell feltétlenül ezt követnünk. A FreeBSD-hez kiadott biztonsági figyelmeztetések mindig leírják, hogyan kell javítani a hibát az érintett kiadásokban  , azonban az egész fejlesztési ágat felesleges csak biztonsági okból kifolyólag követni, mivel így olyan változások is kerülhetnek a rendszerbe, amire nincs szükségünk.

Habár igyekszünk gondoskodni a FreeBSD-STABLE ágban található források lefordíthatóságáról és mûködõképességérõl, nem minden esetben szavatolható. Ráadásul mivel a FreeBSD-STABLE ágba kerülõ kódokat elõször a FreeBSD-CURRENT ágban fejlesztik ki, és mivel a FreeBSD-STABLE felhasználói többen vannak a FreeBSD-CURRENT változaténál, ezért szinte elkerülhetetlen, hogy ilyenkor a FreeBSD-STABLE változatban bizonyos hibák és szélsõséges esetek be ne következzenek, amelyek a FreeBSD-CURRENT használata során még nem buktak ki.

Ezért a FreeBSD-STABLE ág vakon követését senkinek _sem_ ajánljuk, és különösen fontos, hogy éles szervereken elõzetes kimerítõ tesztelések nélkül ne futassunk FreeBSD-STABLE rendszert.

Ha ehhez nem rendelkezünk elegendõ erõforrással, akkor egyszerûen használjuk a FreeBSD legfrissebb kiadását, és az egyes kiadások között pedig bináris frissítéssel közlekedjünk.

==== A FreeBSD-STABLE használata

. Iratkozzunk fel a {freebsd-stable} listára. Ezen keresztül értesülhetünk a FreeBSD-STABLE használata során felmerülõ fordítási függõségekrõl vagy más, külön figyelmet igénylõ problémákról. Gyakran ezen a levelezési listán elmélkednek a fejlesztõk a vitatott javításokról vagy frissítésekrõl, amibe a felhasználók is beleszólhatnak, ha a szóbanforgó változtatással kapcsolatban bármilyen problémájuk vagy ötletünk van.
+ 
Iratkozzunk fel a követni kívánt ághoz tartozó SVN levelezési listára. Például ha a 7-STABLE ág változásait követjük, akkor az link:{svn-src-stable-7-url}[svn-src-stable-7] listára érdemes feliratkoznunk. Ennek segítségével elolvashatjuk az egyes változtatásokhoz tartozó naplóbejegyzéseket, a rájuk vonatkozó esetleges mellékhatások ismertetésével együtt.
+ 
Ezekre, valamint a {mailing-lists-url} címen elérhetõ listák valamelyikére úgy tudunk feliratkozni, ha a nevükre kattintunk. A további teendõk ezután itt jelennek meg.
. Amennyiben egy új rendszert akarunk telepíteni és a FreeBSD-STABLE havonta készült pillanatképeit akarjuk rajta futtatni, akkor errõl bõvebb felvilágosítást a link:https://www.FreeBSD.org/snapshots/[Pillanatképek] honlapján találhatunk (angolul). Emellett a legfrissebb FreeBSD-STABLE kiadást telepíthetjük a crossref:mirrors[mirrors,tükrözések] valamelyikérõl is, majd innen a lentebb található utasítások szerint tudunk hozzáférni a FreeBSD-STABLE forráskódjának legfrissebb változatához.
+ 
Ha már fut a gépünkön a FreeBSD egy korábbi kiadása, és ezt akarjuk forráson keresztül frissíteni, akkor ezt a FreeBSD crossref:mirrors[mirrors,tükrözéseivel] könnyedén megtehetjük. Két módon is:
.. Használjuk a crossref:mirrors[cvsup,cvsup] programot a [.filename]#/usr/shared/examples/cvsup# könyvtárból származó [.filename]#stable-supfile# állománnyal. Ez a leginkább ajánlott módszer, mivel így csak egyszer kell letölteni a teljes gyûjteményt, utána már csak a hozzá tartozó változtatásokra van szükségünk. A `cvsup` parancsot sokan a `cron` segítségével futtatják, és ezzel automatikusan frissülnek a forrásainak. A crossref:mirrors[cvsup,cvsup] mûködését környezetünkhöz az elõbb említett minta [.filename]#supfile# megfelelõ módosításával tudjuk behangolni.
.. Használjuk a CTM programot. Ha nincs olcsó vagy gyors internetkapcsolatunk, akkor érdemes ezt a módszert választani.

. Alapvetõen azonban ha gyorsan szeretnénk hozzájutni a forrásokhoz és a sávszélesség nem meghatározó tényezõ, akkor helyette válasszuk a `cvsup` vagy az `ftp` használatát, és csak minden más esetben CTM-et.
. Mielõtt lefordítanánk a FreeBSD-STABLE változatát, figyelmesen olvassuk át a [.filename]#/usr/src# könyvtárban levõ [.filename]#Makefile# állományt. Az átállási folyamat részeként elõször minden bizonnyal <<makeworld,telepítenünk kell egy új rendszermagot és újra kell fordítanunk az alaprendszert>>. A {freebsd-stable} valamint a [.filename]#/usr/src/UPDATING# elolvasásából értesülhetünk azokról az egyéb, gyakran nagyon fontos változásokról, melyek elengedhetetlenek lesznek a következõ kiadás használatához.

[[synching]]
== A forrás szinkronizálása

Az internet (vagy elektronikus levelek) használatán keresztül számos mód kínálkozik az FreeBSD Projekthez tartozó források frissen tartásához egy adott, vagy éppen az összes területen attól függõen, hogy mik érdekelnek minket. Ehhez elsõsorban az crossref:mirrors[anoncvs,Anonim CVS], crossref:mirrors[cvsup,CVSup] és crossref:mirrors[ctm,CTM] szolgáltatásokat ajánljuk fel.

[WARNING]
====

Habár lehetséges csupán a forrásfa egyes részeit letölteni, a támogatott frissítési eljárás során azonban szükségünk lesz az egész fa szinkronizálására és a rendszerhez tartozó felhasználói programok (vagyis minden olyan program, amely a felhasználói térben fut, ilyeneket találhatunk többek közt a [.filename]#/bin# és [.filename]#/sbin# könyvtárakban) valamint rendszermag újrafordítására is. Ha csak a felhasználói programok forrásait, vagy csak a rendszermagot, esetleg csupán a forrásfa egyes részeit frissítjük, akkor az gondokat okozhat. Az itt elõforduló problémák fordítási hibáktól kezdve rendszerösszeomlásokon keresztül akár adatvesztésbe is torkollhatnak.
====

Az Anonim CVS és a CVSup alkalmazások ún. _lehúzással_ frissítik a forrásokat. A CVSup használatakor a felhasználó (vagy a `cron` szkript) meghívja a `cvsup` programot, amely az állományok aktualizálásához felveszi a kapcsolatot egy máshol megtalálható `cvsupd` szerverrel. Az így nyert frissítések az adott pillanatig visszemenõleg érkeznek meg, de csak akkor, ha igényeljük ezeket. A frissítést könnyedén le tudjuk szabályozni a számunkra érdekes egyes állományokra és könyvtárakra. A frissítéseket a szerver hozza létre menet közben annak megfelelõen, hogy milyen verziókkal rendelkezünk, és mihez akarunk szinkronizálni. Az Anonim CVS a CVSupnál valamivel egyszerûbb abban a tekintetben, hogy ez a CVS-nek egy olyan kiterjesztése, amely lehetõvé teszi a változtatások közvetlen lehúzását egy távoli CVS tárházból. Miközben a CVSup mindezt sokkal hatékonnyabb valósítja meg, addig az Anonim CVS jóval könnyebben használható.

Velük szemben a CTM nem hasonlítja össze interaktívan a saját és a központi szerveren tárolt forrásokat és nem is húzza át ezeket. Ehelyett egy olyan szkriptõl van szó, amely naponta többször megvizsgálja a központi CTM szerveren tárolt állományok a legutóbbi futtatás óta keletkezett változtatásait, majd az észlelt módosulásokat betömöríti, felcímkézi egy sorozatszámmal és (nyomtatható ASCII formátumban) elõkészíti ezeket az e-mailen keresztüli küldésre. Az így létrehozott "CTM delták" megérkezésük után a man:ctm_rmail[1] segédprogrammal kerülnek feldolgozásra, amely magától visszaalakítja, ellenõrzi és alkalmazza a változtatásokat a forrásfa felhasználó birtokában levõ másolatára. Ez a megoldás hatékonyabb a CVSup használatánál, mert kisebb terhelést jelent a szerverek számára, hiszen a frissítéshez nem a _lehúzást_, hanem a _küldést_ alkalmazzák.

Természetesen minden említett eljárásnak megvannak a maga kompromisszumai. Ha véletlenül kitöröljük a forrásfánk egyes részeit, a CVSup képes ezt észrevenni és helyreállítani a sérült részeket. A CTM ezzel szemben ezt nem végzi el, szóval ha (biztonsági mentés nélkül) letöröljük a forrásainkat, akkor az egész szinkronizálást az elejérõl kell kezdenünk (pontosabban a legfrissebb CVS-es "alapdeltától") és a CTM-mel újraépíteni az egészet, esetleg a Anonim CVS-sel letörölni a hibás adatokat és újraszinkronizálni.

[[makeworld]]
== Az alaprendszer újrafordítása

Miután sikerült a helyi forrásfánkat a FreeBSD egy nekünk szimpatikus (FreeBSD-STABLE, FreeBSD-CURRENT és így tovább) változatához igazítanunk, elérkezett az idõ, hogy a segítségével újrafordítsuk az egész rendszert.

[WARNING]
.Készítsünk biztonsági mentést
====
Nem tudjuk eléggé nyomatékosítani, hogy _mielõtt_ nekikezdenénk, készítsünk egy biztonsági mentést a rendszerünkrõl. Míg az alaprendszer újrafordítása nem túlságosan bonyolult feladat (egészen addig, amíg a megadott utasításokat követjük), saját magunk vagy mások hibájából fakadóan kialakulhatnak olyan helyzetek, amikor a rendszer nem lesz képes elindulni.

Mindenképpen gyõzödjünk meg róla, hogy tisztességesen elvégeztük a mentést és akad a kezünk ügyében egy javításra felhasználható rendszerindító floppy vagy CD. Valószínûleg soha nem lesz ténylegesen szükségünk rájuk, azonban jobb félni, mint megijedni!
====

[WARNING]
.Iratkozzunk fel a megfelelõ levelezési listákra
====
A FreeBSD-STABLE és FreeBSD-CURRENT ágak természetüknél fogva _fejlesztés alatt állnak_. A FreeBSD fejlesztését is emberek végzik, ezért elõfordulhatnak benne tévedések.

Ezek a tévedések gyakran csak ártalmatlan apróságok, amelyek hatására kapunk például egy ismeretlen diagnosztikai hibát. De ezzel szemben létrejöhetnek pusztító erejû hibák is, amelyek hatására a rendszerünk nem lesz képes elindulni, károsodnak az állományrendszerek (vagy még rosszabb).

Ha ilyen történik, akkor egy "felszólítást" (egy "heads up" témájú üzenetet) küldenek az érintett változatokhoz tartozó listákra, amelyben igyekeznek kifejteni a probléma természetét és a rendszerre mért hatását. Miután "minden rendbejött", a probléma megoldásáról is küldenek egy értesítést.

Ha a {freebsd-stable} vagy a {freebsd-current} olvasása nélkül próbáljuk meg használni a FreeBSD-STABLE és FreeBSD-CURRENT verziókat, akkor csak magunknak keressük a bajt.
====

[WARNING]
.Ne használjuk a `make world` parancsot
====
Rengeteg régebben készült dokumentáció erre a feladatra a `make world` parancs kiadását javasolja. Ennek használatával azonban átlépünk olyan fontos lépéseket, amelyek valójában csak akkor lennének kihagyhatóak, ha pontosan tudjuk mit csinálunk. Ezért az esetek döntõ többségében nem a `make world` használatára van szükségünk, hanem a most bemutatandó eljárásra.
====

[[canonical-build]]
=== A rendszer frissítése dióhéjban

A frissítés megkezdése elõtt érdemes elolvasnunk a [.filename]#/usr/src/UPDATING# állományt, ahol a letöltött források használatához elvégzendõ elõzetes intézkedésekrõl kaphatunk hírt. Ezután kövessük az alábbiakban körvonalazott módszer egyes lépéseit.

Ezek a lépések feltételezik, hogy egy korábbi FreeBSD verziót használunk, tehát a fordító, a rendszermag, az alaprendszer és a konfigurációs állományok valamelyik régebbi változatát. Alaprendszer alatt, amelyet sokszor csak a "world" néven hivatkozunk, a rendszer számára alapvetõ fontosságú binárisokat, programkönyvtárakat és programfejlesztéshez szükséges egyéb állományokat értjük. Maga a fordítóprogram is része ennek, azonban tartalmaz néhány speciális megszorítást.

Mindezek mellett továbbá feltételezzük, hogy elõzetesen már valamilyen módon letöltöttük a friss forrásokat. Ha rendszerünkön ezt még nem tettük volna meg, akkor a <<synching>> segítségével tájékozódhatunk részletesen arról, hogyan tölthetjük le a legfrissebb verziót.

A rendszer forráskódon keresztüli frissítése egy kicsivel körülményesebb, mint amennyire elsõre látszik. A FreeBSD fejlesztõk az évek során fontosnak találták, hogy a folyamatosan felszínre bukkanó, elkerülhetetlen függõségek tükrében meglehetõsen drámai módon megváltoztassák az erre javasolt módszert. Ezért a szakasz további részében a pillanatnyilag javasolt frissítési megoldás nyomán fogunk haladni.

A sikeres frissítések során az alábbi akadályokkal kell mindenképpen szembenéznünk:

* A fordító régebbi változata nem feltétlenül lesz képes lefordítani az új rendszermagot. (Illetve a régebbi fordítóprogramok tartalmazhatnak hibákat.) Ezért az új rendszermagot már a fordító új változatával kell elõállítanunk. Ebbõl következik, hogy az új rendszermag elkészítéséhez elõször a fordítóprogram újabb változatát kell lefordítanunk. Ez viszont nem feltétlenül jelenti azt, hogy az új rendszermag fordítása elõtt az új fordítóprogramot _telepítenünk_ is kellene.
* Az új alaprendszer esetenként bizonyos új funkciókat igényelhet a rendszermagtól. Ezért a frissebb alaprendszer telepítése elõtt telepítenünk kell a frissebb rendszermagot.
* Ez az elõbb említett két akadály képzi az okát a következõ bekezdésekben bemutatott `buildworld`, `buildkernel`, `installkernel`, `installworld` sorozatnak. Természetesen léteznek további egyéb indokok is, amiért még érdemes az itt leírtak szerint frissíteni a rendszerünket. Ezek közül most vegyünk néhány kevésbé nyilvánvalóbbat:

** A régebbi alaprendszer nem minden esetben fog problémamentesen együttmûködni az új rendszermaggal, ezért az alaprendszer újabb változatát szinte azonnal az új rendszermagot követõen kell telepítenünk.
** Vannak olyan konfigurációs változtatások, amelyeket még az új alaprendszer telepítése elõtt el kell végeznünk, a többi viszont veszélyes lehet a korábbi alaprendszerre. Ezért a konfigurációs állományokat általában két külön lépésben kell frissíteni.
** A frissítés során nagyrészt csak állományok cserélõdnek el és újabbak érkeznek, a korábbiak nem törlõdnek. Ez bizonyos esetekben azonban gondokat okozhat. Ennek eredményeképpen a frissítés során idõnként elõfordulhat, hogy magunknak kell manuálisan némely megadott állományokat törölnünk. Elképzelhetõ, hogy ezt a jövõben még majd automatizálni fogják.

+ 
Ezek a megfontolások vezettek tehát az ismertetendõ eljárás kialakításához. Ettõl függetlenül adódhatnak olyan helyzetek, amikor további lépéseket is be kell iktatnunk, viszont az itt bemutatott folyamat egy ideje már viszonylag elfogadottnak tekinthetõ:
.. `make buildworld`
+ 
Elõször lefordítja az új fordítóprogramot és néhány hozzá tartozó eszközt, majd ennek felhasználásával elkészíti az alaprendszer többi részét. Az eredmény a [.filename]#/usr/obj# könyvtárban keletkezik.
.. `make buildkernel`
+ 
Eltérõen a man:config[8] és man:make[1] programok korábban javasolt alkalmazásától, ezzel a paranccsal már a [.filename]#/usr/obj# könyvtárban létrehozott _új_ fordítót használjuk. Ez védelmet nyújt a fordító és rendszermag változatai közti eltérésekbõl fakadó problémák ellen.
.. `make installkernel`
+ 
Telepíti a lemezre az új rendszermagot és a hozzá tartozó modulokat, ezáltal lehetõvé válik a frissített rendszermag betöltése.
.. Átváltás egyfelhasználós módba.
+ 
Egyfelhasználós módban a minimálisra csökkenthetjük a futó szoftverek frissítésébõl adódó bonyodalmakat. Ezzel együtt minimálissá válik a régi alaprendszer és az új rendszermag eltéréseibõl eredõ problémák elõfordulása is.
.. `mergemaster -p`
+ 
Az új alaprendszer telepítéséhez elvégzi a konfigurációs állományok részérõl szükséges frissítéseket. Például felvesz még nem létezõ csoportokat vagy felhasználókat. Ez gyakran elengedhetetlennek bizonyulhat, mivel ha a rendszer legutóbbi frissítése óta újabb csoportok vagy felhasználók kerültek be az alaprendszerbe, a `installworld` csak akkor tud hibamentesen lefutni, ha ezek már a futásakor is elérhetõek.
.. `make installworld`
+ 
Átmásolja a [.filename]#/usr/obj# könyvtárból a korábban elkészített új alaprendszert. Lefutása után már mind az új rendszermag és az új alaprendszer a megfelelõ helyén található.
.. `mergemaster`
+ 
Feldolgozzuk a korábbi fázisból fennmaradó konfigurációs állományok frissítését, mivel most már elérhetõ az új alaprendszer.
.. A rendszer újraindítása.
+ 
Az új rendszermag és az új konfigurációs állományokkal futó alaprendszer használatához teljesen újra kell indítanunk a számítógépünket.
+ 
Ha a FreeBSD ugyanazon fejlesztési ágán belül frissítjük a rendszerünket, például a 7.0 kiadásról a 7.1 kiadásra, akkor értelemszerûen nem kell az iménti eljárás minden lépését szorosan követni, hiszen nagyon valószínûtlen, hogy komoly eltérések lennének a fordítóprogram, a rendszermag, az alaprendszer és a konfigurációs állományok között. Ilyenkor akár nyugodtan kiadhatjuk a `make world` parancsot, majd kérhetjük a rendszermag fordítását és telepítését.
+ 
A fejlesztési ágak közti váltás során azonban könnyen érhetnek minket meglepetések, ha nem a megadottak szerint járunk el.
+ 
Egyes váltásokhoz (például 4._X_ és 5.0 között) további lépések megtétele is szükséges lehet (például adott állományok törlése vagy átnevezése még az `installworld` elõtt). Ilyenkor mindig figyelmesen olvassuk át a [.filename]#/usr/src/UPDATING# állományt, különös tekintettel a végére, mivel gyakran ott adják meg a konkrét verzióváltáshoz szükséges teendõket.
+ 
A szakaszban összefoglalt lépések egyfajta evolúciós folyamat eredményei, melynek során a fejlesztõk felismerték, hogy nem tökéletesen kivédeni az összes frissítéssel járó problémát. A javasolt eljárás remélhetõleg viszont még sokáig érvényes marad.
+
[NOTE]
====
A FreeBSD 3._X_ vagy annál is korábbi változatok frissítése még ennél is több ügyességet kíván. Ha ilyen verziót akarunk frissíteni, akkor feltétlenül olvassuk el az [.filename]#UPDATING# állományt!
====
+ 
Röviden tehát a FreeBSD forráskódon keresztüli frissítését így foglalhatjuk össze:

[source,shell]
....
# cd /usr/src
# make buildworld
# make buildkernel
# make installkernel
# shutdown -r now
....

[NOTE]
====
Néhány ritka esetben a `buildworld` lépés elõtt szükségünk lehet a `mergemaster -p` parancs lefuttatására is. Errõl az [.filename]#UPDATING# állományból tudakozódhatunk. Általában azonban nyugodt szívvel kihagyhatjuk ezt a lépést, kivéve, ha nem egy vagy több fõbb FreeBSD változatot átívelõ frissítést végzünk.
====

Miután az `installkernel` sikeresen befejezte a munkáját, indítsuk újra a számítógépet egyfelhasználós módban (a betöltõ parancssorában adjuk ki `boot -s` parancsot). Itt futtassuk a következõket:

[source,shell]
....
# adjkerntz -i
# mount -a -t ufs
# mergemaster -p
# cd /usr/src
# make installworld
# mergemaster
# reboot
....

[WARNING]
.Olvassuk el a magyarázatokat
====
Az iménti leírt folyamat csupán rövid összefoglalás, amivel némi gyorstalpalást igyekeztünk adni. Az egyes lépések megértéséhez azonban javasolt átolvasni a most következõ szakaszokat is, különösen abban az esetben, ha saját rendszermagot akarunk használni.
====

[[src-updating]]
=== Nézzük meg a [.filename]#/usr/src/UPDATING# állományt

Mielõtt bármihez is nekifognánk, keressük meg a [.filename]#/usr/src/UPDATING# (vagy hasonló, a forráskód másolatunk tényleges helyétõl függõ) állományt. Ebben adják hírül az esetlegesen felmerülõ problémákra vonatkozó fontosabb információkat, vagy határozzák meg az egyes lefuttatandó parancsok pontos sorrendjét. Amennyiben az [.filename]#UPDATING# ellentmondana az itt olvasottaknak, az [.filename]#UPDATING# tartalma a mérvadó.

[IMPORTANT]
====
A korábban tárgyaltak szerint az [.filename]#UPDATING# elolvasása nem helyettesíti a megfelelõ levelezési listák figyelemmel kísérését. Ez a két elvárás nem kizárja, hanem kiegészíti egymást.
====

[[make-conf]]
=== Ellenõrizzük az [.filename]#/etc/make.conf# állományt

Vizsgáljuk át a [.filename]#/usr/shared/examples/etc/make.conf# és az [.filename]#/etc/make.conf# állományokat. Az elõbbi tartalmaz néhány alapértelmezett beállítást - ezek javarészét megjegyzésbe rakták. Ha használni akarjuk a rendszer lefordítása során, tegyük bele ezeket az [.filename]#/etc/make.conf# állományba. Ne felejtsük el azonban, hogy minden, amit megadunk az [.filename]#/etc/make.conf# állományba, a `make` minden egyes elindításakor felhasználásra kerül. Éppen ezért olyanokat érdemes itt beállítani, amik az egész rendszerünket érintik.

A legtöbb felhasználó számára az [.filename]#/etc/make.conf# állományhoz a [.filename]#/usr/shared/examples/etc/make.conf# állományban található `CFLAGS` és `NO_PROFILE` sorokra lesz szüksége, melyeket kivehetünk a megjegyzésbõl.

A többi definíció (`COPTFLAGS`, `NOPORTDOCS` és így tovább) használatáról már mindenki maga dönt.

[[updating-etc]]
=== Frissítsük az [.filename]#/etc# tartalmát

Az [.filename]#/etc# könyvtár tartalmazza a rendszer beállításaival kapcsolatos információk jelentõs részét, valamint a rendszer indítása során lefutó szkripteket. Egyes szkriptek a FreeBSD verzióiról verzióira változnak.

Némely konfigurációs állományok a rendszer hétköznapi mûködésében is szerepet játszanak. Ilyen például az [.filename]#/etc/group#.

Alkalmanként a `make installworld` parancs futása során igényt tart adott nevû felhasználókra és csoportokra. A frissítéskor azonban ezek a felhasználók vagy csoportok nem feltétlenül állnak rendelkezésre, ami gondokat okozhat. Ezért bizonyos esetekben a `make buildworld` elõzetesen ellenõrzi az igényelt felhasználók és csoportok meglétét.

Erre például szolgálhat a `smmsp` felhasználó esete. Nélküle a felhasználók nem tudták telepíteni az új rendszert, mert hiányában az man:mtree[8] nem volt képes létrehozni a [.filename]#/var/spool/clientmqueue# könyvtárat.

Ezt úgy lehetett megoldani, hogy még az alaprendszer lefordítása (a `buildworld`) elõtt meg kellett hívni a man:mergemaster[8] parancsot a `-p` paraméterrel. Így csak azokat az állományokat fogja összehasonlítani, amelyek feltétlenül szükségesek a `buildworld` vagy az `installworld` sikeres mûködéséhez. Amennyiben a `mergemaster` egy olyan verziójával rendelkezünk, amely nem ismeri a `-p` paramétert, akkor az elsõ indításakor használjuk a forrásfában található újabb verzióját:

[source,shell]
....
# cd /usr/src/usr.sbin/mergemaster
# ./mergemaster.sh -p
....

[TIP]
====

Ha különösen paranoiásak vagyunk, akkor a csoport törlése vagy átnevezése elõtt az alábbi paranccsal ellenõrizni tudjuk az általa birtokolt állományokat:

[source,shell]
....
# find / -group GID -print
....

Ez megmutatja _GID_ (mely megadható numerikus vagy név formájában is) jelzésû csoporthoz tartozó összes állományt a rendszerünkben.
====

[[makeworld-singleuser]]
=== Váltsunk egyfelhasználós módba

A rendszert egyfelhasználós módban érdemes lefordítani. A nyilvánvalóan érezhetõ gyorsaság elõnyei mellett azért is jobban járunk, mert az új rendszer telepítése során számos rendszerszintû állomány is módosításra kerül, beleértve a szabványos rendszerszintû binárisokat, függvénykönyvtárakat, include állományokat és így tovább. Ha üzemelõ rendszeren végezzük el mindezen változtatásokat (különösen amikor rajtunk kívül még további felhasználók is tartózkodnak a rendszerben), az csak a bajt hozza ránk.

Másik lehetõség gyanánt a rendszert magát lefordíthatjuk többfelhasználós módban is, majd ezután csak a telepítést hajtjuk végre egyfelhasználós üzemmódban. Ha eszerint cselekszünk, egyszerûen várjunk addig, amíg az összes fordítás be nem fejezõdik, és az egyfelhasználósra váltást halasszuk a `installkernel` vagy `installworld` idejére.

Egy mûködõ rendszerben rendszeradminisztrátorként az alábbi parancs kiadásával válthatunk át egyfelhasználós módba:

[source,shell]
....
# shutdown now
....

Ezt elérhetjük úgy is, ha újraindítjuk a rendszert és a rendszer indításakor a "single user" pontot választjuk a menübõl. Ekkor a rendszer egyfelhasználós módban indul el. Miután ez megtörtént, adjuk ki a következõ parancsokat:

[source,shell]
....
# fsck -p
# mount -u /
# mount -a -t ufs
# swapon -a
....

Ezekkel a parancsokkal elõször ellenõrizzük az állományrendszereket, ezután újracsatlakoztatjuk a [.filename]#/# állományrendszert írható módban, csatlakoztatjuk az [.filename]#/etc/fstab# állományban megadott összes többi UFS típusú állományrendszert, majd bekapcsoljuk a lapozóállomány használatát.

[NOTE]
====
Ha a gépünk óráját nem a greenwich-i, hanem a helyi idõ szerint állítottuk be (ez akkor áll fenn, ha a man:date[1] parancs nem a helyes idõt és idõzónát jelzi ki), akkor még erre is szükségünk lehet:

[source,shell]
....
# adjkerntz -i
....

Ezzel a helyi idõzóna beállításait tudjuk jól beállítani - nélküle késõbb még gondjaink akadhatnak.
====

[[cleaning-usr-obj]]
=== Töröljük a [.filename]#/usr/obj# könyvtárat

A rendszer egyes részei fordításuk során a [.filename]#/usr/obj# könyvtáron belülre kerülnek (alapértelmezés szerint). Az itt található könyvtárak a [.filename]#/usr/src# könyvtárszerkezetét követik.

Ha mindenestõl töröljük ezt a könyvtárat, akkor növeli tudjuk a `make buildworld` folyamat sebességét és megmenekülünk néhány függõségekkel kapcsolatos fejfájástól is.

Egyes [.filename]#/usr/obj# könyvtáron belüli állományoknál szerepelhet a "megváltoztathatatlan" (immutable) állományjelzõ (lásd man:chflags[1]), amelyet a mûvelet elvégzéséhez elõször el kell távolítanunk.

[source,shell]
....
# cd /usr/obj
# chflags -R noschg *
# rm -rf *
....

[[updating-upgrading-compilebase]]
=== Fordítsuk újra az alaprendszert

==== A kimenet elmentése

Jól járunk azzal, ha a man:make[1] futásának kimenetét elmentjük egy állományba, mivel így a hibák esetén lesz egy másolatunk a hibaüzenetrõl. Ha konkrétan nekünk nem is feltétlenül segít megtalálni a hiba tényleges okát, mások viszont többet tudnak róla mondani, ha beküldjük ezt a FreeBSD egyik levelezési listájára.

Ezt egyébként a legegyszerûbben a man:script[1] parancs segítségével oldhatjuk meg, amelynek paraméteréül azt az állományt kell megadni, ahova menteni akarjuk a kimenetet. Ezt közvetlenül a rendszer újrafordítása elõtt kell kiadnunk, majd miután megállt, a `exit` paranccsal kiléphetünk belõle.

[source,shell]
....
# script /var/tmp/mw.out
Script started, output file is /var/tmp/mw.out
# make TARGET
... fordít, fordít, fordít ...
# exit
Script done, ...
....

Ilyenkor _soha ne_ a [.filename]#/tmp# könyvtárba mentsük a kimenetet, mert ennek a tartalma a következõ indítás során magától törlõdik. Sokkal jobban tesszük, ha a [.filename]#/var/tmp# könyvtárba (ahogy tettük azt az elõbbi példában is) vagy a `root` felhasználó könyvtárába mentünk.

[[make-buildworld]]
==== Az alaprendszer fordítása

A [.filename]#/usr/src# könyvtárban kell állnunk:

[source,shell]
....
# cd /usr/src
....

(kivéve természetesen, ha máshol van a forráskód, akkor abba a könyvtárba menjünk).

Az alaprendszert a man:make[1] paranccsal fordíthatjuk újra. Ez a [.filename]#Makefile# nevû állományból olvassa be a FreeBSD programjainak újrafordítását leíró utasításokat, a fordításuk sorrendjét és így tovább.

A begépelendõ paranccsor általános alakja tehát a következõképpen néz ki:

[source,shell]
....
# make -x -DVÁLTOZÓ target
....

A fenti példában a `-_x_` egy olyan a paraméter, amelyet a man:make[1] programnak adunk át. A man:make[1] man oldalán megtalálhatjuk az összes neki átadható ilyen beállítást.

A `-D_VÁLTOZÓ_` alakú paraméterek közvetlenül a [.filename]#Makefile# állománynak adnak át olyan változókat, amelyek segítségével vezérelhetõ a viselkedése. Ezek ugyanazok a változók, mint amelyek az [.filename]#/etc/make.conf# állományban is szerepelnek, és itt a beállításuk egy másik módját kapjuk. Így a

[source,shell]
....
# make -DNO_PROFILE target
....

paranccsal is megadhatjuk, hogy ne profilozott függkönyvtárak jöjjenek létre, ami pontosan megfelel a

[.programlisting]
....
NO_PROFILE=    true 	#    Avoid compiling profiled libraries
....

sornak az [.filename]#/etc/make.conf# állományban.

A _target_ árulja el a man:make[1] programnak, hogy mi a teendõje. Minden egyes [.filename]#Makefile# különbözõ "targeteket" definiál, és a kiválasztott target mondja meg, pontosan mi is fog történni.

Egyes targetek ugyan megjelennek a [.filename]#Makefile# állományban, azonban nem feltétlenül hivatkozhatunk rájuk közvetlenül. Ehelyett csupán arra valók, hogy a fordítás folyamatának lépéseit felbontsák még kisebb allépésekre.

A legtöbb esetben azonban semmilyen paramétert nem kell átadnunk a man:make[1] parancsnak, ezért a teljes formája így fog kinézni:

[source,shell]
....
# make target
....

ahol a _target_ az egyik fordítási lehetõséget képviseli. Az elsõ ilyen targetnek mindig a `buildworld`-nek kell lennie.

Ahogy a neve is mutatja, a `buildworld` lefordítja az összes forrást a [.filename]#/usr/obj# könyvtárba, majd a `installworld` mint másik target, telepíti az így létrehozott elemeket a számítógépre.

A targetek szétválasztása két okból is elõnyös. Elõször is lehetõvé teszi, hogy az új rendszert biztonságban lefordíthassuk, miközben az a jelenleg futó rendszert nem zavarja. A rendszer tehát képes "saját magát újrafordítani". Emiatt a `buildworld` target akár többfelhasználós módban is mindenféle nem kívánatos hatás nélkül használható. Ennek ellenére azonban továbbra is azt javasoljuk, hogy a `installworld` részt egyfelhasználós módban futtassuk le.

Másodrészt ezzel lehetõségünk nyílik NFS állományrendszer alkalmazásával több számítógépre is telepíteni hálózaton keresztül. Ha például három frissítendõ számítógépünk van, az `A`, `B` és `C`, akkor az `A` gépen elõször adjuk ki a `make buildworld`, majd a `make installworld` parancsot. A `B` és `C` gépek ezután NFS segítségével csatlakoztatják az `A`[.filename]#/usr/src# és [.filename]#/usr/obj# könyvtárait, amelyet követõen a `make installworld` paranccsal telepíteni tudjuk a fordítás eredményét a `B` és `C` gépekre.

Noha a `world` mint target még mindig létezik, használata határozottan ellenjavalt.

A

[source,shell]
....
# make buildworld
....

parancs kiadásakor a `make` parancsnak megadható egy `-j` paraméter is, amellyel párhuzamosíthatjuk a folyamat egyes részeit. Ez általában többprocesszoros számítógépeken nyer értelmet, azonban mivel a fordítás folyamatának haladását inkább az állománymûveletek mintsem a processzor sebessége korlátozza, ezért alkalmazható akár egyprocesszoros gépeken is.

Tehát egy átlagos egyprocesszoros gépen így adható ki a parancs:

[source,shell]
....
# make -j4 buildworld
....

Ennek hatására man:make[1] egyszerre 4 szálon igyekszik mûködni. A levelezési listákra beküldött tapasztalati jellegû bizonyítékok azt igazolják, hogy általában ez a beállítás adja a legjobb teljesítményt.

Ha többprocesszoros géppel rendelkezünk és rajta SMP támogatású rendszermagot indítottunk el, akkor érdemes 6 és 10 közötti értékekkel kísérleteznünk.

==== Idõigény

Számos tényezõ befolyásolja a fordítás tényleges idõbeli hosszát, de a FreeBSD-STABLE fa lefordítása mindenféle trükkök és rövidítések nélkül a legtöbb számítógépen olyan egy vagy két órára taksálható. A FreeBSD-CURRENT fához ennél valamivel több idõre lesz szükségünk.

[[new-kernel]]
=== Fordítsunk és telepítsünk egy új rendszermagot

Az újdonsült rendszerünket csak akkor tudjuk igazán kihasználni, ha egy új rendszermagot is készítünk hozzá. Ez gyakorlati szinten tulajdonképpen elvárás, mivel könnyen elõfordulhat, hogy bizonyos memóriabeli adatszerkezetek felépítése megváltozott, ezért némely programok, mint például a man:ps[1] és man:top[1], egészen addig nem lesznek képesek normálisan mûködni, amíg a rendszer és a rendszermag forráskódja nem illeszkedik egymáshoz.

Ennek legegyszerûbb és egyben legbiztonságosabb módja, ha a [.filename]#GENERIC# beállításai alapján gyártunk és telepítünk egy rendszermagot. Még ha a [.filename]#GENERIC# beállításai nem is tartalmazzák a rendszerünkben fellelhetõ összes eszközt, minden megtalálható bennük ahhoz, hogy a rendszert sikeresen elindíthassuk legalább egyfelhasználós módban. Ez mellesleg remek próbája az új rendszer életképességének. Miután elindítottuk a rendszert a [.filename]#GENERIC# típusú rendszermaggal és meggyõzõdtünk róla, hogy a rendszer tényleg mûködõképes, a megszokott rendszermagunk konfigurációs állománya alapján nyugodtan elkészíthetjük ezután azt is.

FreeBSD alatt egy új rendszermag építése elõtt fontos <<make-buildworld,újrafordítani az alaprendszert>>.

[NOTE]
====
Ha saját beállításaink szerint akarunk rendszermagot létrehozni és már van is ehhez egy konfigurációs állományunk, akkor erre használhatjuk a `KERNCONF=SAJÁTMAG` paramétert is, valahogy így:

[source,shell]
....
# cd /usr/src
# make buildkernel KERNCONF=SAJÁTMAG
# make installkernel KERNCONF=SAJÁTMAG
....

====

Hozzátennénk, hogy ha a `kern.securelevel` rendszerváltozó értékét 1 felé állítottuk _és_ a rendszermag állományának beállítottunk `noschg` vagy hozzá hasonló állományjelzõt, akkor az `installkernel` lefuttatásához mindenképpen egyfelhasználós módba kell váltanunk. Minden más esetben további bonyodalmak nélkül ki tudjuk adni az említett parancsokat. A `kern.securelevel` részleteirõl az man:init[8] oldalán, a különbözõ állományjelzõkrõl pedig a man:chflags[1] oldalán olvashatunk.

[[new-kernel-singleuser]]
=== Indítsuk újra a rendszert egyfelhasználós módban

Az új rendszermag mûködésének leteszteléséhez indítsuk újra a rendszert egyfelhasználós módban. Ennek pontos részleteit lásd <<makeworld-singleuser>>.

[[make-installworld]]
=== Telepítsük az új rendszer binárisait

Ha a FreeBSD friss változatát nemrég fordítottuk le a `make buildworld` paranccsal, akkor utána az `installworld` segítségével tudjuk telepíteni a keletkezett programokat.

Tehát írjuk be ezeket:

[source,shell]
....
# cd /usr/src
# make installworld
....

[NOTE]
====
Amennyiben a paranccsorban a `make buildworld` használata során adtunk meg változókat, akkor ne felejtsük el ugyanazokat megadni a `make installworld` kiadása során sem. Ez viszont a többi paraméterre már nem feltétlenül érvényes. Például a `-j` beállítást szigorúan tilos az `installworld` targettel együtt használni.

Ennek megfelelõen tehát ha korábban ezt írtuk be:

[source,shell]
....
# make -DNO_PROFILE buildworld
....

akkor így telepítsünk:

[source,shell]
....
# make -DNO_PROFILE installworld
....

Máskülönben azokat a profilozott függvénykönyvtárakat próbáljuk meg telepíteni, amelyek a `make buildworld` futása során nem jöttek létre.
====

[[post-installworld-updates]]
=== Frissítsük a `make installworld` által kihagyott állományokat

Az alaprendszer újrafordítása nem regisztrálja az új vagy megváltozott állományokat bizonyos könyvtárakban (különösen értendõ ez az [.filename]#/etc#, [.filename]#/var# és [.filename]#/usr# esetén).

Az ilyen állományokat a legegyszerûbben a man:mergemaster[8] használatával tarthatjuk karban, de igény szerint akár kézzel is elvégezhetjük a szükséges aktualizálásokat. Függetlenül attól, hogy mit is választunk, mindenképpen készítsünk biztonsági mentést az [.filename]#/etc# könyvtárról arra az esetre, ha bármilyen szörnyûség történne.

[[mergemaster]]
==== A `mergemaster`

A man:mergemaster[8] segédprogram valójában egy Bourne szkript, amely segít az [.filename]#/etc# könyvtárunkban és a forrásfában levõ [.filename]#/usr/src/etc# könyvtárban elhelyezkedõ konfigurációs állományok közti eltérések megállapításában. Ezt a módszert ajánljuk arra, hogy összevessük a konfigurációs állományainkat a forrásfában található változataikkal.

A használatának megkezdéséhez egyszerûen írjuk be, hogy `mergemaster`, majd várjunk egy kicsit, amíg a `mergemaster` létrehoz magának egy átmeneti környezetet a [.filename]#/# könyvtárból elindulva és megtölti azt a különbözõ rendszerszintû beállításokat tartalmazó állományokkal. Ezeket az állományokat aztán összehasonlítja a jelenleg érvényben levõ változataikkal. Ilyenkor a köztük talált eltéréseket a man:diff[1] formátumának megfelelõen módon mutatja meg, ahol a `+` jelöli a hozzáadott vagy módosított sorokat, a `-` pedig a teljesen eltávolítandó vagy cserélendõ sorokat. Errõl a formátumról bõvebben a man:diff[1] man oldalán találhatunk felvilágosítást.

A man:mergemaster[8] ezt követõen megmutatja az összes olyan állományt, ahol eltérést tapasztalt, és ezen a ponton van lehetõségünk letörölni (delete) az új állományokat (amelyekre itt most ideiglenes állományként hivatkozik), telepíteni (install) a módosítatlan ideiglenes (új) állományt, valamint összefésülni (merge) az ideiglenes (új) és a jelenlegi állományokat, vagy ismét átnézni (view) a man:diff[1] által jelzett különbségeket.

Ha az ideiglenes állomány törlését választjuk, akkor a man:mergemaster[8] ezt úgy értelmezi, hogy változatlanul meg akarjuk tartani a jelenlegi változatot és törölni az újat. Ezt alapvetõen nem javasoljuk, hacsak tényleg nem látunk valamilyen okot erre. A man:mergemaster[8] parancssorában a kbd:[?] begépelésével bármikor kérhetünk segítséget. Ha az állomány kihagyását (skip) választjuk, akkor majd ismét felajánlja, amikor végeztünk az összes többivel.

A módosítatlan ideiglenes állomány telepítésének választásával lecseréljük a jelenleg verziót az újra. Ha az aktuális verziót sem változtattuk meg, akkor számunkra ez a legjobb megoldás.

Az állományok összefésülésének kiválasztásakor kapunk egy szövegszerkesztõt, benne a két állomány tartalmával. Ilyenkor tudjuk a képernyõn soronként egyeztetni a két állományt, majd a belõlük a megfelelõ részek összeválogatásával kialakítani az eredményt. Ebben a feldolgozási módban az kbd:[l] (mint left, vagyis bal) billentyû lenyomására a bal oldalon látható részt, az kbd:[r] (mint right, vagyis jobb) lenyomására pedig a jobb oldalon látható részt választjuk ki. Az így keletkezõ eredményt ezután egy állományba kerül, amelyet telepíteni tudunk. Ez a megoldás olyan állományok esetében használható, amikor a felhasználó módosított az alapértelmezett beállításokat.

Ha a man:diff[1] szerinti alakban akarjuk átnézni a különbségeket, akkor a man:mergemaster[8] ugyanúgy megmutatja ezeket, mint a paranccsor megjelenítése elõtt.

Miután a man:mergemaster[8] végigment a rendszerszintû állományokon, további opciókat mutat. Megkérdezheti, hogy újra létre akarjuk-e hozni a jelszavakat tároló állományt (rebuild), illetve a folyamat végén a megmaradt ideiglenes állományok törlésére (remove) vár választ.

==== Az állományok aktualizálása kézzel

Ha inkább manuálisan szeretnénk frissíteni, akkor nem másolhatjuk csak egyszerûen át az állományokat a [.filename]#/usr/src/etc# könyvtárból a [.filename]#/etc# könyvtárba és nem hagyhatjuk ezeket sorsukra. Egyes állományokat elõször "telepíteni" kell. Ez azért van így, mert a [.filename]#/usr/src/etc# könyvtár _nem pusztán_ az [.filename]#/etc# könyvtár egyszerû másolata. Ráadásul az [.filename]#/etc# könyvtárban vannak olyan állományok, amelyek a [.filename]#/usr/src/etc# könyvtárban nem is találhatóak meg.

Ha (az ajánlottak szerint) a man:mergemaster[8] segítségével dolgozunk, nyugodtan átléphetünk a <<updating-upgrading-rebooting,következõ szakaszra>>.

Saját magunk a legegyszerûbben ezt úgy tudjuk megoldani, ha telepítjük az állományokat egy új könyvtárba és ezután nekiállunk változásokat keresni.

[WARNING]
.Az [.filename]#/etc# meglevõ tartalmának mentése
====
Habár elméletileg magától semmi sem fogja bántani ezt a könyvtárat, azért ettõl függetlenül mindig érdemes biztosra menni. Ezért másoljuk az [.filename]#/etc# könyvtár tartalmát egy megbízható helyre. Például:

[source,shell]
....
# cp -Rp /etc /etc.old
....

Az `-R` itt a rekurzív másolást jelenti, a `-p` pedig a dátumok, az állományok és egyebek tulajdoni viszonyainak megõrzését.
====

Az [.filename]#/etc# új változatának telepítéséhez szükségünk lesz még további könyvtárakra is. Erre a feladatra a [.filename]#/var/tmp/root# tökéletesen megfelel, ahol még létre kell hoznunk néhány alkönyvtárat.

[source,shell]
....
# mkdir /var/tmp/root
# cd /usr/src/etc
# make DESTDIR=/var/tmp/root distrib-dirs distribution
....

Ezzel létrejön a szükséges könyvtárszerkezet és települnek az állományok. Sok üres alkönyvtár is keletkezik a [.filename]#/var/tmp/root# könyvtáron belül, ezeket töröljük. Ezt a legkönnyebben így tehetjük meg:

[source,shell]
....
# cd /var/tmp/root
# find -d . -type d | xargs rmdir 2/dev/null
....

Ezzel törlõdnek az üres könyvtárak. (A szabvány hibakimenetet átirányítottuk a [.filename]#/dev/null# eszközre, és ezzel elnyomtuk a nem üres könyvtárak esetén keletkezõ hibaüzeneteket.)

A [.filename]#/var/tmp/root# most már tartalmazza az összes olyan állományt, amelyek normális esetben a [.filename]#/# könyvtáron belül foglalnak helyet. Ezt követõen nincs más dolgunk, csak végigmenni az itt található állományokon és megállapítani, miben térnek a meglévõektõl.

Vegyük észre, hogy a [.filename]#/var/tmp/root# könyvtárba telepített állományok némelyikének neve "."-tal kezdõdik. Az írás pillanatában ezek csak a [.filename]#/var/tmp/root/# és [.filename]#/var/tmp/root/root/# könyvtárakban található parancsértelmezõhöz tartozó indító állományok lehetnek, habár adódhatnak még ilyenek (attól függõen, mikor olvassuk ezt). Ezért a feldolgozásukhoz ne felejtsük el a `ls -a` parancsot használni.

A man:diff[1] alkalmazásával legegyszerûbben így tudunk összehasonlítani két állományt:

[source,shell]
....
# diff /etc/shells /var/tmp/root/etc/shells
....

Ennek hatására megjelennek az [.filename]#/etc/shells# és az új [.filename]#/var/tmp/root/etc/shells# állományok közti különbségek. A segítségével gyorsan el tudjuk dönteni, hogy összefésüljük-e a két állományt, vagy csak egyszerûen írjuk felül a régebbi verziót az újjal.

[TIP]
.Az új könyvtár ([.filename]#/var/tmp/root#) nevébe írjuk bele a dátumot is, így könnyedén össze tudunk hasonlítani több verziót is
====
A rendszer gyakori újrafordítása az [.filename]#/etc# szintén gyakori aktualizálását is maga után vonja, ami viszont fárasztó lehet.

Az iménti folyamatot fel tudjuk gyorsítani, hogy ha az [.filename]#/etc# legutoljára összefésült változatát megtartjuk. A most következõ eljárás ennek mikéntjét vázolja fel.

[.procedure]
======
. A megszokottak szerint fordítsuk le a rendszert. Majd amikor az [.filename]#/etc# könyvtárat és a többit is frissíteni akarjuk, a célként megadott könyvtár nevében adjuk meg a dátumot. Ha tehát például 1998. február 14. van, akkor írjuk ezt:
+
[source,shell]
....
# mkdir /var/tmp/root-19980214
# cd /usr/src/etc
# make DESTDIR=/var/tmp/root-19980214 \
    distrib-dirs distribution
....
+
. Fésüljük össze a könyvtárban található az állományokat a fentiekben körvonalazottak szerint.
+ 
Befejezés után _õrizzük meg_ a [.filename]#/var/tmp/root-19980214# könyvtárat.
. Mikor újra letöltjük a legfrissebb forrásokat és megismételjük az elõbbi lépéseket, haladjunk megint az elsõ lépés szerint. Ekkor tehát létrejön egy újabb könyvtár, amelynek a neve ezúttal már [.filename]#/var/tmp/root-19980221# lesz (ha például hetente frissítünk).
. Most már meg tudjuk vizsgálni a közbeesõ héten született eltéréseket, ha a két könyvtárra kiadunk egy rekurzív man:diff[1] hívást:
+
[source,shell]
....
# cd /var/tmp
# diff -r root-19980214 root-19980221
....
+ 
Általában így kevesebb eltérést kapunk, mint amennyi például a [.filename]#/var/tmp/root-19980221/etc/# és az [.filename]#/etc# összehasonlítása során elkerült volna. Mivel kisebb a keletkezett különbségek száma, ezért könnyebb lesz átvinnünk az [.filename]#/etc# könyvtárunkba is a módosításokat.
. Ezután törölhetjük a régebbi [.filename]#/var/tmp/root-*# könyvtárat:
+
[source,shell]
....
# rm -rf /var/tmp/root-19980214
....
+
. Az [.filename]#/etc# összefésülésekor mindig ismételjük meg ezeket a lépéseket.
======

A man:date[1] meghívásával akár automatikussá is tehetjük a könyvtárak névadását:

[source,shell]
....
# mkdir /var/tmp/root-`date "+%Y%m%d"`
....

====

[[updating-upgrading-rebooting]]
=== Újraindítás

Ezzel készen is vagyunk. Miután ellenõriztük, hogy minden a megfelelõ helyére került, indítsuk újra a rendszert. Ehhez egy egyszerû man:shutdown[8] is elegendõ:

[source,shell]
....
# shutdown -r now
....

=== Befejeztük!

Gratulálunk, sikerült frissítenünk a FreeBSD rendszerünket.

Ha mégis valami balul ütne ki, könnyen újra tudjuk fordítani a rendszer egyes részeit. Például, ha véletlenül letöröltük az [.filename]#/etc/magic# állományt az [.filename]#/etc# frissítése vagy összefésülése során, a man:file[1] parancs nem fog tudni rendesen mûködni. Ilyenkor a következõket kell tennünk a hiba kijavításához:

[source,shell]
....
# cd /usr/src/usr.bin/file
# make all install
....

[[updating-questions]]
=== Kérdések

==== Minden egyes változtatásnál újra kell fordítani a rendszert?

Nem könnyû választ adni erre a kérdésre, mivel ez alapvetõen a változtatás jellegétõl függ. Például, ha elindítjuk a CVSup programot és csak az alábbi állományok frissülnek:

[source,shell]
....
src/games/cribbage/instr.c
src/games/sail/pl_main.c
src/release/sysinstall/config.c
src/release/sysinstall/media.c
src/shared/mk/bsd.port.mk
....

Ekkor valószínûleg nem éri meg újrafordítani a teljes rendszert. Elegendõ csupán belépni az érintett állományokat tartalmazó alkönyvtárakba és ott rendre kiadni a `make all install` parancsot. Ha viszont már valami komolyabb, például az [.filename]#src/lib/libc/stdlib# változott meg, akkor vagy az egész rendszert, vagy legalább azon részeit fordítsuk újra, amely statikusan linkeltek (és minden más idõközben még hozzáadott statikusan linkelt dolgot).

Hogy melyik megoldást választjuk, teljesen rajtunk áll. Újrafordíthatjuk az egész rendszert kéthetente, mondván, hadd gyüljenek fel szépen a módosítások, vagy a függõségek pontos kielemzésével csak azokat az elemeket fordítjuk újra, amelyek tényleg meg is változtak.

Természetesen az egész attól függ, hogy milyen gyakran és melyik rendszert, a FreeBSD-STABLE-t vagy a FreeBSD-CURRENT-et frissítjük.

==== A fordító rengeteg 11-es jelzést (signal 11)signal 11 (vagy másfajta jelzéseket) dob hibával. Mi történhetett?

Ez általában hardveres meghibásodásra utal. A rendszer újrafordítása alapjaiban véve egy remek módszer számítógépünk alkatrészeinek terhelésére, ezért gyakorta elõhozza a memória már meglevõ hibáit. Ezek többnyire abban fogalmazódnak meg, hogy a fordító rejtélyes módon leáll mindenféle furcsa jelzések hatására.

Errõl biztosan úgy tudunk meggyõzõdni, ha újraindítjuk a make programot és az a folyamat egy teljesen másik pontján vérzik el.

Ilyenkor nem tudunk mást tenni, mint egymás után kicserélgetjük, kivesszük az alkatrészeket és így próbáljuk megállapítani, pontosan melyikük is okozza a gondokat.

==== A fordítása befejezése után törölhetem a /usr/obj könyvtárat?

Röviden: Igen.

A [.filename]#/usr/obj# tartalmazza a fordítás folyamata során keletkezõ összes tárgykódot. Ennek törlése általában a `make buildworld` elsõ lépései között szerepel. Ezért tulajdonképpen a [.filename]#/usr/obj# megtartásának nincs túlságosan sok értelme, viszont elég sok (jelenleg úgy kb. 340 MB) helyet fel tudunk így szabadítani.

Ha azonban értjük a dolgunkat, akkor megadhatjuk a `make buildworld` parancsnak, hogy hagyja ki ezt a lépést. Ennek hatására a fordítás sokkal hamarabb véget ér, mivel a legtöbb forrást így nem kell újrafordítani. Üröm az örömben, hogy ha netalán aprócska függõségi problémák merülnének fel, akkor az egész fordítás megfeneklik mindenfelé különös módokon. Emiatt gyakran írnak feleslegesen leveleket a FreeBSD levelezési listáira, melyek a rendszer sikertelen újrafordításáról panaszkodnak, miközben kiderül, hogy az maguk az érintettek akarták lerövidíteni a folyamatot.

==== Lehetséges a megszakadt fordítás folytatása?

Ez attól függ, hogy a probléma bekövetkezése elõtt mennyire sikerült eljutni a fordításban.

_Általában_ (tehát nem feltétlenül minden esetben) a `make buildworld` lefordítja a fordításhoz szükséges eszközök (például a man:gcc[1] és man:make[1]) újabb változatait és a rendszer függvénykönyvtárait, majd ezeket telepíti. Ezután ezekkel az új eszközökkel lefordítattja saját magukat és ismét telepíti. Ezt követõen fordítja újra az új rendszerállományokkal az egész rendszert (így ezúttal már az olyan szokásos felhasználói programokat is, mint például az man:ls[1] és a man:grep[1]).

Ha tudjuk, hogy az utolsó fázisban álltunk le (mivel megnéztük a fordításhoz tartozó kimenetet), akkor (minden további nélkül) elég ennyi:

[source,shell]
....
kijavítjuk a hibát ...
# cd /usr/src
# make -DNO_CLEAN all
....

Ezzel megmarad a korábbi `make buildworld` munkájának eredménye.

Ha ezt az üzenetet látjuk a `make buildworld` kimenetében:

[source,shell]
....
--------------------------------------------------------------
Building everything..
--------------------------------------------------------------
....

akkor különösebb gond nélkül megcsinálhatjuk.

Amennyiben viszont nem látunk ilyen üzenetet, vagy nem vagyunk benne biztosak, akkor még mindig jobb elõvigyázatosnak lenni, ezért kénytelenek leszünk teljesen elölrõl kezdeni a fordítást.

==== Hogyan tudjuk felgyorsítani a fordítást?

* Futtassuk egyfelhasználós módban.
* Tegyük a [.filename]#/usr/src# és [.filename]#/usr/obj# könyvtárakat külön állományrendszerekre, külön lemezekre. Sõt, ha lehetséges, akkor ezeket a lemezeket tegyük külön lemezvezérlõkre.
* Még mindig jobb, ha ezeket az állományrendszereket a man:ccd[4] (lemezek összefûzését vezérlõ meghajtó) segítségével kiterjesztjük több lemezes eszközre.
* Kapcsoljuk ki a profilozást (az [.filename]#/etc/make.conf# állományban a "NO_PROFILE=true" megadásával). Többnyire úgy sem lesz rá szükségünk.
* Az [.filename]#/etc/make.conf# állományban a `CFLAGS` változót állítsuk az `-O -pipe` értékre. Az `-O2` gyakran sokkal lassabb, az `-O` és `-O2` alig tér el az optimalizálás mértékében. A `-pipe` paraméter hatására pedig a fordítóprogram átmeneti állományok helyett csöveket használ a kommunikációra, és így megtakarít némi lemezhasználatot (a memóriahasználat terhére).
* Ha a man:make[1] parancsnak átadjuk a `-j_n_` paramétert, akkor képes több mindent párhuzamosan futtatni. Ez sok esetben segít attól függetlenül, hogy egy- vagy többprocesszoros gépünk van.
* A [.filename]#/usr/src# könyvtárat tartalmazó állományrendszert csatlakoztathatjuk (vagy újracsatlakoztathatjuk) a `noatime` beállítással. Ilyenkor az állományrendszer nem rögzíti a hozzáférés idejét. Erre az információra sincs igazából szükségünk.
+
[source,shell]
....
# mount -u -o noatime /usr/src
....
+
[WARNING]
====

A fenti példa azt feltételezi, hogy a [.filename]#/usr/src# könyvtárnak saját állományrendszere van. Ha ez nem így lenne (tehát például a [.filename]#/usr# része), akkor itt azt kell megadnunk, nem pedig a [.filename]#/usr/src# nevét.
====

* A [.filename]#/usr/obj# könyvtárat tartalmazó állományrendszert csatlakoztathatjuk (vagy újracsatlakoztathatjuk) az `async` beállítással. Ennek hatására a lemez írása aszinkron módon történik. Magyarul az írási mûveletek azonnal befejezõdnek, miközben az adat ténylegesen csak pár másodperccel késõbb kerül ki a lemezre. Ezzel az írási kérelmek gyönyörûen összegyûjthetõek, ami nagymértékû növekedést eredményez a teljesítményben.
+
[WARNING]
====

Ne felejtsük el azonban, hogy ezzel együtt az állományrendszerünk is sérülékenyebbé válik. Ezen beállítás használatával megnõ annak az esélye, hogy egy áramkimaradást követõ indításnál az állományrendszer helyreállíthatatlan állapotba kerül.

Ha egyedül csak a [.filename]#/usr/obj# található ezen az állományrendszeren, akkor ez nem jelent akkora veszélyt. Amikor viszont rajta kívül még értékes adat is található az állományrendszeren, a beállítás érvényesítése elõtt mindenképpen készítsünk róla friss mentéseket.
====
+
[source,shell]
....
# mount -u -o async /usr/obj
....
+
[WARNING]
====

Ahogy arról az elõbb is szó esett, ha a [.filename]#/usr/obj# nem egy különálló állományrendszeren található, akkor a példában szereplõ csatlakozási pontot cseréljük ki a megfelelõre.
====

==== Mi tegyünk, ha valami nem megy rendesen?

Egyértelmûen bizonyosodjunk meg róla, hogy a korábbi fordításokból nem maradtak vissza semmiféle kóbor állományok. Ennyi sokszor pontosan elég.

[source,shell]
....
# chflags -R noschg /usr/obj/usr
# rm -rf /usr/obj/usr
# cd /usr/src
# make cleandir
# make cleandir
....

Igen, a `make cleandir` parancsot tényleg kétszer kell kiadni.

Ezután a `make buildworld` parancstól indulva kezdjük újra a fordítást.

Ha még ezek után is fennáll a probléma, küldjük el a hibát tartalmazó kimenetet és a `uname -a` parancs eredményét a {freebsd-questions} címére. Ne lepõdjünk meg, ha a beállításainkra vonatkozóan még kapunk további kérdéseket is!

[[small-lan]]
== A források követése több géppel

Ha egyszerre több számítógéppel is szeretnénk követni ugyanannak a forrásfának a változásait és ezért mindegyikre letöltjük a forrásokat majd újrafordítjuk ezeket, akkor sok erõforrást, de leginkább lemezterületet, hálózati sávszélességet és processzoridõt, feleslegesen használunk. Ezekkel úgy tudunk spórolni, ha valójában csak egyetlen géppel végeztetjük el a munka legtöbb részét, miközben a többi NFS használatával dolgozik. Ez a szakasz ezt a módszert foglalja össze.

[[small-lan-preliminaries]]
=== Elõkészületek

Elõször is szedjük össze az egyezõ binárisokat futtató gépeket, melyekre a továbbiakban csak _fordítási csoport_ néven hivatkozunk. Minden gépnek lehet saját rendszermagja, viszont a felhasználói programok mindegyikõjük esetében ugyanazok. Ebbõl a csoportból válasszuk ki egy _fordító gépet_. Ez lesz az a gép, amelyen a rendszer és a rendszermag lefordításra kerül. Ideális esetben ez a leggyorsabb gép, amelynek elegendõ a processzorkapacitása arra, hogy lefuttassa a `make buildworld` és `make buildkernel` parancsokat. Érdemes még rajta kívül kiválasztanunk egy _tesztelõ gépet_ is, ahol a véglegesítés elõtt kipróbálhatjuk a szoftverfrissítéseket. Ennek egy olyan gépnek _kell_ lennie, amely akár hosszabb ideig is nélkülözhetõ a csoportból. Lehet akár maga a fordítást végzõ gép is, de nem elvárás.

A fordítási csoportban levõ összes gépnek ugyanarról a géprõl és ugyanarra a pontra kell csatlakoztatnia a [.filename]#/usr/obj# és [.filename]#/usr/src# könyvtárakat. Ezek optimális esetben a fordítással foglalkozó gép két külön lemezmeghajtóján vannak, melyek egyaránt elérhetõek NFS-en keresztül. Ha több fordítási csoportunk is van, akkor az [.filename]#/usr/src# könyvtárnak elegendõ csak egyetlen fordító gépen meglennie, a többi pedig csatlakoztassa NFS-en keresztül.

Végül gyõzödjünk meg róla, hogy az [.filename]#/etc/make.conf# és a [.filename]#/etc/src.conf# állományok tartalma a fordítási csoport mindegyik gépénél megegyezik a fordító gépével. Ez azt jelenti, hogy a fordító gépnek az alaprendszer ugyanazon részeit és ugyanúgy kell létrehozni, mint amelyet a fordítási csoport akármelyik gépére telepíteni is akarunk. Ezenkívül még a fordítási csoportban levõ minden egyes gép [.filename]#/etc/make.conf# állományában a `KERNCONF` értékének a saját rendszermagjára vonatkozó konfigurációt kell megadni, illetve a fordítással foglakozó gép `KERNCONF` változójánál pedig az együtt összeset, a sajátjával kezdve. Ennek megfelelõen a fordító gépnek a rendszermagok lefordításához rendelkeznie kell az egyes gépek [.filename]#/usr/src/sys/arch/conf# könyvtárában meglevõ állományaival.

[[small-lan-base-system]]
=== Az alaprendszer

Most, miután mindent megfelelõen elõkészítettünk, készen állunk a munkára. A <<make-buildworld>>ban leírtak szerint fordítsuk le a rendszermagokat és az alaprendszert a fordító gépen, de utána még nem telepítsünk semmit se. Ha befejezõdött a fordítás, lépjünk be a tesztelõ gépre és telepítsük a frissen fordított rendszermagot. Ha ez a gép NFS-en keresztül éri a [.filename]#/usr/src# és [.filename]#/usr/obj# könyvtárakat, akkor az egyfelhasználós módban aktiválni kell a hálózatot, majd csatlakoztatni ezeket. Ezt legkönnyebben úgy tudjuk megcsinálni, ha a gépet elõször elindítjuk többfelhasználós módban, majd a `shutdown now` paranccsal egyfelhasználós módba váltunk. Ha eljuttunk ide, telepítsünk az új rendszermagot és rendszert, illetve a megszokott módon futtassuk a `mergemaster` parancsot. Amikor ezt befejeztük, ezen a gépen térjünk vissza a hétköznapi többfelhasználós mûködési módba.

Miután a tesztelésre szánt gépen ellenõriztük, hogy minden a megfelelõ módon mûködik, az elõbb tárgyalt eljárással telepítsük fel a fordítási csoportban levõ összes többi gépre is az új szoftvereket.

[[small-lan-ports]]
=== Portok

Ugyanezt a gondolatmenet alkalmazható a portfa esetében is. Az elsõ és egyben legfontosabb lépés a [.filename]#/usr/ports# csatlakoztatása ugyanarról a géprõl a fordítási csoport minden gépére. Az [.filename]#/etc/make.conf# megfelelõ beállításával még a terjesztési állományokat is meg tudjuk osztani. A `DISTDIR` értékét egy olyan közösen használt könyvtárra állítsuk, amely írható az NFS-en keresztül megosztott állományrendszerünkben a `root` felhasználóként tevékenykedõk számára. A `WRKDIRPREFIX` változót minden gépen egy helyi fordítási könyvtárra állítsuk. Zárásképpen még hozzátesszük, hogy ha csomagokat akarunk készíteni és mások számára is elérhetõvé tenni, akkor ne felejtsük el a `PACKAGES` változót a `DISTDIR` változóhoz hasonlóan beállítani.
