Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 508262

Summary: Fence agents ends with traceback when option is missing
Product: Red Hat Enterprise Linux 5 Reporter: Marek Grac <mgrac>
Component: cmanAssignee: Marek Grac <mgrac>
Status: CLOSED ERRATA QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: low    
Version: 5.3CC: bkahn, cluster-maint, djansa, edamato, jkortus
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: cman-2.0.115-4.el5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 508268 (view as bug list) Environment:
Last Closed: 2010-03-30 08:41:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 508268    
Attachments:
Description Flags
Proposed patch none

Description Marek Grac 2009-06-26 11:21:28 UTC
If WTI device expects login and login name is not entered then it fails with traceback. Correct error message is expected.

Login name is required for WTI, so it has to be checked after login is encountered.

Comment 1 Marek Grac 2009-06-26 11:29:01 UTC
Same problem can occur with password (also optional on wti)

Comment 5 Marek Grac 2009-08-31 15:15:22 UTC
Created attachment 359277 [details]
Proposed patch

Similar problem exists also for APC

Comment 10 Jaroslav Kortus 2010-03-11 17:19:22 UTC
[root@z2 ~]# echo -e "ipaddr=1.1.1.1\nport=44\nipport=54444\n" | fence_apc
Failed: You have to set login name

[root@z2 ~]# echo -e "ipaddr=1.1.1.1\nport=44\nipport=54444\nlogin=x\n" | fence_apc
Failed: You have to enter password or password script

fence_apc clearly still requires both login and password to start any operation. Is this as intended?

Comment 12 Perry Myers 2010-03-12 17:42:03 UTC
(In reply to comment #10)
> [root@z2 ~]# echo -e "ipaddr=1.1.1.1\nport=44\nipport=54444\n" | fence_apc
> Failed: You have to set login name
> 
> [root@z2 ~]# echo -e "ipaddr=1.1.1.1\nport=44\nipport=54444\nlogin=x\n" |
> fence_apc
> Failed: You have to enter password or password script
> 
> fence_apc clearly still requires both login and password to start any
> operation. Is this as intended?    

Yes.  username/password is required.  This bug wasn't about username/password not being required.  It was that when username/password wasn't given to fence_wti, the fence agent would fail in a non graceful manner.

As you can see, the apc fence agent is failing in a graceful manner and prompting the user for the username/password as appropriate

Did you check the WTI agent specifically to make sure that the traceback is gone?

Comment 13 Lon Hohberger 2010-03-12 17:56:11 UTC
APC fencing devices always require username and password.

WTI fencing devices usually require both.  Older devices such as the IPS may get by with only the password.

Comment 14 Lon Hohberger 2010-03-12 17:56:55 UTC
that is: the fence_wti agent should not _require_ a username, only a password.

APC should require both.

Comment 15 Lon Hohberger 2010-03-12 17:57:39 UTC
> fence_apc clearly still requires both login and password to start any
> operation. Is this as intended?    

Yeah, that's correct behavior for fence_apc.

Comment 16 Jaroslav Kortus 2010-03-12 19:38:18 UTC
the wti agent worked as expected, so if the apc case is also as it should be, I'm marking this as verified. Thanks for comments.

Comment 18 errata-xmlrpc 2010-03-30 08:41:17 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0266.html