Hoofdstuk 29. Netwerkdiensten

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.

inetd wordt gestart door het rc(8)-systeem. De optie inetd_enable staat standaard op NO, maar kan tijdens de installatie door sysinstall worden aangezet. Door het plaatsen van

of

in /etc/rc.conf wordt inetd bij het opstarten van een systeem wel of niet ingeschakeld. Het commando:

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.

Zoals de meeste serverdaemons heeft inetd een aantal opties die doorgegeven kunnen worden om het gedrag aan te passen. Zie de handleidingpagina inetd(8) voor een volledige lijst van de opties.

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.

Ook al worden er hieronder rate-limiting opties besproken, beginnende gebruikers kunnen blij zijn met het feit dat deze parameters gewoonlijk niet hoeven te worden aangepast. Deze opties kunnen interessant zijn wanneer er een buitensporige hoeveelheid verbindingen worden opgezet. Een volledige lijst van opties staat in de hulppagina inetd(8).

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:

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:

Een voorbeeldregel voor de daemon ftpd(8) met IPv4 kan eruit zien als:

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 max-connections-per-ip-per-minute, max-child of max-child-per-ip 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 hosts_access(5).

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 inetd(8).

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:

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 nfsiod(8).

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:

mountd start automatisch als de NFS server is ingeschakeld.

Op de cliënt dient de volgende optie in /etc/rc.conf te staan:

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 exports(5).

Nu volgen een aantal voorbeelden voor /etc/exports:

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 -ro exporteert het bestandssysteem als alleen-lezen. Door die vlag kan een ander systeem niet schrijven naar het geëxporteerde bestandssysteem.

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 hosts(5). Met de vlag -alldirs 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.

Het volgende voorbeeld exporteert /a zo dat twee cliënten uit verschillende domeinen bij het bestandssysteem mogen. Met de vlag -maproot=root mag de gebruiker op het andere systeem gegevens naar het geëxporteerde bestandssysteem schrijven als root. Als de vlag -maproot=root niet wordt gebruikt, dan kan een gebruiker geen bestanden wijzigen op het geëxporteerde bestandssysteem, zelfs niet als een gebruiker daar root is.

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:

Eén bestandssysteem, /usr, heeft twee regels waarin exports naar dezelfde host worden aangegeven, client. In deze situatie is de juiste instelling:

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:

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:

of door het rc(8) script mountd met de juiste parameter aan te roepen:

Raadpleeg Gebruik van rc met FreeBSD voor meer informatie over het gebruik van rc-scripts.

Het is ook mogelijk een machine te herstarten, zodat FreeBSD 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:

Op de NFS cliënt:

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:

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:

Alle beschikbare opties staan in fstab(5).

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):

Start de applicatie met:

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 -L aan mount_nfs(8) door te geven. In de handleidingpagina mount_nfs(8) staan verdere details.

NFS is voor veel doeleinden in te zetten. Een aantal voorbeelden:

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.

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:

Er kunnen ook nog opties meegegeven worden aan amd met de optie amd_flags. Standaard staat amd_flags ingesteld op:

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 amd(8) en amd.conf(8) staat meer informatie.

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 FreeBSD, maar het kan op FreeBSD wel voor komen.

Het probleem ontstaat bijna altijd als (FreeBSD) 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 FreeBSD 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 FreeBSD systeem is, is er zo om het probleem heen te werken dat het werkbaar is. Als FreeBSD de server is, kan de optie -w=1024 gebruikt worden bij het aankoppelen door de cliënt. Als het FreeBSD systeem de cliënt is, dan dient het NFS-bestandssysteem aangekoppeld te worden met de optie r=1024. Deze opties kunnen het vierde veld zijn in een regel in fstab voor automatische aankoppelingen en bij handmatige aankoppelingen met mount(8) kan de parameter -o 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 FreeBSD systeem met een Ethernet adapter die mindere prestaties levert. /sharedfs wordt het geëxporteerde NFS-bestandssysteem (zie exports(5)) en /project wordt het koppelpunt voor het geëxporteerde bestandssysteem op de cliënt.

Voorbeelden voor het FreeBSD systeem (freebox) als de cliënt in /etc/fstab op freebox:

Als een handmatig aankoppelcommando op freebox:

Voorbeelden voor het FreeBSD systeem als de server in /etc/fstab op fastws:

Als een handmatig aankoppelcommando op fastws:

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 "block"grootte 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.

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, FreeBSD, enzovoort) ondersteunen NIS.

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.

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.

Het is te vergelijken met het Windows NT® domeinsysteem en hoewel de interne implementatie van de twee helemaal niet overeenkomt, is de basisfunctionaliteit vergelijkbaar.

