Re: Help with Tomcat Automatic Application Deployment
Thanks Mark, your answer is very helpful. I tried many scenarios using your
inputs.
I want Tomcat to NOT perform reload but it needs to perform a redeploy when
context.xml is changed. So i set autoDeploy=true and commented out below
section in context.xml to server my purpose.
WEB-INF/web.xml
${catalina.base}/conf/web.xml
Now what i noticed is, while tomcat and application are in running state,
if i removed /opt/apache-tomcat-8.5.23/webapps/cp directory, Tomcat is
trying to redeploy which is good but it hung at below error
*SEVERE: The web application [cp] created a ThreadLocal with key of type
[java.lang.ThreadLocal] (value [java.lang.ThreadLocal@5640c1bb) and a value
of type [foo.context.ServiceToken] (value [Unknow] ) but failed to remove
it when the web application was stopped. Threads are going to be renewed
over time to try and avoid a probable memory leak.*
In order to get rid of this error, i manually need to stop / forcefully
kill PID for the tomcat and then start tomcat to perform a redeploy ---> So
here there's a human interaction of manually stopping tomcat and starting
it (not serving the purpose of redeploy). Do you have any thoughts or
suggestions in this scenarios ?
Thanks,
Srinath.
On Fri, May 11, 2018 at 11:44 AM Mark Thomas wrote:
> On 08/05/18 19:07, sri devops wrote:
> > Hello Team,
> >
> > Currently I have apache-tomcat-8.5.23 installed and running on
> > RHEL7.x86_64. I have a war deployed and application is running under
> > tomcat. While application is running, if i make any manual changes to
> some
> > config files [ context.xml or server.xml or web.xml] and noticed Tomcat
> is
> > restarting application even though I haven't called tomcat service start
> > script.
>
> Changes to server.xml do not trigger web application reload or redeploy.
> Neither does it trigger a Tomcat restart.
>
> Changes to web.xml trigger a web application reload because of the
> default watched resources (see CATALINA_BASE/conf/context.xml) and
> because autoDeploy is true by default.
>
> Changes to context.xml will trigger a web application redeploy because
> autoDeploy is true by default.
>
>
> > My intention is,
> > 1) At first when there's initial war deployed and tomcat service start
> > script is called, tomcat should extract war and app should work
> > 2) Second, While tomcat is in running state and application is running
> and
> > if i make any manual changes to any tomcat config file, I do not want
> > application to auto magically restart.
> >
> > *my server.xml looks as below*
> >
> > >unpackWARs="true" autoDeploy="true">
> >
> >
> > I also looked at your docs and researched online, but unclear on these
> > parameters what to use when. [ setting autoDeploy=false (or) having
> > deployIgnore attribute somewhere ?]
>
> Set autoDeploy to false.
>
> Mark
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
SSL Session Cache with Tomcat 9 and Java 9
I noticed on ssllabs.com that when I upgrade from java 8 to java 9 (9.0.4 to be exact) that without changing any other variables I start to get "Session resumption (caching) No (IDs assigned but not accepted)" as a warning. I also tried explicitly setting the sessionCacheSize (even tho docs say default is 0 which means unlimited size) and that did not help. Anyone else seeing this or know how to get session cache working again on java 9? Thanks! Jesse
Re: Amazon EC2 Tomcat 7.0.85 not starting up due to some memory issue .Please mask if
On 5/16/2018 11:13 AM, Kiran Badi wrote: > Yes tomcat is not starting up. I am also suspecting that EC2 instance was > > probably compromised. Not sure as how but I see some rogue programs were > running under tomcat user. I use putty with private keys to login and those > keys are not in public view for sure. > > These program were talking to some servers based out of China,Russia and > Germany with tcp,http and stratrum-tcp protocol with jsonp as data exchange > formt. I am not sure as how they got access to my ec2 instance and got > themselves installed. > > I did some initial analysis on this one and have put those files in my g > drive which I have made public. I suspect either they have used tomcat to > gain access or they might have used yum updates for getting access to ec2 > instance. Because the evil software is/was running as the tomcat user, it is likely that a vulnerability in Tomcat or a vulnerability in the application(s) you're running in tomcat was the entry point. Your logs may provide clues, but it's also possible that information about exactly how they broke in isn't available. Information in the jwzckuz.cf file you provided indicates that this is a crypto-mining program for the monero crypto-currency. They're using your system resources to mine currency for themselves. The Java Hotspot warning you received during startup indicates that Java was not able to allocate memory from the operating system. The information in the hotspot error log (near the end, from /proc/meminfo) says that this machine only has 1GB of total memory, and that at the time of the crash, 899240KB of that was actively being used. There wasn't enough memory for Java to allocate what it was being asked to allocate. Depending on how much memory the programs added by the attacker are using, killing them might allow Tomcat to start up. Thanks, Shawn - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Amazon EC2 Tomcat 7.0.85 not starting up due to some memory issue .Please mask if
Yes tomcat is not starting up. I am also suspecting that EC2 instance was probably compromised. Not sure as how but I see some rogue programs were running under tomcat user. I use putty with private keys to login and those keys are not in public view for sure. These program were talking to some servers based out of China,Russia and Germany with tcp,http and stratrum-tcp protocol with jsonp as data exchange formt. I am not sure as how they got access to my ec2 instance and got themselves installed. I did some initial analysis on this one and have put those files in my g drive which I have made public. I suspect either they have used tomcat to gain access or they might have used yum updates for getting access to ec2 instance. cronjobs.txt contains information that some programs were running with tomcat user id. hs_err_pid23773.log contains pid details for tomcat event. jwzckuz.cf is probably some config file installed by hacker. rciwd - was actual program which was consuming too much of swap and cpu and was running as cron job. Not sure as what this is. script.txt is actual script I extracted from one of the http request by capturing traffic via wireshark. files with names 0515 are tcpdump capture on the server taken while unauthorised programs were running. 172-xx-68-244 is my ec2 instance and 98.122.xx.xx is my ip in the trace. https://drive.google.com/drive/folders/1K5gfXTEvmuoIynCYtlwmf7DknyGkvhMI?usp=sharing appreciate if someone from tomcat team take a look at all the files I have attached in the drive. Please let me know if more information is needed. On Wed, May 16, 2018 at 11:09 AM, Christopher Schultz < ch...@christopherschultz.net> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Kiran, > > On 5/15/18 5:58 PM, Kiran Badi wrote: > > For some reason my application hosted on ec2 is just not starting > > up. I know I never had any memory issues in last 1 year or so. > > > > I see below trace in catalina.out file. I am not sure if I need to > > add swap space or file permission is an issue here. Something > > changed in ec2 that is causing this error.I think they auto updated > > the tomcat version as well from 7.0.82 to 7.0.85. > > > > I seriously need some suggestions. I also need some suggestion as > > how to prevent bots from trying to access manager app. > > > > May 14, 2018 8:44:46 PM org.apache.catalina.realm.LockOutRealm > > filterLockedAccounts WARNING: An attempt was made to authenticate > > the locked user "admin" > > It sure looks like Tomcat has started, since it is processing > requests. Are you sure it's not starting? > > > java.util.logging.ErrorManager: 4 java.io.FileNotFoundException: > > /usr/share/tomcat7/logs/catalina.2018-05-15.log (Permission > > denied) at java.io.FileOutputStream.open0(Native Method) > > Obviously this is not memory-related. Did you intend to report this as > a part of your problem? > > Java HotSpot(TM) 64-Bit Server VM warning: INFO: > > os::commit_memory(0x7f48f29d, 65536, 1) failed; > > error='Cannot allocate memory' (errno=12) # # There is insufficient > > memory for the Java Runtime Environment to continue. # Native > > memory allocation (mmap) failed to map 65536 bytes for committing > > reserved memory. # An error report file with more information is > > saved as: # /usr/share/tomcat7/hs_err_pid23773.log # # Compiler > > replay data is saved as: > > > > The Java stack trace might be helpful, as would the native stack trace. > > What are your memory-related JVM launch parameters? What JVM are you > using (version, architecture)? > > Odd that allocating 64kib should fail... > > - -chris > -BEGIN PGP SIGNATURE- > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlr8Sa0ACgkQHPApP6U8 > pFiBZg/+JmjmrlDUZuzoleg1ypwrxM51NSCCUPxLCxy/tI2UZF2MgRUwDZU3tdXX > iHJsfwZ83bCt8m9eFBVy/4jWUQNjlDK+ahDBTOeqJvDkaNtdYLiLRBMqegtXF9JT > cyt2nQdsetKx+rsI5HGytXBX6OuzJCSAw+bVHzzq2KFiOe4gnyqItsLg8TyXM+50 > giB0WlIBldyqj+kD9S8hRwqTTIXkAg4H+tI8+piBKKAojfLpuZB3qGhXhTncEMBA > LL8Udbrz08vU3gXMg5U07pUHc/Vkn8U1axgcn4U3lQ0flKHRkBeabp/wVZ6a1Cuj > a918715HRqZPezqEYoEYJjyUHV13c07T1nKFcLfR97VhFx1WjuTEGuHFriYjsPXN > Qo0J6ej4+z0JItQVJ3w3qxijU9Vt0kEJq53raeclqNgdxhaVvLDDrPOxwZWvT9vz > 1FiIyylRTNlC0tEAV3osQ9MFhf4eUgLGPGbEN69U+pEJ4Y2WgTlioKsueVDZcNrs > czS6x0sR1Rd1waYQbnIXNpzIngQNAsnrw9cX73FSTmRVT3VGNdtlIFYzQ9aIl3UX > 3cuLlqyumLySIV6BjORu6TgqGefSw+KYOJagTWo6IuExzLeU1vYs4V/ZVGt5qHQO > kKLJmRaQozQ4u+ajMR9Lp5ESsLtjs+TPWy5tu4cQr6SE9PzL1fo= > =Bm4c > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Amazon EC2 Tomcat 7.0.85 not starting up due to some memory issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Kiran, On 5/15/18 5:58 PM, Kiran Badi wrote: > For some reason my application hosted on ec2 is just not starting > up. I know I never had any memory issues in last 1 year or so. > > I see below trace in catalina.out file. I am not sure if I need to > add swap space or file permission is an issue here. Something > changed in ec2 that is causing this error.I think they auto updated > the tomcat version as well from 7.0.82 to 7.0.85. > > I seriously need some suggestions. I also need some suggestion as > how to prevent bots from trying to access manager app. > > May 14, 2018 8:44:46 PM org.apache.catalina.realm.LockOutRealm > filterLockedAccounts WARNING: An attempt was made to authenticate > the locked user "admin" It sure looks like Tomcat has started, since it is processing requests. Are you sure it's not starting? > java.util.logging.ErrorManager: 4 java.io.FileNotFoundException: > /usr/share/tomcat7/logs/catalina.2018-05-15.log (Permission > denied) at java.io.FileOutputStream.open0(Native Method) Obviously this is not memory-related. Did you intend to report this as a part of your problem? > Java HotSpot(TM) 64-Bit Server VM warning: INFO: > os::commit_memory(0x7f48f29d, 65536, 1) failed; > error='Cannot allocate memory' (errno=12) # # There is insufficient > memory for the Java Runtime Environment to continue. # Native > memory allocation (mmap) failed to map 65536 bytes for committing > reserved memory. # An error report file with more information is > saved as: # /usr/share/tomcat7/hs_err_pid23773.log # # Compiler > replay data is saved as: > The Java stack trace might be helpful, as would the native stack trace. What are your memory-related JVM launch parameters? What JVM are you using (version, architecture)? Odd that allocating 64kib should fail... - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlr8Sa0ACgkQHPApP6U8 pFiBZg/+JmjmrlDUZuzoleg1ypwrxM51NSCCUPxLCxy/tI2UZF2MgRUwDZU3tdXX iHJsfwZ83bCt8m9eFBVy/4jWUQNjlDK+ahDBTOeqJvDkaNtdYLiLRBMqegtXF9JT cyt2nQdsetKx+rsI5HGytXBX6OuzJCSAw+bVHzzq2KFiOe4gnyqItsLg8TyXM+50 giB0WlIBldyqj+kD9S8hRwqTTIXkAg4H+tI8+piBKKAojfLpuZB3qGhXhTncEMBA LL8Udbrz08vU3gXMg5U07pUHc/Vkn8U1axgcn4U3lQ0flKHRkBeabp/wVZ6a1Cuj a918715HRqZPezqEYoEYJjyUHV13c07T1nKFcLfR97VhFx1WjuTEGuHFriYjsPXN Qo0J6ej4+z0JItQVJ3w3qxijU9Vt0kEJq53raeclqNgdxhaVvLDDrPOxwZWvT9vz 1FiIyylRTNlC0tEAV3osQ9MFhf4eUgLGPGbEN69U+pEJ4Y2WgTlioKsueVDZcNrs czS6x0sR1Rd1waYQbnIXNpzIngQNAsnrw9cX73FSTmRVT3VGNdtlIFYzQ9aIl3UX 3cuLlqyumLySIV6BjORu6TgqGefSw+KYOJagTWo6IuExzLeU1vYs4V/ZVGt5qHQO kKLJmRaQozQ4u+ajMR9Lp5ESsLtjs+TPWy5tu4cQr6SE9PzL1fo= =Bm4c -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[SECURITY] CVE-2018-8014 Insecure defaults for CORS filter
CVE-2018-8014 Insecure defaults for CORS filter Severity: Low Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 9.0.0.M1 to 9.0.8 Apache Tomcat 8.5.0 to 8.5.31 Apache Tomcat 8.0.0.RC1 to 8.0.52 Apache Tomcat 7.0.41 to 7.0.88 Description: The defaults settings for the CORS filter are insecure and enable 'supportsCredentials' for all origins. It is expected that users of the CORS filter will have configured it appropriately for their environment rather than using it in the default configuration. Therefore, it is expected that most users will not be impacted by this issue. Mitigation: Users of the affected versions should apply one of the following mitigations. - Configure the filter appropriately for your environment Secure defaults will be provided in the following versions: - Apache Tomcat 9.0.9 or later when released - Apache Tomcat 8.5.32 or later when released - Apache Tomcat 8.0.53 or later when released - Apache Tomcat 7.0.89 or later when released History: 2018-05-15 Original advisory References: [1] http://tomcat.apache.org/security-9.html [2] http://tomcat.apache.org/security-8.html [3] http://tomcat.apache.org/security-7.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
