Bug 90171

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".