Bug 784647 - Libguestfs uses deprecated net-tools
Libguestfs uses deprecated net-tools
Status: CLOSED UPSTREAM
Product: Virtualization Tools
Classification: Community
Component: libguestfs (Show other bugs)
unspecified
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Richard W.M. Jones
:
Depends On:
Blocks: 687920
  Show dependency treegraph
 
Reported: 2012-01-25 11:47 EST by Jiri Popelka
Modified: 2012-05-02 11:50 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-05-02 11:50:27 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)
patch (905 bytes, patch)
2012-01-25 11:47 EST, Jiri Popelka
no flags Details | Diff

  None (edit)
Description Jiri Popelka 2012-01-25 11:47:35 EST
Created attachment 557482 [details]
patch

Hi,

as you maybe know net-tools has been deprecated for some time.
We (as well as other distributions) try to eviscerate net-tools from as many packages as possible and replace it with iproute.
I see that libguestfs-1.17.1/appliance/init script uses ifconfig, route and netstat.
Would it be possible to use 'ip' command instead (see attached patch) ?

And therefore also replace
(Build)Requires: net-tools
with
(Build)Requires: iproute
in Fedora's spec file ?

Thanks !
Comment 1 Richard W.M. Jones 2012-01-25 13:00:48 EST
Is it possible there is a mistake in the patch (I'm not
very familiar with the 'ip' commands)?  With the patch
applied, the network doesn't work.

Here is the old working config:

><rescue> cat /etc/resolv.conf 
# Generated by NetworkManager
domain home.annexia.org
search home.annexia.org
nameserver 192.168.0.254
><rescue> ip r
default via 169.254.2.2 dev eth0 
169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.2.10 
><rescue> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 169.254.2.10/16 brd 169.254.255.255 scope global eth0
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

Here is the new non-working config:

><rescue> cat /etc/resolv.conf 
# Generated by NetworkManager
domain home.annexia.org
search home.annexia.org
nameserver 192.168.0.254
><rescue> ip r
default via 169.254.2.2 dev eth0 
169.254.0.0/16 dev eth0  proto kernel  scope link  src 169.254.2.10 
><rescue> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:12:34:56 brd ff:ff:ff:ff:ff:ff
    inet 169.254.2.10/16 brd 169.254.255.255 scope link eth0
    inet6 fe80::5054:ff:fe12:3456/64 scope link 
       valid_lft forever preferred_lft forever

I cannot see any significant different, but in the second
(non-working) case, the VM cannot connect to anything, not
even by IP address.
Comment 2 Richard W.M. Jones 2012-01-25 13:01:52 EST
Actually I can see a difference ...

<   inet 169.254.2.10/16 brd 169.254.255.255 scope global eth0
>   inet 169.254.2.10/16 brd 169.254.255.255 scope link eth0
Comment 3 Richard W.M. Jones 2012-01-25 14:17:32 EST
I changed your patch so that:

-ip addr add 169.254.2.10/16 brd + dev eth0 scope link
+ip addr add 169.254.2.10/16 brd + dev eth0 scope global

and the network is working again.  Obviously 169.254.* addresses
probably shouldn't be global, but that may be another bug.

It is now upstream here:

https://github.com/libguestfs/libguestfs/commit/501561742b43edb044072ec85048bb35b0b8201a

and I have made the corresponding change to libguestfs.spec
(but not pushed it yet).
Comment 4 Jiri Popelka 2012-01-26 00:53:04 EST
Yes, I forgot to mention that I wasn't sure about the link vs. global scope. Thanks !
Comment 5 Richard W.M. Jones 2012-05-02 11:50:27 EDT
Upstream for a while now and well tested, so closing.

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