Hi,
I have succesfully deployed a web.war inside a JBoss 7.1.1 and in my dev environment everything works fine.
I have then succesfully deployed the same JBoss instance into another machine outside my office.
LoadModule proxymodule modules/modproxy.so LoadModule proxyajpmodule modules/modproxyajp.so In that case, this configuration works for me: ServerName public.server.name ProxyRequests Off ProxyPreserveHost On Order deny,allow Allow from all ProxyPass / ajp://localhost:8080/ # ProxyPassReverse might not. This version contains: Apache, MySQL, PHP + PEAR, Perl, modphp, modperl, modssl, OpenSSL, phpMyAdmin, Webalizer, Mercury Mail Transport System for Win32 and NetWare Systems v3.32, Ming, FileZilla FTP Server, mcrypt, eAccelerator, SQLite, and WEB-DAV + modauthmysql. Apache 2.4.4 MySQL 5.5.32 PHP 5.4.16 phpMyAdmin 4.0.4 FileZilla FTP Server.
My dev environrmet is the same as the machine I have deployed JBoss to;
Apache2
Ubuntu 12.04
OpenJdk
When I try to access the site at http://123.456.78.90:8080 or http://123.456.78.90 I get the following error in the /var/log/apache2/error.log:
[notice] Apache/2.2.22 (Ubuntu) proxy_html/3.0.1 configured -- resuming normal operations
[error] (111)Connection refused: proxy: AJP: attempt to connect to 127.0.0.1:8009 (127.0.0.1) failed
[error] ap_proxy_connect_backend disabling worker for (127.0.0.1)
[error] proxy: AJP: failed to make connection to backend: 127.0.0.1
[ [error] proxy: AJP: disabled connection for (127.0.0.1)
So I am thinking that the problem might be in Apache2 but I am not sure.
My standalone.xml has:
.
.
.
.
.
.
Can anyone confirm that I am not doing anything wrong in the standalone.xml?
Then Apache2 is where I am getting lost this is what I have as mods_enabled:
alias.conf
authn_file.load
authz_host.load
autoindex.load
dir.load
mime.conf
negotiation.load
proxy_html.conf
proxy.load
setenvif.conf
status.load
alias.load
authz_default.load
authz_user.load
cgi.load
env.load
mime.load
proxy_ajp.load
proxy_html.load
reqtimeout.conf
setenvif.load
userdir.conf
auth_basic.load
authz_groupfile.load
autoindex.conf
dir.conf
headers.load
negotiation.conf
proxy.conf
proxy_http.load
reqtimeout.load
status.conf
userdir.load
In the /etc/apache2/sites-enabled I have the following settings:
NameVirtualHost *:80
DocumentRoot /home/ftp/ftpadmin
Options FollowSymLinks
AllowOverride None
ErrorLog /var/log/apache2/error.log
Chime app web. # Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature On
ProxyPass /images/thumbs !
ProxyPass /images/display !
Proxy Ajp Disabled Connection For
ProxyPass /images/zoom !
ProxyPass / ajp://127.0.0.1:8009/
ProxyPassReverse / ajp://127.0.0.1:8009/
ProxyPass /opac-rest ajp://127.0.0.1:8009/opac-rest
ProxyPassReverse /opac-rest ajp://127.0.0.1:8009/opac-rest
When I check the 8009 port on the machine 123.456.78.90 with the following command netstat -na|grep 8009 the port is listening:
tcp 0 0 123.456.78.90:8009 0.0.0.0:* LISTEN
Do I need to remove all the proxy modules and install the mod_jk as documented in https://docs.jboss.org/author/display/AS7/AJP+Connectors?
Thanks
Max
By default Tomcat and JBoss run on port 8080. So your Tomcat urls look like http://example.com:8080/index.jsp.
There are a few ways ways you can access Tomcat webapps on the regular port 80 so that you do not need the port number in the URL.
- Apache, mod_proxy/mod_jk2, Tomcat: You can use Apache as the front end to all requests then forward certain URLs or virtual hosts to Tomcat. This option lets have some content served by Tomcat (e.g. a whole domain, or a certain directory on a domain) and other content (e.g. HTML, PHP pages, etc) served by Apache. If you are on a recent distro (e.g. FC5, Centos5 and Debian Etch or later) with Apache 2.2 or 2.4 you would use mod_proxy or if you had an older distro with Apache 2.0 (e.g. RHEL4, Debian Sarge) then you would configure the Apache mod_jk2 module.
- Tomcat, iptables, Port 80: Another method you can use is iptables. iptables let you forward traffic received on one port (80) to another port (8080). This method bypasses the Apache webserver completely (even if it is running on port 80). This is the simple to setup. But you will not be able to use Apache (e.g. for webmail, using PHP apps, or apps like phpMyAdmin).
- Tomcat, Root, Port 80: You can also set Tomcat to run on port 80. We do not recommend this method, since then Tomcat would need to run as a privileged user. Which has security implications.
Often customers want to combine the use of JSP and Apache. For example, they may have some PHP scripts and some JSP programs they want to run. (And the Servlet engines cannot execute PHP scripts). Using Apache to handle your incoming requests also gives you more options for things like using SSL, error logs, and using .htaccess files.
Apache 2 introduces the mod_proxy module. It is a standard module in most modern distros. This module pretty much deprecates the need for mod_jk2. Full Apache 2.2 and Apache 2.4 documentation for mod_proxy is available.
To setup mod_proxy_ajp add something like the following inside of your Apache VirtualHost entries (e.g. in /etc/httpd/conf/httpd.conf under CentOS/Fedora, /etc/apache2/sites-enabled under Ubuntu/Debian):
To forward all requests to http://yourip/tomcat to tomcat's ROOT webapp:
The ProxyPassReverse line helps to fix URLs returned by tomcat so they make sense on the Proxy context. Apache 2.4 extends this syntax to make it even more powerful.
Another example, to forward all requests to http://yourip/tomcat to tomcat's jsp-examples webapp.
To forward all requests to http://yourip/ to tomcat's ROOT webapp:
When apache is handleing SSL, if you use letsencrpyt add an exclusion line like the below. Note the exclusion falls *before* the main Proxy statements.
Also on Ubuntu/Debian systems, you may need to enable the specific proxy module for apache. One of the shell commands bellow as needed..
Resolving 'client denied by server configuration'
If you get an error in the Apache error log like client denied by server configuration: proxy:ajp://127.0.0.1:8009/tomcat then you may need to enable Proxying. e.g. on Ubuntu/Debian systems change the Proxy * setting from Deny all to Deny none in /etc/apache2/mods-enabled/proxy.conf:
Run the following to enable mod-proxy-ajp and to change allow/deny setting..
Prevent mod_proxy abuse as an open proxy.
The 'ProxyRequests off' line is important, setting that to on will turn your server into an open proxy, which is not what you want. In some cases it is helpful to check across the entire apache configuration for cases where that may be present. Use something like the following snippet to find and fix those.
New installs of tomcat may disable the ajp connector by default. Once enabled you may need to add secretRequired='false' to allow ajp connections from apache. But do make sure in that case, tomcat is only listening on a trusted network (eg 127.0.0.1). It might look like this
If you have a very recent version of apache installed (2.4.41 or later) you could replace the secretRequired line above with 'secret=yourphrase' in the connector, and add that to the ProxyPass line shown above for added security.
mod_jk2 is an option on Apache setups prior to Apache 2.2 (e.g. RHEL4, Debian 3.1). It is not an option on newer setups (e.g. not on Centos5, FC5 or newer, Debian Etch, or Ubuntu 7.10). For the newer distros you would use mod_proxy instead.
mod_jk2 intercepts Apache requests to certain URLs and forwards them to your Servlet engine. For example, it can hand off requests to certain 'mount points' like /jsp to your Servlet engine. It can also hand off certain file types (e.g. *.jsp) to your Servlet engine.
mod_jk2 forwards the Apache requests to your Servlet engine via a socket using a protocol called ajp13. Both Tomcat and Jetty support the ajp13 protocol.
First Step: Serve Content on Default Servlet Port
The first step towards running your webapps with Apache as a front end, is to first get them working directly from your default servlet eninge port. 8080 is the default port for Tomcat (including JBoss/Tomcat) and Jetty. Taking this step before testing the mod_jk2 setup makes troubleshooting problems easier:
- Set up your web apps (you may use any of the installed Servlet engines, they all support mod_jk2).
- Make sure your can browse your webapp using a URL like: http://yourip:8080/jsp/index.jsp. When using Apache as a front end, it is best to not use a 'ROOT' mounted webapp.
- Do not run the iptables command to forward port 80 requests to the Servlet engine (since we want Apache to handle the incoming requests).
- Test you can load your web app on http://yourip/jsp/index.jsp
Note: your Servlet container needs to listen for connections from Apache. The Tomcat and Jetty installations on RimuHosting VPSs are set up this way by default. You just need to make sure they are running (see the Tomcat and Jetty start up instructions above).
Next Steps: Serving up your WebApp from Apache
RimuHosting have pre-installed the mod_jk2.so module binary for the Fedora, White Box Enterprise Linux 3 and recent Red Hat 9 distributions. (If your Red Hat VPS was setup prior to 2004, contact support for information on how to get the mod_jk2.so module).
mod_jk2 is configured in the /etc/httpd/conf.d/mod_jk2.conf file.
This file includes a sample 'Location'. It looks like this:
This Location tag will direct requests to http://yourdomain/jsp-examples to the jsp-examples webapp (if one exists) on your Servlet engine.
If you want to run your own webapp instead, just edit this file and rename jsp-examples to your own webapp's name. Alternatively you can add your own Location tags in /etc/httpd/conf/httpd.conf.
You can put the Location tag inside a VirtualHost tag if you want the Location to only work for a particular domain. Note: on some servers there seems to be a problem where the VirtualHost is ignored, and the Location is used across all domains. In this case you will need to setup a workers2.properties.
ROOT WebApps
If you want to have all requests go to Tomcat, use a Location of / and your requests will go to the Tomcat ROOT webapp.
If you want to mix and match Apache and Servlet engine requests for the domain, you may need to change the Location tag. For example, set it to /*.jsp and /*.do. This will make it so only the Servlet related requests go to the Servlet engine.
Tomcat Host Directive: When Each Domain Has Their Own Root Webapp
Do you have more than one domain and you want each domain to use a different root webapp? Then you will need to use Tomcat Host directives so that Tomcat knows which webapp to serve for which domain.
Setup Apache VirtualHosts. Then add a Location tag inside each of the VirtualHost directives in /etc/httpd/conf/httpd.conf, e.g.
In your server.xml file (usually /usr/local/tomcat/conf/server.xml) add something like:
These directives setup the default webapps for each of the virtual hosts.
Then restart Apache and Tomcat.
Note: The server.xml changes are only required if you want to run multiple virtual hosts with different ROOT webapps. If you just have multiple virtual hosts with uniquely named webapps, they are not required. Just use the regular Location tags and make sure the webapp name and the Location directory match.
workers2.properties: When Location Tags Inside VirtualHost Directives Do Not Work
On some versions of mod_jk2 and Apache we have noticed a problem where Apache ignores the VirtualHost that a Location tag is nested within. For example, a Location / inside one VirtualHost ends up applying to all VirtualHosts on the server. So that all requests go to Tomcat, not just the requests for the intended domain.
To workaround this problem, remove your Location directives. Create a /etc/httpd/conf/workers2.properties file. Then add directives like:
These directives will pass the requests to the named virtual hosts to your Java server. If you have yourdomain.com and www.yourdomain.com you'll need to add both those [uri] directives for each.
jk2_init Errors
Getting something like this in your apache error_log file?
We have seen these errors before. They do not appear to cause any problems. And according to our googling can just be ignored.
If you want to use Apache as a front end to Tomcat, skip this section.
If you want to use iptables to forward incoming requests on port 80 to Tomcat on port 8080, run these commands to setup an iptable rule:
First, stop and disable apache. Under Centos or Fedora try the following..
.. or if you have Debian/Ubuntu based systems try ..
.. then set the redirection up..
For RedHat/Fedora/CentOS based distros (if there is a file called /etc/redhat-release) use this:
For Debian based distros (if there is a file called /etc/debian_version) use this:
Proxy Ajp Cping/cpong Failed
You may get a QM_MODULES warning. You can safely ignore that. Our VPS servers are built without modules and with the iptable features built into kernel itself. The iptables scripts just do not detect that modules are not available and do not know to skip that step.
If you decide to turn off your iptables rules, run this:
For RedHat/Fedora/CentOS based distros (if there is a file called /etc/redhat-release) use this:
For Debian based distros (if there is a file called /etc/debian_version) use this:
If your application makes use of Java Sessions, you may need to tweak the Cookie Path attribute to make it work as expected. A common problem this might fix is when attempts to log in appear successful, but require you to log in again immediately.
The problem is that Java is sending a cookie path for a certain location, but Apache is configured to serve the application at a different location, so the browser receives the session cookie, but never sends it back because it never requests a page that matches the cookies location.
The original Set-Cookie header looks like this in the HTTP response
Proxy_ajp Error
If your application is not accessible at /myapp though, it won't ever send that cookie back in a request, so you don't appear to have working sessions. The solution is simple, but requires Apache 2.2 which introduced the ProxyPassReverseCookiePath setting with mod_proxy. Add this line to your Apache configuration to have Apache rewrite the Path attribute in the Set-Cookie header:
That will change the path attribute in the Set-Cookie response header to this:
And now your browser will send the cookie back on requests to your application.
