Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 1336365 - Satellite 6.2 - httpd fails to start after being updated
Satellite 6.2 - httpd fails to start after being updated
Status: CLOSED ERRATA
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Upgrades (Show other bugs)
6.2.0
All Linux
high Severity high (vote)
: 6.2.4
: Unused
Assigned To: Chris Roberts
Lukas Pramuk
http://projects.theforeman.org/issues...
: Reopened, Triaged
: 1339298 1340310 1367188 (view as bug list)
Depends On:
Blocks: GSS_Sat6Beta_Tracker/GSS_Sat6_Tracker
  Show dependency treegraph
 
Reported: 2016-05-16 05:37 EDT by Julio Entrena Perez
Modified: 2017-09-12 10:57 EDT (History)
30 users (show)

See Also:
Fixed In Version: katello-installer-base-3.0.0.61-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-10 11:00:52 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)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 2362111 None None None 2016-06-13 05:16 EDT
Red Hat Knowledge Base (Solution) 2751421 None None None 2016-11-09 16:09 EST
Foreman Issue Tracker 16972 None None None 2016-10-17 11:19 EDT
Red Hat Product Errata RHBA-2016:1885 normal SHIPPED_LIVE Satellite 6.2.2 bug fix update 2016-09-14 20:57:56 EDT

  None (edit)
Description Julio Entrena Perez 2016-05-16 05:37:47 EDT
Description of problem:
Running "yum update" on a Satellite 6.2 beta installed on RHEL 7 results in package httpd being updated from 2.4.6-40.el7 to 2.4.6-40.el7_2.1.
This causes previously non existent file /etc/httpd/conf.d/ssl.conf to be created.
Running "foreman-installer --scenario katello --upgrade" does not remove /etc/httpd/conf.d/ssl.conf and httpd fails to start.
"Listen 443" in /etc/httpd/conf.d/ssl.conf conflicts with "Listen 443" on /etc/httpd/conf/ports.conf .

Version-Release number of selected component (if applicable):
foreman-installer-1.11.0.3-1.el7sat

How reproducible:
Always

Steps to Reproduce:
1. Run "yum update" on the Satellite and have httpd package updated.
2. Running "foreman-installer --scenario katello --upgrade"
3.

Actual results:
httpd fails to start:

# foreman-installer --scenario katello --upgrade
Upgrading...
Upgrade Step: stop_services...
Upgrade Step: start_databases...
Upgrade Step: migrate_pulp...
Upgrade Step: start_httpd...
Upgrade step start_httpd failed. Check logs for more information.

