This looks like a pretty basic parser error in netcf. Including quotes is certainly allowed & needs to be taken into account.

Yeah this is something that somebody just started doing recently, which is why it hasn't popped up before now. (I actually saw it once about a week ago for the first time, but assumed at the time that it was something I'd messed up, not that it came that way out of the box).

David - is this something that has to be handled in Augeas, or at a higher level?

Dan - do you know what code has changed that's started putting quotes around all the values in the ifcfg-* files? (who makes the original ifcfg files? anaconda?)

I have no problem supporting the reading of these files, but am loathe to start quoting when writing *to* the files without knowing why they're showing up this way now.

(In particular, if they're just stripped off when augeas reads them in, during the write there would be no information about whether or not to quote (what about newly defined values?) and I don't want to start quoting everything in ifcfg-* files on older systems; who knows what other tools / scripts that might screw up... I notice that NetworkManager unquotes everything as it writes it, unless there's a space in the value, which makes sense to me)

Created attachment 431984 [details]
affects on adding new network interface on host

It affects the virt-manager on adding new network interface on host.

IMHO it isn't relevant what app is putting quotes, because an admin editing the files themselves is just as likely to add quotes. So we need to cope with this regardless. The ifcfg-XXX files are technically in "shell" syntax, hence quotes are required if the value contains whitespace or other shell meta characters, otherwise optional.

I both agree and disagree with you. I agree that netcf should be able to handle quoted values, but do think knowing who made the change is relevant - it's possible it was just a gratuitous change (likely) in which case it won't be a problem if netcf writes out modified lines with unquoted values, but it's also possible that someone made the change and now expects all the values to be quoted (very unlikely, but possible).

A fix has been committed upstream:

https://fedorahosted.org/pipermail/netcf-devel/2010-July/000431.html

I've tested this, and it does properly solve the problem. Now awaiting the necessary ACKs to put it into RHEL.

That fix is also now posted to rhvirt-patches:

http://post-office.corp.redhat.com/archives/rhvirt-patches/2010-July/msg00580.html

netcf-0.1.6-3.el6, which contains the fix, has been built for RHEL-6, and will
be in the next compose.

After upgrade the netcf-0.1.6-3.el6 and restart the libvirtd service, there is an error occured when I try iface-list:

[root@dhcp-66-92-126 images]# virsh iface-list --all
error: Failed to list active interfaces
error: internal error failed to get number of interfaces on host (netcf: unspecified error - errors in loading some config files)

version of related components:
libvirt-0.8.1-15.el6.x86_64
netcf-0.1.6-3.el6.x86_64
kernel 2.6.32-50.el6.x86_64

Please attach the contents of the /etc/sysconfig/network-scripts/ifcfg-* files, as well as /etc/sysconfig/iptables.

Today after I reinstall the netcf-0.1.6-3.el6.x86_64, it appears another error:
[root@dhcp-66-92-126 Downloads]# virsh iface-list --all
error: Failed to list active interfaces
error: this function is not supported by the connection driver: virConnectNumOfInterfaces

version of related components:
libvirt-0.8.1-17.el6.x86_64
netcf-0.1.6-3.el6.x86_64
kernel 2.6.32-50.el6.x86_64 

#vi /etc/sysconfig/network-scripts/ifcfg-eth0

DEVICE="eth0"
BOOTPROTO="dhcp"
ONBOOT="yes"

#vi /etc/sysconfig/iptables

# Generated by iptables-save v1.4.7 on Mon Jul 19 19:09:45 2010
*nat
:PREROUTING ACCEPT [3325:514584]
:POSTROUTING ACCEPT [291:29482]
:OUTPUT ACCEPT [325:33721]
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p tcp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -p udp -j MASQUERADE --to-ports 1024-65535
-A POSTROUTING -s 192.168.122.0/24 ! -d 192.168.122.0/24 -j MASQUERADE
COMMIT
# Completed on Mon Jul 19 19:09:45 2010
# Generated by iptables-save v1.4.7 on Mon Jul 19 19:09:45 2010
*filter
:INPUT ACCEPT [23:3309]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2:100]
-A INPUT -i virbr0 -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -i virbr0 -p udp -m udp --dport 67 -j ACCEPT
-A INPUT -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT
-A FORWARD -m physdev --physdev-is-bridged -j ACCEPT
-A FORWARD -d 192.168.122.0/24 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 192.168.122.0/24 -i virbr0 -j ACCEPT
-A FORWARD -i virbr0 -o virbr0 -j ACCEPT
-A FORWARD -o virbr0 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr0 -j REJECT --reject-with icmp-port-unreachable
COMMIT
# Completed on Mon Jul 19 19:09:45 2010

