flyinweb's blog - WEB服务器

Apache编译失败及其解决方案

shanyiwan@live.com() — Fri, 13 Jan 2012 02:47:45 GMT

1、checking for SSL_set_cert_store... no
configure: error: ... Error, SSL/TLS libraries were missing or unusable

安装openssl,在编译参数中添加--with-ssl=/usr/local/ssl （ssl安装路径，根据安装的实际路径设置）

Nginx as an IMAP/POP3 proxy

shanyiwan@live.com() — Thu, 12 Jan 2012 03:55:12 GMT

At Gigahost we are managing a lot of mailboxes for our users.

At the moment these are all located on one high speced server with the outgoing SMTP split to another server.

We allow our users to connect via both IMAP and POP3 and support STARTTLS on ports 110/143 and SSL/TLS on ports 993/995.

Since we are constantly adding new users and these in turn add new mailboxes we are running out of options as to upgrade the current server. Hosting mailboxes via Courier, Dovecot or similar is very IO intensive and therefore in the long run disk IO becomes a problem.

The solution to this is ofcourse to scale the setup to more servers. Some hosting providers do this by simply adding users to a new mail server eg. mail2.example.com, mail3.example.com and so on.

What we would like to do is use a reverse proxy so that the user always connects to mail.gigahost.dk and the proxy ensures that the user is send to the correct server.

Enter nginx.

nginx is mostly known as the reverse proxy that drives sites such as youtube.com, wordpress.com, hulu.com, github.com and many many more.

But nginx can also act as an IMAP/POP3 proxy and does quite a good job at it.

Using nginx you can authenticate the mail user before she/he reaches the mailserver and specify i) if the user can be authenticated, ii) what server the user should be send to. You can infact also alter the username and do other magic stuff.

excerpt from nginx.conf

                http {
                  perl_modules  perl/lib;
                  perl_require  mailauth.pm;
            
                  server {
                    location /auth {
                      perl  mailauth::handler;
                    }
                  }
                }
            
                mail {
                  auth_http  127.0.0.1:80/auth;
                  auth_http_header X-NGX-Auth-Key "some secret";
            
                  imap_auth plain login cram-md5;
                  pop3_auth plain apop cram-md5;
                }

In the above excerpts you will see that I use the embedded perl module in nginx (you must add this a compile time). This serves up the mailauth.pm script on port 80.

Be aware that the embedded perl parser blocks the current nginx process – so you might consider running a few and ensure that the script executes fast.

The auth_http setting in the nginx config is where the magic happens. This points to the HTTP server that handles the authentication and find the server the connection should be proxied to.

mailauth.pm

                package mailauth;
                use Digest::HMAC_MD5 qw/ hmac_md5_hex /;
                use nginx;
                use DBI;
                use URI::Escape;
                my $dsn="DBI:mysql:database=postfix;host=10.0.0.1";
                our $dbh=DBI->connect_cached($dsn, 'mail-proxy', 'p@ssword', {AutoCommit => 1, mysql_auto_reconnect => 1});
              
                our $auth_ok;
                our $protocol_ports={};
                $protocol_ports->{'pop3'}=110;
                $protocol_ports->{'imap'}=143;
                $protocol_ports->{'smtp'}=25;
              
                sub handler {
                  if (!$dbh->ping()) {
                    ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime(time);
                    $dbh=DBI->connect_cached($dsn, 'mail-proxy', 'p@ssword', {AutoCommit => 1, mysql_auto_reconnect => 1});
                    printf STDERR "%4d/%02d/%02d %02d:%02d:%02d [notice] : MySQL server connection lost. Reconnecting.\n", $year+1900,$mon+1,$mday,$hour,$min,$sec;
                  }
                  
                  my $r = shift;
              
                  my $auth_method = $r->header_in("Auth-Method");
                  my $username = uri_unescape($r->header_in("Auth-User"));
                  my $password = uri_unescape($r->header_in("Auth-Pass"));
                  my $salt = $r->header_in("Auth-Salt");
              
                  our $sth=$dbh->prepare("select clear from users where email=? limit 1"); 
                  $sth->execute($username);
                  my $hash=$sth->fetchrow_hashref();
                  my $real_password = $hash->{'clear'};
              
                  # Authorize user
                  if (($auth_method eq "plain" && $password eq $real_password) or
                    ($auth_method eq "cram-md5" && $password eq hmac_md5_hex($salt, $real_password))) {
                    # Auth OK, find mail server
                    our $sth=$dbh->prepare("select destination_mailstore from transport where domain=? limit 1"); 
                    my $domain = $r->header_in("Auth-User");
                    $domain =~ s/^.*@//; # remove @ and everything before 
                    $sth->execute($domain);
                    my $hash=$sth->fetchrow_hashref();
                    my $mailserver = $hash->{'destination_mailstore'};
                    $mailserver =~ s/smtp://;
              
                    $r->header_out("Auth-User", $username);
                    $r->header_out("Auth-Pass", $real_password);
                    $r->header_out("Auth-Status", "OK");
                    $r->header_out("Auth-Server", $mailserver);
                    $r->header_out("Auth-Port", $protocol_ports->{$r->header_in("Auth-Protocol")});
                    
                    # Shared secret to ensure that the request comes from this script
                    $r->header_out("X-NGX-Auth-Key", "some secret");
                  } else {
                    $r->header_out("Auth-Status", "Invalid login or password");
                  }
              
                  $r->send_http_header("text/html");
              
                  return OK;
                }
              
                1;
                __END__

The above script supports both plain and CRAM-MD5 authentication. The request headers set by nginx are visible as header_in("...") and the response headers that the script sets are header_out.

It should be pretty self-explanatory what the script does and how. The main feature here is ofcourse setting the Auth-Server response header to the mailserver where you would like to point the user.

UPDATE 2011/02/08:
nginx sends the HTTP headers for the auth script urlencoded. Therefore it is emparative that they be decoded so passwords like my little p%ony works.

I’ve updated the script here to make use of the Perl uri library (you might have to install this).

Also I’ve added a small check to ensure that the MySQL connection is still alive and if not reconnect.

It seems that either my Perl script or the nginx embedded Perl module suffers from memory leaks.

Now, the easy way to fix this would be to run a /etc/init.d/nginx restart every so often. However, that would of course suck.

So I started looking into alternative ways, using FastCGI to serve the authentication script.

The normal fcgiwrapper in Debian was way to slow though. Handling only about 30 requests/sec.

Enter FCGI-Daemon by Dmitry Smirnov. It works by keeping the processes alive not respawning Perl on every request.

With this I was able to achieve 2500-3000 request/sec. More than enough to handle IMAP/POP3 authentications.

I’ve included an updated authentication script for use with this.

auth.pl

               #!/usr/bin/perl
            
               use Digest::HMAC_MD5 qw/ hmac_md5_hex /;
               use DBI;
               use URI::Escape;
               use CGI;
            
               print "Content-type: text/html\n";
            
               my $q = CGI->new;
               my $auth_shared_secret = $q->http("X-NGX-Auth-Key");
            
               # Shared secret to ensure that the request comes from nginx
               if ( $auth_shared_secret ne "your secret" ) {
                 print "Auth-Status: Authentication failed.\n\n";
                 print STDERR "Wrong X-NGC-Auth-Key $auth_shared_secret";
                 exit(0);
               }
            
               my $dsn = "DBI:mysql:database=postfix;host=1.2.3.4";
               our $dbh =
                 DBI->connect_cached( $dsn, 'mailproxy', 'p@ssw0rd',
                   { AutoCommit => 1, mysql_auto_reconnect => 1 } );
            
               our $auth_ok;
               our $protocol_ports = {};
               $protocol_ports->{'pop3'} = 110;
               $protocol_ports->{'imap'} = 143;
               $protocol_ports->{'smtp'} = 25;
            
               if ( !defined $dbh || !$dbh->ping() ) {
                   ( $sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst ) =
                     localtime(time);
                   $dbh =
                     DBI->connect_cached( $dsn, 'mailproxy', 'p@ssw0rd',
                       { AutoCommit => 1, mysql_auto_reconnect => 1 } );
                   printf STDERR
               "%4d/%02d/%02d %02d:%02d:%02d [notice] : MySQL server connection lost. Reconnecting.\n",
                     $year + 1900, $mon + 1, $mday, $hour, $min, $sec;
               }
            
               my $auth_method = $q->http("Auth-Method");
               my $username    = uri_unescape( $q->http("Auth-User") );
               my $password    = uri_unescape( $q->http("Auth-Pass") );
               my $salt        = $q->http("Auth-Salt");
            
               our $sth = $dbh->prepare("select clear from users where email=? limit 1");
               $sth->execute($username);
               my $hash          = $sth->fetchrow_hashref();
               my $real_password = $hash->{'clear'};
            
               # Authorize user
               if (
                   ( $auth_method eq "plain" && $password eq $real_password )
                   or (   $auth_method eq "cram-md5"
                       && $password eq hmac_md5_hex( $salt, $real_password ) )
                 )
               {
            
                   # Auth OK, find mail server
                   our $sth = $dbh->prepare(
                       "select destination_mailstore from transport where domain=? limit 1");
                   my $domain = $q->http("Auth-User");
            
                   # remove @ and everything before
                   $domain =~ s/^.*@//;
                   $sth->execute($domain);
                   my $hash       = $sth->fetchrow_hashref();
                   my $mailserver = $hash->{'destination_mailstore'};
                   $mailserver =~ s/smtp://;
            
                   print "Auth-User: $username\n";
                   print "Auth-Pass: $real_password\n";
                   print "Auth-Status: OK\n";
                   print "Auth-Server: $mailserver\n";
                   $auth_port = $protocol_ports->{ $q->http("Auth-Protocol") };
                   print "Auth-Port: $auth_port\n";
               }
               else {
                   print "Auth-Status: Authentication failed.\n";
               }
            
               print "\n";

