0 Replies Latest reply on Oct 30, 2007 11:37 PM by Trevor Merrill

    Apache + mod_proxy + Jboss virtual hosts HOWTO

    Trevor Merrill Newbie

      Here is a brief howto to get virtual hosts working. I have looked all over this forum and I could not find a good HOWTO so I am going to post my configs. This worked for me on Ubuntu 7.10 with JBoss AS 4.2.1 GA. I have an internal DNS record for www.test1.com and www.test2.com that resolves to a single IP.

      Apache mod proxy + JBoss AS virtual host example

      /etc/apache2/httpd.conf

      ProxyRequests Off
      
      <Proxy *>
       Order deny,allow
       Allow from all
      </Proxy>
      
      NameVirtualHost 192.168.1.93:80
      
      <VirtualHost 192.168.1.93:80>
       ServerName www.test1.com
       ProxyPass / http://www.test.com:8380/
      </VirtualHost>
      
      <VirtualHost 192.168.1.93:80>
       ServerName www.test2.com
       ProxyPass / http://www.test2.com:8380/
      </VirtualHost>
      

      jboss/server/default/deploy/test1.war/WEB-INF/jboss-web.xml
      <?xml version="1.0"?>
      <jboss-web>
       <context-root>/</context-root>
       <virtual-host>www.test1.com</virtual-host>
      </jboss-web>
      

      jboss/server/default/deploy/test2.war/WEB-INF/jboss-web.xml
      <?xml version="1.0"?>
      <jboss-web>
       <context-root>/</context-root>
       <virtual-host>www.test2.com</virtual-host>
      </jboss-web>


      jboss/server/default/deploy/jboss-web.deployer/server.xml
      <Server>
      
       <!--APR library loader. Documentation at /docs/apr.html -->
       <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
       <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
       <Listener className="org.apache.catalina.core.JasperListener" />
      
       <!-- Use a custom version of StandardService that allows the
       connectors to be started independent of the normal lifecycle
       start to allow web apps to be deployed before starting the
       connectors.
       -->
       <Service name="jboss.web">
      
       <!-- A "Connector" represents an endpoint by which requests are received
       and responses are returned. Documentation at :
       Java HTTP Connector: /docs/config/http.html (blocking & non-blocking)
       Java AJP Connector: /docs/config/ajp.html
       APR (HTTP/AJP) Connector: /docs/apr.html
       Define a non-SSL HTTP/1.1 Connector on port 8080
       -->
       <Connector port="8380" address="${jboss.bind.address}"
       maxThreads="250" maxHttpHeaderSize="8192"
       emptySessionPath="true" protocol="HTTP/1.1"
       enableLookups="false" redirectPort="8443" acceptCount="100"
       connectionTimeout="20000" disableUploadTimeout="true" />
      
       <!-- Define a SSL HTTP/1.1 Connector on port 8443
       This connector uses the JSSE configuration, when using APR, the
       connector should be using the OpenSSL style configuration
       described in the APR documentation -->
       <!--
       <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
       maxThreads="150" scheme="https" secure="true"
       clientAuth="false" sslProtocol="TLS" />
       -->
      
       <!-- Define an AJP 1.3 Connector on port 8009 -->
       <Connector port="8009" address="${jboss.bind.address}" protocol="AJP/1.3"
       emptySessionPath="true" enableLookups="false" redirectPort="8443" />
      
       <Engine name="jboss.web" defaultHost="localhost">
      
       <!-- The JAAS based authentication and authorization realm implementation
       that is compatible with the jboss 3.2.x realm implementation.
       - certificatePrincipal : the class name of the
       org.jboss.security.auth.certs.CertificatePrincipal impl
       used for mapping X509[] cert chains to a Princpal.
       - allRolesMode : how to handle an auth-constraint with a role-name=*,
       one of strict, authOnly, strictAuthOnly
       + strict = Use the strict servlet spec interpretation which requires
       that the user have one of the web-app/security-role/role-name
       + authOnly = Allow any authenticated user
       + strictAuthOnly = Allow any authenticated user only if there are no
       web-app/security-roles
       -->
       <Realm className="org.jboss.web.tomcat.security.JBossSecurityMgrRealm"
       certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping"
       allRolesMode="authOnly"
       />
       <!-- A subclass of JBossSecurityMgrRealm that uses the authentication
       behavior of JBossSecurityMgrRealm, but overrides the authorization
       checks to use JACC permissions with the current java.security.Policy
       to determine authorized access.
       - allRolesMode : how to handle an auth-constraint with a role-name=*,
       one of strict, authOnly, strictAuthOnly
       + strict = Use the strict servlet spec interpretation which requires
       that the user have one of the web-app/security-role/role-name
       + authOnly = Allow any authenticated user
       + strictAuthOnly = Allow any authenticated user only if there are no
       web-app/security-roles
       <Realm className="org.jboss.web.tomcat.security.JaccAuthorizationRealm"
       certificatePrincipal="org.jboss.security.auth.certs.SubjectDNMapping"
       allRolesMode="authOnly"
       />
       -->
      
       <Host name="localhost"
       autoDeploy="false" deployOnStartup="false" deployXML="false"
       configClass="org.jboss.web.tomcat.security.config.JBossContextConfig"
       >
      
       <!-- Uncomment to enable request dumper. This Valve "logs interesting
       contents from the specified Request (before processing) and the
       corresponding Response (after processing). It is especially useful
       in debugging problems related to headers and cookies."
       -->
       <!--
       <Valve className="org.apache.catalina.valves.RequestDumperValve" />
       -->
      
       <!-- Access logger -->
       <!--
       <Valve className="org.apache.catalina.valves.AccessLogValve"
       prefix="localhost_access_log." suffix=".log"
       pattern="common" directory="${jboss.server.home.dir}/log"
       resolveHosts="false" />
       -->
      
       <!-- Uncomment to enable single sign-on across web apps
       deployed to this host. Does not provide SSO across a cluster.
      
       If this valve is used, do not use the JBoss ClusteredSingleSignOn
       valve shown below.
      
       A new configuration attribute is available beginning with
       release 4.0.4:
      
       cookieDomain configures the domain to which the SSO cookie
       will be scoped (i.e. the set of hosts to
       which the cookie will be presented). By default
       the cookie is scoped to "/", meaning the host
       that presented it. Set cookieDomain to a
       wider domain (e.g. "xyz.com") to allow an SSO
       to span more than one hostname.
       -->
       <!--
       <Valve className="org.apache.catalina.authenticator.SingleSignOn" />
       -->
      
       <!-- Uncomment to enable single sign-on across web apps
       deployed to this host AND to all other hosts in the cluster.
      
       If this valve is used, do not use the standard Tomcat SingleSignOn
       valve shown above.
      
       Valve uses a JBossCache instance to support SSO credential
       caching and replication across the cluster. The JBossCache
       instance must be configured separately. By default, the valve
       shares a JBossCache with the service that supports HttpSession
       replication. See the "jboss-web-cluster-service.xml" file in the
       server/all/deploy directory for cache configuration details.
      
       Besides the attributes supported by the standard Tomcat
       SingleSignOn valve (see the Tomcat docs), this version also
       supports the following attributes:
      
       cookieDomain see above
      
       treeCacheName JMX ObjectName of the JBossCache MBean used to
       support credential caching and replication across
       the cluster. If not set, the default value is
       "jboss.cache:service=TomcatClusteringCache", the
       standard ObjectName of the JBossCache MBean used
       to support session replication.
       -->
       <!--
       <Valve className="org.jboss.web.tomcat.service.sso.ClusteredSingleSignOn" />
       -->
      
       <!-- Check for unclosed connections and transaction terminated checks
       in servlets/jsps.
      
       Important: The dependency on the CachedConnectionManager
       in META-INF/jboss-service.xml must be uncommented, too
       -->
       <Valve className="org.jboss.web.tomcat.service.jca.CachedConnectionValve"
       cachedConnectionManagerObjectName="jboss.jca:service=CachedConnectionManager"
       transactionManagerObjectName="jboss:service=TransactionManager" />
      
       </Host>
       <Host name="test1" autoDeploy="false"
       deployOnStartup="false" deployXML="false">
       <Alias>www.test1.com</Alias>
       <Valve className="org.apache.catalina.valves.AccessLogValve"
       prefix="test1" suffix=".log" pattern="common"
       directory="${jboss.server.home.dir}/log"/>
      
      
       <DefaultContext cookies="true" crossContext="true" override="true"/>
       </Host>
       <Host name="test2" autoDeploy="false"
       deployOnStartup="false" deployXML="false">
       <Alias>www.test2.com</Alias>
       <Valve className="org.apache.catalina.valves.AccessLogValve"
       prefix="test2" suffix=".log" pattern="common"
       directory="${jboss.server.home.dir}/log"/>
      
      
       <DefaultContext cookies="true" crossContext="true" override="true"/>
       </Host>
       </Engine>
      
       </Service>
      
      </Server>


      This is a way that worked for me. If anyone, especially the developers see a flaw in my method please let me know. Or if anyone has a better way I would love to see it. This is the only way I could get it working.