Bug 1440963
| Summary: | RFC: easier overriding of java.security file | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Paulo Andrade <pandrade> |
| Component: | java-1.7.0-openjdk | Assignee: | jiri vanek <jvanek> |
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE - Apps <qe-baseos-apps> |
| Severity: | medium | Docs Contact: | Vladimír Slávik <vslavik> |
| Priority: | medium | ||
| Version: | 6.8 | CC: | cww, dbhole, fred.kubli, jkurik, jvanek, lzachar, mkolaja, pandrade, thozza, vslavik, zzambers |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | No Doc Update | |
| Doc Text: |
undefined
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-06-19 05:23:45 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: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1374441, 1461138, 1503147, 1504312 | ||
|
Description
Paulo Andrade
2017-04-10 20:37:03 UTC
Jiri, is the non-propagation of change expected? Seems like a bug does it not? First - there are intentions to move all java config files to /etc/java/NVRA in jdk9 (it is hard to imagine this done in already existing jdks) With this done, it make sense to have the configurations switch-able by configurations. Still I'm a bit against. (In reply to Deepak Bhole from comment #2) > Jiri, is the non-propagation of change expected? Seems like a bug does it > not? The propagation reorter have in mind is tricky. There was recently bug, that the propagation does happen. Current state should be very correct - after update - as we keep java.security as config(norepalce) then after update, you have java.security.rpmnew and your changed one is still there. Lukas, can you please double check? Adding NEEDINFO for Lukas. Lukas, please see comment #5 Hello! (In reply to Paulo Andrade from comment #0) > > User would also to know about how will it be > handled in java 9. > > Reason of the RFC is that editing that file does > not provide a clean upgrade path, as the file is > not removed, and changes there are not propagated. > > The query is about clean update procedures on > several servers. Paulo, is this root cause stil valid? java.security should have already clear update path. If not, then it (theupdate path) will be fixed in 6.10, but no alterantives over this file are planned. Are you ok with this statement? If clean update path exists, is the bug considered as resolved? The issue is this:
1. customer has custom
/usr/lib/jvm/java-{openjdk,oracle}-1.7.0.XX.x86_64/jre/lib/security/java.security
2. when updating to a new rpm/build it ends with:
/usr/lib/jvm/java-{openjdk,oracle}-1.7.0.YY.x86_64/jre/lib/security/java.security
and the custom java.security still in the -XX directory.
If the current state is to move the custom
/usr/lib/jvm/java-{openjdk,oracle}-1.7.0.XX.x86_64/jre/lib/security/java.security
to
/usr/lib/jvm/java-{openjdk,oracle}-1.7.0.YY.x86_64/jre/lib/security/java.security
on upgrade, then the initial report is corrected.
Yes, that is how it is supposed to work, and should get even a bit more better. Based on this, Lukas, may you ack? Lets have this 100% covered i erratum. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:1924 |