From 1ffd2e8bc6b9b4cac0f1221f90251e049b2f0bec Mon Sep 17 00:00:00 2001 From: Murray Stokely Date: Tue, 13 Jul 2004 03:48:29 +0000 Subject: [PATCH] The advanced networking chapter had grown to almost 100 pages. Split out the sections about network servers into a new chapter. Reviewed by: doc@ --- en_US.ISO8859-1/books/handbook/Makefile | 1 + .../handbook/advanced-networking/chapter.sgml | 4089 +--------------- en_US.ISO8859-1/books/handbook/book.sgml | 2 + en_US.ISO8859-1/books/handbook/chapters.ent | 1 + .../books/handbook/network-servers/Makefile | 15 + .../handbook/network-servers/chapter.sgml | 4129 +++++++++++++++++ 6 files changed, 4151 insertions(+), 4086 deletions(-) create mode 100644 en_US.ISO8859-1/books/handbook/network-servers/Makefile create mode 100644 en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml diff --git a/en_US.ISO8859-1/books/handbook/Makefile b/en_US.ISO8859-1/books/handbook/Makefile index 39eeedb054..4c6fac6387 100644 --- a/en_US.ISO8859-1/books/handbook/Makefile +++ b/en_US.ISO8859-1/books/handbook/Makefile @@ -171,6 +171,7 @@ SRCS+= mac/chapter.sgml SRCS+= mail/chapter.sgml SRCS+= mirrors/chapter.sgml SRCS+= multimedia/chapter.sgml +SRCS+= network-servers/chapter.sgml SRCS+= pgpkeys/chapter.sgml SRCS+= ports/chapter.sgml SRCS+= ppp-and-slip/chapter.sgml diff --git a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml index e20c460559..56e31080b3 100644 --- a/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml +++ b/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml @@ -10,11 +10,9 @@ Synopsis - This chapter will cover some of the more frequently used network - services on &unix; systems. We will cover how to define, set up, test and - maintain all of the network services that FreeBSD utilizes. In addition, - there have been example configuration files included throughout this - chapter for you to benefit from. + This chapter will cover a number of advanced networking + topics. Will describe a number of different network topologies + and protocols. After reading this chapter, you will know: @@ -31,40 +29,14 @@ How to make FreeBSD act as a bridge. - - How to set up a network filesystem. - - How to set up network booting on a diskless machine. - - How to set up a network information server for sharing user - accounts. - - - - How to set up automatic network settings using DHCP. - - - - How to set up a domain name server. - - - - How to synchronize the time and date, and set up a - time server, with the NTP protocol. - - How to set up network address translation. - - How to manage the inetd daemon. - - How to connect two computers via PLIP. @@ -1854,547 +1826,6 @@ net.link.ether.bridge.ipfw=1 - - - - - Tom - Rhodes - Reorganized and enhanced by - - - - - Bill - Swingle - Written by - - - - NFS - - NFS - Among the many different filesystems that FreeBSD supports is - the Network File System, also known as NFS. - NFS allows a system to share directories and files - with others over a network. By using NFS, users and - programs can access files on remote systems almost as if they were local - files. - - Some of the most notable benefits that - NFS can provide are: - - - - Local workstations use less disk space because - commonly used data can be stored on a single machine and still - remain accessible to others over the network. - - - - There is no need for users to have separate home directories - on every network machine. Home directories could be set up on the - NFS server and made available throughout - the network. - - - - Storage devices such as floppy disks, CDROM drives, and - ZIP drives can be used by other machines on the network. - This may reduce the number of removable media drives - throughout the network. - - - - - How <acronym>NFS</acronym> Works - - NFS consists of at least two main parts: - a server and one or more clients. The client remotely accesses - the data that is stored - on the server machine. In order for this to function properly a few - processes have to be configured and running. - - In &os; 5.X, the portmap utility - has been replaced with the rpcbind utility. Thus, - in &os; 5.X the user is required to replace every instance of - portmap with rpcbind - in the forthcoming examples. - - The server has to be running the following daemons: - - NFS - server - - - portmap - - - mountd - - - nfsd - - - - - - - - - - Daemon - Description - - - - - nfsd - The NFS daemon which services requests from - the NFS clients. - - - mountd - The NFS mount daemon which carries out - the requests that &man.nfsd.8; passes on to it. - - - portmap - The portmapper daemon - allows NFS clients to discover which port the NFS server - is using. - - - - - - The client can also run a daemon, known as - nfsiod. The - nfsiod daemon services the requests - from the NFS server. This is optional, and - improves performance, but is not required for normal and - correct operation. See the &man.nfsiod.8; manual page for - more information. - - - - - Configuring <acronym>NFS</acronym> - - NFS - configuration - - - NFS configuration is a relatively - straightforward process. The processes that need to be - running can all start at boot time with a few modifications to - your /etc/rc.conf file. - - On the NFS server, make sure that the - following options are configured in the - /etc/rc.conf file: - - portmap_enable="YES" -nfs_server_enable="YES" -mountd_flags="-r" - - mountd runs automatically whenever the - NFS server is enabled. - - On the client, make sure this option is present in - /etc/rc.conf: - - nfs_client_enable="YES" - - The /etc/exports file specifies which - filesystems NFS should export (sometimes - referred to as share). Each line in - /etc/exports specifies a filesystem to be - exported and which machines have access to that filesystem. - Along with what machines have access to that filesystem, - access options may also be specified. There are many such - options that can be used in this file but only a few will be - mentioned here. You can easily discover other options by - reading over the &man.exports.5; manual page. - - Here are a few example /etc/exports - entries: - - - NFS - export examples - - - The following examples give an idea of how to export filesystems, - although the settings may be different depending on - your environment and network configuration. - For instance, to export the /cdrom directory to - three example machines that have the same domain name as the server - (hence the lack of a domain name for each) or have entries in your - /etc/hosts file. The - flag makes the exported filesystem read-only. With this flag, the - remote system will not be able to write any changes to the - exported filesystem. - - /cdrom -ro host1 host2 host3 - - The following line exports /home to - three hosts by IP address. This is a useful setup if you have - a private network without a DNS server - configured. Optionally the /etc/hosts - file could be configured for internal hostnames; please review - &man.hosts.5; for more information. The - flag allows the subdirectories to be - mount points. In other words, it will not mount the - subdirectories but permit the client to mount only the - directories that are required or needed. - - /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 - - The following line exports /a so that - two clients from different domains may access the filesystem. - The flag allows the - root user on the remote system to write - data on the exported filesystem as root. - If the -maproot=root flag is not specified, - then even if a user has root access on - the remote system, he will not be able to modify files on - the exported filesystem. - - /a -maproot=root host.example.com box.example.org - - In order for a client to access an exported filesystem, - the client must have permission to do so. Make sure the - client is listed in your /etc/exports - file. - - In /etc/exports, each line represents - the export information for one filesystem to one host. A - remote host can only be specified once per filesystem, and may - only have one default entry. For example, assume that - /usr is a single filesystem. The - following /etc/exports would be - invalid: - - /usr/src client -/usr/ports client - - One filesystem, /usr, has two lines - specifying exports to the same host, client. - The correct format for this situation is: - - /usr/src /usr/ports client - - The properties of one filesystem exported to a given host - must all occur on one line. Lines without a client specified - are treated as a single host. This limits how you can export - filesystems, but for most people this is not an issue. - - The following is an example of a valid export list, where - /usr and /exports - are local filesystems: - - # Export src and ports to client01 and client02, but only -# client01 has root privileges on it -/usr/src /usr/ports -maproot=root client01 -/usr/src /usr/ports client02 -# The client machines have root and can mount anywhere -# on /exports. Anyone in the world can mount /exports/obj read-only -/exports -alldirs -maproot=root client01 client02 -/exports/obj -ro - - You must restart - mountd whenever you modify - /etc/exports so the changes can take effect. - This can be accomplished by sending the HUP signal - to the mountd process: - - &prompt.root; kill -HUP `cat /var/run/mountd.pid` - - Alternatively, a reboot will make FreeBSD set everything - up properly. A reboot is not necessary though. - Executing the following commands as root - should start everything up. - - On the NFS server: - - &prompt.root; portmap -&prompt.root; nfsd -u -t -n 4 -&prompt.root; mountd -r - - On the NFS client: - - &prompt.root; nfsiod -n 4 - - Now everything should be ready to actually mount a remote file - system. In these examples the - server's name will be server and the client's - name will be client. If you only want to - temporarily mount a remote filesystem or would rather test the - configuration, just execute a command like this as root on the - client: - - NFS - mounting - - &prompt.root; mount server:/home /mnt - - This will mount the /home directory - on the server at /mnt on the client. If - everything is set up correctly you should be able to enter - /mnt on the client and see all the files - that are on the server. - - If you want to automatically mount a remote filesystem - each time the computer boots, add the filesystem to the - /etc/fstab file. Here is an example: - - server:/home /mnt nfs rw 0 0 - - The &man.fstab.5; manual page lists all the available options. - - - - Practical Uses - - NFS has many practical uses. Some of the more common - ones are listed below: - - - NFS - uses - - - - Set several machines to share a CDROM or other media - among them. This is cheaper and often a more convenient - method to install software on multiple machines. - - - - On large networks, it might be more convenient to - configure a central NFS server in which - to store all the user home directories. These home - directories can then be exported to the network so that - users would always have the same home directory, - regardless of which workstation they log in to. - - - - Several machines could have a common - /usr/ports/distfiles directory. That - way, when you need to install a port on several machines, - you can quickly access the source without downloading it - on each machine. - - - - - - - - - Wylie - Stilwell - Contributed by - - - - - Chern - Lee - Rewritten by - - - - Automatic Mounts with <application>amd</application> - - amd - automatic mounter daemon - - &man.amd.8; (the automatic mounter daemon) - automatically mounts a - remote filesystem whenever a file or directory within that - filesystem is accessed. Filesystems that are inactive for a - period of time will also be automatically unmounted by - amd. Using - amd provides a simple alternative - to permanent mounts, as permanent mounts are usually listed in - /etc/fstab. - - amd operates by attaching - itself as an NFS server to the /host and - /net directories. When a file is accessed - within one of these directories, amd - looks up the corresponding remote mount and automatically mounts - it. /net is used to mount an exported - filesystem from an IP address, while /host - is used to mount an export from a remote hostname. - - An access to a file within - /host/foobar/usr would tell - amd to attempt to mount the - /usr export on the host - foobar. - - - Mounting an Export with <application>amd</application> - - You can view the available mounts of a remote host with - the showmount command. For example, to - view the mounts of a host named foobar, you - can use: - - &prompt.user; showmount -e foobar -Exports list on foobar: -/usr 10.10.10.0 -/a 10.10.10.0 -&prompt.user; cd /host/foobar/usr - - - As seen in the example, the showmount shows - /usr as an export. When changing directories to - /host/foobar/usr, amd - attempts to resolve the hostname foobar and - automatically mount the desired export. - - amd can be started by the - startup scripts by placing the following lines in - /etc/rc.conf: - - amd_enable="YES" - - Additionally, custom flags can be passed to - amd from the - amd_flags option. By default, - amd_flags is set to: - - amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" - - The /etc/amd.map file defines the - default options that exports are mounted with. The - /etc/amd.conf file defines some of the more - advanced features of amd. - - Consult the &man.amd.8; and &man.amd.conf.5; manual pages for more - information. - - - - - - - John - Lind - Contributed by - - - - Problems Integrating with Other Systems - - Certain Ethernet adapters for ISA PC systems have limitations - which can lead to serious network problems, particularly with NFS. - This difficulty is not specific to FreeBSD, but FreeBSD systems - are affected by it. - - The problem nearly always occurs when (FreeBSD) PC systems are - networked with high-performance workstations, such as those made - by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS - mount will work fine, and some operations may succeed, but - suddenly the server will seem to become unresponsive to the - client, even though requests to and from other systems continue to - be processed. This happens to the client system, whether the - client is the FreeBSD system or the workstation. On many systems, - there is no way to shut down the client gracefully once this - problem has manifested itself. The only solution is often to - reset the client, because the NFS situation cannot be - resolved. - - Though the correct solution is to get a higher - performance and capacity Ethernet adapter for the FreeBSD system, - there is a simple workaround that will allow satisfactory - operation. If the FreeBSD system is the - server, include the option - on the mount from the client. If the - FreeBSD system is the client, then mount the - NFS filesystem with the option . These - options may be specified using the fourth field of the - fstab entry on the client for automatic - mounts, or by using the parameter of the &man.mount.8; - command for manual mounts. - - It should be noted that there is a different problem, - sometimes mistaken for this one, when the NFS servers and clients - are on different networks. If that is the case, make - certain that your routers are routing the - necessary UDP information, or you will not get anywhere, no matter - what else you are doing. - - In the following examples, fastws is the host - (interface) name of a high-performance workstation, and - freebox is the host (interface) name of a FreeBSD - system with a lower-performance Ethernet adapter. Also, - /sharedfs will be the exported NFS - filesystem (see &man.exports.5;), and - /project will be the mount point on the - client for the exported filesystem. In all cases, note that - additional options, such as or - and may be desirable in - your application. - - Examples for the FreeBSD system (freebox) as - the client in /etc/fstab on freebox: - - fastws:/sharedfs /project nfs rw,-r=1024 0 0 - - As a manual mount command on freebox: - - &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project - - Examples for the FreeBSD system as the server in - /etc/fstab on fastws: - - freebox:/sharedfs /project nfs rw,-w=1024 0 0 - - As a manual mount command on fastws: - - &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project - - Nearly any 16-bit Ethernet adapter will allow operation - without the above restrictions on the read or write size. - - For anyone who cares, here is what happens when the failure - occurs, which also explains why it is unrecoverable. NFS - typically works with a block size of 8 K (though it - may do fragments of smaller sizes). Since the maximum Ethernet - packet is around 1500 bytes, the NFS block gets - split into multiple Ethernet packets, even though it is still a - single unit to the upper-level code, and must be received, - assembled, and acknowledged as a unit. The - high-performance workstations can pump out the packets which - comprise the NFS unit one right after the other, just as close - together as the standard allows. On the smaller, lower capacity - cards, the later packets overrun the earlier packets of the same - unit before they can be transferred to the host and the unit as a - whole cannot be reconstructed or acknowledged. As a result, the - workstation will time out and try again, but it will try again - with the entire 8 K unit, and the process will be repeated, ad - infinitum. - - By keeping the unit size below the Ethernet packet size - limitation, we ensure that any complete Ethernet packet received - can be acknowledged individually, avoiding the deadlock - situation. - - Overruns may still occur when a high-performance workstations - is slamming data out to a PC system, but with the better cards, - such overruns are not guaranteed on NFS units. When - an overrun occurs, the units affected will be retransmitted, and - there will be a fair chance that they will be received, assembled, - and acknowledged. - - - @@ -3458,3074 +2889,6 @@ ISDN BRI line - - - - - Bill - Swingle - Written by - - - - - Eric - Ogren - Enhanced by - - - Udo - Erdelhoff - - - - NIS/YP - - - What Is It? - NIS - Solaris - HP-UX - AIX - Linux - NetBSD - OpenBSD - NIS, which stands for Network Information Services, was - developed by Sun Microsystems to centralize administration of &unix; - (originally &sunos;) systems. It has now essentially become an - industry standard; all major &unix; like systems (&solaris;, HP-UX, &aix;, Linux, - NetBSD, OpenBSD, FreeBSD, etc) support NIS. - - yellow pagesNIS - NIS was formerly known as Yellow Pages, but because of - trademark issues, Sun changed the name. The old term (and yp) is - still often seen and used. - - - NIS - domains - - It is a RPC-based client/server system that allows a group - of machines within an NIS domain to share a common set of - configuration files. This permits a system administrator to set - up NIS client systems with only minimal configuration data and - add, remove or modify configuration data from a single - location. - - Windows NT - It is similar to the &windowsnt; domain system; although the - internal implementation of the two are not at all similar, - the basic functionality can be compared. - - - - Terms/Processes You Should Know - - There are several terms and several important user processes - that you will come across when - attempting to implement NIS on FreeBSD, whether you are trying to - create an NIS server or act as an NIS client: - - - portmap - - - - - - - - - - Term - Description - - - - - NIS domainname - An NIS master server and all of its clients - (including its slave servers) have a NIS - domainname. Similar to an &windowsnt; domain name, the NIS - domainname does not have anything to do with DNS. - - - portmap - Must be running in order to enable RPC (Remote - Procedure Call, a network protocol used by NIS). If - portmap is not running, it will be - impossible to run an NIS server, or to act as an NIS - client. - - - ypbind - - Binds an NIS client to its NIS - server. It will take the NIS domainname from the - system, and using RPC, connect to the - server. ypbind is the core of - client-server communication in an NIS environment; if - ypbind dies on a client machine, it - will not be able to access the NIS server. - - - ypserv - Should only be running on NIS servers; this is the NIS - server process itself. If &man.ypserv.8; dies, then the - server will no longer be able to respond to NIS requests - (hopefully, there is a slave server to take over for - it). There are some implementations of NIS (but not the - FreeBSD one), that do not try to reconnect to another - server if the server it used before dies. Often, the - only thing that helps in this case is to restart the - server process (or even the whole server) or the - ypbind process on the client. - - - - rpc.yppasswdd - Another process that should only be running on - NIS master servers; this is a daemon that will allow NIS - clients to change their NIS passwords. If this daemon - is not running, users will have to login to the NIS - master server and change their passwords there. - - - - - - - - - - How Does It Work? - - There are three types of hosts in an NIS environment: master - servers, slave servers, and clients. Servers act as a central - repository for host configuration information. Master servers - hold the authoritative copy of this information, while slave - servers mirror this information for redundancy. Clients rely on - the servers to provide this information to them. - - Information in many files can be shared in this manner. The - master.passwd, group, - and hosts files are commonly shared via NIS. - Whenever a process on a client needs information that would - normally be found in these files locally, it makes a query to the - NIS server that it is bound to instead. - - - Machine Types - - - - NIS - master server - - - A NIS master server. - This server, analogous to a &windowsnt; - primary domain controller, maintains the files used by all - of the NIS clients. The passwd, - group, and other various files used by the - NIS clients live on the master server. - - It is possible for one machine to be an NIS - master server for more than one NIS domain. However, this will - not be covered in this introduction, which assumes a relatively - small-scale NIS environment. - - - NIS - slave server - - - NIS slave servers. - Similar to the &windowsnt; backup domain - controllers, NIS slave servers maintain copies of the NIS - master's data files. NIS slave servers provide the redundancy, - which is needed in important environments. They also help - to balance the load of the master server: NIS Clients always - attach to the NIS server whose response they get first, and - this includes slave-server-replies. - - - NIS - client - - - NIS clients. NIS clients, like most - &windowsnt; workstations, authenticate against the NIS server (or the &windowsnt; - domain controller in the &windowsnt; workstations case) to log on. - - - - - - - Using NIS/YP - - This section will deal with setting up a sample NIS - environment. - - This section assumes that you are running FreeBSD 3.3 - or later. The instructions given here will - probably work for any version of FreeBSD greater - than 3.0, but there are no guarantees that this is - true. - - - - Planning - - Let us assume that you are the administrator of a small - university lab. This lab, which consists of 15 FreeBSD machines, - currently has no centralized point of administration; each machine - has its own /etc/passwd and - /etc/master.passwd. These files are kept in - sync with each other only through manual intervention; - currently, when you add a user to the lab, you must run - adduser on all 15 machines. - Clearly, this has to change, so you have decided to convert the - lab to use NIS, using two of the machines as servers. - - Therefore, the configuration of the lab now looks something - like: - - - - - - Machine name - IP address - Machine role - - - - - ellington - 10.0.0.2 - NIS master - - - coltrane - 10.0.0.3 - NIS slave - - - basie - 10.0.0.4 - Faculty workstation - - - bird - 10.0.0.5 - Client machine - - - cli[1-11] - 10.0.0.[6-17] - Other client machines - - - - - - If you are setting up a NIS scheme for the first time, it - is a good idea to think through how you want to go about it. No - matter what the size of your network, there are a few decisions - that need to be made. - - - Choosing a NIS Domain Name - - - NIS - domainname - - This might not be the domainname that you - are used to. It is more accurately called the - NIS domainname. When a client broadcasts its - requests for info, it includes the name of the NIS domain - that it is part of. This is how multiple servers on one - network can tell which server should answer which request. - Think of the NIS domainname as the name for a group of hosts - that are related in some way. - - Some organizations choose to use their Internet - domainname for their NIS domainname. This is not - recommended as it can cause confusion when trying to debug - network problems. The NIS domainname should be unique - within your network and it is helpful if it describes the - group of machines it represents. For example, the Art - department at Acme Inc. might be in the - acme-art NIS domain. For this example, - assume you have chosen the name - test-domain. - - SunOS - However, some operating systems (notably &sunos;) use their - NIS domain name as their Internet domain name. - If one or more machines on your network have this restriction, - you must use the Internet domain name as - your NIS domain name. - - - - Physical Server Requirements - - There are several things to keep in mind when choosing a - machine to use as a NIS server. One of the unfortunate things - about NIS is the level of dependency the clients have on the - server. If a client cannot contact the server for its NIS - domain, very often the machine becomes unusable. The lack of - user and group information causes most systems to temporarily - freeze up. With this in mind you should make sure to choose a - machine that will not be prone to being rebooted regularly, or - one that might be used for development. The NIS server should - ideally be a stand alone machine whose sole purpose in life is - to be an NIS server. If you have a network that is not very - heavily used, it is acceptable to put the NIS server on a - machine running other services, just keep in mind that if the - NIS server becomes unavailable, it will affect - all of your NIS clients adversely. - - - - - NIS Servers - - The canonical copies of all NIS information are stored on - a single machine called the NIS master server. The databases - used to store the information are called NIS maps. In FreeBSD, - these maps are stored in - /var/yp/[domainname] where - [domainname] is the name of the NIS domain - being served. A single NIS server can support several domains - at once, therefore it is possible to have several such - directories, one for each supported domain. Each domain will - have its own independent set of maps. - - NIS master and slave servers handle all NIS requests with - the ypserv daemon. ypserv - is responsible for receiving incoming requests from NIS clients, - translating the requested domain and map name to a path to the - corresponding database file and transmitting data from the - database back to the client. - - - Setting Up a NIS Master Server - - NIS - server configuration - - Setting up a master NIS server can be relatively straight - forward, depending on your needs. FreeBSD comes with support - for NIS out-of-the-box. All you need is to add the following - lines to /etc/rc.conf, and FreeBSD will - do the rest for you. - - - - nisdomainname="test-domain" - This line will set the NIS domainname to - test-domain - upon network setup (e.g. after reboot). - - - nis_server_enable="YES" - This will tell FreeBSD to start up the NIS server processes - when the networking is next brought up. - - - nis_yppasswdd_enable="YES" - This will enable the rpc.yppasswdd - daemon which, as mentioned above, will allow users to - change their NIS password from a client machine. - - - - - Depending on your NIS setup, you may need to add - further entries. See the section about NIS servers - that are also NIS clients, below, for - details. - - - Now, all you have to do is to run the command - /etc/netstart as superuser. It will - set up everything for you, using the values you defined in - /etc/rc.conf. - - - - Initializing the NIS Maps - - NIS - maps - - The NIS maps are database files, - that are kept in the /var/yp directory. - They are generated from configuration files in the - /etc directory of the NIS master, with one - exception: the /etc/master.passwd file. - This is for a good reason, you do not want to propagate - passwords to your root and other - administrative accounts to all the servers in the NIS domain. - Therefore, before we initialize the NIS maps, you should: - - &prompt.root; cp /etc/master.passwd /var/yp/master.passwd -&prompt.root; cd /var/yp -&prompt.root; vi master.passwd - - You should remove all entries regarding system accounts - (bin, tty, - kmem, games, etc), as - well as any accounts that you do not want to be propagated to the - NIS clients (for example root and any other - UID 0 (superuser) accounts). - - Make sure the - /var/yp/master.passwd is neither group - nor world readable (mode 600)! Use the - chmod command, if appropriate. - - Tru64 UNIX - When you have finished, it is time to initialize the NIS - maps! FreeBSD includes a script named - ypinit to do this for you - (see its manual page for more information). Note that this - script is available on most &unix; Operating Systems, but not on all. - On Digital UNIX/Compaq Tru64 UNIX it is called - ypsetup. - Because we are generating maps for an NIS master, we are - going to pass the option to - ypinit. - To generate the NIS maps, assuming you already performed - the steps above, run: - - ellington&prompt.root; ypinit -m test-domain -Server Type: MASTER Domain: test-domain -Creating an YP server will require that you answer a few questions. -Questions will all be asked at the beginning of the procedure. -Do you want this procedure to quit on non-fatal errors? [y/n: n] n -Ok, please remember to go back and redo manually whatever fails. -If you don't, something might not work. -At this point, we have to construct a list of this domains YP servers. -rod.darktech.org is already known as master server. -Please continue to add any slave servers, one per line. When you are -done with the list, type a <control D>. -master server : ellington -next host to add: coltrane -next host to add: ^D -The current list of NIS servers looks like this: -ellington -coltrane -Is this correct? [y/n: y] y - -[..output from map generation..] - -NIS Map update completed. -ellington has been setup as an YP master server without any errors. - - ypinit should have created - /var/yp/Makefile from - /var/yp/Makefile.dist. - When created, this file assumes that you are operating - in a single server NIS environment with only FreeBSD - machines. Since test-domain has - a slave server as well, you must edit - /var/yp/Makefile: - - ellington&prompt.root; vi /var/yp/Makefile - - You should comment out the line that says - - NOPUSH = "True" - - (if it is not commented out already). - - - - Setting up a NIS Slave Server - - NIS - slave server - - Setting up an NIS slave server is even more simple than - setting up the master. Log on to the slave server and edit the - file /etc/rc.conf as you did before. - The only difference is that we now must use the - option when running ypinit. - The option requires the name of the NIS - master be passed to it as well, so our command line looks - like: - - coltrane&prompt.root; ypinit -s ellington test-domain - -Server Type: SLAVE Domain: test-domain Master: ellington - -Creating an YP server will require that you answer a few questions. -Questions will all be asked at the beginning of the procedure. - -Do you want this procedure to quit on non-fatal errors? [y/n: n] n - -Ok, please remember to go back and redo manually whatever fails. -If you don't, something might not work. -There will be no further questions. The remainder of the procedure -should take a few minutes, to copy the databases from ellington. -Transferring netgroup... -ypxfr: Exiting: Map successfully transferred -Transferring netgroup.byuser... -ypxfr: Exiting: Map successfully transferred -Transferring netgroup.byhost... -ypxfr: Exiting: Map successfully transferred -Transferring master.passwd.byuid... -ypxfr: Exiting: Map successfully transferred -Transferring passwd.byuid... -ypxfr: Exiting: Map successfully transferred -Transferring passwd.byname... -ypxfr: Exiting: Map successfully transferred -Transferring group.bygid... -ypxfr: Exiting: Map successfully transferred -Transferring group.byname... -ypxfr: Exiting: Map successfully transferred -Transferring services.byname... -ypxfr: Exiting: Map successfully transferred -Transferring rpc.bynumber... -ypxfr: Exiting: Map successfully transferred -Transferring rpc.byname... -ypxfr: Exiting: Map successfully transferred -Transferring protocols.byname... -ypxfr: Exiting: Map successfully transferred -Transferring master.passwd.byname... -ypxfr: Exiting: Map successfully transferred -Transferring networks.byname... -ypxfr: Exiting: Map successfully transferred -Transferring networks.byaddr... -ypxfr: Exiting: Map successfully transferred -Transferring netid.byname... -ypxfr: Exiting: Map successfully transferred -Transferring hosts.byaddr... -ypxfr: Exiting: Map successfully transferred -Transferring protocols.bynumber... -ypxfr: Exiting: Map successfully transferred -Transferring ypservers... -ypxfr: Exiting: Map successfully transferred -Transferring hosts.byname... -ypxfr: Exiting: Map successfully transferred - -coltrane has been setup as an YP slave server without any errors. -Don't forget to update map ypservers on ellington. - - You should now have a directory called - /var/yp/test-domain. Copies of the NIS - master server's maps should be in this directory. You will - need to make sure that these stay updated. The following - /etc/crontab entries on your slave - servers should do the job: - - 20 * * * * root /usr/libexec/ypxfr passwd.byname -21 * * * * root /usr/libexec/ypxfr passwd.byuid - - These two lines force the slave to sync its maps with - the maps on the master server. Although these entries are - not mandatory, since the master server attempts to ensure - any changes to its NIS maps are communicated to its slaves - and because password information is vital to systems - depending on the server, it is a good idea to force the - updates. This is more important on busy networks where map - updates might not always complete. - - Now, run the command /etc/netstart on the - slave server as well, which again starts the NIS server. - - - - - NIS Clients - - An NIS client establishes what is called a binding to a - particular NIS server using the - ypbind daemon. - ypbind checks the system's default - domain (as set by the domainname command), - and begins broadcasting RPC requests on the local network. - These requests specify the name of the domain for which - ypbind is attempting to establish a binding. - If a server that has been configured to serve the requested - domain receives one of the broadcasts, it will respond to - ypbind, which will record the server's - address. If there are several servers available (a master and - several slaves, for example), ypbind will - use the address of the first one to respond. From that point - on, the client system will direct all of its NIS requests to - that server. ypbind will - occasionally ping the server to make sure it is - still up and running. If it fails to receive a reply to one of - its pings within a reasonable amount of time, - ypbind will mark the domain as unbound and - begin broadcasting again in the hopes of locating another - server. - - - Setting Up a NIS Client - - NIS - client configuration - - Setting up a FreeBSD machine to be a NIS client is fairly - straightforward. - - - - Edit the file /etc/rc.conf and - add the following lines in order to set the NIS domainname - and start ypbind upon network - startup: - - nisdomainname="test-domain" -nis_client_enable="YES" - - - - To import all possible password entries from the NIS - server, remove all user accounts from your - /etc/master.passwd file and use - vipw to add the following line to - the end of the file: - - +::::::::: - - - This line will afford anyone with a valid account in - the NIS server's password maps an account. There are - many ways to configure your NIS client by changing this - line. See the netgroups - section below for more information. - For more detailed reading see O'Reilly's book on - Managing NFS and NIS. - - - - You should keep at least one local account (i.e. - not imported via NIS) in your - /etc/master.passwd and this - account should also be a member of the group - wheel. If there is something - wrong with NIS, this account can be used to log in - remotely, become root, and fix things. - - - - - To import all possible group entries from the NIS - server, add this line to your - /etc/group file: - - +:*:: - - - - After completing these steps, you should be able to run - ypcat passwd and see the NIS server's - passwd map. - - - - - - NIS Security - - In general, any remote user can issue an RPC to - &man.ypserv.8; and retrieve the contents of your NIS maps, - provided the remote user knows your domainname. To prevent - such unauthorized transactions, &man.ypserv.8; supports a - feature called securenets which can be used to restrict access - to a given set of hosts. At startup, &man.ypserv.8; will - attempt to load the securenets information from a file called - /var/yp/securenets. - - - This path varies depending on the path specified with the - option. This file contains entries that - consist of a network specification and a network mask separated - by white space. Lines starting with # are - considered to be comments. A sample securenets file might look - like this: - - - # allow connections from local host -- mandatory -127.0.0.1 255.255.255.255 -# allow connections from any host -# on the 192.168.128.0 network -192.168.128.0 255.255.255.0 -# allow connections from any host -# between 10.0.0.0 to 10.0.15.255 -# this includes the machines in the testlab -10.0.0.0 255.255.240.0 - - If &man.ypserv.8; receives a request from an address that - matches one of these rules, it will process the request - normally. If the address fails to match a rule, the request - will be ignored and a warning message will be logged. If the - /var/yp/securenets file does not exist, - ypserv will allow connections from any - host. - - The ypserv program also has support for Wietse - Venema's - tcpwrapper package. This allows the - administrator to use the tcpwrapper configuration - files for access control instead of - /var/yp/securenets. - - - While both of these access control mechanisms provide some - security, they, like the privileged port test, are - vulnerable to IP spoofing attacks. All - NIS-related traffic should be blocked at your firewall. - - Servers using /var/yp/securenets - may fail to serve legitimate NIS clients with archaic TCP/IP - implementations. Some of these implementations set all - host bits to zero when doing broadcasts and/or fail to - observe the subnet mask when calculating the broadcast - address. While some of these problems can be fixed by - changing the client configuration, other problems may force - the retirement of the client systems in question or the - abandonment of /var/yp/securenets. - - Using /var/yp/securenets on a - server with such an archaic implementation of TCP/IP is a - really bad idea and will lead to loss of NIS functionality - for large parts of your network. - - tcpwrapper - The use of the tcpwrapper - package increases the latency of your NIS server. The - additional delay may be long enough to cause timeouts in - client programs, especially in busy networks or with slow - NIS servers. If one or more of your client systems - suffers from these symptoms, you should convert the client - systems in question into NIS slave servers and force them - to bind to themselves. - - - - - Barring Some Users from Logging On - - In our lab, there is a machine basie that is - supposed to be a faculty only workstation. We do not want to take this - machine out of the NIS domain, yet the passwd - file on the master NIS server contains accounts for both faculty and - students. What can we do? - - There is a way to bar specific users from logging on to a - machine, even if they are present in the NIS database. To do this, - all you must do is add - -username to the end of - the /etc/master.passwd file on the client - machine, where username is the username of - the user you wish to bar from logging in. This should preferably be - done using vipw, since vipw - will sanity check your changes to - /etc/master.passwd, as well as - automatically rebuild the password database when you - finish editing. For example, if we wanted to bar user - bill from logging on to basie - we would: - - basie&prompt.root; vipw -[add -bill to the end, exit] -vipw: rebuilding the database... -vipw: done - -basie&prompt.root; cat /etc/master.passwd - -root:[password]:0:0::0:0:The super-user:/root:/bin/csh -toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh -daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin -operator:*:2:5::0:0:System &:/:/sbin/nologin -bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin -tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin -kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin -games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin -news:*:8:8::0:0:News Subsystem:/:/sbin/nologin -man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin -bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin -uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico -xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin -pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin -nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin -+::::::::: --bill - -basie&prompt.root; - - - - - - - Udo - Erdelhoff - Contributed by - - - - - Using Netgroups - netgroups - - The method shown in the previous section works reasonably - well if you need special rules for a very small number of - users and/or machines. On larger networks, you - will forget to bar some users from logging - onto sensitive machines, or you may even have to modify each - machine separately, thus losing the main benefit of NIS: - centralized administration. - - The NIS developers' solution for this problem is called - netgroups. Their purpose and semantics - can be compared to the normal groups used by &unix; file - systems. The main differences are the lack of a numeric ID - and the ability to define a netgroup by including both user - accounts and other netgroups. - - Netgroups were developed to handle large, complex networks - with hundreds of users and machines. On one hand, this is - a Good Thing if you are forced to deal with such a situation. - On the other hand, this complexity makes it almost impossible to - explain netgroups with really simple examples. The example - used in the remainder of this section demonstrates this - problem. - - Let us assume that your successful introduction of NIS in - your laboratory caught your superiors' interest. Your next - job is to extend your NIS domain to cover some of the other - machines on campus. The two tables contain the names of the - new users and new machines as well as brief descriptions of - them. - - - - - - User Name(s) - Description - - - - - - alpha, beta - Normal employees of the IT department - - - - charlie, delta - The new apprentices of the IT department - - - - echo, foxtrott, golf, ... - Ordinary employees - - - - able, baker, ... - The current interns - - - - - - - - - - Machine Name(s) - Description - - - - - - - war, death, famine, pollution - Your most important servers. Only the IT - employees are allowed to log onto these - machines. - - - - pride, greed, envy, wrath, lust, sloth - Less important servers. All members of the IT - department are allowed to login onto these machines. - - - - one, two, three, four, ... - Ordinary workstations. Only the - real employees are allowed to use - these machines. - - - - trashcan - A very old machine without any critical data. - Even the intern is allowed to use this box. - - - - - - If you tried to implement these restrictions by separately - blocking each user, you would have to add one - -user line to each system's - passwd - for each user who is not allowed to login onto that system. - If you forget just one entry, you could be in trouble. It may - be feasible to do this correctly during the initial setup, - however you will eventually forget to add - the lines for new users during day-to-day operations. After - all, Murphy was an optimist. - - Handling this situation with netgroups offers several - advantages. Each user need not be handled separately; - you assign a user to one or more netgroups and allow or forbid - logins for all members of the netgroup. If you add a new - machine, you will only have to define login restrictions for - netgroups. If a new user is added, you will only have to add - the user to one or more netgroups. Those changes are - independent of each other: no more for each combination - of user and machine do... If your NIS setup is planned - carefully, you will only have to modify exactly one central - configuration file to grant or deny access to machines. - - The first step is the initialization of the NIS map - netgroup. FreeBSD's &man.ypinit.8; does not create this map by - default, but its NIS implementation will support it once it has - been created. To create an empty map, simply type - - ellington&prompt.root; vi /var/yp/netgroup - - and start adding content. For our example, we need at - least four netgroups: IT employees, IT apprentices, normal - employees and interns. - - IT_EMP (,alpha,test-domain) (,beta,test-domain) -IT_APP (,charlie,test-domain) (,delta,test-domain) -USERS (,echo,test-domain) (,foxtrott,test-domain) \ - (,golf,test-domain) -INTERNS (,able,test-domain) (,baker,test-domain) - - IT_EMP, IT_APP etc. - are the names of the netgroups. Each bracketed group adds - one or more user accounts to it. The three fields inside a - group are: - - - - The name of the host(s) where the following items are - valid. If you do not specify a hostname, the entry is - valid on all hosts. If you do specify a hostname, you - will enter a realm of darkness, horror and utter confusion. - - - - The name of the account that belongs to this - netgroup. - - - - The NIS domain for the account. You can import - accounts from other NIS domains into your netgroup if you - are one of the unlucky fellows with more than one NIS - domain. - - - - Each of these fields can contain wildcards. See - &man.netgroup.5; for details. - - - netgroups - Netgroup names longer than 8 characters should not be - used, especially if you have machines running other - operating systems within your NIS domain. The names are - case sensitive; using capital letters for your netgroup - names is an easy way to distinguish between user, machine - and netgroup names. - - Some NIS clients (other than FreeBSD) cannot handle - netgroups with a large number of entries. For example, some - older versions of &sunos; start to cause trouble if a netgroup - contains more than 15 entries. You can - circumvent this limit by creating several sub-netgroups with - 15 users or less and a real netgroup that consists of the - sub-netgroups: - - BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] -BIGGRP2 (,joe16,domain) (,joe17,domain) [...] -BIGGRP3 (,joe31,domain) (,joe32,domain) -BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 - - You can repeat this process if you need more than 225 - users within a single netgroup. - - - Activating and distributing your new NIS map is - easy: - - ellington&prompt.root; cd /var/yp -ellington&prompt.root; make - - This will generate the three NIS maps - netgroup, - netgroup.byhost and - netgroup.byuser. Use &man.ypcat.1; to - check if your new NIS maps are available: - - ellington&prompt.user; ypcat -k netgroup -ellington&prompt.user; ypcat -k netgroup.byhost -ellington&prompt.user; ypcat -k netgroup.byuser - - The output of the first command should resemble the - contents of /var/yp/netgroup. The second - command will not produce output if you have not specified - host-specific netgroups. The third command can be used to - get the list of netgroups for a user. - - The client setup is quite simple. To configure the server - war, you only have to start - &man.vipw.8; and replace the line - - +::::::::: - - with - - +@IT_EMP::::::::: - - Now, only the data for the users defined in the netgroup - IT_EMP is imported into - war's password database and only - these users are allowed to login. - - Unfortunately, this limitation also applies to the ~ - function of the shell and all routines converting between user - names and numerical user IDs. In other words, - cd ~user will not work, - ls -l will show the numerical ID instead of - the username and find . -user joe -print will - fail with No such user. To fix this, you will - have to import all user entries without allowing them - to login onto your servers. - - This can be achieved by adding another line to - /etc/master.passwd. This line should - contain: - - +:::::::::/sbin/nologin, meaning - Import all entries but replace the shell with - /sbin/nologin in the imported - entries. You can replace any field - in the passwd entry by placing a default value in your - /etc/master.passwd. - - - - Make sure that the line - +:::::::::/sbin/nologin is placed after - +@IT_EMP:::::::::. Otherwise, all user - accounts imported from NIS will have /sbin/nologin as their - login shell. - - - After this change, you will only have to change one NIS - map if a new employee joins the IT department. You could use - a similar approach for the less important servers by replacing - the old +::::::::: in their local version - of /etc/master.passwd with something like - this: - - +@IT_EMP::::::::: -+@IT_APP::::::::: -+:::::::::/sbin/nologin - - The corresponding lines for the normal workstations - could be: - - +@IT_EMP::::::::: -+@USERS::::::::: -+:::::::::/sbin/nologin - - And everything would be fine until there is a policy - change a few weeks later: The IT department starts hiring - interns. The IT interns are allowed to use the normal - workstations and the less important servers; and the IT - apprentices are allowed to login onto the main servers. You - add a new netgroup IT_INTERN, add the new IT interns to this - netgroup and start to change the configuration on each and every - machine... As the old saying goes: Errors in - centralized planning lead to global mess. - - NIS' ability to create netgroups from other netgroups can - be used to prevent situations like these. One possibility - is the creation of role-based netgroups. For example, you - could create a netgroup called - BIGSRV to define the login - restrictions for the important servers, another netgroup - called SMALLSRV for the less - important servers and a third netgroup called - USERBOX for the normal - workstations. Each of these netgroups contains the netgroups - that are allowed to login onto these machines. The new - entries for your NIS map netgroup should look like this: - - BIGSRV IT_EMP IT_APP -SMALLSRV IT_EMP IT_APP ITINTERN -USERBOX IT_EMP ITINTERN USERS - - This method of defining login restrictions works - reasonably well if you can define groups of machines with - identical restrictions. Unfortunately, this is the exception - and not the rule. Most of the time, you will need the ability - to define login restrictions on a per-machine basis. - - Machine-specific netgroup definitions are the other - possibility to deal with the policy change outlined above. In - this scenario, the /etc/master.passwd of - each box contains two lines starting with +. - The first of them adds a netgroup with the accounts allowed to - login onto this machine, the second one adds all other - accounts with /sbin/nologin as shell. It - is a good idea to use the ALL-CAPS version of the machine name - as the name of the netgroup. In other words, the lines should - look like this: - - +@BOXNAME::::::::: -+:::::::::/sbin/nologin - - Once you have completed this task for all your machines, - you will not have to modify the local versions of - /etc/master.passwd ever again. All - further changes can be handled by modifying the NIS map. Here - is an example of a possible netgroup map for this - scenario with some additional goodies: - - # Define groups of users first -IT_EMP (,alpha,test-domain) (,beta,test-domain) -IT_APP (,charlie,test-domain) (,delta,test-domain) -DEPT1 (,echo,test-domain) (,foxtrott,test-domain) -DEPT2 (,golf,test-domain) (,hotel,test-domain) -DEPT3 (,india,test-domain) (,juliet,test-domain) -ITINTERN (,kilo,test-domain) (,lima,test-domain) -D_INTERNS (,able,test-domain) (,baker,test-domain) -# -# Now, define some groups based on roles -USERS DEPT1 DEPT2 DEPT3 -BIGSRV IT_EMP IT_APP -SMALLSRV IT_EMP IT_APP ITINTERN -USERBOX IT_EMP ITINTERN USERS -# -# And a groups for a special tasks -# Allow echo and golf to access our anti-virus-machine -SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) -# -# machine-based netgroups -# Our main servers -WAR BIGSRV -FAMINE BIGSRV -# User india needs access to this server -POLLUTION BIGSRV (,india,test-domain) -# -# This one is really important and needs more access restrictions -DEATH IT_EMP -# -# The anti-virus-machine mentioned above -ONE SECURITY -# -# Restrict a machine to a single user -TWO (,hotel,test-domain) -# [...more groups to follow] - - If you are using some kind of database to manage your user - accounts, you should be able to create the first part of the - map with your database's report tools. This way, new users - will automatically have access to the boxes. - - One last word of caution: It may not always be advisable - to use machine-based netgroups. If you are deploying a couple of - dozen or even hundreds of identical machines for student labs, - you should use role-based netgroups instead of machine-based - netgroups to keep the size of the NIS map within reasonable - limits. - - - - Important Things to Remember - - There are still a couple of things that you will need to do - differently now that you are in an NIS environment. - - - - Every time you wish to add a user to the lab, you - must add it to the master NIS server only, - and you must remember to rebuild the NIS - maps. If you forget to do this, the new user will - not be able to login anywhere except on the NIS master. - For example, if we needed to add a new user - jsmith to the lab, we would: - - &prompt.root; pw useradd jsmith -&prompt.root; cd /var/yp -&prompt.root; make test-domain - - You could also run adduser jsmith instead - of pw useradd jsmith. - - - Keep the administration accounts out of the NIS - maps. You do not want to be propagating administrative - accounts and passwords to machines that will have users that - should not have access to those accounts. - - - Keep the NIS master and slave - secure, and minimize their downtime. - If somebody either hacks or simply turns off - these machines, they have effectively rendered many people without - the ability to login to the lab. - - This is the chief weakness of any centralized administration - system. If you do - not protect your NIS servers, you will have a lot of angry - users! - - - - - - NIS v1 Compatibility - - FreeBSD's ypserv has some support - for serving NIS v1 clients. FreeBSD's NIS implementation only - uses the NIS v2 protocol, however other implementations include - support for the v1 protocol for backwards compatibility with older - systems. The ypbind daemons supplied - with these systems will try to establish a binding to an NIS v1 - server even though they may never actually need it (and they may - persist in broadcasting in search of one even after they receive a - response from a v2 server). Note that while support for normal - client calls is provided, this version of ypserv does not handle - v1 map transfer requests; consequently, it cannot be used as a - master or slave in conjunction with older NIS servers that only - support the v1 protocol. Fortunately, there probably are not any - such servers still in use today. - - - - NIS Servers That Are Also NIS Clients - - Care must be taken when running ypserv in a multi-server - domain where the server machines are also NIS clients. It is - generally a good idea to force the servers to bind to themselves - rather than allowing them to broadcast bind requests and possibly - become bound to each other. Strange failure modes can result if - one server goes down and others are dependent upon it. - Eventually all the clients will time out and attempt to bind to - other servers, but the delay involved can be considerable and the - failure mode is still present since the servers might bind to each - other all over again. - - You can force a host to bind to a particular server by running - ypbind with the - flag. If you do not want to do this manually each time you - reboot your NIS server, you can add the following lines to - your /etc/rc.conf: - - nis_client_enable="YES" # run client stuff as well -nis_client_flags="-S NIS domain,server" - - See &man.ypbind.8; for further information. - - - - Password Formats - - NIS - password formats - - One of the most common issues that people run into when trying - to implement NIS is password format compatibility. If your NIS - server is using DES encrypted passwords, it will only support - clients that are also using DES. For example, if you have - &solaris; NIS clients in your network, then you will almost certainly - need to use DES encrypted passwords. - - To check which format your servers - and clients are using, look at /etc/login.conf. - If the host is configured to use DES encrypted passwords, then the - default class will contain an entry like this: - - default:\ - :passwd_format=des:\ - :copyright=/etc/COPYRIGHT:\ - [Further entries elided] - - Other possible values for the passwd_format - capability include blf and md5 - (for Blowfish and MD5 encrypted passwords, respectively). - - If you have made changes to /etc/login.conf, - you will also need to rebuild the login capability database, which is - achieved by running the following command as root: - - &prompt.root; cap_mkdb /etc/login.conf - - The format of passwords already in - /etc/master.passwd will not be updated until - a user changes his password for the first time after - the login capability database is rebuilt. - - Next, in order to ensure that passwords are encrypted with the - format that you have chosen, you should also check that the - crypt_default in /etc/auth.conf - gives precedence to your chosen password format. To do this, place - the format that you have chosen first in the list. For example, when - using DES encrypted passwords, the entry would be: - - crypt_default = des blf md5 - - Having followed the above steps on each of the &os; based NIS - servers and clients, you can be sure that they all agree on which - password format is used within your network. - If you have trouble authenticating on an NIS client, this - is a pretty good place to start looking for possible problems. - Remember: if you want to deploy an NIS server for a heterogenous - network, you will probably have to use DES on all systems - because it is the lowest common standard. - - - - - - - - Greg - Sutter - Written by - - - - DHCP - - - What Is DHCP? - - Dynamic Host Configuration Protocol - DHCP - - - Internet Software Consortium (ISC) - - - DHCP, the Dynamic Host Configuration Protocol, describes - the means by which a system can connect to a network and obtain the - necessary information for communication upon that network. FreeBSD - uses the ISC (Internet Software Consortium) DHCP implementation, so - all implementation-specific information here is for use with the ISC - distribution. - - - - What This Section Covers - - This section describes both the client-side and server-side - components of the ISC DHCP system. The client-side program, - dhclient, comes integrated within FreeBSD, and - the server-side portion is available from the - net/isc-dhcp3-server port. The - &man.dhclient.8;, &man.dhcp-options.5;, and &man.dhclient.conf.5; - manual pages, in addition to the references below, are useful - resources. - - - - How It Works - UDP - When dhclient, the DHCP client, is - executed on the client machine, it begins broadcasting - requests for configuration information. By default, these - requests are on UDP port 68. The server replies on UDP 67, - giving the client an IP address and other relevant network - information such as netmask, router, and DNS servers. All of - this information comes in the form of a DHCP - lease and is only valid for a certain time - (configured by the DHCP server maintainer). In this manner, - stale IP addresses for clients no longer connected to the - network can be automatically reclaimed. - - DHCP clients can obtain a great deal of information from - the server. An exhaustive list may be found in - &man.dhcp-options.5;. - - - - FreeBSD Integration - - FreeBSD fully integrates the ISC DHCP client, - dhclient. DHCP client support is provided - within both the installer and the base system, obviating the need - for detailed knowledge of network configurations on any network - that runs a DHCP server. dhclient has been - included in all FreeBSD distributions since 3.2. - - sysinstall - - - DHCP is supported by - sysinstall. When configuring a - network interface within sysinstall, the first question - asked is: Do you want to try DHCP configuration of - this interface?. Answering affirmatively will execute - dhclient, and if successful, will fill in - the network configuration information automatically. - - There are two things you must do to have your system use - DHCP upon startup: - - DHCP - requirements - - - - Make sure that the bpf - device is compiled into your kernel. To do this, add - device bpf (pseudo-device bpf under &os; 4.X) to your kernel - configuration file, and rebuild the kernel. For more - information about building kernels, see . - The bpf device is already - part of the GENERIC kernel that is - supplied with FreeBSD, so if you do not have a custom - kernel, you should not need to create one in order to get - DHCP working. - - For those who are particularly security conscious, - you should be warned that bpf - is also the device that allows packet sniffers to work - correctly (although they still have to be run as - root). bpf - is required to use DHCP, but if - you are very sensitive about security, you probably - should not add bpf to your - kernel in the expectation that at some point in the - future you will be using DHCP. - - - - Edit your /etc/rc.conf to - include the following: - - ifconfig_fxp0="DHCP" - - - Be sure to replace fxp0 with the - designation for the interface that you wish to dynamically - configure, as described in - . - - - If you are using a different location for - dhclient, or if you wish to pass additional - flags to dhclient, also include the - following (editing as necessary): - - dhcp_program="/sbin/dhclient" -dhcp_flags="" - - - - - DHCP - server - - The DHCP server, dhcpd, is included - as part of the net/isc-dhcp3-server port in the ports - collection. This port contains the ISC DHCP server and - documentation. - - - - Files - - DHCP - configuration files - - - /etc/dhclient.conf - dhclient requires a configuration file, - /etc/dhclient.conf. Typically the file - contains only comments, the defaults being reasonably sane. This - configuration file is described by the &man.dhclient.conf.5; - manual page. - - - /sbin/dhclient - dhclient is statically linked and - resides in /sbin. The &man.dhclient.8; - manual page gives more information about - dhclient. - - - /sbin/dhclient-script - dhclient-script is the FreeBSD-specific - DHCP client configuration script. It is described in - &man.dhclient-script.8;, but should not need any user - modification to function properly. - - - /var/db/dhclient.leases - The DHCP client keeps a database of valid leases in this - file, which is written as a log. &man.dhclient.leases.5; - gives a slightly longer description. - - - - - - Further Reading - - The DHCP protocol is fully described in - RFC 2131. - An informational resource has also been set up at - dhcp.org. - - - - Installing and Configuring a DHCP Server - - - What This Section Covers - - This section provides information on how to configure - a FreeBSD system to act as a DHCP server using the ISC - (Internet Software Consortium) implementation of the DHCP - suite. - - The server portion of the suite is not provided as part of - FreeBSD, and so you will need to install the - net/isc-dhcp3-server - port to provide this service. See for - more information on using the ports collection. - - - - DHCP Server Installation - - DHCP - installation - - In order to configure your FreeBSD system as a DHCP server, - you will need to ensure that the &man.bpf.4; - device is compiled into your kernel. To do this, add - device bpf (pseudo-device bpf under &os; 4.X) to your kernel - configuration file, and rebuild the kernel. For more - information about building kernels, see . - - The bpf device is already - part of the GENERIC kernel that is - supplied with FreeBSD, so you do not need to create a custom - kernel in order to get DHCP working. - - - Those who are particularly security conscious - should note that bpf - is also the device that allows packet sniffers to work - correctly (although such programs still need privileged - access). bpf - is required to use DHCP, but if - you are very sensitive about security, you probably - should not include bpf in your - kernel purely because you expect to use DHCP at some - point in the future. - - - The next thing that you will need to do is edit the sample - dhcpd.conf which was installed by the - net/isc-dhcp3-server port. - By default, this will be - /usr/local/etc/dhcpd.conf.sample, and you - should copy this to - /usr/local/etc/dhcpd.conf before proceeding - to make changes. - - - - Configuring the DHCP Server - - DHCP - dhcpd.conf - - dhcpd.conf is - comprised of declarations regarding subnets and hosts, and is - perhaps most easily explained using an example : - - option domain-name "example.com"; -option domain-name-servers 192.168.4.100; -option subnet-mask 255.255.255.0; - -default-lease-time 3600; -max-lease-time 86400; -ddns-update-style none; - -subnet 192.168.4.0 netmask 255.255.255.0 { - range 192.168.4.129 192.168.4.254; - option routers 192.168.4.1; -} - -host mailhost { - hardware ethernet 02:03:04:05:06:07; - fixed-address mailhost.example.com; -} - - - - This option specifies the domain that will be provided - to clients as the default search domain. See - &man.resolv.conf.5; for more information on what this - means. - - - - This option specifies a comma separated list of DNS - servers that the client should use. - - - - The netmask that will be provided to clients. - - - - A client may request a specific length of time that a - lease will be valid. Otherwise the server will assign - a lease with this expiry value (in seconds). - - - - This is the maximum length of time that the server will - lease for. Should a client request a longer lease, a lease - will be issued, although it will only be valid for - max-lease-time seconds. - - - - This option specifies whether the DHCP server should - attempt to update DNS when a lease is accepted or released. - In the ISC implementation, this option is - required. - - - - This denotes which IP addresses should be used in - the pool reserved for allocating to clients. IP - addresses between, and including, the ones stated are - handed out to clients. - - - - Declares the default gateway that will be provided to - clients. - - - - The hardware MAC address of a host (so that the DHCP server - can recognize a host when it makes a request). - - - - Specifies that the host should always be given the same - IP address. Note that using a hostname is correct here, since the DHCP - server will resolve the hostname itself before returning the - lease information. - - - - Once you have finished writing your - dhcpd.conf, you can proceed to start the - server by issuing the following command: - - &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start - - Should you need to make changes to the configuration of your - server in the future, it is important to note that sending a - SIGHUP signal to - dhcpd does not - result in the configuration being reloaded, as it does with most - daemons. You will need to send a SIGTERM - signal to stop the process, and then restart it using the command - above. - - - - Files - - DHCP - configuration files - - - /usr/local/sbin/dhcpd - dhcpd is statically linked and - resides in /usr/local/sbin. The - &man.dhcpd.8; manual page installed with the - port gives more information about - dhcpd. - - - /usr/local/etc/dhcpd.conf - dhcpd requires a configuration - file, /usr/local/etc/dhcpd.conf before it - will start providing service to clients. This file needs to - contain all the information that should be provided to clients - that are being serviced, along with information regarding the - operation of the server. This configuration file is described - by the &man.dhcpd.conf.5; manual page installed - by the port. - - - /var/db/dhcpd.leases - The DHCP server keeps a database of leases it has issued - in this file, which is written as a log. The manual page - &man.dhcpd.leases.5;, installed by the port - gives a slightly longer description. - - - /usr/local/sbin/dhcrelay - dhcrelay is used in advanced - environments where one DHCP server forwards a request from a - client to another DHCP server on a separate network. If you - require this functionality, then install the net/isc-dhcp3-server port. The - &man.dhcrelay.8; manual page provided with the - port contains more detail. - - - - - - - - - - - - - Chern - Lee - Contributed by - - - - DNS - - - Overview - BIND - - FreeBSD utilizes, by default, a version of BIND (Berkeley - Internet Name Domain), which is the most common implementation of the - DNS protocol. DNS is the protocol through which names are mapped to - IP addresses, and vice versa. For example, a query for - www.FreeBSD.org - will receive a reply with the IP address of The FreeBSD Project's - web server, whereas, a query for ftp.FreeBSD.org - will return the IP - address of the corresponding FTP machine. Likewise, the opposite can - happen. A query for an IP address can resolve its hostname. It is - not necessary to run a name server to perform DNS lookups on a system. - - - DNS - DNS is coordinated across the Internet through a somewhat - complex system of authoritative root name servers, and other - smaller-scale name servers who host and cache individual domain - information. - - - - This document refers to BIND 8.x, as it is the stable version - used in FreeBSD. BIND 9.x in FreeBSD can be installed through - the net/bind9 port. - - - - RFC1034 and RFC1035 dictate the DNS protocol. - - - - Currently, BIND is maintained by the - Internet Software Consortium (www.isc.org). - - - - - Terminology - - To understand this document, some terms related to DNS must be - understood. - - - - - - - - - Term - Definition - - - - - - Forward DNS - Mapping of hostnames to IP addresses - - - - Origin - Refers to the domain covered in a particular zone - file - - - - named, BIND, name server - Common names for the BIND name server package within - FreeBSD - - - resolver - - Resolver - A system process through which a - machine queries a name server for zone information - - - reverse DNS - - Reverse DNS - The opposite of forward DNS; mapping of IP addresses to - hostnames - - - root zone - - Root zone - - The beginning of the Internet zone hierarchy. - All zones fall under the root zone, similar to how - all files in a file system fall under the root directory. - - - - Zone - An individual domain, subdomain, or portion of the DNS administered by - the same authority - - - - - - - zones - examples - - - Examples of zones: - - - - . is the root zone - - - org. is a zone under the root zone - - - example.org is a zone under the - org. zone - - - foo.example.org. is a subdomain, a - zone under the example.org. zone - - - - 1.2.3.in-addr.arpa is a zone referencing - all IP addresses which fall under the 3.2.1.* IP space. - - - - - As one can see, the more specific part of a hostname appears to - its left. For example, example.org. is more - specific than org., as org. is - more specific than the root zone. The layout of each part of - a hostname is much like a filesystem: the /dev - directory falls within the root, and so on. - - - - - - Reasons to Run a Name Server - - Name servers usually come in two forms: an authoritative - name server, and a caching name server. - - An authoritative name server is needed when: - - - - one wants to serve DNS information to the - world, replying authoritatively to queries. - - - a domain, such as example.org, is - registered and IP addresses need to be assigned to hostnames - under it. - - - an IP address block requires reverse DNS entries (IP to - hostname). - - - a backup name server, called a slave, must reply to queries - when the primary is down or inaccessible. - - - - A caching name server is needed when: - - - - a local DNS server may cache and respond more quickly - than querying an outside name server. - - - a reduction in overall network traffic is desired (DNS - traffic has been measured to account for 5% or more of total - Internet traffic). - - - - When one queries for www.FreeBSD.org, the - resolver usually queries the uplink ISP's name server, and retrieves - the reply. With a local, caching DNS server, the query only has to - be made once to the outside world by the caching DNS server. Every - additional query will not have to look to the outside of the local - network, since the information is cached locally. - - - - - How It Works - In FreeBSD, the BIND daemon is called - named for obvious reasons. - - - - - - File - Description - - - - - - named - the BIND daemon - - - - ndc - name daemon control program - - - - /etc/namedb - directory where BIND zone information resides - - - - /etc/namedb/named.conf - daemon configuration file - - - - - - - Zone files are usually contained within the - /etc/namedb - directory, and contain the DNS zone information - served by the name server. - - - - - Starting BIND - - BIND - starting - - - Since BIND is installed by default, configuring it all is - relatively simple. - - - To ensure the named daemon is started at boot, put the following - line in /etc/rc.conf: - - named_enable="YES" - To start the daemon manually (after configuring it): - &prompt.root; ndc start - - - - Configuration Files - - BIND - configuration files - - - Using <command>make-localhost</command> - Be sure to: - - &prompt.root; cd /etc/namedb -&prompt.root; sh make-localhost - to properly create the local reverse DNS zone file in - /etc/namedb/localhost.rev. - - - - - <filename>/etc/namedb/named.conf</filename> - - // $FreeBSD$ -// -// Refer to the named(8) manual page for details. If you are ever going -// to setup a primary server, make sure you've understood the hairy -// details of how DNS is working. Even with simple mistakes, you can -// break connectivity for affected parties, or cause huge amount of -// useless Internet traffic. - -options { - directory "/etc/namedb"; - -// In addition to the "forwarders" clause, you can force your name -// server to never initiate queries of its own, but always ask its -// forwarders only, by enabling the following line: -// -// forward only; - -// If you've got a DNS server around at your upstream provider, enter -// its IP address here, and enable the line below. This will make you -// benefit from its cache, thus reduce overall DNS traffic in the -Internet. -/* - forwarders { - 127.0.0.1; - }; -*/ - - - Just as the comment says, to benefit from an uplink's cache, - forwarders can be enabled here. Under normal - circumstances, a name server will recursively query the Internet - looking at certain name servers until it finds the answer it is - looking for. Having this enabled will have it query the uplink's - name server (or name server provided) first, taking advantage of - its cache. If the uplink name server in question is a heavily - trafficked, fast name server, enabling this may be worthwhile. - - - 127.0.0.1 - will not work here. - Change this IP address to a name server at your uplink. - - - /* - * If there is a firewall between you and name servers you want - * to talk to, you might need to uncomment the query-source - * directive below. Previous versions of BIND always asked - * questions using port 53, but BIND 8.1 uses an unprivileged - * port by default. - */ - // query-source address * port 53; - - /* - * If running in a sandbox, you may have to specify a different - * location for the dumpfile. - */ - // dump-file "s/named_dump.db"; -}; - -// Note: the following will be supported in a future release. -/* -host { any; } { - topology { - 127.0.0.0/8; - }; -}; -*/ - -// Setting up secondaries is way easier and the rough picture for this -// is explained below. -// -// If you enable a local name server, don't forget to enter 127.0.0.1 -// into your /etc/resolv.conf so this server will be queried first. -// Also, make sure to enable it in /etc/rc.conf. - -zone "." { - type hint; - file "named.root"; -}; - -zone "0.0.127.IN-ADDR.ARPA" { - type master; - file "localhost.rev"; -}; - -zone -"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { - type master; - file "localhost.rev"; -}; - -// NB: Do not use the IP addresses below, they are faked, and only -// serve demonstration/documentation purposes! -// -// Example secondary config entries. It can be convenient to become -// a secondary at least for the zone where your own domain is in. Ask -// your network administrator for the IP address of the responsible -// primary. -// -// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone! -// (This is the first bytes of the respective IP address, in reverse -// order, with ".IN-ADDR.ARPA" appended.) -// -// Before starting to setup a primary zone, better make sure you fully -// understand how DNS and BIND works, however. There are sometimes -// unobvious pitfalls. Setting up a secondary is comparably simpler. -// -// NB: Don't blindly enable the examples below. :-) Use actual names -// and addresses instead. -// -// NOTE!!! FreeBSD runs BIND in a sandbox (see named_flags in rc.conf). -// The directory containing the secondary zones must be write accessible -// to BIND. The following sequence is suggested: -// -// mkdir /etc/namedb/s -// chown bind:bind /etc/namedb/s -// chmod 750 /etc/namedb/s - - For more information on running BIND in a sandbox, see - Running named in a sandbox. - - - /* -zone "example.com" { - type slave; - file "s/example.com.bak"; - masters { - 192.168.1.1; - }; -}; - -zone "0.168.192.in-addr.arpa" { - type slave; - file "s/0.168.192.in-addr.arpa.bak"; - masters { - 192.168.1.1; - }; -}; -*/ - In named.conf, these are examples of slave - entries for a forward and reverse zone. - - For each new zone served, a new zone entry must be added to - named.conf. - - For example, the simplest zone entry for - example.org can look like: - - zone "example.org" { - type master; - file "example.org"; -}; - - The zone is a master, as indicated by the - statement, holding its zone information in - /etc/namedb/example.org indicated by - the statement. - - zone "example.org" { - type slave; - file "example.org"; -}; - - In the slave case, the zone information is transferred from - the master name server for the particular zone, and saved in the - file specified. If and when the master server dies or is - unreachable, the slave name server will have the transferred - zone information and will be able to serve it. - - - - Zone Files - - An example master zone file for example.org - (existing within /etc/namedb/example.org) - is as follows: - - - $TTL 3600 - -example.org. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial - 10800 ; Refresh - 3600 ; Retry - 604800 ; Expire - 86400 ) ; Minimum TTL - -; DNS Servers -@ IN NS ns1.example.org. -@ IN NS ns2.example.org. - -; Machine Names -localhost IN A 127.0.0.1 -ns1 IN A 3.2.1.2 -ns2 IN A 3.2.1.3 -mail IN A 3.2.1.10 -@ IN A 3.2.1.30 - -; Aliases -www IN CNAME @ - -; MX Record -@ IN MX 10 mail.example.org. - - - Note that every hostname ending in a . is an - exact hostname, whereas everything without a trailing - . is referenced to the origin. For example, - www is translated into www.origin. - In our fictitious zone file, our origin - is example.org., so - www would translate to - www.example.org. - - - - The format of a zone file follows: - - recordname IN recordtype value - - - DNS - records - - - The most commonly used DNS records: - - - - - SOA - - start of zone authority - - - - NS - - an authoritative name server - - - - A - - a host address - - - - CNAME - - the canonical name for an alias - - - - MX - - mail exchanger - - - - PTR - - a domain name pointer (used in reverse DNS) - - - - - -example.org. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial - 10800 ; Refresh after 3 hours - 3600 ; Retry after 1 hour - 604800 ; Expire after 1 week - 86400 ) ; Minimum TTL of 1 day - - - - - - example.org. - - the domain name, also the origin for this - zone file. - - - - ns1.example.org. - - the primary/authoritative name server for this - zone. - - - - admin.example.org. - - the responsible person for this zone, - email address with @ - replaced. (admin@example.org becomes - admin.example.org) - - - - - 5 - - the serial number of the file. This - must be incremented each time the zone file is modified. - Nowadays, many admins prefer a - yyyymmddrr format for the serial - number. 2001041002 would mean last modified 04/10/2001, - the latter 02 being the second time the zone file has - been modified this day. The serial number is important - as it alerts slave name servers for a zone when it is - updated. - - - - - -@ IN NS ns1.example.org. - - - This is an NS entry. Every name server that is going to reply - authoritatively for the zone must have one of these entries. - The @ as seen here could have been - example.org. - The @ translates to the origin. - - - -localhost IN A 127.0.0.1 -ns1 IN A 3.2.1.2 -ns2 IN A 3.2.1.3 -mail IN A 3.2.1.10 -@ IN A 3.2.1.30 - - - The A record indicates machine names. As seen above, - ns1.example.org would resolve to - 3.2.1.2. Again, - the origin symbol, @, is - used here, thus meaning example.org - would resolve to 3.2.1.30. - - - -www IN CNAME @ - - - The canonical name record is usually used for giving aliases - to a machine. In the example, www is - aliased to the machine addressed to the origin, or - example.org - (3.2.1.30). - CNAMEs can be used to provide alias - hostnames, or round robin one hostname among multiple - machines. - - - - MX record - - - -@ IN MX 10 mail.example.org. - - - The MX record indicates which mail - servers are responsible for handling incoming mail for the - zone. mail.example.org is the - hostname of the mail server, and 10 being the priority of - that mail server. - - - - One can have several mail servers, with priorities of 3, 2, - 1. A mail server attempting to deliver to example.org would first try the - highest priority MX, then the second highest, etc, until the - mail can be properly delivered. - - - - For in-addr.arpa zone files (reverse DNS), the same format is - used, except with PTR entries instead of - A or CNAME. - - - $TTL 3600 - -1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( - 5 ; Serial - 10800 ; Refresh - 3600 ; Retry - 604800 ; Expire - 3600 ) ; Minimum - -@ IN NS ns1.example.org. -@ IN NS ns2.example.org. - -2 IN PTR ns1.example.org. -3 IN PTR ns2.example.org. -10 IN PTR mail.example.org. -30 IN PTR example.org. - - This file gives the proper IP address to hostname mappings of our above - fictitious domain. - - - - - - Caching Name Server - - BIND - caching name server - - - A caching name server is a name server that is not - authoritative for any zones. It simply asks queries of its own, - and remembers them for later use. To set one up, just configure - the name server as usual, omitting any inclusions of zones. - - - - - Running <application>named</application> in a Sandbox - - BIND - running in a sandbox - - - - chroot - - For added security you may want to run &man.named.8; as an - unprivileged user, and configure it to &man.chroot.8; into a - sandbox directory. This makes everything outside of the sandbox - inaccessible to the named daemon. Should - named be compromised, this will help to - reduce the damage that can be caused. By default, FreeBSD has a user - and a group called bind, intended for this - use. - - Various people would recommend that instead of configuring - named to chroot, you - should run named inside a &man.jail.8;. - This section does not attempt to cover this situation. - - - Since named will not be able to - access anything outside of the sandbox (such as shared - libraries, log sockets, and so on), there are a number of steps - that need to be followed in order to allow - named to function correctly. In the - following checklist, it is assumed that the path to the sandbox - is /etc/namedb and that you have made no - prior modifications to the contents of this directory. Perform - the following steps as root: - - - - Create all directories that named - expects to see: - - &prompt.root; cd /etc/namedb -&prompt.root; mkdir -p bin dev etc var/tmp var/run master slave -&prompt.root; chown bind:bind slave var/* - - - - - - named only needs write access to - these directories, so that is all we give it. - - - - - - Rearrange and create basic zone and configuration files: - &prompt.root; cp /etc/localtime etc -&prompt.root; mv named.conf etc && ln -sf etc/named.conf -&prompt.root; mv named.root master - -&prompt.root; sh make-localhost && mv localhost.rev localhost-v6.rev master -&prompt.root; cat > master/named.localhost -$ORIGIN localhost. -$TTL 6h -@ IN SOA localhost. postmaster.localhost. ( - 1 ; serial - 3600 ; refresh - 1800 ; retry - 604800 ; expiration - 3600 ) ; minimum - IN NS localhost. - IN A 127.0.0.1 -^D - - - - This allows named to log the - correct time to &man.syslogd.8;. - - - - - - If you are running a version of &os; prior to 4.9-RELEASE, build a statically linked copy of - named-xfer, and copy it into the sandbox: - - &prompt.root; cd /usr/src/lib/libisc -&prompt.root; make cleandir && make cleandir && make depend && make all -&prompt.root; cd /usr/src/lib/libbind -&prompt.root; make cleandir && make cleandir && make depend && make all -&prompt.root; cd /usr/src/libexec/named-xfer -&prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all -&prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer - - After your statically linked - named-xfer is installed some cleaning up - is required, to avoid leaving stale copies of libraries or - programs in your source tree: - - &prompt.root; cd /usr/src/lib/libisc -&prompt.root; make cleandir -&prompt.root; cd /usr/src/lib/libbind -&prompt.root; make cleandir -&prompt.root; cd /usr/src/libexec/named-xfer -&prompt.root; make cleandir - - - - This step has been reported to fail occasionally. If this - happens to you, then issue the command: - - &prompt.root; cd /usr/src && make cleandir && make cleandir - - and delete your /usr/obj tree: - - &prompt.root; rm -fr /usr/obj && mkdir /usr/obj - - This will clean out any cruft from your - source tree, and retrying the steps above should then work. - - - - If you are running &os; version 4.9-RELEASE or later, then - the copy of named-xfer in - /usr/libexec is statically linked by default, - and you can simply use &man.cp.1; to copy it into your sandbox. - - - - Make a dev/null that - named can see and write to: - - &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 -&prompt.root; chmod 666 null - - - - Symlink /var/run/ndc to - /etc/namedb/var/run/ndc: - - &prompt.root; ln -sf /etc/namedb/var/run/ndc /var/run/ndc - - - This simply avoids having to specify the - option to &man.ndc.8; every time you - run it. Since the contents of /var/run are deleted on boot, - if this is something that you find useful you - may wish to add this command to root's crontab, making use - of the option. See - &man.crontab.5; for more information regarding - this. - - - - - - Configure &man.syslogd.8; to create an extra - log socket that - named can write to. To do this, - add -l /etc/namedb/dev/log to the - syslogd_flags variable in - /etc/rc.conf. - - - - Arrange to have named start - and chroot itself to the sandbox by - adding the following to - /etc/rc.conf: - - named_enable="YES" -named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" - - - Note that the configuration file - /etc/named.conf is denoted by a full - pathname relative to the sandbox, i.e. in - the line above, the file referred to is actually - /etc/namedb/etc/named.conf. - - - - - The next step is to edit - /etc/namedb/etc/named.conf so that - named knows which zones to load and - where to find them on the disk. There follows a commented - example (anything not specifically commented here is no - different from the setup for a DNS server not running in a - sandbox): - - options { - directory "/"; - named-xfer "/bin/named-xfer"; - version ""; // Don't reveal BIND version - query-source address * port 53; -}; -// ndc control socket -controls { - unix "/var/run/ndc" perm 0600 owner 0 group 0; -}; -// Zones follow: -zone "localhost" IN { - type master; - file "master/named.localhost"; - allow-transfer { localhost; }; - notify no; -}; -zone "0.0.127.in-addr.arpa" IN { - type master; - file "master/localhost.rev"; - allow-transfer { localhost; }; - notify no; -}; -zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { - type master; - file "master/localhost-v6.rev"; - allow-transfer { localhost; }; - notify no; -}; -zone "." IN { - type hint; - file "master/named.root"; -}; -zone "private.example.net" in { - type master; - file "master/private.example.net.db"; - allow-transfer { 192.168.10.0/24; }; -}; -zone "10.168.192.in-addr.arpa" in { - type slave; - masters { 192.168.10.2; }; - file "slave/192.168.10.db"; -}; - - - - The - directory statement is specified as - /, since all files that - named needs are within this - directory (recall that this is equivalent to a - normal user's - /etc/namedb). - - - - Specifies the full path - to the named-xfer binary (from - named's frame of reference). This - is necessary since named is - compiled to look for named-xfer in - /usr/libexec by default. - - Specifies the filename (relative - to the directory statement above) where - named can find the zone file for this - zone. - - Specifies the filename - (relative to the directory statement above) - where named should write a copy of - the zone file for this zone after successfully transferring it - from the master server. This is why we needed to change the - ownership of the directory slave to - bind in the setup stages above. - - - - After completing the steps above, either reboot your - server or restart &man.syslogd.8; and start &man.named.8;, making - sure to use the new options specified in - syslogd_flags and - named_flags. You should now be running a - sandboxed copy of named! - - - - - Security - - Although BIND is the most common implementation of DNS, - there is always the issue of security. Possible and - exploitable security holes are sometimes found. - - - - It is a good idea to read CERT's security advisories and - to subscribe to the &a.security-notifications; - to stay up to date with the current Internet and FreeBSD security - issues. - - - If a problem arises, keeping sources up to date and having a - fresh build of named would not hurt. - - - - Further Reading - - BIND/named manual pages: &man.ndc.8; &man.named.8; &man.named.conf.5; - - - - - Official ISC BIND - Page - - - - - BIND FAQ - - - - O'Reilly - DNS and BIND 4th Edition - - - - RFC1034 - - Domain Names - Concepts and Facilities - - - - RFC1035 - - Domain Names - Implementation and Specification - - - - - - - - - - Tom - Hukins - Contributed by - - - - NTP - - NTP - - - Overview - - Over time, a computer's clock is prone to drift. As time - passes, the computer's clock becomes less accurate. NTP - (Network Time Protocol) is one way to ensure your clock is - right. - - Many Internet services rely on, or greatly benefit from, - computers' clocks being accurate. For example, a Web server - may receive requests to send a file if it has modified since a - certain time. Services such as &man.cron.8; run commands at a - given time. If the clock is inaccurate, these commands may - not run when expected. - - - NTP - ntpd - - FreeBSD ships with the &man.ntpd.8; NTP server which can - be used to query other NTP servers to set the clock on your - machine or provide time services to others. - - - - Choosing Appropriate NTP Servers - - - NTP - choosing servers - - - In order to synchronize your clock, you will need to find - one or more NTP servers to use. Your network administrator or - ISP may have set up an NTP server for this purpose—check - their documentation to see if this is the case. There is a - list of - publicly accessible NTP servers which you can use to - find an NTP server near to you. Make sure you are aware of - the policy for any servers you choose, and ask for permission - if required. - - Choosing several unconnected NTP servers is a good idea in - case one of the servers you are using becomes unreachable or - its clock is unreliable. &man.ntpd.8; uses the responses it - receives from other servers intelligently—it will favor - unreliable servers less than reliable ones. - - - - Configuring Your Machine - - - NTP - configuration - - - - Basic Configuration - ntpdate - - If you only wish to synchronize your clock when the - machine boots up, you can use &man.ntpdate.8;. This may be - appropriate for some desktop machines which are frequently - rebooted and only require infrequent synchronization, but - most machines should run &man.ntpd.8;. - - Using &man.ntpdate.8; at boot time is also a good idea - for machines that run &man.ntpd.8;. The &man.ntpd.8; program changes the - clock gradually, whereas &man.ntpdate.8; sets the clock, no - matter how great the difference between a machine's current - clock setting and the correct time. - - To enable &man.ntpdate.8; at boot time, add - ntpdate_enable="YES" to - /etc/rc.conf. You will also need to - specify all servers you wish to synchronize with and any - flags to be passed to &man.ntpdate.8; in - ntpdate_flags. - - - - - NTP - ntp.conf - - - General Configuration - - NTP is configured by the - /etc/ntp.conf file in the format - described in &man.ntp.conf.5;. Here is a simple - example: - - server ntplocal.example.com prefer -server timeserver.example.org -server ntp2a.example.net - -driftfile /var/db/ntp.drift - - The server option specifies which - servers are to be used, with one server listed on each line. - If a server is specified with the prefer - argument, as with ntplocal.example.com, that server is - preferred over other servers. A response from a preferred - server will be discarded if it differs significantly from - other servers' responses, otherwise it will be used without - any consideration to other responses. The - prefer argument is normally used for NTP - servers that are known to be highly accurate, such as those - with special time monitoring hardware. - - The driftfile option specifies which - file is used to store the system clock's frequency offset. - The &man.ntpd.8; program uses this to automatically compensate for the - clock's natural drift, allowing it to maintain a reasonably - correct setting even if it is cut off from all external time - sources for a period of time. - - The driftfile option specifies which - file is used to store information about previous responses - from the NTP servers you are using. This file contains - internal information for NTP. It should not be modified by - any other process. - - - - Controlling Access to Your Server - - By default, your NTP server will be accessible to all - hosts on the Internet. The restrict - option in /etc/ntp.conf allows you to control which - machines can access your server. - - If you want to deny all machines from accessing your NTP - server, add the following line to - /etc/ntp.conf: - - restrict default ignore - - If you only want to - allow machines within your own network to synchronize their - clocks with your server, but ensure they are not allowed to - configure the server or used as peers to synchronize - against, add - - restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap - - instead, where 192.168.1.0 is - an IP address on your network and 255.255.255.0 is your network's - netmask. - - /etc/ntp.conf can contain multiple - restrict options. For more details, see - the Access Control Support subsection of - &man.ntp.conf.5;. - - - - - Running the NTP Server - - To ensure the NTP server is started at boot time, add the - line xntpd_enable="YES" to - /etc/rc.conf. If you wish to pass - additional flags to &man.ntpd.8;, edit the - xntpd_flags parameter in - /etc/rc.conf. - - To start the server without rebooting your machine, run - ntpd being sure to specify any additional - parameters from xntpd_flags in - /etc/rc.conf. For example: - &prompt.root; ntpd -p /var/run/ntpd.pid - - - Under &os; 5.X, various options in - /etc/rc.conf have been renamed. Thus, - you have to replace every instance of xntpd - with ntpd in the options above. - - - - Using ntpd with a Temporary Internet - Connection - - The &man.ntpd.8; program does not need a permanent - connection to the Internet to function properly. However, if - you have a temporary connection that is configured to dial out - on demand, it is a good idea to prevent NTP traffic from - triggering a dial out or keeping the connection alive. If you - are using user PPP, you can use filter - directives in /etc/ppp/ppp.conf. For - example: - - set filter dial 0 deny udp src eq 123 - # Prevent NTP traffic from initiating dial out - set filter dial 1 permit 0 0 - set filter alive 0 deny udp src eq 123 - # Prevent incoming NTP traffic from keeping the connection open - set filter alive 1 deny udp dst eq 123 - # Prevent outgoing NTP traffic from keeping the connection open - set filter alive 2 permit 0/0 0/0 - - For more details see the PACKET - FILTERING section in &man.ppp.8; and the examples in - /usr/share/examples/ppp/. - - - Some Internet access providers block low-numbered ports, - preventing NTP from functioning since replies never - reach your machine. - - - - - Further Information - - Documentation for the NTP server can be found in - /usr/share/doc/ntp/ in HTML - format. - - - @@ -6807,452 +3170,6 @@ redirect_port tcp 192.168.0.3:80 80 - - - - - Chern - Lee - Contributed by - - - - - The <application>inetd</application> <quote>Super-Server</quote> - - - Overview - - &man.inetd.8; is referred to as the Internet - Super-Server because it manages connections for several - daemons. Programs that provide network service are commonly - known as daemons. inetd serves as a - managing server for other daemons. When a connection is - received by inetd, it determines - which daemon the connection is destined for, spawns the - particular daemon and delegates the socket to it. Running one - instance of inetd reduces the overall - system load as compared to running each daemon individually in - stand-alone mode. - - Primarily, inetd is used to - spawn other daemons, but several trivial protocols are handled - directly, such as chargen, - auth, and - daytime. - - This section will cover the basics in configuring - inetd through its command-line - options and its configuration file, - /etc/inetd.conf. - - - - Settings - - inetd is initialized through - the /etc/rc.conf system. The - inetd_enable option is set to - NO by default, but is often times turned on by - sysinstall with the medium security - profile. Placing: - inetd_enable="YES" or - inetd_enable="NO" into - /etc/rc.conf can enable or disable - inetd starting at boot time. - - Additionally, different command-line options can be passed - to inetd via the - inetd_flags option. - - - - Command-Line Options - - inetd synopsis: - - - - - - -d - - - Turn on debugging. - - - - - -l - - - Turn on logging of successful connections. - - - - - -w - - - Turn on TCP Wrapping for external services (on by - default). - - - - - -W - - - Turn on TCP Wrapping for internal services which are - built into inetd (on by - default). - - - - - -c maximum - - - Specify the default maximum number of simultaneous - invocations of each service; the default is unlimited. - May be overridden on a per-service basis with the - parameter. - - - - - -C rate - - - Specify the default maximum number of times a - service can be invoked from a single IP address in one - minute; the default is unlimited. May be overridden on a - per-service basis with the - - parameter. - - - - - -R rate - - - Specify the maximum number of times a service can be - invoked in one minute; the default is 256. A rate of 0 - allows an unlimited number of invocations. - - - - - -a - - - Specify one specific IP address to bind to. - Alternatively, a hostname can be specified, in which case - the IPv4 or IPv6 address which corresponds to that - hostname is used. Usually a hostname is specified when - inetd is run inside a - &man.jail.8;, in which case the hostname corresponds to - the &man.jail.8; environment. - - When hostname specification is used and both IPv4 - and IPv6 bindings are desired, one entry with the - appropriate protocol type for each binding is required for - each service in /etc/inetd.conf. For - example, a TCP-based service would need two entries, one - using tcp4 for the protocol and the other using - tcp6. - - - - - -p - - - Specify an alternate file in which to store the - process ID. - - - - - These options can be passed to - inetd using the - inetd_flags option in - /etc/rc.conf. By default, - inetd_flags is set to -wW, - which turns on TCP wrapping for - inetd's internal and external - services. For novice users, these parameters usually do not need - to be modified or even entered in - /etc/rc.conf. - - - An external service is a daemon outside of - inetd, which is invoked when a - connection is received for it. On the other hand, an internal - service is one that inetd has the - facility of offering within itself. - - - - - - <filename>inetd.conf</filename> - - Configuration of inetd is - controlled through the /etc/inetd.conf - file. - - When a modification is made to - /etc/inetd.conf, - inetd can be forced to re-read its - configuration file by sending a HangUP signal to the - inetd process as shown: - - - Sending <application>inetd</application> a HangUP Signal - - &prompt.root; kill -HUP `cat /var/run/inetd.pid` - - - Each line of the configuration file specifies an - individual daemon. Comments in the file are preceded by a - #. The format of - /etc/inetd.conf is as follows: - - service-name -socket-type -protocol -{wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] -user[:group][/login-class] -server-program -server-program-arguments - - An example entry for the ftpd daemon - using IPv4: - - ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l - - - - service-name - - - This is the service name of the particular daemon. - It must correspond to a service listed in - /etc/services. This determines which - port inetd must listen to. If - a new service is being created, it must be placed in - /etc/services - first. - - - - - socket-type - - - Either stream, - dgram, raw, or - seqpacket. stream - must be used for connection-based, TCP daemons, while - dgram is used for daemons utilizing the - UDP transport protocol. - - - - - protocol - - - One of the following: - - - - - - Protocol - Explanation - - - - - tcp, tcp4 - TCP IPv4 - - - udp, udp4 - UDP IPv4 - - - tcp6 - TCP IPv6 - - - udp6 - UDP IPv6 - - - tcp46 - Both TCP IPv4 and v6 - - - udp46 - Both UDP IPv4 and v6 - - - - - - - - - {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] - - - indicates whether the - daemon invoked from inetd is - able to handle its own socket or not. - socket types must use the - option, while stream socket daemons, which are usually - multi-threaded, should use . - usually hands off multiple sockets - to a single daemon, while spawns a - child daemon for each new socket. - - The maximum number of child daemons - inetd may spawn can be set using - the option. If a limit of ten - instances of a particular daemon is needed, a - /10 would be placed after - . - - In addition to , another - option limiting the maximum connections from a single - place to a particular daemon can be enabled. - does - just this. A value of ten here would limit any particular - IP address connecting to a particular service to ten - attempts per minute. This is useful to prevent - intentional or unintentional resource consumption and - Denial of Service (DoS) attacks to a machine. - - In this field, or - is mandatory. - and - are - optional. - - A stream-type multi-threaded daemon without any - or - limits - would simply be: nowait. - - The same daemon with a maximum limit of ten daemons - would read: nowait/10. - - Additionally, the same setup with a limit of twenty - connections per IP address per minute and a maximum - total limit of ten child daemons would read: - nowait/10/20. - - These options are all utilized by the default - settings of the fingerd daemon, - as seen here: - - finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s - - - - - user - - - This is the username that the particular daemon - should run as. Most commonly, daemons run as the - root user. For security purposes, it is - common to find some servers running as the - daemon user, or the least privileged - nobody user. - - - - - server-program - - - The full path of the daemon to be executed when a - connection is received. If the daemon is a service - provided by inetd internally, - then should be - used. - - - - - server-program-arguments - - - This works in conjunction with - by specifying the - arguments, starting with argv[0], passed to the daemon on - invocation. If mydaemon -d is - the command line, mydaemon -d would be - the value of . - Again, if the daemon is an internal service, use - here. - - - - - - - Security - - Depending on the security profile chosen at install, many - of inetd's daemons may be enabled by - default. If there is no apparent need for a particular daemon, - disable it! Place a # in front of the daemon in - question, and send a hangup signal - to inetd. - Some daemons, such as fingerd, may - not be desired at all because they provide an attacker with too - much information. - - Some daemons are not security-conscious and have long, or - non-existent timeouts for connection attempts. This allows an - attacker to slowly send connections to a particular daemon, thus - saturating available resources. It may be a good idea to place - and - limitations on certain daemons. - - By default, TCP wrapping is turned on. Consult the - &man.hosts.access.5; manual page for more information on placing - TCP restrictions on various inetd - invoked daemons. - - - - Miscellaneous - - daytime, - time, - echo, - discard, - chargen, and - auth are all internally provided - services of inetd. - - The auth service provides identity - (ident, identd) network services, and is configurable to a certain - degree. - - Consult the &man.inetd.8; manual page for more in-depth - information. - - - Parallel Line IP (PLIP) diff --git a/en_US.ISO8859-1/books/handbook/book.sgml b/en_US.ISO8859-1/books/handbook/book.sgml index 123dcdbbcb..767c0ee917 100644 --- a/en_US.ISO8859-1/books/handbook/book.sgml +++ b/en_US.ISO8859-1/books/handbook/book.sgml @@ -48,6 +48,7 @@ + @@ -230,6 +231,7 @@ + diff --git a/en_US.ISO8859-1/books/handbook/chapters.ent b/en_US.ISO8859-1/books/handbook/chapters.ent index 1302f7ce0a..7fc5788b1f 100644 --- a/en_US.ISO8859-1/books/handbook/chapters.ent +++ b/en_US.ISO8859-1/books/handbook/chapters.ent @@ -34,6 +34,7 @@ + diff --git a/en_US.ISO8859-1/books/handbook/network-servers/Makefile b/en_US.ISO8859-1/books/handbook/network-servers/Makefile new file mode 100644 index 0000000000..150dbe3121 --- /dev/null +++ b/en_US.ISO8859-1/books/handbook/network-servers/Makefile @@ -0,0 +1,15 @@ +# +# Build the Handbook with just the content from this chapter. +# +# $FreeBSD$ +# + +CHAPTERS= network-servers/chapter.sgml + +VPATH= .. + +MASTERDOC= ${.CURDIR}/../${DOC}.${DOCBOOKSUFFIX} + +DOC_PREFIX?= ${.CURDIR}/../../../.. + +.include "../Makefile" diff --git a/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml b/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml new file mode 100644 index 0000000000..46997346d7 --- /dev/null +++ b/en_US.ISO8859-1/books/handbook/network-servers/chapter.sgml @@ -0,0 +1,4129 @@ + + + + Network Servers + + + Synopsis + + This chapter will cover some of the more frequently used network + services on &unix; systems. We will cover how to install, + configure, test, and maintain many different types of network services. + Example configuration files are included throughout this + chapter for you to benefit from. + + After reading this chapter, you will know: + + + + How to set up a network filesystem. + + + + How to set up a network information server for sharing user + accounts. + + + + How to set up automatic network settings using DHCP. + + + + How to set up a domain name server. + + + + How to synchronize the time and date, and set up a + time server, with the NTP protocol. + + + + How to manage the inetd daemon. + + + + + Before reading this chapter, you should: + + + + Understand the basics of the /etc/rc scripts. + + + + Be familiar with basic network terminology. + + + + + + + + + Tom + Rhodes + Reorganized and enhanced by + + + + + Bill + Swingle + Written by + + + + NFS + + NFS + Among the many different filesystems that FreeBSD supports is + the Network File System, also known as NFS. + NFS allows a system to share directories and files + with others over a network. By using NFS, users and + programs can access files on remote systems almost as if they were local + files. + + Some of the most notable benefits that + NFS can provide are: + + + + Local workstations use less disk space because + commonly used data can be stored on a single machine and still + remain accessible to others over the network. + + + + There is no need for users to have separate home directories + on every network machine. Home directories could be set up on the + NFS server and made available throughout + the network. + + + + Storage devices such as floppy disks, CDROM drives, and + ZIP drives can be used by other machines on the network. + This may reduce the number of removable media drives + throughout the network. + + + + + How <acronym>NFS</acronym> Works + + NFS consists of at least two main parts: + a server and one or more clients. The client remotely accesses + the data that is stored + on the server machine. In order for this to function properly a few + processes have to be configured and running. + + In &os; 5.X, the portmap utility + has been replaced with the rpcbind utility. Thus, + in &os; 5.X the user is required to replace every instance of + portmap with rpcbind + in the forthcoming examples. + + The server has to be running the following daemons: + + NFS + server + + + portmap + + + mountd + + + nfsd + + + + + + + + + + Daemon + Description + + + + + nfsd + The NFS daemon which services requests from + the NFS clients. + + + mountd + The NFS mount daemon which carries out + the requests that &man.nfsd.8; passes on to it. + + + portmap + The portmapper daemon + allows NFS clients to discover which port the NFS server + is using. + + + + + + The client can also run a daemon, known as + nfsiod. The + nfsiod daemon services the requests + from the NFS server. This is optional, and + improves performance, but is not required for normal and + correct operation. See the &man.nfsiod.8; manual page for + more information. + + + + + Configuring <acronym>NFS</acronym> + + NFS + configuration + + + NFS configuration is a relatively + straightforward process. The processes that need to be + running can all start at boot time with a few modifications to + your /etc/rc.conf file. + + On the NFS server, make sure that the + following options are configured in the + /etc/rc.conf file: + + portmap_enable="YES" +nfs_server_enable="YES" +mountd_flags="-r" + + mountd runs automatically whenever the + NFS server is enabled. + + On the client, make sure this option is present in + /etc/rc.conf: + + nfs_client_enable="YES" + + The /etc/exports file specifies which + filesystems NFS should export (sometimes + referred to as share). Each line in + /etc/exports specifies a filesystem to be + exported and which machines have access to that filesystem. + Along with what machines have access to that filesystem, + access options may also be specified. There are many such + options that can be used in this file but only a few will be + mentioned here. You can easily discover other options by + reading over the &man.exports.5; manual page. + + Here are a few example /etc/exports + entries: + + + NFS + export examples + + + The following examples give an idea of how to export filesystems, + although the settings may be different depending on + your environment and network configuration. + For instance, to export the /cdrom directory to + three example machines that have the same domain name as the server + (hence the lack of a domain name for each) or have entries in your + /etc/hosts file. The + flag makes the exported filesystem read-only. With this flag, the + remote system will not be able to write any changes to the + exported filesystem. + + /cdrom -ro host1 host2 host3 + + The following line exports /home to + three hosts by IP address. This is a useful setup if you have + a private network without a DNS server + configured. Optionally the /etc/hosts + file could be configured for internal hostnames; please review + &man.hosts.5; for more information. The + flag allows the subdirectories to be + mount points. In other words, it will not mount the + subdirectories but permit the client to mount only the + directories that are required or needed. + + /home -alldirs 10.0.0.2 10.0.0.3 10.0.0.4 + + The following line exports /a so that + two clients from different domains may access the filesystem. + The flag allows the + root user on the remote system to write + data on the exported filesystem as root. + If the -maproot=root flag is not specified, + then even if a user has root access on + the remote system, he will not be able to modify files on + the exported filesystem. + + /a -maproot=root host.example.com box.example.org + + In order for a client to access an exported filesystem, + the client must have permission to do so. Make sure the + client is listed in your /etc/exports + file. + + In /etc/exports, each line represents + the export information for one filesystem to one host. A + remote host can only be specified once per filesystem, and may + only have one default entry. For example, assume that + /usr is a single filesystem. The + following /etc/exports would be + invalid: + + /usr/src client +/usr/ports client + + One filesystem, /usr, has two lines + specifying exports to the same host, client. + The correct format for this situation is: + + /usr/src /usr/ports client + + The properties of one filesystem exported to a given host + must all occur on one line. Lines without a client specified + are treated as a single host. This limits how you can export + filesystems, but for most people this is not an issue. + + The following is an example of a valid export list, where + /usr and /exports + are local filesystems: + + # Export src and ports to client01 and client02, but only +# client01 has root privileges on it +/usr/src /usr/ports -maproot=root client01 +/usr/src /usr/ports client02 +# The client machines have root and can mount anywhere +# on /exports. Anyone in the world can mount /exports/obj read-only +/exports -alldirs -maproot=root client01 client02 +/exports/obj -ro + + You must restart + mountd whenever you modify + /etc/exports so the changes can take effect. + This can be accomplished by sending the HUP signal + to the mountd process: + + &prompt.root; kill -HUP `cat /var/run/mountd.pid` + + Alternatively, a reboot will make FreeBSD set everything + up properly. A reboot is not necessary though. + Executing the following commands as root + should start everything up. + + On the NFS server: + + &prompt.root; portmap +&prompt.root; nfsd -u -t -n 4 +&prompt.root; mountd -r + + On the NFS client: + + &prompt.root; nfsiod -n 4 + + Now everything should be ready to actually mount a remote file + system. In these examples the + server's name will be server and the client's + name will be client. If you only want to + temporarily mount a remote filesystem or would rather test the + configuration, just execute a command like this as root on the + client: + + NFS + mounting + + &prompt.root; mount server:/home /mnt + + This will mount the /home directory + on the server at /mnt on the client. If + everything is set up correctly you should be able to enter + /mnt on the client and see all the files + that are on the server. + + If you want to automatically mount a remote filesystem + each time the computer boots, add the filesystem to the + /etc/fstab file. Here is an example: + + server:/home /mnt nfs rw 0 0 + + The &man.fstab.5; manual page lists all the available options. + + + + Practical Uses + + NFS has many practical uses. Some of the more common + ones are listed below: + + + NFS + uses + + + + Set several machines to share a CDROM or other media + among them. This is cheaper and often a more convenient + method to install software on multiple machines. + + + + On large networks, it might be more convenient to + configure a central NFS server in which + to store all the user home directories. These home + directories can then be exported to the network so that + users would always have the same home directory, + regardless of which workstation they log in to. + + + + Several machines could have a common + /usr/ports/distfiles directory. That + way, when you need to install a port on several machines, + you can quickly access the source without downloading it + on each machine. + + + + + + + + + Wylie + Stilwell + Contributed by + + + + + Chern + Lee + Rewritten by + + + + Automatic Mounts with <application>amd</application> + + amd + automatic mounter daemon + + &man.amd.8; (the automatic mounter daemon) + automatically mounts a + remote filesystem whenever a file or directory within that + filesystem is accessed. Filesystems that are inactive for a + period of time will also be automatically unmounted by + amd. Using + amd provides a simple alternative + to permanent mounts, as permanent mounts are usually listed in + /etc/fstab. + + amd operates by attaching + itself as an NFS server to the /host and + /net directories. When a file is accessed + within one of these directories, amd + looks up the corresponding remote mount and automatically mounts + it. /net is used to mount an exported + filesystem from an IP address, while /host + is used to mount an export from a remote hostname. + + An access to a file within + /host/foobar/usr would tell + amd to attempt to mount the + /usr export on the host + foobar. + + + Mounting an Export with <application>amd</application> + + You can view the available mounts of a remote host with + the showmount command. For example, to + view the mounts of a host named foobar, you + can use: + + &prompt.user; showmount -e foobar +Exports list on foobar: +/usr 10.10.10.0 +/a 10.10.10.0 +&prompt.user; cd /host/foobar/usr + + + As seen in the example, the showmount shows + /usr as an export. When changing directories to + /host/foobar/usr, amd + attempts to resolve the hostname foobar and + automatically mount the desired export. + + amd can be started by the + startup scripts by placing the following lines in + /etc/rc.conf: + + amd_enable="YES" + + Additionally, custom flags can be passed to + amd from the + amd_flags option. By default, + amd_flags is set to: + + amd_flags="-a /.amd_mnt -l syslog /host /etc/amd.map /net /etc/amd.map" + + The /etc/amd.map file defines the + default options that exports are mounted with. The + /etc/amd.conf file defines some of the more + advanced features of amd. + + Consult the &man.amd.8; and &man.amd.conf.5; manual pages for more + information. + + + + + + + John + Lind + Contributed by + + + + Problems Integrating with Other Systems + + Certain Ethernet adapters for ISA PC systems have limitations + which can lead to serious network problems, particularly with NFS. + This difficulty is not specific to FreeBSD, but FreeBSD systems + are affected by it. + + The problem nearly always occurs when (FreeBSD) PC systems are + networked with high-performance workstations, such as those made + by Silicon Graphics, Inc., and Sun Microsystems, Inc. The NFS + mount will work fine, and some operations may succeed, but + suddenly the server will seem to become unresponsive to the + client, even though requests to and from other systems continue to + be processed. This happens to the client system, whether the + client is the FreeBSD system or the workstation. On many systems, + there is no way to shut down the client gracefully once this + problem has manifested itself. The only solution is often to + reset the client, because the NFS situation cannot be + resolved. + + Though the correct solution is to get a higher + performance and capacity Ethernet adapter for the FreeBSD system, + there is a simple workaround that will allow satisfactory + operation. If the FreeBSD system is the + server, include the option + on the mount from the client. If the + FreeBSD system is the client, then mount the + NFS filesystem with the option . These + options may be specified using the fourth field of the + fstab entry on the client for automatic + mounts, or by using the parameter of the &man.mount.8; + command for manual mounts. + + It should be noted that there is a different problem, + sometimes mistaken for this one, when the NFS servers and clients + are on different networks. If that is the case, make + certain that your routers are routing the + necessary UDP information, or you will not get anywhere, no matter + what else you are doing. + + In the following examples, fastws is the host + (interface) name of a high-performance workstation, and + freebox is the host (interface) name of a FreeBSD + system with a lower-performance Ethernet adapter. Also, + /sharedfs will be the exported NFS + filesystem (see &man.exports.5;), and + /project will be the mount point on the + client for the exported filesystem. In all cases, note that + additional options, such as or + and may be desirable in + your application. + + Examples for the FreeBSD system (freebox) as + the client in /etc/fstab on freebox: + + fastws:/sharedfs /project nfs rw,-r=1024 0 0 + + As a manual mount command on freebox: + + &prompt.root; mount -t nfs -o -r=1024 fastws:/sharedfs /project + + Examples for the FreeBSD system as the server in + /etc/fstab on fastws: + + freebox:/sharedfs /project nfs rw,-w=1024 0 0 + + As a manual mount command on fastws: + + &prompt.root; mount -t nfs -o -w=1024 freebox:/sharedfs /project + + Nearly any 16-bit Ethernet adapter will allow operation + without the above restrictions on the read or write size. + + For anyone who cares, here is what happens when the failure + occurs, which also explains why it is unrecoverable. NFS + typically works with a block size of 8 K (though it + may do fragments of smaller sizes). Since the maximum Ethernet + packet is around 1500 bytes, the NFS block gets + split into multiple Ethernet packets, even though it is still a + single unit to the upper-level code, and must be received, + assembled, and acknowledged as a unit. The + high-performance workstations can pump out the packets which + comprise the NFS unit one right after the other, just as close + together as the standard allows. On the smaller, lower capacity + cards, the later packets overrun the earlier packets of the same + unit before they can be transferred to the host and the unit as a + whole cannot be reconstructed or acknowledged. As a result, the + workstation will time out and try again, but it will try again + with the entire 8 K unit, and the process will be repeated, ad + infinitum. + + By keeping the unit size below the Ethernet packet size + limitation, we ensure that any complete Ethernet packet received + can be acknowledged individually, avoiding the deadlock + situation. + + Overruns may still occur when a high-performance workstations + is slamming data out to a PC system, but with the better cards, + such overruns are not guaranteed on NFS units. When + an overrun occurs, the units affected will be retransmitted, and + there will be a fair chance that they will be received, assembled, + and acknowledged. + + + + + + + + Bill + Swingle + Written by + + + + + Eric + Ogren + Enhanced by + + + Udo + Erdelhoff + + + + NIS/YP + + + What Is It? + NIS + Solaris + HP-UX + AIX + Linux + NetBSD + OpenBSD + NIS, which stands for Network Information Services, was + developed by Sun Microsystems to centralize administration of &unix; + (originally &sunos;) systems. It has now essentially become an + industry standard; all major &unix; like systems (&solaris;, HP-UX, &aix;, Linux, + NetBSD, OpenBSD, FreeBSD, etc) support NIS. + + yellow pagesNIS + NIS was formerly known as Yellow Pages, but because of + trademark issues, Sun changed the name. The old term (and yp) is + still often seen and used. + + + NIS + domains + + It is a RPC-based client/server system that allows a group + of machines within an NIS domain to share a common set of + configuration files. This permits a system administrator to set + up NIS client systems with only minimal configuration data and + add, remove or modify configuration data from a single + location. + + Windows NT + It is similar to the &windowsnt; domain system; although the + internal implementation of the two are not at all similar, + the basic functionality can be compared. + + + + Terms/Processes You Should Know + + There are several terms and several important user processes + that you will come across when + attempting to implement NIS on FreeBSD, whether you are trying to + create an NIS server or act as an NIS client: + + + portmap + + + + + + + + + + Term + Description + + + + + NIS domainname + An NIS master server and all of its clients + (including its slave servers) have a NIS + domainname. Similar to an &windowsnt; domain name, the NIS + domainname does not have anything to do with DNS. + + + portmap + Must be running in order to enable RPC (Remote + Procedure Call, a network protocol used by NIS). If + portmap is not running, it will be + impossible to run an NIS server, or to act as an NIS + client. + + + ypbind + + Binds an NIS client to its NIS + server. It will take the NIS domainname from the + system, and using RPC, connect to the + server. ypbind is the core of + client-server communication in an NIS environment; if + ypbind dies on a client machine, it + will not be able to access the NIS server. + + + ypserv + Should only be running on NIS servers; this is the NIS + server process itself. If &man.ypserv.8; dies, then the + server will no longer be able to respond to NIS requests + (hopefully, there is a slave server to take over for + it). There are some implementations of NIS (but not the + FreeBSD one), that do not try to reconnect to another + server if the server it used before dies. Often, the + only thing that helps in this case is to restart the + server process (or even the whole server) or the + ypbind process on the client. + + + + rpc.yppasswdd + Another process that should only be running on + NIS master servers; this is a daemon that will allow NIS + clients to change their NIS passwords. If this daemon + is not running, users will have to login to the NIS + master server and change their passwords there. + + + + + + + + + + How Does It Work? + + There are three types of hosts in an NIS environment: master + servers, slave servers, and clients. Servers act as a central + repository for host configuration information. Master servers + hold the authoritative copy of this information, while slave + servers mirror this information for redundancy. Clients rely on + the servers to provide this information to them. + + Information in many files can be shared in this manner. The + master.passwd, group, + and hosts files are commonly shared via NIS. + Whenever a process on a client needs information that would + normally be found in these files locally, it makes a query to the + NIS server that it is bound to instead. + + + Machine Types + + + + NIS + master server + + + A NIS master server. + This server, analogous to a &windowsnt; + primary domain controller, maintains the files used by all + of the NIS clients. The passwd, + group, and other various files used by the + NIS clients live on the master server. + + It is possible for one machine to be an NIS + master server for more than one NIS domain. However, this will + not be covered in this introduction, which assumes a relatively + small-scale NIS environment. + + + NIS + slave server + + + NIS slave servers. + Similar to the &windowsnt; backup domain + controllers, NIS slave servers maintain copies of the NIS + master's data files. NIS slave servers provide the redundancy, + which is needed in important environments. They also help + to balance the load of the master server: NIS Clients always + attach to the NIS server whose response they get first, and + this includes slave-server-replies. + + + NIS + client + + + NIS clients. NIS clients, like most + &windowsnt; workstations, authenticate against the NIS server (or the &windowsnt; + domain controller in the &windowsnt; workstations case) to log on. + + + + + + + Using NIS/YP + + This section will deal with setting up a sample NIS + environment. + + This section assumes that you are running FreeBSD 3.3 + or later. The instructions given here will + probably work for any version of FreeBSD greater + than 3.0, but there are no guarantees that this is + true. + + + + Planning + + Let us assume that you are the administrator of a small + university lab. This lab, which consists of 15 FreeBSD machines, + currently has no centralized point of administration; each machine + has its own /etc/passwd and + /etc/master.passwd. These files are kept in + sync with each other only through manual intervention; + currently, when you add a user to the lab, you must run + adduser on all 15 machines. + Clearly, this has to change, so you have decided to convert the + lab to use NIS, using two of the machines as servers. + + Therefore, the configuration of the lab now looks something + like: + + + + + + Machine name + IP address + Machine role + + + + + ellington + 10.0.0.2 + NIS master + + + coltrane + 10.0.0.3 + NIS slave + + + basie + 10.0.0.4 + Faculty workstation + + + bird + 10.0.0.5 + Client machine + + + cli[1-11] + 10.0.0.[6-17] + Other client machines + + + + + + If you are setting up a NIS scheme for the first time, it + is a good idea to think through how you want to go about it. No + matter what the size of your network, there are a few decisions + that need to be made. + + + Choosing a NIS Domain Name + + + NIS + domainname + + This might not be the domainname that you + are used to. It is more accurately called the + NIS domainname. When a client broadcasts its + requests for info, it includes the name of the NIS domain + that it is part of. This is how multiple servers on one + network can tell which server should answer which request. + Think of the NIS domainname as the name for a group of hosts + that are related in some way. + + Some organizations choose to use their Internet + domainname for their NIS domainname. This is not + recommended as it can cause confusion when trying to debug + network problems. The NIS domainname should be unique + within your network and it is helpful if it describes the + group of machines it represents. For example, the Art + department at Acme Inc. might be in the + acme-art NIS domain. For this example, + assume you have chosen the name + test-domain. + + SunOS + However, some operating systems (notably &sunos;) use their + NIS domain name as their Internet domain name. + If one or more machines on your network have this restriction, + you must use the Internet domain name as + your NIS domain name. + + + + Physical Server Requirements + + There are several things to keep in mind when choosing a + machine to use as a NIS server. One of the unfortunate things + about NIS is the level of dependency the clients have on the + server. If a client cannot contact the server for its NIS + domain, very often the machine becomes unusable. The lack of + user and group information causes most systems to temporarily + freeze up. With this in mind you should make sure to choose a + machine that will not be prone to being rebooted regularly, or + one that might be used for development. The NIS server should + ideally be a stand alone machine whose sole purpose in life is + to be an NIS server. If you have a network that is not very + heavily used, it is acceptable to put the NIS server on a + machine running other services, just keep in mind that if the + NIS server becomes unavailable, it will affect + all of your NIS clients adversely. + + + + + NIS Servers + + The canonical copies of all NIS information are stored on + a single machine called the NIS master server. The databases + used to store the information are called NIS maps. In FreeBSD, + these maps are stored in + /var/yp/[domainname] where + [domainname] is the name of the NIS domain + being served. A single NIS server can support several domains + at once, therefore it is possible to have several such + directories, one for each supported domain. Each domain will + have its own independent set of maps. + + NIS master and slave servers handle all NIS requests with + the ypserv daemon. ypserv + is responsible for receiving incoming requests from NIS clients, + translating the requested domain and map name to a path to the + corresponding database file and transmitting data from the + database back to the client. + + + Setting Up a NIS Master Server + + NIS + server configuration + + Setting up a master NIS server can be relatively straight + forward, depending on your needs. FreeBSD comes with support + for NIS out-of-the-box. All you need is to add the following + lines to /etc/rc.conf, and FreeBSD will + do the rest for you. + + + + nisdomainname="test-domain" + This line will set the NIS domainname to + test-domain + upon network setup (e.g. after reboot). + + + nis_server_enable="YES" + This will tell FreeBSD to start up the NIS server processes + when the networking is next brought up. + + + nis_yppasswdd_enable="YES" + This will enable the rpc.yppasswdd + daemon which, as mentioned above, will allow users to + change their NIS password from a client machine. + + + + + Depending on your NIS setup, you may need to add + further entries. See the section about NIS servers + that are also NIS clients, below, for + details. + + + Now, all you have to do is to run the command + /etc/netstart as superuser. It will + set up everything for you, using the values you defined in + /etc/rc.conf. + + + + Initializing the NIS Maps + + NIS + maps + + The NIS maps are database files, + that are kept in the /var/yp directory. + They are generated from configuration files in the + /etc directory of the NIS master, with one + exception: the /etc/master.passwd file. + This is for a good reason, you do not want to propagate + passwords to your root and other + administrative accounts to all the servers in the NIS domain. + Therefore, before we initialize the NIS maps, you should: + + &prompt.root; cp /etc/master.passwd /var/yp/master.passwd +&prompt.root; cd /var/yp +&prompt.root; vi master.passwd + + You should remove all entries regarding system accounts + (bin, tty, + kmem, games, etc), as + well as any accounts that you do not want to be propagated to the + NIS clients (for example root and any other + UID 0 (superuser) accounts). + + Make sure the + /var/yp/master.passwd is neither group + nor world readable (mode 600)! Use the + chmod command, if appropriate. + + Tru64 UNIX + When you have finished, it is time to initialize the NIS + maps! FreeBSD includes a script named + ypinit to do this for you + (see its manual page for more information). Note that this + script is available on most &unix; Operating Systems, but not on all. + On Digital UNIX/Compaq Tru64 UNIX it is called + ypsetup. + Because we are generating maps for an NIS master, we are + going to pass the option to + ypinit. + To generate the NIS maps, assuming you already performed + the steps above, run: + + ellington&prompt.root; ypinit -m test-domain +Server Type: MASTER Domain: test-domain +Creating an YP server will require that you answer a few questions. +Questions will all be asked at the beginning of the procedure. +Do you want this procedure to quit on non-fatal errors? [y/n: n] n +Ok, please remember to go back and redo manually whatever fails. +If you don't, something might not work. +At this point, we have to construct a list of this domains YP servers. +rod.darktech.org is already known as master server. +Please continue to add any slave servers, one per line. When you are +done with the list, type a <control D>. +master server : ellington +next host to add: coltrane +next host to add: ^D +The current list of NIS servers looks like this: +ellington +coltrane +Is this correct? [y/n: y] y + +[..output from map generation..] + +NIS Map update completed. +ellington has been setup as an YP master server without any errors. + + ypinit should have created + /var/yp/Makefile from + /var/yp/Makefile.dist. + When created, this file assumes that you are operating + in a single server NIS environment with only FreeBSD + machines. Since test-domain has + a slave server as well, you must edit + /var/yp/Makefile: + + ellington&prompt.root; vi /var/yp/Makefile + + You should comment out the line that says + + NOPUSH = "True" + + (if it is not commented out already). + + + + Setting up a NIS Slave Server + + NIS + slave server + + Setting up an NIS slave server is even more simple than + setting up the master. Log on to the slave server and edit the + file /etc/rc.conf as you did before. + The only difference is that we now must use the + option when running ypinit. + The option requires the name of the NIS + master be passed to it as well, so our command line looks + like: + + coltrane&prompt.root; ypinit -s ellington test-domain + +Server Type: SLAVE Domain: test-domain Master: ellington + +Creating an YP server will require that you answer a few questions. +Questions will all be asked at the beginning of the procedure. + +Do you want this procedure to quit on non-fatal errors? [y/n: n] n + +Ok, please remember to go back and redo manually whatever fails. +If you don't, something might not work. +There will be no further questions. The remainder of the procedure +should take a few minutes, to copy the databases from ellington. +Transferring netgroup... +ypxfr: Exiting: Map successfully transferred +Transferring netgroup.byuser... +ypxfr: Exiting: Map successfully transferred +Transferring netgroup.byhost... +ypxfr: Exiting: Map successfully transferred +Transferring master.passwd.byuid... +ypxfr: Exiting: Map successfully transferred +Transferring passwd.byuid... +ypxfr: Exiting: Map successfully transferred +Transferring passwd.byname... +ypxfr: Exiting: Map successfully transferred +Transferring group.bygid... +ypxfr: Exiting: Map successfully transferred +Transferring group.byname... +ypxfr: Exiting: Map successfully transferred +Transferring services.byname... +ypxfr: Exiting: Map successfully transferred +Transferring rpc.bynumber... +ypxfr: Exiting: Map successfully transferred +Transferring rpc.byname... +ypxfr: Exiting: Map successfully transferred +Transferring protocols.byname... +ypxfr: Exiting: Map successfully transferred +Transferring master.passwd.byname... +ypxfr: Exiting: Map successfully transferred +Transferring networks.byname... +ypxfr: Exiting: Map successfully transferred +Transferring networks.byaddr... +ypxfr: Exiting: Map successfully transferred +Transferring netid.byname... +ypxfr: Exiting: Map successfully transferred +Transferring hosts.byaddr... +ypxfr: Exiting: Map successfully transferred +Transferring protocols.bynumber... +ypxfr: Exiting: Map successfully transferred +Transferring ypservers... +ypxfr: Exiting: Map successfully transferred +Transferring hosts.byname... +ypxfr: Exiting: Map successfully transferred + +coltrane has been setup as an YP slave server without any errors. +Don't forget to update map ypservers on ellington. + + You should now have a directory called + /var/yp/test-domain. Copies of the NIS + master server's maps should be in this directory. You will + need to make sure that these stay updated. The following + /etc/crontab entries on your slave + servers should do the job: + + 20 * * * * root /usr/libexec/ypxfr passwd.byname +21 * * * * root /usr/libexec/ypxfr passwd.byuid + + These two lines force the slave to sync its maps with + the maps on the master server. Although these entries are + not mandatory, since the master server attempts to ensure + any changes to its NIS maps are communicated to its slaves + and because password information is vital to systems + depending on the server, it is a good idea to force the + updates. This is more important on busy networks where map + updates might not always complete. + + Now, run the command /etc/netstart on the + slave server as well, which again starts the NIS server. + + + + + NIS Clients + + An NIS client establishes what is called a binding to a + particular NIS server using the + ypbind daemon. + ypbind checks the system's default + domain (as set by the domainname command), + and begins broadcasting RPC requests on the local network. + These requests specify the name of the domain for which + ypbind is attempting to establish a binding. + If a server that has been configured to serve the requested + domain receives one of the broadcasts, it will respond to + ypbind, which will record the server's + address. If there are several servers available (a master and + several slaves, for example), ypbind will + use the address of the first one to respond. From that point + on, the client system will direct all of its NIS requests to + that server. ypbind will + occasionally ping the server to make sure it is + still up and running. If it fails to receive a reply to one of + its pings within a reasonable amount of time, + ypbind will mark the domain as unbound and + begin broadcasting again in the hopes of locating another + server. + + + Setting Up a NIS Client + + NIS + client configuration + + Setting up a FreeBSD machine to be a NIS client is fairly + straightforward. + + + + Edit the file /etc/rc.conf and + add the following lines in order to set the NIS domainname + and start ypbind upon network + startup: + + nisdomainname="test-domain" +nis_client_enable="YES" + + + + To import all possible password entries from the NIS + server, remove all user accounts from your + /etc/master.passwd file and use + vipw to add the following line to + the end of the file: + + +::::::::: + + + This line will afford anyone with a valid account in + the NIS server's password maps an account. There are + many ways to configure your NIS client by changing this + line. See the netgroups + section below for more information. + For more detailed reading see O'Reilly's book on + Managing NFS and NIS. + + + + You should keep at least one local account (i.e. + not imported via NIS) in your + /etc/master.passwd and this + account should also be a member of the group + wheel. If there is something + wrong with NIS, this account can be used to log in + remotely, become root, and fix things. + + + + + To import all possible group entries from the NIS + server, add this line to your + /etc/group file: + + +:*:: + + + + After completing these steps, you should be able to run + ypcat passwd and see the NIS server's + passwd map. + + + + + + NIS Security + + In general, any remote user can issue an RPC to + &man.ypserv.8; and retrieve the contents of your NIS maps, + provided the remote user knows your domainname. To prevent + such unauthorized transactions, &man.ypserv.8; supports a + feature called securenets which can be used to restrict access + to a given set of hosts. At startup, &man.ypserv.8; will + attempt to load the securenets information from a file called + /var/yp/securenets. + + + This path varies depending on the path specified with the + option. This file contains entries that + consist of a network specification and a network mask separated + by white space. Lines starting with # are + considered to be comments. A sample securenets file might look + like this: + + + # allow connections from local host -- mandatory +127.0.0.1 255.255.255.255 +# allow connections from any host +# on the 192.168.128.0 network +192.168.128.0 255.255.255.0 +# allow connections from any host +# between 10.0.0.0 to 10.0.15.255 +# this includes the machines in the testlab +10.0.0.0 255.255.240.0 + + If &man.ypserv.8; receives a request from an address that + matches one of these rules, it will process the request + normally. If the address fails to match a rule, the request + will be ignored and a warning message will be logged. If the + /var/yp/securenets file does not exist, + ypserv will allow connections from any + host. + + The ypserv program also has support for Wietse + Venema's + tcpwrapper package. This allows the + administrator to use the tcpwrapper configuration + files for access control instead of + /var/yp/securenets. + + + While both of these access control mechanisms provide some + security, they, like the privileged port test, are + vulnerable to IP spoofing attacks. All + NIS-related traffic should be blocked at your firewall. + + Servers using /var/yp/securenets + may fail to serve legitimate NIS clients with archaic TCP/IP + implementations. Some of these implementations set all + host bits to zero when doing broadcasts and/or fail to + observe the subnet mask when calculating the broadcast + address. While some of these problems can be fixed by + changing the client configuration, other problems may force + the retirement of the client systems in question or the + abandonment of /var/yp/securenets. + + Using /var/yp/securenets on a + server with such an archaic implementation of TCP/IP is a + really bad idea and will lead to loss of NIS functionality + for large parts of your network. + + tcpwrapper + The use of the tcpwrapper + package increases the latency of your NIS server. The + additional delay may be long enough to cause timeouts in + client programs, especially in busy networks or with slow + NIS servers. If one or more of your client systems + suffers from these symptoms, you should convert the client + systems in question into NIS slave servers and force them + to bind to themselves. + + + + + Barring Some Users from Logging On + + In our lab, there is a machine basie that is + supposed to be a faculty only workstation. We do not want to take this + machine out of the NIS domain, yet the passwd + file on the master NIS server contains accounts for both faculty and + students. What can we do? + + There is a way to bar specific users from logging on to a + machine, even if they are present in the NIS database. To do this, + all you must do is add + -username to the end of + the /etc/master.passwd file on the client + machine, where username is the username of + the user you wish to bar from logging in. This should preferably be + done using vipw, since vipw + will sanity check your changes to + /etc/master.passwd, as well as + automatically rebuild the password database when you + finish editing. For example, if we wanted to bar user + bill from logging on to basie + we would: + + basie&prompt.root; vipw +[add -bill to the end, exit] +vipw: rebuilding the database... +vipw: done + +basie&prompt.root; cat /etc/master.passwd + +root:[password]:0:0::0:0:The super-user:/root:/bin/csh +toor:[password]:0:0::0:0:The other super-user:/root:/bin/sh +daemon:*:1:1::0:0:Owner of many system processes:/root:/sbin/nologin +operator:*:2:5::0:0:System &:/:/sbin/nologin +bin:*:3:7::0:0:Binaries Commands and Source,,,:/:/sbin/nologin +tty:*:4:65533::0:0:Tty Sandbox:/:/sbin/nologin +kmem:*:5:65533::0:0:KMem Sandbox:/:/sbin/nologin +games:*:7:13::0:0:Games pseudo-user:/usr/games:/sbin/nologin +news:*:8:8::0:0:News Subsystem:/:/sbin/nologin +man:*:9:9::0:0:Mister Man Pages:/usr/share/man:/sbin/nologin +bind:*:53:53::0:0:Bind Sandbox:/:/sbin/nologin +uucp:*:66:66::0:0:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico +xten:*:67:67::0:0:X-10 daemon:/usr/local/xten:/sbin/nologin +pop:*:68:6::0:0:Post Office Owner:/nonexistent:/sbin/nologin +nobody:*:65534:65534::0:0:Unprivileged user:/nonexistent:/sbin/nologin ++::::::::: +-bill + +basie&prompt.root; + + + + + + + Udo + Erdelhoff + Contributed by + + + + + Using Netgroups + netgroups + + The method shown in the previous section works reasonably + well if you need special rules for a very small number of + users and/or machines. On larger networks, you + will forget to bar some users from logging + onto sensitive machines, or you may even have to modify each + machine separately, thus losing the main benefit of NIS: + centralized administration. + + The NIS developers' solution for this problem is called + netgroups. Their purpose and semantics + can be compared to the normal groups used by &unix; file + systems. The main differences are the lack of a numeric ID + and the ability to define a netgroup by including both user + accounts and other netgroups. + + Netgroups were developed to handle large, complex networks + with hundreds of users and machines. On one hand, this is + a Good Thing if you are forced to deal with such a situation. + On the other hand, this complexity makes it almost impossible to + explain netgroups with really simple examples. The example + used in the remainder of this section demonstrates this + problem. + + Let us assume that your successful introduction of NIS in + your laboratory caught your superiors' interest. Your next + job is to extend your NIS domain to cover some of the other + machines on campus. The two tables contain the names of the + new users and new machines as well as brief descriptions of + them. + + + + + + User Name(s) + Description + + + + + + alpha, beta + Normal employees of the IT department + + + + charlie, delta + The new apprentices of the IT department + + + + echo, foxtrott, golf, ... + Ordinary employees + + + + able, baker, ... + The current interns + + + + + + + + + + Machine Name(s) + Description + + + + + + + war, death, famine, pollution + Your most important servers. Only the IT + employees are allowed to log onto these + machines. + + + + pride, greed, envy, wrath, lust, sloth + Less important servers. All members of the IT + department are allowed to login onto these machines. + + + + one, two, three, four, ... + Ordinary workstations. Only the + real employees are allowed to use + these machines. + + + + trashcan + A very old machine without any critical data. + Even the intern is allowed to use this box. + + + + + + If you tried to implement these restrictions by separately + blocking each user, you would have to add one + -user line to each system's + passwd + for each user who is not allowed to login onto that system. + If you forget just one entry, you could be in trouble. It may + be feasible to do this correctly during the initial setup, + however you will eventually forget to add + the lines for new users during day-to-day operations. After + all, Murphy was an optimist. + + Handling this situation with netgroups offers several + advantages. Each user need not be handled separately; + you assign a user to one or more netgroups and allow or forbid + logins for all members of the netgroup. If you add a new + machine, you will only have to define login restrictions for + netgroups. If a new user is added, you will only have to add + the user to one or more netgroups. Those changes are + independent of each other: no more for each combination + of user and machine do... If your NIS setup is planned + carefully, you will only have to modify exactly one central + configuration file to grant or deny access to machines. + + The first step is the initialization of the NIS map + netgroup. FreeBSD's &man.ypinit.8; does not create this map by + default, but its NIS implementation will support it once it has + been created. To create an empty map, simply type + + ellington&prompt.root; vi /var/yp/netgroup + + and start adding content. For our example, we need at + least four netgroups: IT employees, IT apprentices, normal + employees and interns. + + IT_EMP (,alpha,test-domain) (,beta,test-domain) +IT_APP (,charlie,test-domain) (,delta,test-domain) +USERS (,echo,test-domain) (,foxtrott,test-domain) \ + (,golf,test-domain) +INTERNS (,able,test-domain) (,baker,test-domain) + + IT_EMP, IT_APP etc. + are the names of the netgroups. Each bracketed group adds + one or more user accounts to it. The three fields inside a + group are: + + + + The name of the host(s) where the following items are + valid. If you do not specify a hostname, the entry is + valid on all hosts. If you do specify a hostname, you + will enter a realm of darkness, horror and utter confusion. + + + + The name of the account that belongs to this + netgroup. + + + + The NIS domain for the account. You can import + accounts from other NIS domains into your netgroup if you + are one of the unlucky fellows with more than one NIS + domain. + + + + Each of these fields can contain wildcards. See + &man.netgroup.5; for details. + + + netgroups + Netgroup names longer than 8 characters should not be + used, especially if you have machines running other + operating systems within your NIS domain. The names are + case sensitive; using capital letters for your netgroup + names is an easy way to distinguish between user, machine + and netgroup names. + + Some NIS clients (other than FreeBSD) cannot handle + netgroups with a large number of entries. For example, some + older versions of &sunos; start to cause trouble if a netgroup + contains more than 15 entries. You can + circumvent this limit by creating several sub-netgroups with + 15 users or less and a real netgroup that consists of the + sub-netgroups: + + BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] +BIGGRP2 (,joe16,domain) (,joe17,domain) [...] +BIGGRP3 (,joe31,domain) (,joe32,domain) +BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3 + + You can repeat this process if you need more than 225 + users within a single netgroup. + + + Activating and distributing your new NIS map is + easy: + + ellington&prompt.root; cd /var/yp +ellington&prompt.root; make + + This will generate the three NIS maps + netgroup, + netgroup.byhost and + netgroup.byuser. Use &man.ypcat.1; to + check if your new NIS maps are available: + + ellington&prompt.user; ypcat -k netgroup +ellington&prompt.user; ypcat -k netgroup.byhost +ellington&prompt.user; ypcat -k netgroup.byuser + + The output of the first command should resemble the + contents of /var/yp/netgroup. The second + command will not produce output if you have not specified + host-specific netgroups. The third command can be used to + get the list of netgroups for a user. + + The client setup is quite simple. To configure the server + war, you only have to start + &man.vipw.8; and replace the line + + +::::::::: + + with + + +@IT_EMP::::::::: + + Now, only the data for the users defined in the netgroup + IT_EMP is imported into + war's password database and only + these users are allowed to login. + + Unfortunately, this limitation also applies to the ~ + function of the shell and all routines converting between user + names and numerical user IDs. In other words, + cd ~user will not work, + ls -l will show the numerical ID instead of + the username and find . -user joe -print will + fail with No such user. To fix this, you will + have to import all user entries without allowing them + to login onto your servers. + + This can be achieved by adding another line to + /etc/master.passwd. This line should + contain: + + +:::::::::/sbin/nologin, meaning + Import all entries but replace the shell with + /sbin/nologin in the imported + entries. You can replace any field + in the passwd entry by placing a default value in your + /etc/master.passwd. + + + + Make sure that the line + +:::::::::/sbin/nologin is placed after + +@IT_EMP:::::::::. Otherwise, all user + accounts imported from NIS will have /sbin/nologin as their + login shell. + + + After this change, you will only have to change one NIS + map if a new employee joins the IT department. You could use + a similar approach for the less important servers by replacing + the old +::::::::: in their local version + of /etc/master.passwd with something like + this: + + +@IT_EMP::::::::: ++@IT_APP::::::::: ++:::::::::/sbin/nologin + + The corresponding lines for the normal workstations + could be: + + +@IT_EMP::::::::: ++@USERS::::::::: ++:::::::::/sbin/nologin + + And everything would be fine until there is a policy + change a few weeks later: The IT department starts hiring + interns. The IT interns are allowed to use the normal + workstations and the less important servers; and the IT + apprentices are allowed to login onto the main servers. You + add a new netgroup IT_INTERN, add the new IT interns to this + netgroup and start to change the configuration on each and every + machine... As the old saying goes: Errors in + centralized planning lead to global mess. + + NIS' ability to create netgroups from other netgroups can + be used to prevent situations like these. One possibility + is the creation of role-based netgroups. For example, you + could create a netgroup called + BIGSRV to define the login + restrictions for the important servers, another netgroup + called SMALLSRV for the less + important servers and a third netgroup called + USERBOX for the normal + workstations. Each of these netgroups contains the netgroups + that are allowed to login onto these machines. The new + entries for your NIS map netgroup should look like this: + + BIGSRV IT_EMP IT_APP +SMALLSRV IT_EMP IT_APP ITINTERN +USERBOX IT_EMP ITINTERN USERS + + This method of defining login restrictions works + reasonably well if you can define groups of machines with + identical restrictions. Unfortunately, this is the exception + and not the rule. Most of the time, you will need the ability + to define login restrictions on a per-machine basis. + + Machine-specific netgroup definitions are the other + possibility to deal with the policy change outlined above. In + this scenario, the /etc/master.passwd of + each box contains two lines starting with +. + The first of them adds a netgroup with the accounts allowed to + login onto this machine, the second one adds all other + accounts with /sbin/nologin as shell. It + is a good idea to use the ALL-CAPS version of the machine name + as the name of the netgroup. In other words, the lines should + look like this: + + +@BOXNAME::::::::: ++:::::::::/sbin/nologin + + Once you have completed this task for all your machines, + you will not have to modify the local versions of + /etc/master.passwd ever again. All + further changes can be handled by modifying the NIS map. Here + is an example of a possible netgroup map for this + scenario with some additional goodies: + + # Define groups of users first +IT_EMP (,alpha,test-domain) (,beta,test-domain) +IT_APP (,charlie,test-domain) (,delta,test-domain) +DEPT1 (,echo,test-domain) (,foxtrott,test-domain) +DEPT2 (,golf,test-domain) (,hotel,test-domain) +DEPT3 (,india,test-domain) (,juliet,test-domain) +ITINTERN (,kilo,test-domain) (,lima,test-domain) +D_INTERNS (,able,test-domain) (,baker,test-domain) +# +# Now, define some groups based on roles +USERS DEPT1 DEPT2 DEPT3 +BIGSRV IT_EMP IT_APP +SMALLSRV IT_EMP IT_APP ITINTERN +USERBOX IT_EMP ITINTERN USERS +# +# And a groups for a special tasks +# Allow echo and golf to access our anti-virus-machine +SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain) +# +# machine-based netgroups +# Our main servers +WAR BIGSRV +FAMINE BIGSRV +# User india needs access to this server +POLLUTION BIGSRV (,india,test-domain) +# +# This one is really important and needs more access restrictions +DEATH IT_EMP +# +# The anti-virus-machine mentioned above +ONE SECURITY +# +# Restrict a machine to a single user +TWO (,hotel,test-domain) +# [...more groups to follow] + + If you are using some kind of database to manage your user + accounts, you should be able to create the first part of the + map with your database's report tools. This way, new users + will automatically have access to the boxes. + + One last word of caution: It may not always be advisable + to use machine-based netgroups. If you are deploying a couple of + dozen or even hundreds of identical machines for student labs, + you should use role-based netgroups instead of machine-based + netgroups to keep the size of the NIS map within reasonable + limits. + + + + Important Things to Remember + + There are still a couple of things that you will need to do + differently now that you are in an NIS environment. + + + + Every time you wish to add a user to the lab, you + must add it to the master NIS server only, + and you must remember to rebuild the NIS + maps. If you forget to do this, the new user will + not be able to login anywhere except on the NIS master. + For example, if we needed to add a new user + jsmith to the lab, we would: + + &prompt.root; pw useradd jsmith +&prompt.root; cd /var/yp +&prompt.root; make test-domain + + You could also run adduser jsmith instead + of pw useradd jsmith. + + + Keep the administration accounts out of the NIS + maps. You do not want to be propagating administrative + accounts and passwords to machines that will have users that + should not have access to those accounts. + + + Keep the NIS master and slave + secure, and minimize their downtime. + If somebody either hacks or simply turns off + these machines, they have effectively rendered many people without + the ability to login to the lab. + + This is the chief weakness of any centralized administration + system. If you do + not protect your NIS servers, you will have a lot of angry + users! + + + + + + NIS v1 Compatibility + + FreeBSD's ypserv has some support + for serving NIS v1 clients. FreeBSD's NIS implementation only + uses the NIS v2 protocol, however other implementations include + support for the v1 protocol for backwards compatibility with older + systems. The ypbind daemons supplied + with these systems will try to establish a binding to an NIS v1 + server even though they may never actually need it (and they may + persist in broadcasting in search of one even after they receive a + response from a v2 server). Note that while support for normal + client calls is provided, this version of ypserv does not handle + v1 map transfer requests; consequently, it cannot be used as a + master or slave in conjunction with older NIS servers that only + support the v1 protocol. Fortunately, there probably are not any + such servers still in use today. + + + + NIS Servers That Are Also NIS Clients + + Care must be taken when running ypserv in a multi-server + domain where the server machines are also NIS clients. It is + generally a good idea to force the servers to bind to themselves + rather than allowing them to broadcast bind requests and possibly + become bound to each other. Strange failure modes can result if + one server goes down and others are dependent upon it. + Eventually all the clients will time out and attempt to bind to + other servers, but the delay involved can be considerable and the + failure mode is still present since the servers might bind to each + other all over again. + + You can force a host to bind to a particular server by running + ypbind with the + flag. If you do not want to do this manually each time you + reboot your NIS server, you can add the following lines to + your /etc/rc.conf: + + nis_client_enable="YES" # run client stuff as well +nis_client_flags="-S NIS domain,server" + + See &man.ypbind.8; for further information. + + + + Password Formats + + NIS + password formats + + One of the most common issues that people run into when trying + to implement NIS is password format compatibility. If your NIS + server is using DES encrypted passwords, it will only support + clients that are also using DES. For example, if you have + &solaris; NIS clients in your network, then you will almost certainly + need to use DES encrypted passwords. + + To check which format your servers + and clients are using, look at /etc/login.conf. + If the host is configured to use DES encrypted passwords, then the + default class will contain an entry like this: + + default:\ + :passwd_format=des:\ + :copyright=/etc/COPYRIGHT:\ + [Further entries elided] + + Other possible values for the passwd_format + capability include blf and md5 + (for Blowfish and MD5 encrypted passwords, respectively). + + If you have made changes to /etc/login.conf, + you will also need to rebuild the login capability database, which is + achieved by running the following command as root: + + &prompt.root; cap_mkdb /etc/login.conf + + The format of passwords already in + /etc/master.passwd will not be updated until + a user changes his password for the first time after + the login capability database is rebuilt. + + Next, in order to ensure that passwords are encrypted with the + format that you have chosen, you should also check that the + crypt_default in /etc/auth.conf + gives precedence to your chosen password format. To do this, place + the format that you have chosen first in the list. For example, when + using DES encrypted passwords, the entry would be: + + crypt_default = des blf md5 + + Having followed the above steps on each of the &os; based NIS + servers and clients, you can be sure that they all agree on which + password format is used within your network. + If you have trouble authenticating on an NIS client, this + is a pretty good place to start looking for possible problems. + Remember: if you want to deploy an NIS server for a heterogenous + network, you will probably have to use DES on all systems + because it is the lowest common standard. + + + + + + + + Greg + Sutter + Written by + + + + DHCP + + + What Is DHCP? + + Dynamic Host Configuration Protocol + DHCP + + + Internet Software Consortium (ISC) + + + DHCP, the Dynamic Host Configuration Protocol, describes + the means by which a system can connect to a network and obtain the + necessary information for communication upon that network. FreeBSD + uses the ISC (Internet Software Consortium) DHCP implementation, so + all implementation-specific information here is for use with the ISC + distribution. + + + + What This Section Covers + + This section describes both the client-side and server-side + components of the ISC DHCP system. The client-side program, + dhclient, comes integrated within FreeBSD, and + the server-side portion is available from the + net/isc-dhcp3-server port. The + &man.dhclient.8;, &man.dhcp-options.5;, and &man.dhclient.conf.5; + manual pages, in addition to the references below, are useful + resources. + + + + How It Works + UDP + When dhclient, the DHCP client, is + executed on the client machine, it begins broadcasting + requests for configuration information. By default, these + requests are on UDP port 68. The server replies on UDP 67, + giving the client an IP address and other relevant network + information such as netmask, router, and DNS servers. All of + this information comes in the form of a DHCP + lease and is only valid for a certain time + (configured by the DHCP server maintainer). In this manner, + stale IP addresses for clients no longer connected to the + network can be automatically reclaimed. + + DHCP clients can obtain a great deal of information from + the server. An exhaustive list may be found in + &man.dhcp-options.5;. + + + + FreeBSD Integration + + FreeBSD fully integrates the ISC DHCP client, + dhclient. DHCP client support is provided + within both the installer and the base system, obviating the need + for detailed knowledge of network configurations on any network + that runs a DHCP server. dhclient has been + included in all FreeBSD distributions since 3.2. + + sysinstall + + + DHCP is supported by + sysinstall. When configuring a + network interface within sysinstall, the first question + asked is: Do you want to try DHCP configuration of + this interface?. Answering affirmatively will execute + dhclient, and if successful, will fill in + the network configuration information automatically. + + There are two things you must do to have your system use + DHCP upon startup: + + DHCP + requirements + + + + Make sure that the bpf + device is compiled into your kernel. To do this, add + device bpf (pseudo-device bpf under &os; 4.X) to your kernel + configuration file, and rebuild the kernel. For more + information about building kernels, see . + The bpf device is already + part of the GENERIC kernel that is + supplied with FreeBSD, so if you do not have a custom + kernel, you should not need to create one in order to get + DHCP working. + + For those who are particularly security conscious, + you should be warned that bpf + is also the device that allows packet sniffers to work + correctly (although they still have to be run as + root). bpf + is required to use DHCP, but if + you are very sensitive about security, you probably + should not add bpf to your + kernel in the expectation that at some point in the + future you will be using DHCP. + + + + Edit your /etc/rc.conf to + include the following: + + ifconfig_fxp0="DHCP" + + + Be sure to replace fxp0 with the + designation for the interface that you wish to dynamically + configure, as described in + . + + + If you are using a different location for + dhclient, or if you wish to pass additional + flags to dhclient, also include the + following (editing as necessary): + + dhcp_program="/sbin/dhclient" +dhcp_flags="" + + + + + DHCP + server + + The DHCP server, dhcpd, is included + as part of the net/isc-dhcp3-server port in the ports + collection. This port contains the ISC DHCP server and + documentation. + + + + Files + + DHCP + configuration files + + + /etc/dhclient.conf + dhclient requires a configuration file, + /etc/dhclient.conf. Typically the file + contains only comments, the defaults being reasonably sane. This + configuration file is described by the &man.dhclient.conf.5; + manual page. + + + /sbin/dhclient + dhclient is statically linked and + resides in /sbin. The &man.dhclient.8; + manual page gives more information about + dhclient. + + + /sbin/dhclient-script + dhclient-script is the FreeBSD-specific + DHCP client configuration script. It is described in + &man.dhclient-script.8;, but should not need any user + modification to function properly. + + + /var/db/dhclient.leases + The DHCP client keeps a database of valid leases in this + file, which is written as a log. &man.dhclient.leases.5; + gives a slightly longer description. + + + + + + Further Reading + + The DHCP protocol is fully described in + RFC 2131. + An informational resource has also been set up at + dhcp.org. + + + + Installing and Configuring a DHCP Server + + + What This Section Covers + + This section provides information on how to configure + a FreeBSD system to act as a DHCP server using the ISC + (Internet Software Consortium) implementation of the DHCP + suite. + + The server portion of the suite is not provided as part of + FreeBSD, and so you will need to install the + net/isc-dhcp3-server + port to provide this service. See for + more information on using the ports collection. + + + + DHCP Server Installation + + DHCP + installation + + In order to configure your FreeBSD system as a DHCP server, + you will need to ensure that the &man.bpf.4; + device is compiled into your kernel. To do this, add + device bpf (pseudo-device bpf under &os; 4.X) to your kernel + configuration file, and rebuild the kernel. For more + information about building kernels, see . + + The bpf device is already + part of the GENERIC kernel that is + supplied with FreeBSD, so you do not need to create a custom + kernel in order to get DHCP working. + + + Those who are particularly security conscious + should note that bpf + is also the device that allows packet sniffers to work + correctly (although such programs still need privileged + access). bpf + is required to use DHCP, but if + you are very sensitive about security, you probably + should not include bpf in your + kernel purely because you expect to use DHCP at some + point in the future. + + + The next thing that you will need to do is edit the sample + dhcpd.conf which was installed by the + net/isc-dhcp3-server port. + By default, this will be + /usr/local/etc/dhcpd.conf.sample, and you + should copy this to + /usr/local/etc/dhcpd.conf before proceeding + to make changes. + + + + Configuring the DHCP Server + + DHCP + dhcpd.conf + + dhcpd.conf is + comprised of declarations regarding subnets and hosts, and is + perhaps most easily explained using an example : + + option domain-name "example.com"; +option domain-name-servers 192.168.4.100; +option subnet-mask 255.255.255.0; + +default-lease-time 3600; +max-lease-time 86400; +ddns-update-style none; + +subnet 192.168.4.0 netmask 255.255.255.0 { + range 192.168.4.129 192.168.4.254; + option routers 192.168.4.1; +} + +host mailhost { + hardware ethernet 02:03:04:05:06:07; + fixed-address mailhost.example.com; +} + + + + This option specifies the domain that will be provided + to clients as the default search domain. See + &man.resolv.conf.5; for more information on what this + means. + + + + This option specifies a comma separated list of DNS + servers that the client should use. + + + + The netmask that will be provided to clients. + + + + A client may request a specific length of time that a + lease will be valid. Otherwise the server will assign + a lease with this expiry value (in seconds). + + + + This is the maximum length of time that the server will + lease for. Should a client request a longer lease, a lease + will be issued, although it will only be valid for + max-lease-time seconds. + + + + This option specifies whether the DHCP server should + attempt to update DNS when a lease is accepted or released. + In the ISC implementation, this option is + required. + + + + This denotes which IP addresses should be used in + the pool reserved for allocating to clients. IP + addresses between, and including, the ones stated are + handed out to clients. + + + + Declares the default gateway that will be provided to + clients. + + + + The hardware MAC address of a host (so that the DHCP server + can recognize a host when it makes a request). + + + + Specifies that the host should always be given the same + IP address. Note that using a hostname is correct here, since the DHCP + server will resolve the hostname itself before returning the + lease information. + + + + Once you have finished writing your + dhcpd.conf, you can proceed to start the + server by issuing the following command: + + &prompt.root; /usr/local/etc/rc.d/isc-dhcpd.sh start + + Should you need to make changes to the configuration of your + server in the future, it is important to note that sending a + SIGHUP signal to + dhcpd does not + result in the configuration being reloaded, as it does with most + daemons. You will need to send a SIGTERM + signal to stop the process, and then restart it using the command + above. + + + + Files + + DHCP + configuration files + + + /usr/local/sbin/dhcpd + dhcpd is statically linked and + resides in /usr/local/sbin. The + &man.dhcpd.8; manual page installed with the + port gives more information about + dhcpd. + + + /usr/local/etc/dhcpd.conf + dhcpd requires a configuration + file, /usr/local/etc/dhcpd.conf before it + will start providing service to clients. This file needs to + contain all the information that should be provided to clients + that are being serviced, along with information regarding the + operation of the server. This configuration file is described + by the &man.dhcpd.conf.5; manual page installed + by the port. + + + /var/db/dhcpd.leases + The DHCP server keeps a database of leases it has issued + in this file, which is written as a log. The manual page + &man.dhcpd.leases.5;, installed by the port + gives a slightly longer description. + + + /usr/local/sbin/dhcrelay + dhcrelay is used in advanced + environments where one DHCP server forwards a request from a + client to another DHCP server on a separate network. If you + require this functionality, then install the net/isc-dhcp3-server port. The + &man.dhcrelay.8; manual page provided with the + port contains more detail. + + + + + + + + + + + + + Chern + Lee + Contributed by + + + + DNS + + + Overview + BIND + + FreeBSD utilizes, by default, a version of BIND (Berkeley + Internet Name Domain), which is the most common implementation of the + DNS protocol. DNS is the protocol through which names are mapped to + IP addresses, and vice versa. For example, a query for + www.FreeBSD.org + will receive a reply with the IP address of The FreeBSD Project's + web server, whereas, a query for ftp.FreeBSD.org + will return the IP + address of the corresponding FTP machine. Likewise, the opposite can + happen. A query for an IP address can resolve its hostname. It is + not necessary to run a name server to perform DNS lookups on a system. + + + DNS + DNS is coordinated across the Internet through a somewhat + complex system of authoritative root name servers, and other + smaller-scale name servers who host and cache individual domain + information. + + + + This document refers to BIND 8.x, as it is the stable version + used in FreeBSD. BIND 9.x in FreeBSD can be installed through + the net/bind9 port. + + + + RFC1034 and RFC1035 dictate the DNS protocol. + + + + Currently, BIND is maintained by the + Internet Software Consortium (www.isc.org). + + + + + Terminology + + To understand this document, some terms related to DNS must be + understood. + + + + + + + + + Term + Definition + + + + + + Forward DNS + Mapping of hostnames to IP addresses + + + + Origin + Refers to the domain covered in a particular zone + file + + + + named, BIND, name server + Common names for the BIND name server package within + FreeBSD + + + resolver + + Resolver + A system process through which a + machine queries a name server for zone information + + + reverse DNS + + Reverse DNS + The opposite of forward DNS; mapping of IP addresses to + hostnames + + + root zone + + Root zone + + The beginning of the Internet zone hierarchy. + All zones fall under the root zone, similar to how + all files in a file system fall under the root directory. + + + + Zone + An individual domain, subdomain, or portion of the DNS administered by + the same authority + + + + + + + zones + examples + + + Examples of zones: + + + + . is the root zone + + + org. is a zone under the root zone + + + example.org is a zone under the + org. zone + + + foo.example.org. is a subdomain, a + zone under the example.org. zone + + + + 1.2.3.in-addr.arpa is a zone referencing + all IP addresses which fall under the 3.2.1.* IP space. + + + + + As one can see, the more specific part of a hostname appears to + its left. For example, example.org. is more + specific than org., as org. is + more specific than the root zone. The layout of each part of + a hostname is much like a filesystem: the /dev + directory falls within the root, and so on. + + + + + + Reasons to Run a Name Server + + Name servers usually come in two forms: an authoritative + name server, and a caching name server. + + An authoritative name server is needed when: + + + + one wants to serve DNS information to the + world, replying authoritatively to queries. + + + a domain, such as example.org, is + registered and IP addresses need to be assigned to hostnames + under it. + + + an IP address block requires reverse DNS entries (IP to + hostname). + + + a backup name server, called a slave, must reply to queries + when the primary is down or inaccessible. + + + + A caching name server is needed when: + + + + a local DNS server may cache and respond more quickly + than querying an outside name server. + + + a reduction in overall network traffic is desired (DNS + traffic has been measured to account for 5% or more of total + Internet traffic). + + + + When one queries for www.FreeBSD.org, the + resolver usually queries the uplink ISP's name server, and retrieves + the reply. With a local, caching DNS server, the query only has to + be made once to the outside world by the caching DNS server. Every + additional query will not have to look to the outside of the local + network, since the information is cached locally. + + + + + How It Works + In FreeBSD, the BIND daemon is called + named for obvious reasons. + + + + + + File + Description + + + + + + named + the BIND daemon + + + + ndc + name daemon control program + + + + /etc/namedb + directory where BIND zone information resides + + + + /etc/namedb/named.conf + daemon configuration file + + + + + + + Zone files are usually contained within the + /etc/namedb + directory, and contain the DNS zone information + served by the name server. + + + + + Starting BIND + + BIND + starting + + + Since BIND is installed by default, configuring it all is + relatively simple. + + + To ensure the named daemon is started at boot, put the following + line in /etc/rc.conf: + + named_enable="YES" + To start the daemon manually (after configuring it): + &prompt.root; ndc start + + + + Configuration Files + + BIND + configuration files + + + Using <command>make-localhost</command> + Be sure to: + + &prompt.root; cd /etc/namedb +&prompt.root; sh make-localhost + to properly create the local reverse DNS zone file in + /etc/namedb/localhost.rev. + + + + + <filename>/etc/namedb/named.conf</filename> + + // $FreeBSD$ +// +// Refer to the named(8) manual page for details. If you are ever going +// to setup a primary server, make sure you've understood the hairy +// details of how DNS is working. Even with simple mistakes, you can +// break connectivity for affected parties, or cause huge amount of +// useless Internet traffic. + +options { + directory "/etc/namedb"; + +// In addition to the "forwarders" clause, you can force your name +// server to never initiate queries of its own, but always ask its +// forwarders only, by enabling the following line: +// +// forward only; + +// If you've got a DNS server around at your upstream provider, enter +// its IP address here, and enable the line below. This will make you +// benefit from its cache, thus reduce overall DNS traffic in the +Internet. +/* + forwarders { + 127.0.0.1; + }; +*/ + + + Just as the comment says, to benefit from an uplink's cache, + forwarders can be enabled here. Under normal + circumstances, a name server will recursively query the Internet + looking at certain name servers until it finds the answer it is + looking for. Having this enabled will have it query the uplink's + name server (or name server provided) first, taking advantage of + its cache. If the uplink name server in question is a heavily + trafficked, fast name server, enabling this may be worthwhile. + + + 127.0.0.1 + will not work here. + Change this IP address to a name server at your uplink. + + + /* + * If there is a firewall between you and name servers you want + * to talk to, you might need to uncomment the query-source + * directive below. Previous versions of BIND always asked + * questions using port 53, but BIND 8.1 uses an unprivileged + * port by default. + */ + // query-source address * port 53; + + /* + * If running in a sandbox, you may have to specify a different + * location for the dumpfile. + */ + // dump-file "s/named_dump.db"; +}; + +// Note: the following will be supported in a future release. +/* +host { any; } { + topology { + 127.0.0.0/8; + }; +}; +*/ + +// Setting up secondaries is way easier and the rough picture for this +// is explained below. +// +// If you enable a local name server, don't forget to enter 127.0.0.1 +// into your /etc/resolv.conf so this server will be queried first. +// Also, make sure to enable it in /etc/rc.conf. + +zone "." { + type hint; + file "named.root"; +}; + +zone "0.0.127.IN-ADDR.ARPA" { + type master; + file "localhost.rev"; +}; + +zone +"0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT" { + type master; + file "localhost.rev"; +}; + +// NB: Do not use the IP addresses below, they are faked, and only +// serve demonstration/documentation purposes! +// +// Example secondary config entries. It can be convenient to become +// a secondary at least for the zone where your own domain is in. Ask +// your network administrator for the IP address of the responsible +// primary. +// +// Never forget to include the reverse lookup (IN-ADDR.ARPA) zone! +// (This is the first bytes of the respective IP address, in reverse +// order, with ".IN-ADDR.ARPA" appended.) +// +// Before starting to setup a primary zone, better make sure you fully +// understand how DNS and BIND works, however. There are sometimes +// unobvious pitfalls. Setting up a secondary is comparably simpler. +// +// NB: Don't blindly enable the examples below. :-) Use actual names +// and addresses instead. +// +// NOTE!!! FreeBSD runs BIND in a sandbox (see named_flags in rc.conf). +// The directory containing the secondary zones must be write accessible +// to BIND. The following sequence is suggested: +// +// mkdir /etc/namedb/s +// chown bind:bind /etc/namedb/s +// chmod 750 /etc/namedb/s + + For more information on running BIND in a sandbox, see + Running named in a sandbox. + + + /* +zone "example.com" { + type slave; + file "s/example.com.bak"; + masters { + 192.168.1.1; + }; +}; + +zone "0.168.192.in-addr.arpa" { + type slave; + file "s/0.168.192.in-addr.arpa.bak"; + masters { + 192.168.1.1; + }; +}; +*/ + In named.conf, these are examples of slave + entries for a forward and reverse zone. + + For each new zone served, a new zone entry must be added to + named.conf. + + For example, the simplest zone entry for + example.org can look like: + + zone "example.org" { + type master; + file "example.org"; +}; + + The zone is a master, as indicated by the + statement, holding its zone information in + /etc/namedb/example.org indicated by + the statement. + + zone "example.org" { + type slave; + file "example.org"; +}; + + In the slave case, the zone information is transferred from + the master name server for the particular zone, and saved in the + file specified. If and when the master server dies or is + unreachable, the slave name server will have the transferred + zone information and will be able to serve it. + + + + Zone Files + + An example master zone file for example.org + (existing within /etc/namedb/example.org) + is as follows: + + + $TTL 3600 + +example.org. IN SOA ns1.example.org. admin.example.org. ( + 5 ; Serial + 10800 ; Refresh + 3600 ; Retry + 604800 ; Expire + 86400 ) ; Minimum TTL + +; DNS Servers +@ IN NS ns1.example.org. +@ IN NS ns2.example.org. + +; Machine Names +localhost IN A 127.0.0.1 +ns1 IN A 3.2.1.2 +ns2 IN A 3.2.1.3 +mail IN A 3.2.1.10 +@ IN A 3.2.1.30 + +; Aliases +www IN CNAME @ + +; MX Record +@ IN MX 10 mail.example.org. + + + Note that every hostname ending in a . is an + exact hostname, whereas everything without a trailing + . is referenced to the origin. For example, + www is translated into www.origin. + In our fictitious zone file, our origin + is example.org., so + www would translate to + www.example.org. + + + + The format of a zone file follows: + + recordname IN recordtype value + + + DNS + records + + + The most commonly used DNS records: + + + + + SOA + + start of zone authority + + + + NS + + an authoritative name server + + + + A + + a host address + + + + CNAME + + the canonical name for an alias + + + + MX + + mail exchanger + + + + PTR + + a domain name pointer (used in reverse DNS) + + + + + +example.org. IN SOA ns1.example.org. admin.example.org. ( + 5 ; Serial + 10800 ; Refresh after 3 hours + 3600 ; Retry after 1 hour + 604800 ; Expire after 1 week + 86400 ) ; Minimum TTL of 1 day + + + + + + example.org. + + the domain name, also the origin for this + zone file. + + + + ns1.example.org. + + the primary/authoritative name server for this + zone. + + + + admin.example.org. + + the responsible person for this zone, + email address with @ + replaced. (admin@example.org becomes + admin.example.org) + + + + + 5 + + the serial number of the file. This + must be incremented each time the zone file is modified. + Nowadays, many admins prefer a + yyyymmddrr format for the serial + number. 2001041002 would mean last modified 04/10/2001, + the latter 02 being the second time the zone file has + been modified this day. The serial number is important + as it alerts slave name servers for a zone when it is + updated. + + + + + +@ IN NS ns1.example.org. + + + This is an NS entry. Every name server that is going to reply + authoritatively for the zone must have one of these entries. + The @ as seen here could have been + example.org. + The @ translates to the origin. + + + +localhost IN A 127.0.0.1 +ns1 IN A 3.2.1.2 +ns2 IN A 3.2.1.3 +mail IN A 3.2.1.10 +@ IN A 3.2.1.30 + + + The A record indicates machine names. As seen above, + ns1.example.org would resolve to + 3.2.1.2. Again, + the origin symbol, @, is + used here, thus meaning example.org + would resolve to 3.2.1.30. + + + +www IN CNAME @ + + + The canonical name record is usually used for giving aliases + to a machine. In the example, www is + aliased to the machine addressed to the origin, or + example.org + (3.2.1.30). + CNAMEs can be used to provide alias + hostnames, or round robin one hostname among multiple + machines. + + + + MX record + + + +@ IN MX 10 mail.example.org. + + + The MX record indicates which mail + servers are responsible for handling incoming mail for the + zone. mail.example.org is the + hostname of the mail server, and 10 being the priority of + that mail server. + + + + One can have several mail servers, with priorities of 3, 2, + 1. A mail server attempting to deliver to example.org would first try the + highest priority MX, then the second highest, etc, until the + mail can be properly delivered. + + + + For in-addr.arpa zone files (reverse DNS), the same format is + used, except with PTR entries instead of + A or CNAME. + + + $TTL 3600 + +1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( + 5 ; Serial + 10800 ; Refresh + 3600 ; Retry + 604800 ; Expire + 3600 ) ; Minimum + +@ IN NS ns1.example.org. +@ IN NS ns2.example.org. + +2 IN PTR ns1.example.org. +3 IN PTR ns2.example.org. +10 IN PTR mail.example.org. +30 IN PTR example.org. + + This file gives the proper IP address to hostname mappings of our above + fictitious domain. + + + + + + Caching Name Server + + BIND + caching name server + + + A caching name server is a name server that is not + authoritative for any zones. It simply asks queries of its own, + and remembers them for later use. To set one up, just configure + the name server as usual, omitting any inclusions of zones. + + + + + Running <application>named</application> in a Sandbox + + BIND + running in a sandbox + + + + chroot + + For added security you may want to run &man.named.8; as an + unprivileged user, and configure it to &man.chroot.8; into a + sandbox directory. This makes everything outside of the sandbox + inaccessible to the named daemon. Should + named be compromised, this will help to + reduce the damage that can be caused. By default, FreeBSD has a user + and a group called bind, intended for this + use. + + Various people would recommend that instead of configuring + named to chroot, you + should run named inside a &man.jail.8;. + This section does not attempt to cover this situation. + + + Since named will not be able to + access anything outside of the sandbox (such as shared + libraries, log sockets, and so on), there are a number of steps + that need to be followed in order to allow + named to function correctly. In the + following checklist, it is assumed that the path to the sandbox + is /etc/namedb and that you have made no + prior modifications to the contents of this directory. Perform + the following steps as root: + + + + Create all directories that named + expects to see: + + &prompt.root; cd /etc/namedb +&prompt.root; mkdir -p bin dev etc var/tmp var/run master slave +&prompt.root; chown bind:bind slave var/* + + + + + + named only needs write access to + these directories, so that is all we give it. + + + + + + Rearrange and create basic zone and configuration files: + &prompt.root; cp /etc/localtime etc +&prompt.root; mv named.conf etc && ln -sf etc/named.conf +&prompt.root; mv named.root master + +&prompt.root; sh make-localhost && mv localhost.rev localhost-v6.rev master +&prompt.root; cat > master/named.localhost +$ORIGIN localhost. +$TTL 6h +@ IN SOA localhost. postmaster.localhost. ( + 1 ; serial + 3600 ; refresh + 1800 ; retry + 604800 ; expiration + 3600 ) ; minimum + IN NS localhost. + IN A 127.0.0.1 +^D + + + + This allows named to log the + correct time to &man.syslogd.8;. + + + + + + If you are running a version of &os; prior to 4.9-RELEASE, build a statically linked copy of + named-xfer, and copy it into the sandbox: + + &prompt.root; cd /usr/src/lib/libisc +&prompt.root; make cleandir && make cleandir && make depend && make all +&prompt.root; cd /usr/src/lib/libbind +&prompt.root; make cleandir && make cleandir && make depend && make all +&prompt.root; cd /usr/src/libexec/named-xfer +&prompt.root; make cleandir && make cleandir && make depend && make NOSHARED=yes all +&prompt.root; cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer + + After your statically linked + named-xfer is installed some cleaning up + is required, to avoid leaving stale copies of libraries or + programs in your source tree: + + &prompt.root; cd /usr/src/lib/libisc +&prompt.root; make cleandir +&prompt.root; cd /usr/src/lib/libbind +&prompt.root; make cleandir +&prompt.root; cd /usr/src/libexec/named-xfer +&prompt.root; make cleandir + + + + This step has been reported to fail occasionally. If this + happens to you, then issue the command: + + &prompt.root; cd /usr/src && make cleandir && make cleandir + + and delete your /usr/obj tree: + + &prompt.root; rm -fr /usr/obj && mkdir /usr/obj + + This will clean out any cruft from your + source tree, and retrying the steps above should then work. + + + + If you are running &os; version 4.9-RELEASE or later, then + the copy of named-xfer in + /usr/libexec is statically linked by default, + and you can simply use &man.cp.1; to copy it into your sandbox. + + + + Make a dev/null that + named can see and write to: + + &prompt.root; cd /etc/namedb/dev && mknod null c 2 2 +&prompt.root; chmod 666 null + + + + Symlink /var/run/ndc to + /etc/namedb/var/run/ndc: + + &prompt.root; ln -sf /etc/namedb/var/run/ndc /var/run/ndc + + + This simply avoids having to specify the + option to &man.ndc.8; every time you + run it. Since the contents of /var/run are deleted on boot, + if this is something that you find useful you + may wish to add this command to root's crontab, making use + of the option. See + &man.crontab.5; for more information regarding + this. + + + + + + Configure &man.syslogd.8; to create an extra + log socket that + named can write to. To do this, + add -l /etc/namedb/dev/log to the + syslogd_flags variable in + /etc/rc.conf. + + + + Arrange to have named start + and chroot itself to the sandbox by + adding the following to + /etc/rc.conf: + + named_enable="YES" +named_flags="-u bind -g bind -t /etc/namedb /etc/named.conf" + + + Note that the configuration file + /etc/named.conf is denoted by a full + pathname relative to the sandbox, i.e. in + the line above, the file referred to is actually + /etc/namedb/etc/named.conf. + + + + + The next step is to edit + /etc/namedb/etc/named.conf so that + named knows which zones to load and + where to find them on the disk. There follows a commented + example (anything not specifically commented here is no + different from the setup for a DNS server not running in a + sandbox): + + options { + directory "/"; + named-xfer "/bin/named-xfer"; + version ""; // Don't reveal BIND version + query-source address * port 53; +}; +// ndc control socket +controls { + unix "/var/run/ndc" perm 0600 owner 0 group 0; +}; +// Zones follow: +zone "localhost" IN { + type master; + file "master/named.localhost"; + allow-transfer { localhost; }; + notify no; +}; +zone "0.0.127.in-addr.arpa" IN { + type master; + file "master/localhost.rev"; + allow-transfer { localhost; }; + notify no; +}; +zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.int" { + type master; + file "master/localhost-v6.rev"; + allow-transfer { localhost; }; + notify no; +}; +zone "." IN { + type hint; + file "master/named.root"; +}; +zone "private.example.net" in { + type master; + file "master/private.example.net.db"; + allow-transfer { 192.168.10.0/24; }; +}; +zone "10.168.192.in-addr.arpa" in { + type slave; + masters { 192.168.10.2; }; + file "slave/192.168.10.db"; +}; + + + + The + directory statement is specified as + /, since all files that + named needs are within this + directory (recall that this is equivalent to a + normal user's + /etc/namedb). + + + + Specifies the full path + to the named-xfer binary (from + named's frame of reference). This + is necessary since named is + compiled to look for named-xfer in + /usr/libexec by default. + + Specifies the filename (relative + to the directory statement above) where + named can find the zone file for this + zone. + + Specifies the filename + (relative to the directory statement above) + where named should write a copy of + the zone file for this zone after successfully transferring it + from the master server. This is why we needed to change the + ownership of the directory slave to + bind in the setup stages above. + + + + After completing the steps above, either reboot your + server or restart &man.syslogd.8; and start &man.named.8;, making + sure to use the new options specified in + syslogd_flags and + named_flags. You should now be running a + sandboxed copy of named! + + + + + Security + + Although BIND is the most common implementation of DNS, + there is always the issue of security. Possible and + exploitable security holes are sometimes found. + + + + It is a good idea to read CERT's security advisories and + to subscribe to the &a.security-notifications; + to stay up to date with the current Internet and FreeBSD security + issues. + + + If a problem arises, keeping sources up to date and having a + fresh build of named would not hurt. + + + + Further Reading + + BIND/named manual pages: &man.ndc.8; &man.named.8; &man.named.conf.5; + + + + + Official ISC BIND + Page + + + + + BIND FAQ + + + + O'Reilly + DNS and BIND 4th Edition + + + + RFC1034 + - Domain Names - Concepts and Facilities + + + + RFC1035 + - Domain Names - Implementation and Specification + + + + + + + + + + Tom + Hukins + Contributed by + + + + NTP + + NTP + + + Overview + + Over time, a computer's clock is prone to drift. As time + passes, the computer's clock becomes less accurate. NTP + (Network Time Protocol) is one way to ensure your clock is + right. + + Many Internet services rely on, or greatly benefit from, + computers' clocks being accurate. For example, a Web server + may receive requests to send a file if it has modified since a + certain time. Services such as &man.cron.8; run commands at a + given time. If the clock is inaccurate, these commands may + not run when expected. + + + NTP + ntpd + + FreeBSD ships with the &man.ntpd.8; NTP server which can + be used to query other NTP servers to set the clock on your + machine or provide time services to others. + + + + Choosing Appropriate NTP Servers + + + NTP + choosing servers + + + In order to synchronize your clock, you will need to find + one or more NTP servers to use. Your network administrator or + ISP may have set up an NTP server for this purpose—check + their documentation to see if this is the case. There is a + list of + publicly accessible NTP servers which you can use to + find an NTP server near to you. Make sure you are aware of + the policy for any servers you choose, and ask for permission + if required. + + Choosing several unconnected NTP servers is a good idea in + case one of the servers you are using becomes unreachable or + its clock is unreliable. &man.ntpd.8; uses the responses it + receives from other servers intelligently—it will favor + unreliable servers less than reliable ones. + + + + Configuring Your Machine + + + NTP + configuration + + + + Basic Configuration + ntpdate + + If you only wish to synchronize your clock when the + machine boots up, you can use &man.ntpdate.8;. This may be + appropriate for some desktop machines which are frequently + rebooted and only require infrequent synchronization, but + most machines should run &man.ntpd.8;. + + Using &man.ntpdate.8; at boot time is also a good idea + for machines that run &man.ntpd.8;. The &man.ntpd.8; program changes the + clock gradually, whereas &man.ntpdate.8; sets the clock, no + matter how great the difference between a machine's current + clock setting and the correct time. + + To enable &man.ntpdate.8; at boot time, add + ntpdate_enable="YES" to + /etc/rc.conf. You will also need to + specify all servers you wish to synchronize with and any + flags to be passed to &man.ntpdate.8; in + ntpdate_flags. + + + + + NTP + ntp.conf + + + General Configuration + + NTP is configured by the + /etc/ntp.conf file in the format + described in &man.ntp.conf.5;. Here is a simple + example: + + server ntplocal.example.com prefer +server timeserver.example.org +server ntp2a.example.net + +driftfile /var/db/ntp.drift + + The server option specifies which + servers are to be used, with one server listed on each line. + If a server is specified with the prefer + argument, as with ntplocal.example.com, that server is + preferred over other servers. A response from a preferred + server will be discarded if it differs significantly from + other servers' responses, otherwise it will be used without + any consideration to other responses. The + prefer argument is normally used for NTP + servers that are known to be highly accurate, such as those + with special time monitoring hardware. + + The driftfile option specifies which + file is used to store the system clock's frequency offset. + The &man.ntpd.8; program uses this to automatically compensate for the + clock's natural drift, allowing it to maintain a reasonably + correct setting even if it is cut off from all external time + sources for a period of time. + + The driftfile option specifies which + file is used to store information about previous responses + from the NTP servers you are using. This file contains + internal information for NTP. It should not be modified by + any other process. + + + + Controlling Access to Your Server + + By default, your NTP server will be accessible to all + hosts on the Internet. The restrict + option in /etc/ntp.conf allows you to control which + machines can access your server. + + If you want to deny all machines from accessing your NTP + server, add the following line to + /etc/ntp.conf: + + restrict default ignore + + If you only want to + allow machines within your own network to synchronize their + clocks with your server, but ensure they are not allowed to + configure the server or used as peers to synchronize + against, add + + restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap + + instead, where 192.168.1.0 is + an IP address on your network and 255.255.255.0 is your network's + netmask. + + /etc/ntp.conf can contain multiple + restrict options. For more details, see + the Access Control Support subsection of + &man.ntp.conf.5;. + + + + + Running the NTP Server + + To ensure the NTP server is started at boot time, add the + line xntpd_enable="YES" to + /etc/rc.conf. If you wish to pass + additional flags to &man.ntpd.8;, edit the + xntpd_flags parameter in + /etc/rc.conf. + + To start the server without rebooting your machine, run + ntpd being sure to specify any additional + parameters from xntpd_flags in + /etc/rc.conf. For example: + &prompt.root; ntpd -p /var/run/ntpd.pid + + + Under &os; 5.X, various options in + /etc/rc.conf have been renamed. Thus, + you have to replace every instance of xntpd + with ntpd in the options above. + + + + Using ntpd with a Temporary Internet + Connection + + The &man.ntpd.8; program does not need a permanent + connection to the Internet to function properly. However, if + you have a temporary connection that is configured to dial out + on demand, it is a good idea to prevent NTP traffic from + triggering a dial out or keeping the connection alive. If you + are using user PPP, you can use filter + directives in /etc/ppp/ppp.conf. For + example: + + set filter dial 0 deny udp src eq 123 + # Prevent NTP traffic from initiating dial out + set filter dial 1 permit 0 0 + set filter alive 0 deny udp src eq 123 + # Prevent incoming NTP traffic from keeping the connection open + set filter alive 1 deny udp dst eq 123 + # Prevent outgoing NTP traffic from keeping the connection open + set filter alive 2 permit 0/0 0/0 + + For more details see the PACKET + FILTERING section in &man.ppp.8; and the examples in + /usr/share/examples/ppp/. + + + Some Internet access providers block low-numbered ports, + preventing NTP from functioning since replies never + reach your machine. + + + + + Further Information + + Documentation for the NTP server can be found in + /usr/share/doc/ntp/ in HTML + format. + + + + + + + + Chern + Lee + Contributed by + + + + + The <application>inetd</application> <quote>Super-Server</quote> + + + Overview + + &man.inetd.8; is referred to as the Internet + Super-Server because it manages connections for several + daemons. Programs that provide network service are commonly + known as daemons. inetd serves as a + managing server for other daemons. When a connection is + received by inetd, it determines + which daemon the connection is destined for, spawns the + particular daemon and delegates the socket to it. Running one + instance of inetd reduces the overall + system load as compared to running each daemon individually in + stand-alone mode. + + Primarily, inetd is used to + spawn other daemons, but several trivial protocols are handled + directly, such as chargen, + auth, and + daytime. + + This section will cover the basics in configuring + inetd through its command-line + options and its configuration file, + /etc/inetd.conf. + + + + Settings + + inetd is initialized through + the /etc/rc.conf system. The + inetd_enable option is set to + NO by default, but is often times turned on by + sysinstall with the medium security + profile. Placing: + inetd_enable="YES" or + inetd_enable="NO" into + /etc/rc.conf can enable or disable + inetd starting at boot time. + + Additionally, different command-line options can be passed + to inetd via the + inetd_flags option. + + + + Command-Line Options + + inetd synopsis: + + + + + + -d + + + Turn on debugging. + + + + + -l + + + Turn on logging of successful connections. + + + + + -w + + + Turn on TCP Wrapping for external services (on by + default). + + + + + -W + + + Turn on TCP Wrapping for internal services which are + built into inetd (on by + default). + + + + + -c maximum + + + Specify the default maximum number of simultaneous + invocations of each service; the default is unlimited. + May be overridden on a per-service basis with the + parameter. + + + + + -C rate + + + Specify the default maximum number of times a + service can be invoked from a single IP address in one + minute; the default is unlimited. May be overridden on a + per-service basis with the + + parameter. + + + + + -R rate + + + Specify the maximum number of times a service can be + invoked in one minute; the default is 256. A rate of 0 + allows an unlimited number of invocations. + + + + + -a + + + Specify one specific IP address to bind to. + Alternatively, a hostname can be specified, in which case + the IPv4 or IPv6 address which corresponds to that + hostname is used. Usually a hostname is specified when + inetd is run inside a + &man.jail.8;, in which case the hostname corresponds to + the &man.jail.8; environment. + + When hostname specification is used and both IPv4 + and IPv6 bindings are desired, one entry with the + appropriate protocol type for each binding is required for + each service in /etc/inetd.conf. For + example, a TCP-based service would need two entries, one + using tcp4 for the protocol and the other using + tcp6. + + + + + -p + + + Specify an alternate file in which to store the + process ID. + + + + + These options can be passed to + inetd using the + inetd_flags option in + /etc/rc.conf. By default, + inetd_flags is set to -wW, + which turns on TCP wrapping for + inetd's internal and external + services. For novice users, these parameters usually do not need + to be modified or even entered in + /etc/rc.conf. + + + An external service is a daemon outside of + inetd, which is invoked when a + connection is received for it. On the other hand, an internal + service is one that inetd has the + facility of offering within itself. + + + + + + <filename>inetd.conf</filename> + + Configuration of inetd is + controlled through the /etc/inetd.conf + file. + + When a modification is made to + /etc/inetd.conf, + inetd can be forced to re-read its + configuration file by sending a HangUP signal to the + inetd process as shown: + + + Sending <application>inetd</application> a HangUP Signal + + &prompt.root; kill -HUP `cat /var/run/inetd.pid` + + + Each line of the configuration file specifies an + individual daemon. Comments in the file are preceded by a + #. The format of + /etc/inetd.conf is as follows: + + service-name +socket-type +protocol +{wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] +user[:group][/login-class] +server-program +server-program-arguments + + An example entry for the ftpd daemon + using IPv4: + + ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l + + + + service-name + + + This is the service name of the particular daemon. + It must correspond to a service listed in + /etc/services. This determines which + port inetd must listen to. If + a new service is being created, it must be placed in + /etc/services + first. + + + + + socket-type + + + Either stream, + dgram, raw, or + seqpacket. stream + must be used for connection-based, TCP daemons, while + dgram is used for daemons utilizing the + UDP transport protocol. + + + + + protocol + + + One of the following: + + + + + + Protocol + Explanation + + + + + tcp, tcp4 + TCP IPv4 + + + udp, udp4 + UDP IPv4 + + + tcp6 + TCP IPv6 + + + udp6 + UDP IPv6 + + + tcp46 + Both TCP IPv4 and v6 + + + udp46 + Both UDP IPv4 and v6 + + + + + + + + + {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] + + + indicates whether the + daemon invoked from inetd is + able to handle its own socket or not. + socket types must use the + option, while stream socket daemons, which are usually + multi-threaded, should use . + usually hands off multiple sockets + to a single daemon, while spawns a + child daemon for each new socket. + + The maximum number of child daemons + inetd may spawn can be set using + the option. If a limit of ten + instances of a particular daemon is needed, a + /10 would be placed after + . + + In addition to , another + option limiting the maximum connections from a single + place to a particular daemon can be enabled. + does + just this. A value of ten here would limit any particular + IP address connecting to a particular service to ten + attempts per minute. This is useful to prevent + intentional or unintentional resource consumption and + Denial of Service (DoS) attacks to a machine. + + In this field, or + is mandatory. + and + are + optional. + + A stream-type multi-threaded daemon without any + or + limits + would simply be: nowait. + + The same daemon with a maximum limit of ten daemons + would read: nowait/10. + + Additionally, the same setup with a limit of twenty + connections per IP address per minute and a maximum + total limit of ten child daemons would read: + nowait/10/20. + + These options are all utilized by the default + settings of the fingerd daemon, + as seen here: + + finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s + + + + + user + + + This is the username that the particular daemon + should run as. Most commonly, daemons run as the + root user. For security purposes, it is + common to find some servers running as the + daemon user, or the least privileged + nobody user. + + + + + server-program + + + The full path of the daemon to be executed when a + connection is received. If the daemon is a service + provided by inetd internally, + then should be + used. + + + + + server-program-arguments + + + This works in conjunction with + by specifying the + arguments, starting with argv[0], passed to the daemon on + invocation. If mydaemon -d is + the command line, mydaemon -d would be + the value of . + Again, if the daemon is an internal service, use + here. + + + + + + + Security + + Depending on the security profile chosen at install, many + of inetd's daemons may be enabled by + default. If there is no apparent need for a particular daemon, + disable it! Place a # in front of the daemon in + question, and send a hangup signal + to inetd. + Some daemons, such as fingerd, may + not be desired at all because they provide an attacker with too + much information. + + Some daemons are not security-conscious and have long, or + non-existent timeouts for connection attempts. This allows an + attacker to slowly send connections to a particular daemon, thus + saturating available resources. It may be a good idea to place + and + limitations on certain daemons. + + By default, TCP wrapping is turned on. Consult the + &man.hosts.access.5; manual page for more information on placing + TCP restrictions on various inetd + invoked daemons. + + + + Miscellaneous + + daytime, + time, + echo, + discard, + chargen, and + auth are all internally provided + services of inetd. + + The auth service provides identity + (ident, identd) network services, and is configurable to a certain + degree. + + Consult the &man.inetd.8; manual page for more in-depth + information. + + + + + +