apache - could not bind to address, but port 80 is not in use

[dh1760]

CentOS 6.3: This is a new one on me. I'm replacing the default Apache (2.2.15) with 2.2.25. Build and install went fine, as it has on a dozen other machines.

I stop the default httpd and confirm nothing is active on port 80:

# netstat -lnp |grep u80
(nothing)

# fuser 80/tcp
(nothing)

# pgrep httpd
(nothing)

I start the new apache, and get:

(98)Address already in use: make_sock: could not bind to address 172.31.1.51:80
no listening sockets available, shutting down
Unable to open logs

So, I restart the default apache and confirm netstat, fuser, pgrep are telling the truth:

# netstat -lnp | grep :80
tcp 0 0 172.31.1.51:80 0.0.0.0:* LISTEN 14369/httpd

# fuser 80/tcp
80/tcp: 14369 14378 14379 14380 14381 14382 14383 14384 14385 14386

# pgrep httpd
14369
(...)

I retry the above several times, always with the same result. It's like the new apache is being faked into thinking something is already listening on port 80.

Any ideas what might be going on? I'm banging my head against the wall on this one.

[dh1760]

Fixed it by commenting out the Listen 80 in httpd.conf. Strange, this was not a problem on CentOS 6.2, but seems to be an issue in CentOS 6.3.

[TrevorH]

We do not support nor recommend replacing the Apache httpd version. CentOS ships a perfectly adequate httpd and the upstream vendor uses their [url=https://access.redhat.com/site/pages/485813]backpoprting policy[/url] to make sure that it is secure.

[dh1760]

Just to put some perspective on this philosophy: under the vast majority of circumstances I would absolutely stick with the vendor-provided version of any core service. The specific binaries have been widely implemented, which provides a high level of confidence in the installation's integrity. And, it allows an admin to devote the time spent building new versions on other pursuits.

However, as others have pointed out, there are organizations (both governmental and public corporation) which must attain certain certifications in order to appease either government oversight agencies or corporate risk assessments. The third party analysts who perform these audits will not provide certification unless the resolutions to their audit findings are fully implemented. In this case, the finding mandated that a resolution for CVE-2012-3499 be implemented. This CVE is not covered by the Redhat-issued patches to 2.2.15. The auditor indicated we could resolve the issue by either updating to 2.2.25 or moving to 2.4. Either resolution required replacing 2.2.15.

[TrevorH]

Wrong!

[code]
# rpm -q --changelog httpd | grep CVE-2012-3499
- add security fixes for CVE-2012-3499, CVE-2012-4558 (#915883, #91588
[/code]

Already fixed in the RH/CentOS shipped version.

[dh1760]

Good to know.

# yum check-update --cve=CVE-2012-3499

returned 'CVE "CVE-2012-3499" not found applicable for this system'. Based on that, I decided 2.2.25 was needed to resolve the issue.

Thanks very much for the correction!

[TrevorH]

CentOS cannot ship the security metadata required for that yum functionality to work (for reasons that I don't fully understand but to do with copyright I believe). That means the yum-plugin-security is a no-op on CentOS. Check the --changelog instead.

[AlanBartlett]

[quote]
The third party analysts who perform these audits . . .
[/quote]
Those typical, clueless, numpties just misinform and spread FUD. :-x

Anything to make money. :roll:

[lluberts]

We do not support nor recommend replacing the Apache httpd version. CentOS ships a perfectly adequate httpd and the upstream vendor uses their backpoprting policy to make sure that it is secure.

Sorry, buddy, this is no longer good enough. Certification agencies are looking for the correct version.

[TrevorH]

Of course it is but you have to tell them in such a way that they believe what you say. Asking them which CVE items they are interested in and then providing them with the output of `rpm -q --changelog httpd | grep CVE-yyyy-xxxx` to prove that it is indeed fixed is the correct way to do this. You can also point them to the CVE page on redhat.com.

If any "certification agency" refuses to accept this as proof then you should ask them to indemnify you against the costs of running unsupported software.