-
Notifications
You must be signed in to change notification settings - Fork 14
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
ifupdown not able to reconfigure interfaces #75
Comments
Hello, sorry for a late reply. Next time you might want to consider creating an issue in the main As for your issue - it seems that you either didn't show the full configuration (just So, can you show the |
Hi @drybjed - thanks for your reply. I didn't realize this was the wrong place to open an issue... I'll make sure to use the main repo next time. Sorry for the slightly confusing initial report - let me see if I can be a little clearer. Yes, I did show output from two hosts... ultimately, I'd like to manage the interfaces for all of my hosts (baremetal + container), but in the interest of simplicity, I'll restrict to my baremetal server here:
(bridges have been renamed For the time being, I'm just trying to get
The configuration is correctly generated by Looking at the
So the script always fails when bringing down the interfaces. Bringing the interfaces up and down with |
If there are not How did you install it, via Debian Installer directly, or is it some kind of VPS deployed from a prepared image? With Debian Installer and just a base install I get a host managed with We can of course fix this in the |
This is a a pretty default install. It's a Dell PowerEdge R7515, installed via the netinst ISO mounted as virtual media over iDRAC. I installed manually, didn't select any tasks other than
One of my goals has been to keep the host OS as "stock" as possible, and isolate all application-specific stuff to containers. I don't even install Docker directly on the host, but rather nested within LXC containers. I have just noticed something interesting, although i don't know what to make of it. After a fresh reboot:
All interfaces are up, but no ifup@ units loaded. But if I tell systemd to bring up an already-active interface:
Now systemd is aware of that interface. So I guess the question becomes: why isn't this happening automatically? Note: systemd doesn't like something about some of the interfaces -
From
Here's the original (pre-debops)
If those |
Hi! I really appreciate the debops project! :-) I've done my best to exclude errors on my part, but as best as I can tell, the
ifupdown-reconfigure-interfaces
can never successfully reconfigure interfaces on my Debian Buster system.The scenario: A baremetal server with some LXC containers running on it, interfaces are configured statically. The
ifupdown
role will generate the interface configs in/etc/network/interface.config.d/
but the task to apply the new configs always fails.From looking at the script, it seems the issue revolves around the assumption that systemd-based systems always have
ifup@${if}.service
units to control their network interfaces... my system is systemd-based, but has no such units, either on host or in containers.For the sake of sparing the baremetal host a lot of mucking around with the network, I've done most of my testing with a test container, but the behavior is the same when applied against the host:
Relevant hostvars:
Filesystem state after run:
To attempt to manually apply, I restore the /etc/network/interfaces file, and run with:
debops -l test1 --tags "role::ifupdown" --extra-vars "ifupdown__reconfigure_auto=False"
After the run, on the container:
This is a systemd-based system:
But there are no
ifup@${if}.service
units:So it seems to me that
interface_down()
will always fail to stop any interfaces.There is nothing particularly unusual about my install that I can think of which make networking behave radically different. Am I missing something obvious?
Here's some output from the baremetal host:
Note: I have manually moved the interface configs from
interfaces.config.d/
tointerfaces.d/
to activate them.What's so strange about my setup that it breaks the script assumptions?
The text was updated successfully, but these errors were encountered: