Yikes! What happened to inetd.conf in RH 7.1?

[Landruu]

I checked xinetd.conf, but this is all that is there.
#
# Simple configuration file for xinetd
#
# Some defaults, and include /etc/xinetd.d/

defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
}

includedir /etc/xinetd.d

I need to see if pop3 and http are runing etc.

Thanks

[Craig McPherson]

Inetd sucks, Xinetd is awesome. I've been using it for two years. Give it a try, you'll like it.

See this line:

includedir /etc/xinetd.d

That causes all the files in the /etc/xinetd.d directory to be treated as if they were part of the xinetd.conf file.

[Craig McPherson]

Here's a sample of my xinetd.conf, just to give you an idea of how it works. And yes, these services are firewalled off from the outside.


service telnet
{
socket_type = stream
protocol = tcp
wait = no
user = telnetd
group = telnetd
server = /usr/sbin/in.telnetd
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 10
banner_fail = /etc/overload.txt
}

service ftp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/proftpd
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 10
banner_fail = /etc/overload.txt
}

service talk
{
socket_type = dgram
protocol = udp
wait = yes
user = nobody
group = tty
server = /usr/sbin/in.talkd
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service ntalk
{
socket_type = dgram
protocol = udp
wait = yes
user = nobody
group = tty
server = /usr/sbin/in.ntalkd
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service smtp
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/exim
server_args = -bs
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instaces = 5
banner_fail = /etc/overload.txt
}

service ssh
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/sshd
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 20
banner_fail = /etc/overload.txt
server_args = -i
}

service echo
{
socket_type = stream
protocol = tcp
wait = no
user = root
type = INTERNAL
id = echo-stream
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service echo
{
socket_type = dgram
protocol = udp
wait = yes
user = root
type = INTERNAL
id = echo-dgram
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service chargen
{
socket_type = stream
protocol = tcp
wait = no
user = root
type = INTERNAL
id = chargen-stream
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service chargen
{
socket_type = dgram
protocol = udp
wait = yes
user = root
type = INTERNAL
id = chargen-dgram
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service discard
{
socket_type = stream
protocol = tcp
wait = no
user = root
type = INTERNAL
id = discard-stream
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}


service discard
{
socket_type = dgram
protocol = udp
wait = yes
user = root
type = INTERNAL
id = discard-dgram
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service daytime
{
socket_type = stream
protocol = tcp
wait = no
user = root
type = INTERNAL
id = daytime-stream
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}


service daytime
{
socket_type = dgram
protocol = udp
wait = yes
user = root
type = INTERNAL
id = daytime-dgram
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service time
{
socket_type = stream
protocol = tcp
wait = no
user = root
type = INTERNAL
id = time-stream
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service time
{
socket_type = dgram
protocol = udp
wait = yes
user = root
type = INTERNAL
id = time-dgram
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service servers
{
socket_type = stream
protocol = tcp
port = 476
wait = no
user = root
type = INTERNAL
id = servers-stream
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 50
instances = 5
banner_fail = /etc/overload.txt
}

service services
{
socket_type = stream
protocol = tcp
port = 477
wait = no
user = root
type = INTERNAL
id = services-stream
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 50
instances = 5
banner_fail = /etc/overload.txt
}

service xadmin-stream
{
socket_type = stream
protocol = tcp
port = 478
wait = no
user = root
type = INTERNAL
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 50
instances = 5
banner_fail = /etc/overload.txt
}

service pop3s
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/ipop3d
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}

service pop3
{
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/ipop3d
log_on_success = HOST DURATION
log_on_failure = HOST
cps = 3 30
instances = 5
banner_fail = /etc/overload.txt
}


See the xinetd manpage if you need more help.

[HTTP-404]

i adgree that inetd sux, i like the way xintd looks

[trekker]

Originally posted by Craig McPherson:
<STRONG>
includedir /etc/xinetd.d

That causes all the files in the /etc/xinetd.d directory to be treated as if they were part of the xinetd.conf file.</STRONG>

Hi Craig, I have not done this before. What are the advantages of doing this. Does that mean I can just edit xinetd.conf and it will take effect as though I edited the individual files in /etc/xinetd.d?

[Craig McPherson]

It's called "run-parts"-style configuration.

It basically works like this:

1. The program starts up, and reads in its main configuration file.

2. It reads all the files in the run-parts directory and mentally "pastes" them into the main configuration file.

3. It runs using the large configuration file you just created.

I don't really see a need for it when it comes to xinetd, although I guess it could be easier to maintain the config file if it's seperate parts if you have a very large config file like I posted above. You could put each service in a seperate file, or put all the udp services in one file and all the tcp services in another file, or whatever.

Logcheck uses run-parts-style configuration now, and that works really well. You can have all your logcheck rules for Cron in one file, all the rules for Exim in another file, etc. It's a lot easier to maintain than having one large flat text file.

[Landruu]

Maybee this cold is messing with my head. But I still don't know where to goto turn on or off things like finger, ftp, http etc.

[Craig McPherson]

The main xinetd configuration file (which some distros might not use anymore, if they've switched over solely to the xinetd.d directory) is /etc/xinetd.conf. All the files found in the /etc/xinetd.d directory are treated as if they were part of the main configuration file.

So the contents of the main configuration file PLUS the contents of every file in /etc/xinetd.d is the sum total configuration file that xinetd will actually use.

[Landruu]

Ok, this is startingto make more sense. But I cannot seam to get the web server going.

I edited the file /etc/xinetd.d/linuxconf-web
I canged disable to
disable = no

Still not having any luck here. but thanks for the help so far.

[Craig McPherson]

Remove the "disable" line entirely.

I don't think it's a boolean setting: if "disable" is there, it's disabled, no matter if you have "= no" after it.

Also, remember you have to restart xinetd after making a change to one of the config files or the change won't take affect.

[Landruu]

COOL!!
Now for your final question! how do I restart services under 7.1? I triedthe usuall. but got permission denied errors.

[Craig McPherson]

What are you trying to do?

If you need to restart xinetd, you do this as root:

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

[Landruu]

[root@knightmare /root]# &gt; /etc/rc.d/init.d/xinetd restart
bash: restart: command not found
[root@knightmare /root]#

I am going to be tinkering with pop3 smtp and http. I will need to be restarting them. but I cannot figure out how.

[Craig McPherson]

Originally posted by Landruu:
<STRONG>[root@knightmare /root]# &gt; /etc/rc.d/init.d/xinetd restart
bash: restart: command not found
[root@knightmare /root]# </STRONG>

There's no "&gt;" in there.