Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1199928

Summary: Red Hat Satellite Restore Procedure restores PostgresDB from the wrong file
Product: Red Hat Satellite Reporter: David Gurtner <dgurtner>
Component: Docs User GuideAssignee: Stephen Wadeley <swadeley>
Status: CLOSED WONTFIX QA Contact: Russell Dickenson <rdickens>
Severity: medium Docs Contact:
Priority: medium    
Version: UnspecifiedCC: adahms, hhudgeon
Target Milestone: Unspecified   
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Build Name: 22921, User Guide-6.0 Build Date: 08-10-2014 13:34:52 Topic ID: 11182-708795 [Latest]
Last Closed: 2016-08-09 00:33:42 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 David Gurtner 2015-03-09 09:53:59 UTC
Title: Red&nbsp;Hat Satellite Restore Procedure

Describe the issue:

While the Backup Procedure already has the following bugs to

1. fix to dump the correct database:

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

2. save the correct dump to the backup:

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

The Restore procedure under 16.2.2. Red Hat Satellite Restore Procedure Step 7 still references katello.dump instead of foreman.dump when restoring.

Suggestions for improvement:

Replace /backup/katello.dump with /backup/foreman.dump under 16.2.2 Step 7.

Additional information:

Comment 1 RHEL Program Management 2015-03-09 10:13:42 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 4 RHEL Program Management 2015-04-21 16:05:42 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 5 Andrew Dahms 2016-03-16 11:34:28 UTC
Assigning to Stephen for review.

Comment 6 Andrew Dahms 2016-03-16 11:41:45 UTC
Stephen - looks like this refers to the older, 6.0 version of the User Guide, and this is no longer relevant.

Would you be able to take a quick look and see if there is anywhere in the current procedure that this would fit? If no, I believe we can close this one given our current focus on the 6.2 release.

Comment 7 Stephen Wadeley 2016-03-16 17:08:44 UTC
Hello


I cannot find ".dump" in published guides newer than 6.0

it is in the repo for 6.0-GA but not Satellite-6.1-async1 onwards

Checking 6.0 guides:

I found "/backup/foreman.dump" in Step 4 of "Procedure 16.2. Red Hat Satellite Backup Procedure" under " ⁠16.2.1. Red Hat Satellite Backup Procedure"[1]

the string "/backup/katello.dump" mentioned in comment 0 is in the next section "16.2.2. Red Hat Satellite Restore Procedure" [2]


[1] https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.0/html-single/User_Guide/index.html#System_Engine_Backup_Procedure

[2]  ⁠ https://access.redhat.com/documentation/en-US/Red_Hat_Satellite/6.0/html-single/User_Guide/index.html#System_Engine_Restore_Procedure

Comment 8 Andrew Dahms 2016-06-06 11:38:57 UTC
Hi Stephen,

My apologies for the long time it has taken to get back to you on this one.

Would this be an easy enough change to make alongside your work on BZ#1199935? If so, looks like it would be good to get to them both at the same time.

Kind regards,

Andrew

Comment 10 Stephen Wadeley 2016-06-06 11:54:01 UTC
(In reply to Andrew Dahms from comment #8)
> Hi Stephen,
> 
> My apologies for the long time it has taken to get back to you on this one.
> 
> Would this be an easy enough change to make alongside your work on
> BZ#1199935? If so, looks like it would be good to get to them both at the
> same time.
> 
> Kind regards,
> 
> Andrew

I am sorry, as the 6.0 guides are not in git I cannot update them.

Comment 11 Stephen Wadeley 2016-07-21 09:54:55 UTC
Hello Andrew

To summarize: 
comment 0 wants "katello.dump" replaced by "foreman.dump"

my comment 7 is trying to imply there is nothing for me to fix, for this bug, in 6.1 or later docs, because the use of <something>.dump no longer occurs after 6.1GA

I made a typo there: s/it is in the repo for 6.0-GA/it is in the repo for 6.1-GA/

It *was* in 6.1 GA guide, but not Satellite-6.1-async1 onwards

last version published was Satellite-6.1-async3

user-guide]$ git checkout Satellite-6.1-async3
Switched to branch 'Satellite-6.1-async3'
Your branch is up-to-date with 'origin/Satellite-6.1-async3'.
 user-guide]$ grep -r ".dump" en-US/
 user-guide]$   {nothing}

as the 6.0 guides are not in git I cannot update them.

Requesting to close this bug.

Comment 12 Andrew Dahms 2016-08-09 00:33:42 UTC
Hi Stephen,

Thank you for the detailed update.

I agree - closing.

Kind regards,

Andrew