diff --git a/nl_NL.ISO8859-1/books/handbook/eresources/chapter.sgml b/nl_NL.ISO8859-1/books/handbook/eresources/chapter.sgml index b38d608fe8..c1c93a432b 100644 --- a/nl_NL.ISO8859-1/books/handbook/eresources/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/eresources/chapter.sgml @@ -1,2302 +1,2308 @@ Bronnen op Internet Door de snelle ontwikkeling van &os; zijn gedrukte media niet zo praktisch om de laatste ontwikkelingen te volgen. Elektronische bronnen zijn de beste, en vaak de enige, om op de hoogte te blijven van de laatste ontwikkelingen. Omdat &os; draait op de inzet van vrijwilligers, is de gebruikersgemeenschap vaak een soort technische ondersteuningsgroep, die heeft ontdekt dat email, webfora, en USENET de meeste effectieve manieren zijn om de gebruikersgemeenschap te bereiken. Hieronder staan de meest belangrijke contactmogelijkheden met de &os; gebruikersgemeenschap beschreven. Mochten er andere bronnen zijn die hier niet beschreven zijn, laat die dan weten aan de &a.doc;, zodat ze hier ook beschreven kunnen worden. Mailinglijsten De mailinglijsten zijn de meest directe manier om vragen te stellen aan of een technische discussie te beginnen met een geconcentreerd &os;-publiek. Er is een grote verscheidenheid aan lijsten met betrekking tot verschillende &os;-onderwerpen. Door uw vragen aan de meest geschikte mailinglijst te stellen bent u ongetwijfeld verzekerd van een sneller en accurater antwoord. De doelstellingen van de verschillende lijsten staan onderaan dit document. Lees alstublieft de doelstellingen alvorens lid te worden of mail te sturen. De meeste leden ontvangen tegenwoordig vaak honderden &os;-gerelateerde berichten per dag, en door de doelstellingen en gebruiksregels op te stellen wordt gestreefd om zo min mogelijk ruis op de lijn te krijgen. Door de voorgaande adviezen te negeren zouden de mailinglijsten op termijn falen als een effectief communicatiemedium over het project. Als u wilt testen of u naar de &os; lijsten email kunt versturen, stuur dan een bericht naar &a.test.name;. Stuur alstublieft geen testberichten naar andere lijsten. Bij twijfel over naar welke lijst te posten, kan de pagina Hoe de beste resultaten uit de &os;-vragen mailinglijst te halen wellicht helpen. Alvorens naar enige lijst te posten, is het verstandig te leren hoe de mailinglijsten het beste gebruikt kunnen worden. Hoe bijvoorbeeld zich vaak herhalende discussies voorkomen kunnen worden door het document Veel Gestelde Mailinglijstvragen (FAQ) te lezen. Voor alle mailinglijsten worden archieven bijgehouden die doorzocht kunnen worden op de &os; World Wide Web server. De met sleutelwoorden te doorzoeken archieven bieden een voortreffelijke methode om antwoorden te vinden op vaak gestelde vragen en horen geraadpleegd te worden voordat er vragen op een lijst worden gesteld. Merk op dat dit ook betekent dat berichten die naar de mailinglijsten van &os; worden verzonden tot in de oneindigheid worden gearchiveerd. Overweeg, wanneer het beschermen van privacy belangrijk is, om een tweede emailadres dat weggegooid kan worden te gebruiken en om alleen publieke informatie te posten. Lijstsamenvatting Algemene lijsten: De volgende zijn algemene lijsten waarop vrijelijk (en aangemoedigd) geabonneerd kan worden: Lijst Doel &a.advocacy.name; &os; Evangelisatie &a.announce.name; Belangrijke gebeurtenissen en projectdoelen &a.arch.name; Architectuur en ontwerp discussies &a.bugbusters.name; Discussie over het onderhoud van de &os; probleemrapportendatabase en aanverwante zaken &a.bugs.name; Bugbeschrijvingen &a.chat.name; Niet-technische onderwerpen met betrekking tot de &os;-gemeenschap &a.current.name; Discussie over het gebruik van &os.current; &a.isp.name; Zaken voor Internet Service Providers die &os; gebruiken &a.jobs.name; Werk en mogelijkheden voor het geven van advies met betrekking tot &os; &a.policy.name; Beleidsbeslissingen van het &os; Kernteam. Laag volume en alleen-lezen &a.questions.name; Gebruikersvragen en technische ondersteuning &a.security-notifications.name; Beveiligingswaarschuwingen &a.stable.name; Discussies over het gebruik van &os.stable; &a.test.name; Hier kunnen testberichten heengestuurd worden in plaats van naar de eigenlijke lijsten Technische lijsten: De volgende lijsten zijn voor technische discussie. Het is van belang de doelstellingen te lezen alvorens lid te worden of mail te sturen omdat de richlijnen voor het gebruik en de inhoud erg strikt zijn. Lijst Doel &a.acpi.name; Ontwikkeling van ACPI en energiebeheer &a.afs.name; Porten van AFS naar &os; &a.aic7xxx.name; Ontwikkeling van stuurprogramma's voor de &adaptec; AIC 7xxx &a.alpha.name; Porten van &os; naar de Alpha &a.amd64.name; Porten van &os; naar AMD64-systemen &a.apache.name; Discussie over ports met betrekking tot Apache &a.arm.name; Porten van &os; naar &arm;-processors &a.atm.name; Het gebruik van ATM-netwerken met &os; &a.audit.name; Audit van broncode project &a.binup.name; Ontwerp en ontwikkeling van het binaire updatesysteem &a.bluetooth.name; &bluetooth; technologie gebruiken in &os; &a.cluster.name; &os; gebruiken in een geclusterde omgeving &a.cvsweb.name; CVSweb onderhoud &a.database.name; Discussie over het gebruik en de ontwikkeling van databases met &os; &a.doc.name; Het maken van &os;-gerelateerde documenten &a.drivers.name; Apparaatstuurprogramma's schrijven voor &os; &a.eclipse.name; Gebruikers van Eclipse IDE, hulpprogramma's, cliëntapplicaties en ports &a.eol.name; Ondersteuning voor &os;-gerelateerde software welke niet langer ondersteund worden door het &os;-project. &a.embedded.name; &os; gebruiken in embedded applicaties. &a.emulation.name; Emulatie van andere systemen zoals &linux;, &ms-dos;, en &windows; &a.firewire.name; &os; &firewire; (iLink, IEEE 1394) technische discussie &a.fs.name; Bestandssystemen &a.gecko.name; Discussies over de Gecko Rendering Engine &a.geom.name; GEOM-specifieke discussies en implementaties &a.gnome.name; Porten van GNOME en GNOME applicaties &a.hackers.name; Algemene technische discussies &a.hardware.name; Algemene discussies over hardware voor het draaien van &os; &a.i18n.name; &os; Internationalisatie &a.ia32.name; &os; op het IA-32 (&intel; x86) platform &a.ia64.name; Porten van &os; naar &intel;'s IA64 systemen &a.ipfw.name; Technische discussie over het herontwerp van de IP-firewallcode &a.isdn.name; ISDN-ontwikkelaars &a.jail.name; Discussies over de &man.jail.8;-faciliteiten. &a.java.name; &java; ontwikkelaars en mensen die &jdk;s porten naar &os; &a.kde.name; Porten van KDE en KDE applicaties &a.lfs.name; Porten van LFS naar &os; &a.libh.name; Het tweede generatie installatie- en pakketsysteem &a.mips.name; Porten van &os; naar &mips; &a.mobile.name; Discussie over mobiel computeren &a.mono.name; Mono en C# applicaties op &os; &a.mozilla.name; Porten van Mozilla naar &os; &a.multimedia.name; Multimedia-applicaties &a.newbus.name; Technische discussies over busarchitecturen &a.net.name; Discussies over netwerken en TCP/IP-broncode &a.openoffice.name; Porten van OpenOffice.org en &staroffice; naar &os; &a.performance.name; Optimalisatie van prestaties voor installaties met hoge prestaties en/of load &a.perl.name; Onderhoud van een aantal ports met betrekking tot Perl &a.pf.name; Discussies en vragen voor het pakketfilter firewallsysteem &a.platforms.name; Ports naar niet &intel;-architectuurplatformen &a.ports.name; Discussie over de Portscollectie &a.ports-bugs.name; Discussie over bugs in ports en PR's &a.ppc.name; Porten van &os; naar de &powerpc; &a.proliant.name; Technische discussie over &os; op HP Proliant serverplatforms &a.python.name; &os;-specifieke zaken over Python &a.qa.name; Discussie over Quality Assurance, meestal in een uitgavetraject &a.realtime.name; Ontwikkeling van realtime-uitbreidingen voor &os; &a.rc.name; Discussie over het rc.d-systeem en de ontwikkeling daarvan &a.ruby.name; &os;-specifieke discussies over Ruby &a.scsi.name; Het SCSI-subsysteem &a.security.name; Beveiligingsonderwerpen betreffende &os; &a.small.name; &os; gebruiken in embedded toepassingen, verouderd, gebruik in plaats hiervan &a.embedded.name; &a.smp.name; Discussies over het ontwerp voor [A]Symmetric MultiProcessing &a.sparc.name; Porten van &os; naar op &sparc; gebaseerde systemen &a.standards.name; Volgen van de C99- en de &posix; standaarden door &os; &a.sun4v.name; Het porteren van &os; naar &ultrasparc; T1-gebaseerde systemen. + + &a.sysinstall.name; + + Ontwikkeling van &man.sysinstall.8; + + &a.threads.name; Threading in &os; &a.testing.name; &os; prestatie- en stabiliteitstesten &a.tokenring.name; Ondersteuning voor Token Ring in &os; &a.usb.name; Discussie over &os;-ondersteuning voor USB &a.virtualization.name; Discussies over verscheidene virtualisatietechnieken ondersteund door &os; &a.vuxml.name; Discussie over VuXML-infrastructuur &a.x11.name; Onderhoud en ondersteuning voor X11 op &os; &a.xen.name; Discussies over het porteren van &os; naar &xen; — implementatie en gebruik Beperkte lijsten: De volgende lijsten zijn voor meer gespecialiseerd publiek en algemene gebruikers hebben er waarschijnlijk niets aan. Het is verstandig om eerst naam te maken in de technische lijsten alvorens lid te worden van een van de onderstaande beperkte lijsten, zodat de gebruiken op die lijst bekend zijn. Lijst Doel &a.hubs.name; Mensen die mirrorsites draaien (infrastructurele ondersteuning) &a.usergroups.name; Gebruikersgroepcoördinatie &a.vendors.name; Coördinatie van vooruitgaven met wederverkopers &a.wip-status.name; &os; Werk-In-Uitvoering status &a.www.name; Beheerders van www.FreeBSD.org Verkorte versie van lijsten (digest): Alle hierboven beschreven lijsten zijn beschikbaar in verkorte vorm. Na het lid worden van een lijst zijn de digest opties te wijzigen bij de accountopties. CVS- & SVN-lijsten: De volgende lijsten zijn voor mensen met interesse in het zien van logboekberichten voor wijzigingen in verschillende onderdelen van de broncodeboom. Het zijn Alleen-lezen-lijsten waar geen email heen gezonden hoort te worden. Lijst Broncodegebied Broncodebeschrijving &a.cvsall.name; /usr/(CVSROOT|doc|ports) Alle wijzigingen op welke plaats in de boom dan ook (som van alle andere CVS-commit-lijsten) &a.cvs-doc.name; /usr/(doc|www) Alle wijzigingen aan de doc- en www-structuren &a.cvs-ports.name; /usr/ports Alle wijzigingen aan de ports-boom &a.cvs-projects.name; /usr/projects Alle wijzigingen aan de projects-boom &a.cvs-src.name; /usr/src Alle wijzigingen aan de src-boom (gegenereerd door de commits van de svn-naar-cvs-importer) &a.svn-src-all.name; /usr/src Alle wijzigingen in het Subversion-repository (behalve user en projects) &a.svn-src-head.name; /usr/src Alle wijzigingen aan de head-tak van het Subversion-repository (de tak &os;-CURRENT) &a.svn-src-projects.name; /usr/projects Alle wijzigingen aan het gebied projects van het src-Subversion-repository &a.svn-src-release.name; /usr/src Alle veranderingen aan het gebied releases van het src-Subversion-repository &a.svn-src-releng.name; /usr/src Alle veranderingen aan de takken releng van het src-Subversion-repository (de beveiligings- / uitgavetakken) &a.svn-src-stable.name; /usr/src Alle veranderingen aan alle stable-takken van het src-Subversion-repository &a.svn-src-stable-6.name; /usr/src Alle veranderingen aan de stable/6-tak van het src-Subversion-repository &a.svn-src-stable-7.name; /usr/src Alle veranderingen aan de stable/7-tak van het src-Subversion-repository &a.svn-src-stable-8.name; /usr/src Alle veranderingen aan de stable/8-tak van het src-Subversion-repository &a.svn-src-stable-other.name; /usr/src Alle veranderingen aan de oudere stable-takken van het src-Subversion-repository &a.svn-src-svnadmin.name; /usr/src Alle veranderingen aan de administratieve scripts, haken, en andere configuratiegegevens van het src-Subversion-repository &a.svn-src-user.name; /usr/src Alle veranderingen aan het experimentele gebied user van het src-Subversion-repository &a.svn-src-vendor.name; /usr/src Alle wijzigingen aan het verkoperswerkgebied van het src-Subversion-repository Hoe abonneren Om te abonneren op een lijst kan geklikt worden op de naam van de lijst hierboven of kan op &a.mailman.lists.link; geklikt worden op de lijst waarin interesse bestaat. De pagina waarop de lijsten staan beschreven bevat alle informatie die nodig is om te abonneren. Om te posten op een lijst kan simpelweg een email gestuurd worden naar lijstnaam@FreeBSD.org. Daarna wordt die doorgestuurd aan leden van de lijst in de hele wereld. Om het abonnement op een lijst op te zeggen kan op de URL die onderaan iedere email van een lijst staat geklikt worden. Het is ook mogelijk om een email te sturen naar lijstnaam-unsubscribe@FreeBSD.org om een abonnement op te zeggen. Hierbij nogmaals het advies om discussies op de technische mailinglijsten technisch te houden. Als er alleen interesse bestaat in belangrijke mededelingen dan wordt aangeraden te abonnneren op &a.announce;, waarop zelden verkeer voorkomt. Lijstdoelstellingen Alle &os;-mailinglijsten hebben eigen regels waaraan voldaan dient te worden bij gebruik. Als daaraan niet wordt voldaan, resulteert dat in maximaal twee (2) schriftelijke waarschuwingen van de &os; Postmaster postmaster@FreeBSD.org, waarna na de derde overtreding de poster verwijderd wordt van alle &os;-mailinglijsten en alle toekomstige mail van het adres van de verzender wordt uitgefilterd. Helaas zijn deze regels nodig, omdat het Internet van vandaag de dag een onvriendelijke omgeving is en slechts weinigen zich bewust zijn van hoe fragiel sommige mechanismen zijn. Standaardregels: Het onderwerp van iedere mail dient te voldoen aan de basisdoelstellingen van de lijst waarnaar wordt gepost. Als de lijst bijvoorbeeld over technische onderwerpen gaat, dan hoort een post ook over iets technisch te gaan. Ruis en flaming doen alleen af aan de waarde van een mailinglijst voor alle leden en dat wordt niet getolereerd. Voor vrije discussie dient de &a.chat; gebruikt te worden die daar speciaal voor is ingesteld. Bijdragen horen niet naar meer dan twee mailinglijsten verzonden te worden en alleen dan naar twee als het helder en duidelijk is dat daarvoor de noodzaak bestaat. Voor de meeste lijsten bestaat er al veel overlap in de leden en met uitzondering van de meer esoterische lijsten, zoals bijvoorbeeld -stable & -scsi, is er eigenlijk slechts zelden aanleiding om naar meer dan een lijst te posten. Als een bericht zo is verzonden dat er meerdere mailinglijsten op de regel Cc staan, dan hoort de regel Cc weer ingekort te worden in een eventueel antwoord. De verzender is verantwoordelijk voor zijn eigen kruisposten, wie ook een eerdere zender was. Persoonlijke aanvallen en profane taal (in de context van een geschil) zijn niet toegestaan. Dit geldt zowel voor gebruikers als ontwikkelaars. Grove schending van de netiquette, zoals kopiëren uit of het volledig doorsturen van persoonlijke email zonder dat daarvoor toestemming is gegeven, wordt niet op prijs gesteld. Er zijn hoe dan ook zeer weinig gevallen waarin zoiets dergelijks wel binnen de doelstelling van een lijst valt, waardoor dat soort emails op grond van de inhoud alleen al vaak reden zijn voor een waarschuwing (of ban). Adverteren voor niet-&os;-gerelateerde producten is streng verboden en heeft direct een ban tot gevolg als helder is dat de overtreder adverteert door middel van spam. Individuele lijstdoelstellingen: &a.acpi.name; ACPI en energiebeheerontwikkeling &a.afs.name; Andrew Bestandssysteem (Andrew File System) Deze lijst is voor onderwerpen over het porten en gebruik van AFS van CMU/Transarc &a.announce.name; Belangrijke gebeurtenissen en projectdoelen Dit is de mailinglijst voor hen die alleen interesse hebben in gelegenheidsmededelingen of belangrijke &os;-gebeurtenissen. Hieronder vallen aankondigingen over snapshots en andere uitgaven. De lijst omvat ook aankondigingen over nieuwe mogelijkheden binnen &os;. Er kunnen ook oproepen gedaan worden voor vrijwilligers, enzovoort. Deze lijst kent een laag volume en is volledig gemodereerd. &a.arch.name; Discussie van architectuur en ontwerp Deze lijst is bedoeld voor het bespreken van de &os;-architectuur. Berichten zijn in het algemeen strikt technisch van aard. Voorbeelden van geschikte onderwerpen zijn: Hoe het buildsysteem bijgewerkt kan worden zodat meerdere aanpaste builds tegelijkertijd kunnen lopen. Wat moet er aan VPS aangepast worden om Heidemann-lagen te laten werken. Hoe kan de apparataatstuurprogramma interface aangepast worden zodat dezelfde stuurprogramma's netjes op vele bussen en architecturen gebruikt kunnen worden. Hoe een netwerkstuurprogramma geschreven kan worden. &a.audit.name; Broncode audit project Dit is de mailinglijst voor het &os;-broncode auditproject. Hoewel in eerst instantie bedoeld voor wijzigingen gerelateerd aan beveiliging, zijn de doelstellingen aangepast naar alle wijzigingen in de code. Op deze lijst komen veel patches voor en hij is waarschijnlijk niet interessant voor de gemiddelde &os;-gebruiker. Beveiligingsdiscussies die niet gerelateerd zijn aan een bepaalde broncodewijziging worden gehouden op freebsd-security. Omgekeerd worden alle ontwikkelaars aangemoedigd hun patches op deze lijst ter review aan te bieden, zeker als hun patch een deel van het systeem raakt waar een bug de integriteit van het systeem nadelig kan beïnvloeden. &a.binup.name; &os; Binaire Updates Project Deze lijst bestaat om de mogelijkheid te bieden tot het bespreken van het binaire updatesysteem of binup. Onderwerpen met betrekking tot ontwerp, implementatiedetails, patches, bugreports, statusreportages, feature-verzoeken, commitlogs en alle andere dingen die met binup te maken hebben kunnen besproken worden. &a.bluetooth.name; &bluetooth; in &os; Dit is het forum waar gebruikers van &bluetooth; op &os; samenkomen. Gespreksstof op het gebied van ontwerp, implementatiedetails, patches, probleemrapportages, statusrapportages, verzoeken voor nieuwe mogelijkheden en al het andere dat met &bluetooth; te maken heeft is geschikt materiaal. &a.bugbusters.name; Coördinatie afhandeling Problem Reports Het doel van deze lijst is een platform zijn voor de coördinatie en discussie voor de Bugmeister, zijn Bugbusters en anderen die interesse hebben in de PR-database. Deze lijst is niet bedoeld voor discussies over specifieke bugs, patches of PR's. &a.bugs.name; Bug reports Dit is de mailinglijst voor het rapporteren van bugs in &os;. Waar mogelijk dienen bugs ingezonden te worden via &man.send-pr.1; of via de Webinterface daarvan. &a.chat.name; Niet-technische onderwerpen met betrekking tot de &os;-gemeenschap Deze lijst bevat alle onderwerpen waar op andere lijsten geen ruimte voor is wat betreft niet-technische en sociale informatie. Er wordt gesproken over de moord op Van Gogh, of er in onderkast of kapitalen geschreven dient te worden, wie er te veel koffie drinkt, waar het beste bier vandaan komt, enzovoort. Belangrijke gebeurtenissen (zoals feestjes, bruiloften, geboorten, nieuwe banen, enzovoort) kunnen op de technische lijsten aangekondigd worden, maar antwoorden dienen naar deze -chat lijst te gaan. &a.core.name; &os; Kernteam Dit is een interne mailinglijst die wordt gebruikt door de kernleden. Er kunnen berichten naar gestuurd worden als een belangrijke &os;-gerelateerde zaak arbitrage nodig heeft of een onderzoekende blik op hoog niveau nodig is. &a.current.name; Discussie over het gebruikt van &os.current; Dit is de mailinglijst voor gebruikers van &os.current;. Er staan waarschuwingen op over nieuwe mogelijkheden in -CURRENT die impact hebben op gebruikers en instructies over de te nemen stappen om -CURRENT te blijven. Iedereen die CURRENT draait, zou zich moeten abonneren. Dit is een technische mailinglijst waarop strikt technische berichten worden verwacht. &a.cvsweb.name; &os; CVSweb Project Technische discussie over het gebruik, de ontwikkeling en het beheer van &os;-CVSweb. &a.doc.name; Documentatieproject Dit is de mailinglijst voor het bespreken van onderwerpen en projecten die te maken hebben met het maken van documentatie voor &os;. De leden van deze mailinglijst worden samen The &os; Documentation Project genoemd. Het is een open lijst waarop zonder problemen een abonnement genomen kan worden en bijdragen zeer op prijs worden gesteld! &a.drivers.name; Apparaatstuurprogramma's schrijven voor &os; Dit is een forum voor technische discussie met betrekking tot apparaatstuurprogramma's op &os;. Het is vooral een plaats voor schrijvers van apparaatstuurprogramma's om vragen te stellen over hoe apparaatstuurprogramma's te schrijven met de API's in de kernel van &os;. &a.eclipse.name; Gebruikers van Eclipse IDE, hulpprogramma's, cliëntapplicaties en ports De doelstelling van deze lijst is wederzijdse ondersteuning bieden voor alles dat te maken heeft met het kiezen, installeren, gebruiken, ontwikkelen, en onderhouden van Eclipse IDE, hulpprogramma's en cliëntapplicaties op het &os;-platform en te ondersteunen bij het porten van Eclipse IDE en plugins naar de &os;-omgeving. Het is ook de bedoeling om het uitwisselen van informatie tussen de Eclipse gemeenschap en de &os;-gemeenschap te bevorderen zodat beiden ervan kunnen profiteren. Hoewel deze lijst voornamelijk is gericht op de behoeften van gebruikers van Eclipse, wordt ook een forum geboden voor hen die &os;-specifieke applicaties willen ontwikkelen met het Eclipse raamwerk. &a.eol.name; Ondersteuning van &os; gerelateerde software welke niet meer ondersteund wordt door het &os;-project. Deze lijst is voor degenen die geinteresseerd zijn in het leveren of gebruiken van ondersteuning voor &os;-gerelateerde software voor welke het &os;-project geen ondersteuning meer biedt (in de vorm van beveiligingsadviezen en patches). &a.embedded.name; &os; gebruiken in embedded applicaties Deze lijst heeft tot doel om te discussieren over &os; in embedded systemen. Dit is een technische mailinglijst waarbij men alleen technische inhoud verwacht. Voor het belang van deze lijst definiëren we embedded systemen als computersystemen die geen desktop-systemen zijn en meestal slechts één doel hebben ten opzichte van gewone systemen. Voorbeelden bevatten onder andere: diverse soorten telefoonsets, netwerkapparatuur zoals routers, switches en PBX'en, op afstand bestuurbare meetapparatuur, PDA's, Point of Sale systemen etc. &a.emulation.name; Emulatie van andere systemen zoals &linux;, &ms-dos; en &windows; Dit is een forum voor technische discussie met betrekking tot het draaien van programma's op &os; die zijn geschreven voor andere besturingssystemen. &a.firewire.name; &firewire; (iLink, IEEE 1394) Dit is de mailinglijst voor het bespreken van het ontwerp en de implementatie van een &firewire; (ook wel IEEE 1394 of iLink) subsysteem voor &os;. Relevante onderwerpen omvatten de standaarden, busapparaten en hun protocollen, adapter boards/kaarten/chipssets en de architectuur en implementatie van code voor een juiste ondersteuning. &a.fs.name; Bestandssystemen Discussie over &os;-bestandssystemen. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.gecko.name; Gecko Rendering Engine Dit is een forum over Gecko applicaties die &os; gebruiken. De discussie concentreert zich op toepassingen van Gecko Ports, hun installatie, hun ontwikkeling en hun ondersteuning binnen &os;. &a.geom.name; GEOM Discussie specifiek over GEOM en gerelateerde implementaties. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.gnome.name; GNOME Discussie over de bureaubladomgeving GNOME voor &os;. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.ipfw.name; IP Firewall Dit is het forum voor technische bespreking van het herontwerp van de IP-firewallcode in &os;. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.ia64.name; Porten van &os; naar IA64 Dit is een technische mailinglijst voor individuen die actief werken aan het porten van &os; naar het platform IA-64 van &intel;, om problemen op tafel te leggen of alternatieve oplossingen te bespreken. Geïnteresseerden die alleen de technische bespreking willen volgen zijn ook welkom. &a.isdn.name; ISDN-communicatie Dit is de mailinglijst voor discussie over de ontwikkeling van ISDN-ondersteuning voor &os;. &a.java.name; &java; Ontwikkeling Dit is de mailinglijst voor het bespreken van de ontwikkeling van significante &java; applicaties voor &os; en het porten en het beheer van &jdk;'s. &a.jobs.name; Banen in de aanbieding en gezocht Dit is een forum voor vacatures en CV's specifiek gerelateerd aan &os;, bijvoorbeeld als er &os;-gerelateerd werk wordt gezocht of in de aanbieding is. Dit is geen mailinglijst voor algemene werkonderwerpen omdat daarvoor al elders ruimte staat. Ook deze lijst wordt net als alle andere FreeBSD.org mailinglijsten wereldwijd verspreid. Daarom dient duidelijk vermeld te worden om welke locatie het gaat en onder welke voorwaarden telewerken of bijdragen in huisvesting mogelijk zijn. Email dient alleen open formaten te bevatten. Bij voorkeur platte tekst, maar standaard Portable Document Format (PDF), HTML, en een aantal andere, zijn acceptabel voor lezers. Gesloten formaten, zoals µsoft; Word (.doc), worden door de mailinglijstserver geweigerd. &a.kde.name; KDE Discussie over KDE op &os;-systemen. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.hackers.name; Technische discussies Dit is een forum voor technische discussie met betrekking tot &os;. Dit is de leidende technische mailinglijst die is bestemd voor mensen die actief aan &os; werken om problemen aan het voetlicht te brengen of alternatieve oplossingen te bespreken. Geïnteresseerden die alleen de technische bespreking willen volgen zijn ook welkom. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.hardware.name; Algemene discussie over &os;-hardware Algemene discussie over de typen hardware waar &os; op draait en problemen en oplossingen over wat te kopen en wat vooral niet. &a.hubs.name; Mirrorsites Aankondigingen en discussie voor beheerders van &os;-mirrorsites. &a.isp.name; Onderwerpen voor Internet Service Providers Deze mailinglijst is voor het bespreken van relevante onderwerpen voor Internet Service Providers (ISP's) die &os; gebruiken. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.mono.name; Mono en C# applicaties op &os; Dit is een lijst voor discussies met betrekking tot het Mono-ontwikkelraamwerk op &os;. Dit is een technische mailinglijst. Het is bedoeld voor individuen die actief werken aan het overbrengen van Mono of C# applicaties naar &os;, om problemen naar voren te brengen of alternatieve oplossingen te bespreken. Individuen die geïnteresseerd zijn in het volgen van de technische discussie zijn ook welkom. &a.openoffice.name; OpenOffice.org Discussie over het porten en beheren van OpenOffice.org en &staroffice;. &a.performance.name; Discussie over het optimaliseren of versnellen van &os; Deze mailinglijst is een platform voor hackers, beheerders en/of andere belanghebbenden om &os;- en prestatiegerelateerde onderwerpen te bespreken. De onderwerpen die besproken kunnen worden omvatten &os;-installaties met een hoge load, systemen met prestatieproblemen of systemen die tegen de limieten van &os; aan zitten. Zij die willen meewerken om de prestaties van &os; te verbeteren worden sterk aangemoedigd zich op deze lijst te abonneren. Deze lijst is bijzonder technisch en bijzonder geschikt voor ervaren &os;-gebruikers, hackers en beheerders die &os; snel, robuust, en schaalbaar willen houden. Deze lijst is geen vraag-en-antwoord lijst die dient als vervanging voor het lezen van documentatie, maar hier worden bijdragen geleverd of vragen gesteld over nog niet eerder beschreven prestatiegerelateerde onderwerpen. &a.pf.name; Discussie en vragen over het pakketfilter firewallsysteem Discussie over het pakketfilter (pf) firewallsysteem met betrekking tot &os;. Technische discussie en gebruikersvragen zijn beiden welkom. Deze lijst is ook de plaats om het raamwerk ALTQ QoS te bespreken. &a.platforms.name; Porten van niet-&intel; platforms Cross-platform &os;-zaken, algemene discussie en voorstellen voor niet-&intel; &os; ports. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.policy.name; Kernteam beleidsbeslissingen Dit is een laag volume, alleen-lezen mailinglijst voor beleidsbeslissingen van het &os; Kernteam. &a.ports.name; Discussie over ports Discussie over de Portscollectie (/usr/ports) van &os;, de Ports infrastructuur en algemene coördinatie aangaande ports. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.ports-bugs.name; Discussie over ports bugs Discussie over probleemrapportages voor de &os; Portscollectie (/usr/ports), voorgestelde ports of aanpassingen aan ports. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.proliant.name; Technische discussie over &os; op HP Proliant serverplatforms Deze mailinglijst wordt gebruikt voor technische discussie over het gebruik van &os; op HP ProLiant servers, inclusief het bespreken van ProLiant-specifieke stuurprogramma's, beheersoftware, gereedschappen voor instellingen en BIOS-updates. Dit is daaarom ook de uitgesproken plaats voor het bespreken van de modules hpasmd, hpasmcli, en hpacucli. &a.python.name; Python op &os; Dit is een lijst voor discussie gerelateerd aan het verbeteren van ondersteuning voor Python op &os;. Dit is een technische mailinglijst voor mensen die aan het porten van Python, aanverwante modules en Zope-dingen naar &os; werken. &a.questions.name; Gebruikersvragen Dit is de mailinglijst voor vragen over &os;. Er horen geen how to vragen op de technische mailinglijsten thuis, tenzij een vraag erg technisch van aard is. &a.ruby.name; &os;-specifieke discussies over Ruby Dit is een lijst voor discussies gerelateerd aan de Ruby-ondersteuning op &os;. Dit is een technische mailinglijst. Het is bedoeld voor individuen die aan Ruby-ports, bibliotheken van derde partijen, en raamwerken werken. Individuen die geïnteresseerd zijn in de technische discussie zijn ook welkom. &a.scsi.name; SCSI-subsysteem Dit is de mailinglijst voor mensen die aan het SCSI-subsysteem voor &os; werken. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.security.name; Beveiligingsonderwerpen &os;-computerbeveiligingsonderwerpen (DES, Kerberos, bekende beveiligingsgaten, oplossingen, enzovoort). Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. Dit is zeker geen vraag-en-antwoord lijst, maar bijdragen voor de FAQ (zowel vraag als antwoord) zijn welkom. &a.security-notifications.name; Beveiligingswaarschuwingen Waarschuwingen voor &os; beveiligingsproblemen en oplossingen. Dit is geen discussielijst. De discussielijst is &a.security.name;. &a.small.name; &os; gebruiken in embedded toepassingen Op deze lijst worden onderwerpen gerelateerd aan ongebruikelijk kleine en embedded &os;-installaties besproken. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. Deze lijst is vervangen door &a.embedded.name; &a.stable.name; Discussie over het gebruik van &os.stable; Dit is de mailinglijst voor gebruikers van &os.stable;. Er worden ook waarschuwingen op gepost over nieuwe opties in -STABLE die invloed op de systemen van gebruikers kunnen hebben en instructies over de te nemen stappen om -STABLE te blijven. Iedereen die STABLE draait hoort zich op deze lijst te abonneren. Dit is een technische mailinglijst waarop slechts strikt technische bijdragen worden verwacht. &a.standards.name; Conformeren C99 & POSIX Dit is een forum voor technische bespreking gerelateerd aan het conformeren van &os; aan de C99- en de POSIX-standaarden. &a.usb.name; Discussie over &os; ondersteuning voor USB Dit is de mailinglijst voor technische bespreking van onderwerpen gerelateerd aan &os; ondersteuning voor USB. &a.usergroups.name; Gebruikersgroep Coördinatie Lijst Dit is de mailinglijst voor coördinatoren voor alle lokale gebruikersgroepen, zodat ze met elkaar en een lid van het Kernteam zaken kunnen bespreken. Deze lijst hoort beperkt te blijven tot een overzicht van overleggen en de coördinatie van projecten waarbij meerdere gebruikersgroepen betrokken zijn. &a.vendors.name; Verkopers Coördinatie en discussie tussen het &os;-project en verkopers van software en hardware voor &os;. &a.virtualization.name; Discussies over verscheidene virtualisatietechnieken ondersteund door &os; Een lijst om de verscheidene virtualisatietechnieken die door &os; worden ondersteund te bespreken. Aan de ene kant zal de nadruk liggen op de implementatie van de basale functionaliteit alsook op het toevoegen van nieuwe mogelijkheden. Aan de andere kant zullen gebruikers een forum hebben om om hulp te vragen bij problemen of om hun usecases te bespreken. &a.wip-status.name; &os; Werk-In-Uitvoering status Deze mailinglijst kan gebruikt worden om de schepping en voortgang van uw &os;-gerelateerd werk aan te kondigen. Berichten zullen gemodereerd worden. Het wordt gesuggereerd om het bericht "Aan:" een &os;-mailinglijst dat het onderwerp beter dekt te sturen en deze lijst alleen te "BCC:"-en. Op deze manier kan uw werk-in-uitvoering ook op de onderwerpslijst worden bediscussieerd, aangezien discussies op deze lijst niet zijn toegestaan. Kijk in de archieven voor voorbeelden van geschikte berichten. Een redactioneel overzicht van de berichten aan deze lijst kan om de paar maanden naar de &os;-website gezonden worden als deel van de Status Reports . Meer voorbeelden en oude rapportages zijn daar ook te vinden. &a.xen.name; Discussies over het porteren van &os; naar &xen; — implementatie en gebruik Een lijst die zich richt op de &os; &xen; port. De verwachte hoeveelheid verkeer is laag genoeg zodat het voor zowel technische discussies over de implementatie- en ontwerpdetails als voor zaken over administratief gebruik bedoeld is. Filters op de mailinglijsten De &os;-mailinglijsten worden op verschillende manieren gefilterd om het doorsturen van spam, virussen, en andere ongewenste email te beperken. De hieronder beschreven filteracties bevatten niet alle genomen acties voor de beveiliging van de mailinglijsten. Er is een beperkt aantal typen bijlagen toegestaan op de mailinglijsten. Alle bijlagen met een MIME-inhoudtype dat niet in de onderstaande lijst staat worden verwijderd voordat de mail wordt doorgestuurd naar de mailinglijsten. application/octet-stream application/pdf application/pgp-signature application/x-pkcs7-signature message/rfc822 multipart/alternative multipart/related multipart/signed text/html text/plain text/x-diff text/x-patch Sommige mailinglijsten staan wellicht bijlagen toe met andere MIME-inhoudtypen, maar de bovenstaande lijst zal gelden voor de meeste mailinglijsten. Als een email zowel een HTML- als een platte tekstversie bevat, dan wordt de HTML-versie verwijderd. Als een mail alleen een HTML-versie bevat, dan wordt die omgezet naar platte tekst. Usenet-nieuwsgroepen Naast de twee specifieke &os;-nieuwsgroepen zijn er nog vele andere waarin &os; wordt besproken of die anderszins relevant zijn voor &os;-gebruikers. Er zijn sleutelwoord doorzoekbare archieven voor een aantal van die nieuwsgroepen, met dank aan Warren Toomey wkt@cs.adfa.edu.au. Specifieke BSD nieuwsgroepen comp.unix.bsd.freebsd.announce comp.unix.bsd.freebsd.misc de.comp.os.unix.bsd (Duits) fr.comp.os.bsd (Frans) it.comp.os.freebsd (Italiaans) tw.bbs.comp.386bsd (Traditioneel Chinees) Overige interessante &unix;-nieuwsgroepen comp.unix comp.unix.questions comp.unix.admin comp.unix.programmer comp.unix.shell comp.unix.user-friendly comp.security.unix comp.sources.unix comp.unix.advocacy comp.unix.misc comp.bugs.4bsd comp.bugs.4bsd.ucb-fixes comp.unix.bsd X Window systeem comp.windows.x.i386unix comp.windows.x comp.windows.x.apps comp.windows.x.announce comp.windows.x.intrinsics comp.windows.x.motif comp.windows.x.pex comp.emulators.ms-windows.wine World wide webservers Fora, blogs, en sociale netwerken The &os; Forums bieden een webgebaseerd discussieforum voor vragen en technische discussies over &os;. Planet &os; biedt een samengestelde feed van tientallen blogs geschreven door &os;-ontwikkelaars. Vele ontwikkelaars gebruiken dit om korte notities te posten over waaraan ze werken, nieuwe patches, en ander werk in uitvoering. Het BSDConferences YouTube Channel biedt een verzameling van video's van hoge kwaliteit van wereldwijde BSD-conferenties. Dit is een prima manier om presentaties van hoofdontwikkelaars over nieuw werk in &os; te zien. Officiële spiegels &chap.eresources.www.inc; Email-adressen De onderstaande gebruikersgroepen bieden &os;-gerelateerde email-adressen aan voor hun leden. De aangegeven beheerders behouden zich het recht voor om een account te verwijderen als die op enigerlei wijze wordt misbruikt. Domein Faciliteiten Gebruikersgroep Beheerder ukug.uk.FreeBSD.org Alleen forwarden ukfreebsd@uk.FreeBSD.org Lee Johnston lee@uk.FreeBSD.org 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 f90c2d35c2..747cef6508 100644 --- a/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml +++ b/nl_NL.ISO8859-1/books/handbook/network-servers/chapter.sgml @@ -1,5795 +1,5793 @@ Murray Stokely Gereorganiseerd door Siebrand Mazeland Vertaald door René Ladan Netwerkdiensten Overzicht Dit hoofdstuk behandelt een aantal veelgebruikte netwerkdiensten op &unix; systemen. Er wordt ingegaan op de installatie, het instellen, testen en beheren van verschillende typen netwerkdiensten. Overal in dit hoofdstuk staan voorbeeldbestanden met instellingen waar de lezer zijn voordeel mee kan doen. Na het lezen van dit hoofdstuk weet de lezer: Hoe om te gaan met de inetd daemon; Hoe een netwerkbestandssysteem opgezet kan worden; Hoe een netwerkinformatiedienst (NIS) opgezet kan worden voor het delen van gebruikersaccounts; Hoe automatische netwerkinstellingen gemaakt kunnen worden met DHCP; Hoe een domeinnaam server opgezet kan worden; Hoe een Apache HTTP Server opgezet kan worden; Hoe een File Transfer Protocol (FTP) Server opgezet kan worden; Hoe een bestand-- en printserver voor &windows; cliënten opgezet kan worden met Samba; Hoe datum en tijd gesynchroniseerd kunnen worden en hoe een tijdserver opgezet kan worden met het NTP-protocol. Hoe het standaard log-daemon syslogd in te stellen om logs van hosts op afstand te accepteren. Veronderstelde voorkennis: Basisbegrip van de scripts in /etc/rc; Bekend zijn met basis netwerkterminologie; Kennis van de installatie van software van derde partijen (). Chern Lee Bijgedragen door Bijgewerkt voor &os; 6.1-RELEASE door The &os; Documentation Project De <application>inetd</application> <quote>Super-Server</quote> Overzicht &man.inetd.8; wordt soms de Internet Super-Server genoemd, omdat het verbindingen voor meerdere diensten beheert. Als door inetd een verbinding wordt ontvangen, bepaalt die voor welk programma de verbinding bedoeld is, splitst het dat proces af en delegeert de socket (het programma wordt gestart met de socket van de dienst als zijn standaardinvoer, -uitvoer en -foutbeschrijvingen). Het draaien van inetd voor servers die niet veel gebruikt worden kan de algehele werklast verminderen in vergelijking met het draaien van elke daemon individueel in stand-alone modus. inetd wordt primair gebruikt om andere daemons aan te roepen, maar het handelt een aantal triviale protocollen direct af, zoals chargen, auth en daytime. In deze paragraaf worden de basisinstellingen van inetd behandeld met de opties vanaf de commandoregel en met het instellingenbestand /etc/inetd.conf. Instellingen inetd wordt gestart door het &man.rc.8;-systeem. De optie inetd_enable staat standaard op NO, maar kan tijdens de installatie door sysinstall worden aangezet. Door het plaatsen van inetd_enable="YES" of inetd_enable="NO" in /etc/rc.conf wordt inetd bij het opstarten van een systeem wel of niet ingeschakeld. Het commando: &prompt.root; /etc/rc.d/inetd rcvar kan gedraaid worden om de huidige effectieve instellingen weer te geven. Dan kunnen er ook nog een aantal commandoregelopties aan inetd meegegeven worden met de optie inetd_flags. Commandoregelopties Zoals de meeste serverdaemons heeft inetd een aantal opties die doorgegeven kunnen worden om het gedrag aan te passen. De volledige lijst van opties is: inetd Opties kunnen door middel van de optie inetd_flags in /etc/rc.conf aan inetd worden doorgegeven. Standaard staat inetd_flags ingesteld op -wW -C 60, dat TCP-wrapping aanzet voor de diensten van inetd, en voorkomt dat elk enkelvoudig IP-adres enige dienst meer dan 60 keer per minuut opvraagt. Beginnende gebruikers zullen blij zijn om te weten dat deze parameters gewoonlijk niet hoeven te worden aangepast, alhoewel we de ratebeperkende opties hieronder noemen aangezien ze nuttig kunnen zijn in het geval u een buitensporig aantal verbindingen ontvangt. Een volledige lijst van opties staat in de hulppagina &man.inetd.8;. -c maximum Geeft het maximale aantal gelijktijdige verzoeken voor iedere dienst aan. De standaard is ongelimiteerd. Kan per dienst ter zijde geschoven worden met de parameter . -C rate Geeft het maximale aantal keren aan dat een dienst vanaf een bepaald IP-adres per minuut aangeroepen kan worden. Kan per dienst ter zijde geschoven worden met de parameter . -R rate Geeft het maximale aantal keren aan dat een dienst per minuut aangeroepen kan worden. De standaard is 256. De instelling 0 geeft aan dat er geen limiet is. -s maximum Specificeert het maximaal aantal keer per minuut dat een dienst aangeroepen kan worden vanuit een enkelvoudig IP-adres; de standaard is onbeperkt. Kan worden overstemd op een per-dienst-basis met de parameter . <filename>inetd.conf</filename> De instellingen van inetd worden beheerd in /etc/inetd.conf. Als er een wijziging wordt aangebracht in /etc/inetd.conf, dan kan inetd gedwongen worden om de instellingen opnieuw in te lezen door dit commando te draaien: Het instellingenbestand van <application>inetd</application> herladen &prompt.root; /etc/rc.d/inetd reload Iedere regel in het bestand met instellingen heeft betrekking op een individuele daemon. Commentaar wordt vooraf gegaan door een #. De opmaak van elke regel van /etc/inetd.conf is als volgt: service-name socket-type protocol {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] user[:group][/login-class] server-program server-program-arguments Een voorbeeldregel voor de daemon &man.ftpd.8; met IPv4 kan eruit zien als: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l service-name Dit is de dienstnaam van een daemon. Die moet overeenkomen met een dienst uit /etc/services. Hiermee kan de poort waarop inetd moet luisteren aangegeven worden. Als er een nieuwe dienst wordt gemaakt, moet die eerst in /etc/services gezet worden. socket-type Dit is stream, dgram, raw of seqpacket. stream moet gebruikt worden voor verbindingsgebaseerde TCP-daemons, terwijl dgram wordt gebruikt voor daemons die gebruik maken van het transportprotocol UDP. protocol Een van de volgende: Protocol Toelichting tcp, tcp4 TCP IPv4 udp, udp4 UDP IPv4 tcp6 TCP IPv6 udp6 UDP IPv6 tcp46 Zowel TCP IPv4 als v6 udp46 Zowel UDP IPv4 als v6 {wait|nowait}[/max-child[/max-connections-per-ip-per-minute[/max-child-per-ip]]] geeft aan of de daemon die door inetd wordt aangesproken zijn eigen sockets kan afhandelen of niet. sockettypen moeten de optie gebruiken, terwijl streamsocket daemons, die meestal multi-threaded zijn, de optie horen te gebruiken. geeft meestal meerdere sockets aan een daemon, terwijl een kinddaemon draait voor iedere nieuwe socket. Het maximum aantal kinddaemons dat inetd mag voortbrengen kan ingesteld worden met de optie . Als een limiet van tien instanties van een bepaalde daemon gewenst is, dan zou er /10 achter gezet worden. Door /0 wordt een onbeperkt aantal kinderen toegestaan. Naast zijn er nog twee andere opties waarmee het maximale aantal verbindingen van een bepaalde plaats naar een daemon ingesteld kan worden. beperkt het aantal verbindingen per minuut voor enig IP-adres, een waarde van tien betekent hier dat er van ieder IP-adres maximaal tien verbindingen naar een bepaalde dienst tot stand gebracht kunnen worden. beperkt het aantal kindprocessen dat namens enig IP-adres op enig moment gestart kan worden. Deze opties kunnen zijn nuttig om bedoeld en onbedoeld buitensporig bronnengebruik van en Denial of Service (DoS) aanvallen op een machine te voorkomen. In dit veld is één van of verplicht. , en zijn optioneel. Een stream-type multi-threaded daemon zonder één van de limieten , of is eenvoudigweg: nowait. Dezelfde daemon met een maximale limiet van tien daemons zou zijn: nowait/10. Dezelfde instellingen met een limiet van twintig verbindingen per IP-adres per minuut en een totaal maximum van tien kinddaemons zou zijn: nowait/10/20. Deze opties worden allemaal gebruikt door de standaardinstellingen van de daemon &man.fingerd.8;: finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s Als afsluiting, een voorbeeld in dit veld met een maximum van 100 kinderen in totaal, met een maximum van 5 voor enig IP-adres zou zijn: nowait/100/0/5. user Dit is de gebruikersnaam waar een daemon onder draait. Daemons draaien meestal als de gebruiker root. Om veiligheidsredenen draaien sommige daemons onder de gebruiker daemon of de gebruiker met de minste rechten: nobody. server-program Het volledige pad van de daemon die uitgevoerd moet worden als er een verbinding wordt ontvangen. Als de daemon een dienst is die door inetd intern wordt geleverd, dan moet de optie gebruikt worden. server-program-arguments Deze optie werkt samen met de optie en hierin worden de argumenten ingesteld, beginnend met argv[0], die bij het starten aan de daemon worden meegegeven. Als mijndaemon -d de commandoregel is, dan zou mijndaemon -d de waarde van zijn. Hier geldt ook dat als de daemon een interne dienst is, hier de optie moet worden. Beveiliging Afhankelijk van keuzes gemaakt tijdens de installatie, kunnen veel van de diensten van inetd standaard ingeschakeld zijn. Het is verstandig te overwegen om een daemon dat niet noodzakelijk is uit te schakelen. Plaats een # voor de daemon in /etc/inetd.conf en herlaad vervolgens de instellingen van inetd. Sommige daemons, zoals fingerd, zijn wellicht helemaal niet gewenst omdat ze informatie geven die nuttig kan zijn voor een aanvaller. Sommige daemons zijn zich niet echt bewust van beveiliging en hebben lange of niet bestaande timeouts voor verbindingspogingen. Hierdoor kan een aanvaller langzaam veel verbindingen maken met een daemon en zo beschikbare bronnen verzadigen. Het is verstandig voor die daemons de limietopties , of te gebruiken als ze naar uw smaak teveel verbindingen hebben. TCP-wrapping staat standaard aan. Er staat meer informatie over het zetten van TCP-restricties op de verschillende daemons die door inetd worden aangesproken in &man.hosts.access.5;. Allerlei daytime, time, echo, discard, chargen en auth zijn allemaal interne diensten van inetd. De dienst auth biedt identiteitsnetwerkdiensten en is tot op een bepaald niveau instelbaar, terwijl de anderen eenvoudigweg aan of uit staan. Meer diepgaande informatie staat in &man.inetd.8;. Tom Rhodes Gereorganiseerd en verbeterd door Bill Swingle Geschreven door Netwerkbestandssysteem (NFS) NFS Het Netwerkbestandssysteem (Network File System) is een van de vele bestandssystemen die &os; ondersteunt. Het staat ook wel bekend als NFS. Met NFS is het mogelijk om mappen en bestanden met anderen in een netwerk te delen. Door het gebruik van NFS kunnen gebruikers en programma's bij bestanden op andere systemen op bijna dezelfde manier als bij hun eigen lokale bestanden. De grootste voordelen van NFS zijn: Lokale werkstations gebruiken minder schijfruimte omdat veel gebruikte data op één machine opgeslagen kan worden en nog steeds toegankelijk is voor gebruikers via het netwerk; Gebruikers hoeven niet op iedere machine een thuismap te hebben. Thuismappen kunnen op de NFS server staan en op het hele netwerk beschikbaar zijn; Opslagapparaten als floppydisks, CD-ROM drives en &iomegazip; drives kunnen door andere machines op een netwerk gebruikt worden. Hierdoor kan het aantal drives met verwijderbare media in een netwerk verkleind worden. Hoe <acronym>NFS</acronym> werkt NFS bestaat uit tenminste twee hoofdonderdelen: een server en een of meer cliënten. De cliënt benadert de gegevens die op een servermachine zijn opgeslagen via een netwerk. Om dit mogelijk te maken moeten er een aantal processen ingesteld en gestart worden. Op de server moeten de volgende daemons draaien: NFS server bestandsserver UNIX cliënten rpcbind mountd nfsd Daemon Beschrijving nfsd De NFS-daemon die verzoeken van de NFS cliënten afhandelt. mountd De NFS koppeldaemon die doorgestuurde verzoeken van &man.nfsd.8; uitvoert. rpcbind Deze daemon geeft voor NFS-cliënten aan welke poort de NFS-server gebruikt. Op de cliënt kan ook een daemon draaien: nfsiod. De daemon nfsiod handelt verzoeken van de NFS-server af. Dit is optioneel en kan de prestaties verbeteren, maar het is niet noodzakelijk voor een normale en correcte werking. Meer informatie staat in &man.nfsiod.8;. <acronym>NFS</acronym> instellen NFS instellen NFS instellen gaat redelijk rechtlijnig. Alle processen die moeten draaien kunnen meestarten bij het opstarten door een paar wijzigingen in /etc/rc.conf. Op de NFS server dienen de volgende opties in /etc/rc.conf te staan: rpcbind_enable="YES" nfs_server_enable="YES" mountd_flags="-r" mountd start automatisch als de NFS server is ingeschakeld. Op de cliënt dient de volgende optie in /etc/rc.conf te staan: nfs_client_enable="YES" In het bestand /etc/exports staat beschreven welke bestandssystemen NFS moet exporteren (soms heet dat ook wel delen of sharen). Iedere regel in /etc/exports slaat op een bestandssysteem dat wordt geëxporteerd en welke machines toegang hebben tot dat bestandssysteem. Samen met machines die toegang hebben, kunnen ook toegangsopties worden aangegeven. Er zijn veel opties beschikbaar, maar hier worden er maar een paar beschreven. Alle opties staan beschreven in &man.exports.5;. Nu volgen een aantal voorbeelden voor /etc/exports: NFS exportvoorbeelden Het volgende voorbeeld geeft een beeld van hoe een bestandssysteem te exporteren, hoewel de instellingen afhankelijk zijn van de omgeving en het netwerk. Om bijvoorbeeld de map /cdrom te exporteren naar drie machines die dezelfde domeinnaam hebben als de server (vandaar dat de machinenamen geef domeinachtervoegsel hebben) of in /etc/hosts staan. De vlag exporteert het bestandssysteem als alleen–lezen. Door die vlag kan een ander systeem niet schrijven naar het geëxporteerde bestandssysteem. /cdrom -ro host1 host2 host3 Het volgende voorbeeld exporteert /home naar drie hosts op basis van IP-adres. Dit heeft zin als er een privaat netwerk bestaat, zonder dat er een DNS server is ingesteld. Optioneel kan /etc/hosts gebruikt worden om interne hostnamen in te stellen. Er is meer informatie te vinden in &man.hosts.5;. Met de vlag mogen submappen ook koppelpunten zijn. De submap wordt dan niet feitelijk aangekoppeld, maar de cliënt koppelt dan alleen de submappen aan die verplicht of nodig zijn. /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 Het volgende voorbeeld exporteert /a zo dat twee cliënten uit verschillende domeinen bij het bestandssysteem mogen. Met de vlag mag de gebruiker op het andere systeem gegevens naar het geëxporteerde bestandssysteem schrijven als root. Als de vlag niet wordt gebruikt, dan kan een gebruiker geen bestanden wijzigen op het geëxporteerde bestandssysteem, zelfs niet als een gebruiker daar root is. /a -maproot=root host.example.com box.example.org Om een cliënt toegang te geven tot een geëxporteerd bestandssysteem, moet die cliënt daar rechten voor hebben. De cliënt moet daarvoor genoemd worden in /etc/exports. In /etc/exports staat iedere regel voor de exportinformatie van één bestandssysteem naar één host. Per bestandssysteem mag een host maar één keer genoemd worden en mag maar één standaard hebben. Stel bijvoorbeeld dat /usr een enkel bestandssysteem is. Dan is de volgende /etc/exports niet geldig: ># Werkt niet als /usr 1 bestandssysteem is /usr/src client /usr/ports client Eén bestandssysteem, /usr, heeft twee regels waarin exports naar dezelfde host worden aangegeven, client. In deze situatie is de juiste instelling: /usr/src /usr/ports client De eigenschappen van een bestandssysteem dat naar een bepaalde host wordt geëxporteerd moeten allemaal op één regel staan. Regels waarop geen cliënt wordt aangegeven worden behandeld als een enkele host. Dit beperkt hoe bestandssysteem geëxporteerd kunnen worden, maar dat blijkt meestal geen probleem te zijn. Het volgende voorbeeld is een geldige exportlijst waar /usr en /exports lokale bestandssystemen zijn: # Exporteer src en ports naar client01 en client02, # maar alleen client01 heeft er rootprivileges /usr/src /usr/ports -maproot=root client01 /usr/src /usr/ports client02 # De cliëntmachines hebben rootrechten en kunnen overal aankoppelen # op /exports. Iedereen in de wereld kan /exports/obj als alleen-lezen aankoppelen. /exports -alldirs -maproot=root client01 client02 /exports/obj -ro De daemon mountd moet gedwongen worden om het bestand /etc/exports te controleren steeds wanneer het is aangepast, zodat de veranderingen effectief kunnen worden. Dit kan worden bereikt door òfwel een HUP-signaal naar de draaiende daemon te sturen: &prompt.root; kill -HUP `cat /var/run/mountd.pid` of door het &man.rc.8; script mountd met de juiste parameter aan te roepen: &prompt.root; /etc/rc.d/mountd onereload Raadpleeg voor meer informatie over het gebruik van rc-scripts. Het is ook mogelijk een machine te herstarten, zodat &os; alles netjes in kan stellen, maar dat is niet nodig. Het uitvoeren van de volgende commando's als root hoort hetzelfde resultaat te hebben. Op de NFS server: &prompt.root; rpcbind &prompt.root; nfsd -u -t -n 4 &prompt.root; mountd -r Op de NFS cliënt: &prompt.root; nfsiod -n 4 Nu is alles klaar om feitelijk het netwerkbestandssysteem aan te koppelen. In de volgende voorbeelden is de naam van de server server en de naam van de cliënt is client. Om een netwerkbestandssysteem slechts tijdelijk aan te koppelen of om alleen te testen, kan een commando als het onderstaande als root op de cliënt uitgevoerd worden: NFS aankoppelen &prompt.root; mount server:/home /mnt Hiermee wordt de map /home op de server aangekoppeld op /mnt op de cliënt. Als alles juist is ingesteld, zijn nu in /mnt op de cliënt de bestanden van de server zichtbaar. Om een netwerkbestandssysteem iedere keer als een computer opstart aan te koppelen, kan het bestandssysteem worden toegevoegd aan het bestand /etc/fstab: server:/home /mnt nfs rw 0 0 Alle beschikbare opties staan in &man.fstab.5;. Op slot zetten Voor sommige applicaties (b.v. mutt) is het nodig dat bestanden op slot staan om correct te werken. In het geval van NFS, kan rpc.lockd worden gebruikt voor het op slot zetten van bestanden. Voeg het volgende toe aan het bestand /etc/rc.conf op zowel de cliënt als de server om het aan te zetten (het wordt aangenomen dat de NFS-cliënt en -server reeds zijn geconfigureerd): rpc_lockd_enable="YES" rpc_statd_enable="YES" Start de applicatie met: &prompt.root; /etc/rc.d/lockd start &prompt.root; /etc/rc.d/statd start Als echt op slot zetten tussen de NFS-cliënten en de NFS-server niet nodig is, is het mogelijk om de NFS-cliënt bestanden lokaal op slot te laten zetten door aan &man.mount.nfs.8; door te geven. In de handleidingpagina &man.mount.nfs.8; staan verdere details. Mogelijkheden voor gebruik NFS is voor veel doeleinden in te zetten. Een aantal voorbeelden: NFS gebruik Een aantal machines een CD-ROM of andere media laten delen. Dat is goedkoper en vaak ook handiger, bijvoorbeeld bij het installeren van software op meerdere machines; Op grote netwerken kan het praktisch zijn om een centrale NFS server in te richten, waarop alle thuismappen staan. Die thuismappen kunnen dan geëxporteerd worden, zodat gebruikers altijd dezelfde thuismap hebben, op welk werkstation ze ook aanmelden; Meerdere machines kunnen een gezamenlijke map /usr/ports/distfiles hebben. Dan is het mogelijk om een port op meerdere machines te installeren, zonder op iedere machine de broncode te hoeven downloaden. Wylie Stilwell Geschreven door Chern Lee Herschreven door Automatisch aankoppelen met <application>amd</application> amd automatic mounter daemon &man.amd.8; (de automatic mounter daemon) koppelt automatisch netwerkbestandssystemen aan als er aan een bestand of map binnen dat bestandssysteem wordt gerefereerd. amd ontkoppelt ook bestandssystemen die een bepaalde tijd niet gebruikt worden. Het gebruikt van amd is een aantrekkelijk en eenvoudig alternatief ten opzichte van permanente koppelingen, die meestal in /etc/fstab staan. amd werkt door zichzelf als NFS-server te koppelen aan de mappen /host en /net. Als binnen die mappen een bestand wordt geraadpleegd, dan zoekt amd de bijbehorende netwerkkoppeling op en koppelt die automatisch aan. /net wordt gebruikt om een geëxporteerd bestandssysteem van een IP-adres aan te koppelen, terwijl /host wordt gebruikt om een geëxporteerd bestandssysteem van een hostnaam aan te koppelen. Het raadplegen van een bestand in /host/foobar/usr geeft amd aan dat die moet proberen de /usr export op de host foobar aan te koppelen. Een export aankoppelen met <application>amd</application> De beschikbare koppelingen van een netwerkhost zijn te bekijken met showmount. Om bijvoorbeeld de koppelingen van de host foobar te bekijken: &prompt.user; showmount -e foobar Exports list on foobar: /usr 10.10.10.0 /a 10.10.10.0 &prompt.user; cd /host/foobar/usr Zoals in het bovenstaande voorbeeld te zien is, toont showmount /usr als een export. Als er naar de map /host/foobar/usr wordt gegaan, probeert amd de hostnaam foobar te resolven en de gewenste export automatisch aan te koppelen. amd kan gestart worden door de opstartscript door de volgende regel in /etc/rc.conf te plaatsen: amd_enable="YES" Er kunnen ook nog opties meegegeven worden aan amd met de optie amd_flags. Standaard staat amd_flags ingesteld op: amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" In het bestand /etc/amd.map staan de standaardinstellingen waarmee exports aangekoppeld worden. In het bestand /etc/amd.conf staan een aantal van de meer gevorderde instellingen van amd. In &man.amd.8; en &man.amd.conf.5; staat meer informatie. John Lind Geschreven door Problemen bij samenwerking met andere systemen Bepaalde Ethernet adapters voor ISA PC systemen kennen limieten die tot serieuze netwerkproblemen kunnen leiden, in het bijzonder met NFS. Dit probleem is niet specifiek voor &os;, maar het kan op &os; wel voor komen. Het probleem ontstaat bijna altijd als (&os;) PC-systemen netwerken met hoog presterende werkstations, zoals van Silicon Graphics, Inc. en Sun Microsystems, Inc. De NFS-koppeling werkt prima en wellicht lukken een aantal acties ook, maar dan ineens lijkt de server niet meer te reageren voor de cliënt, hoewel verzoeken van en naar andere systemen gewoon verwerkt worden. Dit gebeurt op een cliëntsysteem, of de cliënt nu het &os; systeem is of het werkstation. Op veel systemen is er geen manier om de cliënt netjes af te sluiten als dit probleem is ontstaan. Vaak is de enige mogelijkheid een reset van de cliënt, omdat het probleem met NFS niet opgelost kan worden. Hoewel de enige correcte oplossing de aanschaf van een snellere en betere Ethernet adapter voor het &os; systeem is, is er zo om het probleem heen te werken dat het werkbaar is. Als &os; de server is, kan de optie gebruikt worden bij het aankoppelen door de cliënt. Als het &os; systeem de cliënt is, dan dient het NFS-bestandssysteem aangekoppeld te worden met de optie . Deze opties kunnen het vierde veld zijn in een regel in fstab voor automatische aankoppelingen en bij handmatige aankoppelingen met &man.mount.8; kan de parameter gebruikt worden. Soms wordt een ander probleem voor dit probleem versleten, als servers en cliënten zich op verschillende netwerken bevinden. Als dat het geval is, dan dient vastgesteld te worden dat routers de UDP informatie op de juiste wijze routeren, omdat er anders nooit NFS-verkeer gerouteerd kan worden. In de volgende voorbeelden is fastws de host(interface)naam van een hoog presterend werkstation en freebox is de host(interface)naam van een &os; systeem met een Ethernet adapter die mindere prestaties levert. /sharedfs wordt het geëxporteerde NFS-bestandssysteem (zie &man.exports.5;) en /project wordt het koppelpunt voor het geëxporteerde bestandssysteem op de cliënt. In sommige gevallen kunnen applicaties beter draaien als extra opties als of en gebruikt worden. Voorbeelden voor het &os; systeem (freebox) als de cliënt in /etc/fstab op freebox: fastws:/sharedfs /project nfs rw,-r=1024 0 0 Als een handmatig aankoppelcommando op freebox: &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project Voorbeelden voor het &os; systeem als de server in /etc/fstab op fastws: freebox:/sharedfs /project nfs rw,-w=1024 0 0 Als een handmatig aankoppelcommando op fastws: &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project Bijna iedere 16–bit Ethernet adapter werkt zonder de hierboven beschreven restricties op de lees- en schrijfgrootte. Voor wie het wil weten wordt nu beschreven wat er gebeurt als de fout ontstaan, wat ook duidelijk maakt waarom het niet hersteld kan worden. NFS werkt meestal met een blockgrootte van 8 K (hoewel het mogelijk is dat er kleinere fragmenten worden verwerkt). Omdat de maximale grootte van een Ethernet pakket rond de 1500 bytes ligt, wordt een block opgesplitst in meerdere Ethernetpakketten, hoewel het hoger in de code nog steeds één eenheid is, en wordt ontvangen, samengevoegd en bevestigd als een eenheid. De hoog presterende werkstations kunnen de pakketten waaruit een NFS-eenheid bestaat bijzonder snel naar buiten pompen. Op de kaarten met minder capaciteit worden de eerdere pakketten door de latere pakketten van dezelfde eenheid ingehaald voordat ze bij die host zijn aangekomen en daarom kan de eenheid niet worden samengesteld en bevestigd. Als gevolg daarvan ontstaat er op het werkstation een timeout en probeert die de eenheid opnieuw te sturen, maar dan weer de hele eenheid van 8 K, waardoor het proces wordt herhaald, ad infinitum. Door de grootte van de eenheid kleiner te houden dan de grootte van een Ethernet pakket, is het zeker dat elk Ethernetpakket dat compleet is aangekomen bevestigd kan worden, zodat de deadlock niet ontstaat. Toch kan een PC systeem nog wel overrompeld worden als hoog presterende werkstations er op inhakken, maar met de betere netwerkkaarten valt het dan in ieder geval niet om door de NFS eenheden. Als het systeem toch wordt overrompeld, dan worden de betrokken eenheden opnieuw verstuurd en dan is de kans groot dat ze worden ontvangen, samengevoegd en bevestigd. Bill Swingle Geschreven door Eric Ogren Verbeterd door Udo Erdelhoff Netwerkinformatiesysteem (NIS/YP) Wat is het? NIS Solaris HP-UX AIX Linux NetBSD OpenBSD NIS, dat staat voor Netwerkinformatiediensten (Network Information Services), is ontwikkeld door Sun Microsystems om het beheer van &unix; (origineel &sunos;) systemen te centraliseren. Tegenwoordig is het eigenlijk een industriestandaard geworden. Alle grote &unix; achtige systemen (&solaris;, HP-UX, &aix;, &linux;, NetBSD, OpenBSD, &os;, enzovoort) ondersteunen NIS. yellow pagesNIS NIS stond vroeger bekend als Yellow Pages, maar vanwege problemen met het handelsmerk heeft Sun de naam veranderd. De oude term, en yp, wordt nog steeds vaak gebruikt. NIS domeinen Het is een op RPC-gebaseerd cliënt/serversysteem waarmee een groep machines binnen een NIS-domein een gezamenlijke verzameling met instellingenbestanden kan delen. Hierdoor kan een beheerder NIS-systemen opzetten met een minimaal aantal instellingen en vanaf een centrale lokatie instellingen toevoegen, verwijderen en wijzigen. Windows NT Het is te vergelijken met het &windowsnt; domeinsysteem en hoewel de interne implementatie van de twee helemaal niet overeenkomt, is de basisfunctionaliteit vergelijkbaar. Termen en processen om te onthouden Er zijn een aantal termen en belangrijke gebruikersprocessen die een rol spelen bij het implementeren van NIS op &os;, zowel bij het maken van een NIS-server als bij het maken van een systeem dan NIS-cliënt is: rpcbind portmap Term Beschrijving NIS-domeinnaam Een NIS-masterserver en al zijn cliënten (inclusief zijn slave master) hebben een NIS-domeinnaam. Vergelijkbaar met een &windowsnt; domeinnaam, maar de NIS-domeinnaam heeft niets te maken met DNS. rpcbind Moet draaien om RPC (Remote Procedure Call in te schakelen, een netwerkprotocol dat door NIS gebruikt wordt). Als rpcbind niet draait, dan kan er geen NIS-server draaien en kan een machine ook geen NIS-cliënt zijn. ypbind Verbindt een NIS-cliënt aan zijn NIS-server. Dat gebeurt door met de NIS-domeinnaam van het systeem en door het gebruik van RPC te verbinden met de server. ypbind is de kern van cliënt-server communicatie in een NIS-omgeving. Als ypbind op een machine stopt, dan kan die niet meer bij de NIS-server komen. ypserv Hoort alleen te draaien op NIS-servers. Dit is het NIS-serverproces zelf. Als &man.ypserv.8; stopt, dan kan de server niet langer reageren op NIS-verzoeken (hopelijk is er dan een slaveserver om het over te nemen). Er zijn een aantal implementaties van NIS, maar niet die op &os;, die geen verbinding met een andere server proberen te maken als de server waarmee ze verbonden waren niet meer reageert. In dat geval is vaak het enige dat werkt het serverproces herstarten (of zelfs de hele server) of het ypbind-proces op de cliënt. rpc.yppasswdd Nog een proces dat alleen op NIS-masterservers hoort te draaien. Dit is een daemon waarbij NIS-cliënten hun NIS-wachtwoorden kunnen wijzigen. Als deze daemon niet draait, moeten gebruikers zich aanmelden op de NIS-masterserver en daar hun wachtwoord wijzigen. Hoe werkt het? Er zijn drie typen hosts in een NIS-omgeving: master servers, slaveservers en cliënten. Servers zijn het centrale depot voor instellingen voor een host. Masterservers bevatten de geautoriseerd kopie van die informatie, terwijl slaveservers die informatie spiegelen voor redundantie. Cliënten verlaten zich op de servers om hun die informatie ter beschikking te stellen. Op deze manier kan informatie uit veel bestanden gedeeld worden. De bestanden master.passwd, group en hosts worden meestal via NIS gedeeld. Als een proces op een cliënt informatie nodig heeft die normaliter in een van die lokale bestanden staat, dan vraagt die het in plaats daarvan aan de NIS-servers waarmee hij verbonden is. Soorten machines NIS masterserver Een NIS-masterserver. Deze server onderhoudt, analoog aan een &windowsnt; primaire domeincontroller, de bestanden die door alle NIS-cliënten gebruikt worden. De bestanden passwd, group en andere bestanden die door de NIS-cliënten gebruikt worden staan op de masterserver. Het is mogelijk om één machine master server te laten zijn voor meerdere NIS-domeinen. Dat wordt in deze inleiding echter niet beschreven, omdat die uitgaat van een relatief kleine omgeving. NIS slaveserver NIS-slaveservers. Deze zijn te vergelijken met &windowsnt; backup domain controllers. NIS-slaveservers beheren een kopie van de bestanden met gegevens op de NIS-master. NIS-slaveservers bieden redundantie, die nodig is in belangrijke omgevingen. Ze helpen ook om de belasting te verdelen met de master server: NIS-cliënten maken altijd een verbinding met de NIS-server die het eerst reageert en dat geldt ook voor antwoorden van slaveservers. NIS cliënt NIS-cliënten. NIS-cliënten authenticeren, net als de meeste &windowsnt; werkstations, tegen de NIS-server (of de &windowsnt; domain controller in het geval van &windowsnt; werkstations) bij het aanmelden. NIS/YP gebruiken Dit onderdeel behandelt het opzetten van een NIS-voorbeeldomgeving. Plannen Er wordt uitgegaan van een beheerder van een klein universiteitslab. Dat lab, dat bestaat uit &os; machines, kent op dit moment geen centraal beheer. Iedere machine heeft zijn eigen /etc/passwd en /etc/master.passwd. Die bestanden worden alleen met elkaar in lijn gehouden door handmatige handelingen. Als er op dit moment een gebruiker aan het lab wordt toegevoegd, moet adduser op alle 15 machines gedraaid worden. Dat moet natuurlijk veranderen en daarom is besloten het lab in te richten met NIS, waarbij twee machines als server worden gebruikt. Het lab ziet er ongeveer als volgt uit: Machinenaam IP-adres Rol Machine ellington 10.0.0.2 NIS-master coltrane 10.0.0.3 NIS-slave basie 10.0.0.4 Wetenschappelijk werkstation bird 10.0.0.5 Cliënt machine cli[1-11] 10.0.0.[6-17] Andere cliënt machines Bij het voor de eerste keer instellen van een NIS-schema is het verstandig eerst na te denken over hoe dat opgezet moet worden. Hoe groot een netwerk ook is, er moeten een aantal beslissingen gemaakt worden. Een NIS-domeinnaam kiezen NIS domeinnaam Dit is wellicht niet de bekende domeinnaam. Daarom wordt het ook de NIS-domeinnaam genoemd. Bij de broadcast van een cliënt om informatie wordt ook de naam van het NIS-domein waar hij onderdeel van uitmaakt meegezonden. Zo kunnen meerdere servers op een netwerk bepalen of er antwoord gegeven dient te worden op een verzoek. De NIS-domeinnaam is kan voorgesteld worden als de naam van een groep hosts op op een of andere manier aan elkaar gerelateerd zijn. Sommige organisaties kiezen hun Internet-domeinnaam als NIS-domeinnaam. Dat wordt niet aangeraden omdat het voor verwarring kan zorgen bij het debuggen van netwerkproblemen. De NIS-domeinnaam moet uniek zijn binnen een netwerk en het is handig als die de groep machines beschrijft waarvoor hij geldt. Zo kan bijvoorbeeld de financiële afdeling van Acme Inc. als NIS-domeinnaam acme-fin hebben. In dit voorbeeld wordt de naam test-domain gekozen. SunOS Sommige besturingssystemen gebruiken echter (met name &sunos;) hun NIS-domeinnaam als hun Internet-domeinnaam. Als er machines zijn op een netwerk die deze restrictie kennen, dan moet de Internet-domeinnaam als de naam voor het NIS-domeinnaam gekozen worden. Systeemeisen Bij het kiezen van een machine die als NIS-server wordt gebruikt zijn er een aantal aandachtspunten. Een van de onhandige dingen aan NIS is de afhankelijkheid van de cliënten van de server. Als een cliënt de server voor zijn NIS-domein niet kan bereiken, dan wordt die machine vaak onbruikbaar. Door het gebrek aan gebruiker- en groepsinformatie bevriezen de meeste systemen. Daarom moet er een machine gekozen worden die niet vaak herstart hoeft te worden of wordt gebruikt voor ontwikkeling. De NIS-server is in het meest ideale geval een alleenstaande server die als enige doel heeft NIS-server te zijn. Als een netwerk niet zwaar wordt gebruikt, kan de NIS-server op een machine die ook andere diensten aanbiedt gezet worden, maar het blijft belangrijk om ervan bewust te zijn dat als de NIS-server niet beschikbaar is, dat nadelige invloed heeft op alle NIS-cliënten. NIS-servers De hoofdversies van alle NIS-informatie staan opgeslagen op één machine die de NIS-masterserver heet. De databases waarin de informatie wordt opgeslagen heten NIS-afbeeldingen. In &os; worden die afbeeldingen opgeslagen in /var/yp/[domeinnaam] waar [domeinnaam] de naam is van het NIS-domein dat wordt bediend. Een enkele NIS-server kan tegelijkertijd meerdere NIS-domeinen ondersteunen en het is dus mogelijk dat er meerdere van zulke mappen zijn, een voor ieder ondersteund domein. Ieder domein heeft zijn eigen onafhankelijke verzameling afbeeldingen. In NIS-master- en -slaveservers worden alle NIS-verzoeken door de daemon ypserv afgehandeld. ypserv is verantwoordelijk voor het ontvangen van inkomende verzoeken van NIS-cliënten, het vertalen van de gevraagde domeinnaam en mapnaam naar een pad naar het corresponderende databasebestand en het terugsturen van de database naar de cliënten. Een NIS-masterserver opzetten NIS server opzetten Het opzetten van een master NIS-server kan erg eenvoudig zijn, afhankelijk van de behoeften. &os; heeft ondersteuning voor NIS als basisfunctie. Alleen de volgende regels hoeven aan /etc/rc.conf toegevoegd te worden en &os; doet de rest: nisdomainname="test-domain" Deze regel stelt de NIS-domeinnaam in op test-domain bij het instellen van het netwerk (bij het opstarten). nis_server_enable="YES" Dit geeft &os; aan de NIS-serverprocessen te starten als het netwerk de volgende keer wordt opgestart. nis_yppasswdd_enable="YES" Dit schakelt de daemon rpc.yppasswdd in die, zoals al eerder aangegeven, cliënten toestaat om hun NIS-wachtwoord vanaf een cliënt-machine te wijzigen. Afhankelijk van de inrichting van NIS, kunnen er nog meer instellingen nodig zijn. In het onderdeel NIS-servers die ook NIS-cliënten zijn staan meer details. Draai na het instellen van bovenstaande regels het commando /etc/netstart als supergebruiker. Het zal alles voor u instellen, gebruikmakende van de waarden die u in /etc/rc.conf heeft ingesteld. Start als laatste stap, voor het initialiseren van de NIS-afbeeldingen, de daemon ypserv handmatig: &prompt.root; /etc/rc.d/ypserv start NIS-afbeeldingen initialiseren NIS afbeeldingen Die NIS-afbeeldingen zijn databasebestanden die in de map /var/yp staan. Ze worden gemaakt uit de bestanden met instellingen uit de map /etc van de NIS-master, met één uitzondering: /etc/master.passwd. Daar is een goede reden voor, want het is niet wenselijk om de wachtwoorden voor root en andere administratieve accounts naar alle servers in het NIS-domein te sturen. Daar moet voor het initialiseren van de NIS-afbeeldingen het volgende uitgevoerd worden: &prompt.root; cp /etc/master.passwd /var/yp/master.passwd &prompt.root; cd /var/yp &prompt.root; vi master.passwd Dan horen alle systeemaccounts verwijderd te worden (bin, tty, kmem, games, enzovoort) en alle overige accounts waarvoor het niet wenselijk is dat ze op de NIS-cliënten terecht komen (bijvoorbeeld root en alle andere UID 0 (supergebruiker) accounts). /var/yp/master.passwd hoort niet te lezen te zijn voor een groep of voor de wereld (dus modus 600)! Voor het aanpassen van de rechten kan chmod gebruikt worden. Tru64 UNIX Als dat is gedaan, kunnen de NIS-afbeeldingen geïnitialiseerd worden. Bij &os; zit een script ypinit waarmee dit kan (in de hulppagina staat meer informatie). Dit script is beschikbaar op de meeste &unix; besturingssystemen, maar niet op allemaal. Op Digital UNIX/Compaq Tru64 UNIX heet het ypsetup. Omdat er afbeeldingen voor een NIS-master worden gemaakt, wordt de optie meegegeven aan ypinit. Aangenomen dat de voorgaande stappen zijn uitgevoerd, kunnen de NIS-afbeeldingen gemaakt worden op de volgende manier: ellington&prompt.root; ypinit -m test-domain Server Type: MASTER Domain: test-domain Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. At this point, we have to construct a list of this domains YP servers. rod.darktech.org is already known as master server. Please continue to add any slave servers, one per line. When you are done with the list, type a <control D>. master server : ellington next host to add: coltrane next host to add: ^D The current list of NIS servers looks like this: ellington coltrane Is this correct? [y/n: y] y [..uitvoer van het maken van de afbeeldingen..] NIS Map update completed. ellington has been setup as an YP master server without any errors. ypinit hoort /var/yp/Makefile gemaakt te hebben uit /var/yp/Makefile.dist. Als dit bestand is gemaakt, neemt dat bestand aan dat er in een omgeving met een enkele NIS-server wordt gewerkt met alleen &os;-machines. Omdat test-domain ook een slaveserver bevat, dient /var/yp/Makefile gewijzigd te worden: ellington&prompt.root; vi /var/yp/Makefile Als de onderstaande regel niet al uitgecommentarieerd is, dient dat alsnog te gebeuren: NOPUSH = "True" Een NIS-slaveserver opzetten NIS slaveserver Het opzetten van een NIS-slaveserver is nog makkelijker dan het opzetten van de master. Dit kan door aan te melden op de slaveserver en net als voor de masterserver /etc/rc.conf te wijzigen. Het enige verschil is dat nu de optie gebruikt wordt voor het draaien van ypinit. Met de optie moet ook de naam van de NIS-master meegegeven worden. Het commando ziet er dus als volgt uit: coltrane&prompt.root; ypinit -s ellington test-domain Server Type: SLAVE Domain: test-domain Master: ellington Creating an YP server will require that you answer a few questions. Questions will all be asked at the beginning of the procedure. Do you want this procedure to quit on non-fatal errors? [y/n: n] n Ok, please remember to go back and redo manually whatever fails. If you don't, something might not work. There will be no further questions. The remainder of the procedure should take a few minutes, to copy the databases from ellington. Transferring netgroup... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byuser... ypxfr: Exiting: Map successfully transferred Transferring netgroup.byhost... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byuid... ypxfr: Exiting: Map successfully transferred Transferring passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring group.bygid... ypxfr: Exiting: Map successfully transferred Transferring group.byname... ypxfr: Exiting: Map successfully transferred Transferring services.byname... ypxfr: Exiting: Map successfully transferred Transferring rpc.bynumber... ypxfr: Exiting: Map successfully transferred Transferring rpc.byname... ypxfr: Exiting: Map successfully transferred Transferring protocols.byname... ypxfr: Exiting: Map successfully transferred Transferring master.passwd.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byname... ypxfr: Exiting: Map successfully transferred Transferring networks.byaddr... ypxfr: Exiting: Map successfully transferred Transferring netid.byname... ypxfr: Exiting: Map successfully transferred Transferring hosts.byaddr... ypxfr: Exiting: Map successfully transferred Transferring protocols.bynumber... ypxfr: Exiting: Map successfully transferred Transferring ypservers... ypxfr: Exiting: Map successfully transferred Transferring hosts.byname... ypxfr: Exiting: Map successfully transferred coltrane has been setup as an YP slave server without any errors. Don't forget to update map ypservers on ellington. Nu hoort er een map /var/yp/test-domain te zijn waarin kopieë van de NIS-masterserver afbeeldingen staan. Die moeten bijgewerkt blijven. De volgende regel in /etc/crontab op de slaveservers regelt dat: 20 * * * * root /usr/libexec/ypxfr passwd.byname 21 * * * * root /usr/libexec/ypxfr passwd.byuid Met de bovenstaande twee regels wordt de slave gedwongen zijn afbeeldingen met de afbeeldingen op de masterserver te synchroniseren. Hoewel dit niet verplicht is, omdat de masterserver probeert veranderingen aan de NIS-afbeeldingen door te geven aan zijn slaves, is het wel verstandig om een slave tot bijwerken te dwingen, omdat wachtwoordinformatie van vitaal belang is voor systemen die van de server afhankelijk zijn. Dit is des te belangrijker op drukke netwerken, omdat daar het bijwerken van afbeeldingen niet altijd compleet afgehandeld hoeft te worden. Nu kan ook op de slaveserver het commando /etc/netstart uitgevoerd worden, dat op zijn beurt de NIS-server start. NIS-cliënten Een NIS-cliënt maakt wat heet een verbinding (binding) met een NIS-server met de daemon ypbind. ypbind controleert het standaarddomein van het systeem (zoals ingesteld met domainname) en begint met het broadcasten van RPC-verzoeken op het lokale netwerk. Die verzoeken bevatten de naam van het domein waarvoor ypbind een binding probeert te maken. Als een server die is ingesteld om het gevraagde domein te bedienen een broadcast ontvangt, dan antwoordt die aan ypbind dat dan het IP-adres van de server opslaat. Als er meerdere servers beschikbaar zijn, een master en bijvoorbeeld meerdere slaves, dan gebruikt ypbind het adres van de eerste server die antwoord geeft. Vanaf dat moment stuurt de cliënt alle NIS-verzoeken naar die server. ypbind pingt de server zo nu en dan om te controleren of die nog draait. Als er na een bepaalde tijd geen antwoord komt op een ping, dan markeert ypbind het domein als niet verbonden en begint het broadcasten opnieuw, in de hoop dat er een andere server wordt gelocaliseerd. Een NIS-cliënt opzetten NIS cliënt instellen Het opzetten van een &os; machine als NIS-cliënt is redelijk doorzichtig: Wijzig /etc/rc.conf en voeg de volgende regels toe om de NIS-domeinnaam in te stellen en ypbind mee te laten starten bij het starten van het netwerk: nisdomainname="test-domain" nis_client_enable="YES" Om alle mogelijke regels voor accounts uit de NIS-server te halen, dienen alle gebruikersaccounts uit /etc/master.passwd verwijderd te worden en dient met vipw de volgende regel aan het einde van het bestand geplaatst te worden: +::::::::: Door deze regel wordt alle geldige accounts in de wachtwoordafbeelding van de NIS-server toegang gegeven. Er zijn veel manieren om de NIS-cliënt in te stellen door deze regel te veranderen. In het onderdeel netgroepen hieronder staat meer informatie. Zeer gedetailleerde informatie staat in het boek NFS en NIS beheren van O'Reilly. Er moet tenminste één lokale account behouden blijven (dus niet geïmporteerd via NIS) in /etc/master.passwd en die hoort ook lid te zijn van de groep wheel. Als er iets mis is met NIS, dan kan die account gebruikt worden om via het netwerk aan te melden, root te worden en het systeem te repareren. Om alle groepen van de NIS-server te importeren, kan de volgende regel aan /etc/group toegevoegd worden: +:*:: Voer, om de NIS-cliënt onmiddelijk te starten, de volgende commando's als supergebruiker uit: &prompt.root; /etc/netstart &prompt.root; /etc/rc.d/ypbind start Na het afronden van deze stappen zou met ypcat passwd de passwd map van de NIS-server te zien moeten zijn. NIS-beveiliging In het algemeen kan iedere netwerkgebruiker een RPC-verzoek doen uitgaan naar &man.ypserv.8; en de inhoud van de NIS-afbeeldingen ontvangen, mits die gebruiker de domeinnaam kent. Omdat soort ongeautoriseerde transacties te voorkomen, ondersteunt &man.ypserv.8; de optie securenets, die gebruikt kan worden om de toegang te beperken tot een opgegeven aantal hosts. Bij het opstarten probeert &man.ypserv.8; de securenets informatie te laden uit het bestand /var/yp/securenets. Dit pad kan verschillen, afhankelijk van het pad dat opgegeven is met de optie . Dit bestand bevat regels die bestaan uit een netwerkspecificatie en een netwerkmasker, gescheiden door witruimte. Regels die beginnen met # worden als commentaar gezien. Een voorbeeld van een securenetsbestand zou er zo uit kunnen zien: # allow connections from local host -- mandatory 127.0.0.1 255.255.255.255 # allow connections from any host # on the 192.168.128.0 network 192.168.128.0 255.255.255.0 # allow connections from any host # between 10.0.0.0 to 10.0.15.255 # this includes the machines in the testlab 10.0.0.0 255.255.240.0 Als &man.ypserv.8; een verzoek ontvangt van een adres dat overeenkomt met een van de bovenstaande regels, dan wordt dat verzoek normaal verwerkt. Als er geen enkele regel op het verzoek van toepassing is, dan wordt het verzoek genegeerd en wordt er een waarschuwing gelogd. Als het bestand /var/yp/securenets niet bestaat, dan accepteert ypserv verbindingen van iedere host. Het programma ypserv ondersteunt ook het pakket TCP Wrapper van Wietse Venema. Daardoor kan een beheerder de instellingenbestanden van TCP Wrapper gebruiken voor toegangsbeperking in plaats van /var/yp/securenets. Hoewel beide methoden van toegangscontrole enige vorm van beveiliging bieden, zijn ze net als de geprivilegieerde poorttest kwetsbaar voor IP spoofing aanvallen. Al het NIS-gerelateerde verkeer hoort door een firewall tegengehouden te worden. Servers die gebruik maken van /var/yp/securenets kunnen wellicht legitieme verzoeken van NIS-cliënten weigeren als die gebruik maken van erg oude TCP/IP-implementaties. Sommige van die implementaties zetten alle host bits op nul als ze een broadcast doen en/of kijken niet naar het subnetmasker als ze het broadcastadres berekenen. Hoewel sommige van die problemen opgelost kunnen worden door de instellingen op de cliënt aan te passen, zorgen andere problemen voor het noodgedwongen niet langer kunnen gebruiker van NIS voor die cliënt of het niet langer gebruiken van /var/yp/securenets. Het gebruik van /var/yp/securenets op een server met zo'n oude implementatie van TCP/IP is echt een slecht idee en zal leiden tot verlies van NIS-functionaliteit voor grote delen van een netwerk. tcpwrapper Het gebruik van het pakket TCP Wrapper leidt tot langere wachttijden op de NIS-server. De extra vertraging kan net lang genoeg zijn om een timeout te veroorzaken in cliëntprogramma's, in het bijzonder als het netwerk druk is of de NIS-server traag is. Als een of meer cliënten last hebben van dat symptoom, dan is het verstandig om de cliëntsysteem in kwestie NIS-slaveserver te maken en naar zichzelf te laten wijzen. Aanmelden voor bepaalde gebruikers blokkeren In het lab staat de machine basie, die alleen faculteitswerkstation hoort te zijn. Het is niet gewenst die machine uit het NIS-domein te halen, maar het passwd bestand op de master NIS-server bevat nu eenmaal accounts voor zowel de faculteit als de studenten. Hoe kan dat opgelost worden? Er is een manier om het aanmelden van specifieke gebruikers op een machine te weigeren, zelfs als ze in de NIS-database staan. Daarvoor hoeft er alleen maar –username aan het einde van /etc/master.passwd op de cliënt machine toegevoegd te worden, waar username de gebruikersnaam van de gebruiker die niet mag aanmelden is. Dit gebeurt bij voorkeur met vipw, omdat vipw de wijzigingen aan /etc/master.passwd controleert en ook de wachtwoord database opnieuw bouwt na het wijzigen. Om bijvoorbeeld de gebruiker bill aan te kunnen laten aanmelden op basie: basie&prompt.root; vipw [add -bill to the end, exit] vipw: rebuilding the database... vipw: done basie&prompt.root; cat /etc/master.passwd root:[password]:0:0::0:0:The super-user:/root:/bin/csh toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin operator:*:2:5::0:0:System &:/:/sbin/nologin bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin news:*:8:8::0:0:News Subsystem:/:/sbin/nologin man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin +::::::::: -bill basie&prompt.root; Udo Erdelhoff Geschreven door Netgroups gebruiken netgroepen De methode uit het vorige onderdeel werkt prima als er maar voor een beperkt aantal gebruikers en/of machines speciale regels nodig zijn. Op grotere netwerken gebeurt het gewoon dat er wordt vergeten om een aantal gebruikers de aanmeldrechten op gevoelige machines te ontnemen of dat zelfs iedere individuele machine aangepast moet worden, waardoor het voordeel van NIS teniet wordt gedaan: centraal beheren. De ontwikkelaars van NIS hebben dit probleem opgelost met netgroepen. Het doel en de semantiek kunnen vergeleken worden met de normale groepen die gebruikt worden op &unix; bestandssystemen. De belangrijkste verschillen zijn de afwezigheid van een numeriek ID en de mogelijkheid om een netgroep aan te maken die zowel gebruikers als andere netgroepen bevat. Netgroepen zijn ontwikkeld om gebruikt te worden voor grote, complexe netwerken met honderden gebruikers en machines. Aan de ene kant is dat iets Goeds. Aan de andere kant is het wel complex en bijna onmogelijk om netgroepen met een paar eenvoudige voorbeelden uit te leggen. Dat probleem wordt in de rest van dit onderdeel duidelijk gemaakt. Stel dat de succesvolle implementatie van NIS in het lab de interesse heeft gewekt van een centrale beheerclub. De volgende taak is het uitbreiden van het NIS-domein met een aantal andere machines op de campus. De onderstaande twee tabellen bevatten de namen van de nieuwe gebruikers en de nieuwe machines met een korte beschijving. Gebruikersna(a)m(en) Beschrijving alpha, beta Gewone medewerkers van de IT-afdeling charlie, delta Junior medewerkers van de IT-afdeling echo, foxtrott, golf, ... Gewone medewerkers able, baker, ... Stagiairs Machinena(a)m(en) Beschrijving war, death, famine, pollution De belangrijkste servers. Alleen senior medewerkers van de IT-afdeling mogen hierop aanmelden. pride, greed, envy, wrath, lust, sloth Minder belangrijke servers. Alle leden van de IT-afdeling mogen aanmelden op deze machines. one, two, three, four, ... Gewone werkstations. Alleen echte medewerkers mogen zich op deze machines aanmelden. trashcan Een erg oude machine zonder kritische data. Zelfs de stagiair mag deze doos gebruiken. Als deze restricties ingevoerd worden door iedere gebruiker afzonderlijk te blokkeren, dan wordt er een -user regel per systeem toegevoegd aan de passwd voor iedere gebruiker die niet mag aanmelden op dat systeem. Als er maar één regel wordt vergeten, kan dat een probleem opleveren. Wellicht lukt het nog dit juist in te stellen bij de bouw van een machine, maar het wordt echt vergeten de regels toe te voegen voor nieuwe gebruikers in de productiefase. Murphy was tenslotte een optimist. Het gebruik van netgroepen biedt in deze situatie een aantal voordelen. Niet iedere gebruiker hoeft separaat afgehandeld te worden. Een gebruik kan aan een of meer groepen worden toegevoegd en aanmelden kan voor alle leden van zo'n groep worden toegestaan of geweigerd. Als er een nieuwe machine wordt toegevoegd, dan hoeven alleen de aanmeldrestricties voor de netgroepen te worden ingesteld. Als er een nieuwe gebruiker wordt toegevoegd, dan hoeft die alleen maar aan de juiste netgroepen te worden toegevoegd. Die veranderingen zijn niet van elkaar afhankelijk: geen voor iedere combinatie van gebruiker en machine moet het volgende .... Als de NIS-opzet zorgvuldig is gepland, dan hoeft er maar één instellingenbestand gewijzigd te worden om toegang tot machines te geven of te ontnemen. De eerst stap is het initialiseren van de NIS-afbeelding netgroup. &man.ypinit.8; van &os; maakt deze map niet standaard, maar als die is gemaakt, ondersteunt de NIS-implementatie hem wel. Een lege map wordt als volgt gemaakt: ellington&prompt.root; vi /var/yp/netgroup Nu kan hij gevuld worden. In het gebruikte voorbeeld zijn tenminste vier netgroepen: IT-medewerkers, IT-junioren, gewone medewerkers en stagiars. IT_MW (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) USERS (,echo,test-domain) (,foxtrott,test-domain) \ (,golf,test-domain) STAGS (,able,test-domain) (,baker,test-domain) IT_MW, IT_APP enzovoort, zijn de namen van de netgroepen. Iedere groep tussen haakjes bevat een of meer gebruikersnamen voor die groep. De drie velden binnen een groep zijn: De na(a)m(en) van de host(s) waar de volgende onderdelen geldig zijn. Als er geen hostnaam wordt opgegeven dan is de regel geldig voor alle hosts. Als er wel een hostnaam wordt opgegeven, dan wordt een donker, spookachtig en verwarrend domein betreden. De naam van de account die bij deze netgroep hoort. Het NIS-domein voor de account. Er kunnen accounts uit andere NIS-domeinen geïmporteerd worden in een netgroep als een beheerder zo ongelukkig is meerdere NIS-domeinen te hebben. Al deze velden kunnen jokerkarakters bevatten. Details daarover staan in &man.netgroup.5;. netgroepen De naam van een netgroep mag niet langer zijn dan acht karakters, zeker niet als er andere besturingssystemen binnen een NIS-domein worden gebruikt. De namen zijn hoofdlettergevoelig: alleen hoofdletters gebruiken voor de namen van netgroepen is een makkelijke manier om onderscheid te kunnen maken tussen gebruikers-, machine- en netgroepnamen. Sommige NIS-cliënten (andere dan die op &os; draaien) kunnen niet omgaan met netgroepen met veel leden. Sommige oudere versies van &sunos; gaan bijvoorbeeld lastig doen als een netgroep meer dan 15 leden heeft. Dit kan omzeild worden door meerdere subnetgroepen te maken met 15 gebruikers of minder en een echte netgroep die de subnetgroepen bevat: BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe31,domain) (,joe32,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 Dit proces kan herhaald worden als er meer dan 225 gebruikers in een netgroep moeten. Het activeren en distribueren van de nieuwe NIS-map is eenvoudig: ellington&prompt.root; cd /var/yp ellington&prompt.root; make Hiermee worden drie nieuwe NIS-afbeeldingen gemaakt: netgroup, netgroup.byhost en netgroup.byuser. Met &man.ypcat.1; kan bekeken worden op de nieuwe NIS-afbeeldingen beschikbaar zijn: ellington&prompt.user; ypcat -k netgroup ellington&prompt.user; ypcat -k netgroup.byhost ellington&prompt.user; ypcat -k netgroup.byuser De uitvoer van het eerste commando hoort te lijken op de inhoud van /var/yp/netgroup. Het tweede commando geeft geen uitvoer als er geen host-specifieke netgroepen zijn ingesteld. Het derde commando kan gebruikt worden om een lijst van netgroepen voor een gebruiker op te vragen. Het instellen van de cliënt is redelijk eenvoudig. Om de server war in te stellen hoeft alleen met &man.vipw.8; de volgende regel in de regel daarna vervangen te worden: +::::::::: Vervang de bovenstaande regel in de onderstaande. +@IT_MW::::::::: Nu worden alleen de gebruikers die in de netgroep IT_MW geïmporteerd in de wachtwoorddatabase van de host war, zodat alleen die gebruikers zich kunnen aanmelden. Helaas zijn deze beperkingen ook van toepassing op de functie ~ van de shell en alle routines waarmee tussen gebruikersnamen en numerieke gebruikers ID's wordt gewisseld. Met andere woorden: cd ~user werkt niet, ls –l toont het numerieke ID in plaats van de gebruikersnaam en find . –user joe –print faalt met de foutmelding No such user. Om dit te repareren moeten alle gebruikers geïmporteerd worden, zonder ze het recht te geven aan te melden op een server. Dit kan gedaan worden door nog een regel aan /etc/master.passwd toe te voegen: +:::::::::/sbin/nologin Dit betekent importeer alle gebruikers, maar vervang de shell door /sbin/nologin. Ieder veld in een passwd regel kan door een standaardwaarde vervangen worden in /etc/master.passwd. De regel +:::::::::/sbin/nologin moet na +@IT_MW::::::::: komen. Anders krijgen alle gebruikers die uit NIS-komen /sbin/nologin als aanmeldshell. Na deze wijziging hoeft er nog maar één NIS-afbeelding gewijzigd te worden als er een nieuwe medewerker komt bij de IT-afdeling. Dezelfde aanpak kan gebruikt worden voor de minder belangrijke servers door de oude regel +::::::::: in de lokale versie van /etc/master.passwd door iets als het volgende te vervangen: +@IT_MW::::::::: +@IT_APP::::::::: +:::::::::/sbin/nologin Voor normale werkstations zijn het de volgende regels: +@IT_MW::::::::: +@USERS::::::::: +:::::::::/sbin/nologin En dat zou allemaal leuk en aardig zijn als er niet na een paar weken een beleidsverandering komt: de IT-afdeling gaat stagiairs aannemen. De IT-stagiairs mogen de normale werkstations en de minder belangrijke servers gebruiken en de juniorbeheerders mogen gaan aanmelden op de hoofdservers. Dat kan door een nieuwe groep IT_STAG te maken en de nieuwe IT-stagiairs toe te voegen aan die netgroep en dan de instellingen op iedere machine te gaan veranderen. Maar zoals het spreekwoord zegt: Fouten in een centrale planning leiden tot complete chaos. Deze situaties kunnen voorkomen worden door gebruik te maken van de mogelijkheid in NIS om netgroepen in netgroepen op te nemen. Het is mogelijk om rolgebaseerde netgroepen te maken. Er kan bijvoorbeeld een netgroep BIGSRV gemaakt worden om het aanmelden op de belangrijke servers te beperken en er kan een andere netgroep SMALLSRV voor de minder belangrijke servers zijn en een derde netgroep met de naam USERBOX voor de normale werkstations. Al die netgroepen kunnen de netgroepen bevatten die op die machines mogen aanmelden. De nieuwe regels in de NIS-afbeelding netgroup zien er dan zo uit: BIGSRV IT_MW IT_APP SMALLSRV IT_MW IT_APP ITSTAG USERBOX IT_MW ITSTAG USERS Deze methode voor het instellen van aanmeldbeperkingen werkt redelijk goed als er groepen van machines gemaakt kunnen worden met identieke beperkingen. Helaas blijkt dat eerder uitzondering dan regel. Meestal moet het mogelijk zijn om per machine in te stellen wie zich wel en wie zich niet mogen aanmelden. Daarom is het ook mogelijk om via machinespecifieke netgroepen de hierboven aangegeven beleidswijziging op te vangen. In dat scenario bevat /etc/master.passwd op iedere machine twee regels die met + beginnen. De eerste voegt de netgroep toe met de accounts die op de machine mogen aanmelden en de tweede voegt alle andere accounts toe met /sbin/nologin als shell. Het is verstandig om als naam van de netgroep de machinenaam in HOOFDLETTERS te gebruiken. De regels zien er ongeveer als volgt uit: +@MACHINENAAM::::::::: +:::::::::/sbin/nologin Als dit voor alle machines is gedaan, dan hoeven de lokale versies van /etc/master.passwd nooit meer veranderd te worden. Alle toekomstige wijzigingen kunnen dan gemaakt worden door de NIS-afbeelding te wijzigen. Hieronder staat een voorbeeld van een mogelijke netgroep map voor het beschreven scenario met een aantal toevoegingen: # Definieer eerst de gebruikersgroepen IT_MW (,alpha,test-domain) (,beta,test-domain) IT_APP (,charlie,test-domain) (,delta,test-domain) DEPT1 (,echo,test-domain) (,foxtrott,test-domain) DEPT2 (,golf,test-domain) (,hotel,test-domain) DEPT3 (,india,test-domain) (,juliet,test-domain) ITSTAG (,kilo,test-domain) (,lima,test-domain) D_STAGS (,able,test-domain) (,baker,test-domain) # # En nu een aantal groepen op basis van rollen USERS DEPT1 DEPT2 DEPT3 BIGSRV IT_MW IT_APP SMALLSRV IT_MW IT_APP ITSTAG USERBOX IT_MW ITSTAG USERS # # Een een groep voor speciale taken. # Geef echo en golf toegang tot de anti-virus machine. SECURITY IT_MW (,echo,test-domain) (,golf,test-domain) # # Machinegebaseerde netgroepen # Hoofdservers WAR BIGSRV FAMINE BIGSRV # Gebruiker india heeft toegang tot deze server nodig. POLLUTION BIGSRV (,india,test-domain) # # Deze is erg belangrijk en heeft strengere toegangseisen nodig. DEATH IT_MW # # De anti-virus machine als hierboven genoemd. ONE SECURITY # # Een machine die maar door 1 gebruiker gebruikt mag worden. TWO (,hotel,test-domain) # [...hierna volgen de andere groepen] Als er een soort database wordt gebruikt om de gebruikersaccounts te beheren, dan is het in ieder geval nodig dat ook het eerste deel van de afbeelding met de databaserapportagehulpmiddelen gemaakt kan worden. Dan krijgen nieuwe gebruikers automatisch toegang tot de machines. Nog een laatste waarschuwing: het is niet altijd aan te raden gebruik te maken van machinegebaseerde netgroepen. Als er tientallen of zelfs honderden gelijke machines voor bijvoorbeeld studentenruimtes worden uitgerold, dan is het verstandiger rolgebaseerde netgroepen te gebruiken in plaats van machinegebaseerde netgroepen om de grootte van de NIS-afbeelding binnen de perken te houden. Belangrijk om te onthouden In een NIS-omgeving werken een aantal dingen wel anders. Als er een gebruiker toegevoegd moet worden, dan moet die alleen toegevoegd worden aan de master NIS-server en mag niet vergeten worden dat de NIS-afbeeldingen herbouwd moeten worden. Als dit wordt vergeten, dan kan de nieuwe gebruiker nergens anders aanmelden dan op de NIS-master. Als bijvoorbeeld een nieuwe gebruiker jsmith toegevoegd moet worden: &prompt.root; pw useradd jsmith &prompt.root; cd /var/yp &prompt.root; make test-domain Er kan ook adduser jsmith in plaats van pw useradd jsmith gebruikt worden. De beheeraccounts moeten buiten de NIS-afbeeldingen gehouden worden. Het is niet handig als de beheeraccounts en wachtwoorden naar machines waarop gebruikers zich aanmelden die geen toegang tot die informatie horen te hebben zouden gaan. De NIS-master en slave moeten veilig blijven en zo min mogelijk niet beschikbaar zijn. Als de machine wordt gehackt of als hij wordt uitgeschakeld, dan kunnen er in theorie nogal wat mensen niet meer aanmelden. Dit is de belangrijkste zwakte van elk gecentraliseerd beheersysteem. Als de NIS-servers niet goed beschermd worden, dan worden veel gebruikers boos! NIS v1-compatibiliteit ypserv voor &os; biedt wat ondersteuning voor NIS v1 cliënten. De NIS-implementatie van &os; gebruikt alleen het NIS v2 protocol, maar andere implementaties bevatten ondersteuning voor het v1 protocol voor achterwaartse compatibiliteit met oudere systemen. De ypbind-daemons die bij deze systemen zitten proberen een binding op te zetten met een NIS v1 server, hoewel dat niet per se ooit nodig is (en ze gaan misschien nog wel door met broadcasten nadat ze een antwoord van een v2 server hebben ontvangen). Het is belangrijk om te melden dat hoewel ondersteuning voor gewone cliëntoproepen aanwezig is, deze versie van ypserv geen overdrachtsverzoeken voor v1-afbeeldingen af kan handelen. Daarom kan ypserv niet gebruikt worden als master of slave in combinatie met oudere NIS-servers die alleen het v1 protocol ondersteunen. Gelukkig worden er in deze tijd niet meer zoveel van deze servers gebruikt. NIS-servers die ook NIS-cliënten zijn Het is belangrijk voorzichtig om te gaan met het draaien van ypserv in een multi-server domein waar de server machines ook NIS-cliënten zijn. Het is in het algemeen verstandiger om de servers te dwingen met zichzelf te binden dan ze toe te staan een bindverzoek te broadcasten en het risico te lopen dat ze een binding met elkaar maken. Er kunnen vreemde fouten optreden als een van de servers plat gaat als er andere servers van die server afhankelijk zijn. Na verloop van tijd treedt op de cliënten wel een timeout op en verbinden ze met een andere server, maar de daarmee gepaard gaande vertraging kan aanzienlijk zijn en de foutmodus is nog steeds van toepassing, omdat de servers dan toch weer opnieuw een verbinding met elkaar kunnen vinden. Het is mogelijk een host aan een specifieke server te binden door aan ypbind de vlag mee te geven. Om dit niet iedere keer handmatig na een herstart te hoeven uitvoeren, kan de volgende regel worden opgenomen in /etc/rc.conf van de NIS-server: nis_client_enable="YES" # start ook het cliënt gedeelte nis_client_flags="-S NIS domain,server" In &man.ypbind.8; staat meer informatie. Wachtwoordformaten NIS wachtwoordformaten Een van de meest voorkomende problemen bij het implementeren van NIS is de compatibiliteit van het wachtwoordformaat. Als een NIS-server wachtwoorden gebruikt die met DES gecodeerd zijn, dan kunnen alleen cliënten die ook DES gebruiken ondersteund worden. Als er bijvoorbeeld &solaris; NIS-cliënten in een netwerk zijn, dan moet er vrijwel zeker gebruik gemaakt worden van met DES gecodeerde wachtwoorden. Van welk formaat cliënten en servers gebruik maken is te zien in /etc/login.conf. Als een host gebruik maakt van met DES gecodeerde wachtwoorden, dan staat er in de klasse default een regel als de volgende: default:\ :passwd_format=des:\ :copyright=/etc/COPYRIGHT:\ [Overige regels weggelaten] Andere mogelijke waarden voor passwd_format zijn blf en md5 (respectievelijk voor Blowfish en MD5 gecodeerde wachtwoorden). Als er wijzigingen gemaakt zijn aan /etc/login.conf dan moet de login capability database herbouwd worden door het volgende commando als root uit te voeren: &prompt.root; cap_mkdb /etc/login.conf Het formaat van de wachtwoorden die al in /etc/master.passwd staan worden niet bijgewerkt totdat een gebruiker zijn wachtwoord voor de eerste keer wijzigt nadat de login capability database is herbouwd. Om te zorgen dat de wachtwoorden in het gekozen formaat zijn gecodeerd, moet daarna gecontroleerd worden of de waarde crypt_default in /etc/auth.conf de voorkeur geeft aan het gekozen formaat. Om dat te realiseren dient het gekozen formaat vooraan gezet te worden in de lijst. Als er bijvoorbeeld gebruik gemaakt wordt van DES gecodeerde wachtwoorden, dan hoort de regel er als volgt uit te zien: crypt_default = des blf md5 Als de bovenstaande stappen op alle &os; gebaseerde NIS-servers en cliënten zijn uitgevoerd, dan is het zeker dat ze het allemaal eens zijn over welk wachtwoordformaat er op het netwerk wordt gebruikt. Als er problemen zijn bij de authenticatie op een NIS-cliënt, dan is dit een prima startpunt voor het uitzoeken waar de problemen vandaan komen. Nogmaals: als er een NIS-server in een heterogene omgeving wordt geplaatst, dan is het waarschijnlijk dat er gebruik gemaakt moet worden van DES op alle systemen, omdat dat de laagst overeenkomende standaard is. Greg Sutter Geschreven door Automatisch netwerk instellen (DHCP) Wat is DHCP? Dynamic Host Configuration Protocol DHCP Internet Systems Consortium (ISC) DHCP, het Dynamic Host Configuration Protocol, schrijft voor hoe een systeem verbinding kan maken met een netwerk en hoe het de benodigde informatie kan krijgen om met dat netwerk te communiceren. &os; versies eerder dan 6.0 gebruiken de implementatie van de DHCP-cliënt van het ISC (Internet Systems Consortium), &man.dhclient.8;. Latere versies gebruiken de OpenBSD dhclient die uit OpenBSD 3.7 komt. Alle informatie over dhclient kan zowel voor de ISC als de OpenBSD DHCP-cliënt gebruikt worden. De DHCP-server zit bij de ISC-distributie. Wat behandeld wordt In dit onderdeel worden de cliëntcomponenten van de ISC en OpenBSD DHCP-cliënt en de servercomponenten van het ISC DHCP-systeem beschreven. Het programma voor de cliënt, dhclient, zit standaard in &os; en de server is beschikbaar via de port net/isc-dhcp31-server. Naast de onderstaande informatie, zijn de hulppagina's van &man.dhclient.8;, &man.dhcp-options.5; en &man.dhclient.conf.5; bruikbare bronnen. Hoe het werkt UDP Als dhclient, de DHCP-cliënt, wordt uitgevoerd op een cliëntmachine, dan begint die met het broadcasten van verzoeken om instellingeninformatie. Standaard worden deze verzoeken op UDP poort 68 gedaan. De server antwoordt op UDP 67 en geeft de cliënt een IP-adres en andere relevante netwerkinformatie, zoals een netmasker, router en DNS-servers. Al die informatie komt in de vorm van een DHCP lease en is voor een bepaalde tijd geldig (die is ingesteld door de beheerder van de DHCP-server). Op die manier kunnen IP-adressen voor cliënten die niet langer met het netwerk verbonden zijn (stale) automatisch weer ingenomen worden. DHCP-cliënten kunnen veel informatie van de server krijgen. Er staat een uitputtende lijst in &man.dhcp-options.5;. &os; integratie &os; integreert de OpenBSD of ISC DHCP-cliënt dhclient volledig (afhankelijk van de gebruikte &os; versie). Er is ondersteuning voor de DHCP-cliënt in zowel het installatieprogramma als in het basissysteem, waardoor het niet noodzakelijk is om kennis te hebben van het maken van netwerkinstellingen voor het netwerk waar een DHCP-server draait. dhclient is onderdeel van &os;-distributies sinds 3.2. sysinstall DHCP wordt ondersteund door sysinstall. Bij het instellen van een netwerkinterface binnen sysinstall is de tweede vraag: Wil je proberen de interface met DHCP in te stellen? Als het antwoord bevestigend luidt, dan wordt dhclient uitgevoerd en als dat succesvol verloopt, dan worden de netwerkinstellingen automatisch ingevuld. Voor het gebruiken van DHCP bij het opstarten van het systeem zijn twee instellingen nodig: DHCP vereisten Het apparaat bpf moet in de kernel gecompileerd zijn. Dit kan door device bpf aan het bestand met kernelinstellingen toe te voegen en de kernel te herbouwen. Meer informatie over het bouwen van een kernel staat in . Het apparaat bpf is al onderdeel van de GENERIC kernel die bij &os; zit, dus als er geen sprake is van een aangepaste kernel, dan hoeft er geen nieuwe gemaakt te worden om DHCP aan te praat te krijgen. Voor de lezer die bijzonder begaan is met beveiliging, is het belangrijk aan te geven dat bpf ook het apparaat is waardoor pakketsnuffelaars hun werk kunnen doen (hoewel ze nog steeds als root moeten draaien). bpf is noodzakelijk voor DHCP, maar als beveiliging bijzonder belangrijk is, dan hoort bpf waarschijnlijk niet in een kernel te zitten omdat de verwachting dat er in de toekomst ooit DHCP gebruikt gaat worden. In /etc/rc.conf moet het volgende worden opgenomen: ifconfig_fxp0="DHCP" fxp0 dient vervangen te worden door de juiste aanduiding van de interface die dynamisch ingesteld moet worden, zoals beschreven staat in . Als er een andere lokatie voor dhclient wordt gebruikt of als er extra parameters aan dhclient meegegeven moeten worden, dan dient ook iets als het volgende toegevoegd te worden: dhclient_program="/sbin/dhclient" dhclient_flags="" DHCP server De DHCP-server, dhcpd, zit bij de port net/isc-dhcp31-server in de Portscollectie. Deze port bevat de ISC DHCP-server en documentatie. Bestanden DHCP instellingenbestanden /etc/dhclient.conf Voor dhclient is een instellingenbestand /etc/dhclient.conf nodig. Dat bestand bevat meestal alleen maar commentaar, omdat de standaardinstellingen redelijk zinvol zijn. Dit bestand wordt beschreven in &man.dhclient.conf.5;. /sbin/dhclient dhclient is statisch gelinkt en staat in /sbin. Er staat meer informatie over dhclient in &man.dhclient.8;. /sbin/dhclient-script dhclient-script is het &os;-specifieke DHCP-cliënt instellingenscript. Het wordt beschreven in &man.dhclient-script.8;, maar het is niet nodig het te wijzigen om goed te werken. /var/db/dhclient.leases De DHCP-cliënt houdt in dit bestand een database bij van geldige leases, die naar een logboekbestand worden geschreven. In &man.dhclient.leases.5; staat een iets uitgebreidere beschrijving. Verder lezen Het DHCP-protocol staat volledig beschreven in RFC 2131. Er is nog een bron van informatie ingesteld op . Een DHCP-server installeren en instellen Wat behandeld wordt In dit onderdeel wordt beschreven hoe een &os; systeem zo ingesteld kan worden dat het opereert als DHCP-server door gebruik te maken van de ISC (Internet Systems Consortium) implementatie van de DHCP-server. De server wordt niet geleverd als deel van &os; en om deze dienst aan te bieden dient de port net/isc-dhcp31-server geïnstalleerd te worden. In staat meer informatie over de Portscollectie. DHCP-serverinstallatie DHCP installatie Om een &os; systeem in te stellen als DHCP-server moet het apparaat &man.bpf.4; in de kernel zijn opgenomen. Om dit te doen dient device bpf aan het bestand met kernelinstellingen toegevoegd te worden en dient de kernel herbouwd te worden. Meer informatie over het bouwen van kernels staat in . Het apparaat bpf is al onderdeel van de GENERIC kernel die bij &os;, dus het is meestal niet nodig om een aangepaste kernel te bouwen om DHCP aan de praat te krijgen. Het is belangrijk te vermelden dat bpf ook het apparaat is waardoor pakketsnuffelaars kunnen werken (hoewel de programma's die er gebruik van maken wel bijzondere toegang nodig hebben). bpf is verplicht voor DHCP, maar als beveiliging van belang is, dan is het waarschijnlijk niet verstandig om bpf in een kernel op te nemen alleen omdat er in de toekomst misschien ooit DHCP gebruikt gaat worden. Hierna dient het standaardbestand dhcpd.conf dat door de port net/isc-dhcp31-server is geïnstalleerd gewijzigd te worden. Standaard is dit /usr/local/etc/dhcpd.conf.sample en dit bestand dient gekopieerd te worden naar /usr/local/etc/dhcpd.conf voordat de wijzigingen worden gemaakt. De DHCP-server instellen DHCP dhcpd.conf dhcpd.conf is opgebouwd uit declaraties over subnetten en hosts en is wellicht het meest eenvoudig te beschrijven met een voorbeeld: option domain-name "example.com"; option domain-name-servers 192.168.4.100; option subnet-mask 255.255.255.0; default-lease-time 3600; max-lease-time 86400; ddns-update-style none; subnet 192.168.4.0 netmask 255.255.255.0 { range 192.168.4.129 192.168.4.254; option routers 192.168.4.1; } host mailhost { hardware ethernet 02:03:04:05:06:07; fixed-address mailhost.example.com; } Deze optie geeft het domein aan dat door cliënten als standaard zoekdomein wordt gebruikt. In &man.resolv.conf.5; staat meer over wat dat betekent. Deze optie beschrijft een door komma's gescheiden lijst met DNS-servers die de cliënt moet gebruiken. Het netmasker dat aan de cliënten wordt voorgeschreven. Een cliënt kan om een bepaalde duur vragen die een lease geldig is. Anders geeft de server aan wanneer de lease vervalt (in seconden). Dit is de maximale duur voor een lease die de server toestaat. Als een cliënt vraagt om een langere lease, dan wordt die wel verstrekt, maar is de maar geldig gedurende max-lease-time seconden. Deze optie geeft aan of de DHCP-server moet proberen de DNS-server bij te werken als een lease is geaccepteerd of wordt vrijgegeven. In de ISC implementatie is deze optie verplicht. Dit geeft aan welke IP-adressen in de groep met adressen zitten die zijn gereserveerd om uitgegeven te worden aan cliënten. Alle IP-adressen tussen de aangegeven adressen en die adressen zelf worden aan cliënten uitgegeven. Geeft de default gateway aan die aan de cliënten wordt voorgeschreven. Het hardware MAC-adres van een host, zodat de DHCP-server een host kan herkennen als die een verzoek doet. Geeft een host aan die altijd hetzelfde IP-adres moet krijgen. Hier kan een hostnaam gebruikt worden, omdat de DHCP-server de hostnaam zelf opzoekt voordat de lease-informatie terug wordt gegeven. Wanneer u klaar bent met het schrijven van uw dhcpd.conf, dient u de DHCP-server in /etc/rc.conf aan te zetten, door het volgende toe te voegen: dhcpd_enable="YES" dhcpd_ifaces="dc0" Vervang de interfacenaam dc0 door de interface (of interfaces, gescheiden door witruimtes) waarop uw DHCP-server moet luisteren naar DHCP-verzoeken van cliënten. Daarna kunt u doorgaan met het starten van de server door het volgende commando te geven: &prompt.root; /usr/local/etc/rc.d/isc-dhcpd start Als er later wijzigingen in de instellingen gemaakt moeten worden, dan is het belangrijk te onthouden dat het sturen van een SIGHUP signaal naar dhcpd niet resulteert in het opnieuw laden van de instellingen, zoals voor de meeste daemons geldt. Voor deze daemon dient een signaal SIGTERM gestuurd te worden om het proces te stoppen. Daarna dient de daemon met het hiervoor beschreven commando weer gestart worden. Bestanden DHCP instellingenbestanden /usr/local/sbin/dhcpd dhcpd is statisch gelinkt en staat in /usr/local/sbin. In de hulppagina voor &man.dhcpd.8; die meekomt met de port staat meer informatie over dhcpd. /usr/local/etc/dhcpd.conf dhcpd heeft een instellingenbestand, /usr/local/etc/dhcpd.conf, nodig voordat de daemon diensten aan cliënten kan leveren. Het bestand moet alle informatie bevatten die aan cliënten gegeven moet worden en de informatie die nodig is voor het draaien van de dienst. Dit instellingenbestand staat beschreven in de hulppagina voor &man.dhcpd.conf.5; die meekomt met de port. /var/db/dhcpd.leases De DHCP-server houdt in dit bestand een database bij met leases die zijn uitgegeven en die naar een logboek worden geschreven. In de hulppagina &man.dhcpd.leases.5; die bij de port zit wordt dit uitvoeriger beschreven. /usr/local/sbin/dhcrelay dhcrelay wordt in uitgebreidere omgevingen gebruikt waar de ene DHCP-server een verzoek van een cliënt naar een andere DHCP-server op een ander netwerk doorstuurt. Als deze functionaliteit nodig is, kan die beschikbaar komen door de port net/isc-dhcp31-relay te installeren. De hulppagina voor &man.dhcrelay.8; die bij de port zit bevat meer details. Chern Lee Geschreven door Tom Rhodes Daniel Gerzo Domeinnaamsysteem (<acronym>DNS</acronym>) Overzicht BIND &os; gebruikt standaard een versie van BIND (Berkeley Internet Name Domain), wat de meest gebruikte implementatie van het DNS-protocol is. DNS is het protocol waarmee namen aan IP-adressen gebonden worden en vice versa. Zo wordt bijvoorbeeld op een zoekopdracht voor www.FreeBSD.org geantwoord met het IP-adres van de webserver van het &os; Project en op een zoekopdracht voor ftp.FreeBSD.org wordt geantwoord met het IP-adres van de bijbehorende FTP-machine. Het tegenovergestelde kan ook gebeuren. Een zoekopdracht voor een IP-adres kan de bijbehorende hostnaam opleveren. Het is niet nodig om een naamserver te draaien om op een systeem zoekopdrachten met DNS uit te voeren. &os; wordt momenteel standaard geleverd met de BIND9 DNS-serversoftware. Onze installatie biedt verbeterde beveilingsmogelijkheden, een nieuwe indeling van het bestandssysteem en geautomatiseerde configuratie van &man.chroot.8;. DNS DNS wordt op Internet onderhouden door een enigszins complex systeem van autoritaire root, Top Level Domain (TLD), en andere kleinschaligere naamservers die individuele domeininformatie hosten en cachen. Op dit moment wordt BIND beheerd door het Internet Systems Consortium . Terminologie Om dit document te begrijpen moeten een aantal termen gerelateerd aan DNS begrepen worden. resolver reverse DNS root zone Term Definitie Voorwaartse DNS Het afbeelden van hostnamen op IP-adressen. Herkomst (origin) Verwijst naar het domein dat door een bepaald zonebestand wordt gedekt. named, BIND Vaak gebruikte namen voor het naamserverpakket BIND in &os;. Resolver Een systeemproces waarmee een machine zoekopdrachten om zoneinformatie aan een naamserver geeft. Reverse DNS Het afbeelden van IP-adressen op hostnamen. Rootzone Het begin van de Internet zonehiërarchie. Alle zones vallen onder de rootzone, net zoals alle bestanden in een bestandssysteem onder de rootmap vallen. Zone Een individueel domein, subdomein of een deel van de DNS die door dezelfde autoriteit wordt beheerd. zones voorbeelden Voorbeelden van zones: . is hoe de rootzone normaliter in de documentatie genoemd wordt. org. is een Top Level Domain (TLD) onder de rootzone. example.org. is een zone onder het TLD org.. 1.168.192.in-addr.arpa is een zone die naar alle IP-adressen verwijst die onder de IP-adresruimte 192.168.1.* vallen. Zoals te zien is staat het specifiekere deel van een hostnaam aan de linkerkant. Zo is bijvoorbeeld example.org. specifieker dan org. en is org. specifieker dan de rootzone. De indeling van ieder deel van een hostnaam lijkt veel op een bestandssysteem: de map /dev valt onder de root, enzovoort. Redenen om een naamserver te draaien - Naamservers bestaan in het algemeen in twee smaken: een - autoratieve naamserver en een caching naamserver. + Naamservers bestaan in het algemeen in twee smaken: autoratieve + naamservers en caching naamservers. Er is een autoratieve naamserver nodig als: Het gewenst is om DNS-informatie aan te bieden aan de wereld om met autoriteit op verzoeken te antwoorden. Een domein, zoals example.org, is geregistreerd en er IP-adressen aan hostnamen die daaronder liggen toegewezen moeten worden. Een IP-adresblok omgekeerde DNS-ingangen nodig heeft (IP naar hostnaam). Een omgekeerde of tweede naamserver, die een slaaf wordt genoemd, moet antwoorden op verzoeken. Er is een caching naamserver nodig als: Een lokale DNS-server kan cachen en wellicht sneller kan antwoorden dan een naamserver die verder weg staat. Als er een verzoek wordt gedaan voor www.FreeBSD.org, dan doet de resolver meestal een verzoek bij de naamserver van de ISP die de uplink levert en ontvangt daarop een antwoord. Met een lokale, caching DNS-server hoeft het verzoek maar één keer door de caching DNS-server naar de buitenwereld gedaan te - worden. Voor ieder volgend verzoek hoeft niet buiten het lokale - netwerk gekeken te worden omdat het al lokaal in de cache - staat. + worden. Voor aanvullende verzoeken hoeft niet buiten het lokale + netwerk te gaan omdat het al lokaal in de cache staat. Hoe het werkt De daemon BIND heet in &os; named. Bestand Beschrijving &man.named.8; De daemon BIND. &man.rndc.8; Naamserverbeheerprogramma. /etc/namedb Map waar zoneinformatie van BIND staat. /etc/namedb/named.conf Instellingenbestand van de daemon. Afhankelijk van hoe en gegeven zone op de server is geconfigureerd, staan de bestanden gerelateerd aan die zone in de submappen master, slave, of dynamic van de map /etc/namedb. Deze bestanden bevatten de DNS-informatie die door de naamserver als antwoord op zoekopdrachten gegeven zal worden. BIND starten BIND starten Omdat BIND standaard wordt geïnstalleerd, is het instellen relatief eenvoudig. De standaardconfiguratie van named is die van een eenvoudige resolverende naamserver, draaiende in een &man.chroot.8;-omgeving, en beperkt tot het luisteren op het lokale IPv4-teruglusadres (127.0.0.1). Gebruik het volgende commando om de server eenmaal met deze configuratie te starten: &prompt.root; /etc/rc.d/named onestart Om er zeker van te zijn dat de daemon named elke keer bij het opstarten gestart wordt, moet de volgende regel in /etc/rc.conf gezet worden: named_enable="YES" Het is duidelijk dat er vele instelopties voor /etc/namedb/named.conf zijn die buiten het bereik van dit document vallen. Als u echter geïnteresseerd bent in de opstartopties voor named op &os;, bekijk dan de named_*-vlaggen in /etc/defaults/rc.conf en raadpleeg de handleidingpagina &man.rc.conf.5;. De sectie is ook nuttig om te lezen. Instellingenbestanden BIND instellingenbestanden Instellingenbestanden voor named bevinden zich momenteel in /etc/namedb en moeten gewijzigd worden voor gebruik, tenzij er alleen een eenvoudige resolver nodig is. Hier vindt de meeste configuratie plaats. <filename>/etc/namedb/named.conf</filename> // $FreeBSD$ // // In de handleidingpagina's named.conf(5) en named(8), en in de // documentatie in /usr/share/doc/bind9 zijn meer details te vinden. // // Voor het opzetten van een autoratieve server is een grondig begrip // van de werking van DNS noodzakelijk. Zelfs eenvoudige fouten kunnen // de werking verstoren voor beïnvloede partijen of veel onnodig // Internetverkeer veroorzaken. options { // Relatief aan de chroot-map, indien aanwezig directory "/etc/namedb"; pid-file "/var/run/named/pid" dump-file "/var/dump/named_dump.db" statistics-file "/var/stats/named.stats" // Als named alleen als een lokale resolver gebruikt wordt, is dit een // veilige standaardinstelling. Om named toegang tot het netwerk te // verschaffen, dient deze optie gecommentarieerd te worden, het // juiste IP-adres opgegeven te worden, of dient deze optie verwijderd // te worden. listen-on { 127.0.0.1; }; // Als u IPv6 aan heeft staan op dit systeem, dient deze optie // uitgecommentarieerd te worden om als lokale resolver te dienen. Om // toegang tot het netwerk te verschaffen, dient een IPv6-adres of het // sleutelwoord "any" gegeven te worden. // listen-on-v6 { ::1; }; // Deze zones zijn reeds opgenomen door de lege zones die hieronder // staan. Als u de gerelateerde lege zones hieronder verwijdert, // dienen deze regels uitgecommentarieerd te worden. disable-empty-zone "255.255.255.255.IN-ADDR.ARPA"; disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.ARPA"; // Als er een DNS-server beschikbaar is bij een upstream provider dan // kan het IP-adres op de regel hieronder ingegeven worden en kan die // geactiveerd worden. Hierdoor wordt voordeel gehaald uit de cache, // waardoor het algehele DNS-verkeer op het Internet vermindert. /* forwarders { 127.0.0.1; }; */ // Als de 'forwarders'-clausule niet leeg is, is de standaard om "forward // first" te gebruiken, welke terug zal vallen op het versturen van een // verzoek naar uw lokale server als de naamservers in 'forwarders' het // antwoord niet weten. Als alternatief kunt u uw naamserver dwingen om // nooit zelf verzoeken in te dienen door de volgende regel aan te // zetten: // forward only; // Als u forwarding automatisch wilt configureren gebaseerd op de regels // in /etc/resolv.conf, verwijder dan het commentaar van de volgende // regel en stel named_auto_forward=yes in in /etc/rc.conf. U kunt ook // named_auto_forward_only aanzetten (het effect hiervan is hierboven // beschreven). // include "/etc/namedb/auto_forward.conf"; Zoals al in het commentaar staat kan van een cache in de uplink geprofiteerd worden als forwarders ingeschakeld worden. Onder normale omstandigheden maakt een naamserver recursief verzoeken tot het Internet op zoek naar zekere naamservers tot er een antwoord komt waar het naar op zoek is. Door de bovenstaande optie in te schakelen wordt eerst de uplink naamserver (of de opgegeven naamserver) gevraagd, waardoor er gebruik gemaakt kan worden van de cache van die server. Als die uplink naamserver een drukke, snelle naamserver is, kan het erg de moeite waard zijn om dit aan te zetten. 127.0.0.1 werkt hier niet. Verander dit IP-adres in een naamserver in de uplink. /* Moderne versies van BIND gebruiken standaard een random UDP-poort voor elk uitgaand verzoek om de kans op cache poisoning drastisch te verminderen. Alle gebruikers wordt met klem verzocht om deze mogelijkheid te gebruiken en hun firewalls overeenkomstig aan te passen. ALS EEN LAATSTE UITVLUCHT om om een beperkende firewall heen te werken kunt u proberen om onderstaande optie aan te zetten. Het gebruik van deze optie vermindert uw kans om een cache poisoning aanval te weerstaan aanzienlijk, en dient indien mogelijk te worden vermeden. Vervang NNNNN in het voorbeeld door een getal tussen 49160 en 65530. */ // query-source address * port NNNNN; }; // Als er een lokale naamserver wordt gebruikt, vergeet dan niet om // eerst 127.0.0.1 in /etc/resolv.conf te zetten zodat die gevraagd // wordt. Controleer ook dat het in /etc/rc.conf is aangezet. // Het traditionele root-hint-mechanisme. Gebruik dit OF de // onderstaande slaafzones. zone "." { type hint; file "named.root"; }; /* Het slaaf maken van de volgende zones vanaf de root-naamservers heeft een aantal aanzienlijke voordelen: 1. Snellere lokale resolutie voor uw gebruikers 2. Geen vals verkeer dat vanaf uw netwerk naar de roots wordt verzonden 3. Betere weerstand tegen elke mogelijk falen van de rootserver/DDoS Wel is het zo dat deze methode meer toezicht vraagt dan het hintbestand om er zeker van te zijn dat een onverwachte faalmodus uw server niet heeft lamgelegd. Naamservers die veel clienten serveren zullen meer voordeel uit deze aanpak halen dan individuele hosts. Met zorg gebruiken. Verwijder het commentaar uit de onderstaande regels en commentarieer de bovenstaande hintzone om dit mechanisme te gebruiken. */ zone "." { type slave; file "slave/root.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "arpa" { type slave; file "slave/arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; zone "in-addr.arpa" { type slave; file "slave/in-addr.arpa.slave"; masters { 192.5.5.241; // F.ROOT-SERVERS.NET. }; notify no; }; /* Het lokaal serveren van de volgende zones voorkomt dat enig verzoek voor deze zones uw netwerk verlaat en naar de root-naamservers gaat. Dit heeft twee aanzienlijke voordelen: 1. Snellere lokale resolutie voor uw gebruikers 2. Er zal geen vals verkeer vanaf uw netwerk naar de roots worden verzonden */ // RFC 1912 zone "localhost" { type master; file "master/localhost-forward.db"; }; zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; }; zone "255.in-addr.arpa" { type master; file "master/empty.db"; }; // RFC 1912-stijl zone voor IPv6 localhost adres zone "0.ip6.arpa" { type master; file "master/localhost-reverse.db"; }; // "Dit" netwerk (RFCs 1912 en 3330) zone "0.in-addr.arpa" { type master; file "master/empty.db"; }; // Netwerken voor privaat gebruik (RFC 1918) zone "10.in-addr.arpa" { type master; file "master/empty.db"; }; zone "16.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "17.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "18.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "19.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "20.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "21.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "22.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "23.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "24.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "25.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "26.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "27.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "28.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "29.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "30.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "31.172.in-addr.arpa" { type master; file "master/empty.db"; }; zone "168.192.in-addr.arpa" { type master; file "master/empty.db"; }; // Lokale link/APIPA (RFCs 3330 en 3927) zone "254.169.in-addr.arpa" { type master; file "master/empty.db"; }; // TEST-NET voor documentatie (RFC 3330) zone "2.0.192.in-addr.arpa" { type master; file "master/empty.db"; }; // Router benchmarken (RFC 3330) zone "18.198.in-addr.arpa" { type master; file "master/empty.db"; } zone "19.198.in-addr.arpa" { type master; file "master/empty.db"; } // Gereserveerd door IANA - oude ruimte van klasse E zone "240.in-addr.arpa" { type master; file "master/empty.db"; } zone "241.in-addr.arpa" { type master; file "master/empty.db"; } zone "242.in-addr.arpa" { type master; file "master/empty.db"; } zone "243.in-addr.arpa" { type master; file "master/empty.db"; } zone "244.in-addr.arpa" { type master; file "master/empty.db"; } zone "245.in-addr.arpa" { type master; file "master/empty.db"; } zone "246.in-addr.arpa" { type master; file "master/empty.db"; } zone "247.in-addr.arpa" { type master; file "master/empty.db"; } zone "248.in-addr.arpa" { type master; file "master/empty.db"; } zone "249.in-addr.arpa" { type master; file "master/empty.db"; } zone "250.in-addr.arpa" { type master; file "master/empty.db"; } zone "251.in-addr.arpa" { type master; file "master/empty.db"; } zone "252.in-addr.arpa" { type master; file "master/empty.db"; } zone "253.in-addr.arpa" { type master; file "master/empty.db"; } zone "254.in-addr.arpa" { type master; file "master/empty.db"; } // Niet-toegewezen IPv6-adressen (RFC 4291) zone "1.ip6.arpa" { type master; file "master/empty.db"; } zone "2.ip6.arpa" { type master; file "master/empty.db"; } zone "3.ip6.arpa" { type master; file "master/empty.db"; } zone "4.ip6.arpa" { type master; file "master/empty.db"; } zone "5.ip6.arpa" { type master; file "master/empty.db"; } zone "6.ip6.arpa" { type master; file "master/empty.db"; } zone "7.ip6.arpa" { type master; file "master/empty.db"; } zone "8.ip6.arpa" { type master; file "master/empty.db"; } zone "9.ip6.arpa" { type master; file "master/empty.db"; } zone "a.ip6.arpa" { type master; file "master/empty.db"; } zone "b.ip6.arpa" { type master; file "master/empty.db"; } zone "c.ip6.arpa" { type master; file "master/empty.db"; } zone "d.ip6.arpa" { type master; file "master/empty.db"; } zone "e.ip6.arpa" { type master; file "master/empty.db"; } zone "0.f.ip6.arpa" { type master; file "master/empty.db"; } zone "1.f.ip6.arpa" { type master; file "master/empty.db"; } zone "2.f.ip6.arpa" { type master; file "master/empty.db"; } zone "3.f.ip6.arpa" { type master; file "master/empty.db"; } zone "4.f.ip6.arpa" { type master; file "master/empty.db"; } zone "5.f.ip6.arpa" { type master; file "master/empty.db"; } zone "6.f.ip6.arpa" { type master; file "master/empty.db"; } zone "7.f.ip6.arpa" { type master; file "master/empty.db"; } zone "8.f.ip6.arpa" { type master; file "master/empty.db"; } zone "9.f.ip6.arpa" { type master; file "master/empty.db"; } zone "a.f.ip6.arpa" { type master; file "master/empty.db"; } zone "b.f.ip6.arpa" { type master; file "master/empty.db"; } zone "0.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "1.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "2.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "3.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "4.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "5.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "6.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "7.e.f.ip6.arpa" { type master; file "master/empty.db"; } // IPv6 ULA (RFC 4193) zone "c.f.ip6.arpa" { type master; file "master/empty.db"; } zone "d.f.ip6.arpa" { type master; file "master/empty.db"; } // IPv6 lokale link (RFC 4291) zone "8.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "9.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "a.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "b.e.f.ip6.arpa" { type master; file "master/empty.db"; } // IPv6 verouderde site-lokale adressen (RFC 3879) zone "c.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "d.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "e.e.f.ip6.arpa" { type master; file "master/empty.db"; } zone "f.e.f.ip6.arpa" { type master; file "master/empty.db"; } // IP6.INT is verouderd (RFC 4159) zone "ip6.int" { type master; file "master/empty.db"; } // NB: De IP-adressen hieronder zijn bedoeld als voorbeeld en dienen // niet gebruikt te worden! // // Voorbeeld instellingen voor slaafzones. Het kan handig zijn om // tenminste slaaf te worden voor de zone waar de host onderdeel van // uitmaakt. Bij uw netwerkbeheerder kan het IP-adres van de // verantwoordelijke meester-naamserver nagevraagd worden. // // Vergeet niet om de omgekeerde lookup-zone op te nemen! // Dit is genoemd na de eerste bytes van het IP-adres, in omgekeerde // volgorde, met daarachter ".IN-ADDR.ARPA", of "IP6.ARPA" voor IPv6. // // Het is van groot belang om de werking van DNS en BIND te begrijpen // voordat er een meester-zone wordt opgezet. Er zijn nogal wat // onverwachte valkuilen. Het opzetten van een slaafzone is // gewoonlijk eenvoudiger. // // NB: Zet de onderstaande voorbeelden niet blindelings aan. :-) // Gebruik in plaats hiervan echte namen en adressen. /* Een voorbeeld van een dynamische zone key "exampleorgkey" { algorithm hmac-md5; secret "sf87HJqjkqh8ac87a02lla=="; }; zone "example.org" { type master; allow-update { key "exampleorgkey"; }; file "dynamic/example.org"; }; */ /* Voorbeeld van een omgekeerde slaafzone zone "1.168.192.in-addr.arpa" { type slave; file "slave/1.168.192.in-addr.arpa"; masters { 192.168.1.1; }; }; */ In named.conf zijn dit voorbeelden van slaafregels voor een voorwaartse en een omgekeerde zone. Voor iedere nieuwe zone die wordt aangeboden dient een nieuwe instelling voor de zone aan named.conf toegevoegd te worden. De eenvoudigste instelling voor de zone example.org kan er als volgt uitzien: zone "example.org" { type master; file "master/example.org"; }; De zone is een master, zoals aangegeven door het statement , waarvan de zoneinformatie in /etc/namedb/example.org staat, zoals het statement aangeeft. zone "example.org" { type slave; file "slave/example.org"; }; In het geval van de slaaf wordt de zoneinformatie voor een zone overgedragen van de master naamserver en opgeslagen in het ingestelde bestand. Als de masterserver het niet meer doet of niet bereikbaar is, dan heeft de slaveserver de overgedragen zoneinformatie nog en kan het die aanbieden. Zonebestanden BIND zonebestanden Een voorbeeldbestand voor een masterzone voor example.org (bestaande binnen /etc/namedb/master/example.org) ziet er als volgt uit: $TTL 3600 ; 1 uur standaard TTL example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serienummer 10800 ; Verversen 3600 ; Opnieuw proberen 604800 ; Verlopen 300 ; Negatieve antwoord-TTL ) ; DNS Servers IN NS ns1.example.org. IN NS ns2.example.org. ; MX Records IN MX 10 mx.example.org. IN MX 20 mail.example.org. IN A 192.168.1.1 ; Machinenamen localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mail IN A 192.168.1.4 mx IN A 192.168.1.5 ; Aliases www IN CNAME example.org. Iedere hostnaam die eindigt op een . is een exacte hostnaam, terwijl alles zonder een . op het einde relatief is aan de oorsprong. Zo wordt ns1 bijvoorbeeld vertaald naar ns1.example.org.. De regels in een zonebestand volgen de volgende opmaak: recordnaam IN recordtype waarde DNS records De meest gebruikte DNS-records: SOA begin van autoriteit (start of authority) NS een bevoegde (autoratieve) name server A een hostadres CNAME de canonieke naam voor een alias MX mail exchanger PTR een domeinnaam pointer (gebruikt in omgekeerde DNS) example.org. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serienummer 10800 ; Ververs na 3 uur 3600 ; Opnieuw proberen na 1 uur 604800 ; Verlopen na 1 week 300 ; Negatieve antwoord-TTL example.org. de domeinnaam, ook de oorsprong voor dit zonebestand. ns1.example.org. de primaire/bevoegde naamserver voor deze zone. admin.example.org. de persoon die verantwoordelijk is voor deze zone, emailadres met @ vervangen. admin@example.org wordt admin.example.org. 2006051501 het serienummer van het bestand. Dit moet iedere keer als het zonebestand wordt aangepast opgehoogd worden. Tegenwoordig geven veel beheerders de voorkeur aan de opmaak yyyymmddrr voor het serienummer. 2006051501 betekent dan dat het voor het laatst is aangepast op 15–05–2006, de laatste 01 betekent dat het zonebestand die dag voor het eerst is aangepast. Het serienummer is belangrijk omdat het slaafnaamservers aangeeft dat een zone is bijgewerkt. IN NS ns1.example.org. Hierboven staat een NS-regel. Voor iedere naamserver die bevoegde antwoorden moet geven voor de zone hoort er zo'n regel te zijn. localhost IN A 127.0.0.1 ns1 IN A 192.168.1.2 ns2 IN A 192.168.1.3 mx IN A 192.168.1.4 mail IN A 192.168.1.5 Een A-record geeft een machinenaam aan. Hierboven is te zien dat ns1.example.org zou resolven naar 192.168.1.2. IN A 192.168.1.1 Deze regel kent IP-adres 192.168.1.1 toe aan de huidige oorsprong, in dit geval example.org. www IN CNAME @ Een canoniek naamrecord wordt meestal gebruikt voor het geven van aliassen aan een machine. In het voorbeeld is www een alias naar de master machine waarvan de naam gelijk is aan de domeinnaam example.org (192.168.1.1). CNAME's kunnen nooit samen met een ander soort record voor dezelfde hostnaam gebruikt worden. MX record IN MX 10 mail.example.org. MX records geven aan welke mailservers verantwoordelijk zijn voor het afhandelen van inkomende mail voor de zone. mail.example.org is de hostnaam - voor de mailserver en 10 is de prioriteit voor die - mailserver. + van een mailserver en 10 is de prioriteit voor die mailserver. Het is mogelijk meerdere mailservers in te stellen met prioriteiten 10, 20, enzovoorts. Een mailserver die probeert mail af te leveren voor example.org probeert dat eerst bij de MX met de hoogste prioriteit (het record met het laagste prioriteitsnummer), daarna de tweede hoogste, enzovoort, totdat de mail afgeleverd kan worden. Voor in-addr.arpa zonebestanden (omgekeerd DNS) wordt dezelfde opmaak gebruikt, maar dan met PTR-regels in plaats van A of CNAME. $TTL 3600 1.168.192.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 2006051501 ; Serienummer 10800 ; Ververs 3600 ; Opnieuw proberen 604800 ; Verlopen 300 ) ; Negatieve antwoord-TTL IN NS ns1.example.org. IN NS ns2.example.org. 1 IN PTR example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 4 IN PTR mx.example.org. 5 IN PTR mail.example.org. Dit bestand geeft de juiste IP-adressen voor hostnamen in het voorbeelddomein hierboven. Het is het vernoemen waard dat alle namen aan de rechterkant van een PTR-record volledig gekwalificeerd dienen te zijn (i.e. met een . eindigen). Caching naamserver BIND caching naamserver Een caching naamserver is een naamserver wiens primaire rol het oplossen van recursieve verzoeken is. Het dient simpelweg zelf verzoeken in en onthoudt de antwoorden voor later gebruik. Beveiliging Hoewel BIND de meest gebruikte implementatie van DNS is, is er altijd nog het beveiligingsvraagstuk. Soms worden er mogelijke en te misbruiken beveiligingsgaten gevonden. Hoewel &os; named automatisch in een &man.chroot.8;-omgeving plaatst; zijn er verschillende andere beveiligingsmechanismen actief die zouden kunnen helpen om mogelijke aanvallen op de DNS-dienst af te wenden. Het is altijd verstandig om de CERT beveiligingswaarschuwingen te lezen en een abonnement te nemen op de &a.security-notifications; om bij te blijven met de beveiligingsproblemen wat betreft Internet en &os;. Als er problemen ontstaan, kan het bijwerken van broncode en het opnieuw bouwen van named - geen kwaad doen. + hulp bieden. Verder lezen BIND/named hulppagina's: &man.rndc.8;, &man.named.8;, &man.named.conf.5; Officiële ISC BIND pagina Officieel ISC BIND Forum O'Reilly DNS en BIND 5e Editie RFC1034 - Domeinnamen - Concepten en Faciliteiten RFC1035 - Domeinnamen - Implementatie en Specificatie Murray Stokely Geschreven door Apache HTTP server webservers opzetten Apache Overzicht &os; wordt gebruikt om een paar van de drukste websites ter wereld te draaien. De meeste webservers op Internet maken gebruik van de Apache HTTP Server. Apache softwarepakketten staan op de &os; installatiemedia. Als Apache niet bij de oorspronkelijke installatie van &os; is meegeïnstalleerd, dan kan dat vanuit de port www/apache13 of www/apache22. Als Apache succesvol is geïnstalleerd, moeten er instellingen gemaakt worden. In dit onderdeel wordt versie 1.3.X van de Apache HTTP Server behandeld omdat die het meest gebruikt wordt op &os;. Apache 2.X biedt veel nieuwe mogelijkheden, maar wordt hier niet beschreven. Meer informatie over Apache 2.X is te vinden op . Instellen Apache configuratiebestand Het belangrijkste bestand met instellingen voor de Apache HTTP Server op &os; is /usr/local/etc/apache/httpd.conf. Dit bestand is een typisch &unix; tekstgebaseerd instellingenbestand waarin regels met commentaar beginnen met het karakter #. Het uitputtend beschrijven van alle mogelijke instellingen valt buiten het bereik van dit boek, dus worden alleen de meest gebruikte directieven beschreven. ServerRoot "/usr/local" Hierin wordt de standaard mappenhiërarchie voor de Apache installatie aangegeven. Binaire bestanden staan in de submappen bin en sbin van de serverroot en bestanden met instellingen staan in etc/apache. ServerAdmin beheerder@beheer.adres Het adres waaraan problemen met de server gemaild kunnen worden. Dit adres verschijnt op een aantal door de server gegenereerde pagina's, zoals documenten met foutmeldingen. ServerName www.example.com Met ServerName kan een hostnaam ingesteld worden die wordt teruggezonden aan de cliënten als de naam van de server anders is dan die is ingesteld (gebruik bijvoorbeeld www in plaats van de echte hostnaam). DocumentRoot "/usr/local/www/data" DocumentRoot: de map waaruit de documenten worden geserveerd. Standaard worden alle verzoeken uit deze map gehaald, maar er kunnen symbolische links en aliassen gebruikt worden om naar andere locaties te wijzen. Het is altijd een goed idee om reservekopieën te maken van het instellingenbestand voor Apache vóór het maken van wijzigingen. Als de juiste instellingen gemaakt zijn, kan Apache gestart worden. <application>Apache</application> draaien Apache starten of stoppen Apache draait niet vanuit de inetd super server zoals veel andere netwerkdiensten. Hij is ingesteld om zelfstandig te draaien vanwege beter prestaties voor het afhandelen van inkomende HTTP-verzoeken van webbrowsers van cliënten. Er wordt een shellscriptwrapper bijgeleverd om het starten, stoppen en herstarten zo eenvoudig mogelijk te maken. Het volgende commando start Apache voor de eerste keer: &prompt.root; /usr/local/sbin/apachectl start De server kan op iedere moment gestopt worden met: &prompt.root; /usr/local/sbin/apachectl stop Na het maken van wijzigingen aan het instellingenbestand moet de dienst herstart worden: &prompt.root; /usr/local/sbin/apachectl restart Om Apache te herstarten zonder bestaande connecties te verbreken: &prompt.root; /usr/local/sbin/apachectl graceful In &man.apachectl.8; staat meer informatie. Om Apache met het systeem mee te starten kan de volgende regel aan /etc/rc.conf worden toegevoegd: apache_enable="YES" of voor Apache 2.2: apache22_enable="YES" Als het nodig is additionele commandoregelopties op te geven voor de Apache httpd bij het opstarten, dan kunnen die in de volgende regel in rc.conf meegegeven worden: apache_flags="" Nu de webserver draait, is die te benaderen door een webbrowser te wijzen naar http://localhost/. De standaard webpagina is /usr/local/www/data/index.html. Virtuele hosting Apache ondersteunt twee verschillende manieren van Virtuele Hosting. De eerste methode is Naamgebaseerde Virtuele Hosting. Naamgebaseerde Virtuele Hosting gebruikt de HTTP/1.1 headers van de cliënten om de hostnaam uit te zoeken. Hierdoor kunnen meerdere domeinen hetzelfde IP-adres delen. Om Apache gebruik te laten maken van Naamgebaseerde Virtuele Hosting kan een regel als de volgende in httpd.conf worden opgenomen: NameVirtualHost * Als een webserver www.domein.tld heet en er moet een virtueel domein voor www.anderdomein.tld gaan draaien, dan kunnen de volgende regels aan httpd.conf worden toegevoegd: <VirtualHost *> ServerName www.domein.tld DocumentRoot /www/domein.tld </VirtualHost> <VirtualHost *> ServerName www.anderdomein.tld DocumentRoot /www/anderdomein.tld </VirtualHost> De adressen en de paden uit dit voorbeeld kunnen in echte implementaties uiteraard gewijzigd worden. Meer informatie over het opzetten van virtuele hosts staat in de officiële documentatie voor Apache op Apache modules Apache modules Er zijn veel verschillende Apache modules die functionaliteit toevoegen aan de basisdienst. De &os; Portscollectie biedt op een eenvoudige manier de mogelijkheid om Apache samen met de meeste populaire add-on modules te installeren. mod_ssl webserver veilig SSL cryptografie De module mod_ssl gebruikt de bibliotheek OpenSSL om sterke cryptografie te leveren via de protocollen Secure Sockets Layer (SSL v2/v3) en Transport Layer Security (TLS v1). Deze module levert alles wat nodig is om een getekend certificaat aan te vragen bij een vertrouwde certificaatautoriteit om een veilige webserver onder &os; te kunnen draaien. Als Apache nog niet is geïnstalleerd, dan is er een versie van Apache 1.3.X die mod_ssl bevat en geïnstalleerd kan worden met de www/apache13-modssl port. SSL-ondersteuning is ook voor Apache 2.X beschikbaar in de port www/apache22, waar het standaard is ingeschakeld. Taalbindingen Er zijn Apache-modules beschikbare voor de meeste grote scriptingtalen. Deze modules maken het typisch mogelijk om Apache-modules geheel in een scriptingtaal te schrijven. Ze worden ook vaak gebruikt als een persistente interpreter die in de server zit en die de rompslomp van het starten van een externe interpreter en de opstartvertraging voor dynamische websites vermijdt, zoals beschreven in de volgende sectie. Dynamische websites webservers dynamisch In het afgelopen decennium hebben steeds meer bedrijven zich op Internet gericht om hun omzet te verhogen en hun zichtbaarheid te vergroten. Hiermee is ook de behoefte aan interactieve webinhoud toegenomen. Hoewel sommige bedrijven zoals µsoft; oplossingen hebben geïntroduceerd voor hun eigen (propriëtaire) producten, heeft ook de open source gemeenschap een antwoord op de vraag gegeven. Moderne opties voor dynamische webinhoud zijn onder andere Django, Ruby on Rails, mod_perl, en mod_php. Django Django is een BSD-gelicenseerd raamwerk ontworpen om ontwikkelaars in staat te stellen om snel hoog presterende, elegante webapplicaties te schrijven. Het biedt een vertaling van objecten naar relaties zodat datatypes ontwikkeld kunnen worden als Python-objecten, en er een rijke dynamische databasetoegang voor die objecten kan worden geboden zonder dat de ontwikkelaar ooit SQL hoeft te schrijven. Het biedt ook een uitbreidbaar sjabloonsysteem zodat de applicatielogica is gescheiden van de HTML-presentatie. Django is afhankelijk van mod_python, Apache, en een SQL-database-engine naar keuze. De &os;-port zal al deze vereisten met de juiste vlaggen voor u installeren. Django installeren met Apache2, mod_python3, en PostgreSQL &prompt.root; cd /usr/ports/www/py-django; make all install clean -DWITH_MOD_PYTHON3 -DWITH_POSTGRESQL Als Django en deze vereisten eenmaal zijn geïnstalleerd, dient u een Django-projectmap te maken en vervolgens Apache te configureren om de ingebakken Python-interpreter te gebruiken om uw applicatie voor specifieke URL's op uw site aan te roepen. Apache-configuratie voor Django/mod_python U moet een regel aan het Apache-bestand httpd.conf toevoegen om Apache in te stellen om verzoeken voor bepaalde URL's aan uw webapplicatie door te geven: <Location "/"> SetHandler python-program PythonPath "['/map/naar/uw/django-pakketten/'] + sys.path" PythonHandler django.core.handlers.modpython SetEnv DJANGO_SETTINGS_MODULE mijnsite.settings PythonAutoReload On PythonDebug On </Location> Ruby on Rails Ruby on Rails Ruby on Rails is een ader opensource webraamwerk dat een volledige ontwikkelstack biedt en geoptimaliseerd is om webontwikkelaars productiever te maken en snel krachtige applicaties te laten ontwikkelen. Het kan eenvoudig vanuit het portssysteem geïnstalleerd worden. &prompt.root; cd /usr/ports/www/rubygem-rails; make all install clean mod_perl mod_perl Perl Het Apache/Perl integratieproject brengt de volledige kracht van de programmeertaal Perl en de Apache HTTP Server samen. Met de module mod_perl is het mogelijk om Apache-modules volledig in Perl te schrijven. Daarnaast voorkomt een ingebouwde persistente interpreter in de server de rompslomp van het starten van een externe interpreter en de nadelen van de opstarttijd van Perl. mod_perl is op een paar verschillende manieren beschikbaar. Om mod_perl te gebruiken dient herinnerd te worden dat mod_perl 1.0 alleen met Apache 1.3 werkt en dat mod_perl 2.0 alleen met Apache 2.X werkt. mod_perl 1.0 is beschikbaar in www/mod_perl en een statisch gecompileerde versie is beschikbaar in www/apache13-modperl. mod_perl 2.0 is beschikbaar in www/mod_perl2. Tom Rhodes Geschreven door mod_php mod_php PHP PHP, ook bekend als PHP: Hypertext Preprocessor, is een algemene scripttaal die bijzonder geschikt is voor webontwikkeling. Het is mogelijk de taal in te bedden in HTML en de syntaxis is afgeleid van C, &java; en Perl met de bedoeling webontwikkelaars in staat te stellen om snel dynamisch samengestelde pagina's te schrijven. Om ondersteuning voor PHP5 toe te voegen aan de Apache webserver kan eerst de port lang/php5 geïnstalleerd worden. Als de port lang/php5 voor het eerst geïnstalleerd wordt, worden automatisch de beschikbare OPTIONS weergegeven. Als er geen menu wordt weergegeven, omdat de port lang/php5 reeds in het verleden is geïnstalleerd, is het altijd mogelijk om het optiedialoog weer te laten verschijnen door &prompt.root; make config uit te voeren in de map van de port. Controleer in het optiedialoog dat de optie APACHE mod_php5 als een laadbare module voor de webserver Apache bouwt. Een heleboel sites draaien nog steeds PHP4 om verschillende redenen (compatibiliteitszaken of reeds in gebruik genomen webapplicaties). Als mod_php4 nodig is in plaats van mod_php5, gebruik dan de port lang/php4. De port lang/php4 ondersteunt een groot deel van de configuratie- en bouwopties van de port lang/php5. Hiermee worden de modules die nodig zijn voor de ondersteuning van dynamische PHP-applicaties geïnstalleerd en ingesteld. Controleer dat de volgende secties aan /usr/local/etc/apache/httpd.conf zijn toegevoegd: LoadModule php5_module libexec/apache/libphp5.so AddModule mod_php5.c <IfModule mod_php5.c> DirectoryIndex index.php index.html </IfModule> <IfModule mod_php5.c> AddType application/x-httpd-php .php AddType application/x-httpd-php-source .phps </IfModule> Na voltooiing is een eenvoudige aanroep van het commando apachectl voor een nette herstart nodig om de module PHP te laden: &prompt.root; apachectl graceful Voor toekomstig bijwerken van PHP zal het commando make config niet nodig zijn; de geselecteerde OPTIONS worden automatisch bewaard door het &os; Ports raamwerk. De ondersteuning voor PHP in &os; is extreem modulair waardoor de basisinstallatie zeer beperkt is. Het is heel gemakkelijk om ondersteuning toe te voegen door de port lang/php5-extensions te gebruiken. Deze port biedt een menugestuurde interface voor de installatie van PHP-uitbreidingen. Als alternatief kunnen individuele uitbreidingen worden geïnstalleerd door de juiste port te gebruiken. Om bijvoorbeeld ondersteuning voor de MySQL databaseserver aan PHP5 toe te voegen kan gewoonweg de port databases/php5-mysql geïnstalleerd worden: Na de installatie van een uitbreiding moet de Apache-server herladen worden om de nieuwe veranderingen in de configuratie op te pikken: &prompt.root; apachectl graceful Murray Stokely Geschreven door File Transfer Protocol (FTP) FTP servers Overzicht Het File Transfer Protocol (FTP) biedt gebruikers een eenvoudige manier om bestanden van en naar een FTP server te verplaatsen. &os; bevat FTP server software, ftpd, in het basissysteem. Hierdoor is het opzetten en beheren van een FTP server op &os; erg overzichtelijk. Instellen De belangrijkste stap bij het instellen is de beslissing welke accounts toegang krijgen tot de FTP server. Een normaal &os; systeem heeft een aantal systeemaccounts die gebruikt worden voor daemons, maar onbekende gebruikers mag niet toegestaan worden van die accounts gebruikt te maken. In /etc/ftpusers staat een lijst met gebruikers die geen FTP toegang hebben. Standaard staan daar de voorgenoemde accounts in, maar het is ook mogelijk om daar gebruikers toe te voegen die geen FTP toegang mogen hebben. Het kan ook wenselijk zijn de FTP toegang voor sommige gebruikers te beperken, maar niet onmogelijk te maken. Dit kan met /etc/ftpchroot. In dat bestand staan gebruikers en groepen waarop FTP toegangsbeperkingen van toepassing zijn. In &man.ftpchroot.5; staan alle details die hier niet beschreven zijn. FTP anoniem Om anonieme FTP toegang voor een server in te schakelen, dient er een gebruiker ftp op een &os; systeem aangemaakt te worden. Dan kunnen gebruikers op de server aanmelden met de gebruikersnaam ftp of anonymous en met ieder wachtwoord (de geldende conventie schrijft voor dat dit een emailadres van de gebruiker is). De FTP server roep bij een anonieme aanmelding &man.chroot.2; aan, zodat er alleen toegang is tot de thuismap van de gebruiker ftp. Er zijn twee tekstbestanden waarin welkomstberichten voor de FTP-cliënten gezet kunnen worden. De inhoud van /etc/ftpwelcome wordt getoond voordat gebruikers een aanmeldprompt zien. Na een succesvolle aanmelding wordt de inhoud van /etc/ftpmotd getoond. Het genoemde pad is relatief ten opzichte van de aanmeldomgeving, dus voor anonieme gebruikers wordt ~ftp/etc/ftpmotd getoond. Als een FTP server eenmaal correct is ingesteld, moet die ingeschakeld worden in /etc/inetd.conf. Daar moet het commentaarkarakter # voor de bestaande ftpd regel verwijderd worden: ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l Zoals is uitgelegd in , moet de configuratie van inetd worden herladen nadat dit instellingenbestand is gewijzigd. Details over het aanzetten van inetd op uw systeem staan in . Als alternatief kan ftpd ook gestart worden als een op zichzelf staande dienst. In dat geval volstaat het om de juiste variabele in te stellen in /etc/rc.conf: ftpd_enable="YES" Na het instellen van de bovenstaande variabele zal de op zichzelf staande server gestart worden nadat de computer opnieuw is opgestart, of het kan handmatig worden gestart door het volgende commando als root uit te voeren: &prompt.root; /etc/rc.d/ftpd start Nu kan aangemeld worden op de FTP-server met: &prompt.user; ftp localhost Beheren syslog logboekbestanden FTP De ftpd daemon gebruikt &man.syslog.3; om berichten te loggen. Standaard plaatst de systeemlogdaemon berichten over FTP in /var/log/xferlog. De lokatie van het FTP logboek kan gewijzigd worden door de volgende regels in /etc/syslog.conf te wijzigen: ftp.info /var/log/xferlog FTP anoniem Het is verstandig na te denken over de gevaren die op de loer liggen bij het draaien van een anonieme FTP server. Dat geldt in het bijzonder voor het laten uploaden ven bestanden. Het is dan goed mogelijk dat een FTP site een forum wordt om commerciële software zonder licenties uit te wisselen of erger. Als anonieme uploads toch nodig zijn, dan horen de rechten op die bestanden zo te staan dat ze niet door andere anonieme gebruikers gelezen kunnen worden tot er door een beheerder naar gekeken is. Murray Stokely Geschreven door Bestands- en printdiensten voor µsoft.windows; cliënten (Samba) Samba server Microsoft Windows bestandsserver Windows-cliënten printserver Windows-cliënten Overzicht Samba is een populair open source softwarepakket dat bestands- en printdiensten voor µsoft.windows; cliënten biedt. Die cliënten kunnen dan ruimte op een &os; bestandssysteem gebruiken alsof het een lokale schijf is en &os; printers gebruiken alsof het lokale printers zijn. Samba softwarepakketten horen op de &os; installatiemedia te staan. Als Samba bij de basisinstallatie niet mee is geïnstalleerd, dan kan dat alsnog via de net/samba3 port of met het pakket. Instellen Een standaardbestand met instellingen voor Samba wordt geïnstalleerd als /usr/local/etc/smb.conf.default. Dit bestand dient gekopieerd te worden naar /usr/local/etc/smb.conf en voordat Samba gebruikt kan worden, moeten er aanpassingen aan worden gemaakt. smb.conf bevat de instellingen voor Samba, zoals die voor de printers en de gedeelde bestandssystemen die gedeeld worden met &windows; cliënten. Het pakket Samba bevat een webgebaseerde beheermodule die swat heet, waarmee smb.conf op een eenvoudige manier ingesteld kan worden. De Samba webbeheermodule gebruiken (SWAT) De Samba Webbeheermodule (SWAT) draait als een daemon vanuit inetd. Daarom dient voor de volgende regel uit /etc/inetd.conf het commentaarkarakter verwijderd te worden voordat swat gebruikt kan worden om Samba in te stellen: swat stream tcp nowait/400 root /usr/local/sbin/swat swat Zoals is uitgelegd in , moet de configuratie van inetd worden herladen nadat dit instellingenbestand is gewijzigd. Als swat is ingeschakeld in inetd.conf, kan de module gebruikt worden door met een browser een verbinding te maken met . Er dient aangemeld te worden met het root account van het systeem. Na succesvol aanmelden op de hoofdpagina voor de Samba instellingen, is het mogelijk de systeemdocumentatie te bekijken of te starten door op het tabblad Globals te klikken. Het onderdeel Globals correspondeert met de sectie [global] in /usr/local/etc/smb.conf. Systeembrede instellingen Of Samba nu wordt ingesteld door /usr/local/etc/smb.conf direct te bewerken of met swat, de eerste instellingen die gemaakt moeten worden zijn de volgende: workgroup NT Domeinnaam of Werkgroepnaam voor de computers die verbinding gaan maken met de server. netbiosnaam NetBIOS Hiermee wordt de NetBIOS naam waaronder de Samba server bekend zal zijn ingesteld. Standaard is de naam het eerste gedeelte van de DNS-naam van een host. server string Hiermee wordt de string ingesteld die te zien is als het commando net view en een aantal andere commando's die gebruik maken van de beschrijvende tekst voor de server gebruikt worden. Beveiligingsinstellingen Twee van de belangrijkste instellingen in /usr/local/etc/smb.conf zijn het gekozen beveiligingsmodel en het wachtwoord voor cliëntgebruikers. Deze worden met de volgende instellingen gemaakt: security De twee meest gebruikte mogelijkheden hier zijn security = share en security = user. Als de cliënten gebruikersnamen hebben die overeenkomen met hun gebruikersnaam op de &os; machine, dan is het verstandig om te kiezen voor beveiliging op gebruikersniveau. Dit is het standaard beveiligingsbeleid en kent als voorwaarde dat gebruikers zich eerst moeten aanmelden voordat ze toegang krijgen tot gedeelde bronnen. Bij beveiliging op shareniveau hoeft een cliënt niet met een geldige gebruikersnaam en wachtwoord aan te melden op de server voor het mogelijk is om een verbinding te proberen te krijgen met een gedeelde bron. Dit was het standaardbeveiligingsmodel voor oudere versies van Samba. passdb backend NIS+ LDAP SQL database Samba kent aan de achterkant verschillende authenticatiemodellen. Cliënten kunnen authenticeren met LDAP, NIS+, een SQL-database of een aangepast wachtwoordbestand. De standaard authenticatiemethode is smbpasswd. Meer wordt hier niet behandeld. Als aangenomen wordt dat de standaard achterkant smbpasswd wordt gebruikt, dan moet /usr/local/private/smbpasswd gemaakt worden om Samba in staat te stellen cliënten te authenticeren. Als het gewenst is om uw &unix; gebruikersaccounts toegang te geven vanaf &windows; cliënten, gebruik dan het volgende commando: &prompt.root; smbpasswd -a gebruikersnaam Sinds Samba 3.0.23c is de eigenlijke map voor authenticatiebestanden /usr/local/etc/samba. De aanbevolen backend is nu tdbsam, en het volgende commando dient gebruikt te worden om gebruikersaccounts toe te voegen: &prompt.root; pdbedit gebruikersnaam In de Official Samba HOWTO staat meer informatie over instelopties. Met de hier gegeven basisuitleg moet het mogelijk zijn Samba draaiende te krijgen. <application>Samba</application> starten De port net/samba3 voegt een nieuw opstartscript toe, dat gebruikt kan worden om Samba te beheren. Om dit script te activeren, zodat het bijvoorbeeld gebruikt kan worden om Samba te starten, stoppen, of te herstarten, dient de volgende regel aan /etc/rc.conf toegevoegd te worden: samba_enable="YES" Of, voor fijnkorrelig beheer: nmbd_enable="YES" smbd_enable="YES" Dit stelt Samba ook in om automatisch tijdens het opstarten te starten. Vervolgens is het mogelijk om Samba op elk moment te starten door dit te typen: &prompt.root; /usr/local/etc/rc.d/samba start Starting SAMBA: removing stale tdbs : Starting nmbd. Starting smbd. Refereer aan voor meer informatie over het gebruikt van rc-scripts. Samba bestaat feitelijk uit drie afzonderlijke daemons. Het script samba start de daemons nmbd en smbd. Als de winbind naamresolutiediensten in smb.conf zijn ingeschakeld, dan start ook de daemon winbindd. Samba kan op ieder moment gestopt worden met: &prompt.root; /usr/local/etc/rc.d/samba stop Samba is een complexe softwaresuite met functionaliteit waarmee verregaande integratie met µsoft.windows; netwerken mogelijk wordt. Informatie die verder gaat dan de basisinstallatie staat op . Tom Hukins Geschreven door Tijd synchroniseren met NTP NTP Overzicht Na verloop van tijd gaat de tijd van een computer meestal uit de pas lopen. Het Netwerk Tijd Protocol (NTP) kan ervoor zorgen dat de tijd accuraat blijft. Veel diensten op Internet zijn afhankelijk, of hebben veel voordeel, van het betrouwbaar zijn van de tijd. Zo ontvangt een webserver bijvoorbeeld veel verzoeken om een bestand te sturen als dat gewijzigd is sinds een bepaald moment. In een LAN-omgeving is het van groot belang dat computers die bestanden delen van eenzelfde server gesynchroniseerde tijd hebben zodat de tijdstempels consistent blijven. Diensten zoals &man.cron.8; zijn ook afhankelijk van een betrouwbare systeemtijd om commando's op het ingestelde moment uit te voeren. NTP ntpd Bij &os; zit de &man.ntpd.8; NTP server die gebruikt kan worden om bij andere NTP servers de tijd op te vragen om de eigen klok gelijk te zetten of om de juiste tijd te verstrekken aan andere apparaten. Passende NTP-servers kiezen NTP servers kiezen Om de tijd te synchroniseren moeten er één of meer NTP-servers beschikbaar zijn. Een lokale systeembeheerder of een ISP heeft wellicht een NTP-server voor dit doel opgezet. Het is verstandig om documentatie te raadplegen en te bekijken of dat het geval is. Er is een online lijst van publiek toegankelijke NTP-servers waarop een NTP-server gezocht kan worden die in geografische zin dichtbij een te synchroniseren computer ligt. Het is belangrijk te voldoen aan het beleid voor de betreffende server en toestemming te vragen als dat in de voorwaarden staat. Het is verstandig meerdere, niet van elkaar afhankelijke, NTP-servers te kiezen voor het geval een van de servers niet langer betrouwbaar is of niet bereikbaar is. &man.ntpd.8; gebruikt de antwoorden die van andere servers ontvangen worden op intelligente wijze: betrouwbare servers krijgen voorrang boven onbetrouwbare servers. Machine instellen NTP instellen Basisinstellingen ntpdate Als het alleen de bedoeling is de tijd te synchroniseren bij het opstarten van een machine, dan kan &man.ntpdate.8; gebruikt worden. Dit kan van toepassing zijn op desktops die regelmatig herstart worden en niet echt regelmatig gesynchroniseerd hoeven te worden. Op sommige machines hoort echter &man.ntpd.8; te draaien. Het gebruik van &man.ntpdate.8; bij het opstarten is ook een goed idee voor machines waarop &man.ntpd.8; draait. De &man.ntpd.8; wijzigt de tijd geleidelijk, terwijl &man.ntpdate.8; gewoon de tijd instelt, hoe groot het verschil tussen de bestaande tijd van een machine en de correcte tijd ook is. Om &man.ntpdate.8; tijdens het opstarten in te schakelen kan ntpdate_enable="YES" aan /etc/rc.conf worden toegevoegd. Alle voor de synchronisatie te gebruiken servers moeten dan, samen met eventuele opties voor &man.ntpdate.8;, in ntpdate_flags aangegeven worden. NTP ntp.conf Algemene instellingen NTP wordt ingesteld met het bestand /etc/ntp.conf in het formaat dat beschreven staat in &man.ntp.conf.5;. Hieronder volgt een eenvoudig voorbeeld: server ntplocal.example.com prefer server timeserver.example.org server ntp2a.example.net driftfile /var/db/ntp.drift De optie server geeft aan welke servers er gebruikt moeten worden, met op elke regel een server. Als de server wordt ingesteld met het argument prefer, zoals bij ntplocal.example.com, dan krijgt die server de voorkeur boven de andere. Een antwoord van een voorkeursserver wordt genegeerd als dat significant afwijkt van de antwoorden van de andere servers. In andere gevallen wordt het gebruikt zonder rekening te houden met de andere antwoorden. Het argument prefer wordt meestal gebruikt voor NTP-servers waarvan bekend is dat ze erg betrouwbaar zijn, zoals die met speciale tijdbewakingshardware. De optie driftfile geeft aan welk bestand gebruikt wordt om de offset van de klokfrequentie van het systeem op te slaan. &man.ntpd.8; gebruikt die om automatisch te compenseren voor het natuurlijke afwijken van de tijd, zodat er zelfs bij gebrek aan externe bronnen een redelijke accurate tijdsinstelling mogelijk is. De optie driftfile geeft aan welk bestand gebruikt wordt om informatie over eerdere antwoorden van NTP-servers die gebruikt worden op te slaan. Dit bestand bevat interne informatie voor NTP. Het hoort niet door andere processen gewijzigd te worden. Toegang tot een server instellen Een NTP-server is standaard toegankelijk voor alle hosts op een netwerk. De optie restrict in /etc/ntp.conf maakt het mogelijk om aan te geven welke machines de dienst mogen benaderen. Voor het blokkeren van toegang voor alle andere machines kan de volgende regel aan /etc/ntp.conf toegevoegd worden: restrict default ignore Dit zal ook toegang van uw server naar alle servers die vermeld staan in uw lokale configuratie verhinderen. Als u uw NTP-server moet synchroniseren met een externe NTP-server, dient u deze specifieke server toe te staan. Lees de handleiding voor &man.ntp.conf.5; voor meer informatie. Om alleen machines op bijvoorbeeld het lokale netwerk toe te staan hun tijd te synchroniseren met een server, maar ze tegelijkertijd niet toe te staan om de server te draaien of de server als referentie voor synchronisatie te gebruiken, kan de volgende regel toegevoegd worden: restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap Hierboven is 192.168.1.0 een IP-adres op een LAN en 255.255.255.0 is het bijbehorende netwerkmasker. /etc/ntp.conf mag meerdere regels met restrict bevatten. Meer details staan in het onderdeel Access Control Support van &man.ntp.conf.5;. De NTP-server draaien De NTP-server kan bij het opstarten gestart worden door de regel ntpd_enable="YES" aan /etc/rc.conf toe te voegen. Om extra opties aan &man.ntpd.8; mee te geven kan de parameter ntpd_flags in /etc/rc.conf gebruikt worden. Om de server zonder een herstart van de machine te starten kan ntpd uitgevoerd worden, met toevoeging van de parameters uit ntpd_flags in /etc/rc.conf. Bijvoorbeeld: &prompt.root; ntpd -p /var/run/ntpd.pid ntpd gebruiken met een tijdelijke Internetverbinding &man.ntpd.8; heeft geen permanente verbinding met een netwerk nodig om goed te werken. Maar als er gebruik gemaakt wordt van een inbelverbinding, is het wellicht verstandig om ervoor te zorgen dat uitgaande NTP-verzoeken geen uitgaande verbinding kunnen starten. Als er gebruik gemaakt wordt van gebruikers-PPP, kunnen er filter commando's ingesteld worden in /etc/ppp/ppp.conf. Bijvoorbeeld: set filter dial 0 deny udp src eq 123 # NTP-verkeer zorgt niet voor uitbellen set filter dial 1 permit 0 0 set filter alive 0 deny udp src eq 123 # Inkomend NTP-verkeer houdt de verbinding niet open set filter alive 1 deny udp dst eq 123 # Uitgaand NTP-verkeer houdt de verbinding niet open set filter alive 2 permit 0/0 0/0 Meer details staan in de sectie PACKET FILTERING in &man.ppp.8; en in de voorbeelden in /usr/share/examples/ppp/. Sommige Internetproviders blokkeren lage poorten, waardoor NTP niet kan werken omdat er nooit een antwoord ontvangen kan worden door een machine. Meer informatie HTML-documentatie voor de NTP-server staat in /usr/share/doc/ntp/. Tom Rhodes Bijgedragen door Hosts op afstand loggen met <command>syslogd</command> Het omgaan met systeemlogs is een cruciaal aspect van zowel beveiligings- als systeembeheer. Het in de gaten houden van logbestanden van meerdere hosts kan nogal onhandelbaar worden als deze hosts over (middel)grote netwerken zijn verspreid, of wanneer ze deel zijn van verschillende soorten netwerken. In deze gevallen kan het op afstand loggen het gehele proces een stuk aangenamer maken. Het centraal loggen naar een specifieke loghost kan wat van de administratieve last van het beheren van logbestanden wegnemen. Het aggregeren, samenvoegen, en roteren van logbestanden kan op één enkele plaats worden ingesteld, door gebruik te maken van de eigen gereedschappen van &os;, zoals &man.syslogd.8; en &man.newsyslog.8;. In de volgende voorbeeldconfiguratie zal host A, genaamd logserv.example.com, loginformatie voor het plaatselijke netwerk verzamelen. Host B, genaamd logclient.example.com, zal loginformatie aan het serversysteem doorgeven. In echte configuraties hebben beide hosts degelijke voor- en terugwaartse DNS of regels in /etc/hosts nodig. Anders worden de gegevens geweigerd door de server. Configuratie van de logserver Logservers zijn machines die zijn geconfigureerd om loginformatie van hosts op afstand te accepteren. In de meeste gevallen is dit om de configuratie te vergemakkelijken, in andere gevallen kan het gewoon een beheersbeslissing zijn. Ongeacht de reden zijn er enkele eisen voordat er verder wordt gegaan. Een juist geconfigureerde logserver voldoet aan de volgende minimale eisen: De regels van de firewall staan toe dat UDP wordt doorgegeven op poort 514 van zowel de cliënt als de server; syslogd is ingesteld om berichten op afstand van cliëntmachines te accepteren; De syslogd-server en alle cliëntmachines moeten geldige regels hebben voor zowel voorwaartse als terugwaartse DNS, of correct zijn geconfigureerd in /etc/hosts. Om de logserver te configureren, moet de cliënt vermeld zijn in /etc/syslog.conf, en moet de logfaciliteit zijn gespecificeerd: +logclient.example.com *.* /var/log/logclient.log Meer informatie over de verschillende ondersteunde en beschikbare faciliteiten kan gevonden worden in de handleidingpagina &man.syslog.conf.5;. Eenmaal toegevoegd worden alle faciliteits-berichten gelogd naar het eerder gespecificeerde bestand, /var/log/logclient.log. De servermachine moet ook het volgende in /etc/rc.conf hebben staan: syslogd_enable="YES" syslogd_flags="-a logclient.example.com -vv" De eerste optie zet de daemon syslogd aan tijdens het opstarten, en de tweede regel staat toe dat gegevens van de cliënt op deze server worden geaccepteerd. Het laatste gedeelte, dat gebruikt, verhoogt de verbositeit van gelogde berichten. Dit is extreem handig voor het optimaal instellen van faciliteiten aangezien beheerders kunnen zien welk soort berichten onder welke faciliteit worden gelogd. Er kunnen meerdere opties worden gespecificeerd om logging vanuit meerdere cliënten toe te staan. IP-adressen en hele netblokken mogen ook worden gespecificeerd, bekijk de hulppagina &man.syslog.3; voor een volledige lijst van mogelijke opties. Als laatste dient het logbestand gecreëerd te worden. De gebruikte manier maakt niet uit, maar &man.touch.1; werkt prima in dit soort situaties: &prompt.root; touch /var/log/logclient.log Nu dient het syslogd-daemon herstart en geverifieerd worden: &prompt.root; /etc/rc.d/syslogd restart &prompt.root; pgrep syslog Als er een PID wordt teruggegeven, dan is de server succesvol herstart, en kan er begonnen worden met de configuratie van de cliënt. Raadpleeg de log /var/log/messages voor uitvoer als de server niet is herstart. Configuratie van de logcliënt Een logcliënt is een machine die loginformatie naar een logserver verstuurt en daarnaast lokale kopieën bewaart. Net als logservers moeten logcliënten ook aan enkele minimumeisen voldoen: &man.syslogd.8; moet zijn ingesteld om berichten van bepaalde soorten naar een logserver te sturen, die ze moet accepteren; De firewall moet UDP-pakketten doorlaten op poort 514; Zowel voorwaartse als terugwaartse DNS moeten geconfigureerd zijn of juiste regels in /etc/hosts hebben. De configuratie van cliënten is wat soepeler dan die van servers. De cliëntmachine moet de volgende regels in /etc/rc.conf hebben: syslogd_enable="YES" syslogd_flags="-s -vv" Net als eerder zullen deze regels de daemon syslogd tijdens het opstarten aanzetten, en de verbositeit van gelogde berichten verhogen. De optie voorkomt dat logs van deze cliënt vanuit andere hosts worden geaccepteerd. Faciliteiten beschrijven het systeemgedeelte waarvoor een bericht is gegenereerd. ftp en ipfw bijvoorbeeld zijn beide faciliteiten. Wanneer er logberichten worden gegenereerd voor deze twee diensten, zullen ze normaalgesproken deze twee gereedschappen in elk logbericht opnemen. Faciliteiten worden vergezeld van een prioriteit of niveau, welke wordt gebruikt om aan te geven hoe belangrijk een logbericht is. De meest voorkomende zullen warning en info zijn. Bekijk de handleidingpagina &man.syslog.3; voor een volledige lijst van beschikbare faciliteiten en prioriteiten. De logserver moet in /etc/syslog.conf van de cliënt zijn gedefinieerd. In dit geval wordt het symbool @ gebruikt om loggegevens naar een server op afstand te sturen en zou er ongeveer als de volgende regel uit moeten zien: *.* @logserv.example.com Eenmaal toegevoegd moet syslogd worden herstart zodat de veranderingen effect hebben: &prompt.root; /etc/rc.d/syslogd restart Om te testen of logberichten over het netwerk worden verzonden, wordt &man.logger.1; op de cliënt gebruikt om een bericht naar syslogd te sturen: &prompt.root; logger "Testbericht van logclient" 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. diff --git a/nl_NL.ISO8859-1/share/sgml/mailing-lists.ent b/nl_NL.ISO8859-1/share/sgml/mailing-lists.ent index d515b160da..b842246c43 100644 --- a/nl_NL.ISO8859-1/share/sgml/mailing-lists.ent +++ b/nl_NL.ISO8859-1/share/sgml/mailing-lists.ent @@ -1,519 +1,523 @@ FreeBSD lijstserver"> &a.mailman.listinfo;"> FreeBSD ACPI mailinglijst"> freebsd-acpi"> FreeBSD steun mailinglijst"> freebsd-advocacy"> FreeBSD AFS porting mailinglijst"> freebsd-afs"> FreeBSD Adaptec AIC7xxx discussies mailinglijst"> freebsd-aic7xxx"> FreeBSD Alpha porting mailinglijst"> freebsd-alpha"> FreeBSD porten naar AMD64 systemen"> freebsd-amd64"> FreeBSD aankondigingen mailinglijst"> freebsd-announce"> FreeBSD Apache mailinglijst"> freebsd-apache"> FreeBSD architectuur en ontwerp mailinglijst"> freebsd-arch"> FreeBSD ARM porting mailinglijst"> freebsd-arm"> FreeBSD ATM netwerken mailinglijst"> freebsd-atm"> FreeBSD broncode audit mailinglijst"> freebsd-audit"> FreeBSD binair updatesysteem systeem mailinglijst"> freebsd-binup"> FreeBSD Bluetooth mailinglijst"> freebsd-bluetooth"> FreeBSD bugbusters mailinglijst"> freebsd-bugbusters"> FreeBSD problem reports mailinglijst"> freebsd-bugs"> FreeBSD babbel mailinglijst"> freebsd-chat"> FreeBSD clustering mailinglijst"> freebsd-cluster"> &os.current; mailinglijst"> freebsd-current"> CTM aankondigingen"> ctm-announce"> CTM distributie van CVS bestanden"> ctm-cvs-cur"> CTM 4-STABLE src tak distributie mailinglijst"> ctm-src-4"> CTM -CURRENT src tak distributie mailinglijst"> ctm-src-cur"> CTM gebruikersdiscussie mailinglijst"> ctm-users"> FreeBSD CVS commitberichten mailinglijst"> cvs-all"> FreeBSD CVS doc commitlijst"> cvs-doc"> FreeBSD CVS ports commitlijst"> cvs-ports"> FreeBSD CVS projecten commitlijst"> cvs-projects"> FreeBSD CVS src commitlijst"> cvs-src"> FreeBSD CVSweb beheer mailinglijst"> freebsd-cvsweb"> FreeBSD gebaseerde Databases mailinglijst"> freebsd-database"> FreeBSD documentatieproject mailinglijst"> freebsd-doc"> Apparaatstuurprogramma's schrijven voor FreeBSD"> freebsd-drivers"> FreeBSD gebruikers van Eclipse IDE, hulpprogramma's, clientapplicaties en ports"> freebsd-eclipse"> FreeBSD-embedded mailinglijst"> freebsd-embedded"> FreeBSD-emulatie mailinglijst"> freebsd-emulation"> FreeBSD-eol mailinglijst"> freebsd-eol"> FreeBSD FireWire (IEEE 1394) discussion mailinglijst"> freebsd-firewire"> FreeBSD bestandssysteem project mailinglijst"> freebsd-fs"> FreeBSD gecko mailinglijst"> freebsd-gecko"> FreeBSD GEOM mailinglijst"> freebsd-geom"> FreeBSD GNOME and GNOME applications mailinglijst"> freebsd-gnome"> FreeBSD technische discussie mailinglijst"> freebsd-hackers"> FreeBSD hardware and apparatuur mailinglijst"> freebsd-hardware"> FreeBSD mirror sites mailinglijsts"> freebsd-hubs"> FreeBSD internationalisatie mailinglijst"> freebsd-i18n"> FreeBSD i386-specifieke onderwerpen mailinglijst"> freebsd-i386"> FreeBSD IA32 porting mailinglijst"> freebsd-ia32"> FreeBSD IA64 porting mailinglijst"> freebsd-ia64"> FreeBSD IPFW code mailinglijst"> freebsd-ipfw"> FreeBSD ISDN mailinglijst"> freebsd-isdn"> FreeBSD Internet service provider mailinglijst"> freebsd-isp"> FreeBSD jails mailinglijst"> freebsd-jail"> FreeBSD Java Language mailinglijst"> freebsd-java"> FreeBSD gerelateerd werk mailinglijst"> freebsd-jobs"> FreeBSD KDE/Qt en KDE applicaties mailinglijst"> freebsd-kde"> FreeBSD LFS porting mailinglijst"> freebsd-lfs"> FreeBSD libh installatie and packagingsysteem mailinglijst"> freebsd-libh"> FreeBSD MIPS porting mailinglijst"> freebsd-mips"> FreeBSD mirrorsite beheerders"> mirror-announce"> FreeBSD laptop computer mailinglijst"> freebsd-mobile"> Mono en C# applicaties op &os;"> freebsd-mono"> FreeBSD port van de Mozilla browser mailinglijst"> freebsd-mozilla"> FreeBSD multimedia mailinglijst"> freebsd-multimedia"> FreeBSD netwerken mailinglijst"> freebsd-net"> FreeBSD nieuwe gebruikers mailinglijst"> freebsd-newbies"> FreeBSD new-bus mailinglijst"> freebsd-new-bus"> FreeBSD OpenOffice mailinglijst"> freebsd-openoffice"> FreeBSD prestaties mailinglijst"> freebsd-performance"> FreeBSD Perl mailinglijst"> freebsd-perl"> FreeBSD pakketfilter mailinglijst"> freebsd-pf"> FreeBSD niet-Intel platformen porting mailinglijst"> freebsd-platforms"> FreeBSD core team beleidsbeslissingen mailinglijst"> freebsd-policy"> FreeBSD ports mailinglijst"> freebsd-ports"> FreeBSD ports bugs mailinglijst"> freebsd-ports-bugs"> FreeBSD PowerPC porting mailinglijst"> freebsd-ppc"> Technische discussie over FreeBSD op HP ProLiant serverplatforms"> freebsd-proliant"> FreeBSD Python mailinglijst"> freebsd-python"> FreeBSD Quality Assurance mailinglijst"> freebsd-qa"> FreeBSD algemene vragen mailinglijst"> freebsd-questions"> FreeBSD boot script system mailinglijst"> freebsd-rc"> FreeBSD realtime extensions mailinglijst"> freebsd-realtime"> FreeBSD Ruby mailinglijst"> freebsd-ruby"> FreeBSD SCSI subsysteem mailinglijst"> freebsd-scsi"> FreeBSD beveiliging mailinglijst"> freebsd-security"> FreeBSD beveiligingswaarschuwingen mailinglijst"> freebsd-security-notifications"> FreeBSD-small mailinglijst"> freebsd-small"> FreeBSD symmetric multiprocessing mailinglijst"> freebsd-smp"> FreeBSD SPARC porting mailinglijst"> freebsd-sparc64"> &os.stable; mailinglijst"> freebsd-stable"> FreeBSD C99 en POSIX compliance mailinglijst"> freebsd-standards"> FreeBSD sun4v porting mailinglijst"> freebsd-sun4v"> SVN-commitberichten voor de gehele src-structuur (behalve voor user en projects)"> svn-src-all"> SVN-commitberichten voor de src-structuur voor head/-current"> svn-src-head"> SVN-commitberichten voor de src-projects-structuur"> svn-src-projects"> SVN-commitberichten voor de uitgaven in de src-structuur"> svn-src-release"> SVN-commitberichten voor de uitgave- / beveiligingscommits naar de src-structuur"> svn-src-releng"> SVN-commitberichten voor alle -stable-takken van de src-structuur"> svn-src-stable"> SVN-commitberichten voor alleen de 6-stable-src-structuur"> svn-src-stable-6"> SVN-commitberichten voor alleen de 7-stable-src-structuur"> svn-src-stable-7"> SVN-commitberichten voor alleen de 8-stable-src-structuur"> svn-src-stable-8"> SVN-commitberichten van de oude stable-src-structuren"> svn-src-stable-other"> SVN-commitberichten voor de admin- / configuratiestructuur"> svn-src-svnadmin"> SVN-commitberichten voor de experimentele user-src-structuur"> svn-src-user"> SVN-commitberichten voor de structuur van het verkoperswerkgebied"> svn-src-vendor"> + +Sysinstall-ontwikkeling mailinglijst"> +freebsd-sysinstall"> + FreeBSD test mailinglijst"> freebsd-test"> FreeBSD prestaties en stabiliteit test mailinglijst"> freebsd-testing"> FreeBSD threads mailinglijst"> freebsd-threads"> FreeBSD tokenring mailinglijst"> freebsd-tokenring"> FreeBSD USB mailinglijst"> freebsd-usb"> FreeBSD gebruikersgroep coördinatie mailinglijst"> freebsd-user-groups"> FreeBSD wederverkopers pre-release coördinatie mailinglijst"> freebsd-vendors"> Discussies over verscheidene virtualizatietechnieken ondersteund door FreeBSD"> freebsd-virtualization"> Discussies over de VuXML infrastructuur"> freebsd-vuxml"> FreeBSD Werk-In-Uitvoering Status"> freebsd-wip-status"> FreeBSD Webmaster mailinglijst"> freebsd-www"> FreeBSD X11 mailinglijst"> freebsd-x11"> FreeBSD port naar Xen mailinglijst"> freebsd-xen"> bug-followup@FreeBSD.org"> majordomo@FreeBSD.org">