From owner-freebsd-doc@FreeBSD.ORG Fri Aug 22 16:10:27 2003 Return-Path: Delivered-To: freebsd-doc@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBA1216A4BF for ; Fri, 22 Aug 2003 16:10:27 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FFBD43FD7 for ; Fri, 22 Aug 2003 16:10:16 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h7MNAGUp018100 for ; Fri, 22 Aug 2003 16:10:16 -0700 (PDT) (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h7MNAGGa018099; Fri, 22 Aug 2003 16:10:16 -0700 (PDT) Resent-Date: Fri, 22 Aug 2003 16:10:16 -0700 (PDT) Resent-Message-Id: <200308222310.h7MNAGGa018099@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-doc@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Gea-Suan Lin Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D0E5C16A4C2 for ; Fri, 22 Aug 2003 16:03:17 -0700 (PDT) Received: from netnews.NCTU.edu.tw (ccreader.nctu.edu.tw [140.113.54.119]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DD5343FBD for ; Fri, 22 Aug 2003 16:03:04 -0700 (PDT) (envelope-from gslin@netnews.NCTU.edu.tw) Received: by netnews.NCTU.edu.tw (Postfix, from userid 1000) id 0528C43; Sat, 23 Aug 2003 07:03:00 +0800 (CST) Message-Id: <20030822230300.0528C43@netnews.NCTU.edu.tw> Date: Sat, 23 Aug 2003 07:03:00 +0800 (CST) From: Gea-Suan Lin To: FreeBSD-gnats-submit@FreeBSD.org X-Send-Pr-Version: 3.113 X-Mailman-Approved-At: Fri, 22 Aug 2003 16:20:42 -0700 cc: gslin@netnews.NCTU.edu.tw Subject: docs/55883: advanced-networking/chapter.sgml X-BeenThere: freebsd-doc@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Gea-Suan Lin List-Id: Documentation project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2003 23:10:28 -0000 >Number: 55883 >Category: docs >Synopsis: advanced-networking/chapter.sgml >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-doc >State: open >Quarter: >Keywords: >Date-Required: >Class: doc-bug >Submitter-Id: current-users >Arrival-Date: Fri Aug 22 16:10:15 PDT 2003 >Closed-Date: >Last-Modified: >Originator: Gea-Suan Lin >Release: FreeBSD 4.8-RELEASE-p1 i386 >Organization: >Environment: System: FreeBSD netnews.NCTU.edu.tw 4.8-RELEASE-p1 FreeBSD 4.8-RELEASE-p1 #0: Mon Aug 4 11:58:06 CST 2003 root@netnews.NCTU.edu.tw:/da0/usr.obj/da0/usr.src/sys/NETNEWS i386 >Description: IPFIREWALL_DEFAULT_TO_ACCEPT is not undocumented now. >How-To-Repeat: >Fix: --- /usr/doc/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml Mon Jul 21 21:35:50 2003 +++ chapter.sgml Sat Aug 23 07:00:11 2003 @@ -1,6773 +0,0 @@ - - - - Advanced Networking - - - Synopsis - - This chapter will cover some of the more frequently used network - services on Unix systems. We will cover how to define, setup, test and - maintain all of the network services that FreeBSD utilizes. In addition, - there have been example configuration files included throughout this - chapter for you to benefit from. - - After reading this chapter, you will know: - - - - The basics of gateways and routes. - - - - How to make FreeBSD act as a bridge. - - - - How to setup a network filesystem. - - - - How to setup network booting on a diskless machine. - - - - How to setup a network information server for sharing user - accounts. - - - - How to setup automatic network settings using DHCP. - - - - How to setup a domain name server. - - - - How to synchronize the time and date, and setup a - time server, with the NTP protocol. - - - - How to setup network address translation. - - - - How to manage the inetd daemon. - - - - How to connect two computers via PLIP. - - - - How to setup IPv6 on a FreeBSD machine. - - - - Before reading this chapter, you should: - - - - Understand the basics of the /etc/rc scripts. - - - - Be familiar with basic network terminology. - - - - - - - - - Coranth - Gryphon - Contributed by - - - - Gateways and Routes - - routing - gateway - subnet - For one machine to be able to find another over a network, - there must be a mechanism in place to describe how to get from - one to the other. This is called - routing. A route is a - defined pair of addresses: a destination and a - gateway. The pair indicates that if you are - trying to get to this destination, - communicate through this gateway. There - are three types of destinations: individual hosts, subnets, and - default. The default route is - used if none of the other routes apply. We will talk a little - bit more about default routes later on. There are also three - types of gateways: individual hosts, interfaces (also called - links), and Ethernet hardware addresses (MAC - addresses). - - - - An Example - - To illustrate different aspects of routing, we will use the - following example from netstat: - - &prompt.user; netstat -r -Routing tables - -Destination Gateway Flags Refs Use Netif Expire - -default outside-gw UGSc 37 418 ppp0 -localhost localhost UH 0 181 lo0 -test0 0:e0:b5:36:cf:4f UHLW 5 63288 ed0 77 -10.20.30.255 link#1 UHLW 1 2421 -example.com link#1 UC 0 0 -host1 0:e0:a8:37:8:1e UHLW 3 4601 lo0 -host2 0:e0:a8:37:8:1e UHLW 0 5 lo0 => -host2.example.com link#1 UC 0 0 -224 link#1 UC 0 0 - - default route - The first two lines specify the default route (which we - will cover in the next - section) and the localhost route. - - loopback device - The interface (Netif column) that this - routing table specifies to use for - localhost is lo0, - also known as the loopback device. This says to keep all - traffic for this destination internal, rather than sending it - out over the LAN, since it will only end up back where it - started. - - - Ethernet - MAC address - - The next thing that stands out are the addresses beginning - with 0:e0:. These are Ethernet - hardware addresses, which are also known as MAC addresses. - FreeBSD will automatically identify any hosts - (test0 in the example) on the local Ethernet - and add a route for that host, directly to it over the - Ethernet interface, ed0. There is - also a timeout (Expire column) associated - with this type of route, which is used if we fail to hear from - the host in a specific amount of time. When this happens, the - route to this host will be automatically deleted. These hosts - are identified using a mechanism known as RIP (Routing - Information Protocol), which figures out routes to local hosts - based upon a shortest path determination. - - subnet - FreeBSD will also add subnet routes for the local subnet (10.20.30.255 is the broadcast address for the - subnet 10.20.30, and example.com is the domain name associated - with that subnet). The designation link#1 refers - to the first Ethernet card in the machine. You will notice no - additional interface is specified for those. - - Both of these groups (local network hosts and local subnets) have - their routes automatically configured by a daemon called - routed. If this is not run, then only - routes which are statically defined (i.e. entered explicitly) will - exist. - - The host1 line refers to our host, which it - knows by Ethernet address. Since we are the sending host, FreeBSD - knows to use the loopback interface (lo0) - rather than sending it out over the Ethernet interface. - - The two host2 lines are an example of - what happens when we use an &man.ifconfig.8; alias (see the - section on Ethernet for reasons why we would do this). The - => symbol after the - lo0 interface says that not only are - we using the loopback (since this address also refers to the - local host), but specifically it is an alias. Such routes - only show up on the host that supports the alias; all other - hosts on the local network will simply have a - link#1 line for such routes. - - The final line (destination subnet 224) deals - with multicasting, which will be covered in another section. - - Finally, various attributes of each route can be seen in - the Flags column. Below is a short table - of some of these flags and their meanings: - - - - - - U - Up: The route is active. - - - - H - Host: The route destination is a single host. - - - - G - Gateway: Send anything for this destination on to this - remote system, which will figure out from there where to send - it. - - - - S - Static: This route was configured manually, not - automatically generated by the system. - - - - C - Clone: Generates a new route based upon this route for - machines we connect to. This type of route is normally used - for local networks. - - - - W - WasCloned: Indicated a route that was auto-configured - based upon a local area network (Clone) route. - - - - L - Link: Route involves references to Ethernet - hardware. - - - - - - - - Default Routes - - default route - When the local system needs to make a connection to a remote host, - it checks the routing table to determine if a known path exists. If - the remote host falls into a subnet that we know how to reach (Cloned - routes), then the system checks to see if it can connect along that - interface. - - If all known paths fail, the system has one last option: the - default route. This route is a special type of gateway - route (usually the only one present in the system), and is always - marked with a c in the flags field. For hosts on a - local area network, this gateway is set to whatever machine has a - direct connection to the outside world (whether via PPP link, - DSL, cable modem, T1, or another network interface). - - If you are configuring the default route for a machine which - itself is functioning as the gateway to the outside world, then the - default route will be the gateway machine at your Internet Service - Provider's (ISP) site. - - Let us look at an example of default routes. This is a common - configuration: - - -[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] - - - The hosts Local1 and - Local2 are at your site. - Local1 is connected to an ISP via a dial up - PPP connection. This PPP server computer is connected through - a local area network to another gateway computer through an - external interface to the ISPs Internet feed. - - The default routes for each of your machines will be: - - - - - - Host - Default Gateway - Interface - - - - - - Local2 - Local1 - Ethernet - - - - Local1 - T1-GW - PPP - - - - - - A common question is Why (or how) would we set - the T1-GW to be the default gateway for - Local1, rather than the ISP server it is - connected to?. - - Remember, since the PPP interface is using an address on the ISP's - local network for your side of the connection, routes for any other - machines on the ISP's local network will be automatically generated. - Hence, you will already know how to reach the T1-GW - machine, so there is no need for the intermediate step - of sending traffic to the ISP server. - - As a final note, it is common to use the address X.X.X.1 as the gateway address for your local - network. So (using the same example), if your local class-C address - space was 10.20.30 and your ISP was - using 10.9.9 then the default routes - would be: - - - - - - Host - Default Route - - - - - Local2 (10.20.30.2) - Local1 (10.20.30.1) - - - Local1 (10.20.30.1, 10.9.9.30) - T1-GW (10.9.9.1) - - - - - - - - Dual Homed Hosts - dual homed hosts - There is one other type of configuration that we should cover, and - that is a host that sits on two different networks. Technically, any - machine functioning as a gateway (in the example above, using a PPP - connection) counts as a dual-homed host. But the term is really only - used to refer to a machine that sits on two local-area - networks. - - In one case, the machine has two Ethernet cards, each - having an address on the separate subnets. Alternately, the - machine may only have one Ethernet card, and be using - &man.ifconfig.8; aliasing. The former is used if two - physically separate Ethernet networks are in use, the latter - if there is one physical network segment, but two logically - separate subnets. - - Either way, routing tables are set up so that each subnet knows - that this machine is the defined gateway (inbound route) to the other - subnet. This configuration, with the machine acting as a router - between the two subnets, is often used when we need to implement - packet filtering or firewall security in either or both - directions. - - If you want this machine to actually forward packets - between the two interfaces, you need to tell FreeBSD to enable - this ability. - - - - Building a Router - - router - - A network router is simply a system that forwards packets - from one interface to another. Internet standards and good - engineering practice prevent the FreeBSD Project from enabling - this by default in FreeBSD. You can enable this feature by - changing the following variable to YES in - &man.rc.conf.5;: - - gateway_enable=YES # Set to YES if this host will be a gateway - - This option will set the &man.sysctl.8; variable - net.inet.ip.forwarding to - 1. If you should need to stop routing - temporarily, you can reset this to 0 temporarily. - - Your new router will need routes to know where to send the - traffic. If your network is simple enough you can use static - routes. FreeBSD also comes with the standard BSD routing - daemon &man.routed.8;, which speaks RIP (both version 1 and - version 2) and IRDP. Support for BGP v4, OSPF v2, and other - sophisticated routing protocols is available with the - net/zebra package. - Commercial products such as gated are also available for more - complex network routing solutions. - -BGP -RIP -OSPF - - Even when FreeBSD is configured in this way, it does not - completely comply with the Internet standard requirements for - routers. It comes close enough for ordinary use, - however. - - - - Routing Propagation - routing propagation - We have already talked about how we define our routes to the - outside world, but not about how the outside world finds us. - - We already know that routing tables can be set up so that all - traffic for a particular address space (in our examples, a class-C - subnet) can be sent to a particular host on that network, which will - forward the packets inbound. - - When you get an address space assigned to your site, your service - provider will set up their routing tables so that all traffic for your - subnet will be sent down your PPP link to your site. But how do sites - across the country know to send to your ISP? - - There is a system (much like the distributed DNS information) that - keeps track of all assigned address-spaces, and defines their point of - connection to the Internet Backbone. The Backbone are - the main trunk lines that carry Internet traffic across the country, - and around the world. Each backbone machine has a copy of a master - set of tables, which direct traffic for a particular network to a - specific backbone carrier, and from there down the chain of service - providers until it reaches your network. - - It is the task of your service provider to advertise to the - backbone sites that they are the point of connection (and thus the - path inward) for your site. This is known as route - propagation. - - - - Troubleshooting - - traceroute - - Sometimes, there is a problem with routing propagation, and some - sites are unable to connect to you. Perhaps the most useful command - for trying to figure out where routing is breaking down is the - &man.traceroute.8; command. It is equally useful if you cannot seem - to make a connection to a remote machine (i.e. &man.ping.8; - fails). - - The &man.traceroute.8; command is run with the name of the remote - host you are trying to connect to. It will show the gateway hosts - along the path of the attempt, eventually either reaching the target - host, or terminating because of a lack of connection. - - For more information, see the manual page for - &man.traceroute.8;. - - - - Multicast Routing - - multicast - options MROUTING - - FreeBSD supports both multicast applications and multicast - routing natively. Multicast applications do not require any - special configuration of FreeBSD; applications will generally - run out of the box. Multicast routing - requires that support be compiled into the kernel: - - options MROUTING - - In addition, the multicast routing daemon, &man.mrouted.8; - must be configured to set up tunnels and DVMRP via - /etc/mrouted.conf. More details on - multicast configuration may be found in the man pages for - mrouted. - - - - - - - - Eric - Anderson - Written by - - - - Wireless Networking - - wireless networking - - 802.11 - wireless networking - - - - Introduction - It can be very useful to be able to use a computer without the - annoyance of having a network cable attached at all times. FreeBSD can - be used as a wireless client, and even as a wireless access - point. - - - - Wireless Modes of Operation - There are two different ways to configure 802.11 wireless devices: - BSS and IBSS. - - - BSS Mode - BSS mode is the mode that typically is used. BSS mode is - also called infrastructure mode. In this mode, a number of - wireless access points are connected to a wired network. Each - wireless network has its own name. This name is called the - SSID of the network. - - Wireless clients connect to these wireless access - points. The IEEE 802.11 standard defines the protocol that - wireless networks use to connect. A wireless client can be - tied to a specific network, when a SSID is set. A wireless - client can also attach to any network by not explicitly - setting a SSID. - - - - IBSS Mode - IBSS mode, also called ad-hoc mode, is designed for point - to point connections. There are actually two types of ad-hoc - mode. One is IBSS mode, also called ad-hoc or IEEE ad-hoc - mode. This mode is defined by the IEEE 802.11 standards. - The second is called demo ad-hoc mode or Lucent ad-hoc mode - (and sometimes, confusingly, ad-hoc mode). This is the old, - pre-802.11 ad-hoc mode and should only be used for legacy - installations. We will not cover either of the ad-hoc modes - further. - - - - - Infrastructure Mode - - Access Points - - Access points are wireless networking devices that allow - one or more wireless clients to use the device as a central - hub. When using an access point, all clients communicate - through the access point. Multiple access points are often - used to cover a complete area such as a house, business, or - park with a wireless network. - - Access points typically have multiple network - connections: the wireless card, and one or more wired Ethernet - adapters for connection to the rest of the network. - - - Access points can either be purchased prebuilt, or you - can build your own with FreeBSD and a supported wireless card. - Several vendors make wireless access points and wireless cards - with various features. - - - - Building a FreeBSD Access Point - wireless networking - access point - - - Requirements - - In order to set up a wireless access point with - FreeBSD, you need to have a compatible wireless card. - Currently, only cards with the Prism chipset are - supported. You will also need a wired network card that is - supported by FreeBSD (this should not be difficult to find, - FreeBSD supports a lot of different devices). For this - guide, we will assume you want to &man.bridge.4; all traffic - between the wireless device and the network attached to the - wired network card. - - The hostap functionality that FreeBSD uses to implement - the access point works best with certain versions of - firmware. Prism 2 cards should use firmware version 1.3.4 - or newer. Prism 2.5 and Prism 3 cards should use firmware - 1.4.9. Older versions of the firmware way or may not - function correctly. At this time, the only way to update - cards is with windows firmware update utilities available - from your card's manufacturer. - - - - Setting It Up - First, make sure your system can see the wireless card: - &prompt.root; ifconfig -a -wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 - inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 - inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 - ether 00:09:2d:2d:c9:50 - media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) - status: no carrier - ssid "" - stationname "FreeBSD Wireless node" - channel 10 authmode OPEN powersavemode OFF powersavesleep 100 - wepmode OFF weptxkey 1 - - Do not worry about the details now, just make sure it shows you - something to indicate you have a wireless card installed. - If you have trouble seeing the wireless interface, and you - are using a PC Card, you may want to check out - &man.pccardc.8; and &man.pccardd.8; manual pages for more - information. - - Next, you will need to load a module in order to get - the bridging part of FreeBSD ready for the access point. In - order to load the &man.bridge.4; module, simply run the - following command: - - &prompt.root; kldload bridge - - It should not have produced any errors when loading the - module. If it did, you may need to compile the - &man.bridge.4; code into your kernel. The Bridging section of the handbook - should be able to help you accomplish that task. - - Now that you have the bridging stuff done, we need to - tell the FreeBSD kernel which interfaces to bridge together. - We do that by using &man.sysctl.8;: - - &prompt.root; sysctl net.link.ether.bridge=1 -&prompt.root; sysctl net.link.ether.bridge_cfg="wi0 xl0" -&prompt.root; sysctl net.inet.ip.forwarding=1 - - Now it is time for the wireless card setup. - The following command will set the card into an access point: - - -&prompt.root; ifconfig wi0 ssid my_net channel 11 media DS/11Mbps mediaopt hostap up stationname "FreeBSD AP" - - - The &man.ifconfig.8; line brings the - wi0 interface up, sets its SSID to - my_net, and sets the station name to - FreeBSD AP. The sets the card into 11Mbps mode and is - needed for any to take effect. - The option places the - interface into access point mode. The option sets the 802.11b channel to use. The - &man.wicontrol.8; man page has valid channel options for - your regulatory domain. - - - Now you should have a complete functioning access point - up and running. You are encouraged to read - &man.wicontrol.8;, &man.ifconfig.8;, and &man.wi.4; for - further information. - - - It is also suggested that you read the section on encryption that follows. - - - - Status Information - Once the access point is configured and operational, - operators will want to see the clients that are associated - with the access point. At any time, the operator may type: - - &prompt.root; wicontrol -l -1 station: -00:09:b7:7b:9d:16 asid=04c0, flags=3<ASSOC,AUTH>, caps=1<ESS>, rates=f<1M,2M,5.5M,11M>, sig=38/15 - - - This shows that there's one station associated, along - with its parameters. The signal indicated should be used - as a relative indication of strength only. Its - translation to dBm or other units varies between different - firmware revisions. - - - - - Clients - - A wireless client is a system that accesses an access - point or another client directly. - - Typically, wireless clients only have one network device, - the wireless networking card. - - There are a few different ways to configure a wireless - client. These are based on the different wireless modes, - generally BSS (infrastructure mode, which requires an access - point), and IBSS (ad-hoc, or peer-to-peer mode). In our - example, we will use the most popular of the two, BSS mode, to - talk to an access point. - - - Requirements - There is only one real requirement for setting up FreeBSD as a wireless client. - You will need a wireless card that is supported by FreeBSD. - - - - Setting Up a Wireless FreeBSD Client - - You will need to know a few things about the wireless - network you are joining before you start. In this example, we - are joining a network that has a name of - my_net, and encryption turned off. - - Note: In this example, we are not using encryption, which - is a dangerous situation. In the next section, you will learn - how to turn on encryption, and why it is important to do so, - and why some encryption technologies still do not completely - protect you. - - Make sure your card is recognized by FreeBSD: - - &prompt.root; ifconfig -a -wi0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 - inet6 fe80::202:2dff:fe2d:c938%wi0 prefixlen 64 scopeid 0x7 - inet 0.0.0.0 netmask 0xff000000 broadcast 255.255.255.255 - ether 00:09:2d:2d:c9:50 - media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps) - status: no carrier - ssid "" - stationname "FreeBSD Wireless node" - channel 10 authmode OPEN powersavemode OFF powersavesleep 100 - wepmode OFF weptxkey 1 - - Now, we will set the card to the correct settings for our - network: - - &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net - - Replace 192.168.0.20 and - 255.255.255.0 with a valid IP - address and netmask on your wired network. Remember, our - access point is bridging the data between the wireless - network, and the wired network, so it will appear to the other - devices on your network that you are on the wired network just - as they are. - - Once you have done that, you should be able to ping hosts - on the wired network just as if you were connected using a - standard wired connection. - - If you are experiencing problems with your wireless - connection, check to make sure that your are associated - (connected) to the access point: - - &prompt.root; ifconfig wi0 - - should return some information, and you should see: - status: associated - - If it does not show associated, then you may be out of - range of the access point, do not have encryption on, or - possibly have a configuration problem. - - - - - - Encryption - - wireless networking - encryption - - - Encryption on a wireless network is important because you - no longer have the ability to keep the network contained in a - well protected area. Your wireless data will be broadcast - across your entire neighborhood, so anyone who cares to read it - can. This is where encryption comes in. By encrypting the - data that is sent over the airwaves, you make it much more - difficult for any interested party to grab your data right out - of the air. - - The two most common ways to encrypt the data between your - client and the access point, are WEP, and &man.ipsec.4;. - - - WEP - WEP - - WEP is an abbreviation for Wired Equivalency Protocol. - WEP is an attempt to make wireless networks as safe and secure - as a wired network. Unfortunately, it has been cracked, and is - fairly trivial to break. This also means it is not something - to rely on when it comes to encrypting sensitive data. - - It is better than nothing, so use the following to turn on - WEP on your new FreeBSD access point: - - &prompt.root; ifconfig wi0 inet up ssid my_net wepmode on wepkey 0x1234567890 media DS/11Mbps mediaopt hostap - - And you can turn on WEP on a client with this command: - - &prompt.root; ifconfig wi0 inet 192.168.0.20 netmask 255.255.255.0 ssid my_net wepmode on wepkey 0x1234567890 - - Note that you should replace the 0x1234567890 with a more unique key. - - - - - IPsec - - &man.ipsec.4; is a much more robust and powerful tool for - encrypting data across a network. This is definitely the - preferred way to encrypt wireless data over a network. You can - read more about &man.ipsec.4; security and how to implement it - in the IPsec section of the - handbook. - - - - - Tools - - There are a small number of tools available for use in - debugging and setting up your wireless network, and here we will - attempt to describe some of them and what they do. - - - The <application>bsd-airtools</application> Package - - The bsd-airtools package is a - complete toolset that includes wireless auditing tools for WEP - key cracking, access point detection, etc. - - The bsd-airtools utilities can be - installed from the net/bsd-airtools port. Information on - installing ports can be found in of the - handbook. - - The program dstumbler is the packaged - tool that allows for access point discovery and signal to noise - ratio graphing. If you are having a hard time getting your - access point up and running, dstumbler may - help you get started. - - To test your wireless network security, you may choose to - use dweputils (dwepcrack, - dwepdump and dwepkeygen) - to help you determine if WEP is the right solution to your - wireless security needs. - - - - - The <application>wicontrol</application>, <application>ancontrol</application> and <application>raycontrol</application> Utilities - - These are the tools you use to control how your wireless - card behaves on the wireless network. In the examples above, we - have chosen to use &man.wicontrol.8;, since our wireless card is - a wi0 interface. If you had a Cisco - wireless device, it would come up as - an0, and therefore you would use - &man.ancontrol.8;. - - - - - The <application>ifconfig</application> Command - ifconfig - - &man.ifconfig.8; can be used to do many of the same options - as &man.wicontrol.8;, however it does lack a few options. Check - &man.ifconfig.8; for command line parameters and options. - - - - - - - Supported Cards - - Access Points - - The only cards that are currently supported for BSS (as an - access point) mode are devices based on the Prism 2, 2.5, or 3 - chipsets. For a complete list, look at &man.wi.4;. - - - - - Clients - - Almost all 802.11b wireless cards are currently supported - under FreeBSD. Most cards based on Prism, Spectrum24, Hermes, - Aironet, and Raylink will work as a wireless network card in - IBSS (ad-hoc, peer-to-peer, and BSS) mode. - - - - - - - - - - - - - Steve - Peterson - Written by - - - - Bridging - - - Introduction - IP subnet - bridge - It is sometimes useful to divide one physical network - (such as an Ethernet segment) into two separate network - segments without having to create IP subnets and use a router - to connect the segments together. A device that connects two - networks together in this fashion is called a - bridge. A FreeBSD system with two network - interface cards can act as a bridge. - - The bridge works by learning the MAC layer addresses - (Ethernet addresses) of the devices on each of its network interfaces. - It forwards traffic between two networks only when its source and - destination are on different networks. - - In many respects, a bridge is like an Ethernet switch with very - few ports. - - - - Situations Where Bridging Is Appropriate - - There are two common situations in which a bridge is used - today. - - - High Traffic on a Segment - - Situation one is where your physical network segment is - overloaded with traffic, but you do not want for whatever reason to - subnet the network and interconnect the subnets with a - router. - - Let us consider an example of a newspaper where the Editorial and - Production departments are on the same subnetwork. The Editorial - users all use server A for file service, and the Production users - are on server B. An Ethernet is used to connect all users together, - and high loads on the network are slowing things down. - - If the Editorial users could be segregated on one - network segment and the Production users on another, the two - network segments could be connected with a bridge. Only the - network traffic destined for interfaces on the - other side of the bridge would be sent to the - other network, reducing congestion on each network - segment. - - - - Filtering/Traffic Shaping Firewall - firewall - IP Masquerading - - The second common situation is where firewall functionality is - needed without IP Masquerading (NAT). - - An example is a small company that is connected via DSL - or ISDN to their ISP. They have a 13 globally-accessible IP - addresses from their ISP and have 10 PCs on their network. - In this situation, using a router-based firewall is - difficult because of subnetting issues. - - router - DSL - ISDN - A bridge-based firewall can be configured and dropped into the - path just downstream of their DSL/ISDN router without any IP - numbering issues. - - - - - Configuring a Bridge - - - Network Interface Card Selection - - A bridge requires at least two network cards to function. - Unfortunately, not all network interface cards as of FreeBSD 4.0 - support bridging. Read &man.bridge.4; for details on the cards that - are supported. - - Install and test the two network cards before continuing. - - - - Kernel Configuration Changes - - kernel options - options BRIDGE - - - To enable kernel support for bridging, add the: - - options BRIDGE - - statement to your kernel configuration file, and rebuild your - kernel. - - - - Firewall Support - firewall - If you are planning to use the bridge as a firewall, you - will need to add the IPFIREWALL option as - well. Read for general - information on configuring the bridge as a firewall. - - If you need to allow non-IP packets (such as ARP) to flow - through the bridge, there is an undocumented firewall option that - must be set. This option is - IPFIREWALL_DEFAULT_TO_ACCEPT. Note that this - changes the default rule for the firewall to accept any packet. - Make sure you know how this changes the meaning of your ruleset - before you set it. - - - - Traffic Shaping Support - - If you want to use the bridge as a traffic shaper, you will need - to add the DUMMYNET option to your kernel - configuration. Read &man.dummynet.4; for further - information. - - - - - Enabling the Bridge - - Add the line: - - net.link.ether.bridge=1 - - to /etc/sysctl.conf to enable the bridge at - runtime, and the line: - - net.link.ether.bridge_cfg=if1,if2 - - to enable bridging on the specified interfaces (replace - if1 and - if2 with the names of your two - network interfaces). If you want the bridged packets to be - filtered by &man.ipfw.8;, you should add: - - net.link.ether.bridge_ipfw=1 - - as well. - - - - Other Information - - If you want to be able to telnet into the bridge from the network, - it is OK to assign one of the network cards an IP address. The - consensus is that assigning both cards an address is a bad - idea. - - If you have multiple bridges on your network, there cannot be more - than one path between any two workstations. Technically, this means - that there is no support for spanning tree link management. - - A bridge can add latency to your ping times, especially for - traffic from one segment to another. - - - - - - - - - Tom - Rhodes - Reorganized and enhanced by - - - - - Bill - Swingle - Written by - - - - NFS - - NFS - Among the many different filesystems that FreeBSD supports is - the Network File System, also known as NFS. - NFS allows a system to share directories and files - with others over a network. By using NFS, users and - programs can access files on remote systems almost as if they were local - files. - - Some of the most notable benefits that - NFS can provide are: - - - - Local workstations use less disk space because - commonly used data can be stored on a single machine and still - remain accessible to others over the network. - - - - There is no need for users to have separate home directories - on every network machine. Home directories could be setup on the - NFS server and made available throughout - the network. - - - - Storage devices such as floppy disks, CDROM drives, and - ZIP drives can be used by other machines on the network. - This may reduce the number of removable media drives - throughout the network. - - - - - How <acronym>NFS</acronym> Works - - NFS consists of at least two main parts: - a server and one or more clients. The client remotely accesses - the data that is stored - on the server machine. In order for this to function properly a few - processes have to be configured and running: - - In &os; 5.X, the portmap utility - has been replaced with the rpcbind utility. Thus, - in &os; 5.X the user is required to replace every instance of - portmap with rpcbind - in the forthcoming examples. - - The server has to be running the following daemons: - - NFS - server - - - portmap - - - mountd - - - nfsd - - - - - - - Daemon - Description - - - - - nfsd - The NFS daemon which services requests from - the NFS clients. - - - mountd - The NFS mount daemon which carries out - the requests that &man.nfsd.8; passes on to it. - - - portmap - The portmapper daemon - allows NFS clients to discover which port the NFS server - is using. - - - - - - The client can also run a daemon, known as - nfsiod. The - nfsiod daemon services the requests - from the NFS server. This is optional, and - improves performance, but is not required for normal and - correct operation. See the &man.nfsiod.8; manual page for - more information. - - - - - Configuring <acronym>NFS</acronym> - - NFS - configuration - - - NFS configuration is a relatively - straightforward process. The processes that need to be - running can all start at boot time with a few modifications to - your /etc/rc.conf file. - - On the NFS server, make sure that the - following options are configured in the - /etc/rc.conf file: - - portmap_enable="YES" -nfs_server_enable="YES" -mountd_flags="-r" - - mountd runs automatically whenever the - NFS server is enabled. - - On the client, make sure this option is present in - /etc/rc.conf: - - nfs_client_enable="YES" - - The /etc/exports file specifies which - filesystems NFS should export (sometimes - referred to as share). Each line in - /etc/exports specifies a filesystem to be - exported and which machines have access to that filesystem. - Along with what machines have access to that filesystem, - access options may also be specified. There are many such - options that can be used in this file but only a few will be - mentioned here. You can easily discover other options by - reading over the &man.exports.5; manual page. - - Here are a few example /etc/exports - entries: - - - NFS - export examples - - - The following examples give an idea of how to export filesystems, - although the settings may be different depending on - your environment and network configuration. - For instance, to export the /cdrom directory to - three example machines that have the same domain name as the server - (hence the lack of a domain name for each) or have entries in your - /etc/hosts file. The - flag makes the exported filesystem read-only. With this flag, the - remote system will not be able to write any changes to the - exported filesystem. - - /cdrom -ro host1 host2 host3 - - The following line exports /home to - three hosts by IP address. This is a useful setup if you have - a private network without a DNS server - configured. Optionally the /etc/hosts - file could be configured for internal hostnames; please review - &man.hosts.5; for more information. The - flag allows the subdirectories to be - mount points. In other words, it will not mount the - subdirectories but permit the client to mount only the - directories that are required or needed. - - /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 - - The following line exports /a so that - two clients from different domains may access the filesystem. - The flag allows the - root user on the remote system to write - data on the exported filesystem as root. - If the -maproot=root flag is not specified, - then even if a user has root access on - the remote system, they will not be able to modify files on - the exported filesystem. - - /a -maproot=root host.example.com box.example.org - - In order for a client to access an exported filesystem, - the client must have permission to do so. Make sure the - client is listed in your /etc/exports - file. - - In /etc/exports, each line represents - the export information for one filesystem to one host. A - remote host can only be specified once per filesystem, and may - only have one default entry. For example, assume that - /usr is a single filesystem. The - following /etc/exports would be - invalid: - - /usr/src client -/usr/ports client - - One filesystem, /usr, has two lines - specifying exports to the same host, client. - The correct format for this situation is: - - /usr/src /usr/ports client - - The properties of one filesystem exported to a given host - must all occur on one line. Lines without a client specified - are treated as a single host. This limits how you can export - filesystems, but for most people this is not an issue. - - The following is an example of a valid export list, where - /usr and /exports - are local filesystems: - - # Export src and ports to client01 and client02, but only -# client01 has root privileges on it -/usr/src /usr/ports -maproot=root client01 -/usr/src /usr/ports client02 -# The client machines have root and can mount anywhere -# on /exports. Anyone in the world can mount /exports/obj read-only -/exports -alldirs -maproot=root client01 client02 -/exports/obj -ro - - You must restart - mountd whenever you modify - /etc/exports so the changes can take effect. - This can be accomplished by sending the HUP signal - to the mountd process: - - &prompt.root; kill -HUP `cat /var/run/mountd.pid` - - Alternatively, a reboot will make FreeBSD set everything - up properly. A reboot is not necessary though. - Executing the following commands as root - should start everything up. - - On the NFS server: - - &prompt.root; portmap -&prompt.root; nfsd -u -t -n 4 -&prompt.root; mountd -r - - On the NFS client: - - &prompt.root; nfsiod -n 4 - - Now everything should be ready to actually mount a remote file - system. In these examples the - server's name will be server and the client's - name will be client. If you only want to - temporarily mount a remote filesystem or would rather test the - configuration, just execute a command like this as root on the - client: - - NFS - mounting - - &prompt.root; mount server:/home /mnt - - This will mount the /home directory - on the server at /mnt on the client. If - everything is set up correctly you should be able to enter - /mnt on the client and see all the files - that are on the server. - - If you want to automatically mount a remote filesystem - each time the computer boots, add the filesystem to the - /etc/fstab file. Here is an example: - - server:/home /mnt nfs rw 0 0 - - The &man.fstab.5; manual page lists all the available options. - - - - Practical Uses - - NFS has many practical uses. Some of the more common - ones are listed below: - - - NFS - uses - - - - Set several machines to share a CDROM or other media - among them. This is cheaper and often a more convenient - method to install software on multiple machines. - - - - On large networks, it might be more convenient to - configure a central NFS server in which - to store all the user home directories. These home - directories can then be exported to the network so that - users would always have the same home directory, - regardless of which workstation they log in to. - - - - Several machines could have a common - /usr/ports/distfiles directory. That - way, when you need to install a port on several machines, - you can quickly access the source without downloading it - on each machine. - - - - - - - - - Wylie - Stilwell - Contributed by - - - - - Chern - Lee - Rewritten by - - - - Automatic Mounts with <application>amd</application> - - amd - automatic mounter daemon - - &man.amd.8; (the automatic mounter daemon) - automatically mounts a - remote filesystem whenever a file or directory within that - filesystem is accessed. Filesystems that are inactive for a - period of time will also be automatically unmounted by - amd. Using - amd provides a simple alternative - to permanent mounts, as permanent mounts are usually listed in - /etc/fstab. - - amd operates by attaching - itself as an NFS server to the /host and - /net directories. When a file is accessed - within one of these directories, amd - looks up the corresponding remote mount and automatically mounts - it. /net is used to mount an exported - filesystem from an IP address, while /host - is used to mount an export from a remote hostname. - - An access to a file within - /host/foobar/usr would tell - amd to attempt to mount the - /usr export on the host - foobar. - - - Mounting an Export with <application>amd</application> - - You can view the available mounts of a remote host with - the showmount command. For example, to - view the mounts of a host named foobar, you - can use: - - &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 - - - As seen in the example, the showmount shows - /usr as an export. When changing directories to - /host/foobar/usr, amd - attempts to resolve the hostname foobar and - automatically mount the desired export. - - amd can be started by the - startup scripts by placing the following lines in - /etc/rc.conf: - - amd_enable="YES" - - Additionally, custom flags can be passed to - amd from the - amd_flags option. By default, - amd_flags is set to: - - amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" - - The /etc/amd.map file defines the - default options that exports are mounted with. The - /etc/amd.conf file defines some of the more - advanced features of amd. - - Consult the &man.amd.8; and &man.amd.conf.5; manual pages for more - information. - - - - - - - John - Lind - Contributed by - - - - Problems Integrating with Other Systems - - Certain Ethernet adapters for ISA PC systems have limitations - which can lead to serious network problems, particularly with NFS. - This difficulty is not specific to FreeBSD, but FreeBSD systems - are affected by it. - - The problem nearly always occurs when (FreeBSD) PC systems are - networked with high-performance workstations, such as those made - by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS - mount will work fine, and some operations may succeed, but - suddenly the server will seem to become unresponsive to the - client, even though requests to and from other systems continue to - be processed. This happens to the client system, whether the - client is the FreeBSD system or the workstation. On many systems, - there is no way to shut down the client gracefully once this - problem has manifested itself. The only solution is often to - reset the client, because the NFS situation cannot be - resolved. - - Though the correct solution is to get a higher - performance and capacity Ethernet adapter for the FreeBSD system, - there is a simple workaround that will allow satisfactory - operation. If the FreeBSD system is the - server, include the option - on the mount from the client. If the - FreeBSD system is the client, then mount the - NFS filesystem with the option . These - options may be specified using the fourth field of the - fstab entry on the client for automatic - mounts, or by using the parameter of the mount - command for manual mounts. - - It should be noted that there is a different problem, - sometimes mistaken for this one, when the NFS servers and clients - are on different networks. If that is the case, make - certain that your routers are routing the - necessary UDP information, or you will not get anywhere, no matter - what else you are doing. - - In the following examples, fastws is the host - (interface) name of a high-performance workstation, and - freebox is the host (interface) name of a FreeBSD - system with a lower-performance Ethernet adapter. Also, - /sharedfs will be the exported NFS - filesystem (see &man.exports.5;), and - /project will be the mount point on the - client for the exported filesystem. In all cases, note that - additional options, such as or - and may be desirable in - your application. - - Examples for the FreeBSD system (freebox) as - the client in /etc/fstab on freebox: - - fastws:/sharedfs /project nfs rw,-r=1024 0 0 - - As a manual mount command on freebox: - - &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project - - Examples for the FreeBSD system as the server in - /etc/fstab on fastws: - - freebox:/sharedfs /project nfs rw,-w=1024 0 0 - - As a manual mount command on fastws: - - &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project - - Nearly any 16-bit Ethernet adapter will allow operation - without the above restrictions on the read or write size. - - For anyone who cares, here is what happens when the failure - occurs, which also explains why it is unrecoverable. NFS - typically works with a block size of 8 k (though it - may do fragments of smaller sizes). Since the maximum Ethernet - packet is around 1500 bytes, the NFS block gets - split into multiple Ethernet packets, even though it is still a - single unit to the upper-level code, and must be received, - assembled, and acknowledged as a unit. The - high-performance workstations can pump out the packets which - comprise the NFS unit one right after the other, just as close - together as the standard allows. On the smaller, lower capacity - cards, the later packets overrun the earlier packets of the same - unit before they can be transferred to the host and the unit as a - whole cannot be reconstructed or acknowledged. As a result, the - workstation will time out and try again, but it will try again - with the entire 8 K unit, and the process will be repeated, ad - infinitum. - - By keeping the unit size below the Ethernet packet size - limitation, we ensure that any complete Ethernet packet received - can be acknowledged individually, avoiding the deadlock - situation. - - Overruns may still occur when a high-performance workstations - is slamming data out to a PC system, but with the better cards, - such overruns are not guaranteed on NFS units. When - an overrun occurs, the units affected will be retransmitted, and - there will be a fair chance that they will be received, assembled, - and acknowledged. - - - - - - - - Jean-François - Dockès - Updated by - - - - Diskless Operation - - diskless workstation - diskless operation - - A FreeBSD machine can boot over the network and operate without a - local disk, using filesystems mounted from an NFS server. No system - modification is necessary, beyond standard configuration files. - Such a system is easy to set up because all the necessary elements - are readily available: - - - There are at least two possible methods to load the kernel over - the network: - - - PXE: Intel's Preboot Execution - Environment system is a form of smart boot ROM built into some - networking cards or motherboards. See &man.pxeboot.8; for more - details. - - - The etherboot - port (net/etherboot) produces - ROM-able code to boot kernels over the network. The - code can be either burnt into a boot PROM on a network - card, or loaded from a local floppy (or hard) disk - drive, or from a running MS-DOS system. Many network - cards are supported. - - - - - - A sample script - (/usr/share/examples/diskless/clone_root) eases - the creation and maintenance of the workstation's root filesystem - on the server. The script will probably require a little - customization but it will get you started very quickly. - - - - Standard system startup files exist in /etc - to detect and support a diskless system startup. - - - - Swapping, if needed, can be done either to an NFS file or to - a local disk. - - - - There are many ways to set up diskless workstations. Many - elements are involved, and most can be customized to suit local - taste. The following will describe the setup of a complete system, - emphasizing simplicity and compatibility with the - standard FreeBSD startup scripts. The system described has the - following characteristics: - - - - The diskless workstations use a shared - read-only root filesystem, and a shared - read-only /usr. - The root filesystem is a copy of a - standard FreeBSD root (typically the server's), with some - configuration files overridden by ones specific to diskless - operation or, possibly, to the workstation they belong to. - The parts of the root which have to be - writable are overlaid with &man.mfs.8; filesystems. Any changes - will be lost when the system reboots. - - - The kernel is loaded by etherboot - , using DHCP (or BOOTP) and TFTP. - - - - As described, this system is insecure. It should - live in a protected area of a network, and be untrusted by - other hosts. - - - - - Setup Instructions - - - Configuring DHCP/BOOTP - - diskless operation - booting - - - There are two protocols that are commonly used to boot a - workstation that retrieves its configuration over the network: BOOTP - and DHCP. They are used at several points in the workstation - bootstrap: - - etherboot uses - DHCP (by default) or BOOTP (needs a configuration option) to - find the kernel. (PXE uses DHCP). - - The kernel uses BOOTP to locate the NFS - root. - - - - It is possible to configure a system to use only BOOTP. - The &man.bootpd.8; server program is included in the - base FreeBSD system. - - However, DHCP has a number of advantages over BOOTP (nicer - configuration files, possibility of using PXE, plus many others - not directly related to diskless operation), and we shall describe - both a pure BOOTP, and a BOOTP+DHCP configuration, with an - emphasis on the latter, which will use the ISC DHCP software - package. - - - Configuration Using ISC DHCP - - DHCP - diskless operation - - - The isc-dhcp server can answer - both BOOTP and DHCP requests. - - As of release 4.4, isc-dhcp - 3.0 is not part of the base - system. You will first need to install the - net/isc-dhcp3 port or the - corresponding package. Please refer to - for general information about ports and packages. - - Once isc-dhcp is installed, it - needs a configuration file to run, (normally named - /usr/local/etc/dhcpd.conf). Here follows - a commented example: - - - default-lease-time 600; - max-lease-time 7200; - authoritative; - - option domain-name "example.com"; - option domain-name-servers 192.168.4.1; - option routers 192.168.4.1; - - subnet 192.168.4.0 netmask 255.255.255.0 { - use-host-decl-names on; - option subnet-mask 255.255.255.0; - option broadcast-address 192.168.4.255; - - host margaux { - hardware ethernet 01:23:45:67:89:ab; - fixed-address margaux.example.com; - next-server 192.168.4.4; - filename "/tftpboot/kernel.diskless"; - option root-path "192.168.4.4:/data/misc/diskless"; - } - } - - - - This option tells - dhcpd to send the value in the - host declarations as the hostname for the - diskless host. An alternate way would be to add an - option host-name - margaux inside the - host declarations. - - - The - next-server directive designates - the TFTP server (the default is to use the same host as the - DHCP server). - - - The - filename directive defines the file that - etherboot will load as a - kernel. - PXE appears to prefer a relative file - name, and it loads pxeboot, not the - kernel (option filename - "pxeboot"). - - - - - The - root-path option defines the path to - the root filesystem, in usual NFS notation. - - - - - - Configuration Using BOOTP - - BOOTP - diskless operation - - - Here follows an equivalent bootpd - configuration. This would be found in - /etc/bootptab. - - Please note that etherboot - must be compiled with the non-default option - NO_DHCP_SUPPORT in order to use BOOTP, - and that PXE needs DHCP. The only - obvious advantage of bootpd is - that it exists in the base system. - - - .def100:\ - :hn:ht=1:sa=192.168.4.4:vm=rfc1048:\ - :sm=255.255.255.0:\ - :ds=192.168.4.1:\ - :gw=192.168.4.1:\ - :hd="/tftpboot":\ - :bf="/kernel.diskless":\ - :rp="192.168.4.4:/data/misc/diskless": - - margaux:ha=0123456789ab:tc=.def100 - - - - - - Preparing a Boot Program with - <application>Etherboot</application> - - - Etherboot - - - Etherboot's Web - site contains - - extensive documentation mainly intended for Linux - systems, but nonetheless containing useful information. The - following will just outline how you would use - etherboot on a FreeBSD - system. - - You must first install the net/etherboot package or port. - The etherboot port can normally - be found in /usr/ports/net/etherboot. - If the ports tree is installed on your system, just typing - make in this directory should take care - of everything. Else refer to for - information about ports and packages. - - For our setup, we shall use a boot floppy. For other methods - (PROM, or dos program), please refer to the - etherboot documentation. - - To make a boot floppy, insert a floppy in the drive on the - machine where you installed etherboot, - then change your current directory to the src - directory in the etherboot tree and - type: - - - &prompt.root; gmake bin32/devicetype.fd0 - - - devicetype depends on the type of - the Ethernet card in the diskless workstation. Refer to the - NIC file in the same directory to determine the - right devicetype. - - - - - - Configuring the TFTP and NFS Servers - - - TFTP - diskless operation - - - NFS - diskless operation - - - You need to enable tftpd on the TFTP - server: - - - Create a directory from which tftpd - will serve the files, i.e.: /tftpboot - - - - Add this line to your - /etc/inetd.conf: - - tftp dgram udp wait root /usr/libexec/tftpd tftpd -s /tftpboot - - It appears that at least some PXE versions want - the TCP version of TFTP. In this case, add a second line, - replacing dgram udp with stream - tcp. - - - - Tell inetd to reread its configuration - file: - &prompt.root; kill -HUP `cat /var/run/inetd.pid` - - - - You can place the tftpboot - directory anywhere on the server. Make sure that the - location is set in both inetd.conf and - dhcpd.conf. - - You also need to enable NFS and export the - appropriate filesystem on the NFS server. - - - - Add this to /etc/rc.conf: - nfs_server_enable="YES" - - - - Export the filesystem where the diskless root directory - is located by adding the following to - /etc/exports (adjust the volume mount - point and replace margaux - with the name of the diskless workstation): - - /data/misc -alldirs -ro margaux - - - Tell mountd to reread its configuration - file. If you actually needed to enable NFS in - /etc/rc.conf - at the first step, you probably want to reboot instead. - &prompt.root; kill -HUP `cat /var/run/mountd.pid` - - - - - - - Building a Diskless Kernel - - - diskless operation - kernel configuration - - - Create a kernel configuration file for the diskless client - with the following options (in addition to the usual - ones): - - - options BOOTP # Use BOOTP to obtain IP address/hostname - options BOOTP_NFSROOT # NFS mount root filesystem using BOOTP info - options BOOTP_COMPAT # Workaround for broken bootp daemons. - - - You may also want to use BOOTP_NFSV3 and - BOOTP_WIRED_TO (refer to LINT). - - Build the kernel (See ), - and copy it to the tftp directory, under the name listed - in dhcpd.conf. - - - - - - Preparing the Root Filesystem - - - root file system - diskless operation - - - You need to create a root filesystem for the diskless - workstations, in the location listed as - root-path in - dhcpd.conf. - - The easiest way to do this is to use the - /usr/share/examples/diskless/clone_root - shell script. This script needs customization, at least to adjust - the place where the filesystem will be created (the - DEST variable). - - Refer to the comments at the top of the script for - instructions. They explain how the base filesystem is built, - and how files may be selectively overridden by versions specific - to diskless operation, to a subnetwork, or to an individual - workstation. They also give examples for the diskless - /etc/fstab and - /etc/rc.conf files. - - The README files in - /usr/share/examples/diskless contain a lot - of interesting background information, but, together with the - other examples in the diskless directory, - they actually document a configuration method which is distinct - from the one used by clone_root and - /etc/rc.diskless[12], which is a little - confusing. Use them for reference only, except if you prefer - the method that they describe, in which case you will need - customized rc scripts. - - - - Configuring Swap - - If needed, a swap file located on the server can be - accessed via NFS. The exact bootptab - or dhcpd.conf options are not clearly - documented at this time. The following configuration - suggestions have been reported to work in some installations - using isc-dhcp 3.0rc11. - - Add the following lines to - dhcpd.conf: - - # Global section - option swap-path code 128 = string; - option swap-size code 129 = integer 32; - - host margaux { - ... # Standard lines, see above - option swap-path "192.168.4.4:/netswapvolume/netswap"; - option swap-size 64000; - } - - The idea is that, at least for a FreeBSD client, - DHCP/BOOTP option code 128 is the path to the NFS swap file, - and option code 129 is the swap size in kilobytes. Older - versions of dhcpd allowed a syntax of - option option-128 "..., which does not - seem to work any more. - /etc/bootptab would use the - following syntax instead: - - T128="192.168.4.4:/netswapvolume/netswap":T129=64000 - - - - - On the NFS swap file server, create the swap - file(s) - - &prompt.root; mkdir /netswapvolume/netswap - &prompt.root; cd /netswapvolume/netswap - &prompt.root; dd if=/dev/zero bs=1024 count=64000 of=swap.192.168.4.6 - &prompt.root; chmod 0600 swap.192.168.4.6 - - 192.168.4.6 is the IP address - for the diskless client. - - - - On the NFS swap file server, add the following line to - /etc/exports: - - /netswapvolume -maproot=0:10 -alldirs margaux - - Then tell mountd to reread the - exports file, as above. - - - - - - - Miscellaneous Issues - - - - Running with a Read-only <filename>/usr</filename> - - - diskless operation - /usr read-only - - - If the diskless workstation is configured to run X, you - will have to adjust the xdm configuration file, which puts - the error log on /usr by default. - - - Using a Non-FreeBSD Server - - When the server for the root filesystem is not running FreeBSD, - you will have to create the root filesystem on a - FreeBSD machine, then copy it to its destination, using - tar or cpio. - In this situation, there are sometimes - problems with the special files in /dev, - due to differing major/minor integer sizes. A solution to this - problem is to export a directory from the non-FreeBSD server, - mount this directory onto a FreeBSD machine, and run - MAKEDEV on the FreeBSD machine - to create the correct device entries (FreeBSD 5.0 and later - use &man.devfs.5; to allocate device nodes transparently for - the user, running MAKEDEV on these - versions is useless). - - - - - - - - - - ISDN - - - ISDN - - - A good resource for information on ISDN technology and hardware is - Dan Kegel's ISDN - Page. - - A quick simple road map to ISDN follows: - - - - If you live in Europe you might want to investigate the ISDN card - section. - - - - If you are planning to use ISDN primarily to connect to the - Internet with an Internet Provider on a dial-up non-dedicated basis, - you might look into Terminal Adapters. This will give you the - most flexibility, with the fewest problems, if you change - providers. - - - - If you are connecting two LANs together, or connecting to the - Internet with a dedicated ISDN connection, you might consider - the stand alone router/bridge option. - - - - Cost is a significant factor in determining what solution you will - choose. The following options are listed from least expensive to most - expensive. - - - - - - Hellmuth - Michaelis - Contributed by - - - - ISDN Cards - - - ISDN - cards - - - FreeBSD's ISDN implementation supports only the DSS1/Q.931 - (or Euro-ISDN) standard using passive cards. Starting with - FreeBSD 4.4, some active cards are supported where the firmware - also supports other signaling protocols; this also includes the - first supported Primary Rate (PRI) ISDN card. - - Isdn4bsd allows you to connect - to other ISDN routers using either IP over raw HDLC or by using - synchronous PPP: either by using kernel PPP with isppp, a - modified sppp driver, or by using userland &man.ppp.8;. By using - userland &man.ppp.8;, channel bonding of two or more ISDN - B-channels is possible. A telephone answering machine - application is also available as well as many utilities such as - a software 300 Baud modem. - - Some growing number of PC ISDN cards are supported under - FreeBSD and the reports show that it is successfully used all - over Europe and in many other parts of the world. - - The passive ISDN cards supported are mostly the ones with - the Infineon (formerly Siemens) ISAC/HSCX/IPAC ISDN chipsets, - but also ISDN cards with chips from Cologne Chip (ISA bus only), - PCI cards with Winbond W6692 chips, some cards with the - Tiger300/320/ISAC chipset combinations and some vendor specific - chipset based cards such as the AVM Fritz!Card PCI V.1.0 and the - AVM Fritz!Card PnP. - - Currently the active supported ISDN cards are the AVM B1 - (ISA and PCI) BRI cards and the AVM T1 PCI PRI cards. - - For documentation on isdn4bsd, - have a look at /usr/share/examples/isdn/ - directory on your FreeBSD system or at the homepage of - isdn4bsd which also has pointers to hints, erratas and - much more documentation such as the isdn4bsd - handbook. - - In case you are interested in adding support for a - different ISDN protocol, a currently unsupported ISDN PC card or - otherwise enhancing isdn4bsd, please - get in touch with &a.hm;. - - For questions regarding the installation, configuration - and troubleshooting isdn4bsd, a - &a.isdn.name; mailing list is available. - - - - ISDN Terminal Adapters - - Terminal adapters(TA), are to ISDN what modems are to regular - phone lines. - modem - Most TA's use the standard hayes modem AT command set, and can be - used as a drop in replacement for a modem. - - A TA will operate basically the same as a modem except connection - and throughput speeds will be much faster than your old modem. You - will need to configure PPP exactly the same - as for a modem setup. Make sure you set your serial speed as high as - possible. - PPP - The main advantage of using a TA to connect to an Internet - Provider is that you can do Dynamic PPP. As IP address space becomes - more and more scarce, most providers are not willing to provide you - with a static IP anymore. Most stand-alone routers are not able to - accommodate dynamic IP allocation. - - TA's completely rely on the PPP daemon that you are running for - their features and stability of connection. This allows you to - upgrade easily from using a modem to ISDN on a FreeBSD machine, if you - already have PPP setup. However, at the same time any problems you - experienced with the PPP program and are going to persist. - - If you want maximum stability, use the kernel PPP option, not the user-land iijPPP. - - The following TA's are known to work with FreeBSD. - - - - Motorola BitSurfer and Bitsurfer Pro - - - - Adtran - - - - Most other TA's will probably work as well, TA vendors try to make - sure their product can accept most of the standard modem AT command - set. - - The real problem with external TA's is that, like modems, - you need a good serial card in your computer. - - You should read the FreeBSD Serial - Hardware tutorial for a detailed understanding of - serial devices, and the differences between asynchronous and - synchronous serial ports. - - A TA running off a standard PC serial port (asynchronous) limits - you to 115.2 Kbs, even though you have a 128 Kbs connection. - To fully utilize the 128 Kbs that ISDN is capable of, - you must move the TA to a synchronous serial card. - - Do not be fooled into buying an internal TA and thinking you have - avoided the synchronous/asynchronous issue. Internal TA's simply have - a standard PC serial port chip built into them. All this will do is - save you having to buy another serial cable and find another empty - electrical socket. - - A synchronous card with a TA is at least as fast as a stand-alone - router, and with a simple 386 FreeBSD box driving it, probably more - flexible. - - The choice of sync/TA v.s. stand-alone router is largely a - religious issue. There has been some discussion of this in - the mailing lists. I suggest you search the archives for - the complete discussion. - - - - Stand-alone ISDN Bridges/Routers - - ISDN - stand-alone bridges/routers - - ISDN bridges or routers are not at all specific to FreeBSD - or any other operating system. For a more complete - description of routing and bridging technology, please refer - to a Networking reference book. - - In the context of this page, the terms router and bridge will - be used interchangeably. - - As the cost of low end ISDN routers/bridges comes down, it - will likely become a more and more popular choice. An ISDN - router is a small box that plugs directly into your local - Ethernet network, and manages its own connection to the other - bridge/router. It has built in software to communicate via - PPP and other popular protocols. - - A router will allow you much faster throughput than a - standard TA, since it will be using a full synchronous ISDN - connection. - - The main problem with ISDN routers and bridges is that - interoperability between manufacturers can still be a problem. - If you are planning to connect to an Internet provider, you - should discuss your needs with them. - - If you are planning to connect two LAN segments together, - such as your home LAN to the office LAN, this is the simplest - lowest - maintenance solution. Since you are buying the equipment for - both sides of the connection you can be assured that the link - will work. - - For example to connect a home computer or branch office - network to a head office network the following setup could be - used. - - - Branch Office or Home Network - - 10 base 2 - Network uses a bus based topology with 10 base 2 - Ethernet (thinnet). Connect router to network cable with - AUI/10BT transceiver, if necessary. - - - - - - - - ---Sun workstation -| ----FreeBSD box -| ----Windows 95 (Do not admit to owning it) -| -Stand-alone router - | -ISDN BRI line - - - - 10 Base 2 Ethernet - - - - If your home/branch office is only one computer you can use a - twisted pair crossover cable to connect to the stand-alone router - directly. - - - - Head Office or Other LAN - - 10 base T - Network uses a star topology with 10 base T Ethernet - (Twisted Pair). - - - - - - - - -------Novell Server - | H | - | ---Sun - | | - | U ---FreeBSD - | | - | ---Windows 95 - | B | - |___---Stand-alone router - | - ISDN BRI line - - - - ISDN Network Diagram - - - - - One large advantage of most routers/bridges is that they allow you - to have 2 separate independent PPP connections to - 2 separate sites at the same time. This is not - supported on most TA's, except for specific (usually expensive) models - that - have two serial ports. Do not confuse this with channel bonding, MPP, - etc. - - This can be a very useful feature if, for example, you - have an dedicated ISDN connection at your office and would - like to tap into it, but do not want to get another ISDN line - at work. A router at the office location can manage a - dedicated B channel connection (64 Kbps) to the Internet - and use the other B channel for a separate data connection. - The second B channel can be used for dial-in, dial-out or - dynamically bonding (MPP, etc.) with the first B channel for - more bandwidth. - - IPX/SPX - An Ethernet bridge will also allow you to transmit more than just - IP traffic. You can also send IPX/SPX or whatever other protocols you - use. - - - - - - - - Bill - Swingle - Written by - - - - - Eric - Ogren - Enhanced by - - - Udo - Erdelhoff - - - - NIS/YP - - - What Is It? - NIS - Solaris - HP-UX - AIX - Linux - NetBSD - OpenBSD - NIS, which stands for Network Information Services, was - developed by Sun Microsystems to centralize administration of Unix - (originally SunOS) systems. It has now essentially become an - industry standard; all major Unix systems (Solaris, HP-UX, AIX, Linux, - NetBSD, OpenBSD, FreeBSD, etc) support NIS. - - yellow pagesNIS - NIS was formerly known as Yellow Pages, but because of - trademark issues, Sun changed the name. The old term (and yp) is - still often seen and used. - - - NIS - domains - - It is a RPC-based client/server system that allows a group - of machines within an NIS domain to share a common set of - configuration files. This permits a system administrator to set - up NIS client systems with only minimal configuration data and - add, remove or modify configuration data from a single - location. - - Windows NT - It is similar to Windows NT's domain system; although the - internal implementation of the two are not at all similar, - the basic functionality can be compared. - - - - Terms/Processes You Should Know - - There are several terms and several important user processes - that you will come across when - attempting to implement NIS on FreeBSD, whether you are trying to - create an NIS server or act as an NIS client: - - - portmap - - - - - - - Term - Description - - - - - NIS domainname - An NIS master server and all of its clients - (including its slave servers) have a NIS - domainname. Similar to an NT domain name, the NIS - domainname does not have anything to do with DNS. - - - portmap - Must be running in order to enable RPC (Remote - Procedure Call, a network protocol used by NIS). If - portmap is not running, it will be - impossible to run an NIS server, or to act as an NIS - client. - - - ypbind - - Binds an NIS client to its NIS - server. It will take the NIS domainname from the - system, and using RPC, connect to the - server. ypbind is the core of - client-server communication in an NIS environment; if - ypbind dies on a client machine, it - will not be able to access the NIS server. - - - ypserv - Should only be running on NIS servers; this is the NIS - server process itself. If &man.ypserv.8; dies, then the - server will no longer be able to respond to NIS requests - (hopefully, there is a slave server to take over for - it). There are some implementations of NIS (but not the - FreeBSD one), that do not try to reconnect to another - server if the server it used before dies. Often, the - only thing that helps in this case is to restart the - server process (or even the whole server) or the - ypbind process on the client. - - - - rpc.yppasswdd - Another process that should only be running on - NIS master servers; this is a daemon that will allow NIS - clients to change their NIS passwords. If this daemon - is not running, users will have to login to the NIS - master server and change their passwords there. - - - - - - - - - - How Does It Work? - - There are three types of hosts in an NIS environment: master - servers, slave servers, and clients. Servers act as a central - repository for host configuration information. Master servers - hold the authoritative copy of this information, while slave - servers mirror this information for redundancy. Clients rely on - the servers to provide this information to them. - - Information in many files can be shared in this manner. The - master.passwd, group, - and hosts files are commonly shared via NIS. - Whenever a process on a client needs information that would - normally be found in these files locally, it makes a query to the - NIS server that it is bound to instead. - - - Machine Types - - - - NIS - master server - - - A NIS master server. - This server, analogous to a Windows - NT primary domain controller, maintains the files used by all - of the NIS clients. The passwd, - group, and other various files used by the - NIS clients live on the master server. - - It is possible for one machine to be an NIS - master server for more than one NIS domain. However, this will - not be covered in this introduction, which assumes a relatively - small-scale NIS environment. - - - NIS - slave server - - - NIS slave servers. - Similar to NT's backup domain - controllers, NIS slave servers maintain copies of the NIS - master's data files. NIS slave servers provide the redundancy, - which is needed in important environments. They also help - to balance the load of the master server: NIS Clients always - attach to the NIS server whose response they get first, and - this includes slave-server-replies. - - - NIS - client - - - NIS clients. NIS clients, like most - NT workstations, authenticate against the NIS server (or the NT - domain controller in the NT Workstation case) to log on. - - - - - - - Using NIS/YP - - This section will deal with setting up a sample NIS - environment. - - This section assumes that you are running FreeBSD 3.3 - or later. The instructions given here will - probably work for any version of FreeBSD greater - than 3.0, but there are no guarantees that this is - true. - - - - Planning - - Let us assume that you are the administrator of a small - university lab. This lab, which consists of 15 FreeBSD machines, - currently has no centralized point of administration; each machine - has its own /etc/passwd and - /etc/master.passwd. These files are kept in - sync with each other only through manual intervention; - currently, when you add a user to the lab, you must run - adduser on all 15 machines. - Clearly, this has to change, so you have decided to convert the - lab to use NIS, using two of the machines as servers. - - Therefore, the configuration of the lab now looks something - like: - - - - - - Machine name - IP address - Machine role - - - - - ellington - 10.0.0.2 - NIS master - - - coltrane - 10.0.0.3 - NIS slave - - - basie - 10.0.0.4 - Faculty workstation - - - bird - 10.0.0.5 - Client machine - - - cli[1-11] - 10.0.0.[6-17] - Other client machines - - - - - - If you are setting up a NIS scheme for the first time, it - is a good idea to think through how you want to go about it. No - matter what the size of your network, there are a few decisions - that need to be made. - - - Choosing a NIS Domain Name - - - NIS - domainname - - This might not be the domainname that you - are used to. It is more accurately called the - NIS domainname. When a client broadcasts its - requests for info, it includes the name of the NIS domain - that it is part of. This is how multiple servers on one - network can tell which server should answer which request. - Think of the NIS domainname as the name for a group of hosts - that are related in some way. - - Some organizations choose to use their Internet - domainname for their NIS domainname. This is not - recommended as it can cause confusion when trying to debug - network problems. The NIS domainname should be unique - within your network and it is helpful if it describes the - group of machines it represents. For example, the Art - department at Acme Inc. might be in the - acme-art NIS domain. For this example, - assume you have chosen the name - test-domain. - - SunOS - However, some operating systems (notably SunOS) use their - NIS domain name as their Internet domain name. - If one or more machines on your network have this restriction, - you must use the Internet domain name as - your NIS domain name. - - - - Physical Server Requirements - - There are several things to keep in mind when choosing a - machine to use as a NIS server. One of the unfortunate things - about NIS is the level of dependency the clients have on the - server. If a client cannot contact the server for its NIS - domain, very often the machine becomes unusable. The lack of - user and group information causes most systems to temporarily - freeze up. With this in mind you should make sure to choose a - machine that will not be prone to being rebooted regularly, or - one that might be used for development. The NIS server should - ideally be a stand alone machine whose sole purpose in life is - to be an NIS server. If you have a network that is not very - heavily used, it is acceptable to put the NIS server on a - machine running other services, just keep in mind that if the - NIS server becomes unavailable, it will affect - all of your NIS clients adversely. - - - - - NIS Servers - - The canonical copies of all NIS information are stored on - a single machine called the NIS master server. The databases - used to store the information are called NIS maps. In FreeBSD, - these maps are stored in - /var/yp/[domainname] where - [domainname] is the name of the NIS domain - being served. A single NIS server can support several domains - at once, therefore it is possible to have several such - directories, one for each supported domain. Each domain will - have its own independent set of maps. - - NIS master and slave servers handle all NIS requests with - the ypserv daemon. ypserv - is responsible for receiving incoming requests from NIS clients, - translating the requested domain and map name to a path to the - corresponding database file and transmitting data from the - database back to the client. - - - Setting Up a NIS Master Server - - NIS - server configuration - - Setting up a master NIS server can be relatively straight - forward, depending on your needs. FreeBSD comes with support - for NIS out-of-the-box. All you need is to add the following - lines to /etc/rc.conf, and FreeBSD will - do the rest for you. - - - - nisdomainname="test-domain" - This line will set the NIS domainname to - test-domain - upon network setup (e.g. after reboot). - - - nis_server_enable="YES" - This will tell FreeBSD to start up the NIS server processes - when the networking is next brought up. - - - nis_yppasswdd_enable="YES" - This will enable the rpc.yppasswdd - daemon which, as mentioned above, will allow users to - change their NIS password from a client machine. - - - - - Depending on your NIS setup, you may need to add - further entries. See the section about NIS servers - that are also NIS clients, below, for - details. - - - Now, all you have to do is to run the command - /etc/netstart as superuser. It will - set up everything for you, using the values you defined in - /etc/rc.conf. - - - - Initializing the NIS Maps - - NIS - maps - - The NIS maps are database files, - that are kept in the /var/yp directory. - They are generated from configuration files in the - /etc directory of the NIS master, with one - exception: the /etc/master.passwd file. - This is for a good reason; you do not want to propagate - passwords to your root and other - administrative accounts to all the servers in the NIS domain. - Therefore, before we initialize the NIS maps, you should: - - &prompt.root; cp /etc/master.passwd /var/yp/master.passwd -&prompt.root; cd /var/yp -&prompt.root; vi master.passwd - - You should remove all entries regarding system accounts - (bin, tty, - kmem, games, etc), as - well as any accounts that you do not want to be propagated to the - NIS clients (for example root and any other - UID 0 (superuser) accounts). - - Make sure the - /var/yp/master.passwd is neither group - nor world readable (mode 600)! Use the - chmod command, if appropriate. - - Tru64 Unix - When you have finished, it is time to initialize the NIS - maps! FreeBSD includes a script named - ypinit to do this for you - (see its manual page for more information). Note that this - script is available on most Unix Operating Systems, but not on all. - On Digital Unix/Compaq Tru64 Unix it is called - ypsetup. - Because we are generating maps for an NIS master, we are - going to pass the option to - ypinit. - To generate the NIS maps, assuming you already performed - the steps above, run: - - 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 - -[..output from map generation..] - -NIS Map update completed. -ellington has been setup as an YP master server without any errors. - - ypinit should have created - /var/yp/Makefile from - /var/yp/Makefile.dist. - When created, this file assumes that you are operating - in a single server NIS environment with only FreeBSD - machines. Since test-domain has - a slave server as well, you must edit - /var/yp/Makefile: - - ellington&prompt.root; vi /var/yp/Makefile - - You should comment out the line that says - - NOPUSH = "True" - - (if it is not commented out already). - - - - Setting up a NIS Slave Server - - NIS - slave server - - Setting up an NIS slave server is even more simple than - setting up the master. Log on to the slave server and edit the - file /etc/rc.conf as you did before. - The only difference is that we now must use the - option when running ypinit. - The option requires the name of the NIS - master be passed to it as well, so our command line looks - like: - - 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. - - You should now have a directory called - /var/yp/test-domain. Copies of the NIS - master server's maps should be in this directory. You will - need to make sure that these stay updated. The following - /etc/crontab entries on your slave - servers should do the job: - - 20 * * * * root /usr/libexec/ypxfr passwd.byname -21 * * * * root /usr/libexec/ypxfr passwd.byuid - - These two lines force the slave to sync its maps with - the maps on the master server. Although these entries are - not mandatory, since the master server attempts to ensure - any changes to its NIS maps are communicated to its slaves - and because password information is vital to systems - depending on the server, it is a good idea to force the - updates. This is more important on busy networks where map - updates might not always complete. - - Now, run the command /etc/netstart on the - slave server as well, which again starts the NIS server. - - - - - NIS Clients - - An NIS client establishes what is called a binding to a - particular NIS server using the - ypbind daemon. - ypbind checks the system's default - domain (as set by the domainname command), - and begins broadcasting RPC requests on the local network. - These requests specify the name of the domain for which - ypbind is attempting to establish a binding. - If a server that has been configured to serve the requested - domain receives one of the broadcasts, it will respond to - ypbind, which will record the server's - address. If there are several servers available (a master and - several slaves, for example), ypbind will - use the address of the first one to respond. From that point - on, the client system will direct all of its NIS requests to - that server. ypbind will - occasionally ping the server to make sure it is - still up and running. If it fails to receive a reply to one of - its pings within a reasonable amount of time, - ypbind will mark the domain as unbound and - begin broadcasting again in the hopes of locating another - server. - - - Setting Up a NIS Client - - NIS - client configuration - - Setting up a FreeBSD machine to be a NIS client is fairly - straightforward. - - - - Edit the file /etc/rc.conf and - add the following lines in order to set the NIS domainname - and start ypbind upon network - startup: - - nisdomainname="test-domain" -nis_client_enable="YES" - - - - To import all possible password entries from the NIS - server, remove all user accounts from your - /etc/master.passwd file and use - vipw to add the following line to - the end of the file: - - +::::::::: - - - This line will afford anyone with a valid account in - the NIS server's password maps an account. There are - many ways to configure your NIS client by changing this - line. See the netgroups - section below for more information. - For more detailed reading see O'Reilly's book on - Managing NFS and NIS. - - - - You should keep at least one local account (i.e. - not imported via NIS) in your - /etc/master.passwd and this - account should also be a member of the group - wheel. If there is something - wrong with NIS, this account can be used to log in - remotely, become root, and fix things. - - - - - To import all possible group entries from the NIS - server, add this line to your - /etc/group file: - - +:*:: - - - - After completing these steps, you should be able to run - ypcat passwd and see the NIS server's - passwd map. - - - - - - NIS Security - - In general, any remote user can issue an RPC to - &man.ypserv.8; and retrieve the contents of your NIS maps, - provided the remote user knows your domainname. To prevent - such unauthorized transactions, &man.ypserv.8; supports a - feature called securenets which can be used to restrict access - to a given set of hosts. At startup, &man.ypserv.8; will - attempt to load the securenets information from a file called - /var/yp/securenets. - - - This path varies depending on the path specified with the - option. This file contains entries that - consist of a network specification and a network mask separated - by white space. Lines starting with # are - considered to be comments. A sample securenets file might look - like this: - - - # 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 - - If &man.ypserv.8; receives a request from an address that - matches one of these rules, it will process the request - normally. If the address fails to match a rule, the request - will be ignored and a warning message will be logged. If the - /var/yp/securenets file does not exist, - ypserv will allow connections from any - host. - - The ypserv program also has support for Wietse - Venema's - tcpwrapper package. This allows the - administrator to use the tcpwrapper configuration - files for access control instead of - /var/yp/securenets. - - - While both of these access control mechanisms provide some - security, they, like the privileged port test, are - vulnerable to IP spoofing attacks. All - NIS-related traffic should be blocked at your firewall. - - Servers using /var/yp/securenets - may fail to serve legitimate NIS clients with archaic TCP/IP - implementations. Some of these implementations set all - host bits to zero when doing broadcasts and/or fail to - observe the subnet mask when calculating the broadcast - address. While some of these problems can be fixed by - changing the client configuration, other problems may force - the retirement of the client systems in question or the - abandonment of /var/yp/securenets. - - Using /var/yp/securenets on a - server with such an archaic implementation of TCP/IP is a - really bad idea and will lead to loss of NIS functionality - for large parts of your network. - - tcpwrapper - The use of the tcpwrapper - package increases the latency of your NIS server. The - additional delay may be long enough to cause timeouts in - client programs, especially in busy networks or with slow - NIS servers. If one or more of your client systems - suffers from these symptoms, you should convert the client - systems in question into NIS slave servers and force them - to bind to themselves. - - - - - Barring Some Users from Logging On - - In our lab, there is a machine basie that is - supposed to be a faculty only workstation. We do not want to take this - machine out of the NIS domain, yet the passwd - file on the master NIS server contains accounts for both faculty and - students. What can we do? - - There is a way to bar specific users from logging on to a - machine, even if they are present in the NIS database. To do this, - all you must do is add - -username to the end of - the /etc/master.passwd file on the client - machine, where username is the username of - the user you wish to bar from logging in. This should preferably be - done using vipw, since vipw - will sanity check your changes to - /etc/master.passwd, as well as - automatically rebuild the password database when you - finish editing. For example, if we wanted to bar user - bill from logging on to basie - we would: - - 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 - Contributed by - - - - - Using Netgroups - netgroups - - The method shown in the previous section works reasonably - well if you need special rules for a very small number of - users and/or machines. On larger networks, you - will forget to bar some users from logging - onto sensitive machines, or you may even have to modify each - machine separately, thus losing the main benefit of NIS, - centralized administration. - - The NIS developers' solution for this problem is called - netgroups. Their purpose and semantics - can be compared to the normal groups used by Unix file - systems. The main differences are the lack of a numeric id - and the ability to define a netgroup by including both user - accounts and other netgroups. - - Netgroups were developed to handle large, complex networks - with hundreds of users and machines. On one hand, this is - a Good Thing if you are forced to deal with such a situation. - On the other hand, this complexity makes it almost impossible to - explain netgroups with really simple examples. The example - used in the remainder of this section demonstrates this - problem. - - Let us assume that your successful introduction of NIS in - your laboratory caught your superiors' interest. Your next - job is to extend your NIS domain to cover some of the other - machines on campus. The two tables contain the names of the - new users and new machines as well as brief descriptions of - them. - - - - - - User Name(s) - Description - - - - - - alpha, beta - Normal employees of the IT department - - - - charlie, delta - The new apprentices of the IT department - - - - echo, foxtrott, golf, ... - Ordinary employees - - - - able, baker, ... - The current interns - - - - - - - - - - Machine Name(s) - Description - - - - - - - war, death, famine, pollution - Your most important servers. Only the IT - employees are allowed to log onto these - machines. - - - - pride, greed, envy, wrath, lust, sloth - Less important servers. All members of the IT - department are allowed to login onto these machines. - - - - one, two, three, four, ... - Ordinary workstations. Only the - real employees are allowed to use - these machines. - - - - trashcan - A very old machine without any critical data. - Even the intern is allowed to use this box. - - - - - - If you tried to implement these restrictions by separately - blocking each user, you would have to add one - -user line to each system's - passwd - for each user who is not allowed to login onto that system. - If you forget just one entry, you could be in trouble. It may - be feasible to do this correctly during the initial setup, - however you will eventually forget to add - the lines for new users during day-to-day operations. After - all, Murphy was an optimist. - - Handling this situation with netgroups offers several - advantages. Each user need not be handled separately; - you assign a user to one or more netgroups and allow or forbid - logins for all members of the netgroup. If you add a new - machine, you will only have to define login restrictions for - netgroups. If a new user is added, you will only have to add - the user to one or more netgroups. Those changes are - independent of each other; no more for each combination - of user and machine do... If your NIS setup is planned - carefully, you will only have to modify exactly one central - configuration file to grant or deny access to machines. - - The first step is the initialization of the NIS map - netgroup. FreeBSD's &man.ypinit.8; does not create this map by - default, but its NIS implementation will support it once it has - been created. To create an empty map, simply type - - ellington&prompt.root; vi /var/yp/netgroup - - and start adding content. For our example, we need at - least four netgroups: IT employees, IT apprentices, normal - employees and interns. - - IT_EMP (,alpha,test-domain) (,beta,test-domain) -IT_APP (,charlie,test-domain) (,delta,test-domain) -USERS (,echo,test-domain) (,foxtrott,test-domain) \ - (,golf,test-domain) -INTERNS (,able,test-domain) (,baker,test-domain) - - IT_EMP, IT_APP etc. - are the names of the netgroups. Each bracketed group adds - one or more user accounts to it. The three fields inside a - group are: - - - - The name of the host(s) where the following items are - valid. If you do not specify a hostname, the entry is - valid on all hosts. If you do specify a hostname, you - will enter a realm of darkness, horror and utter confusion. - - - - The name of the account that belongs to this - netgroup. - - - - The NIS domain for the account. You can import - accounts from other NIS domains into your netgroup if you - are one of the unlucky fellows with more than one NIS - domain. - - - - Each of these fields can contain wildcards. See - &man.netgroup.5; for details. - - - netgroups - Netgroup names longer than 8 characters should not be - used, especially if you have machines running other - operating systems within your NIS domain. The names are - case sensitive; using capital letters for your netgroup - names is an easy way to distinguish between user, machine - and netgroup names. - - Some NIS clients (other than FreeBSD) cannot handle - netgroups with a large number of entries. For example, some - older versions of SunOS start to cause trouble if a netgroup - contains more than 15 entries. You can - circumvent this limit by creating several sub-netgroups with - 15 users or less and a real netgroup that consists of the - sub-netgroups: - - BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] -BIGGRP2 (,joe16,domain) (,joe17,domain) [...] -BIGGRP3 (,joe31,domain) (,joe32,domain) -BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 - - You can repeat this process if you need more than 225 - users within a single netgroup. - - - Activating and distributing your new NIS map is - easy: - - ellington&prompt.root; cd /var/yp -ellington&prompt.root; make - - This will generate the three NIS maps - netgroup, - netgroup.byhost and - netgroup.byuser. Use &man.ypcat.1; to - check if your new NIS maps are available: - - ellington&prompt.user; ypcat -k netgroup -ellington&prompt.user; ypcat -k netgroup.byhost -ellington&prompt.user; ypcat -k netgroup.byuser - - The output of the first command should resemble the - contents of /var/yp/netgroup. The second - command will not produce output if you have not specified - host-specific netgroups. The third command can be used to - get the list of netgroups for a user. - - The client setup is quite simple. To configure the server - war, you only have to start - &man.vipw.8; and replace the line - - +::::::::: - - with - - +@IT_EMP::::::::: - - Now, only the data for the users defined in the netgroup - IT_EMP is imported into - war's password database and only - these users are allowed to login. - - Unfortunately, this limitation also applies to the ~ - function of the shell and all routines converting between user - names and numerical user IDs. In other words, - cd ~user will not work, - ls -l will show the numerical id instead of - the username and find . -user joe -print will - fail with No such user. To fix this, you will - have to import all user entries without allowing them - to login onto your servers. - - This can be achieved by adding another line to - /etc/master.passwd. This line should - contain: - - +:::::::::/sbin/nologin, meaning - Import all entries but replace the shell with - /sbin/nologin in the imported - entries. You can replace any field - in the passwd entry by placing a default value in your - /etc/master.passwd. - - - - Make sure that the line - +:::::::::/sbin/nologin is placed after - +@IT_EMP:::::::::. Otherwise, all user - accounts imported from NIS will have /sbin/nologin as their - login shell. - - - After this change, you will only have to change one NIS - map if a new employee joins the IT department. You could use - a similar approach for the less important servers by replacing - the old +::::::::: in their local version - of /etc/master.passwd with something like - this: - - +@IT_EMP::::::::: -+@IT_APP::::::::: -+:::::::::/sbin/nologin - - The corresponding lines for the normal workstations - could be: - - +@IT_EMP::::::::: -+@USERS::::::::: -+:::::::::/sbin/nologin - - And everything would be fine until there is a policy - change a few weeks later: The IT department starts hiring - interns. The IT interns are allowed to use the normal - workstations and the less important servers; and the IT - apprentices are allowed to login onto the main servers. You - add a new netgroup IT_INTERN, add the new IT interns to this - netgroup and start to change the config on each and every - machine... As the old saying goes: Errors in - centralized planning lead to global mess. - - NIS' ability to create netgroups from other netgroups can - be used to prevent situations like these. One possibility - is the creation of role-based netgroups. For example, you - could create a netgroup called - BIGSRV to define the login - restrictions for the important servers, another netgroup - called SMALLSRV for the less - important servers and a third netgroup called - USERBOX for the normal - workstations. Each of these netgroups contains the netgroups - that are allowed to login onto these machines. The new - entries for your NIS map netgroup should look like this: - - BIGSRV IT_EMP IT_APP -SMALLSRV IT_EMP IT_APP ITINTERN -USERBOX IT_EMP ITINTERN USERS - - This method of defining login restrictions works - reasonably well if you can define groups of machines with - identical restrictions. Unfortunately, this is the exception - and not the rule. Most of the time, you will need the ability - to define login restrictions on a per-machine basis. - - Machine-specific netgroup definitions are the other - possibility to deal with the policy change outlined above. In - this scenario, the /etc/master.passwd of - each box contains two lines starting with +. - The first of them adds a netgroup with the accounts allowed to - login onto this machine, the second one adds all other - accounts with /sbin/nologin as shell. It - is a good idea to use the ALL-CAPS version of the machine name - as the name of the netgroup. In other words, the lines should - look like this: - - +@BOXNAME::::::::: -+:::::::::/sbin/nologin - - Once you have completed this task for all your machines, - you will not have to modify the local versions of - /etc/master.passwd ever again. All - further changes can be handled by modifying the NIS map. Here - is an example of a possible netgroup map for this - scenario with some additional goodies. - - # Define groups of users first -IT_EMP (,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) -ITINTERN (,kilo,test-domain) (,lima,test-domain) -D_INTERNS (,able,test-domain) (,baker,test-domain) -# -# Now, define some groups based on roles -USERS DEPT1 DEPT2 DEPT3 -BIGSRV IT_EMP IT_APP -SMALLSRV IT_EMP IT_APP ITINTERN -USERBOX IT_EMP ITINTERN USERS -# -# And a groups for a special tasks -# Allow echo and golf to access our anti-virus-machine -SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) -# -# machine-based netgroups -# Our main servers -WAR BIGSRV -FAMINE BIGSRV -# User india needs access to this server -POLLUTION BIGSRV (,india,test-domain) -# -# This one is really important and needs more access restrictions -DEATH IT_EMP -# -# The anti-virus-machine mentioned above -ONE SECURITY -# -# Restrict a machine to a single user -TWO (,hotel,test-domain) -# [...more groups to follow] - - If you are using some kind of database to manage your user - accounts, you should be able to create the first part of the - map with your database's report tools. This way, new users - will automatically have access to the boxes. - - One last word of caution: It may not always be advisable - to use machine-based netgroups. If you are deploying a couple of - dozen or even hundreds of identical machines for student labs, - you should use role-based netgroups instead of machine-based - netgroups to keep the size of the NIS map within reasonable - limits. - - - - Important Things to Remember - - There are still a couple of things that you will need to do - differently now that you are in an NIS environment. - - - - Every time you wish to add a user to the lab, you - must add it to the master NIS server only, - and you must remember to rebuild the NIS - maps. If you forget to do this, the new user will - not be able to login anywhere except on the NIS master. - For example, if we needed to add a new user - jsmith to the lab, we would: - - &prompt.root; pw useradd jsmith -&prompt.root; cd /var/yp -&prompt.root; make test-domain - - You could also run adduser jsmith instead - of pw useradd jsmith. - - - Keep the administration accounts out of the NIS - maps. You do not want to be propagating administrative - accounts and passwords to machines that will have users that - should not have access to those accounts. - - - Keep the NIS master and slave - secure, and minimize their downtime. - If somebody either hacks or simply turns off - these machines, they have effectively rendered many people without - the ability to login to the lab. - - This is the chief weakness of any centralized administration - system, and it is probably the most important weakness. If you do - not protect your NIS servers, you will have a lot of angry - users! - - - - - - NIS v1 Compatibility - - FreeBSD's ypserv has some support - for serving NIS v1 clients. FreeBSD's NIS implementation only - uses the NIS v2 protocol, however other implementations include - support for the v1 protocol for backwards compatibility with older - systems. The ypbind daemons supplied - with these systems will try to establish a binding to an NIS v1 - server even though they may never actually need it (and they may - persist in broadcasting in search of one even after they receive a - response from a v2 server). Note that while support for normal - client calls is provided, this version of ypserv does not handle - v1 map transfer requests; consequently, it cannot be used as a - master or slave in conjunction with older NIS servers that only - support the v1 protocol. Fortunately, there probably are not any - such servers still in use today. - - - - NIS Servers That Are Also NIS Clients - - Care must be taken when running ypserv in a multi-server - domain where the server machines are also NIS clients. It is - generally a good idea to force the servers to bind to themselves - rather than allowing them to broadcast bind requests and possibly - become bound to each other. Strange failure modes can result if - one server goes down and others are dependent upon it. - Eventually all the clients will time out and attempt to bind to - other servers, but the delay involved can be considerable and the - failure mode is still present since the servers might bind to each - other all over again. - - You can force a host to bind to a particular server by running - ypbind with the - flag. If you do not want to do this manually each time you - reboot your NIS server, you can add the following lines to - your /etc/rc.conf: - - nis_client_enable="YES" # run client stuff as well -nis_client_flags="-S NIS domain,server" - - See &man.ypbind.8; for further information. - - - - Password Formats - - NIS - password formats - - One of the most common issues that people run into when trying - to implement NIS is password format compatibility. If your NIS - server is using DES encrypted passwords, it will only support - clients that are also using DES. For example, if you have - Solaris NIS clients in your network, then you will almost certainly - need to use DES encrypted passwords. - - To check which format your servers - and clients are using, look at /etc/login.conf. - If the host is configured to use DES encrypted passwords, then the - default class will contain an entry like this: - - default:\ - :passwd_format=des:\ - :copyright=/etc/COPYRIGHT:\ - [Further entries elided] - - Other possible values for the passwd_format - capability include blf and md5 - (for Blowfish and MD5 encrypted passwords, respectively). - - If you have made changes to /etc/login.conf, - you will also need to rebuild the login capability database, which is - achieved by running the following command as root: - - &prompt.root; cap_mkdb /etc/login.conf - - The format of passwords already in - /etc/master.passwd will not be updated until - a user changes their password for the first time after - the login capability database is rebuilt. - - Next, in order to ensure that passwords are encrypted with the - format that you have chosen, you should also check that the - crypt_default in /etc/auth.conf - gives precedence to your chosen password format. To do this, place - the format that you have chosen first in the list. For example, when - using DES encrypted passwords, the entry would be: - - crypt_default = des blf md5 - - Having followed the above steps on each of the &os; based NIS - servers and clients, you can be sure that they all agree on which - password format is used within your network. - If you have trouble authenticating on an NIS client, this - is a pretty good place to start looking for possible problems. - Remember: if you want to deploy an NIS server for a heterogenous - network, you will probably have to use DES on all systems - because it is the lowest common standard. - - - - - - - - Greg - Sutter - Written by - - - - DHCP - - - What Is DHCP? - - Dynamic Host Configuration Protocol - DHCP - - - Internet Software Consortium (ISC) - - - DHCP, the Dynamic Host Configuration Protocol, describes - the means by which a system can connect to a network and obtain the - necessary information for communication upon that network. FreeBSD - uses the ISC (Internet Software Consortium) DHCP implementation, so - all implementation-specific information here is for use with the ISC - distribution. - - - - What This Section Covers - - This section describes both the client-side and server-side - components of the ISC DHCP system. The client-side program, - dhclient, comes integrated within FreeBSD, and - the server-side portion is available from the - net/isc-dhcp3 port. The - &man.dhclient.8;, &man.dhcp-options.5;, and &man.dhclient.conf.5; - manual pages, in addition to the references below, are useful - resources. - - - - How It Works - UDP - When dhclient, the DHCP client, is - executed on the client machine, it begins broadcasting - requests for configuration information. By default, these - requests are on UDP port 68. The server replies on UDP 67, - giving the client an IP address and other relevant network - information such as netmask, router, and DNS servers. All of - this information comes in the form of a DHCP - lease and is only valid for a certain time - (configured by the DHCP server maintainer). In this manner, - stale IP addresses for clients no longer connected to the - network can be automatically reclaimed. - - DHCP clients can obtain a great deal of information from - the server. An exhaustive list may be found in - &man.dhcp-options.5;. - - - - FreeBSD Integration - - FreeBSD fully integrates the ISC DHCP client, - dhclient. DHCP client support is provided - within both the installer and the base system, obviating the need - for detailed knowledge of network configurations on any network - that runs a DHCP server. dhclient has been - included in all FreeBSD distributions since 3.2. - - sysinstall - - - DHCP is supported by - sysinstall. When configuring a - network interface within sysinstall, the first question - asked is, Do you want to try DHCP configuration of - this interface? Answering affirmatively will execute - dhclient, and if successful, will fill in - the network configuration information automatically. - - There are two things you must do to have your system use - DHCP upon startup: - - DHCP - requirements - - - - Make sure that the bpf - device is compiled into your kernel. To do this, add - pseudo-device bpf to your kernel - configuration file, and rebuild the kernel. For more - information about building kernels, see . - The bpf device is already - part of the GENERIC kernel that is - supplied with FreeBSD, so if you do not have a custom - kernel, you should not need to create one in order to get - DHCP working. - - For those who are particularly security conscious, - you should be warned that bpf - is also the device that allows packet sniffers to work - correctly (although they still have to be run as - root). bpf - is required to use DHCP, but if - you are very sensitive about security, you probably - should not add bpf to your - kernel in the expectation that at some point in the - future you will be using DHCP. - - - - Edit your /etc/rc.conf to - include the following: - - ifconfig_fxp0="DHCP" - - - Be sure to replace fxp0 with the - designation for the interface that you wish to dynamically - configure, as described in - . - - - If you are using a different location for - dhclient, or if you wish to pass additional - flags to dhclient, also include the - following (editing as necessary): - - dhcp_program="/sbin/dhclient" -dhcp_flags="" - - - - - DHCP - server - - The DHCP server, dhcpd, is included - as part of the net/isc-dhcp3 port in the ports - collection. This port contains the full ISC DHCP - distribution, consisting of client, server, relay agent and - documentation. - - - - - Files - - DHCP - configuration files - - - /etc/dhclient.conf - dhclient requires a configuration file, - /etc/dhclient.conf. Typically the file - contains only comments, the defaults being reasonably sane. This - configuration file is described by the &man.dhclient.conf.5; - manual page. - - - /sbin/dhclient - dhclient is statically linked and - resides in /sbin. The &man.dhclient.8; - manual page gives more information about - dhclient. - - - /sbin/dhclient-script - dhclient-script is the FreeBSD-specific - DHCP client configuration script. It is described in - &man.dhclient-script.8;, but should not need any user - modification to function properly. - - - /var/db/dhclient.leases - The DHCP client keeps a database of valid leases in this - file, which is written as a log. &man.dhclient.leases.5; - gives a slightly longer description. - - - - - - Further Reading - - The DHCP protocol is fully described in - RFC 2131. - An informational resource has also been set up at - dhcp.org. - - - - Installing and Configuring a DHCP Server - - - What This Section Covers - - This section provides information on how to configure - a FreeBSD system to act as a DHCP server using the ISC - (Internet Software Consortium) implementation of the DHCP - suite. - - The server portion of the suite is not provided as part of - FreeBSD, and so you will need to install the - net/isc-dhcp3 - port to provide this service. See for - more information on using the ports collection. - - - - DHCP Server Installation - - DHCP - installation - - In order to configure your FreeBSD system as a DHCP server, - you will need to ensure that the &man.bpf.4; - device is compiled into your kernel. To do this, add - pseudo-device bpf to your kernel - configuration file, and rebuild the kernel. For more - information about building kernels, see . - - The bpf device is already - part of the GENERIC kernel that is - supplied with FreeBSD, so you do not need to create a custom - kernel in order to get DHCP working. - - - Those who are particularly security conscious - should note that bpf - is also the device that allows packet sniffers to work - correctly (although such programs still need privileged - access). bpf - is required to use DHCP, but if - you are very sensitive about security, you probably - should not include bpf in your - kernel purely because you expect to use DHCP at some - point in the future. - - - The next thing that you will need to do is edit the sample - dhcpd.conf which was installed by the - net/isc-dhcp3 port. - By default, this will be - /usr/local/etc/dhcpd.conf.sample, and you - should copy this to - /usr/local/etc/dhcpd.conf before proceeding - to make changes. - - - - Configuring the DHCP Server - - DHCP - dhcpd.conf - - dhcpd.conf is - comprised of declarations regarding subnets and hosts, and is - perhaps most easily explained using an example : - - 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; -} - - - - This option specifies the domain that will be provided - to clients as the default search domain. See - &man.resolv.conf.5; for more information on what this - means. - - - - This option specifies a comma separated list of DNS - servers that the client should use. - - - - The netmask that will be provided to clients. - - - - A client may request a specific length of time that a - lease will be valid. Otherwise the server will assign - a lease with this expiry value (in seconds). - - - - This is the maximum length of time that the server will - lease for. Should a client request a longer lease, a lease - will be issued, although it will only be valid for - max-lease-time seconds. - - - - This option specifies whether the DHCP server should - attempt to update DNS when a lease is accepted or released. - In the ISC implementation, this option is - required. - - - - This denotes which IP addresses should be used in - the pool reserved for allocating to clients. IP - addresses between, and including, the ones stated are - handed out to clients. - - - - Declares the default gateway that will be provided to - clients. - - - - The hardware MAC address of a host (so that the DHCP server - can recognize a host when it makes a request). - - - - Specifies that the host should always be given the same - IP address. Note that a hostname is OK here, since the DHCP - server will resolve the hostname itself before returning the - lease information. - - - - Once you have finished writing your - dhcpd.conf, you can proceed to start the - server by issuing the following command: - - &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start - - Should you need to make changes to the configuration of your - server in the future, it is important to note that sending a - SIGHUP signal to - dhcpd does not - result in the configuration being reloaded, as it does with most - daemons. You will need to send a SIGTERM - signal to stop the process, and then restart it using the command - above. - - - - Files - - DHCP - configuration files - - - /usr/local/sbin/dhcpd - dhcpd is statically linked and - resides in /usr/local/sbin. The - dhcpd(8) manual page installed with the - port gives more information about - dhcpd. - - - /usr/local/etc/dhcpd.conf - dhcpd requires a configuration - file, /usr/local/etc/dhcpd.conf before it - will start providing service to clients. This file needs to - contain all the information that should be provided to clients - that are being serviced, along with information regarding the - operation of the server. This configuration file is described - by the dhcpd.conf(5) manual page installed - by the port. - - - /var/db/dhcpd.leases - The DHCP server keeps a database of leases it has issued - in this file, which is written as a log. The manual page - dhcpd.leases(5), installed by the port - gives a slightly longer description. - - - /usr/local/sbin/dhcrelay - dhcrelay is used in advanced - environments where one DHCP server forwards a request from a - client to another DHCP server on a separate network. The - dhcrelay(8) manual page provided with the - port contains more detail. - - - - - - - - - - - - - Chern - Lee - Contributed by - - - - DNS - - - Overview - BIND - - FreeBSD utilizes, by default, a version of BIND (Berkeley - Internet Name Domain), which is the most common implementation of the - DNS protocol. DNS is the protocol through which names are mapped to - IP addresses, and vice versa. For example, a query for - www.FreeBSD.org - will receive a reply with the IP address of The FreeBSD Project's - web server, whereas, a query for ftp.FreeBSD.org - will return the IP - address of the corresponding FTP machine. Likewise, the opposite can - happen. A query for an IP address can resolve its hostname. It is - not necessary to run a name server to perform DNS lookups on a system. - - - DNS - DNS is coordinated across the Internet through a somewhat - complex system of authoritative root name servers, and other - smaller-scale name servers who host and cache individual domain - information. - - - - This document refers to BIND 8.x, as it is the stable version - used in FreeBSD. BIND 9.x in FreeBSD can be installed through - the net/bind9 port. - - - - RFC1034 and RFC1035 dictate the DNS protocol. - - - - Currently, BIND is maintained by the - Internet Software Consortium (www.isc.org) - - - - - Terminology - - To understand this document, some terms related to DNS must be - understood. - - - - - - Term - Definition - - - - - - forward DNS - mapping of hostnames to IP addresses - - - - origin - refers to the domain covered for the particular zone - file - - - - named, bind, name server - common names for the BIND name server package within - FreeBSD - - - resolver - - resolver - a system process through which a - machine queries a name server for zone information - - - reverse DNS - - reverse DNS - the opposite of forward DNS, mapping of IP addresses to - hostnames - - - root zone - - root zone - - literally, a ., refers to the - root, or beginning zone. All zones fall under this, as - do all files in fall under the root directory. It is - the beginning of the Internet zone hierarchy. - - - - zone - Each individual domain, subdomain, or area dictated by - DNS - - - - - - - zones - examples - - - Examples of zones: - - - - . is the root zone - - - org. is a zone under the root zone - - - example.org is a zone under the - org. zone - - - foo.example.org. is a subdomain, a - zone under the example.org. zone - - - - 1.2.3.in-addr.arpa is a zone referencing - all IP addresses which fall under the 3.2.1.* IP space. - - - - - As one can see, the more specific part of a hostname appears to - its left. For example, example.org. is more - specific than org., as org. is - more specific than the root zone. The layout of each part of - a hostname is much like a filesystem: the /dev - directory falls within the root, and so on. - - - - - - Reasons to Run a Name Server - - Name servers usually come in two forms: an authoritative - name server, and a caching name server. - - An authoritative name server is needed when: - - - - one wants to serve DNS information to the - world, replying authoritatively to queries. - - - a domain, such as example.org, is - registered and IP addresses need to be assigned to hostnames - under it. - - - an IP address block requires reverse DNS entries (IP to - hostname). - - - a backup name server, called a slave, must reply to queries - when the primary is down or inaccessible. - - - - A caching name server is needed when: - - - - a local DNS server may cache and respond more quickly - than querying an outside name server. - - - a reduction in overall network traffic is desired (DNS - traffic has been measured to account for 5% or more of total - Internet traffic). - - - - When one queries for www.FreeBSD.org, the - resolver usually queries the uplink ISP's name server, and retrieves - the reply. With a local, caching DNS server, the query only has to - be made once to the outside world by the caching DNS server. Every - additional query will not have to look to the outside of the local - network, since the information is cached locally. - - - - - How It Works - In FreeBSD, the BIND daemon is called - named for obvious reasons. - - - - - - File - Description - - - - - - named - the BIND daemon - - - - ndc - name daemon control program - - - - /etc/namedb - directory where BIND zone information resides - - - - /etc/namedb/named.conf - daemon configuration file - - - - - - - Zone files are usually contained within the - /etc/namedb - directory, and contain the DNS zone information - served by the name server. - - - - - Starting BIND - - BIND - starting - - - Since BIND is installed by default, configuring it all is - relatively simple. - - - To ensure the named daemon is started at boot, put the following - modifications in /etc/rc.conf: - - named_enable="YES" - To start the daemon manually (after configuring it) - &prompt.root; ndc start - - - - Configuration Files - - BIND - configuration files - - - Using <command>make-localhost</command> - Be sure to: - - &prompt.root; cd /etc/namedb -&prompt.root; sh make-localhost - to properly create the local reverse DNS zone file in - /etc/namedb/localhost.rev. - - - - - <filename>/etc/namedb/named.conf</filename> - - // $FreeBSD$ -// -// Refer to the named(8) manual page for details. If you are ever going -// to setup a primary server, make sure you've understood the hairy -// details of how DNS is working. Even with simple mistakes, you can -// break connectivity for affected parties, or cause huge amount of -// useless Internet traffic. - -options { - directory "/etc/namedb"; - -// In addition to the "forwarders" clause, you can force your name -// server to never initiate queries of its own, but always ask its -// forwarders only, by enabling the following line: -// -// forward only; - -// If you've got a DNS server around at your upstream provider, enter -// its IP address here, and enable the line below. This will make you -// benefit from its cache, thus reduce overall DNS traffic in the -Internet. -/* - forwarders { - 127.0.0.1; - }; -*/ - - - Just as the comment says, to benefit from an uplink's cache, - forwarders can be enabled here. Under normal - circumstances, a name server will recursively query the Internet - looking at certain name servers until it finds the answer it is - looking for. Having this enabled will have it query the uplink's - name server (or name server provided) first, taking advantage of - its cache. If the uplink name server in question is a heavily - trafficked, fast name server, enabling this may be worthwhile. - - - 127.0.0.1 - will not work here. - Change this IP address to a name server at your uplink. - - - /* - * If there is a firewall between you and name servers you want - * to talk to, you might need to uncomment the query-source - * directive below. Previous versions of BIND always asked - * questions using port 53, but BIND 8.1 uses an unprivileged - * port by default. - */ - // query-source address * port 53; - - /* - * If running in a sandbox, you may have to specify a different - * location for the dumpfile. - */ - // dump-file "s/named_dump.db"; -}; - -// Note: the following will be supported in a future release. -/* -host { any; } { - topology { - 127.0.0.0/8; - }; -}; -*/ - -// Setting up secondaries is way easier and the rough picture for this -// is explained below. -// -// If you enable a local name server, don't forget to enter 127.0.0.1 -// into your /etc/resolv.conf so this server will be queried first. -// Also, make sure to enable it in /etc/rc.conf. - -zone "." { - type hint; - file "named.root"; -}; - -zone "0.0.127.IN-ADDR.ARPA" { - type master; - file "localhost.rev"; -}; - -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.IP6.INT" { - type master; - file "localhost.rev"; -}; - -// NB: Do not use the IP addresses below, they are faked, and only -// serve demonstration/documentation purposes! -// -// Example secondary config entries. It can be convenient to become -// a secondary at least for the zone where your own domain is in. Ask -// your network administrator for the IP address of the responsible -// primary. -// -// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone! -// (This is the first bytes of the respective IP address, in reverse -// order, with ".IN-ADDR.ARPA" appended.) -// -// Before starting to setup a primary zone, better make sure you fully -// understand how DNS and BIND works, however. There are sometimes -// unobvious pitfalls. Setting up a secondary is comparably simpler. -// -// NB: Don't blindly enable the examples below. :-) Use actual names -// and addresses instead. -// -// NOTE!!! FreeBSD runs bind in a sandbox (see named_flags in rc.conf). -// The directory containing the secondary zones must be write accessible -// to bind. The following sequence is suggested: -// -// mkdir /etc/namedb/s -// chown bind:bind /etc/namedb/s -// chmod 750 /etc/namedb/s - - For more information on running BIND in a sandbox, see - Running named in a sandbox. - - - /* -zone "example.com" { - type slave; - file "s/example.com.bak"; - masters { - 192.168.1.1; - }; -}; - -zone "0.168.192.in-addr.arpa" { - type slave; - file "s/0.168.192.in-addr.arpa.bak"; - masters { - 192.168.1.1; - }; -}; -*/ - In named.conf, these are examples of slave - entries for a forward and reverse zone. - - For each new zone served, a new zone entry must be added to - named.conf - - For example, the simplest zone entry for - example.org can look like: - - zone "example.org" { - type master; - file "example.org"; -}; - - The zone is a master, as indicated by the - statement, holding its zone information in - /etc/namedb/example.org indicated by - the statement. - - zone "example.org" { - type slave; - file "example.org"; -}; - - In the slave case, the zone information is transferred from - the master name server for the particular zone, and saved in the - file specified. If and when the master server dies or is - unreachable, the slave name server will have the transferred - zone information and will be able to serve it. - - - - Zone Files - - An example master zone file for example.org - (existing within /etc/namedb/example.org) - is as follows: - - - $TTL 3600 - -example.org. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial - 10800 ; Refresh - 3600 ; Retry - 604800 ; Expire - 86400 ) ; Minimum TTL - -; DNS Servers -@ IN NS ns1.example.org. -@ IN NS ns2.example.org. - -; Machine Names -localhost IN A 127.0.0.1 -ns1 IN A 3.2.1.2 -ns2 IN A 3.2.1.3 -mail IN A 3.2.1.10 -@ IN A 3.2.1.30 - -; Aliases -www IN CNAME @ - -; MX Record -@ IN MX 10 mail.example.org. - - - Note that every hostname ending in a . is an - exact hostname, whereas everything without a trailing - . is referenced to the origin. For example, - www is translated into www + - origin. In our fictitious zone file, our origin - is example.org., so - www would translate to - www.example.org. - - - - The format of a zone file follows: - - recordname IN recordtype value - - - DNS - records - - - The most commonly used DNS records: - - - - - SOA - - start of zone authority - - - - NS - - an authoritative name server - - - - A - - A host address - - - - CNAME - - the canonical name for an alias - - - - MX - - mail exchanger - - - - PTR - - a domain name pointer (used in reverse DNS) - - - - - -example.org. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial - 10800 ; Refresh after 3 hours - 3600 ; Retry after 1 hour - 604800 ; Expire after 1 week - 86400 ) ; Minimum TTL of 1 day - - - - - - example.org. - - the domain name, also the origin for this - zone file. - - - - ns1.example.org. - - the primary/authoritative name server for this - zone - - - - admin.example.org. - - the responsible person for this zone, - email address with @ - replaced. (admin@example.org becomes - admin.example.org) - - - - - 5 - - the serial number of the file. this - must be incremented each time the zone file is modified. - Nowadays, many admins prefer a - yyyymmddrr format for the serial - number. 2001041002 would mean last modified 04/10/2001, - the latter 02 being the second time the zone file has - been modified this day. The serial number is important - as it alerts slave name servers for a zone when it is - updated. - - - - - -@ IN NS ns1.example.org. - - - This is an NS entry. Every name server that is going to reply - authoritatively for the zone must have one of these entries. - The @ as seen here could have been - example.org. - The @ translates to the origin. - - - -localhost IN A 127.0.0.1 -ns1 IN A 3.2.1.2 -ns2 IN A 3.2.1.3 -mail IN A 3.2.1.10 -@ IN A 3.2.1.30 - - - The A record indicates machine names. As seen above, - ns1.example.org would resolve to - 3.2.1.2. Again, - the origin symbol, @, is - used here, thus meaning example.org - would resolve to 3.2.1.30. - - - -www IN CNAME @ - - - The canonical name record is usually used for giving aliases - to a machine. In the example, www is - aliased to the machine addressed to the origin, or - example.org - (3.2.1.30). - CNAMEs can be used to provide alias - hostnames, or round robin one hostname among multiple - machines. - - - -@ IN MX 10 mail.example.org. - - - The MX record indicates which mail - servers are responsible for handling incoming mail for the - zone. mail.example.org is the - hostname of the mail server, and 10 being the priority of - that mail server. - - - - One can have several mail servers, with priorities of 3, 2, - 1. A mail server attempting to deliver to example.org would first try the - highest priority MX, then the second highest, etc, until the - mail can be properly delivered. - - - - For in-addr.arpa zone files (reverse DNS), the same format is - used, except with PTR entries instead of - A or CNAME. - - - $TTL 3600 - -1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial - 10800 ; Refresh - 3600 ; Retry - 604800 ; Expire - 3600 ) ; Minimum - -@ IN NS ns1.example.org. -@ IN NS ns2.example.org. - -2 IN PTR ns1.example.org. -3 IN PTR ns2.example.org. -10 IN PTR mail.example.org. -30 IN PTR example.org. - - This file gives the proper IP address to hostname mappings of our above - fictitious domain. - - - - - - Caching Name Server - - BIND - caching name server - - - A caching name server is a name server that is not - authoritative for any zones. It simply asks queries of its own, - and remembers them for later use. To set one up, just configure - the name server as usual, omitting any inclusions of zones. - - - - - Running <application>named</application> in a Sandbox - - BIND - running in a sandbox - - - - chroot - - For added security you may want to run &man.named.8; as an - unprivileged user, and configure it to &man.chroot.8; into a - sandbox directory. This makes everything outside of the sandbox - inaccessible to the named daemon. Should - named be compromised, this will help to - reduce the damage that can be caused. By default, FreeBSD has a user - and a group called bind, intended for this - use. - - Various people would recommend that instead of configuring - named to chroot, you - should run named inside a &man.jail.8;. - This section does not attempt to cover this situation. - - - Since named will not be able to - access anything outside of the sandbox (such as shared - libraries, log sockets, and so on), there are a number of steps - that need to be followed in order to allow - named to function correctly. In the - following checklist, it is assumed that the path to the sandbox - is /etc/namedb and that you have made no - prior modifications to the contents of this directory. Perform - the following steps as root. - - - - Create all directories that named - expects to see: - - &prompt.root; cd /etc/namedb -&prompt.root; mkdir -p bin dev etc var/tmp var/run master slave -&prompt.root; chown bind:bind slave var/* - - - - - - named only needs write access to - these directories, so that is all we give it. - - - - - - Rearrange and create basic zone and configuration files: - &prompt.root; cp /etc/localtime etc -&prompt.root; mv named.conf etc && ln -sf etc/named.conf -&prompt.root; mv named.root master - -&prompt.root; sh make-localhost && mv localhost.rev localhost-v6.rev master -&prompt.root; cat > master/named.localhost -$ORIGIN localhost. -$TTL 6h -@ IN SOA localhost. postmaster.localhost. ( - 1 ; serial - 3600 ; refresh - 1800 ; retry - 604800 ; expiration - 3600 ) ; minimum - IN NS localhost. - IN A 127.0.0.1 -^D - - - - This allows named to log the - correct time to &man.syslogd.8; - - - - - - Build a statically linked copy of - named-xfer, and copy it into the sandbox: - - &prompt.root; cd /usr/src/lib/libisc -&prompt.root; make cleandir && make cleandir && make depend && make all -&prompt.root; cd /usr/src/lib/libbind -&prompt.root; make cleandir && make cleandir && make depend && make all -&prompt.root; cd /usr/src/libexec/named-xfer -&prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all -&prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer - - After your statically linked - named-xfer is installed some cleaning up - is required, to avoid leaving stale copies of libraries or - programs in your source tree: - - &prompt.root; cd /usr/src/lib/libisc -&prompt.root; make cleandir -&prompt.root; cd /usr/src/lib/libbind -&prompt.root; make cleandir -&prompt.root; cd /usr/src/libexec/named-xfer -&prompt.root; make cleandir - - - - This step has been reported to fail occasionally. If this - happens to you, then issue the command: - - &prompt.root; cd /usr/src && make cleandir && make cleandir - - and delete your /usr/obj tree: - - &prompt.root; rm -fr /usr/obj && mkdir /usr/obj - - This will clean out any cruft from your - source tree, and retrying the steps above should then work. - - - - - - Make a dev/null that - named can see and write to: - - &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 -&prompt.root; chmod 666 null - - - - Symlink /var/run/ndc to - /etc/namedb/var/run/ndc: - - &prompt.root; ln -sf /etc/namedb/var/run/ndc /var/run/ndc - - - This simply avoids having to specify the - option to &man.ndc.8; every time you - run it. Since the contents of /var/run are deleted on boot, - if this is something that you find useful you - may wish to add this command to root's crontab, making use - of the option. See - &man.crontab.5; for more information regarding - this. - - - - - - Configure &man.syslogd.8; to create an extra - log socket that - named can write to. To do this, - add -l /etc/namedb/dev/log to the - syslogd_flags variable in - /etc/rc.conf. - - - - Arrange to have named start - and chroot itself to the sandbox by - adding the following to - /etc/rc.conf: - - named_enable="YES" -named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" - - - Note that the configuration file - /etc/named.conf is denoted by a full - pathname relative to the sandbox, i.e. in - the line above, the file referred to is actually - /etc/namedb/etc/named.conf. - - - - - The next step is to edit - /etc/namedb/etc/named.conf so that - named knows which zones to load and - where to find them on the disk. There follows a commented - example (anything not specifically commented here is no - different from the setup for a DNS server not running in a - sandbox): - - options { - directory "/"; - named-xfer "/bin/named-xfer"; - version ""; // Don't reveal BIND version - query-source address * port 53; -}; -// ndc control socket -controls { - unix "/var/run/ndc" perm 0600 owner 0 group 0; -}; -// Zones follow: -zone "localhost" IN { - type master; - file "master/named.localhost"; - allow-transfer { localhost; }; - notify no; -}; -zone "0.0.127.in-addr.arpa" IN { - type master; - file "master/localhost.rev"; - allow-transfer { localhost; }; - notify no; -}; -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.ip6.int" { - type master; - file "master/localhost-v6.rev"; - allow-transfer { localhost; }; - notify no; -}; -zone "." IN { - type hint; - file "master/named.root"; -}; -zone "private.example.net" in { - type master; - file "master/private.example.net.db"; - allow-transfer { 192.168.10.0/24; }; -}; -zone "10.168.192.in-addr.arpa" in { - type slave; - masters { 192.168.10.2; }; - file "slave/192.168.10.db"; -}; - - - - The - directory statement is specified as - /, since all files that - named needs are within this - directory (recall that this is equivalent to a - normal user's - /etc/namedb. - - - - Specifies the full path - to the named-xfer binary (from - named's frame of reference). This - is necessary since named is - compiled to look for named-xfer in - /usr/libexec by default. - - Specifies the filename (relative - to the directory statement above) where - named can find the zonefile for this - zone. - - Specifies the filename - (relative to the directory statement above) - where named should write a copy of - the zonefile for this zone after successfully transferring it - from the master server. This is why we needed to change the - ownership of the directory slave to - bind in the setup stages above. - - - - After completing the steps above, either reboot your - server or restart &man.syslogd.8; and start &man.named.8;, making - sure to use the new options specified in - syslogd_flags and - named_flags. You should now be running a - sandboxed copy of named! - - - - - Security - - Although BIND is the most common implementation of DNS, - there is always the issue of security. Possible and - exploitable security holes are sometimes found. - - - - It is a good idea to subscribe to CERT and - freebsd-security-notifications - to stay up to date with the current Internet and FreeBSD security - issues. - - - If a problem arises, keeping sources up to date and having a - fresh build of named would not hurt. - - - - Further Reading - - BIND/named manual pages: &man.ndc.8; &man.named.8; &man.named.conf.5; - - - - - Official ISC Bind - Page - - - - - BIND FAQ - - - - O'Reilly - DNS and BIND 4th Edition - - - - RFC1034 - - Domain Names - Concepts and Facilities - - - - RFC1035 - - Domain Names - Implementation and Specification - - - - - - - - - - Tom - Hukins - Contributed by - - - - NTP - - NTP - - - Overview - - Over time, a computer's clock is prone to drift. As time - passes, the computer's clock becomes less accurate. NTP - (Network Time Protocol) is one way to ensure your clock is - right. - - Many Internet services rely on, or greatly benefit from, - computers' clocks being accurate. For example, a Web server - may receive requests to send a file if it has modified since a - certain time. Services such as &man.cron.8; run commands at a - given time. If the clock is inaccurate, these commands may - not run when expected. - - - NTP - ntpd - - FreeBSD ships with the &man.ntpd.8; NTP server which can - be used to query other NTP servers to set the clock on your - machine or provide time services to others. - - - - Choosing Appropriate NTP Servers - - - NTP - choosing servers - - - In order to synchronize your clock, you will need to find - one or more NTP servers to use. Your network administrator or - ISP may have setup an NTP server for this purpose—check - their documentation to see if this is the case. There is a - list of - publicly accessible NTP servers which you can use to - find an NTP server near to you. Make sure you are aware of - the policy for any servers you choose, and ask for permission - if required. - - Choosing several unconnected NTP servers is a good idea in - case one of the servers you are using becomes unreachable or - its clock is unreliable. &man.ntpd.8; uses the responses it - receives from other servers intelligently—it will favor - unreliable servers less than reliable ones. - - - - Configuring Your Machine - - - NTP - configuration - - - - Basic Configuration - ntpdate - - If you only wish to synchronize your clock when the - machine boots up, you can use &man.ntpdate.8;. This may be - appropriate for some desktop machines which are frequently - rebooted and only require infrequent synchronization, but - most machines should run &man.ntpd.8;. - - Using &man.ntpdate.8; at boot time is also a good idea - for machines that run &man.ntpd.8;. &man.ntpd.8; changes the - clock gradually, whereas &man.ntpdate.8; sets the clock, no - matter how great the difference between a machine's current - clock setting and the correct time. - - To enable &man.ntpdate.8; at boot time, add - ntpdate_enable="YES" to - /etc/rc.conf. You will also need to - specify all servers you wish to synchronize with and any - flags to be passed to &man.ntpdate.8; in - ntpdate_flags. - - - - - NTP - ntp.conf - - - General Configuration - - NTP is configured by the - /etc/ntp.conf file in the format - described in &man.ntp.conf.5;. Here is a simple - example: - - server ntplocal.example.com prefer -server timeserver.example.org -server ntp2a.example.net - -driftfile /var/db/ntp.drift - - The server option specifies which - servers are to be used, with one server listed on each line. - If a server is specified with the prefer - argument, as with ntplocal.example.com, that server is - preferred over other servers. A response from a preferred - server will be discarded if it differs significantly from - other servers' responses, otherwise it will be used without - any consideration to other responses. The - prefer argument is normally used for NTP - servers that are known to be highly accurate, such as those - with special time monitoring hardware. - - The driftfile option specifies which - file is used to store the system clock's frequency offset. - &man.ntpd.8; uses this to automatically compensate for the - clock's natural drift, allowing it to maintain a reasonably - correct setting even if it is cut off from all external time - sources for a period of time. - - The driftfile option specifies which - file is used to store information about previous responses - from the NTP servers you are using. This file contains - internal information for NTP. It should not be modified by - any other process. - - - - Controlling Access to Your Server - - By default, your NTP server will be accessible to all - hosts on the Internet. The restrict - option in &man.ntp.conf.5; allows you to control which - machines can access your server. - - If you want to deny all machines from accessing your NTP - server, add the following line to - /etc/ntp.conf - - restrict default ignore - - If you only want to - allow machines within your own network to synchronize their - clocks with your server, but ensure they are not allowed to - configure the server or used as peers to synchronize - against, add - - restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap - - instead, where 192.168.1.0 is - an IP address on your network and 255.255.255.0 is your network's - netmask. - - /etc/ntp.conf can contain multiple - restrict options. For more details, see - the Access Control Support subsection of - &man.ntp.conf.5;. - - - - - Running the NTP Server - - To ensure the NTP server is started at boot time, add the - line xntpd_enable="YES" to - /etc/rc.conf. If you wish to pass - additional flags to &man.ntpd.8; edit the - xntpd_flags parameter in - /etc/rc.conf. - - To start the server without rebooting your machine, run - ntpd being sure to specify any additional - parameters from xntpd_flags in - /etc/rc.conf. For example: - &prompt.root; ntpd -p /var/run/ntpd.pid - - - - Using &man.ntpd.8; with a Temporary Internet - Connection - - ntpd does not need a permanent - connection to the Internet to function properly. However, if - you have a temporary connection that is configured to dial out - on demand, it is a good idea to prevent NTP traffic from - triggering a dial out or keeping the connection alive. If you - are using user PPP, you can use filter - directives in /etc/ppp/ppp.conf. For - example: - - set filter dial 0 deny udp src eq 123 - # Prevent NTP traffic from initiating dial out - set filter dial 1 permit 0 0 - set filter alive 0 deny udp src eq 123 - # Prevent incoming NTP traffic from keeping the connection open - set filter alive 1 deny udp dst eq 123 - # Prevent outgoing NTP traffic from keeping the connection open - set filter alive 2 permit 0/0 0/0 - - For more details see the PACKET - FILTERING section in &man.ppp.8; and the examples in - /usr/share/examples/ppp/. - - - Some Internet access providers block low-numbered ports, - preventing NTP from functioning since replies never - reach your machine. - - - - - Further Information - - Documentation for the NTP server can be found in - /usr/share/doc/ntp/ in HTML - format. - - - - - - - - Chern - Lee - Contributed by - - - - Network Address Translation - - - Overview - - natd - - FreeBSD's Network Address Translation daemon, commonly known as - &man.natd.8; is a daemon that accepts incoming raw IP packets, - changes the source to the local machine and re-injects these packets - back into the outgoing IP packet stream. natd does this by changing - the source IP address and port such that when data is received back, - it is able to determine the original location of the data and forward - it back to its original requester. - Internet connection sharing - IP masquerading - The most common use of NAT is to perform what is commonly known as - Internet Connection Sharing. - - - - Setup - Due to the diminishing IP space in IPv4, and the increased number - of users on high-speed consumer lines such as cable or DSL, people are - increasingly in need of an Internet Connection Sharing solution. The - ability to connect several computers online through one connection and - IP address makes &man.natd.8; a reasonable choice. - - Most commonly, a user has a machine connected to a cable or DSL - line with one IP address and wishes to use this one connected computer to - provide Internet access to several more over a LAN. - - To do this, the FreeBSD machine on the Internet must act as a - gateway. This gateway machine must have two NICs--one for connecting - to the Internet router, the other connecting to a LAN. All the - machines on the LAN are connected through a hub or switch. - - - - - - - - _______ __________ ________ - | | | | | | - | Hub |-----| Client B |-----| Router |----- Internet - |_______| |__________| |________| - | - ____|_____ -| | -| Client A | -|__________| - - - - Network Layout - - - - A setup like this is commonly used to share an Internet - connection. One of the LAN machines is - connected to the Internet. The rest of the machines access - the Internet through that gateway - machine. - - - - - kernel - configuration - - Configuration - The following options must be in the kernel configuration - file: - options IPFIREWALL -options IPDIVERT - - Additionally, at choice, the following may also be suitable: - options IPFIREWALL_DEFAULT_TO_ACCEPT -options IPFIREWALL_VERBOSE - - The following must be in /etc/rc.conf: - - gateway_enable="YES" -firewall_enable="YES" -firewall_type="OPEN" -natd_enable="YES" -natd_interface="fxp0" -natd_flags="" - - - - - - gateway_enable="YES" - Sets up the machine to act as a gateway. Running - sysctl net.inet.ip.forwarding=1 - would have the same effect. - - firewall_enable="YES" - Enables the firewall rules in - /etc/rc.firewall at boot. - - firewall_type="OPEN" - This specifies a predefined firewall ruleset that - allows anything in. See - /etc/rc.firewall for additional - types. - - - natd_interface="fxp0" - Indicates which interface to forward packets through - (the interface connected to the Internet). - - - natd_flags="" - Any additional configuration options passed to - &man.natd.8; on boot. - - - - - - Having the previous options defined in - /etc/rc.conf would run - natd -interface fxp0 at boot. This can also - be run manually. - - Each machine and interface behind the LAN should be - assigned IP address numbers in the private network space as - defined by RFC 1918 - and have a default gateway of the natd machine's internal IP - address. - - For example, client a and - b behind the LAN have IP addresses of 192.168.0.2 and 192.168.0.3, while the natd machine's - LAN interface has an IP address of 192.168.0.1. Client a - and b's default gateway must be set to that - of the natd machine, 192.168.0.1. The natd machine's - external, or Internet interface does not require any special - modification for natd to work. - - - - Port Redirection - - The drawback with natd is that the LAN clients are not accessible - from the Internet. Clients on the LAN can make outgoing connections to - the world but cannot receive incoming ones. This presents a problem - if trying to run Internet services on one of the LAN client machines. - A simple way around this is to redirect selected Internet ports on the - natd machine to a LAN client. - - - For example, an IRC server runs on Client A, and a web server runs - on Client B. For this to work properly, connections received on ports - 6667 (IRC) and 80 (web) must be redirected to the respective machines. - - - The -redirect_port must be passed to - &man.natd.8; with the proper options. The syntax is as follows: - -redirect_port proto targetIP:targetPORT[-targetPORT] - [aliasIP:]aliasPORT[-aliasPORT] - [remoteIP[:remotePORT[-remotePORT]]] - - In the above example, the argument should be: - -redirect_port tcp 192.168.0.2:6667 6667 - -redirect_port tcp 192.168.0.3:80 80 - This will redirect the proper tcp ports to the - LAN client machines. - - - The -redirect_port argument can be used to indicate port - ranges over individual ports. For example, tcp - 192.168.0.2:2000-3000 2000-3000 would redirect - all connections received on ports 2000 to 3000 to ports 2000 - to 3000 on Client A. - - These options can be used when directly running - &man.natd.8; or placed within the - natd_flags="" option in - /etc/rc.conf. - - For further configuration options, consult &man.natd.8; - - - - Address Redirection - address redirection - Address redirection is useful if several IP addresses are - available, yet they must be on one machine. With this, - &man.natd.8; can assign each LAN client its own external IP address. - &man.natd.8; then rewrites outgoing packets from the LAN clients - with the proper external IP address and redirects - all traffic incoming on that particular IP address back to - the specific LAN client. This is also known as static NAT. - For example, the IP addresses 128.1.1.1, - 128.1.1.2, and - 128.1.1.3 belong to the natd gateway - machine. 128.1.1.1 can be used - as the natd gateway machine's external IP address, while - 128.1.1.2 and - 128.1.1.3 are forwarded back to LAN - clients A and B. - - The -redirect_address syntax is as follows: - - - - - - - - localIP - The internal IP address of the LAN client. - - - publicIP - The external IP address corresponding to the LAN client. - - - - - - In the example, this argument would read: - - - Like -redirect_port, these arguments are also placed within - natd_flags of /etc/rc.conf. With address - redirection, there is no need for port redirection since all data - received on a particular IP address is redirected. - - The external IP addresses on the natd machine must be active and aliased - to the external interface. Look at &man.rc.conf.5; to do so. - - - - - - - - - Chern - Lee - Contributed by - - - - - The <application>inetd</application> <quote>Super-Server</quote> - - - Overview - - &man.inetd.8; is referred to as the Internet - Super-Server because it manages connections for several - daemons. Programs that provide network service are commonly - known as daemons. inetd serves as a - managing server for other daemons. When a connection is - received by inetd, it determines - which daemon the connection is destined for, spawns the - particular daemon and delegates the socket to it. Running one - instance of inetd reduces the overall - system load as compared to running each daemon individually in - stand-alone mode. - - Primarily, inetd is used to - spawn other daemons, but several trivial protocols are handled - directly, such as chargen, - auth, and - daytime. - - This section will cover the basics in configuring - inetd through its command-line - options and its configuration file, - /etc/inetd.conf. - - - - Settings - - inetd is initialized through - the /etc/rc.conf system. The - inetd_enable option is set to - NO by default, but is often times turned on by - sysinstall with the medium security - profile. Placing: - inetd_enable="YES" or - inetd_enable="NO" into - /etc/rc.conf can enable or disable - inetd starting at boot time. - - Additionally, different command-line options can be passed - to inetd via the - inetd_flags option. - - - - Command-Line Options - - inetd synopsis: - - - - - - -d - - - Turn on debugging. - - - - - -l - - - Turn on logging of successful connections. - - - - - -w - - - Turn on TCP Wrapping for external services (on by - default). - - - - - -W - - - Turn on TCP Wrapping for internal services which are - built into inetd (on by - default). - - - - - -c maximum - - - Specify the default maximum number of simultaneous - invocations of each service; the default is unlimited. - May be overridden on a per-service basis with the - parameter. - - - - - -C rate - - - Specify the default maximum number of times a - service can be invoked from a single IP address in one - minute; the default is unlimited. May be overridden on a - per-service basis with the - - parameter. - - - - - -R rate - - - Specify the maximum number of times a service can be - invoked in one minute; the default is 256. A rate of 0 - allows an unlimited number of invocations. - - - - - -a - - - Specify one specific IP address to bind to. - Alternatively, a hostname can be specified, in which case - the IPv4 or IPv6 address which corresponds to that - hostname is used. Usually a hostname is specified when - inetd is run inside a - &man.jail.8;, in which case the hostname corresponds to - the &man.jail.8; environment. - - When hostname specification is used and both IPv4 - and IPv6 bindings are desired, one entry with the - appropriate protocol type for each binding is required for - each service in /etc/inetd.conf. For - example, a TCP-based service would need two entries, one - using tcp4 for the protocol and the other using - tcp6. - - - - - -p - - - Specify an alternate file in which to store the - process ID. - - - - - These options can be passed to - inetd using the - inetd_flags option in - /etc/rc.conf. By default, - inetd_flags is set to -wW, - which turns on TCP wrapping for - inetd's internal and external - services. For novice users, these parameters usually do not need - to be modified or even entered in - /etc/rc.conf. - - - An external service is a daemon outside of - inetd, which is invoked when a - connection is received for it. On the other hand, an internal - service is one that inetd has the - facility of offering within itself. - - - - - - <filename>inetd.conf</filename> - - Configuration of inetd is - controlled through the /etc/inetd.conf - file. - - When a modification is made to - /etc/inetd.conf, - inetd can be forced to re-read its - configuration file by sending a HangUP signal to the - inetd process as shown: - - - Sending <application>inetd</application> a HangUP Signal - - &prompt.root; kill -HUP `cat /var/run/inetd.pid` - - - Each line of the configuration file specifies an - individual daemon. Comments in the file are preceded by a - #. The format of - /etc/inetd.conf is as follows: - - service-name -socket-type -protocol -{wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] -user[:group][/login-class] -server-program -server-program-arguments - - An example entry for the ftpd daemon - using IPv4: - - ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l - - - - service-name - - - This is the service name of the particular daemon. - It must correspond to a service listed in - /etc/services. This determines which - port inetd must listen to. If - a new service is being created, it must be placed in - /etc/services - first. - - - - - socket-type - - - Either stream, - dgram, raw, or - seqpacket. stream - must be used for connection-based, TCP daemons, while - dgram is used for daemons utilizing the - UDP transport protocol. - - - - - protocol - - - One of the following: - - - - - - Protocol - Explanation - - - - - tcp, tcp4 - TCP IPv4 - - - udp, udp4 - UDP IPv4 - - - tcp6 - TCP IPv6 - - - udp6 - UDP IPv6 - - - tcp46 - Both TCP IPv4 and v6 - - - udp46 - Both UDP IPv4 and v6 - - - - - - - - - {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] - - - indicates whether the - daemon invoked from inetd is - able to handle its own socket or not. - socket types must use the wait - option, while stream socket daemons, which are usually - multi-threaded, should use . - usually hands off multiple sockets - to a single daemon, while spawns a - child daemon for each new socket. - - The maximum number of child daemons - inetd may spawn can be set using - the option. If a limit of ten - instances of a particular daemon is needed, a - /10 would be placed after - . - - In addition to , another - option limiting the maximum connections from a single - place to a particular daemon can be enabled. - does - just this. A value of ten here would limit any particular - IP address connecting to a particular service to ten - attempts per minute. This is useful to prevent - intentional or unintentional resource consumption and - Denial of Service (DoS) attacks to a machine. - - In this field, or - is mandatory. - and - are - optional. - - A stream-type multi-threaded daemon without any - or - limits - would simply be: nowait - - The same daemon with a maximum limit of ten daemons - would read: nowait/10 - - Additionally, the same setup with a limit of twenty - connections per IP address per minute and a maximum - total limit of ten child daemons would read: - nowait/10/20 - - These options are all utilized by the default - settings of the fingerd daemon, - as seen here: - - finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s - - - - - user - - - The user is the username that the particular daemon - should run as. Most commonly, daemons run as the - root user. For security purposes, it is - common to find some servers running as the - daemon user, or the least privileged - nobody user. - - - - - server-program - - - The full path of the daemon to be executed when a - connection is received. If the daemon is a service - provided by inetd internally, - then should be - used. - - - - - server-program-arguments - - - This works in conjunction with - by specifying the - arguments, starting with argv[0], passed to the daemon on - invocation. If mydaemon -d is - the command line, mydaemon -d would be - the value of . - Again, if the daemon is an internal service, use - here. - - - - - - - Security - - Depending on the security profile chosen at install, many - of inetd's daemons may be enabled by - default. If there is no apparent need for a particular daemon, - disable it! Place a # in front of the daemon in - question, and send a hangup signal - to inetd. - Some daemons, such as fingerd, may - not be desired at all because they provide an attacker with too - much information. - - Some daemons are not security-conscious and have long, or - non-existent timeouts for connection attempts. This allows an - attacker to slowly send connections to a particular daemon, thus - saturating available resources. It may be a good idea to place - and - limitations on certain daemons. - - By default, TCP wrapping is turned on. Consult the - &man.hosts.access.5; manual page for more information on placing - TCP restrictions on various inetd - invoked daemons. - - - - Miscellaneous - - daytime, - time, - echo, - discard, - chargen, and - auth are all internally provided - services of inetd. - - The auth service provides identity - (ident, identd) network services, and is configurable to a certain - degree. - - Consult the &man.inetd.8; manual page for more in-depth - information. - - - - - Parallel Line IP (PLIP) - - PLIP - Parallel Line IP - - PLIP lets us run TCP/IP between parallel ports. It is - useful on machines without network cards, or to install on - laptops. In this section, we will discuss: - - - - Creating a parallel (laplink) cable. - - - - Connecting two computers with PLIP. - - - - - Creating a Parallel Cable - - You can purchase a parallel cable at most computer supply - stores. If you cannot do that, or you just want to know how - it is done, the following table shows how to make one out of a normal parallel - printer cable. - - - Wiring a Parallel Cable for Networking - - - - - A-name - - A-End - - B-End - - Descr. - - Post/Bit - - - - - - DATA0 --ERROR - - 2 -15 - - 15 -2 - - Data - - 0/0x01 -1/0x08 - - - - DATA1 -+SLCT - - 3 -13 - - 13 -3 - - Data - - 0/0x02 -1/0x10 - - - - DATA2 -+PE - - 4 -12 - - 12 -4 - - Data - - 0/0x04 -1/0x20 - - - - DATA3 --ACK - - 5 -10 - - 10 -5 - - Strobe - - 0/0x08 -1/0x40 - - - - DATA4 -BUSY - - 6 -11 - - 11 -6 - - Data - - 0/0x10 -1/0x80 - - - - GND - - 18-25 - - 18-25 - - GND - - - - - - -
- - - - Setting Up PLIP - - Get a laplink cable. - - Confirm that both computers have a kernel with &man.lpt.4; driver - support. - - &prompt.root; grep lp /var/run/dmesg.boot -lpt0 at 0x378-0x37f irq 7 on isa -lpt0: Interrupt-driven -lp0: TCP/IP capable interface - - Plug in the laplink cable into the parallel interface on - both computers. - - Configure the network interface parameters for lp0 on both - sites as root. For example, if you want connect - the host host1 with host2: - - host1 <-----> host2 -IP Address 10.0.0.1 10.0.0.2 - - Configure the interface on host1 by doing: - - &prompt.root; ifconfig lp0 10.0.0.1 10.0.0.2 - - Configure the interface on host2 by doing: - - &prompt.root; ifconfig lp0 10.0.0.2 10.0.0.1 - - - You now should have a working connection. Please read the - manual pages &man.lp.4; and &man.lpt.4; for more details. - - You should also add both hosts to - /etc/hosts: - - 127.0.0.1 localhost.my.domain localhost -10.0.0.1 host1.my.domain host1 -10.0.0.2 host2.my.domain - - To confirm the connection works, go to each host and ping - the other. For example, on host1: - - &prompt.root; ifconfig lp0 -lp0: flags=8851<UP,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1500 - inet 10.0.0.1 --> 10.0.0.2 netmask 0xff000000 -&prompt.root; netstat -r -Routing tables - -Internet: -Destination Gateway Flags Refs Use Netif Expire -host2 host1 UH 4 127592 lp0 -&prompt.root; ping -c 4 host2 -PING host2 (10.0.0.2): 56 data bytes -64 bytes from 10.0.0.2: icmp_seq=0 ttl=255 time=2.774 ms -64 bytes from 10.0.0.2: icmp_seq=1 ttl=255 time=2.530 ms -64 bytes from 10.0.0.2: icmp_seq=2 ttl=255 time=2.556 ms -64 bytes from 10.0.0.2: icmp_seq=3 ttl=255 time=2.714 ms - ---- host2 ping statistics --- -4 packets transmitted, 4 packets received, 0% packet loss -round-trip min/avg/max/stddev = 2.530/2.643/2.774/0.103 ms - - - - - - - - - Aaron - Kaplan - Originally Written by - - - - - Tom - Rhodes - Restructured and Added by - - - - - IPv6 - IPv6 (also know as IPng IP next generation) is - the new version of the well known IP protocol (also know as - IPv4). Like the other current *BSD systems, - FreeBSD includes the KAME IPv6 reference implementation. - So your FreeBSD system comes with all you will need to experiment with IPv6. - This section focuses on getting IPv6 configured and running. - - In the early 1990s, people became aware of the rapidly - diminishing address space of IPv4. Given the expansion rate of the - Internet there were two major concerns: - - - - Running out of addresses. Today this is not so much of a concern - anymore since private address spaces - (10.0.0.0/8, - 192.168.0.0/24, - etc.) and Network Address Translation (NAT) are - being employed. - - - - Router table entries were getting too large. This is - still a concern today. - - - - IPv6 deals with these and many other issues: - - - - 128 bit address space. In other words theoretically there are - 340,282,366,920,938,463,463,374,607,431,768,211,456 addresses - available. This means there are approximately - 6.67 * 10^27 IPv6 addresses per square meter on our planet. - - - - Routers will only store network aggregation addresses in their routing - tables thus reducing the average space of a routing table to 8192 - entries. - - - - There are also lots of other useful features of IPv6 such as: - - - - Address autoconfiguration (RFC2462) - - - - Anycast addresses (one-out-of many) - - - - Mandatory multicast addresses - - - - IPsec (IP security) - - - - Simplified header structure - - - - Mobile IP - - - - IPv4-to-IPv6 transition mechanisms - - - - - For more information see: - - - - IPv6 overview at Sun.com - - - - IPv6.org - - - - KAME.net - - - - 6bone.net - - - - - Background on IPv6 Addresses - There are different types of IPv6 addresses: Unicast, Anycast and - Multicast. - - Unicast addresses are the well known addresses. A packet sent - to a unicast address arrives exactly at the interface belonging to - the address. - - Anycast addresses are syntactically indistinguishable from unicast - addresses but they address a group of interfaces. The packet destined for - an anycast address will arrive at the nearest (in router metric) - interface. Anycast addresses may only be used by routers. - - Multicast addresses identify a group of interfaces. A packet destined - for a multicast address will arrive at all interfaces belonging to the - multicast group. - - The IPv4 broadcast address (usually xxx.xxx.xxx.255) is expressed - by multicast addresses in IPv6. - - Reserved IPv6 addresses: - -ipv6-address prefixlength(Bits) description Notes - - :: 128 Bits unspecified cf. 0.0.0.0 in IPv4 address - ::1 128 Bits loopback address cf. 127.0.0.1 in IPv4 - ::00:xx:xx:xx:xx 96 Bits embedded IPv4 The lower 32 bits are the - address IPv4 address. Also called - IPv4 compatible IPv6 - address - ::ff:xx:xx:xx:xx 96 Bits IPv4 mapped The lower 32 bits are the - IPv6 address IPv4 address. For hosts - which do not support IPv6 - fe80:: - feb:: 10 Bits link-local cf. loopback address in - IPv4 - fec0:: - fef:: 10 Bits site-local - ff:: 8 Bits multicast - 001 (base 2) 3 Bits global unicast All global unicast - addresses are assigned from - this pool. The first 3 Bits - are 001. - - - - - Reading IPv6 Addresses - The canonical form is represented as: x:x:x:x:x:x:x:x, each - x being a 16 Bit hex value. For example - FEBC:A574:382B:23C1:AA49:4592:4EFE:9982 - - Often an address will have long substrings of all zeros - therefore each such substring can be abbreviated by ::. - For example fe80::1 - corresponds to the canonical form - fe80:0000:0000:0000:0000:0000:0000:0001 - - A third form is to write the last 32 Bit part in the - well known (decimal) IPv4 style with dots . - as separators. For example - 2002::10.0.0.1 - corresponds to the (hexadecimal) canonical representation - 2002:0000:0000:0000:0000:0000:0a00:0001 - which in turn is equivalent to - writing 2002::a00:1 - - By now the reader should be able to understand the following: - - &prompt.root; ifconfig - - rl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 - inet 10.0.0.10 netmask 0xffffff00 broadcast 10.0.0.255 - inet6 fe80::200:21ff:fe03:8e1%rl0 prefixlen 64 scopeid 0x1 - ether 00:00:21:03:08:e1 - media: Ethernet autoselect (100baseTX ) - status: active - - fe80::200:21ff:fe03:8e1%rl0 - is an auto configured link-local address. It includes the - scrambled Ethernet MAC as part of the auto configuration. - - For further information on the structure of IPv6 addresses - see RFC2373. - - - - Getting Connected - - Currently there are four ways to connect to other IPv6 hosts and networks: - - - - Join the experimental 6bone - - - - Getting an IPv6 network from your upstream provider. Talk to your - Internet provider for instructions. - - - - Tunnel via 6-to-4 - - - - Use the freenet6 port if you are on a dial-up connection. - - - - Here we will talk on how to connect to the 6bone since it currently seems - to be the most popular way. - - First take a look at the 6bone site and find a 6bone connection nearest to - you. Write to the responsible person and with a little bit of luck you - will be given instructions on how to set up your connection. Usually this - involves setting up a GRE (gif) tunnel. - - Here is a typical example on setting up a &man.gif.4; tunnel: - - &prompt.root; ifconfig gif0 create -&prompt.root; ifconfig gif0 -gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 -&prompt.root; ifconfig gif0 tunnel MY_IPv4_ADDR HIS_IPv4_ADDR -&prompt.root; ifconfig gif0 inet6 alias MY_ASSIGNED_IPv6_TUNNEL_ENDPOINT_ADDR - - Replace the capitalized words by the information you received from the - upstream 6bone node. - - This establishes the tunnel. Check if the tunnel is working by &man.ping6.8; - 'ing ff02::1%gif0. You should receive two ping replies. - - In case you are intrigued by the address ff02:1%gif0, this is a - multicast address. %gif0 states that the multicast address at network - interface gif0 is to be used. Since we ping a multicast address the - other endpoint of the tunnel should reply as well). - - By now setting up a route to your 6bone uplink should be rather - straightforward: - - &prompt.root; route add -inet6 default -interface gif0 -&prompt.root; ping6 -n MY_UPLINK - - &prompt.root; traceroute6 www.jp.FreeBSD.org -(3ffe:505:2008:1:2a0:24ff:fe57:e561) from 3ffe:8060:100::40:2, 30 hops max, 12 byte packets - 1 atnet-meta6 14.147 ms 15.499 ms 24.319 ms - 2 6bone-gw2-ATNET-NT.ipv6.tilab.com 103.408 ms 95.072 ms * - 3 3ffe:1831:0:ffff::4 138.645 ms 134.437 ms 144.257 ms - 4 3ffe:1810:0:6:290:27ff:fe79:7677 282.975 ms 278.666 ms 292.811 ms - 5 3ffe:1800:0:ff00::4 400.131 ms 396.324 ms 394.769 ms - 6 3ffe:1800:0:3:290:27ff:fe14:cdee 394.712 ms 397.19 ms 394.102 ms - - This output will differ from machine to machine. By now you should be - able to reach the IPv6 site www.kame.net - and see the dancing tortoise - that is if you have a IPv6 enabled browser such as - mozilla. - - - - - DNS in the IPv6 World - There are two new types of DNS records for IPv6: - - - - AAAA records, - - - - A6 records - - - - Using AAAA records is straightforward. Assign your hostname to the new - IPv6 address you just got by adding: - - MYHOSTNAME AAAA MYIPv6ADDR - - To your primary zone DNS file. In case you do not serve your own - DNS zones ask your DNS provider. - Current versions of bind (version 8.3 and 9) - support AAAA records. - - - - - - >Release-Note: >Audit-Trail: >Unformatted: