You are not logged in.

#1 2003-09-23 01:48:12

kakabaratruskia
Member
From: Santiago, Chile
Registered: 2003-08-24
Posts: 596

Why should I use xinetd?

Im using inetd, but in mandrake I had xinetd, and somewhere I had read that it is better. Is this true?, and if so, ahow do I install it, cause it's not in pacman (i know I cant install it from source, but I wonder if it's hidden somewhere in the distro)


And where were all the sportsmen who always pulled you though?
They're all resting down in Cornwall
writing up their memoirs for a paper-back edition
of the Boy Scout Manual.

Offline

#2 2003-09-23 15:15:26

sarah31
Member
From: Middle of Canada
Registered: 2002-08-20
Posts: 2,975
Website

Re: Why should I use xinetd?

plans are to move to xinetd. however i don't know when this will happen.


AKA uknowme

I am not your friend

Offline

#3 2003-09-23 16:07:08

marin_linuxer
Member
From: San Rafael, CA U.S.A.
Registered: 2003-09-03
Posts: 111
Website

Re: Why should I use xinetd?

http://www.xinetd.org/faq.html


Q. What is xinetd ?
A. xinetd is a replacement for inetd, the internet services daemon.

Q: I am not a system administrator; what do I care about an inetd replacement ?
A: xinetd is not just an inetd replacement. Anybody can use it to start servers that don't require privileged ports because xinetd does not require that the services in its configuration file be listed in /etc/services.

Q. Is it compatible with inetd ?
A. No, its configuration file has a different format than inetd's one and it understands different signals. However the signal-to-action assignment can be changed and a program has been included to convert inetd.conf to xinetd.conf.


Q. Why should I use it ?
A. Because it is a lot better (IMHO) than inetd. Here are the reasons:


1) It can do access control on all services based on:
     a. address of remote host
     b. time of access
     c. name of remote host
     d. domain name of remote host
2) Access control works on all services, whether multi-threaded or single-threaded and for both the TCP and UDP protocols. All UDP packets can be checked as well as all TCP connections.
3) It provides hard reconfiguration:
     a. kills servers for services that are no longer in the configuration file
     b. kills servers that no longer meet the access control criteria
4) It can prevent denial-of-access attacks by
     a. placing limits on the number of servers for each service (avoids process table overflows)
     b. placing an upper bound on the number of processes it will fork
     c. placing limits on the size of log files it creates
     d. placing limits on the number of connection a single host can initiate
     e. place limits on the rate of incoming connections
     f. discontinue services if the load exceeds specified limit
5) Extensive logging abilities:
     a. for every server started it can log:
          i) the time when the server was started
          ii) the remote host address
          iii) who was the remote user (if the other end runs a RFC-931/RFC-1413 server)
          iv) how long the server was running
          (i, ii and iii can be logged for failed attempts too).
     b. for some services, if the access control fails, it can log information about the attempted access (for example, it can log the user name and command for the rsh service)
6) No limit on number of server arguments
7) You can bind specifc services to specific IP's on your host machine


-- Linux!  Isn't it time?

Offline

Board footer

Powered by FluxBB