Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1545001 - Document the addition of the '-y' flag to the katello-backup command
Document the addition of the '-y' flag to the katello-backup command
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Docs Server Administration Guide (Show other bugs)
6.2.13
Unspecified Unspecified
medium Severity medium (vote)
: 6.2.15
: Unused
Assigned To: Russell Dickenson
Melanie Corr
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2018-02-13 20:30 EST by Andrew Dahms
Modified: 2018-08-31 11 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-03-04 17:50:04 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Andrew Dahms 2018-02-13 20:30:32 EST
Red Hat Satellite 6.2.14 introduced a '-y' flag to the katello-backup command that changed the default behaviour. Now, users must supply this flag when running an off-line backup to ensure services are stopped when the backup is created.

The following section of the 6.2 Server Administration Guide must be updated to reflect the new behaviour -

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/server_administration_guide/chap-red_hat_satellite-server_administration_guide-backup_and_disaster_recovery
Comment 1 Andrew Dahms 2018-02-13 20:31:32 EST
Assigning to Russell for review.

Russell - we'll tackle these changes in the 6.2 version to start with given that this is where the greatest need is right now. When the 6.3 version has been fully converted to AsciiDoc, we can look to making the changes there as well, perhaps under a separate bug.
Comment 8 Bengt Giger 2018-02-26 07:17:50 EST
The question should be avoided when the scripts runs non interactive. Currently, non interactive and offline mode, the script assumes "no" and continues. Consequently, the backup is performed with the services still running, leading to backups guaranteed to being corrupt, without feedback to the user. It took us 2 weeks and an analysis of the backup code until we discovered we had nothing but useless backups.

The script MUST either cancel and return an error code, or unconditionally stop the services if in offline mode, assuming that the selection of the offline mode implicates services stopped; IMHO using offline mode implicates stopping the services.

Please check how the currently broken script will be fixed before documenting.

Btw. the flag was introduced with 6.2.13
Comment 9 John Mitsch 2018-02-26 09:06:44 EST
> The question should be avoided when the scripts runs non interactive.
> Currently, non interactive and offline mode, the script assumes "no" and
> continues. 

To make sure I understand, you are running the script with -y but not using --online-backup flag, and the script keeps the services running? If this is the case, we definitely need to file a bug around this. What version of satellite?
Comment 10 Bengt Giger 2018-02-27 11:49:57 EST
No, with "-y" it behaves as designed. But doing offline backups in a non interactive script environment without the "-y" flag (which was the default up to 6.2.12) must either stop the services or return an error code. Not continue silently with the worst decicion: doing backup while the services are running. Customer scripts migrating from 6.2.12 do not set a "-y" flag.

I'm in touch with David Caplan about this issue, because two modifications introduced with 6.2.13 had disastrous effects on backup script implementations. I'm sure there are Satellite customer still running backup scripts which produces corrupt backups every day, unnoticed, because of the dangerous act of introducing this new flag. I just want to make sure that the documentation takes into account upcoming changes.

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