RH7.1 question.

[Robert G. Brown]

On Fri, 25 May 2001 alvin at Mail.Linux-Consulting.com wrote:

>
> hi ya...
>
> i like the /etc/rc.d/init.d/foo  stop   and start method
>
> i didnt like that all the individual services are
> now explicity defined in each file in /etc/xinetd.d
> 	- went around to each file ... one by one to
> 	check it... ( to explicitly disable it )

Or use the chkconfig one-liner as previously mentioned.

I think that there are some decent reasons for the xinetd changes:

  a) By putting all inetd configuration data for a service in a single
file per service, it becomes very easy to package inetd-based services.
Before, one had to write clever sed-ism's like (the uninstall part of
procstatd.spec):

%postun

if grep "^procstatd" /etc/inetd.conf > /dev/null
then
 # There is a procstatd line installed.  Remove it (and the
 # rest of the procstatd modifications).  Should be no need to
 # backup the files as I'm just going to sed them outta there.
 sed -e "/^# procstatd/d;/^procstatd/d" /etc/inetd.conf >
/tmp/inetd.conf.tmp
 sed -e "/^procstatd/d" /etc/services > /tmp/services.tmp
 sed -e "/^procstatd/d" /etc/hosts.allow > /tmp/hosts.allow.tmp
 mv /tmp/inetd.conf.tmp /etc/inetd.conf
 mv /tmp/services.tmp /etc/services
 mv /tmp/hosts.allow.tmp /etc/hosts.allow

 killall -HUP inetd

fi

Note that this is a real pain and fraught with terror for error -- lots
of ways to screw things up royally if the system dies in mid-script,
even though the script fragment is written to be at least moderately
robust agains this.  Ditto on the install side -- one has to remove any
old procstatd lines from /etc/inetd.conf and put in the new one (as the
default configuration might have changed) while saving the old as
/etc/inetd.conf.rpmsave, but even this latter isn't stable as one might
be installing a string of RPM's and each one might overwrite the
one saved by the original.  If you HAD hand-tuned procstatd's inetd port
or ownership or permissions, by the time you got around to restoring it
after a reinstall or upgrade the original line might long be gone.

In the next procstatd release (coming soon) this will all be much
simpler -- just pop in /etc/xinetd/procstatd on install (saving the old
one in /etc/xinetd/procstatd.rpmsave), remove it on uninstall.

  b) It allows inetd to be managed with chkconfig.  This is actually not
a bad thing at all -- a single tool provides a consistent user
interface.  chkconfig --list shows you at a glance what is on and what
is off and where/when everything is started for BOTH script-started
services and xinetd-managed services.  And of course there can be higher
order GUI tools and such for novices or ex-Windows or Mac users who
don't do command lines.

  c) I personally never really cared for an /etc/inetd.conf that was
basically all commented out anyway, with just one or two functional
lines (if that) at the very bottom.  Messy and inefficient and dangerous
(easy to miss commmenting something out on one client in a
department-sized network), but those lines get in there pretty much no
matter what in a default install followed by years of updating,
upgrading, adding this and removing that.

This layout encourages the removal of irrelevant packages and their
xinetd.d configuration, or better their non-inclusion in a
kickstart-based install.  It further encourages the separate packaging
of each separate service rather than packaging in an "inetd" package
that contains all of them at once (but turned off by default).  You
want/need certain services in your particular environment?  Include them
(and ONLY them) in your kickstart configuration and you don't have to
worry about what is and isn't commented out -- the service just ain't on
the system.

(A special bonus is that one can do an rpm --erase linuxconf and have it
go AWAY and/or keep it OUT of a kickstart configuration -- this is one
that seems to come back like a bad penny and add a line to
/etc/inetd.conf each time it comes back.  I've had as many as two or
three commented out linuxconf lines in old systems after upgrades.)

<rant>

It still isn't perfect.  If I were to whine about xinetd it would
primarily be about documentation -- there is a man page for xinetd and
another for xinetd.conf which aren't bad, but they don't explain the
chkconfig mechanism at all and xinetd is different enough that it really
deserves a HOWTO to help buffer the change -- and the format of
/etc/inetd.d/whatever.  It should be done in XML, goddammit.  Everything
should be moving there at this point.

The latter is a personal religious gripe.

<religious tone=deep voice=sonorous lighting=godsky>

In the Beginning there was the Flatfile, formed in the Bounty of Diskful
Space, and it was Good.  It allowed information to be easily read and
edited by the administrator with a Single Universal Tool, the Editor.

The Good of the Flatfile, however, contained the Seeds of Evil.  A Babel
of Cacaphonous Voices arose creating configuration files with ":" as
separators in this, "\t" as separators in that.  New Fields were Added,
and old Fields were Taken Away as systems Evolved to a Higher State of
Being.

Soon the Users and Administrators in all the Lands were Crying out under
the Burden of this Evil.  What Began as a Good Idea of Universal Access
to Power had created a Cult of the Guru, for veritably only a Guru could
keep straight the Fields and the Separators and the Formats of lo, the
many Files.

