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? 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/