The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Xinetd services fail fail fail!

Discussion in 'General Discussion' started by ozzi4648, Jan 5, 2003.

  1. ozzi4648

    ozzi4648 Guest

    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.
     
  2. ozzi4648

    ozzi4648 Guest

    [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.

    :p
     
  3. ecoutez

    ecoutez Well-Known Member

    Joined:
    May 23, 2002
    Messages:
    152
    Likes Received:
    0
    Trophy Points:
    0
    FWIW...

    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
     
  4. ozzi4648

    ozzi4648 Guest

    [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!
     
Loading...

Share This Page