Re: Update of tomcat6 - JVM_TMP issue + Dealing with Debian-Ubuntu delta
Niels Thykier wrote:
> As some of you know (and as the subject suggested) I am working on an
> update of tomcat6 package. My main interest was to add some OSGi to some
> jar files in libservlet2.5-java; however, while I was at it I looked if
> I could fix a couple of other bugs. This is when I noticed Thierry was
> working on a separate upload in Ubuntu.
I'm not working on it right now... though I certainly plan to do an
update to fix the bugs opened in Ubuntu before the end of the Lucid
development window. If they can be fixed by syncing or merging the
Debian package, that's even better.
> Since eclipse depends on these OSGi changes; I need them to propagate to
> Ubuntu as well and figured I might as well try to please the developers
> and users in both Debian and Ubuntu, while I was at it. However - I ran
> into a couple of things I would like some more experienced people to
> look at (see below).
>
> I hope I can convince you, Thierry, to help us by committing/sending
> your coming changes to our tomcat6 package repository/mailing them to
> (e.g.) me and perhaps review the part below as well (particularly the
> JVM_TMP issue).
I can commit to debian-java SVN so it's definitely better to commit
"obvious" patches directly there and sync/merge the Ubuntu version with
the new Debian one. The Ubuntu-Debian delta only makes sense for patches
that are, for some reason, not acceptable in one distribution or the other.
> JVM_TMP issue
> =============
> In Debian JVM_TMP was set to /tmp/tomcat6-tmp in the init script. I
> suspect this is also the case in Ubuntu (at least nothing suggests that
> it has been changed).
>
> I changed this to /var/cache/$NAME (defaults to /var/cache/tomcat6
> [expanded before reading any config files])[3]. However I noticed that
> tomcat6's postrm script already deletes /var/cache/tomcat6; so should I
> change it to another value (and if so - which)?
>
> I also intend to change the default JVM_TMP value in
> debian/tomcat6.default (I did not notice it before my commit).
Small explanation here... since I was the author of that tmp thing. For
(more) FHS compliance /var/lib/tomcat6/work (the tomcat6 compilation
cache directory) is a link to /var/cache/tomcat6. That's what this
directory is currently used for. It is also where the catalina.policy
combined file is being created when the init script starts. So it's
really used as a cache. This is different from the JVM temporary
directory (where temp files will be created by default), which should
definitely be separate (otherwise there is risk of conflict in files
being created there).
I still think /tmp is the right location for JVM temp files, since they
aren't cache files and should be cleaned up at system restart. If you
don't want them to be in /tmp, you will have to use a specific directory
(separate from /var/cache/tomcat6) and make sure it's cleaned up
periodically. You mention a security problem as the main reason to
change that, could you elaborate ? This code looks secure to me.
> (Build-)Depends - The remaining delta
> =====================================
>
> A comment in debian/tomcat6.default (and [2]) suggests that java5 could
> actually be used to run tomcat6; though neither Debian nor Ubuntu uses
> an alternative on java5 in their Depends. I presume this is because of
> gcj failing to run tomcat properly in the past (e.g. LP: #251004) and
> that gcj does not provide java6-runtime(-headless).
Yes. All java6-runtime-headless providers could be used to run tomcat,
while /some/ java5-runtime-headless providers (gcj) used to fail in some
features (like security manager).
> Comparing the 6.0.20-2ubuntu2 with the current Debian the only
> differences I see (besides the Debian changes in -3 to -7) is that
> Ubuntu uses default-{jdk,jre-headless} in (Build-)Depends. [Thierry: can
> you please confirm this?]
Yes.
> I intended to adopt this in Debian as well. I am aware that
> default-jre(-headless) is gcj on some archs, but
> java6-runtime(-headless) is provided by default-jre(-headless) which
> means that gcj has always been a valid alternative on those (and only
> those) archs in Debian.
Yes.
> ** Ubuntu **
> Bugs from Ubuntu I believe will be or could be easily fixed and that I
> am considering to get into the next Debian upload.
>
> LP: #375493: tomcat6 needs debug start mode with jpda
> As promised Ludovic Claude added the change stated in comment#4. Thierry
> - are you satisfied with the solution? If so - this bug can be closed
> with a sync from Debian (though it is not mention in the changelog as a
> bug closing change).
Sure, sounds good.
> LP: #475457: Adding JSVC_CLASSPATH to /etc/default/tomcat6
> I understand this is being working on and I see no reason not to include
> the solution in Debian as well.
If everyone agrees, I can commit that change to Debian SVN rather than
Ubuntu and sync the resulting debian package (when published) in Ubuntu.
If anyone wants to have a stab at it before I can commit time to do
that, please be my guest.
> LP: #440685: Make it clearer that JAVA_OPTS is about JSVC options
> Assuming this is just debian/tomcat6.default that needs the update; this
> seems trivial to fix and I do not mind doing it.
Yes, it's just about making the comment a little more obvious to avoid
further bugs like this one.
> LP: #410379: Tomcat security configuration error prevents proper ...
> As I understand it; the solution appears to be granting permission to do
> setContextClassLoader and openjdk6 is only unaffected because it lacks
> some implementation on the SecurityManager area. However I am unsure
> which policy file to add it to.
I just commented on the bug on the right way to fix this. Note that this
is only needed to support Sun's JVM at the moment. However, it shouldn't
hurt openJDK and future releases of OpenJDK might be affected when they
catch up, so it sounds like a reasonable fix.
--
Thierry Carrez
Ubuntu server team
Reply to: