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/
