Re: inetd Enhancements

[mlelstv%serpens.de@localhost (Michael van Elst)]

mouse%Rodents-Montreal.ORG@localhost (Mouse) writes:

>> https://wiki.netbsd.org/projects/project/inetd-enhancements/

>> When it comes to adding per-service configuration files, our current
>> plan is to add a new configuration command, simlar to xinetd's
>> "includedir", that allows for specification of a per-service
>> configuration directory.

>Personally, I think this is a bad idea, most fundamentally because it
>enables, even encourages, administration without understanding.

I personally would just send things through m4. I doubt that splitting
up the configuration file into multiple files hinders understanding.
It just simplifies maintenance (putting a file instead of atomically
updating a file). It also allows to easily install services by
packages.

None of that requires the syntax to change.

But seeing that we already modified the original (very simple) syntax
to shoehorn extra parameters or policy strings makes me think that this
is a very normal process. I also don't think that the previous changes
were "clean", "readable" or even "logical". Whatever comes out of the
project should do better.


>> In addition we are considering also changing the syntax of the inetd
>> configuration file to be cleaner and easier to read (something more
>> in line with what xinetd does).

>"Cleaner" and "easier to read" are matters of opinion and taste.

Definitely.


>Of course, the flip side of this is flexibility.  Personally, I would
>look for a way to express the flexibility in a more compact way, one
>that doesn't invalidate existing files and doesn't take a dozen lines
>to express what used to be one line.

Having things on a single line and in a single file helps to get
a concise overview. But it gets less practical when the amount
of information grows. Think about the traditional *cap-files
as a counter-example.


>You started off speaking of being unintrusive.  I find it hard to see
>how changing the config file syntax so as to invalidate existing
>configurations could possibly be considered unintrusive.

The goal should therefore be to support the existing syntax and also to
support all new features with the existing (and possibly augmented)
syntax.


>As for rate limiting, well, inetd as of even 1.4T had per-service rate
>limiting, in the form of a per-service maximum number of requests per
>minute.

Yes. The project milestone is a bit confusing, the rate-limit feature
is pretty ancient and was always per-service.

In any case, the suggested features will be more intrusive than a
changed config file syntax and surely require more understanding
by the administrator and possibly by users as well.

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."