Bug 1021954
| Summary: | Apache HTTP Server and mod_auth_kerb.so and auth_kerb.conf [RHEL] [SOLARIS] | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise Application Platform 6 | Reporter: | Michal Karm Babacek <mbabacek> |
| Component: | Apache Server (httpd) and Connectors | Assignee: | Mladen Turk <mturk> |
| Status: | CLOSED NOTABUG | QA Contact: | Michal Karm Babacek <mbabacek> |
| Severity: | medium | Docs Contact: | Russell Dickenson <rdickens> |
| Priority: | medium | ||
| Version: | 6.2.0 | Flags: | mbabacek:
needinfo+
|
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-10-22 12:55:10 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: | |||
I would liek to bring this BZilla to your attention: * [BZ 900673] - (JBEWS-310) EWS 2.0 ER4 auth_kerb.conf, nss.conf sym links - can't start apache The change was made according to https://bugzilla.redhat.com/show_bug.cgi?id=1014510 Please reassign the issue to Weinan cause he's maintaining RHEL part. I presume that's a bug in spec file. BTW, think this is duplicate of bz1014510 (seems there are still inconsistencies lef) I talked to Jan Stefl and it's getting clearer now: * Why this change happened? Where is the change request/3ack for it? - OK, Jan Stefl requested it in [BZ 1014510] * Why wasn't it communicated to the documentation team? - Glitch in the MATRIX. I'll take over and create a BZilla. * And most importantly: Where is our customer supposed to download mod_auth_kerb from? RPM via RHN? - OK, it's RPM. Regarding the inconsistency between Solaris conf and RHEL conf.d: I assume the ultimate goal is alignment with EWS, and because EWS distribution presents it in the same way, I guess this is OK. Regarding RPMs: In EWS, there is no dependency of httpd package on mod_auth_kerb, yet, mod_auth_kerb is in yum groupinstall. IN EAP, there is no groupinstall for natives, both httpd and other natives are optional packages within EAP context. Let's leave it this way. Conclusion: It's cool this way. Do not take any action, do not add any mod_auth_kerb dependencies to any EAP natives RPMs. I'll just make sure it's documented. THX |
Hmm, there are these symlinks in RHEL zips in EAP 6.2.0.ER6 Apache HTTP Server distribution: * jboss-ews-2.0/httpd/modules/mod_auth_kerb.so -> /usr/lib64/httpd/modules/mod_auth_kerb.so * jboss-ews-2.0/httpd/conf.d/auth_kerb.conf -> /etc/httpd/conf.d/auth_kerb.conf These hadn't been present in EAP 6.2.0.ER3 build and appeared no later than in EAP 6.2.0.ER4 build. This is not wrong per se, yet, it is noteworthy that this setup actually prevents customer from starting the httpd instance unless there is mod_auth_kerb installed in the system. This is an example from a box where no mod_auth_kerb is installed: httpd: Syntax error on line 221 of /tmp/hudson/httpd/conf/httpd.conf: Could not open configuration file /tmp/hudson/httpd/conf.d/auth_kerb.conf: No such file or directory So, some questions arise: * Why this change happened? Where is the change request/3ack for it? * Why wasn't it communicated to the documentation team? * And most importantly: Where is our customer supposed to download mod_auth_kerb from? RPM via RHN? Last but not least: Solaris mod_auth_kerb.so and auth_kerb.conf appeared in Solaris zip distribution as well (hadn't been there in EAP 6.2.0 ER3). Unlike in RHEL, these are actual files, not symlinks, so user is not forced to install anything. It is noteworthy that in RHEL zips, auth_kerb.conf appears in conf.d directory and as such is immediately included by httpd.conf, whereas in Solaris zips, auth_kerb.conf appears in conf directory and therefore is being ignored unless user explicitly copies it to conf.d. I find these inconsistencies rather bewildering.