Bug 23478 - inetd/xinetd.conf entries mgmt
Summary: inetd/xinetd.conf entries mgmt
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: xinetd
Version: 7.0
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Trond Eivind Glomsrxd
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-01-06 10:17 UTC by stano
Modified: 2007-03-27 03:38 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-01-06 10:17:31 UTC
Embargoed:


Attachments (Terms of Use)

Description stano 2001-01-06 10:17:29 UTC
There are packages that need to add/remove inetd entries on
install/uninstall. This is easy with xinetd, but AFAIK
Red Hat itself recommends to develop on older systems
to ensure maximal compatibility right now due to
compiler/library mess^H^H^H^Hdecisions.

Is there a recommended future-proof way to check, whether
there is inetd or xinetd running on the target machine?
I would say that a wrapper similar to chkfontpath,
chkconfig etc. should be used - this does not solve anything
for previous releases, but might help if there is similar
change in the future.

Comment 1 Trond Eivind Glomsrxd 2001-01-08 01:57:46 UTC
There isn't a glibc/compilers mess, but binaries compiled on 7 aren't compatible
with 6.2 due to use of new glibc (binary compatiblity is what we use to define a
major series). 7 is a nice development platform, but if you need to deploy on
multiple releases you need to compile with older libraries as the other ones
aren't as uptodate yet.

Anyway, inetd and xinetd are very different - the way to check for which one is
present would be "rpm -q inetd" (or xinetd), and check if it is running with
"service xinetd status" (or inetd)


Note You need to log in before you can comment on or make changes to this bug.