This bug was reported by Adam Emerich on xcat mailing list. Here is the details:
[xcat-user] Makedns seems to be broken in High Availability configured xCAT 2.8.3 cluster
"makedns <nodename>" fails with the following message:</nodename>
"Ignoring host wbire1-en01, it does not belong to any nets defined in networks
table or the net it belongs to is configured to use an external nameserver."
After doing some digging, I discovered that the subroutine "my_ip_facing" in
NetworkUtils.pm only returns the first address that matches the criteria.
In our case we have eth0 set to 10.0.10.10 on mgmt01 and 10.0.10.11 on mgmt02.
We also have a virtual ip on eth0 (etho:xCAT) that moves with the active mgmt node
and it is set to 10.0.0.1. 10.0.0.1 is the IP of the xCAT manager in the tab files. In addition,
the nameservers field in the site tab file is set to "10.0.0.1,10.0.10.11,10.1.10.10" which
causes the logic in this block of code in ddns.pm:
foreach (@networks)
{
if ($ and $->{nameservers})
{
my $myip = xCAT::NetworkUtils->my_ip_facing($->{net});
xCAT::SvrUtils::sendmsg("DEBUG: $->{net} $myip $sitens $->{nameservers}", $callback);
unless (($->{nameservers} eq $myip) || ($->{nameservers} eq '<xcatmaster>') || ($</xcatmaster>->{nameservers} eq $sitens))
{
$_ = undef;
}
}
}
to return undef for the 10.0.0.0/16 network.
Here is the entry in the networks table for this network:
"MLAN","10.0.0.0","255.255.0.0","eth0","10.0.0.1","10.0.0.1","10.0.0.1","10.0.0.1","10.0.0.1","10.0.0.1","10.0.250.2-10.0.250.254",,,,"<dnsdomain>",,,,</dnsdomain>
This works on our xCAT 2.6.8 cluster, but the subroutines in NetworkUtils.pm have changed significantly from that release.
The root reason is xCAT::NetworkUtils->my_ip_facing() only returns the first address that matches the criteria, but in the HA cluster, there could be multiple addresses in the same subnet configured on xcat mn, so we need a fix in xCAT::NetworkUtils->my_ip_facing().
Need to be really careful here my_ip_facing is used all over xCAT when running hierarchical command like updatenode, xdsh, nodeset.
My suggestion is to add a new argument to subroutine xCAT::NetworkUtils->my_ip_facing to return all the ip matched addresses in an array, then modify the calling code case by case. In this bug, we could fix the logic in ddns.pm, as mentioned in the bug description.
Xiao Peng, could you work on this? Thanks.
We can check the 'wantarray' to know what the caller wanted. I went through all the call of my_ip_facing in current code that all of them want 'scalar'. So we can just change the return of my_ip_facing to make ti support the output to be list or scalar. It should be safe for the existed calls.
It's close to the 2.9 release, I'll fix it in the earlier of 2.9.1.
Make the networkUtils->my_ip_facing() check the caller to know return a scalar or array.
2.9 77d46e9
2.10 09dc22a