Mailing List Archive

Hi Dejan,Tim

How do you think about a patch of this apache?

Regards,
Tomo

2011$BG/(B12$B7n(B14$BF|(B14:27 nozawat <nozawat@gmail.com>:
> Hi
>
> 1.apache.patch(Coping of monitor failure)
> When a newline code is included, I fail in a monitor.
> Therefore I coped with a newline code.
>
> 2.http-mon.sh.patch(IPv6 support)
> When I did wget, I assigned 127.0.0.1 to --bind-address optionally,
> but this deleted it now for IPv4.
> Even IPv6 works by doing so it.
>
> Regards,
> Tomo
_______________________________________________________
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/

Hi,

On Wed, Dec 14, 2011 at 02:27:56PM +0900, nozawat wrote:
> Hi
>
> 1.apache.patch(Coping of monitor failure)
> When a newline code is included, I fail in a monitor.
> Therefore I coped with a newline code.

OK. I guess that this won't introduce a regression. And I guess
that sometimes one may need a newline in the test string.

> 2.http-mon.sh.patch(IPv6 support)
> When I did wget, I assigned 127.0.0.1 to --bind-address optionally,
> but this deleted it now for IPv4.
> Even IPv6 works by doing so it.

But this may have adverse effect on existing configurations. For
instance, if the configuration specifies a URL which may be
accessed from outside, then suddenly a monitor will return
success on any node in the cluster. I think that we need a
different approach here.

Why exactly IPv6 doesn't work?

Thanks,

Dejan

> Regards,
> Tomo



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

On Fri, Jan 13, 2012 at 06:58:21PM +0100, Dejan Muhamedagic wrote:
> Hi,
>
> On Wed, Dec 14, 2011 at 02:27:56PM +0900, nozawat wrote:
> > Hi
> >
> > 1.apache.patch(Coping of monitor failure)
> > When a newline code is included, I fail in a monitor.
> > Therefore I coped with a newline code.
>
> OK. I guess that this won't introduce a regression. And I guess
> that sometimes one may need a newline in the test string.
>
> > 2.http-mon.sh.patch(IPv6 support)
> > When I did wget, I assigned 127.0.0.1 to --bind-address optionally,
> > but this deleted it now for IPv4.
> > Even IPv6 works by doing so it.
>
> But this may have adverse effect on existing configurations. For
> instance, if the configuration specifies a URL which may be
> accessed from outside, then suddenly a monitor will return
> success on any node in the cluster. I think that we need a
> different approach here.
>
> Why exactly IPv6 doesn't work?

I think, because:

$ wget -O- -q -L --no-proxy --bind-address 127.0.0.1 "http://[::1]/"
does not work.

strace reveals:
socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINVAL (Invalid argument)

However, this does work:
$ wget -O- -q -L --no-proxy --bind-address ::1 "http://[::1]/" ; echo $?

So maybe bindaddress should become an option as well?
Or auto-detect:
if ip -o -f inet6 a s dev lo | grep -q " ::1/"; then
# alternatively, to not be linux specific, ifconfig lo | grep ...
# in case the output is actually reliably grep-able accross OSes.
bind_address="::1"
else
bind_address="127.0.0.1"
fi

Because, at least as long as net.ipv6.bindv6only = 0,
binding to ::1 works for http://127.0.0.1 as well.

> Thanks,
>
> Dejan
>
> > Regards,
> > Tomo
>
>
>
> > _______________________________________________________
> > 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/

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® 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/

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.

Regards,
Tomo

2012$BG/(B1$B7n(B14$BF|(B20:55 Lars Ellenberg <lars.ellenberg@linbit.com>:
> On Fri, Jan 13, 2012 at 06:58:21PM +0100, Dejan Muhamedagic wrote:
>> Hi,
>>
>> On Wed, Dec 14, 2011 at 02:27:56PM +0900, nozawat wrote:
>> > Hi
>> >
>> > 1.apache.patch(Coping of monitor failure)
>> > When a newline code is included, I fail in a monitor.
>> > Therefore I coped with a newline code.
>>
>> OK. I guess that this won't introduce a regression. And I guess
>> that sometimes one may need a newline in the test string.
>>
>> > 2.http-mon.sh.patch(IPv6 support)
>> > When I did wget, I assigned 127.0.0.1 to --bind-address optionally,
>> > but this deleted it now for IPv4.
>> > Even IPv6 works by doing so it.
>>
>> But this may have adverse effect on existing configurations. For
>> instance, if the configuration specifies a URL which may be
>> accessed from outside, then suddenly a monitor will return
>> success on any node in the cluster. I think that we need a
>> different approach here.
>>
>> Why exactly IPv6 doesn't work?
>
> I think, because:
>
> $ wget -O- -q -L --no-proxy --bind-address 127.0.0.1 "http://[::1]/"
> does not work.
>
> strace reveals:
> socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
> bind(3, {sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINVAL (Invalid argument)
>
> However, this does work:
> $ wget -O- -q -L --no-proxy --bind-address ::1 "http://[::1]/" ; echo $?
>
> So maybe bindaddress should become an option as well?
> Or auto-detect:
> if ip -o -f inet6 a s dev lo | grep -q " ::1/"; then
> # alternatively, to not be linux specific, ifconfig lo | grep ...
> # in case the output is actually reliably grep-able accross OSes.
> bind_address="::1"
> else
> bind_address="127.0.0.1"
> fi
>
> Because, at least as long as net.ipv6.bindv6only = 0,
> binding to ::1 works for http://127.0.0.1 as well.
>
>> Thanks,
>>
>> Dejan
>>
>> > Regards,
>> > Tomo
>>
>>
>>
>> > _______________________________________________________
>> > 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/
>
> --
> : 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/

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?

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® 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/

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® and LINBIT® 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/

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"
----------

Regards,
Tomo

2012$BG/(B1$B7n(B17$BF|(B23:28 Dejan Muhamedagic <dejan@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/

Hi Dejan

I was very sorry to mistake the spelling of your name (in the previous email).

Regards,
Tomo

2012$BG/(B1$B7n(B18$BF|(B11:19 nozawat <nozawat@gmail.com>:
> 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"
> ----------
>
> Regards,
> Tomo
>
> 2012$BG/(B1$B7n(B17$BF|(B23:28 Dejan Muhamedagic <dejan@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/

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 <dejan@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/

Hi,

On Wed, Jan 18, 2012 at 11:26:05AM +0900, nozawat wrote:
> Hi Dejan
>
> I was very sorry to mistake the spelling of your name (in the previous email).

No worries.

Cheers,

Dejan

> Regards,
> Tomo
>
> 2012年1月18日11:19 nozawat <nozawat@gmail.com>:
> > 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"
> > ----------
> >
> > Regards,
> > Tomo
> >
> > 2012年1月17日23:28 Dejan Muhamedagic <dejan@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/

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.
2)apache-002.patch
->It is a processing method using tr at the age of HB2.1.4.
3)http-mon.sh.patch
->It is the patch which coupled my suggestion with A.

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$BG/(B1$B7n(B19$BF|(B1:12 Dejan Muhamedagic <dejan@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$BG/(B1$B7n(B17$BF|(B23:28 Dejan Muhamedagic <dejan@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/

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 <dejan@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 <dejan@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/

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.

Regards,
Tomo

2012$BG/(B1$B7n(B20$BF|(B4:20 Dejan Muhamedagic <dejan@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$BG/(B1$B7n(B19$BF|(B1:12 Dejan Muhamedagic <dejan@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$BG/(B1$B7n(B17$BF|(B23:28 Dejan Muhamedagic <dejan@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/

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 <dejan@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 <dejan@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 <dejan@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/

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$BG/(B1$B7n(B28$BF|(B5:34 Dejan Muhamedagic <dejan@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?
>
> Cheers,
>
> Dejan
>
>> Regards,
>> Tomo
>>
>> 2012$BG/(B1$B7n(B20$BF|(B4:20 Dejan Muhamedagic <dejan@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$BG/(B1$B7n(B19$BF|(B1:12 Dejan Muhamedagic <dejan@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$BG/(B1$B7n(B17$BF|(B23:28 Dejan Muhamedagic <dejan@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/
_______________________________________________________
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/

Hi,

2012/1/28 Dejan Muhamedagic <dejan@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$BG/(B1$B7n(B20$BF|(B4:20 Dejan Muhamedagic <dejan@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$BG/(B1$B7n(B19$BF|(B1:12 Dejan Muhamedagic <dejan@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$BG/(B1$B7n(B17$BF|(B23:28 Dejan Muhamedagic <dejan@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/

Hi Keisuke-san,

On Mon, Jan 30, 2012 at 08:38:35PM +0900, Keisuke MORI wrote:
> Hi,
>
> 2012/1/28 Dejan Muhamedagic <dejan@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.

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 <dejan@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 <dejan@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 <dejan@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/
_______________________________________________________
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/

Hi,

On Mon, Jan 30, 2012 at 02:22:48PM +0900, nozawat wrote:
> 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?

It's not really important why, just that it isn't there since
more than 3 years. I'd say it's just a matter of agreement, one
form (with newlines) is not really better than the other (without
newlines).

> > 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.

Oh, that question was rather silly, sorry about that :)

Cheers,

Dejan

> Regards,
> Tomo
>
> 2012年1月28日5:34 Dejan Muhamedagic <dejan@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?
> >
> > Cheers,
> >
> > Dejan
> >
> >> Regards,
> >> Tomo
> >>
> >> 2012年1月20日4:20 Dejan Muhamedagic <dejan@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 <dejan@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 <dejan@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/
> _______________________________________________________
> 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/

On Mon, Jan 30, 2012 at 09:24:19PM +0100, Dejan Muhamedagic wrote:
> > 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

different versions of grep in various distributions seem to behave
differently with -z and ^:

distro;
grep --version | head -n1;
printf "A\nB\nC\n" | grep -q -z ^B ; echo $?

etch grep (GNU grep) 2.5.1 0
lenny GNU grep 2.5.3 0
squeeze GNU grep 2.6.3 1 breaks
lucid GNU grep 2.5.4 0

rhel4 grep (GNU grep) 2.5.1 1 breaks
rhel5 grep (GNU grep) 2.5.1 0
rhel6 GNU grep 2.6.3 1 breaks

sles9 grep (GNU grep) 2.5.1 1 breaks
sles10 grep (GNU grep) 2.5.1 1 breaks
sles11 GNU grep 2.5.2 1 breaks
sles11-sp1 GNU grep 2.5.2 1 breaks


So neither distros nor grep version seem to agree
if "^" is supposed to be equivalent to pcre /^/m or /\A/ ;-)

Best practices for monitoring apache with pacemaker
would be to have some dedicated page print out
either a text/plain "ALL OK" only.
Or, in case something is wrong, anything with arbitrary diagnostic
output, if any, which reliably does not containing that string.

> But we could just as well reduce to the default regular
> expression to '</ *html *>'. If nobody objects :)

As the default regex only checks for basically "any" response that
remotely looks like it may have something to do with html output,
that should be fine.

--
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com
_______________________________________________________
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/

Hi Dejan,

2012/1/31 Dejan Muhamedagic <dejan@suse.de>:
> Hi Keisuke-san,
>
> On Mon, Jan 30, 2012 at 08:38:35PM +0900, Keisuke MORI wrote:
>> Hi,
>>
>> 2012/1/28 Dejan Muhamedagic <dejan@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.
>
> 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.


The current RA will try to check the top page (http://localhost:80)
as the default behavior if you have not enabled server-status in httpd.conf
and it would fail to start even for the apache's default test page:)

I agree that an user should change the testregex accordingly when
they specify the page to be monitored, but I just wanted to make it work
with a default configuration.

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

Hmm, OK you are right. My test was not enough.
(Thanks to Lars for the comprehensive tests in the other mail!)

Now I understand that we should not support multiple lines matching
so that we can support ^ or $ as testregex in various platforms.
It is reasonable.


>
>> 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 :)

Yes.


Regards,

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

On Tue, Jan 31, 2012 at 11:34:19AM +0100, Lars Ellenberg wrote:
> On Mon, Jan 30, 2012 at 09:24:19PM +0100, Dejan Muhamedagic wrote:
> > > 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
>
> different versions of grep in various distributions seem to behave
> differently with -z and ^:
>
> distro;
> grep --version | head -n1;
> printf "A\nB\nC\n" | grep -q -z ^B ; echo $?
>
> etch grep (GNU grep) 2.5.1 0
> lenny GNU grep 2.5.3 0
> squeeze GNU grep 2.6.3 1 breaks
> lucid GNU grep 2.5.4 0
>
> rhel4 grep (GNU grep) 2.5.1 1 breaks
> rhel5 grep (GNU grep) 2.5.1 0
> rhel6 GNU grep 2.6.3 1 breaks
>
> sles9 grep (GNU grep) 2.5.1 1 breaks
> sles10 grep (GNU grep) 2.5.1 1 breaks
> sles11 GNU grep 2.5.2 1 breaks
> sles11-sp1 GNU grep 2.5.2 1 breaks

sles11-sp2 GNU grep 2.7 1 breaks

Lovely. SLES is at least consequent.

> So neither distros nor grep version seem to agree
> if "^" is supposed to be equivalent to pcre /^/m or /\A/ ;-)
>
> Best practices for monitoring apache with pacemaker
> would be to have some dedicated page print out
> either a text/plain "ALL OK" only.
> Or, in case something is wrong, anything with arbitrary diagnostic
> output, if any, which reliably does not containing that string.

Right. Searching for just <html> could conceivably at times
match a wrong output.

> > But we could just as well reduce to the default regular
> > expression to '</ *html *>'. If nobody objects :)
>
> As the default regex only checks for basically "any" response that
> remotely looks like it may have something to do with html output,
> that should be fine.

Yes, I think so to.

Cheers,

Dejan

> --
> : Lars Ellenberg
> : LINBIT | Your Way to High Availability
> : DRBD/HA support and consulting http://www.linbit.com
> _______________________________________________________
> 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/

Hi Keisuke-san,

On Tue, Jan 31, 2012 at 08:46:35PM +0900, Keisuke MORI wrote:
> Hi Dejan,
>
> 2012/1/31 Dejan Muhamedagic <dejan@suse.de>:
> > Hi Keisuke-san,
> >
> > On Mon, Jan 30, 2012 at 08:38:35PM +0900, Keisuke MORI wrote:
> >> Hi,
> >>
> >> 2012/1/28 Dejan Muhamedagic <dejan@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.
> >
> > 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.
>
>
> The current RA will try to check the top page (http://localhost:80)
> as the default behavior if you have not enabled server-status in httpd.conf
> and it would fail to start even for the apache's default test page:)

Hmm, the current RA would produce an error for that URL:

488 case $STATUSURL in
489 http://*/*) ;;
490 *)
491 ocf_log err "Invalid STATUSURL $STATUSURL"
492 exit $OCF_ERR_ARGS ;;
493 esac

> I agree that an user should change the testregex accordingly when
> they specify the page to be monitored, but I just wanted to make it work
> with a default configuration.

Of course.

> >> 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
>
> Hmm, OK you are right. My test was not enough.
> (Thanks to Lars for the comprehensive tests in the other mail!)
>
> Now I understand that we should not support multiple lines matching
> so that we can support ^ or $ as testregex in various platforms.
> It is reasonable.
>
>
> >
> >> 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 :)
>
> Yes.

So, with this the RA will always match any HTML. That should be
fine for the default.

Cheers,

Dejan

>
> Regards,
>
> --
> 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/
_______________________________________________________
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/

Hi Dejan

2012/1/31 Dejan Muhamedagic <dejan@suse.de>:
> Hi Keisuke-san,
(...)
> On Tue, Jan 31, 2012 at 08:46:35PM +0900, Keisuke MORI wrote:
>> The current RA will try to check the top page (http://localhost:80)
>> as the default behavior if you have not enabled server-status in httpd.conf
>> and it would fail to start even for the apache's default test page:)
>
> Hmm, the current RA would produce an error for that URL:
>
> 488     case $STATUSURL in
> 489         http://*/*) ;;
> 490         *)
> 491         ocf_log err "Invalid STATUSURL $STATUSURL"
> 492         exit $OCF_ERR_ARGS ;;
> 493     esac

Strange. That URL is generated by the RA itself.

apache-conf.sh:
119 buildlocalurl() {
120 [ "x$Listen" != "x" ] &&
121 echo "http://${Listen}" ||
122 echo "${LOCALHOST}:${PORT}"


Probably we should relax the validation pattern, as just 'http://*' ?





>
>> I agree that an user should change the testregex accordingly when
>> they specify the page to be monitored, but I just wanted to make it work
>> with a default configuration.
>
> Of course.
>
>> >> 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
>>
>> Hmm, OK you are right. My test was not enough.
>> (Thanks to Lars for the comprehensive tests in the other mail!)
>>
>> Now I understand that we should not support multiple lines matching
>> so that we can support ^ or $ as testregex in various platforms.
>> It is reasonable.
>>
>>
>> >
>> >> 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 :)
>>
>> Yes.
>
> So, with this the RA will always match any HTML. That should be
> fine for the default.
>
> Cheers,
>
> Dejan
>
>>
>> Regards,
>>
>> --
>> 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/
> _______________________________________________________
> 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/


Regards,
--
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/

Hi Keisuke-san,

On Tue, Jan 31, 2012 at 09:52:24PM +0900, Keisuke MORI wrote:
> Hi Dejan
>
> 2012/1/31 Dejan Muhamedagic <dejan@suse.de>:
> > Hi Keisuke-san,
> (...)
> > On Tue, Jan 31, 2012 at 08:46:35PM +0900, Keisuke MORI wrote:
> >> The current RA will try to check the top page (http://localhost:80)
> >> as the default behavior if you have not enabled server-status in httpd.conf
> >> and it would fail to start even for the apache's default test page:)
> >
> > Hmm, the current RA would produce an error for that URL:
> >
> > 488     case $STATUSURL in
> > 489         http://*/*) ;;
> > 490         *)
> > 491         ocf_log err "Invalid STATUSURL $STATUSURL"
> > 492         exit $OCF_ERR_ARGS ;;
> > 493     esac
>
> Strange. That URL is generated by the RA itself.
>
> apache-conf.sh:
> 119 buildlocalurl() {
> 120 [ "x$Listen" != "x" ] &&
> 121 echo "http://${Listen}" ||
> 122 echo "${LOCALHOST}:${PORT}"
>
>
> Probably we should relax the validation pattern, as just 'http://*' ?

Agreed. I thought that the intention was to always use the status
page, but obviously people figured out that they could skip that.
Just as well.

[...]

Cheers,

Dejan
_______________________________________________________
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/