Just had a quick look. One thing that is missing is a status
rpc. The underlying fencing libraries use status to make sure
the fencing worked.
Otherwise looking good.
On 04/04/2011 6:12 AM, "Gémes Géza" <
geza@xxxxxxxxxxx>
wrote:
> Hi Matt,
>
> As I've wrote before I've started working on the server
part. The first
> working example server code is at:
>
https://github.com/geza-gemes/Xen-Cloud-Platform-Xensever-stonith-fence-agent
> It is an XML-RPC server which accept start, shutdown and
reboot
> requests. The stonith/fence agent
> There are still lots of things to do:
> -Load configuration, secrets from a ini file (I've started
working on this)
> -Handle the signals which could be sent to the server
process
> -Better logging (currently none)
> -Better handling of already running already shutdown,
paused suspended
> states (there is none at the moment)
> -Set up an init script, and an optional stunel config for
the server
> (XCP/Xenserver doesn't have SSL python libs)
> -Build a rpm of the server part so it can be easily
installed in Dom0
>
> Cheers,
>
> Geza
>> Hi Geza,
>>
>> Thanks for your feedback.
>>
>> Using a specific server for this was the first approach
I took,
>> writing a python daemon process that utilised XML-RPC
(I will see if I
>> can dig it up). Got a fair way down that path but
realised I was just
>> rewriting fence-virtd so then I started to look into
altering
>> fence-virtd instead. That's where I stopped. I want to
get back around
>> to this eventually, but that's not what this script is
for.
>>
>> This script is to fence a node through the XenAPI. As
you mentioned,
>> the security model employed by XenAPI does not allow
username/password
>> based access control of specific VM's (that I am aware
of without
>> using windows based active directory credentials), but
maybe it will
>> in the future. Note that this is an underlying API
limitation.
>>
>> The same script can be updated to also use GezaAPI in
the future, once
>> this is written. I will be happy to make the changes
once you have
>> your daemon working and API laid out. To be honest it
should be a
>> pretty straight forward transition.
>>
>> Cheers,
>> Matt.
>>
>> On Thu, Mar 31, 2011 at 6:51 AM, Gémes Géza <
geza@xxxxxxxxxxx
>> <mailto:
geza@xxxxxxxxxxx>>
wrote:
>>
>> 2011-03-30 13:09 keltezéssel, m c írta:
>>> Hi,
>>>
>>> I think this would be the best forum, let me know
if not.
>>>
>>> I am in the middle of writing fencing scripts for
Citrix
>>> XenServer virtual machines (specifically for use
with Redhat
>>> Clustering, but will also work from pacemaker etc)
and I noticed
>>> that XCP uses the same XenAPI (from what I can
tell).
>>>
>>> Just wondering if someone would be able to test the
scripts on
>>> XCP and let me know if they work.
>>>
>>> The latest tar ball can be downloaded from the
following URL:-
>>>
http://code.google.com/p/fence-xenserver/downloads/list
>>>
>>> Once extracted a test can be performed as follows
(the following
>>> will just list all the VM's and their current
state, it will not
>>> turn reboot a machine so is safe):-
>>>
>>> cd /tmp
>>> tar xvzf fence-xenserver-0.8.tar.gz
>>> cd fence-xenserver-0.8
>>> ./fence_cxs_redhat.py -o list -s
http://192.168.1.1/
-l root -p
>>> <passwd>
>>>
>>> That should be enough to test if it is functioning
properly.
>>> Appreciate any feedback.
>>>
>>> Thanks,
>>> Matt.
>>>
>>>
>>> _______________________________________________
>>> Xen-users mailing list
>>>
Xen-users@xxxxxxxxxxxxxxxxxxx
>>> <mailto:
Xen-users@xxxxxxxxxxxxxxxxxxx>
>>>
http://lists.xensource.com/xen-users
>> Hi,
>>
>> Just this morning I've decided to start writing
something similar
>> (stonith script for pacemaker).
>> I have only one objection to the approach used by your
script. It
>> would be more robust (more secure) if the script would
connect to
>> a small server running in Dom0 with some shared secret
>> corresponding to each DomU, in this way non-cluster
member DomU's
>> won't be able to shut down cluster members, or legit
DomU's
>> wouldn't be able to do whatever they would want on the
Dom0
>> (allowing fence/stonith to run with root credentials,
ssh keys,
>> whatever laying somewhere in the DomUs filesystem is
not the best
>> solution regarding security).
>> I planed to write a small server program which would
run on the
>> Dom0, with a htpasswd like config file, where user
entries would
>> have been DomUs, each with a password. The fence
agent/stonith
>> script would connect to this server and providing the
right
>> credentials for the given DomU it would be able to
issue
>> force-reboot, start, force-shutdown, whatever would be
needed
>> actions on that DomU, and nothing more. A similar
approach without
>> using a Dom0 side server would be possible if using AD
>> authentication and assignment of different DomUs to
different roles.
>>
>> Best Regards
>>
>> Geza
>>
>> _______________________________________________
>> Xen-users mailing list
>>
Xen-users@xxxxxxxxxxxxxxxxxxx
<mailto:
Xen-users@xxxxxxxxxxxxxxxxxxx>
>>
http://lists.xensource.com/xen-users
>>
>>
>
