Bug 579529

Summary:	generate-db-password.sh does not work on Solaris
Product:	[Other] RHQ Project	Reporter:	Corey Welton <cwelton>
Component:	Installer	Assignee:	Heiko W. Rupp <hrupp>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Corey Welton <cwelton>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	1.4	CC:	mazz
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Other
Whiteboard:
Fixed In Version:	2.4	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-08-12 16:48:01 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:	577033

Description Corey Welton 2010-04-05 18:25:10 UTC

Description of problem:
Attempting to run `generate-db-password.sh` on sun; the former is more innocuous, the latter appears fatal.

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


How reproducible:
Every time.

Steps to Reproduce:
  
bash-2.05# ./generate-db-password.sh rhqadmin
./generate-db-password.sh: readlink: not found
./generate-db-password.sh: test: unknown operator ==


Expected results:
functional generate-db-password.sh 

Additional info:
Can't remember why we would need readlink in this sort of script, but that's not a terribly big deal I don't think, and we tell people to install readlink on Sun anyway if they think they'll be using the startup scripts for agent and server.  That said, we should probably just make readlink from sunfreeware a hard requirement...

But regarding the other issue, this appears fatal to the tool -- it does not successfully run.  We do manage to obfuscate in rhq-server.properties, however...?

Comment 1 Charles Crouch 2010-04-05 19:33:45 UTC

We've had similar problems with our other scripts iirc, in both the same places. So we should take a look at the existing server/agent scripts, when fixing this.

Comment 4 Heiko W. Rupp 2010-04-21 19:23:20 UTC

Fix for the unknown operator is in 48423a9

Comment 5 John Mazzitelli 2010-04-21 19:54:14 UTC

the issues charles refers to is:

https://bugzilla.redhat.com/show_bug.cgi?id=534755

https://bugzilla.redhat.com/show_bug.cgi?id=535359

The "==" is due to the shell on solaris - we never use "==" in our scripts
anymore due to this. Always use "=".

readlink issue: they don't HAVE to have readlink - only if they are symlinking
to the script itself. We continue on if readlink isn't available, but if the
script is a symlink it will fail. See:

http://rhq-project.org/display/JOPR2/Running+the+RHQ+Agent#RunningtheRHQAgent-RunningasaDaemon

"For Solaris Admins: Symbolically linking the agent scripts require invocation
of readlink in rhq-agent-wrapper.sh. However, readlink is not supplied by
default in some Solaris installations. Solaris users must either download
readlink from a third party provider, such as Sunfreeware, or refrain from
symbolically linking the agent scripts when using the wrapper script. Note that
if you do not use symbolic links, the agent will not be able to auto-update the
script if it needs to do so in the future."

That's why our scripts do this (notice the || operator):

_DOLLARZERO=`readlink "$0" || echo "$0"`

Comment 6 Corey Welton 2010-05-11 13:36:35 UTC

QA Verified.

Comment 7 Corey Welton 2010-05-11 13:39:03 UTC

BTW, my comment regarding any necessity of readlink is the question as to why we would need this in the first place.  It makes sense for agent scripts to have to deal with symlinks, since they are service wrappers and may exist in symlinked locations.  I don't imagine many people would be doing this sort of thing with the obfuscation script though.

Comment 8 Corey Welton 2010-08-12 16:48:01 UTC

Mass-closure of verified bugs against JON.