On Sat, Nov 21, 2020 at 08:24:56PM -0800, James Browning wrote: > 2. To inquire about the ideal way to implement per-service > configuration files in inetd.
Please see the other post I just wrote, even though it's somewhat deep in the thread. (You don't necessarily need to read the rest of that branch of the thread first.) Per-service configuration files are a mistake. As the project definition partly says, what you want are per-service _service definitions_ and a single master config file that turns services on and off. (And, perhaps, allows setting command-line flags, though that's somewhat of a can of worms.) This seems to have migrated to "nice to have" but is really essential for doing this correctly. The other post explains in substantially more detail. > 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). We would like to > know if this change would be worth it at the cost of users > potentially needing to change their inetd config files to conform > to the new format. You need to extend it, not change it. The current syntax has been extended well past its elastic limit, so what this means in practice is: continue to accept the old syntax but also accept files that begin with "syntax v2" or "inetd.conf v2" or some other magic sequence that isn't easily confused with a valid traditional inetd.conf line, and are read with a different parser and have a completely different syntax. IIRC at one point there was a suggestion to use "#@" (by analogy to "#!") for these markings but that may not be a good idea. Don't follow xinetd blindly; there's nothing especially good about its syntax and it doesn't have the service definition vs. configuration decomposition. > per-service rate limiting. This is also configuration, not part of the service definition, so it doesn't belong in the service definition files. (Though a service definition might want to come with a default set of rate limiting settings.) As other people have noted, the rate limiting is already at least somewhat per-service and has been since at least 4.3BSD. I can't remember how that clause got into the project description in its current form; it's probably edit sausage. My recollection is that the goal was to make the rate limiting more flexible than it currently is, but I don't remember how and I haven't thought about this in years so I'm not sure at the moment what would be useful. Probably a good first step is to allow more reactions than unceremoniously shutting off for a fixed (and rather long) period of time. Configuring that period is an obvious direction. It should also be possible to continue accepting connections but limit the rate at which it happens (giving those who don't get in ECONNREFUSED). Limits based on system load average, or the number of subprocesses _running_ rather than the fork rate, are probably also useful. > [...] Another important thing often gotten wrong doing this in the Linux world: when pointed at a directory, don't read _every_ file in the directory; read only the ones whose names match "*.conf" or "*.inetd" or something like that. Otherwise you inevitably end up editor backups or scratch files or other miscellaneous rubbish and problems ensue. -- David A. Holland dholl...@netbsd.org
