Bug 1474514

Summary:	Yum updates of httpd package break links to run modules and logs
Product:	Red Hat Enterprise Linux 6	Reporter:	Michael Kushnir <michael.kushnir>
Component:	httpd	Assignee:	Luboš Uhliarik <luhliari>
Status:	CLOSED WONTFIX	QA Contact:	BaseOS QE - Apps <qe-baseos-apps>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.10	CC:	bnater, jorton, luhliari, michael.kushnir
Target Milestone:	rc
Target Release:	---
Hardware:	All
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-12-06 10:36:51 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 Michael Kushnir 2017-07-24 20:04:20 UTC

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 11:55:42 UTC

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 10:36:51 UTC

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/

Comment 4 Red Hat Bugzilla 2023-09-14 04:01:33 UTC

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days