📄 00000000.htm
字号:
e services specified elsewhere in the file. The defaults section can contain <BR> a number of attributes: log_type, log_on_success, log_on_failure, only_from <BR>, no_access, passenv, instances, disabled, and enabled. Of these, only log_t <BR>ype and instances do not display a "cumulative effect". The cumulative effec <BR>t is the ability to specify an attribute multiple times within the section. <BR>The first attribute we see here is instances (instances = 25). It specifies <BR>the maximum number of requests any service may handle at one once. This sett <BR>ing says that for any service that doesn't specify it's own instances attrib <BR>ute, that service will be limited to 25 connections. The next attribute is l <BR>og_type (FILE /var/log/servicelog), which specifies the log type (either FIL <BR>E or SYSLOG) and where specifically to log to. For the FILE log type, this m <BR>eans the full path to the log file, and for the SYSLOG log type it syslog fa <BR>cility and optionally the syslog level. <BR>The next two attributes, log_on_success and log_on_failure, deal with what i <BR>s to be logged when a server is started and exited. The log_on_success attri <BR>bute accepts five different values: PID (log of the pid xinetd uses to spawn <BR> the server), HOST (logs the remote host's IP address), USERID (logs the use <BR>rid of the remote user as returned by remote identd service), EXIT (logs the <BR> exit status of the server when it exits), and DURATION ( logs the duration <BR>of the server session). Here, only the host's address and the server's pid a <BR>re logged by default (log_on_success = HOST PID). The log_on_failure attribu <BR>te comes into play when either the server could not be started due to lack o <BR>f resources, or access was denied via the rules in the conf file. It has fou <BR>r valid values: HOST (again, the remote host's IP address), USERID (same as <BR>log_on_success), ATTEMPT (simple acknowledge that a failed attempt was made) <BR>, and RECORD (grabs as much info about the remote end as is possible). In th <BR>is default xinetd.conf, the remote machine's address as well as any other in <BR>formation it can garner are logged (log_on_failure = HOST RECORD). <BR>The last attribute shown in the default configuration is the per_source attr <BR>ibute. This specifies the maximum number of connections for any one remote a <BR>ddress to a service. It can either be an integer, or the special value "UNLI <BR>MITED" which is at is says, an unlimited number of connections. Here it defa <BR>ults to a maximum of 5 connections per server per IP address (per_source = 5 <BR>). <BR>As you can see, there are a number of attributes not accounted for in the de <BR>fault configuration. I'll briefly discuss the missing attributes here, as mo <BR>st also apply to the individual service sections we'll get into later. To ex <BR>plicitly allow and deny addresses and networks, xinetd provides two attribut <BR>es called only_from, and no_access. There are a number of ways to specify an <BR> ip address or range of addresses, including dotted decimal quads, CIDR nota <BR>tion, and factorized quads. <BR>The disabled and enabled attributes are meant to be lists of service names ( <BR>see the next section) that are enabled and disabled. If enabled is specified <BR>, then any services not listed as values are considered. The same is true wi <BR>th the disabled attribute, with the unlisted services being considered enabl <BR>ed. Should a service be listed as a value for both enabled and disabled, the <BR> disabled attribute overrides. These two attributes are only available in th <BR>e defaults section. <BR>The remaining attribute available in the defaults section is passenv. The va <BR>lues for passenv are items in a list of environment variables from xinetd's <BR>environment to send to the server when it gets instantiated. <BR>With this brief intro to the defaults section complete, we'll move on to the <BR> service sections. But never fear, we'll return to the defaults section and <BR>its attributes later with the sample configurations. <BR>Services sections <BR>The services section define the individual services to be started by xinetd <BR>and how they are to be started. Their general form is <BR> service <servicename> <BR> { <BR> <attribute> <assign_op> <value> <value> ... <BR> <anotherattribute> <assign_op> <value> <value> ... <BR> ... <BR> } <BR>Like the defaults section, the services sections have a number of attributes <BR> that can be specified: type, flags, socket_type, protocol, wait, user, grou <BR>p, instances, nice, server, server_args, only_from, no_access, access_times, <BR> log_type, log_on_success, log_on_failure, rpc_version, rpc_number, env, pas <BR>senv, port, redirect, bind, interface, banner, banner_success, banner_fail, <BR>per_source, cps, max_load, and groups. That may seem like a lot, but realize <BR> that you'll need about 7 of them to setup a basic service. <BR>xconv.pl makes services sections that look like this: <BR> service ftp <BR> { <BR> flags = REUSE NAMEINARGS <BR> socket_type = stream <BR> protocol = tcp <BR> wait = no <BR> user = root <BR> server = /usr/libexec/ftpd <BR> server_args = ftpd -l <BR> } <BR> service telnet <BR> { <BR> flags = REUSE NAMEINARGS <BR> socket_type = stream <BR> protocol = tcp <BR> wait = no <BR> user = root <BR> server = /usr/libexec/telnetd <BR> server_args = telnetd <BR> } <BR>xconv.pl will only translate those services in the inetd.conf that are uncom <BR>mented, and those it does translate are set to their most basic and compatib <BR>le mode. <BR>The first thing you'll probably notice here are that the services sections a <BR>re split into individual service configurations. The servicename is a unique <BR> name for a service you wish to configure in the following section. This ser <BR>vicename is what is used to look up the service information in /etc/services <BR> (or equivalent). <BR>The flags attribute can generally be left as is. The REUSE value is generall <BR>y a good thing and should be left unless you have a specific reason to remov <BR>e it. NAMEINARGS specifies that the first value in the server_args attribute <BR> will be used as the first argument when starting the service specified. Thi <BR>s is most useful when using tcpd; you would specify tcpd in the server attri <BR>bute, and give it the service ("ftpd -l") in the server_args attribute. The <BR>flags attribute is optional. The default configurations should work fine in <BR>most cases. <BR>The attributes socket_type, protocol, wait, and user attributes are all syno <BR>nymous with their inetd counter parts. In all cases I've seen, these can be <BR>left alone. Of these, protocol is optional. <BR>We've already talked about server and server_args a bit. The server attribut <BR>e is simply the full path to the server's executable, very much a required f <BR>ield. Server_args is a list arguments to be passed to the above executable. <BR>Though the xconv.pl application lists the server's executable name in this a <BR>ttribute, it is not necessary, nor particularly desirable (as stated by the <BR>xinetd man pages). However, there doesn't seem to be any specific problems w <BR>ith leaving the attribute as xconv.pl sets it. If you wish to delete the nam <BR>e from the attributes, remember to remove the NAMEINARGS flag from the flags <BR> attribute as well. The server_args attribute must included in a service def <BR>inition, even if it is left blank. <BR>A minimally configured version of the example ftp service would look as foll <BR>ows: <BR>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -