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 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.

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

--
He played the king as if afraid someone else would play the ace.
                -- John Mason Brown, drama critic


_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to