On 11/09/14 16:07, Job Snijders wrote: > On Sun, Nov 09, 2014 at 01:36:59PM -0700, Theo de Raadt wrote: >> >I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, >> >rshd, rwho, rwhod, etc have been removed (at least according to the >> >Changelog). However, the upgrade instructions fail to mention that files >> >like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. >> >> How much of a catastrophy is this? >> >> Question for the community: Do you want the upgrade instructions to >> be 100% useful, or 100% complete? > > 100% complete should be the goal. > > I expect a system that is upgraded from 5.5 to 5.6 (following the > upgrade documentation) to be in the _exact_ same state as a clean 5.6 > installation, barring changes local to the system.
wow. See the third paragraph of any of the upgrade documents from 3.7 until 5.5. I removed that paragraph this release because I figured it was probably self-evident to people who understood which end of their digestive tract to put the fresh food into. Perhaps I overestimated. I would invite you to give it a shot. Start with current.html, plus56.html, anything else you wish. Not a lot of the developers really care a lot about the document, so they won't have been keeping current.html super accurate, you are basically on your own. You will have a lot of testing to do. You will note that while deleting rwhod was undoubtedly exciting for developers, actually putting it on current.html -- so I could put it on upgrade56.html -- was not nearly as much fun and never happened When you get it all done...look at your work. Can you imagine someone following it for 50 machines they support? How about 500? Can they use it for all of the 17 or so platforms OpenBSD supports? Can they do it from a remote site with no console access? is it the "_exact_ same" as a fresh install? Oh, to add to the realism, do it while holding down a full-time+ job, a few other volunteer activities, and cool-ass vehicles that beg to be driven any time the weather doesn't suck and a significant other you like to spend time with. BTW: if you fuck it up, you will cause a lot of people all over the world to have really really bad days. So don't fuck up. No pressure or anything. And in less than six months, you get to do it again. The good news is, if you do a half-way decent job, only two people complain: you and one other person (the other person does many things to contribute to the project, however), and you get lots of positive feedback. Can you make a better one than me? Give it a shot. Really. It's win all around. If you succeed, the community wins. Do a great job, I can go spend my time on other things. Win all around. :) The goal of the upgradeXX.html document -- as *I* see it -- is to provide enough information for real administrators of real systems to take their systems from a functional state of the previous release to a functional state of the current release, and leave them in a good state for the NEXT release cycle, too (lather, rinse, repeat, indefinitely). The idea is to be concise enough that the job can be done quickly and easily, and yet provide enough details so that virtually all users can figure out if they have edge cases which might cause them problems. Is the upgraded system identical to a fresh install? No; not a goal of mine. Will there be "ashes" left over? Yes. I think rwho and friends probably should have been removed as part of that huge list of files to delete, but the negative consequences of not deleting rwho are basically zero. And someone who's infrastructure depends on it might just be happy to find that it still runs on some platforms and might give them a little more time to fix their systems. That's why we aren't obsessive about deleting old library files, too -- you may well have applications, either as packages or things you compiled on your own -- which will still work on the upgraded system and may actually be really important for that system to continue to work (or even boot!) until the updated applications are installed. Does it work always? No, but if it saves the butt of a few administrators, it is almost certainly a net gain. Nick.
