Bug 1279224 - Interface sit1 wont start after recent updates [NEEDINFO]
Interface sit1 wont start after recent updates
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: initscripts (Show other bugs)
5.11
i686 Linux
unspecified Severity unspecified
: rc
: ---
Assigned To: Lukáš Nykrýn
qe-baseos-daemons
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-11-08 12:48 EST by Mike A. Harris
Modified: 2017-04-18 17:59 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-04-18 17:59:56 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
lnykryn: needinfo? (mharris)


Attachments (Terms of Use)

  None (edit)
Description Mike A. Harris 2015-11-08 12:48:06 EST
Description of problem:

On October the 14th I updated a system to current but did not reboot it immediately.  A few days ago I updated it again and realized it needed a reboot to pick up the new kernel previously installed.  Upon rebooting I discovered that my Hurricane Electric tunnelbroker.net tunnel which is normally active on the network device "sit1" as configured by /etc/sysconfig/network-scripts/ifcfg-sit1 was no longer starting up.

None of the network config files have been human altered on that machine since it was installed a few years ago roughly, so any network configuration related problems would be unexpected.  An investigation into the problem discovered that all of the ifcfg-* files had been modified simultaneously on October the 14th which was exactly when the update occurred.  In addition to that, all of the ifcfg-* files were now triple-hardlinked to locations elsewhere in the system under /etc/sysconfig/networking/ which they had not been previously.

At this point I suspected that something that got updated tried to manipulate the network configs and introduced breakage to them which in turn caused sit1 to not start up anymore.  I examined the files and found that a single line had been affixed to the end of each of the files:

TYPE=Ethernet

Additionally there was a 0 byte file turd left behind in the network-scripts subdir named simply "1" which I took as being a script redirection typo.  It was timestamped the same day/time as the ifcfg-* files so I assumed it was the result of an upgrade script gone bad.


Version-Release number of selected component (if applicable):

I'm not sure if this is a problem in the udev package or not, it happened during a routine update that updated the kernel, udev and several other packages.  The udev package seemed the most likely culprit so I assigned it to udev.  If udev does not alter the network config scripts feel free to reassign it to a more appropriate component of whatever does modify them during upgrade or via triggerscripts or whatnot.


How reproducible:
Impossible to determine, I only have one host configured like this with an sit1 network device connected to tunnelbroker.net and I have no easy way to downgrade the machine to the pre-problem state and re-update it to recorrupt the network configuration.  It may be 100% reproduceable with the appropriate setup, or it might be non-reproduceable.  Indeterminate.

Steps to Reproduce:
1. Have an EL5/x86 install that is fully updated to about Aug 2015 state.
2. Have an sit1 device configured to connect to a remote IPv6 tunnel such as tunnelbroker.net
3. Make sure TYPE= is not specified in the ifcfg-* files (my originals did not have it)
4. yum -y update to current and reboot


Actual results:
The sit1 device does not come up and an error stating that the sit1 network device does not exist shows up when the network starts.  I do not have the exact error message handy but I can reconfigure the error-state easily and reproduce the error to paste it here if that is necessary and requested.

Expected results:
My networking configuration files to not be adulturated by anything during software upgrades, and to not have other things hardlinking to them in multiple locations.  Also to not find random temporary files laying around from some kind of update processing which appear to be a buggy script or something leaving file turds (the file named '1' that I discovered).
Comment 1 Lukáš Nykrýn 2015-11-09 08:01:58 EST
Hmm, I doubt that this was cause by initscripts or udev. At least I haven't found anything.

If this was cause by an update, maybe we could find something in rpm triggers.

Can you post here "rpm -qa --triggers" from that machine?
Comment 2 Chris Williams 2017-04-18 17:59:56 EDT
Red Hat Enterprise Linux 5 shipped it's last minor release, 5.11, on September 14th, 2014. On March 31st, 2017 RHEL 5 exited Production Phase 3 and entered Extended Life Phase. For RHEL releases in the Extended Life Phase, Red Hat  will provide limited ongoing technical support. No bug fixes, security fixes, hardware enablement or root-cause analysis will be available during this phase, and support will be provided on existing installations only.  If the customer purchases the Extended Life-cycle Support (ELS), certain critical-impact security fixes and selected urgent priority bug fixes for the last minor release will be provided.  For more details please consult the Red Hat Enterprise Linux Life Cycle Page:
https://access.redhat.com/support/policy/updates/errata

This BZ does not appear to meet ELS criteria so is being closed WONTFIX. If this BZ is critical for your environment and you have an Extended Life-cycle Support Add-on entitlement, please open a case in the Red Hat Customer Portal, https://access.redhat.com ,provide a thorough business justification and ask that the BZ be re-opened for consideration of an errata. Please note, only certain critical-impact security fixes and selected urgent priority bug fixes for the last minor release can be considered.

Note You need to log in before you can comment on or make changes to this bug.