Re: Inetd and wrapping.
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 extension that might happen soon. :-) in order to make this compatible won't one have to specify the not-so-pretty "wait/0/0/nowrap"? i guess "wait/nowrap" could be made to work. that's less ugly. Actually, any of the following ought to work: wait/nowrap wait/10/nowrap wait/10/10/nowrap wait/nowrap/10wait/10/nowrap/10 As well as the previous permutations available. We're lucky because "nowrap" isn't a number, so it can't be confused with a request to set max_child nor max_cpm. i am less bothered by this change given the maxchild precedent, if there are definitely people who will *use* this. if people don't actually use it, it will just become a chunk of legacy extra-complexity. I think you may have as many as two people using it. :-\ As I said earlier, if no else wants this and if everyone hates this (which appears to be the case), then you don't have to add it.. majority rule wins. Some viable solutions (such as running two inetd's and sucking up the rather small performance hit and running regular tcpd) have been offered so that the rare functionality I mentioned is still available. I didn't realize adding another tunable know was such an evil hack (I did realize that my original idea of using a seperate flag was an evil hack and has made the original suggestion in a previous post of the wait/(wrao|nowrap) thingamajig). Guess "show me the code" doesn't always work.. :) all: sorry if i came off too strident. i have a sore spot for feeping creaturism. :) Don't be sorry. It's about time people started articulating my rebuttal. ;-) 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. If it hurts, then by all means. If not, then why design out extra configurability? However, it's no big deal and I'll be content with whatever decision you come to. Note that this would solve the -w(e|i) solution that Doug(?) requested in a more orthogonal way... Ciao, Sheldon. --- John Baldwin [EMAIL PROTECTED] -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
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 extension that might happen soon. :-) in order to make this compatible won't one have to specify the not-so-pretty wait/0/0/nowrap? i guess wait/nowrap could be made to work. that's less ugly. Actually, any of the following ought to work: wait/nowrap wait/10/nowrap wait/10/10/nowrap wait/nowrap/10wait/10/nowrap/10 As well as the previous permutations available. We're lucky because nowrap isn't a number, so it can't be confused with a request to set max_child nor max_cpm. i am less bothered by this change given the maxchild precedent, if there are definitely people who will *use* this. if people don't actually use it, it will just become a chunk of legacy extra-complexity. I think you may have as many as two people using it. :-\ As I said earlier, if no else wants this and if everyone hates this (which appears to be the case), then you don't have to add it.. majority rule wins. Some viable solutions (such as running two inetd's and sucking up the rather small performance hit and running regular tcpd) have been offered so that the rare functionality I mentioned is still available. I didn't realize adding another tunable know was such an evil hack (I did realize that my original idea of using a seperate flag was an evil hack and has made the original suggestion in a previous post of the wait/(wrao|nowrap) thingamajig). Guess show me the code doesn't always work.. :) all: sorry if i came off too strident. i have a sore spot for feeping creaturism. :) Don't be sorry. It's about time people started articulating my rebuttal. ;-) 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. If it hurts, then by all means. If not, then why design out extra configurability? However, it's no big deal and I'll be content with whatever decision you come to. Note that this would solve the -w(e|i) solution that Doug(?) requested in a more orthogonal way... Ciao, Sheldon. --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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.conf. How 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 want to run both wrapped and non-wrapped services agree that this is an option, there needn't be a hack to do this sort of thing. Neil -- Neil Blakey-Milner n...@rucus.ru.ac.za To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 something for the week-end, if I can convince my wife that it's a good idea. :-) could you please restate the argument for this? i still haven't heard a decent reason for this sort of conf format perturbation. every small whack like this makes freebsd weirder to administrate -- there is a value to sharing the same inetd.conf format with lots of other platforms. 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.conf. How do you propose to solve this with the internal wrapping (which is a good idea, IMO as it eliminates an exec())? aaron --- John Baldwin [EMAIL PROTECTED] -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
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 compatability is evil. Do something like this instead - ftp stream tcp nowaitwrap root /usr/libexec/ftpd ftpd -l That's easy to change (just change where it reads the wrap/nowrap whatever in the last half of the patch). It was more of a proof of concept to show that it could be easily done in 10 minutes or so. --- John Baldwin [EMAIL PROTECTED] -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
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 would be writing tcp-wrappers rules with numbers, not names. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
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 an exec())? i wouldn't...i'd have to either pay the (small) cost of wrapping or pay the (less small) tcpd exec and not use internal wrapping. it's "nice" to save the exec, but intensely performance or latency sensitive daemons probably shouldn't be starting out of inetd, they should be standalone and preforked or threaded... aaron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
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 something for the week-end, if I can convince my wife that it's a good idea. :-) could you please restate the argument for this? i still haven't heard a decent reason for this sort of conf format perturbation. every small whack like this makes freebsd weirder to administrate -- there is a value to sharing the same inetd.conf format with lots of other platforms. 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.conf. How do you propose to solve this with the internal wrapping (which is a good idea, IMO as it eliminates an exec())? aaron --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 Breaking backwards compatability is evil. Do something like this instead - ftp stream tcp nowaitwrap root /usr/libexec/ftpd ftpd -l That's easy to change (just change where it reads the wrap/nowrap whatever in the last half of the patch). It was more of a proof of concept to show that it could be easily done in 10 minutes or so. --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 would be writing tcp-wrappers rules with numbers, not names. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 an exec())? i wouldn't...i'd have to either pay the (small) cost of wrapping or pay the (less small) tcpd exec and not use internal wrapping. it's nice to save the exec, but intensely performance or latency sensitive daemons probably shouldn't be starting out of inetd, they should be standalone and preforked or threaded... aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 the nowrap feature would be a very good idea. I'm willing to agree (somewhat grudgingly) that incorporating libwrap is a definite feature improvement, but this conf file change doesn't seem to buy much at all. If a user needs that level of granularity, they can disable libwrap support on the inetd command line and use tcpd. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 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 something for the week-end, if I can convince my wife that it's a good idea. :-) Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 convince my wife that it's a good idea. :-) could you please restate the argument for this? i still haven't heard a decent reason for this sort of conf format perturbation. every small whack like this makes freebsd weirder to administrate -- there is a value to sharing the same inetd.conf format with lots of other platforms. if people have their undies in a wad over this, can't they compile inetd without LIBWRAP? aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 he doesn't have any more with inetd + libwrap. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 Baldwin has suggested that he had functionality with inetd + tcpd that he doesn't have any more with inetd + libwrap. As much as I appreciate the work that has gone into adding this feature to inetd, I'm starting to wonder if it is causing more harm than good. One of the things I good-naturedly complain about to my Linux-using friends is the large number of seemingly gratuitous changes which make Linux different that other similar operating systems. As well-intentioned as adding libwrap support to inetd was, I'm having trouble finding a justification for the change. 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? I realize that I'm more than a bit late in raising these issues. I didn't even realize that libwrap had been added to inetd until Mark Murray told me at USENIX. (Somehow I missed all of the announcements.) Assuming that it is too late to undo the changes to inetd, I'd like to urge that we not also start tinkering with the format of inetd.conf. I'm just not comfortable with creating FreeBSD-isms when there isn't a clear improvement in functionality. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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_ use tcpd, we save an exec on every call to every wrapped service. I know we're all worried about creeping featurisms, but think about what we'll end up with here. We'll end up with an inetd that does _not_ wrap by default (discussed with jkh in private mail). So people wanting to carry on using tcpd stubbornly will be more than welcome to do so. 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 can't find an inetd that uses the -w flag for anything). I realize that I'm more than a bit late in raising these issues. Not at all, so long as you don't manage to convince us that we've gone in the wrong direction. ;-) The additional option in inetd.conf is not something I want. However, it's something someone has made a legitimate public argument for, to which I can't come up with a decent rebuttal. The ``nowrap'' option in inetd.conf will be something specific to FreeBSD, I agree, but it's something you and me and the rest of the sane universe can happily do without -- you won't have to edit your inetd.conf just to cope with this FreeBSD-specific change. Ciaol, Sheldon (who is quickly learning that you can't please 'em all at all) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 else's) instead of bringing tcpd into the base system? If we _don't_ use tcpd, we save an exec on every call to every wrapped service. Ok, I can see that as a win, especially for very busy servers. (I'm thinking ISPs here.) I know we're all worried about creeping featurisms, but think about what we'll end up with here. We'll end up with an inetd that does _not_ wrap by default (discussed with jkh in private mail). So people wanting to carry on using tcpd stubbornly will be more than welcome to do so. 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 can't find an inetd that uses the -w flag for anything). Good. I was worried that we would have to add a flag to turn wrapping off. This makes the change much more palatable. The additional option in inetd.conf is not something I want. However, it's something someone has made a legitimate public argument for, to which I can't come up with a decent rebuttal. As long as this new option can safely be omitted by those of us who prefer a more traditional approach, I can't argue about it too much either. The purist in me doesn't like it, but I can't come up with a rebuttal either. Ciaol, Sheldon (who is quickly learning that you can't please 'em all at all) Only a fool\h\h\h\h optimist tries to... :) Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 can't find an inetd that uses the -w flag for anything). hi sheldon, i have no problem with -w options, but i am still surprised that you want to go ahead with the conf format change. i'm going to present my rebuttal here, but the only argument i could dig up was there is missing functionality. (john baldwin? not sure) raised the issue that before, he could control which services were wrapped. now, all services are wrapped. why is this bad? what has been lost? can the user no longer get the old behavior? no, he can. undefining LIBWRAP at compile time (or a runtime flag) plus tcpd gets him exactly where he was before. this will be even less of an issue with -w flags or an inverted default. performance incurred by reading default allow rules on invocations? no, for several reasons. the hosts.allow file is going to be in the cache. the design is first matched, so one can also place the service one is concerned about at the beginning of the lists. but third and most importantly: if startup performance is an issue to the extent that the small overhead of this call is important, you should not be using inetd. you should have a standalone daemon. (which you can decide to wrap or not wrap). the overhead here is going to in reality be small. logging configurability? i seem to remember something about this, and while i am trying to come up with a difference, i can't see one. hosts.allow is very configurable logging wise. the messages come from inetd, yes...but they can be separated out by severity/facility. i can't imagine logging differences is a good reason. so to this one too i have to say no. we already have a service-by-service control file hosts.allow that provides the ability to in EFFECT control what gets wrapped. please do not duplicate that functionality again -- we can do without it. it's an additional complexity that buys us *nothing*. The additional option in inetd.conf is not something I want. However, it's something someone has made a legitimate public argument for, to which I can't come up with a decent rebuttal. i hope i've made a persuasive case that a *conf file format change* isn't justified here. it doesn't make sense, especially if you are, as you have mentioned, going to switch unwrapped to default and require -w for wrapping. thanks, aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 support max child and max child per minute - which aren't a standard inetd feature. All old inetd.conf files remain valid. (It's not like inetd.conf is all that machine independant anyway, as it is full of paths to programs and contains services specific to that machine. You'd never condider rdisting it between machines of a different architecture for example). (john baldwin? not sure) raised the issue that before, he could control which services were wrapped. now, all services are wrapped. why is this bad? what has been lost? 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 wouldn't say it actually makes that much difference 'cos very few people provide really high performance services from inetd, and the hit from tcp wrapping isn't all that high (we run our smtpd from inetd first through tcp wrappers and then through a rbl program and then finally the smtpd and don't have any problems with it). David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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. 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? (sheldon said backwards compatible the other day but i'm not sure if he meant upwards compatible...) (It's not like inetd.conf is all that machine independant anyway, as it is full of paths to programs and contains services specific to that machine. You'd never condider rdisting it between machines of a different architecture for example). agreed; what i was trying to get at is the mental difference in dealing 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. in order to make this compatible won't one have to specify the not-so-pretty wait/0/0/nowrap? i guess wait/nowrap could be made to work. that's less ugly. is 0 already an alias for unlimited? i am less bothered by this change given the maxchild precedent, if there are definitely people who will *use* this. if people don't actually use it, it will just become a chunk of legacy extra-complexity. 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). you won't have to go to disk, though (it will be cached for all cases in which you care), and if you've got an early allow rule for the service, you won't have to do any lookups. and like you say, if it's that sensitive, why is it starting out of inetd? all: sorry if i came off too strident. i have a sore spot for feeping creaturism. :) aaron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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. Do something like this instead - ftp stream tcp nowaitwrap root /usr/libexec/ftpd ftpd -l To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 difference in dealing 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 extension that might happen soon. :-) in order to make this compatible won't one have to specify the not-so-pretty wait/0/0/nowrap? i guess wait/nowrap could be made to work. that's less ugly. Actually, any of the following ought to work: wait/nowrap wait/10/nowrap wait/10/10/nowrap wait/nowrap/10 wait/10/nowrap/10 As well as the previous permutations available. We're lucky because nowrap isn't a number, so it can't be confused with a request to set max_child nor max_cpm. i am less bothered by this change given the maxchild precedent, if there are definitely people who will *use* this. if people don't actually use it, it will just become a chunk of legacy extra-complexity. I think you may have as many as two people using it. :-\ all: sorry if i came off too strident. i have a sore spot for feeping creaturism. :) Don't be sorry. It's about time people started articulating my rebuttal. ;-) 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. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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. You keep saying, but you can do something like what you want to do with tcp wrappers, but others are saying, quite clearly that they want to be able to COMPLETELY bypass tcp_wrappers altogether. Configuring tcp_wrappers for a specific case is very different from not having to configure it at all. 1) Performance. I think we're all clear now that exclusion options will not introduce a significant performance gain. We've already scored our performance gain by obviating an exec on tcpd. By excluding tcp_wrappers you're also 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. It just so happens that the two cases share a common goal. Actually, the same thing is happening, just in different places. When you say you want functionality that exists with TCP wrappers, I think you mean identical semantics to those used with tcpd. You can't have it, it's that simple. 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 objection since you seem to be assuming that silence == assent. What you should be able to have is the same functionality as was available when using tcpd. I don't think the fact that you may need to set things up differently to achieve the same results as you had before isn't a serious problem, because you're doing a different thing now. That's because you're looking at this from the standpoint of a developer who is deeply involved in the code on a daily basis. You need to start thinking of things in terms of the much more common case, the casual user who will be going from say, 3.0-Release to 3.3-Release without reading any of the documentation. Why should this user have to either go out of his way to fix something that wasn't broken, or find a critical service disabled when he reboots just because no one could be bothered to make the new interface compatible? As far as I'm concerned the system should ship with per service toggles, and all of them toggled off, with a hosts.allow with nothing but ALL : ALL in it. But then again I've been called overcautious. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 objection since you seem to be assuming that silence == assent. You're right. If I make my intentions publically known and nobody objects, I assume public agreement. So I acknowledge that we're involved in design decisions here. You need to start thinking of things in terms of the much more common case, the casual user who will be going from say, 3.0-Release to 3.3-Release without reading any of the documentation. You're making assumptions about what I'm trying to achieve. I'm quite sensitive to upgrade issues. Why should this user have to either go out of his way to fix something that wasn't broken, or find a critical service disabled when he reboots just because no one could be bothered to make the new interface compatible? Okay, this is what makes sense. :-) I do agree that it should be as easy as possible to upgrade from 3.2-RELEASE to 3.3-RELEASE. What you need to see is that such an upgrade _will_ involve changing some things, which is why we offer people release notes. What we're discussing (and have up until now disagreed on) is how much has to change. Since none of the people who've suggested per-case exclusion options for wrapping have come up with diffs, it's something I'll have to think about. If I can come up with something backward compatible without rupturing a testicle, I'll do so. Watch this space for details. :-) Cia, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 that won't
stop me from registering an objection since you seem to be assuming that
silence == assent.
You're right. If I make my intentions publically known and nobody
objects, I assume public agreement. So I acknowledge that we're involved
in design decisions here.
You need to start thinking of things in terms of the much more common
case, the casual user who will be going from say, 3.0-Release to
3.3-Release without reading any of the documentation.
You're making assumptions about what I'm trying to achieve. I'm quite
sensitive to upgrade issues.
Why should this user have to either go out of his way to fix something
that wasn't broken, or find a critical service disabled when he
reboots just because no one could be bothered to make the new
interface compatible?
Okay, this is what makes sense. :-)
I do agree that it should be as easy as possible to upgrade from
3.2-RELEASE to 3.3-RELEASE. What you need to see is that such an upgrade
_will_ involve changing some things, which is why we offer people
release notes. What we're discussing (and have up until now disagreed
on) is how much has to change.
Since none of the people who've suggested per-case exclusion options
for wrapping have come up with diffs, it's something I'll have to think
about. If I can come up with something backward compatible without
rupturing a testicle, I'll do so.
Watch this space for details. :-)
Ok. since you asked:
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
as an example of ftp being wrapped. here's the patch to inetd.c (against
-stable, which is all I have at the moment):
Index: inetd.c
===
RCS file: /usr/cvs/src/usr.sbin/inetd/inetd.c,v
retrieving revision 1.46.2.2
diff -u -r1.46.2.2 inetd.c
--- inetd.c 1999/05/12 07:02:02 1.46.2.2
+++ inetd.c 1999/06/24 23:36:24
@@ -73,6 +73,7 @@
* socket type stream/dgram/raw/rdm/seqpacket
* protocolmust be in /etc/protocols
* wait/nowait single-threaded/multi-threaded
+ * wrap/nowrap wrapped or not
* useruser to run daemon as
* server program full path name
* server program argumentsmaximum of MAXARGS (20)
@@ -97,6 +98,7 @@
* socket type stream/dgram/raw/rdm/seqpacket
* protocolmust be in /etc/protocols
* wait/nowait single-threaded/multi-threaded
+ * wrap/nowrap wrapped or not
* useruser to run daemon as
* server program full path name
* server program argumentsmaximum of MAXARGS
@@ -215,6 +217,9 @@
u_char se_type;/* type: normal, mux, or mux+ */
u_char se_checked; /* looked at during merge */
u_char se_accept; /* i.e., wait/nowait mode */
+#ifdef LIBWRAP_INTERNAL
+u_char se_wrap;/* wrap/nowrap mode */
+#endif
u_char se_rpc; /* ==1 if RPC service */
int se_rpc_prog;/* RPC program number */
u_int se_rpc_lowvers; /* RPC low version */
@@ -621,6 +626,8 @@
#ifdef LIBWRAP
#ifndef LIBWRAP_INTERNAL
if (sep-se_bi == 0)
+#else
+if (sep-se_wrap)
#endif
if (sep-se_accept
sep-se_socktype == SOCK_STREAM) {
@@ -905,6 +912,9 @@
}
}
sep-se_accept = new-se_accept;
+#ifdef LIBWRAP_INTERNAL
+ sep-se_wrap = new-se_wrap;
+#endif
SWAP(sep-se_user, new-se_user);
SWAP(sep-se_group, new-se_group);
#ifdef LOGIN_CAP
@@ -1377,6 +1387,19 @@
goto more;
}
}
+#ifdef LIBWRAP_INTERNAL
+ arg = sskip(cp);
+ if (!strncmp(arg, wrap, 4))
+ sep-se_wrap = 1;
+else if (!strncmp(arg, nowrap, 6))
+sep-se_wrap = 0;
+else {
+syslog(LOG_ERR,
+%s: bad wrap/nowrap for services %s,
+ CONFIG, sep-se_service);
+ goto more;
+ }
+#endif
sep-se_user = newstr(sskip(cp));
#ifdef LOGIN_CAP
if ((s =
Re: Inetd and wrapping.
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 and if it is a pain to add it in, then I guess it's no real big deal. I used to pride myself in my communication skills, but I'm starting to doubt myself. :-) My concern is that what you want introduces duplicate functionality. I'm not denying that you can't do exactly the same things with inetd that you could with tcpd, but that's to be expected. So far, the mail that I've received which has requested per-case exclusion options has been motivated by two concerns: 1) Performance. I think we're all clear now that exclusion options will not introduce a significant performance gain. We've already scored our performance gain by obviating an exec on tcpd. 2) Logging. I understand that folks want to be able to have their logs look the same as they did when tcpd was in use. That's already not possible, since the wrapping-related messages you see come from inetd[pid] and not tcpd[pid]. I believe that you can have all the messages you used to get going to all the places it used to go, but now using different configuration. Now you should use 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 of wrapping to a program called tcpd. Something different is happening in each case. It just so happens that the two cases share a common goal. When you say you want "functionality that exists with TCP wrappers", I think you mean "identical semantics to those used with tcpd". You can't have it, it's that simple. What you should be able to have is the same functionality as was available when using tcpd. I don't think the fact that you may need to set things up differently to achieve the same results as you had before isn't a serious problem, because you're doing a different thing now. Hopefully this clarifies what's going on in my head. :-) Later, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Inetd and wrapping.
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 and if it is a pain to add it in, then I guess it's no real big deal. I used to pride myself in my communication skills, but I'm starting to doubt myself. :-) My concern is that what you want introduces duplicate functionality. I'm not denying that you can't do exactly the same things with inetd that you could with tcpd, but that's to be expected. So far, the mail that I've received which has requested per-case exclusion options has been motivated by two concerns: 1) Performance. I think we're all clear now that exclusion options will not introduce a significant performance gain. We've already scored our performance gain by obviating an exec on tcpd. 2) Logging. I understand that folks want to be able to have their logs look the same as they did when tcpd was in use. That's already not possible, since the wrapping-related messages you see come from inetd[pid] and not tcpd[pid]. I believe that you can have all the messages you used to get going to all the places it used to go, but now using different configuration. Now you should use 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 of wrapping to a program called tcpd. Something different is happening in each case. It just so happens that the two cases share a common goal. When you say you want functionality that exists with TCP wrappers, I think you mean identical semantics to those used with tcpd. You can't have it, it's that simple. What you should be able to have is the same functionality as was available when using tcpd. I don't think the fact that you may need to set things up differently to achieve the same results as you had before isn't a serious problem, because you're doing a different thing now. Hopefully this clarifies what's going on in my head. :-) Later, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 wrapping behaviour -- that's what hosts.allow was for. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 for per-case exclusions from the default wrapping behaviour -- that's what hosts.allow was for. Because that only controls access, it does not actually turn wrapping off. Wrapping also logs as well as access control. If you use ftp -l -l, then the ftp daemon will produce the same log messages, thus there is no need to have them twice, except to eat up disk space. And if you are only using wrapping for logging purposes, then turning off wrapping on ftpd then cuts out the duplicate messages, allowing you to store more actual logs instead of wasting space on dup's. It's also more orthogonal to allow an on/off switch for each service. Ciao, Sheldon. --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 connections, so you won't see any logging at all. Asking for command-line switches and/or inetd.conf directives that allow per-case exclusions seems to me like asking for duplicate functionality that isn't required (or is that tautology? :-). Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 . A stock configuration won't log successful connections, so you won't see any logging at all. But if you can turn off wrapping, you can save a fork()/exec() per connection. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 save a fork, not an exec. Forks are cheap. I'm not really opposed to having command-line options for per-case exclusions -- I'm just opposed to doing the work myself if it doesn't gain us anything significant. :-) Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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. It's done irrespective of wrapping. So you can save a fork, not an exec. Forks are cheap. Oh, duh. I was still thinking in terms of tcpd, not libwrap. -- Ben UNIX Systems Engineer, Skunk Group StarMedia Network, Inc. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 everyone in. to your /etc/hosts.allow . A stock configuration won't log successful connections, so you won't see any logging at all. 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 and if it is a pain to add it in, then I guess it's no real big deal. Asking for command-line switches and/or inetd.conf directives that allow per-case exclusions seems to me like asking for duplicate functionality that isn't required (or is that tautology? :-). Actually, it's asking for functionality that exists with TCP wrappers, but not with the integrated inetd. Like I said, though, if no one but me is going to miss it, and it is non-trivial to implement, then don't bother. OTOH, if it is trivial to implement, then why remove functionality? Ciao, Sheldon. --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 finished off in a manner that is acceptable
to the more die-hard hackers.
Is committing changes the only way to ellicit DES / bde / other-nasty
responses? ;-)
Thanks,
Sheldon.
On Fri, 18 Jun 1999 14:11:26 +0100, David Malone wrote:
An interesting question is, should we try to do this in a
clever fashion, or should we stick with something simple.
The simple implimentation looks like:
fork(); if( rejected ) exit() else provide_serivce();
The clever implimentation would look like:
fork; while( rejected !timedout ) { get new packet };
if( timedout ) exit() else provide_service();
The clever one reduces forks, but as inetd isn't the place
where high performance services are provided from the extra
complexity may not be worth it.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 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. David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 once, it disables wrapping of internal services. Specified twice, it disables wrapping altogether. It's a pity we went forward the way we did, making wrapping the default for STABLE. I'd have preferred leaving it disabled by default, for maximum backward compatibility. However, now that we're here, I think it'll be a very confusing move to make non-wrapping behaviour the default. There's already a flag in inetd.conf called inetd_flags, in which the administrator could place her -w or -w -w as desired. Ciao, Sheldon. PS: My request for feedback wasn't about the command-ling options. It was about the handling of UDP connections. :-) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 and I would like to see finished off. 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. inetd.conf is one of those things, like newsyslog.conf which is long past due for an overhaul... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator Always think very hard before messing with TCP. And then don't. -- MC -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 distinct advantages over inetd: - Per-service control. Simply use kill -(STOP|CONT) to manage a service, or even better, use supervise/svc from the sysutils/daemontools port. - Built-in wrapping support, which scales better because it uses a hashed, read-only database instead of a textfile. - Non-privileged users can run servers without root having to edit /etc/inetd.conf and HUP inetd. Of course, this only covers TCP-based services. I'll leave mentioning the downsides to other members of the audience. -- Jos Backus _/ _/_/_/ Reliability means never _/ _/ _/ having to say you're sorry. _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ jos.bac...@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 is a -w option. Specified once, it disables wrapping of internal services. Specified twice, it disables wrapping altogether. E It's a pity we went forward the way we did, making wrapping the default for STABLE. When exactly was it made the default? Prior to 3.2-Release, or after? I'd have preferred leaving it disabled by default, for maximum backward compatibility. However, now that we're here, I think it'll be a very confusing move to make non-wrapping behaviour the default. 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. Very few users adopt -Stable compared to the number of users who adopt releases. If the change happened prior to the release, we're stuck with it for all practical purposes. There's already a flag in inetd.conf called inetd_flags, in which the administrator could place her -w or -w -w as desired. It would be more traditionally unix-like to have a flag for wrapping a service (on by default, or not, see above) and a flag for not wrapping. For instance I could start inetd with the -w flag to wrap all services, and then disable one service with a -d for don't wrap, and vv. Doug To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 _before_ 3.2-RELEASE. That's why I plan to leave wrapping turned on by default and providing command-line options for turning it off. If I had a solid support on a decision to reverse the behaviour exhibited in 3.2-RELEASE, I'd do it. :-) It would be more traditionally unix-like to have a flag for wrapping a service (on by default, or not, see above) and a flag for not wrapping. For instance I could start inetd with the -w flag to wrap all services, and then disable one service with a -d for don't wrap, and vv. I agree that -w for enable wrapping would be preferable. I don't agree that an exception option would be cool at all, so that's not something I'll be doing myself. Nevertheless, my understanding of the FreeBSD way leads me to believe that it's a bad idea to reverse the behaviour established for a stable release without solid support. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 off. 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. David. 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... possibly in a non-backwards-compatible fashion. Or you could ugly-hack it using wait/wait-wrap/nowait/nowait-wrap which would be backwards compatible, but ugly nonetheless. Just some ideas. HTH. Personally, I would vote for the first solution, but it may not be practical. --- John Baldwin jobal...@vt.edu -- http://members.freedomnet.com/~jbaldwin/ PGP Key: http://members.freedomnet.com/~jbaldwin/pgpkey.asc Power Users Use the Power to Serve! - http://www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 then inetd can do as much as tcpd could. (Wrapping of internal services is a bonus over what tcpd can do already). I'd be happy with just adding support for wrapping udp stuff and adding a command line flag which turns off wrapping to keep purists happy. I just wanted to see what the general opinion was. David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Inetd and wrapping.
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 line option, or a per service
option in inetd.conf? I'd suggest that we have two command
line options, one which disables wrapping all together and
one which disables it for internal services.
Wrapping dgram services:
If our inetd wrapping is to replace tcpd we need to be able
to wrap the initial connection to udp based services. The
man page should make it clear that it can only check the
first connection to the service, and after that the service
is on its own.
An interesting question is, should we try to do this in a
clever fashion, or should we stick with something simple.
The simple implimentation looks like:
fork(); if( rejected ) exit() else provide_serivce();
The clever implimentation would look like:
fork; while( rejected !timedout ) { get new packet };
if( timedout ) exit() else provide_service();
The clever one reduces forks, but as inetd isn't the place
where high performance services are provided from the extra
complexity may not be worth it.
Making internal services cleverer if they have forked:
If an internal udp service has forked it could provide its
service using a similar loop to the one for clever UDP
wrapping. This would reduce the amount of forking. Is it
worth the extra complexity?
Trying to wrap stream/wait services:
Doing this would involve being able to find the address of
the next connection on a listening socket without calling
accept. AFAIK this isn't possible with the normal socket
interface, and isn't supported by tcpd. We should probably
just say this isn't possible in the man page?
Wrapping of weirder types:
According to the inetd man page we support sockets of type:
``stream'', ``dgram'', ``raw'', ``rdm'', or ``seqpacket''.
I (personally) have never seen any inetd services using
raw, rdm or seqpacket - is it worth providing wrapping for
these socket types?
Adding wrapper support to wait daemons:
Daemons that use the wait class can only have their first
successful connection wrapped by inetd, and then they are
free to accept or reject subsequent connections themselves
until they exit. Usually they have a timeout (identd,
talkd), or only serve one connection (tftpd, rpc.rstatd).
Should we go around and try to add wrapper support into
these services?
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 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. :-( Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 think we may almost be there, and we've unearther problems with inetd that were there anyway - but not as obvious without wrapping. While the process is painful I think the end result may be OK. David. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Inetd and wrapping.
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 to have TCPWrapper support in the inetd, but there's no reason why it has to explicitly be made part of inetd. The support (after the patches Sheldon brought in) now is pretty good; is there any reason why the existing functionality should be extended ? A RedHat installation I used yonks ago had TCP/Wrappers installed as is on installation, and had no integration with the inetd; it was basically inetd and the TCP/Wrappers port installed. We're already better than that right now. --- Khetan Gajjar (!kg1779) * khe...@os.org.za http://khetan.os.org.za/ * Talk/Finger khe...@khetan.os.org.za FreeBSD enthusiast* http://www2.za.freebsd.org/ Reference : 19990618143617.a43...@bell.maths.tcd.ie Date : Jun 18, 1999, 2:36pm To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
REQ: Review inetd internal wrapping fix
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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
