diff --git a/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml index 98fd73adc4..307ca21d94 100644 --- a/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1,2030 +1,1903 @@ Jim Mock Geherstructureerd, gereorganiseerd en delen bijgewerkt door Jordan Hubbard Origineel door Poul-Henning Kamp John Polstra Nik Clayton Remko Lodder Vertaald door Siebrand Mazeland Het scherp van de snede Overzicht &os; wordt ontwikkeld tussen de verschillende versies in. Voor mensen die het nieuwste van het nieuwste willen hebben zijn er verschillende makkelijke mechanismes om een systeem gesynchroniseerd te houden met de laatste ontwikkelingen. Wees gewaarschuwd: het nieuwste van het nieuwste is niet voor iedereen geschikt! Dit hoofdstuk helpt om een keuze te maken of het wenselijk is het ontwikkelsysteem te volgen of één van de uitgegeven versies. Na het lezen van dit hoofdstuk weet de lezer: De verschillen tussen de ontwikkeltakken &os.stable; en &os.current;; Hoe een systeem bijgewerkt kan worden met CVSup, CVS of CTM; Hoe een basissysteem opnieuw te compileren en te herinstalleren met make buildworld, enzovoort. Veronderstelde criteria: Een juist ingesteld netwerk (); Weten hoe software van derden te installeren (). &os.current; vs. &os.stable; -CURRENT -STABLE Er zijn twee ontwikkeltakken voor &os;: &os.current; en &os.stable;. Deze sectie licht beiden toe en beschrijft hoe een systeem bijgewerkt te houden met elke tak. &os.current; wordt eerst behandeld, daarna &os.stable;. Bijblijven met &os; Bedenk dat &os.current; het nieuwste van het nieuwste is van &os; ontwikkeling. Van &os.current; gebruikers wordt verwacht dat ze veel technische kennis hebben en capabel zijn om zelfstandig lastige systeemproblemen op te lossen. Nieuwe gebruikers van &os; kunnen het beste twee keer nadenken alvorens het te installeren. Wat is &os.current;? momentopname &os.current; is de laatste werkende set broncode voor &os;. Dit bevat werk in uitvoering, experimentele wijzigingen en overgangsmechanismes die mogelijk wel of niet meegenomen worden in de volgende officiële uitgave van het besturingssysteem. Alhoewel veel &os;-ontwikkelaars de broncode van &os.current; dagelijks compileren, zijn er periodes dat de broncode niet compileerbaar is. Deze problemen worden zo snel mogelijk gerepareerd, maar het is mogelijk dat &os.current; een ramp veroorzaakt in plaats van dat het de gewenste functionaliteit levert. Dit ligt geheel aan het moment waarop de broncode is opgehaald. Wie heeft &os.current; nodig? &os.current; is beschikbaar voor drie primaire aandachtsgroepen: Leden van de &os;-gemeenschap die actief werken aan een deel van de broncode voor wie current een echte eis is. Leden van de &os;-gemeenschap die actief testen en tijd hebben om problemen op te lossen om zeker te stellen dat &os.current; zo gezond als mogelijk is. Er zijn ook mensen die actuele suggesties maken over wijzigingen en de algemene richting van &os; en die patches opsturen om deze te implementeren. Diegenen die alleen een oogje in het zeil willen houden of de huidige bronnen gebruiken ter referentie (bijvoorbeeld voor het lezen en niet het draaien). Deze mensen geven ook regelmatig commentaar of dragen bij in de code. Wat is &os.current; <emphasis>niet</emphasis>? Een snelle manier om pre-release versies te krijgen omdat bekend is dat er een aantal leuke nieuwe mogelijkheden in zitten en het leuk is deze als eerste te gebruiken. Het als eerste gebruiken van nieuwe mogelijkheden betekent ook de eerste zijn die nieuwe bugs ontdekt. Een snelle manier om bugfixes te krijgen. Elke willekeurige versie van &os.current; heeft waarschijnlijk net zoveel nieuwe bugs als dat er bugs opgelost zijn. Op welke manier dan ook officieel ondersteund. We doen onze best om mensen echt te helpen in één van de drie legitieme &os.current; groepen maar er is simpelweg niet genoeg tijd om technische ondersteuning te leveren. Dit is niet omdat we gemene en vervelende mensen zijn die anderen niet willen helpen (we zouden niet eens aan &os; werken als we dat durfden). De ontwikkelaars kunnen simpelweg geen honderd berichten per dag beantwoorden én aan &os; werken. Bij de keuze tussen het verbeteren van &os; en vragen beantwoorden over experimentele code, kiezen ontwikkelaars voor het eerste. &os.current; gebruiken -CURRENT gebruiken Neem een abonnement op de mailinglijsten &a.current.name; en &a.cvsall.name;. Dit is niet alleen een goed idee, het is essentieel. Geen berichten ontvangen van de lijst &a.current.name; betekent geen commentaar zien dat mensen maken over de huidige staat van het systeem en dus waarschijnlijk struikelen over problemen die anderen al gevonden en opgelost hebben. Nog belangrijker is het missen van belangrijke informatie die kritisch kan zijn voor een systeem. De lijst &a.cvsall.name; biedt de mogelijkheid de wijzigingsboodschap te zien voor elke wijziging die gemaakt wordt samen met relevante informatie over mogelijke bijwerkingen. Ga om op deze lijsten of één van de andere beschikbare lijsten te abonneren naar &a.mailman.lists.link; en klik op de gewenste lijst. Instructies over de rest van de procedure zijn daar beschikbaar. Haal de broncode van een &os; mirrorsite. Dit kan op de volgende twee manieren: cvsup cron -CURRENT Synchroniseren met CVSup Gebruik het programma cvsup met de supfile genaamd standard-supfile uit /usr/share/examples/cvsup. Dit is de geadviseerde methode, omdat de gehele collectie in één keer wordt binnengehaald en daarna alleen hetgeen wat gewijzigd is. Veel mensen draaien cvsup vanuit de cron en houden daarmee hun broncode automatisch bijgewerkt. De voorbeeld supfile dient aangepast te worden om cvsup in te stellen voor een omgeving. -CURRENT Synchroniseren met CTM Gebruik de CTM faciliteit. Bij een slechte verbinding, dure connecties of alleen e-mail toegang, is CTM een optie. Het werkt echter lastig en geeft mogelijk corrupte bestanden. Dit zorgt ervoor dat het zelden gebruikt wordt, dat de kans verhoogt dat het niet werkt voor redelijk lange periodes. Het advies is CVSup te gebruiken. Als de broncode wordt opgehaald om te draaien en niet alleen om naar te kijken, haal dan alles op van &os.current; en niet alleen geselecteerde delen. De reden hiervoor is dat verschillende delen van de code afhangen van updates op andere plekken en het compileren van een onderdeel gegarandeerd problemen oplevert. -CURRENT compileren Voordat &os.current; gecompileerd wordt is het raadzaam om de Makefile in /usr/src aandachtig te bekijken. Het is handig om de eerste keer op zijn minst de kernel en de wereld opnieuw te bouwen als onderdeel van het updateproces. Via de &a.current; en /usr/src/UPDATING is het mogelijk op de hoogte te blijven van mogelijke wijzigingen in de opstartprocedures die soms nodig zijn tussen verschillende versies. Wees actief! Ervaringen van &os.current;-gebruikers zijn belangrijk, zeker als het gaat om suggesties voor verbeteringen of bugfixes. Suggesties met bijbehorende code worden enthousiast ontvangen! &os; stabiel houden Wat is &os.stable;? -STABLE &os.stable; is de ontwikkeltak waaruit grote releases gemaakt worden. Wijzigingen in deze tak gaan in een ander tempo en met de algemene aanname dat ze eerst in &os.current; worden ingebracht ter test. Dit is nog steeds een ontwikkeltak, echter dit betekent dat op elk gegeven moment de code voor &os.stable; wel of niet geschikt is voor een speciaal doel. Het is simpelweg een andere ontwikkelomgeving en geen bron voor eindgebruikers. Wie heeft &os.stable; nodig? Bij interesse in het bijhouden van of bijdragen aan het &os;-ontwikkelproces, speciaal als het gerelateerd is aan de volgende versie van &os;, is het volgen van &os.stable; het overwegen waard. Ondanks dat security fixes ook in de &os.stable;-tak komen, hoeft dit niet per se. In elke beveiligingswaarschuwing voor &os; wordt uitgelegd uit hoe het probleem opgelost kan worden voor de release die het betreft. Dit is niet helemaal waar. Oude releases van &os; kunnen niet eeuwig ondersteund worden, ook al duurt ondersteuning vele jaren. Een volledige beschrijving van het huidige beveiligingsbeleid voor oudere releases van &os; staat op http://www.FreeBSD.org/security/. Het volgen van de volledige ontwikkeltak alleen om veiligheidsredenen levert ongetwijfeld ongewenste wijzigingen op. Ondanks het voornemen ervoor te zorgen dat de &os.stable;-tak compileert en altijd draait, wordt dit niet gegarandeerd. Terwijl code ontwikkeld wordt in &os.current; voordat die in &os.stable; verwerkt wordt, draaien meer mensen &os.stable; dan &os.current;, dus het is onontkoombaar dat bugs en randgevallen soms in &os.stable; gevonden worden die niet in &os.current; bekend waren. Om deze redenen wordt niet aangeraden &os.stable; blindelings te volgen en het is extra belangrijk geen productieservers bij te werken naar &os.stable; zonder de code te testen in een testomgeving. Als de mogelijkheden om dit te doen niet beschikbaar zijn, dan is het advies de meest recente release van &os; te draaien en dan de binaire update methode te hanteren om bij te werken tussen verschillende releases. &os.stable; gebruiken &os.stable; gebruiken Neem een abonnement op de lijst &a.stable.name;. Deze biedt informatie over onderdelen van de build die mogelijk verschijnen in &os.stable; of eventuele andere kwesties die speciale aandacht vereisen. Ontwikkelaars kondigen in deze mailinglijst ook aan wanneer ze overwegen om een controversiële fix of aanpassing willen maken, waardoor de gebruikers een kans hebben om te reageren als ze goede redenen hebben tegen de voorgestelde wijziging. De lijst &a.cvsall.name; biedt informatie over de commitlogregels voor elke wijziging zoals deze gemaakt is tezamen met relevante informatie over mogelijke bijwerkingen. Ga om te abonneren op deze lijsten, of één van de andere beschikbare lijsten naar &a.mailman.lists.link; en klik op de lijst waarop een abonnement gewenst is. Instructies over de rest van de procedure zijn daar beschikbaar. Kijk op de webpagina Snapshots om een systeem te installeren van een maandelijkse snapshot van &os.stable;. Het is ook mogelijk om de meest recente &os.stable; release te installeren van de mirrorsites. Volg de onderstaande instructies om een systeem bij te werken naar de meest recente &os.stable; broncode. Als al een vorige release van &os; draait en bijgewerkt moet worden via de broncodes dan kan dat via de &os; mirrorsites. Dit kan op één van de twee volgende manieren: cvsup cron &os.stable; synchroniseren met CVSup Gebruik het programma cvsup met de supfile stable-supfile uit de map /usr/share/examples/cvsup. Dit is de aanbevolen methode omdat het hiermee mogelijk is de volledige collectie te downloaden en daarna alleen hetgeen wat veranderd is. Veel mensen draaien cvsup vanuit de cron om de broncodes automatisch bij te werken. Het voorbeeld van de supfile dient aangepast en ingesteld te worden voor de omgeving waarin het instellingenbestand gebruikt wordt. &os.stable; synchroniseren met CTM Gebruik CTM als er geen snelle, goedkope verbinding is met internet. Dan is dit de methode om te gebruiken. Als er snelle on-demand toegang nodig is tot de broncode en bandbreedte is geen overweging, gebruik dan cvsup of ftp. Gebruik anders CTM. &os.stable; compileren Lees alvorens &os.stable; te compileren goed de Makefile in /usr/src. Het is handig om de eerste keer op zijn minst de kernel en de wereld opnieuw te bouwen als onderdeel van het updateproces. Via de &a.stable; en /usr/src/UPDATING is het mogelijk op de hoogte te blijven van mogelijke wijzigingen in de opstartprocedures die soms nodig zijn tussen verschillende releases. Broncode synchroniseren Er zijn verschillende manieren om een internet (of e-mail) verbinding te gebruiken om bij te blijven met elk onderdeel van de &os; projectbronnen of alle onderdelen, afhankelijk van het interessegebied. De primaire diensten zijn Anonieme CVS en CTM. Ondanks dat het mogelijk is om alleen delen van de broncode bij te werken, is de enige ondersteunde methode de totale broncode bijwerken en zowel userland (alle programma's die in gebruikersruimte draaien, zoals programma's in /bin en /sbin) als de kernel opnieuw compileren. Als alleen delen van de broncode worden bijgewerkt, alleen de kernel of alleen het userland, resulteert dat vaak in problemen. Deze problemen kunnen verschillen van compileerfouten tot kernel panics of corruptie van gegevens. CVS anoniem Anonieme CVS en CVSup gebruiken het pull model om broncode bij te werken. In het geval van CVSup start de gebruiker (of een cron script) het programma cvsup waarbij het communiceert met een cvsupd server om bestanden bij te werken. De ontvangen updates zijn op de minuut nauwkeurig en ze komen alleen wanneer dat is ingesteld. Updates kunnen eenvoudig beperkt worden tot specifieke bestanden of mappen uit een interessegebied. Updates worden automatisch gegenereerd door een server, aan de hand van wat is ingesteld. Anonieme CVS is veel eenvoudiger dan CVSup omdat dat alleen een uitbreiding is van CVS die de mogelijkheid biedt om wijzigingen direct van een CVS repository op afstand te halen. CVSup kan dit veel efficiënter doen, maar anonieme CVS is makkelijker in het gebruik. CTM CTM aan de andere kant maakt geen vergelijking tussen de aanwezige bronnen en die op de master server. In plaats daarvan wordt een script uitgevoerd dat wijzigingen in bestanden ziet sinds de vorige keer dat is bijgewerkt en die meerdere keren per dag worden uitgevoerd op de master CTM machine. Elke ontdekte wijziging wordt gecomprimeerd, krijgt een volgnummer toegekend en wordt gecodeerd voor verzending via e-mail (in leesbare ASCII). Deze CTM delta's kunnen dan aangeleverd worden aan &man.ctm.rmail.1; die ze automatisch decodeert, controleert en toepast in de gebruikerskopie van de bronnen. Dit proces is veel efficiënter dan CVSup en claimt minder systeembronnen omdat het model push in plaats van pull is. Er zijn andere nadelen. Als per ongeluk een deel van het archief wordt verwijderd, kan CVSup dat detecteren en het beschadigde deel repareren. CTM doet dit niet en als een deel van de broncode wordt verwijderd (en er geen backup is), dan moet er opnieuw begonnen worden (vanaf de meest recente CVS base delta en moet alles opnieuw opgebouwd worden met CTM. Met Anonymous CVS kan simpelweg het slechte deel verwijderd worden alvorens weer te synchroniseren. De <quote>wereld</quote> opnieuw bouwen world opnieuw bouwen Zodra de lokale broncode gesynchroniseerd is met een bepaalde versie van &os; (&os.stable;, &os.current;, enzovoort) kan de broncode gebruikt worden om een systeem te herbouwen. Maak een backup Het kan niet vaak genoeg verteld worden hoe belangrijk het is om een backup te maken van een systeem vóór deze taak uit te voeren. Ook al is het opnieuw bouwen van de wereld vrij simpel (als deze instructies gevolgd worden), er worden ongetwijfeld ooit fouten gemaakt, misschien zelfs in de broncode, die het onmogelijk maken om een systeem op te starten. Wees ervan verzekerd dat er een backup gemaakt is en dat er een reparatiediskette of cd-rom bij de hand is. Deze wordt waarschijnlijk nooit gebruikt maar better safe than sorry. Abonneer op de juiste mailinglijsten mailinglijst De &os.stable; en &os.current; takken zijn van nature in ontwikkeling. Mensen die bijdragen aan &os; zijn menselijk en foutjes ontstaan regelmatig. Soms zijn deze foutjes onschadelijk, ze geven dan hooguit een nieuwe diagnostische waarschuwing weer. Maar de wijziging kan ook catastrofaal zijn en ervoor zorgen dat een systeem niet meer opstart of bestandssystemen vernietigt (of erger). Als problemen zoals deze voorkomen wordt er een heads up naar de juiste mailinglijst gestuurd, waarin uitgelegd wordt wat het probleem is en welke systemen het raakt. Er wordt een all clear bericht gestuurd als het probleem is opgelost. &os.stable; of &os.current; volgen zonder de &a.stable; of &a.current; te volgen is vragen om problemen. Gebruik geen <command>make world</command> Veel oudere documentatie raadt aan om make world te gebruiken. In dat geval worden er belangrijke stappen overgeslagen en gebruik het commando alleen als er voldoende kennis over aanwezig is. In bijna alle omstandigheden is make world verkeerd en de procedure die hier beschreven is hoort in plaats daarvan gebruikt te worden. De universele wijze om een systeem bij te werken Een systeem bijwerken kan met de volgende procedure, nadat /usr/src/UPDATING is geraadpleegd om te controleren of er voor buildworld voor de gebruikte versie van de broncode nog acties zijn uit te voeren: &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; reboot Er zijn een aantal zeldzame gevallen waarin mergemaster -p nog een keer moet draaien voor de stap met buildworld. Deze staan beschreven in UPDATING. In het algemeen kan deze stap echter zonder risico worden overgeslagen als er niet tussen een of meer hoofdversies wordt bijgewerkt. Nadat installkernel succesvol is afgerond, dient er in single-user modus opgestart te worden (met boot -s vanaf de loaderprompt). Draai dan: &prompt.root; mergemaster -p &prompt.root; make installworld &prompt.root; mergemaster &prompt.root; reboot Lees verdere uitleg De hierboven beschreven volgorde is alleen een korte samenvatting. Ook de volgende secties lezen geeft een beter beeld van elke stap, met name als er een op maat gemaakte kernelinstelling wordt gebruikt. <filename>/usr/src/UPDATING</filename> lezen Lees voor verder te gaan /usr/src/UPDATING (of het gelijknamige bestand waar de kopie van de broncode ook staat). Dit bestand kan belangrijke informatie bevatten over mogelijke problemen of specificeert de volgorde waarin bepaalde commando's gestart moeten worden. Als UPDATING tegenstrijdig is met wat hier wordt beschreven, heeft UPDATING voorrang. UPDATING lezen is geen acceptabele vervanging voor het abonneren op de correcte mailinglijst zoals eerder beschreven. De twee vullen elkaar aan en zijn niet exclusief. <filename>/etc/make.conf</filename> controleren make.conf Controleer /usr/share/examples/etc/make.conf - (/etc/defaults/make.conf in - &os; 4.X) en /etc/make.conf. Het + en /etc/make.conf. Het eerste bestand bevat standaard definities, waarvan de meeste uitgecommentarieerd zijn. Om hiervan gebruik te maken als het systeem opnieuw opgebouwd wordt vanuit de broncode, moeten ze toegevoegd worden aan /etc/make.conf. Bedenk dat alles wat toegevoegd wordt aan /etc/make.conf ook gebruikt wordt bij elk make commando. Het is dus verstandig om daar redelijke waardes in te vullen voor een systeem. Een typische gebruiker wil waarschijnlijk de regels - CFLAGS en NO_PROFILE (of - NOPROFILE in &os; 5.X en ouder) uit + CFLAGS en NO_PROFILE uit /usr/share/examples/etc/make.conf - (/etc/defaults/make.conf in &os; 4.X) kopieren naar /etc/make.conf en het commentaar verwijderen. Bekijk de andere definities (COPTFLAGS, NOPORTDOCS, enzovoort) en bepaal of deze relevant zijn. <filename>/etc</filename> bijwerken De map /etc bevat een groot deel van de systeeminstellingen en scripts die gestart worden tijdens de systeemstart. Sommige van deze scripts verschillen van versie tot versie in &os;. Sommige van de instellingenbestanden worden dagelijks gebruikt voor het draaien van een systeem. In het bijzonder /etc/group. Er zijn gevallen geweest waarbij het installatiegedeelte van make installworld een aantal gebruikersnamen of groepen verwachtte. Als er een upgrade wordt uitgevoerd is het waarschijnlijk dat deze gebruikers of groepen niet bestaan. Dit levert problemen op bij upgraden. In sommige gevallen controleert make buildworld of deze gebruikers of groepen bestaan. Een voorbeeld hiervan is het toevoegen van de gebruiker smmsp. Gebruikers hadden een falend installatieproces toen &man.mtree.8; probeerde om /var/spool/clientmqueue te creëren. - De oplossing is om /usr/src/etc/group - te controleren en de lijst met groepen te vergelijken met die - van het bij te werken systeem. Als daar groepen bestaan die - nog niet op een systeem staan, moeten deze worden gekopieerd. - Hetzelfde geldt voor het hernoemen van groepen in - /etc/group die hetzelfde GID hebben maar - een andere naam dan in - /usr/src/etc/group. - &man.mergemaster.8; kan in voorbereidende modus gedraaid worden als de optie wordt meegegeven. Dan worden alleen de bestanden vergeleken die essentieel zijn voor het succes van buildworld of installworld: &prompt.root; cd /usr/src/usr.sbin/mergemaster &prompt.root; ./mergemaster.sh -p In paranoide beheerdersmodus kan er gecontroleerd worden welke bestanden op een systeem eigendom zijn van de groep die wordt hernoemd of verwijderd: &prompt.root; find / -group GID -print Dit commando toont alle bestanden die eigendom zijn van de groep GID (een groepsnaam of een numeriek groeps-ID). Systeem naar single-user modus brengen single-user modus Het kan zijn dat een systeem in single-user modus gecompileerd moet worden. Buiten het duidelijke voordeel dat de operatie iets sneller verloopt, is het voordeel dat bij een herinstallatie van een systeem een aantal belangrijke systeembestanden waaronder binaire systeembestanden, bibliotheken, include bestanden, enzovoort, worden aangepast, iets wat op een actief systeem vragen om problemen is (zeker als er actieve gebruikers op een systeem aanwezig zijn). multi-user modus Een andere methode is het systeem compileren in multi-user modus en daarna naar single-user modus gaan voor de installatie. Bij deze methode moeten de volgende stappen gevolgd worden. Het overschakelen naar single-user modus kan uitgesteld worden tot en met installkernel of installworld. Een supergebruiker kan als volgt een draaiend systeem naar single-user modus overgeschakelen: &prompt.root; shutdown now Als alternatief kan tijdens het opstarten de optie - worden meegegeven. Het systeem start dan + worden gekozen. Het systeem start dan in single-user modus. Op de shell prompt moet dan worden ingegeven: &prompt.root; fsck -p &prompt.root; mount -u / &prompt.root; mount -a -t ufs &prompt.root; swapon -a Hierdoor worden de bestandssystemen gecontroleerd, / met lees en schrijf rechten opnieuw gemount, worden alle andere UFS bestandssystemen die in /etc/fstab staan gemount en wordt swap ingeschakeld. Als de CMOS-klok ingesteld is naar de lokale tijd en niet naar GMT (dit is waar als het resultaat van &man.date.1; niet de correcte tijd en zone weergeeft), dan is het misschien handig om het volgende commando te starten: &prompt.root; adjkerntz -i Dit zorgt ervoor dat de lokale tijdzoneinstellingen correct ingesteld worden. Zonder deze instelling kunnen er later problemen ontstaan. <filename>/usr/obj</filename> verwijderen Als delen van een systeem opnieuw gebouwd worden, worden ze standaard geplaatst in mappen onder /usr/obj. Deze mappen schaduwen de mappen onder /usr/src. Het proces make buildworld kan versneld worden en problemen met afhankelijkheden kunnen voorkomen worden als deze map wordt verwijderd. Sommige bestanden onder /usr/obj hebben mogelijk de optie niet aanpassen ingesteld (zie &man.chflags.1;) die eerst verwijderd moet worden: &prompt.root; cd /usr/obj &prompt.root; chflags -R noschg * &prompt.root; rm -rf * - - Broncode hercompileren + + Broncode van het basis systeem hercompileren Uitvoer bewaren Het is een goed idee om de uitvoer van &man.make.1; te bewaren in een ander bestand. Als er iets misgaat is er een kopie van de foutmelding aanwezig. Hoewel dit misschien niet helpt in de diagnose van wat er fout is gegaan, kan het anderen helpen als het probleem wordt aangegeven in een &os; mailinglijst. De makkelijkste manier om dit te doen is door het commando &man.script.1; te gebruiken, met een parameter die de naam specificeert waar de uitvoer naartoe moet. Dit moet direct gedaan worden vóór het herbouwen van de wereld, zodat het proces klaar is moet exit worden ingegeven: &prompt.root; script /var/tmp/mw.out Script started, output file is /var/tmp/mw.out &prompt.root; make TARGET … compile, compile, compile … &prompt.root; exit Script done, … Bewaar de uitvoer in deze stap niet in /tmp. Deze map wordt mogelijk opgeschoond tijdens de volgende herstart. Een betere plaats om dit bestand te bewaren is de map /var/tmp (zoals in het vorige voorbeeld) of in de thuismap van root. Basissysteem compileren Ga naar de map /usr/src, tenzij de broncode ergens anders staat, in welk geval naar die map gegaan moet worden: &prompt.root; cd /usr/src make Om de wereld opnieuw te bouwen moet het commando &man.make.1; gebruikt worden. Dit commando leest zijn instructies uit het bestand Makefile, dat beschrijft hoe de programma's die samen &os; vormen moeten worden gebouwd, in welke volgorde ze gebouwd moeten worden, enzovoort. Het algemene formaat van de commandoregel die gebruikt moet worden is als volgt: &prompt.root; make -x -DVARIABELE doel In dit voorbeeld is de optie een optie die wordt meegegeven aan &man.make.1;. In de hulppagina voor &man.make.1; staat een voorbeeld van de opties die meegegeven kunnen worden. geeft een variabele door aan Makefile. Het gedrag van Makefile wordt beïnvloed door deze variabele. Dit zijn dezelfde variabelen die ingesteld worden in /etc/make.conf. Deze optie biedt een alternatief om deze opties in te stellen. &prompt.root; make -DNO_PROFILE doel Het bovenstaande commando is een andere manier om aan te geven dat geprofileerde bibliotheken niet gebouwd moeten worden en correspondeert met de onderstaande regel in /etc/make.conf: NO_PROFILE= true # Avoid compiling profiled libraries doel geeft &man.make.1; aan wat er gedaan moet worden. Elke Makefile definieert een aantal van verschillende doelen en het gekozen doel bepaalt wat er gebeurt. Sommige doelen staan vermeld in het bestand Makefile, maar zijn niet geschikt om direct te starten. Integendeel, deze worden gebruikt door het bouwproces om de benodigde stappen onder te verdelen. In veel gevallen hoeven er geen parameters te worden meegegeven aan &man.make.1; en dus ziet de commando regel er als volgt uit: &prompt.root; make doel - Het world doel is opgesplitst in - twee delen: buildworld en - installworld. Vanaf versie - 5.3 van &os; verandert world - dusdanig dat het helemaal niet meer werkt omdat het - gevaarlijk is voor de meeste gebruikers. + Waar doel een van de vele + bouw opties is. De eerste target moet echter altijd + buildworld zijn. Zoals de namen impliceren bouwt buildworld een compleet nieuwe boom onder /usr/obj en - installworld installeert deze boom - op de huidige machine. + installworld, een andere target, + installeert deze boom op de huidige machine. - Dit is erg handig om twee redenen. Als eerste biedt het + Het hebben van verschillende opties is handig om twee + redenen. Als eerste biedt het de mogelijkheid om de bouw veilig te doen met de wetenschap dat geen enkel draaiend onderdeel van een systeem geraakt wordt. De bouw is zelf ondersteunend. Hierdoor kan veilig in multi-user modus buildworld gedraaid worden. Het wordt echter nog steeds aangeraden om installworld in single-user modus te starten. Ten tweede geeft het de mogelijkheid om NFS-mounts te gebruiken om meerdere machines in het netwerk bij te werken. Als er drie machines zijn, A, B en C, die bijgewerkt moeten worden, dan kunnen make buildworld en make installworld gedraaid worden op A waarna B en C een NFS-mount kunnen opzetten naar /usr/src en /usr/obj op machine A waarna make installworld gedraaid kan worden op B en C om de resultaten de installeren. Alhoewel het doel world nog wel bestaat wordt het gebruik ervan sterk afgeraden. Voer het volgende commando uit: &prompt.root; make buildworld - Het is nu mogelijk om de optie mee te + Het is mogelijk om de optie mee te geven aan make, wat resulteert in meerdere processen die tegelijkertijd draaien. Dit heeft het meeste effect op machines met meerdere processoren. Echter, omdat het compilatieproces meer IO-gericht is dan processorgericht, kan het ook nuttig zijn op systemen met één processor. Start als volgt op een systeem met één processor: &prompt.root; make -j4 buildworld &man.make.1; draait dan maximaal 4 processen tegelijkertijd. In het algemeen blijkt uit de mailinglijsten dat dit de beste resultaten geeft. Als er meerdere processoren in een systeem zitten en gebruik gemaakt wordt van een SMP kernel, probeer dan waardes tussen de 6 en 10 en bekijk hoe het systeem reageert. - - Deze mogelijkheid is nog steeds fragiel en commits in de - broncode verbreken deze mogelijkheid vaak. Als het opnieuw - bouwen van de wereld mislukt, probeer dan nogmaals te - compileren zonder deze opties alvorens een probleemrapport - aan te maken. Doorlooptijd world opnieuw bouwen doorlooptijd - De doorlooptijd wordt door veel factoren beïnvloed. - Een 500 MHz &pentium; III met 128 MB ram doet - er ongeveer 2 uur over om de &os.stable; boom te bouwen + Veel factoren bepalen de doorlooptijd van het bouwen van + een boom, maar redelijk recente machines doen er maar 1 tot + 2 uur over om de &os.stable; boom te bouwen. zonder extra trucjes. Een &os.current; boom kan wat langer duren. Nieuwe kernel compileren en installeren kernel compileren Om volledig gebruik te maken van het nieuwe systeem moet de kernel opnieuw gecompileerd worden. Dit is bijna altijd nodig omdat sommige geheugenstructuren mogelijkerwijs veranderd zijn en programma's als &man.ps.1; en &man.top.1; niet werken totdat de kernel en de broncode dezelfde versie hebben. De simpelste en makkelijkste manier om dit te doen is om een kernel te maken die gebaseerd is op GENERIC. Ondanks dat GENERIC mogelijk niet alle benodigde apparaten heeft voor een systeem, hoort het alles te bevatten dat nodig is om een systeem te starten in single-user modus. Dit is een goede test op de correcte werking van een nieuw systeem. Na het opstarten van GENERIC en een systeemcontrole kan erna een nieuwe kernel gebouwd worden gebaseerd op een aangepast kernelinstellingenbestand. - Op moderne versies van &os; is het belangrijk om de + Op &os; is het belangrijk om de wereld opnieuw te bouwen voordat een nieuwe kernel gebouwd wordt. Als een aangepaste kernel gemaakt moet worden en er reeds een instellingenbestand aanwezig is, gebruik dan KERNCONF=MYKERNEL als volgt: &prompt.root; cd /usr/src &prompt.root; make buildkernel KERNCONF=MYKERNEL &prompt.root; make installkernel KERNCONF=MYKERNEL Let op dat als kern.securelevel een waarde hoger dan 1 heeft of noschg of gelijksoortige opties geplaatst zijn op het binaire kernelbestand, is het misschien nodig om terug te gaan naar single-user modus om installkernel uit te voeren. In andere gevallen moet het mogelijk zijn om deze commando's zonder problemen uit te voeren in multi-user modus. Zie &man.init.8; voor meer informatie over kern.securelevel en &man.chflags.1; voor informatie over diverse bestandsopties. Opnieuw opstarten in single-user modus single-user modus Start met de instructies in in single-user modus op om te testen of de nieuwe kernel werkt. Nieuwe binaire systeembestanden installeren Na het draaien van make buildworld kan nu installworld gebruikt worden om de nieuwe binaire systeembestanden te installeren. Voer de volgende commando's uit: &prompt.root; cd /usr/src &prompt.root; make installworld Als er variabelen gespecificeerd zijn op de commandoregel van make buildworld moeten dezelfde variabelen gebruikt worden op de commandoregel van make installworld. Dit is niet per se waar voor opties zoals , die nooit gebruikt mogen worden met installworld. Als bijvoorbeeld het volgende commando is uitgevoerd: &prompt.root; make -DNO_PROFILE buildworld Dan moet het resultaat geïnstalleerd worden met: &prompt.root; make -DNO_PROFILE installworld Anders wordt geprobeerd geprofileerde bibliotheken te installeren die niet gebouwd zijn tijdens de fase make buildworld. - + Bestanden bijwerken die niet bijgewerkt zijn door <command>make installworld</command> Het herbouwen van de wereld werkt bepaalde mappen niet bij (in het bijzonder /etc, /var en /usr) met nieuwe of gewijzigde instellingenbestanden. De simpelste manier om deze bestanden bij te werken is door &man.mergemaster.8; te gebruiken, maar het is ook mogelijk dit handmatig te doen. Welke manier er ook gekozen wordt, zorg er altijd voor dat een backup van /etc beschikbaar is voor het geval er iets misgaat. Tom Rhodes Bijgedragen door <command>mergemaster</command> mergemaster Het hulpprogramma &man.mergemaster.8; is een Bourne script dat helpt bij het bepalen van de verschillen tussen de instellingenbestanden in /etc en de instellingenbestanden in de broncodeboom /usr/src/etc. Deze methode wordt aangeraden om instellingenbestanden van een systeem bijgewerkt te houden met de bestanden die in de broncodeboom staan. Het programma wordt gestart met mergemaster op de commandoregel en geeft dan resultaten weer. mergemaster bouwt dan een tijdelijke root omgeving vanaf / en vult deze met diverse instellingenbestanden voor een systeem. Deze bestanden worden vergeleken met de bestanden die geïnstalleerd zijn op een systeem. Op dit punt worden de bestanden getoond die verschillen in het &man.diff.1;-formaat, met een voor toegevoegde of gewijzigde regels en een voor regels die verwijderd of vervangen zijn. In de hulppagina voor &man.diff.1; staat meer informatie over de syntaxis van &man.diff.1; en hoe bestandsverschillen getoond worden. &man.mergemaster.8; toont dan elk bestand dat verschilt en op dit moment is er de mogelijkheid om of het nieuwe bestand te verwijderen (ofwel het tijdelijke bestand), het tijdelijke bestand te installeren zonder enige wijzigingen, het verwerken van het oude bestand in het nieuwe bestand of de resultaten van &man.diff.1; nogmaals te tonen. Als gekozen wordt om het tijdelijke bestand te verwijderen, geeft dit &man.mergemaster.8; aan dat het huidige bestand niet gewijzigd dient te worden en de nieuwe versie verwijderd kan worden. Deze optie wordt niet aangeraden, behalve als er geen reden is om het huidige bestand aan te passen. Op ieder moment kunnen hulpteksten getoond worden door ? in te geven op de prompt van &man.mergemaster.8;. Als een bestand wordt overgeslagen, dan wordt het weer getoond als alle overige bestanden verwerkt zijn. Bij de keuze om het ongewijzigde tijdelijke bestand te installeren wordt het huidige bestand vervangen door het nieuwe. Voor de meeste ongewijzigde bestanden is dit de beste optie. Als ervoor gekozen wordt om de wijzigingen te verwerken wordt er een tekstverwerker gestart die de inhoud van beide bestanden toont. De verschillen kunnen verwerkt worden terwijl beide bestanden naast elkaar op het scherm staan. Hier kunnen delen gekozen worden die gezamenlijk een nieuw bestand opleveren. Als de bestanden zij aan zij vergeleken worden, wordt met de toets l de inhoud links geselecteerd en met de toets r de inhoud rechts geselecteerd. Het eindresultaat bestaat uit delen van beide bestanden die erna geinstalleerd kunnen worden. Deze optie wordt voornamelijk gebruikt voor bestanden die gewijzigd zijn door de beheerder. Als ervoor gekozen wordt om de &man.diff.1; resultaten nog een keer te tonen, worden dezelfde verschillen getoond zoals &man.mergemaster.8; deed voordat een optie gevraagd werd. Zodra &man.mergemaster.8; klaar is met de systeembestanden worden er andere opties getoond. &man.mergemaster.8; kan - vragen of het wachtwoordbestand opnieuw gebouwd moet worden - en/of &man.MAKEDEV.8; gestart moet worden als er een versie van - &os; voor 5.0 draait. Als laatste wordt een optie getoond om + vragen of het wachtwoordbestand opnieuw gebouwd moet worden. + Als laatste wordt een optie getoond om alle overgebleven tijdelijke bestanden te verwijderen. Handmatig bijwerken Bij handmatig bijwerken kunnen de bestanden van /usr/src/etc niet zomaar naar /etc gekopieerd worden om een werkend systeem te krijgen. Sommige van deze bestanden moeten eerst geïnstalleerd worden. Dit omdat de map /usr/src/etc geen kopie is van /etc. Daarnaast staan er in /etc bestanden die niet in /usr/src/etc staan. Als &man.mergemaster.8; gebruikt wordt (zoals aangeraden), kan doorgegaan worden met het volgende onderdeel. + linkend="cutting-edge-rebooting">volgende onderdeel. De simpelste manier om met de hand bij te werken, is de bestanden in een nieuwe map installeren en daarna naar verschillen tussen de bestanden te zoeken. Backup maken van <filename>/etc</filename> Ondanks dat, in theorie, niets in deze map automatisch wordt aangepast, is het altijd beter om daar zeker van te zijn. Dus kopieer de bestaande /etc naar een veilige locatie. Zoals bijvoorbeeld met het volgende commando: &prompt.root; cp -Rp /etc /etc.old maakt een recursieve kopie, bewaart tijden, eigenaarschap, enzovoort op bestanden. Er moet een dummyset van mappen gemaakt worden om de nieuwe /etc en andere bestanden in te installeren. /var/tmp/root is een redelijke keuze en er zijn hier een aantal benodigde submappen aanwezig: &prompt.root; mkdir /var/tmp/root &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root distrib-dirs distribution Dit maakt de benodigde mappenstructuur en installeert de bestanden. Een groot deel van de submappen die gemaakt zijn in /var/tmp/root zijn leeg en moeten verwijderd worden. De simpelste manier om dit te doen is: &prompt.root; cd /var/tmp/root &prompt.root; find -d . -type d | xargs rmdir 2>/dev/null Dit verwijderd alle lege mappen. De standaardfout wordt omgeleid naar /dev/null om waarschuwingen te voorkomen over mappen die niet leeg zijn. /var/tmp/root bevat nu alle bestanden die geplaatst zouden moeten worden op de juiste locaties in /. Er moet nu in de bestanden gekeken worden om te bepalen of deze verschillen met de huidige betanden. Let op dat sommige van de bestanden die geïnstalleerd zijn in /var/tmp/root beginnen met een .. Op het moment van schrijven hebben alleen shell opstartscripts in /var/tmp/root en /var/tmp/root/root dit, maar er kunnen ook andere zijn. Zorg ervoor dat ls -a gebruikt wordt om deze bestanden te zien. De simpelste manier om twee bestanden te vergelijken is &man.diff.1; gebruiken: &prompt.root; diff /etc/shells /var/tmp/root/etc/shells Dit toont de verschillen tussen de huidige /etc/shells en de nieuwe /var/tmp/root/etc/shells. Gebruik dit om te bepalen of de wijzigingen gemigreerd moeten worden of dat het oude bestand gekopieërd moet worden. Voeg aan de naam van de nieuwe rootmap (<filename>/var/tmp/root</filename>) een tijdsindicatie toe zodat makkelijk verschillen tussen versies bepaald kunnen worden Als de wereld regelmatig wordt herbouwd moeten bestanden in /etc ook regelmatig bijgewerkt moeten worden, wat een vervelend werkje kan zijn. Dit proces kan versneld worden door een kopie te bewaren van de bestanden die gemigreerd zijn naar /etc. De volgende procedure geeft een idee over hoe dit gedaan kan worden. Maak de wereld zoals normaal. Als /etc en de andere mappen bijgewerkt moeten worden, geef dan de doelmap een naam gebaseerd op de huidige datum. Op 14 februari 1998 wordt dat als volgt gedaan: &prompt.root; mkdir /var/tmp/root-19980214 &prompt.root; cd /usr/src/etc &prompt.root; make DESTDIR=/var/tmp/root-19980214 \ distrib-dirs distribution Migreer de wijzigingen van deze map zoals hierboven beschreven. Verwijder de map /var/tmp/root-19980214 niet na afronden. Als de laatste versie van de broncode gedownload en opnieuw gemaakt is, volg stap 1. Dit geeft een nieuwe map die wellicht /var/tmp/root-19980221 heet (als er een week zit tussen het bijwerken). De verschillen die gemaakt zijn in de tussenliggende week kunnen nu getoond worden door met &man.diff.1; een recursieve diff te maken tussen de twee mappen: &prompt.root; cd /var/tmp &prompt.root; diff -r root-19980214 root-19980221 Vaak is dit een kleinere set aan verschillen dan tussen /var/tmp/root-19980221/etc en /etc. Omdat de set verschillen kleiner is, is het makkelijker om deze te migreren naar de map /etc. De oudste van de twee /var/tmp/root-*-mappen kan nu verwijderd worden: &prompt.root; rm -rf /var/tmp/root-19980214 Herhaal dit proces elke keer als er wijzigingen gemigreerd moeten worden naar /etc. Met &man.date.1; kan het maken van de mappen geautomatiseerd worden: &prompt.root; mkdir /var/tmp/root-`date "+%Y%m%d"` - - <filename>/dev</filename> bijwerken - - - DEVFS - - Als &os; 5.0 of later wordt gebruikt kan deze sectie - veilig overgeslagen worden. Deze versies gebruiken - &man.devfs.5; om apparaatnodes transparant aan te maken voor - gebruikers. - - - In veel gevallen herkent &man.mergemaster.8; dat het nodig - is om apparaatnodes bij te werken en aan te bieden en doet dat - automatisch. Hieronder wordt beschreven hoe apparaatnodes - handmatig bijgewerkt kunnen worden. - - Om veiligheidsredenen bestaat dit proces uit meerdere - stappen. - - - - Kopieer /var/tmp/root/dev/MAKEDEV - naar /dev: - - &prompt.root; cp /var/tmp/root/dev/MAKEDEV /dev - - MAKEDEV - - Als &man.mergemaster.8; is gebruikt om - /etc bij te werken is het script - MAKEDEV al aangepast. Het kan echter - geen kwaad om dit te controleren (met &man.diff.1;) en het - script indien nodig handmatig te kopieren. - - - - Maak een afdruk van de huidige - /dev. Deze snapshot moet de - permissies, eigenaarschappen, grote en kleine nummers van - ieder bestand bevatten, maar niet de timestamps. De - makkelijkste manier om dit te doen is door &man.awk.1; te - gebruiken om er informatie uit te halen: - - &prompt.root; cd /dev -&prompt.root; ls -l | awk '{print $1, $2, $3, $4, $5, $6, $NF}' > /var/tmp/dev.out - - - - Creeër alle apparaatnodes opnieuw: - - &prompt.root; sh MAKEDEV all - - - - Maak een tweede afdruk van de map, deze keer naar - /var/tmp/dev2.out. Bekijk nu door de - twee bestanden te vergelijken of er apparaatnodes niet zijn - aangemaakt. Dit hoort niet voor te komen, maar het kan - maar beter gecontroleerd zijn. - - &prompt.root; diff /var/tmp/dev.out /var/tmp/dev2.out - - Als er verschillen zijn is het waarschijnlijk dat deze - in diskslices zitten. Om deze apparaatnodes opnieuw aan te - maken kan iets als het onderstaande commando gebruikt - worden: - - &prompt.root; sh MAKEDEV sd0s1 - - De precieze afwijkingen kunnen variëren. - - - - - - <filename>/stand</filename> bijwerken - - - Deze stap is opgenomen om het proces compleet te maken. - Hij kan zonder problemen overgeslagen worden. Als - &os; 5.2 of later wordt gebruikt, wordt de map - /rescue automatisch bijgewerkt met de - nieuwste, statisch gecompileerde binaire bestanden tijdens - make installworld, waardoor het overbodig - wordt om /stand bij te werken (bestaat - helemaal niet in &os; 6.0 en later). - - - Volledigheidshalve is het misschien wenselijk de bestanden - in de map /stand bij te werken. Deze - bestanden bestaan uit harde links naar het binaire bestand - /stand/sysinstall. Dit bestand moet - statisch gelinkt zijn zodat het zonder tussenkomst van andere - bestandssystemen kan werken (in het bijzonder - /usr). - - &prompt.root; cd /usr/src/release/sysinstall -&prompt.root; make all install - - - + Herstarten Dit was het. Na een controle of alles op de juiste plaats staat kan het systeem herstart worden. Dan kan met een simpele &man.shutdown.8;: &prompt.root; shutdown -r now Klaar Het &os; systeem is nu succesvol bijgewerkt. Gefeliciteerd! Als er dingen misgingen is het makkelijk om een deel van het systeem opnieuw te bouwen. Als bijvoorbeeld per ongeluk /etc/magic verwijderd is als onderdeel van de upgrade of door een merge van /etc, dan werkt &man.file.1; niet meer. Dat kan als volgt opgelost worden: &prompt.root; cd /usr/src/usr.bin/file &prompt.root; make all install Vragen Moet de wereld opnieuw gemaakt worden voor elke wijziging? Op deze vraag bestaat geen eenvoudig antwoord, omdat dit afhangt van de aard van de wijziging. Als bijvoorbeeld net CVSup is gedraaid en de onderstaande bestanden zijn bijgewerkt, dan is het waarschijnlijk niet de moeite waard om de volledige wereld te herbouwen: 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 Dan is het handiger om naar de juiste submappen te gaan, daar make all install uit te voeren en dat is het zo'n beetje. Maar als er iets wezenlijks is veranderd, bijvoorbeeld src/lib/libc/stdlib, dan dient ofwel de wereld herbouwd te worden of tenminste die delen die statisch gelinkt zijn (en ook al het andere dat statisch gelinkt is en onderdeel is van een systeem). Uiteindelijk beslist een beheerder zelf. Misschien vindt die het prettig iedere twee weken de wereld te herbouwen terwijl de wijzigingen in die twee weken binnenkomen. Een andere beheerder herbouwt alleen die onderdelen die veranderd zijn en vertrouwt erop dat hij alle afhankelijkheden in de gaten heeft. Natuurlijk hangt het ook af van de keuze hoe vaak het wenselijk is bij te werken en of &os.stable; of &os.current; wordt bijgehouden. Het compileren gaat fout met veel meldingen van signal 11 (of andere signalnummers). Wat is er aan de hand? signal 11 Dit wijst meestal op hardwareproblemen. Het (her)bouwen van de wereld is een prima manier om een stresstest op hardware uit te voeren en hierdoor komen vaak geheugenproblemen bovendrijven. Die resulteren vaak in een compiler die op mysterieuze wijze overlijdt na het ontvangen van vreemde signalen. Dit probleem is nog duidelijker als na het herstarten van de make het proces opnieuw stopt op een ander punt. Hier biedt niets anders uitkomst dan componenten in een systeem wisselen om uit te zoeken welk component er faalt. Kan /usr/obj verwijderd worden na afloop? Het korte antwoord is ja. /usr/obj bevat alle objectbestanden die tijdens het compileren zijn gemaakt. Normaliter is een van de eerste stappen in het make buildworld proces deze map verwijderen en een verse start maken. In dit geval heeft het behouden van /usr/obj na het afronden weinig zin en geeft het ook nogal wat extra vrije schijfruimte (ongeveer 340 MB). Als er veel kennis aanwezig is bij een beheerder, dan kan make buildworld aangegeven worden deze stap over te slaan. Hierdoor draaien volgende builds veel sneller, omdat veel broncode niet opnieuw gecompileerd hoeft te worden. De andere kant van de medaille is dat er subtiele afhankelijkheidsproblemen kunnen ontstaan, waardoor een build op bijzondere wijze kan falen. Hierdoor onstaat regelmatig ruis op &os; mailinglijsten als er iemand klaagt dat zijn build faalt, terwijl hij zich niet realiseert dat dit komt doordat hij zijn updateproces niet volgens het boekje heeft uitgevoerd. Kunnen onderbroken builds gecontinueerd worden? Dit hangt af van hoever een systeem was voordat een probleem gevonden werd. Normaal gesproken (en dit is geen vaste regel) maakt het proces make buildworld nieuwe kopieën van essentiele hulpprogramma's (zoals &man.gcc.1; en &man.make.1;) en de systeembibliotheken. Deze hulpprogramma's en bibliotheken worden daarna geïnstalleerd. De nieuwe hulpprogramma's en bibliotheken worden daarna gebruikt om zichzelf opnieuw op te bouwen en wederom te installeren. Het complete systeem (nu met gewone programma's zoals &man.ls.1; en &man.grep.1;) wordt daarna opnieuw gebouwd met de nieuwe systeembestanden. Als een systeem in de laatste fase zit (wat uit de uitvoer blijkt) kan dit redelijk veilig gedaan worden: … fix the problem … &prompt.root; cd /usr/src &prompt.root; make -DNO_CLEAN all - - Gebruik in &os; 5.X en ouder - -DNOCLEAN. - - Dit maakt het werk van de vorige make buildworld niet ongedaan. Als het onderstaande bericht in de uitvoer van make buildworld staat, dan is het redelijk veilig om het te doen: -------------------------------------------------------------- Building everything.. -------------------------------------------------------------- Als dat bericht er niet is, of er is onzekerheid over, dan is het altijd beter om de build opnieuw te starten vanaf het begin. Kan kan de wereld bouwen versneld worden? Draai in single-user modus; Zet de mappen /usr/src en /usr/obj op aparte bestandssystemen die op aparte schijven staan. Hang deze schijven als mogelijk aan aparte schijfcontrollers; Nog beter, verspreid de bestandssystemen over meerdere schijven via het apparaat &man.ccd.4; (concatenated disk driver); Zet profiling uit (voeg NO_PROFILE=true toe aan /etc/make.conf). Het is zeer waarschijnlijk niet nodig; Voer ook CFLAGS toe aan /etc/make.conf met iets als . De optimalisatie is veel langzamer en het optimalisatieverschil tussen en is meestal verwaarloosbaar. laat de compiler gebruik maken van pipes in plaats van tijdelijke bestanden voor communicatie, wat schijfacties scheelt (ten koste van geheugengebruik); Geef de optie mee aan &man.make.1; om meerdere processen parallel te laten lopen. Dit helpt in de meeste gevallen, onafhankelijk of er gewerkt wordt op een systeem met één of meerdere processoren; Het bestandssysteem dat /usr/src bevat, kan (opnieuw) gemount worden met de optie . Dit voorkomt dat het bestandssysteem de toegangsmomenten registreert. Deze informatie is waarschijnlijk toch niet nodig. &prompt.root; mount -u -o noatime /usr/src In dit voorbeeld wordt aangenomen dat /usr/src op zijn eigen bestandssysteem staat. Als dit niet het geval is (bijvoorbeeld als het onderdeel is van /usr), dan moet het mountpunt voor dat bestandssysteem gebruikt moeten worden en niet /usr/src; Het bestandssysteem dat /usr/obj gevat kan (opnieuw) worden gemount met de optie . Dit zorgt ervoor dat schrijfacties naar een schijf asynchroon plaatsvinden. In andere woorden: de schrijfactie wordt direct uitgevoerd en de gegevens worden later naar de schijf geschreven. Dit stelt het systeem in staat om data geclusterd weg te schrijven, wat een grote prestatieverbetering kan opleveren. Houd er rekening mee dat deze optie het bestandssysteem kwetsbaarder maakt. Met deze optie is er een vergrote kans dat, indien er een stroomstoring optreed, het bestandssysteem in een niet meer te herstellen staat komt als de machine herstart. Als op dit bestandssysteem alleen /usr/obj staat, is dit geen probleem. Als er andere belangrijke gegevens op hetzelfde bestandssysteem staan, zorg er dan voor dat er verse backups zijn voordat deze optie aangezet wordt. &prompt.root; mount -u -o async /usr/obj Zorg ervoor, zoals al eerder is aangegeven, dat als /usr/obj niet op een eigen bestandssysteem staat, het juiste mountpunt wordt gebruikt. Wat te doen als er iets mis gaat? Zorg ervoor dat het systeem geen rommel meer bevat van eerdere builds. Het volgende helpt daarbij: &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 Inderdaad, make cleandir moet twee keer gedraaid worden. Herstart daarna het complete proces vanaf make buildworld. Als er nog steeds problemen zijn, stuur dan de foutmelding en de uitvoer van uname -a naar de &a.questions;. Wees bereid aanvullende vragen over het systeem te beantwoorden! Mike Meyer Bijgedragen door Meerdere machines bijwerken NFS meerdere machines installeren Als er meerdere machines zijn die dezelfde broncode bijhouden, lijkt het downloaden van alle broncode en alles overal opnieuw bouwen zonde van de bronnen: harde schijfruimte, netwerk bandbreedte, en processorbelasting. Dit klopt en de oplossing is om alles op één machine te doen terwijl de overige machines het uitgevoerde werk benaderen via NFS. Nu wordt een methode beschreven waarmee dit gedaan kan worden. Benodigdheden Als eerste moet er een groep van machines gekozen worden die dezelfde set aan binaire bestanden zal draaien, hier een bouwgroep. Elke machine kan een eigen afwijkende kernel hebben maar moet dezelfde binaire gebruikersbestanden draaien. Uit die groep moet een machine gekozen worden die de bouwmachine wordt. Dit wordt de machine waar de wereld en kernel op gebouwd worden. In het meest ideale geval is dit een snelle machine die genoeg processorkracht vrij heeft om make buildworld en make buildkernel te draaien. Er moet ook een machine gekozen worden die de testmachine wordt waarop alle bijgewerkte software wordt test voordat die in productie wordt genomen. Dit moet een machine zijn die voor langere tijd down mag zijn. Dit kan de bouwmachine zijn maar dat hoeft niet per se. Alle machines in deze bouwgroep moeten ingesteld worden om /usr/obj en /usr/src vanaf dezelfde machine te mounten op hetzelfde punt. In het meest ideale geval zijn dit twee verschillende schijven op de bouwmachine, maar ze kunnen ook door middel van NFS op die machine gemount zijn. Als er meerdere bouwgroepen zijn, dan moet /usr/src op één bouwmachine staan en door middel van NFS gemount worden op de overige machines. Zorg er als laatste voor dat /etc/make.conf op alle machines in de bouwgroep het eens zijn met de bouwmachine. Dat betekent dat de bouwmachine alle delen van het basissysteem moet bouwen die elke machine in de bouwgroep installeert. Ook heeft elke bouwmachine zijn kernelnaam ingesteld met KERNCONF in /etc/make.conf en de bouwmachine moet ze allemaal hebben in KERNCONF, zijn eigen kernel eerst. De bouwmachine moet de instellingenbestanden voor elke machine in /usr/src/sys/arch/conf hebben als deze machine de kernels voor de overige machines gaat bouwen. Basissysteem Nu kan één systeem alles bouwen. Bouw de kernel en wereld zoals beschreven in op de bouwmachine, maar installeer niets. Zodra de bouw klaar is, moet op de testmachine de kernel geïnstalleerd en getest worden. Als deze machine /usr/src en /usr/obj mount via NFS, moet na een herstart in single-user modus het netwerk ingeschakeld worden zodat de mounts opnieuw gemaakt kunnen worden. De makkelijkste manier om dit te doen is om te starten in multi-user modus en daar shutdown now starten om in single-user modus te komen. Eenmaal daar aangekomen kunnen de nieuwe kernel en de wereld geïnstalleerd worden en kan daarna normaal mergemaster gestart worden. Zodra dit klaar is, kan de machine opnieuw gestart worden om naar multi-user modus terug te keren. Nadat zeker is dat alles op de testmachine correct werkt, kan dezelfde procedure gebruikt worden om de nieuwe software op elke machine te installeren in de bouwgroep. Ports Dezelfde ideeën kunnen gebruikt worden voor de ports. De eerste kritieke stap is om /usr/ports te mounten op alle machines in de bouwgroep. Daarna kan /etc/make.conf correct ingesteld worden om de distfiles te delen. De variabele DISTDIR moet wijzen naar een gedeelde map waarin geschreven kan worden door de gebruiker waar root naar wijst in de NFS mounts. Op elke machine moet WRKDIRPREFIX naar een lokale bouwmap wijzen. Als er pakketten gebouwd en gedistribueerd worden moet PACKAGES naar een map wijzen gelijkvormig aan de instelling voor DISTDIR.