Jim Mock Átdolgozta, átrendezte és egyes részeit aktualizálta: Jordan Hubbard Eredetileg írta: Poul-Henning Kamp John Polstra Nik Clayton A &os; 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 &os; 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 &os.stable; és a &os.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 (); a külső szoftverek telepítésének ismerete (). A fejezetben a &os; forrásainak frissítését a cvsup parancs segítségével fogjuk elvégezni. Ehhez telepítsük a net/cvsup portot vagy csomagot (ha a cvsup parancsot nem akarjuk grafikus felületen keresztül használni, akkor elegendő csak a net/cvsup-without-gui portot). Ha a &os; 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. Tom Rhodes Írta: Colin Percival A megíráshoz felhasznált jegyzeteket készítette: frissítés és frissen tartás freebsd-update frissítés és frissen tartás 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 &os; 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 &os; 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 &os; 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. Ezek a bináris frissítések azonban csak a &os; 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 &os; 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 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. Ha változtatnénk szeretnénk a frissítési folyamaton, ekkor a programhoz tartozó, /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: # Az alaprendszerben frissíteni kívánt komponensek Components src world kernel Ezzel a paraméterrel határozhatjuk meg, hogy a &os; 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 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. # 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 /bin vagy az /sbin. Így meg tudjuk akadályozni, hogy freebsd-update esetleg felülírjon valamilyen helyi változtatást a rendszerünkben. # 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. # A MergeChanges beállításnál szereplő állományok helyi módosításait # automatikusan összefésüljük a &os; ú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 /etc könyvtárat és fogadjuk el mindegyik összefésülés eredményét. A mergemaster működéséről a ad részletesebb tájékoztatást. # A &os; 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. # 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. 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: &prompt.root; freebsd-update fetch &prompt.root; 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 /etc/crontab állományban: @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: &prompt.root; 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 &os; 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. Mindig érdemes tartani egy másolatot a GENERIC rendszermagról a /boot/GENERIC könyvtárban. Rengeteg különböző probléma felderítésében tud segíteni, illetve ez a szakaszban leírt freebsd-update programmal végzett frissítéseknél is hasznos lehet. Hacsak nem változtatjuk meg az /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ő. 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 /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. 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 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: &prompt.root; 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 /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 /boot/kernel.old könyvtárban még megtalálható a GENERIC. Ezt nevezzük át egyszerűen /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: &prompt.root; mount /cdrom &prompt.root; cd /cdrom/X.Y-RELEASE/kernels &prompt.root; ./install.sh GENERIC Itt a 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 /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: &prompt.root; cd /usr/src &prompt.root; env DESTDIR=/boot/GENERIC make kernel &prompt.root; mv /boot/GENERIC/boot/kernel/* /boot/GENERIC &prompt.root; 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 /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 &os; 6.4 használatára: &prompt.root; 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ó: 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: 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 /etc könyvtárban tárolt fontosabb állományokról, mint például a master.passwd vagy group javasolt előzetesen biztonsági mentést készíteni és később kézzel hozzájuk adni a változtatásaikat. 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: &prompt.root; 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 /boot/GENERIC könyvtárban levőre (ezt frissítettük): &prompt.root; nextboot -k GENERIC 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 /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: &prompt.root; 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: &prompt.root; freebsd-update install 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 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: &prompt.root; portupgrade -f ruby &prompt.root; rm /var/db/pkg/pkgdb.db &prompt.root; portupgrade -f ruby18-bdb &prompt.root; rm /var/db/pkg/pkgdb.db /usr/ports/INDEX-*.db &prompt.root; 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: &prompt.root; 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 &os; frissített változatával. A folyamat ezzel véget ért. A freebsd-update ragyogóan felhasználható a &os; 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: &prompt.root; freebsd-update IDS >> eredmeny.idk Habár a parancs neve IDS (intrusion detection system), nem helyettesít semmilyen olyan behatolásjelző megoldást, mint amilyen például a 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 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: &prompt.root; 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 /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 /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. Tom Rhodes Írta: Colin Percival A megíráshoz felhasznált jegyzeteket készítette: frissítés és frissen tartás Portsnap frissítés és frissen tartás A &os; 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: &prompt.root; 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: &prompt.root; 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: &prompt.root; 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: &prompt.root; portsnap fetch update Ez a parancs letölti a Portgyűjtemény legfrissebb változatát, majd kitömöríti azt a helyi /usr/ports könyvtárba. frissítés és frissen tartás dokumentáció frissítés és frissen tartás Az alaprendszer és a Portgyűjtemény mellett a dokumentáció is a &os; operációs rendszer szerves részét képezi. Noha a &os; dokumentációjának legfrissebb változata folyamatosan elérhető a &os; 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ő. A &os; telepített dokumentációjának forrásai az alaprendszeréhez hasonlóan (lásd ) 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 &os; dokumentációját; hogyan töltsük le a dokumentáció forrását CVSup segítségével a /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. Viszonylag sokféle eszközre lesz szükségünk, ha a &os; dokumentációját a forrásokból akarjuk előállítani. Ezek az segédprogramok nem részei a &os; alaprendszerének, mivel alapvetően nagyon sok helyet foglalnak el, és leginkább olyan &os; 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 &os; Dokumentációs Projekt összeállított egy textproc/docproj nevű portot, amellyel az említett programok telepítését és frissítését igyekezték megkönnyíteni. Ha nem tartunk igényt a dokumentáció &postscript; vagy PDF változatára, akkor ehelyett inkább érdemes megfontolnunk a 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 CVSup használatával foglalkozó szakaszban olvashatunk. A /usr/share/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: &prompt.root; cvsup -h cvsup.FreeBSD.org -g -L 2 /usr/share/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 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 /usr/doc könyvtárban található Makefile használatával állíthatjuk elő. Tehát miután az /etc/make.conf állományban beállítottuk a SUP_UPDATE, SUPHOST és DOCSUPFILE változókat, le tudjuk futtatni a következő parancsot: &prompt.root; cd /usr/doc &prompt.root; make update Az előbb említett &man.make.1; változók jellemző értékei: SUP_UPDATE= yes SUPHOST?= cvsup.freebsd.org DOCSUPFILE?= /usr/share/examples/cvsup/doc-supfile 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 /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. A &os; 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 /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 /usr/share/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 &os; 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 A &os; Dokumentációs Projekt irányelvei kezdőknek című könyvet. Miután sikerült letöltenünk a /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: &prompt.root; cd /usr/doc &prompt.root; make install clean Ha a 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: &prompt.root; cd /usr/doc &prompt.root; 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 /usr/doc könyvtáron belül az egyes nyelvekhez tartozó alkönyvtárakon belül is meghívható, például: &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make update install clean A dokumentáció formátumát a FORMATS változó felhasználásával tudjuk meghatározni: &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean Marc Fonvieille A szóbanforgó megoldást fejlesztette: frissítés és frissen tartás dokumentáció frissítés és frissen tartás Ez előző szakaszban megmutattuk hogyan lehet a &os; 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 &os; 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 &os; 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 &os; dokumentáció frissítésének fentebb említett módjait támogatják tehát a dokumentációs portok, amelyeket a &a.doceng; havi rendszerességgel tart karban. Ezek a portok a &os; Portgyűjteményén belül a docs nevű virtuális kategóriában találhatóak meg. 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 &os; port vagy csomag esetében. 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 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 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 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): &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean Ennek hatására előáll és telepítődik a /usr/local/share/doc/freebsd könyvtárba az angol nyelvű dokumentáció állományokra bontott HTML formátumban (hasonlóan a tartalmához). 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 article.html (cikk) vagy book.html (könyv) néven keletkezik (képekkel együtt). WITH_PDF Minden dokumentum &adobe; 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 article.pdf (cikk) vagy 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 /usr/local/share/doc/freebsd könyvtár. Ü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 /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: &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean 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 &a.doceng; minden hónapban előkészíti a &os; 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. A bináris csomagok használata esetén a &os; 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: &prompt.root; pkg_add -r hu-freebsd-doc 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. 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 ports-mgmt/portupgrade eszközön keresztül így frissíthető csomagok használatával: &prompt.root; portupgrade -PP hu-freebsd-doc -CURRENT -STABLE A &os;-nek két fejlesztési ága van: a &os;.current és a &os.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 &os.current;, majd a &os.stable; változata kerül tárgyalásra. Ahogy arról már az imént is szó esett, nem szabad elfelejtenünk, hogy a &os.current; a &os; fejlesztésének frontvonala. Emiatt a &os.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 &os;-vel, kétszer is gondoljuk meg a telepítését! pillanatkép A &os.current; a &os; 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 &os; fejlesztői a &os.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 &os.current; használata kész katasztrófa vagy akár a fejlődésben igazi továbblépés is lehet. A &os.current; használata elsősorban az alábbi 3 csoportot érinti: A &os; 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 &os; közösség azon tagjait, akik aktívan tesztelnek, és a &os.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 &os; 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. 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 &os.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 &os.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 &os;). Csupán a &os; fejlesztése közben fizikailag képtelenek vagyunk a naponta érkező ezernyi üzenetet rendre megválaszolni! A &os; 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. -CURRENT használata Iratkozzunk fel az &a.current.name; és &a.svn-src-head.name; listákra. Ez nem egyszerűen hasznos, hanem elengedhetetlen. Ha nem vagyunk a &a.current.name; 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 &a.svn-src-head.name; 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 &a.mailman.lists.link; 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 &a.svn-src-all.name; lista olvasását. A tükrözések egyikéről töltsük le a &os; forrását. Erre két mód is kínálkozik: cvsup cron -CURRENT frissítés CVSuppal Használjuk a cvsup programot a /usr/share/examples/cvsup könyvtárban található 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 cvsup működését a fentebb említett minta supfile állomány megfelelő módosításával tudjuk a saját környezetünkhöz igazítani. Az említett standard-supfile állomány eredetileg nem a &os.current;, hanem inkább a &os; biztonsági problémáit érintő javítások követésére használatos. A &os.current; forrásainak eléréséhez a következő sort kell kicserélnünk ebben az állományban: *default release=cvs tag=RELENG_X_Y Erre: *default release=cvs tag=. A tag paramétereként megadható egyéb címkékről a kézikönyv CVS címkék szakaszában olvashatunk. -CURRENT frissítés CTM-mel 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 &os.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. -CURRENT fordítása A &os.current; lefordítása előtt figyelmesen olvassuk át a /usr/src könyvtárban található Makefile állományt. A frissítési folyamat részeként először mindenképpen érdemes telepíteni egy új rendszermagot és újrafordítani az alaprendszert. Olvassuk el a &a.current; üzeneteit és a /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 &os.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 &os.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 &os.current; ágból. Ez azonban még mindig csak egy fejlesztési ág, ami arra utal, hogy a &os.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. Ha szeretnénk figyelemmel kísérni vagy valamilyen módon kiegészíteni a &os; fejlesztési folyamatát, különösen a &os; következő nagyobb kiadását illetően, akkor érdemes követnünk a &os.stable; forrásait. Habár a &os.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 &os;-hez kiadott biztonsági figyelmeztetések mindig leírják, hogyan kell javítani a hibát az érintett kiadásokban Ez azért nem teljesen igaz. A régebbi &os; kiadásokat ugyan nem támogathatjuk a végtelenségig, de általában így is több évig foglalkozunk velük. A &os; régebbi kiadásaival kapcsolatos jelenleg érvényes biztonsági házirend részletes bemutatása a http://www.FreeBSD.org/security/ oldalon olvasható (angolul). , 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 &os.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 &os.stable; ágba kerülő kódokat először a &os.current; ágban fejlesztik ki, és mivel a &os.stable; felhasználói többen vannak a &os.current; változaténál, ezért szinte elkerülhetetlen, hogy ilyenkor a &os.stable; változatban bizonyos hibák és szélsőséges esetek be ne következzenek, amelyek a &os.current; használata során még nem buktak ki. Ezért a &os.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 &os.stable; rendszert. Ha ehhez nem rendelkezünk elegendő erőforrással, akkor egyszerűen használjuk a &os; legfrissebb kiadását, és az egyes kiadások között pedig bináris frissítéssel közlekedjünk. -STABLE használata Iratkozzunk fel a &a.stable.name; listára. Ezen keresztül értesülhetünk a &os.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 &a.svn-src-stable-7.name; 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 &a.mailman.lists.link; 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 &os.stable; havonta készült pillanatképeit akarjuk rajta futtatni, akkor erről bővebb felvilágosítást a Pillanatképek honlapján találhatunk (angolul). Emellett a legfrissebb &os.stable; kiadást telepíthetjük a tükrözések valamelyikéről is, majd innen a lentebb található utasítások szerint tudunk hozzáférni a &os.stable; forráskódjának legfrissebb változatához. Ha már fut a gépünkön a &os; egy korábbi kiadása, és ezt akarjuk forráson keresztül frissíteni, akkor ezt a &os; tükrözéseivel könnyedén megtehetjük. Két módon is: cvsup cron -STABLE frissítés CVSuppal Használjuk a cvsup programot a /usr/share/examples/cvsup könyvtárból származó 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 cvsup működését környezetünkhöz az előbb említett minta supfile megfelelő módosításával tudjuk behangolni. -STABLE frissítés CTM-mel 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. -STABLE fordítása Mielőtt lefordítanánk a &os.stable; változatát, figyelmesen olvassuk át a /usr/src könyvtárban levő Makefile állományt. Az átállási folyamat részeként először minden bizonnyal telepítenünk kell egy új rendszermagot és újra kell fordítanunk az alaprendszert. A &a.stable; valamint a /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. Az internet (vagy elektronikus levelek) használatán keresztül számos mód kínálkozik az &os; 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 Anonim CVS, CVSup és CTM szolgáltatásokat ajánljuk fel. 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 /bin és /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. CVS anonim 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ó. CTM 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. az alaprendszer újrafordítása Miután sikerült a helyi forrásfánkat a &os; egy nekünk szimpatikus (&os.stable;, &os.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. 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! levelezési lista A &os.stable; és &os.current; ágak természetüknél fogva fejlesztés alatt állnak. A &os; 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 &a.stable; vagy a &a.current; olvasása nélkül próbáljuk meg használni a &os.stable; és &os.current; verziókat, akkor csak magunknak keressük a bajt. 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. A frissítés megkezdése előtt érdemes elolvasnunk a /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 &os; 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 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 &os; 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 /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 /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 /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 &os; 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 /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. A &os; 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 UPDATING állományt! Röviden tehát a &os; forráskódon keresztüli frissítését így foglalhatjuk össze: &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; shutdown -r now 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 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 &os; 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: &prompt.root; adjkerntz -i &prompt.root; mount -a -t ufs &prompt.root; mergemaster -p &prompt.root; cd /usr/src &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot 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. Mielőtt bármihez is nekifognánk, keressük meg a /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 UPDATING ellentmondana az itt olvasottaknak, az UPDATING tartalma a mérvadó. A korábban tárgyaltak szerint az 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 Vizsgáljuk át a /usr/share/examples/etc/make.conf és az /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 /etc/make.conf állományba. Ne felejtsük el azonban, hogy minden, amit megadunk az /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 /etc/make.conf állományhoz a /usr/share/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. Az /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 &os; 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 /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 /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: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p 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: &prompt.root; 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. egyfelhasználós mód 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. többfelhasználós mód 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: &prompt.root; 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: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Ezekkel a parancsokkal először ellenőrizzük az állományrendszereket, ezután újracsatlakoztatjuk a / állományrendszert írható módban, csatlakoztatjuk az /etc/fstab állományban megadott összes többi UFS típusú állományrendszert, majd bekapcsoljuk a lapozóállomány használatát. 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: &prompt.root; 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. A rendszer egyes részei fordításuk során a /usr/obj könyvtáron belülre kerülnek (alapértelmezés szerint). Az itt található könyvtárak a /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 /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. &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * 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 &os; 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. &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … fordít, fordít, fordít … &prompt.root; exit Script done, … Ilyenkor soha ne a /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 /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. A /usr/src könyvtárban kell állnunk: &prompt.root; cd /usr/src (kivéve természetesen, ha máshol van a forráskód, akkor abba a könyvtárba menjünk). make Az alaprendszert a &man.make.1; paranccsal fordíthatjuk újra. Ez a Makefile nevű állományból olvassa be a &os; 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: &prompt.root; 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 -DVÁLTOZÓ alakú paraméterek közvetlenül a 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 /etc/make.conf állományban is szerepelnek, és itt a beállításuk egy másik módját kapjuk. Így a &prompt.root; make -DNO_PROFILE target paranccsal is megadhatjuk, hogy ne profilozott függkönyvtárak jöjjenek létre, ami pontosan megfelel a NO_PROFILE= true # Avoid compiling profiled libraries sornak az /etc/make.conf állományban. A target árulja el a &man.make.1; programnak, hogy mi a teendője. Minden egyes 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 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: &prompt.root; 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 /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 /usr/src és /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 &prompt.root; 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: &prompt.root; 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. az alaprendszer újrafordítása időigény Számos tényező befolyásolja a fordítás tényleges időbeli hosszát, de a &os.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 &os.current; fához ennél valamivel több időre lesz szükségünk. rendszermagot fordítása 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 GENERIC beállításai alapján gyártunk és telepítünk egy rendszermagot. Még ha a 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 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. &os; alatt egy új rendszermag építése előtt fontos újrafordítani az alaprendszert. 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: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=SAJÁTMAG &prompt.root; 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. egyfelhasználós mód 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 . Ha a &os; 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: &prompt.root; cd /usr/src &prompt.root; make installworld 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: &prompt.root; make -DNO_PROFILE buildworld akkor így telepítsünk: &prompt.root; 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. 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 /etc, /var és /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 /etc könyvtárról arra az esetre, ha bármilyen szörnyűség történne. Tom Rhodes Írta: mergemaster A &man.mergemaster.8; segédprogram valójában egy Bourne szkript, amely segít az /etc könyvtárunkban és a forrásfában levő /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 / 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 ? 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 l (mint left, vagyis bal) billentyű lenyomására a bal oldalon látható részt, az 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. Ha inkább manuálisan szeretnénk frissíteni, akkor nem másolhatjuk csak egyszerűen át az állományokat a /usr/src/etc könyvtárból a /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 /usr/src/etc könyvtár nem pusztán az /etc könyvtár egyszerű másolata. Ráadásul az /etc könyvtárban vannak olyan állományok, amelyek a /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 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. 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 /etc könyvtár tartalmát egy megbízható helyre. Például: &prompt.root; 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 /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 /var/tmp/root tökéletesen megfelel, ahol még létre kell hoznunk néhány alkönyvtárat. &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; 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 /var/tmp/root könyvtáron belül, ezeket töröljük. Ezt a legkönnyebben így tehetjük meg: &prompt.root; cd /var/tmp/root &prompt.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 /dev/null eszközre, és ezzel elnyomtuk a nem üres könyvtárak esetén keletkező hibaüzeneteket.) A /var/tmp/root most már tartalmazza az összes olyan állományt, amelyek normális esetben a / 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 /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 /var/tmp/root/ és /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: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Ennek hatására megjelennek az /etc/shells és az új /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. A rendszer gyakori újrafordítása az /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 /etc legutoljára összefésült változatát megtartjuk. A most következő eljárás ennek mikéntjét vázolja fel. A megszokottak szerint fordítsuk le a rendszert. Majd amikor az /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: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; 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 /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 /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: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Általában így kevesebb eltérést kapunk, mint amennyi például a /var/tmp/root-19980221/etc/ és az /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 /etc könyvtárunkba is a módosításokat. Ezután törölhetjük a régebbi /var/tmp/root-* könyvtárat: &prompt.root; rm -rf /var/tmp/root-19980214 Az /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: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` 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ő: &prompt.root; shutdown -r now Gratulálunk, sikerült frissítenünk a &os; 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 /etc/magic állományt az /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: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install 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: src/games/cribbage/instr.c src/games/sail/pl_main.c src/release/sysinstall/config.c src/release/sysinstall/media.c src/share/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 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 &os.stable;-t vagy a &os.current;-et frissítjük. signal 11 A fordító rengeteg 11-es jelzést (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 /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 /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 &os; 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: … kijavítjuk a hibát … &prompt.root; cd /usr/src &prompt.root; 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: -------------------------------------------------------------- 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 /usr/src és /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 /etc/make.conf állományban a NO_PROFILE=true megadásával). Többnyire úgy sem lesz rá szükségünk. Az /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 -jn 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 /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. &prompt.root; mount -u -o noatime /usr/src A fenti példa azt feltételezi, hogy a /usr/src könyvtárnak saját állományrendszere van. Ha ez nem így lenne (tehát például a /usr része), akkor itt azt kell megadnunk, nem pedig a /usr/src nevét. A /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. 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 /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. &prompt.root; mount -u -o async /usr/obj Ahogy arról az előbb is szó esett, ha a /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. &prompt.root; chflags -R noschg /usr/obj/usr &prompt.root; rm -rf /usr/obj/usr &prompt.root; cd /usr/src &prompt.root; make cleandir &prompt.root; 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 &a.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! Mike Meyer Írta: NFS több gép telepítése 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. 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 /usr/obj és /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 /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 /etc/make.conf és a /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 /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 /usr/src/sys/arch/conf könyvtárában meglevő állományaival. Most, miután mindent megfelelően előkészítettünk, készen állunk a munkára. A 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 /usr/src és /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. Ugyanezt a gondolatmenet alkalmazható a portfa esetében is. Az első és egyben legfontosabb lépés a /usr/ports csatlakoztatása ugyanarról a gépről a fordítási csoport minden gépére. Az /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.