From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jan Friesse <jfriesse@redhat.com>
Date: Thu, 11 Jun 2009 11:31:55 +0200
Subject: [Cluster-devel] Prototype Fencing Agent for Raritan eRIC G4
In-Reply-To: <4A30087D.3060901@bobich.net>
References: <4A2ED075.5020207@bobich.net> <4A300034.9050603@redhat.com>
	<4A30087D.3060901@bobich.net>
Message-ID: <4A30CF0B.2030203@redhat.com>
List-Id: <cluster-devel.redhat.com>
To: cluster-devel.redhat.com
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Gordan,

Gordan Bobic wrote:
> Subhendu Ghosh wrote:
> 
>> Would it be possible to look at migrating this agent to SSH (more secure)
> 
> I started with the idea of doing it over ssh, but Net::SSH module seemed
> to be a lot less forgiving about the terminal quirkyness. I can have
> another go. There's also the issue of manual intervention being required
> to save the signatures (and where do the known hosts go?).
> 
>> or to SNMP (less screen scraping)?
> 
> Hmm, maybe. I haven't looked into the SNMP capability on the device, but
> it looks like it'll work, and probably be easier to do than SSH.
> 
>> Look at fence_cisco as an example of snmp usage.
> 
> Assuming they speak a compatible dialect, which may not be the case.
> I'll have a look.

We are using fence agents library, which makes writing agents easier
(capable of doing things like command line parsing, implement reboot
operation, ...), shorter and easier to maintain. fence_cisco is good
example (short, tested, ...) HOW to write such agent. Agents are written
in Python, and we are migrating all agents on top of library.

> 
>> Long term maintainability of screen scraping is an issue with firmware
>> changes.
> 
> Tell me about it. I submitted a patch for fence_drac a while back to
> address an issue that seems to have arisen from a firmware update
> inducted pattern match failure.
> 
> Not only that, but I've discovered a bug on the latest eRIC G4 firmware
> - 04.02.00-7153 seems to have broken USB keyboard support (you'd think
> this was important on a remote console device!) and potentially some
> power button press dodgyness. The previous firmware, however -
> 04.02.00-6505, works OK.
> 
>> Also it seems that card has IPMI support. If so, can use test with
>> fence_ipmi?
>> Would remove the need for yet-another-agent ;)
> 
> Sadly, my servers with these cards in them don't have IPMI support. The
> card only proxies it. The card supports direct power/reset button
> control in addition to IPMI, so this is what I'm using. But as you can
> see from the code, it operates only on the power on/off even for a
> reboot because the said servers also don't have a reset connector. I
> wrote this agent because I _needed_ it. :)
> 
> But I'll look into the SNMP way of doing it, it sounds like it might be
> neater. I'll add it as an option since the telnet way is already
> written. What parameter should/can be used to specify such things, that
> is available from a cluster.conf reference?

This question answers you little look to fence_cisco agent (or you can
use fence_ifmib, fence_intel_modular, fence_apc_snmp, ...). In case you
will not understand something, please ask.

> 
> Thanks.
> 
> Gordan
> 

Regards,
  Honza