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 1679129

Summary: foreman-maintian service fails with "couldn't find HOME environment -- exp anding `~' (ArgumentError)"
Product: Red Hat Satellite Reporter: Anand Agrawal <aagrawal>
Component: Satellite MaintainAssignee: Anurag Patel <apatel>
Status: CLOSED ERRATA QA Contact: Jameer Pathan <jpathan>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.4CC: apatel, aupadhye, bbuckingham, inecas, jesper.schmidt, jpathan, kgaikwad, mbacovsk, pcreech, smajumda, supatil
Target Milestone: 6.8.0Keywords: Triaged
Target Release: Unused   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: rubygem-foreman_maintain-0.6.9 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-10-27 12:38:20 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 Anand Agrawal 2019-02-20 12:17:49 UTC
Description of problem:

`foreman-maintain service stop` fails with below error message:
~~~~~~~~~~~~~~~~
/usr/share/gems/gems/foreman_maintain-0.2.11/lib/foreman_maintain/config.rb:18:in `expand_path': couldn't find HOME environment -- exp
anding `~' (ArgumentError)
        from /usr/share/gems/gems/foreman_maintain-0.2.11/lib/foreman_maintain/config.rb:18:in `initialize'
        from /usr/share/gems/gems/foreman_maintain-0.2.11/lib/foreman_maintain.rb:54:in `new'
        from /usr/share/gems/gems/foreman_maintain-0.2.11/lib/foreman_maintain.rb:54:in `setup'
        from /usr/share/gems/gems/foreman_maintain-0.2.11/bin/foreman-maintain:12:in `<top (required)>'
        from /usr/bin/foreman-maintain:23:in `load'
        from /usr/bin/foreman-maintain:23:in `<main>'
~~~~~~~~~~~~~~~~~~~~~~
Observation:

1. $HOME=/root is set by default in both the Satellite 6.3 and Satellite 6.4.

2. If we manually unset the $HOME in Satellite 6.3, foreman-maintain service still works.

3. If we manually unset the $HOME in Satellite 6.4, foreman-maintain service doesn't work.

Version-Release number of selected component (if applicable):
6.4

How reproducible:
Always, when $HOME is unset in Satellite 6.4

Steps to Reproduce:
1. Open Satellite 6.4 terminal and unset the HOME
2. unset HOME
3. foreman-maintain service stop
4. This will fail

Actual results:

foreman-maintain service should work even if HOME is unset as in Satellite 6.3

Expected results:

Fails with below error:

/usr/share/gems/gems/foreman_maintain-0.2.11/lib/foreman_maintain/config.rb:18:in `expand_path': couldn't find HOME environment -- exp
anding `~' (ArgumentError)
        from /usr/share/gems/gems/foreman_maintain-0.2.11/lib/foreman_maintain/config.rb:18:in `initialize'
        from /usr/share/gems/gems/foreman_maintain-0.2.11/lib/foreman_maintain.rb:54:in `new'
        from /usr/share/gems/gems/foreman_maintain-0.2.11/lib/foreman_maintain.rb:54:in `setup'
        from /usr/share/gems/gems/foreman_maintain-0.2.11/bin/foreman-maintain:12:in `<top (required)>'
        from /usr/bin/foreman-maintain:23:in `load'
        from /usr/bin/foreman-maintain:23:in `<main>'

Additional info:

In order to get an offline and consistent backup of the Satellite, the customer uses the custom script to stop the Satellite services before the backup/snapshot starts.

Comment 5 JazPerSen 2019-12-20 09:23:19 UTC
For completeness, I wanted to add to this bz that this problem appears when the script "bpstart_notify" is executed. This particular script is an optional pre-backup-script that the Veritas Netbackup client will invoke before the file backup/copy operation starts. 

Typically, this script is used for bringing databases or applications offline, in order to get a consistent backup.


It seems like the Netbackup client invokes this script with something like this command:

   exec -c bpstart_notify

The result is that the script and the containing commands will not have the environment variable "HOME" set.



This behavior does pose a problem, when for example the command "/sbin/katello-service stop" from Satellite 6.4 _requires_ HOME to be set, and if it's not, it will show the error shown in the description above.


Please note: The "katello-service" from Satellite 6.3.5 does NOT require the HOME set, and works well with the Netbackup bpstart_notify script.

