Hi Dejan > Why is it important to match multiple lines? When I check normal WEB page, I think that a newline code enters in almost all. Corresponding to that purpose, newline code thought whether it was necessary.
But I know that Dejan deleted the handling of 'tr'. I deleted 'tr' or why will teach a reason? Is a problem of 'tr' the problem about the newline of the HTML side? > Just curious: how do you put this string into statusurl? I'm sorry if different whether it was not to say that I show the HTML that I obtain in WGET. Regards, Tomo 2012年1月28日5:34 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? > > 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/ _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