Er zijn een aantal termen en belangrijke gebruikersprocessen die een rol spelen bij het implementeren van NIS op FreeBSD, zowel bij het maken van een NIS-server als bij het maken van een systeem dan NIS-cliënt is:

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.

Dit onderdeel behandelt het opzetten van een NIS-voorbeeldomgeving.

In het algemeen kan iedere netwerkgebruiker een RPC-verzoek doen uitgaan naar ypserv(8) en de inhoud van de NIS-afbeeldingen ontvangen, mits die gebruiker de domeinnaam kent. Omdat soort ongeautoriseerde transacties te voorkomen, ondersteunt ypserv(8) de optie "securenets", die gebruikt kan worden om de toegang te beperken tot een opgegeven aantal hosts. Bij het opstarten probeert ypserv(8) de securenets informatie te laden uit het bestand /var/yp/securenets.

Als 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.

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 -gebruikersnaam met het juiste aantal dubbele punten (zoals bij andere regels) aan het einde van /etc/master.passwd op de cliëntmachine toegevoegd te worden, waar gebruikersnaam de gebruikersnaam van de gebruiker die niet mag aanmelden is. De regel met de geblokkeerde gebruiker moet voor de regel met + staan om NIS-gebruikers toe te staan. 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 te kunnen laten aanmelden op basie:

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.

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. ypinit(8) van FreeBSD maakt deze map niet standaard, maar als die is gemaakt, ondersteunt de NIS-implementatie hem wel. Een lege map wordt als volgt gemaakt:

Nu kan hij gevuld worden. In het gebruikte voorbeeld zijn tenminste vier netgroepen: IT-medewerkers, IT-junioren, gewone medewerkers en stagiars.

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:

Al deze velden kunnen jokerkarakters bevatten. Details daarover staan in netgroup(5).

Het activeren en distribueren van de nieuwe NIS-map is eenvoudig:

Hiermee worden drie nieuwe NIS-afbeeldingen gemaakt: netgroup, netgroup.byhost en netgroup.byuser. Met ypcat(1) kan bekeken worden op de nieuwe NIS-afbeeldingen beschikbaar zijn:

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 vipw(8) de volgende regel in de regel daarna vervangen te worden:

Vervang de bovenstaande regel in de onderstaande.

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:

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.

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:

Voor normale werkstations zijn het de volgende regels:

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:

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:

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:

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.

In een NIS-omgeving werken een aantal dingen wel anders.

ypserv voor FreeBSD biedt wat ondersteuning voor NIS v1 cliënten. De NIS-implementatie van FreeBSD 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.

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 -S 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:

In ypbind(8) staat meer informatie.

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:

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:

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:

Als de bovenstaande stappen op alle FreeBSD 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.

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. FreeBSD gebruikt de OpenBSD dhclient welke 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.

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 FreeBSD en de server is beschikbaar via de port net/isc-dhcp42-server. Naast de onderstaande informatie, zijn de hulppagina’s van dhclient(8), dhcp-options(5) en dhclient.conf(5) bruikbare bronnen.

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 dhcp-options(5).

FreeBSD integreert de OpenBSD DHCP-cliënt dhclient volledig. 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.

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:

De DHCP-server, dhcpd, zit bij de port net/isc-dhcp42-server in de Portscollectie. Deze port bevat de ISC DHCP-server en documentatie.

Het DHCP-protocol staat volledig beschreven in RFC 2131. Er is nog een bron van informatie ingesteld op http://www.dhcp.org/.

FreeBSD 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 FreeBSD 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.

FreeBSD wordt momenteel standaard geleverd met de BIND9 DNS-serversoftware. Onze installatie biedt verbeterde beveilingsmogelijkheden, een nieuwe indeling van het bestandssysteem en geautomatiseerde configuratie van chroot(8).

DNS wordt op Internet onderhouden door een enigszins complex systeem van autoritaire root, Top Level Domain (TLD), en andere kleinschaligere naamservers die individuele domeininformatie hosten en cachen.

Op dit moment wordt BIND beheerd door het Internet Systems Consortium https://www.isc.org/.

Om dit document te begrijpen moeten een aantal termen gerelateerd aan DNS begrepen worden.

Voorbeelden van zones:

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.

Naamservers bestaan in het algemeen in twee smaken: autoratieve naamservers en caching (ook bekend als resolving) naamservers.

Er is een autoratieve naamserver nodig als:

Er is een caching naamserver nodig als:

