Bug 877400

Summary:	Use /var instead of /root as SSL scratch directory
Product:	Red Hat Satellite	Reporter:	Dominic Cleal <dcleal>
Component:	Installation	Assignee:	satellite6-bugs <satellite6-bugs>
Status:	CLOSED WONTFIX	QA Contact:	Katello QA List <katello-qa-list>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	6.0.0	CC:	bkearney, cwelton, ehelms, stbenjam
Target Milestone:	Unspecified	Keywords:	Triaged
Target Release:	Unused
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-01-04 17:39:34 UTC	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 Dominic Cleal 2012-11-16 12:31:32 UTC

Description of problem:
katello-configure (rather, the "certs::config" class) uses /root/ssl-build as a scratch directory to store lots of SSL data.  It contains OpenSSL configs, keys, certs, serials etc., generated by install steps in the class.

This data should move to /var/lib/katello or similar, so it follows the FHS.  Under /root it's in danger of not being backed up.

Version-Release number of selected component (if applicable):
1.1, confirmed in git master.

How reproducible:
Always

Steps to Reproduce:
1. install katello
2. run katello-configure
3. check /root/ssl-build
  
Actual results:
Present

Expected results:
Absent

Comment 1 Bryan Kearney 2013-01-22 16:07:17 UTC

From LZAP in email
I think the reason why we choosen /root was:

1) There are few files which contains private keys
2) Satellite do this
3) The ultimate goal is to generate Katello ueber-cert with private key
that must be kept separetely (and backuped separately too) and then to
sign everything else. I am not sure if we want to move this one into
/var (therefore regular backups - very often unencrypted).

So I am for moving the content out of /root maybe except the most
sensitive information - like ueber-passphrase.

Comment 2 Stephen Benjamin 2016-10-13 16:05:35 UTC

Created redmine issue http://projects.theforeman.org/issues/16914 from this bug

Comment 4 Bryan Kearney 2017-01-04 17:39:34 UTC

This is an older bug, which is being tracked upstream. We will not be tracking this downstream. When the upstream issue is resolved, the next rebase will pull in the fix.