Re: ERR_CONNECTION_REFUSED
On Mon, Nov 30, 2020 at 10:39 AM Tercio Pedro wrote: > Hello, > > I am a user of the Tomcat server, I need assistance in configuring the ssl > certificate and port 443. > > I installed the ssl certificate but the site just opens on port 8443 I want > to go to port 443, I already changed the port on the connector > (server.xml), I already enabled the port on the firewall and when I try to > open on port 443 I have the error: ERR_CONNECTION_REFUSED > > I need your help. > > Thanks > Hello, I guess my first questions would be what user / account are you using to run the Tomcat process? Can you confirm that port 443 is actually listening when you start Tomcat? Are there any errors in the catalina.out log? Ports lower than 1024 are considered privileged ports and only root can manage processes that use those ports. There are some workarounds where you can use software like authbind to have a non-root user do it instead but it takes some extra tinkering. There are also folks that run Tomcat on 8443 and then configure iptables to forward port 443 to 8443. There are a few different ways to accomplish what you want to do - have you researched any of these solutions? Jim
Re: AT WITS END regarding JVM arguments
Hi James, On Thu, Sep 1, 2016 at 2:36 PM, James H. H. Lampert < jam...@touchtonecorp.com> wrote: > Ladies and Gentlemen: > > One of our Tomcat servers (refreshed from > apache-tomcat-7.0.67-windows-x86.zip) > is running AS A SERVICE on a Windows box. > > And we need to set JVM Options of > -Djavax.servlet.request.encoding=UTF-8 > -Dfile.encoding=UTF-8 > -Djava.awt.headless=true > > Unlike IBM Midrange boxes, on which I can, with a simple OS command, list > all the JVMs currently running on the system, and look up the arguments, > environment variables, system properties, &c, I can't find any way to > verify the JVM arguments (this box has only a JRE, not a JDK), other than > what gets sent to the log file. I even tried installing a trial of > JProfiler, but if checking arguments is in there, it's well-hidden! > > I just tried adding a "setenv.bat" to the "bin" directory, containing > > SET CATALINA_OPTS=-Djava.awt.headless=true > -Djavax.servlet.request.encoding=UTF-8 >> -Dfile.encoding=UTF-8 >> > > and after stopping and starting the service, even after rebooting the > Windows box, "headless" cannot be found in the log file, and neither can I > find "UTF." > > WHAT COULD BE GOING WRONG HERE? > > -- > JHHL > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > I don't run Tomcat on Windows so there might be a typo in this line here but in your setenv.bat have you tried something like: SET JAVA_OPTS="%JAVA_OPTS% -Djava.awt.headless=true -Djavax.servlet.request.encoding=UTF-8 -Dfile.encoding=UTF-8" instead of using CATALINA_OPTS? We use JAVA_OPTS in our setenv.sh file for Linux, perhaps it will work for Windows as well ... - Jim
Best practices around Kerberos ticket management & Tomcat instances? [Linux]
Hello, This is my first experience using Kerberos and lucky me it's with Tomcat on Linux. We're only using it to access an MSSQL database for now - no single sign-on (yet). So far the testing has been done on one server and it's been pretty successful. We're now looking to enable this functionality on the other two servers that make up this environment. My questions are mostly around best practices when it comes to managing tickets with multiple tomcat instances for a single app so I'll just get to it: - We will have three tomcat instances on three different linux servers all running the same application that will be connecting to the same MSSQL instances. Here are the two options I've come up with that make the most sense right now - 1. Have each Tomcat instance use the same SPN and get tickets on their own respective servers. The means that at any given time there would be three active tickets for the same SPN but I would have each tomcat instance doing kinits and kdestroys as the app is started or stopped. Or 2. I need to create a new SPN (and new AD accounts?) for each tomcat instance accessing the MSSQL database and each tomcat instance would be doing kinits and kdestroys with its own ticket. I'm leaning towards option #1 but perhaps someone has another option or can lend some thoughts as to which way I should proceed? - On each server, we need to go through a process that requests a ticket when tomcat starts, uses the ticket as long as the JVM is running and then destroys the ticket when the JVM is stopped. I'm thinking that I modify the tomcat startup script in /etc/init.d so that when the specific tomcat option is called the following things happen: start:: - kdestroy is called to clear any existing tickets in the tomcat ticket cache (cache is in custom location w/ custom filename) - kinit is called to request a renewable ticket - lets say 14 days - tomcat process starts as normal stop:: - tomcat process stops as normal - kdestroy is called to clear any existing tickets in the tomcat ticket cache (cache is in custom location w/ custom filename) Once the ticket has been requested, I would have a crontab job go out and do renewals every 12 hours - noon and midnight perhaps? Does a ticket renewal in the middle of the day become too risky with the application running in production? Then once a week, I would have the application stopped for DB re-indexing, other maintenance, etc. We should never get to the point where the JVM is running for 2 weeks and then causes a problem when the ticket expires. Would these align with best practices that others have done or seen in similar scenarios? Do the ticket lifespans and renewal timeframes make sense or should they be less often / more often? I really appreciate any feedback or thoughts on this - thanks! - Jim
