README

   1 xinetd is a powerful replacement for inetd.
   2 Original site: http://www.xinetd.org
   3 xinetd has access control mechanisms, extensive logging capabilities,
   4 the ability to make services available based on time, can place
   5 limits on the number of servers that can be started, and has deployable
   6 defence mechanisms to protect against port scanners, among other things.
   7
   8 There are a number of differences between xinetd and inetd.  The
   9 largest difference to the end user is the config file.  xinetd's
  10 config file format is more C like, and somewhat similar to bind 8's.
  11
  12 *** NOTE ***
  13 xinetd's reconfig signal is now SIGHUP.  SIGUSR2 still works for now,
  14 but should be considered deprecated.  The state dump signal is now
  15 SIGUSR1.
  16 ***      ***
  17
  18 There are a couple of compile time options to xinetd:
  19 --------------------------------------------------------------------------
  20
  21 --with-libwrap  : This option to the configure script tells xinetd
  22 to compile in support for tcp wrappers.  You must already have libwrap
  23 installed on your system.  This option will have xinetd pay attention
  24 to your /etc/hosts.{allow|deny} files.  With this option turned on,
  25 xinetd will first look at your /etc/hosts.{allow|deny} files, then
  26 if access is granted, it goes through xinetd's internal access control
  27 mechanisms.  Note that xinetd passes the server name if there is one,
  28 otherwise it uses the service id, *not* the service name to libwrap -
  29 this is a change from previous behaviour.
  30
  31 --with-loadavg  : This option to the configure script tells xinetd
  32 to compile in support for the max_load configuration option.  This
  33 option allows you to have certain services disabled when the system
  34 load gets above a specified level.  This is highly operating system
  35 specific.  It currently has been tested on linux, and there is
  36 developmental support for solaris 2.6 and higher.
  37
  38 --with-inet6    : Services default to IPv6 (PF_INET6) sockets.
  39 Now that IPv6 support is fully integrated into xinetd, this option
  40 is almost meaningless.  IPv6 sockets are available with the "IPv6"
  41 service flag, even without this option.
  42
  43 --with-howl=PATH: Adds howl mdns advertising support to xinetd.
  44 PATH is the prefix where howl is installed, such as /usr/local,
  45 /usr, etc.  PATH is not optional.  configure will not automatically
  46 detect howl's installed location.
  47
  48 Access Control:
  49 --------------------------------------------------------------------------
  50 As of xinetd 2.1.8.8pre3 there is a change in the handling of
  51 names specified in the access control directives, only_from and
  52 no_access.  For numerical entries in these fields, nothing has
  53 changed.
  54
  55 The way it used to be:  When xinetd started, it would lookup the
  56 name(s) specified.  It would then collect all the IP addresses
  57 associated with that name, and store them in the access control
  58 lists.  This led to problems of acls being out of date, and
  59 access controls being messed up when names were specified.  It did
  60 have the advantage of not waiting for a lookup to happen when you
  61 connected.
  62
  63 The way it is now:  xinetd keeps all the names you specify on the
  64 access control directives.  When a client attempts to connect to
  65 a service, a reverse lookup is performed on the client's IP address.
  66 The canonical name returned is compared with the specified names.
  67 If the first character of the name being specified in the config
  68 file is a '.', then all hosts within that domain are matched.
  69 For example, if I put .synack.net, all hosts with a reverse mapping
  70 that are in .synack.net domain, are matched.
  71
  72 libwrap support:
  73 ----------------------------------------------------------------------
  74 For libwrap access control, the access control is done by the
  75 server name for the service.  So, if you have an entry like this:
  76 service telnet
  77 {
  78      ...
  79          server = /usr/sbin/in.telnetd
  80          ...
  81 }
  82 Your corresponding hosts.{allow|deny} entry would look something
  83 like this:
  84 in.telnetd: ALL
  85
  86 However, many services don't have a "server".  Internal services
  87 and redirection services don't have a "server" line in the configuration
  88 file.  For these services, the service name is used.  For example:
  89 server telnet
  90 {
  91         ...
  92         redirect = 10.0.0.1 23
  93         ...
  94 }
  95 Your hosts.{allow|deny} entry would look something like this:
  96 telnet: ALL
  97
  98 So, in general, if a service has a "server" attribute to it, access
  99 control is performed based on that entry.  If a service does not have
 100 a "server" attribute, (internal and redirection services) then access
 101 control is based on the service name.
 102 This is only for libwrap access control.
 103
 104 itox:
 105 --------------------------------------------------------------------------
 106 I will continue to keep itox in the distribution, and fix any bugs or
 107 compatibility issues that come to my attention, but I probably won't
 108 get around to adding features.  If someone else would like to pick this
 109 up, let me know and I'd be happy to incorporate changes.
 110 I have made a quick perl script (xconv.pl) to replace itox.  xconv.pl
 111 does a straight translation of inetd.conf file syntax to xinetd.conf.
 112 It handles tcpd correctly, warns on the use of rpc services,
 113 sets the REUSE flag, and handles groups properly if your inetd.conf file
 114 supports them.
 115
 116 xinetd was originally written by panos@cs.colorado.edu.  At least one other
 117 version of xinetd has been seen floating around the net.  This version is
 118 being maintained by Rob Braun (bbraun@synack.net) and bug reports for this
 119 version should be directed there.
 120
 121 Known bugs: On some BSD's, you may need to set 'groups = yes' in your services.
 122 If you need this, and you don't specify 'groups = yes', you'll get a log
 123 message telling you it is needed, when you connect to a service.
 124
 125 Bug reports/comments/suggestions/flames for this version should be sent
 126 to bbraun@synack.net