Re: inetd enhancements - config syntax
On 21-01-31 18:12, David Holland wrote: | Alternatively you could put the glob in the include explicitly | (that is, "include dir/*.conf" That seems the sanest to me too; it's explicit, and it's also following a well-established pattern used by other applications, including: dovecot, (apache) httpd, rsyslogd. The include syntax may differ, the pattern is the same; include a path that supports globbing. Luke.
Re: inetd enhancements - config syntax
> The reason to have a suffix and only read files with that suffix is
> that there are lots of ways to get extra files in the directory that
> the user didn't mean for you to read, and ~98% of the time they won't
> have the right suffix so filtering by suffix is a good way to skip
> them and avoid trouble.
...and most of the 2% are files you don't want to read even if they do
have the right singax.
> This doesn't just mean foo.conf~ files left behind by emacs,
Some versions of emacs, maybe. ("emacs" is not a single thing.) The
emacs I use would leave foo.conf= and, in rarer circumstances,
#CKP#foo.conf - and either of them would contain something similar
enough to foo.conf that it would be a bad idea to include it.
> Alternatively you could put the glob in the include explicitly (that
> is, "include dir/*.conf"
This, I think, is the only sane way to do this. Then, at least, the
admin is in a position to alter it as appropriate without needing to go
grubbing around in the source. *I* am fine with hacking on the source,
maybe, but even I usually prefer to not need to.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: inetd enhancements - config syntax
On Wed, Jan 20, 2021 at 01:37:44AM +0700, Robert Elz wrote: > Date:Mon, 18 Jan 2021 22:15:30 + > From:David Holland > Message-ID: > > | ...and also, for your own and the operator's sanity, skip anything > | else beginning with '.', > > That one is probably reasonable (and also possibly some other odd > character, to give an easy way to "turn off" a file in a directory, > without removing it - and without 'hiding' it using a '.' name). > [...] > But please, no, file name suffixes are a horrible idea, invented to > cope with file systems with either no (rational) directory scheme Basically what you want is to read only files matching some glob that matches the POLA reasonably well, like "*.conf". The reason to have a suffix and only read files with that suffix is that there are lots of ways to get extra files in the directory that the user didn't mean for you to read, and ~98% of the time they won't have the right suffix so filtering by suffix is a good way to skip them and avoid trouble. This doesn't just mean foo.conf~ files left behind by emacs, but also files like foo.conv,v, directories named RCS, and things like that. :-p Without the suffix filtering you just can't have a directory named RCS in there. Alternatively you could put the glob in the include explicitly (that is, "include dir/*.conf" > Devices and pipes, etc, yes, but I thought the idea was to allow recursion > through directory trees. For that just skipping directories isn't the > right approach. What's more being able to do that seems useful to me. I don't think you want to include a whole subtree recursively. I can't think of any tool that does that by default, including these read-a- whole-directory tools meant to be fed by package managers. > | ...also I strongly recommend against having global settings that are > | meant to change around as things are included > > While in general I think I agree with what you mean, I wouldn't write > it like that. What I'd say instead is that anything in an included > file can affect only that file, and other files included below it, > nothing should be exported back to wherever the file was included from. Perhaps. That's at least reasonably sane, but I think in general it's better to design things so you don't need to do that either. E.g. (partially cribbing from Mouse's example) to avoid pasting listen addresses all over the place you might have some syntax like 10.10.10.10: ntalk dgram udp wait nobody:tty /usr/libexec/ntalkd ntalkd finger stream tcp nowait nobody /usr/libexec/fingerd fingerd 20.20.20.20: httpd stream tcp nowait _httpd /usr/libexec/httpd httpd /var/www ftp stream tcp nowait root /usr/libexec/ftpd ftpd -ll where the listen address is a global setting in the config file that changes over time. Making changes to it not escape include files is one way to avoid allowing regrettable things to happen, but something like this also avoids the problem without need for the global variable, plus works better with ipv6: service ntalk type=dgram user=nobody:tty options?= /usr/libexec/ntalkd ntalkd $(options) service finger type=stream user=nobody /usr/libexec/fingerd fingerd service httpd type=stream user=_httpd dir?=/var/www /usr/libexec/httpd httpd $(dir) service ftpd type=stream user=root options?= /usr/libexec/ftpd ftpd $(options) interface inside ipv4=10.10.10.10 ipv6=fe80::... interface outside ipv4=20.20.20.20 ipv6=1234::... enable ntalk listen=inside enable finger listen=inside enable httpd listen=outside enable ftpd listen=outside options=-ll and among other things it also lets you quickly slap down things like enable httpd listen=inside port=8080 dir=/var/www.new for testing purposes. -- David A. Holland dholl...@netbsd.org
Re: inetd enhancements - config syntax
>>> and anything that isn't a regular file (DT_REG). >> I don't recall whether this is relevant (it's been quite a while >> since I did anything with d_type), but I strongly believe that >> symlinks should be followed before any such test. > That makes not much sense, the d_type tells you it is a symlink, so > the test comes first, and after that you decide what to do with it. My "any such test" was talking about more "test for plain files" than "test of d_type". >> If such a check does go in, well, I don't *think* O_PLAIN (fail if >> the putatively-opened object isn't a plain file) dates back far >> enough I got it into NetBSD's tree, > We have no such flag: Not under that name. But, since I wrote what you replied to, I went looking and, if man pages are to be believed, you do have it, just spelled O_REGULAR instead of O_PLAIN. (Though the open(2) I found doesn't describe errno if O_REGULAR is attempted on something other than a regular file; when I added O_PLAIN I also added ENOTPLAIN. The open(2) I found also wasn't explicit about what O_REGULAR and O_DIRECTORY do if the pathname names a symlink.) > The question really is what happens with >> 10.10.10.10: >> .include "private-stuff/" >> *: >> .include "everybody-stuff/" > if private-stuff/service1 contains > 1.2.3.4: > > and private-stuff/service2 contains just > Agreed. I'm not sure what I think is the rightest answer, but I definitely believe the order of the directory entries in private-stuff/ should not matter: either the processing order doesn't matter or the directory is sorted in a well-defined order before processing. (As I read your mail, you agree with me on at least this point.) The best reason I can think of offhand to support settings that persist from one included file to another is things like first-file: 1.2.3.4: # maybe other "global" settings here # no services other-files: I'm not sure whether the clever-stuff potential of that is enough to outweigh the stupid-stuff potential. Maybe have some explicit indication, either in first-file or some kind of option on the include, needed? I'm not sure. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: inetd enhancements - config syntax
Date:Mon, 18 Jan 2021 22:15:30 + From:David Holland Message-ID: | ...and also, for your own and the operator's sanity, skip anything | else beginning with '.', That one is probably reasonable (and also possibly some other odd character, to give an easy way to "turn off" a file in a directory, without removing it - and without 'hiding' it using a '.' name). | names that don't end in ".conf" (or ".inetd" | or whatever you think the proper suffix should be), But please, no, file name suffixes are a horrible idea, invented to cope with file systems with either no (rational) directory scheme (ie: like one big flat directory for everything) or where using directories is either very inconvenient or costly. There's no reason or need to invent such a scheme for this, accept almost anything as the file name (with no semantics applied to it at all). | and anything that isn't a regular file (DT_REG). | | (If you get DT_UNKNOWN it's reasonable to call stat to get the real | type rather than just skipping it, and you might want to allow | symlinks, but definitely skip directories, devices, named pipes, etc.) Devices and pipes, etc, yes, but I thought the idea was to allow recursion through directory trees. For that just skipping directories isn't the right approach. What's more being able to do that seems useful to me. | ...also I strongly recommend against having global settings that are | meant to change around as things are included While in general I think I agree with what you mean, I wouldn't write it like that. What I'd say instead is that anything in an included file can affect only that file, and other files included below it, nothing should be exported back to wherever the file was included from. That I think allows plenty of generality, and | (such that the order includes are processed in matters) would not be an issue (obviously, when includes are specified include A include B A would naturally be included first, then B, though even there, it shouldn't matter, but include DIR can simply include all (appropriately filtered) files from inside the named directory in whatever order they're encountered. And replying to a second message, all in this one reply: Date:Mon, 18 Jan 2021 18:32:16 -0500 (EST) From:Mouse Message-ID: <202101182332.saa15...@stone.rodents-montreal.org> | > and anything that isn't a regular file (DT_REG). | | I don't recall whether this is relevant (it's been quite a while since | I did anything with d_type), but I strongly believe that symlinks | should be followed before any such test. That makes not much sense, the d_type tells you it is a symlink, so the test comes first, and after that you decide what to do with it. But I agree with the sentiment, if the code is to use the d_type field as an optimisation (which for this purpose I'm not sure is really worth it, since not all filesystems contain such a thing, resulting in DT_UNKNOWN for almost everything, the code to stat() needs to be there anyway, I'd just use it, and ignore d_type - it isn't as if inetd reading its config files is ever likely to be a very time consuming task, however it is implemented, and it doesn't happen very frequently). For the stat() code I'd be using stat(), not lstat(), which nicely deals with the symlink issue... | If such a check does go in, well, I don't *think* O_PLAIN (fail if the | putatively-opened object isn't a plain file) dates back far enough I | got it into NetBSD's tree, We have no such flag: jinx$ grep O_PLAIN /usr/include/* /usr/include/sys/* jinx$ | I may - occasionally - write code that uses global variables that way, | depending on precisely what you mean. I definitely think there is a | place for (to borrow from the current syntax for a moment) | | 10.10.10.10: | .include "private-stuff/" | 20.20.20.20: | .include "world-facing-stuff/" | *: | .include "everybody-stuff/" | | This may or may not be an example of what you're talking about. I agree that should work, and should still work no matter how deep down include file nesting it occurs. The question really is what happens with | 10.10.10.10: | .include "private-stuff/" | *: | .include "everybody-stuff/" if private-stuff/service1 contains 1.2.3.4: and private-stuff/service2 contains just and then does it matter whether sevice2 is included before or after service1. If before, then it is clear that the second server would listen only on 10.10.10.10, but if service1 is included first, then the listen addr (depending upon the semantics specified) for the second server might now be 1.2.3.4 (which it clearly is intended to be, for either include order, for the first server). | I do think the order in which the directory entries appear in the | directory should not matter; I agree, in the above, I'd have the 1.2.3.4:
Re: inetd enhancements - config syntax
> ...and also, for your own and the operator's sanity, skip anything > else beginning with '.', Not sure I agree with that; I'd have to think about it. I could argue it either way. Why do you think .-prefixed entries should be skipped? Relatedly, do you feel the same way about names beginning with, or containing, other unusual things, such as , + | ~ # * % !? Why or why not? > names that don't end in ".conf" (or ".inetd" or whatever you think > the proper suffix should be), Yes. > and anything that isn't a regular file (DT_REG). I don't recall whether this is relevant (it's been quite a while since I did anything with d_type), but I strongly believe that symlinks should be followed before any such test. > (If you get DT_UNKNOWN it's reasonable to call stat to get the real > type rather than just skipping it, and you might want to allow > symlinks, but definitely skip directories, devices, named pipes, > etc.) I'm not sure I agree. (I'm also not sure I disagree.) I certainly don't have any immediate use for any such, but I'm also very unsure this wouldn't be a case of forbidding stupid things and thereby forbidding clever things. Maybe a switch to turn it off, or maybe people who want to get that clever should just hack on the source themselves? I'm not sure how reasonable I think that is. If such a check does go in, well, I don't *think* O_PLAIN (fail if the putatively-opened object isn't a plain file) dates back far enough I got it into NetBSD's tree, but if there isn't currently anything equivalent, maybe it'd be worth adding? I found it borderline trivial to add, and it really helps for things like this. I should probably go read man.netbsd.org's open(2) > ...also I strongly recommend against having global settings that are > meant to change around as things are included (such that the order > includes are processed in matters) -- you wouldn't write code that > used global variables that way, don't do it in configs... I may - occasionally - write code that uses global variables that way, depending on precisely what you mean. I definitely think there is a place for (to borrow from the current syntax for a moment) 10.10.10.10: .include "private-stuff/" 20.20.20.20: .include "world-facing-stuff/" *: .include "everybody-stuff/" This may or may not be an example of what you're talking about. I do think the order in which the directory entries appear in the directory should not matter; either the spec should be such that the order in which they're processed doesn't end up mattering, or the entries should be sorted in a well-defined order (whether hardwired or chosen by the admin or indicated by the include directive or what). /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: inetd enhancements - config syntax
On Fri, Jan 15, 2021 at 05:43:45PM -0800, John Nemeth wrote: > } We like the idea of being able to include files along with > } directories. Our current plan is to implement directories first, > } along with files if time permits us. If we don't have time to > } implement include-a-file, then we will make sure our include-a-directory > } implementation can easily be extended to support fies in the future. > > You should really start by implementing functionality to > include files as that is your base. The way to implement including > directories is to stat the item being included to see if it is a > directory, and if it is, then branch to a routine that will scan > the directory and call the file inclusion routine on each file > found (skipping . and .. of course). ...and also, for your own and the operator's sanity, skip anything else beginning with '.', names that don't end in ".conf" (or ".inetd" or whatever you think the proper suffix should be), and anything that isn't a regular file (DT_REG). (If you get DT_UNKNOWN it's reasonable to call stat to get the real type rather than just skipping it, and you might want to allow symlinks, but definitely skip directories, devices, named pipes, etc.) ...also I strongly recommend against having global settings that are meant to change around as things are included (such that the order includes are processed in matters) -- you wouldn't write code that used global variables that way, don't do it in configs... -- David A. Holland dholl...@netbsd.org
Re: inetd enhancements - config syntax
Date:Fri, 15 Jan 2021 17:43:45 -0800 From:John Nemeth Message-ID: <202101160143.10g1hjbv018...@server.cornerstoneservice.ca> | The way to implement including | directories is to stat the item being included to see if it is a | directory, and if it is, then branch to a routine that will scan | the directory and call the file inclusion routine on each file When doing this, you also need to decide whether the order of the config commands matters - if it is all just service definitions, then it doesn't (shouldn't) and so the files in the directory can be processed in any order (eg: the order they happen to appear in the directory). But if there are any kinds of global commands (like the ability to set the listen address for future service definitions) then order matters, and there might need to be a way to order the directory contents to achieve the desired effect ... it all depends upon the specifics of the definition of the config language. But do think about this - it isn't too hard to add an ordering mechanism in the original design (and then if it turns out to be superfluous, just ignore it), but it is hard to retro-fit, as by that stage you need to deal with existing configurations. If some kind of ordering is wanted, then the method used by /etc/rc (or something like it) is orders of magnitude better, and easier to manage, then the horrible numbered file technique that the Sys V init used for its init.d (and has been used in various other places) which is manageable only when the number of files to be ordered is very small, and changes rarely. kre
Re: inetd enhancements - config syntax
On Jan 14, 12:21, James Browning wrote: } } >I also don't like the only form of include being include-a-directory; } >in my estimation, that wires too much policy into the mechanism. I } >would prefer to see either two include directives, one for directories } >and one for files, or a single directive that somehow subsumes both. } >(Two ways come to mind immediately. (A) if the argument names a file, } >it's a file include; if a directory, a directory include. (B) to } >include files in a directory, write something like "include dir/*" or } >"include dir/*.conf" or something of the sort. Though there is the } >conflict with a possible service named "include" - perhaps ".include"?) } } We like the idea of being able to include files along with } directories. Our current plan is to implement directories first, } along with files if time permits us. If we don't have time to } implement include-a-file, then we will make sure our include-a-directory } implementation can easily be extended to support fies in the future. You should really start by implementing functionality to include files as that is your base. The way to implement including directories is to stat the item being included to see if it is a directory, and if it is, then branch to a routine that will scan the directory and call the file inclusion routine on each file found (skipping . and .. of course). If the item being included is a file, then simply make a call to the file inclusion routine. It isn't possible to include a directory without also being able to include a file. It is just a matter of properly modularising the code so that the routine to include a file is separate. }-- End of excerpt from James Browning
Re: inetd enhancements - config syntax
>> That should be true only if you specify a listening address with no >> command. If it works that way when a command is given on the same >> line, that's a bug that needs fixing. > There is no bug, and it is working correctly in the way you > described. To avoid potential misunderstandings in the future, it > may be a good idea to update the man page to make it explicitly clear > [...current wording...] > To avoid the need to repeat listen addresses over and over again, > listen addresses are inherited from line to line, and the listen > address can be changed without defining a service by including a line > containing just a listen-addr followed by a colon. Someone changed it since I last touched it, then; that is not my wording from 1996. The wording I committed (which as far as I'm concerned you're welcome to reuse, in whole or part) was +For Internet services, the first field of the line may also have a host +address specifier prefixed to it, separated from the service name by a +colon. If this is done, the string before the colon in the first field +indiciates what local address +.Nm +should use when listening for that service, or the single character +.Dq \&* +to indicate +.Dv INADDR_ANY , +meaning +.Sq all local addresses . +To avoid repeating an address that occurs frequently, a line with a +host address specifier and colon, but no further fields, causes the +host address specifier to be remembered and used for all further lines +with no explicit host specifier (until another such line or the end of +the file). A line +.Dl *: +is implicitly provided at the top of the file; thus, traditional +configuration files (which have no host address specifiers) will be +interpreted in the traditional manner, with all services listened for +on all local addresses. +.Pp I don't know what led to this wording being replaced. (Oops, I just now noticed the typo "indiciates" in the above.) I agree the wording you quote sounds as though it works the way you outlined. It's total speculation, but, perhaps someone intended to change the code but ended up changing only the manpage? /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: inetd enhancements - config syntax
>That should be true only if you specify a listening address with no >command. If it works that way when a command is given on the same >line, that's a bug that needs fixing. (I feel moderately authoritative >on this matter since I'm the person who added the code back in 1996.) Our apologies. There is no bug, and it is working correctly in the way you described. To avoid potential misunderstandings in the future, it may be a good idea to update the man page to make it explicitly clear that [listen-addr:] only changes the listen address for that service, unless it is followed by a newline character. Currently that part of the man page reads: To avoid the need to repeat listen addresses over and over again, listen addresses are inherited from line to line, and the listen address can be changed without defining a service by including a line containing just a listen-addr followed by a colon. I suggest: To avoid the need to repeat listen addresses over and over again, listen addresses can be inherited from line to line by specifying a listen address, followed by a colon and newline. Specification of a listen address followed by a service definition will not be inherited on the following lines We can do this while we also update the man page to reflect the undocumented [,arg] Christos mentioned.
Re: inetd enhancements - config syntax
>> inetd.conf already supports per-service overriding of the >> listen-addr. According to cvsweb, this went in 1996-12-30 (inetd.8 >> rev 1.8, inetd.c rev 1.16). > Itâ??s true that inetd currently supports specification of the > listen-addr, however, the way it currently functions is that when > [listen-addr:] is used, it changes the default listening address for > all services in the remainder of the conf file, or until it is > changed again (meaning that if you only want to set a specific > address for one service, you will need to use [listen-addr:] twice, > once to change the listening address, and again to change it back). That should be true only if you specify a listening address with no command. If it works that way when a command is given on the same line, that's a bug that needs fixing. (I feel moderately authoritative on this matter since I'm the person who added the code back in 1996.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: inetd enhancements - config syntax
On Thu, Jan 14, 2021 at 12:21:14PM -0800, James Browning wrote: > > Our reasoning behind not wanting multiple levels of includedir was to avoid > overly complex or messy configuration systems, but we see your point. If time > allows, then we will implement cycle detection. > If people want to shoot themselves in the foot then you should let them, allowing multiple includes allows a competent person to structure their files and avoid duplication. Detecting cycles is simple, just count the number of include tokens seen and error out after an arbitrary number if the number is large enough then a legitimate configuration will work but an include loop will error out quickly. -- Brett Lymn -- Sent from my NetBSD device. "We are were wolves", "You mean werewolves?", "No we were wolves, now we are something else entirely", "Oh"
Re: inetd enhancements - config syntax
>That's not the only use for escapes. From a theoretical and aesthetic >perspective, it would be nice to be able to get arbitrary octet >sequences into arguments; as outlined, for example, it's not possible >to get a newline into an argument. (Well, _almost_ arbitrary octet >sequences. Until and unless the underlying C issues are fixed or >worked around, zero octets will have to stay reserved as terminators.) We will definitely consider adding some escape sequence functionality to the syntax. At this point for us it more of a question of time constraints, but we like your idea about octet sequences. Since it seems that current implementation of inetd doesn’t support escape sequences, we may not implement this right away. >Cycles...mabe. Multiple levels of includedir - what's wrong with >that? That is, why is avoiding it a Good Thing? Forbidding nesting >includes strikes me as instance of preventing stupid things and thereby >preventing clever things. Our reasoning behind not wanting multiple levels of includedir was to avoid overly complex or messy configuration systems, but we see your point. If time allows, then we will implement cycle detection. >I also don't like the only form of include being include-a-directory; >in my estimation, that wires too much policy into the mechanism. I >would prefer to see either two include directives, one for directories >and one for files, or a single directive that somehow subsumes both. >(Two ways come to mind immediately. (A) if the argument names a file, >it's a file include; if a directory, a directory include. (B) to >include files in a directory, write something like "include dir/*" or >"include dir/*.conf" or something of the sort. Though there is the >conflict with a possible service named "include" - perhaps ".include"?) We like the idea of being able to include files along with directories. Our current plan is to implement directories first, along with files if time permits us. If we don’t have time to implement include-a-file, then we will make sure our include-a-directory implementation can easily be extended to support fies in the future. >inetd.conf already supports per-service overriding of the listen-addr. >According to cvsweb, this went in 1996-12-30 (inetd.8 rev 1.8, inetd.c >rev 1.16). It’s true that inetd currently supports specification of the listen-addr, however, the way it currently functions is that when [listen-addr:] is used, it changes the default listening address for all services in the remainder of the conf file, or until it is changed again (meaning that if you only want to set a specific address for one service, you will need to use [listen-addr:] twice, once to change the listening address, and again to change it back). In our new syntax, we think a service should be able to change its own listening address (with a key-value pair) without changing the “global” [listen-addr] value. Thank you for your input, inetd Team
Re: inetd enhancements - config syntax
> The new syntax would look something like:
> on/off key1=value, key2=value1 value2 value3,
> key3=â??this is a valueâ??, key4=value1 value2 â??this is value3â??;
Hm. I think this is about as good a new syntax as we're likely to get.
In particular, it offers a fairly wide variety of extensibility
possibilities for the future.
> 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. [...] 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?)
That's not the only use for escapes. From a theoretical and aesthetic
perspective, it would be nice to be able to get arbitrary octet
sequences into arguments; as outlined, for example, it's not possible
to get a newline into an argument. (Well, _almost_ arbitrary octet
sequences. Until and unless the underlying C issues are fixed or
worked around, zero octets will have to stay reserved as terminators.)
And, if it is ever extended to, for example, support compound values
with something like key={...}, there will still be a way to get the old
semantics if there is a uniform quoting mechanism.
> 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.
Cycles...mabe. Multiple levels of includedir - what's wrong with
that? That is, why is avoiding it a Good Thing? Forbidding nesting
includes strikes me as instance of preventing stupid things and thereby
preventing clever things.
I also don't like the only form of include being include-a-directory;
in my estimation, that wires too much policy into the mechanism. I
would prefer to see either two include directives, one for directories
and one for files, or a single directive that somehow subsumes both.
(Two ways come to mind immediately. (A) if the argument names a file,
it's a file include; if a directory, a directory include. (B) to
include files in a directory, write something like "include dir/*" or
"include dir/*.conf" or something of the sort. Though there is the
conflict with a possible service named "include" - perhaps ".include"?)
> 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.
inetd.conf already supports per-service overriding of the listen-addr.
According to cvsweb, this went in 1996-12-30 (inetd.8 rev 1.8, inetd.c
rev 1.16).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
inetd enhancements - config syntax
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: 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
