I'm starting from the bitnami jenkins stack. Everything is working perfectly with jenkins.
http://sample:8080/jenkins (works fine)
I'm trying to add additional directories to apache to proxy to nginx:
http://sample:8080/other_tool
I can get to the other_tool homepage, but references to that other tool break down because they are looking for http://sample:8080/relative_url rather than http://sample:8080/other_tool/relative_url
I can pull config settings from the necessary files as needed, but it is on an air-gapped network so wholesale posting would be a challenge
The apache conf looks like:
<Directory /other_tool>
ProxyPass http://localhost:9999
ProxyPassReverse http://localhost:9999
</Directory>
The nginx configuration is a standard "/" with root directory. I'm not as familiar with nginx so I can't recall the exact information off the top of my head. If needed I will provide it.
I could try to switch the jenkins hosting over to nginx, but I'm not sure that simplifies anything.
I can't open more ports on the machine. I can't use a subdomain as that would require additional DNS entries that I do not control.
Ideas or suggestions?
Related
I was not able any suitable solution on the web and all my trials result in failure.
My goal is to set up Tomcat9(TC9) while Tomcat7 (TC7) is still running, so I can configure and test the applications without any interference for the users. After I finished the configuration I want to switch to TC9 so the URLs of the webapps do not change and the Users won't notice the change.
I set up successfully TC9 with an AJP Connector Port on 8010 and I used the existing config file of the httpd and copied the /etc/httpd/conf.modules.d/00-tomcat7.conf to /etc/httpd/conf.modules.d/00-tomcat9.conf and edited accordingly
ProxyPass / ajp://localhost:8010/
However the old pass does not work anymore
ProxyPass / ajp://localhost:8009/
There might be a problem with the URL as I implemented it like so:
https:////
I had several attempts with configuration of the ProxPass like
ProxyPass /<webappgroup1> ajp://localhost:8009/<webappgroup1>
ProxyPass /<webappgroup2> ajp://localhost:8010/<webappgroup2>
But how does the actual endpoint URL look like and do I need to deploy my webapps still as #.war?
however like this I always get the Browser Error This site could not be found.
I don't know in which logs i could find more Information what is going wrong.
An example for the ProxyPass config or input of any kind is very much appreciated.
Thanks in advance!
I am able to reach the GeoServer log-in form on a new server instance using a URL like this: https://sub.domain.tld/geoserver.
However, entering the correct username and password causes Cannot POST /geoserver/j_spring_security_check to be displayed in plain text in the browser window and "http://localhost:8080/geoserver/j_spring_security_check" to appear on the address line (Chrome and Firefox). Logging-in works just fine from http://sub.domain.tld:8080/geoserver and, while logged in that way, the SSL URL will skip the log-in form entirely and open the full GUI -- but none of the example layer previews will work (Cannot GET /geoserver/tiger/wms ...or whatever layer).
I have 3 similar servers set up with earlier software versions that all work perfectly:
CentOS Linux release 7.5.1804 (Core)
Apache 2.4.6
Tomcat 9.0.4.0
JVM 1.8.0_171-b10 (Oracle)
GeoServer 2.15.1 (also 2.14.1)
This latest server is:
CentOS Linux release 7.9.2009 (Core)
Apache 2.4.6
Tomcat 9.0.48.0
JVM 1.8.0_292-b10 (Red Hat)
GeoServer 2.19.1
I closely followed the GeoServer install procedure found here. Apache was already installed and working with a virtual host configuration using certbot and a Let's Encrypt certificate. I added the following to the <VirtualHost *:443> section of the /etc/httpd/sites-available/sub.domain.tld.conf file:
ProxyRequests Off
ProxyPass /geoserver http://localhost:8080/geoserver
ProxyPassReverse /geoserver http://localhost:8080/geoserver
<Location "/geoserver">
Order allow,deny
Allow from all
Header set Access-Control-Allow-Origin "*"
</Location>
I also set "https://sub.domain.tld/geoserver/" as the Proxy Base URL in GeoServer. This is exactly how my working instances are set up.
The newest /opt/tomcat/webapps/geoserver/WEB-INF/web.xml file is slightly different in that it has separate CORS sections to be uncommented for Jetty vs. Tomcat. The Tomcat section and the cross-origin filter-mapping are uncommented. Unlike before, I had to enable the SELinux httpd_can_network_connect process in order to get to the GeoServer log-in form via SSL. Disabling SELinux enforcement, however, does not solve the j_spring_security_check problem.
Sensitive WMS and WFS content must be served via SSL. I am now spinning my wheels on research so any help in resolving this would be greatly appreciated!
I was running into a similar problem trying to reverse proxy a Geoserver docker container using Apache.
After bashing my head for a few days, I found I needed a couple of changes on both ends of the setup.
Apache:
<Location "/geoserver">
ProxyPreserveHost On
ProxyPass http://localhost:8080/geoserver
ProxyPassReverse http://localhost:8080/geoserver
</Location>
The ProxyPreserveHost directive should ensure that sub.domain.tld is what's used rather than localhost.
However, at this point I hit another problem, no matter what I did the login & logout URLs were using http:// and not https://
This required adjusting the server config of Tomcat, specifically the scheme used by the connector.
Tomcat:
<Connector
port="8080"
protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
scheme="https"
/>
Note the value of scheme is https, normally it's http because it's the http connector. This connector doesn't SSL/TLS encrypt the traffic so it would, under normal circumstances (appropriately), set the protocol to http.
Since we're using a proxy for SSL/TLS encryption we don't need Tomcat to do that work but we still need to tell Tomcat to describe the server name using https instead of the usual http.
Alternatively, you could also look at using the AJP connector which is an entirely different protocol but gets around some of these issues rather neatly and can be more performant.
The issue with this approach is that it requires more Apache mods to be enabled to work as well as some security concerns given how much more powerful AJP can be VS the http connector.
Also, there are some other proxy settings that can be used in Tomcat to possibly remove the need for ProxyPreserveHost in Apache, but this should get you where you're going.
Additional reading:
Tomcat HTTP Connector docs: https://tomcat.apache.org/tomcat-9.0-doc/config/http.html
Tomcat AJP docs: https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html
I run a local development web server for testing out code changes.
Often I have to test my local changes with remote services that can only connect securely to another domain.
e.g. https://external1.com will only talk to https://someOtherDomain.com, but I've got to test integration of my new code changes with https://external1.com
While I've got a setup configured that works, it seems complex, and took a bit to get setup right. It seems to me that many developers would want to do this same thing, so my question is this:
Is there an easy way to proxy my local webserver as https://someOtherDomain.com ?
EDIT: So maybe this should be asked this way - Does a command line or GUI tool exist that you can pass a local port and a domain name, and it serves your local port securely over https://someOtherDomain.com - no config or SSL cert creation required? Of course it'd be nice if the SSL cert could be replaced through configuration if need be, but by default, it'd work automatically, by using a precanned SSL cert. And even though I'm using Apache, I'm looking for a solution that actually doesnt use Apache - it uses something else. Why? Because I want this solution to work well with any other webserver that's being used by people on our team - as we all run different stacks, and I'd like to be able to let any of us securely serve our sites without having to configure each webserver individually.
Here's my current setup for taking my local webserver and serving it up at https://www.someOtherDomain.com
To test this locally, I've been:
editing my hosts file, and adding an entry to make www.someOtherDomain.com point to my local machine, which of course is running my dev server. This makes it so my local site is now available at http://www.someOtherDomain.com
127.0.0.1 www.someOtherDomain.com
Running Apache with a SSL Cert setup and mod_proxy to redirect all https requests to my local http server, thus making my site available at https://www.someOtherDomain.com. Here's my Apache config for this:
ServerName www.someOtherDomain.com
<Location /balancer-manager>
SetHandler balancer-manager
</Location>
ProxyPass /balancer-manager !
ProxyPass / balancer://mycluster/
<Proxy balancer://mycluster>
BalancerMember http://localhost route=1
</Proxy>
ProxyPass / balancer://mycluster
ProxyPassReverse / balancer://mycluster
SSLHonorCipherOrder On
SSLProtocol -ALL +SSLv3 +TLSv1
SSLCipherSuite RC4-SHA:HIGH:!ADH
# Rewrite all http requests to https
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
I run this on a mac, but am interested in solutions for linux as well. I've seen various Man in the Middle proxy's that sound like they'd work with some configuration... but I'm looking for something really simple to install and run - not just for me, but something I can tell team members about too, as we may all have to do this a lot in the future.
IMPORTANT NOTE: My local webserver isn't running on Port 80, though I've put it this way in the above example, to keep it simple. I understand port 80 on a mac is a bit special, but am very happy with solutions that work fine on all ports but port 80.
I think mitmproxy can do this for you, as least on linux and os-x. I haven't tried it myself but this question seems to show how it is done. It's still not a trivial program though.
There are however other approaches, which I have used:
The first one is the most pretty simple one, create a DNS entry for develop.mydomain.com which points to 127.0.0.1 and a single certificate for a (sub)domain where you control the DNS. Spread that certificate to all your developers. They'll still need to setup SSL themself but they don't need to generate certificates anymore. It has the added benefit that everybody is developing against https://develop.mydomain.com which allows them to share the configuration.
For bonus points, create a DNS entry for *.develop.mydomain.com and a wildcard certificate and your developers can have different sites (e.g. https://project1.develop.mydomain.com and https://project2.develop.mydomain.com) on there local machine. (Contrary to what the internet sometimes tells you, name based virtual hosting works fine with SSL as long as the certificate is valid for all the named hosts). Since the domain is the same for everybody you can consider getting a valid wildcard certificate to get rid of the warnings.
Unlike the solutions below this works even outside of the office network, which may be relevant when people are working from home or at the customer.
Building on this you could also create DNS entries for the internal IP's of the developer machines (if those are fixed). This does add some work, but it means the ongoing work of a developer can be reached by others in the local network, which can be very convenient for demo's, testing on mobile devices, etc.
An other option is to configure a single machine to proxy for all your developers. Create a DNS entry pointing to the internal IP of this box on something like *.develop.mydomain.com, a matching wildcard certificate and configure that box once with the correct certificate. Now you can create a virtual host for each proxied server, and again, all sites will be reachable throughout the local network, but it does require the developer to have fixed ip addresses (or hostnames added to DNS through DHCP).
Combined with the ability of apache to include all files in a directory in it's configuration makes it trivial to create a script which adds a new site based on a template. All it has to do is write a new file based on the requested subdomain plus the destination and reload the apache config. This means something like a simple PHP script can do what you want the application to do.
If you want to expose your web on your local machine to the internet try Runscope Passageway, it's easy to setup and "just works" (from experience).
Another alternative is ngrok which I also used, but it didn't always work for me.
My problem is, that I recently set up a Tomcat7 application container with Apache2.2 Frontend. As the project is still under development I am controlling access by an IP whitelist set up in .htaccess for the domain.
I set up mod_jk via AJP13 to Tomcat, it works absolutely fine, except the fact that .htaccess doesn't block the forward for Tomcat. In other words if you enter www.mydomain.com from a "black" IP, you get forwarded to the error page but if you enter www.mydomain.com/AppContext you slip through Apache into Tomcat
I started messing with urlrewritefilter with Tomcat, but for some reason it didn't work.
I am wondering if there is any way to set up .htaccess or apache instead to block requests forwarded to Tomcat similarly to request for Apache?
Also noticed a dramatic speed decrease when using it like that, us that common when using Apache as a frontend?
.htaccess files will work only when Apache is using a <Directory> based configuration (in httpd.conf). In case of mod_jk, matching requests (as specified by JkMount directive) will simply be forwarded to the AJP connector.
Use <Location> to control access instead:
<Location "/AppContext">
Order Deny,Allow
Deny from all
Allow from .myCompany.local
</Location>
See <Location> Directive> for details.
I faced the same problem and found a solution which may solve your case too.
Use a reverse proxy server like Nginx or Squid to redirect the traffic Apache Tomcat. Both of them can use htpassword for authentication and hence, will serve your need. If you want to use Apache as frontend then backend can be nginx which in turn will redirect to Tomcat after proper authentication. It may have a performance hit, though.
https://www.digitalocean.com/community/tutorials/how-to-set-up-http-authentication-with-nginx-on-ubuntu-12-10
I realize this question has probably been asked numerous times, but I have not been able to find a good, up-to-date answer. The only guide I have been able to find was from 2005 and was on tomcat 5. It seems a lot of the OS paths have changed.
Our situation is this:
We want to run multiple instances of tomcat 7 on a single server. Each tomcat serves up a different address. For instance, www.oursite.com should be served from a separate tomcat than test.oursite.com. So, for example the base tomcat installtion will sit in /opt/tomcat/ and the instance specific directories (this is what I could make out from that old tutorial) will be in /home/user1/some/path/ and /home/user2/some/path so that everything is seperated nicely.
Can anyone point to a good tutorial, or maybe explain here the steps to set this up? I'm a bit new to apache setups.
Are there any advantages / drawbacks to doing it this way? Would a single tomcat instance be better? We need to be able to bring down sites one at a time without influencing each other. Also, our DNS provider prevents us from setting up stealth redirects, so we have to go through apache to have nice URLs rather than redirecting straight to the tomcats.
Thanks
I believe you have 2 questions here:
How to run multiple tomcat instances in the same server and should
you?
How to configure apache httpd to do virtual host and front
tomcat?
For 1. The following is a very good tutorial on how to run multiple tomcat instances in the same server: http://java.dzone.com/articles/running-multiple-tomcat, but should you? the answer is "it depends". If you have a super powerful box and it is under utilized, you should. It also depends on what type of application you runs for each individual sites. It will definitely help you "bring down sites one at a time without influencing each other". With apache httpd configuration which I will explain in the next section, you can also run the each site on separate machines (physical or vm).
For 2. In you case, you just need to configure apache httpd to do virtual host and use ajp to connect to tomcat.
<VirtualHost *:80>
ServerName www.oursite.com
ProxyPass / ajp://tomcat.oursite.com:8009/www retry=5
ProxyPassReverse / ajp://tomcat.oursite.com:8009/www
</VirtualHost>
<VirtualHost *:80>
ServerName test.oursite.com
ProxyPass / ajp://tomcat.oursite.com:8010/test retry=5
ProxyPassReverse / ajp://tomcat.oursite:8010/test
</VirtualHost>
In the above configuration, you need to configure DNS entries of both www.yoursite.com and test.yoursite.com to point to the same host. It also assume you run both your www and test webapps on different tomcat instances on the same host tomcat.oursite.com, one on ajp port 8009 and the other one on ajp port 8010. You can also change it to a different server of its own. It's very flexible. FYI, following is how to configure ajp in tomcat: http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html
I found a problem with the apache mod_proxy_ajp connector in such a configuration, it absolutely won't allow you to use any other port when setting up multiple virtual hosts each with its own tomcat instance.
Having spent some time ruling out port conflicts, tomcat configuration issues, firewall issues I have concluded that ProxyPass and ProxyPassReverse will not work when using any port other than 8009 by default.
The solution is likely to be to switch to mod_jk, which also solves problems seen in mod_proxy_ajp with basic configurations not loading or rewriting urls embedded within tomcat hosted pages without extensive configuration changes if the tomcat instance is rooted to a subdirectory. This doesn't seem to happen with Mod_Jk