Bug 579529 - generate-db-password.sh does not work on Solaris
Summary: generate-db-password.sh does not work on Solaris
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Installer
Version: 1.4
Hardware: All
OS: Other
medium
medium
Target Milestone: ---
: ---
Assignee: Heiko W. Rupp
QA Contact: Corey Welton
URL:
Whiteboard:
Depends On:
Blocks: 577033
TreeView+ depends on / blocked
 
Reported: 2010-04-05 18:25 UTC by Corey Welton
Modified: 2010-08-12 16:48 UTC (History)
1 user (show)

Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-12 16:48:01 UTC
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.