Bug 23478 - inetd/xinetd.conf entries mgmt
inetd/xinetd.conf entries mgmt
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: xinetd (Show other bugs)
7.0
All Linux
low Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-01-06 05:17 EST by stano
Modified: 2007-03-26 23:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-01-06 05:17:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description stano 2001-01-06 05:17:29 EST
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-07 20:57:46 EST
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.