On 4/24/06, Kevin Kinsey <[EMAIL PROTECTED]> wrote: > > Jonathan Horne wrote: > > >i have begun spending a good deal of time researching and practicing the > >buildworld process on my dev boxes. i want to make sure i have the > entire > >process down pat, before i attempt it on my production server. > > > > > > So, Mr. Murphy has never visited? "down pat" is probably > an oxymoron..... ;-) > > >the handbook states that i should: > > > >make buildworld > >make buildkernel > >make installkernel > > > >and then reboot to single usermode. the installworld comes while in > >single user mode, and my production server would see quite a bit of > >downtime over this. handbook says to, in sigle user mode: > > > >mergemaster -p > > > > > > /etc/ is not updated by "buildworld" nor "buildkernel", > hence the need for mergemaster (to get the new files > into /etc/ if anything has changed). > > Note, from mergemaster(8), that the "-p" option is > "pre buildworld"; so, to place this at this juncture is > assuming that nothing in /etc/ has changed to the point > of destroying the "build world" procedure. If it has, then > you should run "mergemaster -p" before *anything* else.... > > This wasn't the case with the last rebuild I did (Saturday). > The newly-built world couldn't be installed without the > "audit" group, so "mergemaster -p" was necessary before > "installworld", but "buildworld" had been fine without it. > It all depends. Which brings up another point ... the > *real* first step is, "read /usr/src/UPDATING". > > Here's the brass tacks: > *You may have to "mergemaster -p" before buildworld. > *You *must* buildworld before buildkernel if you want > the new kernel to match the new world. > *You must build a world and a kernel before you install > either. ;-) > *You probably don't want to install the new world before > you install the new kernel, 'cause currently running > programs could be affected, or might cause problems > with the current kernel. But, I guess you *could*.... > *You have to reboot to run a new kernel, so you must > install the kernel prior to a reboot. When you reboot, > your kernel will be using an old userland until the new > world is installed. Probably won't cause many issues, > but it could. > *It's possible that installing a new userland/world while > running could interfere with some processes/users/whatnot. > *It's possible that programs running after the world is reinstalled > need something in the new /etc/. > > From this, one might extract this sequence: > > cvsup your source > read /usr/src/UPDATING, take notes > mergemaster -p > buildworld > buildkernel > installkernel > reboot (su preferred/wisest) > installworld > mergemaster > > But, frankly, the last "mergemaster" could be anywhere > after the initial cvsup, I suppose. Kicks/pointers > welcomed on that.... > > >make installworld > >mergemaster > >reboot > > > >ive seen several articles on the net, and of course, no one agrees on the > >exact steps to take to update your system. my question is, is it safe to > >'mergemaster' and 'make installworld' while still up and running? or do > i > >just need to bite the downtime-bullet, and put it in single user? > > > > > > As you have probably noted, various "authorities" will give you > different answers. 'Nix is "tools, not policy". There are a few > ways to skin the cat.... > > It is possible to "installworld" after a remote reboot on a > low-trafficked machine without issues --- I do it all the time > (in fact, the entire process, with the exception of the reboot, > is scripted). But, I've been visited by Mr. Murphy once > or twice in the almost 5 years I've done this. Fortunately, my > "co-location" is only 20 minutes away, and I've a key... at > least for one of my production systems (I rebuild the other > during office hours ;-)
I've done remote src upgrade a few times now and also have had no issues. Although, I agree that you can probably only get away with this on low volume boxes. > I note from previous responses that for some people, such a > strategy is not acceptable at all. YMMV; mine does. > > You might ask if anyone uses a "limited reboot" strategy. You > could turn your daemons off in /rc.conf prior to the reboot, and > set your firewall to only allow you in; then perform the last steps > and re-enable the daemons/firewall, etc. > > Of course, the real problems start if the kernel panics on reboot, > and you're sitting in your chair 300 miles away on a Sunday > afternoon, wonder why "ping myhost" still isn't working after 240 > seconds.... > > >my server is co-located, so its not exactly convenient to put it in > single > >user mode, so if there is any reason to believe the whole processes can > be > >completed safely without single-user mode, then i will probably try it. > > > > > It's possible to enter single-user remotely via the use of a second > box and a serial console arrangement, but it's not something I've > needed to investigate. IP KVM is the way to go for something like this. This is assuming , though, that you have a spare switchport and IP for it. http://www.kvms.com/kvm-over-ip.asp I'd recommend practicing on a "scratch" box, for starters. Also, > it'd be a real Good Thing(tm) if a tech at the colo knows his BSD > stuff, and his time is included in your contract ;-) . > > HTH, > > Kevin Kinsey -David _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > [EMAIL PROTECTED]" > _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
