Bug 624428 - httpd 2.2.16-1.fc13 (x86_64) does not start as a service (starts when invoked directly)
Summary: httpd 2.2.16-1.fc13 (x86_64) does not start as a service (starts when invoked...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: httpd
Version: 13
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-16 12:33 UTC by Patrick Sefton
Modified: 2011-06-28 14:34 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-28 14:34:23 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Patrick Sefton 2010-08-16 12:33:52 UTC
Description of problem: httpd does not start as a service (returns FAILED).  However, httpd will start when invoked directly from the command line.


Version-Release number of selected component (if applicable): Fedora 13
(recent upgrade from Fedora 12, httpd worked fine in Fedora 12)
httpd-2.2.16-1.fc13 (x86_64)


How reproducible: always fails to start as a service
always starts properly when invoked directly from command line


Steps to Reproduce:
1. # service httpd start
2. Starting httpd: [FAILED]
  

Actual results:
Starting httpd: [FAILED]


Expected results:
Starting httpd: [  OK  ]


Additional info:

# httpd
(works - httpd starts properly when invoked at cmd line)

# service httpd status
httpd (pid  22366) is running...

httpd worked fine for me on Fedora 12;  recently upgraded to Fedora 13 using preupgrade

Comment 1 Joe Orton 2010-08-16 12:59:32 UTC
This is probably an SELinux-related failure.  I suggest you 

  # touch /.autorelabel
  # reboot

to make sure everything is labelled correctly after your upgrade.  If it still fails, check your audit logs.

  # ausearch -ts today -x httpd

Comment 2 Patrick Sefton 2010-08-16 13:52:24 UTC
Thanks for the quick response.

I did the relabel, but that didn't fix it (same symptoms as above).  The audit logs don't show anything

 # ausearch -ts today -x httpd
<no matches>

However I noticed something else.  I'm using mod_ssl with the builtin terminal-based pass-phrase input (ie, I normally get a pass phrase request when I start httpd).

When I turn off mod_ssl, then httpd starts properly as a service.  That is,

 # mv /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.backup
 # service httpd start
Starting httpd:                                            [  OK  ]

and when I turn mod_ssl back on, httpd no-longer starts properly:

 # mv /etc/httpd/conf.d/ssl.conf.backup /etc/httpd/conf.d/ssl.conf
 # service httpd restart
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [FAILED]

Comment 3 Joe Orton 2010-08-16 20:49:14 UTC
Check the error log for details then, /var/log/httpd/error_log.

Comment 4 Patrick Sefton 2010-08-16 22:22:06 UTC
OK, well in the failure case I get:

/var/log/httpd/error_log:

[Tue Aug 17 08:05:57 2010] [notice] SELinux policy enabled; httpd running as con
text unconfined_u:system_r:httpd_t:s0
[Tue Aug 17 08:05:57 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin
/suexec)
[Tue Aug 17 08:05:57 2010] [notice] SSL FIPS mode disabled

and /var/log/httpd/ssl_error_log:

[Tue Aug 17 08:05:57 2010] [error] Init: Unable to read pass phrase [Hint: key i
ntroduced or changed before restart?]
[Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218529960 error:0D0680A8:a
sn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218640442 error:0D08303A:a
sn1 encoding routines:ASN1_TEMPLATE_NOEXP_D2I:nested asn1 error
[Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218529960 error:0D0680A8:a
sn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218595386 error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error
[Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 67710980 error:04093004:rsa routines:OLD_RSA_PRIV_DECODE:RSA lib
[Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218529960 error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag
[Tue Aug 17 08:05:57 2010] [error] SSL Library Error: 218595386 error:0D07803A:asn1 encoding routines:ASN1_ITEM_EX_D2I:nested asn1 error


and in the success case (ie, started directly from cmd line) I get:

/var/log/httpd/error_log:

[Tue Aug 17 08:06:06 2010] [notice] SELinux policy enabled; httpd running as context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[Tue Aug 17 08:06:06 2010] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Tue Aug 17 08:06:06 2010] [notice] SSL FIPS mode disabled
[Tue Aug 17 08:06:08 2010] [notice] Digest: generating secret for digest authentication ...
[Tue Aug 17 08:06:08 2010] [notice] Digest: done
[Tue Aug 17 08:06:08 2010] [notice] SSL FIPS mode disabled
[Tue Aug 17 08:06:08 2010] [notice] Apache/2.2.16 (Unix) DAV/2 PHP/5.3.2 mod_ssl/2.2.16 OpenSSL/1.0.0a-fips configured -- resuming normal operations

and /var/log/httpd/ssl_error_log:

[Tue Aug 17 08:06:08 2010] [warn] RSA server certificate CommonName (CN) `Server' does NOT match server name!?
[Tue Aug 17 08:06:08 2010] [warn] RSA server certificate CommonName (CN) `Server' does NOT match server name!?

Comment 5 Joe Orton 2010-08-17 16:02:56 UTC
The error message is surprising.  Have you configured an SSL cert with a private key which requires a passphrase to decrypt?

If so, does running "setsebool httpd_tty_comm=1" make a difference?

If not, I'd suspect that SELinux is causing the SSL cert/key to be unreadable by httpd.  SELinux is only activated when you start httpd from the init script, not directly.  But it's surprising that audit failures don't show if this is the case.

ls -lZ output on the certs/keys?  Please attach complete mod_ssl configuration (/etc/httpd/conf.d/ssl.conf)

Comment 6 Patrick Sefton 2010-08-17 23:16:43 UTC
Yes, I use mod_ssl with a private key with passphrase (ie, using the
SSLPassPhraseDialog builtin
directive in ssl.conf)

OK, running "setsebool httpd_tty_comm=1" fixes this for me.  I can now use "service httpd start" and it starts httpd (and prompts for the SSL password).

Many thanks.  Do you still want the mod_ssl config and keys/certs list?

Comment 7 Joe Orton 2010-09-17 15:43:21 UTC
I'm kind of surprised by this since I thought that httpd_tty_comm 
was still set by default.  Is it expected/desired that httpd_tty_comm
is unset by default, Dan?

In the past I had developed a separate program "htsslpass" which could
be allowed terminal access and was used by httpd by default to read the
from /dev/tty (effectively as a "proxy").   This can be resurrected
if it is deemed necessary to disallow httpd terminal access by default.

Comment 8 Daniel Walsh 2010-09-17 17:14:32 UTC
It was on in F12 and off in F13.  I will turn it back on in F14.

It is on in RHEL6.

Comment 9 Bug Zapper 2011-06-01 11:25:11 UTC
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 10 Bug Zapper 2011-06-28 14:34:23 UTC
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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