Bug 114715 - Hard Links Created Backwards
Hard Links Created Backwards
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-network (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
Depends On:
Blocks: rcn-profiling
  Show dependency treegraph
 
Reported: 2004-02-01 01:42 EST by Brian Beaudoin
Modified: 2007-04-18 13:02 EDT (History)
0 users

See Also:
Fixed In Version: system-config-network-1.3.26-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-20 08:08:26 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 Brian Beaudoin 2004-02-01 01:42:25 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1)
Gecko/20030225

Description of problem:
When creating a profile or switching between profiles, the files are
deleted from the profile directories and replaced with hard links to
the running system configuration files.

Because all profile files link to the running system configuration
files, changes to one profile are immediately reflected in the current
configuration and in all other profiles created.  When the profile
files are created by hand (by copying and editing the files directly)
and the profile is switched, the same effect occurs.

The problem appears to be in NCProfileList.py.  The source and
destination files seem to be reversed with 'devfilename' being the
source and 'profilename' being the destination (as defined in
NC_functions.py).

This problem is easily duplicated.

Version-Release number of selected component (if applicable):
redhat-config-network-1.2.15-1

How reproducible:
Always

Steps to Reproduce:
1.  Create a new profile with the GUI configuration utility
2.  Select the new profile (if not already selected)
3.  Change a setting in the new profile
4.  Save the settings
5.  Examine the inodes of the files under
     /etc/sysconfig/networking/profiles/*
6.  The files in both profiles are linked to the same inodes
    

Actual Results:  Effectively the configuration in one profile is lost
when changes are made to the other profile or when a new profile is
selected because the files are deleted and set to reference the same
configuration.

Expected Results:  The files under each profile should have unique
inodes and the running system configuration files should be linked
(hard or soft) to the current running profile.  Switching profiles
shouldn't clobber the second profile's settings.

Additional info:

This problem may be reproduced on Red Hat 9 with
redhat-config-network-1.2.15-1 and on Fedora Core 1 with
redhat-config-network-1.3.10.

I am not cross-posting this bug and hope it doesn't get passed by
because someone thinks it is just a problem with Red Hat 9 which is
reaching "end of life".
Comment 1 Harald Hoyer 2004-02-05 11:37:09 EST
how to use profiles:
http://people.redhat.com/harald/redhat-config-network/help/network-profiles.html
this may be considered a design bug, which makes it non-intuitive...
Comment 2 Brian Beaudoin 2004-02-07 23:40:18 EST
You're right - it is a design bug because if a profile is
automatically an exact copy of another profile (and by extension, the
default profile) then it compeltely negates the purpose of having
profiles to begin with.

The document "Working with profiles" says you can have an Away profile
that always starts up the ppp interface and an Office profile that
always starts up the eth0 interface but that only the default profile
is activated at boot time.  Here's the problem with that:

[...]/profiles/default/ifcfg-eth0 ->  ../../network-scripts/ifcfg-eth0
[...]/profiles/Away/ifcfg-eth0 ->  ../../network-scripts/ifcfg-eth0
[...]/profiles/Office/ifcfg-eth0 ->  ../../network-scripts/ifcfg-eth0

No matter what, the default profile is activated at boot time because
really there is only ONE profile.  On the other hand, if the links
were created like this:

(Inode 123 for example)
[...]/network-scripts/eth0 -> ../../profiles/default/ifcfg-eth0

(Inode 456) /etc/sysconfig/networking/profiles/Away/ifcfg-eth0
(Inode 789) /etc/sysconfig/networking/profiles/Office/ifcfg-eth0

Then:
    (1) The selected profile would always be the bootable default
    (2) Each profile could be unique (not sharing inodes w/default)
    (3) The program would match the documentation you referenced

Aliases, yes, I understand.  If a laptop user doesn't have root
access, they need a simple way to swap configurations.  There isn't
any confusion about that and that isn't what this is related to.

BTW, I already use aliases - basically the same as root doing:

    # ifdown eth-home
    # ifup eth-office

If the hard links were corrected, one could select "Home" (with root
access of course) before leaving the office and when getting home
voila!  It's in the right configuration (and vice-versa).

Please note, only the /etc/sysconfig/networking-scripts files are
linked incorrectly.  Please observe the following outputs of 'ls -i':

  1255798 /etc/hosts
  1255798 /etc/sysconfig/networking/profiles/default/hosts
   213504 /etc/sysconfig/networking/profiles/Testing/hosts

  1255799 /etc/resolv.conf
  1255799 /etc/sysconfig/networking/profiles/default/resolv.conf
   213503 /etc/sysconfig/networking/profiles/Testing/resolv.conf

   440741 /etc/sysconfig/networking/profiles/default/ifcfg-eth0
   440741 /etc/sysconfig/networking/profiles/Testing/ifcfg-eth0
   440741 /etc/sysconfig/network-scripts/ifcfg-eth0

As you see, the /etc/ files are linked to the active profile.  On the
other hand, the /etc/sysconfig/networking/profiles/<profile>/ files
ended up being cross-linked.

Definitely a bug.

This is quite simple to reproduce - I "saved" the default profile,
created a new profile called "Testing", then I saved the new profile
and selected the default profile again and saved again.

Definitely non-intuitive as well.

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