My Drupal Web Stack - new and improved

It's amazing how sometimes breaking through a major obstacle leads to new and improved technologies.

I had recently realized that one of my servers had been compromised. Hacked into. The best solution I had come up with was to rebuild the server. I quickly did a backup of the databases and all the code and moved them off of the server.

When spinning up a new server, I had the chance to finally move to a different tech stack I had been wanting to use.

1. CentOS 7
2. Nginx
3. MariaDB

This meant no more Apache and no more MySQL. The change between MySQL and MariaDB was really only in the name. There was no change in code or scripts for what I was doing. Awesome!

The Nginx implementation was a lot easier than I thought it was going to be too. I had some Nginx experience from a past contract and knew of the performance increase. Some configuration changes and learning how to setup multiple virtual hosts, and that was that.

At this point, the basic installation seems as fast as my previous Apache + Memcache install.

What is left?

Well this was a very quick implementation in-order-to get my websites moved to a different server. As fast as the stack is right now, I still want to install Memcache as well as Varnish.

Here are a couple of great articles that I used to setup my server and get Drupal 7 running with Nginx and MariaDB.

https://www.rosehosting.com/blog/how-to-install-lemp-linux-nginx-mariadb-php-fpm-on-a-centos-7-vps/

https://www.rosehosting.com/blog/how-to-install-drupal-7-on-centos-7-with-nginx-mariadb-and-php-fpm/

Don't forget to install Drush on your new server. It's too easy:
https://www.drupal.org/node/2132447

A little bit of learning, but I'm very happy with the LEMP and Drupal 7 configuration.

Backup and Migrate - Restore 1 Table

Well I never thought about trying this before, and there was no reason why it wouldn't work, but restoring a single table into a Drupal website using the Backup and Migrate module worked like a charm!

Scenario

I'm using the IP Ranges module on several websites across several servers. Most of the time the websites have content that is specific to certain geographic regions or countries, so getting hit a ton by China, Russia, or Brazil isn't desirable.

Also, adding the IP Ranges entries to each website (or even a new one) is tedious.

Enter Backup and Migrate

On one site, I do all of my manual entries using the IP Ranges interface. Then I can do a backup of the IP Ranges table from this site. The backup will contain info for just IP_RANGES and nothing else. I do not want to break my other sites. I have a Settings Profile for IP Ranges and then I do a manual backup.

On another site, do a restore using that backup file. But wait.....read below.

One Gotcha!

The backup contains a "DROP TABLE IF EXISTS" statement for ip_ranges. Now the script should be fairly quick, but dropping the table while the module is enabled can cause issues for the site if someone visits.

What I like to do is replace the statement in the script with "TRUNCATE" giving: TRUNCATE `ip_ranges`;

double check the rest of the script to make sure you haven't accidentally included other stuff.

Then run the script through the rest of the sites!

I'd rather use Firewall rules, but I need to do more research on that. I've broken access to sites before because I've entered the wrong Firewall rule. :P

Blocking the Spammers

Stop the spammers and bad referrers.

This is a compilation of info I found on various sites.

Add this to the end of your .htaccess file:

SetEnvIfNoCase Via evil-spam-proxy spammer=yes
SetEnvIfNoCase Referer evil-spam-domain.com spammer=yes
SetEnvIfNoCase Referer evil-spam-keyword spammer=yes
SetEnvIfNoCase Via pinappleproxy spammer=yes
SetEnvIfNoCase Referer semalt.com spammer=yes
SetEnvIfNoCase Referer semalt.semalt.com spammer=yes
SetEnvIfNoCase Referer poker spammer=yes

Order allow,deny
Allow from all
Deny from env=spammer

Drupal Modules I use:

ip_ranges - https://www.drupal.org/project/ip_ranges - Block entire range of IP's.

Additional Sites:

http://myip.ms/info/whois/  OR any other popular Whois database. I use this to see the range of IP's I want to exclude. 

This process is a little long for me. Going through the logs and seeing what IP's are hitting bad URL's or protected URL's. Then find the IP range and enter into IP Ranges.  I'd like to see a nice report that uses a Whois database to show where the requests are coming from.

I'm still looking for a better overall solution. For example, I've got to be able to put the rules somewhere in my Apache config to cover all the sites on my server, rather than configuring each one individually, I just haven't taken the time to do it yet. We'll see. :)

Module - Front Page

Do you want different user roles to have different Front pages when they login or go to the Home page?

The Front Page module (https://drupal.org/project/front) works very well for that.  18,109 reported installs at the time of this writing.

If you want token support, 7.x-2.4 and lower will need a patch: https://drupal.org/node/1786128

Front Page handles roles in the reverse order of what you have defined in the Role arrangement and creation page (admin/people/permissions/roles), so Admin role, then Authenticated, and then finally Anonymous role will be processed when implementing a custom front page.

Here's a screenshot of 2 roles, Authenticated and Anonymous.

As an example, for an e-commerce site and with token support, I can redirect a "customer" role to their Orders page.

More advanced users and cases will probably want to use Rules.