diff --git a/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml index 5709380d4e..fa3029a6b4 100644 --- a/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/mirrors/chapter.sgml @@ -1,3344 +1,3356 @@ &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 - Saint-Petersburg + 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) Japan: :pserver:anoncvs@anoncvs.jp.FreeBSD.org:/home/ncvs Gebruik cvs login en gebruik als wachtwoord anoncvs 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)) 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) 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 Cal Poly. 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 je echter complete repositories wilt schaduwen, is CVSup nog steeds noodzakelijk. 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_7 De ontwikkellijn voor &os;-7.X, ook bekend als &os; 7-STABLE. 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_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://cvsup4.ru.FreeBSD.org/ Beschikbare collecties: FreeBSD-gnats: De GNATS bug-tracking database. 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 d51c3d185d..b2f7a03f12 100644 --- a/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml @@ -1,5652 +1,5786 @@ 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. Nu hoeft alleen /etc/netstart als supergebruiker uitgevoerd te worden. Dat stelt alles in met gebruikmaking van de waarden uit /etc/rc.conf. 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: +:*:: 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 Software Consortium (ISC) + 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 ISC - (Internet Software Consortium) DHCP-cliënt - (&man.dhclient.8;) implementatie. Latere versies gebruiken de - OpenBSD dhclient die uit OpenBSD 3.7 + 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-dhcp3-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-dhcp3-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 Software Consortium) + 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-dhcp3-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-dhcp3-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.sh 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-dhcp3-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 Software - Consortium . + 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, - naamserver + 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 tegenovergestelde van voorwaartse DNS; het - afbeelden van IP-adressen op + 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 de rootzone. + . 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-ruimte 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: een autoratieve naamserver en een caching naamserver. 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 ieder volgend verzoek hoeft niet buiten het lokale netwerk gekeken te worden omdat het al lokaal in de cache staat. Hoe het werkt - Om begrijpelijke redenen heet de daemon BIND in &os; + 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 - resolvende naamserver, draaiende in een &man.chroot.8;-omgeving. - Gebruik het volgende commando om de server eenmaal met deze - configuratie te starten: + 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 forcestart + &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. - - <command>make-localhost</command> gebruiken - - Ga om een masterzone voor de lokale host in te stellen - naar de map /etc/namedb - en draai het volgende commando: - - &prompt.root; sh make-localhost - - Als alles goed ging zou er een nieuw bestand in de submap - master moeten staan. - De bestandsnamen zouden localhost.rev - voor de lokale domeinnaam en - localhost-v6.rev voor - IPv6-configuraties moeten zijn. Voor het - standaardinstellingenbestand staat de benodigde informatie in - het bestand named.conf. - - <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; }; -// Als aanvulling op de "forwarders" clausule kan de naamserver ook -// worden aangegeven dat hij nooit zelf verzoeken mag maken, maar dat -// altijd aan zijn forwarders moet vragen door de volgende regel te -// activeren: -// -// forward only; +// 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. /* - * Als er een firewall tussen een host en naamservers staat waarmee - * gesproken moet worden, dan dient het commentaar voor de - * query-source directive hieronder verwijderd te worden. In eerdere - * versies van BIND werden verzoeken altijd via poort 53 gedaan, maar - * versie 8 en later van BIND gebruiken standaard een pseudo-random - * poort zonder privileges. - */ - // query-source address * port 53; + 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 hint; - file "named.root"; + type slave; + file "slave/root.slave"; + masters { + 192.5.5.241; // F.ROOT-SERVERS.NET. + }; + notify no; }; -zone "0.0.127.IN-ADDR.ARPA" { - type master; - file "master/localhost.rev"; +zone "arpa" { + type slave; + file "slave/arpa.slave"; + masters { + 192.5.5.241; // F.ROOT-SERVERS.NET. + }; + notify no; }; -// RFC 3152 -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" { - type master; - file "master/localhost-v6.rev"; +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 primaire zone nagevraagd worden. +// verantwoordelijke meester-naamserver nagevraagd worden. // -// De omgekeerde lookupzone (IN-ADDR.ARPA) mag nooit vergeten worden! -// (Dit is genoemd naar de eerste bytes van het IP-adres, in omgekeerde -// volgorde, met daarachter ".IN-ADDR.ARPA".) +// 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 primaire zone wordt opgezet. Er zijn nogal wat +// voordat er een meester-zone wordt opgezet. Er zijn nogal wat // onverwachte valkuilen. Het opzetten van een slaafzone is -// eenvoudiger. +// gewoonlijk eenvoudiger. // // NB: Zet de onderstaande voorbeelden niet blindelings aan. :-) // Gebruik in plaats hiervan echte namen en adressen. -/* Een voorbeeld van een masterzone -zone "example.net" { - type master; - file "master/example.net"; -}; -*/ - /* 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"; }; */ -/* Voorbeelden van voorwaartse en omgekeerde slaafzones -zone "example.com" { - type slave; - file "slave/example.com"; - masters { - 192.168.1.1; - } -}; +/* Voorbeeld van een omgekeerde slaafzone zone "1.168.192.in-addr.arpa" { type slave; - file "s/1.168.192.in-addr.arpa.bak"; + 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 + $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 - 86400 ; Minimum TTL + 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 @ +www IN CNAME example.org. Iedere hostnaam die eindigt op een . is een exacte hostnaam, terwijl alles zonder een - . op het einde refereert aan de oorsprong. - Zo wordt www bijvoorbeeld vertaald naar - www.origin. - In de zone uit het voorbeeld hierboven is de oorsprong - example.org., dus www - vertaalt naar www.example.org. + . 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. ( + 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 - 86400 ) ; Minimum TTL van 1 dag + 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. + 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 + 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 + 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 @ + 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 - gebruikt worden om een alias aan hostnamen te geven of om - round-robin één hostnaam naar meerdere machines - te laten wijzen. + nooit samen met een ander soort record voor dezelfde hostnaam + gebruikt worden. MX record - - IN MX 10 mail.example.org. + 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 voor de 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 - 3600 ) ; Minimum + 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 die voor geen - enkele zone bevoegd is en alleen verzoeken doet en die onthoudt - voor later gebruik. Het opzetten ervan is eenvoudigweg het - opzetten van een naamserver zonder zones toe te voegen. + 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 geen kwaad doen. Verder lezen BIND/named hulppagina's: &man.rndc.8;, &man.named.8;, &man.named.conf.5; Officiële + url="https://www.isc.org/software/bind/">Officiële ISC BIND pagina Officieel ISC BIND + url="https://www.isc.org/software/guild/">Officieel ISC BIND Forum - - BIND9 - FAQ - - O'Reilly DNS en BIND 5e Editie RFC1034 - + url="http://www.rfc-editor.org/rfc/rfc1034.txt">RFC1034 - Domeinnamen - Concepten en Faciliteiten RFC1035 - + url="http://www.rfc-editor.org/rfc/rfc1035.txt">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" 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.