? HTML.manifest ? LEGALNOTICE.html ? acpi-debug.html ? acpi-overview.html ? adding-swap-space.html ? advanced-networking.html ? anoncvs.html ? appendices.html ? backup-basics.html ? backups-floppybackups.html ? backups-tapebackups.html ? basics-daemons.html ? basics-devices.html ? basics-more-information.html ? basics-processes.html ? basics.html ? bibliography-adminguides.html ? bibliography-hardware.html ? bibliography-history.html ? bibliography-journals.html ? bibliography-osinternals.html ? bibliography-programmers.html ? bibliography-security.html ? bibliography-userguides.html ? bibliography.html ? binary-formats.html ? book-preface.html ? boot-blocks.html ? boot-init.html ? boot-introduction.html ? boot-kernel.html ? boot-shutdown.html ? boot.html ? colophon.html ? config-network-setup.html ? config-tuning.html ? configtuning-appconfig.html ? configtuning-configfiles.html ? configtuning-core-configuration.html ? configtuning-cron.html ? configtuning-disk.html ? configtuning-initial.html ? configtuning-kernel-limits.html ? configtuning-rcng.html ? configtuning-starting-services.html ? configtuning-sysctl.html ? configtuning-virtual-hosts.html ? consoles.html ? creating-cds.html ? creating-dvds.html ? crypt.html ? ctm.html ? current-stable.html ? cutting-edge.html ? cvs-tags.html ? cvsup.html ? desktop-browsers.html ? desktop-finance.html ? desktop-productivity.html ? desktop-summary.html ? desktop-viewers.html ? desktop.html ? device-hints.html ? dialout.html ? dialup.html ? dirstructure.html ? disk-organization.html ? disks-adding.html ? disks-encrypting.html ? disks-naming.html ? disks-virtual.html ? disks.html ? docbook.css ? editors.html ? eresources-email.html ? eresources-news.html ? eresources-shell.html ? eresources-web.html ? eresources.html ? eresources.sgml.www.inc ? firewalls.html ? floppies.html ? fs-acl.html ? getting-started.html ? history.html ? imagelib ? index.html ? install-advanced.html ? install-choosing.html ? install-diff-media.html ? install-final-warning.html ? install-media.html ? install-post.html ? install-pre.html ? install-start.html ? install-steps.html ? install-supported-hardware.html ? install-trouble.html ? install.html ? introduction.html ? ipsec.html ? kerberos5.html ? kerberosiv.html ? kernelconfig-building.html ? kernelconfig-config.html ? kernelconfig-custom-kernel.html ? kernelconfig-nodes.html ? kernelconfig-trouble.html ? kernelconfig.html ? l10n-basics.html ? l10n-compiling.html ? l10n.html ? lang-setup.html ? linuxemu-advanced.html ? linuxemu-lbc-install.html ? linuxemu-maple.html ? linuxemu-mathematica.html ? linuxemu-matlab.html ? linuxemu-oracle.html ? linuxemu.html ? mac-biba.html ? mac-bsdextended.html ? mac-examplehttpd.html ? mac-glossary.html ? mac-ifoff.html ? mac-implementing.html ? mac-initial.html ? mac-labelingpolicies.html ? mac-lomac.html ? mac-mls.html ? mac-modules.html ? mac-partition.html ? mac-portacl.html ? mac-troubleshoot.html ? mac-understandlabel.html ? mac.html ? mail-advanced.html ? mail-agents.html ? mail-changingmta.html ? mail-fetchmail.html ? mail-procmail.html ? mail-trouble.html ? mail-using.html ? mail.html ? makeworld.html ? mirrors-afs.html ? mirrors-ftp.html ? mirrors-rsync.html ? mirrors.html ? mirrors.sgml.cvsup.inc ? mirrors.sgml.ftp.inc ? mount-unmount.html ? multimedia.html ? network-atm.html ? network-bluetooth.html ? network-bridging.html ? network-dhcp.html ? network-diskless.html ? network-dns.html ? network-inetd.html ? network-ipv6.html ? network-isdn.html ? network-natd.html ? network-nfs.html ? network-nis.html ? network-ntp.html ? network-plip.html ? network-routing.html ? network-servers ? network-servers.html ? network-wireless.html ? nutshell.html ? one-time-passwords.html ? openssh.html ? openssl.html ? out ? outgoing-only.html ? output ? packages-using.html ? permissions.html ? pgpkeys-core.html ? pgpkeys-developers.html ? pgpkeys.html ? ports-broken.html ? ports-finding-applications.html ? ports-nextsteps.html ? ports-overview.html ? ports-using.html ? ports.html ? ppp-and-slip.html ? ppp-troubleshoot.html ? ppp.html ? pppoa.html ? pppoe.html ? printing-advanced.html ? printing-intro-setup.html ? printing-intro-spooler.html ? printing-lpd-alternatives.html ? printing-troubleshooting.html ? printing-using.html ? printing.html ? quotas.html ? raid.html ? sapr3.html ? securing-freebsd.html ? security-advisories.html ? security-intro.html ? security.html ? sendmail.html ? serial.html ? serialcomms.html ? serialconsole-setup.html ? shells.html ? slip.html ? small-lan.html ? smtp-auth.html ? smtp-dialup.html ? smtp-uucp.html ? snapshots.html ? sound-mp3.html ? sound-setup.html ? synching.html ? system-administration.html ? term.html ? tvcard.html ? usb-disks.html ? userppp.html ? users-groups.html ? users-introduction.html ? users-limiting.html ? users-modifying.html ? users-personalizing.html ? users-superuser.html ? users-system.html ? users-user.html ? users.html ? using-localization.html ? using-sysinstall.html ? usr ? video-playback.html ? vinum-access-bottlenecks.html ? vinum-config.html ? vinum-data-integrity.html ? vinum-examples.html ? vinum-intro.html ? vinum-object-naming.html ? vinum-objects.html ? vinum-root.html ? vinum-vinum.html ? x-config.html ? x-fonts.html ? x-install.html ? x-understanding.html ? x-xdm.html ? x11-wm.html ? x11.html Index: Makefile =================================================================== RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/handbook/Makefile,v retrieving revision 1.86 diff -u -r1.86 Makefile --- Makefile 12 Jul 2004 09:26:16 -0000 1.86 +++ Makefile 12 Jul 2004 09:45:06 -0000 @@ -169,6 +169,7 @@ 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 Index: book.sgml =================================================================== RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/handbook/book.sgml,v retrieving revision 1.149 diff -u -r1.149 book.sgml --- book.sgml 6 Jul 2004 15:09:53 -0000 1.149 +++ book.sgml 12 Jul 2004 09:45:07 -0000 @@ -48,6 +48,7 @@ + @@ -230,6 +231,7 @@ + Index: chapters.ent =================================================================== RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/handbook/chapters.ent,v retrieving revision 1.26 diff -u -r1.26 chapters.ent --- chapters.ent 21 Jun 2004 19:34:55 -0000 1.26 +++ chapters.ent 12 Jul 2004 09:45:07 -0000 @@ -34,6 +34,7 @@ + Index: advanced-networking/chapter.sgml =================================================================== RCS file: /home/dcvs/doc/en_US.ISO8859-1/books/handbook/advanced-networking/chapter.sgml,v retrieving revision 1.322 diff -u -r1.322 chapter.sgml --- advanced-networking/chapter.sgml 12 Jul 2004 07:59:56 -0000 1.322 +++ advanced-networking/chapter.sgml 12 Jul 2004 09:45:10 -0000 @@ -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: @@ -32,40 +30,14 @@ - 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 @@ - - - - - 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,3166 +2889,98 @@ - + - Bill - Swingle - Written by - - - - - Eric - Ogren - Enhanced by - - - Udo - Erdelhoff - + Chern + Lee + Contributed by + - 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. + Network Address Translation + + Overview - NIS - domains + natd - 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. + FreeBSD's Network Address Translation daemon, commonly known as + &man.natd.8; is a daemon that accepts incoming raw IP packets, + changes the source to the local machine and re-injects these packets + back into the outgoing IP packet stream. &man.natd.8; does this by changing + the source IP address and port such that when data is received back, + it is able to determine the original location of the data and forward + it back to its original requester. + Internet connection sharing + IP masquerading + The most common use of NAT is to perform what is commonly known as + Internet Connection Sharing. - - Terms/Processes You Should Know + + Setup + Due to the diminishing IP space in IPv4, and the increased number + of users on high-speed consumer lines such as cable or DSL, people are + increasingly in need of an Internet Connection Sharing solution. The + ability to connect several computers online through one connection and + IP address makes &man.natd.8; a reasonable choice. - 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: + Most commonly, a user has a machine connected to a cable or DSL + line with one IP address and wishes to use this one connected computer to + provide Internet access to several more over a LAN. - - portmap - + To do this, the FreeBSD machine on the Internet must act as a + gateway. This gateway machine must have two NICs—one for connecting + to the Internet router, the other connecting to a LAN. All the + machines on the LAN are connected through a hub or switch. - - - - + + + + - - - 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 + + _______ __________ ________ + | | | | | | + | Hub |-----| Client B |-----| Router |----- Internet + |_______| |__________| |________| + | + ____|_____ +| | +| Client A | +|__________| + - 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. - - - - - + + Network Layout + + + A setup like this is commonly used to share an Internet + connection. One of the LAN machines is + connected to the Internet. The rest of the machines access + the Internet through that gateway + machine. - - 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. + + + kernel + configuration + + Configuration + The following options must be in the kernel configuration + file: + options IPFIREWALL +options IPDIVERT - - Machine Types + Additionally, at choice, the following may also be suitable: + options IPFIREWALL_DEFAULT_TO_ACCEPT +options IPFIREWALL_VERBOSE - - - 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 - - - - Network Address Translation - - - Overview - - natd - - FreeBSD's Network Address Translation daemon, commonly known as - &man.natd.8; is a daemon that accepts incoming raw IP packets, - changes the source to the local machine and re-injects these packets - back into the outgoing IP packet stream. &man.natd.8; does this by changing - the source IP address and port such that when data is received back, - it is able to determine the original location of the data and forward - it back to its original requester. - Internet connection sharing - IP masquerading - The most common use of NAT is to perform what is commonly known as - Internet Connection Sharing. - - - - Setup - Due to the diminishing IP space in IPv4, and the increased number - of users on high-speed consumer lines such as cable or DSL, people are - increasingly in need of an Internet Connection Sharing solution. The - ability to connect several computers online through one connection and - IP address makes &man.natd.8; a reasonable choice. - - Most commonly, a user has a machine connected to a cable or DSL - line with one IP address and wishes to use this one connected computer to - provide Internet access to several more over a LAN. - - To do this, the FreeBSD machine on the Internet must act as a - gateway. This gateway machine must have two NICs—one for connecting - to the Internet router, the other connecting to a LAN. All the - machines on the LAN are connected through a hub or switch. - - - - - - - - _______ __________ ________ - | | | | | | - | Hub |-----| Client B |-----| Router |----- Internet - |_______| |__________| |________| - | - ____|_____ -| | -| Client A | -|__________| - - - - Network Layout - - - - A setup like this is commonly used to share an Internet - connection. One of the LAN machines is - connected to the Internet. The rest of the machines access - the Internet through that gateway - machine. - - - - - kernel - configuration - - Configuration - The following options must be in the kernel configuration - file: - options IPFIREWALL -options IPDIVERT - - Additionally, at choice, the following may also be suitable: - options IPFIREWALL_DEFAULT_TO_ACCEPT -options IPFIREWALL_VERBOSE - - The following must be in /etc/rc.conf: + The following must be in /etc/rc.conf: gateway_enable="YES" firewall_enable="YES" @@ -6804,452 +3167,6 @@ The external IP addresses on the natd machine must be active and aliased to the external interface. Look at &man.rc.conf.5; to do so. - - - - - - - - Chern - Lee - Contributed by - - - - - The <application>inetd</application> <quote>Super-Server</quote> - - - Overview - - &man.inetd.8; is referred to as the Internet - Super-Server because it manages connections for several - daemons. Programs that provide network service are commonly - known as daemons. inetd serves as a - managing server for other daemons. When a connection is - received by inetd, it determines - which daemon the connection is destined for, spawns the - particular daemon and delegates the socket to it. Running one - instance of inetd reduces the overall - system load as compared to running each daemon individually in - stand-alone mode. - - Primarily, inetd is used to - spawn other daemons, but several trivial protocols are handled - directly, such as chargen, - auth, and - daytime. - - This section will cover the basics in configuring - inetd through its command-line - options and its configuration file, - /etc/inetd.conf. - - - - Settings - - inetd is initialized through - the /etc/rc.conf system. The - inetd_enable option is set to - NO by default, but is often times turned on by - sysinstall with the medium security - profile. Placing: - inetd_enable="YES" or - inetd_enable="NO" into - /etc/rc.conf can enable or disable - inetd starting at boot time. - - Additionally, different command-line options can be passed - to inetd via the - inetd_flags option. - - - - Command-Line Options - - inetd synopsis: - - - - - - -d - - - Turn on debugging. - - - - - -l - - - Turn on logging of successful connections. - - - - - -w - - - Turn on TCP Wrapping for external services (on by - default). - - - - - -W - - - Turn on TCP Wrapping for internal services which are - built into inetd (on by - default). - - - - - -c maximum - - - Specify the default maximum number of simultaneous - invocations of each service; the default is unlimited. - May be overridden on a per-service basis with the - parameter. - - - - - -C rate - - - Specify the default maximum number of times a - service can be invoked from a single IP address in one - minute; the default is unlimited. May be overridden on a - per-service basis with the - - parameter. - - - - - -R rate - - - Specify the maximum number of times a service can be - invoked in one minute; the default is 256. A rate of 0 - allows an unlimited number of invocations. - - - - - -a - - - Specify one specific IP address to bind to. - Alternatively, a hostname can be specified, in which case - the IPv4 or IPv6 address which corresponds to that - hostname is used. Usually a hostname is specified when - inetd is run inside a - &man.jail.8;, in which case the hostname corresponds to - the &man.jail.8; environment. - - When hostname specification is used and both IPv4 - and IPv6 bindings are desired, one entry with the - appropriate protocol type for each binding is required for - each service in /etc/inetd.conf. For - example, a TCP-based service would need two entries, one - using tcp4 for the protocol and the other using - tcp6. - - - - - -p - - - Specify an alternate file in which to store the - process ID. - - - - - These options can be passed to - inetd using the - inetd_flags option in - /etc/rc.conf. By default, - inetd_flags is set to -wW, - which turns on TCP wrapping for - inetd's internal and external - services. For novice users, these parameters usually do not need - to be modified or even entered in - /etc/rc.conf. - - - An external service is a daemon outside of - inetd, which is invoked when a - connection is received for it. On the other hand, an internal - service is one that inetd has the - facility of offering within itself. - - - - - - <filename>inetd.conf</filename> - - Configuration of inetd is - controlled through the /etc/inetd.conf - file. - - When a modification is made to - /etc/inetd.conf, - inetd can be forced to re-read its - configuration file by sending a HangUP signal to the - inetd process as shown: - - - Sending <application>inetd</application> a HangUP Signal - - &prompt.root; kill -HUP `cat /var/run/inetd.pid` - - - Each line of the configuration file specifies an - individual daemon. Comments in the file are preceded by a - #. The format of - /etc/inetd.conf is as follows: - - service-name -socket-type -protocol -{wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] -user[:group][/login-class] -server-program -server-program-arguments - - An example entry for the ftpd daemon - using IPv4: - - ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l - - - - service-name - - - This is the service name of the particular daemon. - It must correspond to a service listed in - /etc/services. This determines which - port inetd must listen to. If - a new service is being created, it must be placed in - /etc/services - first. - - - - - socket-type - - - Either stream, - dgram, raw, or - seqpacket. stream - must be used for connection-based, TCP daemons, while - dgram is used for daemons utilizing the - UDP transport protocol. - - - - - protocol - - - One of the following: - - - - - - Protocol - Explanation - - - - - tcp, tcp4 - TCP IPv4 - - - udp, udp4 - UDP IPv4 - - - tcp6 - TCP IPv6 - - - udp6 - UDP IPv6 - - - tcp46 - Both TCP IPv4 and v6 - - - udp46 - Both UDP IPv4 and v6 - - - - - - - - - {wait|nowait}[/max-child[/max-connections-per-ip-per-minute]] - - - indicates whether the - daemon invoked from inetd is - able to handle its own socket or not. - socket types must use the - 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.