Bug 1104730

Summary:	[GSS] add-user.sh exits with status code 0 when password complexity fails
Product:	[JBoss] JBoss Enterprise Application Platform 6	Reporter:	Andy Fraley <andrew.fraley>
Component:	Scripts and Commands	Assignee:	Chao Wang <chaowan>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Petr Kremensky <pkremens>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.3.0	CC:	andrew.fraley, cdewolf, chaowan, darran.lofthouse, fnasser, kkhan, myarboro, pgier, smatasar
Target Milestone:	DR1
Target Release:	EAP 6.4.0
Hardware:	All
OS:	All
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Andy Fraley 2014-06-04 14:46:35 UTC

Description of problem:
add-user.sh exists with status code 0 when the password complexity check fails.  This should exit with status code 1 instead.

Version-Release number of selected component (if applicable):
6.2.0

How reproducible:
./add-user.sh -u derp -p 1234; echo $?

Actual results:
0

Expected results:
1

Additional info:

Comment 1 Chao Wang 2014-06-09 07:57:10 UTC

IMHO, its not a bug. It works like that by design since we catch the PasswordValidationException which is threw from LengthRestriction, and generate a new ErrorState to print error message into terminal. Due to this, the exit status code is 0.

Comment 2 Andy Fraley 2014-06-11 15:10:46 UTC

The script fails to create the user, so IMO it should exit with an error status.  For example, I'm trying to use this script as part of a Chef recipe that needs to create an admin account.  Due to this behavior, I can't use the exit status of the script to determine if the account creation was successful.

Comment 4 Fernando Nasser 2014-07-09 12:43:09 UTC

A good fix to add on a CPxx release, so I propose 6.3.1 (could not find flag)

Comment 5 Darran Lofthouse 2014-07-09 12:56:43 UTC

If this issue is going to become the issue for EAP 6.3.1 which issue is going to track EAP 6.4.0?  Without an ACKed issue for EAP 6.4.0 I don't believe this can go into EAP 6.3.1 unless we are handling that one differently.

Comment 8 Petr Kremensky 2014-09-19 08:32:49 UTC

Verified on EAP 6.4.0.DR1.1

Comment 9 Shay Matasaro 2015-10-01 13:35:01 UTC

fix requested for next EAP CP