Estos días en el trabajo he estado desplegando una aplicación web hecha en Ruby On Rails, y hoy por fin acabamos con ello. La verdad que el despliegue ha sido bastante sencillo, quitando aquellos típicos errores por no saber . Hay varios tutoriales para desplegar usando Capistrano, Mongrel y Nginx, pero yo voy a postear mi propia solución.

Para empezar,supongo que tienes un servidor funcionando con Ruby, las gemas de Rails, acceso ssh y Subversion.

Vayamos por partes, como diría Jack El Destripador: instalar Mongrel y Nginx en el servidor (en mi caso un flamante Debian Lenny):

# apt-get install nginx
# ### Mongrel lo instalo como una gema de Ruby
# gem install mongrel mongrel-cluster

Ahora podemos instalar Capistrano en el equipo de trabajo local

# gem install capistrano

¿Está? Ahora comenzamos el trabajo de verdad. La documentación de Capistrano (Getting Started y From The Beiginning) son más que suficentes para hacer funcionar Capistrano como Dios manda. Vayamos a la carpeta de la aplicación y ejecuta lo siguiente (si no está en el path, no queda otra que buscarlo):

# capify .

Esto genera dos ficheros, Capfile y deploy.rb. El contenido de deploy.rb tendrá la siguiente forma:

set :application, "Nombre de la aplicación"
set :repository,  "Ruta del repositorio al código. Como no especifico nada más, Capistrano asume que es Subversion"
# Desplegar desde la rama trunk puede estar bien, pero a veces puede ser mejor crear una rama estable y desplegar de ahí, para curarse en salud

role :web, "192.168.1.192"                          # Mi servidor HTTP, Apache/etc
role :app, "192.168.1.192"                          # Mi servidor de aplicaciones
role :db,  "192.168.1.192",:primary => true         # Servidor de base de datos. Le indico también que es la base de datos primaria

set :deploy_to, "/home/deploy/apps/nombre-aplicacion/" # El sitio donde se va a desplegar
set :user, 'deploy' # El usuario que desplegará todo

# namespace :deploy do
#   task :start {}
#   task :stop {}
#   task :restart, :roles => :app, :except => { :no_release => true } do
#     run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
#   end
# end

En el fichero Capfile no suele haber que tocar nada, pero puede que necesites especificar que usuario va a arrancar el servidor de aplicaciones. Para ello añade la siguiente línea al fichero Capfile:

set :runner, 'deploy'

Con esto, un desplegado debería funcionar, como norma general. Para mas opciones, mira en los enlaces que mencioné antes.

Ahora, con Capistrano preparado para la marcha, y el servidor con las aplicaciones necesarias, desplegar es tan sencillo como hacer desde el equipo de trabajo:

cap deploy: setup
# => Con esto se prepara el servidor con la jerarquía de carpetas
# Después de esto es mejor mirar si las carpetas tienen el propietario y los permisos que deben.
cap deploy:check
# => Un chequeo de dependencias automático
cap deploy:update
# => Hace un checkout de la última versión del repositorio y lo organiza, estableciendo la ultima versión como "current".

Ahora damos respiro a este equipo, ya que tenemos que crear la base de datos. para ello nos conectamos a la base de datos de turno para la producción, creamos usuarios y todo lo necesario y desde el servidor mandamos hacer las migraciones:

rake RAILS_ENV=production db:schema:load
# = > Cualquier error aquí vendrá por que falta algo por hacer, o database.yml tiene algún dato incorrecto

Con todo esto, ya debería funcionar la aplicación web. Podemos probarlo con “script/console production” o con WEBrick

Para que Capistrano pueda arrancar el servidor de aplicaciones, hay que crear un script en la carpeta script del proyecto. Lo llamamos spin, y para funcionar con Mongrel, ha de tener lo siguiente (cambiando por tus datos, claro ^_^):

#!/bin/sh

/home/deploy/apps/mvweb4/current/script/process/spawner \
 mongrel \
 --environment=production \
 --instances=1 \
 --address=127.0.0.1 \
 --port=8000

Si quisiera ejecutar más mongrels, en distintos puertos, solo tengo que repetir ese comando en el fichero.

Ahora, solo queda que en el equipo se mande a capistrano que arranque los Mongrel con:

# cap deploy:start

Gracias a todo esto tenemos el servidor de aplicaciones escuchando, desde local todo funciona, pero nos queda el servidor web. Como este post esta quedando muy largo, dejo para el siguiente finiquitar esto y dejarlo 100% funcional. Si llegaste leyendo hasta aquí ¡enhorabuena!

Czego będziemy potrzebowali aby uruchomić nasze Wiki:

• PHP,
• PHP-FPM,
• XCache,
• Nginx,
• skrypt DokuWiki,
• oraz kilku podstawowych pakietów z repozytorium.

PHP myślę, że nie ma specjalnej potrzeby w tym miejscu opisywać. Dodam tylko, że **PHP-FPM** ma za zadanie nieco podnieść wydajność i zachęcam do skorzystania.

