[sf-lug] SF-LUG & BALUG: System OS upgrades "soon" (approx. 2012-02-06)

Michael Paoli Michael.Paoli at cal.berkeley.edu
Thu Jan 26 18:34:45 PST 2012


[include: "SF-LUG & BALUG: System OS upgrades" (less quotes) within
Subject: header for folks to follow on this topic]

First of all, thanks to all who've expressed interest, volunteered,
and/or came to the meeting at Noisebridge yesterday evening.

Secondly, from that meeting, lots of good discussion, observations,
questions, points, etc.  I'll follow-up relatively soon (probably
on or by sometime this coming weekend) in more details - both much
of what was covered in that meeting, and also a bit more detail /
background on the system(s) (notably one physical and 2 virtual)
most notably involved in this particular discussion/upgrade project.

Thirdly, it was discussed/suggested - and I was thinking also along
such lines before said meeting, as for where to "discuss" (email)
about/regarding such on-line; fairly simple, protocol, a list that's
already relevant, suitable, and fairly high-traffic:
SF-LUG <sf-lug at linuxmafia.com>
and along with that, protocol so those that want to follow the
relevant bits on that area of discussion, but may not have
time/interest/resources to read or filter through much or most of the
other SF-LUG <sf-lug at linuxmafia.com> email traffic, a protocol
agreement - particular fixed string included in the Subject:
headers for all the relevant emails intended to be on/about that
topic/project ...

Subject: SF-LUG & BALUG: System OS upgrades
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Include the string (without the quotes):
"SF-LUG & BALUG: System OS upgrades"
in any the Subject: header of any email intended to be on-topic for
that particular "thread" (and here I'm *not* using thread in its
proper technical sense).
One may add more before or after the requisite string in the Subject:
header, but it *must* contain the requisite string in the Subject:
header if one wants to assure it will be "seen"/read by those wishing
to follow the topic.  E.g. if your Subject header is:
Subject: RE: sf-lug Digest, Vol 72, Issue 25
folks (e.g. me) interested and relevant to the
SF-LUG & BALUG: System OS upgrades
topic may not read your email (or might catch up to it weeks/month(s) or
more later).

I'll point "BALUG-Talk" folks that may be interested in following along /
participating, over here to the SF-LUG list and this message.

Thanks again all - more later (fairly soon).

references/excerpts:
> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> Subject: [BALUG-Talk] (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]
> Date: Wed, 25 Jan 2012 13:25:55 -0800

> [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.
>>
>> references/excerpts:
>> https://www.noisebridge.net/wiki/Visitor_advice
>> https://www.noisebridge.net/wiki/Getting_Here
>> https://www.noisebridge.net/wiki/LinuxDiscussion
>> http://www.sf-lug.com/
>> http://www.balug.org/#Lists
>>
>>> 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:
>>>> SF-LUG:
>>>> sflug (guest on vicki, hosts [www.]sf-lug.com)
>>>> vicki (host for the above)
>>>> BALUG:
>>>> vicki (noted above, hosts the immediately below)
>>>> balug-sf-lug-v2.balug.org (guest on vicki, hosts lot of BALUG
>>>>  production)
>>>> 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
>>>> thereafter.
>>>>
>>>> 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.
>>>>
>>>> references:
>>>> http://lists.debian.org/debian-security-announce/2011/msg00238.html
>>
>> //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)
>> //after:
>> sda2 sdb2 md1 (unused)
>> sda10 sdb10 md7 vg00
>>
>> references:
>> file://vicki/root/upgrades/5.0_lenny_to_6.0_squeeze/
>> 0001_a_general_plan_or_outline
>> 0002_vicki-pre-disk-analysis
>> 0003_vicki_initial_disk_prep





More information about the sf-lug mailing list