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 7da8c8f408..acfefc7a62 100644 --- a/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/cutting-edge/chapter.sgml @@ -1,3412 +1,3412 @@ 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 René Ladan &os; updaten en upgraden Overzicht &os; wordt ontwikkeld tussen de verschillende versies in. Sommige mensen prefereren om de officieel uitgegeven versies te draaien, terwijl anderen gesynchroniseerd willen blijven met de nieuwste ontwikkelingen. Zelfs officiële uitgaven echter worden vaak bijgewerkt met veiligheids- en andere kritieke reparaties. Ongeacht de gebruikte versie biedt &os; alle noodzakelijke gereedschappen om uw systeem bijgewerkt te houden, en maakt het het upgraden tussen versies ook gemakkelijk. Dit hoofdstuk helpt om een keuze te maken of het wenselijk is het ontwikkelsysteem te volgen of één van de uitgegeven versies. De basisgereedschappen om uw systeem bijgewerkt te houden worden ook gepresenteerd. Na het lezen van dit hoofdstuk weet de lezer: Welke gereedschappen gebruikt kunnen worden om het systeem en de Portscollectie te updaten. Hoe een systeem bijgewerkt kan worden met freebsd-update, CVSup, CVS of CTM; Hoe de toestand van een geïnstalleerd systeem met een bekende maagdelijke kopie te vergelijken. Hoe uw documentatie bijgewerkt te houden met CVSup of documentatie-ports. De verschillen tussen de ontwikkeltakken &os.stable; en &os.current;; 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 (). Door dit hoofdstuk heen wordt cvsup gebruikt om de broncode van &os; te verkrijgen en bij te werken. Om het te gebruiken, dient u een port of pakket als net/cvsup-without-gui te installeren. Als u &os; 6.2-RELEASE of nieuwer gebruikt, kunt u dit vervangen door &man.csup.1; welke nu deel uitmaakt van het basissysteem. Tom Rhodes Geschreven door Colin Percival Gebaseerd op notities aangeleverd door &os; Update updaten en upgraden freebsd-update updating-upgrading Het toepassen van beveiligingspatches is een belangrijk onderdeel van het beheren van computersoftware, met name het besturingssysteem. Dit was voor een lange tijd geen gemakkelijk proces op &os;. Er moesten patches op de broncode worden toegepast, de code moest herbouwd worden tot binairen, en daarna moesten de binairen worden geherinstalleerd. Dit is niet langer het geval aangezien &os; nu een gereedschap heeft dat eenvoudigweg freebsd-update heet. Dit gereedschap biedt twee gescheiden functies. Ten eerste voorziet het in het toepassen van binaire beveiligings- en errata-updates op het basissysteem van &os; zonder de eis om te bouwen en te installeren. Ten tweede ondersteunt het gereedschap kleine en grote uitgave-upgrades. Binaire updates zijn beschikbaar voor alle architecturen en uitgaven die momenteel door het beveiligingsteam worden ondersteund; voor sommige eigenschappen, zoals de upgrades van het besturingssysteem &os;, zijn de laatste uitgave van &man.freebsd-update.8; en &os; 6.3 nodig. Voordat naar een nieuwe uitgave wordt ge-updated, dienen de huidige uitgaveaankondigingen gelezen te worden aangezien ze belangrijke informatie over de gewenste uitgave kunnen bevatten. De aankondigingen kunnen op de volgende koppeling bekeken worden: . Als er een crontab bestaat die de mogelijkheden van freebsd-update gebruikt, moet het uitgeschakeld worden voordat aan de volgende operatie wordt begonnen. Het configuratiebestand Sommige gebruikers willen het standaard configuratiebestand optimaliseren, waardoor het proces beter gecontroleerd kan worden. De opties zijn goed gedocumenteerd, maar voor de volgenden is wat extra uitleg nodig: # Componenten van het basissysteem die bijgewerkt moeten blijven Components src world kernel Deze parameter bepaalt welke delen van &os; bijgewerkt blijven. Standaard wordt de broncode bijgewerkt, het hele basissysteem, en de kernel. Dezelfde componenten als tijdens de installatie zijn beschikbaar, het toevoegen van bijvoorbeeld "world/games" zou de spelpatches toepassen. Het gebruik van "src/bin" zou de broncode in src/bin bijgewerkt houden. Het beste kan dit op de standaardwaarde blijven aangezien het veranderen hiervan om specifieke items te bevatten de gebruiker dwingt om alle items die bijgewerkt dienen te worden op te noemen. Dit kan rampzalige gevolgen hebben aangezien de broncode en de binairen asynchroon kunnen raken. # Paden die beginnen met iets wat overeenkomt met een regel in een IgnorePaths # statement zullen genegeerd worden. IgnorePaths Voeg paden, zoals /bin of /sbin toe om deze specifieke mappen ongemoeid te laten tijdens het updateproces. Deze optie kan gebruikt worden om te voorkomen dat freebsd-update lokale wijzigingen overschrijft. # Paden die beginnen met iets wat overeenkomt met een regel in een UpdateIfUnmodified # statement zullen alleen worden bijgewerkt als de inhoud van het bestand niet is # gewijzigd door de gebruiker (tenzij veranderingen zijn samengevoegd; zie beneden). UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile Werk configuratiebestanden in de aangegeven mappen alleen bij als ze niet zijn gewijzigd. Alle veranderingen die door de gebruiker zijn gemaakt maken het automatisch bijwerken van deze bestanden ongeldig. Er is een andere optie, KeepModifiedMetadata, die freebsd-update instrueert om de veranderingen tijdens het samenvoegen te bewaren. # Wanneer naar een nieuwe uitgave van &os; wordt ge-upgraded, worden lokale veranderingen van bestanden die overeenkomen met MergeChanges # samengevoegd in de versie van de nieuwe uitgave. MergeChanges /etc/ /var/named/etc/ Lijst van mappen met instellingenbestanden waar freebsd-update moet proberen om in samen te voegen. Het proces van bestanden samenvoegen is een serie van &man.diff.1;-patches die ongeveer gelijk is aan &man.mergemaster.8; met minder opties, de samenvoegingen worden ofwel geaccepteerd, of openen een tekstverwerker, of zorgen ervoor dat freebsd-update afbreekt. Maak in geval van twijfel een reservekopie van /etc en accepteer de samenvoegingen. In staat meer informatie over het commando mergemaster. # Map waarin de gedownloade updates en tijdelijke bestanden # die door een &os; Update worden gebruikt worden worden opgeslagen. # WorkDir /var/db/freebsd-update Dit is de map waarin alle patches en tijdelijke bestanden worden geplaatst. In het geval dat de gebruiker een versie-upgrade uitvoert, dient deze locatie tenminste een gigabyte aan vrije schijfruimte te hebben. # Wanneer tussen uitgaven wordt ge-upgraded, dient de lijst van Componenten dan # strikt gelezen te worden (StrictComponents yes) of slechts als een lijst van componenten # die geïnstalleerd *kunnen* worden en waarvan &os; Update uit dient te zoeken # welke daadwerkelijk zijn geïnstalleerd en die te upgraden (StrictComponents no)? # StrictComponents no Wanneer ingesteld op yes, zal freebsd-update aannemen dat de lijst Components compleet is en zal het niet proberen om wijzigingen buiten de lijst te maken. Effectief zal freebsd-update proberen om elk bestand bij te werken dat op de lijst Components staat. Beveiligingspatches Beveiligingspatches staan op een verre machine en kunnen met het volgende commando gedownload en geïnstalleerd worden: &prompt.root; freebsd-update fetch &prompt.root; freebsd-update install Als er kernelpatches zijn toegepast moet het systeem opnieuw opgestart worden. Als alles goed is gegaan dient het systeem gepatcht te zijn en kan freebsd-update als een nachtelijke &man.cron.8;-taak gedraaid worden. Een regel in /etc/crontab zou genoeg moeten zijn om deze taak te volbrengen: @daily root freebsd-update cron Deze regel verklaart dat eenmaal per dag het commando freebsd-update gedraaid zal worden. Op deze manier, door het argument te gebruiken, zal het gereedschap freebsd-update alleen kijken of er updates bestaan. Als er patches bestaan, zullen ze automatisch worden gedownload naar de plaatselijke schijf maar niet worden toegepast. Er zal een email aan de gebruiker root worden verstuurd zodat ze handmatig geïnstalleerd kunnen worden. Als er iets misging, heeft freebsd-update de mogelijkheid om de laatste verzamelingen veranderingen terug te draaien met het volgende commando: &prompt.root; freebsd-update rollback Eenmaal voltooid, dient het systeem herstart te worden als de kernel of enige kernelmodule is gewijzigd. Dit stelt &os; in staat om de nieuwe binairen in het geheugen te laden. Het gereedschap freebsd-update kan alleen de kernel GENERIC automatisch bijwerken. Als een eigen kernel wordt gebruikt, moet het herbouwd en geherinstalleerd worden nadat freebsd-update klaar is met het installeren de rest van de updates. freebsd-update zal echter de kernel GENERIC in /boot/GENERIC detecteren en bijwerken (als het bestaat), zelfs als het niet de huidige (draaiende) kernel van het systeem is. Het is een goed idee om altijd een kopie van de kernel GENERIC in /boot/GENERIC te bewaren. Het kan van pas komen bij het vaststellen van een keur aan problemen, en bij het uitvoeren van versie-upgrades met freebsd-update zoals beschreven in . Tenzij de standaardconfiguratie in /etc/freebsd-update.conf is gewijzigd, zal freebsd-update de bijgewerkte kernelbronnen samen met de rest van de updates installeren. Het herbouwen en herinstalleren van uw nieuwe eigen kernel kan daarna op de gebruikelijke manier gedaan worden. De updates die via freebsd-update verspreid worden hebben niet altijd betrekking op de kernel. Het is niet nodig om uw eigen kernel te herbouwen als de kernelbronnen niet zijn aangepast door het uitvoeren van freebsd-update install. freebsd-update install zal echter altijd het bestand /usr/src/sys/conf/newvers.sh bijwerken. Het huidige patchniveau (zoals aangegeven door het -p-nummer gerapporteerd door uname -r) wordt uit dit bestand gehaald. Het herbouwen van uw eigen kernel, zelfs als er niets veranderd is, stelt &man.uname.1; in staat om het huidige patchniveau van het systeem accuraat te rapporteren. Dit is in het bijzonder behulpzaam wanneer meerdere systemen onderhouden worden, aangezien hierdoor snel de geïnstalleerde updates op elk ervan kunnen worden nagegaan. Grote en kleine upgrades Dit proces ruimt oude objectbestanden en bibliotheken op waardoor de meeste applicaties van derde partijen kapot gaan. Het wordt aangeraden dat alle geïnstalleerde poorten ofwel verwijderd en geherinstalleerd worden of later ge-upgraded worden met het hulpmiddel ports-mgmt/portupgrade. De meeste gebruikers zullen willen proefdraaien met het volgende commando: &prompt.root; portupgrade -af Dit zorgt ervoor dat alles juist wordt geherinstalleerd. Merk op dat het instellen van de omgevingsvariabele BATCH op yes het antwoord yes zal geven op alle prompts tijdens dit proces, waardoor het niet nodig is om handmatig in het bouwproces in te grijpen. Als een eigen kernel wordt gebruikt, is het upgradeproces iets ingewikkelder. Een kopie van de kernel GENERIC is nodig en dient in /boot/GENERIC geplaatst te worden. Als de kernel GENERIC niet reeds op het systeem aanwezig is, moet het met één van de volgende methoden verkregen worden: Als er slechts eenmaal een eigen kernel is gebouwd, dan is de kernel in /boot/kernel.old eigenlijk de GENERIC. Hernoem deze map naar /boot/GENERIC. Aannemende dat fysieke toegang tot de machine mogelijk is, kan een kopie van de kernel GENERIC van het CD-ROM-medium worden geïnstalleerd. Laad de installatieschijf en geef de volgende commando's: &prompt.root; mount /cdrom &prompt.root; cd /cdrom/X.Y-RELEASE/kernels &prompt.root; ./install.sh GENERIC Vervang X.Y-RELEASE met de versie van de uitgave die u gebruikt. De kernel GENERIC zal standaard in /boot/GENERIC worden geïnstalleerd. Als al het bovenstaande niet lukt, kan de kernel GENERIC herbouwd en geherinstalleerd worden vanaf de broncode: &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 Om deze kernel door freebsd-update als GENERIC te laten herkennen, mag het configuratiebestand voor GENERIC niet op enige wijze veranderd zijn. Het is ook aan te raden dat het zonder andere speciale opties wordt gebouwd (bij voorkeur met een leeg /etc/make.conf). Opnieuw opstarten naar de kernel GENERIC is in dit stadium niet nodig. Updates van grote en kleine versies kunnen worden uitgevoerd door een uitgaveversie als doel aan freebsd-update op te geven, het volgende commando zal bijvoorbeeld updaten naar &os; 6.4: &prompt.root; freebsd-update -r 6.4-RELEASE upgrade Nadat het commando is ontvangen, zal freebsd-update het instellingenbestand en het huidige systeem evalueren in een poging om de benodigde informatie te verzamelen om het systeem te updaten. Een lijst op het scherm zal aangeven welke componenten zijn gedetecteerd en welke niet. Bijvoorbeeld: 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 Nu zal freebsd-update proberen om alle bestanden die nodig zijn voor de upgrade te downloaden. In sommige gevallen kan de gebruiker worden gevraagd wat te installeren of hoe verder te gaan. Wanneer een eigen kernel wordt gebruikt, zal de bovenstaande stap een waarschuwing geven die lijkt op de volgende: WARNING: This system is running a "MIJNKERNEL" 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" Deze waarschuwing kan op dit moment veilig worden genegeerd. De bijgewerkte kernel GENERIC zal als tussenliggende stap in het upgradeproces worden gebruikt. Nadat alle patches zijn gedownload naar het plaatselijke systeem zullen ze worden toegepast. Dit proces kan afhankelijk van de snelheid en werklast van de machine even duren. Hierna zullen instellingenbestanden worden samengevoegd — voor dit gedeelte van het proces is enige tussenkomst van de gebruiker nodig aangezien een bestand kan worden samengevoegd of omdat er een tekstverwerker op het scherm kan verschijnen om het bestand handmatig samen te voegen. Het resultaat van elke succesvolle samenvoeging zal aan de gebruiker worden getoond naarmate het proces verder gaat. Een mislukte of genegeerde samenvoegpoging zal het proces afbreken. Het is mogelijk voor gebruikers om een reservekopie van /etc te maken en belangrijke bestanden, zoals master.passwd of group, later samen te voegen. Het systeem is nog niet veranderd, al het patchen en samenvoegen gebeurt in een andere map. Wanneer alle patches succesvol zijn toegepast, alle instellingenbestanden zijn samengevoegd en het erop lijkt dat het proces soepel verloopt, dienen de veranderingen verzegeld te worden door de gebruiker. Als dit proces eenmaal voltooid is, kan de upgrade aan de schijf toevertrouwd worden met het volgende commando. &prompt.root; freebsd-update install De kernel en kernelmodules zullen als eerste gepatcht worden. Nu moet de machine opnieuw opgestart worden. Als het systeem een eigen kernel draaide, gebruik dan het commando &man.nextboot.8; om de kernel voor de volgende keer dat opgestart wordt in te stellen op /boot/GENERIC (welke is bijgewerkt): &prompt.root; nextboot -k GENERIC Voordat er met de kernel GENERIC wordt opgestart, dient te worden gecontroleerd dat het alle stuurprogramma's bevat om uw systeem juist te laten opstarten (en met het netwerk te verbinden, als de machine die bijgewerkt wordt van afstand wordt benaderd). In het bijzonder, als de vorige kernel die draaide ingebouwde functionaliteit bevatte die normaalgesproken door kernelmodules wordt geleverd, zorg er dan voor dat deze modules tijdelijk in de kernel GENERIC worden geladen door de faciliteit /boot/loader.conf te gebruiken. U kunt er ook voor kiezen om niet-essentiële diensten, schijf- en netwerkkoppelingen, enzovoorts uit te zetten totdat het upgradeproces voltooid is. De machine dient nu te worden herstart met de bijgewerkte kernel: &prompt.root; shutdown -r now Als het systeem weer actief is, moet freebsd-update nogmaals gestart worden. De toestand van het proces is opgeslagen en dus zal freebsd-update niet vooraan beginnen, maar zal het alle oude gedeelde bibliotheken en objectbestanden verwijderen. Geef het volgende commando om verder te gaan op dit punt: &prompt.root; freebsd-update install Afhankelijk van het feit of er versienummers van bibliotheken zijn opgehoogd, kunnen er slechts twee in plaats van drie installatiefasen zijn. Alle software van derde partijen dient nu opnieuw gebouwd en geïnstalleerd te worden. Dit is nodig omdat geïnstalleerde software van bibliotheken afhankelijk kan zijn die tijdens het upgradeproces zijn verwijderd. Het commando ports-mgmt/portupgrade kan gebruikt worden om dit proces te automatiseren. Dit proces kan met de volgende commando's gestart worden: &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 Voltooi, nadat dit voltooid is, het upgradeproces met een laatste aanroep naar freebsd-update. Geef het volgende commando om alle losse eindjes in het upgradeproces samen te knopen: &prompt.root; freebsd-update install Als de kernel GENERIC tijdelijk werd gebruikt, is dit het moment om een nieuwe eigen kernel op de gebruikelijke manier te bouwen en installeren. Start de machine opnieuw op in de nieuwe &os;-versie. Het proces is voltooid. Het vergelijken van systeemtoestanden Het gereedschap freebsd-update kan gebruikt worden om de toestand van de geïnstalleerde versie van &os; met een bekende goede kopie te vergelijken. Deze optie evalueert de huidige versie van systeemgereedschappen, bibliotheken, en instellingenbestanden. Geef het volgende commando om met de vergelijking te beginnen: &prompt.root; freebsd-update IDS >> uitvoerbestand.ids Hoewel de commandonaam IDS is, is het in geen geval een vervanging voor een indringdetectiesysteem zoals security/snort. Aangezien freebsd-update gegevens op schijf opslaat, is de mogelijkheid om te knoeien duidelijk. Hoewel deze mogelijkheid verminderd kan worden door de instelling kern.securelevel te gebruiken en de gegevens van freebsd-update op een bestandssysteem dat alleen gelezen kan worden op te slaan wanneer deze niet gebruikt worden, zou een betere oplossing zijn om het systeem met een veilige schijf te vergelijken, zoals een DVD of een veilig opgeslagen externe USB-schijf. Het systeem zal nu geïnspecteerd worden, en er zal een lijst van hun &man.sha256.1;-hashwaarden, zowel de bekende waarde in de uitgave en de huidige geïnstalleerde waarde, afgebeeld worden. Hierom wordt de uitvoer naar het bestand uitvoerbestand.ids gezonden. Het scrollt te snel voorbij om het met het oog te vergelijken, en het vult al snel de gehele consolebuffer op. Deze regels zijn ook extreem lang, maar het uitvoerformaat kan vrij eenvoudig geparsed worden. Geef, om bijvoorbeeld een lijst van alle bestanden te krijgen die verschillen van die in de uitgave, het volgende commando: &prompt.root; cat uitvoerbestand.ids | awk '{ print $1 }' | more /etc/master.passwd /etc/motd /etc/passwd /etc/pf.conf Deze uitvoer is afgekapt, er bestaan veel meer bestanden. Sommige van deze bestanden hebben natuurlijke veranderingen, het /etc/passwd is gewijzigd omdat er gebruikers aan het systeem zijn toegevoegd. In sommige gevallen kunnen er andere bestanden zijn, zoals kernelmodules, die verschillen aangezien freebsd-update ze ge-updated kan hebben. Voeg, om bepaalde bestanden of mappen uit te sluiten, deze toe aan de optie IDSIgnorePaths in /etc/freebsd-update.conf. Dit systeem kan gebruikt worden als deel van een uitgebreide upgrademethode, afgezien van de eerder besproken versie. Tom Rhodes Geschreven door Colin Percival Gebaseerd op notities geleverd door Portsnap: een updategereedschap voor de Portscollectie updaten en upgraden Portsnap updaten en upgraden Het basissysteem van &os; bevat ook een gereedschap om de Portscollectie bij te werken: het hulpmiddel &man.portsnap.8;. Wanneer het wordt uitgevoerd, zal het een verbinding maken met een verre site, de veilige sleutel controleren, en een nieuwe kopie van de Portscollectie downloaden. De sleutel wordt gebruikt om de integriteit van alle gedownloade bestanden te controleren, om er zeker van te zijn dat ze niet tijdens het downloaden zijn gewijzigd. Geef het volgende commando om de nieuwste versie van de bestanden van de Portscollectie te downloaden: &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. Dit voorbeeld laat zien dat &man.portsnap.8; verscheidene patches heeft gevonden en deze met de huidige portsgegevens heeft gecontroleerd. Het geeft ook aan dat het gereedschap eerder is gedraaid, als het voor de eerste keer was gedraaid, had het simpelweg de collectie gedownload. Wanneer &man.portsnap.8; succesvol een fetch-operatie afrondt, bestaan de Portscollectie en de vervolgpatches die de verificatie doorstaan hebben op het plaatselijke systeem. Gebruik de eerste keer dat portsnap wordt uitgevoerd extract om de bijgewerkte bestanden te installeren: &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 ... Bij verder gebruik van portsnap fetch dient update gebruikt te worden: &prompt.root; portsnap update Het proces is nu compleet, en applicaties kunnen met de bijgewerkte Portscollectie worden geïnstalleerd of worden bijgewerkt. De bewerkingen fetch en extract of update kunnen achter elkaar uitgevoerd worden, zoals het volgende voorbeeld laat zien: &prompt.root; portsnap fetch update De documentatie bijwerken updaten en upgraden documentatie updaten en upgraden Naast het basissysteem en de Portscollectie is documentatie een integraal onderdeel van het besturingssysteem &os;. Hoewel een actuele versie van de &os;-documentatie altijd beschikbaar is op de &os; website, hebben sommige gebruikers een langzame of helemaal geen permanente netwerkverbinding. Gelukkig zijn er verschillende manieren om de documentatie die bij elke uitgave wordt geleverd bij te werken door een lokale kopie van de nieuwste &os;-documentatie bij te houden. CVSup gebruiken om de documentatie bij te werken De bronnen en de geïnstalleerde kopie van de &os;-documentatie kunnen met CVSup worden bijgewerkt, waarbij een mechanisme wordt gebruikt dat lijkt op degene die voor de broncode van het basissysteem wordt gebruikt (c.f. ). Deze sectie beschrijft: Hoe de documentatiegereedschappen, de gereedschappen die nodig zijn om de &os;-documentatie vanuit de broncode te herbouwen, te installeren. Hoe een kopie van de documentatiebronnen in /usr/doc te downloaden door CVSup te gebruiken. Hoe de &os;-documentatie vanuit de broncode te herbouwen en onder /usr/share/doc te installeren. Sommige bouwopties die door het bouwsysteem van de documentatie ondersteund worden, i.e. de opties die slechts enkele van de verschillende vertalingen van de documentatie bouwen of de opties die een specifiek uitvoerformaat selecteren. CVSup en de documentatiegereedschappen installeren Voor het herbouwen van de &os;-documentatie vanuit de broncode is een aardig grote verzameling gereedschappen nodig. Deze gereedschappen zijn geen deel van het basissysteem van &os; omdat ze een grote hoeveelheid schijfruimte nodig hebben en niet voor alle &os;-gebruikers nuttig zijn; ze zijn alleen nuttig voor die gebruikers die actief nieuwe documentatie voor &os; schrijven of regelmatig hun documentatie vanuit de broncode bijwerken. Alle benodigde gereedschappen zijn beschikbaar als deel van de Portscollectie. De port textproc/docproj is een meester-port die door het &os; Documentatieproject is ontwikkeld om de installatie en toekomstige updates van deze gereedschappen makkelijker te maken. Wanneer er geen &postscript;- of PDF-documentatie nodig is, kan men overwegen om in plaats hiervan de port textproc/docproj-nojadetex te installeren. Deze versie van de documentatiegereedschappen bevat alles behalve de typesetting-engine teTeX. teTeX is een erg grote verzameling van gereedschappen, dus kan het zinvol zijn om de installatie ervan achterwege te laten als PDF-uitvoer niet echt nodig is. Bekijk CVSup gebruiken voor meer informatie over het installeren en gebruiken van CVSup. De documentatiebroncode bijwerken Het hulpmiddel CVSup kan een schone kopie van de documentatiebroncode ophalen, door het bestand /usr/share/examples/cvsup/doc-supfile als een configuratiesjabloon te gebruiken. Voor de standaard update-host is in doc-supfile een nog in te vullen waarde ingevuld, maar &man.cvsup.1; accepteert een hostnaam via de opdrachtregel, dus kan de documentatiebroncode van een van de CVSup-servers worden opgehaald door het volgende te typen: &prompt.root; cvsup -h cvsup.FreeBSD.org -g -L 2 /usr/share/examples/cvsup/doc-supfile Verander cvsup.FreeBSD.org in de dichtstbijzijnde CVSup-server. Zie voor een complete lijst van spiegelsites. De initiële download van de documentatiebroncode kan een tijd duren. Laat het draaien totdat het voltooid is. Toekomstige updates van de documentatiebroncode kunnen opgehaald worden door hetzelfde commando te draaien. Het hulpmiddel CVSup downloadt en kopieert alleen de updates sinds de laatste keer dat het gedraaid werd, dus zou elke keer dat CVSup gedraaid wordt na de eerste complete keer redelijk snel moeten zijn. Nadat de broncode is uitgecheckt, wordt een alternatieve manier om de documentatie bij te werken ondersteund door Makefile van de map /usr/doc. Door SUP_UPDATE, SUP_HOST, en DOCSUPFILE in het bestand /etc/make.conf in te stellen, is het mogelijk om dit te draaien: &prompt.root; cd /usr/doc &prompt.root; make update Een typische verzameling van deze &man.make.1;-opties voor /etc/make.conf is: SUP_UPDATE= yes SUPHOST?= cvsup.FreeBSD.org DOCSUPFILE?= /usr/share/examples/cvsup/doc-supfile Het instellen van de waardes SUPHOST en DOCSUPFILE met ?= staat toe dat ze in de opdrachtregel van make overschreven worden. Dit is de aangeraden manier om opties aan /etc/make.conf toe te voegen, om te voorkomen dat het bestand telkens wanneer er een andere waarde van de optie getest moet worden bewerkt moet worden. Instelbare opties van de documentatiebroncode Het bijwerk- en bouwsysteem van de &os;-documentatie ondersteunt enkele opties die het proces om de documentatie alleen gedeeltelijk bij te werken, of om specifieke vertalingen te bouwen, makkelijker maken. Deze opties kunnen of als systeemwijde opties in het bestand /etc/make.conf worden ingesteld, of als opdrachtregelopties aan het hulpmiddel &man.make.1; worden doorgegeven. De volgende opties zijn er enkelen van: DOC_LANG De lijst van te bouwen en te installeren talen en coderingen, bijvoorbeeld en_US.ISO8859-1 voor alleen de Engelse documentatie. FORMATS Een enkel formaat of een lijst van uitvoerformaten die gebouwd moeten worden. Momenteel worden html, html-split, txt, ps, pdf, en rtf ondersteund. SUPHOST De hostnaam van de CVSup server die gebruikt wordt tijdens het bijwerken. DOCDIR Waar de documentatie te installeren. Dit staat standaard op /usr/share/doc. Bekijk &man.make.conf.5; voor meer make-variabelen die als systeemwijde opties in &os; worden ondersteund. Voor meer make-variabelen die die door het bouwsysteem van de &os;-documentatie ondersteund worden, wordt naar het &os; Documentation Project Primer for New Contributors verwezen. De &os;-documentatie vanuit de broncode installeren Wanneer er een actueel snapshot van de documentatiebroncode is opgehaald in /usr/doc, is alles gereed om de geïnstalleerde documentatie bij te werken. Het volledig bijwerken van alle talen die in de Makefile-optie DOC_LANG zijn gedefinieerd kan worden gedaan door te typen: &prompt.root; cd /usr/doc &prompt.root; make install clean Als make.conf is ingesteld met de juiste opties voor DOCSUPFILE, SUPHOST, en SUP_UPDATE, dan kan de installatiestap worden gecombineerd met het bijwerken van de documentatiebroncode door te typen: &prompt.root; cd /usr/doc &prompt.root; make update install clean Als alleen het bijwerken van een specifieke taal gewenst is, dan kan &man.make.1; worden aangeroepen in een taalspecifieke submap van /usr/doc, i.e.: &prompt.root; cd /usr/doc/en_US.ISO8859-1 &prompt.root; make update install clean De te installeren uitvoerformaten kunnen worden gespecificeerd door de make-variabele FORMATS in te stellen, i.e.: &prompt.root; cd /usr/doc &prompt.root; make FORMATS='html html-split' install clean Marc Fonvieille Gebaseerd op het werk van Documentatieports gebruiken Updaten en upgraden documentatiepakket Updaten en upgraden In de vorige sectie werd er een methode voor het bijwerken van de &os;-documentatie vanaf de broncode gepresenteerd. Het bijwerken gebaseerd op broncode is echter niet voor alle &os;-systemen haalbaar of praktisch. Voor het bouwen van de documentatiebronnen zijn een redelijk grote verzameling van gereedschappen, de documentatie gereedschapskist, een bepaald niveau van bekendheid met CVS en checkouts van broncode vanuit een reservoir nodig, en een aantal handmatige stappen om de uitgecheckte broncode te bouwen. In deze sectie wordt een alternatieve manier beschreven om de geïnstalleerde kopiën van de &os;-documentatie bij te werken; een die de Ports Collectie gebruikt en het mogelijk maakt om: Voorgebouwde versies van de documentatie te downloaden en te installeren, zonder iets lokaal te hoeven bouwen (op deze manier wordt de noodzaak voor een installatie van de gehele documentatie-gereedschapskist voorkomen). De documentatiebronnen te bouwen en ze via het ports-raamwerk te bouwen (de stappen van het uitchecken en bouwen worden iets eenvoudiger gemaakt). Deze twee methoden om de &os;-documentatie bij te werken worden ondersteund door een verzameling van documentatie-ports die maandelijks door het &a.doceng; worden bijgewerkt. Deze zijn vermeld in de &os; Ports Collectie onder de virtuele categorie docs. Documentatie-ports bouwen en installeren De documentatie-ports gebruiken het bouwraamwerk van de ports om het bouwen van documentatie eenvoudiger te maken. Ze automatiseren het proces van het uitchecken van de broncode van de documentatie, het draaien van &man.make.1; met de juiste omgevingsinstellingen en opdrachtregelopties, en ze maken de installatie of deïnstallatie van documentatie net zo eenvoudig als de installatie van elke andere &os;-port of -pakket. Als een extra eigenschap registreren de documentatie-ports, wanneer ze lokaal zijn gebouwd, een afhankelijkheid naar de ports van de documentatie-gereedschapskist, zodat de laatste ook automatisch is geïnstalleerd. De organisatie van de documentatie-ports is als volgt: Er is een meester-port, misc/freebsd-doc-en, waar de bestanden van de documentatie-ports gevonden kunnen worden. Het is de basis van alle documentatie-ports. Standaard bouwt het alleen de Engelstalige documentatie. Er is een alles-in-één port, misc/freebsd-doc-all, en het bouwt en installeert alle documentatie in alle beschikbare talen. Ten slotte is er een slaaf-port voor elke vertaling, b.v. misc/freebsd-doc-hu voor de documenten in het Hongaars. Ze zijn allemaal afhankelijk van de meester-port en installeren de vertaalde documentatie van de respectievelijke taal. Gebruik de volgende commando's (als root) om een documentatieport vanaf de broncode te installeren: &prompt.root; cd /usr/ports/misc/freebsd-doc-en &prompt.root; make install clean Dit zal de Engelstalige documentatie in gesplitst HTML-formaat (hetzelfde als dat op wordt gebruikt) in de map /usr/local/share/doc/freebsd bouwen en installeren. Algemene knoppen en opties Er zijn vele opties om het standaardgedrag van de documentatie-ports aan te passen. Het volgende is slechts een korte lijst: WITH_HTML Staat bouwen van het HTML-formaat toe: een enkel HTML-bestand per document. De opgemaakte documentatie wordt naar gelang in een bestand genaamd article.html, of book.html, met afbeeldingen opgeslagen. WITH_PDF Staat bouwen van het &adobe; Portable Document Format toe, te gebruiken met &adobe; &acrobat.reader;, Ghostscript, of andere PDF-lezers. De opgemaakte documentatie wordt naar gelang opgeslagen in een bestand genaamd article.pdf of book.pdf opgeslagen. DOCBASE Waar de documentatie te installeren. Standaard is dit /usr/local/share/doc/freebsd. Merk op dat de standaard doelmap afwijkt van de map die door de CVSup-methode wordt gebruikt. Dit komt omdat er een port wordt geïnstalleerd, en ports worden normaliter onder de map /usr/local geïnstalleerd. Dit kan veranderd worden door de variabele PREFIX toe te voegen. Hier is een kort voorbeeld over hoe de bovengenoemde variabelen te gebruiken om de Hongaarse documentatie in Portable Document Format te installeren: &prompt.root; cd /usr/ports/misc/freebsd-doc-hu &prompt.root; make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean Documentatiepakketten gebruiken Voor het bouwen van de documentatie-ports vanaf broncode, zoals beschreven in de vorige sectie, is een lokale installatie van de documentatie-gereedschapskist en wat schijfruimte voor het bouwen van de ports nodig. Wanneer de bronnen voor het installeren van de documentatie-gereedschapskist niet aanwezig zijn, of wanneer het bouwen vanaf broncode te veel schijfruimte in beslag neemt, is het nog steeds mogelijk om de vooraf gebouwde versies van de documentatie-ports te installeren. Het &a.doceng; bereidt maandelijkse versies van de &os; documentatiepakketten voor. Deze binaire pakketten kunnen met elk van de meegeleverde pakketgereedschappen, zoals &man.pkg.add.1;, &man.pkg.delete.1;, enzovoorts gebruikt worden. Wanneer binaire pakketten worden gebruikt, zal de &os; documentatie in alle beschikbare formaten voor de gegeven taal geïnstalleerd worden. Het volgende commando bijvoorbeeld zal het nieuwste vooraf gebouwde pakket van de Hongaarse documentatie installeren: &prompt.root; pkg_add -r hu-freebsd-doc Pakketten hebben het volgende naamformaat welke afwijkt van de naam van de overeenkomstige port: taal-freebsd-doc. Hier is taal het korte formaat van de taalcode, i.e. hu voor Hongaars, of zh_cn voor Vereenvoudigd Chinees. Documentatieports bijwerken Voor het bijwerken van een eerder geïnstalleerde documentatieport is elk gereedschap voor het bijwerken van ports geschikt. Het volgende commando bijvoorbeeld werkt de geïnstalleerde Hongaarse documentatie bij via het gereedschap ports-mgmt/portupgrade door alleen pakketten te gebruiken: &prompt.root; portupgrade -PP hu-freebsd-doc Pav Lucistnik Gebaseerd op informatie geleverd door Docsnap gebruiken updaten en upgraden Docsnap updaten en upgraden Docscnap is een &man.rsync.1;-reservoir voor het bijwerken van geïnstalleerde &os;-documentatie op een relatief gemakkelijke en snelle manier. Een Docsnap server volgt de documentatiebroncode en bouwt ze elk uur in HTML-formaat. De port textproc/docproj is niet nodig met Docsnap aangezien er alleen patches voor de gebouwde documentatie bestaan. De enige benodigdheid om deze techniek te gebruiken is de port of het pakket net/rsync. Gebruik het volgende commando om het toe te voegen: &prompt.root; pkg_add -r rsync Docsnap is eigenlijk ontwikkeld om de documentatie die in /usr/share/doc is geïnstalleerd bij te werken, maar de volgende voorbeelden kunnen ook voor andere mappen worden gebruikt. Voor gebruikersmappen heeft het geen root-rechten nodig. Geef het volgende commando om de documentatie bij te werken: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap /usr/share/doc Er is momenteel slechts één Docsnap-server; de bovengenoemde host docsnap.sk.FreeBSD.org. Gebruik hier niet de vlag omdat er tijdens make installworld wat dingen in /usr/share/doc worden geïnstalleerd, die dan per ongeluk verwijderd zouden worden. Gebruik in plaats daarvan dit commando om op te ruimen: &prompt.root; rsync -rltvz --delete docsnap.sk.FreeBSD.org::docsnap/??_??\.\* /usr/share/doc Het volgende commando dient gebruikt te worden als er een deelverzameling van de documentatie, bijvoorbeeld alleen de Engelse documentatie, bijgewerkt moet worden: &prompt.root; rsync -rltvz docsnap.sk.FreeBSD.org::docsnap/en_US.ISO8859-1 /usr/share/doc ]]> Een ontwikkelingstak volgen -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.svn-src-head.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.svn-src-head.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. Als u geïnteresseerd bent in het volgen van veranderingen voor de gehele broncodeboom, raden wij u aan een abonnement te nemen op de &a.svn-src-all.name; lijst. 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 uw omgeving. Het voorbeeld standard-supfile is bedoeld om een specifieke beveiligingstak van &os; te volgen, niet &os.current;. U moet dit bestand bewerken en de volgende regel vervangen: *default release=cvs tag=RELENG_X_Y door deze: *default release=cvs tag=. Voor een gedetailleerde uitleg over bruikbare tags wordt naar de sectie CVS Tags van het Handboek verwezen. -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. Wordt lid van de relevante SVN-lijst voor de tak die u volgt. Als u bijvoorbeeld de tak 7-STABLE volgt, wordt u lid van de &a.svn-src-stable-7.name; lijst. Dit stelt u in staat om het commit-log-bericht te bekijken voor elke verandering die is gemaakt, tezamen met relevante informatie over mogelijke bijwerkingen. Ga om te abonneren op deze lijsten, of één van de andere beschikbare lijsten naar &a.mailman.lists.link; en klik op de lijst waarop een abonnement gewenst is. Instructies over de rest van de procedure zijn daar beschikbaar. Als u geïnteresseerd bent in het volgen van veranderingen voor de gehele broncodeboom, raden wij u aan een abonnement te nemen op de &a.svn-src-all.name; lijst. 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 Om uw systeem bij te werken, dient u /usr/src/UPDATING te controleren op eventuele pre-buildworld stappen die nodig zijn voor uw versie van de broncode en daarna de procedure te gebruiken die hier beschreven staat. Deze bijwerkstappen nemen aan dat u nu een oude versie van &os; gebruikt, die uit een oude compiler, een oude kernel, een oude wereld en oude instellingenbestanden bestaat. Onder wereld worden de binairen, bibliotheken, en programmeerbestanden van het kernsysteem verstaan. De compiler is deel van wereld, maar heeft enkele speciale aandachtspunten. We nemen ook aan dat u reeds de broncode van een nieuwer systeem heeft verkregen. Bekijk, als de bronnen op een bepaald systeem ook oud zijn, voor uitgebreide hulp over het synchroniseren ervan naar een nieuwere versie. Het bijwerken van het systeem vanaf de broncode is wat subtieler dan het op het eerste gezicht lijkt, en de ontwikkelaars van &os; vonden het in de loop der jaren nodig om de aangeraden methode redelijk drastisch te veranderen met het aan het licht komen van nieuwe soorten onontwijkbare afhankelijkheden. De rest van deze sectie beschrijft de rationale achter de huidige aanbevolen bijwerkmethode. Elke succesvolle bijwerkmethode krijgt te maken met de volgende punten: Het kan voorkomen dat de oude compiler de nieuwe kernel niet kan compileren. (Oude compilers bevatten soms bugs.) De nieuwe kernel dient dus met de nieuwe compiler gebouwd te worden. In het bijzonder moet de nieuwe compiler gebouwd worden voordat de nieuwe kernel gebouwd wordt. Dit betekent niet per se dat de nieuwe compiler geïnstalleerd moet worden voordat de nieuwe kernel gebouwd wordt. De nieuwe wereld kan afhankelijk zijn van mogelijkheden van de nieuwe kernel. Dus moet de nieuwe kernel worden geïnstalleerd voordat de nieuwe wereld wordt geïnstalleerd. De eerste twee gevallen zijn de basis voor de methode buildworld, buildkernel, installkernel, installworld die we in de volgende paragrafen beschrijven. Dit is geen uitputtende lijst van alle redenen waarom het huidige aanbevolen bijwerkproces de voorkeur verdient. Wat minder voor de hand liggende redenen worden hieronder genoemd: Het kan zijn dat de oude wereld niet correct draait op de nieuwe kernel, dus moet de nieuwe wereld onmiddellijk na het installeren van de nieuwe kernel geïnstalleerd worden. Sommige instellingen moeten veranderd worden voordat de nieuwe wereld wordt geïnstalleerd, maar anderen kunnen de oude wereld kapot maken. Vandaar dat over het algemeen twee verschillende bijwerkstappen voor de instellingen nodig zijn. Voor het grootste gedeelte houdt het bijwerkproces zich alleen bezig met het vervangen of toevoegen van bestanden; bestaande oude bestanden worden niet verwijderd. Dit kan in sommige gevallen problemen geven. Als een gevolg zal de bijwerkprocedure soms aangeven dat bepaalde bestanden tijdens bepaalde stappen handmatig verwijderd dienen te worden. Dit kan in de toekomst eventueel geautomatiseerd worden. Deze zorgen hebben tot het volgende aanbevolen bijwerkproces geleid. Merk op dat het gedetailleerde proces voor bepaalde updates aanvullende stappen nodig kan hebben, maar dit kernproces zou de komende tijd ongewijzigd moeten blijven: make buildworld Dit compileert eerst de nieuwe compiler en enkele aanverwante gereedschappen, daarna wordt de nieuwe compiler gebruikt om de rest van de nieuwe wereld te compileren. Het resultaat komt in /usr/obj te staan. make buildkernel In tegenstelling tot de oude aanpak, die &man.config.8; en &man.make.1; gebruikt, gebruikt dit de nieuwe compiler die in /usr/obj verblijft. Dit beschermt u tegen mismatches tussen de compiler en de kernel. make installkernel Plaatst de nieuwe kernel en kernelmodules op de schijf, waardoor het mogelijk wordt om met de nieuw bijgewerkte kernel op te starten. Start opnieuw op in enkele-gebruikersmodus. De enkele-gebruikersmodus minimaliseert problemen met het bijwerken van software die al draait. Het minimaliseert ook problemen die opduiken door een oude wereld op een nieuwe kernel te draaien. mergemaster Dit voert wat initiële updates aan instellingenbestanden uit ter voorbereiding op de nieuwe wereld. Het kan bijvoorbeeld nieuwe gebruikersgroepen aan het systeem, of nieuwe gebruikersnamen aan de wachtwoorddatabase toevoegen. Dit is vaak nodig wanneer er nieuwe groepen of speciale accounts voor systeemgebruikers zijn toegevoegd sinds de laatste keer bijwerken, zodat de stap installworld zonder problemen de nieuw geïnstalleerde namen van systeemgebruikers of systeemgroepen kan gebruiken. make installworld Kopieert de wereld van /usr/obj. U heeft nu een nieuwe kernel en een nieuwe wereld op schijf staan. mergemaster Nu kunt u de overgebleven instellingenbestanden bijwerken, aangezien u een nieuwe wereld op schijf heeft staan. Start opnieuw op. Een volledige nieuwe start van de machine is nodig om de nieuwe kernel en de nieuwe wereld met nieuwe instellingenbestanden te laden. Merk op dat als u van de ene uitgave van dezelfde tak van &os; bijwerkt naar een recentere uitgave van dezelfde tak, i.e. van 7.0 naar 7.1, dat deze procedure dan niet absoluut nodig is, aangezien het onwaarschijnlijk is dat u serieuze problemen krijgt met de compiler, kernel, gebruikersland en instellingenbestanden. De oudere aanpak met make world gevolgd door het bouwen en installeren van een nieuwe kernel kan voor kleine updates goed genoeg zijn. Maar mensen die deze procedure niet volgen tijdens het bijwerken tussen grote uitgaven kunnen wat problemen verwachten. Het is ook goed om op te merken dat veel upgrades (i.e. 4.X naar 5.0) wat specifieke aanvullende stappen nodig hebben (bijvoorbeeld het hernoemen of verwijderen van specifieke bestanden voorafgaand aan installworld). Lees het bestand /usr/src/UPDATING zorgvuldig, met name het einde, waar het huidig aangeraden bijwerkproces expliciet wordt beschreven. Deze procedure is in de loop der tijd veranderd aangezien de ontwikkelaars zagen dat het onmogelijk was om bepaalde mismatch-problemen volledig te voorkomen. Hopelijk blijft de huidige procedure voor een lange tijd stabiel. Het bijwerken van &os; 3.X of eerdere uitgaven is wat lastiger; lees UPDATING zorgvuldig door als u zo'n soort upgrade moet uitvoeren. Samengevat is de huidige aanbevolen manier om &os; vanaf broncode bij te werken: &prompt.root; cd /usr/src &prompt.root; make buildworld &prompt.root; make buildkernel &prompt.root; make installkernel &prompt.root; shutdown -r now 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; 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 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 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 uit /usr/share/examples/etc/make.conf 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. &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 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 van het basissysteem 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 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, een andere target, installeert deze boom op de huidige machine. 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 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. Doorlooptijd world opnieuw bouwen doorlooptijd 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 &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. 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. 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"` 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 het samenvoegen 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 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 en /etc/src.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. diff --git a/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml index fb23034b45..9ce77e6d26 100644 --- a/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -1,3404 +1,3396 @@ &os; verkrijgen CD-ROM en DVD uitgevers Winkelproducten in doos &os; is beschikbaar in een doos (&os; CD-ROMs, additionele software en gedrukte documentatie) bij verschillende verkopers:
CompUSA WWW:
Frys Electronics WWW:
CD-ROMs en DVD's &os; CD-ROMs en DVD's zijn te koop bij veel online winkels:
&os; Mall, Inc. 700 Harvest Park Ste F Brentwood, CA 94513 Verenigde Staten Telefoon: +1 925 240-6652 Fax: +1 925 674-0821 E–mail: info@freebsdmall.com WWW:
Dr. Hinner EDV St. Augustinus-Str. 10 D-81825 München Duitsland Telefoon: (089) 428 419 WWW:
Ikarios 22-24 rue Voltaire 92000 Nanterre Frankrijk WWW:
JMC Software Ierland Telefoon: 353 1 6291282 WWW:
The Linux Emporium Hilliard House, Lester Way Wallingford OX10 9TA Verenigd Koninkrijk Telefoon: +44 1491 837010 Fax: +44 1491 837016 WWW:
Linux+ DVD Magazine Lewartowskiego 6 Warsaw 00-190 Polen Telefoon: +48 22 860 18 18 E–mail: editors@lpmagazine.org WWW:
Linux System Labs Australia 21 Ray Drive Balwyn North VIC - 3104 Australië Telefoon: +61 3 9857 5918 Fax: +61 3 9857 8974 WWW:
LinuxCenter.Ru Galernaya Street, 55 Saint-Petersburg 190000 Rusland Telefoon: +7-812-3125208 E–mail: info@linuxcenter.ru WWW:
Distributeurs Wederverkopers die &os; CD-ROM producten willen verkopen kunnen contact opnemen met een distributeur:
Cylogistics 809B Cuesta Dr., #2149 Mountain View, CA 94040 Verenigde Staten Telefoon: +1 650 694-4949 Fax: +1 650 694-4953 E–mail: sales@cylogistics.com WWW:
Ingram Micro 1600 E. St. Andrew Place Santa Ana, CA 92705-4926 Verenigde Staten Telefoon: 1 (800) 456-8000 WWW:
Kudzu, LLC 7375 Washington Ave. S. Edina, MN 55439 Verenigde Staten Telefoon: +1 952 947-0822 Fax: +1 952 947-0876 E–mail: sales@kudzuenterprises.com
LinuxCenter.Kz Ust-Kamenogorsk Kazachstan Telefoon: +7-705-501-6001 Email: info@linuxcenter.kz WWW:
LinuxCenter.Ru Galernaya Street, 55 Sint-Petersburg 190000 Rusland Telefoon: +7-812-3125208 E–mail: info@linuxcenter.ru WWW:
Navarre Corp 7400 49th Ave South New Hope, MN 55428 Verenigde Staten Telefoon: +1 763 535-8333 Fax: +1 763 535-0341 WWW:
FTP sites De officiële broncode voor &os; is beschikbaar via anoniem toegankelijke FTP in de hele wereld via vele mirrorsites. De site heeft een goede verbinding en staat veel verbindingen toe, maar het is waarschijnlijk beter om een mirrorsite te zoeken die dichterbij is (zeker als het doel is ook een soort mirrorsite op te zetten). De &os; mirrorsites database is beter bijgewerkt dan die in het Handboek omdat die lijst uit DNS komt in plaats van een met de hand ingevoerde lijst. &os; is beschikbaar via de onderstaande anonieme FTP mirror sites. Bij het kiezen van anonieme FTP voor het verkrijgen van &os; wordt aangeraden een site die dichtbij ligt te kiezen. De mirrorsites die in de lijst staan als Primaire Mirrorsites hebben meestal het complete &os; archief (alle beschikbare versies voor alle architecturen) maar downloads zijn waarschijnlijk sneller van een site die in het land of de regio van de gebruiker staat. De regionale sites hebben de meeste recente versies voor de meest populaire architecturen, maar hebben wellicht niet het complete archief. Alle sites geven toegang via anonieme FTP, maar een aantal sites hebben ook andere toegangsmogelijkheden. De toegangsmogelijkheden voor iedere site staan tussen haakjes achter de hostnaam. &chap.mirrors.ftp.inc; BitTorrent BitTorrent De ISO-afbeeldingen voor de basis-CD's van de uitgaven zijn beschikbaar via BitTorrent. Een verzameling torrent-bestanden om de afbeeldingen binnen te halen is beschikbaar op http://torrents.freebsd.org:8080 De software voor de BitTorrent-cliënt is beschikbaar via de port net-p2p/py-bittorrent, of als voorgecompileerd pakket. Nadat de ISO-afbeelding met BitTorrent is gedownload, kan het op CD of DVD gebrand worden zoals beschreven in . Anonieme CVS <anchor id="anoncvs-intro">Inleiding CVS anoniem Anonieme CVS (of ook wel bekend als anoncvs) is een functie die beschikbaar is met de hulpprogramma's die bij &os; zitten om te synchroniseren met een elders aanwezig CVS depot. Het staat gebruikers van &os; onder andere toe om zonder bijzondere rechten alleen-lezen operaties uit te voeren op een van de officiële anoncvs servers van het &os; project. Om het te kunnen gebruiken dient de omgevingsvariabele CVSROOT zo ingesteld te worden dat hij wijst naar de gewenste anoncvs server, dient het bekende wachtwoord anoncvs bij het commando cvs login opgegeven te worden en kan daarna &man.cvs.1; gebruikt worden om het te benaderen als ieder lokaal aanwezig depot. Het commando cvs login slaat de wachtwoorden die voor aanmelden bij de CVS server op in een bestand met de naam .cvspass in de map HOME. Als dit bestand niet bestaat, is het mogelijk dat er een foutmelding wordt gegeven als cvs login de eerste keer wordt gebruikt. Dat kan opgelost worden door een leeg bestand .cvspass te maken en dan opnieuw aan te melden. Hoewel de diensten CVSup en anoncvs beiden vrijwel dezelfde functie invullen, zijn er redenen die de keuze voor de synchronisatiemethode beïnvloeden. In een notendop is CVSup veel efficiënter in het gebruik van netwerkbronnen en is het de meest geavanceerde van de twee, maar daar staat iets tegenover. Voor het gebruik van CVSup moet eerst een speciale client geïnstalleerd en ingesteld worden voordat er bits kunnen gaan stromen en dat kan dan alleen in de redelijk grote brokken die in CVSup collections heten. Anoncvs kan daarentegen gebruikt worden om alles te bekijken van een individueel bestand tot aan een specifiek programma (als ls of grep) door aan de naam van de CVS module te refereren. Ook anoncvs is alleen geschikt voor alleen-lezen operaties op het CVS depot, dus als het de bedoeling is om lokaal ontwikkelwerk en hetzelfde depot met delen uit het &os; project te combineren, dan biedt alleen CVSup daar een oplossing voor. <anchor id="anoncvs-usage">Anonieme CVS gebruiken Het instellen van &man.cvs.1; om gebruik te maken van een Anoniem CVS depot is een kwestie van het instellen van de omgevingsvariabele CVSROOT op een van de anoncvs servers van het &os; project. Op het moment van schrijven zijn de volgende servers beschikbaar: Frankrijk: :pserver:anoncvs@anoncvs.fr.FreeBSD.org:/home/ncvs - (pserver (wachtwoord anoncvs), ssh - (geen wachtwoord) + (Gebruik cvs login voor pserver-modus en voer het + wachtwoord anoncvs in wanneer het gevraagd wordt. + Voor ssh is geen wachtwoord nodig.) - + Taiwan: :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs - (pserver (gebruik cvs login en - vul een willekeurig wachtwoord in wanneer daarom - gevraagd wordt), ssh (geen wachtwoord)) + (Gebruik cvs login voor pserver-modus en voer elk + willekeurig wachtwoord in wanneer het gevraagd wordt. Voor ssh is + geen wachtwoord nodig.) SSH2 HostKey: 1024 02:ed:1b:17:d6:97:2b:58:5e:5c:e2:da:3b:89:88:26 /etc/ssh/ssh_host_rsa_key.pub SSH2 HostKey: 1024 e8:3b:29:7b:ca:9f:ac:e9:45:cb:c8:17:ae:9b:eb:55 /etc/ssh/ssh_host_dsa_key.pub VS: - freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs - (alleen ssh - geen wachtwoord) - - SSH HostKey: 1024 a1:e7:46:de:fb:56:ef:05:bc:73:aa:91:09:da:f7:f4 root@sanmateo.ecn.purdue.edu -SSH2 HostKey: 1024 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65 ssh_host_dsa_key.pub - - - - VS: - anoncvs@anoncvs1.FreeBSD.org:/home/ncvs (alleen ssh2 - geen - wachtwoord) + anoncvs@anoncvs1.FreeBSD.org:/home/ncvs (Gebruik ssh versie 2 voor + ssh, een wachtwoord is niet nodig.) SSH2 HostKey: 2048 4d:59:19:7b:ea:9b:76:0b:ca:ee:da:26:e2:3a:83:b8 ssh_host_dsa_key.pub Omdat met CVS vrijwel iedere versie die ooit beschikbaar is geweest uitgecheckt kan worden, is het van belang op de hoogte te zijn van de &man.cvs.1; vlag voor revisie () en welke waarden zie zoal kan aannemen in het &os; Project depot. Er zijn twee soorten labels (tags): revisielabels en taklabels (branch). Een revisielabel refereert aan een specifieke revisie. De betekenis blijft van dag tot dag gelijk. Aan de andere kant refereert een taklabel aan de laatste revisie in een bepaalde ontwikkellijn op een bepaald moment. Omdat een taklabel niet refereert aan een specifieke revisie, kan die morgen anders zijn dan vandaag. bevat revisielabels waar gebruikers in geïnteresseerd kunnen zijn. Nogmaals: deze zijn allemaal niet geldig voor de Portscollectie omdat de Portscollectie geen meerdere ontwikkel takken kent. Als een specifiek taklabel wordt aangegeven, worden als alles goed gaat, de laatste revisies uit een bepaalde ontwikkellijn ontvangen. Als er een oudere versie opgehaald moet worden, kan dat door met de vlag een datum aan te geven. In &man.cvs.1; staan meer details. Voorbeelden Hoewel het sterk wordt aangeraden eerst de hulppagina's voor &man.cvs.1; grondig door te lezen, volgen hier een aantal snelle voorbeelden die feitelijk aangeven hoe Anonieme CVS gebruikt kan worden. SSH gebruiken om de <filename>src/</filename> tree uit te checken: &prompt.user; cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co src The authenticity of host 'anoncvs.freebsd.org (128.46.156.46)' can't be established. DSA key fingerprint is 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs.freebsd.org' (DSA) to the list of known hosts. Iets uitchecken uit -CURRENT (&man.ls.1;): &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Op de prompt, voer een willekeurig wachtwoord in wachtwoord. &prompt.user; cvs co ls SSH gebruiken om de <filename>src/</filename> structuur uit te checken: &prompt.user; cvs -d freebsdanoncvs@anoncvs.FreeBSD.org:/home/ncvs co src The authenticity of host 'anoncvs.freebsd.org (128.46.156.46)' can't be established. DSA key fingerprint is 52:02:38:1a:2f:a8:71:d3:f5:83:93:8d:aa:00:6f:65. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'anoncvs.freebsd.org' (DSA) to the list of known hosts. De versie van &man.ls.1; in de 6-STABLE tak uitchecken: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Op de prompt, voer een willekeurig wachtwoord in wachtwoord. &prompt.user; cvs co -rRELENG_6 ls Een lijst wijzigingen maken (als unified diffs) voor &man.ls.1; &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Op de prompt, voer een willekeurig wachtwoord in wachtwoord. &prompt.user; cvs rdiff -u -rRELENG_5_3_0_RELEASE -rRELENG_5_4_0_RELEASE ls Uitzoeken welke modulenamen gebruikt kunnen worden: &prompt.user; setenv CVSROOT :pserver:anoncvs@anoncvs.tw.FreeBSD.org:/home/ncvs &prompt.user; cvs login Op de prompt, voer een willekeurig wachtwoord in wachtwoord. &prompt.user; cvs co modules &prompt.user; more modules/modules Andere bronnen De volgende bronnen kunnen bijdragen aan een beter begrip van CVS: CVS Tutorial van California Polytechnic State University. CVS Home, de CVS gemeenschap voor ontwikkeling en ondersteuning. CVSweb is de &os; Project webinterface voor CVS. CTM gebruiken CTM CTM is een methode om een map elders gesynchroniseerd te houden met een centrale. Het is ontwikkeld voor gebruik met de &os; broncode, hoewel sommigen het ook voor andere doeleinden handig vinden. Er bestaat op dit moment weinig tot geen documentatie over het proces van het maken van delta's. Voor informatie over het gebruik van CTM kan het beste contact gezocht worden met de &a.ctm-users.name; mailinglijst. Waarom <application>CTM</application> gebruiken? CTM geeft een lokale kopie van de &os; broncode. Die is in een aantal smaken beschikbaar. Of het gaat om slechts één tak of de complete CVS structuur, CTM kan het bieden. CTM is gewoon gemaakt voor actieve ontwikkelaars die met &os; werken, maar geen of een slechte Internetverbinding hebben of gewoon automatisch de laatste wijzigingen willen ontvangen. De meest actieve takken kennen op z'n hoogst drie delta's per dag. Het is het overwegen waard om ze per automatische mail te laten sturen. De grootte van de updates wordt altijd zo klein mogelijk gehouden. Meestal kleiner dan 5 K en soms (in tien procent van de gevallen) is het 10–50 K. In uitzonderlijke gevallen komt het voor dat een mail van 100 K of meer wordt gestuurd. Het is wel van belang op de hoogte te zijn van de valkuilen die een rol spelen bij het direct werken met broncode in plaats van met een voorverpakte release. Dit geldt nog meer als wordt gewerkt met de current code. Het lezen van Bijblijven met &os; wordt sterk aangeraden. Wat is er nodig om <application>CTM</application> te gebruiken? Voor het gebruik van CTM zijn twee dingen nodig: het CTM programma en de initiële delta's om de applicatie te voeden en naar een current niveau te komen. CTM is al onderdeel van &os; sinds versie 2.0 is uitgebracht en is te vinden in /usr/src/usr.sbin/ctm, als de broncode aanwezig is. De delta's voor CTM kunnen op twee manieren komen: met FTP of per e-mail. De volgende FTP sites bieden ondersteuning voor CTM: Er staan er nog meer in de paragraaf mirrors. FTP de relevante map en download het bestand README vanaf daar. Voor delta's via e-mail: Er dient een abonnement genomen te worden op een van de CTM distributielijsten. &a.ctm-cvs-cur.name; ondersteunt de complete CVS structuur. &a.ctm-src-cur.name; ondersteunt het hoofd van de ontwikkeltak. &a.ctm-src-4.name; ondersteunt de 4.X release tak, enzovoort. Om te abonneren kan geklikt worden op de bovenstaande links of via &a.mailman.lists.link; kan in een lijst geklikt worden op de lijst waarvoor waarvoor een abonnement gewenst is. De lijstpagina bevat instructies over hoe te abonneren. Na het ontvangen van CTM updates per mail, kan ctm_rmail gebruikt worden voor het uitpakken en verwerken. ctm_rmail kan zelfs direct vanuit /etc/aliases gebruikt worden om het proces volledig automatisch te laten verlopen. In de hulppagina van ctm_rmail staan meer details. Welke methode ook gebruikt wordt voor de CTM delta's, het is belangrijk een abonnement te nemen op de &a.ctm-announce.name; mailinglijst. In de toekomst worden alleen op die lijst aankondigingen gedaan over het CTM systeem. Abonneren kan door op de link hierboven te klikken en de instructies te volgen. <application>CTM</application> de eerste keer gebruiken Voordat de CTM delta's gebruikt kunnen worden, moet er een startpunt voor bepaald worden. Eerst moet bepaald worden wat er al is. Het is mogelijk te beginnen vanuit een lege map. Dan moet een initiële Empty delta gebruikt worden om een door CTM ondersteunde structuur te starten. Het is de bedoeling dat deze start delta's ooit voor het gemak op de CD-ROM komen te staan, maar dit is nog niet het geval. Omdat de structuren tientallen megabytes groot zijn, heeft het de voorkeur om al met iets te beginnen. Als er een -RELEASE CD-ROM beschikbaar is, kan de initiële broncode gekopieerd of uitgepakt worden. Dit bespaart nogal wat dataverkeer. De start delta's kunnen herkend worden aan de X die aan het nummer is toegevoegd (bijvoorbeeld src-cur.3210XEmpty.gz). De nummering achter de X komt overeen met de oorsprong van het initiële zaad. Empty is een lege map. Er wordt in het algemeen iedere honderd delta's een basistransitie voor Empty gemaakt. Die zijn trouwens groot: 70 tot 80 Megabytes gzip data is normaal voor de XEmpty delta's. Als er een delta als startpunt is gekozen, zijn ook alle delta's met hogere volgnummers nodig. <application>CTM</application> in het dagelijks leven gebruiken Om de delta's toe te passen: &prompt.root; cd /where/ever/you/want/the/stuff &prompt.root; ctm -v -v /where/you/store/your/deltas/src-xxx.* CTM begrijpt delta's in gzip formaat, dus het niet nodig om eerst gunzip te gebruiken. Dat spaart diskruimte. Tenzij het zeker is van de veiligheid van het proces, doet CTM niets met de structuur. Om een delta te verifiëren kan ook de vlag gebruikt worden en dan komt CTM ook niet aan een structuur. Dan wordt alleen de integriteit van de delta gecontroleerd en of die zonder problemen op de huidige structuur kan worden toegepast. CTM kent nog meer opties die in de hulppagina's worden besproken. Meer is er niet. Iedere keer dat er een delta wordt ontvangen, moet die door CTM gehaald worden om de broncode bijgewerkt te houden. Delta's kunnen het beste niet verwijderd worden als het lastig is ze opnieuw te downloaden. Dan kunnen ze het beste bewaard worden voor het geval er eens iets gebeurt. Zelfs als er alleen floppy's beschikbaar zijn, is het wellicht verstandig die te gebruiken met fdwrite. Lokale wijzigingen behouden Een ontwikkelaar wil graag experimenteren met bestanden in de structuur en die bestanden veranderen. CTM ondersteunt lokale wijzigingen in beperkte mate: alvorens te kijken of bestand foo bestaat, zoekt het eerst naar foo.ctm. Als dat bestand bestaat, past CTM de wijzigigen daarop toe in plaats van op foo. Dit gedrag biedt een eenvoudige mogelijkheid om lokale wijzigingen bij te houden. Dat kan dus door bestanden die gewijzigd gaan worden te kopiëren naar een bestand met dezelfde naam met de toevoeging .ctm. Dan kan er vrijelijk gespeeld worden met de code, terwijl CTM het bestand .ctm bijwerkt. Andere interessante mogelijkheden van <application>CTM</application> Uitvinden wat precies wordt veranderd met bijwerken Het is mogelijk een lijst met wijzigingen te maken die CTM zou maken op het broncodedepot met de optie . Dit is nuttig als het gewenst is om een logboek bij te houden van de wijzigingen, de te wijzigen bestanden voor- of na te bewerken op welke manier dan ook, of als de gebruiker gewoon een beetje paranoïde is. Back-ups maken vóór bijwerken Soms kan het wenselijk zijn om een back-up te maken van alle bestanden die gewijzigd gaan worden door een CTM update. Met back-upt CTM alle bestanden die gewijzigd gaan worden door een CTM delta naar back–upbestand. Te wijzigen bestanden door bijwerken beperken Soms is het wenselijk de reikwijdte voor een CTM update te beperken of kan het wenselijk zijn om maar een paar bestanden bij te werken uit een aantal delta's. Een lijst met bestanden die CTM mag bewerken kan aangegeven worden met de opties en en het opgeven van regular expressions. Om bijvoorbeeld een bijgewerkte kopie van lib/libc/Makefile te maken uit de verzameling met opgeslagen CTM delta's, kan het volgende commando uitgevoerd worden: &prompt.root; cd /where/ever/you/want/to/extract/it/ &prompt.root; ctm -e '^lib/libc/Makefile' ~ctm/src-xxx.* Voor ieder te wijzigen bestand in een CTM delta worden de opties en toegepast in de volgorde waarin ze op de commandoregel staan. Het bestand wordt alleen door CTM verwerkt als het passend is bevonden na het toepassen van alle parameters in en . Toekomstige plannen voor <application>CTM</application> Die zijn er: Een of andere vorm van authenticatie in het CTM systeem bouwen zodat vervalste CTM updates afgevangen kunnen worden; De opties voor CTM opruimen omdat ze verwarrend zijn geworden. Nog meer Er zijn ook delta's voor de portscollectie, maar daar is nog niet zo veel belangstelling voor. CTM mirrors CTM/&os; is op de volgende mirrorsites via anonieme FTP beschikbaar. Als voor CTM anonieme FTP wordt gebruikt, heeft het de voorkeur een site die in geografische zin dichtbij is te gebruiken. Bij problemen kan contact gezocht worden met de &a.ctm-users.name; mailinglijst. Californië, Bay Area, officiële bron Zuid-Afrika, back-upserver voor oude delta's Taiwan/R.O.C. Als er geen mirror dichtbij is of als die incompleet is, kan een zoekmachine als alltheweb gebruikt worden. CVSup gebruiken Inleiding CVSup is een softwarepakket voor het verspreiden en bijwerken van broncodestructuren vanaf een master CVS depot op een andere server. De &os; broncode wordt beheerd in een broncode depot op een centrale ontwikkelmachine in Californië. Met CVSup kunnen &os; gebruikers op eenvoudige wijze hun broncode bijwerken. CVSup gebruikt een zogenaamd pull model voor het bijwerken. In het pull-model vraagt iedere client de server om updates als die nodig zijn. De server wacht passief op een verzoek om updates van zijn clients. Alle updates worden dus op initiatief van de client gedaan. De server stuurt nooit ongevraagde updates. Gebruikers moeten de CVSup client handmatig draaien om te updaten of een cron taak instellen om op regelmatige basis bij te werken. De term CVSup, op de gegeven wijze geschreven, doelt op het complete softwarepakket. De belangrijkste componenten zijn de client cvsup, die op de machine van een gebruiker draait, en de server cvsupd, die op alle &os; mirrorsites draait. In de &os; documentatie en op de mailinglijsten zijn referenties aan sup te vinden. Sup was de voorloper van CVSup en diende hetzelfde doel. CVSup wordt op dezelfde manier gebruikt als sup en gebruikt zelfs bestanden met instellingen die ook te gebruiken zijn met sup. Sup wordt niet langer gebruikt in het &os; project omdat CVSup sneller en flexibeler is. De csup applicatie is een herschreven versie van CVSup in de C taal. Het grootste voordeel ervan is dat het sneller is en dat het niet afhankelijk is van de Modula-3 taal, dus dat hoeft niet geïnstalleerd te worden als afhankelijkheid. Sterker nog als gebruik wordt gemaakt van &os; 6.2 of later, wordt de applicatie standaard meegeleverd, oudere versies hebben dit echter niet, maar deze kunnen simpel de net/csup port installeren of een vooraf gecompileerd pakket. Als ervoor gekozen is om csup te gebruiken, sla dan de installatie stappen voor CVSup over en vervang de referenties naar CVSup met csup terwijl de rest van het artikel gevolgd wordt. Installatie De meest eenvoudige wijze van installatie van CVSup is met het voorgecompileerde pakket net/cvsup uit de &os; pakkettencollectie. Als het gewenst is, kan CVSup ook uit de broncode gebouwd worden in net/cvsup. De net/cvsup port is afhankelijk van het Modula-3 systeem en dat kan wel even duren en er is ook nogal wat schijfruimte voor nodig om het te downloaden en te bouwen. Als CVSup gebruikt gaat worden op een machine waarop geen &xfree86; of &xorg; staat, zoals een server, dan dient de port waar geen CVSup GUI bij zit geïnstalleerd te worden: net/cvsup-without-gui. Als csup geïnstalleerd moet worden op &os; 6.1 of eerder, kan gebruik gemaakt worden van een van te voren gecompileerd net/csup pakket van de &os; pakkettencollectie, of als de voorkeur wordt gegeven aan het volledig compileren van csup, kan gebruik gemaakt worden van de net/csup port. CVSup instellingen De werking van CVSup wordt gestuurd door een bestand met instellingen met de naam supfile. Er staan een aantal supfiles als voorbeeld in de map /usr/share/examples/cvsup/. De informatie in een supfile beantwoordt de volgende vragen voor CVSup: Welke bestanden moeten ontvangen worden? Welke versies daarvan moeten ontvangen worden? Waar moeten ze vandaan komen? Waar moeten ze komen te staan? Waar moet cvsup zijn statusbestanden bijhouden? In de volgende paragrafen wordt een supfile bestand opgebouwd door achtereenvolgens alle gestelde vragen te beantwoorden. Als eerste wordt de algemene structuur van een supfile beschreven. Een supfile is een tekstbestand. Commentaar begint met een # en loopt tot het einde van de regel. Lege regels en regels die alleen commentaar bevatten worden genegeerd. Iedere regel die overblijft slaat op een groep bestanden die ontvangen moet worden. De regel begint met de naam van een collectie, een logische groep bestanden op de server. De naam van de collectie geeft de server aan welke bestanden er gestuurd moeten worden. Na de naam van de collectie komen er geen of meer velden die gescheiden worden door witruimte. Die velden beantwoorden de hierboven gestelde vragen. Er zijn twee soorten velden: vlagvelden en waardevelden. Een vlagveld bestaat uit een alleenstaand sleutelwoord, bijvoorbeeld delete of compress. Een waardeveld begint ook met een sleutelwoord, maar het sleutelwoord wordt direct (zonder witruimte) gevolgd door = en een tweede woord. release=cvs is bijvoorbeeld een waardeveld. In een supfile wordt meestal aangegeven dat er meerdere collecties ontvangen moeten worden. Het is mogelijk om een supfile te structureren door expliciet alle relevante velden aan te geven voor iedere collectie, maar dat maakt de regels in de supfile nogal lang en het is onhandig omdat de meeste velden hetzelfde zijn voor alle collecties in een supfile. CVSup biedt een systeem met standaardinstellingen om dit probleem te omzeilen. Regels die beginnen met de speciale pseudo-collectienaam *default kunnen gebruikt worden om standaarden in te stellen voor de collecties die er in de supfile achteraan komen. Een standaardwaarde kan voor individuele collecties overschreven worden door een andere waarde in de collectie zelf aan te geven. Standaarden kunnen ook middenin het bestand gewijzigd of aangevuld worden met extra *default regels. Na deze achtergronden wordt er nu een supfile samengesteld voor het ontvangen en bijwerken van de hoofd broncodestructuur van &os;-CURRENT. Welke bestanden moeten ontvangen worden? De bestanden die via CVSup beschikbaar zijn, zijn beschikbaar in groepen die collecties heten. De beschikbare collecties staan beschreven in de volgende paragraaf. In dit voorbeeld is het de bedoeling dat de hele hoofd broncodestructuur voor &os; wordt ontvangen. Daar is één grote collectie voor: src-all. De eerste stap in het maken van een supfile is het opsommen van de gewenste collecties, één per regel (in dit geval maar één regel): src-all Welke versies daarvan moeten ontvangen worden? Met CVSup kan vrijwel iedere versie van de broncode die ooit heeft bestaan opgehaald worden. Dat kan omdat de cvsupd server direct vanaf het CVS depot werkt, dat alle versies bevat. Er kan aangegeven welke ontvangen moeten worden met de waardevelden tag= en . Voorzichtigheid is geboden bij het correct aangeven van velden met tag=. Sommige labels zijn alleen geldig voor bepaalde collecties of bestanden. Als ze incorrect worden aangeven of als er een spelfout wordt gemaakt in een label, verwijdert CVSup bestanden waarvan dat waarschijnlijk niet de bedoeling is. Het label tag=. dient eigenlijk alleen gebruikt te worden voor de ports-* collecties. Het veld tag= benoemt een symbolisch label in het depot. Er zijn twee soorten labels: revisielabels en taklabels. Een revisielabel refereert aan een specifieke revisie. De betekenis blijft altijd hetzelfde. Een taklabel refereert echter aan de laatste revisie van een gegeven ontwikkellijn op een gegeven moment. Omdat een taklabel niet refereert aan een specifieke revisie, kan het morgen iets anders betekenen dan vandaag. beschrijft de meest interessante taklabels. Als er in het instellingenbestand van CVSup een label wordt aangegeven, moet dat vooraf gegaan worden door tag= (RELENG_4 zal tag=RELENG_4 worden). Voor de Portscollectie is alleen tag=. relevant. Labels dienen exact zo ingegeven te worden als ze staan beschreven. CVSup kan geen onderscheid maken tussen geldige en ongeldige labels. Als er een spelfout in een label wordt gemaakt, doet CVSup alsof er een geldig label is ingegeven dat aan geen enkel bestand refereert. Dan zal CVSup de bestaande broncode wissen. Bij het aangeven van een taklabel wordt meestal de laatste versie van de bestanden voor een bepaalde ontwikkellijn ontvangen. Om een oudere versie te ontvangen kan in het veld een datum opgegeven worden. In &man.cvsup.1; staat hoe dat werkt. Om bijvoorbeeld &os;-CURRENT te ontvangen dient het volgende aan het begin van supfile toegevoegd te worden: *default tag=. Er ontstaat een belangrijk speciaal geval als er geen velden met tag= of date= worden aangegeven. In dat geval worden de eigenlijke RCS bestanden direct uit het CVS depot van de server ontvangen in plaats van dat een bepaalde versie wordt ontvangen. Ontwikkelaars geven in het algemeen de voorkeur aan deze optie. Door zelf een kopie van de broncode op hun systeem te hebben, krijgen ze de mogelijkheid om zelf door eerdere versies van bestanden te bladeren en de geschiedenis ervan te bekijken. Dit voordeel kost wel veel schijfruimte. Waar moeten ze vandaan komen? Het veld host= wordt gebruikt om cvsup aan te geven waar de updates vandaan moeten komen. Dat kan van elke CVSup mirrorsite, hoewel er wordt aangeraden een site die geografisch dichtbij ligt te kiezen. In dit voorbeeld wordt een fictieve &os; distributiesite gebruikt, cvsup99.FreeBSD.org: *default host=cvsup99.FreeBSD.org In een werkelijke situatie dient de hostnaam gewijzigd te worden in een host die echt bestaat voordat CVSup gaat draaien. Iedere keer dat cvsup wordt gestart, kan er een andere host op de commandoregel opgegeven worden met de optie . Waar moeten ze komen te staan? Het veld prefix= geeft cvsup aan waar de ontvangen bestanden terecht moeten komen. In dit voorbeeld worden de bestanden direct in de hoofd broncodestructuur /usr/src geplaatst. De map src is al impliciet in de gekozen collecties, vandaar dat het onderstaande de juiste instelling is: *default prefix=/usr Waar moet cvsup zijn statusbestanden bijhouden? De CVSup client houdt statusbestanden bij in een map die base wordt genoemd. Die bestanden helpen CVSup efficiënter te werken door bij te houden welke updates al eerder zijn ontvangen. Hier wordt de standaard basemap gebruikt, /var/db: *default base=/var/db De bovenstaande instelling wordt standaard gebruikt als die niet wordt aangegeven in de supfile, dus hij is eigenlijk niet nodig. Als de basemap niet al bestaat, moet die gemaakt worden. De cvsup client weigert te draaien als de basemap niet bestaat. Allerlei supfile instellingen: Er is nog een regel die in een supfile moet staan: *default release=cvs delete use-rel-suffix compress release=cvs geeft de server aan dat de informatie uit het &os; hoofd CVS depot moet komen. Dat is eigenlijk altijd het geval, maar er zijn mogelijkheden die buiten het bereik van dit handboek vallen. delete geeft CVSup het recht om bestanden te verwijderen. Dit moet altijd aangegeven worden zodat CVSup de broncode altijd kan bijwerken. CVSup gaat voorzichtig om met het verwijderen van bestanden waar het verantwoordelijk voor is. Extra bestanden in de structuur worden met rust gelaten. use-rel-suffix is nogal geheimzinnig. Voor de nieuwsgierigen staat er meer over in &man.cvsup.1;. Anders kan het gewoon ingesteld worden zonder erover na te denken. compress schakelt het gebruikt van gzip compressie in voor het communicatiekanaal. Als de verbinding een E1 of sneller is, hoeft er geen compressie gebruikt te worden. Anders helpt het aanzienlijk. Alles combinerend: Hieronder staat de hele supfile uit het voorbeeld: *default tag=. *default host=cvsup99.FreeBSD.org *default prefix=/usr *default base=/var/db *default release=cvs delete use-rel-suffix compress src-all Het bestand <filename>refuse</filename> Zoals hierboven al is aangegeven, gebruikt CVSup een pull methode. Dat betekent eigenlijk dat er een verbinding wordt gemaakt met de CVSup server en die zegt dan: Dit kan er van mij gedownload worden..., en dan antwoordt de client met: Oké, ik wil dit en dat en zus en zo. Met de standaardinstellingen haalt de CVSup client alle bestanden die bij een collectie en het label horen dat in het bestand met de instellingen is opgegeven. Maar dat is niet altijd wenselijk, in het bijzonder als de doc, ports of www structuren worden gesynchroniseerd. De meeste mensen kunnen geen vier of vijf talen lezen en die hebben de taalspecifieke bestanden dus niet nodig. Als de Portscollectie met CVSup wordt opgehaald, is het mogelijk om iedere collectie apart aan te geven (bijvoorbeeld ports-astrology, ports-biology, enzovoort, in plaats van eenvoudigweg ports-all). Maar omdat de doc en www structuren geen taalspecifieke collecties hebben, moet er gebruik gemaakt worden van een van de vele mooie mogelijkheden van CVSup: het bestand refuse. Het bestand refuse geeft CVSup in feite aan dat niet ieder bestand uit een collectie opgehaald moet worden. Het geeft dus aan dat de client bepaalde bestanden van de server moet weigeren. Het bestand refuse staat in (of kan gemaakt worden in) base/sup/. base staat ingesteld in supfile. De standaardlocatie voor base is /var/db. De standaardplaats voor refuse is dus /var/db/sup/refuse. Het bestand refuse heeft een erg eenvoudige opmaak. Het bevat de namen van de bestanden die niet gedownload mogen worden. Als een gebruiker bijvoorbeeld geen andere talen spreekt dan Engels en Nederlands, maar de Nederlandse vertaling van de documentatie hoeft niet binnengehaald te worden, dan kan het volgende in het bestand refuse gezet worden: doc/bn_* doc/da_* doc/de_* doc/el_* doc/es_* doc/fr_* doc/hu_* doc/it_* doc/ja_* doc/mn_* doc/nl_* doc/no_* doc/pl_* doc/pt_* doc/ru_* doc/sr_* doc/tr_* doc/zh_* Dit gaat zo door voor de andere talen. De volledige lijst staat in het &os; CVS depot. Met deze handige eigenschap kunnen gebruikers met langzamere verbindingen of zij die per minuut voor hun Internetverbinding betalen waardevolle tijd besparen omdat er geen bestanden meer gedownload worden die nooit gebruikt worden. Meer informatie over refuse bestanden en andere leuke mogelijkheden van CVSup staat in de handleiding. <application>CVSup</application> draaien Nu kan het bijwerken beginnen. Het commando is best wel eenvoudig: &prompt.root; cvsup supfile De supfile is de naam van het supfile bestand dat gebruikt moet worden. Aangenomen dat er X11 draait op een machine, toont cvsup een GUI venster met wat knoppen om de bekende acties uit te voeren. Het proces start na het klikken op de knop go. Omdat in dit voorbeeld de werkelijke structuur in /usr/src wordt bijgewerkt, moet het programma als root uitgevoerd worden, zodat cvsup de rechten heeft die het nodig heeft om de bestanden bij te werken. Het is voorstelbaar dat de benodigde rechten, het net gemaakte bestand met instellingen en het voor de eerste keer draaien van een programma zorgt voor wat onrust. Daarom is het mogelijk proef te draaien zonder dat er bestanden gewijzigd worden. Dat kan door ergens een lege map te maken en een extra argument mee te geven op de commandoregel: &prompt.root; mkdir /var/tmp/dest &prompt.root; cvsup supfile /var/tmp/dest De opgegeven map is de bestemming voor alle bestandsupdates. CVSup bekijkt wel de bestanden in /usr/src, maar wijzigt ze niet. Alle updates belanden in /var/tmp/dest/usr/src. CVSup werkt ook de statusbestanden niet bij als het op deze wijze wordt uitgevoerd. De nieuwe versies van de bestanden worden naar de aangegeven map geschreven. Als er maar leestoegang is tot /usr/src, hoeft een gebruiker zelfs geen root te zijn bij het uitvoeren van dit experiment. Als er geen X11 draait of als het niet wenselijk is een GUI te gebruiken, dan kunnen daarvoor opties op de commandoregel meegegeven worden bij het draaien van cvsup: &prompt.root; cvsup -g -L 2 supfile De optie geeft CVSup aan dat de GUI niet gebruikt hoeft te worden. Dit gebeurt automatisch als X11 niet draait, maar anders moet het aangegeven worden. De optie geeft CVSup aan dat details getoond moeten worden over alle bestanden die bijgewerkt worden. Er zijn drie niveaus van uitvoerigheid, van tot . Standaard is het 0, wat betekent dat er geen enkel bericht wordt getoond, met uitzondering van foutmeldingen. Er zijn nog veel andere opties beschikbaar. Met cvsup -H wordt een lijst met korte uitleg getoond. Beschrijvingen met meer details staan in de handleiding. Als het bijwerken op de gewenste manier loopt, kan het regulier draaien van CVSup met &man.cron.8; ingesteld worden. Natuurlijk hoort CVSup zonder GUI te draaien als het programma vanuit de &man.cron.8; draait. <application>CVSup</application> bestandscollecties De via CVSup beschikbare bestandscollecties zijn hiërarchisch georganiseerd. Er zijn een paar grote collecties en die zijn opgedeeld in kleinere subcollecties. Het ontvangen van een collectie is hetzelfde als het ontvangen van alle subcollecties. De hiërarchische relatie tussen de collecties wordt hieronder aangegeven door het niveau van inspringen. De meest gebruikte collecties zijn src-all en ports-all. De andere collecties worden door kleine groepen mensen gebruikt voor bijzondere doeleinden en sommige mirrorsites hebben ze niet allemaal. cvs-all release=cvs Het &os; CVS hoofddepot, inclusief de cryptografische code. distrib release=cvs Bestanden die betrekking hebben op het verspreiden en spiegelen van &os;. doc-all release=cvs Broncode voor het &os; Handboek en andere documentatie, zonder de bestanden voor de &os; website. ports-all release=cvs De &os; Portscollectie. Als ports-all (het complete portssysteem) niet bijgewerkt hoeft te worden, maar enkele van de onderstaande subcollecties, dan moet altijd ook de ports-base subcollectie bijgewerkt worden! Als er iets wijzigt in de infrastructuur van de ports waar ports–base voor staat, is het vrijwel zeker dat die wijzigingen heel snel door echte ports gebruikt gaan worden. Dus als alleen de echte ports bijgewerkt worden en als die gebruik maken van nieuwe mogelijkheden, dan is de kans groot dat het bouwen daarvan foutloopt met een vage foutmelding. Het eerste dat gedaan moeten worden is ervoor zorgen dat de ports-base subcollectie is bijgewerkt. Bij het zelf bouwen van een lokale kopie van ports/INDEX moet ports-all geaccepteerd worden (de hele port structuur). Het bouwen van ports/INDEX met een gedeeltelijke structuur wordt niet ondersteund. Zie ook de FAQ. ports-accessibility release=cvs Software voor minder valide gebruikers. ports-arabic release=cvs Ondersteuning voor de Arabische taal. ports-archivers release=cvs Archiveringshulpmiddelen. ports-astro release=cvs Astronomie ports. ports-audio release=cvs Geluidsondersteuning. ports-base release=cvs De infrastructuur van de Portscollectie. Bestanden uit de mappen Mk/ en Tools/ van /usr/ports. Zie ook de belangrijke waarschuwing hierboven: deze subcollectie dient altijd bijgewerkt te worden als er een onderdeel van de &os; Portscollectie wordt bijgewerkt! ports-benchmarks release=cvs Benchmarks. ports-biology release=cvs Biologie. ports-cad release=cvs Computer aided design programma's. ports-chinese release=cvs Ondersteuning voor de Chinese taal. ports-comms release=cvs Communicatiesoftware. ports-converters release=cvs Karaktercode omzetters. ports-databases release=cvs Databases. ports-deskutils release=cvs Dingen die op een bureaublad stonden voordat computers waren uitgevonden. ports-devel release=cvs Ontwikkelhulpmiddelen. ports-dns release=cvs DNS gerelateerde software. ports-editors release=cvs Editors. ports-emulators release=cvs Emulatoren voor besturingssystemen. ports-finance release=cvs Monetaire, financiële en gerelateerde applicaties. ports-ftp release=cvs FTP client en server programma's. ports-games release=cvs Spelletjes. ports-german release=cvs Ondersteuning voor de Duitse taal. ports-graphics release=cvs Grafische programma's. ports-hebrew release=cvs Ondersteuning voor de Hebreeuwse taal. ports-hungarian release=cvs Ondersteuning voor de Hongaarse taal. ports-irc release=cvs Internet Relay Chat hulpprogramma's. ports-japanese release=cvs Ondersteuning voor de Japanse taal. ports-java release=cvs &java; programma's. ports-korean release=cvs Ondersteuning voor de Koreaanse taal. ports-lang release=cvs Programmeertalen. ports-mail release=cvs Mailsoftware. ports-math release=cvs Numerieke rekensoftware. ports-mbone release=cvs MBone applicaties. ports-misc release=cvs Verschillende programma's. ports-multimedia release=cvs Multimedia software. ports-net release=cvs Netwerksoftware. ports-net-im release=cvs Berichtenuitwisseling. ports-net-mgmt release=cvs Netwerkbeheersoftware. ports-net-p2p release=cvs Peer to Peer Netwerken ports-news release=cvs USENET news software. ports-palm release=cvs Softwareondersteuning voor Palm apparatuur. ports-polish release=cvs Ondersteuning voor de Poolse taal. ports-ports-mgmt release=cvs Programma's om ports en pakketten te beheren. ports-portuguese release=cvs Ondersteuning voor de Portugese taal. ports-print release=cvs Printsoftware. ports-russian release=cvs Ondersteuning voor de Russische taal. ports-science release=cvs Wetenschappelijk. ports-security release=cvs Beveiligingsprogramma's. ports-shells release=cvs Commandoregelshells. ports-sysutils release=cvs Systeemprogramma's. ports-textproc release=cvs Tekstverwerkingsprogramma's (zonder desktop publishing). ports-ukrainian release=cvs Ondersteuning voor de Oekraïense taal. ports-vietnamese release=cvs Ondersteuning voor de Viëtnamese taal. ports-www release=cvs Software gerelateerd aan het Wereldwijde Web. ports-x11 release=cvs Ports voor het X windowsysteem. ports-x11-clocks release=cvs X11 klokken. ports-x11-drivers release=cvs X11-stuurprogramma's ports-x11-fm release=cvs X11 bestandsbeheerders. ports-x11-fonts release=cvs X11 lettertypen en lettertypeprogramma's. ports-x11-toolkits release=cvs X11 hulpprogramma's. ports-x11-servers release=cvs X11 servers. ports-x11-themes X11 thema's. ports-x11-wm release=cvs X11 vensterbeheerprogramma's. projects-all release=cvs Broncode's voor de &os; projecten repository. src-all release=cvs De hoofdbroncode van &os;, inclusief de cryptografische code. src-base release=cvs Verschillende bestanden bovenin de /usr/src structuur. src-bin release=cvs Gebruikersprogramma's die wellicht nodig zijn in single-user modus (/usr/src/bin). src-cddl release=cvs Programma's en bibliotheken die uitgegeven zijn onder de CDDL licentie (/usr/src/cddl). src-contrib release=cvs Programma's en bibliotheken van buiten het &os; project die vrijwel ongewijzigd gebruikt worden (/usr/src/contrib). src-crypto release=cvs Cryptografische programma's en bibliotheken van buiten het &os; project, die vrijwel ongewijzigd worden gebruikt (/usr/src/crypto). src-eBones release=cvs Kerberos en DES (/usr/src/eBones). Niet gebruikt in recente uitgaves van &os;. src-etc release=cvs Bestanden met systeeminstellingen (/usr/src/etc). src-games release=cvs Spelletjes (/usr/src/games). src-gnu release=cvs Programma's die onder de GNU Public License vallen (/usr/src/gnu). src-include release=cvs Headerbestanden (/usr/src/include). src-kerberos5 release=cvs Kerberos5 beveiligingspakket (/usr/src/kerberos5). src-kerberosIV release=cvs KerberosIV beveiligingspakket (/usr/src/kerberosIV). src-lib release=cvs Bibliotheken (/usr/src/lib). src-libexec release=cvs Systeemprogramma's die meestal door andere programma's worden uitgevoerd (/usr/src/libexec). src-release release=cvs Bestanden die nodig zijn voor het maken van een &os; release (/usr/src/release). src-release release=cvs Statisch gelinkte programma's voor nood onderhoud, zie &man.rescue.8; (/usr/src/rescue). src-sbin release=cvs Systeemprogramma's voor single-user modus (/usr/src/sbin). src-secure release=cvs Cryptografische bibliotheken en commando's (/usr/src/secure). src-share release=cvs Bestanden die tussen meerdere systemen gedeeld kunnen worden (/usr/src/share). src-sys release=cvs De kernel (/usr/src/sys). src-sys-crypto release=cvs Cryptografische kernelcode (/usr/src/sys/crypto). src-tools release=cvs Verschillende hulpprogramma's voor het onderhoud van &os; (/usr/src/tools). src-usrbin release=cvs Gebruikersprogramma's (/usr/src/usr.bin). src-usrsbin release=cvs Systeemprogramma's (/usr/src/usr.sbin). www release=cvs De broncode voor de &os; website. distrib release=self De instellingenbestanden van de CVSup server zelf. Gebruikt door de CVSup mirrorsites. gnats release=current De GNATS bug-tracking database. mail-archive release=current &os; mailinglijstarchief. www release=current De voorbewerkte &os; websitebestanden (niet de broncode). Gebruikt door WWW mirrorsites. Voor meer informatie De CVSup FAQ en andere informatie over CVSup is te vinden op De CVSup Homepage. De meeste &os;–gerelateerde discussie over CVSup vindt plaats op de &a.hackers;. Daar worden nieuwe versies van de software aangekondigd, net als op de &a.announce;. Voor vragen en foutrapporten moet een kijkje genomen worden op de CVSup FAQ CVSup sites CVSup servers voor &os; draaien op de onderstaande sites. &chap.mirrors.cvsup.inc; CVS labels Bij het ophalen of bijwerken van broncode met cvs of CVSup moet een revisielabel meegegeven worden. Een revisielabel refereert aan een specifieke lijn in de &os; ontwikkeling of aan een specifiek moment in de tijd. Het eerste type heet taklabel (branch tag) en het tweede type heet releaselabel (release tag). Taklabels Deze zijn, met uitzondering van HEAD (dat altijd een geldig label is), alleen van toepassing op de src/ structuur. De ports/, doc/ en www/ structuren kennen geen takken. HEAD Symbolische naam voor de hoofdlijn van &os;-CURRENT. Ook de standaard als geen revisie is aangegeven. In CVSup wordt dit label aangegeven met een . (dat is dus geen interpunctie, maar een echt . karakter). In CVS is dit de standaard als er geen revisielabel is aangegeven. Het is meestal geen goed idee om een checkout of update van CURRENT broncode op een STABLE machine te doen, tenzij dat expliciet de bedoeling is. RELENG_8 De ontwikkellijn voor &os;-8.X, ook bekend als &os; 8-STABLE. RELENG_8_0 De uitgavetak voor &os;-8.0, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_7 De ontwikkellijn voor &os;-7.X, ook bekend als &os; 7-STABLE. RELENG_7_3 De uitgavetak voor &os;-7.3, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_7_2 De uitgavetak voor &os;-7.2, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_7_1 De uitgavetak voor &os;-7.1, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_7_0 De uitgavetak voor &os;-7.0, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_6 De ontwikkellijn voor &os;-6.X, ook bekend als &os; 6-STABLE. RELENG_6_4 De uitgavetak voor &os;-6.4, alleen gebruikt voor beveiligingsadviezen en andere kritieke reparaties. RELENG_6_3 De uitgavetak voor &os;-6.3, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_6_2 De releasetak voor &os;-6.2, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_6_1 De releasetak voor &os;-6.1, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_6_0 De releasetak voor &os;-6.0, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5 De ontwikkellijn voor &os;-5.X, ook bekend als &os; 5-STABLE. RELENG_5_5 De releasetak voor &os;-5.5, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5_4 De releasetak voor &os;-5.4, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5_3 De releasetak voor &os;-5.3, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5_2 De releasetak voor &os;-5.2 en &os;-5.2.1, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5_1 De releasetak voor &os;-5.1, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_5_0 De releasetak voor &os;-5.0, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4 De ontwikkellijn voor &os;-4.X, ook bekend als &os; 4-STABLE. RELENG_4_11 De releasetak voor &os;-4.11, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_10 De releasetak voor &os;-4.10, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_9 De releasetak voor &os;-4.9, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_8 De releasetak voor &os;-4.8, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_7 De releasetak voor &os;-4.7, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_6 De releasetak voor &os;-4.6 en &os;-4.6.2, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_5 De releasetak voor &os;-4.5, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_4 De releasetak voor &os;-4.4, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_4_3 De releasetak voor &os;-4.3, alleen gebruikt voor beveiligingswaarschuwingen en andere kritische aanpassingen. RELENG_3 De ontwikkellijn voor &os;-3.X, ook bekend als 3.X-STABLE. RELENG_2_2 De ontwikkellijn voor &os;-2.2.X, ook bekend als 2.2-STABLE. Deze tak is sterk verouderd. Releaselabels Deze labels refereren aan een specifiek moment in de tijd waarop een versie van &os; is uitgegeven. Het proces om tot een release te komen is gedetailleerder beschreven in de Release Engineering Informatie en Release Proces documenten. De src structuur gebruikt labelnamen die beginnen met RELENG_ labels. De ports en doc structuren gebruiken labels waarvan de naam begint met het label RELEASE. De www tenslotte, is niet gemarkeerd met een bijzondere naam bij releases. RELENG_8_0_0_RELEASE &os; 8.0 RELENG_7_3_0_RELEASE &os; 7.3 RELENG_7_2_0_RELEASE &os; 7.2 RELENG_7_1_0_RELEASE &os; 7.1 RELENG_7_0_0_RELEASE &os; 7.0 RELENG_6_4_0_RELEASE &os; 6.4 RELENG_6_3_0_RELEASE &os; 6.3 RELENG_6_2_0_RELEASE &os; 6.2 RELENG_6_1_0_RELEASE &os; 6.1 RELENG_6_0_0_RELEASE &os; 6.0 RELENG_5_5_0_RELEASE &os; 5.5 RELENG_5_4_0_RELEASE &os; 5.4 RELENG_4_11_0_RELEASE &os; 4.11 RELENG_5_3_0_RELEASE &os; 5.3 RELENG_4_10_0_RELEASE &os; 4.10 RELENG_5_2_1_RELEASE &os; 5.2.1 RELENG_5_2_0_RELEASE &os; 5.2 RELENG_4_9_0_RELEASE &os; 4.9 RELENG_5_1_0_RELEASE &os; 5.1 RELENG_4_8_0_RELEASE &os; 4.8 RELENG_5_0_0_RELEASE &os; 5.0 RELENG_4_7_0_RELEASE &os; 4.7 RELENG_4_6_2_RELEASE &os; 4.6.2 RELENG_4_6_1_RELEASE &os; 4.6.1 RELENG_4_6_0_RELEASE &os; 4.6 RELENG_4_5_0_RELEASE &os; 4.5 RELENG_4_4_0_RELEASE &os; 4.4 RELENG_4_3_0_RELEASE &os; 4.3 RELENG_4_2_0_RELEASE &os; 4.2 RELENG_4_1_1_RELEASE &os; 4.1.1 RELENG_4_1_0_RELEASE &os; 4.1 RELENG_4_0_0_RELEASE &os; 4.0 RELENG_3_5_0_RELEASE &os;-3.5 RELENG_3_4_0_RELEASE &os;-3.4 RELENG_3_3_0_RELEASE &os;-3.3 RELENG_3_2_0_RELEASE &os;-3.2 RELENG_3_1_0_RELEASE &os;-3.1 RELENG_3_0_0_RELEASE &os;-3.0 RELENG_2_2_8_RELEASE &os;-2.2.8 RELENG_2_2_7_RELEASE &os;-2.2.7 RELENG_2_2_6_RELEASE &os;-2.2.6 RELENG_2_2_5_RELEASE &os;-2.2.5 RELENG_2_2_2_RELEASE &os;-2.2.2 RELENG_2_2_1_RELEASE &os;-2.2.1 RELENG_2_2_0_RELEASE &os;-2.2.0 AFS sites Er draaien AFS servers voor &os; op de volgende sites: Zweden Het pad naar de bestanden is: /afs/stacken.kth.se/ftp/pub/FreeBSD/ stacken.kth.se # Stacken Computer Club, KTH, Sweden 130.237.234.43 #hot.stacken.kth.se 130.237.237.230 #fishburger.stacken.kth.se 130.237.234.3 #milko.stacken.kth.se Beheerder: ftp@stacken.kth.se rsync sites De volgende sites bieden &os; aan via het protocol rsync. Het programma rsync werkt vrijwel hetzelfde als &man.rcp.1;, maar kent meer mogelijkheden en gebruikt het rsync remote-update protocol, dat alleen verschillen tussen twee groepen bestanden overbrengt, waardoor het synchroniseren via een netwerk drastisch wordt versneld. Dit kan het beste gedaan worden als er een mirrorsite voor de &os; FTP server of het &os; CVS depot draait. De rsync suite is voor veel besturingssystemen beschikbaar. Voor &os; kan het pakket of de port uit net/rsync geïnstalleerd worden. Tsjechië rsync://ftp.cz.FreeBSD.org/ Beschikbare collecties: ftp: een gedeeltelijke mirror van de &os; FTP server. &os;: een volledige mirror van de &os; FTP server. Nederland rsync://ftp.nl.FreeBSD.org/ Beschikbare collecties: &os;: een volledige mirror van de &os; FTP server. Rusland rsync://ftp.mtu.ru/ Beschikbare collecties: &os;: een volledige spiegel van de FTP-server van &os;. &os;-gnats: De GNATS bug-tracking database. &os;-archief: spiegel van de &os; Archive FTP-server. Taiwan rsync://ftp.tw.FreeBSD.org/ rsync://ftp2.tw.FreeBSD.org/ rsync://ftp6.tw.FreeBSD.org/ Beschikbare collecties: FreeBSD: een volledige mirror van de &os; FTP server. Verenigd Koninkrijk rsync://rsync.mirrorservice.org/ Beschikbare collecties: sites/ftp.freebsd.org: een volledige mirror van de &os; FTP server. Verenigde Staten van Amerika rsync://ftp-master.FreeBSD.org/ Deze server mag alleen gebruikt worden door &os; primaire mirrorsites. Beschikbare collecties: &os;: het masterarchief van de &os; FTP server. acl: de &os; master ACL lijst. rsync://ftp13.FreeBSD.org/ Beschikbare collecties: &os;: een volledige mirror van de &os; FTP server. diff --git a/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml index 747cef6508..6bc2be644b 100644 --- a/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml @@ -1,5793 +1,5793 @@ Murray Stokely Gereorganiseerd door Siebrand Mazeland Vertaald door René Ladan Netwerkdiensten Overzicht Dit hoofdstuk behandelt een aantal veelgebruikte netwerkdiensten op &unix; systemen. Er wordt ingegaan op de installatie, het instellen, testen en beheren van verschillende typen netwerkdiensten. Overal in dit hoofdstuk staan voorbeeldbestanden met instellingen waar de lezer zijn voordeel mee kan doen. Na het lezen van dit hoofdstuk weet de lezer: Hoe om te gaan met de inetd daemon; Hoe een netwerkbestandssysteem opgezet kan worden; Hoe een netwerkinformatiedienst (NIS) opgezet kan worden voor het delen van gebruikersaccounts; Hoe automatische netwerkinstellingen gemaakt kunnen worden met DHCP; Hoe een domeinnaam server opgezet kan worden; Hoe een Apache HTTP Server opgezet kan worden; Hoe een File Transfer Protocol (FTP) Server opgezet kan worden; Hoe een bestand-- en printserver voor &windows; cliënten opgezet kan worden met Samba; Hoe datum en tijd gesynchroniseerd kunnen worden en hoe een tijdserver opgezet kan worden met het NTP-protocol. Hoe het standaard log-daemon syslogd in te stellen om logs van hosts op afstand te accepteren. Veronderstelde voorkennis: Basisbegrip van de scripts in /etc/rc; Bekend zijn met basis netwerkterminologie; Kennis van de installatie van software van derde partijen (). Chern Lee Bijgedragen door Bijgewerkt voor &os; 6.1-RELEASE door The &os; Documentation Project De <application>inetd</application> <quote>Super-Server</quote> Overzicht &man.inetd.8; wordt soms de Internet Super-Server genoemd, omdat het verbindingen voor meerdere diensten beheert. Als door inetd een verbinding wordt ontvangen, bepaalt die voor welk programma de verbinding bedoeld is, splitst het dat proces af en delegeert de socket (het programma wordt gestart met de socket van de dienst als zijn standaardinvoer, -uitvoer en -foutbeschrijvingen). Het draaien van inetd voor servers die niet veel gebruikt worden kan de algehele werklast verminderen in vergelijking met het draaien van elke daemon individueel in stand-alone modus. inetd wordt primair gebruikt om andere daemons aan te roepen, maar het handelt een aantal triviale protocollen direct af, zoals chargen, auth en daytime. In deze paragraaf worden de basisinstellingen van inetd behandeld met de opties vanaf de commandoregel en met het instellingenbestand /etc/inetd.conf. Instellingen inetd wordt gestart door het &man.rc.8;-systeem. De optie inetd_enable staat standaard op NO, maar kan tijdens de installatie door sysinstall worden aangezet. Door het plaatsen van inetd_enable="YES" of inetd_enable="NO" in /etc/rc.conf wordt inetd bij het opstarten van een systeem wel of niet ingeschakeld. Het commando: &prompt.root; /etc/rc.d/inetd rcvar kan gedraaid worden om de huidige effectieve instellingen weer te geven. Dan kunnen er ook nog een aantal commandoregelopties aan inetd meegegeven worden met de optie inetd_flags. Commandoregelopties Zoals de meeste serverdaemons heeft inetd een aantal opties die doorgegeven kunnen worden om het gedrag aan te passen. De volledige lijst van opties is: inetd Opties kunnen door middel van de optie inetd_flags in /etc/rc.conf aan inetd worden doorgegeven. Standaard staat inetd_flags ingesteld op -wW -C 60, dat TCP-wrapping aanzet voor de diensten van inetd, en voorkomt dat elk enkelvoudig IP-adres enige dienst meer dan 60 keer per minuut opvraagt. Beginnende gebruikers zullen blij zijn om te weten dat deze parameters gewoonlijk niet hoeven te worden aangepast, alhoewel we de ratebeperkende opties hieronder noemen aangezien ze nuttig kunnen zijn in het geval u een buitensporig aantal verbindingen ontvangt. Een volledige lijst van opties staat in de hulppagina &man.inetd.8;. -c maximum Geeft het maximale aantal gelijktijdige verzoeken voor iedere dienst aan. De standaard is ongelimiteerd. Kan per dienst ter zijde geschoven worden met de parameter . -C rate Geeft het maximale aantal keren aan dat een dienst vanaf een bepaald IP-adres per minuut aangeroepen kan worden. Kan per dienst ter zijde geschoven worden met de parameter . -R rate Geeft het maximale aantal keren aan dat een dienst per minuut aangeroepen kan worden. De standaard is 256. De instelling 0 geeft aan dat er geen limiet is. -s maximum Specificeert het maximaal aantal keer per minuut dat een dienst aangeroepen kan worden vanuit een enkelvoudig IP-adres; de standaard is onbeperkt. Kan worden overstemd op een per-dienst-basis met de parameter . <filename>inetd.conf</filename> De instellingen van inetd worden beheerd in /etc/inetd.conf. Als er een wijziging wordt aangebracht in /etc/inetd.conf, dan kan inetd gedwongen worden om de instellingen opnieuw in te lezen door dit commando te draaien: Het instellingenbestand van <application>inetd</application> herladen &prompt.root; /etc/rc.d/inetd reload Iedere regel in het bestand met instellingen heeft betrekking op een individuele daemon. Commentaar wordt vooraf gegaan door een #. De opmaak van elke regel van /etc/inetd.conf is als volgt: service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments Een voorbeeldregel voor de daemon &man.ftpd.8; met IPv4 kan eruit zien als: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l service-name Dit is de dienstnaam van een daemon. Die moet overeenkomen met een dienst uit /etc/services. Hiermee kan de poort waarop inetd moet luisteren aangegeven worden. Als er een nieuwe dienst wordt gemaakt, moet die eerst in /etc/services gezet worden. socket-type Dit is stream, dgram, raw of seqpacket. stream moet gebruikt worden voor verbindingsgebaseerde TCP-daemons, terwijl dgram wordt gebruikt voor daemons die gebruik maken van het transportprotocol UDP. protocol Een van de volgende: Protocol Toelichting tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 Zowel TCP IPv4 als v6 udp46 Zowel UDP IPv4 als v6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] geeft aan of de daemon die door inetd wordt aangesproken zijn eigen sockets kan afhandelen of niet. sockettypen moeten de optie gebruiken, terwijl streamsocket daemons, die meestal multi-threaded zijn, de optie horen te gebruiken. geeft meestal meerdere sockets aan een daemon, terwijl een kinddaemon draait voor iedere nieuwe socket. Het maximum aantal kinddaemons dat inetd mag voortbrengen kan ingesteld worden met de optie . Als een limiet van tien instanties van een bepaalde daemon gewenst is, dan zou er /10 achter gezet worden. Door /0 wordt een onbeperkt aantal kinderen toegestaan. Naast zijn er nog twee andere opties waarmee het maximale aantal verbindingen van een bepaalde plaats naar een daemon ingesteld kan worden. beperkt het aantal verbindingen per minuut voor enig IP-adres, een waarde van tien betekent hier dat er van ieder IP-adres maximaal tien verbindingen naar een bepaalde dienst tot stand gebracht kunnen worden. beperkt het aantal kindprocessen dat namens enig IP-adres op enig moment gestart kan worden. Deze opties kunnen zijn nuttig om bedoeld en onbedoeld buitensporig bronnengebruik van en Denial of Service (DoS) aanvallen op een machine te voorkomen. In dit veld is één van of verplicht. , en zijn optioneel. Een stream-type multi-threaded daemon zonder één van de limieten , of is eenvoudigweg: nowait. Dezelfde daemon met een maximale limiet van tien daemons zou zijn: nowait/10. Dezelfde instellingen met een limiet van twintig verbindingen per IP-adres per minuut en een totaal maximum van tien kinddaemons zou zijn: nowait/10/20. Deze opties worden allemaal gebruikt door de standaardinstellingen van de daemon &man.fingerd.8;: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Als afsluiting, een voorbeeld in dit veld met een maximum van 100 kinderen in totaal, met een maximum van 5 voor enig IP-adres zou zijn: nowait/100/0/5. user Dit is de gebruikersnaam waar een daemon onder draait. Daemons draaien meestal als de gebruiker root. Om veiligheidsredenen draaien sommige daemons onder de gebruiker daemon of de gebruiker met de minste rechten: nobody. server-program Het volledige pad van de daemon die uitgevoerd moet worden als er een verbinding wordt ontvangen. Als de daemon een dienst is die door inetd intern wordt geleverd, dan moet de optie gebruikt worden. server-program-arguments Deze optie werkt samen met de optie en hierin worden de argumenten ingesteld, beginnend met argv[0], die bij het starten aan de daemon worden meegegeven. Als mijndaemon -d de commandoregel is, dan zou mijndaemon -d de waarde van zijn. Hier geldt ook dat als de daemon een interne dienst is, hier de optie moet worden. Beveiliging Afhankelijk van keuzes gemaakt tijdens de installatie, kunnen veel van de diensten van inetd standaard ingeschakeld zijn. Het is verstandig te overwegen om een daemon dat niet noodzakelijk is uit te schakelen. Plaats een # voor de daemon in /etc/inetd.conf en herlaad vervolgens de instellingen van inetd. Sommige daemons, zoals fingerd, zijn wellicht helemaal niet gewenst omdat ze informatie geven die nuttig kan zijn voor een aanvaller. Sommige daemons zijn zich niet echt bewust van beveiliging en hebben lange of niet bestaande timeouts voor verbindingspogingen. Hierdoor kan een aanvaller langzaam veel verbindingen maken met een daemon en zo beschikbare bronnen verzadigen. Het is verstandig voor die daemons de limietopties , of te gebruiken als ze naar uw smaak teveel verbindingen hebben. TCP-wrapping staat standaard aan. Er staat meer informatie over het zetten van TCP-restricties op de verschillende daemons die door inetd worden aangesproken in &man.hosts.access.5;. Allerlei daytime, time, echo, discard, chargen en auth zijn allemaal interne diensten van inetd. De dienst auth biedt identiteitsnetwerkdiensten en is tot op een bepaald niveau instelbaar, terwijl de anderen eenvoudigweg aan of uit staan. Meer diepgaande informatie staat in &man.inetd.8;. Tom Rhodes Gereorganiseerd en verbeterd door Bill Swingle Geschreven door Netwerkbestandssysteem (NFS) NFS Het Netwerkbestandssysteem (Network File System) is een van de vele bestandssystemen die &os; ondersteunt. Het staat ook wel bekend als NFS. Met NFS is het mogelijk om mappen en bestanden met anderen in een netwerk te delen. Door het gebruik van NFS kunnen gebruikers en programma's bij bestanden op andere systemen op bijna dezelfde manier als bij hun eigen lokale bestanden. De grootste voordelen van NFS zijn: Lokale werkstations gebruiken minder schijfruimte omdat veel gebruikte data op één machine opgeslagen kan worden en nog steeds toegankelijk is voor gebruikers via het netwerk; Gebruikers hoeven niet op iedere machine een thuismap te hebben. Thuismappen kunnen op de NFS server staan en op het hele netwerk beschikbaar zijn; Opslagapparaten als floppydisks, CD-ROM drives en &iomegazip; drives kunnen door andere machines op een netwerk gebruikt worden. Hierdoor kan het aantal drives met verwijderbare media in een netwerk verkleind worden. Hoe <acronym>NFS</acronym> werkt NFS bestaat uit tenminste twee hoofdonderdelen: een server en een of meer cliënten. De cliënt benadert de gegevens die op een servermachine zijn opgeslagen via een netwerk. Om dit mogelijk te maken moeten er een aantal processen ingesteld en gestart worden. Op de server moeten de volgende daemons draaien: NFS server bestandsserver UNIX cliënten rpcbind mountd nfsd Daemon Beschrijving nfsd De NFS-daemon die verzoeken van de NFS cliënten afhandelt. mountd De NFS koppeldaemon die doorgestuurde verzoeken van &man.nfsd.8; uitvoert. rpcbind Deze daemon geeft voor NFS-cliënten aan welke poort de NFS-server gebruikt. Op de cliënt kan ook een daemon draaien: nfsiod. De daemon nfsiod handelt verzoeken van de NFS-server af. Dit is optioneel en kan de prestaties verbeteren, maar het is niet noodzakelijk voor een normale en correcte werking. Meer informatie staat in &man.nfsiod.8;. <acronym>NFS</acronym> instellen NFS instellen NFS instellen gaat redelijk rechtlijnig. Alle processen die moeten draaien kunnen meestarten bij het opstarten door een paar wijzigingen in /etc/rc.conf. Op de NFS server dienen de volgende opties in /etc/rc.conf te staan: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd start automatisch als de NFS server is ingeschakeld. Op de cliënt dient de volgende optie in /etc/rc.conf te staan: nfs_client_enable="YES" In het bestand /etc/exports staat beschreven welke bestandssystemen NFS moet exporteren (soms heet dat ook wel delen of sharen). Iedere regel in /etc/exports slaat op een bestandssysteem dat wordt geëxporteerd en welke machines toegang hebben tot dat bestandssysteem. Samen met machines die toegang hebben, kunnen ook toegangsopties worden aangegeven. Er zijn veel opties beschikbaar, maar hier worden er maar een paar beschreven. Alle opties staan beschreven in &man.exports.5;. Nu volgen een aantal voorbeelden voor /etc/exports: NFS exportvoorbeelden Het volgende voorbeeld geeft een beeld van hoe een bestandssysteem te exporteren, hoewel de instellingen afhankelijk zijn van de omgeving en het netwerk. Om bijvoorbeeld de map /cdrom te exporteren naar drie machines die dezelfde domeinnaam hebben als de server (vandaar dat de machinenamen geef domeinachtervoegsel hebben) of in /etc/hosts staan. De vlag exporteert het bestandssysteem als alleen–lezen. Door die vlag kan een ander systeem niet schrijven naar het geëxporteerde bestandssysteem. /cdrom -ro host1 host2 host3 Het volgende voorbeeld exporteert /home naar drie hosts op basis van IP-adres. Dit heeft zin als er een privaat netwerk bestaat, zonder dat er een DNS server is ingesteld. Optioneel kan /etc/hosts gebruikt worden om interne hostnamen in te stellen. Er is meer informatie te vinden in &man.hosts.5;. Met de vlag mogen submappen ook koppelpunten zijn. De submap wordt dan niet feitelijk aangekoppeld, maar de cliënt koppelt dan alleen de submappen aan die verplicht of nodig zijn. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 Het volgende voorbeeld exporteert /a zo dat twee cliënten uit verschillende domeinen bij het bestandssysteem mogen. Met de vlag mag de gebruiker op het andere systeem gegevens naar het geëxporteerde bestandssysteem schrijven als root. Als de vlag niet wordt gebruikt, dan kan een gebruiker geen bestanden wijzigen op het geëxporteerde bestandssysteem, zelfs niet als een gebruiker daar root is. /a -maproot=root host.example.com box.example.org Om een cliënt toegang te geven tot een geëxporteerd bestandssysteem, moet die cliënt daar rechten voor hebben. De cliënt moet daarvoor genoemd worden in /etc/exports. In /etc/exports staat iedere regel voor de exportinformatie van één bestandssysteem naar één host. Per bestandssysteem mag een host maar één keer genoemd worden en mag maar één standaard hebben. Stel bijvoorbeeld dat /usr een enkel bestandssysteem is. Dan is de volgende /etc/exports niet geldig: ># Werkt niet als /usr 1 bestandssysteem is /usr/src client /usr/ports client Eén bestandssysteem, /usr, heeft twee regels waarin exports naar dezelfde host worden aangegeven, client. In deze situatie is de juiste instelling: /usr/src /usr/ports client De eigenschappen van een bestandssysteem dat naar een bepaalde host wordt geëxporteerd moeten allemaal op één regel staan. Regels waarop geen cliënt wordt aangegeven worden behandeld als een enkele host. Dit beperkt hoe bestandssysteem geëxporteerd kunnen worden, maar dat blijkt meestal geen probleem te zijn. Het volgende voorbeeld is een geldige exportlijst waar /usr en /exports lokale bestandssystemen zijn: # Exporteer src en ports naar client01 en client02, # maar alleen client01 heeft er rootprivileges /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # De cliëntmachines hebben rootrechten en kunnen overal aankoppelen # op /exports. Iedereen in de wereld kan /exports/obj als alleen-lezen aankoppelen. /exports -alldirs -maproot=root client01 client02 /exports/obj -ro De daemon mountd moet gedwongen worden om het bestand /etc/exports te controleren steeds wanneer het is aangepast, zodat de veranderingen effectief kunnen worden. Dit kan worden bereikt door òfwel een HUP-signaal naar de draaiende daemon te sturen: &prompt.root; kill -HUP `cat /var/run/mountd.pid` of door het &man.rc.8; script mountd met de juiste parameter aan te roepen: &prompt.root; /etc/rc.d/mountd onereload Raadpleeg voor meer informatie over het gebruik van rc-scripts. Het is ook mogelijk een machine te herstarten, zodat &os; alles netjes in kan stellen, maar dat is niet nodig. Het uitvoeren van de volgende commando's als root hoort hetzelfde resultaat te hebben. Op de NFS server: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r Op de NFS cliënt: &prompt.root; nfsiod -n 4 Nu is alles klaar om feitelijk het netwerkbestandssysteem aan te koppelen. In de volgende voorbeelden is de naam van de server server en de naam van de cliënt is client. Om een netwerkbestandssysteem slechts tijdelijk aan te koppelen of om alleen te testen, kan een commando als het onderstaande als root op de cliënt uitgevoerd worden: NFS aankoppelen &prompt.root; mount server:/home /mnt Hiermee wordt de map /home op de server aangekoppeld op /mnt op de cliënt. Als alles juist is ingesteld, zijn nu in /mnt op de cliënt de bestanden van de server zichtbaar. Om een netwerkbestandssysteem iedere keer als een computer opstart aan te koppelen, kan het bestandssysteem worden toegevoegd aan het bestand /etc/fstab: server:/home /mnt nfs rw 0 0 Alle beschikbare opties staan in &man.fstab.5;. Op slot zetten Voor sommige applicaties (b.v. mutt) is het nodig dat bestanden op slot staan om correct te werken. In het geval van NFS, kan rpc.lockd worden gebruikt voor het op slot zetten van bestanden. Voeg het volgende toe aan het bestand /etc/rc.conf op zowel de cliënt als de server om het aan te zetten (het wordt aangenomen dat de NFS-cliënt en -server reeds zijn geconfigureerd): rpc_lockd_enable="YES" rpc_statd_enable="YES" Start de applicatie met: &prompt.root; /etc/rc.d/lockd start &prompt.root; /etc/rc.d/statd start Als echt op slot zetten tussen de NFS-cliënten en de NFS-server niet nodig is, is het mogelijk om de NFS-cliënt bestanden lokaal op slot te laten zetten door aan &man.mount.nfs.8; door te geven. In de handleidingpagina &man.mount.nfs.8; staan verdere details. Mogelijkheden voor gebruik NFS is voor veel doeleinden in te zetten. Een aantal voorbeelden: NFS gebruik Een aantal machines een CD-ROM of andere media laten delen. Dat is goedkoper en vaak ook handiger, bijvoorbeeld bij het installeren van software op meerdere machines; Op grote netwerken kan het praktisch zijn om een centrale NFS server in te richten, waarop alle thuismappen staan. Die thuismappen kunnen dan geëxporteerd worden, zodat gebruikers altijd dezelfde thuismap hebben, op welk werkstation ze ook aanmelden; Meerdere machines kunnen een gezamenlijke map /usr/ports/distfiles hebben. Dan is het mogelijk om een port op meerdere machines te installeren, zonder op iedere machine de broncode te hoeven downloaden. Wylie Stilwell Geschreven door Chern Lee Herschreven door Automatisch aankoppelen met <application>amd</application> amd automatic mounter daemon &man.amd.8; (de automatic mounter daemon) koppelt automatisch netwerkbestandssystemen aan als er aan een bestand of map binnen dat bestandssysteem wordt gerefereerd. amd ontkoppelt ook bestandssystemen die een bepaalde tijd niet gebruikt worden. Het gebruikt van amd is een aantrekkelijk en eenvoudig alternatief ten opzichte van permanente koppelingen, die meestal in /etc/fstab staan. amd werkt door zichzelf als NFS-server te koppelen aan de mappen /host en /net. Als binnen die mappen een bestand wordt geraadpleegd, dan zoekt amd de bijbehorende netwerkkoppeling op en koppelt die automatisch aan. /net wordt gebruikt om een geëxporteerd bestandssysteem van een IP-adres aan te koppelen, terwijl /host wordt gebruikt om een geëxporteerd bestandssysteem van een hostnaam aan te koppelen. Het raadplegen van een bestand in /host/foobar/usr geeft amd aan dat die moet proberen de /usr export op de host foobar aan te koppelen. Een export aankoppelen met <application>amd</application> De beschikbare koppelingen van een netwerkhost zijn te bekijken met showmount. Om bijvoorbeeld de koppelingen van de host foobar te bekijken: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr Zoals in het bovenstaande voorbeeld te zien is, toont showmount /usr als een export. Als er naar de map /host/foobar/usr wordt gegaan, probeert amd de hostnaam foobar te resolven en de gewenste export automatisch aan te koppelen. amd kan gestart worden door de opstartscript door de volgende regel in /etc/rc.conf te plaatsen: amd_enable="YES" Er kunnen ook nog opties meegegeven worden aan amd met de optie amd_flags. Standaard staat amd_flags ingesteld op: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" In het bestand /etc/amd.map staan de standaardinstellingen waarmee exports aangekoppeld worden. In het bestand /etc/amd.conf staan een aantal van de meer gevorderde instellingen van amd. In &man.amd.8; en &man.amd.conf.5; staat meer informatie. John Lind Geschreven door Problemen bij samenwerking met andere systemen Bepaalde Ethernet adapters voor ISA PC systemen kennen limieten die tot serieuze netwerkproblemen kunnen leiden, in het bijzonder met NFS. Dit probleem is niet specifiek voor &os;, maar het kan op &os; wel voor komen. Het probleem ontstaat bijna altijd als (&os;) PC-systemen netwerken met hoog presterende werkstations, zoals van Silicon Graphics, Inc. en Sun Microsystems, Inc. De NFS-koppeling werkt prima en wellicht lukken een aantal acties ook, maar dan ineens lijkt de server niet meer te reageren voor de cliënt, hoewel verzoeken van en naar andere systemen gewoon verwerkt worden. Dit gebeurt op een cliëntsysteem, of de cliënt nu het &os; systeem is of het werkstation. Op veel systemen is er geen manier om de cliënt netjes af te sluiten als dit probleem is ontstaan. Vaak is de enige mogelijkheid een reset van de cliënt, omdat het probleem met NFS niet opgelost kan worden. Hoewel de enige correcte oplossing de aanschaf van een snellere en betere Ethernet adapter voor het &os; systeem is, is er zo om het probleem heen te werken dat het werkbaar is. Als &os; de server is, kan de optie gebruikt worden bij het aankoppelen door de cliënt. Als het &os; systeem de cliënt is, dan dient het NFS-bestandssysteem aangekoppeld te worden met de optie . Deze opties kunnen het vierde veld zijn in een regel in fstab voor automatische aankoppelingen en bij handmatige aankoppelingen met &man.mount.8; kan de parameter gebruikt worden. Soms wordt een ander probleem voor dit probleem versleten, als servers en cliënten zich op verschillende netwerken bevinden. Als dat het geval is, dan dient vastgesteld te worden dat routers de UDP informatie op de juiste wijze routeren, omdat er anders nooit NFS-verkeer gerouteerd kan worden. In de volgende voorbeelden is fastws de host(interface)naam van een hoog presterend werkstation en freebox is de host(interface)naam van een &os; systeem met een Ethernet adapter die mindere prestaties levert. /sharedfs wordt het geëxporteerde NFS-bestandssysteem (zie &man.exports.5;) en /project wordt het koppelpunt voor het geëxporteerde bestandssysteem op de cliënt. In sommige gevallen kunnen applicaties beter draaien als extra opties als of en gebruikt worden. Voorbeelden voor het &os; systeem (freebox) als de cliënt in /etc/fstab op freebox: fastws:/sharedfs /project nfs rw,-r=1024 0 0 Als een handmatig aankoppelcommando op freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Voorbeelden voor het &os; systeem als de server in /etc/fstab op fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 Als een handmatig aankoppelcommando op fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Bijna iedere 16–bit Ethernet adapter werkt zonder de hierboven beschreven restricties op de lees- en schrijfgrootte. Voor wie het wil weten wordt nu beschreven wat er gebeurt als de fout ontstaan, wat ook duidelijk maakt waarom het niet hersteld kan worden. NFS werkt meestal met een blockgrootte van 8 K (hoewel het mogelijk is dat er kleinere fragmenten worden verwerkt). Omdat de maximale grootte van een Ethernet pakket rond de 1500 bytes ligt, wordt een block opgesplitst in meerdere Ethernetpakketten, hoewel het hoger in de code nog steeds één eenheid is, en wordt ontvangen, samengevoegd en bevestigd als een eenheid. De hoog presterende werkstations kunnen de pakketten waaruit een NFS-eenheid bestaat bijzonder snel naar buiten pompen. Op de kaarten met minder capaciteit worden de eerdere pakketten door de latere pakketten van dezelfde eenheid ingehaald voordat ze bij die host zijn aangekomen en daarom kan de eenheid niet worden samengesteld en bevestigd. Als gevolg daarvan ontstaat er op het werkstation een timeout en probeert die de eenheid opnieuw te sturen, maar dan weer de hele eenheid van 8 K, waardoor het proces wordt herhaald, ad infinitum. Door de grootte van de eenheid kleiner te houden dan de grootte van een Ethernet pakket, is het zeker dat elk Ethernetpakket dat compleet is aangekomen bevestigd kan worden, zodat de deadlock niet ontstaat. Toch kan een PC systeem nog wel overrompeld worden als hoog presterende werkstations er op inhakken, maar met de betere netwerkkaarten valt het dan in ieder geval niet om door de NFS eenheden. Als het systeem toch wordt overrompeld, dan worden de betrokken eenheden opnieuw verstuurd en dan is de kans groot dat ze worden ontvangen, samengevoegd en bevestigd. Bill Swingle Geschreven door Eric Ogren Verbeterd door Udo Erdelhoff Netwerkinformatiesysteem (NIS/YP) Wat is het? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD NIS, dat staat voor Netwerkinformatiediensten (Network Information Services), is ontwikkeld door Sun Microsystems om het beheer van &unix; (origineel &sunos;) systemen te centraliseren. Tegenwoordig is het eigenlijk een industriestandaard geworden. Alle grote &unix; achtige systemen (&solaris;, HP-UX, &aix;, &linux;, NetBSD, OpenBSD, &os;, enzovoort) ondersteunen NIS. yellow pagesNIS NIS stond vroeger bekend als Yellow Pages, maar vanwege problemen met het handelsmerk heeft Sun de naam veranderd. De oude term, en yp, wordt nog steeds vaak gebruikt. NIS domeinen Het is een op RPC-gebaseerd cliënt/serversysteem waarmee een groep machines binnen een NIS-domein een gezamenlijke verzameling met instellingenbestanden kan delen. Hierdoor kan een beheerder NIS-systemen opzetten met een minimaal aantal instellingen en vanaf een centrale lokatie instellingen toevoegen, verwijderen en wijzigen. Windows NT Het is te vergelijken met het &windowsnt; domeinsysteem en hoewel de interne implementatie van de twee helemaal niet overeenkomt, is de basisfunctionaliteit vergelijkbaar. Termen en processen om te onthouden Er zijn een aantal termen en belangrijke gebruikersprocessen die een rol spelen bij het implementeren van NIS op &os;, zowel bij het maken van een NIS-server als bij het maken van een systeem dan NIS-cliënt is: rpcbind portmap Term Beschrijving NIS-domeinnaam Een NIS-masterserver en al zijn cliënten (inclusief zijn slave master) hebben een NIS-domeinnaam. Vergelijkbaar met een &windowsnt; domeinnaam, maar de NIS-domeinnaam heeft niets te maken met DNS. rpcbind Moet draaien om RPC (Remote Procedure Call in te schakelen, een netwerkprotocol dat door NIS gebruikt wordt). Als rpcbind niet draait, dan kan er geen NIS-server draaien en kan een machine ook geen NIS-cliënt zijn. ypbind Verbindt een NIS-cliënt aan zijn NIS-server. Dat gebeurt door met de NIS-domeinnaam van het systeem en door het gebruik van RPC te verbinden met de server. ypbind is de kern van cliënt-server communicatie in een NIS-omgeving. Als ypbind op een machine stopt, dan kan die niet meer bij de NIS-server komen. ypserv Hoort alleen te draaien op NIS-servers. Dit is het NIS-serverproces zelf. Als &man.ypserv.8; stopt, dan kan de server niet langer reageren op NIS-verzoeken (hopelijk is er dan een slaveserver om het over te nemen). Er zijn een aantal implementaties van NIS, maar niet die op &os;, die geen verbinding met een andere server proberen te maken als de server waarmee ze verbonden waren niet meer reageert. In dat geval is vaak het enige dat werkt het serverproces herstarten (of zelfs de hele server) of het ypbind-proces op de cliënt. rpc.yppasswdd Nog een proces dat alleen op NIS-masterservers hoort te draaien. Dit is een daemon waarbij NIS-cliënten hun NIS-wachtwoorden kunnen wijzigen. Als deze daemon niet draait, moeten gebruikers zich aanmelden op de NIS-masterserver en daar hun wachtwoord wijzigen. Hoe werkt het? Er zijn drie typen hosts in een NIS-omgeving: master servers, slaveservers en cliënten. Servers zijn het centrale depot voor instellingen voor een host. Masterservers bevatten de geautoriseerd kopie van die informatie, terwijl slaveservers die informatie spiegelen voor redundantie. Cliënten verlaten zich op de servers om hun die informatie ter beschikking te stellen. Op deze manier kan informatie uit veel bestanden gedeeld worden. De bestanden master.passwd, group en hosts worden meestal via NIS gedeeld. Als een proces op een cliënt informatie nodig heeft die normaliter in een van die lokale bestanden staat, dan vraagt die het in plaats daarvan aan de NIS-servers waarmee hij verbonden is. Soorten machines NIS masterserver Een NIS-masterserver. Deze server onderhoudt, analoog aan een &windowsnt; primaire domeincontroller, de bestanden die door alle NIS-cliënten gebruikt worden. De bestanden passwd, group en andere bestanden die door de NIS-cliënten gebruikt worden staan op de masterserver. Het is mogelijk om één machine master server te laten zijn voor meerdere NIS-domeinen. Dat wordt in deze inleiding echter niet beschreven, omdat die uitgaat van een relatief kleine omgeving. NIS slaveserver NIS-slaveservers. Deze zijn te vergelijken met &windowsnt; backup domain controllers. NIS-slaveservers beheren een kopie van de bestanden met gegevens op de NIS-master. NIS-slaveservers bieden redundantie, die nodig is in belangrijke omgevingen. Ze helpen ook om de belasting te verdelen met de master server: NIS-cliënten maken altijd een verbinding met de NIS-server die het eerst reageert en dat geldt ook voor antwoorden van slaveservers. NIS cliënt NIS-cliënten. NIS-cliënten authenticeren, net als de meeste &windowsnt; werkstations, tegen de NIS-server (of de &windowsnt; domain controller in het geval van &windowsnt; werkstations) bij het aanmelden. NIS/YP gebruiken Dit onderdeel behandelt het opzetten van een NIS-voorbeeldomgeving. Plannen Er wordt uitgegaan van een beheerder van een klein universiteitslab. Dat lab, dat bestaat uit &os; machines, kent op dit moment geen centraal beheer. Iedere machine heeft zijn eigen /etc/passwd en /etc/master.passwd. Die bestanden worden alleen met elkaar in lijn gehouden door handmatige handelingen. Als er op dit moment een gebruiker aan het lab wordt toegevoegd, moet adduser op alle 15 machines gedraaid worden. Dat moet natuurlijk veranderen en daarom is besloten het lab in te richten met NIS, waarbij twee machines als server worden gebruikt. Het lab ziet er ongeveer als volgt uit: Machinenaam IP-adres Rol Machine ellington 10.0.0.2 NIS-master coltrane 10.0.0.3 NIS-slave basie 10.0.0.4 Wetenschappelijk werkstation bird 10.0.0.5 Cliënt machine cli[1-11] 10.0.0.[6-17] Andere cliënt machines Bij het voor de eerste keer instellen van een NIS-schema is het verstandig eerst na te denken over hoe dat opgezet moet worden. Hoe groot een netwerk ook is, er moeten een aantal beslissingen gemaakt worden. Een NIS-domeinnaam kiezen NIS domeinnaam Dit is wellicht niet de bekende domeinnaam. Daarom wordt het ook de NIS-domeinnaam genoemd. Bij de broadcast van een cliënt om informatie wordt ook de naam van het NIS-domein waar hij onderdeel van uitmaakt meegezonden. Zo kunnen meerdere servers op een netwerk bepalen of er antwoord gegeven dient te worden op een verzoek. De NIS-domeinnaam is kan voorgesteld worden als de naam van een groep hosts op op een of andere manier aan elkaar gerelateerd zijn. Sommige organisaties kiezen hun Internet-domeinnaam als NIS-domeinnaam. Dat wordt niet aangeraden omdat het voor verwarring kan zorgen bij het debuggen van netwerkproblemen. De NIS-domeinnaam moet uniek zijn binnen een netwerk en het is handig als die de groep machines beschrijft waarvoor hij geldt. Zo kan bijvoorbeeld de financiële afdeling van Acme Inc. als NIS-domeinnaam acme-fin hebben. In dit voorbeeld wordt de naam test-domain gekozen. SunOS Sommige besturingssystemen gebruiken echter (met name &sunos;) hun NIS-domeinnaam als hun Internet-domeinnaam. Als er machines zijn op een netwerk die deze restrictie kennen, dan moet de Internet-domeinnaam als de naam voor het NIS-domeinnaam gekozen worden. Systeemeisen Bij het kiezen van een machine die als NIS-server wordt gebruikt zijn er een aantal aandachtspunten. Een van de onhandige dingen aan NIS is de afhankelijkheid van de cliënten van de server. Als een cliënt de server voor zijn NIS-domein niet kan bereiken, dan wordt die machine vaak onbruikbaar. Door het gebrek aan gebruiker- en groepsinformatie bevriezen de meeste systemen. Daarom moet er een machine gekozen worden die niet vaak herstart hoeft te worden of wordt gebruikt voor ontwikkeling. De NIS-server is in het meest ideale geval een alleenstaande server die als enige doel heeft NIS-server te zijn. Als een netwerk niet zwaar wordt gebruikt, kan de NIS-server op een machine die ook andere diensten aanbiedt gezet worden, maar het blijft belangrijk om ervan bewust te zijn dat als de NIS-server niet beschikbaar is, dat nadelige invloed heeft op alle NIS-cliënten. NIS-servers De hoofdversies van alle NIS-informatie staan opgeslagen op één machine die de NIS-masterserver heet. De databases waarin de informatie wordt opgeslagen heten NIS-afbeeldingen. In &os; worden die afbeeldingen opgeslagen in /var/yp/[domeinnaam] waar [domeinnaam] de naam is van het NIS-domein dat wordt bediend. Een enkele NIS-server kan tegelijkertijd meerdere NIS-domeinen ondersteunen en het is dus mogelijk dat er meerdere van zulke mappen zijn, een voor ieder ondersteund domein. Ieder domein heeft zijn eigen onafhankelijke verzameling afbeeldingen. In NIS-master- en -slaveservers worden alle NIS-verzoeken door de daemon ypserv afgehandeld. ypserv is verantwoordelijk voor het ontvangen van inkomende verzoeken van NIS-cliënten, het vertalen van de gevraagde domeinnaam en mapnaam naar een pad naar het corresponderende databasebestand en het terugsturen van de database naar de cliënten. Een NIS-masterserver opzetten NIS server opzetten Het opzetten van een master NIS-server kan erg eenvoudig zijn, afhankelijk van de behoeften. &os; heeft ondersteuning voor NIS als basisfunctie. Alleen de volgende regels hoeven aan /etc/rc.conf toegevoegd te worden en &os; doet de rest: nisdomainname="test-domain" Deze regel stelt de NIS-domeinnaam in op test-domain bij het instellen van het netwerk (bij het opstarten). nis_server_enable="YES" Dit geeft &os; aan de NIS-serverprocessen te starten als het netwerk de volgende keer wordt opgestart. nis_yppasswdd_enable="YES" Dit schakelt de daemon rpc.yppasswdd in die, zoals al eerder aangegeven, cliënten toestaat om hun NIS-wachtwoord vanaf een cliënt-machine te wijzigen. Afhankelijk van de inrichting van NIS, kunnen er nog meer instellingen nodig zijn. In het onderdeel NIS-servers die ook NIS-cliënten zijn staan meer details. Draai na het instellen van bovenstaande regels het commando /etc/netstart als supergebruiker. Het zal alles voor u instellen, gebruikmakende van de waarden die u in /etc/rc.conf heeft ingesteld. Start als laatste stap, voor het initialiseren van de NIS-afbeeldingen, de daemon ypserv handmatig: &prompt.root; /etc/rc.d/ypserv start NIS-afbeeldingen initialiseren NIS afbeeldingen Die NIS-afbeeldingen zijn databasebestanden die in de map /var/yp staan. Ze worden gemaakt uit de bestanden met instellingen uit de map /etc van de NIS-master, met één uitzondering: /etc/master.passwd. Daar is een goede reden voor, want het is niet wenselijk om de wachtwoorden voor root en andere administratieve accounts naar alle servers in het NIS-domein te sturen. Daar moet voor het initialiseren van de NIS-afbeeldingen het volgende uitgevoerd worden: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd Dan horen alle systeemaccounts verwijderd te worden (bin, tty, kmem, games, enzovoort) en alle overige accounts waarvoor het niet wenselijk is dat ze op de NIS-cliënten terecht komen (bijvoorbeeld root en alle andere UID 0 (supergebruiker) accounts). /var/yp/master.passwd hoort niet te lezen te zijn voor een groep of voor de wereld (dus modus 600)! Voor het aanpassen van de rechten kan chmod gebruikt worden. Tru64 UNIX Als dat is gedaan, kunnen de NIS-afbeeldingen geïnitialiseerd worden. Bij &os; zit een script ypinit waarmee dit kan (in de hulppagina staat meer informatie). Dit script is beschikbaar op de meeste &unix; besturingssystemen, maar niet op allemaal. Op Digital UNIX/Compaq Tru64 UNIX heet het ypsetup. Omdat er afbeeldingen voor een NIS-master worden gemaakt, wordt de optie meegegeven aan ypinit. Aangenomen dat de voorgaande stappen zijn uitgevoerd, kunnen de NIS-afbeeldingen gemaakt worden op de volgende manier: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..uitvoer van het maken van de afbeeldingen..] NIS Map update completed. ellington has been setup as an YP master server without any errors. ypinit hoort /var/yp/Makefile gemaakt te hebben uit /var/yp/Makefile.dist. Als dit bestand is gemaakt, neemt dat bestand aan dat er in een omgeving met een enkele NIS-server wordt gewerkt met alleen &os;-machines. Omdat test-domain ook een slaveserver bevat, dient /var/yp/Makefile gewijzigd te worden: ellington&prompt.root; vi /var/yp/Makefile Als de onderstaande regel niet al uitgecommentarieerd is, dient dat alsnog te gebeuren: NOPUSH = "True" Een NIS-slaveserver opzetten NIS slaveserver Het opzetten van een NIS-slaveserver is nog makkelijker dan het opzetten van de master. Dit kan door aan te melden op de slaveserver en net als voor de masterserver /etc/rc.conf te wijzigen. Het enige verschil is dat nu de optie gebruikt wordt voor het draaien van ypinit. Met de optie moet ook de naam van de NIS-master meegegeven worden. Het commando ziet er dus als volgt uit: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. Nu hoort er een map /var/yp/test-domain te zijn waarin kopieë van de NIS-masterserver afbeeldingen staan. Die moeten bijgewerkt blijven. De volgende regel in /etc/crontab op de slaveservers regelt dat: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Met de bovenstaande twee regels wordt de slave gedwongen zijn afbeeldingen met de afbeeldingen op de masterserver te synchroniseren. Hoewel dit niet verplicht is, omdat de masterserver probeert veranderingen aan de NIS-afbeeldingen door te geven aan zijn slaves, is het wel verstandig om een slave tot bijwerken te dwingen, omdat wachtwoordinformatie van vitaal belang is voor systemen die van de server afhankelijk zijn. Dit is des te belangrijker op drukke netwerken, omdat daar het bijwerken van afbeeldingen niet altijd compleet afgehandeld hoeft te worden. Nu kan ook op de slaveserver het commando /etc/netstart uitgevoerd worden, dat op zijn beurt de NIS-server start. NIS-cliënten Een NIS-cliënt maakt wat heet een verbinding (binding) met een NIS-server met de daemon ypbind. ypbind controleert het standaarddomein van het systeem (zoals ingesteld met domainname) en begint met het broadcasten van RPC-verzoeken op het lokale netwerk. Die verzoeken bevatten de naam van het domein waarvoor ypbind een binding probeert te maken. Als een server die is ingesteld om het gevraagde domein te bedienen een broadcast ontvangt, dan antwoordt die aan ypbind dat dan het IP-adres van de server opslaat. Als er meerdere servers beschikbaar zijn, een master en bijvoorbeeld meerdere slaves, dan gebruikt ypbind het adres van de eerste server die antwoord geeft. Vanaf dat moment stuurt de cliënt alle NIS-verzoeken naar die server. ypbind pingt de server zo nu en dan om te controleren of die nog draait. Als er na een bepaalde tijd geen antwoord komt op een ping, dan markeert ypbind het domein als niet verbonden en begint het broadcasten opnieuw, in de hoop dat er een andere server wordt gelocaliseerd. Een NIS-cliënt opzetten NIS cliënt instellen Het opzetten van een &os; machine als NIS-cliënt is redelijk doorzichtig: Wijzig /etc/rc.conf en voeg de volgende regels toe om de NIS-domeinnaam in te stellen en ypbind mee te laten starten bij het starten van het netwerk: nisdomainname="test-domain" nis_client_enable="YES" Om alle mogelijke regels voor accounts uit de NIS-server te halen, dienen alle gebruikersaccounts uit /etc/master.passwd verwijderd te worden en dient met vipw de volgende regel aan het einde van het bestand geplaatst te worden: +::::::::: Door deze regel wordt alle geldige accounts in de wachtwoordafbeelding van de NIS-server toegang gegeven. Er zijn veel manieren om de NIS-cliënt in te stellen door deze regel te veranderen. In het onderdeel netgroepen hieronder staat meer informatie. Zeer gedetailleerde informatie staat in het boek NFS en NIS beheren van O'Reilly. Er moet tenminste één lokale account behouden blijven (dus niet geïmporteerd via NIS) in /etc/master.passwd en die hoort ook lid te zijn van de groep wheel. Als er iets mis is met NIS, dan kan die account gebruikt worden om via het netwerk aan te melden, root te worden en het systeem te repareren. Om alle groepen van de NIS-server te importeren, kan de volgende regel aan /etc/group toegevoegd worden: +:*:: Voer, om de NIS-cliënt onmiddelijk te starten, de volgende commando's als supergebruiker uit: &prompt.root; /etc/netstart &prompt.root; /etc/rc.d/ypbind start Na het afronden van deze stappen zou met ypcat passwd de passwd map van de NIS-server te zien moeten zijn. NIS-beveiliging In het algemeen kan iedere netwerkgebruiker een RPC-verzoek doen uitgaan naar &man.ypserv.8; en de inhoud van de NIS-afbeeldingen ontvangen, mits die gebruiker de domeinnaam kent. Omdat soort ongeautoriseerde transacties te voorkomen, ondersteunt &man.ypserv.8; de optie securenets, die gebruikt kan worden om de toegang te beperken tot een opgegeven aantal hosts. Bij het opstarten probeert &man.ypserv.8; de securenets informatie te laden uit het bestand /var/yp/securenets. Dit pad kan verschillen, afhankelijk van het pad dat opgegeven is met de optie . Dit bestand bevat regels die bestaan uit een netwerkspecificatie en een netwerkmasker, gescheiden door witruimte. Regels die beginnen met # worden als commentaar gezien. Een voorbeeld van een securenetsbestand zou er zo uit kunnen zien: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 # this includes the machines in the testlab 10.0.0.0 255.255.240.0 Als &man.ypserv.8; een verzoek ontvangt van een adres dat overeenkomt met een van de bovenstaande regels, dan wordt dat verzoek normaal verwerkt. Als er geen enkele regel op het verzoek van toepassing is, dan wordt het verzoek genegeerd en wordt er een waarschuwing gelogd. Als het bestand /var/yp/securenets niet bestaat, dan accepteert ypserv verbindingen van iedere host. Het programma ypserv ondersteunt ook het pakket TCP Wrapper van Wietse Venema. Daardoor kan een beheerder de instellingenbestanden van TCP Wrapper gebruiken voor toegangsbeperking in plaats van /var/yp/securenets. Hoewel beide methoden van toegangscontrole enige vorm van beveiliging bieden, zijn ze net als de geprivilegieerde poorttest kwetsbaar voor IP spoofing aanvallen. Al het NIS-gerelateerde verkeer hoort door een firewall tegengehouden te worden. Servers die gebruik maken van /var/yp/securenets kunnen wellicht legitieme verzoeken van NIS-cliënten weigeren als die gebruik maken van erg oude TCP/IP-implementaties. Sommige van die implementaties zetten alle host bits op nul als ze een broadcast doen en/of kijken niet naar het subnetmasker als ze het broadcastadres berekenen. Hoewel sommige van die problemen opgelost kunnen worden door de instellingen op de cliënt aan te passen, zorgen andere problemen voor het noodgedwongen niet langer kunnen gebruiker van NIS voor die cliënt of het niet langer gebruiken van /var/yp/securenets. Het gebruik van /var/yp/securenets op een server met zo'n oude implementatie van TCP/IP is echt een slecht idee en zal leiden tot verlies van NIS-functionaliteit voor grote delen van een netwerk. tcpwrapper Het gebruik van het pakket TCP Wrapper leidt tot langere wachttijden op de NIS-server. De extra vertraging kan net lang genoeg zijn om een timeout te veroorzaken in cliëntprogramma's, in het bijzonder als het netwerk druk is of de NIS-server traag is. Als een of meer cliënten last hebben van dat symptoom, dan is het verstandig om de cliëntsysteem in kwestie NIS-slaveserver te maken en naar zichzelf te laten wijzen. Aanmelden voor bepaalde gebruikers blokkeren In het lab staat de machine basie, die alleen faculteitswerkstation hoort te zijn. Het is niet gewenst die machine uit het NIS-domein te halen, maar het passwd bestand op de master NIS-server bevat nu eenmaal accounts voor zowel de faculteit als de studenten. Hoe kan dat opgelost worden? Er is een manier om het aanmelden van specifieke gebruikers op een machine te weigeren, zelfs als ze in de NIS-database staan. Daarvoor hoeft er alleen maar –username aan het einde van /etc/master.passwd op de cliënt machine toegevoegd te worden, waar username de gebruikersnaam van de gebruiker die niet mag aanmelden is. Dit gebeurt bij voorkeur met vipw, omdat vipw de wijzigingen aan /etc/master.passwd controleert en ook de wachtwoord database opnieuw bouwt na het wijzigen. Om bijvoorbeeld de gebruiker bill aan te kunnen laten aanmelden op basie: basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Geschreven door Netgroups gebruiken netgroepen De methode uit het vorige onderdeel werkt prima als er maar voor een beperkt aantal gebruikers en/of machines speciale regels nodig zijn. Op grotere netwerken gebeurt het gewoon dat er wordt vergeten om een aantal gebruikers de aanmeldrechten op gevoelige machines te ontnemen of dat zelfs iedere individuele machine aangepast moet worden, waardoor het voordeel van NIS teniet wordt gedaan: centraal beheren. De ontwikkelaars van NIS hebben dit probleem opgelost met netgroepen. Het doel en de semantiek kunnen vergeleken worden met de normale groepen die gebruikt worden op &unix; bestandssystemen. De belangrijkste verschillen zijn de afwezigheid van een numeriek ID en de mogelijkheid om een netgroep aan te maken die zowel gebruikers als andere netgroepen bevat. Netgroepen zijn ontwikkeld om gebruikt te worden voor grote, complexe netwerken met honderden gebruikers en machines. Aan de ene kant is dat iets Goeds. Aan de andere kant is het wel complex en bijna onmogelijk om netgroepen met een paar eenvoudige voorbeelden uit te leggen. Dat probleem wordt in de rest van dit onderdeel duidelijk gemaakt. Stel dat de succesvolle implementatie van NIS in het lab de interesse heeft gewekt van een centrale beheerclub. De volgende taak is het uitbreiden van het NIS-domein met een aantal andere machines op de campus. De onderstaande twee tabellen bevatten de namen van de nieuwe gebruikers en de nieuwe machines met een korte beschijving. Gebruikersna(a)m(en) Beschrijving alpha, beta Gewone medewerkers van de IT-afdeling charlie, delta Junior medewerkers van de IT-afdeling echo, foxtrott, golf, ... Gewone medewerkers able, baker, ... Stagiairs Machinena(a)m(en) Beschrijving war, death, famine, pollution De belangrijkste servers. Alleen senior medewerkers van de IT-afdeling mogen hierop aanmelden. pride, greed, envy, wrath, lust, sloth Minder belangrijke servers. Alle leden van de IT-afdeling mogen aanmelden op deze machines. one, two, three, four, ... Gewone werkstations. Alleen echte medewerkers mogen zich op deze machines aanmelden. trashcan Een erg oude machine zonder kritische data. Zelfs de stagiair mag deze doos gebruiken. Als deze restricties ingevoerd worden door iedere gebruiker afzonderlijk te blokkeren, dan wordt er een -user regel per systeem toegevoegd aan de passwd voor iedere gebruiker die niet mag aanmelden op dat systeem. Als er maar één regel wordt vergeten, kan dat een probleem opleveren. Wellicht lukt het nog dit juist in te stellen bij de bouw van een machine, maar het wordt echt vergeten de regels toe te voegen voor nieuwe gebruikers in de productiefase. Murphy was tenslotte een optimist. Het gebruik van netgroepen biedt in deze situatie een aantal voordelen. Niet iedere gebruiker hoeft separaat afgehandeld te worden. Een gebruik kan aan een of meer groepen worden toegevoegd en aanmelden kan voor alle leden van zo'n groep worden toegestaan of geweigerd. Als er een nieuwe machine wordt toegevoegd, dan hoeven alleen de aanmeldrestricties voor de netgroepen te worden ingesteld. Als er een nieuwe gebruiker wordt toegevoegd, dan hoeft die alleen maar aan de juiste netgroepen te worden toegevoegd. Die veranderingen zijn niet van elkaar afhankelijk: geen voor iedere combinatie van gebruiker en machine moet het volgende .... Als de NIS-opzet zorgvuldig is gepland, dan hoeft er maar één instellingenbestand gewijzigd te worden om toegang tot machines te geven of te ontnemen. De eerst stap is het initialiseren van de NIS-afbeelding netgroup. &man.ypinit.8; van &os; maakt deze map niet standaard, maar als die is gemaakt, ondersteunt de NIS-implementatie hem wel. Een lege map wordt als volgt gemaakt: ellington&prompt.root; vi /var/yp/netgroup Nu kan hij gevuld worden. In het gebruikte voorbeeld zijn tenminste vier netgroepen: IT-medewerkers, IT-junioren, gewone medewerkers en stagiars. IT_MW (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) STAGS (,able,test-domain) (,baker,test-domain) IT_MW, IT_APP enzovoort, zijn de namen van de netgroepen. Iedere groep tussen haakjes bevat een of meer gebruikersnamen voor die groep. De drie velden binnen een groep zijn: De na(a)m(en) van de host(s) waar de volgende onderdelen geldig zijn. Als er geen hostnaam wordt opgegeven dan is de regel geldig voor alle hosts. Als er wel een hostnaam wordt opgegeven, dan wordt een donker, spookachtig en verwarrend domein betreden. De naam van de account die bij deze netgroep hoort. Het NIS-domein voor de account. Er kunnen accounts uit andere NIS-domeinen geïmporteerd worden in een netgroep als een beheerder zo ongelukkig is meerdere NIS-domeinen te hebben. Al deze velden kunnen jokerkarakters bevatten. Details daarover staan in &man.netgroup.5;. netgroepen De naam van een netgroep mag niet langer zijn dan acht karakters, zeker niet als er andere besturingssystemen binnen een NIS-domein worden gebruikt. De namen zijn hoofdlettergevoelig: alleen hoofdletters gebruiken voor de namen van netgroepen is een makkelijke manier om onderscheid te kunnen maken tussen gebruikers-, machine- en netgroepnamen. Sommige NIS-cliënten (andere dan die op &os; draaien) kunnen niet omgaan met netgroepen met veel leden. Sommige oudere versies van &sunos; gaan bijvoorbeeld lastig doen als een netgroep meer dan 15 leden heeft. Dit kan omzeild worden door meerdere subnetgroepen te maken met 15 gebruikers of minder en een echte netgroep die de subnetgroepen bevat: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 Dit proces kan herhaald worden als er meer dan 225 gebruikers in een netgroep moeten. Het activeren en distribueren van de nieuwe NIS-map is eenvoudig: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Hiermee worden drie nieuwe NIS-afbeeldingen gemaakt: netgroup, netgroup.byhost en netgroup.byuser. Met &man.ypcat.1; kan bekeken worden op de nieuwe NIS-afbeeldingen beschikbaar zijn: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser De uitvoer van het eerste commando hoort te lijken op de inhoud van /var/yp/netgroup. Het tweede commando geeft geen uitvoer als er geen host-specifieke netgroepen zijn ingesteld. Het derde commando kan gebruikt worden om een lijst van netgroepen voor een gebruiker op te vragen. Het instellen van de cliënt is redelijk eenvoudig. Om de server war in te stellen hoeft alleen met &man.vipw.8; de volgende regel in de regel daarna vervangen te worden: +::::::::: Vervang de bovenstaande regel in de onderstaande. +@IT_MW::::::::: Nu worden alleen de gebruikers die in de netgroep IT_MW geïmporteerd in de wachtwoorddatabase van de host war, zodat alleen die gebruikers zich kunnen aanmelden. Helaas zijn deze beperkingen ook van toepassing op de functie ~ van de shell en alle routines waarmee tussen gebruikersnamen en numerieke gebruikers ID's wordt gewisseld. Met andere woorden: cd ~user werkt niet, ls –l toont het numerieke ID in plaats van de gebruikersnaam en find . –user joe –print faalt met de foutmelding No such user. Om dit te repareren moeten alle gebruikers geïmporteerd worden, zonder ze het recht te geven aan te melden op een server. Dit kan gedaan worden door nog een regel aan /etc/master.passwd toe te voegen: +:::::::::/sbin/nologin Dit betekent importeer alle gebruikers, maar vervang de shell door /sbin/nologin. Ieder veld in een passwd regel kan door een standaardwaarde vervangen worden in /etc/master.passwd. De regel +:::::::::/sbin/nologin moet na +@IT_MW::::::::: komen. Anders krijgen alle gebruikers die uit NIS-komen /sbin/nologin als aanmeldshell. Na deze wijziging hoeft er nog maar één NIS-afbeelding gewijzigd te worden als er een nieuwe medewerker komt bij de IT-afdeling. Dezelfde aanpak kan gebruikt worden voor de minder belangrijke servers door de oude regel +::::::::: in de lokale versie van /etc/master.passwd door iets als het volgende te vervangen: +@IT_MW::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin Voor normale werkstations zijn het de volgende regels: +@IT_MW::::::::: +@USERS::::::::: +:::::::::/sbin/nologin En dat zou allemaal leuk en aardig zijn als er niet na een paar weken een beleidsverandering komt: de IT-afdeling gaat stagiairs aannemen. De IT-stagiairs mogen de normale werkstations en de minder belangrijke servers gebruiken en de juniorbeheerders mogen gaan aanmelden op de hoofdservers. Dat kan door een nieuwe groep IT_STAG te maken en de nieuwe IT-stagiairs toe te voegen aan die netgroep en dan de instellingen op iedere machine te gaan veranderen. Maar zoals het spreekwoord zegt: Fouten in een centrale planning leiden tot complete chaos. Deze situaties kunnen voorkomen worden door gebruik te maken van de mogelijkheid in NIS om netgroepen in netgroepen op te nemen. Het is mogelijk om rolgebaseerde netgroepen te maken. Er kan bijvoorbeeld een netgroep BIGSRV gemaakt worden om het aanmelden op de belangrijke servers te beperken en er kan een andere netgroep SMALLSRV voor de minder belangrijke servers zijn en een derde netgroep met de naam USERBOX voor de normale werkstations. Al die netgroepen kunnen de netgroepen bevatten die op die machines mogen aanmelden. De nieuwe regels in de NIS-afbeelding netgroup zien er dan zo uit: BIGSRV IT_MW IT_APP SMALLSRV IT_MW IT_APP ITSTAG USERBOX IT_MW ITSTAG USERS Deze methode voor het instellen van aanmeldbeperkingen werkt redelijk goed als er groepen van machines gemaakt kunnen worden met identieke beperkingen. Helaas blijkt dat eerder uitzondering dan regel. Meestal moet het mogelijk zijn om per machine in te stellen wie zich wel en wie zich niet mogen aanmelden. Daarom is het ook mogelijk om via machinespecifieke netgroepen de hierboven aangegeven beleidswijziging op te vangen. In dat scenario bevat /etc/master.passwd op iedere machine twee regels die met + beginnen. De eerste voegt de netgroep toe met de accounts die op de machine mogen aanmelden en de tweede voegt alle andere accounts toe met /sbin/nologin als shell. Het is verstandig om als naam van de netgroep de machinenaam in HOOFDLETTERS te gebruiken. De regels zien er ongeveer als volgt uit: +@MACHINENAAM::::::::: +:::::::::/sbin/nologin Als dit voor alle machines is gedaan, dan hoeven de lokale versies van /etc/master.passwd nooit meer veranderd te worden. Alle toekomstige wijzigingen kunnen dan gemaakt worden door de NIS-afbeelding te wijzigen. Hieronder staat een voorbeeld van een mogelijke netgroep map voor het beschreven scenario met een aantal toevoegingen: # Definieer eerst de gebruikersgroepen IT_MW (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITSTAG (,kilo,test-domain) (,lima,test-domain) D_STAGS (,able,test-domain) (,baker,test-domain) # # En nu een aantal groepen op basis van rollen USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_MW IT_APP SMALLSRV IT_MW IT_APP ITSTAG USERBOX IT_MW ITSTAG USERS # # Een een groep voor speciale taken. # Geef echo en golf toegang tot de anti-virus machine. SECURITY IT_MW (,echo,test-domain) (,golf,test-domain) # # Machinegebaseerde netgroepen # Hoofdservers WAR BIGSRV FAMINE BIGSRV # Gebruiker india heeft toegang tot deze server nodig. POLLUTION BIGSRV (,india,test-domain) # # Deze is erg belangrijk en heeft strengere toegangseisen nodig. DEATH IT_MW # # De anti-virus machine als hierboven genoemd. ONE SECURITY # # Een machine die maar door 1 gebruiker gebruikt mag worden. TWO (,hotel,test-domain) # [...hierna volgen de andere groepen] Als er een soort database wordt gebruikt om de gebruikersaccounts te beheren, dan is het in ieder geval nodig dat ook het eerste deel van de afbeelding met de databaserapportagehulpmiddelen gemaakt kan worden. Dan krijgen nieuwe gebruikers automatisch toegang tot de machines. Nog een laatste waarschuwing: het is niet altijd aan te raden gebruik te maken van machinegebaseerde netgroepen. Als er tientallen of zelfs honderden gelijke machines voor bijvoorbeeld studentenruimtes worden uitgerold, dan is het verstandiger rolgebaseerde netgroepen te gebruiken in plaats van machinegebaseerde netgroepen om de grootte van de NIS-afbeelding binnen de perken te houden. Belangrijk om te onthouden In een NIS-omgeving werken een aantal dingen wel anders. Als er een gebruiker toegevoegd moet worden, dan moet die alleen toegevoegd worden aan de master NIS-server en mag niet vergeten worden dat de NIS-afbeeldingen herbouwd moeten worden. Als dit wordt vergeten, dan kan de nieuwe gebruiker nergens anders aanmelden dan op de NIS-master. Als bijvoorbeeld een nieuwe gebruiker jsmith toegevoegd moet worden: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain Er kan ook adduser jsmith in plaats van pw useradd jsmith gebruikt worden. De beheeraccounts moeten buiten de NIS-afbeeldingen gehouden worden. Het is niet handig als de beheeraccounts en wachtwoorden naar machines waarop gebruikers zich aanmelden die geen toegang tot die informatie horen te hebben zouden gaan. De NIS-master en slave moeten veilig blijven en zo min mogelijk niet beschikbaar zijn. Als de machine wordt gehackt of als hij wordt uitgeschakeld, dan kunnen er in theorie nogal wat mensen niet meer aanmelden. Dit is de belangrijkste zwakte van elk gecentraliseerd beheersysteem. Als de NIS-servers niet goed beschermd worden, dan worden veel gebruikers boos! NIS v1-compatibiliteit ypserv voor &os; biedt wat ondersteuning voor NIS v1 cliënten. De NIS-implementatie van &os; gebruikt alleen het NIS v2 protocol, maar andere implementaties bevatten ondersteuning voor het v1 protocol voor achterwaartse compatibiliteit met oudere systemen. De ypbind-daemons die bij deze systemen zitten proberen een binding op te zetten met een NIS v1 server, hoewel dat niet per se ooit nodig is (en ze gaan misschien nog wel door met broadcasten nadat ze een antwoord van een v2 server hebben ontvangen). Het is belangrijk om te melden dat hoewel ondersteuning voor gewone cliëntoproepen aanwezig is, deze versie van ypserv geen overdrachtsverzoeken voor v1-afbeeldingen af kan handelen. Daarom kan ypserv niet gebruikt worden als master of slave in combinatie met oudere NIS-servers die alleen het v1 protocol ondersteunen. Gelukkig worden er in deze tijd niet meer zoveel van deze servers gebruikt. NIS-servers die ook NIS-cliënten zijn Het is belangrijk voorzichtig om te gaan met het draaien van ypserv in een multi-server domein waar de server machines ook NIS-cliënten zijn. Het is in het algemeen verstandiger om de servers te dwingen met zichzelf te binden dan ze toe te staan een bindverzoek te broadcasten en het risico te lopen dat ze een binding met elkaar maken. Er kunnen vreemde fouten optreden als een van de servers plat gaat als er andere servers van die server afhankelijk zijn. Na verloop van tijd treedt op de cliënten wel een timeout op en verbinden ze met een andere server, maar de daarmee gepaard gaande vertraging kan aanzienlijk zijn en de foutmodus is nog steeds van toepassing, omdat de servers dan toch weer opnieuw een verbinding met elkaar kunnen vinden. Het is mogelijk een host aan een specifieke server te binden door aan ypbind de vlag mee te geven. Om dit niet iedere keer handmatig na een herstart te hoeven uitvoeren, kan de volgende regel worden opgenomen in /etc/rc.conf van de NIS-server: nis_client_enable="YES" # start ook het cliënt gedeelte nis_client_flags="-S NIS domain,server" In &man.ypbind.8; staat meer informatie. Wachtwoordformaten NIS wachtwoordformaten Een van de meest voorkomende problemen bij het implementeren van NIS is de compatibiliteit van het wachtwoordformaat. Als een NIS-server wachtwoorden gebruikt die met DES gecodeerd zijn, dan kunnen alleen cliënten die ook DES gebruiken ondersteund worden. Als er bijvoorbeeld &solaris; NIS-cliënten in een netwerk zijn, dan moet er vrijwel zeker gebruik gemaakt worden van met DES gecodeerde wachtwoorden. Van welk formaat cliënten en servers gebruik maken is te zien in /etc/login.conf. Als een host gebruik maakt van met DES gecodeerde wachtwoorden, dan staat er in de klasse default een regel als de volgende: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Overige regels weggelaten] Andere mogelijke waarden voor passwd_format zijn blf en md5 (respectievelijk voor Blowfish en MD5 gecodeerde wachtwoorden). Als er wijzigingen gemaakt zijn aan /etc/login.conf dan moet de login capability database herbouwd worden door het volgende commando als root uit te voeren: &prompt.root; cap_mkdb /etc/login.conf Het formaat van de wachtwoorden die al in /etc/master.passwd staan worden niet bijgewerkt totdat een gebruiker zijn wachtwoord voor de eerste keer wijzigt nadat de login capability database is herbouwd. Om te zorgen dat de wachtwoorden in het gekozen formaat zijn gecodeerd, moet daarna gecontroleerd worden of de waarde crypt_default in /etc/auth.conf de voorkeur geeft aan het gekozen formaat. Om dat te realiseren dient het gekozen formaat vooraan gezet te worden in de lijst. Als er bijvoorbeeld gebruik gemaakt wordt van DES gecodeerde wachtwoorden, dan hoort de regel er als volgt uit te zien: crypt_default = des blf md5 Als de bovenstaande stappen op alle &os; gebaseerde NIS-servers en cliënten zijn uitgevoerd, dan is het zeker dat ze het allemaal eens zijn over welk wachtwoordformaat er op het netwerk wordt gebruikt. Als er problemen zijn bij de authenticatie op een NIS-cliënt, dan is dit een prima startpunt voor het uitzoeken waar de problemen vandaan komen. Nogmaals: als er een NIS-server in een heterogene omgeving wordt geplaatst, dan is het waarschijnlijk dat er gebruik gemaakt moet worden van DES op alle systemen, omdat dat de laagst overeenkomende standaard is. Greg Sutter Geschreven door Automatisch netwerk instellen (DHCP) Wat is DHCP? Dynamic Host Configuration Protocol DHCP Internet Systems Consortium (ISC) DHCP, het Dynamic Host Configuration Protocol, schrijft voor hoe een systeem verbinding kan maken met een netwerk en hoe het de benodigde informatie kan krijgen om met dat netwerk te communiceren. &os; versies eerder dan 6.0 gebruiken de implementatie van de DHCP-cliënt van het ISC (Internet Systems Consortium), &man.dhclient.8;. Latere versies gebruiken de OpenBSD dhclient die uit OpenBSD 3.7 komt. Alle informatie over dhclient kan zowel voor de ISC als de OpenBSD DHCP-cliënt gebruikt worden. De DHCP-server zit bij de ISC-distributie. Wat behandeld wordt In dit onderdeel worden de cliëntcomponenten van de ISC en OpenBSD DHCP-cliënt en de servercomponenten van het ISC DHCP-systeem beschreven. Het programma voor de cliënt, dhclient, zit standaard in &os; en de server is beschikbaar via de port net/isc-dhcp31-server. Naast de onderstaande informatie, zijn de hulppagina's van &man.dhclient.8;, &man.dhcp-options.5; en &man.dhclient.conf.5; bruikbare bronnen. Hoe het werkt UDP Als dhclient, de DHCP-cliënt, wordt uitgevoerd op een cliëntmachine, dan begint die met het broadcasten van verzoeken om instellingeninformatie. Standaard worden deze verzoeken op UDP poort 68 gedaan. De server antwoordt op UDP 67 en geeft de cliënt een IP-adres en andere relevante netwerkinformatie, zoals een netmasker, router en DNS-servers. Al die informatie komt in de vorm van een DHCP lease en is voor een bepaalde tijd geldig (die is ingesteld door de beheerder van de DHCP-server). Op die manier kunnen IP-adressen voor cliënten die niet langer met het netwerk verbonden zijn (stale) automatisch weer ingenomen worden. DHCP-cliënten kunnen veel informatie van de server krijgen. Er staat een uitputtende lijst in &man.dhcp-options.5;. &os; integratie &os; integreert de OpenBSD of ISC DHCP-cliënt dhclient volledig (afhankelijk van de gebruikte &os; versie). Er is ondersteuning voor de DHCP-cliënt in zowel het installatieprogramma als in het basissysteem, waardoor het niet noodzakelijk is om kennis te hebben van het maken van netwerkinstellingen voor het netwerk waar een DHCP-server draait. dhclient is onderdeel van &os;-distributies sinds 3.2. sysinstall DHCP wordt ondersteund door sysinstall. Bij het instellen van een netwerkinterface binnen sysinstall is de tweede vraag: Wil je proberen de interface met DHCP in te stellen? Als het antwoord bevestigend luidt, dan wordt dhclient uitgevoerd en als dat succesvol verloopt, dan worden de netwerkinstellingen automatisch ingevuld. Voor het gebruiken van DHCP bij het opstarten van het systeem zijn twee instellingen nodig: DHCP vereisten Het apparaat bpf moet in de kernel gecompileerd zijn. Dit kan door device bpf aan het bestand met kernelinstellingen toe te voegen en de kernel te herbouwen. Meer informatie over het bouwen van een kernel staat in . Het apparaat bpf is al onderdeel van de GENERIC kernel die bij &os; zit, dus als er geen sprake is van een aangepaste kernel, dan hoeft er geen nieuwe gemaakt te worden om DHCP aan te praat te krijgen. Voor de lezer die bijzonder begaan is met beveiliging, is het belangrijk aan te geven dat bpf ook het apparaat is waardoor pakketsnuffelaars hun werk kunnen doen (hoewel ze nog steeds als root moeten draaien). bpf is noodzakelijk voor DHCP, maar als beveiliging bijzonder belangrijk is, dan hoort bpf waarschijnlijk niet in een kernel te zitten omdat de verwachting dat er in de toekomst ooit DHCP gebruikt gaat worden. In /etc/rc.conf moet het volgende worden opgenomen: ifconfig_fxp0="DHCP" fxp0 dient vervangen te worden door de juiste aanduiding van de interface die dynamisch ingesteld moet worden, zoals beschreven staat in . Als er een andere lokatie voor dhclient wordt gebruikt of als er extra parameters aan dhclient meegegeven moeten worden, dan dient ook iets als het volgende toegevoegd te worden: dhclient_program="/sbin/dhclient" dhclient_flags="" DHCP server De DHCP-server, dhcpd, zit bij de port net/isc-dhcp31-server in de Portscollectie. Deze port bevat de ISC DHCP-server en documentatie. Bestanden DHCP instellingenbestanden /etc/dhclient.conf Voor dhclient is een instellingenbestand /etc/dhclient.conf nodig. Dat bestand bevat meestal alleen maar commentaar, omdat de standaardinstellingen redelijk zinvol zijn. Dit bestand wordt beschreven in &man.dhclient.conf.5;. /sbin/dhclient dhclient is statisch gelinkt en staat in /sbin. Er staat meer informatie over dhclient in &man.dhclient.8;. /sbin/dhclient-script dhclient-script is het &os;-specifieke DHCP-cliënt instellingenscript. Het wordt beschreven in &man.dhclient-script.8;, maar het is niet nodig het te wijzigen om goed te werken. /var/db/dhclient.leases De DHCP-cliënt houdt in dit bestand een database bij van geldige leases, die naar een logboekbestand worden geschreven. In &man.dhclient.leases.5; staat een iets uitgebreidere beschrijving. Verder lezen Het DHCP-protocol staat volledig beschreven in RFC 2131. Er is nog een bron van informatie ingesteld op . Een DHCP-server installeren en instellen Wat behandeld wordt In dit onderdeel wordt beschreven hoe een &os; systeem zo ingesteld kan worden dat het opereert als DHCP-server door gebruik te maken van de ISC (Internet Systems Consortium) implementatie van de DHCP-server. De server wordt niet geleverd als deel van &os; en om deze dienst aan te bieden dient de port net/isc-dhcp31-server geïnstalleerd te worden. In staat meer informatie over de Portscollectie. DHCP-serverinstallatie DHCP installatie Om een &os; systeem in te stellen als DHCP-server moet het apparaat &man.bpf.4; in de kernel zijn opgenomen. Om dit te doen dient device bpf aan het bestand met kernelinstellingen toegevoegd te worden en dient de kernel herbouwd te worden. Meer informatie over het bouwen van kernels staat in . Het apparaat bpf is al onderdeel van de GENERIC kernel die bij &os;, dus het is meestal niet nodig om een aangepaste kernel te bouwen om DHCP aan de praat te krijgen. Het is belangrijk te vermelden dat bpf ook het apparaat is waardoor pakketsnuffelaars kunnen werken (hoewel de programma's die er gebruik van maken wel bijzondere toegang nodig hebben). bpf is verplicht voor DHCP, maar als beveiliging van belang is, dan is het waarschijnlijk niet verstandig om bpf in een kernel op te nemen alleen omdat er in de toekomst misschien ooit DHCP gebruikt gaat worden. Hierna dient het standaardbestand dhcpd.conf dat door de port net/isc-dhcp31-server is geïnstalleerd gewijzigd te worden. Standaard is dit /usr/local/etc/dhcpd.conf.sample en dit bestand dient gekopieerd te worden naar /usr/local/etc/dhcpd.conf voordat de wijzigingen worden gemaakt. De DHCP-server instellen DHCP dhcpd.conf dhcpd.conf is opgebouwd uit declaraties over subnetten en hosts en is wellicht het meest eenvoudig te beschrijven met een voorbeeld: option domain-name "example.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.example.com; } Deze optie geeft het domein aan dat door cliënten als standaard zoekdomein wordt gebruikt. In &man.resolv.conf.5; staat meer over wat dat betekent. Deze optie beschrijft een door komma's gescheiden lijst met DNS-servers die de cliënt moet gebruiken. Het netmasker dat aan de cliënten wordt voorgeschreven. Een cliënt kan om een bepaalde duur vragen die een lease geldig is. Anders geeft de server aan wanneer de lease vervalt (in seconden). Dit is de maximale duur voor een lease die de server toestaat. Als een cliënt vraagt om een langere lease, dan wordt die wel verstrekt, maar is de maar geldig gedurende max-lease-time seconden. Deze optie geeft aan of de DHCP-server moet proberen de DNS-server bij te werken als een lease is geaccepteerd of wordt vrijgegeven. In de ISC implementatie is deze optie verplicht. Dit geeft aan welke IP-adressen in de groep met adressen zitten die zijn gereserveerd om uitgegeven te worden aan cliënten. Alle IP-adressen tussen de aangegeven adressen en die adressen zelf worden aan cliënten uitgegeven. Geeft de default gateway aan die aan de cliënten wordt voorgeschreven. Het hardware MAC-adres van een host, zodat de DHCP-server een host kan herkennen als die een verzoek doet. Geeft een host aan die altijd hetzelfde IP-adres moet krijgen. Hier kan een hostnaam gebruikt worden, omdat de DHCP-server de hostnaam zelf opzoekt voordat de lease-informatie terug wordt gegeven. Wanneer u klaar bent met het schrijven van uw dhcpd.conf, dient u de DHCP-server in /etc/rc.conf aan te zetten, door het volgende toe te voegen: dhcpd_enable="YES" dhcpd_ifaces="dc0" Vervang de interfacenaam dc0 door de interface (of interfaces, gescheiden door witruimtes) waarop uw DHCP-server moet luisteren naar DHCP-verzoeken van cliënten. Daarna kunt u doorgaan met het starten van de server door het volgende commando te geven: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd start Als er later wijzigingen in de instellingen gemaakt moeten worden, dan is het belangrijk te onthouden dat het sturen van een SIGHUP signaal naar dhcpd niet resulteert in het opnieuw laden van de instellingen, zoals voor de meeste daemons geldt. Voor deze daemon dient een signaal SIGTERM gestuurd te worden om het proces te stoppen. Daarna dient de daemon met het hiervoor beschreven commando weer gestart worden. Bestanden DHCP instellingenbestanden /usr/local/sbin/dhcpd dhcpd is statisch gelinkt en staat in /usr/local/sbin. In de hulppagina voor &man.dhcpd.8; die meekomt met de port staat meer informatie over dhcpd. /usr/local/etc/dhcpd.conf dhcpd heeft een instellingenbestand, /usr/local/etc/dhcpd.conf, nodig voordat de daemon diensten aan cliënten kan leveren. Het bestand moet alle informatie bevatten die aan cliënten gegeven moet worden en de informatie die nodig is voor het draaien van de dienst. Dit instellingenbestand staat beschreven in de hulppagina voor &man.dhcpd.conf.5; die meekomt met de port. /var/db/dhcpd.leases De DHCP-server houdt in dit bestand een database bij met leases die zijn uitgegeven en die naar een logboek worden geschreven. In de hulppagina &man.dhcpd.leases.5; die bij de port zit wordt dit uitvoeriger beschreven. /usr/local/sbin/dhcrelay dhcrelay wordt in uitgebreidere omgevingen gebruikt waar de ene DHCP-server een verzoek van een cliënt naar een andere DHCP-server op een ander netwerk doorstuurt. Als deze functionaliteit nodig is, kan die beschikbaar komen door de port net/isc-dhcp31-relay te installeren. De hulppagina voor &man.dhcrelay.8; die bij de port zit bevat meer details. Chern Lee Geschreven door Tom Rhodes Daniel Gerzo Domeinnaamsysteem (<acronym>DNS</acronym>) Overzicht BIND &os; gebruikt standaard een versie van BIND (Berkeley Internet Name Domain), wat de meest gebruikte implementatie van het DNS-protocol is. DNS is het protocol waarmee namen aan IP-adressen gebonden worden en vice versa. Zo wordt bijvoorbeeld op een zoekopdracht voor www.FreeBSD.org geantwoord met het IP-adres van de webserver van het &os; Project en op een zoekopdracht voor ftp.FreeBSD.org wordt geantwoord met het IP-adres van de bijbehorende FTP-machine. Het tegenovergestelde kan ook gebeuren. Een zoekopdracht voor een IP-adres kan de bijbehorende hostnaam opleveren. Het is niet nodig om een naamserver te draaien om op een systeem zoekopdrachten met DNS uit te voeren. &os; wordt momenteel standaard geleverd met de BIND9 DNS-serversoftware. Onze installatie biedt verbeterde beveilingsmogelijkheden, een nieuwe indeling van het bestandssysteem en geautomatiseerde configuratie van &man.chroot.8;. DNS DNS wordt op Internet onderhouden door een enigszins complex systeem van autoritaire root, Top Level Domain (TLD), en andere kleinschaligere naamservers die individuele domeininformatie hosten en cachen. Op dit moment wordt BIND beheerd door het Internet Systems Consortium . Terminologie Om dit document te begrijpen moeten een aantal termen gerelateerd aan DNS begrepen worden. resolver reverse DNS root zone Term Definitie Voorwaartse DNS Het afbeelden van hostnamen op IP-adressen. Herkomst (origin) Verwijst naar het domein dat door een bepaald zonebestand wordt gedekt. named, BIND Vaak gebruikte namen voor het naamserverpakket BIND in &os;. Resolver Een systeemproces waarmee een machine zoekopdrachten om zoneinformatie aan een naamserver geeft. Reverse DNS Het afbeelden van IP-adressen op hostnamen. Rootzone Het begin van de Internet zonehiërarchie. Alle zones vallen onder de rootzone, net zoals alle bestanden in een bestandssysteem onder de rootmap vallen. Zone Een individueel domein, subdomein of een deel van de DNS die door dezelfde autoriteit wordt beheerd. zones voorbeelden Voorbeelden van zones: . is hoe de rootzone normaliter in de documentatie genoemd wordt. org. is een Top Level Domain (TLD) onder de rootzone. example.org. is een zone onder het TLD org.. 1.168.192.in-addr.arpa is een zone die naar alle IP-adressen verwijst die onder de IP-adresruimte 192.168.1.* vallen. Zoals te zien is staat het specifiekere deel van een hostnaam aan de linkerkant. Zo is bijvoorbeeld example.org. specifieker dan org. en is org. specifieker dan de rootzone. De indeling van ieder deel van een hostnaam lijkt veel op een bestandssysteem: de map /dev valt onder de root, enzovoort. Redenen om een naamserver te draaien Naamservers bestaan in het algemeen in twee smaken: autoratieve naamservers en caching naamservers. Er is een autoratieve naamserver nodig als: Het gewenst is om DNS-informatie aan te bieden aan de wereld om met autoriteit op verzoeken te antwoorden. Een domein, zoals example.org, is geregistreerd en er IP-adressen aan hostnamen die daaronder liggen toegewezen moeten worden. Een IP-adresblok omgekeerde DNS-ingangen nodig heeft (IP naar hostnaam). Een omgekeerde of tweede naamserver, die een slaaf wordt genoemd, moet antwoorden op verzoeken. Er is een caching naamserver nodig als: Een lokale DNS-server kan cachen en wellicht sneller kan antwoorden dan een naamserver die verder weg staat. Als er een verzoek wordt gedaan voor www.FreeBSD.org, dan doet de resolver meestal een verzoek bij de naamserver van de ISP die de uplink levert en ontvangt daarop een antwoord. Met een lokale, caching DNS-server hoeft het verzoek maar één keer door de caching DNS-server naar de buitenwereld gedaan te worden. Voor aanvullende verzoeken hoeft niet buiten het lokale netwerk te gaan omdat het al lokaal in de cache staat. Hoe het werkt De daemon BIND heet in &os; named. Bestand Beschrijving &man.named.8; De daemon BIND. &man.rndc.8; Naamserverbeheerprogramma. /etc/namedb Map waar zoneinformatie van BIND staat. /etc/namedb/named.conf Instellingenbestand van de daemon. Afhankelijk van hoe en gegeven zone op de server is geconfigureerd, staan de bestanden gerelateerd aan die zone in de submappen master, slave, of dynamic van de map /etc/namedb. Deze bestanden bevatten de DNS-informatie die door de naamserver als antwoord op zoekopdrachten gegeven zal worden. BIND starten BIND starten Omdat BIND standaard wordt geïnstalleerd, is het instellen relatief eenvoudig. De standaardconfiguratie van named is die van een eenvoudige resolverende naamserver, draaiende in een &man.chroot.8;-omgeving, en beperkt tot het luisteren op het lokale IPv4-teruglusadres (127.0.0.1). Gebruik het volgende commando om de server eenmaal met deze configuratie te starten: &prompt.root; /etc/rc.d/named onestart Om er zeker van te zijn dat de daemon named elke keer bij het opstarten gestart wordt, moet de volgende regel in /etc/rc.conf gezet worden: named_enable="YES" Het is duidelijk dat er vele instelopties voor /etc/namedb/named.conf zijn die buiten het bereik van dit document vallen. Als u echter geïnteresseerd bent in de opstartopties voor named op &os;, bekijk dan de named_*-vlaggen in /etc/defaults/rc.conf en raadpleeg de handleidingpagina &man.rc.conf.5;. De sectie is ook nuttig om te lezen. Instellingenbestanden BIND instellingenbestanden Instellingenbestanden voor named bevinden zich momenteel in /etc/namedb en moeten gewijzigd worden voor gebruik, tenzij er alleen een eenvoudige resolver nodig is. Hier vindt de meeste configuratie plaats. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // In de handleidingpagina's named.conf(5) en named(8), en in de // documentatie in /usr/share/doc/bind9 zijn meer details te vinden. // // Voor het opzetten van een autoratieve server is een grondig begrip // van de werking van DNS noodzakelijk. Zelfs eenvoudige fouten kunnen // de werking verstoren voor beïnvloede partijen of veel onnodig // Internetverkeer veroorzaken. options { // Relatief aan de chroot-map, indien aanwezig directory "/etc/namedb"; pid-file "/var/run/named/pid" dump-file "/var/dump/named_dump.db" statistics-file "/var/stats/named.stats" // Als named alleen als een lokale resolver gebruikt wordt, is dit een // veilige standaardinstelling. Om named toegang tot het netwerk te // verschaffen, dient deze optie gecommentarieerd te worden, het // juiste IP-adres opgegeven te worden, of dient deze optie verwijderd // te worden. listen-on { 127.0.0.1; }; // Als u IPv6 aan heeft staan op dit systeem, dient deze optie // uitgecommentarieerd te worden om als lokale resolver te dienen. Om // toegang tot het netwerk te verschaffen, dient een IPv6-adres of het // sleutelwoord "any" gegeven te worden. // listen-on-v6 { ::1; }; // Deze zones zijn reeds opgenomen door de lege zones die hieronder // staan. Als u de gerelateerde lege zones hieronder verwijdert, // dienen deze regels uitgecommentarieerd te worden. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // Als er een DNS-server beschikbaar is bij een upstream provider dan // kan het IP-adres op de regel hieronder ingegeven worden en kan die // geactiveerd worden. Hierdoor wordt voordeel gehaald uit de cache, // waardoor het algehele DNS-verkeer op het Internet vermindert. /* forwarders { 127.0.0.1; }; */ // Als de 'forwarders'-clausule niet leeg is, is de standaard om "forward // first" te gebruiken, welke terug zal vallen op het versturen van een // verzoek naar uw lokale server als de naamservers in 'forwarders' het // antwoord niet weten. Als alternatief kunt u uw naamserver dwingen om // nooit zelf verzoeken in te dienen door de volgende regel aan te // zetten: // forward only; // Als u forwarding automatisch wilt configureren gebaseerd op de regels // in /etc/resolv.conf, verwijder dan het commentaar van de volgende // regel en stel named_auto_forward=yes in in /etc/rc.conf. U kunt ook // named_auto_forward_only aanzetten (het effect hiervan is hierboven // beschreven). // include "/etc/namedb/auto_forward.conf"; Zoals al in het commentaar staat kan van een cache in de uplink geprofiteerd worden als forwarders ingeschakeld worden. Onder normale omstandigheden maakt een naamserver recursief verzoeken tot het Internet op zoek naar zekere naamservers tot er een antwoord komt waar het naar op zoek is. Door de bovenstaande optie in te schakelen wordt eerst de uplink naamserver (of de opgegeven naamserver) gevraagd, waardoor er gebruik gemaakt kan worden van de cache van die server. Als die uplink naamserver een drukke, snelle naamserver is, kan het erg de moeite waard zijn om dit aan te zetten. 127.0.0.1 werkt hier niet. Verander dit IP-adres in een naamserver in de uplink. /* Moderne versies van BIND gebruiken standaard een random UDP-poort voor elk uitgaand verzoek om de kans op cache poisoning drastisch te verminderen. Alle gebruikers wordt met klem verzocht om deze mogelijkheid te gebruiken en hun firewalls overeenkomstig aan te passen. ALS EEN LAATSTE UITVLUCHT om om een beperkende firewall heen te werken kunt u proberen om onderstaande optie aan te zetten. Het gebruik van deze optie vermindert uw kans om een cache poisoning aanval te weerstaan aanzienlijk, en dient indien mogelijk te worden vermeden. Vervang NNNNN in het voorbeeld door een getal tussen 49160 en 65530. */ // query-source address * port NNNNN; }; // Als er een lokale naamserver wordt gebruikt, vergeet dan niet om // eerst 127.0.0.1 in /etc/resolv.conf te zetten zodat die gevraagd // wordt. Controleer ook dat het in /etc/rc.conf is aangezet. // Het traditionele root-hint-mechanisme. Gebruik dit OF de // onderstaande slaafzones. zone "." { type hint; file "named.root"; }; /* Het slaaf maken van de volgende zones vanaf de root-naamservers heeft een aantal aanzienlijke voordelen: 1. Snellere lokale resolutie voor uw gebruikers 2. Geen vals verkeer dat vanaf uw netwerk naar de roots wordt verzonden 3. Betere weerstand tegen elke mogelijk falen van de rootserver/DDoS Wel is het zo dat deze methode meer toezicht vraagt dan het hintbestand om er zeker van te zijn dat een onverwachte faalmodus uw server niet heeft lamgelegd. Naamservers die veel clienten serveren zullen meer voordeel uit deze aanpak halen dan individuele hosts. Met zorg gebruiken. Verwijder het commentaar uit de onderstaande regels en commentarieer de bovenstaande hintzone om dit mechanisme te gebruiken. */ zone "." { type slave; file "slave/root.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "arpa" { type slave; file "slave/arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "in-addr.arpa" { type slave; file "slave/in-addr.arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; /* Het lokaal serveren van de volgende zones voorkomt dat enig verzoek voor deze zones uw netwerk verlaat en naar de root-naamservers gaat. Dit heeft twee aanzienlijke voordelen: 1. Snellere lokale resolutie voor uw gebruikers 2. Er zal geen vals verkeer vanaf uw netwerk naar de roots worden verzonden */ // RFC 1912 zone "localhost" { type master; file "master/localhost-forward.db"; }; zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; }; zone "255.in-addr.arpa" { type master; file "master/empty.db"; }; // RFC 1912-stijl zone voor IPv6 localhost adres zone "0.ip6.arpa" { type master; file "master/localhost-reverse.db"; }; // "Dit" netwerk (RFCs 1912 en 3330) zone "0.in-addr.arpa" { type master; file "master/empty.db"; }; // Netwerken voor privaat gebruik (RFC 1918) zone "10.in-addr.arpa" { type master; file "master/empty.db"; }; zone "16.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "17.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "18.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "19.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "20.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "21.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "22.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "23.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "24.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "25.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "26.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "27.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "28.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "29.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "30.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "31.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "168.192.in-addr.arpa" { type master; file "master/empty.db"; }; // Lokale link/APIPA (RFCs 3330 en 3927) zone "254.169.in-addr.arpa" { type master; file "master/empty.db"; }; // TEST-NET voor documentatie (RFC 3330) zone "2.0.192.in-addr.arpa" { type master; file "master/empty.db"; }; // Router benchmarken (RFC 3330) zone "18.198.in-addr.arpa" { type master; file "master/empty.db"; } zone "19.198.in-addr.arpa" { type master; file "master/empty.db"; } // Gereserveerd door IANA - oude ruimte van klasse E zone "240.in-addr.arpa" { type master; file "master/empty.db"; } zone "241.in-addr.arpa" { type master; file "master/empty.db"; } zone "242.in-addr.arpa" { type master; file "master/empty.db"; } zone "243.in-addr.arpa" { type master; file "master/empty.db"; } zone "244.in-addr.arpa" { type master; file "master/empty.db"; } zone "245.in-addr.arpa" { type master; file "master/empty.db"; } zone "246.in-addr.arpa" { type master; file "master/empty.db"; } zone "247.in-addr.arpa" { type master; file "master/empty.db"; } zone "248.in-addr.arpa" { type master; file "master/empty.db"; } zone "249.in-addr.arpa" { type master; file "master/empty.db"; } zone "250.in-addr.arpa" { type master; file "master/empty.db"; } zone "251.in-addr.arpa" { type master; file "master/empty.db"; } zone "252.in-addr.arpa" { type master; file "master/empty.db"; } zone "253.in-addr.arpa" { type master; file "master/empty.db"; } zone "254.in-addr.arpa" { type master; file "master/empty.db"; } // Niet-toegewezen IPv6-adressen (RFC 4291) zone "1.ip6.arpa" { type master; file "master/empty.db"; } zone "2.ip6.arpa" { type master; file "master/empty.db"; } zone "3.ip6.arpa" { type master; file "master/empty.db"; } zone "4.ip6.arpa" { type master; file "master/empty.db"; } zone "5.ip6.arpa" { type master; file "master/empty.db"; } zone "6.ip6.arpa" { type master; file "master/empty.db"; } zone "7.ip6.arpa" { type master; file "master/empty.db"; } zone "8.ip6.arpa" { type master; file "master/empty.db"; } zone "9.ip6.arpa" { type master; file "master/empty.db"; } zone "a.ip6.arpa" { type master; file "master/empty.db"; } zone "b.ip6.arpa" { type master; file "master/empty.db"; } zone "c.ip6.arpa" { type master; file "master/empty.db"; } zone "d.ip6.arpa" { type master; file "master/empty.db"; } zone "e.ip6.arpa" { type master; file "master/empty.db"; } zone "0.f.ip6.arpa" { type master; file "master/empty.db"; } zone "1.f.ip6.arpa" { type master; file "master/empty.db"; } zone "2.f.ip6.arpa" { type master; file "master/empty.db"; } zone "3.f.ip6.arpa" { type master; file "master/empty.db"; } zone "4.f.ip6.arpa" { type master; file "master/empty.db"; } zone "5.f.ip6.arpa" { type master; file "master/empty.db"; } zone "6.f.ip6.arpa" { type master; file "master/empty.db"; } zone "7.f.ip6.arpa" { type master; file "master/empty.db"; } zone "8.f.ip6.arpa" { type master; file "master/empty.db"; } zone "9.f.ip6.arpa" { type master; file "master/empty.db"; } zone "a.f.ip6.arpa" { type master; file "master/empty.db"; } zone "b.f.ip6.arpa" { type master; file "master/empty.db"; } zone "0.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "1.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "2.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "3.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "4.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "5.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "6.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "7.e.f.ip6.arpa" { type master; file "master/empty.db"; } // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" { type master; file "master/empty.db"; } zone "d.f.ip6.arpa" { type master; file "master/empty.db"; } // IPv6 lokale link (RFC 4291) zone "8.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "9.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "a.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "b.e.f.ip6.arpa" { type master; file "master/empty.db"; } // IPv6 verouderde site-lokale adressen (RFC 3879) zone "c.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "d.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "e.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "f.e.f.ip6.arpa" { type master; file "master/empty.db"; } // IP6.INT is verouderd (RFC 4159) zone "ip6.int" { type master; file "master/empty.db"; } // NB: De IP-adressen hieronder zijn bedoeld als voorbeeld en dienen // niet gebruikt te worden! // // Voorbeeld instellingen voor slaafzones. Het kan handig zijn om // tenminste slaaf te worden voor de zone waar de host onderdeel van // uitmaakt. Bij uw netwerkbeheerder kan het IP-adres van de // verantwoordelijke meester-naamserver nagevraagd worden. // // Vergeet niet om de omgekeerde lookup-zone op te nemen! // Dit is genoemd na de eerste bytes van het IP-adres, in omgekeerde // volgorde, met daarachter ".IN-ADDR.ARPA", of "IP6.ARPA" voor IPv6. // // Het is van groot belang om de werking van DNS en BIND te begrijpen // voordat er een meester-zone wordt opgezet. Er zijn nogal wat // onverwachte valkuilen. Het opzetten van een slaafzone is // gewoonlijk eenvoudiger. // // NB: Zet de onderstaande voorbeelden niet blindelings aan. :-) // Gebruik in plaats hiervan echte namen en adressen. /* Een voorbeeld van een dynamische zone key "exampleorgkey" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "example.org" { type master; allow-update { key "exampleorgkey"; }; file "dynamic/example.org"; }; */ /* Voorbeeld van een omgekeerde slaafzone zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ In named.conf zijn dit voorbeelden van slaafregels voor een voorwaartse en een omgekeerde zone. Voor iedere nieuwe zone die wordt aangeboden dient een nieuwe instelling voor de zone aan named.conf toegevoegd te worden. De eenvoudigste instelling voor de zone example.org kan er als volgt uitzien: zone "example.org" { type master; file "master/example.org"; }; De zone is een master, zoals aangegeven door het statement , waarvan de zoneinformatie in /etc/namedb/example.org staat, zoals het statement aangeeft. zone "example.org" { type slave; file "slave/example.org"; }; In het geval van de slaaf wordt de zoneinformatie voor een zone overgedragen van de master naamserver en opgeslagen in het ingestelde bestand. Als de masterserver het niet meer doet of niet bereikbaar is, dan heeft de slaveserver de overgedragen zoneinformatie nog en kan het die aanbieden. Zonebestanden BIND zonebestanden Een voorbeeldbestand voor een masterzone voor example.org (bestaande binnen /etc/namedb/master/example.org) ziet er als volgt uit: $TTL 3600 ; 1 uur standaard TTL example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serienummer 10800 ; Verversen 3600 ; Opnieuw proberen 604800 ; Verlopen 300 ; Negatieve antwoord-TTL ) ; DNS Servers IN NS ns1.example.org. IN NS ns2.example.org. ; MX Records IN MX 10 mx.example.org. IN MX 20 mail.example.org. IN A 192.168.1.1 ; Machinenamen localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mail IN A 192.168.1.4 mx IN A 192.168.1.5 ; Aliases www IN CNAME example.org. Iedere hostnaam die eindigt op een . is een exacte hostnaam, terwijl alles zonder een . op het einde relatief is aan de oorsprong. Zo wordt ns1 bijvoorbeeld vertaald naar ns1.example.org.. De regels in een zonebestand volgen de volgende opmaak: recordnaam IN recordtype waarde DNS records De meest gebruikte DNS-records: SOA begin van autoriteit (start of authority) NS een bevoegde (autoratieve) name server A een hostadres CNAME de canonieke naam voor een alias MX mail exchanger PTR een domeinnaam pointer (gebruikt in omgekeerde DNS) example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serienummer 10800 ; Ververs na 3 uur 3600 ; Opnieuw proberen na 1 uur 604800 ; Verlopen na 1 week 300 ; Negatieve antwoord-TTL example.org. de domeinnaam, ook de oorsprong voor dit zonebestand. ns1.example.org. de primaire/bevoegde naamserver voor deze zone. admin.example.org. de persoon die verantwoordelijk is voor deze zone, emailadres met @ vervangen. admin@example.org wordt admin.example.org. 2006051501 het serienummer van het bestand. Dit moet iedere keer als het zonebestand wordt aangepast opgehoogd worden. Tegenwoordig geven veel beheerders de voorkeur aan de opmaak yyyymmddrr voor het serienummer. 2006051501 betekent dan dat het voor het laatst is aangepast op 15–05–2006, de laatste 01 betekent dat het zonebestand die dag voor het eerst is aangepast. Het serienummer is belangrijk omdat het slaafnaamservers aangeeft dat een zone is bijgewerkt. IN NS ns1.example.org. Hierboven staat een NS-regel. Voor iedere naamserver die bevoegde antwoorden moet geven voor de zone hoort er zo'n regel te zijn. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 Een A-record geeft een machinenaam aan. Hierboven is te zien dat ns1.example.org zou resolven naar 192.168.1.2. IN A 192.168.1.1 Deze regel kent IP-adres 192.168.1.1 toe aan de huidige oorsprong, in dit geval example.org. www IN CNAME @ Een canoniek naamrecord wordt meestal gebruikt voor het geven van aliassen aan een machine. In het voorbeeld is www een alias naar de master machine waarvan de naam gelijk is aan de domeinnaam example.org (192.168.1.1). CNAME's kunnen nooit samen met een ander soort record voor dezelfde hostnaam gebruikt worden. MX record IN MX 10 mail.example.org. MX records geven aan welke mailservers verantwoordelijk zijn voor het afhandelen van inkomende mail voor de zone. mail.example.org is de hostnaam van een mailserver en 10 is de prioriteit voor die mailserver. Het is mogelijk meerdere mailservers in te stellen met prioriteiten 10, 20, enzovoorts. Een mailserver die probeert mail af te leveren voor example.org probeert dat eerst bij de MX met de hoogste prioriteit (het record met het laagste prioriteitsnummer), daarna de tweede hoogste, enzovoort, totdat de mail afgeleverd kan worden. Voor in-addr.arpa zonebestanden (omgekeerd DNS) wordt dezelfde opmaak gebruikt, maar dan met PTR-regels in plaats van A of CNAME. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serienummer 10800 ; Ververs 3600 ; Opnieuw proberen 604800 ; Verlopen 300 ) ; Negatieve antwoord-TTL IN NS ns1.example.org. IN NS ns2.example.org. 1 IN PTR example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 4 IN PTR mx.example.org. 5 IN PTR mail.example.org. Dit bestand geeft de juiste IP-adressen voor hostnamen in het voorbeelddomein hierboven. Het is het vernoemen waard dat alle namen aan de rechterkant van een PTR-record volledig gekwalificeerd dienen te zijn (i.e. met een . eindigen). Caching naamserver BIND caching naamserver Een caching naamserver is een naamserver wiens primaire rol het oplossen van recursieve verzoeken is. Het dient simpelweg zelf verzoeken in en onthoudt de antwoorden voor later gebruik. Beveiliging Hoewel BIND de meest gebruikte implementatie van DNS is, is er altijd nog het beveiligingsvraagstuk. Soms worden er mogelijke en te misbruiken beveiligingsgaten gevonden. Hoewel &os; named automatisch in een &man.chroot.8;-omgeving plaatst; zijn er verschillende andere beveiligingsmechanismen actief die zouden kunnen helpen om mogelijke aanvallen op de DNS-dienst af te wenden. Het is altijd verstandig om de CERT beveiligingswaarschuwingen te lezen en een abonnement te nemen op de &a.security-notifications; om bij te blijven met de beveiligingsproblemen wat betreft Internet en &os;. Als er problemen ontstaan, kan het bijwerken van broncode en het opnieuw bouwen van named hulp bieden. Verder lezen BIND/named hulppagina's: &man.rndc.8;, &man.named.8;, &man.named.conf.5; Officiële ISC BIND pagina Officieel ISC BIND Forum O'Reilly DNS en BIND 5e Editie RFC1034 - Domeinnamen - Concepten en Faciliteiten RFC1035 - Domeinnamen - Implementatie en Specificatie Murray Stokely Geschreven door Apache HTTP server webservers opzetten Apache Overzicht &os; wordt gebruikt om een paar van de drukste websites ter wereld te draaien. De meeste webservers op Internet maken gebruik van de Apache HTTP Server. Apache softwarepakketten staan op de &os; installatiemedia. Als Apache niet bij de oorspronkelijke installatie van &os; is meegeïnstalleerd, dan kan dat vanuit de port www/apache13 of www/apache22. Als Apache succesvol is geïnstalleerd, moeten er instellingen gemaakt worden. In dit onderdeel wordt versie 1.3.X van de Apache HTTP Server behandeld omdat die het meest gebruikt wordt op &os;. Apache 2.X biedt veel nieuwe mogelijkheden, maar wordt hier niet beschreven. Meer informatie over Apache 2.X is te vinden op . Instellen Apache configuratiebestand Het belangrijkste bestand met instellingen voor de Apache HTTP Server op &os; is /usr/local/etc/apache/httpd.conf. Dit bestand is een typisch &unix; tekstgebaseerd instellingenbestand waarin regels met commentaar beginnen met het karakter #. Het uitputtend beschrijven van alle mogelijke instellingen valt buiten het bereik van dit boek, dus worden alleen de meest gebruikte directieven beschreven. ServerRoot "/usr/local" Hierin wordt de standaard mappenhiërarchie voor de Apache installatie aangegeven. Binaire bestanden staan in de submappen bin en sbin van de serverroot en bestanden met instellingen staan in etc/apache. ServerAdmin beheerder@beheer.adres Het adres waaraan problemen met de server gemaild kunnen worden. Dit adres verschijnt op een aantal door de server gegenereerde pagina's, zoals documenten met foutmeldingen. ServerName www.example.com Met ServerName kan een hostnaam ingesteld worden die wordt teruggezonden aan de cliënten als de naam van de server anders is dan die is ingesteld (gebruik bijvoorbeeld www in plaats van de echte hostnaam). DocumentRoot "/usr/local/www/data" DocumentRoot: de map waaruit de documenten worden geserveerd. Standaard worden alle verzoeken uit deze map gehaald, maar er kunnen symbolische links en aliassen gebruikt worden om naar andere locaties te wijzen. Het is altijd een goed idee om reservekopieën te maken van het instellingenbestand voor Apache vóór het maken van wijzigingen. Als de juiste instellingen gemaakt zijn, kan Apache gestart worden. <application>Apache</application> draaien Apache starten of stoppen Apache draait niet vanuit de inetd super server zoals veel andere netwerkdiensten. Hij is ingesteld om zelfstandig te draaien vanwege beter prestaties voor het afhandelen van inkomende HTTP-verzoeken van webbrowsers van cliënten. Er wordt een shellscriptwrapper bijgeleverd om het starten, stoppen en herstarten zo eenvoudig mogelijk te maken. Het volgende commando start Apache voor de eerste keer: &prompt.root; /usr/local/sbin/apachectl start De server kan op iedere moment gestopt worden met: &prompt.root; /usr/local/sbin/apachectl stop Na het maken van wijzigingen aan het instellingenbestand moet de dienst herstart worden: &prompt.root; /usr/local/sbin/apachectl restart Om Apache te herstarten zonder bestaande connecties te verbreken: &prompt.root; /usr/local/sbin/apachectl graceful In &man.apachectl.8; staat meer informatie. Om Apache met het systeem mee te starten kan de volgende regel aan /etc/rc.conf worden toegevoegd: apache_enable="YES" of voor Apache 2.2: apache22_enable="YES" Als het nodig is additionele commandoregelopties op te geven voor de Apache httpd bij het opstarten, dan kunnen die in de volgende regel in rc.conf meegegeven worden: apache_flags="" Nu de webserver draait, is die te benaderen door een webbrowser te wijzen naar http://localhost/. De standaard webpagina is /usr/local/www/data/index.html. Virtuele hosting Apache ondersteunt twee verschillende manieren van Virtuele Hosting. De eerste methode is Naamgebaseerde Virtuele Hosting. Naamgebaseerde Virtuele Hosting gebruikt de HTTP/1.1 headers van de cliënten om de hostnaam uit te zoeken. Hierdoor kunnen meerdere domeinen hetzelfde IP-adres delen. Om Apache gebruik te laten maken van Naamgebaseerde Virtuele Hosting kan een regel als de volgende in httpd.conf worden opgenomen: NameVirtualHost * Als een webserver www.domein.tld heet en er moet een virtueel domein voor www.anderdomein.tld gaan draaien, dan kunnen de volgende regels aan httpd.conf worden toegevoegd: <VirtualHost *> ServerName www.domein.tld DocumentRoot /www/domein.tld </VirtualHost> <VirtualHost *> ServerName www.anderdomein.tld DocumentRoot /www/anderdomein.tld </VirtualHost> De adressen en de paden uit dit voorbeeld kunnen in echte implementaties uiteraard gewijzigd worden. Meer informatie over het opzetten van virtuele hosts staat in de officiële documentatie voor Apache op Apache modules Apache modules Er zijn veel verschillende Apache modules die functionaliteit toevoegen aan de basisdienst. De &os; Portscollectie biedt op een eenvoudige manier de mogelijkheid om Apache samen met de meeste populaire add-on modules te installeren. mod_ssl webserver veilig SSL cryptografie De module mod_ssl gebruikt de bibliotheek OpenSSL om sterke cryptografie te leveren via de protocollen Secure Sockets Layer (SSL v2/v3) en Transport Layer Security (TLS v1). Deze module levert alles wat nodig is om een getekend certificaat aan te vragen bij een vertrouwde certificaatautoriteit om een veilige webserver onder &os; te kunnen draaien. Als Apache nog niet is geïnstalleerd, dan is er een versie van Apache 1.3.X die mod_ssl bevat en geïnstalleerd kan worden met de www/apache13-modssl port. SSL-ondersteuning is ook voor Apache 2.X beschikbaar in de port www/apache22, waar het standaard is ingeschakeld. Taalbindingen Er zijn Apache-modules beschikbare voor de meeste grote scriptingtalen. Deze modules maken het typisch mogelijk om Apache-modules geheel in een scriptingtaal te schrijven. Ze worden ook vaak gebruikt als een persistente interpreter die in de server zit en die de rompslomp van het starten van een externe interpreter en de opstartvertraging voor dynamische websites vermijdt, zoals beschreven in de volgende sectie. Dynamische websites webservers dynamisch In het afgelopen decennium hebben steeds meer bedrijven zich op Internet gericht om hun omzet te verhogen en hun zichtbaarheid te vergroten. Hiermee is ook de behoefte aan interactieve webinhoud toegenomen. Hoewel sommige bedrijven zoals µsoft; oplossingen hebben geïntroduceerd voor hun eigen (propriëtaire) producten, heeft ook de open source gemeenschap een antwoord op de vraag gegeven. Moderne opties voor dynamische webinhoud zijn onder andere Django, Ruby on Rails, mod_perl, en mod_php. Django Django is een BSD-gelicenseerd raamwerk ontworpen om ontwikkelaars in staat te stellen om snel hoog presterende, elegante webapplicaties te schrijven. Het biedt een vertaling van objecten naar relaties zodat datatypes ontwikkeld kunnen worden als Python-objecten, en er een rijke dynamische databasetoegang voor die objecten kan worden geboden zonder dat de ontwikkelaar ooit SQL hoeft te schrijven. Het biedt ook een uitbreidbaar sjabloonsysteem zodat de applicatielogica is gescheiden van de HTML-presentatie. Django is afhankelijk van mod_python, Apache, en een SQL-database-engine naar keuze. De &os;-port zal al deze vereisten met de juiste vlaggen voor u installeren. Django installeren met Apache2, mod_python3, en PostgreSQL &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL Als Django en deze vereisten eenmaal zijn geïnstalleerd, dient u een Django-projectmap te maken en vervolgens Apache te configureren om de ingebakken Python-interpreter te gebruiken om uw applicatie voor specifieke URL's op uw site aan te roepen. Apache-configuratie voor Django/mod_python U moet een regel aan het Apache-bestand httpd.conf toevoegen om Apache in te stellen om verzoeken voor bepaalde URL's aan uw webapplicatie door te geven: <Location "/"> SetHandler python-program PythonPath "['/map/naar/uw/django-pakketten/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mijnsite.settings PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails Ruby on Rails is een ader opensource webraamwerk dat een volledige ontwikkelstack biedt en geoptimaliseerd is om webontwikkelaars productiever te maken en snel krachtige applicaties te laten ontwikkelen. Het kan eenvoudig vanuit het portssysteem geïnstalleerd worden. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean mod_perl mod_perl Perl Het Apache/Perl integratieproject brengt de volledige kracht van de programmeertaal Perl en de Apache HTTP Server samen. Met de module mod_perl is het mogelijk om Apache-modules volledig in Perl te schrijven. Daarnaast voorkomt een ingebouwde persistente interpreter in de server de rompslomp van het starten van een externe interpreter en de nadelen van de opstarttijd van Perl. mod_perl is op een paar verschillende manieren beschikbaar. Om mod_perl te gebruiken dient herinnerd te worden dat mod_perl 1.0 alleen met Apache 1.3 werkt en dat mod_perl 2.0 alleen met Apache 2.X werkt. mod_perl 1.0 is beschikbaar in www/mod_perl en een statisch gecompileerde versie is beschikbaar in www/apache13-modperl. mod_perl 2.0 is beschikbaar in www/mod_perl2. Tom Rhodes Geschreven door mod_php mod_php PHP PHP, ook bekend als PHP: Hypertext Preprocessor, is een algemene scripttaal die bijzonder geschikt is voor webontwikkeling. Het is mogelijk de taal in te bedden in HTML en de syntaxis is afgeleid van C, &java; en Perl met de bedoeling webontwikkelaars in staat te stellen om snel dynamisch samengestelde pagina's te schrijven. Om ondersteuning voor PHP5 toe te voegen aan de Apache webserver kan eerst de port lang/php5 geïnstalleerd worden. Als de port lang/php5 voor het eerst geïnstalleerd wordt, worden automatisch de beschikbare OPTIONS weergegeven. Als er geen menu wordt weergegeven, omdat de port lang/php5 reeds in het verleden is geïnstalleerd, is het altijd mogelijk om het optiedialoog weer te laten verschijnen door &prompt.root; make config uit te voeren in de map van de port. Controleer in het optiedialoog dat de optie APACHE mod_php5 als een laadbare module voor de webserver Apache bouwt. Een heleboel sites draaien nog steeds PHP4 om verschillende redenen (compatibiliteitszaken of reeds in gebruik genomen webapplicaties). Als mod_php4 nodig is in plaats van mod_php5, gebruik dan de port lang/php4. De port lang/php4 ondersteunt een groot deel van de configuratie- en bouwopties van de port lang/php5. Hiermee worden de modules die nodig zijn voor de ondersteuning van dynamische PHP-applicaties geïnstalleerd en ingesteld. Controleer dat de volgende secties aan /usr/local/etc/apache/httpd.conf zijn toegevoegd: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Na voltooiing is een eenvoudige aanroep van het commando apachectl voor een nette herstart nodig om de module PHP te laden: &prompt.root; apachectl graceful Voor toekomstig bijwerken van PHP zal het commando make config niet nodig zijn; de geselecteerde OPTIONS worden automatisch bewaard door het &os; Ports raamwerk. De ondersteuning voor PHP in &os; is extreem modulair waardoor de basisinstallatie zeer beperkt is. Het is heel gemakkelijk om ondersteuning toe te voegen door de port lang/php5-extensions te gebruiken. Deze port biedt een menugestuurde interface voor de installatie van PHP-uitbreidingen. Als alternatief kunnen individuele uitbreidingen worden geïnstalleerd door de juiste port te gebruiken. Om bijvoorbeeld ondersteuning voor de MySQL databaseserver aan PHP5 toe te voegen kan gewoonweg de port databases/php5-mysql geïnstalleerd worden: Na de installatie van een uitbreiding moet de Apache-server herladen worden om de nieuwe veranderingen in de configuratie op te pikken: &prompt.root; apachectl graceful Murray Stokely Geschreven door File Transfer Protocol (FTP) FTP servers Overzicht Het File Transfer Protocol (FTP) biedt gebruikers een eenvoudige manier om bestanden van en naar een FTP server te verplaatsen. &os; bevat FTP server software, ftpd, in het basissysteem. Hierdoor is het opzetten en beheren van een FTP server op &os; erg overzichtelijk. Instellen De belangrijkste stap bij het instellen is de beslissing welke accounts toegang krijgen tot de FTP server. Een normaal &os; systeem heeft een aantal systeemaccounts die gebruikt worden voor daemons, maar onbekende gebruikers mag niet toegestaan worden van die accounts gebruikt te maken. In /etc/ftpusers staat een lijst met gebruikers die geen FTP toegang hebben. Standaard staan daar de voorgenoemde accounts in, maar het is ook mogelijk om daar gebruikers toe te voegen die geen FTP toegang mogen hebben. Het kan ook wenselijk zijn de FTP toegang voor sommige gebruikers te beperken, maar niet onmogelijk te maken. Dit kan met /etc/ftpchroot. In dat bestand staan gebruikers en groepen waarop FTP toegangsbeperkingen van toepassing zijn. In &man.ftpchroot.5; staan alle details die hier niet beschreven zijn. FTP anoniem Om anonieme FTP toegang voor een server in te schakelen, dient er een gebruiker ftp op een &os; systeem aangemaakt te worden. Dan kunnen gebruikers op de server aanmelden met de gebruikersnaam ftp of anonymous en met ieder wachtwoord (de geldende conventie schrijft voor dat dit een emailadres van de gebruiker is). De FTP server roep bij een anonieme aanmelding &man.chroot.2; aan, zodat er alleen toegang is tot de thuismap van de gebruiker ftp. Er zijn twee tekstbestanden waarin welkomstberichten voor de FTP-cliënten gezet kunnen worden. De inhoud van /etc/ftpwelcome wordt getoond voordat gebruikers een aanmeldprompt zien. Na een succesvolle aanmelding wordt de inhoud van /etc/ftpmotd getoond. Het genoemde pad is relatief ten opzichte van de aanmeldomgeving, dus voor anonieme gebruikers wordt ~ftp/etc/ftpmotd getoond. Als een FTP server eenmaal correct is ingesteld, moet die ingeschakeld worden in /etc/inetd.conf. Daar moet het commentaarkarakter # voor de bestaande ftpd regel verwijderd worden: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Zoals is uitgelegd in , moet de configuratie van inetd worden herladen nadat dit instellingenbestand is gewijzigd. Details over het aanzetten van inetd op uw systeem staan in . Als alternatief kan ftpd ook gestart worden als een op zichzelf staande dienst. In dat geval volstaat het om de juiste variabele in te stellen in /etc/rc.conf: ftpd_enable="YES" Na het instellen van de bovenstaande variabele zal de op zichzelf staande server gestart worden nadat de computer opnieuw is opgestart, of het kan handmatig worden gestart door het volgende commando als root uit te voeren: &prompt.root; /etc/rc.d/ftpd start Nu kan aangemeld worden op de FTP-server met: &prompt.user; ftp localhost Beheren syslog logboekbestanden FTP De ftpd daemon gebruikt &man.syslog.3; om berichten te loggen. Standaard plaatst de systeemlogdaemon berichten over FTP in /var/log/xferlog. De lokatie van het FTP logboek kan gewijzigd worden door de volgende regels in /etc/syslog.conf te wijzigen: ftp.info /var/log/xferlog FTP anoniem Het is verstandig na te denken over de gevaren die op de loer liggen bij het draaien van een anonieme FTP server. Dat geldt in het bijzonder voor het laten uploaden ven bestanden. Het is dan goed mogelijk dat een FTP site een forum wordt om commerciële software zonder licenties uit te wisselen of erger. Als anonieme uploads toch nodig zijn, dan horen de rechten op die bestanden zo te staan dat ze niet door andere anonieme gebruikers gelezen kunnen worden tot er door een beheerder naar gekeken is. Murray Stokely Geschreven door Bestands- en printdiensten voor µsoft.windows; cliënten (Samba) Samba server Microsoft Windows bestandsserver Windows-cliënten printserver Windows-cliënten Overzicht Samba is een populair open source softwarepakket dat bestands- en printdiensten voor µsoft.windows; cliënten biedt. Die cliënten kunnen dan ruimte op een &os; bestandssysteem gebruiken alsof het een lokale schijf is en &os; printers gebruiken alsof het lokale printers zijn. Samba softwarepakketten horen op de &os; installatiemedia te staan. Als Samba bij de basisinstallatie niet mee is geïnstalleerd, dan kan dat alsnog via de net/samba3 port of met het pakket. Instellen Een standaardbestand met instellingen voor Samba wordt geïnstalleerd als /usr/local/etc/smb.conf.default. Dit bestand dient gekopieerd te worden naar /usr/local/etc/smb.conf en voordat Samba gebruikt kan worden, moeten er aanpassingen aan worden gemaakt. smb.conf bevat de instellingen voor Samba, zoals die voor de printers en de gedeelde bestandssystemen die gedeeld worden met &windows; cliënten. Het pakket Samba bevat een webgebaseerde beheermodule die swat heet, waarmee smb.conf op een eenvoudige manier ingesteld kan worden. De Samba webbeheermodule gebruiken (SWAT) De Samba Webbeheermodule (SWAT) draait als een daemon vanuit inetd. Daarom dient voor de volgende regel uit /etc/inetd.conf het commentaarkarakter verwijderd te worden voordat swat gebruikt kan worden om Samba in te stellen: swat stream tcp nowait/400 root /usr/local/sbin/swat swat Zoals is uitgelegd in , moet de configuratie van inetd worden herladen nadat dit instellingenbestand is gewijzigd. Als swat is ingeschakeld in inetd.conf, kan de module gebruikt worden door met een browser een verbinding te maken met . Er dient aangemeld te worden met het root account van het systeem. Na succesvol aanmelden op de hoofdpagina voor de Samba instellingen, is het mogelijk de systeemdocumentatie te bekijken of te starten door op het tabblad Globals te klikken. Het onderdeel Globals correspondeert met de sectie [global] in /usr/local/etc/smb.conf. Systeembrede instellingen Of Samba nu wordt ingesteld door /usr/local/etc/smb.conf direct te bewerken of met swat, de eerste instellingen die gemaakt moeten worden zijn de volgende: workgroup NT Domeinnaam of Werkgroepnaam voor de computers die verbinding gaan maken met de server. netbiosnaam NetBIOS Hiermee wordt de NetBIOS naam waaronder de Samba server bekend zal zijn ingesteld. Standaard is de naam het eerste gedeelte van de DNS-naam van een host. server string Hiermee wordt de string ingesteld die te zien is als het commando net view en een aantal andere commando's die gebruik maken van de beschrijvende tekst voor de server gebruikt worden. Beveiligingsinstellingen Twee van de belangrijkste instellingen in /usr/local/etc/smb.conf zijn het gekozen beveiligingsmodel en het wachtwoord voor cliëntgebruikers. Deze worden met de volgende instellingen gemaakt: security De twee meest gebruikte mogelijkheden hier zijn security = share en security = user. Als de cliënten gebruikersnamen hebben die overeenkomen met hun gebruikersnaam op de &os; machine, dan is het verstandig om te kiezen voor beveiliging op gebruikersniveau. Dit is het standaard beveiligingsbeleid en kent als voorwaarde dat gebruikers zich eerst moeten aanmelden voordat ze toegang krijgen tot gedeelde bronnen. Bij beveiliging op shareniveau hoeft een cliënt niet met een geldige gebruikersnaam en wachtwoord aan te melden op de server voor het mogelijk is om een verbinding te proberen te krijgen met een gedeelde bron. Dit was het standaardbeveiligingsmodel voor oudere versies van Samba. passdb backend NIS+ LDAP SQL database Samba kent aan de achterkant verschillende authenticatiemodellen. Cliënten kunnen authenticeren met LDAP, NIS+, een SQL-database of een aangepast wachtwoordbestand. De standaard authenticatiemethode is smbpasswd. Meer wordt hier niet behandeld. Als aangenomen wordt dat de standaard achterkant smbpasswd wordt gebruikt, dan moet /usr/local/private/smbpasswd gemaakt worden om Samba in staat te stellen cliënten te authenticeren. Als het gewenst is om uw &unix; gebruikersaccounts toegang te geven vanaf &windows; cliënten, gebruik dan het volgende commando: &prompt.root; smbpasswd -a gebruikersnaam Sinds Samba 3.0.23c is de eigenlijke map voor authenticatiebestanden /usr/local/etc/samba. De aanbevolen backend is nu tdbsam, en het volgende commando dient gebruikt te worden om gebruikersaccounts toe te voegen: &prompt.root; pdbedit gebruikersnaam In de Official Samba HOWTO staat meer informatie over instelopties. Met de hier gegeven basisuitleg moet het mogelijk zijn Samba draaiende te krijgen. <application>Samba</application> starten De port net/samba3 voegt een nieuw opstartscript toe, dat gebruikt kan worden om Samba te beheren. Om dit script te activeren, zodat het bijvoorbeeld gebruikt kan worden om Samba te starten, stoppen, of te herstarten, dient de volgende regel aan /etc/rc.conf toegevoegd te worden: samba_enable="YES" Of, voor fijnkorrelig beheer: nmbd_enable="YES" smbd_enable="YES" Dit stelt Samba ook in om automatisch tijdens het opstarten te starten. Vervolgens is het mogelijk om Samba op elk moment te starten door dit te typen: &prompt.root; /usr/local/etc/rc.d/samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Refereer aan voor meer informatie over het gebruikt van rc-scripts. Samba bestaat feitelijk uit drie afzonderlijke daemons. Het script samba start de daemons nmbd en smbd. Als de winbind naamresolutiediensten in smb.conf zijn ingeschakeld, dan start ook de daemon winbindd. Samba kan op ieder moment gestopt worden met: &prompt.root; /usr/local/etc/rc.d/samba stop Samba is een complexe softwaresuite met functionaliteit waarmee verregaande integratie met µsoft.windows; netwerken mogelijk wordt. Informatie die verder gaat dan de basisinstallatie staat op . Tom Hukins Geschreven door Tijd synchroniseren met NTP NTP Overzicht Na verloop van tijd gaat de tijd van een computer meestal uit de pas lopen. Het Netwerk Tijd Protocol (NTP) kan ervoor zorgen dat de tijd accuraat blijft. Veel diensten op Internet zijn afhankelijk, of hebben veel voordeel, van het betrouwbaar zijn van de tijd. Zo ontvangt een webserver bijvoorbeeld veel verzoeken om een bestand te sturen als dat gewijzigd is sinds een bepaald moment. In een LAN-omgeving is het van groot belang dat computers die bestanden delen van eenzelfde server gesynchroniseerde tijd hebben zodat de tijdstempels consistent blijven. Diensten zoals &man.cron.8; zijn ook afhankelijk van een betrouwbare systeemtijd om commando's op het ingestelde moment uit te voeren. NTP ntpd Bij &os; zit de &man.ntpd.8; NTP server die gebruikt kan worden om bij andere NTP servers de tijd op te vragen om de eigen klok gelijk te zetten of om de juiste tijd te verstrekken aan andere apparaten. Passende NTP-servers kiezen NTP servers kiezen Om de tijd te synchroniseren moeten er één of meer NTP-servers beschikbaar zijn. Een lokale systeembeheerder of een ISP heeft wellicht een NTP-server voor dit doel opgezet. Het is verstandig om documentatie te raadplegen en te bekijken of dat het geval is. Er is een online lijst van publiek toegankelijke NTP-servers waarop een NTP-server gezocht kan worden die in geografische zin dichtbij een te synchroniseren computer ligt. Het is belangrijk te voldoen aan het beleid voor de betreffende server en toestemming te vragen als dat in de voorwaarden staat. Het is verstandig meerdere, niet van elkaar afhankelijke, NTP-servers te kiezen voor het geval een van de servers niet langer betrouwbaar is of niet bereikbaar is. &man.ntpd.8; gebruikt de antwoorden die van andere servers ontvangen worden op intelligente wijze: betrouwbare servers krijgen voorrang boven onbetrouwbare servers. Machine instellen NTP instellen Basisinstellingen ntpdate Als het alleen de bedoeling is de tijd te synchroniseren bij het opstarten van een machine, dan kan &man.ntpdate.8; gebruikt worden. Dit kan van toepassing zijn op desktops die regelmatig herstart worden en niet echt regelmatig gesynchroniseerd hoeven te worden. Op sommige machines hoort echter &man.ntpd.8; te draaien. Het gebruik van &man.ntpdate.8; bij het opstarten is ook een goed idee voor machines waarop &man.ntpd.8; draait. De &man.ntpd.8; wijzigt de tijd geleidelijk, terwijl &man.ntpdate.8; gewoon de tijd instelt, hoe groot het verschil tussen de bestaande tijd van een machine en de correcte tijd ook is. Om &man.ntpdate.8; tijdens het opstarten in te schakelen kan ntpdate_enable="YES" aan /etc/rc.conf worden toegevoegd. Alle voor de synchronisatie te gebruiken servers moeten dan, samen met eventuele opties voor &man.ntpdate.8;, in ntpdate_flags aangegeven worden. NTP ntp.conf Algemene instellingen NTP wordt ingesteld met het bestand /etc/ntp.conf in het formaat dat beschreven staat in &man.ntp.conf.5;. Hieronder volgt een eenvoudig voorbeeld: server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift De optie server geeft aan welke servers er gebruikt moeten worden, met op elke regel een server. Als de server wordt ingesteld met het argument prefer, zoals bij ntplocal.example.com, dan krijgt die server de voorkeur boven de andere. Een antwoord van een voorkeursserver wordt genegeerd als dat significant afwijkt van de antwoorden van de andere servers. In andere gevallen wordt het gebruikt zonder rekening te houden met de andere antwoorden. Het argument prefer wordt meestal gebruikt voor NTP-servers waarvan bekend is dat ze erg betrouwbaar zijn, zoals die met speciale tijdbewakingshardware. De optie driftfile geeft aan welk bestand gebruikt wordt om de offset van de klokfrequentie van het systeem op te slaan. &man.ntpd.8; gebruikt die om automatisch te compenseren voor het natuurlijke afwijken van de tijd, zodat er zelfs bij gebrek aan externe bronnen een redelijke accurate tijdsinstelling mogelijk is. De optie driftfile geeft aan welk bestand gebruikt wordt om informatie over eerdere antwoorden van NTP-servers die gebruikt worden op te slaan. Dit bestand bevat interne informatie voor NTP. Het hoort niet door andere processen gewijzigd te worden. Toegang tot een server instellen Een NTP-server is standaard toegankelijk voor alle hosts op een netwerk. De optie restrict in /etc/ntp.conf maakt het mogelijk om aan te geven welke machines de dienst mogen benaderen. Voor het blokkeren van toegang voor alle andere machines kan de volgende regel aan /etc/ntp.conf toegevoegd worden: restrict default ignore Dit zal ook toegang van uw server naar alle servers die vermeld staan in uw lokale configuratie verhinderen. Als u uw NTP-server moet synchroniseren met een externe NTP-server, dient u deze specifieke server toe te staan. Lees de handleiding voor &man.ntp.conf.5; voor meer informatie. Om alleen machines op bijvoorbeeld het lokale netwerk toe te staan hun tijd te synchroniseren met een server, maar ze tegelijkertijd niet toe te staan om de server te draaien of de server als referentie voor synchronisatie te gebruiken, kan de volgende regel toegevoegd worden: restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap Hierboven is 192.168.1.0 een IP-adres op een LAN en 255.255.255.0 is het bijbehorende netwerkmasker. /etc/ntp.conf mag meerdere regels met restrict bevatten. Meer details staan in het onderdeel Access Control Support van &man.ntp.conf.5;. De NTP-server draaien De NTP-server kan bij het opstarten gestart worden door de regel ntpd_enable="YES" aan /etc/rc.conf toe te voegen. Om extra opties aan &man.ntpd.8; mee te geven kan de parameter ntpd_flags in /etc/rc.conf gebruikt worden. Om de server zonder een herstart van de machine te starten kan ntpd uitgevoerd worden, met toevoeging van de parameters uit ntpd_flags in /etc/rc.conf. Bijvoorbeeld: &prompt.root; ntpd -p /var/run/ntpd.pid ntpd gebruiken met een tijdelijke Internetverbinding &man.ntpd.8; heeft geen permanente verbinding met een netwerk nodig om goed te werken. Maar als er gebruik gemaakt wordt van een inbelverbinding, is het wellicht verstandig om ervoor te zorgen dat uitgaande NTP-verzoeken geen uitgaande verbinding kunnen starten. Als er gebruik gemaakt wordt van gebruikers-PPP, kunnen er filter commando's ingesteld worden in /etc/ppp/ppp.conf. Bijvoorbeeld: set filter dial 0 deny udp src eq 123 # NTP-verkeer zorgt niet voor uitbellen set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Inkomend NTP-verkeer houdt de verbinding niet open set filter alive 1 deny udp dst eq 123 # Uitgaand NTP-verkeer houdt de verbinding niet open set filter alive 2 permit 0/0 0/0 Meer details staan in de sectie PACKET FILTERING in &man.ppp.8; en in de voorbeelden in /usr/share/examples/ppp/. Sommige Internetproviders blokkeren lage poorten, waardoor NTP niet kan werken omdat er nooit een antwoord ontvangen kan worden door een machine. Meer informatie HTML-documentatie voor de NTP-server staat in /usr/share/doc/ntp/. Tom Rhodes Bijgedragen door Hosts op afstand loggen met <command>syslogd</command> Het omgaan met systeemlogs is een cruciaal aspect van zowel beveiligings- als systeembeheer. Het in de gaten houden van logbestanden van meerdere hosts kan nogal onhandelbaar worden als deze hosts over (middel)grote netwerken zijn verspreid, of wanneer ze deel zijn van verschillende soorten netwerken. In deze gevallen kan het op afstand loggen het gehele proces een stuk aangenamer maken. Het centraal loggen naar een specifieke loghost kan wat van de administratieve last van het beheren van logbestanden wegnemen. Het aggregeren, samenvoegen, en roteren van logbestanden kan op één enkele plaats worden ingesteld, door gebruik te maken van de eigen gereedschappen van &os;, zoals &man.syslogd.8; en &man.newsyslog.8;. In de volgende voorbeeldconfiguratie zal host A, genaamd logserv.example.com, loginformatie voor het plaatselijke netwerk verzamelen. Host B, genaamd logclient.example.com, zal loginformatie aan het serversysteem doorgeven. In echte configuraties hebben beide hosts degelijke voor- en terugwaartse DNS of regels in /etc/hosts nodig. Anders worden de gegevens geweigerd door de server. Configuratie van de logserver Logservers zijn machines die zijn geconfigureerd om loginformatie van hosts op afstand te accepteren. In de meeste gevallen is dit om de configuratie te vergemakkelijken, in andere gevallen kan het gewoon een beheersbeslissing zijn. Ongeacht de reden zijn er enkele eisen voordat er verder wordt gegaan. Een juist geconfigureerde logserver voldoet aan de volgende minimale eisen: De regels van de firewall staan toe dat UDP wordt doorgegeven op poort 514 van zowel de cliënt als de server; syslogd is ingesteld om berichten op afstand van cliëntmachines te accepteren; De syslogd-server en alle cliëntmachines moeten geldige regels hebben voor zowel voorwaartse als terugwaartse DNS, of correct zijn geconfigureerd in /etc/hosts. Om de logserver te configureren, moet de cliënt vermeld zijn in /etc/syslog.conf, en moet de logfaciliteit zijn gespecificeerd: +logclient.example.com *.* /var/log/logclient.log Meer informatie over de verschillende ondersteunde en beschikbare faciliteiten kan gevonden worden in de handleidingpagina &man.syslog.conf.5;. Eenmaal toegevoegd worden alle faciliteits-berichten gelogd naar het eerder gespecificeerde bestand, /var/log/logclient.log. De servermachine moet ook het volgende in /etc/rc.conf hebben staan: syslogd_enable="YES" syslogd_flags="-a logclient.example.com -vv" De eerste optie zet de daemon syslogd aan tijdens het opstarten, en de tweede regel staat toe dat gegevens van de cliënt op deze server worden geaccepteerd. Het laatste gedeelte, dat gebruikt, verhoogt de verbositeit van gelogde berichten. Dit is extreem handig voor het optimaal instellen van faciliteiten aangezien beheerders kunnen zien welk soort berichten onder welke faciliteit worden gelogd. Er kunnen meerdere opties worden gespecificeerd om logging vanuit meerdere cliënten toe te staan. IP-adressen en hele netblokken mogen ook worden gespecificeerd, bekijk de hulppagina &man.syslog.3; voor een volledige lijst van mogelijke opties. Als laatste dient het logbestand gecreëerd te worden. De gebruikte manier maakt niet uit, maar &man.touch.1; werkt prima in dit soort situaties: &prompt.root; touch /var/log/logclient.log Nu dient het syslogd-daemon herstart en geverifieerd worden: &prompt.root; /etc/rc.d/syslogd restart &prompt.root; pgrep syslog Als er een PID wordt teruggegeven, dan is de server succesvol herstart, en kan er begonnen worden met de configuratie van de cliënt. Raadpleeg de log /var/log/messages voor uitvoer als de server niet is herstart. Configuratie van de logcliënt Een logcliënt is een machine die loginformatie naar een logserver verstuurt en daarnaast lokale kopieën bewaart. Net als logservers moeten logcliënten ook aan enkele minimumeisen voldoen: &man.syslogd.8; moet zijn ingesteld om berichten van bepaalde soorten naar een logserver te sturen, die ze moet accepteren; De firewall moet UDP-pakketten doorlaten op poort 514; Zowel voorwaartse als terugwaartse DNS moeten geconfigureerd zijn of juiste regels in /etc/hosts hebben. De configuratie van cliënten is wat soepeler dan die van servers. De cliëntmachine moet de volgende regels in /etc/rc.conf hebben: syslogd_enable="YES" syslogd_flags="-s -vv" Net als eerder zullen deze regels de daemon syslogd tijdens het opstarten aanzetten, en de verbositeit van gelogde berichten verhogen. De optie voorkomt dat logs van deze cliënt vanuit andere hosts worden geaccepteerd. Faciliteiten beschrijven het systeemgedeelte waarvoor een bericht is gegenereerd. ftp en ipfw bijvoorbeeld zijn beide faciliteiten. Wanneer er logberichten worden gegenereerd voor deze twee diensten, zullen ze normaalgesproken deze twee gereedschappen in elk logbericht opnemen. Faciliteiten worden vergezeld van een prioriteit of niveau, welke wordt gebruikt om aan te geven hoe belangrijk een logbericht is. De meest voorkomende zullen warning en info zijn. Bekijk de handleidingpagina &man.syslog.3; voor een volledige lijst van beschikbare faciliteiten en prioriteiten. De logserver moet in /etc/syslog.conf van de cliënt zijn gedefinieerd. In dit geval wordt het symbool @ gebruikt om loggegevens naar een server op afstand te sturen en zou er ongeveer als de volgende regel uit moeten zien: *.* @logserv.example.com Eenmaal toegevoegd moet syslogd worden herstart zodat de veranderingen effect hebben: &prompt.root; /etc/rc.d/syslogd restart Om te testen of logberichten over het netwerk worden verzonden, wordt &man.logger.1; op de cliënt gebruikt om een bericht naar syslogd te sturen: - &prompt.root; logger "Testbericht van logclient" + &prompt.root; logger "Testbericht van logclient" Dit bericht dient nu zowel in /var/log/messages op de cliënt als /var/log/logclient.log op de logserver te staan. Logservers debuggen In bepaalde gevallen kan het nodig zijn om te debuggen als berichten niet door de logserver worden ontvangen. Er zijn verschillende redenen waarom dit kan gebeuren; de twee meest voorkomende zijn echter voorvallen met de netwerkverbinding en DNS. Om deze gevallen te testen, dient te worden nagegaan dat beide hosts elkaar kunnen bereiken door de hostnaam in /etc/rc.conf te gebruiken. Als dit juist lijkt te werken, dient de optie syslogd_flags in /etc/rc.conf te worden veranderd. In het volgende voorbeeld is /var/log/logclient.log leeg, en noemt /var/log/messages geen reden waarom het mislukt. Verander de optie syslogd_flags zoals in het volgende voorbeeld en herstart om de debuguitvoer te verhogen: syslogd_flags="-d -a logclien.example.com -vv" &prompt.root; /etc/rc.d/syslogd restart Debuggegevens zoals de volgende zullen meteen na de herstart over het scherm vliegen: logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel Logging to FILE /var/log/messages syslogd: kernel boot file is /boot/kernel/kernel cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; rejected in rule 0 due to name mismatch. Het is duidelijk dat de berichten worden geweigerd wegens een niet-overeenkomende naam. Na de configuratie grondig te hebben herzien, lijkt het of een typefout in de volgende regel in /etc/rc.conf een probleem heeft: syslogd_flags="-d -a logclien.example.com -vv" De regel dient logclient, niet logclien te bevatten. Nadat de juiste wijzigingen zijn gemaakt, wordt er herstart met de verwachte resultaten: &prompt.root; /etc/rc.d/syslogd restart logmsg: pri 56, flags 4, from logserv.example.com, msg syslogd: restart syslogd: restarted logmsg: pri 6, flags 4, from logserv.example.com, msg syslogd: kernel boot file is /boot/kernel/kernel syslogd: kernel boot file is /boot/kernel/kernel logmsg: pri 166, flags 17, from logserv.example.com, msg Dec 10 20:55:02 <syslog.err> logserv.example.com syslogd: exiting on signal 2 cvthname(192.168.1.10) validate: dgram from IP 192.168.1.10, port 514, name logclient.example.com; accepted in rule 0. logmsg: pri 15, flags 0, from logclient.example.com, msg Dec 11 02:01:28 trhodes: Test message 2 Logging to FILE /var/log/logclient.log Logging to FILE /var/log/messages Nu worden de berichten juist ontvangen en in het correcte bestand geplaatst. Beveiligingsoverwegingen Zoals bij alle netwerkdiensten, dienen beveiligingseisen in acht te worden genomen voordat deze configuratie wordt geïmplementeerd. Soms kunnen logbestanden gevoelige gegevens bevatten over diensten die aanstaan op de lokale host, gebruikersaccounts, en configuratiegegevens. Netwerkgegevens die van de cliënt naar de server worden verzonden worden niet versleuteld noch met een wachtwoord beveiligd. Als versleuteling nodig is, kan security/stunnel worden gebruikt, wat gegevens over een versleutelde tunnel verstuurt. Aan lokale beveiliging moet ook gedacht worden. Logbestanden worden niet versleuteld tijdens gebruik of na logrotatie. Lokale gebruikers kunnen deze bestanden benaderen om aanvullende inzichten over de systeemconfiguratie op te doen. In deze gevallen is het van kritiek belang om de juiste rechten op deze bestanden in te stellen. Het gereedschap &man.syslogd.8; ondersteunt het instellen van rechten op nieuw aangemaakte en geroteerde logbestanden. Het instellen van logbestanden op modus 600 dient al het ongewenste spieken door lokale gebruikers te verhinderen.