Sponsored Content
Full Discussion: xinetd.conf
Special Forums Cybersecurity xinetd.conf Post 13626 by Neo on Monday 21st of January 2002 01:23:52 PM
Old 01-21-2002
Many people use xinetd vs. inetd because xinetd has a few more features. However, lots of folks (including me) are doing just fine with inetd ..... You may use either one or the other (not both)....
 

10 More Discussions You Might Find Interesting

1. Linux

uninstall xinetd

hey, haha it's me agian, i think that my xinetd is messed up, i am unable to stop it. I can start it though...lol. I just wonderd how can i uninstall it so i can reinstall it...maybe this time it'll work. I'm running RH 7.1 i think. thanks:) (5 Replies)
Discussion started by: byblyk
5 Replies

2. Linux

Requiste for starting service xinetd

hi... i am trying to find out the services which should be started before the service xinetd can be started. I have read thru the /etc/rc.d/init.d script and i think xinetd depends on service network as it checks whether the variable NETWORKING is set or not || exit 0 Does it... (0 Replies)
Discussion started by: tuxfood
0 Replies

3. UNIX for Advanced & Expert Users

Configuring snmpd.conf and snmptrapd.conf

HI, I want a help for Configuring snmpd.conf and snmptrapd.conf (i.e Configuring SNMP) for receiving TRAPS in my networks. I am using RHEL4.0 OS. Please tell me How I can configure above two files in a proper way and at an advanced level. Especially I am getting... (2 Replies)
Discussion started by: jagdish.machhi@
2 Replies

4. Linux

xinetd @system reboot

Hi, Once again I came to get rescued in a situation where one of my workstations has this ierd thing that "xinetd" won't start at reboot or shutdown. I have done the follwoing but no change in results. chkconfig --list xinetd xinetd 0:off 1:off 2:on 3:on 4:on 5:on ... (2 Replies)
Discussion started by: harjitsingh
2 Replies

5. Red Hat

activate ftp from xinetd

Hello all, I´m trying to configure the ftp service (port 21) in a Red Hat Enterprise 4 from xinetd. Anybody have done this? Thank you in advance. (3 Replies)
Discussion started by: mig28mx
3 Replies

6. Solaris

basic question on sd.conf and lpc.conf file

Hello Guys, Do we need to configure this file only if we add SAN disk or even if we add local disk, do we need to modify? (4 Replies)
Discussion started by: mokkan
4 Replies

7. Emergency UNIX and Linux Support

take ssh out of xinetd

i solved myself. thx! (2 Replies)
Discussion started by: pabloli150
2 Replies

8. Solaris

Looking for Xinetd for Solaris

I got the xinetd src from synack archive but when I try to compile I get errors all over the place, so am just wondering if anyone has a pre patched working version of xinetd for solaris 7 or higher there can share ??? thanks (4 Replies)
Discussion started by: Wpgn
4 Replies

9. Shell Programming and Scripting

Script to update rsyslog.conf and auditd.conf

Hello all, Newbie here. I'm currently tasked with updating rsyslog.conf and auditd.conf on a large set of servers. I know the exact logging configurations that I want to enable. I have updated both files on on a server and hope to use the updated files as a template for the rest of the... (3 Replies)
Discussion started by: Mide
3 Replies

10. Solaris

Configure resolv.conf and nsswitch.conf

Hi, I've installed Solaris 11.3(live media) and configured DNS. Everytime I reboot the server, resolv.conf got deleted and it created a new nsswitch.conf. I used below to configure both settings: # svccfg -s dns/client svc:/network/dns/client> setprop config/nameserver = (xx.xx.xx.aa... (1 Reply)
Discussion started by: flexihopper18
1 Replies
RECONF-INETD(8) 					  System Administration Utilities					   RECONF-INETD(8)

