The trouble was that I have lots of site (like this one!) that rely on a myriad of rewrite rules and logic to direct users properly.  Because we lose the mod_rewrite provided by apache, we need to tell nginx about our rewrite rules.

Luckily the logic is very similar, and all expression based as before…

create domain specific configuration

The first step is creating directories for each site you want to customize.  Any file within this directory will be read into configuration when nginx starts or reloads.

/home/my_user/nginx/edwardawebb.com/wordpress.conf

Harvest those .htaccess files

next we turn to our existing rules as a launch pad for our new rewrite logic.

your apache rule (from .htaccess)

RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

your new nginx config (into wordpress.conf)

if (!-e $request_filename) {
rewrite ^(.*)$ /index.php?url=$1 last;
}

Note the similarity!

” if the path they are looking for does not exist, give them this path instead. ”

The differences are subtle but important.  Apache assumed absolute paths in the created path, so index.php would be /index.php – but nginx does not make that assumption, so we need to explicitly include the root /.

Got more rules to rewrite?

I am actually finding nginx’s logic based syntax much easier to master than Apache’s.  You can specify rules for specific domains or servers, and use many variables including the user agent and

http://nginx.org/en/docs/http/converting_rewrite_rules.html

http://wiki.nginx.org/NginxConfiguration

Reload nginx

For any changes to take affect you will need to force nginx to reload.

sudo /etc/init.d/nginx reload

If you still have questions maybe it is because you have not read the page here – but please post your thoughts!

IMpossible you say? Not with the release of Apache 2.2.13!

I stumbled on this nice little feature called SNI (or Server Name Indication) that allows multiple domains to share an IP and implement SSL without showing warnings to users or confusing Apache.  I found this beauty after reading another great article on Linux Magazine, Ten Things You Didn’t KNow Apache (2.2) Could Do

So those of you running your own servers can take advantage by upgrading today!

For those of you relying on a Host you should start bombarding them with requests immediately. DreamHost members can vote up the already created suggestion  to implement this.

Hotlinking is when users insert a url to your images on their own site rather than linking to your page (or just uploading the image to their own servers)

What is a simple webmaster like yourself to do with these hooligans that are chewing away at your bandwidth allocations? Well block them of course.  The solution is simple and straightforward.

Best of all you can even server up a humorous or fearful image to replace the one being hijacked.

The problem:

You innocently hosted a sweet background image or icon only to find that devilish designers or bloggers are hotlinking to the image within their own sites.

The solution:

Catch the incoming requests and instead return a static image that warns they have been caught in the act.  The image should be of minimal size to lower bandwidth consumption.

Implementation:

Again we will rely on the quintessential Apache Rewrite module to preform this task.

Open up the .htaccess file in your top-most directory and add the following snippet;

<FilesMatch "\.(png|gif|jpg|jpeg|bmp)$">
SetEnvIfNoCase Referer "^http://([^/]*\.)?example.com/" requested_locally=1
RewriteCond %{ENV:requested_locally} !=1
RewriteRule ".*" "/no-hotlink.gif" [L]
</FilesMatch>

What’s all this then? Here’s a breakdown line by line;

• For any files that end with image extensions, use the following rules
• Case insensitive check against the headers referrer sent by browser. (yes referrer is spelled wrong as it was in the original specs) If the referrer is your own, set an environmental variable to 1
• If our environmental variable is not set (meaning its not a local request)
• Then send them an ugly/funny/angry photo instead
• end rules for files matching image extensions

Doesn’t matter whether it’s a CakePHP app for a client, your own personal CMS, or any other web based application. If your passing around passwords or other sensitive info you should really implement SSL. SSL provides 2 main perks to your visitors.

• First it encrypts all communication that flies across the web. This prevents curious or devious billies from getting your secrets.
• Secondly it ensures to the user that your server is in fact who it claims, and not a nasty ‘man in the middle” attack.
• Finally it gives your site that touch of class…. which of course a classy person like yourself relies on.

Once you implement SSL certificates on your server you’ll want to require secure connections using Apache’s rewrite module.

Now I won’t dwell on the creation and signing of certificates, its already well documented.  If your just starting out though,heres a few links I recommend;

• Creating self-signed certificates (free, but should only be used internally or for testing, users will; see an ‘Untrusted” warning)
• Requesting a CA Signed certificate (not free, but the final certificate is trusted and seamless for users)

The second link uses the schools internal CA, you will need to pay a public CA like Entrust or Verisign.

All of this information is aimed at ‘nix or solaris servers running apache. Why? cause a production windows server is laughable :-p

Now that you have a certificate, whats next?

So there you are you have a shiny new Certificate and Server key, how do you force visitors to your apache driven site to use the SSL?

You copied the certificates into the appropite locations right?

And you have made the needed changes in httpd.conf right?

So now when you view https://example.com you see a ‘trusted’ warning or your site right?

If No to any of these than this article does a pretty good job of outlining those steps.

The SSL Works, How do I force connections to use it?

