Hi Chun,
thanks a lot for your diagnosis of this issue. I appreciate it. Your
patch seems ok, and the most important thing is to have your test. I
have applied this patch to the sources and we'll hope it works out.
M
Chun Tian (binghe) wrote:
Hi, Werner & Mark
Sorry to reply this mail late. I just find time to do this job, and to
test cfengine, I must set up a new test environment and bootstrap a new
cfengine config, that's not easy.
By checking Mark's svn commit (r524):
http://svn.iu.hio.no/viewvc/trunk/src/nameinfo.c?root=Cfengine-2&r1=498&r2=524&pathrev=524
Now I'm quite sure there's a new bug invoked which caused CFengine can
only detect one interface's address.
In function GetInterfaceInfo (nameinfo.c), Mark added a first_address
var which been set to true at start:
int fd,len,i,j,first_address = true;
There's no other assignment to set this variable to true again but a
chance to set it false:
if (first_address)
{
first_address = false;
strcpy(ip,inet_ntoa(sin->sin_addr));
snprintf(name,CF_MAXVARSIZE-1,"ipv4[%s]",CanonifyName(ifp->ifr_name));
AddMacroValue(CONTEXTID,name,ip);
So this IF block can only run exactly ONCE, which caused
global.ipv4[ethX] got only one interface's address, which depends the
interfaces order on linux. For most cases, eth0 appear before eth1, so
global.ipv4[eth0] is good but global.ipv4[eth1] cannot expand to any
address because it didn't exist in cfengine's nameinfo list.
For a quick fix, I attach a new patch which can be put into Debian
package's debian/patches directory, or merge into cfengine trunk. I test
it, and works for me. Please review it.
Thanks,
Chun Tian (binghe)
"Chun Tian (binghe)" <[EMAIL PROTECTED]> writes:
I have this "editfiles" class definition:
editfiles:
{ /etc/default/snmpd
ReplaceFirst "^SNMPDOPTS.*$" With "SNMPDOPTS='-Lsd -Lf /dev/null -
u snmp -I -smux -p /var/run/snmpd.pid ${global.ipv4[eth0]}:1185 $
{global.ipv4[eth1]}'"
}
I found one of ${global.ipv4[eth0]} and ${global.ipv4[eth1]} cannot be
expanded into right value, which depends my interfaces order on
server.
I haven't had time to test this myself, but this worked as intended
before we applied the patch from upstream?
- Werner
--
Mark Burgess
Web: http://www.iu.hio.no/~mark
Tlf: +47 22453272
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