Als er een verzoek wordt gedaan voor www.FreeBSD.org, dan doet de resolver meestal een verzoek bij de naamserver van de ISP die de uplink levert en ontvangt daarop een antwoord. Met een lokale, caching DNS-server hoeft het verzoek maar één keer door de caching DNS-server naar de buitenwereld gedaan te worden. Voor aanvullende verzoeken hoeft niet buiten het lokale netwerk te gaan omdat het al lokaal in de cache staat.

De daemon BIND heet in FreeBSD named.

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.

Omdat BIND standaard wordt geïnstalleerd, is het instellen relatief eenvoudig.

De standaardconfiguratie van named is die van een eenvoudige resolverende naamserver, draaiende in een 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:

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:

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 FreeBSD, bekijk dan de named_*-vlaggen in /etc/defaults/rc.conf en raadpleeg de handleidingpagina rc.conf(5). De sectie Gebruik van rc met FreeBSD is ook nuttig om te lezen.

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.

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.

Domain Name Security System Extensions, ofwel DNSSEC, is een verzameling van specificaties om resolvende naamservers te beschermen tegen valse DNS-gegevens, zoals vervalste DNS-records. Door digitale handtekeningen te gebruiken kan een resolver de integriteit van een record controleren. Merk op dat DNSSEC alleen integriteit biedt via het digitaal ondertekenen van het Resource Record (RRs). Het biedt noch betrouwbaarheid noch bescherming tegen onjuiste aannames van eindgebruikers. Dit betekent dat het mensen niet kan beschermen tegen het bezoeken van example.net in plaats van example.com. Het enige wat DNSSEC doet is authenticeren dat de gegevens niet tijdens het transport zijn gecompromitteerd. De beveiliging van DNSSEC is een belangrijke stap in het beveiligen van het internet in het algemeen. De relevante RFCs zijn een goed beginpunt voor meer gedetailleerde gegevens over hoe DNSSEC werkt. Raadpleeg de lijst in Verder lezen.

De volgende secties laten zien hoe DNSSEC voor een autoratieve DNS-server en een recursieve (of caching) DNS-server die BIND 9 draait kan worden bewerkstelligd. Hoewel alle versies van BIND 9 DNSSEC ondersteunen, is tenminste versie 9.6.2 nodig om gebruik te kunnen maken van de ondertekende rootzones tijdens het valideren van DNS-verzoeken. Dit komt doordat eerdere versies de benodigde algoritmes om validatie met de sleutel voor de rootzone te uit te voeren niet hebben. Het wordt sterk aangeraden om de nieuwste versie van BIND 9.7 te gebruiken om gebruik te kunnen maken van automatische sleutel-updates voor de rootsleutel en van andere mogelijkheden om zones ondertekend en sleutel up-to-date te houden. Wanneer configuraties tussen 9.6.2 en 9.7 en later verschillen, zullen deze worden toegelicht.

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 FreeBSD named automatisch in een 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 FreeBSD beveiligingswaarschuwingen mailinglijst om bij te blijven met de beveiligingsproblemen wat betreft Internet en FreeBSD.

BIND/named hulppagina’s: rndc(8) named(8) named.conf(8) nsupdate(8) dnssec-signzone(8) dnssec-keygen(8)

FreeBSD 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 FreeBSD installatiemedia. Als Apache niet bij de oorspronkelijke installatie van FreeBSD is meegeïnstalleerd, dan kan dat vanuit de port www/apache22.

Als Apache succesvol is geïnstalleerd, moeten er instellingen gemaakt worden.

Het belangrijkste bestand met instellingen voor de Apache HTTP Server op FreeBSD is /usr/local/etc/apache22/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.

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.

De port www/apache2 installeert een rc(8)-script dat helpt met het starten, stoppen en herstarten van Apache en is te vinden in /usr/local/etc/rc.d/.

Om Apache met het systeem mee te starten kan de volgende regel aan /etc/rc.conf worden toegevoegd:

Als het nodig is Apache met afwijkende opties op te starten, kan de volgende regel aan /etc/rc.conf worden toegevoegd:

De configuratie van Apache kan worden getest op fouten voordat het daemon httpd voor de eerste keer wordt gestart, of na het maken van wijzigingen aan de instellingen terwijl httpd draait. Dit kan direct door het rc(8)-script worden gedaan, of door het gereedschap service(8) door één van de volgende commando’s op te geven:

Als Apache geen instellingsfouten meldt, kan Apache httpd gestart worden met service(8):

De dienst httpd kan getest worden door http://localhost in een webbrowser te typen, waarbij localhost door de volledig gekwalificeerde domeinnaam wordt vervangen van de machine die httpd draait, als het niet de lokale machine is. De standaard webpagina die afgebeeld wordt is /usr/local/www/apache22/data/index.html.

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:

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:

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 http://httpd.apache.org/docs/vhosts/

