Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 124643
Summary: | system-config-network-cmd does not work as advertised | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Michal Jaegermann <michal> |
Component: | system-config-network | Assignee: | Harald Hoyer <harald> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | andrew, mattdm, redhat.com, triage |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | bzcl34nup | ||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2008-04-29 22:27:33 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 125274 |
Description
Michal Jaegermann
2004-05-28 03:52:12 UTC
I'm seeing the same thing when the "nickname" for the device does not match the device name. It works when I make sure that the nickame is "eth0" or "eth1" I believe this is related: s-c-n 1.3.17-0.FC2.1 I (would like to) have 5 profiles for different wireless environments, each with a different ifcfg-eth1 containing various ESSID= KEY= MODE= lines. After executing system-config-network -p <profilename> I find that all my instances of /etc/sysconfig/networking/profiles/*/ifcfg-eth1 /etc/sysconfig/networking/devices/ifcfg-eth1 /etc/sysconfig/network-scripts/ifcfg-eth1 have been hard-linked as a single instance which is scarcely helpful Cancel that comment --- that's what comes from working in text mode and not fully understanding how the tool is trying to work. I think that one one of problems is that is really hard to even start to understand, not talking about "fully", how this is supposed to work beyond very basic "one interface - one connection". I have to meet yet a person who would be not baffled by this tool. Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match. I do not think that this was ever really changed either in FC3 or in FC4test. A "solution" to the problem seems to be not to have ever "active" devices in a Common profile in a case when multiple profiles are in use. These other profiles are the only one with active devices. I did not try various possible ways of using system-config-network but _this_ seem to work. How this can be derived from a documentation and/or interfaces instead of a trial-and-error is still unclear to me. Is there any documentation on this? Or any working examples? I decided to take another look at this today, and it's driving me absolutely crazy. If I use names like eth0 (resulting in names like /etc/sysconfig/network-scripts/ifcfg-eth0) the different profiles get confused. If I use names like eth0_home, then I get errors from /sbin/dhclient-script which only looks for ifcfg-$DEVICE, i.e. ifcfg-eth0. This is on a fully updated FC3 system. AFAICT this basically works with multiple profiles provided _none_ of interface definitions is selected in "Common" which serves only as a container to hold all "devices" (to me a quite misleading terminology). Now if you will create various profiles in which want to use, assign what you want to belong to each of these and do some other necessary modifications like name servers and /etc/hosts tables, then you can switch between profiles with expectations that results will make some sense. Selecting something in "Common", when other profiles are present, seems to be a recipe for an instant disaster. Maybe if you have some interface which indeed is common across all your possible profiles then it can be selected there. If this is how it is _supposed_ to be I have no idea but feel free to study a content of files in /usr/share/system-config-network/help/. Currently they are owned by 'system-config-network-tui'. Fedora Core 3 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC5 updates or in the FC6 test release, reopen and change the version to match. Thank you! harald moved this to devel. thanks! Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again. I have to find yet somebody for whom setting up networking with multiple profiles would be "obvious". If, on the top of it, one would like to have one of these profiles controlled by NetworkManager and other static then we are moving into "Mission Impossible" teritory. After so long time I am not going to loose my sleep over those issues. Re: comment #12 does this mean you are fine closing this bug? Re: comment #13. I guess so. It does not appear that there is much point in keeping it open but maybe there are dissenting opinions? thanks for your update |