[Pacemaker] Frustrating fun with Pacemaker / CentOS / Apache

[Tim Serong]

On 2/19/2010 at 08:40 AM, Paul Graydon <paul at ehawaii.gov> wrote: 
> >> I started looking into this today to find out whether it was 
> >> possible to use another URL for testing.  According to the heartbeat 
> >> script you can specify the parameter statusurl and as long as it has 
> >> a body and html tag on the page you test it should work. 
> >>       
> > You can also set your own "testregex" which should match the 
> > output of "statusurl". Since resource agents release 1.0.2, 
> > apache can also do more thorough tests (see "crm ra info apache" 
> > or ocf_heartbeat_apache(7)). 
> > 
> >     
> >> So I thought I'd give it a try, but it failed.  Initially I assumed 
> >> it was because I hadn't selected a page with the body and html tag 
> >> (having not noticed that was a necessity) but even when against a 
> >> page that has them it still failed.  Trying to execute the command 
> >> it runs came up with a failure for me too, but it appears to be how 
> >> all the arguments are presented to wget courtesy of "sh -c". 
> >> 
> >> It's looking for a positive return from: 
> >> 
> >> sh -c wget -O- -q -L http://whatever.url.youprovided | tr '\012' ' ' 
> >> | grep -Ei "</ *body *>[[:space:]]*</ *html *>" 
> >> 
> >> Problem is if you cut it down to just that first section: 
> >> sh -c wget -O- -q -L http://whatever.url.youprovided 
> >> 
> >> it pops back and tells you 
> >> wget: missing URL 
> >> Usage: wget [OPTION]... [URL]... 
> >> 
> >> Try `wget --help' for more options. 
> >> 
> >> If you execute wget without using "sh -c" in front of it it sees the 
> >> URL and parses it successfully. 
> >> 
> >> Surrounding the wget string with ' marks, as in: 
> >> sh -c 'wget -O- -q -L http://whatever.url.youprovided ' 
> >> 
> >> I'm trying to figure out what other options are available.  Adding 
> >> in ' marks on line 406 of the ocf heartbeat apache script breaks it! 
> >>       
> > I really don't think there is a need to change anything there. 
> > Otherwise, apache would never be able to work. If you think you 
> > found a problem, you can try to wrap the critical part in 
> > "set -x/+x" and we'll see what the output looks like. 
> > 
> > Thanks, 
> > 
> > Dejan 
> >     
> I've looked into this with fresh eyes this morning and managed to track  
> down the problem to this addition to the related to meta  
> target-role="Started" 
>  
> Not sure quite where I picked that up from, presumably one of the  
> configurations I used as a template?  Without setting it as an attribute  
> it works fine, tested and retested with and without that addition. 
>  
> This works: 
> primitive failover-apache ocf:heartbeat:apache \ 
>          params configfile="/etc/httpd/conf/httpd.conf"  
> httpd="/usr/sbin/httpd" port="80" \ 
>          op monitor interval="5s" timeout="20s"  
> statusurl="https://valid.test.url/index.html" 
>  
> This doesn't: 
> primitive failover-apache ocf:heartbeat:apache \ 
>          params configfile="/etc/httpd/conf/httpd.conf"  
> httpd="/usr/sbin/httpd" port="80" \ 
>          op monitor interval="5s" timeout="20s"  
> statusurl="https://valid.test.url/index.html" \ 
>      meta target-role="Started" 

That's weird.  That attribute shouldn't make any difference in this case -
it's just telling the cluster that it should try to start the resource,
which is the default anyway.

> My understanding of the meta bits is a little weak, and I can't find an  
> explanation as to what target-role is actually trying to do. 

It specifies the state the resource is meant to be in[1], i.e. stopped,
started, or a master or slave (the latter of which you would use for an active/passive DRBD clone pair, for example).

Ignoring master/slave resources, this attribute is set if you use
"crm resource stop" or "crm resource start" to force a resource to stop
or start.

Regards,

Tim

[1] Yes, I know I should use the word "role" here, not state :)


-- 
Tim Serong <tserong at novell.com>
Senior Clustering Engineer, Novell Inc.