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

[jim]

     At the SF-LUG meeting today, for some reason,
we tried to access the sf-lug.{com,org} web site;
at least one member reported getting a page with
an image of a guy in a suit, definitely not the
sf-lug penguin on the tower.
     We're wondering what happened (now); and I'm
blaming NetSol, though by knee-jerk, not real
knowledge.
     Michael, can you shed light?





On 07/04/2015 05:49 AM, Michael Paoli wrote:
> And it's completed - fully 64-bit (amd64) now.
>
>> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
>> Subject: Re: sf-lug.org "32-bit" (i386) to "64-bit" (amd64) (!)
>> Date: Fri, 03 Jul 2015 17:08:11 -0700
>
>> 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20150705/81440aaa/attachment.html>