Bug 883301

Summary: notifier.conf: MAIL_PASSWORD= <value containing &> is refered to as empty, and fail notifier service start
Product: Red Hat Enterprise Virtualization Manager Reporter: Ilanit Stein <istein>
Component: ovirt-engine-notification-serviceAssignee: Noam Slomianko <nslomian>
Status: CLOSED CURRENTRELEASE QA Contact: Ilanit Stein <istein>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.1.0CC: bazulay, dfediuck, dyasny, iheim, nslomian, pstehlik, Rhev-m-bugs, sgrinber, ykaul, yzaslavs
Target Milestone: ---   
Target Release: 3.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: infra
Fixed In Version: sf8 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: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 915537    

Description Ilanit Stein 2012-12-04 09:28:58 UTC
Description of problem:

Using '&' in MAIL_PASSWORD, give same failure, as if it was empty.

When using the following settings in notifier.conf:
MAIL_USER=istein, MAIL_ENABLE_SSL=true, MAIL_PASSWORD=&
restartting notifier service fail on:
Error: $MAIL_PASSWORD is not defined for SSL MAIL, please check for this in configuration file /etc/ovirt-engine/notifier/notifier.conf

Version-Release number of selected component (if applicable):
SI24.5

How reproducible:
always

Expected results:
Have the '&' a valid charachter for MAIL_PASSWORD.

Comment 1 Simon Grinberg 2012-12-25 11:10:07 UTC
Ilanit, does this happen for any password containing this character? in any length? 

If it only happens if password is a single & character I would close as not fix, this password hardly if ever be found in a real life use case. Not worth the fix.

Comment 2 Yaniv Kaul 2012-12-25 11:13:50 UTC
(In reply to comment #1)
> If it only happens if password is a single & character I would close as not
> fix, this password hardly if ever be found in a real life use case. Not
> worth the fix.

We were specifically asked in the past to support chars such as !@#$%^&*() 
We had bugs from customers where they were not supported.

Comment 3 Ilanit Stein 2012-12-26 08:11:45 UTC
This happen for any password containing this character. At any length.

Comment 4 Simon Grinberg 2012-12-30 10:02:37 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > If it only happens if password is a single & character I would close as not
> > fix, this password hardly if ever be found in a real life use case. Not
> > worth the fix.
> 
> We were specifically asked in the past to support chars such as !@#$%^&*() 
> We had bugs from customers where they were not supported.

Agree, no problem with that, I was only wandering if it's just an issue with a password with length of one character. At any length as mentioned in comment #3 then it's a bug that needs fixing.

Comment 5 Ilanit Stein 2013-02-28 12:37:24 UTC
Verified on sf-8

Comment 6 Itamar Heim 2013-06-11 08:22:45 UTC
3.2 has been released

Comment 7 Itamar Heim 2013-06-11 08:24:56 UTC
3.2 has been released