Comment 7 Anurag Patel 2020-06-01 14:23:15 UTC
Investigating further, it seems like in a few places we need to be able to resolve ~ to the correct home directory location. This is a handy shortcut. HOME environment variable may also be required by underlying commands that the maintain tool executes, which we may not have control over.

My question on this would be - under what conditions is it necessary to unset $HOME environment variable and run foreman-maintain?

Comment 8 Anand Agrawal 2020-06-02 09:59:18 UTC
(In reply to Anurag Patel from comment #7)
> Investigating further, it seems like in a few places we need to be able to
> resolve ~ to the correct home directory location. This is a handy shortcut.
> HOME environment variable may also be required by underlying commands that
> the maintain tool executes, which we may not have control over.
> 
> My question on this would be - under what conditions is it necessary to
> unset $HOME environment variable and run foreman-maintain?

Anurag, 

1. $HOME=/root is set by default in both the Satellite 6.3 and Satellite 6.4 and above

2. If we manually unset the $HOME in Satellite 6.3, katello-service still works.

3. If we manually unset the $HOME in Satellite 6.4 and above katello-service doesn't work.

This seems to be a regression bug.

I do not have exact condition why unset $HOME.

Regards,
Anand

Comment 9 JazPerSen 2020-06-02 10:33:49 UTC
(In reply to Anand Agrawal from comment #8)

> I do not have exact condition why unset $HOME.

Well, did you read comment #5 above?

The problem is also documented in support-case #02308710, in which you have contributed and then registered this BZ.

What else do you need?

Comment 10 Anand Agrawal 2020-06-02 11:07:37 UTC
JazPerSen,

Thank you for the update.

I have re-read comment #5 above. I will pass this information to our engineering team and wait for their response.

Regards,
Anand

Comment 11 Anurag Patel 2020-06-02 15:34:02 UTC
Hello JazPerSen,

>   exec -c bpstart_notify

The problem indeed seems to be Netbackup invoking bpstart_notify via `exec -c`, which executes bpstart_notify with an empty environment. While we'd like to be able to rely on environment variables to load a few things, I understand that its important to support unattended or non-interactive foreman-maintain runs in diverse scenarios. We'll modify the tool to guess load paths if $HOME is missing. 

Meanwhile, please set $HOME explicitly in bpstart and/or bpend scripts.

Comment 12 JazPerSen 2020-06-04 10:53:24 UTC
(In reply to Anurag Patel from comment #11)

> Meanwhile, please set $HOME explicitly in bpstart and/or bpend scripts.

We could not wait for you to fix this, so we already do.

Comment 13 Kavita 2020-06-05 08:12:26 UTC
Created redmine issue https://projects.theforeman.org/issues/30024 from this bug

Comment 14 Bryan Kearney 2020-07-17 12:04:03 UTC
Moving this bug to POST for triage into Satellite since the upstream issue https://projects.theforeman.org/issues/30024 has been resolved.

Comment 17 Jameer Pathan 2020-09-07 09:35:50 UTC
Verified

Verified with:
- Satellite 6.8.0 snap 14
- rubygem-foreman_maintain-0.6.9-1.el7sat.noarch

Test steps:
1. unset HOME
2. foreman-maintain service start/stop

Observation:
- foreman-maintain service works even if HOME environment variable is not unset.

[root@hpe-dl360egen8-01 ~]# unset HOME
[root@hpe-dl360egen8-01 root]# echo $HOME

[root@hpe-dl360egen8-01 root]# foreman-maintain service start
Running Start Services
================================================================================
Check if command is run as root user:                                 [OK]
--------------------------------------------------------------------------------
Start applicable services: 

Starting the following service(s):
rh-mongodb34-mongod, postgresql, qdrouterd, qpidd, rh-redis5-redis, squid, pulp_celerybeat, pulp_resource_manager, pulp_streamer, pulp_workers, smart_proxy_dynflow_core, tomcat, dynflow-sidekiq@orchestrator, foreman, httpd, puppetserver, dynflow-sidekiq@worker, dynflow-sidekiq@worker-hosts-queue, foreman-proxy
| All services started                                                [OK]      
--------------------------------------------------------------------------------

Comment 20 errata-xmlrpc 2020-10-27 12:38:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Satellite 6.8 Satellite Maintenance Release), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4365