Date: Wed, 23 Oct 2002 15:29:30 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Brooks Davis <brooks@one-eyed-alien.net> Cc: Steven Ames <steve@virtual-voodoo.com>, Andrew Mishchenko <andrew@driftin.net>, freebsd-current@FreeBSD.ORG Subject: Re: Request: remove ssh1 fallback Message-ID: <3DB722CA.2A6E6482@mindspring.com> References: <007501c27a5c$27203fc0$6501a8c0@VAIO650> <20021023155753.GB7503@HAL9000.homeunix.com> <004401c27aad$740a5400$33d90c42@officescape.net> <20021023161643.GA7813@HAL9000.homeunix.com> <20021023143917.GA3222@driftin.net> <3DB6F2E1.799FF6F7@mindspring.com> <009001c27ac8$af6d77f0$33d90c42@officescape.net> <20021023123349.A9132@Odin.AC.HMC.Edu> <3DB6FF07.5DAC9CCB@mindspring.com> <20021023131051.A21930@Odin.AC.HMC.Edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Brooks Davis wrote: > On Wed, Oct 23, 2002 at 12:56:55PM -0700, Terry Lambert wrote: > > Brooks Davis wrote: > > > I think it's safe to say that if you do a remote upgrade to 5.0 and > > > miss this change (if it happens), you're probably going to have missed > > > several other more important change. A source upgrade from 4.x to 5.x > > > is definatly not for the faint of heart or the non detail oriented. > > > > I'm talking a binary upgrade, using the sysinstall "upgrade" > > option. > > A binary upgrade to 5.0 isn't going to be much better. If you just > do it, it's going to leave you with most of the problems described in > UPDATING. You're still going to have to remember to delete things from > your includes directories if you want C++ to work, your pam.conf will be > obsolete, the names of some devices will be different, etc. I thought 5.0-RELEASE wouldn't suck. Now you are saying that it will, and the fact that it will is justification for making it suck even more by breaking existing installed 4.7-RELEASE machines that get upgraded to 5.0-RELEASE. I really don't buy the "It's OK to suck if someone else sucks" rationalization (I had enough of that when doing the code review on NFS and NUC for UnixWare, thanks). > You can argue that the upgrade option shouldn't change anything until > you're blue in the face, but that's not going to change reality. I'm not saying that it shouldn't change implementation, I'm saying that it shouldn't change configuration. Upgrade is the whole reason we went to a central rc.conf thing in the first place, isn't it? Yes, it's really easy to break a lot of things, and then hope someone will follow along after you, cleaning up your mess, but it's not a reasonable attitude. If someone wants to drop support for an older protocol in a server that currently supports the older protocol, the way to deal with it is to deprecate, not delete, the older protocol. Specifically, if someone wants to not support ssh1 by default in sshd, then it is the job of that someone to make sure that legacy support can be enabled by a command line option, in order to deperecate the protocol (instead of yanking the rug out from everyone who uses it). It is also the job of that someone to add code to the upgrade process to, minimally, if the system being upgraded supports ssh1 by default, then automatically add the command line option to configuration, so that the behaviour does not change on existing systems. A non-minimal job would have the upgrade process query the user whether or not to disable ssh1 -- with a default of "No". Note that this only becomes a problem when someone wants to change a default behaviour -- and it *rightly* becomes the problem of the one wanting to make the change. There is no such thing as "bitrot". There is only a person who makes a hash of something, instead of doing a complete job. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DB722CA.2A6E6482>