Re: Weirdness going on with Tomcat on an AWS instance

2020-08-06 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 8/4/20 20:20, James H. H. Lampert wrote:
> I am once again attempting to get our development AWS box switched
> over to Let's Encrypt.
>
> This time, I've managed to get the httpd server working with the
> Let's Encrypt cert.

This is far easier than doing it with Tomcat (unfortunately for us).
Before you go too much farther: why not just use httpd and be done
with it?

And if you are going to AWS, you could use an AWS application load
balancer and free auto-renewing certificates from AWS. If you don't
trust AWS's networking to isolate your traffic from lb -> worker
nodes, you can use self-signed certificates with large expiration
dates or something like that.

Just an option for you.

> And this time, I've even managed to get Tomcat 8.5 to use it
> without crashing on takeoff. It's not yet on speaking terms with
> Chrome, but Firefox can access it just fine. And that's when I
> noticed the weirdness:
>
> The mere act of spinning up a spot instance from last night's
> backup caused Tomcat to update itself to the latest version (from
> 8.5.40 to 8.5.57).

That's ... unusual. I can assure you that neither Tomcat nor any Linux
distro I know would auto-upgrade anything like that. Sure you don't
have anything like that installed after-market?

> This would not be a bad thing in and of itself, except for two
> side effects: First, the default ROOT context was overlaid onto our
> ROOT context!

Wah wah.

> Second, Manager was disabled!

Wah wah.

Are you using "split" CATALINA_HOME and CATALINA_BASE?

> I spun up a new spot instance, the same way I did the one I'm using
> for my experiments, and sure enough, the ROOT context was changed:
> eleven files were added, and an undetermined number were changed.
>
> The other contexts appear to all be there, but the "examples"
> context, which we remove from all our working Tomcat installations,
> was added back in.
>
> But our server.xml appears to be completely intact, and so does
> our tomcat-users.xml.
>
> Yet, as I said, Manager is disabled.
>
> Can anybody shed any light on what happened?

Try this:

1. Get your server into a state with the "old" version of Tomcat.

2. Take a snapshot so you can get back here (or prepare to trash the nod
e)

3. Do a "chown -R root:root /path/to/tomcat"

4. Do a "chmod -R a= /path/to/tomcat5

5. Relaunch the instance and look for errors

That might still not do anything if whatever process is upgrading
Tomcat is running as root and "fixes" everything.

You could also look in /etc/init.d/* for interesting things, or
/etc/rc.local, or anything in /etc/systemd depending upon what flavor
of Linux you are running. Those places have scripty-like things which
usually get run on startup. Maybe:

$ grep -i tomcat $( find /etc -type f )

?

Hope that helps,
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sHxgACgkQHPApP6U8
pFhHJQ//WErtFN1kVlMbSQqtNjyYbhfsv7V8CKCYXpsAJ6wAOjIflE2sf3t391s1
0L4uIgFZZWsnPyB96bdzr6lOf4swfPWCwK+thzqcm+vrzPdgFPiwxwL/rhVn99Zf
RxQcC8kgjfI6L9GfDS/m3qJYLMYH+w8+bUn3mlZYCX7GODvmQ/96YE+HMiados/O
XVuGxkDEQMHXL01mqo8NLGTTG2q3FnrSprEAVaxNYV6P3hoQNbcxBDEBS3rS9SXf
y4hTbFm8RtaA73RS5lllh5NTRrM+k5ed6K1Nj4FGwVzHKyXcBdqV7RIKi0bJH4Z0
I/W8GcVtqv5EBS/Ox++yo3yjSIfSv1doOgnQ1wrDxMSDxmUUjhQITR4XF66/HE7H
riD6rIsyIymXKfpbCEnO+EpsnmNJz1sVtP7oWlMiN9TqIoQDKXNMBexYyjGVBN0I
1Mpsl0DvkzS7AqBCUpsMyFpdJr4qVjCIxfPaqV4b56C0QdOWhWDAnz2TKifyS8Dn
+pgU9iL3tWaTi0NL3i2a3ugQHh0BCrgRmM21FBf6bQVeJHSzZ4lvRkRon6q+di0C
7ECztmifIqaNnp4QlCg2s0TzAAyBUw0m3r+Vr61cPBSeU5G3CsXEn+lT/ZZ9rpQe
QbrzFSG+glTiq/OGUFp0AL6tLYiLLSeUlPjxHOB9aXHHiOgcxSc=
=rd2M
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Weirdness going on with Tomcat on an AWS instance

2020-08-04 Thread James H. H. Lampert

Ladies and Gentlemen:

I am once again attempting to get our development AWS box switched over 
to Let's Encrypt.


This time, I've managed to get the httpd server working with the Let's 
Encrypt cert. And this time, I've even managed to get Tomcat 8.5 to use 
it without crashing on takeoff. It's not yet on speaking terms with 
Chrome, but Firefox can access it just fine. And that's when I noticed 
the weirdness:


The mere act of spinning up a spot instance from last night's backup 
caused Tomcat to update itself to the latest version (from 8.5.40 to 
8.5.57).


This would not be a bad thing in and of itself, except for two side effects:
First, the default ROOT context was overlaid onto our ROOT context!

Second, Manager was disabled!

I spun up a new spot instance, the same way I did the one I'm using for 
my experiments, and sure enough, the ROOT context was changed: eleven 
files were added, and an undetermined number were changed.


The other contexts appear to all be there, but the "examples" context, 
which we remove from all our working Tomcat installations, was added 
back in.


But our server.xml appears to be completely intact, and so does our 
tomcat-users.xml.


Yet, as I said, Manager is disabled.

Can anybody shed any light on what happened?

--
James H. H. Lampert

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org