You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Aryeh Friedman <ar...@gmail.com> on 2024/01/10 22:48:37 UTC
Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
After upgrading the machine (brand new VM) from FreeBSD 12.X to
14.0-RELEASE, OpenJDK 8 to OpenJdk 21 and Tomcat 9.0.35 to 9.0.84
(copied the existing server.xml over) I am having problems with a
servlet that has worked in the past that uploaded images from one app
(which is re-installed on each version thus no perm files in the web
app) to an other (to give persistence).... i.e.
https://machine/specMed/ to https://macine/images/ and the existing
images are shown as expected but the servlet silently fails (no errors
to browser, catalina.out or anywhere else I can find) and I was
careful to make sure the permissions where identical.... ideas?
Some troubleshooting I have tried on our development machine (same
versions as above) it seems to work but not in production (the
primary/"only" difference between the two I can find is production is
https and development is http but the cert from comodo covers the
entire machine [no subdomains or aliases in server.xml] and is
multidomain). In both cases I set
/usr/local/apache-tomcat-9.0/images to be 777 permissions and owned by
www:www (same uids/gids on both the new and old production machines).
Note both production and test are brand new VM's never used for
anything but these apps.
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Aryeh,
On 1/11/24 15:07, Aryeh Friedman wrote:
> TL;DR (see inline for details):
> Problem found and worked around (root cause still unknown but likely a
> bug in OpenJDK 21's standard lib [see below])
>
> On Thu, Jan 11, 2024 at 8:43 AM Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>>
>> Aryeh,
>>
>> On 1/10/24 17:48, Aryeh Friedman wrote:
>>> After upgrading the machine (brand new VM) from FreeBSD 12.X to
>>> 14.0-RELEASE, OpenJDK 8 to OpenJdk 21 and Tomcat 9.0.35 to 9.0.84
>>> (copied the existing server.xml over) I am having problems with a
>>> servlet that has worked in the past that uploaded images from one app
>>> (which is re-installed on each version thus no perm files in the web
>>> app) to an other (to give persistence).... i.e.
>>> https://machine/specMed/ to https://macine/images/ and the existing
>>> images are shown as expected but the servlet silently fails (no errors
>>> to browser, catalina.out or anywhere else I can find) and I was
>>> careful to make sure the permissions where identical.... ideas?
>>
>> Does the user upload the file, or does one web app upload the file to
>> the other one (or both)? How does the file-upload work from a
>> code-perspective?
>
> up loads to one app stored in the other (used for storing details of
> the policies of when certain symptoms reach certain thresholds and the
> doctor needs to be notified immediately [i.e. as a lab we are not
> legally allowed to contact the patient directly but for their own good
> they should get to the nearest ER ASAP ]).... code prospective:
>
> Original code:
>
> Decode form
> Save file to /tmp/[sessId]/[filename]
> Move file from above to images app and rename the file from
> /tmp/[sessId][filename] to [webapp dir]/images/[doc]/1.jpg (simelar if
> it is org policy or a system wide one)
>
> Open21 vs. Open8 weirdness:
>
> Turns out for some wacko reason java.io.File.renameTo() was failing
> silently (i.e. it was return false but being ultra opaque about why
> [no stack traces/etc]) [note I also had to deal with a caching issue
> on the browser first].
>
> But switching to java.nio.Files.move() does work and gives no errors
> or anything (no need to modify ownership or permissions)
>
>
>>> Some troubleshooting I have tried on our development machine (same
>>> versions as above) it seems to work but not in production (the
>>> primary/"only" difference between the two I can find is production is
>>> https and development is http but the cert from comodo covers the
>>> entire machine [no subdomains or aliases in server.xml] and is
>>> multidomain). In both cases I set
>>> /usr/local/apache-tomcat-9.0/images to be 777 permissions and owned by
>>> www:www (same uids/gids on both the new and old production machines).
>>> Note both production and test are brand new VM's never used for
>>> anything but these apps.
>>>
>> Yikes! You really shouldn't use 777 file permissions unless you are
>> absolutely desperate to figure out what is going on. Permissions
>> problems /should/ cause some kind of error message, somewhere.
>>
>> The "fail silently" problem is concerning. It makes me think maybe
>> nothing is happening at all, and there is actually no "active" failure.
>
> 777 is normally 775 (the group permissions are to allow for scripted
> installs of war files without sudo/su) for webapps/ and then we allow
> tomcat to set the default 755 on the unpacked war (in the case of
> images there is no war and we set the permissions by hand to be the
> above).
>
> As shown above there was an active failure but due to the contract for
> File.renameTo it was effectively silent since the code never checked
> the return value (the new code using Files.move() does check and have
> a proper try catch)
Files.move is a lot more resilient and has behavior more in-line with
more other core Java IO methods e.g. it throws exceptions when it fails,
etc. You should always use Files.move if it is an option over File.moveTo.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
Posted by Konstantin Kolinko <kn...@gmail.com>.
чт, 11 янв. 2024 г. в 23:08, Aryeh Friedman <ar...@gmail.com>:
> [...]
> Original code:
>
> Decode form
> Save file to /tmp/[sessId]/[filename]
> Move file from above to images app and rename the file from
> /tmp/[sessId][filename] to [webapp dir]/images/[doc]/1.jpg (simelar if
> it is org policy or a system wide one)
>
> Open21 vs. Open8 weirdness:
>
> Turns out for some wacko reason java.io.File.renameTo() was failing
> silently (i.e. it was return false but being ultra opaque about why
> [no stack traces/etc]) [note I also had to deal with a caching issue
> on the browser first].
>
> But switching to java.nio.Files.move() does work and gives no errors
> or anything (no need to modify ownership or permissions)
Are "/tmp" and "[webapp dir]" on the same filesystem? If they are not,
you need to move the actual bytes from one partition/hard drive to
another and a simple "rename" is not enough.
I wonder why your file ends up in /tmp and not in ${java.io.tmpdir}.
The latter is set by Tomcat startup scripts to be
"${catalina.base}/temp".
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
Posted by Aryeh Friedman <ar...@gmail.com>.
TL;DR (see inline for details):
Problem found and worked around (root cause still unknown but likely a
bug in OpenJDK 21's standard lib [see below])
On Thu, Jan 11, 2024 at 8:43 AM Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> Aryeh,
>
> On 1/10/24 17:48, Aryeh Friedman wrote:
> > After upgrading the machine (brand new VM) from FreeBSD 12.X to
> > 14.0-RELEASE, OpenJDK 8 to OpenJdk 21 and Tomcat 9.0.35 to 9.0.84
> > (copied the existing server.xml over) I am having problems with a
> > servlet that has worked in the past that uploaded images from one app
> > (which is re-installed on each version thus no perm files in the web
> > app) to an other (to give persistence).... i.e.
> > https://machine/specMed/ to https://macine/images/ and the existing
> > images are shown as expected but the servlet silently fails (no errors
> > to browser, catalina.out or anywhere else I can find) and I was
> > careful to make sure the permissions where identical.... ideas?
>
> Does the user upload the file, or does one web app upload the file to
> the other one (or both)? How does the file-upload work from a
> code-perspective?
up loads to one app stored in the other (used for storing details of
the policies of when certain symptoms reach certain thresholds and the
doctor needs to be notified immediately [i.e. as a lab we are not
legally allowed to contact the patient directly but for their own good
they should get to the nearest ER ASAP ]).... code prospective:
Original code:
Decode form
Save file to /tmp/[sessId]/[filename]
Move file from above to images app and rename the file from
/tmp/[sessId][filename] to [webapp dir]/images/[doc]/1.jpg (simelar if
it is org policy or a system wide one)
Open21 vs. Open8 weirdness:
Turns out for some wacko reason java.io.File.renameTo() was failing
silently (i.e. it was return false but being ultra opaque about why
[no stack traces/etc]) [note I also had to deal with a caching issue
on the browser first].
But switching to java.nio.Files.move() does work and gives no errors
or anything (no need to modify ownership or permissions)
> > Some troubleshooting I have tried on our development machine (same
> > versions as above) it seems to work but not in production (the
> > primary/"only" difference between the two I can find is production is
> > https and development is http but the cert from comodo covers the
> > entire machine [no subdomains or aliases in server.xml] and is
> > multidomain). In both cases I set
> > /usr/local/apache-tomcat-9.0/images to be 777 permissions and owned by
> > www:www (same uids/gids on both the new and old production machines).
> > Note both production and test are brand new VM's never used for
> > anything but these apps.
> >
> Yikes! You really shouldn't use 777 file permissions unless you are
> absolutely desperate to figure out what is going on. Permissions
> problems /should/ cause some kind of error message, somewhere.
>
> The "fail silently" problem is concerning. It makes me think maybe
> nothing is happening at all, and there is actually no "active" failure.
777 is normally 775 (the group permissions are to allow for scripted
installs of war files without sudo/su) for webapps/ and then we allow
tomcat to set the default 755 on the unpacked war (in the case of
images there is no war and we set the permissions by hand to be the
above).
As shown above there was an active failure but due to the contract for
File.renameTo it was effectively silent since the code never checked
the return value (the new code using Files.move() does check and have
a proper try catch)
--
Aryeh M. Friedman, Lead Developer, http://www.PetiteCloud.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Aryeh,
On 1/10/24 17:48, Aryeh Friedman wrote:
> After upgrading the machine (brand new VM) from FreeBSD 12.X to
> 14.0-RELEASE, OpenJDK 8 to OpenJdk 21 and Tomcat 9.0.35 to 9.0.84
> (copied the existing server.xml over) I am having problems with a
> servlet that has worked in the past that uploaded images from one app
> (which is re-installed on each version thus no perm files in the web
> app) to an other (to give persistence).... i.e.
> https://machine/specMed/ to https://macine/images/ and the existing
> images are shown as expected but the servlet silently fails (no errors
> to browser, catalina.out or anywhere else I can find) and I was
> careful to make sure the permissions where identical.... ideas?
Does the user upload the file, or does one web app upload the file to
the other one (or both)? How does the file-upload work from a
code-perspective?
> Some troubleshooting I have tried on our development machine (same
> versions as above) it seems to work but not in production (the
> primary/"only" difference between the two I can find is production is
> https and development is http but the cert from comodo covers the
> entire machine [no subdomains or aliases in server.xml] and is
> multidomain). In both cases I set
> /usr/local/apache-tomcat-9.0/images to be 777 permissions and owned by
> www:www (same uids/gids on both the new and old production machines).
> Note both production and test are brand new VM's never used for
> anything but these apps.
>
Yikes! You really shouldn't use 777 file permissions unless you are
absolutely desperate to figure out what is going on. Permissions
problems /should/ cause some kind of error message, somewhere.
The "fail silently" problem is concerning. It makes me think maybe
nothing is happening at all, and there is actually no "active" failure.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Problems with cross app uploads (migrating from 9.0.35 to 9.0.84)
Posted by Michael Osipov <mi...@apache.org>.
Aryeh,
a general advice: The current Tomcat ports on FreeBSD are a bit unfortunate since they don't motivate to use separate catalina bases. I do not recommend using it as-is. Leverage the multi-instance options provided by its rc script to split out and the do:
> tomcat_{name}_enable="YES"
> tomcat_{name}_catalina_user="your-user"
> tomcat_{name}_catalina_base="/your/path"
> tomcat_{name}_umask="0027"
I do *not* recommend to spill your deployment into CATALINA_HOME [1]
I have discussed this once briefly with the port maintainer, but simply didn't have the time to work on a tomcatX-split port.
Michael
[1] https://github.com/freebsd/freebsd-ports/blob/4430a994eea5d6b2ed84c940963788069d6fd1d6/www/tomcat9/Makefile#L42
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org