[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Advice: managing inetd entries for cvs



Hi,

I've got a serious bug (#403334) open against cvs over the way it
handles some of its configuration via debconf, specifically its inetd
configuration for the pserver. At the moment, the package will
reconfigure inetd on each upgrade, which is quite clearly a bug. If
the local admin has changed the pserver inetd entry by hand since the
package was installed, then those changes will be lost ---> bug. Most
network daemons fall into one of two camps:

 1) installation implies an inetd entry, no configuration is expected
    (e.g. tftpd)
 2) there's a choice of running from inetd or standalone (e.g. proftpd)

cvs, however, is commonly configured both ways, either with an inetd
entry (for remote pserver access) and without (as a client only, or
remote access via ssh). This seems to be quite a rare setup.

There are more complications, though:

 1) cvs *also* optionally changes the inetd respawn limit, as heavy
    pserver usage will otherwise quickly trigger the inetd respawn
    protection.

 2) update-inetd allows for easy *changing* of inetd entries in a
    server-independent manner (e.g. for old-style inetd and in theory
    for xinetd too), but there is no equivalent method for *reading*
    the current inetd config in a portable fashion.

 3) update-inetd will ignore lines starting with a single "#", as
    configured by the admin. Enabling/re-enabling the pserver using
    update-inetd may fail in these situations.

Given these issues, there doesn't seem to be a safe way at all for cvs
to automatically configure itself via inetd. Peter suggested grepping
the inetd.conf file to read current config, but I'm not convinced
that's such a good idea due to its lack of portability. I'm beginning
to think that the best way to go might be to just ignore inetd setup
altogether from the package config point of view, or at best simply
add an inetd entry *once* at initial installation time if the user
asks for it then add a section in README.Debian to tell the user what
needs doing.

Thoughts/suggestions welcome! Have I missed anything screamingly
obvious here?

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Attachment: signature.asc
Description: Digital signature


Reply to: