log4j2 configuration in Tomcat 8.5.8
It's a little bit frustrating to configure Tomcat 8.5.8 with log4j2.
I put the following jars in $CATALINA_HOME/lib
log4j 2 core (log4j-core-2.6.2.jar)
log4j 2 api (log4j-api-2.6.2.jar)
Delete the file $CATALINA_HOME/conf/logging.properties
Put the new log4j 2 config file (log4j2.xml) in $CATALINA_HOME/lib
%d %p %c{1.} [%t] %m%n
No errors but the created catalina.out file is empty and the console layout
doesn't change
What else to check or change?
THX Frank
Re: [OT] Using iptables to remap port 443 -> 8443 for localhost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 12/4/16 3:30 PM, Christopher Schultz wrote: > All, > > I'm aware of various techniques to allow Tomcat to serve from port > 80 without using root, but I've never actually tried using them > before. > > I'm trying to use iptables on a bare-metal Linux server running > kernel 3.2 and I'm having no luck. > > I've already got iptables doing other things for me, but adding > this should not be interfering. > > Here's what I've done (following [1]): > > > $ sudo /sbin/iptables -I FORWARD -p tcp \ --destination-port 443 -j > ACCEPT $ sudo /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p > tcp \ --destination-port 443 --to-ports 8443 > > So here are my tables, now: > > $ sudo iptables-save | grep "\(FORWARD\|PREROUTING\)" :PREROUTING > ACCEPT [10:1392] -A PREROUTING -p tcp -m tcp --dport 443 -j > REDIRECT --to-ports 8443 :FORWARD ACCEPT [0:0] -A FORWARD -p tcp -m > tcp --dport 443 -j ACCEPT -A FORWARD -j LOG > > $ telnet localhost 8443 Trying 127.0.0.1... Connected to > localhost. Escape character is '^]'. ^C Connection closed by > foreign host. > > (connects) > > cschultz@europa:~$ telnet localhost 443 Trying 127.0.0.1... telnet: > Unable to connect to remote host: Connection refused > > (fails) > > Oddly enough, both ports 8443 and 443 are accessible from the > outside: > > elsewhere$ telnet myhost 8443 Trying 204.9.143.102... Connected to > europa.chadis.com. Escape character is '^]'. ^CConnection closed by > foreign host. > > elsewhere$ telnet myhost 443 Trying 204.9.143.102... Connected to > europa.chadis.com. Escape character is '^]'. ^CConnection closed by > foreign host. > > Do I need to do something different in order to allow "localhost" > connections to be PREROUTED? > > Thanks, -chris Looks like PREROUTING is ignored for localhost connections... OUTPUT must be used instead: $ sudo iptables -t nat -I OUTPUT -p tcp -o lo \ --dport 443 -j REDIRECT --to-ports 8443 I'm going to add this to the wiki, just in case anyone else is puzzled as to why localhost doesn't work given the existing instructions. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYRH3AAAoJEBzwKT+lPKRYXkwP/RJ4KUBrRgzphrBg/IZfpbFQ qkS59nAM7BZB6RyjSl3bbxAOIUGZ6+Yar0sKJcWTzx6DdSKYK4tedEz4zc7NWK+o z5UK9k6FU+c7Qi+4ibbT3XoViwCc9m4c+8fuwbhinkEt84dbMN8CZp7+WZmzym66 RsIKU9pWjCifLSA0bXg6wPrPmIJ4yIrP3p41Y/UIeFxPfXSdXpjl7C/G7QOhrMIi op1Db9h0lUn6HG/zQSeDZ9fWlWrXjdk2Q8nsESLWGYR3ihz1Aso8eQ9tJnJia1dJ Ph+6l9u5Y5/LePMwCOJOGvL5SYhz2wsDaBSItLu7mONqMJLNXGydlm5WxE5KR4xr FsUqFrQysctmhc6VuprYhPXvmic9hcxCW1B0Eu4+1nuOLziO7xJKn4haRoRldzg7 7T7FqcP8WVxSBJeLS/SC6NAayBSDYoehE/Qn9qgzmEQFgohtxONu661b2LqoWdxJ 7G1K3ili0txg2ew3drj1JCZjPIClRmxpYbs5SC3W6Jrye5dJRGqIL9fAG53s44rM uXQxcsv48XXqpX06P7Oq47K8Z2zAotEQl8zufoDEEWxCHCzvZ+FbAWacTOE8OT/K uhGfmJkTu4IH2H7EdwsnfkTPGNw02qmoti8Yt/t5bpV6/idL4MwnSqWQMGzI2+af ZPC+N6ekZ5ry8JsdorhZ =ARK1 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[OT] Using iptables to remap port 443 -> 8443 for localhost
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, I'm aware of various techniques to allow Tomcat to serve from port 80 without using root, but I've never actually tried using them before. I'm trying to use iptables on a bare-metal Linux server running kernel 3.2 and I'm having no luck. I've already got iptables doing other things for me, but adding this should not be interfering. Here's what I've done (following [1]): $ sudo /sbin/iptables -I FORWARD -p tcp \ --destination-port 443 -j ACCEPT $ sudo /sbin/iptables -t nat -A PREROUTING -j REDIRECT -p tcp \ --destination-port 443 --to-ports 8443 So here are my tables, now: $ sudo iptables-save | grep "\(FORWARD\|PREROUTING\)" :PREROUTING ACCEPT [10:1392] - -A PREROUTING -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443 :FORWARD ACCEPT [0:0] - -A FORWARD -p tcp -m tcp --dport 443 -j ACCEPT - -A FORWARD -j LOG $ telnet localhost 8443 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. ^C Connection closed by foreign host. (connects) cschultz@europa:~$ telnet localhost 443 Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused (fails) Oddly enough, both ports 8443 and 443 are accessible from the outside: elsewhere$ telnet myhost 8443 Trying 204.9.143.102... Connected to europa.chadis.com. Escape character is '^]'. ^CConnection closed by foreign host. elsewhere$ telnet myhost 443 Trying 204.9.143.102... Connected to europa.chadis.com. Escape character is '^]'. ^CConnection closed by foreign host. Do I need to do something different in order to allow "localhost" connections to be PREROUTED? Thanks, - -chris [1] https://wiki.apache.org/tomcat/HowTo#How_to_run_Tomcat_without_root_priv ileges.3F -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYRHzLAAoJEBzwKT+lPKRYOfEP/At/1Wc598mYz5jJ3qOQrMIP +YZD0pIEy9s2LHwIWCnxRExHCaaQUvPH6ARWI3IdpYSfdSJO0vAzi0szXcZLxA3Y v68sd1ZbBiF/ik8jDS4wshtSqOiw3JNSQZTfwNP118OKEzC3g4ip8wf3ieEyhC+2 w2r4Xz43aJ6eDJWiSgG+AFzUBKK8HWF8JhYIGQNdNYGa2Ri54oWEAlrqqTq0GpfL dUuSGWEk6UqdC7EBR8qQeEjhehVhYnhP5Zje0eOlfdxmMsjSYYG7aPvPeLYL7GlW IPcVe9qc/FmY8fYqydJNU/gLIeGb9tdambJe0nLPs2Xg5qBSeZ8Hcz6n/7us3g1Z nOsX2PQwlwXBjuh6xlBRkxHUq/P739nkBjf6jQdpX0ffQksmMtMUcO+DYTRsB8zF M4hmGUSfjYbskfDCf9iNLHc/qjaoy+oO8h/AbFc0GC6eqZICPr61zXbbItOtRRzz m2eMituyGtLnVxoC3Kr7axneXKeneiJPS4xabwm4UF1RjAZznOMyT16/i2d/r40g XbOal8PFFg8m9esk3J0RqWoZw29uoC7DnwqTkR2PNIPxRZOdNQUrddxbHwAE3Jmi HBADi9Z0+znZI/Prq9kp3rkAHyuksrpw/j1XzV/L0kJiI6t79nXLdOwjLWD3IMVo mSMjvWlRH05HsSrzBgkT =yi01 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector bindOnInit=false not behaving as expected
On 04/12/2016 20:09, Christopher Schultz wrote: > All, > > On 12/1/16 6:07 PM, Christopher Schultz wrote: >> All, > >> On 12/1/16 5:59 PM, Christopher Schultz wrote: >>> All, > >>> I'm trying to use JMX to do things with Tomcat Connectors and >>> ProtocolHandlers. Specifically, I'd like to re-load the keystore >>> (really certificate) used for an HTTPs connection. > >>> I'm currently using Tomcat 8.0.30 for my testing. > >>> It looks like the ProtocolHandler is really the place where the >>> TLS configuration is taking effect, and not the Connector, so >>> I'm largely ignoring the Connector for now. Is that the right >>> choice to make, here? It depends. What you actually need to do is swap out the SSLContext. This is in the SSLHostConfigCertificate. >>> It seems that calling the pause()/resume() or stop()/start() on >>> the ProtocolHandler have no effect on resetting the >>> SSLServerSockeyFactory, which is what would be required to >>> achieve my goals (update a certificate for a running Tomcat >>> instance). You need new code to do this if you want to handle it smoothly. Failing that, you need to trigger bind(). Which means: bindOnInit=false start() stop() change TLS config stop() * drop existing connections, new connections fail here * this is generally a Bad Thing (tm) start() new TLS config available >>> I suspect I'll have to call init(). When I do this without >>> specifying bindOnInit=false awful things happen. First, calling >>> init() gets me an error on stdout that the address is already in >>> use, and then it's basically not possible to restart the >>> ProtocolHandler after that point: it's dead as far as I can >>> tell, because you can't call start() or resume() without getting >>> a whole bunch of errors. You can't just call nay method you like. You have to respect the standard Lifecycle state transitions even though Endpoint doesn't enforce them (the Interface and supporting base classes are not visible to the package. >>> Does that sound like a problem to anyone? I would think that >>> failure to call init() would leave the ProtocolHandler in an >>> uninitialized state, but I'm wondering if trying to >>> RE-initialize the ProtocolHandler should be something that won't >>> damage a previously-initialized component. When trying to script >>> these types of connections, having a non-destructive init() might >>> be useful. This is not a problem. >>> So, I set bindOnInit="false" which is documented[1] to unbind on >>> "stop". When calling stop(), the port continues to be bound by >>> Tomcat. Calling stop() and then start() throws a BindException. >>> :( Destroying the ProtocolHandler also leaves the port still >>> bound, and also (unsurprisingly) destroys the ProtocolHandler. That sounds like a possible problem but we have unit tests that explicitly test this behaves as expected (TestXxxEndpoint) so a Tomcat bug looks unlikely. >>> Stopping the Connector also does not release the port. :( Calling >>> stop() and then start() also throws a BindException. > >>> At this point, I think I'm stuck. Is there a bug here? > >>> I'm going to upgrade to 8.0.latest and repeat my tests, just in >>> case. > >> I updated to 8.0.39 and noticed that I had moved my keystore out >> of the way temporarily and so the connector was failing at some >> point looking for that. I'll be repeating my tests with more >> attention to detail, but what I think I've noticed is that there >> are certain errors which can occur that cause the Connector to get >> itself into a bad state. > >> Specifically, I think that problems with the crypto setup cause >> the connector to bind to the port, then fail and not unbind. Any >> later attempt to re-start the Connector fails because the port is >> still bound. > >> I think the connector should catch (some?) exceptions and unbind >> the port in those cases when bindOnInit=false. > > Any comments on whether or not these items should be considered bugs? > Specifically, uncaught exceptions which can prevent the connector from > coming back up again? If you find a sequence where start-up fails due to bad config and puts the connector in a start where it can't be started once the config has been fixed then that is probably a bug but likely only a minor one. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector bindOnInit=false not behaving as expected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 All, On 12/1/16 6:07 PM, Christopher Schultz wrote: > All, > > On 12/1/16 5:59 PM, Christopher Schultz wrote: >> All, > >> I'm trying to use JMX to do things with Tomcat Connectors and >> ProtocolHandlers. Specifically, I'd like to re-load the keystore >> (really certificate) used for an HTTPs connection. > >> I'm currently using Tomcat 8.0.30 for my testing. > >> It looks like the ProtocolHandler is really the place where the >> TLS configuration is taking effect, and not the Connector, so >> I'm largely ignoring the Connector for now. Is that the right >> choice to make, here? > >> It seems that calling the pause()/resume() or stop()/start() on >> the ProtocolHandler have no effect on resetting the >> SSLServerSockeyFactory, which is what would be required to >> achieve my goals (update a certificate for a running Tomcat >> instance). > >> I suspect I'll have to call init(). When I do this without >> specifying bindOnInit=false awful things happen. First, calling >> init() gets me an error on stdout that the address is already in >> use, and then it's basically not possible to restart the >> ProtocolHandler after that point: it's dead as far as I can >> tell, because you can't call start() or resume() without getting >> a whole bunch of errors. > >> Does that sound like a problem to anyone? I would think that >> failure to call init() would leave the ProtocolHandler in an >> uninitialized state, but I'm wondering if trying to >> RE-initialize the ProtocolHandler should be something that won't >> damage a previously-initialized component. When trying to script >> these types of connections, having a non-destructive init() might >> be useful. > >> So, I set bindOnInit="false" which is documented[1] to unbind on >> "stop". When calling stop(), the port continues to be bound by >> Tomcat. Calling stop() and then start() throws a BindException. >> :( Destroying the ProtocolHandler also leaves the port still >> bound, and also (unsurprisingly) destroys the ProtocolHandler. > >> Stopping the Connector also does not release the port. :( Calling >> stop() and then start() also throws a BindException. > >> At this point, I think I'm stuck. Is there a bug here? > >> I'm going to upgrade to 8.0.latest and repeat my tests, just in >> case. > > I updated to 8.0.39 and noticed that I had moved my keystore out > of the way temporarily and so the connector was failing at some > point looking for that. I'll be repeating my tests with more > attention to detail, but what I think I've noticed is that there > are certain errors which can occur that cause the Connector to get > itself into a bad state. > > Specifically, I think that problems with the crypto setup cause > the connector to bind to the port, then fail and not unbind. Any > later attempt to re-start the Connector fails because the port is > still bound. > > I think the connector should catch (some?) exceptions and unbind > the port in those cases when bindOnInit=false. Any comments on whether or not these items should be considered bugs? Specifically, uncaught exceptions which can prevent the connector from coming back up again? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJYRHgQAAoJEBzwKT+lPKRYwzgP/3BlD2DnNa5ZJwpX1Wcl9JXe 3Oj2zgUbv0z9qExmAYfuIYYpyUiIiGoO0oJIo9r4sGjCSeQg/GWv/w9q03YlCKOE U/+t4FH2UZ0W15x27PF1j1TSMna8Heq2Wysqp3ccgyX4E3BGcOxTE6RwE9MQI3+e aduTjtw4Wy34jh426pX4ilSxgagHPDXeqsuvUsbt5nS8FGizK0fMqYvcIfpfpfCx F+BYGKi5ZkafhyrkXyCGzdL8XzpAFDC8Vx2bqQGYAGrsDmP4S7xQwHhMPoG4T0xN bB98jV7MMJTxb+P4Yog+xN1t3MnpsgCtztW6TxVflSc+fm6mPy+9NGgN7D3vLSHw EWZSR9AzuLQwNRI8hqubNoLIXT0ddoG3zZ4CP6YtMbtCN9qIGmby9idCM2mEoarp oBpQL+rvcvQs3qJU9KsVOV3YXjNPsHciXquI8HrvaqwMPaSf3NRHR897OZOwapjX IHV6/8K2yqL2t3UXoOS87O/94cCZb5g/XPA/QZO8ljF6M7rDKE8omR7XcbMoyW9p 4Dm2RSiUm7nqn2Eto7p2fKlQ10iK4bdeQ/6q4nLuMMEQ/Nmh6pRPt9Jgz8A8goTZ k/xSQJg+5Pij/fg76StfkLWULdVSm6tUkW9CPPzqEvdPWZeEOn6KBQ9m4d0S80Ro 9MMGOsmaWRf6TfEkwmkB =Arwu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help On Tomcat Process which is utilizing more than 300%
Am 04.12.2016 um 07:37 schrieb Jayaram Ponnusamy: Dear All, I am new to Tomcat We are using Tomcat 7.0.42 with JVM 1.7.0_40-b43 on Rhel 6 (8 Core CPU). Suddenly tomcat process start utilizing more than 300% and our website performance went down. I couldn't find anything in the Log. Kindly please help me to resolve this issue. One approach would be to take a couple of thread dumps, when this happens and look for threads that are doing work at that time. (Look for "Thread Dump" on https://wiki.apache.org/tomcat/HowTo) Another problem could be garbage collections, that are using too much cpu. (You could look at http://www.tomcatexpert.com/blog/2011/11/16/setting-measurement-garbage-collection-apache-tomcat or google yourself a bit) If you want to get a better picture of the threads that are running, I would recommend to use the jdk tools jconsole, jvisualvm or the newer jmc. Regards, Felix - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat Realm/LDAP - userRoles and Organization Unit name for authenticated users
Am 04.12.2016 um 08:04 schrieb Taylor, Larry:
Hello,
For Users that have authenticated from the Web Login page through Tomcat
Realm LDAP configuration is it possible to get the authenticated user's
ou=Organizational Unit or Department name? and also what their role names
are? I need this information to pass to a servlet or jsp page.
I saw documentation about the java.security.Principal class but could not find
any documentation or examples on how to get this type of information after
users are authenticated.
I am able to get the username with ${pageContext.request.userPrincipal.name} &
request.getRemoteUser(); but nothing about how to get the user's member
affiliations and roles.
The standard way to get the roles is to iterate over your expected roles
and ask for request.isUserInRole(role). The servlet spec has no API to
get directly a list of roles.
If you are willing to bind yourself to the implementation of JNDIRealm
you could get the list of roles. But I don't recommend it, as that
implementation is not guaranteed to stay stable.
Do you really need to get the list, or is isUserInRole enough?
Regards,
Felix
Any information or pointers on this is appreciated.
Larry Taylor
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
