Using “sleha-init -c servername -i eth1” to create a new cluster.
it failed.
i check the script of sleha-functions, and i found the Auto-detection of IP address and netmask procedure like the following:
# Auto-detection of IP address and netmask only works if $NET_IF is
# up. If $IP_ADDRESS is overridden, network detect shouldn't work,
# because "ip route" won't be able to help us.
if [ -z "$IP_ADDRESS" ]; then
IP_ADDRESS=$(ip -o -f inet addr show primary | \\
awk "/[[:space:]]${NET_IF}[[:space:]]/ {print \\$4} " |
sed 's/\\/[1-9][1-9]*//')
fi
if [ -z "$IP_NETWORK" -a -n "$IP_ADDRESS" ]; then
IP_NETWORK=$(ip route list | \\
awk "/${IP_ADDRESS}/ { print \\$1; }" |
sed 's/\\/[1-9][1-9]//')
fi
and when i used this command to check ip address, i got the result:
# ip -o -f inet addr show primary
1: lo inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
2: eth0 inet 10.107.228.119/24 brd 10.107.228.255 scope global eth0
3: eth1 inet 200.200.0.202/30 brd 200.200.0.203 scope global eth1
then i used the same command in sleha-functions, i got the result:
# ip -o -f inet addr show primary | awk "/[[:space:]]eth1[[:space:]]/ {print \\$4} " |sed 's/\\/[1-9][1-9]*//'
200.200.0.2020
i think the regular expression [COLOR="#FF0000"]sed ‘s/\/[1-9][1-9]//’[/COLOR] is not correct here.
so if i change the regular expression to [COLOR="#FF0000"]sed 's/\/[1-9][0-9]//’[/COLOR],
# ip -o -f inet addr show primary | awk "/[[:space:]]eth1[[:space:]]/ {print \\$4} " |sed 's/\\/[1-9][0-9]*//'
200.200.0.202
is it a bug or some limitation (like we can use netmask such as 30 or 20 or 10) not including in the documents?
I think you-re on the right track. Even more, though, that regex would
also seem to incorrectly rule out any single-digit netmasks, and while
those are rare there is no reason I can see for doing that either.
Certainly the [1-9] bit is wrong… I am more than a little surprised
somebody wrote it that way since regex examples to detect number ranges
are extremely common and include things like [0-9] along with the
character equivalents of [a-zA-Z] and such. I’ll report this and let you
know what I find.
For now I’d modify the script on your system so that it works and
hopefully the next patch will include fixes.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Clarification as I re-read this… the two-digit netmask requirement is
only the second block where the ‘ip route’ output is being processed, and
not on the ‘ip addr’ output processing.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Well, it looks like it to us. Admittedly the one I found about the route
netmask is unlikely to be hit, but then again so is yours. Mine is
probably less-likely since /9 to /1 subnetting is pretty odd (though I
have one customer doing that internally, at least on their servers). /30
is also a bit rare, but all of these situations should be handled.
On the other hand, I’m not the developer, so we’ll see what comes back
from them and their experience on why the scripts were written this way.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
Looks like Bug# 854783 is submitted for this. If you want a PTF you’ll
probably need an SR but for now the solution seems to be what was
mentioned before in making small changes to the script.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…