update-inetd and xinetd
One of the things on my plate has been to make it so that
update-inetd works with xinetd. Which, basically, means
rewriting DebianNet.pm so that there's something analogous
to it for xinetd.
Problem is: there's lots of assumptions in the semantics of
update-inetd and DebianNet.pm that we're working with inetd,
and not something else. [Something else in this case being
xinetd, but it could just as easily be a suite of init.d/
scripts spawning one server for each port.]
One of the more annoying feature of update-inetd is --pattern.
The man page doesn't really document this one's semantics: basically,
it's just a regexp search on the lines of inetd.conf. Current practice
is that it's looking for commands of a given name. Maybe the documentation
and code should be modified to conform to this practice? Except this
isn't the only option that let's you do this kind of search, and
for example cvs uses --remove ^cvspserver (which removes based on
the service rather than on the program name). How many other packages
are expecting a match on the service name instead of on the program
name? The interface sure isn't very helpful about this kind of thing.
Another oddball feature is that update-inetd has different semantics
if it's passed it a line of inetd that's commented out. Not that
hard to deal with. But then there's also --comment-chars, which
specifies the prefix to be used for the commented out line in
inetd.conf. Now, is that a record prefix or a line prefix (xinetd
has multi-line records)? [This is really more a gripe about xinetd
-- how do you reliably automatically maintain a file with multi-line
records where there's no good way of commenting out a record other
than commenting out each line individually?]
Oh, and xinetd has this mechanism where each record is implicitly
tagged with a unique id, but update-inetd doesn't really give a
good interface to match up to this feature. But you almost have
to use this feature when manipulating xinetd records (if you
don't take it into account you run the risk of stomping all over
it).
Anyways, none of these are insurmountable obstacles, but I just
have to wonder: maybe update-inetd could have its interface
designed? [And the current interface depreciated, and only
supported if the user genuinely has inetd installed. Certainly
that's no worse than the current situation.]
--
Raul
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: