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).
Created attachment 119522 [details] a proposed patch for network-functions (it makes things to work for me again)
I'm sorry, I'm not following in general - can you give some example configs of yours that trip this up?
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.
So, the case you're talking about essentially boils down to: ifcfg-$NAME where $NAME != $DEVICE. and $HWADDR is in multiple of these files. Correct?
> 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).
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 )
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
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!
*** Bug 196324 has been marked as a duplicate of this bug. ***