First you need to decide if you want to force every page on your site to use SSL, or only a particular sub-domain, or maybe just your admin directory.  Since the overhead is minimal there is no harm is forcing the entire domain to leverage SSL, but if it is a self-signed certificate for your personal use than you’ll most certainly want to restrict its use to your own areas. This prevents users from seeing that nasty warning “This server is not trusted”

You’ll know if your using SSL because the url prefix changes from http to https (s for secure).

Forcing entire domain to use SSL

You want any visit, any where to use ssl. This probably the simplest solution.

Create or append to your htaccess file in the top directory of your server. Some people use a port check (80 is typically http, while 443 is https) but if you have alernate configs or the user just adds :8080 to the end of the url this method is useless.

Instead check whether the https environmental variable is set, if not then redirect.

RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{SERVER_NAME}$1 [R,L]

Forcing sub-domains to use SSL

Maybe you only want mysecretarea.example.com to use SSL, that’s easy enough.

Its the same premise as above, but you move the htaccess file into the directory that corresponds to the subdomain. Also change the second line like below;

RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://mysecretarea.%{SERVER_NAME}$1 [R,L]

Forcing a directory to use SSL

This method cn get a little hairier if your using aliases or redirects on top of this one. You’ll need to consider what order the commands are read. The basic principle is like so.  You want all visits to example.com/admin to use ssl.

Create a htaccess file in the parent directory.  Again will check for the https variable, but this time we also check for the sub-directory to be in the path.

RewriteCond %{HTTPS} !=on
RewriteRule ^/admin/(.*)$ https://%{SERVER_NAME}/admin/$1 [R,L]

Changing out your index page will only work for users who go to your main pages.

In order to effectively block all pages, and redirect to a proper message, I recommend using apache’s .htaccess.

The best part about this feature is you can still allow your development team to access the site while blocking everyone else.

There are two main pieces to this method;

1. Create a pretty, funny or informational page explaining why users can’t reach the good stuff.
2. Create an .htaccess file to point all request (except yours) to the page above.

The site down message

A simple ‘This site is down for maintenance” works, but how boring!  Instead you’ll see a lot of sites using humor to mask the horrible technical struggle that may be taking place behind the scenes.  Elaborate messages like “Unfortunately our intern, Scott, decided that CAT 5e cables are overrated. However he soon discovered that telepathy is not a common trait among servers.  Please be patient as we work to restore service.” may or may not hit your target audience. But whatever the case try to be unique in the way that your users have come to rely on.

sitedown.html

<html>
<head>
<title>Baby come back</title>
</head>
<body>
<h1>This site is down, but no need for alarm</h1>
<p>
You were right, it wasn't you.. it was us.</p>
<p>But we're different know, and we really <em>want</em> to change.</p>
<p>Give us another chance, and by tomorrow we'll be a whole new site, a better site, promise.</p>
'<h4>Service should be restored by the end of October 29th</h4>
<p>We apologize for any inconveniences caused</p>
</body>
</html>

The redirect

Once you’ve created your page, whatever it may say, save it to the root directory of your site.

The .htaccess is a file read by apache when a directory is accessed.  For redirection it requires that mod_rewrite is enabled in apache.  There is already much good information on general practice and such for .htaccess, so we’ll keep it simple here.

Basically we’ll use some regular expressions to apply  rules to all incoming requests.

1. IF  the request is not from an internal IP address
2. AND it is not for our sitedown page (that would cause an infinite redirect loop, oh my!)
3. THEN send them to the site down page instead.

in /.htaccess

RewriteEngine On
RewriteBase /
RewriteCond %{REMOTE_ADDR} !^10\.103\.18\.104     # <--YOUR IP HERE
RewriteCond %{REQUEST_URI} !^/sitedown\.html$                      
RewriteRule ^(.*)$ http://example.com/sitedown.html [R=503]

The piece [R=503] is the type of header sent to the requester, and used by search engines and other bots. You should not use 404 or other 400 level errors. 404 for example means “this page does not exist” (and never will). In reality our page could be valid on any other day.

503 in contrast means “service (temporarily) unavailable.” It indicated the redirect to be temporary in nature, as appose to a 301, or 404 meaning permanent. This tells Google that your site , and all its pages will be back eventually, and to not purge them from its index.

Another perk of 503 is that dependent services on your site can intelligently relay the message to users.

That’s it!

Just restart apache to pick up the changes;

/etc/init.d/apache2 restart

Troubleshooting

1. Nothing happens!
   No worries, check in httpd.conf or default-server.conf for code that looks similar to whats below AND references your web root directory. In this case it is my /src/www/htdocs directory.
   

   #
   # Configure the DocumentRoot
   #
   
   #
   	# Possible values for the Options directive are "None", "All",
   	# or any combination of:
   	#   Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
   	#
   	# Note that "MultiViews" must be named *explicitly* --- "Options All"
   	# doesn't give it to you.
   	#
   	# The Options directive is both complicated and important.  Please see
   	# http://httpd.apache.org/docs-2.2/mod/core.html#options
   	# for more information.
   	Options All
   	# AllowOverride controls what directives may be placed in .htaccess files.
   	# It can be "All", "None", or any combination of the keywords:
   	#   Options FileInfo AuthConfig Limit
   	AllowOverride All
   	# Controls who can get stuff from this server.
   	Order allow,deny
   
   	Allow from all
   
   

   Make sure the AllowOverride is set to All.

