Bug 90171 - Network profiles in the current state have a rather dubious utilty
Network profiles in the current state have a rather dubious utilty
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-network (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks: rcn-profiling
  Show dependency treegraph
 
Reported: 2003-05-04 09:59 EDT by Michal Jaegermann
Modified: 2007-04-18 12:53 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-05 13:08:49 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michal Jaegermann 2003-05-04 09:59:26 EDT
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
Comment 1 Harald Hoyer 2003-05-06 09:39:01 EDT
no... wrong concept... make a new configuration with r-c-n and mark it only
active in the appropriate profile.
Comment 2 Michal Jaegermann 2003-05-06 11:31:18 EDT
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).
Comment 3 Harald Hoyer 2003-05-06 11:54:41 EDT
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?
Comment 4 Harald Hoyer 2003-05-06 11:59:13 EDT
Documentation for profiles:
file:///usr/share/redhat-config-network//help/network-profiles.html
Comment 5 Harald Hoyer 2003-05-06 12:00:19 EDT
You may also use the updates from:
http://people.redhat.com/harald/redhat-config-network/
Comment 6 Michal Jaegermann 2003-05-06 13:20:38 EDT
> 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.
Comment 7 Harald Hoyer 2003-05-12 09:09:02 EDT
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
Comment 8 Michal Jaegermann 2003-05-12 12:08:23 EDT
> 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.
Comment 9 Cengiz Tuztas 2003-11-20 15:49:07 EST
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. 
Comment 10 Bill Nottingham 2006-08-04 23:10:15 EDT
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.
Comment 11 Michal Jaegermann 2006-08-05 13:08:49 EDT
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".

Note You need to log in before you can comment on or make changes to this bug.