On 26-Jun-99 Sheldon Hearn wrote:
On Fri, 25 Jun 1999 13:02:00 MST, Aaron Smith wrote:
with it. i didn't realize there was an extension already in place -- i
should have checked the man page over when i saw sheldon's first message
about "wait/10/10/nowrap".
There isn't. It's a proposed
On 26-Jun-99 Sheldon Hearn wrote:
On Fri, 25 Jun 1999 13:02:00 MST, Aaron Smith wrote:
with it. i didn't realize there was an extension already in place -- i
should have checked the man page over when i saw sheldon's first message
about wait/10/10/nowrap.
There isn't. It's a proposed
do you propose to solve this with the internal
wrapping (which is a good idea, IMO as it eliminates an exec())?
Run two copies of inetd?
Seriously, if wrapping support can be tuned at runtime, and you can
set up inetd to run with different configuration files (which you can),
if those people who
On 25-Jun-99 Aaron Smith wrote:
On Fri, 25 Jun 1999 10:14:48 +0200, Sheldon Hearn writes:
I think I prefer the suggestion I saw from someone else, which would
allow
ftp stream tcp nowait/10/10/wrap root ...
This can be done in such a way as to be backward compatible. Looks like
On 25-Jun-99 Drew Eckhardt wrote:
In article [EMAIL PROTECTED] you write:
Here's one possibility, it adds a a wrap/nowrap field that goes beside the
wait/nowait field, so you would have:
ftp stream tcp nowait wrap root /usr/libexec/ftpd ftpd
-l
Breaking backwards
On Fri, 25 Jun 1999, David Malone wrote:
Some people think that doing the hosts.allow lookup is too expensive
for some services but not others. (It requires opening /etc/hosts.allow,
reading it in line by line and possibly doing DNS lookups).
I would hope that anyone concerned about speed
On Sun, 27 Jun 1999 22:26:34 EDT, John Baldwin writes:
Let's say I have two services, foo and bar, with food and bard. I want to
wrap food, but *NOT* bard and they are both in /etc/inetd.conf. How do
you propose to solve this with the internal wrapping (which is a good
idea, IMO as it
On 25-Jun-99 Aaron Smith wrote:
On Fri, 25 Jun 1999 10:14:48 +0200, Sheldon Hearn writes:
I think I prefer the suggestion I saw from someone else, which would
allow
ftp stream tcp nowait/10/10/wrap root ...
This can be done in such a way as to be backward compatible. Looks like
On 25-Jun-99 Drew Eckhardt wrote:
In article 199906242353.taa06...@smtp4.erols.com you write:
Here's one possibility, it adds a a wrap/nowrap field that goes beside the
wait/nowait field, so you would have:
ftp stream tcp nowait wrap root /usr/libexec/ftpd ftpd
-l
On Fri, 25 Jun 1999, David Malone wrote:
Some people think that doing the hosts.allow lookup is too expensive
for some services but not others. (It requires opening /etc/hosts.allow,
reading it in line by line and possibly doing DNS lookups).
I would hope that anyone concerned about speed
On Sun, 27 Jun 1999 22:26:34 EDT, John Baldwin writes:
Let's say I have two services, foo and bar, with food and bard. I want to
wrap food, but *NOT* bard and they are both in /etc/inetd.conf. How do
you propose to solve this with the internal wrapping (which is a good
idea, IMO as it eliminates
On Sat, Jun 26, 1999 at 06:55:53AM +0200, Sheldon Hearn wrote:
I don't think the core team would care enough about something this silly
to bother making a decision, so I'm just watching what people have to
say. I'm leaning toward leaving the nowrap feature out.
FWIW, I think that leaving out
On Thu, 24 Jun 1999 19:53:08 -0400, John Baldwin wrote:
Here's one possibility, it adds a a wrap/nowrap field that goes beside the
wait/nowait field, so you would have:
ftp stream tcp nowait wrap root /usr/libexec/ftpd ftpd
-l
hi John,
I think I prefer the
On Fri, 25 Jun 1999 10:14:48 +0200, Sheldon Hearn writes:
I think I prefer the suggestion I saw from someone else, which would
allow
ftpstream tcp nowait/10/10/wrap root ...
This can be done in such a way as to be backward compatible. Looks like
something for the week-end, if I can
On Fri, 25 Jun 1999 05:44:06 MST, Aaron Smith wrote:
could you please restate the argument for this? i still haven't heard a
decent reason for this sort of conf format perturbation.
I'm so tempted to say me too. :-)
John Baldwin has suggested that he had functionality with inetd + tcpd
that
On Fri, Jun 25, 1999 at 02:50:34PM +0200, Sheldon Hearn wrote:
On Fri, 25 Jun 1999 05:44:06 MST, Aaron Smith wrote:
could you please restate the argument for this? i still haven't heard a
decent reason for this sort of conf format perturbation.
I'm so tempted to say me too. :-)
John
On Fri, 25 Jun 1999 09:31:26 -0400, Keith Stevenson wrote:
What is possible now that wasn't possible with tcpd from the ports
collection? Why incorporate libwrap (and make our inetd functionally
different from everyone else's) instead of bringing tcpd into the base
system?
If we _don't_
On Fri, Jun 25, 1999 at 04:05:05PM +0200, Sheldon Hearn wrote:
On Fri, 25 Jun 1999 09:31:26 -0400, Keith Stevenson wrote:
What is possible now that wasn't possible with tcpd from the ports
collection? Why incorporate libwrap (and make our inetd functionally
different from everyone
On Fri, 25 Jun 1999 16:05:05 +0200, Sheldon Hearn writes:
We'll also end up with an inetd that _can_ wrap if it's told to (-w
and -ww). So we end up offering a better super-server than we had
before, with no backward compatibility problems, and no additional
incompatibilities with other systems (I
On Fri, Jun 25, 1999 at 11:02:04AM -0700, Aaron Smith wrote:
i have no problem with -w options, but i am still surprised that you want
to go ahead with the conf format change.
This isn't so much a conf format change, as a conf format extension.
It is the same type of extension as was added to
On Fri, 25 Jun 1999 20:12:01 BST, David Malone writes:
This isn't so much a conf format change, as a conf format extension.
It is the same type of extension as was added to support max child
and max child per minute - which aren't a standard inetd feature.
All old inetd.conf files remain valid.
In article 199906242353.taa06...@smtp4.erols.com you write:
Here's one possibility, it adds a a wrap/nowrap field that goes beside the
wait/nowait field, so you would have:
ftp stream tcp nowait wrap root /usr/libexec/ftpd ftpd -l
Breaking backwards compatability is evil.
On Fri, 25 Jun 1999 13:02:00 MST, Aaron Smith wrote:
hey, that's a pretty neat feature. i confess i wasn't aware of that. out
of curiosity, can old inetds read this without choking?
No, the extension would cause older inetd's to barf.
agreed; what i was trying to get at is the mental
excluding the overhead to check
the
hosts.allow file. On a heavily loaded service this can be considerable.
It's critical that folks understand that built-in wrapping in inetd is
not the same as inetd passing the job of wrapping to a program called
tcpd. Something different is happening in each case
On Thu, 24 Jun 1999 01:53:32 MST, Doug wrote:
As long as you acknowledge that in this case, You can't have it is a
design decision, and not everyone agrees with your concept of the design.
Personally I don't care enough about it to write the patch, but that won't
stop me from registering an
On 24-Jun-99 Sheldon Hearn wrote:
On Thu, 24 Jun 1999 01:53:32 MST, Doug wrote:
As long as you acknowledge that in this case, You can't have it is a
design decision, and not everyone agrees with your concept of the design.
Personally I don't care enough about it to write the patch, but
the
hosts_options(5) "severity" option to assign a syslog
selector to the messages generated for a service and tune
syslog.conf to get messages to the right log destinations.
It's critical that folks understand that built-in wrapping in inetd is
not the same as inetd passi
the
hosts_options(5) severity option to assign a syslog
selector to the messages generated for a service and tune
syslog.conf to get messages to the right log destinations.
It's critical that folks understand that built-in wrapping in inetd is
not the same as inetd passing the job
On Mon, 21 Jun 1999 17:47:10 -0400, John Baldwin wrote:
I suppose you could a field wrap/nowrap like the wait/nowait field..
but then you'd be butchering the sacred cow of the inetd.conf
format...
I don't see why people want to make inetd responsible for per-case
exclusions from the default
On 22-Jun-99 Sheldon Hearn wrote:
On Mon, 21 Jun 1999 17:47:10 -0400, John Baldwin wrote:
I suppose you could a field wrap/nowrap like the wait/nowait field..
but then you'd be butchering the sacred cow of the inetd.conf
format...
I don't see why people want to make inetd responsible
On Tue, 22 Jun 1999 07:04:29 -0400, John Baldwin wrote:
Because that only controls access, it does not actually turn wrapping off.
Let me be more specific; if you don't want ftpd wrapped, just add
ftpd: ALL : ALLOW
to your /etc/hosts.allow . A stock configuration won't log successful
On Tue, 22 Jun 1999, Sheldon Hearn wrote:
On Tue, 22 Jun 1999 07:04:29 -0400, John Baldwin wrote:
Because that only controls access, it does not actually turn wrapping off.
Let me be more specific; if you don't want ftpd wrapped, just add
ftpd: ALL : ALLOW
to your /etc/hosts.allow .
On Tue, 22 Jun 1999 14:53:28 GMT, Ben Rosengart wrote:
But if you can turn off wrapping, you can save a fork()/exec() per
connection.
The only exec is an execv() at line 740 of inetd.c, which launches the
program that will service a request. It's done irrespective of wrapping.
So you can
On Tue, 22 Jun 1999, Sheldon Hearn wrote:
On Tue, 22 Jun 1999 14:53:28 GMT, Ben Rosengart wrote:
But if you can turn off wrapping, you can save a fork()/exec() per
connection.
The only exec is an execv() at line 740 of inetd.c, which launches the
program that will service a request.
On 22-Jun-99 Sheldon Hearn wrote:
On Tue, 22 Jun 1999 07:04:29 -0400, John Baldwin wrote:
Because that only controls access, it does not actually turn wrapping off.
Let me be more specific; if you don't want ftpd wrapped, just add
ftpd: ALL : ALLOW
That still wraps, it just allows
Folks, public feedback on the following portion of David's mail would be
much appreciated. Since resolution of UDP wrapping would bring about the
execution of the we want tcpd campaign, it's obviously something that
both David and I would like to see finished off.
It's just that we'd like it
Folks, public feedback on the following portion of David's mail would be
much appreciated. Since resolution of UDP wrapping would bring about the
execution of the we want tcpd campaign, it's obviously something that
both David and I would like to see finished off.
I got one person who
On Mon, 21 Jun 1999 14:13:49 +0100, David Malone wrote:
I got one person who suggested a flag in inetd.conf which could disable
wrapping for a service. This seems like quite a good idea if we can come
up with an acceptable syntax for the flag.
What I have in mind is a -w option. Specified
On Mon, Jun 21, 1999 at 02:13:49PM +0100, David Malone wrote:
Folks, public feedback on the following portion of David's mail would be
much appreciated. Since resolution of UDP wrapping would bring about the
execution of the we want tcpd campaign, it's obviously something that
both David
On Mon, Jun 21, 1999 at 02:26:35PM +0100, Dom Mitchell wrote:
inetd.conf is one of those things, like newsyslog.conf which is long
past due for an overhaul...
Some would say the same for inetd. Without wanting to start a flame war,
tcpserver (part of the sysutils/ucspi-tcp port) has some
Sheldon Hearn wrote:
On Mon, 21 Jun 1999 14:13:49 +0100, David Malone wrote:
I got one person who suggested a flag in inetd.conf which could disable
wrapping for a service. This seems like quite a good idea if we can come
up with an acceptable syntax for the flag.
What I have in mind
On Mon, 21 Jun 1999 07:58:58 MST, Doug wrote:
When exactly was it made the default? Prior to 3.2-Release, or after?
It's never (ok, rarely) too late to undo a bad decision. If the change
happened after the latest -Release, by all means, back it out.
Cvsweb says it happened
On 21-Jun-99 David Malone wrote:
Folks, public feedback on the following portion of David's mail would be
much appreciated. Since resolution of UDP wrapping would bring about the
execution of the we want tcpd campaign, it's obviously something that
both David and I would like to see finished
The support (after the patches Sheldon brought in) now is
pretty good; is there any reason why the existing functionality should be
extended ?
We should support atleast as much as tcpd did. I think the only
thing we're missing now is wrapping the first connection of a
udp/wait service and
Sheldon and myself have been looking at the wrapping support in inetd, and
I'd be interested to hear what people think on the following issues.
David.
Making wrapping a run time option:
It seems strange to make wrapping a compile time option,
when it could be a command
On Fri, 18 Jun 1999 14:11:26 +0100, David Malone wrote:
Sheldon and myself have been looking at the wrapping support in inetd, and
I'd be interested to hear what people think on the following issues.
Is the general consensus that we absolutely must have wrapper support
built into inetd? What
On Fri, Jun 18, 1999 at 03:30:03PM +0200, Sheldon Hearn wrote:
Is the general consensus that we absolutely must have wrapper support
built into inetd? What we've got right now isn't doing a fantastic job,
and trying to wedge in the job tcpd did before is getting progressively
uglier. :-(
I
Around Today, David Malone wrote :
DM I think we may almost be there, and we've unearther problems with inetd
DM that were there anyway - but not as obvious without wrapping. While the
DM process is painful I think the end result may be OK.
As a user, I'd say that it would certainly be nice
Hi folks,
I'm looking for feedback on the fix that is attached to PR 11651, which
I believe fixes wrapping for inetd's internal services.
I found the code quite intense, so I'm not entirely convinced that my
approach is sound.
Thanks,
Sheldon.
To Unsubscribe: send mail to
49 matches
Mail list logo
