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 pro
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 prop
On Sun 1999-06-27 (22:26), John Baldwin wrote:
> > if people have their undies in a wad over this, can't they compile
> > inetd without LIBWRAP?
>
> Ahem..
>
> 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.
On Sun 1999-06-27 (22:26), John Baldwin wrote:
> > if people have their undies in a wad over this, can't they compile
> > inetd without LIBWRAP?
>
> Ahem..
>
> 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.c
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 elimin
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 elimina
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 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 w
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
>
> Breaki
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 ft
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
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
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 leavi
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 leavin
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 d
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 di
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 compatability is evil. Do somethin
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
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
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.
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, 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 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 system
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
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 ever
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 every
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'
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 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".
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". :
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
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
t
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
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 c
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 sugg
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 su
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
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
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 register
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 registeri
Sheldon Hearn wrote:
> I used to pride myself in my communication skills, but I'm starting to
> doubt myself. :-)
It's not that we don't understand you, it's that we don't agree with you.
There is a HUGE difference.
> My concern is that what you want introduces duplicate functionality.
Sheldon Hearn wrote:
> I used to pride myself in my communication skills, but I'm starting to
> doubt myself. :-)
It's not that we don't understand you, it's that we don't agree with
you.
There is a HUGE difference.
> My concern is that what you want introduces duplicate functionality.
On Tue, 22 Jun 1999 18:18:34 -0400, John Baldwin wrote:
> But if I want to log *all* connections to service foo, but not bar, I
> could not use tcpd for foo and and bar by itself and achieve that, so
> you are removing some configurability. If very few people use this
> extra configurability a
On Tue, 22 Jun 1999 18:18:34 -0400, John Baldwin wrote:
> But if I want to log *all* connections to service foo, but not bar, I
> could not use tcpd for foo and and bar by itself and achieve that, so
> you are removing some configurability. If very few people use this
> extra configurability an
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 ju
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 jus
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 re
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 s
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 req
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 sa
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/hos
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/host
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
conne
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
connec
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
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
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 defa
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 defau
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
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
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 _b
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 ha
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 disti
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
> > bot
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
> 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 su
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 f
> 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 t
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 ni
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
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? Wha
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 li
72 matches
Mail list logo