#!/usr/bin/perl
use Digest::HMAC_MD5 qw/ hmac_md5_hex /;
use DBI;
use URI::Escape;
use CGI;
print "Content-type: text/html\n";
my $q = CGI->new;
my $auth_shared_secret = $q->http("X-NGX-Auth-Key");
# Shared secret to ensure that the request comes from nginx
if ( $auth_shared_secret ne "your secret" ) {
  print "Auth-Status: Authentication failed.\n\n";
  print STDERR "Wrong X-NGC-Auth-Key $auth_shared_secret";
  exit(0);
}
my $dsn = "DBI:mysql:database=postfix;host=1.2.3.4";
our $dbh =
  DBI->connect_cached( $dsn, 'mailproxy', 'p@ssw0rd',
    { AutoCommit => 1, mysql_auto_reconnect => 1 } );
our $auth_ok;
our $protocol_ports = {};
$protocol_ports->{'pop3'} = 110;
$protocol_ports->{'imap'} = 143;
$protocol_ports->{'smtp'} = 25;
if ( !defined $dbh || !$dbh->ping() ) {
    ( $sec, $min, $hour, $mday, $mon, $year, $wday, $yday, $isdst ) =
      localtime(time);
    $dbh =
      DBI->connect_cached( $dsn, 'mailproxy', 'p@ssw0rd',
        { AutoCommit => 1, mysql_auto_reconnect => 1 } );
    printf STDERR
"%4d/%02d/%02d %02d:%02d:%02d [notice] : MySQL server connection lost. Reconnecting.\n",
      $year + 1900, $mon + 1, $mday, $hour, $min, $sec;
}
my $auth_method = $q->http("Auth-Method");
my $username    = uri_unescape( $q->http("Auth-User") );
my $password    = uri_unescape( $q->http("Auth-Pass") );
my $salt        = $q->http("Auth-Salt");
our $sth = $dbh->prepare("select clear from users where email=? limit 1");
$sth->execute($username);
my $hash          = $sth->fetchrow_hashref();
my $real_password = $hash->{'clear'};
# Authorize user
if (
    ( $auth_method eq "plain" && $password eq $real_password )
    or (   $auth_method eq "cram-md5"
        && $password eq hmac_md5_hex( $salt, $real_password ) )
  )
{
    # Auth OK, find mail server
    our $sth = $dbh->prepare(
        "select destination_mailstore from transport where domain=? limit 1");
    my $domain = $q->http("Auth-User");
    # remove @ and everything before
    $domain =~ s/^.*@//;
    $sth->execute($domain);
    my $hash       = $sth->fetchrow_hashref();
    my $mailserver = $hash->{'destination_mailstore'};
    $mailserver =~ s/smtp://;
    print "Auth-User: $username\n";
    print "Auth-Pass: $real_password\n";
    print "Auth-Status: OK\n";
    print "Auth-Server: $mailserver\n";
    $auth_port = $protocol_ports->{ $q->http("Auth-Protocol") };
    print "Auth-Port: $auth_port\n";
}
else {
    print "Auth-Status: Authentication failed.\n";
}
print "\n";

Creating Certificate Authorities and self-signed SSL certificates

shanyiwan@live.com() — Sat, 07 Jan 2012 08:35:20 GMT

Following is a step-by-step guide to creating your own CA (Certificate Authority) -- and also self-signed SSL server certificates -- with openssl on Linux. Self-signing is the simpler route to take, but making one's own CA allows the signing of multiple server certificates using the same CA and involves only a few extra steps.

After using openssl to generate the necessary files, you'll need to integrate them into Apache. This process differs between Linux distros and versions of Apache. Additional references exist at the end of this document. My instructions for Setting up SSL: Ubuntu and Apache 2 are kept most current, and will carry you through to completion.

Making a homemade CA or self-signed certificate will cause the client web browser to prompt with a message whether to trust the certificate signing authority (yourself) permanently (store it in the browser), temporarily for that session, or to reject it. The message "web site certified by an unknown authority... accept?" may be a business liability for general public usage, although it's simple enough for the client to accept the certificate permanently.

Whichever route you take, you'll save the periodic expense of paying a recognized signing authority. This is purely for name recognition -- they've paid the major browser producers to have their CA pre-loaded into them. So if you're on a budget, have a special need or small audience, this may be useful.

Before you start
You need Apache and openssl. Compiling them from source, handling dependencies, etc. is beyond the scope of this document. You can consult their documentation, or go with a mainstream Linux distro that will do the preliminary work for you.

Now you need to decide whether you'll make a CA (Certificate Authority) and sign a server certificate with it -- or just self-sign a server certificate. Both procedures are detailed below.

(1A) Create a self-signed certificate.

Complete this section if you do NOT want to make a CA (Certificate Authority). If you want to make a CA, skip 1A entirely and go to 1B instead.

Some steps in this document require priviledged access, and you'll want to limit access to the cert files to all but the root user. So you should su to root and create a working directory that only root has read/write access to (for example: mkdir certwork, chmod 600 certwork). Go to that directory.

Generate a server key:

openssl genrsa -des3 -out server.key 4096

