[sf-lug] sf-lug.org "32-bit" (i386) to "64-bit" (amd64) (!)

[Michael Paoli]

No trip needed, all remote.
And may start it *now* ... or relatively shortly.
Between start and completion, one can expect some *brief* outages,
notably for reboot to change kernel, and some bouncing of services
as binaries are swapped out.

Again, that's just for sflug (provides [www.]sf-lug.{org,com}),
the other hosts (physical and virtual) on that box are already
64-bit (amd64).

Only bit that should ever need or warrant (as precaution, if nothing else)
on-site, is particularly critical work on the operating system on the
physical host ("vicki") - all else can be fully done remotely (and if
we ever fully get the IPMI set up properly for "vicki", then even that
could be done fully remotely).


> From: jim <jim at well.com>
> Subject: Re: sf-lug.org "32-bit" (i386) to "64-bit" (amd64) (?)
> Date: Fri, 03 Jul 2015 20:59:28 +0000

>
> lemme know if that'll entail a trip
> to the box; I can hold things and
> bring food.
>
>
>
> On 07/03/2015 04:50 AM, Michael Paoli wrote:
>> If there are no serious objections,
>> I'll probably proceed in relatively near future (e.g. this month)
>> to "upgrade"(/sidegrade/crossgrade) the sflug host (providing sf-lug.org &
>> sf-lug.com) from "32-bit" (i386) to "64-bit" (amd64)
>> installation.
>>
>> Rationale (at least in key part):
>> Simplification of administration.  At present that host is the one and
>> only "odd man out" - of three hosts installed on that physical box (1
>> physical and 2 virtual), sflug is the only remaining 32-bit installation.
>> Conversion to 64 bit would render it to be same architecture (and  
>> distribution)
>> as the other 2 hosts on that physical box (which would also save on
>> bandwidth and storage, etc.)
>>
>> references/excerpts:
>> Have done quite similar before:
>> http://www.wiki.balug.org/wiki/doku.php?id=system:32-bit_to_64-bit