Ummm to all it's means hit... sorry
-----Original Message-----
From: help-cfengine-boun...@cfengine.org
[mailto:help-cfengine-boun...@cfengine.org] On Behalf Of Lebel, Marco
Sent: Tuesday, March 09, 2010 3:19 PM
To: Mark Burgess; Jesse Becker
Cc: help-cfengine@cfengine.org
Subject: RE: Discovered classes
Hello,
After some investigation the proposed fix did not solve my problem but since
you gave me the file and routine to look at I found the following further down
in the code:
if (strcmp(inet_ntoa(sin->sin_addr),"0.0.0.0") == 0) <--- probably the value
that we get if no address are attached to an interface
{
// Maybe we need to do something windows specific here?
This is the message I get when the code it's the none value interface
CfOut(cf_verbose,""," !! Cannot discover hardware IP, using DNS value");
strcpy(ip,"ipv4_");
strcat(ip,VIPADDRESS);
AppendItem(&IPADDRESSES,VIPADDRESS,"");
for (sp = ip+strlen(ip)-1; (sp > ip); sp--)
{
if (*sp == '.')
{
*sp = '\0';
NewClass(CanonifyName(ip));
}
}
strcpy(ip,VIPADDRESS);
i = 3;
for (sp = ip+strlen(ip)-1; (sp > ip); sp--)
{
if (*sp == '.')
{
*sp = '\0';
snprintf(name,CF_MAXVARSIZE-1,"ipv4_%d[%s]",i--,CanonifyName(VIPADDRESS));
NewScalar("sys",name,ip,cf_str);
}
}
close(fd); <---
return; <---
}
My question to those of you that have the knowledge or time to figure it out.
Why does it do a close followed by a return?
Marco
-----Original Message-----
From: Mark Burgess [mailto:mark.burg...@iu.hio.no]
Sent: Tuesday, March 09, 2010 11:42 AM
To: Jesse Becker
Cc: Lebel, Marco; help-cfengine@cfengine.org
Subject: Re: Discovered classes
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
>>> Help-cfengine@cfengine.org
>>> 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
>> Help-cfengine@cfengine.org
>> 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
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
_______________________________________________
Help-cfengine mailing list
Help-cfengine@cfengine.org
https://cfengine.org/mailman/listinfo/help-cfengine
