[sf-lug] (6-8p tonight @ Noisebridge) ... SF-LUG & BALUG: System OS upgrades *soon*(?) - volunteer(s)? [DON'T "REPLY ALL" TO BOTH LISTS UNLESS YOU'RE SUBSCRIBED TO BOTH]
Michael.Paoli at cal.berkeley.edu
Wed Jan 25 13:25:55 PST 2012
[DON'T "REPLY ALL" TO BOTH LISTS UNLESS YOU'RE SUBSCRIBED TO BOTH]
And yes, I should be at Noisebridge this evening, 6p-8p.
For those that are interested in the planning/upgrade process,
but can't make it tonight, I'm also planning to attend the next
SF-LUG meeting on 2012-02-05. May also put out some status/summary
emails in the meantime (may or may not also send those to
BALUG-Talk - but will probably at least put pointer(s) on email
to BALUG-Talk where such emails may be found/followed).
> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: Re: SF-LUG & BALUG: System OS upgrades *soon*(?) -
> volunteer(s)? [DON'T "REPLY ALL" TO BOTH LISTS UNLESS YOU'RE
> SUBSCRIBED TO BOTH]
> Date: Mon, 23 Jan 2012 19:05:35 -0800
> [DON'T "REPLY ALL" TO BOTH LISTS UNLESS YOU'RE SUBSCRIBED TO BOTH]
> Jim, thanks for passing this along - thought you might. :-)
> I'm also passing it along to "BALUG-Talk".
> Also, I *probably* will make it to Noisebridge this Wednesday
> evening (6-8p). I'll confirm Wednesday afternoon if I'm able to make
> it (and will confirm at *least* an hour in advance (before 5pm),
> and probably a fair bit earlier than that (perhaps before 3pm)).
> I'm also intending to make the SF-LUG 2012-02-05 meeting.
> Anyway, between those meetings, hopefully we'll have the upgrades pretty
> well planned out and can execute them relatively soon after.
> I did also get the host "vicki" a wee bit closer to prepared yesterday.
> Some we reference excerpts added further towards the tail end of this email.
>> From: jim <jim at well.com>
>> Subject: Re: SF-LUG & BALUG: System OS upgrades *soon*(?) - volunteer(s)?
>> Date: Sun, 22 Jan 2012 20:51:51 -0800
>> I think this is a great volunteer project for anyone
>> who's interested in linux system administration. Let us
>> know if you're interested in helping or learning.
>> We can meet up either at the next regular SF-LUG
>> meeting (Sunday February 5 from 11 AM to 1 PM at the Cafe
>> Enchante on Geary at 26th Ave) or at the Linux Discussion
>> Group meeting at Noisebridge (every Wednesday evening
>> from 6 to 8 PM) or both--don't worry about coordinating
>> between multiple meetings, we'll take care of that.
>> Note that Michael is an expert Linux sys admin with
>> a particularly good sense of best practices.
>> On Sun, 2012-01-22 at 18:25 -0800, Michael Paoli wrote:
>>> SF-LUG & BALUG: System OS upgrades *soon*(?) - volunteer(s)?
>>> Jim, et. al.,
>>> Do we have a quorum of volunteers (or should we also try to add a person
>>> or two)? In this case, I'm specifically thinking colo box, physical
>>> access and associated systems administration stuff (there's also lots
>>> that can be done mostly remotely).
>>> Anyway, I see some fairly major upgrades due in our near future.
>>> Impacted are:
>>> sflug (guest on vicki, hosts [www.]sf-lug.com)
>>> vicki (host for the above)
>>> vicki (noted above, hosts the immediately below)
>>> balug-sf-lug-v2.balug.org (guest on vicki, hosts lot of BALUG
>>> aladfar.dreamhost.com. (hosted, will be upgraded/replaced for us, hosts
>>> [www.]balug.org, etc.)
>>> Security support for Debian 5.0 "lenny" ends *soon* (2012-02-06).
>>> To the extent feasible, we should upgrade the relevant systems soon,
>>> preferably before that date, if that's doable, but if not, soon
>>> Maybe we could plan out the upgrades at an upcoming SF-LUG meeting?
>>> Roughly, I have in mind (what I'd like to do):
>>> o There isn't any official supported upgrade path from i386 to amd64
>>> o the Silicon Mechanics physical box is and will run amd64/x86_64
>>> o the Silicon Mechanics physical box supports hardware virtualization
>>> o suitably backup (including on-disk as feasible)
>>> o generally prepare for upgrades
>>> o do "upgrades" as follows:
>>> o vicki:
>>> o backup / move / "shove" stuff around beginning of disk suitably
>>> out-of-the-way (on-disk backups / access to existing data)
>>> o install Debian 6.0.3 (or latest 6.0.x) amd64, using beginning
>>> area(s) of disks, general architecture layout mostly quite as
>>> before (everything mirrored, separate /boot, rest under LVM2,
>>> separate filesystems, etc.)
>>> o install/configure vicki as above to fully support both qemu-kvm,
>>> and xen. Note that on amd64, and with hardware virtualization,
>>> that will allow vicki to support i386 and amd64 images under
>>> qemu-kvm and I believe also xen.
>>> o sflug & balug-sf-lug-v2.balug.org:
>>> o once the above vicki upgrades are done, sflug and
>>> balug-sf-lug-v2.balug.org can be dealt with remotely
>>> o sflug & balug-sf-lug-v2.balug.org can each be dealt with
>>> separately by their primary/lead sysadmin(s) as may be desired, in
>>> general for them, I'd probably recommend proceeding as follows:
>>> o get the existing xen guests running again, more-or-less as they
>>> were (may require some adjustments - most notably boot bits) -
>>> may be advisable to convert them to run under qemu-kvm as soon as
>>> feasible (to avoid guest<-->host kernel, etc. interdependencies)
>>> o upgrade guests to Debian 6.0.3 (or latest 6.0.x)
>>> o optional: change guests from i386 to amd64, use above guests
>>> as reference installations, and do an install/merge to get the
>>> guest(s) as desired to amd64 architecture.
>>> bit 'o reference/background ;-) ...
>>> THE END* IS NEAR**! *of security support for Debian GNU/Linux 5.0
>>> (code name "lenny") **2012-02-06
>>> Security support of Debian GNU/Linux 5.0 (code name "lenny") will be
>>> terminated 2012-02-06.
>>> Debian released Debian GNU/Linux 5.0 alias "lenny" 2009-02-14.
>>> Debian released Debian GNU/Linux 6.0 alias "squeeze" 2011-02-06.
> //or if we present that data a bit differently, to show just how
> //identical the partitioning on the two /dev/sd[ab] disks is:
> Disk /dev/sd[ab]: 30401 cylinders, 255 heads, 63 sectors/track
> Units = sectors of 512 bytes, counting from 0
> Device Boot Start End #sectors Id System
> /dev/sd[ab]1 63 498014 497952 fd Linux raid autodetect
> /dev/sd[ab]2 498015 35648234 35150220 fd Linux raid autodetect
> /dev/sd[ab]10 318472623 375037424 56564802 fd Linux raid autodetect
> //excepting extended partition, all logical and non-zero length primary
> //partitions paired up between the sda and sdb devices partisions as md
> //raid1 devices
> ///dev/md0 is used for /boot
> sda1 sdb1 md0
> /dev/md0 241036 57135 171457 25% /boot
> //md[1-6] used for LVM
> PV Name /dev/md1 VG Name vg00
> //before: (and above)
> sda2 sdb2 md1 vg00
> sda10 sdb10 md7 (unused)
> sda2 sdb2 md1 (unused)
> sda10 sdb10 md7 vg00
More information about the sf-lug