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

[jim]

see what you think:
http://www.sf-lug.com
http://www.sf-lug.org



On 07/06/2015 02:59 AM, Michael Paoli wrote:
> 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://linuxmafia.com/pipermail/sf-lug/attachments/20150706/0ab3aae2/attachment.html>