Categories
Blog Technology

Configure Xwiki as Root Website

Once Xwiki is installed and running, the default URL is http://wiki.petersens.ws/xwiki. Which is ok and works, however I don’t like specifying the application after the website. If I typed http://wiki.petersens.ws, tomcat would display it’s default banner. Instead I really wanted Xwiki to come up.

To change this behavior I needed to make 2 changes. 1/ deploy Xwiki as ROOT in tomcat and 2/ tell Xwiki that the URL and web app doesn’t contain the /xwiki/ application.

To deploy the application as root within tomcat, I deleted tomcat/webapps/ROOT directory. I then renamed the extracted xwiki folder to ROOT and renamed the war file xwiki.war to ROOT.war.

To update xwiki I modified the xwiki.cfg file. The file is now located in tomcat/webapps/ROOT/WEB-INF directory. There were 2 variables that needed to be uncommented and updated as follows:

xwiki.home=http://wiki.petersens.ws/
xwiki.webapppath=

After that is was simply a matter of restarting tomcat with a systemctl restart tomcat.

Categories
Blog Home

Now We’re Talking Squid!!

Victory is mine!!!

I’ve been running the Squid proxy server in the house for the past two+ years. In our house if you want to get to the Internet, you have to point your browser to the Squid proxy. Otherwise, no dice on the Internet access. I set this up so that I could keep a liberal policy on computer usage in our house while at the same time keeping an eye on the kids. On top of Squid I’ve been using MySAR for the reporting and it has been doing a very nice job, although the MySAR interface is getting old.

For the Blog, I had the router forward all the port 80 inbound web traffic to the web server. As long as I could run everything off a common Apache server, this setup worked just fine. For this blog I’ve been runningĀ  WordPress. I’ve been very happy with WordPress so far.

Lately I’ve been help my good friend, Dave, with some web site work. Eventually the websites will be hosted at a still undetermined hosting provider. But for now I needed to bring them up on my home server. At first I just needed to resolve the domains to the single Apache server. No problem. The home network can easily handle this.

Then things got a little more complicated, I also needed to bring up a wiki. For the wiki I wanted to stay with Confluence. I like the Confluence wiki. Its easy to setup and maintain. Even in large installations it is quick and runs on minimal hardware.

We wanted to have the primary domain, www.agsaurora.com resolve to the Apache web server. But we wanted wiki.agsaurora.com to resolve to the Confluence server. Home routers, while they provide a lot of functionality that 98% of the people don’t even know exists, they can’t perform layer 7 content switching. Initially to get the wiki up and running I had the home router forward port 8080 to the server running Confluence. If you typed www or wiki.agsaurora.com:8080, it would redirect to the wiki. Problem with that is the URL’s are ugly. Who wants to see “:8080” in the URL. Second issue was that any sub-domain under “*.agsaurora.com:8080” would resolve to the wiki. Not clean and not elegant.

I looked on ebay for something that could provide the functionality that I needed, but the hardware was way to expensive. So I started to look for an Open Source software solution. The load balancing software solutions were complicated to setup and maintain. I was looking for a simple solution. Then I rediscovered Squid! The reverse proxy acceleration was exactly what we were looking for. All the traffic would be forwarded to the Squid server and I had to only open the single port 80 to the Internet. Squid would then proxy the requests to the correct backend server:port. This setup gave me an added bonus! It gave me positive control over the sub-domains and where they landed. It was relatively easy to get wiki.agsaurora.com to resolve to the Confluence server on port 8080 and all the other web traffic, like www.agsaurora.com or download.agsaurora.com, to resolve on the Apache web server on port 80.

Here is the snipet of the Squid Config that performs the magic:

# Squid normally listens to port 3128
http_port 80 accel vhost

acl myhost dstdomain .petersens.ws
acl myhost dstdomain .agsaurora.net .agsaurora.com
acl mywiki dstdomain wiki.agsaurora.net wiki.agsaurora.com

#setup cache peers for accelration
cache_peer 10.10.1.4 parent 80 0 no-query originserver name=xenweb login=PROXYPASS
cache_peer 10.10.1.5 parent 8080 0 no-query originserver name=xenshare

cache_peer_access xenweb deny mywiki
cache_peer_access xenweb allow myhost
cache_peer_access xenshare allow mywiki
always_direct deny myhost
always_direct deny mywiki

Eleven lines of configuration. It took the better part of three hours to get this config just right so that I can still use the Squid proxy to capture all the Internet bound traffic while at the same time perform the reverse proxy acceleration. The cache_peer and cache_peer_access lines setup the reverse proxy. The two last lines, always_direct, allows all the internally generated traffic to pass through the proxy to the outside world. I double checked the MySAR application after setting everything up and it was still processing all the logs just fine! So I can still monitor what the kids are up to on the Internet!!! VICTORY!!!

WP2Social Auto Publish Powered By : XYZScripts.com