Mark, On 11/25/15 6:44 PM, Mark Thomas wrote: > On 25/11/2015 22:38, George Sexton wrote: >> Mark, >> >> On 11/24/2015 4:11 PM, Mark Thomas wrote: >>> All, >>> >>> As promised, today's webinar "Apache Tomcat 9: HTTP/2 Quick Start" is >>> now available on the Apache Tomcat YouTube channel: >>> >>> https://www.youtube.com/channel/UCpqpJ0-G1lYfUBQ6_36Au_g >> >> I watched the video and I have two comments. First, I'm really excited >> about SNI support. For my particular use-case, it's going to be really >> nice. >> >> Second, for my use case, I deploy hundreds ( like 700+ on one server >> right now) of virtual hosts. I deploy and un-deploy hosts kind of >> randomly depending on things that are happening. I use the host-manager >> application to deploy/undeploy virtual hosts. At startup time, I have a >> script that generates the host entries to a file, and then I include >> that file within server.xml using an entity expansion. >> >> I'm trying to understand how I could dynamically deploy a new host with >> an SSL certificate. Since the certificate configuration seems to be >> getting done at the connector, it "looks" to me like deploying a host >> with a new certificate (or changed certificate) would require >> re-starting the connector (tomcat). That would be really painful for me, >> forcing me to delay cert changes until maintenance times. > > You are correct, that - currently - a Connector restart would be required. > >> I wish that configuration was more consolidated. Right now (and if I'm >> doing this wrong, let me know), I have the generated host snippet that >> gets included in server.xml. Then, I have >> $CATALINA_BASE/conf/Catalina/hostname/context.xml which contains the >> context docBase, and access log valve configuration. Now, I'm looking at >> a 3rd thing with the certificates named in the Connector entry. Is there >> any way that .pem files that are in >> $CATALINA_BASE/conf/Catalina/hostname could be auto-loaded for that >> virtual host? I'm just kind of brainstorming. > > The separation of the Host element and the SSLVirtualHost element was > bugging me slightly, as was the duplication of the default host > information. This is a good use case for trying to come up with > something better / consolidated.
I'd like to point-out that this is no more painful than doing the same operation on Tomcat 7 or 8... you still need to restart the connector if you want to change something about the TLS configuration. I just wanted to make it clear that this isn't any kind of loss of capabilties or a regression or anything. I suppose the Connector could "search" through the configured <Host>s looking for one that had a name (or alias) matching the SNI name in the TLS handshake, and then looking for an appropriate SSLHostConfig (or whatever) configuration to go with it. That would slow-down the handshake ever so slightly. This is all new stuff, and so it doesn't have the support yet for fancy re-configuration at runtime, yet. This is good feedback. What if adding a <Host> at runtime -- either directly, programatically, or by using JMX/some other technique -- could also add an SSLHostConfig to wherever is appropriate? So, if we were to move SSLHostConfig from the Connector to the Host itself, or leave it where it is, Tomcat could take-care of the complexity there for you? >> Also, just thinking out >> loud, it would be really nice if Tomcat automatically found a host >> configuration xml file in $CATALINA_BASE/conf/Catalina/hostname so that >> I don't have to do the kind of ugly hack of the entity inclusion which >> has it's own problems (picture JSVC restart after deploying new host). > > We'd need to think about naming, otherwise there will be the potential > for the file being treated as a context file. +1 Instead of using conf/Catalina/[hostname].xml (or similar), we could use a subdirectory: conf/Catalina/hosts/[hostname].xml The "hosts" subdirectory should never be confused with a context deployment descriptor. >> I appreciate your thoughts, and if I'm doing something the hard way, any >> suggestions you might have. > > I can't think of a better way right now. I'll see what I can come up > with. It is probably worth creating an enhancement request in Bugzilla > against 9.0.x with the info you provided above. +1 This was a milestone release with a "1.0" waaaay down the line -- mostly because of the fact that we have to wait-around for the Servlet and other related specifications to be finalized -- so I think we have plenty of time to change our minds about things. I've had many occasions to talk to Mark about Tomcat use versus implementation and he's made it perfectly clear to me that he is neither an application developer nor an administrator, so he's not a good resource for coming up with real-world requirements. That is, he's not a "user" of Tomcat and therefore not in a great position to be able to guess what the best way for users to use Tomcat would be. That's where we -- the users and the community -- come in: *we* are a much better resource for that kind of thing, so we can tell the committers what we need. I'm mostly reiterating my assertion from above that "this is good feedback". So please, continue this conversation with us, because it will result in a better product for everyone. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
