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

Re: dh_installinetd

Brian May wrote:
> 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.

I've thought about it, but I could see no way around requiring a lot of
information of this sort. Trying to shoehorn this into debhelper as you
do here --

> 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 ---

Has the same problem as suggested dh_adduser program (bug #118787).
Namely, you end up with something that is just as complicated as adding
calls to updte-inetd to the maintainer scripts yourself. Which just ends
up increasing the learning curve for maintainers, since they have to
learn all of the above plus still learn how update-inetd really works,
to debug things. There is some benefit in moving from procedural to
data-driven mechanisms, but it doesn't seem to be worth it in the case
of either adduser or update-inetd, to me.

see shy jo

Attachment: pgpi8A8qR6JGX.pgp
Description: PGP signature

Reply to: