diff options
Diffstat (limited to 'en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml')
| -rw-r--r-- | en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml | 2746 |
1 files changed, 0 insertions, 2746 deletions
diff --git a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml deleted file mode 100644 index 32c941bb80..0000000000 --- a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml +++ /dev/null @@ -1,2746 +0,0 @@ -<!-- - The FreeBSD Documentation Project - - $FreeBSD: doc/en_US.ISO_8859-1/books/handbook/advanced-networking/chapter.sgml,v 1.31 2000/09/19 17:05:47 ben Exp $ ---> - -<chapter id="advanced-networking"> - <title>Advanced Networking</title> - - <sect1> - <title>Synopsis</title> - - <para>The following chapter will cover some of the more frequently - used network services on UNIX systems. This, of course, will - pertain to configuring said services on your FreeBSD system.</para> - </sect1> - - <sect1 id="routing"> - <title>Gateways and Routes</title> - - <para><emphasis>Contributed by &a.gryphon;. 6 October - 1995.</emphasis></para> - - <para>For one machine to be able to find another, there must be a - mechanism in place to describe how to get from one to the other. This is - called Routing. A <quote>route</quote> is a defined pair of addresses: a - <quote>destination</quote> and a <quote>gateway</quote>. The pair - indicates that if you are trying to get to this - <emphasis>destination</emphasis>, send along through this - <emphasis>gateway</emphasis>. There are three types of destinations: - individual hosts, subnets, and <quote>default</quote>. The - <quote>default route</quote> 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 - <quote>links</quote>), and ethernet hardware addresses.</para> - - <sect2> - <title>An example</title> - - <para>To illustrate different aspects of routing, we will use the - following example which is the output of the command <command>netstat - -r</command>:</para> - - <screen>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 -foobar.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.foobar.com link#1 UC 0 0 -224 link#1 UC 0 0</screen> - - <para>The first two lines specify the default route (which we will cover - in the next section) and the <hostid>localhost</hostid> route.</para> - - <para>The interface (<literal>Netif</literal> column) that it specifies - to use for <literal>localhost</literal> is - <devicename>lo0</devicename>, 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 anyway.</para> - - <para>The next thing that stands out are the <hostid - role="mac">0:e0:...</hostid> addresses. These are ethernet hardware - addresses. FreeBSD will automatically identify any hosts - (<hostid>test0</hostid> in the example) on the local ethernet and add - a route for that host, directly to it over the ethernet interface, - <devicename>ed0</devicename>. There is also a timeout - (<literal>Expire</literal> column) associated with this type of route, - which is used if we fail to hear from the host in a specific amount of - time. In this case the route 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.</para> - - <para>FreeBSD will also add subnet routes for the local subnet (<hostid - role="ipaddr">10.20.30.255</hostid> is the broadcast address for the - subnet <hostid role="ipaddr">10.20.30</hostid>, and <hostid - role="domainname">foobar.com</hostid> is the domain name associated - with that subnet). The designation <literal>link#1</literal> refers - to the first ethernet card in the machine. You will notice no - additional interface is specified for those.</para> - - <para>Both of these groups (local network hosts and local subnets) have - their routes automatically configured by a daemon called - <command>routed</command>. If this is not run, then only routes which - are statically defined (ie. entered explicitly) will exist.</para> - - <para>The <literal>host1</literal> line refers to our host, which it - knows by ethernet address. Since we are the sending host, FreeBSD - knows to use the loopback interface (<devicename>lo0</devicename>) - rather than sending it out over the ethernet interface.</para> - - <para>The two <literal>host2</literal> lines are an example of what - happens when we use an ifconfig alias (see the section of ethernet for - reasons why we would do this). The <literal>=></literal> symbol - after the <devicename>lo0</devicename> interface says that not only - are we using the loopback (since this is 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 <literal>link#1</literal> line for - such.</para> - - <para>The final line (destination subnet <literal>224</literal>) deals - with MultiCasting, which will be covered in a another section.</para> - - <para>The other column that we should talk about are the - <literal>Flags</literal>. Each route has different attributes that - are described in the column. Below is a short table of some of these - flags and their meanings:</para> - - <informaltable frame="none"> - <tgroup cols="2"> - <tbody> - <row> - <entry>U</entry> - <entry>Up: The route is active.</entry> - </row> - - <row> - <entry>H</entry> - <entry>Host: The route destination is a single host.</entry> - </row> - - <row> - <entry>G</entry> - <entry>Gateway: Send anything for this destination on to this - remote system, which will figure out from there where to send - it.</entry> - </row> - - <row> - <entry>S</entry> - <entry>Static: This route was configured manually, not - automatically generated by the system.</entry> - </row> - - <row> - <entry>C</entry> - <entry>Clone: Generates a new route based upon this route for - machines we connect to. This type of route is normally used - for local networks.</entry> - </row> - - <row> - <entry>W</entry> - <entry>WasCloned: Indicated a route that was auto-configured - based upon a local area network (Clone) route.</entry> - </row> - - <row> - <entry>L</entry> - <entry>Link: Route involves references to ethernet - hardware.</entry> - </row> - </tbody> - </tgroup> - </informaltable> - </sect2> - - <sect2> - <title>Default routes</title> - - <para>When the local system needs to make a connection to 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.</para> - - <para>If all known paths fail, the system has one last option: the - <quote>default</quote> route. This route is a special type of gateway - route (usually the only one present in the system), and is always - marked with a <literal>c</literal> 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, or your - hardware device attached to a dedicated data line).</para> - - <para>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.</para> - - <para>Let us look at an example of default routes. This is a common - configuration:</para> - - <literallayout> -[Local2] <--ether--> [Local1] <--PPP--> [ISP-Serv] <--ether--> [T1-GW] - </literallayout> - - <para>The hosts <hostid>Local1</hostid> and <hostid>Local2</hostid> are - at your site, with the formed being your PPP connection to your ISP's - Terminal Server. Your ISP has a local network at their site, which - has, among other things, the server where you connect and a hardware - device (T1-GW) attached to the ISP's Internet feed.</para> - - <para>The default routes for each of your machines will be:</para> - - <informaltable frame="none"> - <tgroup cols="3"> - <thead> - <row> - <entry>host</entry> - <entry>default gateway</entry> - <entry>interface</entry> - </row> - </thead> - - <tbody> - <row> - <entry>Local2</entry> - <entry>Local1</entry> - <entry>ethernet</entry> - </row> - - <row> - <entry>Local1</entry> - <entry>T1-GW</entry> - <entry>PPP</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para>A common question is <quote>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?</quote>.</para> - - <para>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.</para> - - <para>As a final note, it is common to use the address <hostid - role="ipaddr">...1</hostid> as the gateway address for your local - network. So (using the same example), if your local class-C address - space was <hostid role="ipaddr">10.20.30</hostid> and your ISP was - using <hostid role="ipaddr">10.9.9</hostid> then the default routes - would be:</para> - - <literallayout> -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) - </literallayout> - </sect2> - - <sect2> - <title>Dual homed hosts</title> - - <para>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.</para> - - <para>In one case, the machine as two ethernet cards, each having an - address on the separate subnets. Alternately, the machine may only - have one ethernet card, and be using ifconfig 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.</para> - - <para>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 Bridge - between the two subnets, is often used when we need to implement - packet filtering or firewall security in either or both - directions.</para> - </sect2> - - <sect2> - <title>Routing propagation</title> - - <para>We have already talked about how we define our routes to the - outside world, but not about how the outside world finds us.</para> - - <para>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.</para> - - <para>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?</para> - - <para>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 <quote>Backbone</quote> 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.</para> - - <para>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.</para> - </sect2> - - <sect2> - <title>Troubleshooting</title> - - <para>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 a 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).</para> - - <para>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.</para> - - <para>For more information, see the manual page for - &man.traceroute.8;.</para> - </sect2> - </sect1> - - <sect1 id="bridging"> - <title>Bridging</title> - - <para><emphasis>Written by Steve Peterson - <email>steve@zpfe.com</email></emphasis>.</para> - - <sect2> - <title>Introduction</title> - - <para>It is sometimes useful to divide one physical network (i.e., 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. and a FreeBSD system with two network - interface cards can act as a bridge.</para> - - <para>The bridge works by learning the MAC layer addresses (i.e., - 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.</para> - - <para>In many respects, a bridge is like an Ethernet switch with very - few ports.</para> - </sect2> - - <sect2> - <title>Situations where bridging is appropriate</title> - - <para>There are two common situations in which a bridge is used - today.</para> - - <sect3> - <title>High traffic on a segment</title> - - <para>Situation one is where your physical network segment is - overloaded with traffic, but you don't want for whatever reason to - subnet the network and interconnect the subnets with a - router.</para> - - <para>Let's 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.</para> - - <para>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.</para> - </sect3> - - <sect3> - <title>Filtering/traffic shaping firewall</title> - - <para>The second common situation is where firewall functionality is - needed without IP Masquerading (NAT).</para> - - <para>An example is a small company that is connected via DSL or ISDN - to their ISP. They have a 13 address global IP allocation for their - ISP and have 10 PCs on their network. In this situation, using a - router-based firewall is difficult because of subnetting - issues.</para> - - <para>A bridge-based firewall can be configured and dropped into the - path just downstream of their DSL/ISDN router without any IP - numbering issues.</para> - </sect3> - </sect2> - - <sect2> - <title>Configuring a bridge</title> - - <sect3> - <title>Network interface card selection</title> - - <para>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.</para> - - <para>Install and test the two network cards before continuing.</para> - </sect3> - - <sect3> - <title>Kernel configuration changes</title> - - <para>To enable kernel support for bridging, add the</para> - - <programlisting>options BRIDGE</programlisting> - - <para>statement to your kernel configuration file, and rebuild your - kernel.</para> - </sect3> - - <sect3> - <title>Firewall support</title> - - <para>If you are planning to use the bridge as a firewall, you will - need to add the IPFIREWALL option as well. Read <xref - linkend="firewalls"> for general information on configuring the - bridge as a firewall.</para> - - <para>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 - <literal>IPFIREWALL_DEFAULT_TO_ACCEPT</literal>. 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.</para> - </sect3> - - <sect3> - <title>Traffic shaping support</title> - - <para>If you want to use the bridge as a traffic shaper, you will need - to add the <literal>DUMMYNET</literal> option to your kernel - configuration. Read &man.dummynet.4; for further - information.</para> - </sect3> - </sect2> - - <sect2> - <title>Enabling the bridge</title> - - <para>Add the line</para> - - <programlisting>net.link.ether.bridge=1</programlisting> - - <para>to <filename>/etc/sysctl.conf</filename> to enable the bridge at - runtime. If you want the bridged packets to be filtered by ipfw, you - should also add</para> - - <programlisting>net.link.ether.bridge_ipfw=1</programlisting> - - <para>as well.</para> - </sect2> - - <sect2> - <title>Performance</title> - - <para>My bridge/firewall is a Pentium 90 with one 3Com 3C900B and one - 3C905B. The protected side of the network runs at 10mbps half duplex - and the connection between the bridge and my router (a Cisco 675) runs - at 100mbps full duplex. With no filtering enabled, I've found that - the bridge adds about 0.4 milliseconds of latency to pings from the - protected 10mbps network to the Cisco 675.</para> - </sect2> - - <sect2> - <title>Other information</title> - - <para>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.</para> - - <para>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.</para> - </sect2> - </sect1> - - <sect1 id="nfs"> - <title>NFS</title> - - <para><emphasis>Written by &a.unfurl;, 4 March 2000.</emphasis></para> - - <para>Among the many different file systems that FreeBSD supports is - a very unique type, the Network File System or NFS. NFS allows you - to share directories and files on one machine with one or more other - machines via the network they are attached to. Using NFS, users and - programs can access files on remote systems as if they were local - files.</para> - - <para>NFS has several benefits:</para> - - <itemizedlist> - <listitem> - <para>Local workstations dont need as much disk space because - commonly used data can be stored on a single machine and still - remain accessible to everyone on the network.</para> - </listitem> - - <listitem> - <para>There is no need for users to have unique home directories - on every machine on your network. Once they have an established - directory that is available via NFS it can be accessed from - anywhere.</para> - </listitem> - - <listitem> - <para>Storage devices such as floppies and CD-ROM drives can be - used by other machines on the network eliminating the need for - extra hardware.</para> - </listitem> - </itemizedlist> - - <sect2> - <title>How It Works</title> - - <para> NFS is composed of two sides – a client side and a - server side. Think of it as a want/have relationship. The client - <emphasis>wants</emphasis> the data that the server side - <emphasis>has</emphasis>. The server shares its data with the - client. In order for this system to function properly a few - processes have to be configured and running properly.</para> - - <para>The server has to be running the following daemons:</para> - - <itemizedlist> - <listitem> - <para><command>nfsd</command> - The NFS Daemon which services - requests from NFS clients.</para> - </listitem> - - <listitem> - <para><command>mountd</command> - The NFS Mount Daemon which - actually carries out requests that nfsd passes on to - it.</para> - </listitem> - </itemizedlist> - - <para>The client side only needs to run a single daemon:</para> - - <itemizedlist> - <listitem> - <para><command>nfsiod</command> - The NFS async I/O Daemon which - services requests from its NFS server.</para> - </listitem> - </itemizedlist> - </sect2> - - <sect2> - <title>Configuring NFS</title> - - <para>Luckily for us, on a FreeBSD system this setup is a snap. The - processes that need to be running can all be run at boot time with - a few modifications to your <filename>/etc/rc.conf</filename> - file.</para> - - <para>On the NFS server make sure you have:</para> - - <programlisting> -nfs_server_enable="YES" -nfs_server_flags="-u -t -n 4" -mountd_flags="-r"</programlisting> - - <para><command>mountd</command> is automatically run whenever the - NFS server is enabled. The <option>-u</option> and - <option>-t</option> flags to <command>nfsd</command> tell it to - serve UDP and TCP clients. The <option>-n 4</option> flag tells - <command>nfsd</command> to start 4 copies of itself.</para> - - <para>On the client, make sure you have:</para> - - <programlisting> -nfs_client_enable="YES" -nfs_client_flags="-n 4"</programlisting> - - <para>Like <command>nfsd</command>, the <option>-n 4</option> tells - <command>nfsiod</command> to start 4 copies of itself.</para> - - <para>The last configuration step requires that you create a file - called <filename>/etc/exports</filename>. The exports file - specifies which file systems on your server will be shared - (a.k.a., <quote>exported</quote>) and with what clients they will - be shared. Each line in the file specifies a file system to be - shared. There are a handful of options that can be used in this - file but I will only touch on a few of them. You can find out - about the rest in the &man.exports.5; man page.</para> - - <para>Here are a few example <filename>/etc/exports</filename> - entries:</para> - - <para>The following line exports <filename>/cdrom</filename> to - three silly machines that have the same domain name as the server - (hence the lack of a domain name for each) or have entries in your - <filename>/etc/hosts</filename> file. The <option>-ro</option> - flag makes the shared file system read-only. With this flag, the - remote system will not be able to make any changes to the the - shared file system.</para> - - <programlisting>/cdrom -ro moe larry curly</programlisting> - - <para>The following line exports <filename>/home</filename> to three - hosts by IP address. This is a useful setup if you have a - private network but do not have DNS running. The - <option>-alldirs</option> flag allows all the directories below - the specified file system to be exported as well.</para> - - <programlisting>/home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4</programlisting> - - <para>The following line exports <filename>/a</filename> to two - machines that have different domain names than the server. The - <option>-maproot=0</option> flag allows - the root user on the remote system to write to the shared - file system as root. Without the -maproot=0 flag even if - someone has root access on the remote system they won't - be able to modify files on the shared file system.</para> - - <programlisting>/a -maproot=0 host.domain.com box.example.com</programlisting> - - <para>In order for a client to share an exported file system it must - have permission to do so. Make sure your client is listed in your - <filename>/etc/exports</filename> file.</para> - - <para>Now that you have made all these changes you can just reboot - and let FreeBSD start everything for you at boot time or you can - run the following commands as root:</para> - - <para>On the NFS server:</para> - - <screen>&prompt.root; <userinput>nfsd -u -t -n 4</userinput> -&prompt.root; <userinput>mountd -r</userinput></screen> - - <para>On the NFS client:</para> - - <screen>&prompt.root; <userinput>nfsiod -n 4</userinput></screen> - - <para>Now you should be ready to actually mount a remote file - system. This can be done one of two ways. In these examples the - server's name will be <literal>server</literal> and the client's - name will be <literal>client</literal>. If you just want to - temporarily mount a remote file system or just want to test out - your config you can run a command like this as root on the - client:</para> - - <screen>&prompt.root; <userinput>mount server:/home /mnt</userinput></screen> - - <para>This will mount <filename>/home</filename> on the server on - <filename>/mnt</filename> on the client. If everything is setup - correctly you should be able to go into /mnt on the client and see - all the files that are on the server.</para> - - <para>If you want to permanently (each time you reboot) mount a - remote file system you need to add it to your - <filename>/etc/fstab</filename> file. Here is an example - line:</para> - - <programlisting>server:/home /mnt nfs rw 0 0</programlisting> - - <para>Read the &man.fstab.5; man page for more options.</para> - </sect2> - - <sect2> - <title>Practical Uses</title> - - <para>There are many very cool uses for NFS. I use it quite a bit - on the LAN I admin. Here are a few ways I have found it to be - useful.</para> - - <para>I have several machines on my network but only one of them has - a CD-ROM drive. Why? Because I have that one CD-ROM drive shared - with all the others via NFS. The same can be done with floppy - drives.</para> - - <para>With so many machines on the network it gets old having your - personal files strewn all over the place. I have a central NFS - server that houses all user home directories and shares them with - the rest of the machines on the LAN, so no matter where I login I - have the same home directory.</para> - - <para>When you get to reinstalling FreeBSD on one of your machines, - NFS is the way to go. Just pop your distribution CD into your - file server and away you go.</para> - - <para>I have a common <filename>/usr/ports/distfiles</filename> - directory that all my machines share. That way when I go to - install a port that I already installed on a different machine I - do not have to download the source all over again.</para> - </sect2> - - <sect2> - <title>Problems integrating with other systems</title> - - <para><emphasis>Contributed by &a.jlind;.</emphasis></para> - - <para>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.</para> - - <para>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.</para> - - <para>Though the <quote>correct</quote> 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 - <emphasis>server</emphasis>, include the option - <option>-w=1024</option> on the mount from the client. If the - FreeBSD system is the <emphasis>client</emphasis>, then mount the - NFS file system with the option <option>-r=1024</option>. These - options may be specified using the fourth field of the - <filename>fstab</filename> entry on the client for automatic - mounts, or by using the <option>-o</option> parameter of the mount - command for manual mounts.</para> - - <para>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 - <emphasis>certain</emphasis> that your routers are routing the - necessary UDP information, or you will not get anywhere, no matter - what else you are doing.</para> - - <para>In the following examples, <hostid>fastws</hostid> is the host - (interface) name of a high-performance workstation, and - <hostid>freebox</hostid> is the host (interface) name of a FreeBSD - system with a lower-performance Ethernet adapter. Also, - <filename>/sharedfs</filename> will be the exported NFS - filesystem (see <command>man exports</command>), and - <filename>/project</filename> will be the mount point on the - client for the exported file system. In all cases, note that - additional options, such as <option>hard</option> or - <option>soft</option> and <option>bg</option> may be desirable in - your application.</para> - - <para>Examples for the FreeBSD system (<hostid>freebox</hostid>) as - the client: in <filename>/etc/fstab</filename> on freebox:</para> - - <programlisting> -fastws:/sharedfs /project nfs rw,-r=1024 0 0</programlisting> - - <para>As a manual mount command on <hostid>freebox</hostid>:</para> - - <screen>&prompt.root; <userinput>mount -t nfs -o -r=1024 fastws:/sharedfs /project</userinput></screen> - - <para>Examples for the FreeBSD system as the server: in - <filename>/etc/fstab</filename> on <hostid>fastws</hostid>:</para> - - <programlisting> -freebox:/sharedfs /project nfs rw,-w=1024 0 0</programlisting> - - <para>As a manual mount command on <hostid>fastws</hostid>:</para> - - <screen>&prompt.root; <userinput>mount -t nfs -o -w=1024 freebox:/sharedfs /project</userinput></screen> - - <para>Nearly any 16-bit Ethernet adapter will allow operation - without the above restrictions on the read or write size.</para> - - <para>For anyone who cares, here is what happens when the failure - occurs, which also explains why it is unrecoverable. NFS - typically works with a <quote>block</quote> size of 8k (though it - may do fragments of smaller sizes). Since the maximum Ethernet - packet is around 1500 bytes, the NFS <quote>block</quote> 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 <emphasis>acknowledged</emphasis> 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 8K unit, and the process will be repeated, ad - infinitum.</para> - - <para>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.</para> - - <para>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 <quote>units</quote>. 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.</para> - </sect2> - </sect1> - - <sect1 id="diskless"> - <title>Diskless Operation</title> - - <para><emphasis>Contributed by &a.martin;.</emphasis></para> - - <para><filename>netboot.com</filename>/<filename>netboot.rom</filename> - allow you to boot your FreeBSD machine over the network and run FreeBSD - without having a disk on your client. Under 2.0 it is now possible to - have local swap. Swapping over NFS is also still supported.</para> - - <para>Supported Ethernet cards include: Western Digital/SMC 8003, 8013, - 8216 and compatibles; NE1000/NE2000 and compatibles (requires - recompile)</para> - - <sect2> - <title>Setup Instructions</title> - - <procedure> - <step> - <para>Find a machine that will be your server. This machine will - require enough disk space to hold the FreeBSD 2.0 binaries and - have bootp, tftp and NFS services available. Tested - machines:</para> - - <itemizedlist> - <listitem> - <para>HP9000/8xx running HP-UX 9.04 or later (pre 9.04 doesn't - work)</para> - </listitem> - - <listitem> - <para>Sun/Solaris 2.3. (you may need to get bootp)</para> - </listitem> - </itemizedlist> - </step> - - <step> - <para>Set up a bootp server to provide the client with IP, gateway, - netmask.</para> - - <programlisting> -diskless:\ - :ht=ether:\ - :ha=0000c01f848a:\ - :sm=255.255.255.0:\ - :hn:\ - :ds=192.1.2.3:\ - :ip=192.1.2.4:\ - :gw=192.1.2.5:\ - :vm=rfc1048:</programlisting> - </step> - - <step> - <para>Set up a TFTP server (on same machine as bootp server) to - provide booting information to client. The name of this file is - <filename>cfg.<replaceable>X.X.X.X</replaceable></filename> (or - <filename>/tftpboot/cfg.<replaceable>X.X.X.X</replaceable></filename>, - it will try both) where <replaceable>X.X.X.X</replaceable> is the - IP address of the client. The contents of this file can be any - valid netboot commands. Under 2.0, netboot has the following - commands:</para> - - <informaltable frame="none"> - <tgroup cols="2"> - <tbody> - <row> - <entry>help</entry> - <entry>print help list</entry> - </row> - - <row> - <entry>ip - <option><replaceable>X.X.X.X</replaceable></option></entry> - <entry>print/set client's IP address</entry> - </row> - - <row> - <entry>server - <option><replaceable>X.X.X.X</replaceable></option></entry> - <entry>print/set bootp/tftp server address</entry> - </row> - - <row> - <entry>netmask - <option><replaceable>X.X.X.X</replaceable></option></entry> - <entry>print/set netmask</entry> - </row> - - <row> - <entry>hostname <replaceable>name</replaceable></entry> - <entry>print/set hostname</entry> - </row> - - <row> - <entry>kernel - <option><replaceable>name</replaceable></option></entry> - <entry>print/set kernel name</entry> - </row> - - <row> - <entry>rootfs - <option><replaceable>ip:/fs</replaceable></option></entry> - <entry>print/set root filesystem</entry> - </row> - - <row> - <entry>swapfs - <option><replaceable>ip:/fs</replaceable></option></entry> - <entry>print/set swap filesystem</entry> - </row> - - <row> - <entry>swapsize - <option><replaceable>size</replaceable></option></entry> - <entry>set diskless swapsize in KBytes</entry> - </row> - - <row> - <entry>diskboot</entry> - <entry>boot from disk</entry> - </row> - - <row> - <entry>autoboot</entry> - <entry>continue boot process</entry> - </row> - - <row> - <entry>trans - <option>on</option>|<option>off</option></entry> - <entry>turn transceiver on|off</entry> - </row> - - <row> - <entry>flags - <option>b</option><option>c</option><option>d</option><option>h</option><option>s</option><option>v</option></entry> - <entry>set boot flags</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para>A typical completely diskless cfg file might contain:</para> - - <programlisting> -rootfs 192.1.2.3:/rootfs/myclient -swapfs 192.1.2.3:/swapfs -swapsize 20000 -hostname myclient.mydomain</programlisting> - - <para>A cfg file for a machine with local swap might contain:</para> - - <programlisting> -rootfs 192.1.2.3:/rootfs/myclient -hostname myclient.mydomain</programlisting> - </step> - - <step> - <para>Ensure that your NFS server has exported the root (and swap if - applicable) filesystems to your client, and that the client has - root access to these filesystems A typical - <filename>/etc/exports</filename> file on FreeBSD might look - like:</para> - - <programlisting> -/rootfs/myclient -maproot=0:0 myclient.mydomain -/swapfs -maproot=0:0 myclient.mydomain</programlisting> - - <para>And on HP-UX:</para> - - <programlisting> -/rootfs/myclient -root=myclient.mydomain -/swapfs -root=myclient.mydomain</programlisting> - </step> - - <step> - <para>If you are swapping over NFS (completely diskless - configuration) create a swap file for your client using - <command>dd</command>. If your <command>swapfs</command> command - has the arguments <filename>/swapfs</filename> and the size 20000 - as in the example above, the swapfile for myclient will be called - <filename>/swapfs/swap.<replaceable>X.X.X.X</replaceable></filename> - where <replaceable>X.X.X.X</replaceable> is the client's IP addr, - e.g.:</para> - - <screen>&prompt.root; <userinput>dd if=/dev/zero of=/swapfs/swap.192.1.2.4 bs=1k count=20000</userinput></screen> - - <para>Also, the client's swap space might contain sensitive - information once swapping starts, so make sure to restrict read - and write access to this file to prevent unauthorized - access:</para> - - <screen>&prompt.root; <userinput>chmod 0600 /swapfs/swap.192.1.2.4</userinput></screen> - </step> - - <step> - <para>Unpack the root filesystem in the directory the client will - use for its root filesystem (<filename>/rootfs/myclient</filename> - in the example above).</para> - - <itemizedlist> - <listitem> - <para>On HP-UX systems: The server should be running HP-UX 9.04 - or later for HP9000/800 series machines. Prior versions do not - allow the creation of device files over NFS.</para> - </listitem> - - <listitem> - <para>When extracting <filename>/dev</filename> in - <filename>/rootfs/myclient</filename>, beware that some - systems (HPUX) will not create device files that FreeBSD is - happy with. You may have to go to single user mode on the - first bootup (press control-c during the bootup phase), cd - <filename>/dev</filename> and do a <command>sh ./MAKEDEV - all</command> from the client to fix this.</para> - </listitem> - </itemizedlist> - </step> - - <step> - <para>Run <command>netboot.com</command> on the client or make an - EPROM from the <filename>netboot.rom</filename> file</para> - </step> - </procedure> - </sect2> - - <sect2> - <title>Using Shared <filename>/</filename> and <filename>/usr</filename> - filesystems</title> - - <para>At present there isn't an officially sanctioned way of doing this, - although I have been using a shared <filename>/usr</filename> - filesystem and individual <filename>/</filename> filesystems for each - client. If anyone has any suggestions on how to do this cleanly, - please let me and/or the &a.core; know.</para> - </sect2> - - <sect2> - <title>Compiling netboot for specific setups</title> - - <para>Netboot can be compiled to support NE1000/2000 cards by changing - the configuration in - <filename>/sys/i386/boot/netboot/Makefile</filename>. See the - comments at the top of this file.</para> - </sect2> - </sect1> - - <sect1 id="isdn"> - <title>ISDN</title> - - <para><emphasis>Last modified by &a.wlloyd;</emphasis>.</para> - - <para>A good resource for information on ISDN technology and hardware is - <ulink url="http://alumni.caltech.edu/~dank/isdn/">Dan Kegel's ISDN - Page</ulink>.</para> - - <para>A quick simple road map to ISDN follows:</para> - - <itemizedlist> - <listitem> - <para>If you live in Europe I suggest you investigate the ISDN card - section.</para> - </listitem> - - <listitem> - <para>If you are planning to use ISDN primarily to connect to the - Internet with an Internet Provider on a dial-up non-dedicated basis, - I suggest you look into Terminal Adapters. This will give you the - most flexibility, with the fewest problems, if you change - providers.</para> - </listitem> - - <listitem> - <para>If you are connecting two LANs together, or connecting to the - Internet with a dedicated ISDN connection, I suggest you consider - the stand alone router/bridge option.</para> - </listitem> - </itemizedlist> - - <para>Cost is a significant factor in determining what solution you will - choose. The following options are listed from least expensive to most - expensive.</para> - - <sect2> - <title>ISDN Cards</title> - - <para><emphasis>Contributed by &a.hm;.</emphasis></para> - - <para>This section is really only relevant to ISDN users in countries - where the DSS1/Q.931 ISDN standard is supported.</para> - - <para>Some growing number of PC ISDN cards are supported under FreeBSD - 2.2.x and up by the isdn4bsd driver package. It is still under - development but the reports show that it is successfully used all over - Europe.</para> - - <para>The latest isdn4bsd version is available from <ulink - url="ftp://isdn4bsd@ftp.consol.de/pub/">ftp://isdn4bsd@ftp.consol.de/pub/</ulink>, - the main isdn4bsd ftp site (you have to log in as user - <username>isdn4bsd</username> , give your mail address as the password - and change to the <filename>pub</filename> directory. Anonymous ftp - as user <username>ftp</username> or <username>anonymous</username> - will <emphasis>not</emphasis> give the desired result).</para> - - <para>Isdn4bsd allows you to connect to other ISDN routers using either - IP over raw HDLC or by using synchronous PPP. A telephone answering - machine application is also available.</para> - - <para>Many ISDN PC cards are supported, mostly the ones with a Siemens - ISDN chipset (ISAC/HSCX), support for other chipsets (from Motorola, - Cologne Chip Designs) is currently under development. For an - up-to-date list of supported cards, please have a look at the <ulink - url="ftp://isdn4bsd@ftp.consol.de/pub/README">README</ulink> - file.</para> - - <para>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 <email>hm@kts.org</email>.</para> - - <para>A majordomo maintained mailing list is available. To join the - list, send mail to &a.majordomo; and - specify:</para> - - <programlisting> -subscribe freebsd-isdn</programlisting> - - <para>in the body of your message.</para> - </sect2> - - <sect2> - <title>ISDN Terminal Adapters</title> - - <para>Terminal adapters(TA), are to ISDN what modems are to regular - phone lines.</para> - - <para>Most TA's use the standard hayes modem AT command set, and can be - used as a drop in replacement for a modem.</para> - - <para>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 <link linkend="ppp">PPP</link> exactly the same - as for a modem setup. Make sure you set your serial speed as high as - possible.</para> - - <para>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.</para> - - <para>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.</para> - - <para>If you want maximum stability, use the kernel <link - linkend="ppp">PPP</link> option, not the user-land <link - linkend="userppp">iijPPP</link>.</para> - - <para>The following TA's are know to work with FreeBSD.</para> - - <itemizedlist> - <listitem> - <para>Motorola BitSurfer and Bitsurfer Pro</para> - </listitem> - - <listitem> - <para>Adtran</para> - </listitem> - </itemizedlist> - - <para>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.</para> - - <para>The real problem with external TA's is like modems you need a good - serial card in your computer.</para> - - <para>You should read the <link linkend="uart">serial ports</link> - section in the handbook for a detailed understanding of serial - devices, and the differences between asynchronous and synchronous - serial ports.</para> - - <para>A TA running off a standard PC serial port (asynchronous) limits - you to 115.2Kbs, even though you have a 128Kbs connection. To fully - utilize the 128Kbs that ISDN is capable of, you must move the TA to a - synchronous serial card.</para> - - <para>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.</para> - - <para>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.</para> - - <para>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 <ulink - url="http://www.FreeBSD.org/search.html">archives</ulink> for the - complete discussion.</para> - </sect2> - - <sect2> - <title>Stand-alone ISDN Bridges/Routers</title> - - <para>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.</para> - - <para>In the context of this page, I will use router and bridge - interchangeably.</para> - - <para>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(or - card), and manages its own connection to the other bridge/router. It - has all the software to do PPP and other protocols built in.</para> - - <para>A router will allow you much faster throughput that a standard TA, - since it will be using a full synchronous ISDN connection.</para> - - <para>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, I recommend that you - discuss your needs with them.</para> - - <para>If you are planning to connect two lan segments together, ie: 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.</para> - - <para>For example to connect a home computer or branch office network to - a head office network the following setup could be used.</para> - - <example> - <title>Branch office or Home network</title> - - <para>Network is 10 Base T Ethernet. Connect router to network cable - with AUI/10BT transceiver, if necessary.</para> - - <!-- This should be a graphic --> - <programlisting> ----Sun workstation -| ----FreeBSD box -| ----Windows 95 (Do not admit to owning it) -| -Stand-alone router - | -ISDN BRI line</programlisting> - - <para>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.</para> - </example> - - <example> - <title>Head office or other lan</title> - - <para>Network is Twisted Pair Ethernet.</para> - - <!-- This should be a graphic --> - <programlisting> - -------Novell Server - | H | - | ---Sun - | | - | U ---FreeBSD - | | - | ---Windows 95 - | B | - |___---Stand-alone router - | - ISDN BRI line</programlisting> - </example> - - <para>One large advantage of most routers/bridges is that they allow you - to have 2 <emphasis>separate independent</emphasis> PPP connections to - 2 separate sites at the <emphasis>same</emphasis> time. This is not - supported on most TA's, except for specific(expensive) models that - have two serial ports. Do not confuse this with channel bonding, MPP - etc.</para> - - <para>This can be very useful feature, for example if you have an - dedicated ISDN connection at your office and would like to - tap into it, but don't want to get another ISDN line at work. A router - at the office location can manage a dedicated B channel connection - (64Kbs) to the internet, as well as a use the other B channel for a - separate data connection. The second B channel can be used for - dial-in, dial-out or dynamically bond(MPP etc.) with the first B channel - for more bandwidth.</para> - - <para>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.</para> - </sect2> - </sect1> - - <sect1 id="nis"> - <title>NIS/YP</title> - - <para><emphasis>Written by &a.unfurl;, 21 January 2000, enhanced - with parts and comments from Eric Ogren - <email>eogren@earthlink.net</email> and Udo Erdelhoff - <email>ue@nathan.ruhr.de</email> in June 2000.</emphasis></para> - - <sect2> - <title>What is it?</title> - - <para>NIS, which stands for Network Information Services, was - developed by Sun Microsystems to centralize adminstration of Unix - (originally SunOS) systems. It has now essentially become an - industry standard; all major Unices (Solaris, HP-UX, AIX, Linux, - NetBSD, OpenBSD, FreeBSD, etc) support NIS.</para> - - <para>NIS was formerly known as Yellow Pages (or yp), but due to - copyright violations, Sun was forced to change the name.</para> - - <para>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.</para> - - <para>It is similar to Windows NT's domain system; although the - internal implementation of the two aren't at all similar, - the basic functionality can be compared.</para> - </sect2> - - <sect2> - <title>Terms/processes you should know</title> - - <para>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 an NIS client:</para> - - <itemizedlist> - <listitem> - <para><emphasis>The NIS domainname</emphasis>. 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.</para> - </listitem> - <listitem> - <para><emphasis>portmap</emphasis>. <command>portmap</command> - must be running in order to enable RPC (Remote Procedure Call, a - network protocol used by NIS). If <command>portmap</command> is - not running, it will be impossible to run an NIS server, or to - act as an NIS client.</para> - </listitem> - <listitem> - <para><emphasis>ypbind</emphasis>. <command>ypbind</command> - “binds” an NIS client to its NIS server. - It will take the NIS domainname from the system, and - using RPC, connect to the server. <command>ypbind</command> is - the core of client-server communication in an NIS environment; if - <command>ypbind</command> dies on a client machine, it will not - be able to access the NIS server.</para> - </listitem> - <listitem> - <para><emphasis>ypserv</emphasis>. <command>ypserv</command>, - which should only be running on NIS servers, is the NIS server - process itself. If ypserv 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).</para> - - <note><para>There are some implementations of NIS (but not the - FreeBSD one), that don't 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 <command>ypbind</command> process - on the client.</para></note> - </listitem> - <listitem> - <para><emphasis>rpc.yppasswdd</emphasis>. - <command>rpc.yppasswdd</command>, another process that should - only be running on NIS master servers, 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.</para> - </listitem> - - <!-- XXX Missing: rpc.ypxfrd (not important, though) May only run - on the master --> - </itemizedlist> - </sect2> - - <sect2> - <title>How does it work?</title> - - <para>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.</para> - - <para>Information in many files can be shared in this manner. The - <filename>master.passwd</filename>, <filename>group</filename>, - and <filename>hosts</filename> 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 - server it is bound to, to get this information.</para> - - <sect3> - <title>Machine types</title> - - <itemizedlist> - <listitem> - <para>A <emphasis>NIS master server</emphasis>. - This server, analogous to a Windows - NT primary domain controller, maintains the files used by all - of the NIS clients. The <filename>passwd</filename>, - <filename>group</filename>, and other various files used by the - NIS clients live on the master server.</para> - - <note><para>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.</para></note> - </listitem> - <listitem> - <para><emphasis>NIS slave servers</emphasis>. - 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 enviroments. 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.</para> - </listitem> - <listitem> - <para><emphasis>NIS clients</emphasis>. NIS clients, like most - NT workstations, authenticate against the NIS server (or the NT - domain controller in the NT Workstation case) to logon.</para> - </listitem> - </itemizedlist> - </sect3> - </sect2> - - <sect2> - <title>Using NIS/YP</title> - - <para>This section will deal with setting up a sample NIS - environment.</para> - - <note><para>This section assumes that you are running FreeBSD 3.3 - or later. The instructions given here will - <emphasis>probably</emphasis> work for any version of FreeBSD greater - than 3.0, but there are no guarantees that this is - true.</para></note> - - - <sect3> - <title>Planning</title> - - <para>Let's assume that you are the administrator of a small - university lab. This lab, which consists of 15 FreeBSD machines, - currently has no centralised point of administration; each machine - has its own <filename>/etc/passwd</filename> and - <filename>/etc/master.passwd</filename>. 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 - <command>adduser</command> 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.</para> - - <para>Therefore, the configuration of the lab now looks something - like:</para> - - <informaltable> - <tgroup cols="3"> - <thead> - <row> - <entry>Machine name</entry> - <entry>IP address</entry> - <entry>Machine role</entry> - </row> - </thead> - <tbody> - <row> - <entry><hostid>ellington</hostid></entry> - <entry><hostid role="ipaddr">10.0.0.2</hostid></entry> - <entry>NIS master</entry> - </row> - <row> - <entry><hostid>coltrane</hostid></entry> - <entry><hostid role="ipaddr">10.0.0.3</hostid></entry> - <entry>NIS slave</entry> - </row> - <row> - <entry><hostid>basie</hostid></entry> - <entry><hostid role="ipaddr">10.0.0.4</hostid></entry> - <entry>Faculty workstation</entry> - </row> - <row> - <entry><hostid>bird</hostid></entry> - <entry><hostid role="ipaddr">10.0.0.5</hostid></entry> - <entry>Client machine</entry> - </row> - <row> - <entry><hostid>cli[1-11]</hostid></entry> - <entry><hostid role="ipaddr">10.0.0.[6-17]</hostid></entry> - <entry>Other client machines</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para>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.</para> - - <sect4> - <title>Choosing a NIS Domain Name</title> - - <para>This might not be the <quote>domainname</quote> that you - are used to. It is more accurately called the - <quote>NIS domainname</quote>. 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 someway way.</para> - - <para>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 <emphasis>test-domain</emphasis>.</para> - - <para>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 <emphasis>must</emphasis> use the Internet domain name as - your NIS domain name.</para> - </sect4> - - <sect4> - <title>Physical Server Requirements</title> - - <para>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 won't 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 - <emphasis>all</emphasis> of your NIS clients adversely.</para> - </sect4> - </sect3> - - <sect3> - <title>NIS Servers</title> - - <para> 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 - <filename>/var/yp/[domainname]</filename> where - <filename>[domainname]</filename> 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.</para> - - <para>NIS master and slave servers handle all NIS requests with - the <command>ypserv</command> daemon. <command>Ypserv</command> - 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.</para> - - <sect4> - <title>Setting up a NIS master server</title> - - <para>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 <filename>/etc/rc.conf</filename>, and FreeBSD will - do the rest for you.</para> - - <itemizedlist> - <listitem> - <para><programlisting>nisdomainname="test-domain"</programlisting> - This line will set the NIS domainname to - <emphasis>test-domain</emphasis> - upon network setup (e.g. after reboot).</para> - </listitem> - <listitem> - <para><programlisting>nis_server_enable="YES"</programlisting> - This will tell FreeBSD to start up the NIS server processes - when the networking is next brought up.</para> - </listitem> - <listitem> - <para><programlisting>nis_yppasswdd_enable="YES"</programlisting> - This will enable the <command>rpc.yppasswdd</command> - daemon, which, as mentioned above, will allow users to - change their NIS password from a client machine.</para> - </listitem> - </itemizedlist> - - <para>Now, everything you have to do is to run the command - <command>/etc/netstart</command> as superuser. It will - setup everything for you, using the values you defined in - <filename>/etc/rc.conf</filename>.</para> - </sect4> - - <sect4> - <title>Initializing the NIS maps</title> - - <para>The <emphasis>NIS maps</emphasis> are database files, - that are kept in the <filename>/var/yp</filename> directory. - They are generated from configuration files in the - <filename>/etc</filename> directory of the NIS master, with one - exception: the <filename>/etc/master.passwd</filename> file. - This is for a good reason; you don't want to propogate - 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:</para> - - <screen> -&prompt.root; <userinput>cp /etc/master.passwd /var/yp/master.passwd</userinput> -&prompt.root; <userinput>cd /var/yp</userinput> -&prompt.root; <userinput>vi master.passwd</userinput> - </screen> - - <para>You should remove all entries regarding system accounts - (bin, tty, kmem, games, etc), as well as any accounts that you - don't want to be propogated to the NIS clients (for example - root and any other UID 0 (superuser) accounts).</para> - - <note><para>Make sure the - <filename>/var/yp/master.passwd</filename> is neither group - nor world readable (mode 600)! Use the - <command>chmod</command> command, if appreciate.</para></note> - - <para>When you have finished, it's time to initialize the NIS - maps! FreeBSD includes a script named - <command>ypinit</command> to do this for you - (see its man page for more information). Note that this - script is available on most UNIX OSs, but not on all. - On Digital Unix/Compaq Tru64 Unix it is called - <command>ypsetup</command>. - Because we are generating maps for an NIS master, we are - going to pass the <option>-m</option> option to - <command>ypinit</command>. - To generate the NIS maps, assuming you already performed - the steps above, run:</para> - - <screen> -ellington&prompt.root; <userinput>ypinit -m test-domain</userinput> -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] <userinput>n</userinput> -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: <userinput>coltrane</userinput> -next host to add: <userinput>^D</userinput> -The current list of NIS servers looks like this: -ellington -coltrane -Is this correct? [y/n: y] <userinput>y</userinput> - -[..output from map generation..] - -NIS Map update completed. -ellington has been setup as an YP master server without any errors. - </screen> - - <para><command>ypinit</command> should have created - <filename>/var/yp/Makefile</filename> from - <filename>/var/yp/Makefile.dist</filename>. - When created, this file assumes that you are operating - in a single server NIS environment with only FreeBSD - machines. Since <emphasis>test-domain</emphasis> has - a slave server as well, you must edit - <filename>/var/yp/Makefile</filename>:</para> - - <screen> -ellington&prompt.root; <userinput>vi /var/yp/Makefile</userinput> - </screen> - - <para>You should comment out the line that says `NOPUSH = - "True"' (if it is not commented out already).</para> - </sect4> - - <sect4> - <title>Setting up a NIS slave server</title> - - <para>Setting up an NIS slave server is even more simple than - setting up the master. Logon to the slave server and edit the - file <filename>/etc/rc.conf</filename> as you did before. - The only difference is that we now must use the - <option>-s</option> option when running <command>ypinit</command>. - The <option>-s</option> option requires the name of the NIS - master be passed to it as well, so our command line looks - like:</para> - - <screen> -coltrane&prompt.root; <userinput>ypinit -s ellington test-domain</userinput> - -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] <userinput>n</userinput> - -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.</screen> - - <para>You should now have a directory called - <filename>/var/yp/test-domain</filename>. 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 - <filename>/etc/crontab</filename> entries on your slave - servers should do the job:</para> - - <programlisting> -20 * * * * root /usr/libexec/ypxfr passwd.byname -21 * * * * root /usr/libexec/ypxfr passwd.byuid</programlisting> - - <para>These two lines force the slave to sync its maps with - the maps on the master server. Although this is - not mandatory, because the master server - tries to make sure any changes to it's NIS maps are - communicated to it's slaves, the password - information is so vital to systems that depend on the server, - that it is a good idea to force the updates. This is more - important on busy networks where map updates might not always - complete.</para> - - <para>Now, run the command <command>/etc/netstart</command> on the - slave server as well, which again starts the NIS server.</para> - </sect4> - </sect3> - - <sect3> - <title>NIS Clients</title> - - <para> An NIS client establishes what is called a binding to a - particular NIS server using the - <command>ypbind</command> daemon. - <command>ypbind</command> checks the system's default - domain (as set by the <command>domainname</command> command), - and begins broadcasting RPC requests on the local network. - These requests specify the name of the domain for which - <command>ypbind</command> 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 - <command>ypbind</command>, which will record the server's - address. If there are several servers available (a master and - several slaves, for example), <command>ypbind</command> 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. <command>Ypbind</command> will - occasionally <quote>ping</quote> 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, - <command>ypbind</command> will mark the domain as unbound and - begin broadcasting again in the hopes of locating another - server.</para> - - <sect4> - <title>Setting up an NIS client</title> - - <para>Setting up a FreeBSD machine to be a NIS client is fairly - straight forward.</para> - - <itemizedlist> - <listitem> - <para>Edit the file <filename>/etc/rc.conf</filename> and - add the following lines in order to set the NIS domainname - and start <command>ypbind</command> upon network - startup:</para> - - <programlisting> -nisdomainname="test-domain" -nis_client_enable="YES"</programlisting> - </listitem> - - <listitem> - <para>To import all possible password entries from the NIS - server, add this line to your - <filename>/etc/master.passwd</filename> file, using - <command>vipw</command>:</para> - - <programlisting>+:::::::::</programlisting> - - <note> - <para>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 <link linkend="netgroups">netgroups - part</link> below for more information. - For more detailed reading see O'Reilly's book on - <literal>Managing NFS and NIS</literal>.</para> - </note> - </listitem> - - <listitem> - <para>To import all possible group entries from the NIS - server, add this line to your - <filename>/etc/group</filename> file:</para> - - <programlisting>+:*::</programlisting> - </listitem> - </itemizedlist> - - <para>After completing these steps, you should be able to run - <command>ypcat passwd</command> and see the NIS server's - passwd map.</para> - </sect4> - </sect3> - </sect2> - - <sect2> - <title>NIS Security</title> - - <para>In general, any remote user can issue an RPC to ypserv and - retrieve the contents of your NIS maps, provided the remote user - knows your domainname. To prevent such unauthorized transactions, - ypserv supports a feature called securenets which can be used to - restrict access to a given set of hosts. At startup, ypserv will - attempt to load the securenets information from a file called - <filename>/var/yp/securenets</filename>.</para> - - <note> - <para>This path varies depending on the path specified with the - <option>-p</option> option. This file contains entries that - consist of a network specification and a network mask separated - by white space. Lines starting with <quote>#</quote> are - considered to be comments. A sample securenets file might look - like this:</para> - </note> - - <programlisting> -# 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</programlisting> - - <para>If ypserv 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 - <filename>/var/yp/securenets</filename> file does not exist, - ypserv will allow connections from any host.</para> - - <para>The ypserv program also has support for Wietse Venema's - <application>tcpwrapper</application> package. This allows the - administrator to use the tcpwrapper configuration files for access - control instead of <filename>/var/yp/securenets</filename>.</para> - - <note> - <para>While both of these access control mechanisms provide some - security, they, like the privileged port test, are - vulnerable to <quote>IP spoofing</quote> attacks. All - NIS-related traffic should be blocked at your firewall.</para> - - <para>Servers using <filename>/var/yp/securenets</filename> - 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 <filename>/var/yp/securenets</filename>.</para> - - <para>Using <filename>/var/yp/securenets</filename> 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.</para> - - <para>The use of the <application>tcpwrapper</application> - 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.</para> - </note> - </sect2> - - <sect2> - <title>Barring some users from logging on</title> - - <para>In our lab, there is a machine <hostid>basie</hostid> that is - supposed to be a faculty only workstation. We don't want to take this - machine out of the NIS domain, yet the <filename>passwd</filename> - file on the master NIS server contains accounts for both faculty and - students. What can we do?</para> - - <para>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 - <emphasis>-<replaceable>username</replaceable></emphasis> to the end of - the <filename>/etc/master.passwd</filename> file on the client - machine, where <replaceable>username</replaceable> is the username of - the user you wish to bar from logging in. This should preferably be - done using <command>vipw</command>, since <command>vipw</command> - will sanity check your changes to - <filename>/etc/master.passwd</filename>, as well as - automatically rebuild the password database when you - finish editing. For example, if we wanted to bar user - <emphasis>bill</emphasis> from logging on to <hostid>basie</hostid> - we would:</para> - - <screen> -basie&prompt.root; <userinput>vipw</userinput> -<userinput>[add -bill to the end, exit]</userinput> -vipw: rebuilding the database... -vipw: done - -basie&prompt.root; <userinput>cat /etc/master.passwd</userinput> - -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;</screen> - </sect2> - - <sect2 id="netgroups"> - <title>Using netgroups</title> - - <para><emphasis>The netgroups part was contributed by - Udo Erdelhoff <email>ue@nathan.ruhr.de</email> in July - 2000.</emphasis></para> - - <para>The method shown in the previous chapter works reasonably - well if you need special rules for a very small number of - users and/or machines. On larger networks, you - <emphasis>will</emphasis> forget to bar some users from logging - onto sensitive machines, or you may even have to modify each - machine separately, thus loosing the main benefit of NIS, - <emphasis>centralised</emphasis> administration.</para> - - <para>The NIS developers' solution for this problem is called - <emphasis>netgroups</emphasis>. 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.</para> - - <para>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 chapter demonstrates this - problem.</para> - - <para>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.</para> - - <informaltable> - <tgroup cols="2"> - <thead> - <row> - <entry>User Name(s)</entry> - <entry>Description</entry> - </row> - </thead> - - <tbody> - <row> - <entry>alpha, beta</entry> - <entry>Normal employees of the IT department</entry> - </row> - - <row> - <entry>charlie, delta</entry> - <entry>The new apprentices of the IT department</entry> - </row> - - <row> - <entry>echo, foxtrott, golf, ...</entry> - <entry>Ordinary employees</entry> - </row> - - <row> - <entry>able, baker, ...</entry> - <entry>The current interns</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <informaltable> - <tgroup cols="2"> - <thead> - <row> - <entry>Machine Name(s)</entry> - <entry>Description</entry> - </row> - </thead> - - <tbody> - <row> - <!-- Names taken from "Good Omens" by Neil Gaiman and Terry - Pratchett. Many thanks for a brilliant book. --> - <entry>war, death, famine, polution</entry> - <entry>Your most important servers. Only the IT - employees are allowed to log onto these - machines.</entry> - </row> - <row> - <!-- gluttony was omitted because it was too fat ;-) --> - <entry>pride, greed, envy, wraith, lust, sloth</entry> - <entry>Less important servers. All members of the IT - department are allowed to login onto these machines.</entry> - </row> - - <row> - <entry>one, two, three, four, ...</entry> - <entry>Ordinary workstations. Only the - <emphasis>real</emphasis> employees are allowed to use - these machines.</entry> - </row> - - <row> - <entry>trashcan</entry> - <entry>A very old machine without any critcal data. - Even the intern is allowed to use this box.</entry> - </row> - </tbody> - </tgroup> - </informaltable> - - <para>If you tried to implement these restrictions by separately - blocking each user, you would have to add one - -<replaceable>user</replaceable> 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 - feasible to do this correctly during the initial setup, - however you <emphasis>will</emphasis> eventually forget to add - the lines for new users during day-to-day operations. After - all, Murphy was an optimist.</para> - - <para>Handling this situation with netgroups offers several - advantages. Each user need not be handled separately; - you assign a user to one or netgroup 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 <quote>for each combination - of user and machine do...</quote> 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.</para> - - <para>The first step is the initialisation of the NIS map - netgroup. FreeBSD's ypinit 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</para> - - <screen> -ellington&prompt.root; <userinput>vi /var/yp/netgroup</userinput> - </screen> - - <para>and start adding content. For our example, we need at - least four netgroups: IT employees, IT apprentices, normal - employees and interns.</para> - - <programlisting> -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) - </programlisting> - - <para><literal>IT_EMP</literal>, <literal>IT_APP</literal> 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:</para> - - <orderedlist> - <listitem> - <para>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 a realm of darkness, horror and utter confusion.</para> - </listitem> - - <listitem> - <para>The name of the account that belongs to this - netgroup.</para> - </listitem> - - <listitem> - <para>The NIS domain for the account. You can import - accounts from other NIS domains into your netgroup if you - are one of unlucky fellows with more than one NIS - domain.</para> - </listitem> - </orderedlist> - - <para>Each of this fields can contain wildcards, see - &man.netgroup.5; for details.</para> - - <note> - <para>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.</para> - - <para>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 <emphasis>entries</emphasis>. 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:</para> - - <programlisting> -BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] -BIGGRP2 (,joe16,domain) (,joe17,domain) [...] -BIGGRP3 (,joe32,domain) (,joe33,domain) -BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 - </programlisting> - - <para>You can repeat this process if you need more than 225 - users within a single netgroup.</para> - </note> - - <para>Activating and distributing your new NIS map is - easy:</para> - - <screen> -ellington&prompt.root; <userinput>cd /var/yp</userinput> -ellington&prompt.root; <userinput>make</userinput> - </screen> - - <para>This will generate the three NIS maps - <filename>netgroup</filename>, - <filename>netgroup.byhost</filename> and - <filename>netgroup.byuser</filename>. Use &man.ypcat.1; to - check if your new NIS map are available:</para> - - <screen> -ellington&prompt.user; <userinput>ypcat -k netgroup</userinput> -ellington&prompt.user; <userinput>ypcat -k netgroup.byhost</userinput> -ellington&prompt.user; <userinput>ypcat -k netgroup.byuser</userinput> - </screen> - - <para>The output of the first command should resemble the - contents of <filename>/var/yp/netgroup</filename>. 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.</para> - - <para>The client setup is quite simple. To configure the server - <replaceable>war</replaceable>, you only have to start - &man.vipw.8; and replace the line</para> - - <programlisting> -+::::::::: - </programlisting> - - <para>with</para> - - <programlisting> -+@IT_EMP::::::::: - </programlisting> - - <para>Now, only the data for the users defined in the netgroup - <replaceable>IT_EMP</replaceable> is imported into - <replaceable>war</replaceable>'s password database and only - these users are allowed to login.</para> - - <para>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 - ~<replaceable>user</replaceable> will not work, <command>ls - -l</command> will show the numerical id instead of the - username and <command>find . -user joe -print</command> will - fail with <quote>No such user</quote>. To fix this, you will - have to import all user entries <emphasis>without - allowing them to login onto your servers</emphasis>.</para> - - <para>This can be achieved by adding another line to - <filename>/etc/master.passwd</filename>. This line should - contain <literal>+:::::::::/sbin/nologin</literal>, meaning - <quote>Import all entries but replace the shell with - <filename>/sbin/nologin</filename> in the imported - entries</quote>. You can replace any field - in the passwd entry by placing a default value in your - <filename>/etc/master.passwd</filename>.</para> - - <!-- Been there, done that, got the scars to prove it - ue --> - <warning> - <para>Make sure that the line - <literal>+:::::::::/sbin/nologin</literal> is placed after - <literal>+@IT_EMP:::::::::</literal>. Otherwise, all user - accounts imported from NIS will have /sbin/nologin as their - login shell.</para> - </warning> - - <para>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 <literal>+:::::::::</literal> in their local version - of <filename>/etc/master.passwd</filename> with something like - this:</para> - - <programlisting> -+@IT_EMP::::::::: -+@IT_APP::::::::: -+:::::::::/sbin/nologin - </programlisting> - - <para>The corresponding lines for the normal workstations - could be:</para> - - <programlisting> -+@IT_EMP::::::::: -+@USERS::::::::: -+:::::::::/sbin/nologin - </programlisting> - - <para>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: <quote>Errors in - centralised planning lead to global mess</quote>.</para> - - <para>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 - <replaceable>BIGSRV</replaceable> to define the login - restrictions for the important servers, another netgroup - called <replaceable>SMALLSRV</replaceable> for the less - important servers and a third netgroup called - <replaceable>USERBOX</replaceable> 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:</para> - - <programlisting> -BIGSRV IT_EMP IT_APP -SMALLSRV IT_EMP IT_APP ITINTERN -USERBOX IT_EMP ITINTERN USERS - </programlisting> - - <para>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.</para> - - <para>Machine-specific netgroup definitions are the other - possibility to deal with the policy change outlined above. In - this scenario, the <filename>/etc/master.passwd</filename> 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 - <filename>/sbin/nologin</filename> 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:</para> - - <programlisting> -+@<replaceable>BOXNAME</replaceable>::::::::: -+:::::::::/sbin/nologin - </programlisting> - - <para>Once you have completed this task for all your machines, - you will not have to modify the local versions of - <filename>/etc/master.passwd</filename> 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.</para> - - <programlisting> -# 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 und 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 -POLUTION 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] - </programlisting> - - <para>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.</para> - - <para>One last word of caution: It may not always be advisable - to use machine-based netgroups. If you are deploying a couple - 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.</para> - </sect2> - - <sect2> - <title>Important things to remember</title> - - <para>There are still a couple of things that you will need to do - differently now that you are in an NIS environment.</para> - - <itemizedlist> - <listitem> - <para>Every time you wish to add a user to the lab, you - must add it to the master NIS server <emphasis>only</emphasis>, - and <emphasis>you must remember to rebuild the NIS - maps</emphasis>. 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:</para> - - <screen> -&prompt.root; <userinput>pw useradd jsmith</userinput> -&prompt.root; <userinput>cd /var/yp</userinput> -&prompt.root; <userinput>make test-domain</userinput></screen> - - <para>You could also run <command>adduser jsmith</command> instead - of <command>pw useradd jsmith</command>.</para> - </listitem> - <listitem> - <para><emphasis>Keep the administration accounts out of the NIS - maps</emphasis>. You don't want to be propogating administrative - accounts and passwords to machines that will have users that - shouldn't have access to those accounts.</para> - </listitem> - <listitem> - <para><emphasis>Keep the NIS master and slave - secure, and minimize their downtime</emphasis>. - If somebody either hacks or simply turns off - these machines, they have effectively rendered many people without - the ability to login to the lab.</para> - - <para>This is the chief weakness of any centralised 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!</para> - </listitem> - </itemizedlist> - </sect2> - - <sect2> - <title>NIS v1 compatibility</title> - - <para> FreeBSD's <application>ypserv</application> 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 <application>ypbind</application> 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 can not 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.</para> - </sect2> - - <sect2> - <title>NIS servers that are also NIS clients</title> - - <para> 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 on 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.</para> - - <para>You can force a host to bind to a particular server by running - <command>ypbind</command> with the <option>-S</option> - flag.</para> - </sect2> - - <sect2> - <title>libscrypt v.s. libdescrypt</title> - - <para>One of the most common issues that people run into when trying - to implement NIS is crypt library compatibility. If your NIS - server is using the DES crypt libraries, it will only support - clients that are using DES as well. To check which one your server - and clients are using look at the symlinks in - <filename>/usr/lib</filename>. If the machine is configured to - use the DES libraries, it will look something like this:</para> - - <screen> -&prompt.user; <userinput>ls -l /usr/lib/*crypt*</userinput> -lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libdescrypt.a -lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libdescrypt.so -lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libdescrypt.so.2 -lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libdescrypt_p.a --r--r--r-- 1 root wheel 13018 Nov 8 14:27 /usr/lib/libdescrypt.a -lrwxr-xr-x 1 root wheel 16 Nov 8 14:27 /usr/lib/libdescrypt.so@ -> libdescrypt.so.2 --r--r--r-- 1 root wheel 12965 Nov 8 14:27 /usr/lib/libdescrypt.so.2 --r--r--r-- 1 root wheel 14750 Nov 8 14:27 /usr/lib/libdescrypt_p.a</screen> - - <para>If the machine is configured to use the standard FreeBSD MD5 - crypt libraries they will look something like this:</para> - - <screen> -&prompt.user; <userinput>ls -l /usr/lib/*crypt*</userinput> -lrwxrwxrwx 1 root wheel 13 Jul 15 08:55 /usr/lib/libcrypt.a@ -> libscrypt.a -lrwxrwxrwx 1 root wheel 14 Jul 15 08:55 /usr/lib/libcrypt.so@ -> libscrypt.so -lrwxrwxrwx 1 root wheel 16 Jul 15 08:55 /usr/lib/libcrypt.so.2@ -> libscrypt.so.2 -lrwxrwxrwx 1 root wheel 15 Jul 15 08:55 /usr/lib/libcrypt_p.a@ -> libscrypt_p.a --r--r--r-- 1 root wheel 6194 Nov 8 14:27 /usr/lib/libscrypt.a -lrwxr-xr-x 1 root wheel 14 Nov 8 14:27 /usr/lib/libscrypt.so@ -> libscrypt.so.2 --r--r--r-- 1 root wheel 7579 Nov 8 14:27 /usr/lib/libscrypt.so.2 --r--r--r-- 1 root wheel 6684 Nov 8 14:27 /usr/lib/libscrypt_p.a</screen> - - <para>If you have trouble authenticating on an NIS client, this - is a pretty good place to start looking for possible problems. - 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.</para> - </sect2> - </sect1> - - <sect1 id="dhcp"> - <title>DHCP</title> - - <para><emphasis>Written by &a.gsutter;, March 2000.</emphasis></para> - - <sect2> - <title>What is DHCP?</title> - - <para>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.</para> - </sect2> - - <sect2> - <title>What This Section Covers</title> - - <para>This handbook section attempts to describe only the parts - of the DHCP system that are integrated with FreeBSD; - consequently, the server portions are not described. The DHCP - manual pages, in addition to the references below, are useful - resources.</para> - </sect2> - - <sect2> - <title>How it Works</title> - - <para>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.</para> - - <para>DHCP clients can obtain a great deal of information from - the server. An exhaustive list may be found in - &man.dhcp-options.5;.</para> - </sect2> - - <sect2> - <title>FreeBSD Integration</title> - - <para>FreeBSD fully integrates the ISC DHCP client, - <command>dhclient</command>. 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. <command>dhclient</command> has been - included in all FreeBSD distributions since 3.2.</para> - - <para>DHCP is supported by <application>sysinstall</application>. - 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.</para> - - <para>There are two things you must do to have your system use - DHCP upon startup:</para> - - <itemizedlist> - <listitem> - <para>Make sure that the <devicename>bpf</devicename> - device is compiled into your kernel. To do this, add - <literal>pseudo-device bpf</literal> to your kernel - configuration file, and rebuild the kernel. For more - information about building kernels, see <xref - linkend="kernelconfig">.</para> - <para>The <devicename>bpf</devicename> device is already - part of the <filename>GENERIC</filename> kernel that is - supplied with FreeBSD, so if you don't have a custom - kernel, you shouldn't need to create one in order to get - DHCP working.</para> - <note> - <para>For those who are particularly security conscious, - you should be warned that <devicename>bpf</devicename> - is also the device that allows packet sniffers to work - correctly (although they still have to be run as - root). <devicename>bpf</devicename> - <emphasis>is</emphasis> required to use DHCP, but if - you are very sensitive about security, you probably - shouldn't add <devicename>bpf</devicename> to your - kernel in the expectation that at some point in the - future you will be using DHCP.</para> - </note> - </listitem> - <listitem> - <para>Edit your <filename>/etc/rc.conf</filename> to - include the following:</para> - - <programlisting> -ifconfig_fxp0="DHCP" - </programlisting> - - <note> - <para>Be sure to replace <literal>fxp0</literal> with the - designation for the interface that you wish to dynamically - configure.</para> - </note> - - <para>If you are using a different location for - <command>dhclient</command>, or if you wish to pass additional - flags to <command>dhclient</command>, also include the - following (editing as necessary):</para> - - <programlisting> -dhcp_program="/sbin/dhclient" -dhcp_flags="" - </programlisting> - </listitem> - </itemizedlist> - - <para>The DHCP server, <command>dhcpd</command>, is included - as part of the <literal>isc-dhcp2</literal> port in the ports - collection. This port contains the full ISC DHCP distribution, - consisting of client, server, relay agent and documentation. - </para> - </sect2> - - <sect2> - <title>Files</title> - - <itemizedlist> - <listitem><para><filename>/etc/dhclient.conf</filename></para> - <para><command>dhclient</command> requires a configuration file, - <filename>/etc/dhclient.conf</filename>. Typically the file - contains only comments, the defaults being reasonably sane. This - configuration file is described by the &man.dhclient.conf.5; - man page.</para> - </listitem> - - <listitem><para><filename>/sbin/dhclient</filename></para> - <para><command>dhclient</command> is statically linked and - resides in <filename>/sbin</filename>. The &man.dhclient.8; - manual page gives more information about - <command>dhclient</command>.</para> - </listitem> - - <listitem><para><filename>/sbin/dhclient-script</filename></para> - <para><command>dhclient-script</command> 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.</para> - </listitem> - - <listitem><para><filename>/var/db/dhclient.leases</filename></para> - <para>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.</para> - </listitem> - </itemizedlist> - </sect2> - - <sect2> - <title>Further Reading</title> - - <para>The DHCP protocol is fully described in - <ulink url="http://www.freesoft.org/CIE/RFC/2131/">RFC 2131</ulink>. - An informational resource has also been set up at - <ulink url="http://www.dhcp.org/">dhcp.org</ulink>.</para> - </sect2> - </sect1> - -</chapter> - -<!-- - Local Variables: - mode: sgml - sgml-declaration: "../chapter.decl" - sgml-indent-data: t - sgml-omittag: nil - sgml-always-quote-attributes: t - sgml-parent-document: ("../book.sgml" "part" "chapter") - End: ---> |