Entries : Category [ Apache ]
The apache web server and its modules
[OpenBSD]  [BSD]  [FreeBSD]  [Linux]  [Security]  [Python]  [Zope]  [Daily]  [e-shell]  [Hacks]  [PostgreSQL]  [OSX]  [Nintendo DS]  [enlightenment]  [Apache]  [Nintendo Wii]  [Django]  [Music]  [Plone]  [Varnish]  [Lugo]  [Sendmail]  [europython]  [Cherokee]  [self]  [Nature]  [Hiking]  [uwsgi]  [nginx]  [cycling]  [Networking]  [DNS] 

05 enero
2008

Rewriting requests based on ip addresses

or how to put those users where they should be...

I found that recipe very useful only 2 days ago.

Imagine you manage a web server, in that web server you have a website with some dynamic-like control panel, where users can log in and modify contents.

Now think about the time when you need to do some modifications/updates on the website code. In an do-the-right-things world you would have a server with a versioning control system (like svn, cvs or darcs) where the website source code will be stored. Of course you would have a development web server, where the changes will be tested before commiting them to the source tree. In that case, you shouldn't need to follow this recipe.

But what happen when you don't have such infraestructure or for any other reason, you have to do the changes directly on the production website code? You probably would like to disable access temporaly to any other user except you.

Well, knowing the problem, let's take a look at the solution. Of course, you could use basic http authentication to protect the directory where the website is located, but that will result in an ugly prompt about user and password information. Another approach should be to move aside the directory where the website code is, and replace it with a directory with only a temporaly index file, but that will not allow you to test in real time your changes to the source code. Finally, you could put just a simply index.html/index.htm/index.php/etc file inside the website directory and change the VirtualHost DirectoryIndex directive, but that will not deny access to users, it will hide such access, but any average user could be able to log in anyway.

So, let's take a look at some mod_rewrite magic to find a more elegant solution:

<IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteLogLevel 9
        RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.10
        RewriteCond %{REQUEST_URI} !^/tmp/
        RewriteRule ^(.+) /tmp/$1 [L]
        RewriteLog      /var/log/apache2/vhostname-rewrite.log
</IfModule>

Adding that to your VirtualHost configuration (and if your Apache server has support for mod_rewrite) will activate the rewrite engine, adding two conditions to it.

The first condition:

RewriteCond %{REMOTE_ADDR} !^192\.168\.1\.10

means where remote ip address is not 192.168.1.10.

The second condition:

RewriteCond %{REQUEST_URI} !^/tmp/

means where the request URI is not /tmp.

Finally, we add a rewrite rule:

RewriteRule ^(.+) /tmp/$1 [L]

that will send the users to where they should be.

So, what does this all means? It means that every request coming from an ip address different than 192.168.1.10, trying to get access to any directory or file different than /tmp, will be redirected to that directory.

Now you only have to create a directory called tmp inside the website directory and put in there whateve you want (probably an index file with some css and images).

Of course this is only an example about how to use this basic ip address filtering. You could use that for serve content dinamically based on ip address and for much more. If you want to learn more about mod_rewrite and its capabilities, just take a look at the apache rewriting guide.

Posted by wu at 03:01 | Comments (2) | Trackbacks (0)
28 enero
2009

Monitoring apache VirtualHosts activity

apache + top, soon on shells near you!

For the last few days I've been monitoring (using the classic top utility) the load of apache processes in one of my webservers. Everything went as expected but, from time to time, one of the apache processes went crazy, reaching 40-50% of CPU use. It is not so important, but I began to think about how usefult it would be to know which VirtualHost is accessed by the request managed by such apache process...

Being honest, my first thought was to code something to do it, but soon I realized it should exist already a tool to do it. A quick search through google and I found an option, apachetop (which is already in the FreeBSD ports). This tool simply does some parsing on apache access logs and show in real time the urls that are being accessed.

It is a useful tool, for sure, but it was not what I was searching for. So, I did some more research, just to find apache-top.

Apache-top is a small python script that will monitor an apache web server /server-status url (more info on the mod_status page from the apache project), displaying it's information in a top-like curses interface. This information includes the pid of each apache process, the VirtualHost ServerName for the request handled by such process and a lot more information.

In FreeBSD to get it working you only have to edit /usr/local/etc/apache22/httpd.conf (if you are using other version than apache 2.2, it could be apache2/ or apache/ instead of apache22/) and uncomment the line:

#Include etc/apache22/extra/httpd-info.conf

Then you will have to edit /usr/local/etc/apache22/extra/httpd-info.conf. There you have to locate the <Location /server-status> directive and change:

Allow from .example.com

to

Allow from 127.0.0.1

This way, you will allow only requests from localhost for the /server-status location (just as a security measure).

Next, uncomment the following line (to activate extended reports):

ExtendedStatus On

And comment the following ones (as they are not needed for apache-top:

<Location /server-info>
    SetHandler server-info
    Order deny,allow
    Deny from all
    Allow from .example.com
</Location>

Then you will have to restart apache, to the changes to have effect:

sudo /usr/local/etc/rc.d/apache22 restart

Ok, almost done, now you will have to download apache-top.py (http://www.fr3nd.net/stuff/projects/apache-top/apache-top.py) and you can rename it to get rid of the .py extension:

cd ~/bin && wget http://www.fr3nd.net/stuff/projects/apache-top/apache-top.py && mv apache-top.py apache-top

Finally, you can call apache-top from a shell to get the information:

apache-top -u http://localhost/server-status

and you should get something like:

apache-top in my e17 desktop, eterm!

Nice, isn't it?

There you will see not only the apache process and the related vhost access, but the cpu load, the ip address from the request is coming and even the url accessed. That's pretty much the thing I was searching for :D

Posted by wu at 19:30 | Comments (0) | Trackbacks (0)
05 febrero
2010

tracd behind an apache2 proxy

wrong redirect after adding a ticket

I found this weird behaviour with tracd and an apache proxy today, while setting up some public trac access for one of our projects.

This is the setup (click on the image for a larger version):

tracd behind an apache 2.2 proxy

The idea is pretty basic, there is an Apache server running with SSL support and accepting requests for https://my.publicname.com. It is configured to act as a reverse proxy for the server running tracd behind it, accepting requests for http://192.168.1.2:8000.

So, in the example someone could open up a browser, put https://my.publicaddress.com/project in the address/location bar and access that project trac page. The process would be:

Nice!! but... it failed when I tried to add a ticket using a external connection. :(

Each time I tried to add a ticket, after it was added, my browser was redirected to http://192.168.1.1:8000/project/ticket/(ticketnumber) instead of https://my.publicaddress.com/project/ticket/(ticketnumber). Ugly. It seemed like trac was building the url internally and, of course, that internal url will not work from outside.

After some read-and-try, I found that the problem could be solved editing my trac env trac.ini config file, and replacing:

base_url =

[ ... ]

use_base_url_for_redirect = False

with:

base_url = /project

[ ... ]

use_base_url_for_redirect = True

This solved the problem, allowing me to use the trac instance from both within the LAN and from the outside.

Posted by wu at 16:24 | Comments (1) | Trackbacks (0)
[1]