Then create a certificate signing request with it. This command will prompt for a series of things (country, state or province, etc.). Make sure that "Common Name (eg, YOUR name)" matches the registered fully qualified domain name of your box (or your IP address if you don't have one). I also suggest not making a challenge password at this point, since it'll just mean more typing for you.

The default values for the questions ([AU], Internet Widgits Pty Ltd, etc.) are stored here: /etc/ssl/openssl.cnf. So if you've got a large number of certificate signing requests to process you probably want to carefully edit that file where appropriate. Otherwise, just execute the command below and type what needs to be typed:

openssl req -new -key server.key -out server.csr

Now sign the certificate signing request. This example lasts 365 days:

openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

Make a version of the server.key which doesn't need a password:

openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key

These files are quite sensitive and should be guarded for permissions very carefully. Chown them to root, if you're not already sudo'd to root. I've found that you can chmod 000 them. That is, root will always retain effective 600 (read) rights on everything.

Now that you've just completed Step 1A, skip ahead to Step 2.

(1B) Generate your own CA (Certificate Authority).

Complete this section if you want to make a CA (Certificate Authority) and sign a server certificate with it. The steps for making a server certificate are also included here. If you'd rather one-time self-sign a server certificate, skip this step entirely and go to 1A instead.

Some steps in this document require priviledged access, and you'll want to limit access to the cert files to all but the root user. So you should su to root and create a working directory that only root has read/write access to (for example: mkdir certwork, chmod 600 certwork). Go to that directory.

In this step you'll take the place of VeriSign, Thawte, etc. You'll first build the CA key, then build the certificate itself.

The Common Name (CN) of the CA and the Server certificates must NOT match or else a naming collision will occur and you'll get errors later on. In this step, you'll provide the CA entries. In a step below, you'll provide the Server entries. In this example, I just added "CA" to the CA's CN field, to distinguish it from the Server's CN field. Use whatever schema you want, just make sure the CA and Server entries are not identical.

CA:
Common Name (CN): www.somesite.edu CA
Organization (O): Somesite
Organizational Unit (OU): Development

Server:
Common Name (CN): www.somesite.edu
Organization (O): Somesite
Organizational Unit (OU): Development

If you don't have a fully qualified domain name, you should use the IP that you'll be using to access your SSL site for Common Name (CN). But, again, make sure that something differentiates the entry of the CA's CN from the Server's CN.

openssl genrsa -des3 -out ca.key 4096
openssl req -new -x509 -days 365 -key ca.key -out ca.crt

Generate a server key and request for signing (csr).

This step creates a server key, and a request that you want it signed (the .csr file) by a Certificate Authority (the one you just created in Step #1B above.)

Think carefully when inputting a Common Name (CN) as you generate the .csr file below. This should match the DNS name, or the IP address you specify in your Apache configuration. If they don't match, client browsers will get a "domain mismatch" message when going to your https web server. If you're doing this for home use, and you don't have a static IP or DNS name, you might not even want worry about the message (but you sure will need to worry if this is a production/public server). For example, you could match it to an internal and static IP you use behind your router, so that you'll never get the "domain mismatch" message if you're accessing the computer on your home LAN, but will always get that message when accessing it elsewhere. Your call -- is your IP stable, do you want to repeat these steps every time your IP changes, do you have a DNS name, do you mainly use it inside your home or LAN, or outside?

openssl genrsa -des3 -out server.key 4096
openssl req -new -key server.key -out server.csr

Sign the certificate signing request (csr) with the self-created Certificate Authority (CA) that you made earlier.

Note that 365 days is used here. After a year you'll need to do this again.

Note also that I set the serial number of the signed server certificate to "01". Each time you do this, especially if you do this before a previously-signed certificate expires, you'll need to change the serial key to something else -- otherwise everyone who's visited your site with a cached version of your certificate will get a browser warning message to the effect that your certificate signing authority has screwed up -- they've signed a new key/request, but kept the old serial number. There are a couple ways to rectify that. crl's (certificate revocation list) is one method, but beyond the scope of the document. Another method is for all clients which have stored the CA certificate to go into their settings and delete the old one manually. But for the purposes of this document, we'll just avoid the problem. (If you're a sysadmin of a production system and your server.key is compromised, you'll certainly need to worry.)

The command below does a number of things. It takes your signing request (csr) and makes a one-year valid signed server certificate (crt) out of it. In doing so, we need to tell it which Certificate Authority (CA) to use, which CA key to use, and which Server key to sign. We set the serial number to 01, and output the signed key in the file named server.crt. If you do this again after people have visited your site and trusted your CA (storing it in their browser), you might want to use 02 for the next serial number, and so on. You might create some scheme to make the serial number more "official" in appearance or makeup but keep in mind that it is fully exposed to the public in their web browsers, so it offers no additional security in itself.

openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

To examine the components if you're curious:

openssl rsa -noout -text -in server.key
openssl req -noout -text -in server.csr
openssl rsa -noout -text -in ca.key
openssl x509 -noout -text -in ca.crt

Make a server.key which doesn't cause Apache to prompt for a password.

Here we create an insecure version of the server.key. The insecure one will be used for when Apache starts, and will not require a password with every restart of the web server. But keep in mind that while this means you don't have to type in a password when restarting Apache (or worse -- coding it somewhere in plaintext), it does mean that anyone obtaining this insecure key will be able to decrypt your transmissions. Guard it for permissions VERY carefully.

openssl rsa -in server.key -out server.key.insecure
mv server.key server.key.secure
mv server.key.insecure server.key

(2) Copy files into position and tweak Apache.

Some professors like to pause for a moment after a long lecture, and do a little recap. It's a good pedagogical tool, so let's do so here. If you took route 1A above, you should have four files in a working directory:

server.crt: The self-signed server certificate.
server.csr: Server certificate signing request.
server.key: The private server key, does not require a password when starting Apache.
server.key.secure: The private server key, it does require a password when starting Apache.

If you took route 1B and created a CA, you'll have two additional files:

ca.crt: The Certificate Authority's own certificate.
ca.key: The key which the CA uses to sign server signing requests.

The CA files are important to keep if you want to sign additional server certificates and preserve the same CA. You can reuse these so long as they remain secure, and haven't expired.

At a bare minimum, the following considerations must now be addressed:

You'll need a virtual host and document root set up for the SSL instance.
You'll need to turn on the SSL engine and enable/load the SSL module.
Apache must reference server.crt and server.key somewhere in its configuration.
Apache must be listening to a port for which SSL is enabled (443 is default).

The particulars differ between Linux distros and versions of Apache. I'm only able to keep the Setting up SSL: Ubuntu and Apache 2 documentation current due to time constraints. Those steps should apply broadly to Debian-based distros with little or no modification. Red Hat and openSUSE commentary is kept online here for historical purposes.

httpd: apr_sockaddr_info_get() failed for HOSTNAME

shanyiwan@live.com() — Fri, 09 Dec 2011 02:10:25 GMT

If you get this error when starting Apache 2 here is the fix…

Performing sanity check on apache22 configuration:
httpd: apr_sockaddr_info_get() failed for someserver1.host-name.net
httpd: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName
Syntax OK
Starting apache22.
httpd: apr_sockaddr_info_get() failed for someserver1.host-name.net
httpd: Could not reliably determine the server’s fully qualified domain name, using 127.0.0.1 for ServerName

The repair is very easy, just fix your hosts file locate at `/etc/hosts`.

First, determing your hostname of the machine that you are on…

#> hostname
someserver1.host-name.net

Then open your hosts file…

#> vi /etc/hosts

Then change all the host items to match

::1 localhost.someserver1.host-name.net localhost
127.0.0.1 localhost.someserver1.host-name.net localhost
192.1.0.123 someserver1.host-name.netsomeserver1
192.1.0.123 someserver1.host-name.net.

Then start the server again…

#> apachectl start
Performing sanity check on apache22 configuration:
Syntax OK
Starting apache22.
#> …

All set!!!

nginx: Setup SSL Reverse Proxy (Load Balanced SSL Proxy)

shanyiwan@live.com() — Fri, 09 Dec 2011 01:38:39 GMT

A reverse proxy is a proxy server that is installed in a server network. Typically, reverse proxies are used in front of Web servers such as Apache, IIS, and Lighttpd. How do I setup nginx web server as SSL reverse proxy?

When you've multiple backend web servers, encryption / SSL acceleration can be done by a reverse proxy. Nginx can act as SSL acceleration software. It provided the following benefits:

Easy of use : Nginx is easy to setup and upgrade.

Security : Nginx provide an additional layer of defense as Apache is behind the proxy. It can protect against common web-based attacks too.

Load Distribution : nginx use very little memory and can distribute the load to several Apache servers. It can even rewrite urls on fly.

Caching : Nginx act as a reverse proxy which offload the Web servers by caching static content, such as images, css, js, static html pages and much more.

Compression : Nginx can optimize and compress the content to speed up the load time.

Our Sample Setup

Internet--
         |
    =============                               |---- apache1 (192.168.1.15)
    | ISP Router|                               |
    =============                               |---- apache2 (192.168.1.16)
         |                                      |
         |                                      |---- db1 (192.168.1.17)
         |      |eth0 -> 192.168.1.11 ----------/
         |-lb0==|                          /
         |      |eth1 -> 202.54.1.1:443---/
         |
         |      |eth0 -> 192.168.1.10 ----------\
         |-lb1==|                          /    |---- apache1 (192.168.1.15)
                |eth1 -> 202.54.1.1:443---/     |
                                                |---- apache2 (192.168.1.16)
                                                |
                                                |---- db1 (192.168.1.17)

lb0 - Linux box directly connected to the Internet via eth1. This is master SSL load balancer.
lb1 - Linux box directly connected to the Internet via eth1. This is backup SSL load balancer. This will become active if master networking failed.
202.54.1.1 A virtual IP address that moves between lb0 and lb1. It is managed by keepalived.
nginx - It is installed on lb0 and lb1.
SSL Certificate - You need to install ssl certificates on lb0 and lb1.

For demonstration purpose I'm going to use Self-signed SSL certificate, but you can use real SSL certificate signed by CAs.

+------+	+-------------+	       +-------------------+
|Client|  <---> |SSL-Nginx:443|	<----> |Apache-HTTP_mode:80|
+------+        +-------------+        +-------------------+

You've the SSL connection between client and Nginx.
Then Nginx act as proxy server and makes unencrypted connection to Apache at port 80.
Nginx can cache all static file and other files.

Generating Self-signed Certificate

First, create required directories:
# cd /usr/local/nginx/conf # mkdir ssl # cd ssl
To create a private key, enter:
# openssl genrsa -des3 -out nixcraft.in.key 1024
Sample outputs:

Fig.01: OpenSSL - Create a Private Key

To create a CSR (Certificate Signing Request):
# openssl req -new -key nixcraft.in.key -out nixcraft.in.csr
Sample outputs:

Fig.02: OpenSSL - Create a CSR (Certificate Signing Request)

Please enter your domain name that you want to associate with the certificate. For example, for the Command Name I entered nixcraft.in as I'm going to use https://nixcraft.in/.

How Do I Remove The Passphrase? (Optional)

You can remove the passphrase so nginx can start on boot without entering the passphrase. Type the following commands
# cp nixcraft.in.key nixcraft.in.key.bak # openssl rsa -in nixcraft.in.key.bak -out nixcraft.in.key
Finally, you should see three files as follows (note I've created all files as vivek user and than moved lb0 and lb1 server /usr/local/ngnix/conf/ssl/ directory):
# ls -l
Sample outputs:

Fig.03: All the files in ssl directory

# openssl x509 -req -days 365 -in nixcraft.in.csr -signkey nixcraft.in.key -out nixcraft.in.crt
Sample outputs:

Fig.04: Generating The Actual Self-signed SSL Certificate

How Do I Copy SSL Certificates Files To lb1?

You need to copy those files to lb1, enter:
# ssh root@lb1 mkdir /usr/local/ngnix/conf/ssl # rsync -av /usr/local/ngnix/conf/ssl/* root@lb1:/usr/local/ngnix/conf/ssl/

Configure Nginx As SSL Reverse Proxy (lb0 and lb1)

Edit nginx.conf, enter (you need to edit files on both lb0 and lb1):
# vi /usr/local/ngnix/conf/nginx.conf
Edit / append as follows:

 
server {
	### server port and name ###
        listen          443 ssl;
        server_name     nixcraft.in;
 
	### SSL log files ###
        access_log      logs/ssl-access.log;
        error_log       logs/ssl-error.log;
 
	### SSL cert files ###
        ssl_certificate      ssl/nixcraft.in.crt;
        ssl_certificate_key  ssl/nixcraft.in.key;
	### Add SSL specific settings here ###
        keepalive_timeout    60;
 
	###  Limiting Ciphers ########################
        # Uncomment as per your setup
	#ssl_ciphers HIGH:!ADH;
        #ssl_perfer_server_ciphers on;
        #ssl_protocols SSLv3;
        ##############################################
	### We want full access to SSL via backend ###
     	location / {
	        proxy_pass  http://nixcraft;
		### force timeouts if one of backend is died ##
        	proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
 
		### Set headers ####
        	proxy_set_header Host $host;
        	proxy_set_header X-Real-IP $remote_addr;
	        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 
		### Most PHP, Python, Rails, Java App can use this header ###
        	proxy_set_header X-Forwarded-Proto https;
 
		### By default we don't want to redirect it ####
	        proxy_redirect     off;}

Save and close the file. Reload nginx:
# /usr/local/nginx/sbin/nginx -t # /usr/local/nginx/sbin/nginx -s reload
Verify port is opened:
# netstat -tulpn | grep :443

How Do I Test And Debug SSL Certificates From The Shell Prompt?

Use the openssl command as follows:
$ openssl s_client -connect nixcraft.in:443

See "How To Verify SSL Certificate From A Shell Prompt" for more details.

How Do I Cache Common Files?

Edit nginx.conf and add as follows to cache common files:

location ~* \.(jpg|png|gif|jpeg|css|js|mp3|wav|swf|mov|doc|pdf|xls|ppt|docx|pptx|xlsx)$ {
        proxy_buffering           on;
        proxy_cache_valid 200 120m;
        expires 864000;
}

Save and close the file. Reload nginx:
# nginx -s reload

CentOS / Redhat Linux: Install Keepalived To Provide IP Failover For Web Cluster

shanyiwan@live.com() — Fri, 09 Dec 2011 01:36:24 GMT

Keepalived provides a strong and robust health checking for LVS clusters. It implements a framework of health checking on multiple layers for server failover, and VRRPv2 stack to handle director failover. How do I install and configure Keepalived for reverse proxy server such as nginx or lighttpd?

If your are using a LVS director to loadbalance a server pool in a production environment, you may want to have a robust solution for healthcheck & failover. This will also work with reverse proxy server such as nginx.

Our Sample Setup

Internet--
         |
    =============
    | ISP Router|
    =============
         |
         |
         |      |eth0 -> 192.168.1.11 (connected to lan)
         |-lb0==|
         |      |eth1 -> 202.54.1.1 (vip master)
         |
         |      |eth0 -> 192.168.1.10 (connected to lan)
         |-lb1==|
                |eth1 -> 202.54.1.1 (vip backup)

Where,

lb0 - Linux box directly connected to the Internet via eth1. This is master load balancer.
lb1 - Linux box directly connected to the Internet via eth1. This is backup load balancer. This will become active if master networking failed.
202.54.1.1 - This ip moves between lb0 and lb1 server. It is called virtual IP address and it is managed by keepalived.
eth0 is connected to LAN and all other backend software such as Apache, MySQL and so on.

You need to install the following softwares on both lb0 and lb1:

keepalived for IP failover.
iptables to filter traffic
nginx or lighttpd revers proxy server.

DNS settings should be as follows:

nixcraft.in - Our sample domain name.
lb0.nixcraft.in - 202.54.1.11 (real ip assigned to eth1)
lb1.nixcraft.in - 202.54.1.12 (real ip assigned to eth1)
www.nixcraft.in - 202.54.1.1 (VIP for web server) do not assign this IP to any interface.

Install Keepalived

Visit keepalived.org to grab latest source code. You can use the wget command to download the same (you need to install keepalived on both lb0 and lb1):
# cd /opt # wget http://www.keepalived.org/software/keepalived-1.1.19.tar.gz # tar -zxvf keepalived-1.1.19.tar.gz # cd keepalived-1.1.19

Install Kernel Headers

You need to install the following packages:

Kernel-headers - includes the C header files that specify the interface between the Linux kernel and userspace libraries and programs. The header files define structures and constants that are needed for building most standard programs and are also needed for rebuilding the glibc package.
kernel-devel - this package provides kernel headers and makefiles sufficient to build modules against the kernel package.

Make sure kernel-headers and kernel-devel packages are installed. If not type the following install the same:
# yum -y install kernel-headers kernel-devel

Compile keepalived

Type the following command:
# ./configure --with-kernel-dir=/lib/modules/$(uname -r)/build
Sample outputs:

checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
...
.....
..
config.status: creating keepalived/check/Makefile
config.status: creating keepalived/libipvs-2.6/Makefile
Keepalived configuration
------------------------
Keepalived version       : 1.1.19
Compiler                 : gcc
Compiler flags           : -g -O2
Extra Lib                : -lpopt -lssl -lcrypto
Use IPVS Framework       : Yes
IPVS sync daemon support : Yes
Use VRRP Framework       : Yes
Use Debug flags          : No

Compile and install the same:
# make && make install

Create Required Softlinks

Type the following commands to create service and run it at RHEL / CentOS run level #3 :
# cd /etc/sysconfig # ln -s /usr/local/etc/sysconfig/keepalived . # cd /etc/rc3.d/ # ln -s /usr/local/etc/rc.d/init.d/keepalived S100keepalived # cd /etc/init.d/ # ln -s /usr/local/etc/rc.d/init.d/keepalived .

Configuration

Your main configuration directory is located at /usr/local/etc/keepalived and configuration file name is keepalived.conf. First, make backup of existing configuration:
# cd /usr/local/etc/keepalived # cp keepalived.conf keepalived.conf.bak
Edit keepalived.conf as follows on lb0:

vrrp_instance VI_1 {
        interface eth0
        state MASTER
        virtual_router_id 51
        priority 101
        authentication {
            auth_type PASS
            auth_pass Add-Your-Password-Here
        }
        virtual_ipaddress {
                202.54.1.1/29 dev eth1
        }
}

Edit keepalived.conf as follows on lb1 (note priority set to 100 i.e. backup load balancer):

vrrp_instance VI_1 {
        interface eth0
        state MASTER
        virtual_router_id 51
        priority 100
        authentication {
            auth_type PASS
            auth_pass Add-Your-Password-Here
        }
        virtual_ipaddress {
                202.54.1.1/29 dev eth1
        }
}

Save and close the file. Finally start keepalived on both lb0 and lb1 as follows:
# /etc/init.d/keepalived start

Verify: Keepalived Working Or Not

/var/log/messages will keep track of VIP:
# tail -f /var/log/messages
Sample outputs:

Feb 21 04:06:15 lb0 Keepalived_vrrp: Netlink reflector reports IP 202.54.1.1 added
Feb 21 04:06:20 lb0 Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 202.54.1.1

Verify that VIP assigned to eth1:
# ip addr show eth1
Sample outputs:

3: eth1:  mtu 1500 qdisc pfifo_fast qlen 10000
    link/ether 00:30:48:30:30:a3 brd ff:ff:ff:ff:ff:ff
    inet 202.54.1.11/29 brd 202.54.1.254 scope global eth1
    inet 202.54.1.1/29 scope global secondary eth1

ping failover test

Open UNIX / Linux / OS X desktop terminal and type the following command to ping to VIP:
# ping 202.54.1.1
Login to lb0 and halt the server or take down networking:
# halt
Within seconds VIP should move from lb0 to lb1 and you should not see any drops in ping. On lb1 you should get the following in /var/log/messages:

Feb 21 04:10:07 lb1 Keepalived_vrrp: VRRP_Instance(VI_1) forcing a new MASTER election
Feb 21 04:10:08 lb1 Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER STATE
Feb 21 04:10:09 lb1 Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
Feb 21 04:10:09 lb1 Keepalived_vrrp: VRRP_Instance(VI_1) setting protocol VIPs.
Feb 21 04:10:09 lb1 Keepalived_healthcheckers: Netlink reflector reports IP 202.54.1.1 added
Feb 21 04:10:09 lb1 Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 202.54.1.1

Conclusion

Your server is now configured with IP failover. However, you need to install and configure the following software in order to configure webserver and security:

nginx or lighttpd
iptables

Handling nginx Failover With KeepAlived

shanyiwan@live.com() — Fri, 09 Dec 2011 01:34:42 GMT

How do configure to release and obtain VIP (virtual IP) when nginx is dead, down or system is rebooted for the kernel upgrades?

Edit /usr/local/etc/keepalived/keepalived.conf and add the following section to check whether nginx is alive or dead:
# vi /usr/local/etc/keepalived/keepalived.conf
Updated file on both lb0 and lb1:

vrrp_script chk_http_port {
        script "/usr/bin/killall -0 nginx"
        interval 2
        weight 2}
vrrp_instance VI_1 {
        interface eth0
        state MASTER
        virtual_router_id 51
        priority 101
        authentication {
            auth_type PASS
            auth_pass Add-Your-Password-Here
        }
        track_script {
            chk_http_port
        }
        virtual_ipaddress {202.54.1.1/29 dev eth1
        }}

Save and close the file. Reload keealived:
# /etc/init.d/keepalived restart
If nginx died due to any issues keepalived will release master VIP and backup server will become active. When master nginx LB0 comes backs online, the backup LB1 will go down in backup state.

CentOS / Redhat: Install nginx As Reverse Proxy Load Balancer

shanyiwan@live.com() — Fri, 09 Dec 2011 01:29:16 GMT

How do I configure nginx as failover reverse proxy load balancer in front of two Apache web servers under CentOS / RHEL 5.x?

nginx is a Web and Reverse proxy server. Nginx used in front of Apache Web servers. All connections coming from the Internet addressed to one of the Web servers are routed through the nginx proxy server, which may either deal with the request itself or pass the request wholly or partially to the main web servers.

Our Sample Setup

Internet--
         |
    =============                               |---- apache1 (192.168.1.15)
    | ISP Router|                               |
    =============                               |---- apache2 (192.168.1.16)
         |                                      |
         |                                      |---- db1 (192.168.1.17)
         |      |eth0 -> 192.168.1.11 ----------/
         |-lb0==|                        /
         |      |eth1 -> 202.54.1.1 ----/
         |
         |      |eth0 -> 192.168.1.10 ----------\
         |-lb1==|                        /      |---- apache1 (192.168.1.15)
                |eth1 -> 202.54.1.1 ----/       |
                                                |---- apache2 (192.168.1.16)
                                                |
                                                |---- db1 (192.168.1.17)

Where,

lb0 - Linux box directly connected to the Internet via eth1. This is master load balancer.
lb1 - Linux box directly connected to the Internet via eth1. This is backup load balancer. This will become active if master networking failed.
202.54.1.1 - This ip moves between lb0 and lb1 server. It is called virtual IP address and it is managed by keepalived.
eth0 is connected to LAN and all other backend software servers are connected via eth0.
nginx is installed on both lb0 and lb1. It will listen on 202.54.1.1. You need to configure nginx as reverse proxy server. It will connects to Apache1 and Apache2.
Install httpd server on Apache#1 and Apache#2 server. Configure them to listen on 192.168.1.15:80 and 192.168.1.16:80. Do not assign public IP to this box. Only activate eth0 via LAN.
Install MySQL / Oracle / PgSQL server on Db#1. Configure db server to listen on 192.168.1.17:$db_server_port. Do not assign public IP to this box. Only activate eth0 via LAN.

In short you need the following hardware:

2 load balancer reverse proxy servers (250GB SATA, 2GB RAM, Single Intel P-D930 or AMD 170s with RHEL 64 bit+keepalived+nginx)
2 Apache web servers (Software RAID-1, SCSI-73GBx2 15k disk, 6GB RAM, Dual Intel Xeon or AMD 64 bit CPU with RHEL 64 bit+Apache 2)
1 backup Apache web servers (Software RAID-1, SCSI-73GBx2 15k disk, 6GB RAM, Dual Intel Xeon or AMD 64 bit CPU with RHEL 64 bit+Apache 2)
1 database server (RAID-10, SCSI-73GBx4 15k disk, 16GB RAM, Dual Intel Xeon or AMD 64 bit CPU with RHEL 64 bit+MySQL 5)
1 Caching server (RAID-1, SCSI-73GBx2 15k disk, 8GB RAM, Dual Intel Xeon or AMD 64 bit CPU with RHEL 64 bit)
1 offsite backup server (RAID-6, 1TB SATAx4, 4GB RAM, Single Intel/AMD CPU with RHEL 64bit)
Slave database, storage, pop3 and SMTP server as per requirements.
Internet uplink 100Mbps+ or as per requirements.

Remove Unwanted Software From lb0 and lb1

Type the following commands:
# yum -y groupremove "X Window System" # x=$(yum list installed | egrep -i 'php|httpd|mysql|bind|dhclient|tftp|inetd|xinetd|ypserv|telnet-server|rsh-server|vsftpd|tcsh' | awk '{ print $1}') # yum -y remove $x # yum -y install bind-utils sysstat openssl-devel.x86_64 pcre-devel.x86_64 openssl097a.x86_64 # /usr/sbin/authconfig --passalgo=sha512 --update # passwd root
The above will remove X windows and other unwanted software from both lb0 and lb1.

Install Nginx On Both lb0 and lb1

Type the following commands to download nginx, enter:
# cd /opt # wget http://sysoev.ru/nginx/nginx-0.8.33.tar.gz
Untar nginx, enter:
# tar -zxvf nginx-0.8.33.tar.gz # cd nginx-0.8.33
Configure nginx for 64 bit RHEL / CentOS Linux:
# ./configure --without-http_autoindex_module --without-http_ssi_module --without-http_userid_module --without-http_auth_basic_module --without-http_geo_module --without-http_fastcgi_module --without-http_empty_gif_module --with-openssl=/lib64
Sample outputs:

....
  nginx path prefix: "/usr/local/nginx"
  nginx binary file: "/usr/local/nginx/sbin/nginx"
  nginx configuration prefix: "/usr/local/nginx/conf"
  nginx configuration file: "/usr/local/nginx/conf/nginx.conf"
  nginx pid file: "/usr/local/nginx/logs/nginx.pid"
  nginx error log file: "/usr/local/nginx/logs/error.log"
  nginx http access log file: "/usr/local/nginx/logs/access.log"
  nginx http client request body temporary files: "client_body_temp"
  nginx http proxy temporary files: "proxy_temp"
  nginx http fastcgi temporary files: "fastcgi_temp"
...

Install the same:
# make # make install

Create nginx User Account

Type the following commands to create a user account:
# useradd -s /sbin/nologin -d /usr/local/nginx/html -M nginx # passwd -l nginx

Configure nginx As Reverse Proxy Load Balancer On Both lb0 and lb1

Edit /usr/local/nginx/conf/nginx.conf, enter:
# vi /usr/local/nginx/conf/nginx.conf
Update it as follows:

 
pid               logs/nginx.pid;
user              nginx nginx;
worker_processes  10;
 
events {
    worker_connections  1024;}
 
http {
  default_type       application/octet-stream;
 
 ## Common options ##
 include options.conf;
 
 ## Proxy settings ##
 include proxy.conf;
 
 ## lb domains ##
 include nixcraft.in.conf;}

Edit /usr/local/nginx/conf/options.conf, enter:
# vi /usr/local/nginx/conf/options.conf
Update it as follows:

 
 ## Size Limits
  client_body_buffer_size     128K;
  client_header_buffer_size   1M;
  client_max_body_size          1M;
  large_client_header_buffers 8 8k;
 
 ## Timeouts
  client_body_timeout   60;
  client_header_timeout 60;
  expires               24h;
  keepalive_timeout     6060;
  send_timeout          60;
 
 ## General Options
  ignore_invalid_headers   on;
  keepalive_requests      100;
  limit_zone gulag $binary_remote_addr 5m;
  recursive_error_pages    on;
  sendfile                 on;
  server_name_in_redirect off;
  server_tokens           off;
 
 ## TCP options
  tcp_nodelay on;
  tcp_nopush  on;
 
 ## Compression
  gzip              on;
  gzip_buffers      16 8k;
  gzip_comp_level   6;
  gzip_http_version 1.0;
  gzip_min_length   0;
  gzip_types        text/plain text/css image/x-icon application/x-perl application/x-httpd-cgi;
  gzip_vary         on;
 
 ## Log Format
  log_format  main  '$remote_addr $host $remote_user [$time_local]"$request" '
                    '$status $body_bytes_sent "$http_referer""$http_user_agent" '
                    '"$gzip_ratio"';

Edit /usr/local/nginx/conf/proxy.conf, enter:

 
 ## Proxy caching options
  proxy_buffering           on;
  proxy_cache_min_uses       3;
  proxy_cache_path          /usr/local/nginx/proxy_temp/ levels=1:2 keys_zone=cache:10m inactive=10m max_size=1000M;
  proxy_cache_valid         any 10m;
  proxy_ignore_client_abort off;
  proxy_intercept_errors    on;
  proxy_next_upstream       error timeout invalid_header;
  proxy_redirect            off;
  proxy_set_header          X-Forwarded-For $remote_addr;
  proxy_connect_timeout     60;
  proxy_send_timeout        60;
  proxy_read_timeout        60;

Edit /usr/local/nginx/conf/nixcraft.in.conf, enter:

 
## Connect to backend servers via LAN ##
## Reverse Proxy Load Balancer Logic ##
upstream nixcraft  {
      server 192.168.1.15weight=10 max_fails=3 fail_timeout=30s;
      server 192.168.1.16weight=10 max_fails=3 fail_timeout=30s;
      # only comes alive when above two fails
      server 192.168.1.23weight=1 backup;}
 
server {
      access_log  logs/access.log main;
      error_log   logs/error.log;
      index       index.html;
      root        /usr/local/nginx/html;
      server_name nixcraft.in www.nixcraft.in subdomain.nixcraft.in;
 
     ## Only requests to our Host are allowed
      if ($host !~ ^(nixcraft.in|www.nixcraft.in|subdomain.nixcraft.in)$ ){
         return 444;}
 
     ## redirect www to nowww
     # if ($host = 'www.nixcraft.in' ){
     #    rewrite  ^/(.*)$  http://nixcraft.in/$1  permanent;
     # }
 
     ## Only allow these request methods
     if ($request_method !~ ^(GET|HEAD|POST)$ ){
         return 444;}
 
     ## PROXY - Web
      location / {
        proxy_pass  http://nixcraft;
        proxy_cache            cache;
        proxy_cache_valid      200 24h;
        proxy_cache_use_stale  error timeout invalid_header updating http_500 http_502 http_503 http_504;
        proxy_ignore_headers   Expires Cache-Control;
 
        proxy_set_header        Host            $host;
        proxy_set_header        X-Real-IP       $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;}
 
     # redirect server error pages to the static page /50x.html
        error_page   500502503504  /50x.html;location = /50x.html {
            root   html;}}

Start nginx web server:
# /usr/local/nginx/sbin/nginx # netstat -tulpn | grep :80 # echo ' /usr/local/nginx/sbin/nginx' >> /etc/rc.local
Fire a webbrowser and type domain name such as nixcraft.in:
http://nixcraft.in

References:

nginx wiki

Using FastCGI to Host PHP Applications on IIS 7

shanyiwan@live.com() — Mon, 17 Oct 2011 15:04:54 GMT

This article describes how to configure the FastCGI module and PHP to host PHP applications on IIS 7.

IMPORTANT: This article provides instructions on how to install and use the FastCGI component on Windows Server 2008 and Windows Vista SP1. SP1 is required on Windows Vista.

Overview

The FastCGI module in IIS enables popular application frameworks that support the FastCGI protocol to be hosted on the IIS Web server in a high performance and reliable way. FastCGI provides a high-performance alternative to the Common Gateway Interface (CGI), which is a standard way of interfacing external applications with Web servers that has been a part of the supported IIS feature set since the first release.

CGI programs are executable files that are launched by the Web server for each request to process the request and generate dynamic responses that are then sent back to the client. Because many of these frameworks do not support multi-threaded execution, CGI enables them to execute reliably on IIS by executing exactly one request per process. Unfortunately, it provides poor performance due to the high cost of starting and shutting down a process for each request.

FastCGI addresses the performance issues that are inherent in CGI by providing a mechanism to reuse a single process over and over again for many requests. Additionally, FastCGI maintains compatibility with non-thread-safe libraries by providing a pool of reusable processes and ensuring that each process handles only one request at a time.

Enable FastCGI Support in IIS 7

Windows Server 2008

Go to Server Manager -> Roles -> Add Role Services. On the Select Role Services page, select the CGI check box. This enables both the CGI and FastCGI services.

Windows Vista SP1

Go to Control Panel -> Programs and Features -> Turn Windows features on or off. In the Windows Features dialog box, select the CGI check box. This enables both the CGI and FastCGI services.

IMPORTANT: Install the Update for the FastCGI Module

The update for the IIS 7 FastCGI module fixes several known compatibility issues with popular PHP applications. Install the update from one of the following locations:

Install the Administration Pack for IIS 7

NOTE: This step is optional.

Among other useful features, the Administration Pack for IIS 7 has a convenient user interface for configuring FastCGI settings. The Administration Pack can be installed from the following locations:

Install and Configure PHP

It is recommended that you use a non-thread safe build of PHP with IIS 7 FastCGI. A non-thread safe build of PHP provides significant performance gains over the standard build by not doing any thread-safety checks, which are not necessary, since FastCGI ensures a single threaded execution environment.

To install PHP:

Download the latest non-thread safe zip package with binaries of PHP: http://www.php.net/downloads.php.
Unpack the files to the directory of your choice (e.g. C:\PHP). Rename the php.ini-recommended file to php.ini.
Open the php.ini file. Uncomment and modify the settings as follows:
- Set fastcgi.impersonate = 1. FastCGI under IIS supports the ability to impersonate security tokens of the calling client. This allows IIS to define the security context that the request runs under.
- Set cgi.fix_pathinfo=1. cgi.fix_pathinfo provides *real* PATH_INFO/PATH_TRANSLATED support for CGI. Previously, PHP behavior was to set PATH_TRANSLATED to SCRIPT_FILENAME, and to not define PATH_INFO. For more information about PATH_INFO, see the cgi specifications. Setting this value to 1 will cause PHP CGI to fix its paths to conform to the specifications.
- Set cgi.force_redirect = 0.
- Set open_basedir to point to the folder or network path where the content of the Web site(s) is located.
- Set extension_dir to point to the location where the PHP extensions are located. Typically, for PHP 5.2.X the value would be set as extension_dir = "./ext"
- Enable the required PHP extension by un-commenting the corresponding lines, for example:
  
  extension=php_mssql.dll
  extension=php_mysql.dll
Open a command prompt, and run the following command to verify that PHP installed successfully:

C:\PHP>php –info

If PHP installed correctly and all its dependencies are available on the machine, this command will output the current PHP configuration information.

Configure IIS 7 to Handle PHP Requests

For IIS 7 to host PHP applications, you must add a handler mapping that tells IIS to pass all PHP-specific requests to the PHP application framework by using the FastCGI protocol.

Configure IIS 7 to handle PHP requests by using IIS Manager

1. Open IIS Manager. At the server level, double-click Handler Mappings.

2. In the Actions pane, click Add Module Mapping.... In the Add Module Mapping dialog box, specify the configuration settings as follows:

Request path: *.php

Module: FastCgiModule

Executable: "C:\[Path to your PHP installation]\php-cgi.exe"

Name: PHP via FastCGI

3. Click OK.

4. In the Add Module Mapping confirmation dialog box that asks if you want to create a FastCGI application for this executable, click Yes.

5. Test that the handler mapping works correctly by creating a phpinfo.php file in the C:\inetpub\wwwroot folder that contains the following code:

<?php phpinfo(); ?>

6. Open a browser and navigate to http://localhost/phpinfo.php. If everything was setup correctly, you will see the standard PHP information page.

NOTE: If you do not see FastCgiModule in the Modules: list, the module is either not registered or not enabled. To check if the FastCGI module is registered, open the IIS configuration file that is located at %windir%\windows\system32\config\applicationHost.config and check that the following line is present in the <globalModules> section:

<add name="FastCgiModule" image="%windir%\System32\inetsrv\iisfcgi.dll" />

In the same file, also check that the FastCGI module is added to the <modules> section:

<add name="FastCgiModule" />

Configure IIS 7 to handle PHP requests by using the command line

Alternatively, you can complete the steps above by using the command line tool AppCmd.

1. Create the FastCGI application process pool by running the following command:

C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\{php_folder}\php-cgi.exe']

2. Create the handler mapping by running the following command:

C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/handlers /+[name='PHP_via_FastCGI',path='*.php',verb='*',modules='FastCgiModule',scriptProcessor='c:\{php_folder}\php-cgi.exe',resourceType='Unspecified']

Note: If you are using PHP version 4.X, you can use php.exe instead of php-cgi.exe.

Best Practices for Configuring FastCGI and PHP

This download contains a summary presentation on Best Practices for hosting PHP in a shared hosting environment.

Security Isolation for PHP Web Sites

The recommendation for isolating PHP Web sites in a shared hosting environment is consistent with all general security isolation recommendations for IIS 7. In particular, it is recommended to:

Use one application pool per Web site
Use a dedicated user account as an identity for the application pool
Configure an anonymous user identity to use the application pool identity
Ensure that FastCGI impersonation is enabled in the php.ini file (fastcgi.impersonate=1)

For more details about security isolation in a shared hosting environment, see Ensure Security Isolation for Web Sites.

PHP Process Recycling Behavior

Ensure that FastCGI always recycles the php-cgi.exe processes before the native PHP recycling kicks in. The FastCGI process recycling behavior is controlled by the configuration property instanceMaxRequests. This property specifies how many requests the FastCGI process will process before recycling. PHP also has a similar process recycling functionality that is controlled by the environment variable PHP_FCGI_MAX_REQUESTS. By setting instanceMaxRequests to be less than or equal to PHP_FCGI_MAX_REQUESTS, you can ensure that the native PHP process recycling logic will never kick in.

The FastCGI settings can be configured either by using IIS Manager or by using the command line tool AppCmd.

Configure FastCGI recycling settings by using IIS Manager

1. Ensure that the Administration Pack for IIS 7 is installed on your server. Open IIS Manager. On the server level, double-click FastCGI Settings.

2. Select the FastCGI application that you want to configure. In the Actions pane, click Edit....

3. In the Edit FastCGI Application dialog box, set the InstanceMaxRequests to 10000. Next to the EnvironmentVariables setting, click the Browse (...) button.

4. In the EnvironmentVariables Collection Editor dialog box, add the PHP_FCGI_MAX_REQUESTS environment variable and set its value to 10000.

Note: If you do not configure these settings, the following default settings will be used: instanceMaxRequests = 200, PHP_FCGI_MAX_REQUESTS = 500 (on most PHP builds).

Configure FastCGI recycling settings by using the command line

Configure the recycling behavior of FastCGI and PHP by using AppCmd by running the following commands:

C:\>%windir%\system32\inetsrv\appcmd set config -section:system.webServer/fastCgi /[fullPath='c:\{php_folder}\php-cgi.exe'].instanceMaxRequests:10000 C:\>%windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/fastCgi /+"[fullPath='C:\{php_folder}\php-cgi.exe'].environmentVariables.[name='PHP_FCGI_MAX_REQUESTS',value='10000']"

PHP Versioning

Many PHP applications rely on functions or features that are available only in certain versions of PHP. If these types of applications are to be hosted on the same server, different PHP versions must be enabled and running side-by-side. The IIS 7 FastCGI handler fully supports running multiple versions of PHP on the same Web server.

For example, assume that on your Web server you plan to support PHP 4.4.8, PHP 5.2.1, and PHP 5.2.5 non-thread safe. To enable that configuration, you must place corresponding PHP binaries in separate folders on the file system (e.g. C:\php448\, C:\php521\ and C:\php525nts) and then create FastCGI application process pools for each version:

C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php448\php.exe'] C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php521\php-cgi.exe'] C:\>%windir%\system32\inetsrv\appcmd set config /section:system.webServer/fastCGI /+[fullPath='c:\php525nts\php-cgi.exe']

If you have three Web sites (site1, site2, site3) and each site must use a different PHP version, you can now define handler mappings on each of those sites to reference a corresponding FastCGI application process pool.

Note: Each FastCGI process pool is uniquely identified by a combination of fullPath and arguments properties.

C:\>%windir%\system32\inetsrv\appcmd set config site1 –section:system.webServer/handlers /+”..[name=’PHP448_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php448\php.exe’,resourceType=’Either’] C:\>%windir%\system32\inetsrv\appcmd set config site2 –section:system.webServer/handlers /+”..[name=’PHP521_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php521\php-cgi.exe’,resourceType=’Either’] C:\>%windir%\system32\inetsrv\appcmd set config site3 –section:system.webServer/handlers /+”..[name=’PHP525nts_via_FastCGI’,path=’*.php’,verb=’*’,modules=’FastCgiModule’,scriptProcessor=’c:\php525nts\php-cgi.exe’,resourceType=’Either’]

PHP Security Recommendations

The following settings can be used to tighten the security of a PHP installation. To make the recommended changes, locate and open the php.ini file and edit the configuration settings as described below:

Setting	Description
allow_url_fopen=Off allow_url_include=Off	Disable remote URLs for file handling functions, which may cause code injection vulnerabilities.
register_globals=Off	Disable register_globals.
open_basedir="c:\inetpub\"	Restrict where PHP processes can read and write on a file system.
safe_mode=Off safe_mode_gid=Off	Disable safe mode.
max_execution_time=30 max_input_time=60	Limit script execution time.
memory_limit=16M upload_max_filesize=2M post_max_size=8M max_input_nesting_levels=64	Limit memory usage and file sizes.
display_errors=Off log_errors=On error_log="C:\path\of\your\choice"	Configure error messages and logging.
fastcgi.logging=0	The IIS FastCGI module will fail the request when PHP sends any data on stderr by using the FastCGI protocol. Disable FastCGI logging to prevent PHP from sending error information over stderr and generating 500 response codes for the client.
expose_php=Off	Hide the presence of PHP.

Enabling per-site PHP configuration

This section describes the recommended way of enabling per-site PHP configuration. This recommendation was discovered and validated by Radney Jasmin with hosting provider GoDaddy.com who now offers PHP hosting on Windows Server 2008 by using FastCGI.

Per-site PHP Process Pools

When each Web site has its own application pool, which is a recommended practice on IIS 7, it is possible to associate a dedicated FastCGI process pool with each Web site. A FastCGI process pool is uniquely identified by the combination of fullPath and arguments attributes. If you need to create several FastCGI process pools for the same process executable, such as php-cgi.exe, you can use the arguments attribute to distinguish the process pool definitions. With php-cgi.exe processes, you can also use the command line switch "-d" to define an INI entry for a PHP process. You can use this switch to set a PHP setting that makes the arguments string unique.

For example, if there are two Web sites "website1" and "website2" that must have their own set of PHP settings, the FastCGI process pools can be defined as follows:

<fastCgi> <application fullPath="C:\PHP\php-cgi.exe" arguments="-d open_basedir=C:\Websites\Website1" /> <application fullPath="C:\PHP\php-cgi.exe" arguments="-d open_basedir=C:\Websites\Website2" /> </fastCgi>

In this example the PHP setting open_basedir is used to distinguish between the process pool definitions. The setting also enforces that the PHP executable for each process pool can perform file operations only within the root folder of the corresponding Web site.

Then website1 can have the PHP handler mapping as follows:

<system.webServer> <handlers accessPolicy="Read, Script"> <add name="PHP via FastCGI" path="*.php" verb="*" modules="FastCgiModule" scriptProcessor="C:\PHP\php-cgi.exe|-d open_basedir=C:\Websites\Website1" resourceType="Unspecified" requireAccess="Script" /> </handlers> </system.webServer>

and website2 can have the PHP handler mapping as follows:

<system.webServer> <handlers accessPolicy="Read, Script"> <add name="PHP via FastCGI" path="*.php" verb="*" modules="FastCgiModule" scriptProcessor="C:\PHP\php-cgi.exe|-d open_basedir=C:\Websites\Website2" resourceType="Unspecified" requireAccess="Script" /> </handlers> </system.webServer>

Specifying php.ini location

When the PHP process starts, it determines the location of the configuration php.ini file by using various settings. The PHP documentation provides a detailed description of the PHP startup process. One of the places where the PHP process searches for the php.ini location is the PHPRC environment variable. If the PHP process finds a php.ini file in the path that is specified in this environment variable, it will use it; otherwise, the PHP process will revert to using the default location of the php.ini file. This environment variable can be used to allow hosting customers to use their own versions of php.ini files.

For example if there are two Web sites "website1" and "website2" that are located at the following file paths: C:\WebSites\website1 and C:\WebSites\website2, you can configure the php-cgi.exe process pools in the <fastCgi> section of the applicationHost.config file as follows:

<fastCgi> <application fullPath="C:\PHP\php-cgi.exe" arguments="-d open_basedir=C:\Websites\Website1"> <environmentVariables> <environmentVariable name="PHPRC" value="C:\WebSites\website1" /> </environmentVariables> </application> <application fullPath="C:\PHP\php-cgi.exe" arguments="-d open_basedir=C:\WebSites\Website2"> <environmentVariables> <environmentVariable name="PHPRC" value="C:\WebSites\website2" /> </environmentVariables> </application> </fastCgi>

This way website1 can have its own version of the php.ini file that is located in the C:\WebSites\website1, while website2 can have its own version of the php.ini file that is located in C:\WebSites\website2. This configuration also ensures that if a php.ini file cannot be found in the location that is specified by the PHPRC environment variable, then PHP will use the default php.ini file that is located in the same folder where the php-cgi.exe is located.

Provide URL Rewriting Functionality for PHP Applications

The majority of popular PHP applications rely on the URL rewriting functionality in Web servers to enable user-friendly and search engine-friendly URLs. IIS 7 provides URL rewriting capabilities by using the URL rewrite module.

For more information about how to use the URL Rewrite module, see the following articles:

Microsoft URL Rewrite Module Walkthroughs. Describes how to use the URL Rewrite module.
Microsoft URL Rewrite Module configuration reference. Explains the functionality of the module and provides descriptions of all the configuration options.
Configuring popular PHP applications to work with the URL Rewrite module:

Related resources

For more information regarding hosting PHP applications on IIS refer to the following resources:

How to check if your Linux WebServer is under a DoS attack

shanyiwan@live.com() — Tue, 13 Sep 2011 02:49:46 GMT

There are few commands I usually use to track if my server is possibly under a Denial of Service attack or under Distributed Denial of Service

Sys Admins who still have not experienced the terrible times of being under a DoS attack are happy people for sure …

1. How to Detect a TCP/IP Denial of Service Attack

This are the commands I use to find out if a loaded Linux server is under a heavy DoS attack, one of the most essential one is of course netstat.
To check if a server is under a DoS attack with netstat, it’s common to use:

linux:~# netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n|wc -l

If the output of below command returns a result like 2000 or 3000 connections!, then obviously it’s very likely the server is under a DoS attack.

To check all the IPS currently connected to the Apache Webserver and get a very brief statistics on the number of times each of the IPs connected to my server, I use the cmd:

linux:~# netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n 221 80.143.207.107 233 145.53.103.70 540 82.176.164.36

As you could see from the above command output the IP 80.143.207.107 is either connected 221 times to the server or is in state of connecting or disconnecting to the node.

Another possible way to check, if a Linux or BSD server is under a Distributed DoS is with the list open files command lsof
Here is how lsof can be used to list the approximate number of ESTABLISHED connections to port 80.

linux:~# lsof -i TCP:80 litespeed 241931 nobody 17u IPv4 18372655 TCP server.pc-freak.net:http (LISTEN) litespeed 241931 nobody 25u IPv4 18372659 TCP 85.17.159.89:http (LISTEN) litespeed 241931 nobody 30u IPv4 29149647 TCP server.pc-freak.net:http->83.101.6.41:54565 (ESTABLISHED) litespeed 241931 nobody 33u IPv4 18372647 TCP 85.17.159.93:http (LISTEN) litespeed 241931 nobody 34u IPv4 29137514 TCP server.pc-freak.net:http->83.101.6.41:50885 (ESTABLISHED) litespeed 241931 nobody 35u IPv4 29137831 TCP server.pc-freak.net:http->83.101.6.41:52312 (ESTABLISHED) litespeed 241931 nobody 37w IPv4 29132085 TCP server.pc-freak.net:http->83.101.6.41:50000 (ESTABLISHED)

Another way to get an approximate number of established connections to let’s say Apache or LiteSpeed webserver with lsof can be achieved like so:

linux:~# lsof -i TCP:80 |wc -l 2100

I find it handy to keep track of above lsof command output every few secs with gnu watch , like so:

linux:~# watch "lsof -i TCP:80"

2. How to Detect if a Linux server is under an ICMP SMURF attack

ICMP attack is still heavily used, even though it’s already old fashioned and there are plenty of other Denial of Service attack types, one of the quickest way to find out if a server is under an ICMP attack is through the command:

server:~# while :; do netstat -s| grep -i icmp | egrep 'received|sent' ; sleep 1; done 120026 ICMP messages received 1769507 ICMP messages sent 120026 ICMP messages received 1769507 ICMP messages sent

As you can see the above one liner in a loop would check for sent and recieved ICMP packets every few seconds, if there are big difference between in the output returned every few secs by above command, then obviously the server is under an ICMP attack and needs to hardened.

3. How to detect a SYN flood with netstat

linux:~# netstat -nap | grep SYN | wc -l 1032

1032 SYNs per second is quite a high number and except if the server is not serving let’s say 5000 user requests per second, therefore as the above output reveals it’s very likely the server is under attack, if however I get results like 100/200 SYNs, then obviously there is no SYN flood targetting the machine

Another two netstat command application, which helps determining if a server is under a Denial of Service attacks are:

server:~# netstat -tuna |wc -l 10012

and

server:~# netstat -tun |wc -l 9606

Of course there also some other ways to check the count the IPs who sent SYN to the webserver, for example:

server:~# netstat -n | grep :80 | grep SYN |wc -l

In many cases of course the top or htop can be useful to find, if many processes of a certain type are hanging around.

4. Checking if UDP Denial of Service is targetting the server

server:~# netstat -nap | grep 'udp' | awk '{print $5}' | cut -d: -f1 | sort |uniq -c |sort -n

The above command will list information concerning possible UDP DoS.

The command can easily be accustomed also to check for both possible TCP and UDP denial of service, like so:

server:~# netstat -nap | grep 'udp|udp' | awk '{print $5}' | cut -d: -f1 | sort |uniq -c |sort -n 104 109.161.198.86 115 112.197.147.216 129 212.10.160.148 227 201.13.27.137 3148 91.121.85.220

If after getting an IP that has too many connections to the server and is almost certainly a DoS host you would like to filter this IP.

You can use the /sbin/route command to filter it out, using route will probably be a better choice instead of iptables, as iptables would load up the CPU more than simply cutting the route to the server.

Here is how I remove hosts to not be able to route packets to my server:

route add 110.92.0.55 reject

The above command would null route the access of IP 110.92.0.55 to my server.

Later on to look up for a null routed IP to my host, I use:

route -n |grep -i 110.92.0.55

Well hopefully this should be enough to give a brief overview on how, one can dig in his server and find if he is under a Distributed Denial of Service, hope it’s helpful to somebody out there.

flyinweb's blog - WEB服务器

Apache编译失败及其解决方案

Nginx as an IMAP/POP3 proxy

Creating Certificate Authorities and self-signed SSL certificates

httpd: apr_sockaddr_info_get() failed for HOSTNAME

nginx: Setup SSL Reverse Proxy (Load Balanced SSL Proxy)

Our Sample Setup

Generating Self-signed Certificate

How Do I Remove The Passphrase? (Optional)

How Do I Copy SSL Certificates Files To lb1?

Configure Nginx As SSL Reverse Proxy (lb0 and lb1)

How Do I Test And Debug SSL Certificates From The Shell Prompt?

How Do I Cache Common Files?

CentOS / Redhat Linux: Install Keepalived To Provide IP Failover For Web Cluster

Our Sample Setup

Install Keepalived

Install Kernel Headers

Compile keepalived

Create Required Softlinks

Configuration

Verify: Keepalived Working Or Not

ping failover test

Conclusion

Handling nginx Failover With KeepAlived

CentOS / Redhat: Install nginx As Reverse Proxy Load Balancer

Our Sample Setup

Remove Unwanted Software From lb0 and lb1

Install Nginx On Both lb0 and lb1

Create nginx User Account

Configure nginx As Reverse Proxy Load Balancer On Both lb0 and lb1

References:

Using FastCGI to Host PHP Applications on IIS 7

Table of Contents

Overview

Enable FastCGI Support in IIS 7

Windows Server 2008

Windows Vista SP1

IMPORTANT: Install the Update for the FastCGI Module

Install the Administration Pack for IIS 7

Install and Configure PHP

Configure IIS 7 to Handle PHP Requests

Configure IIS 7 to handle PHP requests by using IIS Manager

Configure IIS 7 to handle PHP requests by using the command line

Best Practices for Configuring FastCGI and PHP

Security Isolation for PHP Web Sites

PHP Process Recycling Behavior

Configure FastCGI recycling settings by using IIS Manager

Configure FastCGI recycling settings by using the command line

PHP Versioning

PHP Security Recommendations

Enabling per-site PHP configuration

Per-site PHP Process Pools

Specifying php.ini location

Provide URL Rewriting Functionality for PHP Applications

Related resources

Related Content

How to check if your Linux WebServer is under a DoS attack