2. Error about infinite loop
   Make sure you have a line like the one below, and that it accurately reflects the location of your message page.

   RewriteCond %{REQUEST_URI} !^/sitedown\.html$

   Notice the characters

   !, ^, $

   , these are special metacharacters. ! means NOT, ^ is the start just after your domain, and $ is the end of the url. So it meets my example of “http://example.com/sitedown.html”

To understand this need you are liekly working on multiple sites at once on your local development machine.  So lets say you have an excellent CakePHP application, a gnarly JS sandbox, and your personal start page all belonging to different directories. Problem is, there is only one localhost.  But just like your live server can have subdomains, you can skip DNS and use virtualhosts in Apache do the work.  Imagine, unlimited sub domains all live at one on your localhost pointing to folders all across your machine.

First off I will be be clear that this is instructions for a Linux device.  If your not running Linux, then start today. You’ll be happy you made the switch to the ubiquitous LAMP architecture.

First thing to do is choose a subdomain for each folder, in my case I have two sub domains;

• digbiz.localhost             -   /home/eddie/workspace/Digital_Business/
• phpmyadmin.loclahost   -   /srv/www/phpMyAdmin

These are in additions to my usual localhost path;

• localhost                      -  /srv/www/htdocs/

Setting your top domain – localhost

Most of you have already done this step long ago, but just to be certain, you have set your documentroot and settings in

/etc/apache2/default-server.conf

#
# Global configuration that will be applicable for all virtual hosts, unless
# deleted here, or overriden elswhere.
# 

DocumentRoot "/srv/www/htdocs"
#
# Configure the DocumentRoot Properties
#
<Directory "/srv/www/htdocs"> 
	Options All
	# AllowOverride controls what directives may be placed in .htaccess files.
	# It can be "All", "None", or any combination of the keywords:
	#   Options FileInfo AuthConfig Limit
	AllowOverride All
	# Controls who can get stuff from this server.
	Order allow,deny
	Allow from all
</Directory>
#
# Configure Sub-Domain Properties. This prevents those nasty 403 errors
#

# mysql administration tool
<Directory "/srv/www/phpMyAdmin/">
	Options Indexes MultiViews
	AllowOverride All
	Order allow,deny
	Allow from all
</Directory>
 
# a client web site built with CakePHP
<Directory "/home/eddie/workspace/Digital_Business/app/webroot/">
	Options All
	AllowOverride All
	Order allow,deny
	Allow from all
</Directory>

Setting your sub domain’s paths

In order for this to work we’ll need to be specific about which sub domain points where, easy enough. You’ll notice I am not using httpd.conf, but rather a configuration file in a sub direcotry that is referenced in the main configuration file. This is the typical setup, and any *.conf file in most of the *.d directoriess should be read. If the folder vhosts.d does not exist, add this code directly to the end of httpd.conf.

/etc/apache2/vhosts.d/subdoms.conf

NameVirtualHost localhost:80
# the mysql tool's url
<VirtualHost phpmyadmin.localhost:80>
# and absolute path
DocumentRoot "/srv/www/phpMyAdmin/"
</VirtualHost>
#Same for the Client Site
<VirtualHost digbiz.localhost:80>
DocumentRoot "/home/eddie/workspace/Digital_Business/app/webroot/"
</VirtualHost>

You may add as many as you want ( to a limit I Imagine) by adding more of the < through> blocks. The very first line of the code should only be used once.  The names you use here are the host names we’ll need below, so keep note.

Setting your new sub domains as valid hosts

For this part you need to edit your you can either edit /etc/hosts directly, or for those who are unsure, use the systems administration panel > network (services) > host(name)s.  I’m running suse so my system panel is Yast, for you it may differ.

Begin by launching the Adminstration Panel

Run the Host Configuration module

Once your inside the Host configuration module (or hosts file) just add a new record for every sub domain. In my example I use ::1 as the IP address only because IPv6 is enabled on my server. You may need to use 127.0.0.1.

Enter each sub domain as a new record

If you open that image up you’ll see I have already added ‘digbiz.localhost’ and was in the process of adding ‘phpmyadmin.localhosts.’  Remember, these are the virtual hosts we setup just before.

Restart Apache

Once your done adding the sub-domains clcik finish and the settings will be saved. You can now restart apache and test it out.

# /etc/init.d/apache2 restart

Note: I was curious if you could set up completely new domains, mylocalhost. I didn’t have much luck though. If anyone has a reason, or has in fact succeeded I would love to hear about it.