dh_installinetd
Has anyone considered writing such a beast?
I find maintaining inetd entries using my custom made maintainer scripts
a pain in the neck, because I make assumptions that are not always
correct, and the different maintainer scripts have duplicated code.
For instance, using the code I stole from some other package,
my maintainer scripts make it hard to re-add inetd entries if
they were deleted for any reason (since it assumes that the
operator deliberately deleted them).
I *think* my scripts should support having multiple installed daemons
compete for the same services, but it would be good if this was
standardized somehow (I don't particularly want to split heimdal-servers
apart just so it is possible to install telnet from heimdal and ftp from
proftpd for instance).
It would be nice if there was a standard way of doing this.
Such a debhelper routine could also support xinetd and rlinetd, too.
Initially this could be done by putting everything into the generated
maintainer scripts, but eventually functionality could be split of into
other packages, if desired.
It could also use a standard configuration file /etc, a bit like the
kernel-img.conf file kernel-images.
Obviously the design would have to be well though out, I think (first
draft only) dh_installinetd would need to be able to determine the
following bits of information:
- service
- group
- commented out by default
- stream/dgram? TCP/UDP? wait/nowait? (not sure about this one).
- userid:groupid
- command (not including /usr/sbin/tcpd).
- parameters
- (maybe extra information could be optionally used, eg. for xinetd.)
- max spawned processes, etc.
eg. heimdal-kdc might have a debian/packagename.inetd file with:
--- cut ---
Service: kerberos-adm
Group: OTHER
Disabled: no
Type: stream/TCP/nowait
User: root
Group: root
Command: /usr/lib/heimdal-servers/kadmind
Parameters:
Service: krb_prop
Group: OTHER
Disabled: yes
Type: stream/TCP/nowait
User: root
Group: root
Command: /usr/sbin/hpropd
Parameters:
--- cut ---
Comments?
--
Brian May <bam@debian.org>
Reply to: