Bug 497110 - spacewalk-certs-tools, rhn-ssl-tool has traceback with option --gen-ca
spacewalk-certs-tools, rhn-ssl-tool has traceback with option --gen-ca
Product: Red Hat Satellite Proxy 5
Classification: Red Hat
Component: Installer (Show other bugs)
All Linux
urgent Severity high
: ---
: ---
Assigned To: Devan Goodwin
Petr Sklenar
: Reopened
Depends On:
Blocks: 456999
  Show dependency treegraph
Reported: 2009-04-22 08:25 EDT by Petr Sklenar
Modified: 2009-09-10 10:38 EDT (History)
3 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-10 10:38:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Petr Sklenar 2009-04-22 08:25:10 EDT
Description of problem:
cannot generate SSL key pair with rhn-ssl-tool

Version-Release number of selected component (if applicable):
rpm -qf `which rhn-ssl-tool`

How reproducible:

Steps to Reproduce:

1. cd /root
2. rhn-ssl-tool --gen-server
3. rhn-ssl-tool --gen-ca

Actual results:
Generating web server's SSL certificate request: ./ssl-build/xen44.englab.brq/server.csr
Using distinguished names:
    --set-country      = "US"
    --set-state        = "North Carolina"
    --set-city         = "Raleigh"
    --set-org          = "Example Corp. Inc."
    --set-org-unit     = "unit"
    --set-hostname     = "xen44.englab.brq.redhat.com"
    --set-email        = "admin@example.com"
Backup made: 'server.csr' --> 'server.csr.1'

Rotated: server.csr --> server.csr.1

Generating/signing web server's SSL certificate: server.crt
Backup made: 'server.crt' --> 'server.crt.1'

Rotated: server.crt --> server.crt.1


ERROR: unhandled exception occurred:
Traceback (most recent call last):
  File "/usr/bin/rhn-ssl-tool", line 58, in ?
    sys.exit(mod.main() or 0)
  File "/usr/share/rhn/certs/rhn_ssl_tool.py", line 1221, in main
    ret = _main() or 0
  File "/usr/share/rhn/certs/rhn_ssl_tool.py", line 1189, in _main
    genServerRpm(DEFS, options.verbose)
  File "/usr/share/rhn/certs/rhn_ssl_tool.py", line 1029, in genServerRpm
    raise Exception("No jabber/jabberd user on system")
Exception: No jabber/jabberd user on system

Expected results:

no traceback 

Additional info:
RHN proxy requires SSL key pair for installation.
Comment 1 Petr Sklenar 2009-04-22 08:33:02 EDT
when I add users jabber+jabberd, then it works
Comment 2 Miroslav Suchý 2009-04-22 09:38:21 EDT
Description of the problem:
when we are installing proxy using webui installer from hosted, it do not have "enable push" option - which is perfectly valid since hosted do not support this.
When push is not enabled, then jabberd is not installed - still perfectly valid since we do not need it for anything.

But rhn_ssl_tool.py expect jabberd user since commit 023fc16f4aca7c477730246f945200290c6f2f52
Comment 3 Brandon Perkins 2009-04-23 10:41:33 EDT
Accepted.  Assigning to Devan per commit:


Should be a simple check.
Comment 4 Devan Goodwin 2009-04-24 11:09:49 EDT
Two ways to go about this, I'm making a choice for one but will document both incase anyone sees any problems with it.

(1) Change the ownership to fall back on root:root if jabberd user isn't found. (very easy)

(2) Don't include jabberd.pem in the generated rpm at all if jabberd user isn't found on the system where the rpm is built.

I'm taking path (1) as I don't really know for sure how this RPM could be used and it seems less likely to introduce problems elsewhere if we keep the jabberd cert included.
Comment 5 Miroslav Suchý 2009-04-24 11:17:51 EDT
[17:09] <dgoodwin> msuchy: just drafting a comment now I think I have a feeling which direction to take
[17:09] <dgoodwin> msuchy: comment posted
[17:15] <msuchy> dgoodwin: I'm not sure with 1) what will happen if you install proxy withou jabber, run this toll, install resulted package (therefore as root:root) and then reinstall proxy with jabber and generate new package, will it be then installed as jabberd:jabberd ?
[17:15] <msuchy> dgoodwin: I suppose that 2) can be safe
[17:15] <dgoodwin> should come out as jabberd:jabberd if you regenerate the rpm and re-install
[17:15] <dgoodwin> hmmm maybe
[17:16] <dgoodwin> i will test, a root:root jabberd 0600 is probably useless anyhow
[17:16] <msuchy> dgoodwin: yeah, correct 1) will work, but I will personaly vote for 2)
[17:17] <dgoodwin> msuchy: yeah i think i agree with you, i'll change that and go with 2)
Comment 6 Devan Goodwin 2009-04-24 11:40:01 EDT
Implemented option (2) and tested upgrades from versions with and without the cert, seems to work fine. 

Committed to:

spacewalk.git: 3b28f1a152a00d3dee084494c9cac79f9c38243b
satellite.git: 9583f21ad84032be78ee6f1697e4d692cbe3d5d5
Comment 7 Devan Goodwin 2009-04-29 12:38:27 EDT
Mistake on my part, this ticket is not yet on QA, the commit was made after the merge.
Comment 8 Devan Goodwin 2009-04-29 12:44:34 EDT
Moved this ON_QA when infact I missed the merge window. Back to modified.
Comment 9 Petr Sklenar 2009-05-11 07:31:49 EDT
reproduced with old and it works with latest version: spacewalk-certs-tools-0.5.5-5.el4sat
Created cert works with RHN proxy 5.2

Comment 10 Miroslav Suchý 2009-08-10 09:42:22 EDT
verified in stage
Comment 11 Brandon Perkins 2009-09-10 10:38:25 EDT
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.


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