Hi,
2012/1/28 Dejan Muhamedagic <de...@suse.de>:
> 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.
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?
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)
Regards,
Keisuke MORI
>
> Cheers,
>
> Dejan
>
>> Regards,
>> Tomo
>>
>> 2012年1月20日4:20 Dejan Muhamedagic <de...@suse.de>:
>> > 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 <de...@suse.de>:
>> >> > 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 <de...@suse.de>:
>> >> >> > 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: Linux-HA-Dev@lists.linux-ha.org
>> >> >> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> >> >> >> Home Page: http://linux-ha.org/
>> >> >> > _______________________________________________________
>> >> >> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> >> >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> >> >> > Home Page: http://linux-ha.org/
>> >> >> _______________________________________________________
>> >> >> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> >> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> >> >> Home Page: http://linux-ha.org/
>> >> > _______________________________________________________
>> >> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> >> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> >> > Home Page: http://linux-ha.org/
>> >
>> >
>> >
>> >
>> >> _______________________________________________________
>> >> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> >> Home Page: http://linux-ha.org/
>> >
>> > _______________________________________________________
>> > Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> > http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> > Home Page: http://linux-ha.org/
>
>
>> _______________________________________________________
>> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
>> Home Page: http://linux-ha.org/
>
> _______________________________________________________
> Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
> Home Page: http://linux-ha.org/
--
Keisuke MORI
_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
