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

[Michael Paoli]

I'm not aware of any issues.

If(/when) there's issue, helps to gather the relevant troubleshooting
information, e.g. DNS & IP, response, capture of the page(s)/image(s),
...
maybe someone typoed the domain name when they went to get the page?

Kind'a hard to troubleshoot (someone thinks) they saw ... but they didn't
save any of the data or details.

And *today* ... that was long after the changes on the host had been
completed.  Also, wondering how someone tried to connect from what/where,
and if they hit any "click through" sites they had to use, or used some
rogue Wi-Fi or something like that?  Again, without relevant details captured,
mostly just left to speculate.

> From: jim <jim at well.com>
> Subject: Re: [sf-lug] done: Re: sf-lug.org "32-bit" (i386) to  
> "64-bit" (amd64)
> Date: Sun, 05 Jul 2015 21:27:44 +0000

>
>     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