George Boobyer iAugur

See http://technology.blue-bag.com/apache-rewrites-control-access-php-files

There are certain PHP files that you want access to but don't want to make public. Common examples of these are:

PHPInfo.php
APC.php
memcache.php

You also don't really want to deploy these on all of your sites on a server nor have them in your git repositories for sites.

Original article: http://www.blue-bag.com/blog/excluding-common-requests-your-apache-logs

Log files can get filled up with repeated calls to files such as favicon, robots.txt, images, css js etc

Mostly you want to log the initial request for a page and not all of the resources subsequently requested.

Troubleshooting other issues may mean you would log files such as favicon, images etc - but generally they needlessly fill up your logs.

Do it ocassionally to look for missing images etc.

This is a good example of how to respond to an issue with Ansible to ensure that your infrastructure is secure and that the measures you take are consistent across your inventory and are documented.

See the full article here for more details.

The example is am using is an issue that cropped up in the Logwatch report for one of our servers. Logwatch is a utility that scans your logs for patterns that may indicate malicious activity. It is commonly used in partnership with fail2Ban and IPtables to ward of common attacks. In this case the line in the log was:

Connection attempts using mod_proxy:

	/**
	* Rebuild the node_comment_statistics
	* turn off when importing
	* $commentvar = variable_get('comment_maintain_node_statistics', TRUE);
	* variable_set('comment_maintain_node_statistics', FALSE);
	* ref: http://drupal.org/node/137458#comment-5072066
	*/


	TRUNCATE TABLE node_comment_statistics;

	/**
	* Get a list of nodes where the entity_translation status is not in sync
	* Note we only get the unpublished translations as it is the node status we are concerned with
	* We are also only interested in the source translations
	**/
	select node.status, et.status
	from entity_translation et
	inner join .node on node.nid = et.entity_id and et.entity_type = 'node'
	where node.status <> et.status and et.status = 0 and et.source = ''

	/* Tables and data for Relational Division Example */
	CREATE TABLE `skill` (
	`idSkill` int(11) NOT NULL AUTO_INCREMENT,
	`Skill` varchar(45) DEFAULT NULL,
	PRIMARY KEY (`idSkill`)
	) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=latin1


	CREATE TABLE `person` (
	`idPerson` int(11) NOT NULL AUTO_INCREMENT,

	/**
	* Get a list of the top selling products on a Drupal Commerce site
	* If you have different product types - add them to the in list.
	* Based on https://drupal.org/node/1292104#comment-6866420 by tmsimont https://drupal.org/user/566678
	*/

	SELECT node.title AS product_title, node.nid AS product_nid, COUNT(cp.title) AS order_count
	FROM commerce_order
	LEFT JOIN field_data_commerce_line_items as fdcli ON commerce_order.order_id = fdcli.entity_id AND (fdcli.entity_type = 'commerce_order' AND fdcli.deleted = '0')
	INNER JOIN commerce_line_item as cli ON fdcli.commerce_line_items_line_item_id = cli.line_item_id

	I have come across a lot of discussions about how to add a reset button to a form in Drupal 7.
	If you search for 'add a reset button to a drupal form' you will find loads of examples using the #markup method of adding html for a reset button. This is because using the render array to add a button #type=> 'button' gives the button a class of 'form-submit'.

	But you can use the render array and simply give the button a '#button_type' which translates into a class. Buttons on a form default to submit and that is why they get a class of form-submit. But make the type 'reset' and it will get a class of form-reset.

	This Gist is to show how to set up a document structure and VHosts file to get a magento site to work alongside a Drupal site
	the original post is here: http://technology.blue-bag.com

	Following on from other Gists I have posted, this one shows a neat way of using Includes to centralise general blocking rules for Bad Bots, creepy crawlers and irritating IPs
	see the full post at http://www.blue-bag.com/blog/apache-better-blocking-common-rules