Bug 478326 - [PATCH] yum-NetworkManager-dispatcher exit code and Network Detection
[PATCH] yum-NetworkManager-dispatcher exit code and Network Detection
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-12-28 02:42 EST by Warren Togami
Modified: 2014-01-21 18:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-29 01:16:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Replacement for /etc/NetworkManager/dispatcher.d/yum-NetworkManager-dispatcher (688 bytes, text/plain)
2008-12-28 02:42 EST, Warren Togami
no flags Details

  None (edit)
Description Warren Togami 2008-12-28 02:42:35 EST
Created attachment 327896 [details]
Replacement for /etc/NetworkManager/dispatcher.d/yum-NetworkManager-dispatcher

The attached replacement script for /etc/NetworkManager/dispatcher.d/yum-NetworkManager-dispatcher solves two bugs.

1) 
Dec 26 23:39:27 newcaprica nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/yum-NetworkManager-dispatcher' exited with error status 1.

The script should always exit 0 to avoid this unnecessary message in the logs.

2) The script should detect if it is actually necessary to flush the yum mirrorlist cache.  If the IP address and MAC address of the default gateway did not change, then do not force a refresh.
NOTE: arping is used instead of passive arp because it is not available from the arp table until later.  It is not a big deal if arping fails.
Comment 1 James Antill 2008-12-29 01:16:59 EST
 Changing the script to:

[ "$2" != "up" ] && exit 0

yum clean expire-cache 2>&1 > /dev/null

...fixes the first bug, yeh? That seems obviously correct to apply, so is now upstream.

 The second part I'm less happy to apply, I assume you are using the gateway as well as the local IP due to NAT addresses? Was there a reason you included all the network settings for the local IP?
 I think if we want to go this route what it checks needs to be at least configureable, and thus. probably not written in sh anymore.

 Also:

% /sbin/ip route show to 0/0
Error: an inet prefix is expected rather than "0/0".

...so I'm guessing that is a Fedora-10 thing? But anyway running 5 commands, and screen scraping to boot, just to get the MAC of the default gateway seems like a bad idea. Which is more reasons to not apply it.
Comment 2 Warren Togami 2008-12-29 04:26:31 EST
Yes, the exit 0 above solves the first problem.

Yes, this ip route syntax is new as of F-10.

> I think if we want to go this route what it checks needs to be at least
> configureable, and thus. probably not written in sh anymore.

I disagree here.  It is not important to get this 100% correct.  It is OK to trigger more often than absolutely necessary, but false negatives are not OK.

The way this works, in the vast majority of cases it will check the IP details and this alone is sufficient to determine if it needs to flush the yum mirrorlist cache.  There is however the possibility of roaming to another network with exactly the same DHCP configuration and getting the same IP address.  Thus an additional check for the MAC address of the gateway should be sufficient to determine if you have roamed to another network.  Now that I think about it more, perhaps the latter MAC address of default gateway alone is a sufficient test for a changed network.

In any case, the nature of a "false positive" due to corner cases of this failing is not really a big deal.  It will only flush the yum mirrorlist cache in such cases.  It is really not necessary to overengineer this by making it configurable.

I do agree that writing it in some other language and avoiding screen scraping would be a good idea.

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