Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 1/8/20 12:35 PM, James H. H. Lampert wrote: > On 1/8/20 5:18 AM, Christopher Schultz wrote: . . . >> Now the URL line becomes (for me, using a management port): >> >> http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtoco lHa >> >> ndler,port%3D8215=reloadSslHostConfigs > . . . >> Have you configured any elements, or are you >> using the old-style configuration like: >> >> > > I just have a connector definition in server.xml, almost exactly > the same as I've been using in Tomcat 7 installations. I don't > think prior to this discussion, I'd even *heard* of > "SSLHostConfig." > >> You may need to change your connector configuration to use >> nested elements if it's not that way already. >> >> Try invoking the "findSslHostConfigs" operation to see if it >> completes. That will at least tell you if you have your >> objectname correct. >> >> Like this: >> >> $ curl -k -u "test:test" >> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto col >> >> Handler,port%3D8443,address%3D127.0.0.1=findSslHostConfigs" > > This gave me a stacktrace: >> curl -k -u "test:test" >> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto colHandler,port%3D8443,ad >> >> >> dress%3D127.0.0.1=findSslHostConfigs" > > But omitting the address parameter, as in your own test, gave me > this: >> curl -k -u test:test >> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto colHandler,port%3D8443& >> >> >> op=findSslHostConfigs" >> OK - Operation findSslHostConfigs returned: >> org.apache.tomcat.util.net.SSLHostConfig@1a9b80c2 > >> curl -k -u test:test >> "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProto colHandler,port%3D8443& >> >> >> op=reloadSslHostConfigs" >> OK - Operation reloadSslHostConfigs without return value > > And I just now confirmed that the latter did indeed reload the > keystore when I swapped between the regular keystore and a > self-signed one, even though I just have the old-style connector > definition. > > So apparently, it was the "address" parameter that was killing me. > Interesting. > > The idea was to put the Tomcat server on the same certificate and > private key files as the httpd server on the same EC2 box. Do I > need this newfangled "SSLHostConfig" for that? > > At any rate, I think we have another breakthrough here, but at the > same time, I think I also need to disable the "test" user, and get > back to another project I have going, at least for now. Glad you got it working. The next releases of Tomcat will give you a better error message from JMXProxyServlet in cases like these. No more NPEs. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4WXLQACgkQHPApP6U8 pFgVRw/+O3zCPWww0FgzSp46NIkqh50j6bGwu95N9mM9r43DNHZ4XOBNoZ/04khc 0otFGF0xnCvXX/3s3RPvYHeV+ZggMhtb8Sd/IZjHAWArVPC1+iXOlydIniaqXeJ5 jEvF4fu67FVLIFRz625gHVGrERwIfUM4om7qo3KYaOOA8+KQY/pCEZGPqMV90FRy Dx2n2ifLEwSFV9lq1yDaqelhW2YgvqaAaoocRoRBaEBnWtgMl+vAtTpWTCFk5bwM iH2mgdc9DIUawjLpIjuCsXb7AlAI4GrB4ATSpMIcvHNkyWSubxvm9PpdYSbwR4vQ N5QJGOdYbpNdY9kylyKi5AteS0IpCBD+iXwTn5QJIxwarIlluIj9pGhZbibumg9M JhwzLpyK90OF6lFlNNWLuc5frC8R2rJFEWCPwGPwml7V8RCzNi8YzTi13UyyaMJi 1wa6uyICKGJIWexyz5sLG/Juo9wDqZzojN4Bxl2AxMWHDpN6M/fXMeesB3B5ScKg kBoHf+1SZTjD5j61QarkyUgfskgG7oH+PaZkQNudggZ/QghuuSmSHjGcIECbRaiC oSWdlv2acRs5eExXu5PedLrQO66HoecMlOA1Sl/B5gajlZCerhTEBqLq6ebwIefF U4sQsBwmwfwo6U1wd0377nTGj/+zWV31BqXfAP3cZ/duyo9g9kA= =oXVx -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
On 1/8/20 5:18 AM, Christopher Schultz wrote: . . . Now the URL line becomes (for me, using a management port): http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa ndler,port%3D8215=reloadSslHostConfigs . . . Have you configured any elements, or are you using the old-style configuration like: I just have a connector definition in server.xml, almost exactly the same as I've been using in Tomcat 7 installations. I don't think prior to this discussion, I'd even *heard* of "SSLHostConfig." You may need to change your connector configuration to use nested elements if it's not that way already. Try invoking the "findSslHostConfigs" operation to see if it completes. That will at least tell you if you have your objectname correct. Like this: $ curl -k -u "test:test" "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocol Handler,port%3D8443,address%3D127.0.0.1=findSslHostConfigs" This gave me a stacktrace: curl -k -u "test:test" "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443,ad dress%3D127.0.0.1=findSslHostConfigs" But omitting the address parameter, as in your own test, gave me this: curl -k -u test:test "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443; op=findSslHostConfigs" OK - Operation findSslHostConfigs returned: org.apache.tomcat.util.net.SSLHostConfig@1a9b80c2 curl -k -u test:test "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocolHandler,port%3D8443; op=reloadSslHostConfigs" OK - Operation reloadSslHostConfigs without return value And I just now confirmed that the latter did indeed reload the keystore when I swapped between the regular keystore and a self-signed one, even though I just have the old-style connector definition. So apparently, it was the "address" parameter that was killing me. Interesting. The idea was to put the Tomcat server on the same certificate and private key files as the httpd server on the same EC2 box. Do I need this newfangled "SSLHostConfig" for that? At any rate, I think we have another breakthrough here, but at the same time, I think I also need to disable the "test" user, and get back to another project I have going, at least for now. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 1/7/20 8:24 PM, James H. H. Lampert wrote: > On 1/7/20 4:19 PM, Christopher Schultz wrote: > >> You probably "spelled" something incorrectly. It might be a >> quoting/escaping issue. It might be a literal misspelling/typo. >> >> The JMXProxyServlet shouldn't NPE like that, though. >> >> I'll take a look and see if we can give you a better error >> message than that when it happens. > > Well given that (1) there's no production data at stake, (2) you > don't know where this server is, (3) the test user will be removed > permanently and replaced with something else once this problem is > resolved, and (4) the test user will never be active if I'm not > running actual tests, there's no reason to censor the curl call. > > curl -k -u test:test > https://localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProto colHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostCon figs > > > > > I tried it with or without quote marks around the URL; I tried it > both with the user in a "-u" clause, as above, or with the user > prefixing the domain. In all four cases, I get what appears to be > the exact same stacktrace as before. You will absolutely have to quote the whole URL, otherwise the embedded "&" character will cause the shell to do weird things. In a local VisualVM, I grabbed the path to a random protocol handler. The JMX bean object name was: Catalina:type=ProtocolHandler,port=8215 I'm only missing the address portion, because I haven't set any address in the configuration. I don't believe any of those characters need to be escaped except for the "=" because the object name needs to be a parameter value. That would give me: Catalina:type%3DProtocolHandler,port%3D8215 Now the URL line becomes (for me, using a management port): http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa ndler,port%3D8215=reloadSslHostConfigs This gives me the same stack trace as you; same line numbers, etc. In my case, I have no SSL configured, so maybe I can't reload those configs for some reason. If I call an arbitrary other method, it works: http://localhost:8217/manager/jmxproxy?invoke=Catalina:type%3DProtocolHa ndler,port%3D8215=findSslHostConfigs OK - Operation findSslHostConfigs returned: There is no other output. So there aren't any SSLHostConfigs. Have you configured any elements, or are you using the old-style configuration like: ? You may need to change your connector configuration to use nested elements if it's not that way already. Try invoking the "findSslHostConfigs" operation to see if it completes. That will at least tell you if you have your objectname correct. Like this: $ curl -k -u "test:test" "https://localhost:8443/manager/jmxproxy?invoke=Catalina:type%3DProtocol Handler,port%3D8443,address%3D127.0.0.1=findSslHostConfigs" > I can't tell any difference, other than the user, and specifying a > port, between that and the "hard-coded" curl call on slide 35 of > the presentation. And if I leave out the port number, I get > "connection refused." > > FYI, the relevant lines in tomcat-users.xml (with the actual admin > user definition redacted) are: > >> >> [line redacted] > roles="manager-gui,manager-jmx"/> Your role is fine, now. You would have gotten a 401 response if you didn't have the right credentials. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4V1okACgkQHPApP6U8 pFgdjw//SJZPMvvfo322JDngUr6Sdv5MAmV0rfJZ0CQYmQ54LnhAIVX4I3TsgXae OwDtoQqi9tBk/1qhv9a9GZneXfox28FFb8PiTcwmUSAMcJfzoNFAESqC1HPZGqtD ET+cNXAde7N4bfaV/+HJGkTUEl5Ze2SBnONBxaBwMQgSUiYCwfr9iv/K2LIpGnjt PdCts7/XuvGmbWLsZFUpR6tWOwVYUGjXlT042mBegJPQoHkabAFv0xknrgk8oKaD bUKk2MSB/KZvR6Pzeq+pltSsjoE4C5zMx04gmMndcD7costp+1l2gXk7yOuC2qlI IRY3LxfI2qIstxcbX9DeuPuQcR0NBsUCcC4CNfBldJy2MEexiwlYp61JPwWr51f3 2gR9MKO11uAlVI1+xXXUsd5wTaXWOvAniphhO35ef88iLsNKQCEo24XhC0x9fYX9 MvbOMFO6w5jlslnrfTxSJyqMm1MT/uBnhoZx1lGHwTswF2/Zp9VDSgOiFCzNLkc9 UfRd+KY/Bk3pDkkkQ3BvEjLg/Lirudtaa9xTjfHDjpEIOUXFsYmALY9cqBvocrtF BVJIMUrvv4LlzzOtFXEqhnr5nh9HZJR9+3AggY0yy3gqa3fdiSli/I3JZNfYBSWx c0XR/sex2+vMeIAL+F89Bwp5AV5Q3ncs5Dp8xYIHnCx8yRd2eDo= =Yj+m -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
On 1/7/20 4:19 PM, Christopher Schultz wrote: You probably "spelled" something incorrectly. It might be a quoting/escaping issue. It might be a literal misspelling/typo. The JMXProxyServlet shouldn't NPE like that, though. I'll take a look and see if we can give you a better error message than that when it happens. Well given that (1) there's no production data at stake, (2) you don't know where this server is, (3) the test user will be removed permanently and replaced with something else once this problem is resolved, and (4) the test user will never be active if I'm not running actual tests, there's no reason to censor the curl call. curl -k -u test:test https://localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs I tried it with or without quote marks around the URL; I tried it both with the user in a "-u" clause, as above, or with the user prefixing the domain. In all four cases, I get what appears to be the exact same stacktrace as before. I can't tell any difference, other than the user, and specifying a port, between that and the "hard-coded" curl call on slide 35 of the presentation. And if I leave out the port number, I get "connection refused." FYI, the relevant lines in tomcat-users.xml (with the actual admin user definition redacted) are: [line redacted] -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 1/7/20 1:33 PM, James H. H. Lampert wrote: > This just gets weirder and weirder. > > I added manager-jmx to the admin account. I continued to get "401 > unauthorized." > > I then tried setting up another user, temporarily, with a > URL-friendly user-ID and password. If I just gave that user > "manager-gui," I got "403 access denied" instead, regardless of > whether I put the user-ID and password into the URL, or into a -u > clause. > > But then, when I tried adding "manager-jmx" to the temporary user, > I got a null pointer exception! > >> java.lang.NullPointerException at >> org.apache.catalina.manager.JMXProxyServlet.invokeOperationInternal(J MXProxyServlet.java:264) >> >> >> at >> org.apache.catalina.manager.JMXProxyServlet.invokeOperation(JMXProxyS ervlet.java:207) >> >> >> at >> org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.jav a:116) >> >> >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:635) >> at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:231) >> >> >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:166) >> >> >> at >> org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52 ) >> >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:193) >> >> >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:166) >> >> >> at >> org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCh aracterEncodingFilter.java:109) >> >> >> at >> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl icationFilterChain.java:193) >> >> >> at >> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF ilterChain.java:166) >> >> >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperV alve.java:199) >> >> >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextV alve.java:96) >> >> >> at >> org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentica torBase.java:610) >> >> >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.j ava:137) >> >> >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.j ava:81) >> >> >> at >> org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAcce ssLogValve.java:660) >> >> >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVal ve.java:87) >> >> >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.jav a:343) >> >> >> at >> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java :798) >> >> >> at >> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLig ht.java:66) >> >> >> at >> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(Abstract Protocol.java:808) >> >> >> at >> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpo int.java:1498) >> >> >> at >> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBas e.java:49) >> >> >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1149) >> >> >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:624) >> >> >> at >> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskTh read.java:61) >> >> >> at java.lang.Thread.run(Thread.java:748) > > What I have on this box is Tomcat 8.5.40, under JVM 1.8.0_201-b09 > > Anybody know what's wrong now? You probably "spelled" something incorrectly. It might be a quoting/escaping issue. It might be a literal misspelling/typo. The JMXProxyServlet shouldn't NPE like that, though. I'll take a look and see if we can give you a better error message than that when it happens. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4VICUACgkQHPApP6U8 pFgpHRAAquY32hPePQt4UBarAvgr1WkryFCoHXO+thEvVtpOj6/S/GBS3L6+Hxlu muT90BbQsFy4fhGM7cmSSeC44GQB5FV0EXiMskDnlqohM0BwgiwGUEVaXW9L7UwA G4KrOCRzYdgzjpdEmS2k1s71bcarawKD2sA7EB/GFmIZjTDj1Lgs66hGNNXsyy4e vrWAYWpp3omSh40a5Z5+ROwOvyjI6hgft33UXFwZbbGQdTmpbx5Y8f9mTRnhh8R0 EMq1Olu9ONsbOi0SPHb4/8DHoBIT4cHgrBtV8mqX3MrSn91D55rVouZzmyOttgXO txdH4mku8z8rr/C7+A8NG/Uc2R3YfH4tzYvzum+DavhL6HQ3N+Ob4GcRWwzR/RXN D35zI4trxtELYpnwJ3nNnSms9J79CIO/jfODubsRlWmBQuKcDww4sWyHQGvMbMGZ JW1MjCywXdcuKe9DXynxkTjjbbJktQEsszBhaFptJBzg7iG1BJXQmgXG70npj1pc FZiqvyKF7fATkZLEeumYmeKzKAb3F2M8l8ZuInscaiBWwHskb6JNkKeZNzvMdiGn kZibenXy78dhaYaldXrTzea7DYHFUdzaEL/1vRh6tdYM8OMHQBF+YIa41A5ICrPY Tx5Oav1yO9QQpsgu+BYjxrrK536g6ezLc8d7HjXh6lmq5K+CFHc= =jukF -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
This just gets weirder and weirder. I added manager-jmx to the admin account. I continued to get "401 unauthorized." I then tried setting up another user, temporarily, with a URL-friendly user-ID and password. If I just gave that user "manager-gui," I got "403 access denied" instead, regardless of whether I put the user-ID and password into the URL, or into a -u clause. But then, when I tried adding "manager-jmx" to the temporary user, I got a null pointer exception! java.lang.NullPointerException at org.apache.catalina.manager.JMXProxyServlet.invokeOperationInternal(JMXProxyServlet.java:264) at org.apache.catalina.manager.JMXProxyServlet.invokeOperation(JMXProxyServlet.java:207) at org.apache.catalina.manager.JMXProxyServlet.doGet(JMXProxyServlet.java:116) at javax.servlet.http.HttpServlet.service(HttpServlet.java:635) at javax.servlet.http.HttpServlet.service(HttpServlet.java:742) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:109) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:610) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:660) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343) at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:798) at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66) at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:808) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1498) at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) What I have on this box is Tomcat 8.5.40, under JVM 1.8.0_201-b09 Anybody know what's wrong now? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
James,
On 1/6/20 9:10 PM, James H. H. Lampert wrote:
> Dear Mr. Schultz, et al.:
>
> The manager password on this Tomcat server has an embedded curly
> brace, and an embedded question mark.
>
> If I do this (the names have been changed to protect the innocent,
> and the -k!)
>
>> curl -k
>> "https://foo:b?a{r@localhost:8443/manager/jmxproxy?invoke=Catalina%3A
type%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=relo
adSslHostConfigs"
>>
>
>>
> I get curl: (3) [globbing] unmatched brace in column xx
>
> If I change the curly brace to "%7B," I get:
>
>> curl -k
>> "https://foo:b?a%7Br@localhost:8443/manager/jmxproxy?invoke=Catalina%
3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=re
loadSslHostConfigs"
>>
>
>>
> I get curl: (3) Port number ended with 'n'
>
> And if I put the user-ID and password in with a -u clause on curl,
> rather than in the URL itself, I get "Unauthorized."
>
> What is wrong here? Are there characters it simply can't tolerate
> in passwords, even if URL-escaped?
>
> Or do I need to give the manager user an additional role?
> Currently, I have: roles="manager-gui"/>
You need another role. The role necessary for jmxproxy is "manager-jmx".
- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl4Up+EACgkQHPApP6U8
pFjy0xAAmwbNbBSnW5mydxPPSD5OXyJW13wmLtZy2BoMyV5E6HR9wu/u79i27VbI
qfNoIMk3K1wAKNTzuBOtM+cUgXaiFBZeehXuN9lF2AvqiOnp948n3JXrY2JvAovk
Adr3tsx+21nZgNVaVTsEezdKcad+odCRVWER52eVKdnz8In3oh4bWXOEcHQ6T22o
/o+JvQY0kjrRFGMWGHGUu7EvtzM+zawf3RDMuRD2xdhMv3MWhH5o5nrt4DalglUU
qhvZQ5RfVcjMNC43clCjdRhoz7hhCAkf6GTCkqQmVGW0KYP4x8yGxM2NFV0ft8Vc
/DJiy3h3rX6j4lE1c7XXDksUqfPx70h8RJ1ApzcYumXrGxHDUsvYzkuzsGQCBMSF
5qo1lRCgK+qaITNuc9nZIhKdtai3iojjCUr0VNN9+3wI61rNBlncPyIRrNJR2pS7
m6IeML1cKxE7c4sWr7Th4egM+NOX65E4oyv1X6vqpWZYL5TrB2Eys+zcPdG981KI
OF06FybbBW4XDpyv9ECTE9gmtqiw0LYLTz8bg9ytRqOfCgSCmUxVzIc9CTk0glgZ
3AJA8QElFlibnORB7rD1nagDBO4VYmcSXnttHrXf47jjtchWEF+cI24IUUZnbWKb
+yVgFfBJS4mqIIe7IvxYjL2I2bMTx+FWGf7erAm+/WYbMt8DAEE=
=bHGS
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
James,
> Am 07.01.2020 um 03:11 schrieb James H. H. Lampert :
>
> Dear Mr. Schultz, et al.:
>
> The manager password on this Tomcat server has an embedded curly brace, and
> an embedded question mark.
>
> If I do this (the names have been changed to protect the innocent, and the
> -k!)
>
>> curl -k
>> "https://foo:b?a{r@localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs;
>
> I get curl: (3) [globbing] unmatched brace in column xx
>
> If I change the curly brace to "%7B," I get:
>
>> curl -k
>> "https://foo:b?a%7Br@localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs;
>
> I get curl: (3) Port number ended with 'n'
>
> And if I put the user-ID and password in with a -u clause on curl, rather
> than in the URL itself, I get "Unauthorized."
>
> What is wrong here? Are there characters it simply can't tolerate in
> passwords, even if URL-escaped?
I‘d prefer them in -u.
for separation of concerns, add a separate user with a longer one and shell
friendly password only with the role below...
> Or do I need to give the manager user an additional role? Currently, I have:
>
manager-jmx
(and maybe for other script-actions manager-script)
Peter
> --
> JHHL
>
> -
> 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: Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
https://stackoverflow.com/questions/17560858/command-prompt-having-trouble-escaping-quotes-and-braces
You can use curl -g to turn off globbing:
On Tue, 7 Jan 2020, 02:11 James H. H. Lampert,
wrote:
> Dear Mr. Schultz, et al.:
>
> The manager password on this Tomcat server has an embedded curly brace,
> and an embedded question mark.
>
> If I do this (the names have been changed to protect the innocent, and
> the -k!)
>
> > curl -k "https://foo:b?a{r@localhost
> :8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs"
>
> I get curl: (3) [globbing] unmatched brace in column xx
>
> If I change the curly brace to "%7B," I get:
>
> > curl -k "https://foo:b?a%7Br@localhost
> :8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs"
>
> I get curl: (3) Port number ended with 'n'
>
> And if I put the user-ID and password in with a -u clause on curl,
> rather than in the URL itself, I get "Unauthorized."
>
> What is wrong here? Are there characters it simply can't tolerate in
> passwords, even if URL-escaped?
>
> Or do I need to give the manager user an additional role? Currently, I
> have:
>
>
> --
> JHHL
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>
Curl problem with reloadSslHostConfigs, Re: Let's Encrypt with Tomcat?
Dear Mr. Schultz, et al.:
The manager password on this Tomcat server has an embedded curly brace,
and an embedded question mark.
If I do this (the names have been changed to protect the innocent, and
the -k!)
curl -k
"https://foo:b?a{r@localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs;
I get curl: (3) [globbing] unmatched brace in column xx
If I change the curly brace to "%7B," I get:
curl -k
"https://foo:b?a%7Br@localhost:8443/manager/jmxproxy?invoke=Catalina%3Atype%3DProtocolHandler%2Cport%3D8443%2Caddress%3D%22127.0.0.1%22=reloadSslHostConfigs;
I get curl: (3) Port number ended with 'n'
And if I put the user-ID and password in with a -u clause on curl,
rather than in the URL itself, I get "Unauthorized."
What is wrong here? Are there characters it simply can't tolerate in
passwords, even if URL-escaped?
Or do I need to give the manager user an additional role? Currently, I have:
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
