It might be worth trying this interface instead of the usual ioctl().
In the mean time, you can comment out the check in sysinfo.c
if (strstr(ifp->ifr_name,":"))
{
if (VSYSTEMHARDCLASS == linuxx)
{
CfOut(cf_verbose,"","Skipping apparent virtual interface %d:
%s\n",j+1,ifp->ifr_name);
continue;
}
}
else
{
CfOut(cf_verbose,"","Interface %d: %s\n",j+1,ifp->ifr_name);
}
and it should bring you back to the classes you know and love.
M
Jesse Becker wrote:
> On Tue, Mar 09, 2010 at 11:04:46AM -0500, Mark Burgess wrote:
>>
>> We are looking for a solution to this issue. Basically, Linux can hang
>> on virtual
>> interfaces and this has caused other people problems. I am open to
>> suggestions for a
>> solution, but it is not an easy matter.
>
> For linux, pull the list directly from /proc/net/dev? Or maybe
> something in /sys/class/net?
>
> From a host running KVM:
>
> [~]$ cat /proc/net/dev
> Inter-| Receive |
> Transmit
> face |bytes packets errs drop fifo frame compressed
> multicast|bytes packets errs drop fifo colls carrier compressed
> lo:2035515595 16347121 0 0 0 0 0 0
> 2035515595 16347121 0 0 0 0 0 0
> eth0:964032855 3733193 0 8 0 0 0 6
> 964776855 3688530 0 0 0 0 0 0
> eth1: 1373978 16577 0 360 0 0 0 6
> 3691060 14479 0 0 0 0 0 0
> eth4:36222924493 92484373 0 0 0 0 0 0
> 190776575475 74917623 0 0 0 0 0 0
> eth2:7622682830 21196351 0 10529689 0 0 0 1423482
> 2799002579 7724799 0 0 0 0 0 0
> eth3:58534522315 168878325 0 1327037 0 0 0
> 939658 290576727566 242375822 0 0 0 0 0 0
> sit0: 0 0 0 0 0 0 0 0
> 0 0 0 0 0 0 0 0
> br1:31993596562 62227565 0 0 0 0 0 5747129
> 190468183725 51855392 0 0 0 0 0 0
> br0:54074870393 162568991 0 0 0 0 0 3030329
> 282032747107 128656319 0 0 0 0 0 0
> vnet0:336505187 2644980 0 0 0 0 0 0
> 428187471 3095434 0 0 0 0 0 0
> vnet1:309250135 2566061 0 0 0 0 0 0
> 442882874 3137403 0 0 0 0 0 0
> vnet3:336338485 2643313 0 0 0 0 0 0
> 428184929 3096606 0 0 0 0 0 0
> vnet4: 6045462 114265 0 0 0 0 0 0
> 31202709 326066 0 0 0 0 0 0
> vnet2:143918060 1137029 0 0 0 0 0 0
> 194492556 1333825 0 0 0 0 0 0
>
> [~]$ ls /sys/class/net
> br0 br1 eth0 eth1 eth2 eth3 eth4 lo sit0 vnet0 vnet1 vnet2
> vnet3 vnet4
>
>
>
>>
>> Lebel, Marco wrote:
>>> Hello all,
>>>
>>>
>>>
>>> Assuming the following (edited) output from a netstat -i
>>>
>>>
>>>
>>> Name Mtu Network Address Ipkts Ierrs Opkts
>>> Oerrs Coll
>>>
>>> lan2:4 1500 xxx.xxx.xxx.xxx name1.domain 1916681074 0
>>> 22 0 0
>>>
>>> lan2 1500 xxx.xxx.xxx.xxx name2.domain 1462215563 0
>>> 926778993 0 0
>>>
>>> lan5:1 1500 xxx.xxx.xxx.xxx name3 1436691065 0 76535747
>>> 0 0
>>>
>>> lan1* 1500 *none* *none* 0 0
>>> 0 0 0
>>> lan0 1500 xxx.xxx.xxx.xxx name4 11705845 0 22842341
>>> 0 0
>>>
>>> lo0 4136 loopback localhost 351634044 0 351634872
>>> 0 0
>>>
>>> lan5:3 1500 xxx.xxx.xxx.xxx name5.domain 9214 0 9172
>>> 0 0
>>>
>>> :
>>>
>>> :
>>>
>>> :
>>>
>>> :
>>>
>>> :
>>>
>>>
>>>
>>>
>>>
>>> With version 2.2.9 name1, name2, name3, name4 and name5 would be defined
>>> as classes (what I call discovered classes). With version 3.0.2 and
>>> 3.0.4 the discovered classes stop at the first entry that matches *none*
>>> (tested on multiple servers) meaning only name1, name2 and name3 are
>>> defined. All of the classes that should be defined as per the 2.2.9
>>> behavior are no longer defined. Needless to say that this change in
>>> behavior is a pain in my effort to convert to V3.
>>>
>>>
>>>
>>> So you have guess it my question is: Is this a bug or an intended
>>> behavior?
>>>
>>>
>>>
>>> Marco
>>>
>>>
>>>
>>> Output from version 2.2.9 cfagent -v
>>>
>>>
>>>
>>> :
>>>
>>> :
>>>
>>> Interface 1: lan2:4
>>>
>>> Interface 2: lan2
>>>
>>> Interface 3: lan5:1
>>>
>>> Interface 4: lan1
>>>
>>> Interface 5: lan0
>>>
>>> Interface 6: lo0
>>>
>>> Interface 7: lan5:3
>>>
>>> Interface 8: lan2:1
>>>
>>> Interface 9: lan5:2
>>>
>>> Interface 10: lan2:3
>>>
>>> Interface 11: lan5
>>>
>>> Interface 12: lan2:2
>>>
>>> Interface 13: lan4
>>>
>>> Trying to locate my IPv6 address
>>>
>>> :
>>>
>>> :
>>>
>>>
>>>
>>> Output from version 3.0.2 cf-promises ???v
>>>
>>> :
>>>
>>> :
>>>
>>> cf3 Interface 1: lan2:4
>>>
>>> cf3 Interface 2: lan2
>>>
>>> cf3 Adding alias name1..
>>>
>>> cf3 Interface 3: lan5:1
>>>
>>> cf3 Adding alias name2.domain..
>>>
>>> cf3 Interface 4: lan1
>>>
>>> cf3 !! Cannot discover hardware IP, using DNS value
>>>
>>> cf3 Trying to locate my IPv6 address
>>>
>>> :
>>>
>>> :
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Help-cfengine mailing list
>>> [email protected]
>>> https://cfengine.org/mailman/listinfo/help-cfengine
>>
>> --
>> Mark Burgess
>>
>> -------------------------------------------------
>> Professor of Network and System Administration
>> Oslo University College, Norway
>>
>> Personal Web: http://www.iu.hio.no/~mark
>> Office Telf : +47 22453272
>> -------------------------------------------------
>> _______________________________________________
>> Help-cfengine mailing list
>> [email protected]
>> https://cfengine.org/mailman/listinfo/help-cfengine
>
--
Mark Burgess
-------------------------------------------------
Professor of Network and System Administration
Oslo University College, Norway
Personal Web: http://www.iu.hio.no/~mark
Office Telf : +47 22453272
-------------------------------------------------
_______________________________________________
Help-cfengine mailing list
[email protected]
https://cfengine.org/mailman/listinfo/help-cfengine
