Requiring xinetd when placing files into /etc/xinetd.d

[Todd Zullinger]

A conversation¹ on fedora-list reminded me of something I found a while
back and never got around to asking about...

It seems that about half of the packages that place files in
/etc/xinetd.d require xinetd and half do not:

$ repoquery --qf '%{name}' --whatprovides '/etc/xinetd.d/*' | \
sort -u | while read p; do
    repoquery --requires $p | \
        grep -q xinet && echo "$p: YES" || echo "$p: NO"
done

amanda: YES
apg: NO
authd: YES
bitlbee: YES
cups-lpd: YES
cvs: NO
ebhttpd: NO
ebnetd: NO
finger-server: YES
git-daemon: NO
krb5-workstation-servers: YES
ldminfod: NO
leafnode: YES
libident-tools: NO
ltsp-server: NO
ndtpd: NO
node: YES
nuttcp: NO
proftpd: NO
pure-ftpd: NO
rsh-server: YES
rsync: NO
samba-swat: YES
talk-server: YES
telnet-server: YES
tftp-server: YES
uucp: NO
uw-imap: YES
vnc-ltsp-config: YES
vtun: YES
xinetd: YES

I am sure there are a few valid reasons a package might place files
into /etc/xinetd.d and not require xinetd, such as cvs or rsync, which
both provide plenty of functionality without xinetd.

A package like git-daemon on the other hand, which is a subpackage
specifically designed to provide an xinetd service, really ought to
require xinetd to give a good experience out of the box, correct?
While it is possible to setup an init script to run git-daemon²,
that's not how we ship it in the current packages. (I'm one of the git
co-maintainers, and I'm leaning toward adding an xinetd requirement,
unless I learn of good reasons not to do so.  I'm slightly torn
because adding an xinetd requirement may well annoy some folks that
prefer to setup an init script.)

I'm guessing that /etc/xinetd.d being provided by the filesystem
package is designed to allow for cases like cvs and rsync, but that
happened back in 2000, and the filesystem spec file doesn't leave any
bugzilla breadcrumbs to follow to see what other reasons there might
be for not requiring xinetd.

If anyone has pointers that might help illustrate other cases where
not requiring xinetd is the best course, I'd be glad to know about
them.  At the same time, if anyone is familiar with the packages in
the "NO" category above, giving a closer look to whether any of them
really should be requiring xinetd would probably be a good idea.

¹ http://www.redhat.com/archives/fedora-list/2009-May/msg01664.html
² https://bugzilla.redhat.com/480755

[Enrico Scholz]

Todd Zullinger  writes:
> A package like git-daemon on the other hand, which is a subpackage
> specifically designed to provide an xinetd service, really ought to
> require xinetd to give a good experience out of the box, correct?

no; you can use it with every inetd like program. E.g. placing something
like

| start on starting local
| respawn
| exec /sbin/busybox tcpsvd 0 1234 /usr/bin/git-daemon ...

into /etc/event.d/git-daemon provides an alternative way to invoke
git-daemon and it's not more work than editing the xinetd setup.

Keeping stuff configurable and do not require stuff which is not needed
for core functionality is a good thing...

Enrico

[Todd Zullinger]

Enrico Scholz wrote:
> Todd Zullinger  writes:
> > A package like git-daemon on the other hand, which is a subpackage
> > specifically designed to provide an xinetd service, really ought to
> > require xinetd to give a good experience out of the box, correct?
>
> no; you can use it with every inetd like program. E.g. placing
> something like
>
> | start on starting local
> | respawn
> | exec /sbin/busybox tcpsvd 0 1234 /usr/bin/git-daemon ...
>
> into /etc/event.d/git-daemon provides an alternative way to invoke
> git-daemon and it's not more work than editing the xinetd setup.
>
> Keeping stuff configurable and do not require stuff which is not
> needed for core functionality is a good thing...

Even when it means that we're shipping something that doesn't work out
of the box?  It seems rude to expect users to install git-daemon, try
to enable it using the standard chkconfig method, then have to
manually install xinetd.

I do understand keeping requirements to a minimum, but I think that
also needs to be balanced against making packages work as smoothly as
possible by default.  I appreciate your opinion Enrico and I'm
certainly interested to know what other folks think about this before
I add an xinetd requirement to git-daemon.

At the least, having a consistent approach to this would help users
and packagers.  Currently, some packages require xinetd and others do
not.  I think that leaves users of our packages in an uncomfortable
position.

If the goal really is to cater to users wanting to run the daemon via
xinetd, upstart, init.d, etc, having subpackages for each would seem
to be the way to go.  But I'm certainly not interested in trying to
play that game.

I think that we should make a sane default choice for a given package
and ensure that it works.  At worst, those wanting to use some method
other than xinetd are stuck with having xinetd pulled in (which costs
~376K of disk space).

[Enrico Scholz]

Todd Zullinger  writes:
> Even when it means that we're shipping something that doesn't work out
> of the box?

Yes. When somebody wants to run git-daemon he has to think about security
implications and has to know technical parameters (e.g. ports which must
be opened in the firewall).  This includes reading documentation where
the requirements can be explicitly mentioned.

For more end-user specific services some special packaging (e.g. moving
core stuff into -core subpackage and providing initscripts in the main
package) can be done.  But for git-daemon this is overkill imo...
> I do understand keeping requirements to a minimum, but I think that
> also needs to be balanced against making packages work as smoothly as
> possible by default.

For me, preconfigured stuff like

| user            = nobody
| server_args     = ... -path=/var/lib/git

is painful to handle (running as 'nobody' might be a temporary hack but
nothing for production usage, and the path simply does not fit into my
system).

Writing setup/initscripts from scratch is here easier than to cope with
the existing ones.

Enrico