Then the Wall said, Let There Be Perl and there was Perl, and lo,
regular expression parsing became easy at the script level.  This
removed some of the Oppression from the shoulders of the Administrators
across the land, but if anything the Evil Power of the Cult grew
stronger, as Deep Knowledge of the Ways was required to write the
appropriate Perl Incantations to manage simple systems functions.

This same Evil existed in the Other Realms of Computing.  Complexity
grew everywhere, but Control was left to the Whim of the application
designer as each application had its own Interface.  Parsing of the
Interface required Dark Secret Lore known only to the most puissant and
powerful Wizards, who thereby commanded great Sacrifice and Tribute.

Finally, those high in the privy councils of the Web and Service design,
who sought to bring the Power of the Universal Interface to Application
Design spoke, and said Parsing Each Tom, Dick and Harry's Flatfile Data
is Darkest Evil and Not Extensible or Portable.

They meditated and prayed and finally said, Let There be XML and lo,
there was XML.

Among the gods, the Sun god, the Daemon god, and the Penguin looked on
XML and Smiled, for it was Good.  At last there was an Interface
Standard (and tools for parsing it) and its Dream of the Universal
Portable Interface was one step closer to reality.  Although the god of
all Windows plotted and schemed to seize the Power of XML and suborn it
his Dark Schemes, the strength of the rest of the gods was United and
Opposed -- XML remained Open and Free.

Alas, the Wizards were Steeped in the Ways of Sin.  They would not
easily give up their bedamned

foo	bar

(tab separated pairs), their

foo,bar

(comma separated pairs), their

foo = bar

(equal sign separated pairs), their

foo  	  bar

(whitespace separated pairs), their

foo:bar

(colon separated pairs), or evillest of all, their

foo	bar  fields=fubar	for:real

(a bunch of crap strung out on a single line)

where adding a new field or using a space instead of a tab created great
Torment and Misery to Administrators and Users everywhere (as the Dream
of the Penguin was to make every User an Administrator while preserving
the Power and Freedom of the Fountain of Open Source and so make the
Evil of Windows dissipate like the Mist of a Dream).

But it was not to be.  Not Yet.

The Penguin Sleeps, but in its Mind's Eye it beholds these Evildoers,
these Necromantic Wizards who turn away from the Light of XML, and one
day they shall be cast into the Outer Darkness and forced to work as
Windows Programmers and MCSEs if they do not turn away from Sin and
convert their configuration and control interfaces to XML.

Yea, a special fiery furnace awaits those who perpetuate the Misery that
is nameservice, the Hell that is Pam, even the Grinding Agony that is
/etc/passwd.  Oblivion is the Best that could befall all who Shun the
Light that is XML.

</religious>

Seriously, life would be so infinitely better if all systems
configuration files were converted to an XML-compliant structural layout
and parsed in the associated services and front end configurators and
managers with standard XML parsing tools.  It would lengthen the files,
sure, but it would also make checking syntactical correctness trivial,
eliminate all possible confusion over which column is which field, get
rid of the tab vs equal vs whitespace vs comma vs period crap, and make
it possible (nay, EASY) to build a universal configurator tool that
dynamically builds a GUI application configurator out of the XML-based
configuration file itself (just parse the damn thing, identify the
fields, create a matching layout of column-or-otherwise labelled
entrybox widgets, pop up the window, done).  Right now the "universal
configurator tool" is the editor of your choice, but without XML you
have to basically know exactly what the each field is for whatever you
are editing (and what the correct formatting is and what matters in the
syntax).  This sucks.  No wonder non-Unix gurus think that Unixoid
systems are "difficult" to figure out...

</rant>

   rgb

>
> where as, in the old setup, all the config items
> was all in one file /etc/inetd.conf.  though it was not really
> confiurable/flexible but was easy to add stuff and add/delete services  )
>
> at least its easily fixable a dozen different ways ???
>
> c ya
> alvin
> http://www.Linux-1U.net
>
>
>
> On Fri, 25 May 2001, Robert G. Brown wrote:
>
> > On Thu, 24 May 2001 alvin at Mail.Linux-Consulting.com wrote:
> >
> > >
> > > hi GSBCP
> > >
> > > yes.... xinetd.d is a mess...
> >
> > Not exactly a mess -- it is just different.  In one sense every change
> > like this is egregious -- things were perfectly easy to manage with
> > /etc/inetd.conf and /etc/rc.[0-6] (BSD/SunOS-style) if you knew what you
> > were doing.  On the other hand, things are perfectly easy to manage with
> > /etc/rc.d/init.d and /etc/xinetd.d, and the layout is arguably more
> > self-consistent.  If you know what you are doing.  The only problem is
> > learning about the differences.
> >
> >
>

-- 
Robert G. Brown	                       http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567  Fax: 919-660-2525     email:rgb at phy.duke.edu