Hello again, We have gone over the community feedback in-depth, and taken into account all of your suggestions regarding the new backwards-compatible syntax for inetd.conf. We have drafted a few ideas, and would like to get your thoughts and feedback on these ideas.
To reiterate the previous thread about inetd enhancements, it was apparent a new backwards compatible syntax for inetd.conf would be needed if we are to implement the new features (http://wiki.netbsd.org/projects/project/inetd-enhancements/). As suggested by David Holland and Mouse on Nov 25, a good way for the parser to distinguish between the new syntax and old syntax would be based on the second token of a service configuration. We like the previously suggested idea of using an “on” or “off” directive to distinguish the new syntax. Something like: ntalk on ... or to make the service off by default: ntalk off ... This would also provide the advantage of allowing easy enabling/disabling of a service if the service configuration extends for multiple lines (which the new syntax may allow), as opposed to needing to comment/uncomment multiple lines. We also are favoring key-value pairs, opposed to the current positional syntax, since that will allow for greater flexibility, making it easier for future additions to inetd as well as making it easier for handling default or implied values. For example, if the admin doesn’t assign a value to the “port” key then the port would be inherited from ‘service-spec’, and similarly for listen-addr and IPsec policy. The new syntax would look something like: <service-spec> on/off key1=value, key2=value1 value2 value3, key3=”this is a value”, key4=value1 value2 ”this is value3”; For example: ntalk on protocol=tcp4, user=nobody, exec=/usr/libexec/ntalkd, args=ntalkd -p; The exact key-value pair names and purposes is up for debate. It is possible that we could implement the features of the current syntax almost exactly as they are now, just as separate key-value pairs, or we could smooth over some of the awkwardness of the current syntax by allowing parameters like dgram/stream and wait/nowait to be implied by default by the actual transport protocol if possible, or vice versa (dgram implies udp). Of course the rules for defaults would need to be well documented and obvious or unambiguous. Comma delimiters allow keys to be associated with multiple values, which could be useful for things like command line arguments or specifying multiple addresses or interfaces. There are some lingering thoughts and questions we have regarding implementing this new syntax. Firstly, we are unsure if we should implement escape sequences for arguments contained inside quotes. Currently, inetd does not do this, and simply removes all occurrences of quotations from arguments. Would it be useful for us to support escape sequences in the new syntax? (In other words, is there any use for being able to pass quotation marks as part of an argument for a service?) For “per-service” (really just “external”) configuration files, our current thought is to allow for the “includedir x” directive (includedir is not necessarily the directive we are set on) inside of inetd.conf where “x” would be a directory containing fragmented configuration files. But we are also thinking it would be best to not support “includedir” inside the fragmented files themselves, in order to avoid potential cycles and to avoid multiple levels of includedir directives. Regarding the [listen-addr:] option, our current idea is to leave this functioning as is (which is that it acts more like a global variable and sets the listening address for the rest of the config file). We would also like to introduce a new key value pair, listen-addr=xxx.xxx.xxx (or an IPv6). This would allow for the listening address to be overwritten only for the service that specifies it. We know this is quite a lengthy email, that has quite a lot to consider and discuss, but your feedback is very useful, and it does help us to consider new perspectives and see oversights we might have had in our design process. We prefer to get this new syntax right, and make sure it is thought out and intelligent as opposed to rushing these changes out. Sincerely, James Browning Gabe Coffland Alex Gavin Solomon Ritzow