Sorry, I forget to close the NetworkManager and after I close it, the error is the same as Comment 13.

David,

It's not liking the iptables file. Can you see what's wrong with it?

By the way, weizhang - I'm curious why you have set 

net.bridge.bridge-nf-call-iptables = 1

on this test machine. The default for RHEL6 is 0. If it is set to 0, netcf won't even need to read the iptables file at all, and will thus avoid this problem. (it still should be fixed, of course)

Laine Stump, I doesn't set 
net.bridge.bridge-nf-call-iptables = 1

# sysctl -p
net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

Very interesting! When I put your iptables file on my system and set net.bridge.bridge-nf-call-iptables = 1, netcf fails exactly as you say, but when I set net.bridge.bridge-nf-call-iptables = 0, it works with no problem (because it's not reading the iptables file).

Can I have access to the system to look around myself for other causes?

Thanks!

This error:

error: internal error failed to get number of interfaces on host (netcf:
unspecified error - errors in loading some config files)

was due to the 0.1.6-3 build requiring a new file, but not installing that file. This only affected RHEL builds, not upstream, because the RHEL specfile doesn't regenerate Makefile.in from Makefile.am.

A patch has been posted to the internal patch list.

*** Bug 618618 has been marked as a duplicate of this bug. ***

netcf-0.1.6-4.el6 has been built with the fix. It will be in RHEL 6.0 snapshot 9, and is also available here:

https://brewweb.devel.redhat.com/taskinfo?taskID=2630304

A better link to find the rpm's is one to the buildinfo:

https://brewweb.devel.redhat.com//buildinfo?buildID=138474

After upgrade the netcf to 0.1.6-4, I test it

#cat /etc/sysconfig/network-scripts/ifcfg-eth0 
DEVICE="eth0"
BOOTPROTO="dhcp"
HWADDR="B8:AC:6F:3B:0D:56"
NM_CONTROLLED="yes"
ONBOOT="yes"

#virsh iface-list --all
Name                 State      MAC Address
--------------------------------------------
eth0                 active     b8:ac:6f:3b:0d:56
lo                   active     00:00:00:00:00:00

# ifconfig
eth0      Link encap:Ethernet  HWaddr B8:AC:6F:3B:0D:56  
          inet addr:10.66.93.195  Bcast:10.66.93.255  Mask:255.255.254.0
          inet6 addr: 3ffe:501:ffff:100:baac:6fff:fe3b:d56/64 Scope:Global
          inet6 addr: fe80::baac:6fff:fe3b:d56/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1377806 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1368576 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1091153086 (1.0 GiB)  TX bytes:993362949 (947.3 MiB)
          Memory:fdfe0000-fe000000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:34289 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34289 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:72310869 (68.9 MiB)  TX bytes:72310869 (68.9 MiB)

I think there is no problem now

version info:
libvirt-0.8.1-18.el6.x86_64
netcf-libs-0.1.6-4.el6.x86_64
netcf-0.1.6-4.el6.x86_64
kernel 2.6.32-52.el6.x86_64

Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

*** Bug 623731 has been marked as a duplicate of this bug. ***

When the following syntax is placed in "/etc/sysconfig/network-scripts/ifcfg-eth0" the problem reappears.

DEVICE="eth0";                  # The physical device name. **COMPULSORY**
HWADDR="20:CF:30:04:B9:61";     # The mac address used to recognise hardware.
ONBOOT="yes";                   # Initialise this device on system start-up.
BRIDGE="br0";                   # This DEVICE is part of this BRIDGE.

When the following syntax is placed in "/etc/sysconfig/network-scripts/ifcfg-eth0" the problem reappears.

DEVICE="eth0";
HWADDR="20:CF:30:04:B9:61";
ONBOOT="yes";
BRIDGE="br0";

but when the following syntax is used instead, there is no problem.

DEVICE="eth0"
                                # The physical device name. **COMPULSORY**
HWADDR="20:CF:30:04:B9:61"
                                # The mac address used to recognise hardware.
ONBOOT="yes"
                                # Initialise this device on system start-up.
BRIDGE="br0"
                                # This DEVICE is part of this BRIDGE.

My guess would be that the netcf libraries do not like a semi-colon at the end of a line. The above syntax works fine with the initscripts package.


rpm -q netcf netcf-libs
    netcf-0.1.9-2.el6.x86_64
    netcf-libs-0.1.9-2.el6.x86_64


As per the comments above, netcf should accept valid shell characters in the network-scripts/ifcfg files.

@pmoore: this bug is now closed because an errata has been issued. Due to the way bug / release process works, this will not be re-opened, so please file a new bug for the problems you describe in comment #29

I have opened a new bug https://bugzilla.redhat.com/show_bug.cgi?id=761246 for this.