----- Original Message ----- > From: "Christopher Schultz" <ch...@christopherschultz.net> > To: users@tomcat.apache.org > Sent: Thursday, December 5, 2019 5:05:42 PM > Subject: Re: Tomcat - No Fork for debugging? > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Alex, > > On 12/5/19 15:18, Alex Scheel wrote: > > Hi all, > > > > I've tried searching to no avail. > > > > I'm working on a(nother) SSL adapter. However, I've had some issues > > with it. There's a native component and I'm trying to tease apart > > its relationship with why the client won't handshake. The stack > > traces aren't overly helpful and I'd love to attach gdb to this and > > set a few specific environment variables. > > > > Query: > > > > Does Tomcat have a mode where it won't fork to a different user and > > will run with a limited number of threads? That'd greatly improve > > my ability to debug. Something similar to `radiusd -X` or `sshd > > -d`? > > You can accomplish this in two steps: > > 1. Change your <Connector> to have an <Executor> with only a single > thread, or set maxThreads="1" on the <Connector> if you aren't > separately configuring an <Executor> > > 2. From the command line, run: > > $ bin/catalina.sh run
I think that behaves better. Thanks! > or > > X:> bin\catalina.bat run > > This will run Tomcat directly in the terminal window (or, on Windows, > open a second terminal window where it will run). > > You can see stdout in that terminal, and you can press CTRL-C to kill > the process. > > > Rationale: > > > > NSS has support for logging calls to its PKCS#11 interface to a > > file, based on the presence of environment variables. When I set > > these environment variables and directly call the JVM to start > > Tomcat: > > > > # java -classpath $CLASSPATH $FLAGS > > org.apache.catalina.startup.Bootstrap start > > > > I see it logging calls when the JDK starts up, but when I hit it > > with wget on the TLS port, the resulting PKCS#11 calls aren't > > logged. When launching in gdb, I get an error about /sbin/nologin > > doesn't understand the -c option, which to me says that Bootstrap > > is trying to fork and create a new shell (I'm running as root in a > > VM and it wants to launch as the tomcat user), dropping my > > environmental variables I want. > > > > Ideally (for debugging) I'd like to simplify this. Is there a more > > direct entry route I can use perhaps? > > Is there a JSSE wrapper for NSS? You can just plug-in the crypto > provider for the SSLContext instead of writing your own connector. > Wait. You said "adapter". What kind of "adapter" are you writing? Ah sorry, my terminology was loose there. I'm writing another org.apache.tomcat.util.net.SSLImplementation implementation. Heh. I'm the maintainer of JSS, a NSS wrapper in Java. This is mostly utilized by the Dogtag project. I also co-maintain TomcatJSS, a JSS adapter for Tomcat < 8.5. When used with Tomcat >= 8.5, it uses JSSE's SSLEngine but initializes JSS based on configuration in server.xml and use it for the keystore. Mostly this is because we've not yet gotten around to adding a SSLEngine to JSS (but will likely finish that work soon -- JSS was started at Netscape back in the late 90s and predated the SSLEngine being added to JVM interfaces in JDK version 5). RHEL 7 still ships with Tomcat 7, but RHEL 8 only has Tomcat 9, so the hard requirement for a SSLEngine is new. We're getting there :) With FIPS certification requirements though, we can't use JSSE (since it isn't FIPS certified). OpenJDK supports NSS via the Sun-PKCS11 provider and has a SSLEngine implementation under the SunJSSE provider. It has some restrictions on it that means it can't be used from Tomcat's JSSE adapter just by swapping out the provider name (for one, wrapping the KeyManager like Tomcat does isn't allowed). I was trying to see if the JDK's SSLEngine would work for us. On RHEL, we FIPS certify our shipped NSS release so the JDK's Sun-PKCS11-NSS-FIPS provider is FIPS certified transitively (since it does no crypto... :). Since I'm not a Tomcat developer (and am more familiar with TomcatJSS), I stubbed out a new SSLImplementation that uses SunJSSE so I could bypass the parts of the Tomcat JSSEImplementation that don't work with the JDK SunJSSE provider. However, currently on RHEL the SunJSSE provider is a bit broken, so this FIPSImplementation isn't really useful. If you're interested, I'd like to get Tomcat to a place where it supports FIPS mode JDK without the need for a separate implementation, but first I need a working FIPS-mode JDK (currently it doesn't handshake)... ...and we're probably going the route of finishing JSS anyways. HTH, - Alex > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3pfzUACgkQHPApP6U8 > pFjVLRAAulhpc4XyarJTFJQ3Iru2MM+X3LrFCmcvpuPLI/j/UXFtEKRh6Wqgx6s1 > yt9E++3LvQvBFaL/NO5a2LDncS186SjUliMorrF4Yc3f0Cc5iaCgzaZe4uyj4RIg > MYidArw56r+FViY2DnHxBLzN4uqANYdnFVGonMei9puvJmBsoQk9LNSOl2RuRJiI > +zg1tjUyjcoSPC9mR/hYk3CI+H2N9FoKKvpkYQKHzyUG+sz4yRSJkx9VfMKHzfAF > xU6DZpKyNRI9Oes4W+B0FMBWF0+nH67O1QI6nnqSjeOuyJcr51kZBswk0kA1iDlJ > 6iAAMp++rB7sSof5PMNId6yKTcda4djolUwFuhoyphORDhd2N8B1VfwVqdo1c2Z1 > vT/8smDjcLiCmW52avY066ujxr3F4BSkXmCCelncfCVpa/uj9hAx1Oaic97bPmJG > KZSijm2kTPRMa6DhvHHg1GmcAvmzfwdpr6YBhxBUJpR+3ZhT+luQpRxvRJREFqnP > pNVICNZ/hWzrtc3gHMZJEH7mcTHKgwU9gD/ctDLnZ7qN5r6LBBfsy17Y/oTnydPN > bJ4/CAMZNVxJMyoew00ZixnCyzRB82QNs2cQClVssSbih5765YEJ/AfssCkcDAZh > rPxcWcu+tWWJiih1NW4oGIxvAXc4jn8h8/c+C6R7iCnTuXuJmz4= > =2O0L > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > 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
