Bug 1413241
Summary: | Adding alias on loopback interface not enable during boot | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Davide Lima "Duarte" Daum <infinity.sbn> |
Component: | NetworkManager | Assignee: | Lubomir Rintel <lkundrak> |
Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 27 | CC: | bgalvani, dcbw, fgiudici, gunnar, infinity.sbn, jonathan, lkundrak, lnykryn, thaller, vladimir-csp, zbyszek |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2018-11-30 23:36:18 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Davide Lima "Duarte" Daum
2017-01-14 03:10:46 UTC
AFAIK, NetworkManager has never managed the loopback interface. I think iniscripts are involved in this. Are You sure ? The only log i can find about the loopback are those from journactl: Jan 14 02:35:39 central46 NetworkManager[406]: <info> [1484361339.0752] device (lo): link connected Jan 14 02:35:39 central46 NetworkManager[406]: <info> [1484361339.0784] manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/0) Nothing else tell me that the loopback is up except for the Network Manager... (In reply to Davide Lima "Duarte" Daum from comment #2) > Are You sure ? The only log i can find about the loopback are those from > journactl: > > Jan 14 02:35:39 central46 NetworkManager[406]: <info> [1484361339.0752] > device (lo): link connected > Jan 14 02:35:39 central46 NetworkManager[406]: <info> [1484361339.0784] > manager: (lo): new Generic device (/org/freedesktop/NetworkManager/Devices/0) > > Nothing else tell me that the loopback is up except for the Network > Manager... NM only recognizes that the loopback exists and is up. initscripts configure it: https://git.fedorahosted.org/cgit/initscripts.git/tree/rc.d/init.d/network#n70 If you enable network initscript (disabled by default) it should work. The question is if there is a use-case for this why NM does not handle it. Ok, enabling the network script now i have the alias working on the loopback. Just to confirm, if i disable Network Manager isn't a problem right ? Because to manage the network configuration i prefer only one tool, and because NM is unable to manage the configuration i have, may i use only the historical and bullet proof network script ? ;) The network-scripts have drawbacks. There is no hotplug, so all of the devices needs to be present during the boot when the network.service is started. Also there is no support for some wireless connections, *-vlans,... But if you have an old-fashioned setup you can use just them. It's a server so no need of wifi. For the vlan are You telling me that this doc page isn't right anymore? https://docs.fedoraproject.org/en-US/Fedora/25/html/Networking_Guide/sec-Configure_802_1Q_VLAN_Tagging_Using_the_Command_Line.html Hello Duarte, nowadays we prefer people to use NetworkManager where possible. So the question from Lukáš stays: Why do you need to have aliases on the loopback device? Is there any valid usecase for this, that we can't think of right now? If so, could you please describe that use case? Without it, it's hard to tell if NetworkManager should support such scenario or not. (In reply to Davide Lima "Duarte" Daum from comment #7) > It's a server so no need of wifi. > For the vlan are You telling me that this doc page isn't right anymore? > > https://docs.fedoraproject.org/en-US/Fedora/25/html/Networking_Guide/sec- > Configure_802_1Q_VLAN_Tagging_Using_the_Command_Line.html Plain vlans works just fine, I was mentioning stuff like macvlans. Example on the use of loopback interface ? In my case the servers are vpn gateway and every server publish some service only on connected on the vpn. So because You cannot use the "127.0.0.1" to access the services on the server You need to use a network, for example 192.168.200.128/32. Apache bind on this address and not on 0.0.0.0. There are a lots of use about an alias in loopback...LVS, or if you want to bind service on the same port on different local address to avoit the boring part to put :port like 8080 for a web and so on... I think that if You want to move on NM all the network configuration, this tool must give the same configuration option we have from the old network script...or we will be forced to manage this things via rc.local or different messy scripts... (1) to have a "lo" interface with 127.0.0.1 you don't need NetworkManager. (2) having additional IP addresses on "lo" is an uncommon (but useful) scenario. NM doesn't manage "lo" because (1) works fine without NM and (2) is an uncommon scenario. But it's really just a missing feature... yes, NM should support this. Hi Thomas, i don't know what is Your background but in my experience here in Italy, the use of the loopback isn't so uncommon. Here we are a lot of debian or ubuntu in production environment and i never saw that the content of the /etc/network/interface (debian based distros) will be ignored because NM. We started to use fedora for the development environment and in production because we need some packages to be near the edge. Maybe a message in the docs that the functionality of the scripts in /etc/sysconfig/network-script will be (ignored|modified) by NM, and that this way to configure will be deprecated in the (near|distant) future, is a good way to start to implement some solution in different way to avoid problems like what i encountered with the loopback alias. This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. As a system engineer I have seen a lot of cases of lo aliases in use. Primarily it is a way to hand routed or proxied traffic to locally bound daemons and add another point for fine-tuning traffic flows. "Loopback alias" connection type would be a great feature addition to Network Manager if you wish to expand its use on servers and routers. As a network admin and devops i'd like to chime in a bit. Even if this might not be the right place. With a server where the main network interface is only for outbound connections, we use loopbacks for incoming services. Daemons bind the loopback address for the specific service. Reasons include but are not limited to: - ddos protected ip - anycasted ip - management ip note: also affected, Fedora 28. This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 27 changed to end-of-life (EOL) status on 2018-11-30. Fedora 27 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |