date:20230110

Re: Tomcat 10.1.4 HTTP Status 404 and 500 Help

2023-01-10 Thread Christopher Schultz


Anthony,

On 1/10/23 13:58, Anthony Dell'Anno wrote:

I'm trying to run my first servlet on Tomcat


Welcome!


and am continually getting an HTTP Status 404 (I've also gotten 500
previously, with the root cause being an apparent compiler mismatch
(it would say that it's being compiled by version 63.0, which is Java
19, but that the latest version that was currently accepted was
version 59.0, or Java 15), but then after upgrading to JDK 19,
changing the JAVA_HOME variable and trying to run, it would still
give me the same error)?


Any error like "Unsupported class version 63.0" or similar will be due 
to a JVM mismatch. There are three ways to correct this:


1. Compile with an earlier JVM
2. Run with a later JVM
3. Specify the target JVM with the compiler. This can be done with the 
"-target" compiler switch in modern compilers


I have my Servlet, called HelloWorldServlet, located in the 
"C:\apache-tomcat-10.1.4\webapps\ROOT\WEB-INF\classes\" directory


This isn't a good choice, but will work. I can get back to this, later. 
Is your servlet compiled into a .class file, or do you have a .java file 
in that directory (or both, which is fine)?



with the web.xml file being located outside of the classes folder,
directly inside of the WEB-INF folder.


That's where it belongs. The "ROOT" directory contains the entire web 
application, and WEB-INF is a special directory which can contain:


