Xinetd services fail fail fail!

[ozzi4648]

I have tested this on 2 cpanel boxes i own including on someones elses box running a totally different version of the OS and xinetd still fails miserably. When is this going to be fixed?

Jan 5 20:23:12 srv04 xinetd[7370]: Error parsing attribute server - DISABLING SERVICE [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Server in.qpopper is not executable [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Error parsing attribute server - DISABLING SERVICE [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Server in.talkd is not executable [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Error parsing attribute server - DISABLING SERVICE [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Server in.telnetd is not executable [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Error parsing attribute server - DISABLING SERVICE [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: xinetd Version 2.3.7 started with libwrap options compiled in.
Jan 5 20:23:12 srv04 xinetd[7370]: Started working: 1 available service

Included in this is telnet. No way to connect to a box using telnet. It fails evertime because of the above. So your asking why on earth would one want to enable telnet. Lots of reasons. Anyone who has half a brain would realize that at times telnet is an absolutely necessary service to open especially when one wants to upgrade openSSH, which is not the latest version anyway, you want to have another way of getting into your box incase the Openssh upgrade, installation, hack, patch goes horribly wrong. I am certainly in the running to patch openssh from source that includes the fix to include a chrooted environment. The way that openssh works on cpanel right now is just security hole in itself.

Can you have this fixed please? The latest E release does not correct the problem and even with portsenty OFF and disabled it will not restart the xinetd services.

[ozzi4648]

[quote:7902a3810b][i:7902a3810b]Originally posted by ozzi4648[/i:7902a3810b]

Jan 5 20:23:12 srv04 xinetd[7370]: Error parsing attribute server - DISABLING SERVICE [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Server in.qpopper is not executable [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Error parsing attribute server - DISABLING SERVICE [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Server in.talkd is not executable [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Error parsing attribute server - DISABLING SERVICE [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Server in.telnetd is not executable [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: Error parsing attribute server - DISABLING SERVICE [line=8]
Jan 5 20:23:12 srv04 xinetd[7370]: xinetd Version 2.3.7 started with libwrap options compiled in.
Jan 5 20:23:12 srv04 xinetd[7370]: Started working: 1 available service
[/quote:7902a3810b]

[b:7902a3810b]Xinetd Error Msg Fix[/b:7902a3810b]

Since nobody replied to my trouble ticket i took it upon myself to fix this error and post it here myself.

The error is really annoying. Anyone restarting xinetd.d by typing /etc/rc.d/init.d/xinetd restart would see the error msgs above appearing and would think there was something majorly wrong with their services. You can fix the following very easily while still keeping telnet, ntalk, talk, finger turned off. There is no reason why the path to the daemons should be removed from these services because by simply saying the service is OFF is good enough to keep anyone from logging into your system. Also, you are running a firewall aren't you? Firewalls will also restrict access to these services. So you have double security. Because the path is removed from these files, not very sensible, the error msgs, above, will appear evertime your server reboots or you restart xinetd.

Fix it by making the changes below then restart xinetd:

cd /etc/xinetd.d

pico telnet
change the line that says:
server = in.telnetd
to
server = /usr/sbin/in.telnetd
make sure disable = yes
save, exit

pico ntalk
change the lins that says:
server = in.ntalkd
to
server = /usr/sbin/in.ntalkd
make sure disable = yes
save, exit

pico pop-3
change the line that says:
server = in.qpopper
to
server = /usr/sbin/in.qpoper
make sure disable = yes
save, exit

Leave cpimap alone! It's for your imap daemon

If you see any other file this directory open it
up and check for the absense of the server path.

All done!

/etc/rc.d/init.d/xinetd restart

Your services should now restart clean, without any warnings in /var/log/messages.

[ecoutez]

You don't need telnet to upgrade OpenSSH. I generally open telnet while I'm doing an upgrade, but have never had to use it. When you issue a restart of OpenSSH while logged in via SSH, your connection does not drop.

CPanel's installed version of OpenSSH is perfectly fine. RedHat generally applies patches to older versions which have been tested rather than upgrade to newer and less tested versions. In the case of OpenSSH, this was a brilliant choice because the upgrades were a lot more problematic than the patches.

- Jason

[ozzi4648]

[quote:99e2426f95][i:99e2426f95]Originally posted by ecoutez[/i:99e2426f95]

You don't need telnet to upgrade OpenSSH. I generally open telnet while I'm doing an upgrade, but have never had to use it. When you issue a restart of OpenSSH while logged in via SSH, your connection does not drop.[/quote:99e2426f95]

I said opening telnet to upgrade OpenSSH is highly recommended. Im not talking about just upgrading using rpm. Upgrading from RPM is the easy part. I'm talking about compiling from source. After you recompile Openssh you need to move a few files from one place to another including sshd.init -& sshd in /etc/rc.d/init.d/ etc. If you forget this and you attempt to restart openssh your connection will drop and you will be completely locked out of your server, just as an example!