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. > 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 > 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 :) Cheers, Dejan > Regards, > Keisuke MORI > > > > > Cheers, > > > > Dejan > > > >> Regards, > >> Tomo > >> > >> 2012年1月20日4:20 Dejan Muhamedagic <[email protected]>: > >> > Hi, > >> > > >> > On Thu, Jan 19, 2012 at 11:42:07AM +0900, nozawat wrote: > >> >> Hi Dejan and Lars > >> >> > >> >> I send the patch which settled a conventional argument. > >> >> 1)apache-001.patch > >> >> ->I am the same with the patch which I sent last time. > >> >> ->It is the version that I added an option of the grep to. > >> > > >> > I'll apply this one. BTW, can you share your use case. > >> > > >> >> 2)apache-002.patch > >> >> ->It is a processing method using tr at the age of HB2.1.4. > >> > > >> > Can't recall or see from the history why tr(1) was dropped (and > >> > it was me who removed it :( But I guess there was a reason for > >> > that. > >> > > >> >> 3)http-mon.sh.patch > >> >> ->It is the patch which coupled my suggestion with A. > >> > > >> > After trying to rework the patch a bit, I think now that we need > >> > a different user interface, i.e. we should introduce a boolean > >> > parameter, say "use_ipv6", then fix interface bind addresses > >> > depending on that. For instance, if user wants to use curl, then > >> > we'd need to add the "-g" option to make it work with IPv6. > >> > > >> > We can also try to figure out from the "statusurl" content if > >> > it contains an IPv6 address (echo "$statusurl" | grep -qs "::") > >> > then make the http client use IPv6 automatically. > >> > > >> > Would that work for you? Opinions? > >> > > >> > Cheers, > >> > > >> > Dejan > >> > > >> >> 1) and 2) improve malfunction at the time of the monitor processing. > >> >> 3) supports IPv6. > >> >> > >> >> The malfunction is not revised when I do not apply at least 1) or 2). > >> >> I think that 2) plan is good, but leave the final judgment to Dejan. > >> >> > >> >> Regards, > >> >> Tomo > >> >> > >> >> 2012年1月19日1:12 Dejan Muhamedagic <[email protected]>: > >> >> > Hi, > >> >> > > >> >> > On Wed, Jan 18, 2012 at 11:19:58AM +0900, nozawat wrote: > >> >> >> Hi Dejna and Lars > >> >> >> > >> >> >> When, for example, it is a logic of the examples of Lars to try > >> >> >> both, > >> >> >> in the case of IPv6, is the check of IPv4 that I enter every time? > >> >> >> Don't you hate that useless processing enters every time? > >> >> >> > >> >> >> In that case, I think that I should give a parameter such as > >> >> >> OCF_RESKEY_bindaddress. > >> >> >> ---------- > >> >> >> bind_address="127.0.0.1" > >> >> >> if [ -n "$OCF_RESKEY_bindaddress" ]; then > >> >> >> bind_address="$OCF_RESKEY_bindaddress" > >> >> >> fi > >> >> >> WGETOPTS="-O- -q -L --no-proxy --bind-address=$bind_address" > >> >> >> ---------- > >> >> > > >> >> > That's fine too. We can combine yours and Lars' proposal, i.e. in > >> >> > case bindaddress is not set, it tries both. Do you think you > >> >> > could prepare such a patch? > >> >> > > >> >> > BTW, the extra processing is minimal, in particular compared to > >> >> > the rest this RA does. > >> >> > > >> >> > Thanks, > >> >> > > >> >> > Dejan > >> >> > > >> >> >> Regards, > >> >> >> Tomo > >> >> >> > >> >> >> 2012年1月17日23:28 Dejan Muhamedagic <[email protected]>: > >> >> >> > On Tue, Jan 17, 2012 at 11:41:41AM +0100, Lars Ellenberg wrote: > >> >> >> >> On Tue, Jan 17, 2012 at 11:07:09AM +0900, nozawat wrote: > >> >> >> >> > Hi Dejan and Lars, > >> >> >> >> > > >> >> >> >> > I send the patch which I revised according to indication of > >> >> >> >> > Lars. > >> >> >> >> > > >> >> >> >> > >> OK. I guess that this won't introduce a regression. And I > >> >> >> >> > >> guess > >> >> >> >> > >> that sometimes one may need a newline in the test string. > >> >> >> >> > I seemed to surely take such a step in the past. > >> >> >> >> > However, I thought that the tr processing was deleted that load > >> >> >> >> > became higher. > >> >> >> >> > Therefore I used the -z option. > >> >> >> >> > >> >> >> >> Thinking about it, maybe to reduce chance of regression, > >> >> >> >> we can try both? > >> >> >> >> I'm not sure about the default order, ipv4 or ipv6 first? > >> >> >> >> > >> >> >> >> for bind_address in 127.0.0.1 ::1 ; do > >> >> >> >> wget ... > >> >> >> >> ret=$? > >> >> >> >> [ $ret = 0 ] && break; > >> >> >> >> # recent wget could [ $ret != 4 ] && break, > >> >> >> >> # "Network error". But older wget return 1... > >> >> >> >> done > >> >> >> >> > >> >> >> >> Dejan? > >> >> >> > > >> >> >> > Yes, that looks like the best way. > >> >> >> > > >> >> >> > Cheers, > >> >> >> > > >> >> >> > Dejan > >> >> >> > > >> >> >> >> -- > >> >> >> >> : Lars Ellenberg > >> >> >> >> : LINBIT | Your Way to High Availability > >> >> >> >> : DRBD/HA support and consulting http://www.linbit.com > >> >> >> >> > >> >> >> >> DRBD(R) and LINBIT(R) are registered trademarks of LINBIT, > >> >> >> >> Austria. > >> >> >> >> _______________________________________________________ > >> >> >> >> 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/ > >> >> >> _______________________________________________________ > >> >> >> 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/ > >> > > >> > > >> > > >> > > >> >> _______________________________________________________ > >> >> 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/ > > > > > >> _______________________________________________________ > >> 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/ > > > > -- > 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/
