Control Apache CPU, Memory, and Processes with httpd.conf

The following Apache HTTPD directives are for controlling processes launched by Apache children. Raising the maximum resource limit requires that the server is running as root, or in the initial startup phase. They apply to processes forked off from Apache children servicing requests, not the Apache children themselves. This includes CGI scripts and SSI exec commands, but not any processes forked off from the Apache parent such as piped logs.

Please check out the following article if you aren’t familiar with what this stuff does: Optimizing Servers and Processes for Speed with ionice, nice, ulimit.

RLimitMEM

Limits the memory consumption.
Sets the soft resource limit for all processes and the second parameter sets the maximum resource limit.
View the RLimitMEM Documentation

RLimitCPU

Limits the CPU consumption.
View the RLimitCPU Documentation

RLimitNPROC

Limits the number of processes that can be launched by processes launched by Apache children.
View the RLimitNPROC Documentation

Sets the soft resource limit for all processes and the second parameter sets the maximum resource limit. Either parameter can be a number, or max to indicate to the server that the limit should be set to the maximum allowed by the operating system configuration. Process limits control the number of processes per user. If CGI processes are not running under user ids other than the web server user id, this directive will limit the number of processes that the server itself can create. Evidence of this situation will be indicated by cannot fork messages in the error_log.


PHP Caching and Acceleration with XCache

Anyone who runs a dedicated server for web hosting will tell you that a great way to decrease the load on your server and decrease the page load time is to use a PHP Cache such as APC or eAccelerator. While the largest noticeable improvements are for those site that receive a lot of traffic or are under heavy load, any site, large or small can see benefit from a PHP cache. That said, in addition to the two caches mentioned above, a new player has recently entered the market: XCache.

I first started using APC about 2 years ago when the load on one of my servers was high enough that it was affecting load times and was costing me user traffic. I chose APC over eAccelerator because it was a bit easier to install (at the time) and because APC had a reputation for being a bit faster than eAccelerator. Shortly there after I noticed my httpd processes segfaulting and a bit of research also showed that APC had a bit of a record for instability under heavy load. With that in mind, I took the slight performance hit and installed eAccelerator (which is still way faster than using nothing at all).

Up until today, I was still using eAccelerator on all of my servers. However, a post on the vBulletin.com forums prompted me to give XCache, the new PHP accelerator from the maker of lighttpd, a try. I’ve got to say, while I’ve only been using it for about 6 hours at this point, it blows eAccelerator out of the water, especially once you enable multiple caches (which benefits SMP systems).

 

If you’re interested in some benchmarks of XCache, eAccelerator, APC, etc. then checkout the Five Opcode Cache Comparison on PHP on Fire.

 

Read more

Allowing or Blocking based on Country with .htaccess

GeoIP Apache API

Requirements
In order to run this API, you need the following installed:

Download
Downloads are available for Apache 1.3.x and Apache 2.x.

Install
See the INSTALL file included with the mod_geoip API download for detailed instructions.

Usage
mod_geoip looks up the IP address of the client end user. If you need to input the IP address instead of simply using the client IP address, you will need to use another one of our APIs.

For the country database, mod_geoip sets two environment variables, GEOIP_COUNTRY_CODE and GEOIP_COUNTRY_NAME. For other databases, see the README file included with the mod_geoip API.

It also sets two entries in Apache’s notes table with the same names as above.

For more documentation, see the README file included with the mod_geoip API download.

Examples
Redirection with mod_geoip and mod_rewrite
Below are examples of how to perform redirection based on country with mod_geoip and mod_rewrite. This configuration should be added to your Apache httpd.conf or .htaccess file.

GeoIPEnable On
GeoIPDBFile /path/to/GeoIP.dat

# Redirect one country
RewriteEngine on
RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^CA$
RewriteRule ^(.*)$ http://www.canada.com$1 [L]

# Redirect multiple countries to a single page
RewriteEngine on
RewriteCond %{ENV:GEOIP_COUNTRY_CODE} ^(CA|US|MX)$
RewriteRule ^(.*)$ http://www.northamerica.com$1 [L]

This example redirects all pages on your site to a corresponding page on http://www.canada.com. For more details on how to use Apache’s redirection features, see the Apache 1.3 URL Rewriting Guide.

Blocking unwanted countries
The following Apache configuration directives uses GeoIP Country to block traffic from China and Russia:

GeoIPEnable On
GeoIPDBFile /path/to/GeoIP.dat

SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
# ... place more countries here

Deny from env=BlockCountry

