tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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:
> 	<whatever spec to start the first server>
> and private-stuff/service2 contains just
> 	<whatever spec to start the second server>

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:
	<service specs>

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 HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index