Gentoo Archives: gentoo-user

From: Nick Khamis <symack@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Updating our live servers. I'm scared!
Date: Thu, 28 Mar 2013 16:30:41
Message-Id: CAGWRaZaHQjvgR2dRsD3zVtdS-Hhn2_gouYv7SF3muz9DBuOqXQ@mail.gmail.com
In Reply to: Re: [gentoo-user] Updating our live servers. I'm scared! by Joshua Murphy
1 So basically rsync configs and databases first? When issuing updates
2 to world and so no. What is the safest process/order to sync portage,
3 and update world? I have seen a number of flags various example use,
4 and was wondering if someone can give me the safest and equally
5 effective commands with flags included.
6
7 Thanks again,
8
9 Nick.
10
11 On 3/28/13, Joshua Murphy <poisonbl@×××××.com> wrote:
12 > On Thu, Mar 28, 2013 at 11:38 AM, Nick Khamis <symack@×××××.com> wrote:
13 >
14 >> Hello Everyone,
15 >>
16 >> Just got a ticket assigned to me where we need to update our production
17 >> servers.
18 >>
19 >> uname -a
20 >> Linux noun 3.4.9-gentoo #2 SMP Sat Oct 13 09:35:07 EDT 2012 x86_64
21 >> Intel(R) Xeon(TM) CPU 3.60GHz GenuineIntel GNU/Linux
22 >>
23 >> eselect
24 >> [18] hardened/linux/amd64 *
25 >>
26 >> I don't think they have been updated since the initial install and
27 >> wanted to get a little feedback on some safe practices and methods
28 >> that should be performed before and while doing so.
29 >>
30 >> Thanks in Advance,
31 >>
32 >> Nick.
33 >>
34 >>
35 > Personally, I would recommend pulling an rsync (databases and such might
36 > cause a hiccup with that) of one of them to a nonessential system and
37 > testing updating there, building packages (assuming matching use flags,
38 > etc, across your systems), documenting the pitfalls you run into as you go.
39 > After you're up to date there, run through and test it again from a base
40 > copy, then test the actual services to ensure changes to them don't hose
41 > your environment's configuration, and once that's good, it then depends
42 > entirely on what failover, or downtime allowances you have available. If
43 > you have no failover to rely on, and can't afford enough downtime to update
44 > the system in place from the packages you've built, clone each off, update,
45 > then migrate the changes that've occured in the time between... time
46 > consuming, and requires a lot of care, but doable.
47 >
48 > --
49 > Poison [BLX]
50 > Joshua M. Murphy
51 >