Description of problem: It would appear that an existence of different "profiles" would be quite handy for a machine which will be connected at various times to different networks - each with its own parameters. This is great upto a moment one realizes that all copies of a rather crucial 'ifcfg-eth0' are really hard links - like that: 26642 1 -rw-r--r-- 4 root root 288 May 3 11:32 ./network-scripts/ifcfg-eth0 26642 1 -rw-r--r-- 4 root root 288 May 3 11:32 ./networking/devices/ifcfg-eth0 26642 1 -rw-r--r-- 4 root root 288 May 3 11:32 ./networking/profiles/default/ifcfg-eth0 26642 1 -rw-r--r-- 4 root root 288 May 3 11:32 ./networking/profiles/dynamic/ifcfg-eth0 so editing it in one "profile" is messing up settings in all others. Pretty useless. Now I realize why one of my friends far away was complaining that attempts to configure network modem connections on his laptop were destroying his, rather carefuly prepared, "regular" network connections he needed working in other times. I have only seen "post-mortem" mess which he created while trying (not with a great understanding) to find a solution to his problem and results were not pretty. He indeed ended up with a bunch of hard links he never intended to create, and likely he is not too sure what really is a hard link, and could not comprehend why apparently unrelated changes were killing his ability to connect. Version-Release number of selected component (if applicable): redhat-config-network-1.2.0-2 but this is really an old problem
no... wrong concept... make a new configuration with r-c-n and mark it only active in the appropriate profile.
Well, if this is "wrong" then what profiles are good for? Besides it is very far from clear how to perform the suggested action. Despite NOTABUG resolution in my take this is actually a severe bug at least in a user interface. Beside that person who totally messed up a networking on his laptop, mentioned in the original report, did not touch r-c-n or equivalents. He just tried to get his modem working, using relevant tools (some "wizzards") and found that his configuration was destroyed. So it looks like that writers of that Red Hat supplied software had the same "wrong concept" too. BTW - a bad workaround he eventually employed was to configure a modem every time from scratch in a "debug mode" as this was not writing anything permanently. Reopened (and close it again if you really think that everything is like it should be).
hmm, hmm... things are _not_ like they should be... I should write some documentation, how to create profiles, and what are these hardlinks for. which config file was destroyed? ifcfg-ppp0?
Documentation for profiles: file:///usr/share/redhat-config-network//help/network-profiles.html
You may also use the updates from: http://people.redhat.com/harald/redhat-config-network/
> which config file was destroyed? ifcfg-ppp0? I realized that I have still this directory on old tapes. This was with a Red Hat 7.3 or 7.2 installation (graphics now is different but principles seem to be the same). This is what I found post-mortem in /etc/sysconfig/networking/profiles/default (never mind file names) -rw-r--r-- 3 root root 838 Feb 25 11:50 hosts -rw------- 1 root root 390 Dec 17 2001 ifcfg-IMPAN -rw------- 1 root root 336 Dec 16 2001 ifcfg-Impan -rw------- 1 root root 390 Mar 18 2002 ifcfg-Modem -rw------- 1 root root 371 Dec 16 2001 ifcfg-Snia -rw------- 7 root root 38 Nov 29 2001 ifcfg-eth0 -rw------- 1 root root 388 Dec 17 2001 ifcfg-modem -rw-r--r-- 2 root root 196 Feb 24 18:32 ifcfg-ppp0 -rw------- 1 root root 286 Dec 17 2001 ifcfg-ppp1 -rw------- 1 root root 255 Dec 16 2001 ifcfg-ppp2 -rw------- 1 root root 388 Dec 17 2001 ifcfg-snia -rw-r--r-- 1 root root 30 Mar 18 2002 network -rw-r--r-- 1 root root 0 Feb 24 19:35 resolv.conf with this in ifcfg-ppp0 DEVICE=ppp0 NAME=Impan WVDIALSECT=Impan MODEMPORT=/dev/modem LINESPEED=115200 PAPNAME=piotr USERCTL=true ONBOOT=no PERSIST=no DEFROUTE=yes PEERDNS=yes DEMAND=no IDLETIMEOUT=600 DNS1=195.187.72.50 and various similar things in this style (sometimes DHCP, sometimes not) in other files. In 'ifcfg-eth0' I found, quite drastically different from the original, DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes where 7 hard links visible above refer to ./devices/ifcfg-eth0 ./netswitch/dynamic/ifcfg-eth0 ./netswitch/guest/ifcfg-eth0 ./netswitch/imada/ifcfg-eth0 ./netswitch/michal/ifcfg-eth0 ./netswitch/noether/ifcfg-eth0 ./profiles/default/ifcfg-eth0 where 'netswitch' directory originally contained files for various network configurations and he had some tools to switch between these (in particular a menu on boot) and _none_ of the above were originally hard links and switching tools used _copies_ and not linking. One would think that in a "private" directory things would be safe but this was clearly not the case. Oh, and 'resolve.conf' in various "netswitch" directories were far from empty so even if he managed to configure eth0 on some networks without DHCP he found that a name resolution, obviously enough, does not work. I am not entirely sure what he really did to achieve these results but definitely only GUI tools, and he claims that only for configuring a modem. I do not have reasons to doubt that as he has a very vague idea what a hard link could be. After playing a bit with r-c-n in RH9 I am starting to understand although details still elude me. If all of the above is not thorougly confusing then I do not know what is. :-) Mind you - even if some details are different between then and now results of "obvious" actions in end-user tools are still, from my point of view, unpredictable beyond trivial situations and this is where is the trouble.
Huh? what is this? Not from our tools... ./netswitch/dynamic/ifcfg-eth0 ./netswitch/guest/ifcfg-eth0 ./netswitch/imada/ifcfg-eth0 ./netswitch/michal/ifcfg-eth0 ./netswitch/noether/ifcfg-eth0
> Huh? what is this? Not from our tools... Sigh! Let me remind you that my description was talking about 'netswitch' directory as a "private" one and that one was _one_ of points. "Our tools" managed somehow to hard link _all_ ifcfg-eth0 files in sight, even if places where they obviously had no business to meddle, and this spelled trouble. Even if you would have only "regular" directories around results would be really the same. Take all of the above as an illustration of what is happening, which I happened to have on hands, and not literally. The original complaint that "profiles" do not allow you to do very much stands on its own.
Since I am very often at customer sites with different network setups. I tried the profiles too. And was also disappointed seeing that this tool only generates hard links and all of my work was gone. So I created a copy of the profiles/default directory, created an init script which is just executed before network asking me for the profile I wish to set. In order to allow unattended startup it waits 5 seconds for input, otherwise it starts with the last selected profile. It does not claim to be complete but it's dirty hack which works for me.
Red Hat apologizes that these issues have not been resolved yet. We do want to make sure that no important bugs slip through the cracks. Red Hat Linux 7.3 and Red Hat Linux 9 are no longer supported by Red Hat, Inc. They are maintained by the Fedora Legacy project (http://www.fedoralegacy.org/) for security updates only. If this is a security issue, please reassign to the 'Fedora Legacy' product in bugzilla. Please note that Legacy security update support for these products will stop on December 31st, 2006. If this is not a security issue, please check if this issue is still present in a current Fedora Core release. If so, please change the product and version to match, and check the box indicating that the requested information has been provided. If you are currently still running Red Hat Linux 7.3 or 9, please note that Fedora Legacy security update support for these products will stop on December 31st, 2006. You are strongly advised to upgrade to a current Fedora Core release or Red Hat Enterprise Linux or comparable. Some information on which option may be right for you is available at http://www.redhat.com/rhel/migrate/redhatlinux/. Any bug still open against Red Hat Linux 7.3 or 9 at the end of 2006 will be closed 'CANTFIX'. Again, if this bug still exists in a current release, or is a security issue, please change the product as necessary. We thank you for your help, and apologize again that we haven't handled these issues to this point.
The rule seems to be: "If you attempt multiple profiles then do not ever assign any interface to Common or you will get screwed". I do not think that this is stated anywhere explicitely or implicitely or that there are any guards which would at least warn that something may not end up right. It is my experience that if somebody "unitiated" is modyfying anything in network profiles setup (in particular various sysadmins on a laptop of my wife when she travels) then invariably the whole thing gets bungled and needs later, often extensive, restoration work. Hard not to conclude that this interface design is too difficult to be generally understood not even mentioning anything about "obvious".