Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

network.managed on RHEL / Fedora with a dummy interface puts in a HWADDR #23556

Closed
SEJeff opened this issue May 11, 2015 · 11 comments

Comments

Projects
None yet
5 participants
@SEJeff
Copy link
Member

commented May 11, 2015

This is incorrect as the mac address is different after a reboot, causing the dummy interface to not come up.

The fix here is to fix the templates that lay down /etc/sysconfig/network-scripts/ifcfg-$interface_name

I'll send in a PR to fix this soonish, but this bug is just for tracking. cc: @junster1

@jfindlay jfindlay added this to the Approved milestone May 12, 2015

@jfindlay

This comment has been minimized.

Copy link
Contributor

commented May 12, 2015

@SEJeff, thanks for your work on this. A pull request would be most welcome.

@signetbv

This comment has been minimized.

Copy link

commented Nov 24, 2015

Any update on this issue?

@SEJeff

This comment has been minimized.

Copy link
Member Author

commented Dec 8, 2015

I've got an internal diff for this that I need to cleanup and send in. I'll try to get to that this week.

@wt

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2016

This block is the source of the wrongness:

What should be done? Should we filter out interfaces named dummy*? That seems less than ideal.

@jfindlay jfindlay added P3 and removed P4 labels Jan 13, 2016

@wt

This comment has been minimized.

Copy link
Contributor

commented Jan 13, 2016

I've started a thread on salt-user about this topic to try to figure out how to fix it. Here's a link:
https://groups.google.com/forum/#!topic/salt-users/MdMf0oiZrrY

@thatch45

This comment has been minimized.

Copy link
Member

commented Jan 19, 2016

@SEJeff any word here? Sounds like this is a small fix that you have already solved. are there any pitfalls you ran into that have prevented you from updating this?

@wt

This comment has been minimized.

Copy link
Contributor

commented Jan 27, 2016

ping

Any new info?

@SEJeff

This comment has been minimized.

Copy link
Member Author

commented Feb 9, 2016

@thatch45 No sir, I've just been a bit slammed and my home workstation ate itsself recently. I'll try to get on this soon. We have this deployed in prod where we use dummy interfaces for tracking via keepalived (all managed via salt naturally).

@wt

This comment has been minimized.

Copy link
Contributor

commented Mar 31, 2016

@SEJeff Any chance this has seen any unreported activity?

@stale

This comment has been minimized.

Copy link

commented Apr 16, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

If this issue is closed prematurely, please leave a comment and we will gladly reopen the issue.

@stale stale bot added the stale label Apr 16, 2018

@stale stale bot closed this Apr 23, 2018

@SEJeff

This comment has been minimized.

Copy link
Member Author

commented May 6, 2019

State to replicate the issue (tested on a RHEL7 minion):

dummy:
  kmod.present

dummy0:
  network.managed:
    - enabled: true
    - type: eth
    - proto: none
    - require:
      - kmod: dummy

Unless we want to teach salt to send ioctl() and speak netfilter (I can do this, but eeeewwwwwww) or run ip link show type dummy, we should probably add a dummy type. The dummy type would be ethernet for all intensive purposes, but would fix the dummy interface problem. I think this is the most generic and sensible approach.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.