Replacing inndstart

[Alex Kiernan]

Russ Allbery <rra at stanford.edu> writes:

> Here's my latest toy.  This is probably an INN 2.5 thing.
> 
> The basic idea is one suggested by Andrew Gierth.  In Unix, what is and
> isn't shared with child processes is a touch complicated, but works out in
> such a fashion that a parent can create a socket, fork a child, have the
> child do a bind, and then go back and listen in the parent and everything
> works, because the socket has an existence outside of either process.
> 
> This provides an opportunity to *vastly* simplify how port binding is
> handled.  If you look at the code for inndstart, most of the complexity
> comes from the fact that it's a wrapper around innd, and therefore has to
> parse command-line arguments, construct arguments to pass to innd, fiddle
> with the environment, have code to allow for a debugger to be run, and so
> forth.  And in order to find innd, and to set up the environment properly,
> it has to parse inn.conf, with all of the code that entails.  All in a
> setuid program.
> 
> All we really need setuid for is the bind, though (see below for resource
> limits).  So a different approach is to just write a simple setuid program
> that only does binds and nothing else, and hence doesn't have to parse any
> sort of configuration file.  Then, rc.news can set up the environment for
> innd, and innd can just run that program to bind any low-numbered ports
> that it needs to bind.
> 
> Furthermore, we can then use that same program for nnrpd in daemon mode,
> which should then not have to start as root.
> 

This is so cool... we should also be able to get nnrpd auto-started as
a daemon correctly this way (as opposed to today where I use a foul
kludge on our production boxes).

> For the resource limits, I think this is better taken care of by putting
> ulimit calls into the sample init script that we provide and documenting
> that in the installation instructions.  That lets us get rid of
> startinnfeed as well, and that's a more common way of solving that
> problem.
> 

Works for me.

-- 
Alex Kiernan, Principal Engineer, Development, THUS plc