Re: Question regarding tomcat random number seeding and startup times
I changed securerandom.source=file:/dev/random in /jre/lib/security/java.security, changing this to urandom and it vastly improved things. My question is, what will this do? I don't really rely on the tomcat generated session affinity .. On 7/28/19, John Dale wrote: > Greetings; > > I found this in the logs where it's hanging-up: > > 28-Jul-2019 19:05:10.520 WARNING [main] > org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom > Creation of SecureRandom instance for session ID generation using > [SHA1PRNG] took [212,424] milliseconds. > > Thoughts? > > John > > > On 7/27/19, Christopher Schultz wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> John, >> >> On 7/27/19 19:49, John Dale wrote: >>> Greetings Everyone; >>> >>> A quick update to the folks who I have interacted with on the list >>> (you know who you are and I thank you). >>> >>> I got all of my applications and sites migrated from Tomcat 7.x.x >>> to Tomcat 9.x running on Ubuntu 18.04 and Java 8. Lots of fun work >>> with the firewalls, databases, and email servers (DKIM, SPF, and >>> DMARC are something else). >>> >>> Overall, I was kind of disappointed to find out that Java 11 >>> doesn't include activation and jax libs, but it sure was fast once >>> I included these things in my lib folder. That said, I thought it >>> might be better to revert to Java 8, which bundles and unit tests >>> these libraries. So, that's what I did. >>> >>> But yikes .. the startup times are now very slow .. sometimes two >>> minutes. I understand that this might relate to the need of the >>> JVM to initialize for random number seeding. Is this true? >> >> What makes you say that? It might be correct, but you are just >> providing a guess, here. >> >>> What other strategies should I be looking at to make the bounce >>> more zippy? I deploy two smallish war files (<5MB, about 160KB >>> Java Services code) >> >> Note that the size of the code is largely irrelevant. >> >>> I noticed several recommendations for different random number >>> seeding strategies, but they came with warnings relative to the >>> quality of encryption. What else might be done that doesn't >>> compromise encryption quality? >> >> Most modern JVMs (on Linux) use /dev/urandom as a source of entropy by >> default which is safe enough to use for probably everything but >> long-loved encryption keys (e.g. multi-year-valid RSA/EC keys, PGP >> keys, etc.). You probably shouldn't be generating long-lived keys of >> these kinds from within a Tomcat-hosted application. /dev/urandom is >> non-blocking so it shouldn't stall when grabbing entropy for things >> like random-number seeding (which are used by Tomcat for both random >> session-id generation and random TLS bulk-encryption keys. >> >>> I would like to push back my Java 11 upgrade until I have a good >>> longer term strategy for jax and activation libraries. Thoughts? >> >> Why not simply bundle those required libraries with your application? >> >>> Glad to have made it through the upgrade .. it really wasn't very >>> painful at all. >> >> Glad to hear it wasn't painful. >> >> - -chris >> -BEGIN PGP SIGNATURE- >> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ >> >> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl09KVgACgkQHPApP6U8 >> pFhPew/+JpMBI7y27lkZdvD61QoWWVYQm4VrsVu9iCGMSSznSPdVSROgvupjtF1Z >> QCuTRLTOGdxWC1RuNMg47chtUiRtUnS/dIaCscN9AYSzqKvyGkGdW97S0cdTZnHy >> plSRqsep4RkoseyFPBrLHRy3FU8po8Bt+2L3btCSwVK6pcp4GNVkywqF9/gkAJVp >> uAL5Pyy57SY84sdHyCxxYeo9iO3Jtg3UVVQzGJzaFJ3bhCQcQO/50CNbsTMutGYJ >> sJFOAWL6vQhnojIH2PAm6fqQ2e0XF+RmZh5Kf0+Jsl3VjBxw1C5wzyixcK9NvKxq >> vdxG2Cs9YGpYiLLmF5Diz0JU7rTWfz/A0jalNt8Fr6y2HS65rFSlWsTsjlmjpl14 >> b1hEw/o+vtRwJ3e+HEbTelnOXzaZU4HhlaiDkd43EcWOUyicvlEuAToQHMou5N68 >> uKjP5/AdrDvGuSdAxCRrnAmAsOP4P0XMXoG9n6tHoTRy6L+3eh01h931lsFlxlYy >> dOly8rOzDwE80x5BzugDw9I9Rotg0U0mGzogNzs9thG/1rrBzdUdWNDcWvJLaEkT >> joKGlScnB/gEisV2NT2DEB4E8q9kf6BoypSVMhzOTQ9KDnIq6cau7dtfXWwusODt >> St7SCCJtAsxMtici5HihZvuf+CDVpuZ5+PD3KWSuFjSxrwrl1Es= >> =Qhtz >> -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
Re: Question regarding tomcat random number seeding and startup times
Greetings; I found this in the logs where it's hanging-up: 28-Jul-2019 19:05:10.520 WARNING [main] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [212,424] milliseconds. Thoughts? John On 7/27/19, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > John, > > On 7/27/19 19:49, John Dale wrote: >> Greetings Everyone; >> >> A quick update to the folks who I have interacted with on the list >> (you know who you are and I thank you). >> >> I got all of my applications and sites migrated from Tomcat 7.x.x >> to Tomcat 9.x running on Ubuntu 18.04 and Java 8. Lots of fun work >> with the firewalls, databases, and email servers (DKIM, SPF, and >> DMARC are something else). >> >> Overall, I was kind of disappointed to find out that Java 11 >> doesn't include activation and jax libs, but it sure was fast once >> I included these things in my lib folder. That said, I thought it >> might be better to revert to Java 8, which bundles and unit tests >> these libraries. So, that's what I did. >> >> But yikes .. the startup times are now very slow .. sometimes two >> minutes. I understand that this might relate to the need of the >> JVM to initialize for random number seeding. Is this true? > > What makes you say that? It might be correct, but you are just > providing a guess, here. > >> What other strategies should I be looking at to make the bounce >> more zippy? I deploy two smallish war files (<5MB, about 160KB >> Java Services code) > > Note that the size of the code is largely irrelevant. > >> I noticed several recommendations for different random number >> seeding strategies, but they came with warnings relative to the >> quality of encryption. What else might be done that doesn't >> compromise encryption quality? > > Most modern JVMs (on Linux) use /dev/urandom as a source of entropy by > default which is safe enough to use for probably everything but > long-loved encryption keys (e.g. multi-year-valid RSA/EC keys, PGP > keys, etc.). You probably shouldn't be generating long-lived keys of > these kinds from within a Tomcat-hosted application. /dev/urandom is > non-blocking so it shouldn't stall when grabbing entropy for things > like random-number seeding (which are used by Tomcat for both random > session-id generation and random TLS bulk-encryption keys. > >> I would like to push back my Java 11 upgrade until I have a good >> longer term strategy for jax and activation libraries. Thoughts? > > Why not simply bundle those required libraries with your application? > >> Glad to have made it through the upgrade .. it really wasn't very >> painful at all. > > Glad to hear it wasn't painful. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl09KVgACgkQHPApP6U8 > pFhPew/+JpMBI7y27lkZdvD61QoWWVYQm4VrsVu9iCGMSSznSPdVSROgvupjtF1Z > QCuTRLTOGdxWC1RuNMg47chtUiRtUnS/dIaCscN9AYSzqKvyGkGdW97S0cdTZnHy > plSRqsep4RkoseyFPBrLHRy3FU8po8Bt+2L3btCSwVK6pcp4GNVkywqF9/gkAJVp > uAL5Pyy57SY84sdHyCxxYeo9iO3Jtg3UVVQzGJzaFJ3bhCQcQO/50CNbsTMutGYJ > sJFOAWL6vQhnojIH2PAm6fqQ2e0XF+RmZh5Kf0+Jsl3VjBxw1C5wzyixcK9NvKxq > vdxG2Cs9YGpYiLLmF5Diz0JU7rTWfz/A0jalNt8Fr6y2HS65rFSlWsTsjlmjpl14 > b1hEw/o+vtRwJ3e+HEbTelnOXzaZU4HhlaiDkd43EcWOUyicvlEuAToQHMou5N68 > uKjP5/AdrDvGuSdAxCRrnAmAsOP4P0XMXoG9n6tHoTRy6L+3eh01h931lsFlxlYy > dOly8rOzDwE80x5BzugDw9I9Rotg0U0mGzogNzs9thG/1rrBzdUdWNDcWvJLaEkT > joKGlScnB/gEisV2NT2DEB4E8q9kf6BoypSVMhzOTQ9KDnIq6cau7dtfXWwusODt > St7SCCJtAsxMtici5HihZvuf+CDVpuZ5+PD3KWSuFjSxrwrl1Es= > =Qhtz > -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
Re: Question regarding tomcat random number seeding and startup times
Greetings; On 7/27/19, Christopher Schultz wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > John, > > On 7/27/19 19:49, John Dale wrote: >> Greetings Everyone; >> >> A quick update to the folks who I have interacted with on the list >> (you know who you are and I thank you). >> >> I got all of my applications and sites migrated from Tomcat 7.x.x >> to Tomcat 9.x running on Ubuntu 18.04 and Java 8. Lots of fun work >> with the firewalls, databases, and email servers (DKIM, SPF, and >> DMARC are something else). >> >> Overall, I was kind of disappointed to find out that Java 11 >> doesn't include activation and jax libs, but it sure was fast once >> I included these things in my lib folder. That said, I thought it >> might be better to revert to Java 8, which bundles and unit tests >> these libraries. So, that's what I did. >> >> But yikes .. the startup times are now very slow .. sometimes two >> minutes. I understand that this might relate to the need of the >> JVM to initialize for random number seeding. Is this true? > > What makes you say that? It might be correct, but you are just > providing a guess, here. After reading up on the issue and searching around for a few hours, I found many posts like these folks falling all over themselves recommending haveged: https://www.digitalocean.com/community/questions/fresh-tomcat-takes-loong-time-to-start-up > >> What other strategies should I be looking at to make the bounce >> more zippy? I deploy two smallish war files (<5MB, about 160KB >> Java Services code) > > Note that the size of the code is largely irrelevant. Correct .. unless there are huge jar files with many many classes to scan for deployment metadata? In my case, I have a very robust little application in a tiny deployable, so I was ruling that out. > >> I noticed several recommendations for different random number >> seeding strategies, but they came with warnings relative to the >> quality of encryption. What else might be done that doesn't >> compromise encryption quality? > > Most modern JVMs (on Linux) use /dev/urandom as a source of entropy by > default which is safe enough to use for probably everything but > long-loved encryption keys (e.g. multi-year-valid RSA/EC keys, PGP > keys, etc.). You probably shouldn't be generating long-lived keys of > these kinds from within a Tomcat-hosted application. /dev/urandom is > non-blocking so it shouldn't stall when grabbing entropy for things > like random-number seeding (which are used by Tomcat for both random > session-id generation and random TLS bulk-encryption keys. I assume you mean "long-lived"? :D I don't believe I'm generating these, but in my survey of online information it seemed to indicate Tomcat might be doing this for some of its own internal processes. You would know better than I would if this is true. At some point I'd like to get into the Tomcat source code, probably after what I have now is hardened and virtually unchanging. But then, that's why we have you, right? :) I'm deploying ssl certs from certbot into a pfx type deployment. Maybe this is related to the issue? > >> I would like to push back my Java 11 upgrade until I have a good >> longer term strategy for jax and activation libraries. Thoughts? > > Why not simply bundle those required libraries with your application? > >> Glad to have made it through the upgrade .. it really wasn't very >> painful at all. Just this startup issue. I like to be able to make quick changes, and faster start times are way more fun. I'm just stumped as to why Java 11 seemed to be so much faster to startup the same code base. I'll keep poking around. If you have any ideas please let me know. Thanks! John Dale DB2DOM > > Glad to hear it wasn't painful. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl09KVgACgkQHPApP6U8 > pFhPew/+JpMBI7y27lkZdvD61QoWWVYQm4VrsVu9iCGMSSznSPdVSROgvupjtF1Z > QCuTRLTOGdxWC1RuNMg47chtUiRtUnS/dIaCscN9AYSzqKvyGkGdW97S0cdTZnHy > plSRqsep4RkoseyFPBrLHRy3FU8po8Bt+2L3btCSwVK6pcp4GNVkywqF9/gkAJVp > uAL5Pyy57SY84sdHyCxxYeo9iO3Jtg3UVVQzGJzaFJ3bhCQcQO/50CNbsTMutGYJ > sJFOAWL6vQhnojIH2PAm6fqQ2e0XF+RmZh5Kf0+Jsl3VjBxw1C5wzyixcK9NvKxq > vdxG2Cs9YGpYiLLmF5Diz0JU7rTWfz/A0jalNt8Fr6y2HS65rFSlWsTsjlmjpl14 > b1hEw/o+vtRwJ3e+HEbTelnOXzaZU4HhlaiDkd43EcWOUyicvlEuAToQHMou5N68 > uKjP5/AdrDvGuSdAxCRrnAmAsOP4P0XMXoG9n6tHoTRy6L+3eh01h931lsFlxlYy > dOly8rOzDwE80x5BzugDw9I9Rotg0U0mGzogNzs9thG/1rrBzdUdWNDcWvJLaEkT > joKGlScnB/gEisV2NT2DEB4E8q9kf6BoypSVMhzOTQ9KDnIq6cau7dtfXWwusODt > St7SCCJtAsxMtici5HihZvuf+CDVpuZ5+PD3KWSuFjSxrwrl1Es= > =Qhtz > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -
Re: Question regarding tomcat random number seeding and startup times
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 John, On 7/27/19 19:49, John Dale wrote: > Greetings Everyone; > > A quick update to the folks who I have interacted with on the list > (you know who you are and I thank you). > > I got all of my applications and sites migrated from Tomcat 7.x.x > to Tomcat 9.x running on Ubuntu 18.04 and Java 8. Lots of fun work > with the firewalls, databases, and email servers (DKIM, SPF, and > DMARC are something else). > > Overall, I was kind of disappointed to find out that Java 11 > doesn't include activation and jax libs, but it sure was fast once > I included these things in my lib folder. That said, I thought it > might be better to revert to Java 8, which bundles and unit tests > these libraries. So, that's what I did. > > But yikes .. the startup times are now very slow .. sometimes two > minutes. I understand that this might relate to the need of the > JVM to initialize for random number seeding. Is this true? What makes you say that? It might be correct, but you are just providing a guess, here. > What other strategies should I be looking at to make the bounce > more zippy? I deploy two smallish war files (<5MB, about 160KB > Java Services code) Note that the size of the code is largely irrelevant. > I noticed several recommendations for different random number > seeding strategies, but they came with warnings relative to the > quality of encryption. What else might be done that doesn't > compromise encryption quality? Most modern JVMs (on Linux) use /dev/urandom as a source of entropy by default which is safe enough to use for probably everything but long-loved encryption keys (e.g. multi-year-valid RSA/EC keys, PGP keys, etc.). You probably shouldn't be generating long-lived keys of these kinds from within a Tomcat-hosted application. /dev/urandom is non-blocking so it shouldn't stall when grabbing entropy for things like random-number seeding (which are used by Tomcat for both random session-id generation and random TLS bulk-encryption keys. > I would like to push back my Java 11 upgrade until I have a good > longer term strategy for jax and activation libraries. Thoughts? Why not simply bundle those required libraries with your application? > Glad to have made it through the upgrade .. it really wasn't very > painful at all. Glad to hear it wasn't painful. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl09KVgACgkQHPApP6U8 pFhPew/+JpMBI7y27lkZdvD61QoWWVYQm4VrsVu9iCGMSSznSPdVSROgvupjtF1Z QCuTRLTOGdxWC1RuNMg47chtUiRtUnS/dIaCscN9AYSzqKvyGkGdW97S0cdTZnHy plSRqsep4RkoseyFPBrLHRy3FU8po8Bt+2L3btCSwVK6pcp4GNVkywqF9/gkAJVp uAL5Pyy57SY84sdHyCxxYeo9iO3Jtg3UVVQzGJzaFJ3bhCQcQO/50CNbsTMutGYJ sJFOAWL6vQhnojIH2PAm6fqQ2e0XF+RmZh5Kf0+Jsl3VjBxw1C5wzyixcK9NvKxq vdxG2Cs9YGpYiLLmF5Diz0JU7rTWfz/A0jalNt8Fr6y2HS65rFSlWsTsjlmjpl14 b1hEw/o+vtRwJ3e+HEbTelnOXzaZU4HhlaiDkd43EcWOUyicvlEuAToQHMou5N68 uKjP5/AdrDvGuSdAxCRrnAmAsOP4P0XMXoG9n6tHoTRy6L+3eh01h931lsFlxlYy dOly8rOzDwE80x5BzugDw9I9Rotg0U0mGzogNzs9thG/1rrBzdUdWNDcWvJLaEkT joKGlScnB/gEisV2NT2DEB4E8q9kf6BoypSVMhzOTQ9KDnIq6cau7dtfXWwusODt St7SCCJtAsxMtici5HihZvuf+CDVpuZ5+PD3KWSuFjSxrwrl1Es= =Qhtz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