# tail /var/log/httpd/error_log
[Mon May 16 09:26:03.951254 2016] [core:crit] [pid 46664] (22)Invalid argument: AH00069: make_sock: for address [::]:443, apr_socket_opt_set: (IPV6_V6ONLY)
(98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
(98)Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443
[Mon May 16 09:26:03.951314 2016] [mpm_prefork:alert] [pid 46664] no listening sockets available, shutting down
[Mon May 16 09:26:03.951317 2016] [:emerg] [pid 46664] AH00019: Unable to open logs, exiting
/usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:105:in `initialize': Connection refused - connect(2) (Errno::ECONNREFUSED)
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:105:in `new'
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:105:in `connect'
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:86:in `socket'
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:90:in `head_request'
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:145:in `<main>'
/usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:105:in `initialize': Connection refused - connect(2) (Errno::ECONNREFUSED)
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:105:in `new'
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:105:in `connect'
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:112:in `connect'
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:86:in `socket'
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:90:in `head_request'
        from /usr/share/gems/gems/passenger-4.0.18/helper-scripts/prespawn:145:in `<main>'

Duplicated "Listen 443" directives as a result of httpd package provided file /etc/httpd/conf.d/ssl.conf not being cleared by "foreman-installer --scenario katello --upgrade":

# grep -r "Listen 443" /etc/httpd
/etc/httpd/conf/ports.conf:Listen 443
/etc/httpd/conf.d/ssl.conf:Listen 443 https

Expected results:
"foreman-installer --scenario katello --upgrade" resolves the conflict and httpd starts successfully.

Additional info:
Comment 1 Tomer Brisker 2016-05-25 04:58:17 EDT
*** Bug 1339298 has been marked as a duplicate of this bug. ***
Comment 2 Tomer Brisker 2016-05-25 05:05:10 EDT
To reproduce if you installed satellite after mod_ssl was updated, run:
mv /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.katello && yum reinstall mod_ssl
This is also present in Satellite 6.1
Comment 4 Tomer Brisker 2016-05-30 05:13:20 EDT
*** Bug 1340310 has been marked as a duplicate of this bug. ***
Comment 10 Alexander Love 2016-06-21 14:41:18 EDT
For me I was getting "pgrade step start_httpd failed. Check logs for more information" and "httpd[8068]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:443"

I edited the /etc/httpd/conf/ports.conf commited out "Listen 443"

Ran a systemctl restart httpd and checked the status with systemctl status httpd to ensure it was running.

after this I reran "foreman-installer --scenario katello --upgrade"

The installed then ran correctly and I checked /etc/httpd/conf/ports.conf file and the "Listen 443" was no longer commited out.

Hope this works for you.
Comment 12 Chris Roberts 2016-07-25 16:34:56 EDT
Hi Alexander,

We use the ports.conf for the 443 directive and we filebucket the ssl.conf. I am working so instead of removing the ssl.conf we make a blank file so when mod_ssl gets updated it will not replace the empty file.

Since we use ports.conf the file got corrected with a puppet run when you ran the installer.
Comment 13 Chris Roberts 2016-07-25 16:36:25 EDT
non existent*
Comment 14 jcallaha 2016-09-12 14:05:45 EDT
Verified in Satellite 6.2.2 Snap 1.1

Followed instructions in Comment #2. Install completed correctly and httpd had no issues post-install.

[root@ibm-x3550m3-07 yum.repos.d]# grep -r "Listen 443" /etc/httpd
/etc/httpd/conf/ports.conf:Listen 443
Comment 16 Chris Roberts 2016-09-14 13:44:22 EDT
*** Bug 1367188 has been marked as a duplicate of this bug. ***
Comment 17 errata-xmlrpc 2016-09-14 17:00:43 EDT
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, 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-2016:1885
Comment 18 Lukas Pramuk 2016-10-11 06:34:06 EDT
By a fleeting glance at fix I'm pretty sure that bug is not fixed and persists ... thus reopening.
Comment 19 Lukas Pramuk 2016-10-11 06:46:18 EDT
1. To check whether is your Satellite vulnerable against any upcoming mod_ssl package update run following command,i.e to check that it's not fixed: 

# ll /etc/httpd/conf.d/ssl.conf
ls: cannot access /etc/httpd/conf.d/ssl.conf: No such file or directory

No such file or dir? => Is vulnerable!


2. To manually prevent this to happen run following command:

# cat <<< '' > /etc/httpd/conf.d/ssl.conf
(as shown in my duplicate https://bugzilla.redhat.com/show_bug.cgi?id=1367188#c3)

That's it. Now you're safe.


3. We still need to fix it that way in Satellite's installation.
Post-deleting or pre-deleting the file doesn't help at all.
The file has to be empty. That's it.
Comment 23 Bryan Kearney 2016-10-11 08:15:07 EDT
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/15380 has been resolved.
Comment 25 Bryan Kearney 2016-10-11 10:15:26 EDT
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/15380 has been resolved.
Comment 33 Lukas Pramuk 2016-11-01 11:46:43 EDT
VERIFIED.

@satellite-6.2.4-1.0.el7sat.noarch
katello-installer-base-3.0.0.63-2.el7sat.noarch

with this manual reproducer:

1. Install (or upgrade) Satellite/Capsule
# satellite-installer (--upgrade)

2. Verify that mod_ssl configuration file ssl.conf is present
$ cat /etc/httpd/conf.d/ssl.conf
# This file is managed by the foreman-installer, do not alter.

>>> ssl.conf is present, so it wont get re-created by mod_ssl package updates with undesirable content ofc
Comment 35 gabicr 2016-11-07 01:28:20 EST
Hello!

Just upgraded my 6.2.3 Sat OS from 7.2 to 7.3....of course httpd included and the bug hit me! So i just mv ssl.conf and cat <<< '' > /etc/httpd/conf.d/ssl.conf.
Comment 36 Fred van Zwieten 2016-11-07 04:25:53 EST
Same happened to me as #35. I don't know what the content of the file sss.conf was before doing the upgrade, but I was on 6.2.3 doing a normal sat upgrade procedure.
Comment 42 Peter Vreman 2016-11-08 10:42:38 EST
Same for me. Doing only an OS upgrade of 7.2 to 7.3 with the standard 'yum update' and reboot
Comment 44 Jason Powell 2016-11-09 17:10:55 EST
Confirming the bug exists in our environment as well. Just updated satellite server from 7.2 -> 7.3, mod_ssl was updated, and httpd would not start because of a conflicting Listen directive on port 443 (Address already in use: AH00072: make_sock: could not bind to address 0.0.0.0:443) and removing /etc/httpd/conf.d/ssl.conf allowed httpd to start normally.
Comment 45 Bryan Kearney 2016-11-10 11:00:52 EST
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, 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-2016:2699
Comment 46 David Rock 2016-11-10 11:56:38 EST
I don't think you have the correct errata referenced.  This BZ is not listed in RHBA-2016:2699.  Either it wasn't fixed, or it's in a different errata.
Comment 48 Ryan Sawhill 2016-11-10 12:04:59 EST
(In reply to David Rock from comment #46)
> I don't think you have the correct errata referenced.  This BZ is not listed
> in RHBA-2016:2699.  Either it wasn't fixed, or it's in a different errata.

... Or they mistakenly omitted it. I'm seeking confirmation about the oddity, David.
Comment 49 David Rock 2016-11-10 12:08:47 EST
(In reply to Ryan Sawhill from comment #48)
> ... Or they mistakenly omitted it. I'm seeking confirmation about the
> oddity, David.

true.. :-)

FWIW, I'm also curious how it was fixed.  Does satellite not care about the mod_ssl ssl.conf file anymore?
Comment 50 Bryan Kearney 2016-11-10 12:30:13 EST
Per comment 33, we are adding an empty ssl.conf file at install so that it will not be overwritten by the http package. See http://projects.theforeman.org/issues/16972.
Comment 51 Ryan Sawhill 2016-11-10 12:40:12 EST
So (In reply to David Rock from comment #46)
> I don't think you have the correct errata referenced.  This BZ is not listed
> in RHBA-2016:2699.  Either it wasn't fixed, or it's in a different errata.

So to recap David: according to Bryan, they mistakenly omitted mention of this BZ in the RHBA announced today.
Comment 52 David Rock 2016-11-10 13:17:23 EST
Sounds good on both counts.  I've verified the ssl.conf looks as advertised at this end. 

Thanks! :-)
Comment 53 Peter Vreman 2016-11-11 05:33:22 EST
As a user i was also suprised when my case got closed. I checked also after upgrading to 6.2.4 and confirm that ssl.conf is now managed by the satellite installer

$ cat /etc/httpd/conf.d/ssl.conf
# This file is managed by the foreman-installer, do not alter.

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