Tomcat 9 symlinks ?
Hello I have scoured the web trying to get symlinks working for jsp pages or folders in Tomcat 9 using Ubuntu 20.04. Here is how to repeat the issue, and what I have tried. 1. Create a new folder in webapps, say "foo" 2. Put HelloWorld.jsp there 3. (I restarted Tomcat just in case) Verify it works at localhost:8080/foo/HelloWorld.jsp 4. Put a soft symlink there: ln -s /opt/tomcat/webapps/foo/HelloWorld.jsp /opt/tomcat/webapps/foo/Link.jsp 5. (restart) Verify that localhost:8080/foo/Link.jsp soft fails with nothing in the log as if it does not exist. WHAT I TRIED: First I put this in the default host "localhost" in server.xml: This achieves the objective of making "foo" the default so now I can just use localhost:8080/HelloWorld.jsp However "allow linking" is silently ignored. I also tried editing context.xml and adding to the context: Both of these solutions were gleaned from reading the documentation and Google searches, and I seem to be stuck here. For now I cannot install a later version of Tomcat (using Amazon Java 8 Coretto) or remove the symlinks as they are required by an existing application. Any thoughts are greatly appreciated.
Re: Tomcat 9 symlinks ?
Thanks very much for the comprehensive reply. I tried as you suggested and it worked fine, resolving symbolic links both inside and outside the tomcat webapps directory. You asked why path="" instead of path="foo" in context at server.xml? That was our attempt to mount this application at "/" instead of at "/foo" which is a requirement here. And that indeed worked, I was able to access the jsp page at "/". However, I will research that again and look at every way of doing it - it's not germane to the real problem here which is symlinks - which appears to be solved at least in initial experimentation using your suggestion. Thanks again. On Wed, Jun 19, 2024 at 3:09 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > Stephen, > > On 6/19/24 13:55, Stephen Tenberg wrote: > > Hello I have scoured the web trying to get symlinks working for jsp pages > > or folders in Tomcat 9 using Ubuntu 20.04. Here is how to repeat the > issue, > > and what I have tried. > > > > 1. Create a new folder in webapps, say "foo" > > > > 2. Put HelloWorld.jsp there > > > > 3. (I restarted Tomcat just in case) Verify it works at > > localhost:8080/foo/HelloWorld.jsp > > > > 4. Put a soft symlink there: ln -s /opt/tomcat/webapps/foo/HelloWorld.jsp > > /opt/tomcat/webapps/foo/Link.jsp > > > > 5. (restart) Verify that localhost:8080/foo/Link.jsp soft fails with > > nothing in the log as if it does not exist. > > > > WHAT I TRIED: > > > > First I put this in the default host "localhost" in server.xml: > > > > > > > > > > > > Why path="" instead of path="foo"? > > In fact... why bother with a element at all? The presence of > the "foo" directory will automatically deploy an application on /foo. > Yes, in order to "allow linking" you will need a to set it on, > but that should be under webapps/foo/META-INF/context.xml and not in > conf/server.xml. Yes, you can put it in server.xml, but you should not > do that for a few reasons. > > > > > Yuck. Now you have an application deployed into "/ROOT" as well as "" > (the default ROOT application, mounted on /) > > > This achieves the objective of making "foo" the default so now I can just > > use localhost:8080/HelloWorld.jsp > > I think you must have copy/pasted incorrectly, but nothing of what you > put above would allow /HelloWorld.jsp to run the JSP in "foo". > > > However "allow linking" is silently ignored. I also tried editing > > context.xml and adding to the context: > > > > > > > > This ... is confusing at best because you have two elements in there. > I'm not sure what will happen if you define it twice. Maybe the second > one overwrites the first? If that's true, it might explain why it > wouldn't work. > > > Both of these solutions were gleaned from reading the documentation and > > Google searches, and I seem to be stuck here. > > > > For now I cannot install a later version of Tomcat (using Amazon Java 8 > > Coretto) or remove the symlinks as they are required by an existing > > application. > > > > Any thoughts are greatly appreciated. > > First: simplify. Put everything into your application and give it the > name AND context-path you want, for example webapps/foo and everything > is in there. > > There is really only one place where symlinking can be configured at > all, which is . Put your in > webapps/foo/META-INF/context.xml and use a single element > with an appropriate configuration. > > Remove everything else. > > Restart and see what happens when you request /foo/Link.jsp > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Tomcat 9 symlinks ?
Thank you. Do we just rename the existing ROOT to something else so the admin stuff is available? The path="" was appealing as we want this existing large application to be available as "/". Is renaming ROOT a better way of achieving this? On Wed, Jun 19, 2024 at 3:50 PM Chuck Caldarale wrote: > > > On Jun 19, 2024, at 14:42, Stephen Tenberg > wrote: > > > > You asked why path="" instead of path="foo" in context at server.xml? > > > > That was our attempt to mount this application at "/" instead of at > "/foo" > > which is a requirement here. > > > Just deploy the application as ROOT (case matters) rather than foo. > > - Chuck > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
The Import cannot be resolved
Hello, I am trying to convert a large mature application to Tomcat 9. No WAR file is used, the files are statistically placed in directories. So far it's going pretty well and large parts of the application are working. A few minor incompatibilities have been solved. One sticking point has been this error: An error occurred at line: [15] in the generated java file: [/opt/tomcat-9.0.90/work/Catalina/local.procheckauto.com/ROOT/org/apache/jsp/admin/menu_jsp.java] The import com.xxx.rr.user cannot be resolved This is confirmed present in the class tree, the permissions are correct, and we compiled from the command line to verify. Looking through the classes tree there is nothing different about this simple class compared to all the others which ARE resolved. Has anyone faced something like this and figured out a way to debug it? The log stack trace has the same information and no clue as to WHY it couldn't be resolved. Compiling the class in Eclipse or command line is fine, and the JSP file looks correct with just a standard import and errors or warning in eclipse. The class directory is symlinked, but allowlinking has been specified and many classes before this one in the same tree are successfully accessed, so I have no reason to think the symlink is an issue.
Re: The Import cannot be resolved
Thanks for the reply! I found my obscure error. I am migrating a large application from another java webserver to Tomcat 9. To prototype the changes, I am using Ubuntu Multipass VMs on my mac. I share the application folders that reside on the mac to Ubuntu. Unfortunately since the mac filesystem is case sensitive, this one Java file caused the error. I had an import for com.xxx.rr.user package but actually also had a com.xxx.rr.User.java file. Out of almost 500 classes this was the only one where using the mac as a fileserver caused the inconsistency, and after renaming that one file, it's all good now. Stephen On Sun, Jun 23, 2024 at 5:39 AM Holger Klawitter wrote: > Hi, > > I once had a similar experience when the tomcat process > ran out of file handles. At some point tomcat wasn't able to > open a file and cached the absence of that file. Later on tomcat > still remembered the absence and threw errors just like yours. > > Stephen Tenberg wrote (at 2024-06-22 09:03 -0400): > > Hello, I am trying to convert a large mature application to Tomcat 9. No > > WAR file is used, the files are statistically placed in directories. > > > > So far it's going pretty well and large parts of the application are > > working. A few minor incompatibilities have been solved. > > > > One sticking point has been this error: > > > > An error occurred at line: [15] in the generated java file: > > [/opt/tomcat-9.0.90/work/Catalina/ > local.procheckauto.com/ROOT/org/apache/jsp/admin/menu_jsp.java] > > The import com.xxx.rr.user cannot be resolved > > > > This is confirmed present in the class tree, the permissions are > > correct, and we compiled from the command line to verify. > > > > Looking through the classes tree there is nothing different about this > > simple class compared to all the others which ARE resolved. > > > > Has anyone faced something like this and figured out a way to debug it? > > > > The log stack trace has the same information and no clue as to WHY it > > couldn't be resolved. > > > > Compiling the class in Eclipse or command line is fine, and the JSP > > file looks correct with just a standard import and errors or warning > > in eclipse. > > > > The class directory is symlinked, but allowlinking has been specified > > and many classes before this one in the same tree are successfully > > accessed, so I have no reason to think the symlink is an issue. > > -- > Mit freundlichem Gruß / With kind regards > Holger Klawitter > -- > listen klawitter de > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Possible penetration attempt or DOS attack: any suggestions on what can be done?
Not a tomcat issue but I can't say enough good things about cloudflare which we use. Easy to configure WAF so the site is locked down to cloudflare only and the rest of the world has to come through them where each keystroke is inspected. They have a number of preconfigured rules that mostly just work right out of the box. Various plans ranging from free and up. We did this years ago on every site. On Thu, Jun 27, 2024 at 11:03 AM Christopher Schultz < ch...@christopherschultz.net> wrote: > James, > > On 6/24/24 17:57, James H. H. Lampert wrote: > > On 6/24/24 12:03 PM, Tim Funk wrote: > >> Conversely, this is a good time for the developers to review > >> their server logging and tune it to be less verbose for these > >> normal exceptions. As well as implementing logging frameworks > >> and logging at the appropriate level (fatal through debug) > > > > Thanks for your thoughts on the subject. > > > > The primary problem isn't that the catalina.out file is enormous, nor > > that the log messages are too verbose (if anything, they're not verbose > > enough: a timestamp would help) ; it's that while the random filenames > > were being tried, in quick succession, the CPU usage of the JVM job > > skyrocketed, and legitimate traffic was probably having trouble getting > in. > > Hmm. Are you getting requests for the same (missing) resource over and > over again, or many different ones? I suspect different, since attackers > have a huge dictionary of "telltale resources" to identify a service as > running one of many known-vulnerable services (e.g. Wordpress, JIRA, etc.). > > Why aren't you seeing the source-IP in your own logs? If you are using a > reverse-proxy and always getting the IP of the proxy, you should be able > to (a) configure the reverse-proxy to provide its own IP to you and > configure Tomcat to use that for logging and/or (b) look-up the same > request in the proxy logs. Once you have that, you can ban. > > Banning can be done in many ways. > > One way would be just by-hand. If you see a huge number of requests from > one IP, just ban it. If it's more than one IP, then you get to play > whack-a-mole and automated solutions would be better. > > Be careful with fail2ban (which I like a lot, but I've never used it > with HTTP logs): you can easily ban people quickly who aren't actually > attacking you. If you use fail2ban (or similar), I would be very > conservative about its configuration. Basically, you choose the number > of flags that have to be thrown per-IP per-time-interval. So something > like "100 404s in a minute per-IP" would be conservative. > > fail2ban is definitely available on Linux and probably also BSD. I think > you are on AS/400 or something like that, right? And of course you'd > want to ban as far up the chain as possible, at the reverse-proxy, TLS > terminator, or load-balancer. I'm not sure exactly what options you have > in that environment. fail2ban works directly with the OS's firewall, so > on Linux that's iptables and on BSD that's generally ipfilter. If AS/400 > has a built-in firewall then it's possible fail2ban has a build for it. > > Tim's suggestion of a WAF is a good one. I've tried to configure > mod_security for Apache httpd and it's got like 100M rules and it > immediately banned every one of our developers when we used it > out-of-the-box. It is SUPER PARANOID about everything. If you are > considering using mod_security, I would (a) run it only in a development > / testing environment and (b) run it in "audit mode" for a week or so > and look at all the complaints it makes. I have had to specifically > disable a LARGE number of checks to make it even partially usable. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
