Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 169749 - initscripts - 'need_config ()' in network-functions may not find the right CONFIG
Summary: initscripts - 'need_config ()' in network-functions may not find the right CO...
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 4
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Brock Organ
: 196324 (view as bug list)
Depends On:
Blocks: FC5Target
TreeView+ depends on / blocked
Reported: 2005-10-02 23:22 UTC by Michal Jaegermann
Modified: 2014-03-17 02:56 UTC (History)
3 users (show)

Fixed In Version: 8.38-1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-08-03 00:45:46 UTC

Attachments (Terms of Use)
a proposed patch for network-functions (it makes things to work for me again) (deleted)
2005-10-02 23:22 UTC, Michal Jaegermann
no flags Details | Diff

Description Michal Jaegermann 2005-10-02 23:22:31 UTC
Description of problem:

The problem strikes at least in /sbin/dhclient-script.  There is a silent
assumption there that if we are configuring an interface, say, eth0 then
a config file will be called ifcfg-eth0. Usually this is the case but if
we have mulitiple network profiles then this file, as produced by
'system-config-network', may be called ifcfg-<whatever> even if an underlying
device is indeed eth0.

In such situation trying to start dhclient results in the following:

/sbin/dhclient-script: configuration for eth0 not found. Continuing with defaults.
basename: too many arguments
Try `basename --help' for more information.
basename: too many arguments
Try `basename --help' for more information.
/sbin/dhclient-script: configuration for eth0 not found. Continuing with defaults.
basename: too many arguments
Try `basename --help' for more information.
basename: too many arguments
Try `basename --help' for more information.

To find that "missing" configuration one needs only try a bit harder
in 'need_config' function using something like an attached patch.
Maybe one should use 'grep -il' there instead of 'grep -l' but this
seems to be excessive. 

A search by a hardware address, which follows in 'need_config', could find 
the right configuration file if:
  - there is a HWADDR specified there, which is not certain
  - if there are no aliases to the given interface with the same HWADDR
    as then multiple filenames are produced and nothing can be guaranteed
    about ordering; moreover we may want a config for an alias
  - only a basename instead of a full path is returned; the later does
    not really seems to be what is desired elsewhere.

The second issue above could be avoided by checking which configuration
file from many returned is the right one but then a proposed patch does really
just that.

This is filed for FC4 but the problem is actually "everywhere" (including
FC3, rawhide and RHEL).

Comment 1 Michal Jaegermann 2005-10-02 23:22:32 UTC
Created attachment 119522 [details]
a proposed patch for network-functions (it makes things to work for me again)

Comment 2 Bill Nottingham 2005-10-03 19:05:22 UTC
I'm sorry, I'm not following in general - can you give some example configs of
yours that trip this up?

Comment 3 Michal Jaegermann 2005-10-03 21:33:27 UTC
OK, for whatever reasons I have now a box with two profiles which can be
switched in between (plus a regular "Common", a.k.a. "default" which does not
"own" any interfaces as that would mess up switching very badly).

One of these profiles configures interfaces eth0, eth0:0, eth0:1 and eth1
with eth0 getting its address over DHCP and all other interfaces static.
Corresponding configuration files happen to be called 'ifcfg-eth0spare',
'ifcfg-eth0:0spare', 'ifcfg-eth0:1spare' and 'ifcfg-eth1spare' (although these
names could be something different but not like 'ifcfg-eth0' as these names
are already used by the other profile and all files in
/etc/sysconfig/networking/devices/ are different even if they refer to the
same interfaces)

Files 'ifcfg-eth0:0spare' and 'ifcfg-eth0:1spare' were created by "Copy"
operation in 'neat' and later by editing their content so, not quite naturally,
all of the share the same 'HWADDR=...' line.  Of course _none_ of these
three files would have to have that line but it happens to be there.

All of that works fine on starting, stopping and configuring all interfaces
if I am using 'need_config()' patched as above.  Otherwise I am seeing what
is described in the original report.

Also a trivial shell script which sources 'network-functions', runs 'need_config'
with an argument passed to it and echos resulting $CONFIG works correctly
with any interface argument and any profile.  Without that patch everything
is fine when config files used happen to have names like 'ifcfg-eth0',
'ifcfg-eth0:1', and so on (which is not very surprising) but I am getting
obviously wrong results otherwise.

Note that when you are searching for a configuration file by a hardware
address it would not help to do 'grep ... | head -1'.  You have no idea
that the file you want would come on the top.

OTOH somebody could have put some extra comments on 'DEVICE=...' line
so instead of using blindly grep it would be more prudent source these
files one by one in a subshell, so we will not mess up other assignments,
and echo a file name on a match.  Something like that:

  ( for f in /etc/sysconfig/network-scripts/ifcfg-* ; do
        [ -r $f ] || continue
        source $f
        if [ "$DEVICE" = "${1}" ]; then echo $f; break; fi
    done )

Similar would also be likely more robust if one has to resort to a search
by HWADDR but then I do not know of a simple way of a case independent string
comparison, even if bash has down(up)casing functions, without invoking some
external programs (and 'tr' is in /usr/bin although 'awk' is /bin/awk).
It is possible though, in shell, to split MACs and compare hexadecimal numbers.

Comment 4 Bill Nottingham 2005-10-03 21:48:03 UTC
So, the case you're talking about essentially boils down to:

ifcfg-$NAME where $NAME != $DEVICE.
and $HWADDR is in multiple of these files.


Comment 5 Michal Jaegermann 2005-10-03 22:02:27 UTC
> Correct?

Yes, that is what I indeed wrote in the original report but you wanted
a specific example.  Such configuration is neither incorrect nor unusual
(if not so frequent).

Comment 6 Michal Jaegermann 2005-10-03 23:09:16 UTC
That could be even better for a search loop as it avoids a basename call.

  ( for f in /etc/sysconfig/network-scripts/ifcfg-* ; do
        [ -r $f ] || continue
        source $f
        if [ "$DEVICE" = "${1}" ]; then echo ${f##*/}; break; fi
    done )

Comment 7 Michal Jaegermann 2005-10-04 04:30:02 UTC
When I started to look at 'network-functions' then I noticed that 'get_hwaddr'
can be simplified to:

    LC_ALL= LANG= ip -o link show ${1} 2>/dev/null | \
      awk '{ print toupper($(NF - 2)) }'

and if you do not want to count fields then you can do

      awk -F'link/[^ ]*  *' '{sub(/ .*/,"", $2); print toupper($2)}'

instead.  I think that the first version is fine.

Also in 'is_available' a line

 if [ -z "$alias" -o "$alias" = "off" -o "$alias" = "/bin/true" ]; then

should read

 if [ -z "$alias" -o "$alias" = "off" -o \
       "$alias" = "/bin/true" -o "$alias" = ":" ]; then

Comment 8 Miloslav Trmač 2006-07-26 03:36:40 UTC
Fixed in CVS.  I have moved the grep for DEVICE= after the HWADDR lookup because
HWADDR is generally more specific than a device name, and alias configuration
files should not contain HWADDR.

Thanks for the patches!

Comment 9 Bill Nottingham 2007-04-17 00:10:08 UTC
*** Bug 196324 has been marked as a duplicate of this bug. ***

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