-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 George,
On 10/31/18 14:17, George Stanchev wrote: > This is an interesting discussion. Are there any guides to > alleviating management work of such deployments? It's a little out of scope for this community (formally), but there may be people here who can share their stories. > For example, how do you deal with the port mapping? We assign each dev a number and each application a number. Each pair of dev+app yields an actual port number. This works great in development so nobody ever steps on anyone's toes. In other environments (test, prod, etc.) there is only ever one "dev number" and that's "the deployer". > Or logs - do you collect at a common location or let each app log > in its corner ? We use separate logs, but many logging systems allow for log aggregation. I know e.g. log4j has a SysLogAppender and you can do *anything* with that. > Can you share configuration across instances such as SSL, JNDI > configuration, etc? We use revision-control for that kind of thing with replaceable parameters for things like relocatable resources (e.g. database URLs) and sensitive information (e.g. passwords). We use "ant" for deployment, which merges the configuration(s) under revision-control with a set of local settings to build a working configuration. > Any blogs to such approach? Not that I have personally written. Configuration-management and deployment strategies are typically very environment-specific. - -chris > -----Original Message----- From: Christopher Schultz > <ch...@christopherschultz.net> Sent: Wednesday, October 31, 2018 > 9:29 AM To: users@tomcat.apache.org Subject: Re: Number of Web > Applications in one Tomcat: THANKS! > > Guido, > > On 10/31/18 05:14, Jäkel, Guido wrote: >>> Has anyone ever attacked one of your web applications? There >>> are some fun ways to make an application use a huge amount of >>> memory. Just because the applications themselves are behaving >>> doesn't mean that all the users are behaving. >>> >>> For example, do you have a max POST size set for your >>> application? If not, I can send your login form a username that >>> is so long it might exhaust your heap. 2147483647 characters is >>> a LOT of characters. >>> >>> If you have a max POST size, maybe you don't filter-out PUT >>> requests, and have Tomcat parsing those for you. Same problem, >>> there. > >> Dear Chris, > >> But that's no argument for or against running more than one >> application per Tomcat: If you're not aware of such things, one >> may attack your other Tomcats in the same way because of >> identical configuration. > > Yes and no. > > Presumably, more than one application means more resources required > in general. Since each application might experience "peak" usage > simultaneously, you must over-provision *for both*. That actually > *helps* you against the kind of attack I proposed (more memory is > slightly more difficult to fill than less). > > On the other hand, each application has different requirements. > Perhaps one application needs to be able to accept file uploads > while the other one does not. That means that the application which > need not accept large POST requests is now vulnerable because of a > shared resource 9memory) which the other application can allow > attackers to consume. > >> Of course, if you plan to run a couple of applications per >> Tomcat, you may also plan to spread it to more than instance to >> have a fail-over or load balancing . But even if you use a >> HA-cluster with one App per cluster member: If one is able to >> crash the Application by a Request on one cluster member, this >> might be repeated on the other members without noteworthy costs. > > Cascade failures can indeed be a serious problem. > > It's generally more difficult to crash a Tomcat instance with a > single request. It usually requires multiple requests (sometimes > concurrently) and so that provides the admin more opportunities at > mitigation. > > -chris > > --------------------------------------------------------------------- > > 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 > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlvbBOUACgkQHPApP6U8 pFjJKg/+KOX+zbD+fIIPDmUToZYCFgCt8fjWUsoUVStfsMzhLCrQ6j0c6iRkIOMl 9SuaorrIhVAPRDJ3M/7tqij5a/Mf2QdVeTEtdCp9VpHeIREmOewtwDPO5ZgW89P0 QECvZ5VyqgXkWqViWE2l8xxCBj4R/3U9oeUkAMBF56HJQSHogr/LYlsiJx8EU116 tmh9QVDZrStD22qG4Lvj997ePJ9qHCePfprerlNjszS9iZr5CmigSB3mC3YZSj1Z L202zj65BABHTvN5uk3pnJ+xsWzdf/55+nnMCleww0LeV3fV9EUaoE9ch44u0T1E Is62vgkPS6IASYnQMc6MPMFqHgcePKuAPMnYmmc8/mId4839h7RYZnaXF75e8Lzk wksw12XCaigCpRT3Fz64xTCz+//2OIU22Lu4Pff9ZGKqn9MWQIXUzqFrqmpyg+Ot lWONDyyfTZ8wjL94Ib49ni1ujIgaXdYU/XIPFc1IBazRu9DUUgwsioRVp0JkMuI+ CQ8u4w+2f1KTGYI4k/i9AMzwXHrNTQKHTOrUetqgfY/yp/J9X7Af4Njwt5gpafpD Jmf3WnhKP1A11bQD93r1++WDll1AZLZcppXdFe4+5Q3fezhiSbL0Pp1HyokhcJ5C ckuM8VCodPMspHONRbTGRn2TqGal4S9RHnYcb5SOlJrsuPz9CSY= =XZX9 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