Nginx (wym. engine x) jest ultraszybkim oraz zajmującym mało pamięci serwerem WWW. Tworzony jest przez rosyjskiego programistę Igora Sysojewa. Więcej na temat serwera na [[http://sysoev.ru/en/|stronie domowej projektu]].

W zasadzie DokuWiki może działać zgodnie z różnymi serwerami WWW, ale ja wybrałem do tej pory nieznanego mi Nginx.

Przygotowanie systemu

Nie jest to zbyt wymagająca procedura, ale należy mieć podstawowe paczki dostępne w repozytorium. Chociażby z tego powodu, że będą potrzebne do późniejszej kompilacji. Moglibyśmy wszystko pobrać z repozytorium Debiana, jednak ma to swoje wady. Po pierwsze PHP ma zbyt dużo zależności, a po drugie instalując ze źródeł skorzystamy z nowszych wersji pakietów (przykładowo na dzień dzisiejszy w repo (testing) mamy wersję Nginx’a 0.6.34-2, a my ze źródeł zainstalujemy 0.7.60).

W celu instalacji wspomnianych pakietów należy wykonać komendę:

aptitude install build-essential libtool libltdl3-dev libgd-dev libmcrypt-dev libxml2-dev libmysqlclient15-dev flex m4 awk automake autoconf bison make
libbz2-dev libpcre3-dev libssl-dev zlib1g-dev re2c mysql-server postfix libjpeg62 libjpeg62-dbg libjpeg62-dev libpng12-0 libpng12-0-dev

Jest to zbiór, który powinien w zupełności wystarczyć.

Instalacja oraz konfiguracja PHP/PHP-FPM

Dobrym pomysłem jest stworzenie katalogu gdzie będziemy przechowywać źródła pakietów.
**Uwaga**: znak “$” przed komendą oznacza wykonanie jej z poziomu zwykłego użytkownika, zaś “#” z poziomu su (root).

$ mkdir ~/zrodla
$ cd ~/zrodla
$ wget http://pt.php.net/distributions/php-5.2.8.tar.bz2
$ tar xjf php-5.2.8.tar.bz2
$ wget http://php-fpm.anight.org/downloads/head/php-5.2.8-fpm-0.5.10.diff.gz
$ gzip -cd php-5.2.8-fpm-0.5.10.diff.gz | patch -d php-5.2.8 -p1
$ cd php-5.2.8
$ ./configure --enable-fastcgi --enable-fpm --with-mcrypt --with-zlib --enable-mbstring --with-openssl --with-mysql --with-mysql-sock --with-gd
--with-jpeg-dir=/usr/lib --enable-gd-native-ttf --without-sqlite --disable-pdo --disable-reflection
#make all install
#strip /usr/local/bin/php-cgi

Oczywiście można użyć dowolnej wersji PHP. Ewentualnie można opcje ./configure dopasować do własnych potrzeb lub zostawić tak jak jest.

Teraz zajmiemy się edycją pliku konfiguracyjnego PHP-FPM za pomocą dowolnego edytora, np. //vim//.

# vim /usr/local/etc/php-fpm.conf

Przechodzimy do linii pliku konfiguracyjnego numer 63. oraz 66. i ustanawiamy nazwę oraz grupę użytkownika. Pamiętamy przy tym aby dany użytkownik istniał w systemie (ja grupę zostawiłem bez zmian).

Instalacja oraz konfiguracja XCache

XCache to dwu modułowe rozszerzenie dla PHP pozwalające na korzystanie z mechanizmu cache. Ma na celu przyspieszać wykonywanie aplikacji PHP.

$ cd ~/zrodla
$ wget http://xcache.lighttpd.net/pub/Releases/1.2.2/xcache-1.2.2.tar.gz
$ tar xzvf xcache-1.2.2.tar.gz
$ cd xcache-1.2.2
$ phpize
$ ./configure --with-php-config=/usr/local/bin/php-config --enable-xcache
# make install

Polecenie //phpize// wspomaga instalowanie dodatków dla PHP.

Instalacja oraz konfiguracja Nginx

$ cd ~/zrodla
$ wget http://sysoev.ru/nginx/nginx-0.7.60.tar.gz
$ tar xzvf nginx-0.7.60.tar.gz
$ cd nginx-0.7.60
$ ./configure --sbin-path=/usr/local/sbin --with-http_ssl_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module
$ make
$make install

Edytujemy plik konfiguracyjny:
# vim /usr/local/nginx/conf/ngingx.conf

Do postaci:
user nazwa_usera;
worker_processes 2;
events {
worker_connections 768;
}
http {
include mime.types;
default_type application/octet-stream;
sendfile on;
tcp_nodelay on;
keepalive_timeout 10 10;
gzip on;
gzip_comp_level 1; gzip_proxied any;
gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
include /usr/local/nginx/sites-enabled/*;
}

W 1. linii powyższego pliku należy podać w polu //nazwa_usera// nazwę użytkownika podaną wcześniej w pliku ///usr/local/etc/php-fpm.conf//.

Następnie:
# vim /usr/local/nginx/conf/fastcgi_params

I na końcu pliku dopisujemy:
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

Tworzymy potrzebny katalog i plik:

# mkdir /usr/local/nginx/sites-enabled
# vim /usr/local/nginx/sites-enabled/trycode.net

Jeżeli korzystamy z innego edytora aniżeli //vim// i otrzymujemy informację, że plik ///usr/local/nginx/sites-enabled/trycode.net// nie istnieje to należy go stworzyć. Po utworzeniu pliku uzupełniamy go w następujący sposób:

server {
listen 80;
server_name www.trycode.net;
index index.php;
root /var/www/wiki;
location / {
error_page 404 = //index.php?q=$uri;
}
location ~ .php$ {
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
include /usr/local/nginx/conf/fastcgi_params;
}
}


Jeszcze na koniec edycja pliku ///usr/local/lib/php.ini//. Jeśli plik nie istnieje to zachowujemy się identycznie jak wyżej i uzupełniamy go treścią:

magic_quotes_gpc=0
[xcache-common]
zend_extension = /usr/local/lib/php/extensions/no-debug-non-zts-20060613/xcache.so
[xcache]
xcache.shm_scheme = "mmap"
xcache.size = 64M
date.timezone = "Europe/Rome"
default_charset = "utf-8"


Uruchamiamy //PHP-FPM// i //Nginx//:
# php-fpm start
# nginx

Czas aby wiki ujrzało światło dzienne

Instalacja DokuWiki nie jest ani trudna, ani pracochłonna. Ściągamy nową wersję skryptu i rozpakowujemy archiwum:

$ wget http://www.splitbrain.org/_media/projects/dokuwiki/dokuwiki-2009-02-14b.tgz
$ tar -xzvf dokuwiki-2009-02-14b.tgz

Teraz przenosimy zawartość rozpakowanego katalogu (na serwer) do ///var/www/wiki// i:

$ touch /var/www/wiki/data/changes.log
$ cd /var/www/wiki
$ chmod 666 data/changes.log
$ chmod 777 data/
$ chmod 777 data/attic

Po tych zabiegach możemy już uruchomić plik instalacyjny:
http://localhost/wiki/install.php

Dalej ustalamy użytkownika, hasło, nazwę wiki itp. Gdy chcemy lokalnie odwiedzić własną stronę (np. w celu edycji) to w przeglądarce internetowej wpisujemy:
http://localhost/wiki

Inne

Jeśli chcemy uruchomić dokuwiki na komputerze bez Xów możemy plik instalacyjny uruchomić (dla pewnego ułatwienia) z innego komputera w sieci LAN wyposażonego w środowisko graficzne. W tym celu należy podać w przeglądarce WWW adres IP serwera, np.:
http://192.168.100.244/wiki/install.php

Lub w celu późniejszej edycji stron:
http://192.168.100.244/wiki

/var/www/wiki/lib/tpl – przechowujemy szablony
/var/www/wiki/data/media/wiki — grafikę (zdjęcia) w formacie png lub jpg
/var/www/wiki/data/pages — strony zawarte w plikach tekstowych

Aby zmienić szablon:
Administracja -> Ustawienia -> Podstawowe -> Motyw

Lub edytując plik:

Jeśli chcemy móc stosować kod PHP lub HTML to należy zaznaczyć te opcje, ponieważ standardowo są wyłączone:
Administracja -> Ustawienia -> Edycja -> Wstawki HTML
Administracja -> Ustawienia -> Edycja -> Wstawki PHP

Artykuł przetłumaczony, rozszerzony i poprawiony na podst. źródła w jęz. angielskim.

This was long lost post I had written about 8 months ago (converted from wiki to HTML – so pardon typos if any)

Terminologies

Capistrano is a ruby gem which helps in remote deployment. As against widely known convention, Capistrano can be used for any deployment, not just a rails app!

Nginx is a web-proxy server. This is simply a light weight HTTP web-server which received requests on HTTP and passes them to other applications. This is way more preferable than Application servers like Apache! Moreover, nginx is very easily configurable and can support multiple domain-names very easily. It has an in-build load-balancer which can send requests to apps based on its internal load-balancing mechanism.

Thin is the next-generation lean, mean rails server. Its much faster, lighter in memory than mongrel. Its has an internal event based mechanism for request processing and a very high concurrency performance ratio than other rails servers.

Linode is a VPS (a Virtual Private Server) that is hosted by www.linode.com. As the name suggests , its a “Linux Node”.  We are using Ubuntu 8.10 (Tip: To find Ubuntu release, issue command: lsb_release -a) NOTE: In the linode we had, it was a raw machine with no packages installed. Please read Linode RoR package installation for details.

Steps

Capistrano Configuration Follow the steps provided by Capistrano for basic instructions: Capistrano – From The Beginning Some modifications that you may need (as I needed for deployment):

• Edit Capfile and add the following to it. This ensures that remote capistrano deployment does not fork a remote shell using command “sh -c”. Some hosting servers do not allow remote shells.

default_run_options[:shell] = false

• In addition to changes mentioned in Capistrano tutorial, add the following to config/deploy.rb. This ensures that “sudo” is not used (default for Capistrano) and the user is “root”. Not usually a good practice.. but what the hell!

set :use_sudo, false            set :user, "root"

• Since capistrano uses default script/spin and script/process/reaper, we need to override the deploy:start, deploy:stop and deploy:restart to ensure that we can start/stop the thin service and the ferret_server. I know that in deply:restart, there is a copy-paste involved but I am trying to find out how to invoke a rake task from another rake task.

namespace :deploy do
    desc "Custom AceMoney deployment: stop."
    task :stop, :roles => :app do

        invoke_command "cd #{current_path};./script/ferret_server -e production stop"
        invoke_command "service thin stop"
    end

    desc "Custom AceMoney deployment: start."
    task :start, :roles => :app do

        invoke_command "cd #{current_path};./script/ferret_server -e production start"
        invoke_command "service thin start"
    end

    # Need to define this restart ALSO as 'cap deploy' uses it
    # (Gautam) I dont know how to call tasks within tasks.
    desc "Custom AceMoney deployment: restart."
    task :restart, :roles => :app do

        invoke_command "cd #{current_path};./script/ferret_server -e production stop"
        invoke_command "service thin stop"
        invoke_command "cd #{current_path};./script/ferret_server -e production start"
        invoke_command "service thin start"
    end
end

Thin Configuraion I looked up most of the default configuration of Thin and Nginx on Ubunto at Nginx + Thin. Some extra configuration or differences are mentioned below.

• The init script for starting thin and nginx during startup is configured during package installation. Leave them as they are.
• The following command generates the /etc/thin/acemoney.yml for 3 server starting from port 3000. Note that the -c option specifies the BASEDIR of the rails app. Do NOT change any settings in this file as far as possible.

thin config -C /etc/thin/acemoney.yml -c /home/josh/current --servers 3 -e production -p 3000

• Starting and stopping thin is as simple as

service thin start
service thin stop

• This will read the acemoney.yml file and spawn the 3 thin processes. I noticed that each thin server took about 31MB in memory to start with and with caching went upto ~70MB. On the contrary, a mongrel server (tested earlier) started with 31MB but exceeded 110MB later!

Nginx Configuration Installation on nginx is simple on Ubuntu

apt-get install nginx

Configure the base /etc/nginx/nginx.conf. The default configuration are fine but I added / edited a few more for as recommended at Nginx Configuration

        worker_processes  4;

        gzip_comp_level 2;
        gzip_proxied any;
        gzip_types  text/plain text/html text/css application/x-javascript
                    text/xml application/xml application/xml+rss text/javascript;

According to this configuration above, nginx will spawn 4 worker threads and each worker thread can process 1024 connections (default setting). So, nginx can now process ~4000 concurrent HTTP requests !!! See performance article of thin at Thin Server

Configure the domainname, in our case acemoney.in. Ensure that acemoney.in “A record” entry points to this server! Check this by doing a nslookup or a ping for the server. In /etc/nginx/sites-available create a file by the domainname to be hosted. So I added /etc/nginx/sites-available/acemoney.in. In /etc/nginx/sites-enabled create a symbolic link to this file.

ln -s /etc/nginx/sites-available/acemoney.in /etc/nginx/sites-enabled/acemoney.in 

Now add the contents in /etc/nginx/sites-available/acemoney.in This is the key configuration to hook up nginx with thin.

upstream thin {
     server 127.0.0.1:3000;
     server 127.0.0.1:3001;
     server 127.0.0.1:3002;
}

server {
    listen 80;
    server_name acemoney.in;

    root /home/josh/current/public;

    location / {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header Host $http_host;
      proxy_redirect false;

      if (-f $request_filename/index.html) {
        rewrite (.*) $1/index.html break;
      }
      if (-f $request_filename.html) {
        rewrite (.*) $1.html break;
      }
      if (!-f $request_filename) {
        proxy_pass http://thin;
        break;
      }
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
      root html;
    }
}

To analyze this configuration, here are some details:

The following lines tell nginx to listen on port 80 for HTTP requests to acemoney.in. The ‘root’ is the public directory for our rails app deployed at /home/josh/current!

server {
    listen 80;
    server_name acemoney.in;

    root /home/josh/current/public;

Now, nginx will try to process all HTTP requests and try to give the response.. for static HTML’s it will automatically give the data from the ‘root’. If it cannot find the HTML file, it will ‘proxy_pass’ it to thin. “thin” in the code below is an ‘upstream’ directive that tells nginx where to forward the current request it cannot directly serve.

if (!-f $request_filename) {
        proxy_pass http://thin;
        break;
      }

The upstream code is where load-balancing plays a role in nginx. The following code tells nginx which all processes are running on which different ports and it forwards requests to any of the servers based on its internal load balancing algorithm. The servers can be on different machines (i.e. different IP addresses) if needed. In AceMoney, we have started 3 thin servers on 3 different ports!

upstream thin {
     server 127.0.0.1:3000;
     server 127.0.0.1:3001;
     server 127.0.0.1:3002;
}

Performance Statistics Nothing is complete without them. Here is what I found out for 3 thin servers and 1 ferret_server.

top - 14:06:10 up 7 days, 22:58,  2 users,  load average: 0.00, 0.00, 0.00
Tasks:  84 total,   1 running,  83 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    553176k total,   530868k used,    22308k free,    16196k buffers
Swap:   524280k total,     2520k used,   521760k free,    87280k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
12424 mysql     18   0  127m  42m 5520 S    0  7.9   0:23.01 mysqld
18338 root      15   0 77572  70m 4392 S    0 13.1   0:06.79 thin
18348 root      15   0 71176  64m 4388 S    0 11.9   0:06.51 thin
18343 root      15   0 68964  62m 4384 S    0 11.5   0:07.20 thin
18375 root      18   0 70912  54m 2660 S    0 10.0   2:34.24 ruby
 8141 www-data  15   0  5176 1736  820 S    0  0.3   0:00.07 nginx
 8142 www-data  15   0  5176 1724  816 S    0  0.3   0:00.01 nginx
 8144 www-data  15   0  5152 1720  816 S    0  0.3   0:00.06 nginx
 8143 www-data  15   0  5156 1656  784 S    0  0.3   0:00.00 nginx

As can be seen:

• Each thin server takes around 70M
• The Mysql server takes 41M
• Ruby process (18375 above) is the ferret_serve which takes 54M
• 4 nginx threads take about 1.7K in memory.

 Overall: (3 thin server cluster + Mysql + ferret): 300MB

虽然AWStats现在已经支持输出静态网页形式的分析结果，但是页面布局没有用Perl生成的动态网页方便，而且用自带的用Perl编写的转换工具稍微有点慢，在流量不大的情况下，还是在Perl+Fast CGI上运行更舒服一些。

首先要参考之前的文章，建立好PERL+FCGI的运行环境，这步准备工作就够费劲的。

然后开始切入正题：

1. 下载最新版的AWStats，基本就是Perl包，所以没必要用apt-get，解压缩到/usr/local/awstats下

wget http://prdownloads.sourceforge.net/awstats/awstats-6.95.tar.gz
tar -xzf awstats-6.95.tar.gz
mv awstats-6.95 /usr/local/awstats

2. 创建一个存放awstats分析数据的目录
mkdir /var/lib/awstats
chown www-data /var/lib/awstats  //这是为了让awstats页面上能直接刷新最新数据

3. 自动配置awstats

cd /usr/local/awstats/tools
perl awstats_configure.pl

除了第一步因为是Ngin服务器的关系，所以要选none，其他基本按照提示选默认值

4. 手工编辑配置文件

1) 修改LogFile路径

LogFile = “/var/log/nginx/access.log”

如果是压缩格式的日志，可以用LogFile = “zcat /var/log/nginx/%YYYY-24%MM-24%DD-24.gz|"。这里用zcat是因为其使用管道输出，对系统资源消耗比较小，千万不要忘了最后的管道操作符！


假设原来/etc/nginx/nginx.conf中关于log部分是如此定义的：（要小变量心空格，不能少，否则awstats就不认了）

log_format  main  ‘$remote_addr $remote_user [$time_local] “$request” $status ‘
‘$host $body_bytes_sent $gzip_ratio “$http_referer” ‘
‘”$http_user_agent” “$http_x_forwarded_for”‘;

很容易知道，对应awstats配置文件中，LogFormat应该设置为
LogFormat= “%host %logname %time1 %methodurl %code %host_r %bytesd  %gzipratio %refererquot %uaquot %otherquot”

最后一个选％otherquot是应为$http_x_forwarded_for在AWstats 6.95中还不认识

3) 将AllowToUpdateStatsFromBrowser=1，便于浏览器中即时刷新数据

5. 更新Awstats的分析记录，测试一下刚才的配置
/usr/local/awstats/wwwroot/cgi-bin/awstats.pl -update -config=yousite.com

如果一切正常，应该看到类似以下的结果：
Create/Update database for config “/etc/awstats/awstats.yoursite.com.conf” by AWStats version 6.95 (build 1.943)
From data in log file “/var/log/nginx/access.log”…
Phase 1 : First bypass old records, searching new record…
Searching new records from beginning of log file…
Phase 2 : Now process new records (Flush history on disk after 20000 hosts)…
Jumped lines in file: 0
Parsed lines in file: 1234
Found 0 dropped records,
Found 0 corrupted records,
Found 0 old records,
Found 1234 new qualified records.

6. 修改logrotate.d下的nginx配置文件，在每天切割日志前，更新awstats状态

/var/log/nginx/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
create 640 www-data www-data
dateext
sharedscripts
prerotate
/usr/local/awstats/wwwroot/cgi-bin/awstats.pl -update -config=yoursite.com
sleep 59
endscript
postrotate
if [ -f /var/run/nginx.pid ]; then
kill -USR1 `cat /var/run/nginx.pid`
fi
endscript
}

7. 接下来是最关键的NGINX配置，

#AWStatus Perl CGI  server
server {
listen       80;
server_name  awstats.yoursite.com;
access_log   /var/log/nginx/awstatus.log main;
root /usr/local/awstats/wwwroot;
auth_basic            “Restricted”;
auth_basic_user_file  /etc/nginx/awstatus.pass;

location = / {
rewrite ^ /awstats.pl?config=freshventure.info;
}

location ~ .*(\.cgi|\.pl?)$ {
gzip off; #gzip makes scripts feel slower since they have to complete before getting gzipped
root /usr/local/awstats/wwwroot/cgi-bin;
fastcgi_pass 127.0.0.1:8000;
fastcgi_index awstats.pl;
fastcgi_param SCRIPT_FILENAME  $document_root$fastcgi_script_name;
include        fastcgi_params;
}

}

好了，测试一下http://awstats.yoursite.com，和前文一样，输入密码后，这次看到的应该就awstats的界面了

8. 如果需要配置静态页面，则可以在logrotate中替换掉上面的awstats.pl, 换成

/usr/local/awstats/tools/awstats_buildstaticpages.pl -update -config=yoursite.com -lang=cn -dir=/usr/local/awstats/wwwroot -awstatsprog=/usr/local/awstats/wwwroot/cgi-bin/awstats.pl。

如果需要更频繁的更新访问情况，则可以把这句命令加入到crontab中，例如crontab -e -uwww-data。

然后nginx相应调整为显示静态网页就可以了

参考文章：

1. 刘辉 － awstats 配置模板 参考

2. 刘辉 － AWStats：示来访者位置 QQ纯真库IP解析插件安装

3. Jeff’s Blog – Awstats安装和设置

4. Jeff’s Blog - NGINX下运行Awstats

5. Jeff’s Blog – IP地址数据库的自动更新

6. 使用 awstats 分析 Nginx 的访问日志

今后拓展阅读

1. 车东 － AWStats的千万级日志解决方案

1.安装Perl
如果系统的没有的话, apt-get install perl
2.安装Perl的FCGI模块和FCGI进程管理模块
第一次运行-e的shell是，会问一堆关于config.pm的问题。
基本上一路回车，选默认值，当然在选择CSPAN镜像的时候，要挑离服务器近的位置

perl -MCPAN -e ‘install FCGI’
perl -MCPAN -e ‘install FCGI::ProcManager’

3. 创建Perl-fcgi.pl文件，作为Perl-FCGI的分配器(Wrapper）

j网上通常的教程都是参考NGINX SimpleCGI上的设置，其中有一个问题就是cgi-wrapper生成的socket文件可能对www-data是无权操作的，我更喜欢和PHP设置成为一样的TCP/IP Socket, 所以要该以下几个地方：

$socket = FCGI::OpenSocket( “127.0.0.1:8000“, 10 ); #use IP sockets

注释掉 #$socket = FCGI::OpenSocket( “/var/run/nginx/perl_cgi-dispatch.sock”,

$proc_manager = FCGI::ProcManager->new( {n_processes => 3 } ); ＃把进程改为3，节省资源，反正只是为了AWStats用

把文件名改为perl-fcgi.pl, chmod +x perl-fcgi.pl， 并将其复制或移动到/usr/bin/下。

试着运行一下，用 perl-fcgi.pl >/dev/null 2>$1 &
第一个参数表示stdout重定向到空设备，不在屏幕上显示
第二个参数表示stderr重定向到设备1，也就是刚才的空设备，不在屏幕上显示
第三个参数表示该进程作为Daemon独立运行，脱离Dash

如果OK的化，用htops可以看到perl-fcgi-pm主进程以及3个perl-fcgi子进程。另外用netstat -tnlp可以看到端口127.0.0.1:8000正在被perl-fcgi-pm监听。不过以root运行并不安全，在启动脚本要以www-data身份运行

4. 创建Perl-FCGI的启动脚本

编辑启动脚本perlfcgi.sh, 然后在/etc/rc.local中 加入/root/perlfcgi.sh

由于perl-fcgi.pl这个脚本还不完善，不能用Ubuntu自带的start-stop-daemon来启动，也不会保存PID文件，也只能简陋的

5. 编辑/etc/nging/nginx.conf，创建FCGI接口

1) 安装whois工具包，获得mkpasswd命令： apt-get install whois
因为我们想把Awstats的访问限制给网站管理员，需要让NGINX为此添加密码设置，要利用mkpasswd中附带的encrypt(3)对Password进行加密，这是NGINX 0.7.x系列唯一认识的加密方法

如果不装这个包，还有一个方法是用这里的htpasswd.py脚本，也可以达到目的

2)运行mkpasswd, 输入想要的密码后，系统为给出一个crypt(3)加密后的Code
编辑 /etc/nginx/awstatus.pass文件，
username:刚才生成的Code
chmod +r /etc/nginx/awstatus.pass 这步很重要!!，否则nginx进程无法读取该文件, 会报500错误

3）编辑/etc/nginx/nginx.conf， 添加一个CGI Server。这里需要在DNS服务器上增加一个CNAME转向awstatus.yoursite.com。 如果修改后不能立即生效的话，可以暂时修改本地host文件，一遍测试（如C:\Windows\System32\Drivers\etc\hosts, 添加一个IP记录）

#AWStatus Perl CGI  server
server {
listen       80;
server_name awstats.yoursite.com;
root /var/www/yoursite;
auth_basic            “Restricted”;
auth_basic_user_file  /etc/nginx/awstatus.pass;

location / {
index index.cgi;
}

location ~ .*(\.cgi|\.pl?)$ {
gzip off; #gzip makes scripts feel slower since they have to complete before getting gzipped
fastcgi_pass 127.0.0.1:8000;
fastcgi_index index.cgi;
fastcgi_param SCRIPT_FILENAME  $document_root$fastcgi_script_name;
include        fastcgi_params;
}

}

重新加载NGINX服务，/etc/init.d/nginx reload

然后在http的根目录下，建立一个index.cgi， 包含

#!/usr/bin/perl

print “Content-type: text/html\n\n”;
print “<html><body>Hello, world.</body></html>”;

chmod +x index.cgi
然后用浏览器访问http://awstatus.yoursite.com/index.cgi， 输入完刚才的密码后应该能看到Hello,world.

其实也很简单，添加以下到/etc/fail2ban/filter.d/nginx-auth.conf就可以了

failregex = no user/password.*client\: <HOST>
user.*authentication failure.*client\: <HOST>
user.*not found.*client\: <HOST>
user.*password mismatch.*client\: <HOST>

fail2ban自身有一个很方便的正则表达式测试工具：

fail2ban-regex  /var/log/nginx/error.log /etc/fail2ban/filter.d/nginx-auth.conf

可以看到究竟命中了多少条记录。

fail2ban比Denyhost等强的地方就在于可以方便的添加filter, 对不同类型服务进行设置，而不是仅仅限于SSH登录

Update 1: Retest data (using different machine and Erlang kernel polling) added near bottom of post.

Update 2: More details and testing on the weird MochiWeb kernel polling results, bottom of post.

Almost a year ago I did some Apache and Nginx performance testing. Apparently I have the bug again and have done some performance testing on Nginx, Yaws and MochiWeb. The latter two being Erlang based. Again deathmatch may be an overstatement but this is my attempt at gleaning some interesting performance data from some high performance web servers. Also, I attempted to improve the graphs this time around since they were a bit hard to read the last time.

The Setup:

I was not able to use the same server and setup as the last time, so comparing between this and my last deathmatch probably isn’t very accurate. For this test I used a Intel Dual Core 2.2GHz, 4GB RAM machine running Ubuntu 8.10 (64bit) and for the test server. Erlang (R12B-3), Yaws (1.77) and Nginx (0.6.32) are installed from the standard repository and mochiweb from subversion (rev 88). All are using the default configurations outside of adjusting listening port numbers. The test is again against a basic robots.txt file. The tests were done using a consumer grade 100mb switch and all tests originated from an old laptop I had laying around. I think that about covers the test bed, if you have any questions let me know.

For the tests I used autobench (httperf under the hood) with the following command, each test ran ten minutes apart. The order of the tests were done in was MochiWeb then Yaws and lastly Nginx.

autobench –single_host –host1 HOST –port1 PORT –uri1 /robots.txt –low_rate 10 –high_rate 200 –rate_step 10 –num_call 10 –num_conn 5000 –timeout 5 –file SERVER-results-`date +%F-%H:%M:%S`.ts

Read the rest of this entry »

 

http://www.joeandmotorboat.com/2009/01/03/nginx-vs-yaws-vs-mochiweb-web-server-performance-deathmatch-part-2/

 

Acemoney is a hosted application built by us i.e. Josh Software. Currently, its hosted on a linode with nginx+thin configured. The problem here is that there are 3 thin servers which consume humongous ’stagnant’ memory. We have decided to migrate to nginx+passenger so that we an control in greater detail the number of instances, the memory and the performance.

Some things in the post are specific to Josh Software and its client. Overall, this should give a good clean idea about migrating to passenger.

1. Checkout from the branch from the respository (the 2.3.4 version)

2. Ensure  Rails 2.3.4 is installed

3. Edit the nginx configuration. /opt/nginx/conf/servers/acemoney.in

server {

 listen 80;
 server_name acemoney.in;
 passenger_enabled on;
 root <path-to-deployment>/acemoney/public;
}

4. Restart Nginx. In case you get an error — something like:

2009/10/27 16:02:07 [error] 32685#0: *9 directory index of
"/home/gautam/deployment/acemoney/public/" is forbidden, client: 121.247.65.47,
server: acemoney.in, request: "GET / HTTP/1.1", host: "acemoney.in"

Check syntax in the conf file (I had forgotten a ‘;’) OR check permissions of the root directory to see if you have given r+x permissions

5. The current gem setup was:

$:/opt/nginx/conf/servers$ sudo gem search

*** LOCAL GEMS ***

abstract (1.0.0)
actionmailer (2.3.4, 2.3.3, 2.2.2, 2.1.2)
actionpack (2.3.4, 2.3.3, 2.2.2, 2.1.2)
activerecord (2.3.4, 2.3.3, 2.2.2, 2.1.2)
activeresource (2.3.4, 2.3.3, 2.2.2, 2.1.2)
activesupport (2.3.4, 2.3.3, 2.2.2, 2.1.2)
capistrano (2.5.5)
cgi_multipart_eof_fix (2.5.0)
chronic (0.2.3)
contacts (1.0.13)
daemons (1.0.10)
engineyard-eycap (0.4.7)
erubis (2.6.4)
eventmachine (0.12.6)
fastthread (1.0.7)
gem_plugin (0.2.3)
heywatch (0.0.1)
highline (1.5.0)
hoe (1.12.2)
json (1.1.6)
memcache-client (1.7.2)
mislav-will_paginate (2.3.10)
mongrel (1.1.5)
mongrel_cluster (1.0.5)
mysql (2.7)
net-scp (1.0.2)
net-sftp (2.0.2)
net-ssh (2.0.11)
net-ssh-gateway (1.0.1)
packet (0.1.15)
passenger (2.2.5)
rack (1.0.0, 0.9.1)
rails (2.3.4, 2.3.3, 2.2.2, 2.1.2)
rake (0.8.4)
RedCloth (4.1.9)
right_aws (1.10.0)
right_http_connection (1.2.4)
rubyforge (1.0.3)
rubyist-aasm (2.0.5)
thin (1.0.0)
tidy (1.1.2)
xml-simple (1.0.12)

So, I had to add the following gems:

$ sudo gem install acts_as_reportable

This added the following dependencies:

Successfully installed fastercsv-1.2.3
Successfully installed archive-tar-minitar-0.5.2
Successfully installed color-1.4.0
Successfully installed transaction-simple-1.4.0
Successfully installed pdf-writer-1.1.8
Successfully installed ruport-1.6.1
Successfully installed acts_as_reportable-1.1.1
Successfully installed json_pure-1.1.9
Successfully installed rubyforge-2.0.3
Successfully installed rake-0.8.7

$ sudo gem install prawn
$ sudo gem install ferret
$ sudo gem install acts_as_ferret

6. Then I got the latest database dump from Acemoney server and configured the database locally. Edit the config/database.yml and the following:

production:
  adapter: mysql
  user: acemoney
  password: <password>
  host: localhost

Created a new user in mysql and granted ALL  permissions to acemoney database

mysql> grant all on acemoney.* to 'acemoney'@'localhost' identified by '<password>'

Then create the database and dump the contents from the backup

$ RAILS_ENV=production rake db:create
$ mysql -uacemoney acemoney -p < <backupfile>

Start the ferret_server

$ ./script/ferret_server -eproduction start

Build the index:

$ RAILS_ENV=production rake ace:rebuildFerretIndex

NOW, we are good to go. Make some local changes in /etc/hosts file on your machine to point acemoney.in to the linode IP address. Then http://acemoney.in should take you to the hosted application on nginx+passenger.

1. VSFTPD

vi /etc/vsftpd.conf

xferlog_file=/var/log/vsftpd/vsftpd.log #调整一下目录存放位置，让/var/log下稍微清晰一些

vi /etc/logrotate.d/vsftpd
修改日志存放目录
/var/log/vsftpd/vsftpd.log

logrotate -d /etc/logrotate.d/vsftpd 测试一下

没问题的话，重启ftp服务

/etc/init.d/vsftpd restart

2. fail2ban

vi /etc/fail2ban/fail2ban.conf

logtarget = /var/log/fail2ban.log

vi /etc/logrotate.d/fail2ban
修改日志存放目录
/var/log/fail2ban/fail2ban.log

logrotate -d /etc/logrotate.d/fail2ban 测试一下

vi /etc/fail2ban/jail.local
logpath = var/log/vsftpd/vsftpd.log

/etc/init.d/fail2ban restart

3. NGINX

编辑 /etc/logrotate.d/nginx

/var/log/nginx/*.log {
daily
missingok
rotate 7
compress
delaycompress
notifempty
create 640 www-data www-data
dateext
sharedscripts
prerotate
sleep 59
endscript
postrotate
if [ -f /var/run/nginx.pid ]; then
kill -USR1 `cat /var/run/nginx.pid`
fi
endscript
}

含义是：

每天执行，日志文件不存在不报错，最多保留365天，用GZip压缩, 延后压缩，无文件不压缩， 文件后加时间戳。

logrotate -d /etc/logrotate.d/nginx 测试一下

没问题的话，重启服务: /etc/init.d/nginx reload

4. 可选：调整logrotate的运行时间

编辑/etc/cron.daily, 把其中的logrotate的时间提前到5：27或更早一点，以便CPU时间可以合理分配

参考文章：
1. Nginx日志切割脚本
2. nginx 使用 logrotate 回滚日志
3. nginx日志管理

1. top命令查看使用CPU最高的进程，还有进阶版htop。通常需要安装：sudo apt-get install htop

2. 更改php.ini和nginx.conf配置文件后，用/etc/init.d/fp-php reload 和/etc/init.d/nginx reload重启服务。
只要没有添加、更改模块，不用restart参数。重启更平滑

3. iptables -L -v 可以查看当前防火墙的详细配置， iptables -L可以看个简化版的

4. fail2ban-client status ssh 或者fail2ban-client status vsftpd可以查看IP封禁状况

5. netstat -tap 可以查看当前开启的端口，如果memcache成功启动的话，就可以在这里看到

I’ve been using Mono ASP.Net for a while with Nginx as the server. I recently started playing around with ASP.Net MVC and discovered that it doesn’t play nice when using Nginx as the server. To make ASP.Net work with Mono and Nginx you need to download the Mono source from here. And then modify the file mcs/class/System.Web.Routing/System.Web.Routing/Route.cs
in particular comment out the following lines in the GetRouteData function

if (pathInfo != String.Empty)
throw new NotImplementedException();

If you comment out the above two lines your MVC website should work just fine when hosting it using Mono and Nginx. I don’t know if there are any negative consequences for commenting out the above two lines but I have not encountered any.