BBS水木清华站∶精华区
发信人: jester (玩笑鬼), 信区: Linux
标 题: an unofficial xinetd tutorial
发信站: BBS 水木清华站 (Wed Nov 29 09:29:47 2000)
An Unofficial Xinetd Tutorial
by curator, The Shmoo Group.
Contents:
What xinetd does
Installation
Configuration file basics
A Simple Configuration with little access control
A More Complicated Configuration with Access Control
Day to day use of xinetd (or updating the xinetd.conf)
Port redirection
Additional info for Mac OS X (Server)
Parting words
----------------------------------------------------------------------------
----
What xinetd does
xinetd is a secure replacement for inetd, and a more efficient replacement f
or inetd and tcp_wrappers. It sports a number of features that make it a goo
d choice for securing a server. These include access control (based on sourc
e address, destination address, and time), extensive logging, and the abilit
y to bind services to specific interfaces. This tutorial will attempt to giv
e an administrator the necessary tools to install, configure, and maintain x
inetd.
Being a "secure replacement for inetd", xinetd attempts to do everything tha
t inetd does, only securely. This means that, like inetd, it is a super-serv
er. Both xinetd and inetd read in their configuration files which are basica
lly a list of IP services to listen to. The super-servers "listen" on the po
rts defined by those listed in configuration files for connection attemps on
those ports. When it receives a connection on a port it thinks it has a ser
vice for, it attempts to start the requisite server. There are exceptions to
this scheme, mostly for single-threaded servers, where the super-servers si
mply start the server, which then takes care of service requests until the s
erver dies.
Where inetd and xinetd begin to differ is xinetd's support for RPC services;
it isn't great. The author of xinetd suggests that an admin running an rpc
service do so from inetd. xinetd and inetd can cohabitate quite peacefully.
Another thing that differs is the configuration files; the two are mutually
incompatible. xinetd's conf file contains more information than inetd does i
n order to handle the additional security parameters.
----------------------------------------------------------------------------
----
Installation
First you need to download the latest source from xinetd.org to some conveni
ent directory (ie., /usr/local/src). Once downloaded, expand the archive and
change to its directory. (If running Mac OS X(S), there is a section later
in this tutorial that has additional to assist you in this process.)
It is possible to compile xinetd with libwrap support by adding the --with-l
ibwrap flag to ./configure. This allows xinetd to use the hosts.{allow | den
y} mechanism. To do so, you'll need to have tcp_wrappers installed, and the
requisite libraries in place. The decision to do so is up to the individual
admin. This option exists mostly to help those more comfortable with the wra
pper mechanism to more easily configure xinetd. We suggest that you do not c
ompile the software with libwrap support unless you have the need; it is bes
t and most flexible to do without it.
Further options are available (such as install paths, ipv6 support, etc) and
you should read the install docs to determince which of these settings is c
orrect for you.
Once you've run ./configure with the options you need, run "make" followed b
y "make install" as root. Assuming xinetd makes and installs with no errors,
the next thing to do is configure it. If it doesn't, you may wish to subscr
ibe to the xinetd maillist by sending a message to majordomo@synack.net with
a body of "subscribe xinetd".
----------------------------------------------------------------------------
----
Configuration file basics
xinetd ships with a perl script (installed in the same directory as the xine
td binary) that conveniently converts an inetd.conf into a xinetd.conf. It m
ay be invoked as "/usr/sbin/xconv.pl < /etc/inetd.conf > /tmp/xinetd.conf",
where "/usr/sbin" is your path to the xinetd executable.
xconv.pl will try to make a xinetd.conf from your original inetd.conf as bes
t it can, but most admins will want (read: need) to modify the xinetd.conf i
t generates. For instance, many BSD's (including Mac OS X [Server]) require
that each service have a "groups = yes" setting.
The defaults section
xconv.pl by default makes a defaults section that looks something like this:
defaults
{
#The maximum number of requests a particular service may handle
# at once.
instances = 25
# The type of logging. This logs to a file that is specified.
# Another option is: SYSLOG syslog_facility [syslog_level]
log_type = FILE /var/log/servicelog
# What to log when the connection succeeds.
# PID logs the pid of the server processing the request.
# HOST logs the remote host's ip address.
# USERID logs the remote user (using RFC 1413)
# EXIT logs the exit status of the server.
# DURATION logs the duration of the session.
log_on_success = HOST PID
# What to log when the connection fails. Same options as above
log_on_failure = HOST RECORD
# The maximum number of connections a specific IP address can
# have to a specific service.
per_source = 5
}
Here we can begin to see some of the basic characteristics of a conf file. S
ections have the general form:
sectiontypeorname
{
<attribute> <assign_op> <value><value> ...
<anotherattribute> <assign_op> <value><value> ...
...
}
Lines beginning with "#" are comments. Whitespace lines are ignored. There c
an be only one defaults section in a xinetd.conf file. In the defaults secti
on the assign_op is only a "=".
The defaults section, as its name implies, specifies default settings for th
e services specified elsewhere in the file. The defaults section can contain
a number of attributes: log_type, log_on_success, log_on_failure, only_from
, no_access, passenv, instances, disabled, and enabled. Of these, only log_t
ype and instances do not display a "cumulative effect". The cumulative effec
t is the ability to specify an attribute multiple times within the section.
The first attribute we see here is instances (instances = 25). It specifies
the maximum number of requests any service may handle at one once. This sett
ing says that for any service that doesn't specify it's own instances attrib
ute, that service will be limited to 25 connections. The next attribute is l
og_type (FILE /var/log/servicelog), which specifies the log type (either FIL
E or SYSLOG) and where specifically to log to. For the FILE log type, this m
eans the full path to the log file, and for the SYSLOG log type it syslog fa
cility and optionally the syslog level.
The next two attributes, log_on_success and log_on_failure, deal with what i
s to be logged when a server is started and exited. The log_on_success attri
bute accepts five different values: PID (log of the pid xinetd uses to spawn
the server), HOST (logs the remote host's IP address), USERID (logs the use
rid of the remote user as returned by remote identd service), EXIT (logs the
exit status of the server when it exits), and DURATION ( logs the duration
of the server session). Here, only the host's address and the server's pid a
re logged by default (log_on_success = HOST PID). The log_on_failure attribu
te comes into play when either the server could not be started due to lack o
f resources, or access was denied via the rules in the conf file. It has fou
r valid values: HOST (again, the remote host's IP address), USERID (same as
log_on_success), ATTEMPT (simple acknowledge that a failed attempt was made)
, and RECORD (grabs as much info about the remote end as is possible). In th
is default xinetd.conf, the remote machine's address as well as any other in
formation it can garner are logged (log_on_failure = HOST RECORD).
The last attribute shown in the default configuration is the per_source attr
ibute. This specifies the maximum number of connections for any one remote a
ddress to a service. It can either be an integer, or the special value "UNLI
MITED" which is at is says, an unlimited number of connections. Here it defa
ults to a maximum of 5 connections per server per IP address (per_source = 5
).
As you can see, there are a number of attributes not accounted for in the de
fault configuration. I'll briefly discuss the missing attributes here, as mo
st also apply to the individual service sections we'll get into later. To ex
plicitly allow and deny addresses and networks, xinetd provides two attribut
es called only_from, and no_access. There are a number of ways to specify an
ip address or range of addresses, including dotted decimal quads, CIDR nota
tion, and factorized quads.
The disabled and enabled attributes are meant to be lists of service names (
see the next section) that are enabled and disabled. If enabled is specified
, then any services not listed as values are considered. The same is true wi
th the disabled attribute, with the unlisted services being considered enabl
ed. Should a service be listed as a value for both enabled and disabled, the
disabled attribute overrides. These two attributes are only available in th
e defaults section.
The remaining attribute available in the defaults section is passenv. The va
lues for passenv are items in a list of environment variables from xinetd's
environment to send to the server when it gets instantiated.
With this brief intro to the defaults section complete, we'll move on to the
service sections. But never fear, we'll return to the defaults section and
its attributes later with the sample configurations.
Services sections
The services section define the individual services to be started by xinetd
and how they are to be started. Their general form is
service <servicename>
{
<attribute> <assign_op> <value> <value> ...
<anotherattribute> <assign_op> <value> <value> ...
...
}
Like the defaults section, the services sections have a number of attributes
that can be specified: type, flags, socket_type, protocol, wait, user, grou
p, instances, nice, server, server_args, only_from, no_access, access_times,
log_type, log_on_success, log_on_failure, rpc_version, rpc_number, env, pas
senv, port, redirect, bind, interface, banner, banner_success, banner_fail,
per_source, cps, max_load, and groups. That may seem like a lot, but realize
that you'll need about 7 of them to setup a basic service.
xconv.pl makes services sections that look like this:
service ftp
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/libexec/ftpd
server_args = ftpd -l
}
service telnet
{
flags = REUSE NAMEINARGS
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/libexec/telnetd
server_args = telnetd
}
xconv.pl will only translate those services in the inetd.conf that are uncom
mented, and those it does translate are set to their most basic and compatib
le mode.
The first thing you'll probably notice here are that the services sections a
re split into individual service configurations. The servicename is a unique
name for a service you wish to configure in the following section. This ser
vicename is what is used to look up the service information in /etc/services
(or equivalent).
The flags attribute can generally be left as is. The REUSE value is generall
y a good thing and should be left unless you have a specific reason to remov
e it. NAMEINARGS specifies that the first value in the server_args attribute
will be used as the first argument when starting the service specified. Thi
s is most useful when using tcpd; you would specify tcpd in the server attri
bute, and give it the service ("ftpd -l") in the server_args attribute. The
flags attribute is optional. The default configurations should work fine in
most cases.
The attributes socket_type, protocol, wait, and user attributes are all syno
nymous with their inetd counter parts. In all cases I've seen, these can be
left alone. Of these, protocol is optional.
We've already talked about server and server_args a bit. The server attribut
e is simply the full path to the server's executable, very much a required f
ield. Server_args is a list arguments to be passed to the above executable.
Though the xconv.pl application lists the server's executable name in this a
ttribute, it is not necessary, nor particularly desirable (as stated by the
xinetd man pages). However, there doesn't seem to be any specific problems w
ith leaving the attribute as xconv.pl sets it. If you wish to delete the nam
e from the attributes, remember to remove the NAMEINARGS flag from the flags
attribute as well. The server_args attribute must included in a service def
inition, even if it is left blank.
A minimally configured version of the example ftp service would look as foll
ows:
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/libexec/ftpd
server_args = -l
}
If you happen to be using rpc services, protocol, rpc_version, and rpc_numbe
r (if it's not listed in /etc/rpc or your equivalent) attributes are also ma
ndatory.
For the most part these are the attributes that are required to properly con
figure a service under xinetd. There are, however, two exceptions: if you're
running a BSD, or if the service you're configuring isn't listed in /etc/se
rvices (or equivalent). Most BSD's seem to require the addition of the group
s (groups = yes) attribute to the service configuration. If you happen to be
configuring a service that isn't in /etc/servicesport = 22, for sshd). Ther
e are some additional variations when dealing with xinetd's internal's servi
ces, but we'll discuss those later.
This is, of course, not the end of the story; we want to not only have funct
ioning services, we want to control access to these services. To this end, x
inetd provides us with a number of pertinent service attributes: instances,
nice, only_from, no_access, access_times, per_source, cps, and max_load.
Instances accepts an integer as it's value, and as noted in the previous def
aults section, specifies the maximum number of simultaneous connections to t
he particular service. As with any of these values, setting this attribute i
n the service definition should override whatever is in the defaults section
. Nice is related to the unix nice command. It takes an integer that specifi
es the services process priority. The max_load attribute accepts a floating
point value, and specifies the load at which the server will stop accepting
connections, based on a one-minute cpu load average. Due to it's OS dependen
cy, this only works on Linux and Solaris right now. Then there's the cps att
ribute, which also takes an integer and is used to rate limit (in connection
s per second) a service. The last of these quantitative limiters is the per_
source attribute. It takes an integer and set the limit on the maximum numbe
r of connections a single host may have to the specified service.
The attributes only_from and no_access are very much related too each other,
in as much as they take the same values, and are of supplimentary function.
The accept a list of ip addresses, network names (via /etc/networks or equi
valent), host/domain names (via reverse lookup), or networks (in CIDR notati
on). If both only_from and no_access are specified for a service, the best f
it match is used (ie, a host is a better match than a network, is better tha
n a network with a larger subnet). The no_access attribute takes precedence
over only_from in case of a complete duplication. If you include either attr
ibute, but leave either blank, they disallow all addresses. The last access
control attribute is access_times. This accepts time intervals in HH:MM-HH:M
M 24-hour notation. Access is granted during these intervals.
The remaining attributes have to do with logging (and have already been disc
ussed in the defaults section), and some nuances of service configuration. S
ome are covered in a later section, but for more information on these handfu
ll of attributes, I would recommend reading the man pages.
----------------------------------------------------------------------------
----
A Simple Configuration with little access control
# This is a modified and cleaned up version of a xinetd.conf
# originally created by xconv.pl.
# The defaults section sets some information for all services
defaults
{
#The maximum number of requests a particular service may handle
# at once.
instances = 25
# The type of logging. This logs to a file that is specified.
# Another option is: SYSLOG syslog_facility [syslog_level]
log_type = FILE /var/log/servicelog
# What to log when the connection succeeds.
# PID logs the pid of the server processing the request.
# HOST logs the remote host's ip address.
# USERID logs the remote user (using RFC 1413)
# EXIT logs the exit status of the server.
# DURATION logs the duration of the session.
log_on_success = HOST PID
# What to log when the connection fails. Same options as above
log_on_failure = HOST RECORD
# The maximum number of connections a specific IP address can
# have to a specific service.
per_source = 25
}
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/libexec/ftpd
server_args = -l
}
service nntp
{
socket_type = stream
wait = no
user = usenet
server = /usr/libexec/nntpd
server_args =
}
service telnet
{
socket_type = stream
wait = no
user = root
server = /usr/libexec/telnetd
server_args =
}
----------------------------------------------------------------------------
----
A More Complicated Configuration with Access Control
# This is a modified and cleaned up version of a xinetd.conf
# originally created by xconv.pl.
# The defaults section sets some information for all services
defaults
{
#The maximum number of requests a particular service may handle
# at once.
instances = 25
# The type of logging. This logs to a file that is specified.
# Another option is: SYSLOG syslog_facility [syslog_level]
log_type = FILE /var/log/servicelog
# What to log when the connection succeeds.
# PID logs the pid of the server processing the request.
# HOST logs the remote host's ip address.
# USERID logs the remote user (using RFC 1413)
# EXIT logs the exit status of the server.
# DURATION logs the duration of the session.
log_on_success = HOST PID
# What to log when the connection fails. Same options as above
log_on_failure = HOST RECORD
# The maximum number of connections a specific IP address can
# have to a specific service.
per_source = 25
# Disabled nntp
disabled = nntp
#Whatever you do, don't let the evil bastards in
no_access = .evilbastards.com
}
service ftp
{
socket_type = stream
wait = no
user = root
server = /usr/libexec/ftpd
server_args = -l
#Allow access from the local network (ie, 192.168.0.0/24)
only_from = 192.168.0.0/24
#And from two remote locations
only_from = 10.1.1.2 roadwarrior.sampleconfig.com
#But not from the evil HR director's subnet
no_access = 192.168.0.128/27
log_on_success = PID HOST EXIT DURATION
log_on_failure = ATTEMPT HOST RECORD
}
service nntp
{
socket_type = stream
wait = no
user = usenet
server = /usr/libexec/nntpd
server_args =
#Allow access from the local network (ie, 192.168.0.0/24)
only_from = 192.168.0.0/24
#And only during working hours
access_times = 08:00-17:00
#And only 5 people at a time
instances = 5
#And only 5 connections per second
cps = 5
#And not under load
max_load = 2.9
#And be low priority
nice = 15
}
service ssh
{
socket_type = stream
wait = no
user = root
server = /usr/libexec/sshd
#It's not listed in my /etc/services
port = 22
server_args = -i
#Allow access from the local network (ie, 192.168.0.0/24)
only_from = 192.168.0.0/24
#And from two remote locations
only_from = 10.1.1.2 roadwarrior.sampleconfig.com
log_on_failure = ATTEMPT HOST RECORD
}
----------------------------------------------------------------------------
----
Day to day use of xinetd (or updating the xinetd.conf)
In the life of every service comes a day when it must be reconfigured for so
me reason. Sometimes it's because you've installed another service, or wish
to enable one that's been previously disabled, or may you've got an evil bas
tard trying to beat your imap server to dust. Whatever the reason, it is gen
erally disadvantageous to have to kill all the processes that xinetd has sta
rted to bring up a new configuration, especially on a busy server. Fortunate
ly, the xinetd coders gave us a way around this. To bring up a new configura
tion, make your modifications to xinetd.conf (after making a backup copy of
it, of course). Then find the PID for xinetd (ps -aux | grep xinetd). With t
he xinetd PID in hand, use the kill command to send it a SIGUSR1 or SIGUSR2
signal (kill -USR1 <pid>). Sending it SIGUSR1 will cause a soft reconfigurat
ion, meaning that it reads the new config and all new connections are applie
d against it. If a SIGUSR2 is sent (kill -USR2 <pid>), a hard reconfiguratio
n occurs. This means that not only will the new config be read in, it will b
e applied immediately; any access controls are applied instantly, as well as
any connection throttles. This allows you to immediately kick an evil basta
rd off one of your servers, or disable a flagging service. One should note,
however, if current connections are beyond the bounds of connection throttli
ng settings in the new config when a SIGUSR2 is sent, random connections wil
l be kicked to bring the rate/instances within acceptable parameters.
----------------------------------------------------------------------------
----
Port redirection
Amazingly enough, the folks that coded xinetd, have added the ability to red
irect ports. That is, you can accept a connection on a port, and redirect th
at connection to another port, even on another host. This is especially usef
ul in a situation where the machine running xinetd is a firewall, or router.
Usually this means the machine has multiple nics in it, each with it's own
IP address and subnet. Using port redirection, an machine could accept a tel
net session on port 23 of the router/firewall machine and redirect it to por
t 23 of one of the internal hosts. The service definition to do this would l
ook like the following:
service telnet
{
flags = REUSE
socket_type = stream
protocol = tcp
wait = no
user = root
groups = yes
bind = 10.1.1.1
redirect = 192.168.0.3 23
}
There are a number of things to notice here. There are two new attributes: b
ind, and redirect. The redirect attribute accepts an ip address (as it is he
re), or a hostname, followed by a port number. The port number specified nee
d not be the same as that of the service (in other words you could just as e
asily accept connections via telnet and redirect them to port 80, being http
, on some host). One can also redirect to a port on the same machine as that
it is being redirected from. The other new attribute is bind. This tells xi
netd that this service/rule is bound to the interface with the specified ip.
In the above scenario, it is likely that there are two or more nics in the
machine, one of which has a configured ip of 10.1.1.1, and the other with an
address on the same network (or has some access to) as the host 192.168.0.3
. The bind attribute is by no means required; it is only shown here because
this is a common configuration and use for the redirect attribute.
----------------------------------------------------------------------------
----
Additional info for Mac OS X (Server)
What follows are instruction specifically for users of Mac OS X (Server and
Client). As the OS is new, and currently in a state of flux, consider these
instrustions as a helpful guide which may be subtley flawed for now. As the
OS continues towards release, and we become more familiar with it, we will u
pdate this section accordingly. If you have suggestions, or find errors, ple
ase feel free to share .
There are differences in the installation of xinetd on Mac OS X Server 1.x a
nd Mac OS X. When these differences are apparent, it will be so noted. Other
unix installs will be similar to MOSX(S), except the startup methods, and t
heir mileage will vary.
Everything that follows needs to be done as root to function as indicated.
Some filenames and paths may need to be changed to protect the innocent.
The compile and install
Download the source to a convenient directory (ie /usr/local/src/).
Decompress the archive and copy the necessary config files from /usr/libexec
∶
tar xzvf xinetd-N.N.N.N.tar.gz
cd xinetd-N.N.N.N/
cp /usr/libexec/config.* ./
Then download the necessary patch from Macsecurity and place it in the xinet
d-N.N.N.N directory.
Then do the following:
cd /path/to/xinetd-N.N.N.N
tar zxvf xinetd-N.N.N.N-osx.patch.tar.gz
patch -p 1 -l < xinetd-N.N.N.N-osx.patch
The next thing to do is run ./configure with whatever options you'd like (li
bwrap support, different command paths). If compiling with libwrap support,
see the section of tutorial called "Compiling with libwrap support". Typical
for MOSX(S):
./configure --sbindir=/usr/sbin --mandir=/usr/share/man
Hopefully this will proceed with no errors. Assuming this is so, you need to
make two minor modifications to two Makefiles. You'll want to do these modi
fications with vi, as pico has a tendency to chop long lines in a way that b
reaks the Makefiles.
In /path/to/xinetd-N.N.N.N/Makefile find a line that starts out "CFLAGS =" a
nd insert "-traditional-cpp" into the list of arguments. Then, find a sectio
n that begins with makelibs: Append a line after that which contains ; done.
Type in $(RANLIB) libs/lib/*.a
This section should now look as follows:
makelibs:
for lib in $(MANDATORY_LIBS) ; do \
( cd libs/src/$$lib ; make install "INSTALL=$(INSTALL_CMD)"
"DEFS=$(LIB_DEFS)" RANLIB=true "CC=$(CC)" DEBUG=-O ) \
; done
$(RANLIB) libs/lib/*.a
In /path/to/xinetd-N.N.N.N/xinetd/Makefile again find the "CFLAGS =" line, a
nd add "-traditional-cpp" to the list of arguments.
Follow this up with the following in /path/to/xinetd-N.N.N.N/:
make
make install
xinetd is now installed. All that remains is to configure it, and that has a
lready been discussed at length in this document. Once you think you have a
good xinetd.conf file created and in place, it is suggested that you run xin
etd from the command line with the '-d' debug flag. This will help you great
ly in solving any problems that may arise. Also, remember to add the "groups
= yes" attribute to each service definition.
Starting the daemon at startup
Most admins will want to start xinetd from startup. Here again, there is a d
ifference between Mac OS X Server, and Mac OS X.
In Mac OS X Server, there are a few ways to do this. One way is to edit the
/etc/1700_IPServices file and add a line for xinetd (look at the lines for i
netd for a clue on how to proceed). It is possible to run both inetd and xin
etd at the same time, though both may not run the same services (FIFO).
In Mac OS X, the way to do it, is to create a StartupItem for xinetd. To do
this follow these directions:
cd /System/Library/StartupItems
cp -R IPServices SecureIPServices
cd SecureIPServices
mv IPServices SecureIPServices
Edit the file SecureIPServices. Delete everything after 'ConsoleMessage "Sta
rting TCP/IP services"'. Modify the remaining text to appear as follows, tak
ing care that the stated paths are the actual paths to the specified file(s)
.
##
# Run the Internet super-server.
##
. /etc/rc.common
ConsoleMessage "Starting Secure TCP/IP services"
/usr/local/sbin/xinetd
Edit StartupParameters.plist to look like the following:
{
Description = "Secure Internet services";
Provides = ("SecureSuperServer"
);
Requires = ("Resolver");
Uses = ("NetworkTime");
OrderPreference = "None";
Messages =
{
start = "Starting secure internet services";
stop = "Stopping secure internet services";
};
}
That's it. Xinetd will now startup at boot time.
Compiling with libwrap support
If you're compiling with libwrap (./configure --with-libwrap) support, then
you'll need to make sure the necessary libraries are installed in there prop
er place(s). Look for tcpd.h in /usr/include or /usr/local/include, and libw
rap.a in /usr/lib or /usr/local/lib; if they're not there, you'll need to ge
t them there. How you do this differs between the two versions of Mac OS X.
For Mac OS X Server, follow these directions (excerpted from Joshua Marker's
article on installing SSH1 on Mac OS X server on Stepwise):
cd /System/Developer/Source/Commands/tcp_wrappers/
make RC_ARCHS=ppc install
mkdir -p /usr/local/lib
mkdir -p /usr/local/include
cp /tmp/tcp_wrappers/Release/usr/local/lib/libwrap.a \
/usr/local/lib/libwrap.a
ranlib /usr/local/lib/libwrap.a
cp /System/Developer/Source/Commands/tcp_wrappers/tcp_wrappers/tcpd.h \
/usr/local/include/
For Mac OS X, these are the directions (excerpted from Joshua Marker's artic
le on installing SSH1 on Mac OS X on Stepwise):
wget ftp://ftp.stepwise.com/pub/macosx/unix/tcp_wrappers-7.6-4.tar.gz
gnutar -xzf tcp_wrappers-7.6-4.tar.gz
cd tcp_wrappers-4
make RC_ARCHS=ppc install
mkdir -p /usr/local/lib
mkdir -p /usr/local/include
cp /tmp/tcp_wrappers/Release/usr/local/lib/libwrap.a \
/usr/local/lib/libwrap.a
ranlib /usr/local/lib/libwrap.a
cp tcp_wrappers/tcpd.h \
/usr/local/include/
Beware that if the xinetd configure scripts do not find the files, and you'v
e compiled with libwrap support, xinetd will not function properly. Remember
to test functionality before relying upon the new daemon.
----------------------------------------------------------------------------
----
Parting words
While we have gone through many of the available options, configurations, an
d features of xinetd, not all options are represented, or fully explained. F
or further information, see "man xinetd.conf" and "man xinetd". If you need
further help, seek out the authors of xinetd, and join the xinetd mailing li
st.
Top Stories
Mac OS X a Brickhouse?
Using IPFW on Mac OS X Public Beta
Where Have We Been
?
--
整天吃不够，蚊子也是肉
※ 来源:·BBS 水木清华站 smth.org·[FROM: 162.105.16.253]
BBS水木清华站∶精华区