# Optional - use if you want to allow a specific IP address from the country you denied
# (See http://httpd.apache.org/docs/1.3/mod/mod_access.html for more details)
Allow from 10.1.2.3

Allowing only specified countries
The following Apache configuration directives uses GeoIP Country to only allow traffic from US, Canada, and Mexico.

GeoIPEnable On
GeoIPDBFile /path/to/GeoIP.dat

SetEnvIf GEOIP_COUNTRY_CODE US AllowCountry
SetEnvIf GEOIP_COUNTRY_CODE CA AllowCountry
SetEnvIf GEOIP_COUNTRY_CODE MX AllowCountry
# ... place more countries here

Deny from all
Allow from env=AllowCountry

# Optional - use if you want to allow a specific IP address from the country you denied
# (See http://httpd.apache.org/docs/1.3/mod/mod_access.html for more details)
Allow from 10.1.2.3

Accessing a HostGator SVN repository via SVN+SSH on Windows

Accessing a HostGator SVN repository via SVN+SSH on Windows

This information should be helpful to anyone trying to access an svn repository stored on a remote (shared) server which does not expose an svn server.

My host is HostGator (good speeds, reliable ssh, cgi-only, MyISAM-only, decent support, non-existent knowledgebase). HostGator runs SSH over port 2222 which presents a few problems when trying to use traditional methods to connect to an SVN repository via SSH.

For these steps you will need Putty. Just get the whole suite.

http://kjvarga.blogspot.com/2008/04/accessing-hostgator-svn-repository-via.html

X-Content-Type-Options: nosniff header

Over the past two months, we’ve received significant community feedback that using a new attribute on the Content-Type header would create a deployment headache for server operators. To that end, we have converted this option into a full-fledged HTTP response header.  Sending the new X-Content-Type-Options response header with the value nosniff will prevent Internet Explorer from MIME-sniffing a response away from the declared content-type.

For example, given the following HTTP-response:

HTTP/1.1 200 OK
Content-Length: 108
Date: Thu, 26 Jun 2008 22:06:28 GMT
Content-Type: text/plain;
X-Content-Type-Options: nosniff

<html>
<body bgcolor=”#AA0000″>
This page renders as HTML source code (text) in IE8.
</body>
</html>

Browsers sniff mime types of HTTP responses, initially because page authors frequently don’t get them right* and now because browsers have done it historically.

The worst instance related to mime sniffing is an old IE bug. As I understand it their sniffer tried some image formats and then HTML; then when they added PNG sniffing it was added to the sniff list after HTML, either by mistake or to maintain compatibility with pages that were currently being sniffed as HTML. The result of this is that even valid PNG images can be sniffed as HTML, converting a user-uploadable image into a Javascript (XSS) vector. The Chromium mime sniffer‘s comments (which are quite readable, and tabulate various browsers’ behaviors) describe this as a “dangerous mime type”.

But there are plenty of other ways that sniffing can screw you as a site author. Your only defenses if you’re building a site are:

  • either make sure user-uploaded images are on a different origin than your site’s cookies;
  • or set the Content-disposition: attachment header, preventing people from displaying the image in their browser.

I believe this bug is why you cannot view images attached to gmail messages — if you click “view image” in gmail you instead get an HTML page with an <img> tag, and if you right-click on that image and pick “view image” you’ll get it served with the attachment header.

To solve this mess, IE introduced the X-Content-Type-Options: nosniff header, which means “don’t sniff the mime type”. It looks like a reasonable workaround to me: it lets new pages opt into sane behavior without breaking old ones. Chromium added support for it.

It sounded good to developers of a Google-internal HTTP server as well; they added it by default to all responses. And then the bug reports started coming in: “Why does my page render in all browsers but Chromium?” It turned out many of these sites were sending no Content-type header, which, when coupled with the nosniff header, meant Chromium would pick the default of application/octet-stream, triggering a download box.

The fix is to match IE (r8559) for this corner case, which is to instead default to text/plain; I made wisecracks about adding an X-Content-Type-Options-Options: no-really-none-of-these-mime-shenanigans header. Adam (master of content-type sniffing, and I believe editor of the HTML5 sniffing spec) also wrote r8257. This collects stats (aggregated anonymized and only from users who have opted in) on what fraction of pages that we normally would’ve sniffed but were instead blocked by the header.

* In fairness, the greater problem is that page authors sometimes don’t control HTTP headers. They’re frequently defined by server configuration, which often requires root on the server or at least a lot more technical know-how than “click on the upload button in your website creator program”

Apache .htaccess

%d bloggers like this: