Re: FHS, macros, and Pinstripe

[Jim Knoble <jmknoble pint-stowp cx>]

Circa 2000-Sep-01 10:51:57 -0400 dixit Jeff Johnson:

: On Thu, Aug 31, 2000 at 05:11:14PM -0700, Kenneth Porter wrote:
: > As a packager of a few daemons, I'm concerned about what I need to do
: > to my spec files to prepare for Pinstripe and FHS compliance. [...]
: 
: A harder issue will be xinetd vs. inetd. If just inetd, you would
: use %post/%preun to add/delete entries to /etc/inetd.conf. If just
: xinetd, you could simply add appropriate /etc/xinetd.d/foo to %files.
: If you wish you package to install on both, you will need to, for example,
: check for /etc/xinetd.d to detect an xinetd system and then create the
: xinetd entry directly.

Best would be to add the proper configuration to both spots.  Then, for
example, if the admin switches from inetd to xinetd after the daemon's
package is installed, the daemon's xinetd config is already there.

: There's also the issue of restarting inetd/xinetd to activate your service.
: IIRC (verify by checking some daemon package(s)) Pinstripe tries to execute
: /etc/init.d/xinetd condrestart. Previous versions of Red Hat left it
: to a reboot/sysadmin to restart inetd (that's probably OL for you too.)

This is generally a packaging policy that varies with distributions and
with packagers.  I don't always want inetd/xinetd restarted when i
install or uninstall a package---for example, if i'm installing a
package so that i can read the documentation to figure out whether i
want the service there or not, i don't want the service started without
my knowledge.  Or perhaps the service won't be secure until i configure
it properly.  The granularity of rpm --install --no-scripts is,
unfortunately, usually too coarse to allow for such situations.

The tradeoff here is pretty much between immediate convenience and
security.  I prefer security, with its long-run convenience of not
having to deal with a compromised system.  Others appear to prefer
convenience.  [Shrug.]

-- 
jim knoble | jmknoble@jmknoble.cx | http://www.jmknoble.cx/