Hi Keisuke-san, On Tue, Jan 31, 2012 at 08:46:35PM +0900, Keisuke MORI wrote: > Hi Dejan, > > 2012/1/31 Dejan Muhamedagic <[email protected]>: > > Hi Keisuke-san, > > > > On Mon, Jan 30, 2012 at 08:38:35PM +0900, Keisuke MORI wrote: > >> Hi, > >> > >> 2012/1/28 Dejan Muhamedagic <[email protected]>: > >> > Hi, > >> > > >> > On Fri, Jan 20, 2012 at 02:09:13PM +0900, nozawat wrote: > >> >> Hi Dejan > >> >> > >> >> I'm agreeable in the opinion. > >> >> I send the patch which I revised. > >> >> > >> >> > I'll apply this one. BTW, can you share your use case. > >> >> If there is not -z option, the following HTML files return an error. > >> >> --------- example ----------- > >> >> <html> > >> >> <body> > >> >> test > >> >> </body> > >> >> </html> > >> >> ----------------------------------- > >> >> I placed a page for checks and was going to monitor it. > >> > > >> > Even though I said I'd apply this one, I'm now rather reluctant, > >> > because it may break some existing configurations, for instance > >> > if there are anchors in the regular expression (^ or $). > >> > > >> > Why is it important to match multiple lines? > >> > Just curious: how do you put this string into statusurl? > >> > >> The problem is that the default value of testregex assumes that > >> </body> and </html> tags are in a single line, > >> although it is very common that the HTML contents return them > >> as multiple lines. > >> > >> TESTREGEX=${OCF_RESKEY_testregex:-'</ *body *>[[:space:]]*</ *html *>'} > >> > >> I think that it will not be a problem when you are using apache with > >> 'server-status' handler enabled > >> because in that case apache seems return those tags in a single line, > >> but it is also a common use case that the RA monitors to, say, the > >> index.html on the top page. > > > > Ah, but in that case, i.e. if another page is specified to be > > monitored, testregex should be adjusted accordingly. The default > > are guaranteed to work only with the apache status page. Though > > I'm not really happy with the default regular expression we > > cannot change that. > > > The current RA will try to check the top page (http://localhost:80) > as the default behavior if you have not enabled server-status in httpd.conf > and it would fail to start even for the apache's default test page:)
Hmm, the current RA would produce an error for that URL: 488 case $STATUSURL in 489 http://*/*) ;; 490 *) 491 ocf_log err "Invalid STATUSURL $STATUSURL" 492 exit $OCF_ERR_ARGS ;; 493 esac > I agree that an user should change the testregex accordingly when > they specify the page to be monitored, but I just wanted to make it work > with a default configuration. Of course. > >> As for the regular expression like ^ or $, it looks like working as > >> expected with -z option in my quick tests. > >> Do you have any examples that it may break the configuration? > > > > For instance, what I see here in the status page is also a PID at > > the beginning of line: > > > > xen-d:~ # wget -q -O- -L --no-proxy --bind-address ::1 > > http://[::1]/server-status | grep ^PID > > PID Key: <br /> > > xen-d:~ # wget -q -O- -L --no-proxy --bind-address ::1 > > http://[::1]/server-status | grep -z ^PID > > xen-d:~ # echo $? > > 1 > > Hmm, OK you are right. My test was not enough. > (Thanks to Lars for the comprehensive tests in the other mail!) > > Now I understand that we should not support multiple lines matching > so that we can support ^ or $ as testregex in various platforms. > It is reasonable. > > > > > >> If we should not really support multiple lines matching, then that is > >> fine for us too, > >> but in that case it would be preferable that the default value of > >> testregex is something better > >> for a single line matching, like just '</ *html *>'. > >> (and also we should mention about it in the meta-data document) > > > > Hmm, I'd really expect that in case a different page is checked, > > then also another test string is specified. After all, shouldn't > > that be part of the content, rather than an HTML code which can > > occur in any HTTP reply. > > > > But we could just as well reduce to the default regular > > expression to '</ *html *>'. If nobody objects :) > > Yes. So, with this the RA will always match any HTML. That should be fine for the default. Cheers, Dejan > > Regards, > > -- > Keisuke MORI > _______________________________________________________ > Linux-HA-Dev: [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev > Home Page: http://linux-ha.org/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
