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
Todd Zullinger tmz@pobox.com 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
Enrico Scholz wrote:
Todd Zullinger tmz@pobox.com 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).
Todd Zullinger tmz@pobox.com 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
packaging@lists.fedoraproject.org
-
Enrico Scholz -
Todd Zullinger