Hi Stefan,
On 10.07.2011 09:48, Stefan Pendl wrote:
> I have investigated the following:
>
> * test4_hosts_nodes - 10
>
> The host definition installed is:
> <host ipaddresses=".+1" profile-id="allip-1" />
>
> If this should match all IPs ending in 1 this must be changed to:
> <host ipaddresses=".+1$" profile-id="allip-1" />
Actually the following should be OK too:
<host ipaddresses="1$" profile-id="allip-1" />
or
<host ipaddresses="^.+1$" profile-id="allip-1" />
Also some other checks seem not match exactly what they are supposed to match.
For example:
<host ipaddresses="10.0.0.1" profile-id="ip1" />
<host ipaddresses="10.0.0..+" profile-id="all-ip" />
The "." character in regular expressions (all extended host matches are always
matched using regexp means "any character" and not the "dot" character.
So this expression would also match "10a0b0c1". Although this is not an IP which
will be read from the host. But it might in some cases lead to unexpected results.
So the correct value would be
<host ipaddresses="^10\.0\.0\.1$" profile-id="ip1" />
<host ipaddresses="^10\.0\.0\..+$" profile-id="all-ip" />
> * test4_hosts_nodes - 21
>
> The host definition additionally installed is:
> <host ipaddresses=".+1" profile-id="allip-1" />
>
> If this should match all IPs ending in 1 this must be changed to:
> <host ipaddresses=".+1$" profile-id="allip-1" />
Changed it to
<host ipaddresses=".+1$" profile-id="allip-1" />
Moreover I found an issue with a host match for "allname-1". Changed it to
<host name=".+1" profile-id="allname-1" />
Note: "name" matches in legacy mode get "^" prepended and "$" appended in regexp
mode. But this does not apply for extended host checks. Here you need to specify
the full regexp including "^" and "$" if you would like to match the full
string. As an advantage this also allows expressions which only match a part of
the string.
> * test4_hosts_nodes - 22
>
> The host definition additionally installed is:
> <host name="^.+1$" profile-id="allname-1" />
>
> This is correct, since the name attribute will also match "/ip:10.0.0.1".
If you want to match IP-addresses via the classic "name" attribute you cannot
use a regular expression. Instead name= is expected to specify IP ranges. E.g.
name="10.0.0.1"
name="0-255.0-255.0-255.1"
Therefore I've changed this entry to:
<host name=".+1" profile-id="allname-1" />
<host name="0-255.0-255.0-255.1" profile-id="allname-1" />
This will match both. IP addresses which end with 1 as well as names which end
with 1. This seems to be the intention of the test.
> Finally I think that the additional need to add "^" and "$" to the name attribute in some of the host definitions is caused by this
> missing code line:
>
> // Still no match is found. Try regular
> // expression host name match.
> var regHostNode = new RegExp("^" + xmlNodeAttrValue + "$", "i");
>
> Which was removed between SVN revision 147 and 148 in function getHostMatches.
>
> Reverting the changes to the hosts.xml files and adding this to the function getHostNameAttribute by default might return the legacy
> behavior.
No. WPKG was adding the leading "^" and trailing "$" when regexp-matching the
name attribute only. The current version in SVN does exactly this again.
But for extended host matching WPKG does not implicitly add "^" and "$" to the
regular expression. This allows one to specify the whole regular expression and
also match only partial strings. It is clearly defined in the documentation
(XSD) that all extended host matches are interpreted as regular expressions.
> Still the legacy behavior seems to be not at all clear in respect to host matching due to the need to support so many cases with one
> attribute.
> The possibility to not have a unique match is quite high, if the expression is "spongy" (German: schwammig).
Sure. In the documentation I've stated already that in case of advanced matching
for IP or extended attributes the new extended host match attributes shall be
used instead of "name". Current implementation in SVN (1.1.3-RC14) allows even
to omit the "name" attribute completely and only use extended host matching.
So for now the algorithm to match the name attribute is exactly identical to
previous WPKG versions:
1. Try to match the strings 1:1
2. Try to match IP-addressees
Format: "<range>.<range>.<range>.<range>"
where <range> is either a digit between 0 and 255 or a range in the format
"x-y".
e.g. "192.168.0.1-255"
3. Transform attribute value into regexp by prepending "^" and appending "$":
"test" becomes "^test$"
This mode is often used to match multiple hosts with a naming scheme.
e.g. "lab-.*" becomes "^lab-.*$"
Do not confuse (3) with the new extended host matches. If you want to use the
hostname attribute instead of the name attribute you have to specify
hostname="^lab-.*$" directly.
That's all.
> The new extended host matching seems to be more robust due to separating the attributes.
This is absolutely clear. The approach of "name" was to detect the user
intention and match the values in a smart way. In fact I think the algorithm to
match ip-addresses is pretty smart, but as I see with test 22 it was also
misunderstood. The regular expression mode of the name attribute does not apply
to IP-addresses. If you want to match IP-addresses with the name attribute they
need to be specified in range-format with exactly 3 separating dots in the
expression.
br,
Rainer
|
|