Bug 1474514 - Yum updates of httpd package break links to run modules and logs [NEEDINFO]
Yum updates of httpd package break links to run modules and logs
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: httpd (Show other bugs)
6.10
All Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Luboš Uhliarik
BaseOS QE - Apps
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-24 16:04 EDT by Michael Kushnir
Modified: 2017-12-06 05:36 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-12-06 05:36:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jorton: needinfo? (michael.kushnir)


Attachments (Terms of Use)

  None (edit)
Description Michael Kushnir 2017-07-24 16:04:20 EDT
Description of problem:

When yum updates the httpd package, links (in /etc/httpd) for run, modules, and logs are reset to:

../../var/run/httpd
../../usr/lib64/httpd/modules
../../var/run/httpd

It generally seems foolish to use relative paths to point to critical system path locations such as logs and modules. For example, we have moved /etc/httpd to shared storage, so the ../ reference is constantly broken. 

We replace these links manually to point to the proper respective absolute path for these components:

/var/run/httpd
/usr/lib64/httpd/modules
/var/run/httpd

But, each update to the httpd package overwrites our links with the default, and again, foolish relative ../../ variants. 


How reproducible:

Very reproducable


Steps to Reproduce:
1. Install httpd
2. Change links for run, logs, and modules
3. Update httpd
4. See links reset to original relative paths 


Expected results:

Yum updates should not be overwriting user changed configuration links silently.
Comment 2 Joe Orton 2017-10-09 07:55:42 EDT
You're right that these symlinks are immutable and hence shouldn't be in /etc.  I don't recall why they needed to be relative rather than absolute.

Probably the best way we could resolve this would be to move the default ServerRoot to /usr/lib/httpd and have 

/usr/lib/httpd/conf -> /etc/httpd/conf (and conf.d, conf.modules.d)
/usr/lib/httpd/logs -> /var/log/httpd
/usr/lib/httpd/modules -> /usr/lib64/httpd/modules
/usr/lib/httpd/logs -> /var/log/httpd

symlinks in place.

It would be useful to understand your use case better - when you say "we have moved /etc/httpd to shared storage" you mean you replaced /etc/httpd itself with a symlink, or something else?

That said, we don't plan to change the way this works at this point in the RHEL6 production lifecycle.
Comment 3 Jan Kurik 2017-12-06 05:36:51 EST
Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/

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