non-casual client of api

[Bill Adams]

Thanks...yes, this helped to confirm what I was trying to do after =
Alan's last suggestion.

I am seeing this log message each time "my own" message is received at =
the destination cluster member:

	Feb 11 19:09:31 clustermember2 heartbeat: ERROR: /etc/ha.d/harc: =
/etc/ha.d/rc.d/my_own: cannot execute

Is there a mechanism for disabling the heartbeat from trying to run a =
script by "my_own" message type name?  Is this expected behavior?  Am I =
misusing the API? =20

Again - thx,
-Bill-

-----Original Message-----
From: Ram Pai [mailto:linuxram@us.ibm.com]
Sent: Monday, February 11, 2002 6:18 PM
To: Bill Adams
Cc: linux-ha@muc.de
Subject: RE: non-casual client of api


On Mon, 11 Feb 2002, Bill Adams wrote:

> Thanks Alan.
> That took me much further.
>
> Next question...
>
> Can I use the HB API to pass "my own" types of messages among my named =
client services in the cluster?
>
> I was hoping that the sendclustermsg() API was going to provide me =
with a mechanism to send 'generic' intra-cluster messages to my own =
named API clients, but it's looking like I have to conform to a standard =
HB API msg format.  Do I have this right/wrong?
>

	You can send your own 'generic' intra-cluster messages, but they
	have to be encoded in HB API msg format.


	You have to send the messages in the form of name=3Dvalue pair
	and on receipt have to retrieve the value by providing the name.


	THe code looks something like this


sending side:

#define MY_OWN_MSG_TYPE1 "xyz"
        if ((ha_msg_add(m, F_TYPE, "myown_type")
                                        =3D=3D HA_FAIL)
                ||(ha_msg_add(m, MY_OWN_MSG_TYPE1, "myownvalue1") =3D=3D =
HA_FAIL)){
                ha_log(LOG_ERR, "Cannot create myown_type "
                                "reply message");
                        rc =3D HA_FAIL;
        } else {
                     rc =3D sendclustermsg(hb, m);
        }



receiving side:

#define MY_OWN_MSG_TYPE1 "xyz"
	type        =3D ha_msg_value(m, F_TYPE);
	myownvalue  =3D ha_msg_value(m, MY_OWN_MSG_TYPE1);


Hope this helps,
--=20
Ram Pai
linuxram@us.ibm.com
503-5783752
Tieline: 7753752
------------------------


> Thx again,
> -Bill-




>
>
> -----Original Message-----
> From: Alan Robertson [mailto:alanr@unix.sh]
> Sent: Friday, February 08, 2002 3:59 PM
> To: Bill Adams
> Cc: linux-ha@muc.de
> Subject: Re: non-casual client of api
>
>
> Bill Adams wrote:
> >
> > int *signon(struct ll_cluster cinfo*, const char *service)
> >
> > Has anyone experienced success when signing on to the heartbeat api =
as a non-casual client (i.e. service !=3D NULL)?
>
> Yes.  The current test program works that way.  I have two such =
clients
> running on my test cluster right now.
>
> Because heartbeat runs as root, it is very security conscious, and =
it's a
> bit hard to get it all configured right so it doesn't refuse to =
operate.
> Most of the moaning about security goes to the logs.
>
> Make fifos named /var/lib/heartbeat/api/servicename.req and
> /var/lib/heartbeat/api/servicename.rsp.  They must be owned by
> the userid of the process that wants to use it.
> The .req fifo must be mode 200, and the .rsp FIFO must be mode 600.
>
> Here's what my API directory looks like:
>   p-w-------    1 root     root            0 Feb  8 11:39 ccm.req
>   prw-------    1 root     root            0 Feb  8 11:39 ccm.rsp
>   p-w-------    1 alanr    root            0 Feb  7 10:39 ping.req
>   prw-------    1 alanr    root            0 Feb  7 09:32 ping.rsp
>
> I am set up to run two named clients, "ccm" and "ping". ("ping" is the
> test program).
>
> The client userid must be a member of group haclient.  So, in this
> case alanr is a member of group ha_client.  The line from /etc/group:
> 	haclient:x:90:root,alanr,ram
>
> I think this is how heartbeat is set up by default, but just in case..
>   ls -ld /var/lib/heartbeat/api
>   drwxr-x---    2 root     haclient      129 Feb  7 21:08
> /var/lib/heartbeat/api
>
>
> Those are the basics.  Try that and see where that gets you.
>
> 	-- Alan Robertson
> 	   alanr@unix.sh
>
> =
-------------------------------------------------------------------------=
-----
> Linux HA Web Site:
>   http://linux-ha.org/
> Linux HA HOWTO:
>   =
http://metalab.unc.edu/pub/Linux/ALPHA/linux-ha/High-Availability-HOWTO.h=
tml
> =
-------------------------------------------------------------------------=
-----
>