[BlueOnyx:21468] Re: Bizarre 5209R loses network config

Chris Gebhardt - VIRTBIZ Internet cobaltfacts at virtbiz.com
Tue Oct 3 16:46:21 -05 2017


Hi Michael,

On 10/3/2017 4:01 PM, Michael Stauber wrote:
> Hi Chris,
> 
>> /etc/udev/rules.d/70-persistent-net.rules had two distinct MAC entries
>> listed for eth0.   Two entries, just as you might expect when there are
>> 2 interfaces (typically eth0 and eth1) but both were eth0.
> 
> This is pretty weird indeed. Just to clarify: The reported MAC addresses
> for eth0 were the same or were they different? If they were different,
> that would make it even weirder as the MAC address of an interface isn't
> supposed to change.

The MAC addresses were different.  One of them wasn't even a MAC on the 
system.  I show that 5209R was installed on this system over a year ago, 
and the hardware hasn't changed.  So yeah - very weird.

>> the net.ifnames=0 variable.   It was missing.
> 
> All the 5209R ISOs do set the net.ifnames=0 during post install and
> during kernel upgrades these options are usually retained. I'm at a loss
> why this would go walkies on its own. :-/

I agree.  Troubling.  Puzzling.

> The likelihood of this to happen again is pretty small.

Which is good news.

> Fact of the matter is: Apache is a bitch to restart or reload
> non-interactively.

Recently, Apache has just plain been a bitch.


> We now run Swatch at the end of any YUM update that issues a CCEd rehash
> or restart and almost all BlueOnyx updates do one of these for good
> measure.

I've been following along there, and am looking forward to seeing that 
in action. Or more accurately, not noticing!  ;)

Honestly, overall the updates go pretty smoothly considering the number 
of servers that are running under our care.  It's interesting that if we 
get a report of one box falling down, it's sometimes just a matter of 
time before the "usual suspects" fall apart as well.  But we've yet to 
determine what, if any, commonality exists.

> There isn't much room for further improvement to that, unless I start
> over and use a radically different approach. I am considering turning
> Swatch into a daemon that performs health checks more often than the
> current 15 minute cronjob. 

Interesting.

> There are a couple of reasons that in favor of such a daemon (and I
> haven't mentioned all of them yet), but also 2-3 that speak against it.
> I'd rather wait an see if the recent changes to Swatch and the YUM
> plugin take good enough care of the issue as is, before I set off to
> code the Swatch-daemon.

Yeah, I'm with you there.   If it ain't broke, don't fix it.  Also, a 
daemon to watch the daemons... hmmm.

-- 
Chris Gebhardt
VIRTBIZ Internet Services
Access, Web Hosting, Colocation, Dedicated
www.virtbiz.com | toll-free (866) 4 VIRTBIZ



More information about the Blueonyx mailing list