Er zijn veel verschillende Apache modules die functionaliteit toevoegen aan de basisdienst. De FreeBSD Portscollectie biedt op een eenvoudige manier de mogelijkheid om Apache samen met de meeste populaire add-on modules te installeren.

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 Microsoft® 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_perl2, en mod_php.

Het File Transfer Protocol (FTP) biedt gebruikers een eenvoudige manier om bestanden van en naar een FTP server te verplaatsen. FreeBSD bevat FTP server software, ftpd, in het basissysteem. Hierdoor is het opzetten en beheren van een FTP server op FreeBSD erg overzichtelijk.

De belangrijkste stap bij het instellen is de beslissing welke accounts toegang krijgen tot de FTP server. Een normaal FreeBSD 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 ftpchroot(5) staan alle details die hier niet beschreven zijn.

Om anonieme FTP toegang voor een server in te schakelen, dient er een gebruiker ftp op een FreeBSD 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 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:

Zoals is uitgelegd in Het instellingenbestand van inetd herladen, moet de configuratie van inetd worden herladen nadat dit instellingenbestand is gewijzigd. Details over het aanzetten van inetd op uw systeem staan in Instellingen.

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:

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:

Nu kan aangemeld worden op de FTP-server met:

De ftpd daemon gebruikt 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:

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.

Samba is een populair open source softwarepakket dat bestands- en printdiensten voor Microsoft® Windows® cliënten biedt. Die cliënten kunnen dan ruimte op een FreeBSD bestandssysteem gebruiken alsof het een lokale schijf is en FreeBSD printers gebruiken alsof het lokale printers zijn.

Samba softwarepakketten horen op de FreeBSD installatiemedia te staan. Als Samba bij de basisinstallatie niet mee is geïnstalleerd, dan kan dat alsnog via de net/samba34 port of met het pakket.

Een standaardbestand met instellingen voor Samba wordt geïnstalleerd als /usr/local/shared/examples/samba34/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 port net/samba34 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:

Of, voor fijnkorrelig beheer:

Vervolgens is het mogelijk om Samba op elk moment te starten door dit te typen:

Refereer aan Gebruik van rc met FreeBSD 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:

Samba is een complexe softwaresuite met functionaliteit waarmee verregaande integratie met Microsoft® Windows® netwerken mogelijk wordt. Informatie die verder gaat dan de basisinstallatie staat op http://www.samba.org.

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 cron(8) zijn ook afhankelijk van een betrouwbare systeemtijd om commando’s op het ingestelde moment uit te voeren.

Bij FreeBSD zit de 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.

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. ntpd(8) gebruikt de antwoorden die van andere servers ontvangen worden op intelligente wijze: betrouwbare servers krijgen voorrang boven onbetrouwbare servers.

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 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:

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:

Meer details staan in de sectie PACKET FILTERING in ppp(8) en in de voorbeelden in /usr/shared/examples/ppp/.

HTML-documentatie voor de NTP-server staat in /usr/shared/doc/ntp/.

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:

Om de logserver te configureren, moet de cliënt vermeld zijn in /etc/syslog.conf, en moet de logfaciliteit zijn gespecificeerd:

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:

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 -v -v 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 -a worden gespecificeerd om logging vanuit meerdere cliënten toe te staan. IP-adressen en hele netblokken mogen ook worden gespecificeerd, bekijk de hulppagina 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 touch(1) werkt prima in dit soort situaties:

Nu dient het syslogd-daemon herstart en geverifieerd worden:

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.

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:

De configuratie van cliënten is wat soepeler dan die van servers. De cliëntmachine moet de volgende regels in /etc/rc.conf hebben:

Net als eerder zullen deze regels de daemon syslogd tijdens het opstarten aanzetten, en de verbositeit van gelogde berichten verhogen. De optie -s 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 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:

Eenmaal toegevoegd moet syslogd worden herstart zodat de veranderingen effect hebben:

Om te testen of logberichten over het netwerk worden verzonden, wordt logger(1) op de cliënt gebruikt om een bericht naar syslogd te sturen:

Dit bericht dient nu zowel in /var/log/messages op de cliënt als /var/log/logclient.log op de logserver te staan.

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:

Debuggegevens zoals de volgende zullen meteen na de herstart over het scherm vliegen:

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:

De regel dient logclient, niet logclien te bevatten. Nadat de juiste wijzigingen zijn gemaakt, wordt er herstart met de verwachte resultaten:

Nu worden de berichten juist ontvangen en in het correcte bestand geplaatst.

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 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.