[Bug 1370262] New: catalina.out is no longer in use, but still gets rotated
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1370262
Bug ID: 1370262
Summary: catalina.out is no longer in use, but still gets
rotated
Product: Fedora
Version: rawhide
Component: tomcat
Assignee: ivan.afonichev(a)gmail.com
Reporter: csutherl(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: alee(a)redhat.com, csutherl(a)redhat.com,
ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com, me(a)coolsvap.net,
tomcat-qe(a)redhat.com, trick(a)vanstaveren.us
Depends On: 1370261
+++ This bug was initially created as a clone of Bug #1370261 +++
Description of problem:
After the update from systemv to systemd for tomcat the service no longer
writes console output to catalina.out. Instead, all of the console output is
just written to stdout, which is received by the journal (and can be reviewed
with `journalctl -u tomcat`. This means that nothing is redirected to
catalina.out like systemv did, and therefore it's always empty. Additionally,
there is a logrotate script included in the package that rotates the empty file
weekly.
Version-Release number of selected component (if applicable):
tomcat-7.0.69-10.el7.noarch
How reproducible:
Always.
Steps to Reproduce:
1. `yum install tomcat` to get the package installed (note that it installs an
empty catalina.out file in /var/log/tomcat)
2. `service tomcat start && service tomcat stop` to get some logging
3. Observe that /var/log/tomcat/catalina.out remains empty while another file
(catalina.$(date).log) is populated with the logging. You can also see the
stdout by using `journalctl -u tomcat`.
Actual results:
The tomcat processes stdout is no longer redirected to catalina.out, but
instead received by the journal.
Expected results:
This is expected behavior, but the bug is being filed to cleanup the
catalina.out file and logrotate script that rotates it.
Additional info:
The file and script can be deleted because tomcat handles it's on file rotation
by default.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=1370261
[Bug 1370261] catalina.out is no longer in use, but still gets rotated
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 5 months
[Bug 1317805] New: %jpackage_script is not compatible with XDG specification
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1317805
Bug ID: 1317805
Summary: %jpackage_script is not compatible with XDG
specification
Product: Fedora
Version: rawhide
Component: jpackage-utils
Assignee: extras-orphan(a)fedoraproject.org
Reporter: jvanek(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: akurtako(a)redhat.com, extras-orphan(a)fedoraproject.org,
java-sig-commits(a)lists.fedoraproject.org,
jerboaa(a)gmail.com, msrb(a)redhat.com,
sochotni(a)redhat.com
the %jpackage_script generates also:
# Source user prefs
if [ -f $HOME/.LauncherName ] ; then
. $HOME/.LauncherName
fi
Which looks really bad. $XDG_* should be followed.
So the correct snippet should be (not tested):
XCFG=$XDG_CONFIG_DIR
if [ "xXCFG" == "x" ] ; then
XCFG=$HOME/.config/.LauncherName
else
XCFG=$XCFG/.LauncherName
fi
if [ -f $XCFG ] ; then
. $XCFG
fi
%jpackage_script is an old macro. It was created before XDG spec
existed. It would be nice to use standardized location for config files,
but I can't just move config file location as it would break user config
files.
Perhaps a second XDG-compliant location could be added next to existing
non-standard config location. Or we could introduce a totally new macro,
which would solve this and many of other issues. New macro would allow
to migrate packages gradually.
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 5 months
[Bug 1347835] New: The security manager doesn't work correctly ( JSPs cannot be compiled)
by Red Hat Bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=1347835
Bug ID: 1347835
Summary: The security manager doesn't work correctly (JSPs
cannot be compiled)
Product: Fedora
Version: 23
Component: tomcat
Assignee: ivan.afonichev(a)gmail.com
Reporter: csutherl(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: alee(a)redhat.com, csutherl(a)redhat.com,
ivan.afonichev(a)gmail.com,
java-sig-commits(a)lists.fedoraproject.org,
krzysztof.daniel(a)gmail.com, me(a)coolsvap.net,
tomcat-qe(a)redhat.com, trick(a)vanstaveren.us
Depends On: 1347774, 927930
Blocks: 1347142, 1347144, 1347146, 1347778
+++ This bug was initially created as a clone of Bug #1347774 +++
Description of problem:
When using the security manager for the tomcat service, JSPs are inaccessible
(they won't compile) because of access permissions.
+++
HTTP Status 500 - access denied ("java.lang.RuntimePermission"
"accessClassInPackage.org.apache.jasper")
type Exception report
message access denied ("java.lang.RuntimePermission"
"accessClassInPackage.org.apache.jasper")
description The server encountered an internal error that prevented it from
fulfilling this request.
exception
java.security.AccessControlException: access denied
("java.lang.RuntimePermission" "accessClassInPackage.org.apache.jasper")
java.security.AccessControlContext.checkPermission(AccessControlContext.java:474)
java.security.AccessController.checkPermission(AccessController.java:685)
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1525)
sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305)
java.lang.ClassLoader.loadClass(ClassLoader.java:412)
java.lang.ClassLoader.loadClass(ClassLoader.java:358)
org.apache.jasper.servlet.JspServletWrapper.<init>(JspServletWrapper.java:120)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:382)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:606)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
java.security.AccessController.doPrivileged(Native Method)
javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:169)
java.security.AccessController.doPrivileged(Native Method)
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
java.lang.reflect.Method.invoke(Method.java:606)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:277)
org.apache.catalina.security.SecurityUtil$1.run(SecurityUtil.java:274)
java.security.AccessController.doPrivileged(Native Method)
javax.security.auth.Subject.doAsPrivileged(Subject.java:536)
org.apache.catalina.security.SecurityUtil.execute(SecurityUtil.java:309)
org.apache.catalina.security.SecurityUtil.doAsPrivilege(SecurityUtil.java:249)
+++
Version-Release number of selected component (if applicable):
tomcat-8.0.32-5.fc23.noarch
How reproducible:
Every time :(
Steps to Reproduce:
1. yum install tomcat
2. echo "SECURITY_MANAGER=\"true\"" >> /etc/sysconfig/tomcat
3. cp reproducer.tar /usr/share/tomcat/webapps/
4. service tomcat start
5. curl -is http://localhost:8080/reproducer/
Actual results:
JSP compilation fails and an error is observed
Expected results:
JSP compiles and displays correctly.
Additional info:
It looks like the java policy in use (catalina.policy) doesn't allow for use of
jars from /usr/share/java
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=927930
[Bug 927930] java.security.AccessControlException: access denied on tomcat6
rpm running with security manager
https://bugzilla.redhat.com/show_bug.cgi?id=1347774
[Bug 1347774] The security manager doesn't work correctly (JSPs cannot be
compiled)
https://bugzilla.redhat.com/show_bug.cgi?id=1347778
[Bug 1347778] The security manager doesn't work correctly
--
You are receiving this mail because:
You are on the CC list for the bug.
7 years, 6 months