Date: Thu, 4 Apr 2002 01:10:44 -0800 (PST) From: Lamont Granquist <lamont@scriptkiddie.org> To: <stable@freebsd.org> Subject: Re: Heads up, a bit: ephemeral port range changes Message-ID: <20020404005218.H1245-100000@coredump.scriptkiddie.org> In-Reply-To: <20020404011316.GB93977@madman.nectar.cc>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 3 Apr 2002, Jacques A. Vidrine wrote: > On Wed, Apr 03, 2002 at 10:53:25PM -0600, Mike Silbersack wrote: > > As we have a RELENG_4_5 branch, I see no reason that I should hold off on > > the change. It's mostly unimportant, not gratuitous. > > Well, Mike, I don't think I can put it more strongly. If you are > insistent about making this change, I cannot stop you. I wish you > would not. > > If it is not gratuitous, pray tell what benefit this change will > bring. It will certainly snag a minority of folks, and that makes it > a bad idea as far as I am concerned. Well, I may be a bit grumpy tonight, but anyone who gets snagged by this is being pretty stupid. If you're writing firewall rules you should expect ephemeral ports to be anywhere between 1024-65535. If you're tweaking for specific OS implementations then you should expect to have to retest and retweak when you make OS upgrades. Meanwhile, it should help the less clueful people who don't know anything about ephemeral portranges run their benchmarks *and* their applications. I've run into portrange limitations with production applications numerous times and had to tweak these settings. I expect that my experience is not unique. > On Wed, Apr 03, 2002 at 04:09:56PM -0800, Michael Sierchio wrote: > > It isn't stable -- gratuitously updating on > > a weekly or daily basis is for hobbyists. It's known to break things now > > and then. > > We try very hard _not_ to break things. We break things only when > there is a compelling reason to break them. Not because we just feel > like it. I think that overall on the balance sheet this is fixing something, not breaking it. And it brings FreeBSD into compliance with standards. > > The idea of holding pending MFCs until we're in RC stage is far worse. > > As I implied in an earlier message, I would prefer that it never be > merged to 4.x. Putting on my System Engineer hat and looking at this from a very conservative IT perspective I don't see what the big deal is. If you're that paranoid about stability you should run any new OS candidate through a battery of qualification tests to weed out problems like this. The ATA merge is much more problematic from a system stability perspective. > On Wed, Apr 03, 2002 at 07:57:08PM -0500, Garance A Drosihn wrote: > > Chances are pretty good that they would not notice any such > > problems until after they have done the "installworld" step, > > and thus it is not necessarily a simple matter to "just go > > back" to their previous kernel. > > Yes, it is worse. It probably will not happen until the run > application X --- perhaps an ICQ client, or an FTP server, or > whatever. It will fail, and for some people it will cost time to > determine the cause and to repair it. This is not /so/ bad for > someone tracking -STABLE, except that the whole problem can and should > be avoided. Yes, but it prevents someone filling up all 4000 ephemeral ports with sockets stuck in TIME_WAIT and having to troubleshoot and futz with reassigning these defaults themselves. That seems like the right problem to be avoiding rather than trying to work around firewall admins who either don't know what they're doing or who have too much free time on their hands. > > I would > > feel a little better about making this change to -stable if > > we knew what important (time-critical) issue that it was > > fixing. > > BSD has used the low range ports ``forever''. There is absolutely no > time-critical reason to change the default now. I consider the current portrange broken. I consider anyone bit by changing the current portrange to themselves be broken. Seems like a fine change for "-STABLE" to me. > I don't think I'll be posting on the issue again, as the length of the > thread will soon be disproportionate to the subject's importance, if > it isn't already. :-) Yeah, agreed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020404005218.H1245-100000>