Need to be active 'xinetd' using Dovecot?

[redesb]

Until now I have xinetd enabled because I use one old DA version but after I move to new one (1.33.1) with Dovecot I'am thinking on disable xinetd. But before doing something wrong, better ask if there is any problem.

1 - Need to be enabled 'xinetd' using 'Dovecot'?
2 - There is any dependence I unknown?
3 - Is safe to disable it?

TIA
Ramon

 

[GXX]

You do not need xinetd to run Dovecot.

 

[tillo]

There is no DA-related service running through xinetd as far as I know.

To see which services is xinetd serving right now, run "netstat -pln |grep xinetd".
If there is no output, you can safely remove xinetd.

 

[redesb]

Hi,

Thanks 'GXX' and Martino for quickly replies. I do a little research (google ) and the conclusion is 'xinetd not needed', at least, running the default new DA.

Until here all right, but why is then installed 'xinetd' when running 'CustomBuild'? I don't installed it on the base minimal CentOS 5.2 kickstart install, and after run 'CustomBuild' I see it installed and enabled. And before someone ask..., I select 'dovecot' not 'vm-pop3' on 'CustomBuild' install.

TIA
Ramon

 

[tillo]

CustomBuild doesn't install xinetd, but I've seen many trojan and rootkits hide themselfs as xinetd because it's installed by default in many distributions.
I don't want to scare you, but you should check the security of your system.

 

[redesb]

CustomBuild doesn't install xinetd,...

You are right Martino, sorry for the mistake, but I'am sure the base install don't install 'xinetd'. And after read all the 'build' script, also sure that 'CustomBuild' has not installed it. But if not 'CustomBuild' need to be DA install due dependencies because 'yum.log' say 'xinetd' was installed 3 minutes after launch the DA 'setup.sh'. Maybe need to send a msg. to support to be sure. I don't know... But I have disabled xinetd without problem.

...but I've seen many trojan and rootkits hide themselfs as xinetd because it's installed by default in many distributions.
I don't want to scare you, but you should check the security of your system.

I am glad not to be the only security paranoid... But same problem on the test bed server accepting only SSH access from my static ip address. But out of doubt I verified the MD5 sum of 'xinetd' on production server and is correct.

 

[tillo]

Well, only DA people can tell you why xinetd has been installed. As you say, probably an optional opt-out dependency... on my Debian systems the DA setup.sh script didn't install it.

I'm also glad I'm not the only one. More people like us, and we would have much less botnets around

 

[nobaloney]

Here's my understanding on xinetd (still inetd on certain distributions):

First of all, here's what xinetd is all about:

It's a superdaemon which listens on certain ports and starts the daemon that's supposed to run on that port (but not as a persistent daemon, only as one instance to handle one request) when a request comes in for a service on that port.

Years ago this was important on a lot of systems, because memory constraints and slow processes made it unwise to run lots of daemons waiting for requests.

Today some VPS configurations may still work better with xinetd, because of said memory constraints.

Since I'm not running any VPS licenses right now I don't know if DirectAdmin automatically sets up xinetd for VPS licenses, but I don't think so.

I can't see anything DirectAdmin does which would require xinetd to run. Certainly Dovecot is controlled by DirectAdmin through the Services control panel; therefore it does NOT require xinetd.

Hopefully John, Martynas, or both, will respond to this thread.

Jeff

 

[redesb]

Hi Jeff,

Here's my understanding on xinetd (still inetd on certain distributions):

First of all, here's what xinetd is all about:

It's a superdaemon which listens on certain ports and starts the daemon that's supposed to run on that port (but not as a persistent daemon, only as one instance to handle one request) when a request comes in for a service on that port.

Years ago this was important on a lot of systems, because memory constraints and slow processes made it unwise to run lots of daemons waiting for requests.

Today some VPS configurations may still work better with xinetd, because of said memory constraints.

Thanks for refreshing our memory.

Since I'm not running any VPS licenses right now I don't know if DirectAdmin automatically sets up xinetd for VPS licenses, but I don't think so.

VPS licenses? I don't know the VPS licenses, sure I'm a bit outdated, need to do 'yum brain-update' more often...

But not the problem, I'm using a 'Lifetime' license on a minimal CentOS 5.2 without xinetd in the kickstart script.

I can't see anything DirectAdmin does which would require xinetd to run. Certainly Dovecot is controlled by DirectAdmin through the Services control panel; therefore it does NOT require xinetd.

Hopefully John, Martynas, or both, will respond to this thread.

Jeff

I think I found the problem, but solution is difficult. The installation file "install.sh" on lines 190 to 194 do the installation of 'xinetd', but only if you use one RedHat or RH like (CentOS) distro.

if [ -e /etc/redhat-release ] && [ ! -e /etc/init.d/xinetd ] && [ -e /usr/bin/yum ]; then
        yum -y install xinetd
        /sbin/chkconfig xinetd on
        /sbin/service xinetd start
fi

John and Martynas, are working hard on new versions of the control panel and am very grateful, but in my view, begins to be necessary to update a little the base install. Although it is only my opinion and in no case a criticism.

Ramon

 

[DirectAdmin Support]

Hello,

xinetd was installed to get imapd working for vm-pop3d installs.
xinetd is also reloaded after removing xinetd.d files for conflicting services (pop, imap, ftp mainly). Only matters if xinetd is running already.

But with custombuild, it doesn't need to be there. I'll add a check for the options.conf file, and it will skip the yum install of xinetd if the options.conf is present (for the next release).

John