22.2.3 配置xinetd
xinetd守护进程依照/etc/xinetd.conf的配置行事。如今的Linux发行版都不鼓励通过直接编辑/etc/xinetd.conf来添加服务,相反用户应该为每个服务单独开辟一个文件,存放在/etc/xinetd.d目录下。查看xinetd.conf可以看到这一点:
$ cat /etc/xinetd.conf ##查看/etc/xinetd.conf
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/
defaults
{
# Please note that you need a log_type line to be able to use log_on_success
# and log_on_failure. The default is the following :
log_type = SYSLOG daemon info
}
includedir /etc/xinetd.d
最后一行使用includedir命令把目录/etc/xinetd.d下的文件包含进来。这样设置的好处是,如果有很多服务需要依靠xinetd,那么把它们全部写入xinetd.conf中势必会让整个结构看起来一团糟,把服务器配置分类存放有助于管理员理清头绪。
xinetd.conf中的defaults配置段设置了xinetd一些参数的默认值。在上面的例子中,log_type的值被设置为SYSLOG deamon info,该变量的含义将在后文解释。
安装xinetd后会在/etc/xinetd.d中自动生成一些服务的配置文件。作为例子,下面显示了time服务的配置信息(在/etc/xinetd.d/time文件中配置)。
service time
{
disable = yes
type = INTERNAL
id = time-stream
socket_type = stream
protocol = tcp
user = root
wait = no
}
每个服务总是以关键字service开头,后面跟着服务名。对该服务的配置包含在一对花括号中,以“参数=值”的形式,每个参数占一行。表22.3列出了xinetd配置的常用参数。
表22.3 xinetd配置的常用参数
参 数 | 取 值 | 含 义 |
id | 有意义的字符串 | 该服务的唯一名称 |
type | RPC/INTERNAL/UNLISTED | 指定特殊服务的类型。RPC用于RPC服务;INTERNAL用于构建到xinetd内部的服务;UNLISTED用于非标准服务 |
disable | yes/no | 是否禁用该服务 |
socket_type | stream/dgram | 网络套接口类型。TCP服务用stream,UDP服务用dgram |
protocol | tcp/udp | 连接使用的通信协议 |
wait | yes/no | xinetd是否等待守护进程结束才重新接管该端口 |
server | 路径 | 服务器二进制文件的路径 |
server_args | 参数 | 提供给服务器二进制文件的命令行参数 |
port | 端口号 | 该服务所在的端口 |
user | 用户名 | 服务器进程应该由哪个用户身份运行 |
nice | 数字 | 服务器进程的谦让度。参考10.7节 |
instances | 数字/UNLIMITED | 同时启动的响应数量。UNLIMITED表示没有限制 |
max_load | 数字 | 调整系统负载阈值。如果实际负载超过该阈值,就停止服务 |
only_from | IP地址列表 | 只接受来自该地址的连接请求 |
no_access | IP地址列表 | 拒绝向该IP地址提供服务 |
log_on_failure | 列表值 | 连接失败时应该记录到日志中的信息 |
log_on_success | 列表值 | 连接成功时应该记录到日志中的信息 |
参数id用于唯一标识服务,这意味着可以为同一个服务器守护进程配置不同的协议。上文中的time服务就拥有两个版本的xinetd配置,另一个用于UDP协议。
参数disable设置是否要禁用该服务。有些时候,管理员只是想列出将来可能会用到的服务,而不是现在就启用它。对这么多行进行注释会让人感到厌烦,将disable设置为yes就可以简单地禁用该服务。不过,管理员偶尔也会忘记在启用服务的时候把这个选项改回来,如果正在奇怪为什么某项服务没有被xinetd加载,那么应该首先检查disable选项是否已经被正确地设置为no了。
将wait参数设置为yes意味着由xinetd派生出的守护进程一旦启动就接管端口,xinetd会一直等待,直到该守护进程自己退出;wait=no表示xinetd会连续监视端口,每次接到一个请求就启动守护进程的一个新副本。管理员应该参考守护进程的手册,或者xinetd的配置样例来确定使用何种配置。
参数port在绝大多数情况下是不需要的。xinetd根据服务名从/etc/service文件中查找信息,确定该服务使用的端口和网络协议。如果没有在/etc/service文件中登记该服务,那么也应该手动添加,而不是使用port参数——把信息集中起来管理总是能省去不少麻烦。下面截取了/etc/service文件中的一部分。
ftp 21/tcp
fsp 21/udp fspd
ssh 22/tcp # SSH Remote Login Protocol
ssh 22/udp
telnet 23/tcp
smtp 25/tcp mail
/etc/service中的每一行对应一个服务,从左到右依次表示:
q 服务名称。例如ssh;
q 该服务使用的端口号。例如22;
q 该服务使用的传输协议。例如tcp;
q 别名(或者叫“绰号”?)。例如fspd;
q 注释。例如# SSH Remote Login Protocol。
参数user设置应该以哪个用户身份运行该服务器进程,大部分服务都使用root。有些时候从安全的角度考虑会使用非特权用户(例如nobody),但这只适用于那些不需要root权利的守护进程。
xinetd会记录连接失败/成功时的信息,用户可以通过定制log_on_failure和log_on_success这两个参数指导xinetd记录哪些信息。表22.4列出了和这两个参数有关的取值。
表22.4 和日志记录有关的取值
值 | 适 用 于 | 描 述 |
HOST | 二者皆可 | 记录远程主机的地址 |
USERID | 二者皆可 | 记录远程用户的ID |
PID | log_on_success | 记录服务器进程的PID |
EXIT | log_on_success | 记录服务器进程的退出信息 |
DURATION | log_on_success | 记录任务持续的时间 |
ATTEMPT | log_on_failure | 记录连接失败的原因 |
RECORD | log_on_failure | 记录连接失败的额外的信息 |
%注意:USERID标志会向远程主机询问建立连接的用户信息,这样总会造成明显的延时,因此应该尽可能避免使用USERID。
完成对服务配置的后,使用下面这条命令重新启动xinetd守护进程。
$ sudo /etc/init.d/xinetd restart