|
Page 1183 IDENTIFICATION Author: Walter F. Tichy, Purdue University, West Lafayette, IN, 47907. Manual Page Revision: 5.6; Release Date: 1995/06/05. Copyright 1982, 1988, 1989, Walter F. Tichy. Copyright 1990, 1991, 1992, 1993, 1994, 1995, Paul Eggert. SEE ALSO rcsintro(1), ci(1), co(1), ident(1), rcs(1), rcsclean(1), rcsdiff(1), rcsmerge(1), rlog(1), Walter F. Tichy, RCS, "A System for Version Control," Software—Practice & Experience, 15, 7 (July 1985), 637-654. GNU, 5 June 1995 resolverresolver—Resolver configuration file. SYNOPSIS /etc/resolv.conf DESCRIPTION The resolver is a set of routines in the C library (resolv(3)) that provides access to the Internet Domain Name System. The resolver configuration file contains information that is read by the resolver routines the first time they are invoked by a process. The file is designed to be human readable and contains a list of keywords with values that provide various types of resolver information. On a normally configured system, this file should not be necessary. The only nameserver to be queried will be on the local machine, the domain name is determined from the host name, and the domain search path is constructed from the domain name. The different configuration options are
Page 1184
The domain and search keywords are mutually exclusive. If more than one instance of these keywords is present, the last instance wins. The search keyword of a system's resolv.conf file can be overridden on a per-process basis by setting the environment variable LOCALDOMAIN to a space-separated list of search domains. The options keyword of a system's resolv.conf file can be amended on a per-process basis by setting the environment variable RES_OPTIONS to a space-separated list of resolver options as explained previously. The keyword and value must appear on a single line, and the keyword (such as nameserver) must start the line. The value follows the keyword, separated by whitespace. FILES /etc/resolv.conf SEE ALSO gethostbyname(3), resolver(3), hostname(7), named(8), Name Server Operations Guide for BIND 11 November 1993 securettysecuretty—File that lists ttys from which root can log in. DESCRIPTION /etc/securetty is used by login(1); the file contains the device names of tty lines (one per line, without leading /dev/) on which root is allowed to log in. FILES /etc/securetty SEE ALSO login(1) Linux, 29 December 1992 servicesservices—Internet network services list. DESCRIPTION services is a plain ASCII file providing a mapping between friendly textual names for Internet services and their underlying assigned port numbers and protocol types. Every networking program should look into this file to get the port number (and Page 1185 protocol) for its service. The C library routines getservent(3), getservbyname(3), getservbyport(3), setservent(3), and endservent(3) support querying this file from programs. Port numbers are assigned by the IANA (Internet Assigned Numbers Authority), and their current policy is to assign both TCP and UDP protocols when assigning a port number. Therefore, most entries will have two entries, even for TCP-only services. Port numbers below 1024 (so-called low-numbered ports) can only be bound to by root (see bind(2), tcp(7), and udp(7).) This is so that clients connecting to low-numbered ports can trust that the service running on the port is the standard implementation and not a rogue service run by a user of the machine. Well-known port numbers specified by the IANA are normally located in this root-only space. The presence of an entry for a service in the services file does not necessarily mean that the service is currently running on the machine. See inetd.conf(5) for the configuration of Internet services offered. Note that not all networking services are started by inetd(8) and so won't appear in inetd.conf(5). In particular, news (NNTP) and mail (SMTP) servers are often initialized from the system boot scripts. The location of the services file is defined by PATH SERVICES in /usr/include/netdb.h. This is usually set to /etc/services. Each line describes one service and is of the form: service-name port/protocol [aliases ...]
Either spaces or tabs may be used to separate the fields. Comments are started by the hash sign (#) and continue until the end of the line. Blank lines are skipped. The service-name should begin in the first column of the file because leading spaces are not stripped. service-names can be any printable characters excluding space and tab; however, a conservative choice of characters should be used to minimize inter-operability problems. For example, a_z, 0_9, and hyphen (_) would seem a sensible choice. Lines not matching this format should not be present in the file. (Currently, they are silently skipped by getservent(3), getservbyname(3), and getservbyport(3). However, this behavior should not be relied on.) As a backwards compatibility feature, the slash (/) between the port number and protocol name can in fact be either a slash or a comma (,). Use of the comma in modern installations is depreciated. This file might be distributed over a network using a network-wide naming service such as Yellow Pages/NIS or BIND/Hesiod. A sample services file might look like this: netstat 15/tcp qotd 17/tcp quote msp 18/tcp # message send protocol msp 18/udp # message send protocol chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp 21/tcp # 22 - unassigned telnet 23/tcp |