classes/**/*.class [classes, usually your application]
lib/*.jar [libraries, usually from elsewhere]
web.xml [the deployment descriptor]

I've included both files. StackOverflow wasn't much help as of yet, 
The mailing list often strips attachments, but your plain-text 
attachment made it through. It's much less helpful as an attachment than 
if it were inline, so I'm going to post it here so I can comment on it, 
and also so others can read it without having to detach it:


(I've performed some light editing, which I hope you'll understand.)




  
  

HelloWorldServlet
webapps.HelloXXXServlet
  

  
HelloWorldServlet

/HelloWorld

  




What is the name of the servlet class itself? You said you have a file 
in WEB-INF/classes called HelloWorldServlet. If that's the class name, 
then it should be in the file HelloWorldServlet.class. In your 
configuration, you have servlet.HelloXXXServlet which is definitely wrong.


If your class name is actually HelloXXXServlet, then you need:

  
  

HelloWorldServlet
HelloXXXServlet
  

The servlet class needs to be the "fully qualified name" of the class, 
which will be the package name (which is nothing in your case) followed 
by a period (if it's in a package, which it isn't) followed by the short 
name of the class (HelloXXXServlet).


The "webapps." was completely incorrect, and it's not clear to me 
exactly what the class name actually is, but I think you should be able 
to get it from here.


The  is something you can make-up and is only used within 
web.xml for the purposes of defining a  and then mapping it 
later in  (and other things, actually, but you aren't 
working with any of those quite yet).


Back to the "don't put your files into WEB-INF/classes" comment I made 
above: it's a good idea to put all of your code into "packages". In 
Java, that means:


1. Putting your class source e.g. HelloXXXServlet.java into a directory 
which matches the package. So if your package will be 
"anthony.dellanno", then you need to have your file in 
src/anthony/dellanno/HelloXXXServlet.java. When compiled, this file 
needs to go into WEB-INF/classes/anthony/dellanno/HelloXXXSServlet.class


2. In your .java file, you need to add at this at the top of the file:

package anthony.dellanno;

Once you do that, you'll change the "fully qualified class name" in 
web.xml to this:


  
HelloWorldServlet
anthony.dellanno.HelloXXXServlet
  

And everything else is the same.


so I'm hoping that the Tomcat Users community can help me solve this
so that I can continue learning servlets. I'm working on building my
own software  company.
I highly recommend that anyone working with Java Servlets actually read 
the Java Servlet Specification -- whatever version makes sense for you 
to read. Almost any of them would be good, since there is little change 
between versions for the most part.


Nick Williams wrote a comprehensive (and I mean comprehensive!) book in 
2014 which – despite its age (9 years ago) – is still entirely relevant. 
It's called Professional Java for Web Applications. It guides you 
through these basics and goes all the way up through databases, 
WebSocket, and using the Spring Framework (which he favors in the book; 
other frameworks are available as well).


You can also probably find something similar as your local library if 
you don't want to pay $50 for a dead tree that takes up space on your 
shelf forever.


Hope that helps,
-chris

-
To unsubscribe,

Re: Tomcat 10.1.4 HTTP Status 404 and 500 Help

2023-01-10 Thread John Barrow

Hi Anthony,

Not an expert, but have managed to deploy simple servlets. A couple of
observations, not sure why using ROOT, you should have your own folder for
your application (e.g. myFirstApp\...).

Also, I have found that the main app folder (e.g. myFirstApp) must start
with a lowercase letter (I don't know reason for this but have it in my
notes) otherwise the servlets won't be found when accessing them through a
browser.

Finally, the default install for TomCat has several example servlets
already written so check that they work first and then take the sources and
clone them, using them as a guide for your own servlets.

John

PS: Probably worth reviewing what file names you use (see your webapps.xml
file) when making public requests so as not to inadvertently offend anyone.

On Tue, 10 Jan 2023, 18:59 Anthony Dell'Anno,
 wrote:

> Good afternoon,
>
> I'm trying to run my first servlet on Tomcat, and am continually
> getting an HTTP Status 404 (I've also gotten 500 previously, with the root
> cause being an apparent compiler mismatch (it would say that it's being
> compiled by version 63.0, which is Java 19, but that the latest version
> that was currently accepted was version 59.0, or Java 15), but then after
> upgrading to JDK 19, changing the JAVA_HOME variable and trying to run, it
> would still give me the same error)?
>
> I have my Servlet, called HelloWorldServlet, located in the
> "C:\apache-tomcat-10.1.4\webapps\ROOT\WEB-INF\classes\" directory, with the
> web.xml file being located outside of the classes folder, directly inside
> of the WEB-INF folder.
>
> I've included both files. StackOverflow wasn't much help as of yet, so
> I'm hoping that the Tomcat Users community can help me solve this so that I
> can continue learning servlets. I'm working on building my own software
> company.
>
> Any help is appreciated.
>
> Thank you very much,
>
> Anthony Dell'Anno
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Basic SSL Certificate Usage logging

2023-01-10 Thread jonmcalexander

:-) Christopher,

This is where my not being a developer really shines out. :-)

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


> -Original Message-
> From: Christopher Schultz 
> Sent: Tuesday, January 10, 2023 4:27 PM
> To: users@tomcat.apache.org
> Subject: Re: Basic SSL Certificate Usage logging
> 
> Jon,
> 
> On 1/10/23 13:37, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Ultimately it would be nice to be able to log it in Jason format for
> > ingestion by Elastic or something similar.
> If you want JSON-formatted logs, then configure JSON-formatted logs.
> JSON embedded in JSON is a little silly:
> 
> {
>"timestamp":"2023-01-10T22:24:00Z",
>"level":"INFO",
>"logger":"org.apache.tomcat.util.net.AbstractEndpoint.logCertificate"
> 
> "message":"{\"tlsVirtualHost\":\"_default_\",\"tlsCertificateType\":\"RSA\",
> ... }"
> }
> 
> Isn't this what logstash is for?
> 
> -chris
> 
> >> -Original Message-
> >> From: Christopher Schultz 
> >> Sent: Tuesday, January 10, 2023 7:52 AM
> >> To: users@tomcat.apache.org
> >> Subject: Re: Basic SSL Certificate Usage logging
> >>
> >> Jon,
> >>
> >> On 1/9/23 18:17, jonmcalexan...@wellsfargo.com.INVALID wrote:
> >>> Yes Chris, It's just for during startup. For a particular instance I
> >>> would like to capture the Certificate Info and Truststore being used
> >>> and pipe that into a separate log/txt file.
> >> So it sounds like just dumping-out the configured certificates, etc.
> >> to something like the debug log from Connector or SSLHostConfig or
> >> similar would work?
> >>
> >> Or would you want that information available to the application so
> >> you can log it in some very specific way? Note that you can already
> >> get the SSLHostConfig info via JMX if you are willing to do that.
> >>
> >> -chris
> >>
> >>>
> >>> Thanks,
> >>>
> >>> Dream * Excel * Explore * Inspire
> >>> Jon McAlexander
> >>> Senior Infrastructure Engineer
> >>> Asst. Vice President
> >>> He/His
> >>>
> >>> Middleware Product Engineering
> >>> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> >>>
> >>> 8080 Cobblestone Rd | Urbandale, IA 50322
> >>> MAC: F4469-010
> >>> Tel 515-988-2508 | Cell 515-988-2508
> >>>
> >>> jonmcalexan...@wellsfargo.com
> >>> This message may contain confidential and/or privileged information.
> >>> If you
> >> are not the addressee or authorized to receive this for the
> >> addressee, you must not use, copy, disclose, or take any action based
> >> on this message or any information herein. If you have received this
> >> message in error, please advise the sender immediately by reply
> >> e-mail and delete this message. Thank you for your cooperation.
> >>>
>  -Original Message-
>  From: Christopher Schultz 
>  Sent: Monday, January 9, 2023 8:10 AM
>  To: users@tomcat.apache.org
>  Subject: Re: Basic SSL Certificate Usage logging
> 
>  Jon,
> 
>  On 1/6/23 15:53, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Thanks for the info.
> >
> > In a nutshell I think the certpath,provider would be sufficient.
> > I'm thinking that I can add this to the java options as
> > -Djava.security.debug=ssl:certpath,provider however I don't know
> > how to specify where to log the information.
>  java.security.debug is really a blunt instrument. It's unfortunate
>  that it's one of the only ways to get information out of the TLS
>  stack. It would have been great if Java had started using its own
>  logging system once it was introduced, but no.
> 
>  That debugging tool always dumps to stdout (or stderr?) and you
>  have very little control over where it goes.
> 
>  You would never want to use it for ongoing logging. It truly is for
>  debugging- only.
> 
>  The good news is that application code should be able to get the
>  information you are looking for.
> 
>  Oh, wait...
> 
> > [...] I'm checking to see if there is any out-of-the-box option to
> > capture in a log which SSL certificate and trust keystore is being
> > used during startup?
>  What do you mean "during startup"? I originally read that as "for
>  incoming connections" thinking that you wanted to log which cert
>  was used for a particular

Re: Basic SSL Certificate Usage logging

2023-01-10 Thread Christopher Schultz


Jon,

On 1/10/23 13:37, jonmcalexan...@wellsfargo.com.INVALID wrote:

Ultimately it would be nice to be able to log it in Jason format for
ingestion by Elastic or something similar.
If you want JSON-formatted logs, then configure JSON-formatted logs. 
JSON embedded in JSON is a little silly:


{
  "timestamp":"2023-01-10T22:24:00Z",
  "level":"INFO",
  "logger":"org.apache.tomcat.util.net.AbstractEndpoint.logCertificate"

"message":"{\"tlsVirtualHost\":\"_default_\",\"tlsCertificateType\":\"RSA\", 
... }"

}

Isn't this what logstash is for?

-chris


-Original Message-
From: Christopher Schultz 
Sent: Tuesday, January 10, 2023 7:52 AM
To: users@tomcat.apache.org
Subject: Re: Basic SSL Certificate Usage logging

Jon,

On 1/9/23 18:17, jonmcalexan...@wellsfargo.com.INVALID wrote:

Yes Chris, It's just for during startup. For a particular instance I
would like to capture the Certificate Info and Truststore being used
and pipe that into a separate log/txt file.

So it sounds like just dumping-out the configured certificates, etc. to
something like the debug log from Connector or SSLHostConfig or similar
would work?

Or would you want that information available to the application so you can
log it in some very specific way? Note that you can already get the
SSLHostConfig info via JMX if you are willing to do that.

-chris



Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you

are not the addressee or authorized to receive this for the addressee, you
must not use, copy, disclose, or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you
for your cooperation.



-Original Message-
From: Christopher Schultz 
Sent: Monday, January 9, 2023 8:10 AM
To: users@tomcat.apache.org
Subject: Re: Basic SSL Certificate Usage logging

Jon,

On 1/6/23 15:53, jonmcalexan...@wellsfargo.com.INVALID wrote:

Thanks for the info.

In a nutshell I think the certpath,provider would be sufficient. I'm
thinking that I can add this to the java options as
-Djava.security.debug=ssl:certpath,provider however I don't know how
to specify where to log the information.

java.security.debug is really a blunt instrument. It's unfortunate
that it's one of the only ways to get information out of the TLS
stack. It would have been great if Java had started using its own
logging system once it was introduced, but no.

That debugging tool always dumps to stdout (or stderr?) and you have
very little control over where it goes.

You would never want to use it for ongoing logging. It truly is for
debugging- only.

The good news is that application code should be able to get the
information you are looking for.

Oh, wait...


[...] I'm checking to see if there is any out-of-the-box option to
capture in a log which SSL certificate and trust keystore is being
used during startup?

What do you mean "during startup"? I originally read that as "for
incoming connections" thinking that you wanted to log which cert was
used for a particular request. But it sounds like maybe you are
asking for something to just be logged one-time during startup?

-chris



Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information.
If you

are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based
on this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply
e-mail and delete this message. Thank you for your cooperation.



-Original Message-
From: Christopher Schultz 
Sent: Friday, January 6, 2023 2:41 PM
To: users@tomcat.apache.org
Subject: Re: Basic SSL Certificate Usage logging

Mark,

On 1/6/23 15:00, Mark Thomas wrote:

Hi Jon,

In a word, no. Sorry.

Some sort of info log message probably makes sense for this. SNI
makes things a little more complicated but we should be able to do

something.

What is the minimum info you'd like to see?


How about adding a request attribute with some kind of identifier (fpr?
serial-number?) in it and indicates at least which server-cert was

chosen.

Then it can trivially be added to e.g. access_log or even to
application code which wants to

Re: Question about Redisson

2023-01-10 Thread Mark Thomas


Doug,

There were a couple of questions in my original response it would be 
useful to get answers to.


Also, Chris's suggesiton to look at 
org.apache.catalina.connector.RECYCLE_FACADES is a good first step. Note 
that the value you need for that may not be what you expect. It needs to 
be "true" whereas I read the name and think it should be "false" to 
disable recycling.


Mark


On 10/01/2023 19:09, Doug Whitfield wrote:

First off, thanks for the link. I’m bringing this up with my manager who is 
much more likely to be able to make some headway with the marketing folks. 
There’s surely a marketing friendly way to say “Pay for SLA”.


Are you able to reproduce the same problem with a non-Redisson-based
segmented cluster, such as one using Tomcat's BackupManager?


No. I told them this was going to be the answer. In fact, this was our answer, 
but customer really, really thinks it is a Tomcat issue. Maybe it is, but I 
haven’t personally seen the evidence.

In any case, having the words in print rather than in prediction might help get 
us something more useful, like I think a heap dump might be.

Thanks!


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.




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

Re: Question about Redisson

2023-01-10 Thread Doug Whitfield

First off, thanks for the link. I’m bringing this up with my manager who is 
much more likely to be able to make some headway with the marketing folks. 
There’s surely a marketing friendly way to say “Pay for SLA”.

> Are you able to reproduce the same problem with a non-Redisson-based
> segmented cluster, such as one using Tomcat's BackupManager?

No. I told them this was going to be the answer. In fact, this was our answer, 
but customer really, really thinks it is a Tomcat issue. Maybe it is, but I 
haven’t personally seen the evidence.

In any case, having the words in print rather than in prediction might help get 
us something more useful, like I think a heap dump might be.

Thanks!


This e-mail may contain information that is privileged or confidential. If you 
are not the intended recipient, please delete the e-mail and any attachments 
and notify us immediately.

Tomcat 10.1.4 HTTP Status 404 and 500 Help

2023-01-10 Thread Anthony Dell'Anno

Good afternoon, 
    I'm trying to run my first servlet on Tomcat, and am continually getting an 
HTTP Status 404 (I've also gotten 500 previously, with the root cause being an 
apparent compiler mismatch (it would say that it's being compiled by version 
63.0, which is Java 19, but that the latest version that was currently accepted 
was version 59.0, or Java 15), but then after upgrading to JDK 19, changing the 
JAVA_HOME variable and trying to run, it would still give me the same error)?

I have my Servlet, called HelloWorldServlet, located in the 
"C:\apache-tomcat-10.1.4\webapps\ROOT\WEB-INF\classes\" directory, with the 
web.xml file being located outside of the classes folder, directly inside of 
the WEB-INF folder.
    I've included both files. StackOverflow wasn't much help as of yet, so I'm 
hoping that the Tomcat Users community can help me solve this so that I can 
continue learning servlets. I'm working on building my own software  company.

Any help is appreciated.
Thank you very much,
Anthony Dell'Anno 

	 
	
		 
		
			HelloWorldServlet 
			webapps.HelloMotherFuckerServlet 
			
		 
		
		 
		
			HelloWorldServlet 
			/HelloWorld 
			
			
			
	 
	

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

RE: Basic SSL Certificate Usage logging

2023-01-10 Thread jonmcalexander

Ultimately it would be nice to be able to log it in Jason format for ingestion 
by Elastic or something similar.

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


> -Original Message-
> From: Christopher Schultz 
> Sent: Tuesday, January 10, 2023 7:52 AM
> To: users@tomcat.apache.org
> Subject: Re: Basic SSL Certificate Usage logging
> 
> Jon,
> 
> On 1/9/23 18:17, jonmcalexan...@wellsfargo.com.INVALID wrote:
> > Yes Chris, It's just for during startup. For a particular instance I
> > would like to capture the Certificate Info and Truststore being used
> > and pipe that into a separate log/txt file.
> So it sounds like just dumping-out the configured certificates, etc. to
> something like the debug log from Connector or SSLHostConfig or similar
> would work?
> 
> Or would you want that information available to the application so you can
> log it in some very specific way? Note that you can already get the
> SSLHostConfig info via JMX if you are willing to do that.
> 
> -chris
> 
> >
> > Thanks,
> >
> > Dream * Excel * Explore * Inspire
> > Jon McAlexander
> > Senior Infrastructure Engineer
> > Asst. Vice President
> > He/His
> >
> > Middleware Product Engineering
> > Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> >
> > 8080 Cobblestone Rd | Urbandale, IA 50322
> > MAC: F4469-010
> > Tel 515-988-2508 | Cell 515-988-2508
> >
> > jonmcalexan...@wellsfargo.com
> > This message may contain confidential and/or privileged information. If you
> are not the addressee or authorized to receive this for the addressee, you
> must not use, copy, disclose, or take any action based on this message or any
> information herein. If you have received this message in error, please advise
> the sender immediately by reply e-mail and delete this message. Thank you
> for your cooperation.
> >
> >> -Original Message-
> >> From: Christopher Schultz 
> >> Sent: Monday, January 9, 2023 8:10 AM
> >> To: users@tomcat.apache.org
> >> Subject: Re: Basic SSL Certificate Usage logging
> >>
> >> Jon,
> >>
> >> On 1/6/23 15:53, jonmcalexan...@wellsfargo.com.INVALID wrote:
> >>> Thanks for the info.
> >>>
> >>> In a nutshell I think the certpath,provider would be sufficient. I'm
> >>> thinking that I can add this to the java options as
> >>> -Djava.security.debug=ssl:certpath,provider however I don't know how
> >>> to specify where to log the information.
> >> java.security.debug is really a blunt instrument. It's unfortunate
> >> that it's one of the only ways to get information out of the TLS
> >> stack. It would have been great if Java had started using its own
> >> logging system once it was introduced, but no.
> >>
> >> That debugging tool always dumps to stdout (or stderr?) and you have
> >> very little control over where it goes.
> >>
> >> You would never want to use it for ongoing logging. It truly is for
> >> debugging- only.
> >>
> >> The good news is that application code should be able to get the
> >> information you are looking for.
> >>
> >> Oh, wait...
> >>
> >>> [...] I'm checking to see if there is any out-of-the-box option to
> >>> capture in a log which SSL certificate and trust keystore is being
> >>> used during startup?
> >> What do you mean "during startup"? I originally read that as "for
> >> incoming connections" thinking that you wanted to log which cert was
> >> used for a particular request. But it sounds like maybe you are
> >> asking for something to just be logged one-time during startup?
> >>
> >> -chris
> >>
> >>>
> >>> Thanks,
> >>>
> >>> Dream * Excel * Explore * Inspire
> >>> Jon McAlexander
> >>> Senior Infrastructure Engineer
> >>> Asst. Vice President
> >>> He/His
> >>>
> >>> Middleware Product Engineering
> >>> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> >>>
> >>> 8080 Cobblestone Rd | Urbandale, IA 50322
> >>> MAC: F4469-010
> >>> Tel 515-988-2508 | Cell 515-988-2508
> >>>
> >>> jonmcalexan...@wellsfargo.com
> >>> This message may contain confidential and/or privileged information.
> >>> If you
> >> are not the addressee or authorized to receive this for the
> >> addressee, you must not use, copy, disclose, or take any action based
> >> on this message or any information herein. If you have received this
> >> message in error, please advise the sender immediately by reply
>

RE: Basic SSL Certificate Usage logging

2023-01-10 Thread jonmcalexander

Can we include valid to dates?

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


> -Original Message-
> From: Mark Thomas 
> Sent: Tuesday, January 10, 2023 8:23 AM
> To: users@tomcat.apache.org
> Subject: Re: Basic SSL Certificate Usage logging
> 
> On 10/01/2023 13:52, Christopher Schultz wrote:
> > Jon,
> >
> > On 1/9/23 18:17, jonmcalexan...@wellsfargo.com.INVALID wrote:
> >> Yes Chris, It's just for during startup. For a particular instance I
> >> would like to capture the Certificate Info and Truststore being used
> >> and pipe that into a separate log/txt file.
> > So it sounds like just dumping-out the configured certificates, etc.
> > to something like the debug log from Connector or SSLHostConfig or
> > similar would work?
> >
> > Or would you want that information available to the application so you
> > can log it in some very specific way? Note that you can already get
> > the SSLHostConfig info via JMX if you are willing to do that.
> 
> How about something like this:
> 
> 10-Jan-2023 14:21:07.951 INFO [main]
> org.apache.tomcat.util.net.AbstractEndpoint.logCertificate
> [https-jsse-nio-8443], TLS virtual host [_default_], Certificate type [RSA]
> configured from [conf/localhost-rsa.jks] using alias [null] and with trust 
> store
> [null]
> 
> ?
> 
> Mark
> 
> >
> > -chris
> >
> >>
> >> Thanks,
> >>
> >> Dream * Excel * Explore * Inspire
> >> Jon McAlexander
> >> Senior Infrastructure Engineer
> >> Asst. Vice President
> >> He/His
> >>
> >> Middleware Product Engineering
> >> Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> >>
> >> 8080 Cobblestone Rd | Urbandale, IA 50322
> >> MAC: F4469-010
> >> Tel 515-988-2508 | Cell 515-988-2508
> >>
> >> jonmcalexan...@wellsfargo.com
> >> This message may contain confidential and/or privileged information.
> >> If you are not the addressee or authorized to receive this for the
> >> addressee, you must not use, copy, disclose, or take any action based
> >> on this message or any information herein. If you have received this
> >> message in error, please advise the sender immediately by reply
> >> e-mail and delete this message. Thank you for your cooperation.
> >>
> >>> -Original Message-
> >>> From: Christopher Schultz 
> >>> Sent: Monday, January 9, 2023 8:10 AM
> >>> To: users@tomcat.apache.org
> >>> Subject: Re: Basic SSL Certificate Usage logging
> >>>
> >>> Jon,
> >>>
> >>> On 1/6/23 15:53, jonmcalexan...@wellsfargo.com.INVALID wrote:
>  Thanks for the info.
> 
>  In a nutshell I think the certpath,provider would be sufficient.
>  I'm thinking that I can add this to the java options as
>  -Djava.security.debug=ssl:certpath,provider however I don't know
>  how to specify where to log the information.
> >>> java.security.debug is really a blunt instrument. It's unfortunate
> >>> that it's one of the only ways to get information out of the TLS
> >>> stack. It would have been great if Java had started using its own
> >>> logging system once it was introduced, but no.
> >>>
> >>> That debugging tool always dumps to stdout (or stderr?) and you have
> >>> very little control over where it goes.
> >>>
> >>> You would never want to use it for ongoing logging. It truly is for
> >>> debugging-
> >>> only.
> >>>
> >>> The good news is that application code should be able to get the
> >>> information you are looking for.
> >>>
> >>> Oh, wait...
> >>>
>  [...] I'm checking to see if there is any out-of-the-box option to
>  capture in a log which SSL certificate and trust keystore is being
>  used during startup?
> >>> What do you mean "during startup"? I originally read that as "for
> >>> incoming connections" thinking that you wanted to log which cert was
> >>> used for a particular request. But it sounds like maybe you are
> >>> asking for something to just be logged one-time during startup?
> >>>
> >>> -chris
> >>>
> 
>  Thanks,
> 
>  Dream * Excel * Explore * Inspire
>  Jon McAlexander
>  Senior Infrastructure Engineer
>  Asst. Vice President
>  He/His
> 
>  Middleware Product Engineering
>  Enterprise CIO | EAS | Middleware | Infrastructure Solutions
> 
>  8080 Cobblestone Rd | Urbandale, IA 50322
>  MAC: F4469-010
>  Tel 515-988-2508 | Cell 515-988-2508
>

Re: Possibilities for fetching config information from Kubernetes

2023-01-10 Thread Christopher Schultz


Mark, Rémy,

On 1/10/23 09:58, Rémy Maucherat wrote:

On Tue, Jan 10, 2023 at 3:11 PM Christopher Schultz
 wrote:


Mark,

On 1/10/23 03:22, Mark Thomas wrote:

On 09/01/2023 22:17, Christopher Schultz wrote:

All,

I'm aware that there is a k8s manager for clustering
(CloudMembershipService) but I was wondering if / how that could be
extended in order to provide any other types of automated
configuration information for a Tomcat installation.

For example, I'd love to be able to deploy a Tomcat node and have it
grab its primary database connection information from k8s.

I spent like 5 minutes reading through the CloudMembershipService and
KubernetesMembershipProvider classes and it seems to be all bundled
together and very geared toward fetching cluster information.

It seems that most of the KubernetesMembershipProvider.start method
could be moved into a separate support class which just manages k8s
connection information (e.g. fetching from the environment, building
URLs to various interesting paths, wrapping fethcing-and-JSON-parsing,
etc.) and that could be re-used for a parameter-resolver for XML
config files like we can do for system properties like



It occurs to be that we should be able to do something like this:



... and write a resolver that fetches that value on the fly.
(Hopefully it would cache stuff, so that a dozen different
environmental references don't have to be resolved separately.)


Isn't this why ServiceBindingPropertySource was contributed? I only
dabble with k8s very occasionally but my understanding is that this is
the 'proper' way to pick up config in a k8s environment.


Yeah, I think you are right. I hadn't noticed that class before, and it
looks like it doesn't interact with k8s (or similar) in any way: it just
assumes that the orchestration framework has already dropped a cache of
useful configuration files onto the system before the service is launched.

It looks like the KubernetesMembershipProvider needs to be separate from
that because it actually has to communicate directly with k8s for, well,
membership services. It's not just reading configuration values.

So, I guess... nothing to see here!


The KubernetesMembershipProvider is the cleanest way to access the
Kube namespace. Then you can use it to list the pods (as here) or
pretty much anything else. There's a problem though: it needs the
token to connect to the service account (= configuration !) *and*
configure the appropriate permissions in Kube to allow the desired
access (= annoying configuration !). I liked it because once it works
it is predictable and reliable.

DNSMembershipProvider is an equivalent to get the list of pods with
far less configuration. However it uses DNS which is prone to
"issues".

So basically yeah, you would need to write a PropertySource that does
somewhat the connection and json parsing that
KubernetesMembershipProvider does. I don't see how the processing can
be generic for everything that is in the Kube namespace, so it would
allow access to some specific values. The problem then is that
security configuration (in Kube) will still be horrible. But it could
work eventually.


I think ServiceBindingPropertySource already covers this, as long as you 
use the servicebinding.io spec, which it seems k8s does.



In KubernetesMembershipProvider, the connection with the token to the
service account is generic. The URL used in the Kube namespace is
hardcoded. And the json parsing is obviously specific to processing
the list of (running) pods in the cluster.


Some of these items could even be parameterized using 
ServiceBindingPropertySource -- same thing with grabbing the config to 
drive KubernetesMembershipProvider, right?


It looks like if I wanted to use k8s for deployment of a simple JDBC 
configuration, I could do something like this:



  


And for an SSL configuration (right from the 
ServiceBindingPropertySource javadoc):



  


I'm curious as to why the sample in ServiceBindingPropertySource javadoc 
actually uses "service resources" for those values when I think it 
doesn't make any sense. ServiceBindingPropertySource.getProperty() will 
resolve the value of the property to the CONTENTS of the file, not to 
the filename itself. This is what the javadoc says:


 * 
 *   certificateKeyFile="${custom-certificate.keyFile}"

 *certificateFile="${custom-certificate.file}"
 * 
certificateChainFile="${custom-certificate.chainFile}"

 *type="RSA" />

I think having certificateFile="-BEGIN CERTIFICATE-" is just 
not going to work, will it? I think this javadoc is wrong.


-chris

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

Re: Basic SSL Certificate Usage logging

2023-01-10 Thread Christopher Schultz


Mark,

On 1/10/23 09:22, Mark Thomas wrote:

On 10/01/2023 13:52, Christopher Schultz wrote:

Jon,

On 1/9/23 18:17, jonmcalexan...@wellsfargo.com.INVALID wrote:

Yes Chris, It's just for during startup. For a particular instance I
would like to capture the Certificate Info and Truststore being used
and pipe that into a separate log/txt file.
So it sounds like just dumping-out the configured certificates, etc. 
to something like the debug log from Connector or SSLHostConfig or 
similar would work?


Or would you want that information available to the application so you 
can log it in some very specific way? Note that you can already get 
the SSLHostConfig info via JMX if you are willing to do that.


How about something like this:

10-Jan-2023 14:21:07.951 INFO [main] 
org.apache.tomcat.util.net.AbstractEndpoint.logCertificate
[https-jsse-nio-8443], TLS virtual host [_default_], Certificate type 
[RSA] configured from [conf/localhost-rsa.jks] using alias [null] and 
with trust store [null]


?


How about also including the cert fingerprint?

I think that's a very helpful item to include.

-chris


-Original Message-
From: Christopher Schultz 
Sent: Monday, January 9, 2023 8:10 AM
To: users@tomcat.apache.org
Subject: Re: Basic SSL Certificate Usage logging

Jon,

On 1/6/23 15:53, jonmcalexan...@wellsfargo.com.INVALID wrote:

Thanks for the info.

In a nutshell I think the certpath,provider would be sufficient. I'm
thinking that I can add this to the java options as
-Djava.security.debug=ssl:certpath,provider however I don't know how
to specify where to log the information.
java.security.debug is really a blunt instrument. It's unfortunate 
that it's one
of the only ways to get information out of the TLS stack. It would 
have been
great if Java had started using its own logging system once it was 
introduced,

but no.

That debugging tool always dumps to stdout (or stderr?) and you have 
very

little control over where it goes.

You would never want to use it for ongoing logging. It truly is for 
debugging-

only.

The good news is that application code should be able to get the 
information

you are looking for.

Oh, wait...


[...] I'm checking to see if there is any out-of-the-box option to
capture in a log which SSL certificate and trust keystore is being
used during startup?
What do you mean "during startup"? I originally read that as "for 
incoming

connections" thinking that you wanted to log which cert was used for a
particular request. But it sounds like maybe you are asking for 
something to

just be logged one-time during startup?

-chris



Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged 
information. If you
are not the addressee or authorized to receive this for the 
addressee, you
must not use, copy, disclose, or take any action based on this 
message or any
information herein. If you have received this message in error, 
please advise
the sender immediately by reply e-mail and delete this message. 
Thank you

for your cooperation.



-Original Message-
From: Christopher Schultz 
Sent: Friday, January 6, 2023 2:41 PM
To: users@tomcat.apache.org
Subject: Re: Basic SSL Certificate Usage logging

Mark,

On 1/6/23 15:00, Mark Thomas wrote:

Hi Jon,

In a word, no. Sorry.

Some sort of info log message probably makes sense for this. SNI
makes things a little more complicated but we should be able to do

something.

What is the minimum info you'd like to see?


How about adding a request attribute with some kind of identifier 
(fpr?
serial-number?) in it and indicates at least which server-cert was 
chosen.

Then it can trivially be added to e.g. access_log or even to
application code which wants to do custom logging.

-chris


On 06/01/2023 18:52, jonmcalexan...@wellsfargo.com.INVALID wrote:

Good afternoon and Happy New Year,

I know about the SSL debug logging, however, I'm checking to see if
there is any out-of-the-box option to capture in a log which SSL
certificate and trust keystore is being used during startup?

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508





jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged 
information.

If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action
based on this message or any information herein. If

Re: Possibilities for fetching config information from Kubernetes

2023-01-10 Thread Rémy Maucherat

On Tue, Jan 10, 2023 at 3:11 PM Christopher Schultz
 wrote:
>
> Mark,
>
> On 1/10/23 03:22, Mark Thomas wrote:
> > On 09/01/2023 22:17, Christopher Schultz wrote:
> >> All,
> >>
> >> I'm aware that there is a k8s manager for clustering
> >> (CloudMembershipService) but I was wondering if / how that could be
> >> extended in order to provide any other types of automated
> >> configuration information for a Tomcat installation.
> >>
> >> For example, I'd love to be able to deploy a Tomcat node and have it
> >> grab its primary database connection information from k8s.
> >>
> >> I spent like 5 minutes reading through the CloudMembershipService and
> >> KubernetesMembershipProvider classes and it seems to be all bundled
> >> together and very geared toward fetching cluster information.
> >>
> >> It seems that most of the KubernetesMembershipProvider.start method
> >> could be moved into a separate support class which just manages k8s
> >> connection information (e.g. fetching from the environment, building
> >> URLs to various interesting paths, wrapping fethcing-and-JSON-parsing,
> >> etc.) and that could be re-used for a parameter-resolver for XML
> >> config files like we can do for system properties like
> >>
> >> 
> >>
> >> It occurs to be that we should be able to do something like this:
> >>
> >> 
> >>
> >> ... and write a resolver that fetches that value on the fly.
> >> (Hopefully it would cache stuff, so that a dozen different
> >> environmental references don't have to be resolved separately.)
> >
> > Isn't this why ServiceBindingPropertySource was contributed? I only
> > dabble with k8s very occasionally but my understanding is that this is
> > the 'proper' way to pick up config in a k8s environment.
>
> Yeah, I think you are right. I hadn't noticed that class before, and it
> looks like it doesn't interact with k8s (or similar) in any way: it just
> assumes that the orchestration framework has already dropped a cache of
> useful configuration files onto the system before the service is launched.
>
> It looks like the KubernetesMembershipProvider needs to be separate from
> that because it actually has to communicate directly with k8s for, well,
> membership services. It's not just reading configuration values.
>
> So, I guess... nothing to see here!

The KubernetesMembershipProvider is the cleanest way to access the
Kube namespace. Then you can use it to list the pods (as here) or
pretty much anything else. There's a problem though: it needs the
token to connect to the service account (= configuration !) *and*
configure the appropriate permissions in Kube to allow the desired
access (= annoying configuration !). I liked it because once it works
it is predictable and reliable.

DNSMembershipProvider is an equivalent to get the list of pods with
far less configuration. However it uses DNS which is prone to
"issues".

So basically yeah, you would need to write a PropertySource that does
somewhat the connection and json parsing that
KubernetesMembershipProvider does. I don't see how the processing can
be generic for everything that is in the Kube namespace, so it would
allow access to some specific values. The problem then is that
security configuration (in Kube) will still be horrible. But it could
work eventually.

In KubernetesMembershipProvider, the connection with the token to the
service account is generic. The URL used in the Kube namespace is
hardcoded. And the json parsing is obviously specific to processing
the list of (running) pods in the cluster.

Rémy

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

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

Re: Having two servers and controlling my secondary server with the primary server

2023-01-10 Thread Olaf Kock




On 09.01.23 18:12, Mark Thomas wrote:

Your mentor is wrong.

Mark

To elaborate on that: When one server is down, its configuration will be 
inactive as well. There's nothing that this non-running server will be 
able to do for you. You'll need to externalize the decision which 
server's responses to serve to /some/ external entity



Olaf




On 09/01/2023 14:56, Manisha Chermadurai wrote:

Thanks for this.

I have set up the solution for failover using nginx as a proxy server
between my two tomcat servers. But my mentor told with only using tomcat
server's configuration files, you can redirect the requests to another
server if and only if the particular server is down. So I am 
searching for
this solution, and came to know about this group. So I requested 
about this

, may be I will get some ideas.

Really thanks for response.

On Mon, 9 Jan 2023, 8:21 pm Olaf Kock,  wrote:


On 09.01.23 15:22, Manisha Chermadurai wrote:

Good evening Sir,


I am trying to control my secondary server with the primary server of

mine.

Bothe are of versions 9.0. Primary server has been available in my

physical

machine and my secondary server is in virtual machine. Both are of

windows

10. I am connecting the vm's 8080 port through the ip address from

primary

machine. It works fine. But I have a doubt like , Can I create my

secondary
server without allocating port ? I have tried it works fine, but 
there is
no entry point for my server. I have doubt of creating a comnector 
for my
vm's server from my primary server and the condition is also like I 
have

to
create a connector for my secondary server and it can be accessible 
only
when my primary server is down. I have researched and tried many 
things

for

literally 2 weeks. But I got stuck in this. So, once again I repeat my
question,  it's I have to create a connector for my secondary 
server by

my
primary server and it will be only accessible when my primary 
server is
down.So my client won't get chance to connect my secondary server 
through
the ip and port. I have tried failover with nginx. But I want to 
try this

only with my server.xml file.


If I understand your use case correctly, I'd recommend to set up a load
balancer that handles the failover.

Other options depend on the scenario you're looking for: Should your
secondary server be a hot-backup for the primary one (e.g. immediate
failover with no downtime?) or a cold backup that get started only when
some component determines that the primary server went down?

You will need to configure a Connector (with a port) on both servers if
you want to be able to access them.

And I'd recommend to either use some orchestration for it, or just
manually configure your second server. Tomcat itself is not the tool of
choice to configure one server through another one. There are 
components

that allow you to distribute deployed web applications (e.g.
https://tomcat.apache.org/tomcat-9.0-doc/config/cluster-deployer.html),
but that's a different use case than what you're asking for.

If you absolutely want to work around a load balancer, you might be 
able

to do some trickery with firewall-level redirection, but I'd say that
this is less transparent than explicitly configuring a load balancer.

Olaf






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






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



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

Re: Basic SSL Certificate Usage logging

2023-01-10 Thread Mark Thomas


On 10/01/2023 13:52, Christopher Schultz wrote:

Jon,

On 1/9/23 18:17, jonmcalexan...@wellsfargo.com.INVALID wrote:

Yes Chris, It's just for during startup. For a particular instance I
would like to capture the Certificate Info and Truststore being used
and pipe that into a separate log/txt file.
So it sounds like just dumping-out the configured certificates, etc. to 
something like the debug log from Connector or SSLHostConfig or similar 
would work?


Or would you want that information available to the application so you 
can log it in some very specific way? Note that you can already get the 
SSLHostConfig info via JMX if you are willing to do that.


How about something like this:

10-Jan-2023 14:21:07.951 INFO [main] 
org.apache.tomcat.util.net.AbstractEndpoint.logCertificate
[https-jsse-nio-8443], TLS virtual host [_default_], Certificate type 
[RSA] configured from [conf/localhost-rsa.jks] using alias [null] and 
with trust store [null]


?

Mark



-chris



Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. 
If you are not the addressee or authorized to receive this for the 
addressee, you must not use, copy, disclose, or take any action based 
on this message or any information herein. If you have received this 
message in error, please advise the sender immediately by reply e-mail 
and delete this message. Thank you for your cooperation.



-Original Message-
From: Christopher Schultz 
Sent: Monday, January 9, 2023 8:10 AM
To: users@tomcat.apache.org
Subject: Re: Basic SSL Certificate Usage logging

Jon,

On 1/6/23 15:53, jonmcalexan...@wellsfargo.com.INVALID wrote:

Thanks for the info.

In a nutshell I think the certpath,provider would be sufficient. I'm
thinking that I can add this to the java options as
-Djava.security.debug=ssl:certpath,provider however I don't know how
to specify where to log the information.
java.security.debug is really a blunt instrument. It's unfortunate 
that it's one
of the only ways to get information out of the TLS stack. It would 
have been
great if Java had started using its own logging system once it was 
introduced,

but no.

That debugging tool always dumps to stdout (or stderr?) and you have 
very

little control over where it goes.

You would never want to use it for ongoing logging. It truly is for 
debugging-

only.

The good news is that application code should be able to get the 
information

you are looking for.

Oh, wait...


[...] I'm checking to see if there is any out-of-the-box option to
capture in a log which SSL certificate and trust keystore is being
used during startup?
What do you mean "during startup"? I originally read that as "for 
incoming

connections" thinking that you wanted to log which cert was used for a
particular request. But it sounds like maybe you are asking for 
something to

just be logged one-time during startup?

-chris



Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. 
If you
are not the addressee or authorized to receive this for the 
addressee, you
must not use, copy, disclose, or take any action based on this 
message or any
information herein. If you have received this message in error, 
please advise
the sender immediately by reply e-mail and delete this message. Thank 
you

for your cooperation.



-Original Message-
From: Christopher Schultz 
Sent: Friday, January 6, 2023 2:41 PM
To: users@tomcat.apache.org
Subject: Re: Basic SSL Certificate Usage logging

Mark,

On 1/6/23 15:00, Mark Thomas wrote:

Hi Jon,

In a word, no. Sorry.

Some sort of info log message probably makes sense for this. SNI
makes things a little more complicated but we should be able to do

something.

What is the minimum info you'd like to see?


How about adding a request attribute with some kind of identifier 
(fpr?
serial-number?) in it and indicates at least which server-cert was 
chosen.

Then it can trivially be added to e.g. access_log or even to
application code which wants to do custom logging.

-chris


On 06/01/2023 18:52, jonmcalexan...@wellsfargo.com.INVALID wrote:

Good afternoon and Happy New Year,

I know about the SSL debug logging, however, I'm checking to see if
there is any out-of-the-box option to capture in a log which SSL
certificate and trust keystore is being used during startup?

Thanks,

Dream *

Re: Possibilities for fetching config information from Kubernetes

2023-01-10 Thread Christopher Schultz


Mark,

On 1/10/23 03:22, Mark Thomas wrote:

On 09/01/2023 22:17, Christopher Schultz wrote:

All,

I'm aware that there is a k8s manager for clustering 
(CloudMembershipService) but I was wondering if / how that could be 
extended in order to provide any other types of automated 
configuration information for a Tomcat installation.


For example, I'd love to be able to deploy a Tomcat node and have it 
grab its primary database connection information from k8s.


I spent like 5 minutes reading through the CloudMembershipService and 
KubernetesMembershipProvider classes and it seems to be all bundled 
together and very geared toward fetching cluster information.


It seems that most of the KubernetesMembershipProvider.start method 
could be moved into a separate support class which just manages k8s 
connection information (e.g. fetching from the environment, building 
URLs to various interesting paths, wrapping fethcing-and-JSON-parsing, 
etc.) and that could be re-used for a parameter-resolver for XML 
config files like we can do for system properties like




It occurs to be that we should be able to do something like this:



... and write a resolver that fetches that value on the fly. 
(Hopefully it would cache stuff, so that a dozen different 
environmental references don't have to be resolved separately.)


Isn't this why ServiceBindingPropertySource was contributed? I only 
dabble with k8s very occasionally but my understanding is that this is 
the 'proper' way to pick up config in a k8s environment.


Yeah, I think you are right. I hadn't noticed that class before, and it 
looks like it doesn't interact with k8s (or similar) in any way: it just 
assumes that the orchestration framework has already dropped a cache of 
useful configuration files onto the system before the service is launched.


It looks like the KubernetesMembershipProvider needs to be separate from 
that because it actually has to communicate directly with k8s for, well, 
membership services. It's not just reading configuration values.


So, I guess... nothing to see here!

Thanks,
-chris

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

Re: Basic SSL Certificate Usage logging

2023-01-10 Thread Christopher Schultz


Jon,

On 1/9/23 18:17, jonmcalexan...@wellsfargo.com.INVALID wrote:

Yes Chris, It's just for during startup. For a particular instance I
would like to capture the Certificate Info and Truststore being used
and pipe that into a separate log/txt file.
So it sounds like just dumping-out the configured certificates, etc. to 
something like the debug log from Connector or SSLHostConfig or similar 
would work?


Or would you want that information available to the application so you 
can log it in some very specific way? Note that you can already get the 
SSLHostConfig info via JMX if you are willing to do that.


-chris



Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


-Original Message-
From: Christopher Schultz 
Sent: Monday, January 9, 2023 8:10 AM
To: users@tomcat.apache.org
Subject: Re: Basic SSL Certificate Usage logging

Jon,

On 1/6/23 15:53, jonmcalexan...@wellsfargo.com.INVALID wrote:

Thanks for the info.

In a nutshell I think the certpath,provider would be sufficient. I'm
thinking that I can add this to the java options as
-Djava.security.debug=ssl:certpath,provider however I don't know how
to specify where to log the information.

java.security.debug is really a blunt instrument. It's unfortunate that it's one
of the only ways to get information out of the TLS stack. It would have been
great if Java had started using its own logging system once it was introduced,
but no.

That debugging tool always dumps to stdout (or stderr?) and you have very
little control over where it goes.

You would never want to use it for ongoing logging. It truly is for debugging-
only.

The good news is that application code should be able to get the information
you are looking for.

Oh, wait...


[...] I'm checking to see if there is any out-of-the-box option to
capture in a log which SSL certificate and trust keystore is being
used during startup?

What do you mean "during startup"? I originally read that as "for incoming
connections" thinking that you wanted to log which cert was used for a
particular request. But it sounds like maybe you are asking for something to
just be logged one-time during startup?

-chris



Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com
This message may contain confidential and/or privileged information. If you

are not the addressee or authorized to receive this for the addressee, you
must not use, copy, disclose, or take any action based on this message or any
information herein. If you have received this message in error, please advise
the sender immediately by reply e-mail and delete this message. Thank you
for your cooperation.



-Original Message-
From: Christopher Schultz 
Sent: Friday, January 6, 2023 2:41 PM
To: users@tomcat.apache.org
Subject: Re: Basic SSL Certificate Usage logging

Mark,

On 1/6/23 15:00, Mark Thomas wrote:

Hi Jon,

In a word, no. Sorry.

Some sort of info log message probably makes sense for this. SNI
makes things a little more complicated but we should be able to do

something.

What is the minimum info you'd like to see?


How about adding a request attribute with some kind of identifier (fpr?
serial-number?) in it and indicates at least which server-cert was chosen.
Then it can trivially be added to e.g. access_log or even to
application code which wants to do custom logging.

-chris


On 06/01/2023 18:52, jonmcalexan...@wellsfargo.com.INVALID wrote:

Good afternoon and Happy New Year,

I know about the SSL debug logging, however, I'm checking to see if
there is any out-of-the-box option to capture in a log which SSL
certificate and trust keystore is being used during startup?

Thanks,

Dream * Excel * Explore * Inspire
Jon McAlexander
Senior Infrastructure Engineer
Asst. Vice President
He/His

Middleware Product Engineering
Enterprise CIO | EAS | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508





jonmcalexan...@wellsfargo.com

This message may

Re: Problems with requests without trailing slash Tomcat 9.0.65

2023-01-10 Thread Mark Thomas


On 10/01/2023 04:37, Fedor Makarov wrote:


Also I tried to write a filter to manually redirect, but tomcat intercepts the 
request before it gets into the filter. Can I disable this behavior for tomcat 
and do it manually?


That isn't the way to solve this problem. The problem is in the reverse 
proxy configuration and that is where you need to fix it.


You previously provided the following set of rules:

RewriteCond %{REQUEST_URI} ^(/api/|/mapi/|/binary/|/rpc/invoker/)

RewriteRule ^/rpc/invoker/(.*)$ http://localhost:9090/rpc/invoker/$1 
[NC,P,L]

RewriteRule ^/api/(.*)$ http://localhost:9090/api/$1 [NC,P,L]
RewriteRule ^/mapi/(.*)$ http://localhost:9090/mapi/$1 [NC,P,L]
RewriteRule ^(.*)$ http://localhost:9090/lundase/$1 [NC,P,L]

I'll note that the RewriteCond appears to be unnecessary.

I'll further note that the NC flag appears to be unnecessary. As is the 
L flag (P implies L).


We can help you fix these rules but when we tried you mentioned 
"vvsguiden" but that does not appear in the rewrite rules.



mod_rewrite isn't necessarily the best way to configure a reverse proxy 
but if that is what you are familiar with, we can work with it. What we 
do need, regardless of how the reverse proxy is configured, is a 
complete list of the mappings you want to implement.


To re-iterate Chris's earlier point, trying to change the context path 
for an application in a reverse proxy is asking for trouble. It is far 
better to reconfigure the contexts in Tomcat so the reverse proxy 
doesn't need to change the URI path.


Based on the paths above, you need to redeploy lundase.war as ROOT.war 
and then the rewrite rules become:


RewriteRule ^(.*)$ http://localhost:9090/$1 [P]

We need more details for "vvsguiden" to figure out why the above won't work.

Mark




   

Понедельник, 9 января 2023, 11:43 +03:00 от Fedor Makarov 
:
  



We have to webapps lundase and vvsguiden therefore, the options you have 
suggested do not look applicable on debug I saw that RequestURI in request 
looks like lundase/lundase/...
  

Вторник, 27 декабря 2022, 22:06 +03:00 от Christopher Schultz < 
ch...@christopherschultz.net >:
  
Fedor,


On 12/27/22 05:55, Fedor Makarov wrote:


proxy for local environment we use the js conf:
proxy: {
     '/api/': {
       target: 'http://localhost:8080/',
       changeOrigin: false,
     },
     '/': {
       target: 'http://localhost:8080/lundase',
       changeOrigin: false
     }
   },

for normal lunch we use apache2.conf:

RewriteCond %{REQUEST_URI} ^(/api/|/mapi/|/binary/|/rpc/invoker/)

RewriteRule ^/rpc/invoker/(.*)$ http://localhost:9090/rpc/invoker/$1 [NC,P,L]
RewriteRule ^/api/(.*)$ http://localhost:9090/api/$1 [NC,P,L]
RewriteRule ^/mapi/(.*)$ http://localhost:9090/mapi/$1 [NC,P,L]
RewriteRule ^(.*)$ http://localhost:9090/lundase/$1 [NC,P,L]


What you are doing is trying to remove the context-path of the
application through URL re-writing which will probably cause endless
problems during the life of your application.

I have two possible suggestions for you:

1. Re-name your application from lundase to ROOT (to deploy it to /
instead of /lundase).

or

2. Don't try to remove the /lundase URL prefix as part of your URL
rewriting.

If you don't choose one or the other of these options, you will find
that you have many years of debugging and trying to fix up every little
weird thing that happens with cookies, redirects, and in-page links.

-chris


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

Fedor Makarov
   
  
  
---

Fedor Makarov
  


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

Re: Possibilities for fetching config information from Kubernetes

2023-01-10 Thread Mark Thomas


On 09/01/2023 22:17, Christopher Schultz wrote:

All,

I'm aware that there is a k8s manager for clustering 
(CloudMembershipService) but I was wondering if / how that could be 
extended in order to provide any other types of automated configuration 
information for a Tomcat installation.


For example, I'd love to be able to deploy a Tomcat node and have it 
grab its primary database connection information from k8s.


I spent like 5 minutes reading through the CloudMembershipService and 
KubernetesMembershipProvider classes and it seems to be all bundled 
together and very geared toward fetching cluster information.


It seems that most of the KubernetesMembershipProvider.start method 
could be moved into a separate support class which just manages k8s 
connection information (e.g. fetching from the environment, building 
URLs to various interesting paths, wrapping fethcing-and-JSON-parsing, 
etc.) and that could be re-used for a parameter-resolver for XML config 
files like we can do for system properties like




It occurs to be that we should be able to do something like this:



... and write a resolver that fetches that value on the fly. (Hopefully 
it would cache stuff, so that a dozen different environmental references 
don't have to be resolved separately.)


Isn't this why ServiceBindingPropertySource was contributed? I only 
dabble with k8s very occasionally but my understanding is that this is 
the 'proper' way to pick up config in a k8s environment.


Mark




Does that sound useful to anyone? I've never used k8s but I'm looking at 
making a service of mine easier to deploy in a totally automated way, 
and this kind of thing would certainly help with that.


-chris

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



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

Re: Tomcat 10.1.4 HTTP Status 404 and 500 Help

Re: Tomcat 10.1.4 HTTP Status 404 and 500 Help

RE: Basic SSL Certificate Usage logging

Re: Basic SSL Certificate Usage logging

Re: Question about Redisson

Re: Question about Redisson

Tomcat 10.1.4 HTTP Status 404 and 500 Help

RE: Basic SSL Certificate Usage logging

RE: Basic SSL Certificate Usage logging

Re: Possibilities for fetching config information from Kubernetes

Re: Basic SSL Certificate Usage logging

Re: Possibilities for fetching config information from Kubernetes

Re: Having two servers and controlling my secondary server with the primary server

Re: Basic SSL Certificate Usage logging

Re: Possibilities for fetching config information from Kubernetes

Re: Basic SSL Certificate Usage logging

Re: Problems with requests without trailing slash Tomcat 9.0.65

Re: Possibilities for fetching config information from Kubernetes

18 matches

Site Navigation

Mail list logo

Footer information