NAME
reconf-inetd - utility to update /etc/inetd.conf and restart inetd SYNOPSIS
reconf-inetd [--verbose] reconf-inetd --sanity-check=fragment [... fragment] DESCRIPTION
reconf-inetd is a maintainer tool that updates inetd.conf. Such updates are based on xinetd.conf-like configuration fragments in /usr/share/reconf-inetd (where server packages install their fragments) and /usr/lib/reconf-inetd (where reconf-inetd keeps track of which inetd.conf entries have been added by itself). reconf-inetd identifies every inetd.conf entry based on the combination of three fields: service name, protocol, and server path. This allows multiple inetd.conf entries for the same service, eg. for IPv4 and IPv6 versions, as well as for different upstreams (eg. proftpd versus ftpd-ssl). reconf-inetd will not add inetd.conf entries for services whose server path is non-existent, or whose combination of protocol, service name and server path matches an existing inetd.conf entry. reconf-inetd does not support internal services. OPTIONS
-h, --help show this help message and exit -c FRAGMENTS_TO_CHECK, --sanity-check=FRAGMENTS_TO_CHECK test the validity of the xinetd.conf-like configuration fragments, as specified by a space-separated list of files -v, --verbose explain what happens -V, --version show version and exit FILES
reconf-inetd declares a file-based dpkg trigger on /usr/share/reconf-inetd. Shadow fragment files are stored in /var/lib/reconf-inetd. A log file is kept at /var/log/reconf-inetd.log FRAGMENT STRUCTURE
reconf-inetd fragments are a much simplified version of xinetd.conf(5) fragments. They have this structure: service <service_name> { <attribute> = <value> <value> ... ... } Of the wide range of fields foreseen by xinetd.conf(5), reconf-inetd honors only these fields: socket_type protocol (optional, except for RPC and unlisted services) port (optional, except for unlisted non-RPC services) wait user server server_args (optional) If the protocol field is omitted and the service is listed, reconf-inetd will assume the protocol of the first matching entry from /etc/services. That will be tcp or udp, which currently implies IPv4, so if the intention is IPv6, then tcp6 or udp6 should be explicitly specified in the protocol field. Unlike, regular xinetd fragment files, reconf-inetd fragment files must have only one service per file. A package that provides more than one service must install a separate fragment file for each service. This is the case to allow for removal of individual services, by simply removing the related file. /usr/share/reconf-inetd fragments are not configuration files; they're just input to reconf-inetd. Local admin configuration should be applied to inetd.conf tcpd-configured service fragments will typically have server set to /usr/sbin/tcpd and server_args will start with the path to the actual server executable. Follows a reproduction of valid atrribute values from xinetd.conf(5): socket_type Possible values for this attribute include: stream stream-based service dgram datagram-based service raw service that requires direct access to IP seqpacket service that requires reliable sequential datagram transmission protocol determines the protocol that is employed by the service. The protocol must exist in /etc/protocols. If this attribute is not defined, the default protocol employed by the service will be used. port determines the service port. wait This attribute determines if the service is single-threaded or multi-threaded and whether or not xinetd accepts the connection or the server program accepts the connection. If its value is yes, the service is single-threaded; this means that xinetd will start the server and then it will stop handling requests for the service until the server dies and that the server software will accept the connection. If the attribute value is no, the service is multi-threaded and xinetd will keep handling new service requests and xinetd will accept the connection. It should be noted that udp/dgram services normally expect the value to be yes since udp is not connection oriented, while tcp/stream servers normally expect the value to be no. user determines the uid for the server process. The user attribute can either be numeric or a name. If a name is given (recommended), the user name must exist in /etc/passwd. This attribute is ineffective if the effective user ID of xinetd is not super-user. server determines the program to execute for this service. server_args determines the arguments passed to the server. FRAGMENT EXAMPLES
Here is an example fragment: service finger { socket_type = stream protocol = tcp6 wait = no user = nobody server = /usr/sbin/fingerd } and it's tcpd-enabled version: service finger { socket_type = stream protocol = tcp6 wait = no user = nobody server = /usr/sbin/tcpd server_args = /usr/sbin/fingerd } BUGS
Known issues and missing features are listed in /usr/share/doc/reconf-inetd/TODO HISTORY
reconf-inetd is a replacement for update-inetd. The motivation for and design of reconf-inetd is detailed at the Debian Enhancement Pro- posal 9, at http://dep.debian.net/deps/dep9/, a copy of which is locally available at /usr/share/doc/reconf-inetd/dep9.html AUTHOR
reconf-inetd was designed, documented and implemented by Serafeim Zanikolas <sez@debian.org> SEE ALSO
inetd.conf(5), xinetd.conf(5), inetd(8), update-inetd(8), deb-triggers(5) reconf-inetd 1.120603 June 2012 RECONF-INETD(8)
All times are GMT -4. The time now is 07:42 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy