Lançado MySQL Workbench 5.1.2 Alpha para Linux

Tags: , — September 27, 2008 @ 10:42 am

mysql-workbenchFinalmente foi lançada uma versão Alpha do MySQL Workbench para Linux, depois de quase dois anos após a versão antiga ficar disponível apenas para Windows.

Para quem não sabe, o MySQL Workbench é o sucessor do antigo DBDesigner4, um editor visual de modelo de dados, criado inicialmente para MySQL, com possibilidade de criar o modelo de dados por engenharia reversa e exportar DDL.

Segue um screenshot do DBDesigner4:

DBDesigner4

A pouco mais de um ano atrás, o MySQL Workbench era incluído no macote mysql-gui-tools para linux e, inclusive, disponível no Debian. Porém o software era por demais instável e continha muitos bugs, assim ele foi removido dos repositórios do Debian e, posteriormente descontinuado, passando a ser disponível apenas a versão Windows.

Possivelmente a maior parte do código do antigo Workbench foi reescrito, e desde a versão beta para windows lançada em Novembro passado, nós usuários Linux temos estado ansiosos para ter a nova ferramente disponível no Linux (e logo para Mac OSX também).

Particularmente falando, minha primeira experiência com o MySQL Workbench foi decepcionante, isso por causa da quantidade de bugs e falta de funcionalidadesque a versão antiga continha. Porém, o antigo DBDesigner era uma ferramenta ótima, que tornava muito mais fácil a criação e visualização de modelos de dados, assim, sempre esperei que o MySQL Workbench viesse a ser tão bom, ou até melhor que seu predecessor.

Naturalmente, vou postar aqui como obter os fontes e instalar o MySQL Workbench 5.1.2 Alpha. Há também um pacote *.deb disponível para ubuntu, mas vou abordar apenas a instalação via fontes.

Primeiramente, será necessário instalar algumas dependências:

# aptitude install \
autoconf \
automake \
libtool \
libzip-dev \
libxml2-dev \
libsigc++-2.0-dev \
libglade2-dev \
libgtkmm-2.4-dev \
libglu1-mesa-dev \
libmysqlclient15-dev \
uuid-dev \
liblua5.1-dev \
libpixman-1-dev \
libpcre3-dev \
g++ \
libgnome2-dev \
libgtk2.0-dev \
libpango1.0-dev \
libcairo2-dev

Também será necessário instalar anteriormente a biblioteca ctemplate, do Google.

$ wget ftp://ftp.mysql.com/pub/mysql/download/gui-tools/mysql-workbench-5.1.2-alpha-linux.tar.gz
$ tar xzvf ctemplate-0.91.tar.gz
$ cd ctemplate-0.91/
$ ./configure --prefix=/usr/local
$ make
# make install (como root)
# ldconfig

Após instalada a biblioteca, vamos compilar e instalar o MySQL Workbench. Os fontes da primeira versão Alpha para Linux podem ser encontrados aqui:

$ wget ftp://ftp.mysql.com/pub/mysql/download/gui-tools/mysql-workbench-5.1.2-alpha-linux.tar.gz
$ tar xzvf mysql-workbench-5.1.2-alpha-linux.tar.gz
$ cd mysql-workbench-5.1.2-alpha-linux/
$ ./autogen.sh --prefix=/usr/local
$ make
# make install (como root)

Após isto a instalação estará concluída, bastando executar mysql-workbench em um terminal para testar o software.

$ mysql-workbench

MySQL Workbench first screen MySQL Workbench EER view

Fontes: http://br-linux.org/2008/lancado-o-alpha-do-mysql-workbench-para-linux/,
http://dev.mysql.com/workbench/?page_id=152,
http://dev.mysql.com/workbench/?p=156

Se você gostou deste artigo, inscreva-se em meu RSS feed!

Enlightenment DR17 movido para Subversion

Tags: — September 22, 2008 @ 4:53 pm

Recentemente, (em 18 de Agosto, pra ser exato) o Projeto Enlightenment migrou de CVS para Subversion. Assim estou postando um novo tutorial para a instalação a partir dos fontes por SVN.

O principal motivo para a migração para Subversion, segundo discussões no canal #E no Freenode, seria  integração com Trac, um sistema de gerenciamento de projetos e bugtracking online. Assim, a página do projeto E17, incluindo wiki e lista de bugs, agora encontra-se em http://trac.enlightenment.org/e/, e o repositório subversion em http://svn.enlightenment.org/.

Primeiramente, veja meu tutorial anterior sobre como instalar o Enightenment via CVS, para instalar as dependências necessárias no Debian.

Você precisará também, obviamente, ter o subversion instalado:

# aptitude install subversion

Após instaladas as dependências e subversion, basta obter os fontes com o comando svn co:

[updated] Adicionada biblioteca eina

$ svn co http://svn.enlightenment.org/svn/e/trunk/eina eina
$ svn co http://svn.enlightenment.org/svn/e/trunk/eet eet
$ svn co http://svn.enlightenment.org/svn/e/trunk/evas evas
$ svn co http://svn.enlightenment.org/svn/e/trunk/ecore ecore
$ svn co http://svn.enlightenment.org/svn/e/trunk/efreet efreet
$ svn co http://svn.enlightenment.org/svn/e/trunk/embryo embryo
$ svn co http://svn.enlightenment.org/svn/e/trunk/edje edje
$ svn co http://svn.enlightenment.org/svn/e/trunk/e_dbus e_dbus
$ svn co http://svn.enlightenment.org/svn/e/trunk/e e17

Após concluído o checkout (a cópia dos fontes), basta entrar em cada um dos diretórios na seguinte ordem:

ordem de diretórios a seguir:

eina
eet
evas
ecore
efreet
embryo
edje
e_dbus

…e executar os seguintes comandos para compilar e instalar as bibliotecas EFL:

$ ./autogen.sh
$ make
# make install (como root)

Após a instalação das bibliotecas, entre no diretório e17 e execute os mesmos comandos acima:

$ cd e17
$ ./autogen.sh
$ make
# make install (como root)

Com isto você terá concluído a instalação do E17.

Dicas e Resolução de problemas

Caso tenha problemas na compilação do e17 após concluídas as instalações das bibliotecas, indicando que algumas dependências não foram encontradas, edite o arquivo /etc/ld.so.conf e adicione “/usr/local/lib” (sem as aspas) no final deste. Então execute ldconfig, como usuário root, e tente compilar novamente. NOTA: pode ser necessário executar o ldconfig durante as instalações das bibliotecas também.

Para adicionar o E17 nas sessões do GDM, edite o arquivo “/etc/gdm/gdm.conf” e adicione “:/usr/local/share/xsessions/” (sem as aspas) a linha com o parâmetro “SessionDesktopDir” na sessão “daemon“. O arquivo deverá ficar mais ou menos assim, mais ou menos entre as linhas 40 a 46:

[daemon]
RemoteGreeter=/usr/lib/gdm/gdmgreeter
SessionDesktopDir=/usr/share/gdm/BuiltInSessions/:/usr/share/xsessions/:/usr/local/share/xsessions/

AlwaysLoginCurrentSession=false

Para atualizar a instalaçãodo E17, posteriormente, basta entrar em cada um dos diretórios acima, na mesma ordem, e executar os comandos:

$ make clean
$ svn up
$ ./autogen.sh
$ make
# make install (como root)

Existem alguns scripts para instalação automática do E17, como o ReasyE17, e o get_e.sh. Eu fiz uma modificação neste último para não utilizar o comando sudo (a senha do root será solicitada antes de cada make install) e não instalar as dependências, garantindo compatibilidade com outras distros não baseadas no Debian (assim você precisará instalar as dependências antes, com apt-get, aptitude, yum, pacman, ou seja qual for o gerenciador de pacotes que sua distro utilize). Para utilizá-lo, apenas faça download do arquivo abaixo e execute “sh get_e.sh” em um terminal.

Script get_e.sh modificado [updated]

Se você gostou deste artigo, inscreva-se em meu RSS feed!

LightTPD + PHP5 no Debian (Part 2: mod_evhost)

Tags: , — September 13, 2008 @ 3:46 pm

Continando com os tutoriais para instalação e uso do LightTPD, vou mostrar agora como utilizar os módulos para User Directories e Virtual Hosts.

Para quem está acostumado com o Apache, o mod_userdir não se diferencia muito, simplesmente criando um Document Root na $HOME de cada usuário que pode ser acessado por http://hostname/~username. Já os Virtual Hosts tem uma sintaxe completamente diferente e, pelo meu ponto de vista (embora eu não tenha estudado os vhosts do Apache muito a fundo), bem mais flexível.

Habilitando o mod_userdir.

A instalação padrão do LightTPD no Debian (# aptitude install lighttpd) já vem com os principais módulos, incluindo o mod_userdir, e também cria um arquivo de configuração para este em /etc/lighttpd/conf-avaiable/. Assim, só o que precisamos é criar um link simbólico para /etc/lighttpd/conf-enabled/:

# cd /etc/lighttpd/conf-enabled/
# ln -s ../conf-available/10-userdir.conf .

Pronto! Após isso basta reiniciar o LightTPD (/etc/init.d/lighttpd restart) e acessar os diretórios de usuários com http://hostname/~username.

Usando condições para criar Virtual Hosts

Para criar Virtual Hosts no LightTPD podemos usar diversas maneiras. A primeira seria sequer utilizando um módulo adicional, mas apenas uma condição no lighttpd.conf, quando se deseja simplesmente criar um Virtual Host para um domínio específico acessando um Document Root alternativo, o que, inclusive, é o mais comum:

$HTTP["host"] == "news.example.org" {
  server.document-root = "/var/www/servers/news2.example.org/pages/"
}

Aqui temos uma grande vantagem do LightTPD, que é a possibilidade de utilizarmos facilmente variáveis na configuração. A variável $HTTP[”host”] obtém o domínio atual que está sendo acessado no servidor e compara com a constante a seguir, se esta comparação for verdadeira, as definições dentro do bloco {} serão usadas. Os operadores de comparação que podem ser utilizados são:

==
    igualdade de strings
!=
    diferença de strings (NOT)
=~
    expressão regular estilo perl (LIKE)
!~
    diferença de expressão regular estilo perl (NOT LIKE)

No exemplo acima, quando o domínio acessado for news.example.org o Document Root usado será /var/www/servers/news2.example.org/pages/. Este seria o modo mais básico de utilizarmos diversos Document Roots, uma espécie de fake vhost.

Utitizando mod_simple_vhost

Outra maneira é utilizando o mod_simple_vhost, recomendado quando se quer agrupar os Document Roots sub um diretório específico. Para habilitar o módulo Simple VHosts, primeiramente cria um link simbólico para o arquivo de configuração, assim como fizemos com o mod_userdir:

# cd /etc/lighttpd/conf-enabled/
# ln -s ../conf-available/10-simple-vhost.conf .

Depois disso edite o arquivo *.conf.

O mod_simple_vhost utiliza três parâmetros:

  •  simple-vhost.server-root: O diretório “pai” onde serão colocados os Document Root. Em nosso exemplo usaremos /var/www.
  • simple-vhost.document-root: O subdiretório que conterá os arquivos HTML, sendo o Document Root de cada VHost. Em nosso exemplo usaremos html/.
  • simple-vhost.default-host: O Virtual Host padrão, utilizado quando não é enviado nenhum domínio (ao acessar o endereço IP do servidor, por exemplo.
## The document root of a virtual host isdocument-root =
## simple-vhost.server-root + $HTTP["host"] + simple-vhost.document-root
simple-vhost.server-root         = "/var/www"
simple-vhost.document-root       = "/html/"
 
## the default host if no host is sent
simple-vhost.default-host        = "localhost"

O mod_simple_vhost procurará pelos doc_root usando o formato simple-vhost.server-root + domínio + simple-vhost.document-root. Assim, se o domínio acessado no servidor for example.org o Document Root utilizado será /var/www/example.org/html.

Utilizar o módulo Simple Virtual Hosts ou apenas condições vai depender de sua necessidade. Em geral, se for necessário apenas adicionarou um dois Document Roots alternativos utilizar condições pode ser mais simples, além de ser um módulo a menos para carregar no servidor (menos recursosnecessários), já no caso de um servidor que hospede diversos web sites de um mesmo proprietário, o módulo Simple Virtual Hosts poderá ser a melhor solução.

Porém, pode ser necessário, em alguns casos, utilizar-se diversos Virtual Hosts com Document Roots utilizando padrões diferentes, como VHosts específicos para usuários ou domínios, por exemplo. Para estes casos, podemos utilizar o módulo Enhanced Virtual-Hosting.

Utilizando mod_evhost

Diferente dos módulos anteriores, a instalação do Debian não cria um arquivo de configuração para o mod_evhost. Assim temos duas opções: Descomentar a linha que carrega o mod_evhost na seção server.modules() do arquivo /etc/lighttpd/lighttpd.conf e adicionar as configurações desejadas no final deste arquivo, ou criar um arquivo de configuração adicional.

Eu prefiro criar o arquivo adicional com luink simbólico, visto que fica mais fácil habilitar/desabilitara configuração rapidamente:

# touch /etc/lighttpd/conf-available/11-evhost.conf
# cd /etc/lighttpd/conf-enabled/
# ln -s ../conf-available/11-evhost.conf

Note que criei o arquivo com o nome 11-evhost.conf. O número (11) a esquerda do nome do arquivo é um modo de definir a ordem que os arquivos de configuração serão incluídos. Após cria-lo edite o arquivo com suas configurações desejadas, lembrando de colocar a seguinte linha para carregar o módulo EVhost:

server.modules += ("mod_evhost")

O mod_evhost contrói o Document Root baseado em um padrão contendo os caracteres curingas a seguir:

%% => Caractere '%'
%0 => Nome do domínio, com sufixo (.com, .org, ...)
%1 => Sufixo do dompinio (.com, .org, ...)
%2 => Nome do domínio sem sufixo
%3 => Primeiro subdomínio
%4 => Segundo subdomínio

Assim, utilizamos estes caracteres para configurar o Document Root, baseado no domínio acessado, adicionando o padrão ao parâmetro evhost.path-pattern.

evhost.path-pattern = "/var/www/%0/html/"

O exemplo acima, terá o mesmo efeito do nosso exemplo anterior utilizando o mod_simple_vhost.

Tanto o mod_simple_vhost como o mod_evhost podem ser utilizados em conjunto com condições, assim podemos criar um Virtual Host para cada usuário, acessando o diretório public_html dentro de sua $HOME como Document Root, por exemplo, ou seja, criando um vhost para cada userdir existente:

## load evhost module
server.modules += ("mod_evhost")
 
## enable per user public_html dir to be accessed by
## http://username.example.org
$HTTP["host"] =~ "\.example\.org" {
    evhost.path-pattern = "/home/%3/public_html/"
}

Assim, quando alguém acessar http://samuraidio.example.org, o Document Root usado será /home/samuraidio/public_html.

Fonte: http://trac.lighttpd.net/trac/wiki/Docs

Se você gostou deste artigo, inscreva-se em meu RSS feed!

Compilando Chromium (ou Google Chrome) no Linux

Tags: , , — September 11, 2008 @ 4:13 pm

Com o lançamento beta do navegador web Google Chrome, obviamente eu também fiquei animado e ansioso para testar o novo “brinquedinho”.

Vou mostrar aqui como compilar o Chromium, o projeto no qual é baseado o Google Chrome, no Debian GNU/Linux e rodar os unit tests que vêm com ele. Note que não existe ainda um navegador Chromium para Linux, tudo o que temos são alguns comandos de terminal usados para testar alguns móduilos, ou seja, este tutorial será exclusivamente destinado a desenvolvedores (principalmente C/C++) e pessoas curiosas.

Nota: Ainda não existe uma versão funcional de navegador baseado no Chromium para Linux. Porém, vários sub-módulos podem ser compilados no Linux, mas tudo o que se obtém é um comando executável que retorna “all tests pass”. ”

Se você deseja instalar um navegador baseado no Chromium funcional, procure por um dos vários tutoriais de instalação do Google Chrome no Wine.

Primeiramente, você precisará instalar as seguintes dependencias:

  • Subversion >= 1.4
  • pkg-config >= 0.20
  • Python >= 2.4
  • Perl >= 5.x
  • gcc/g++ >= 4.2
  • bison >= 2.3
  • flex >= 2.5.34
  • gperf >= 3.0.3
  • libnss3-dev >= 3.12

No Debian e distribuições derivadas dele (como o Ubuntu) basta instalar tudo com o apt-get / aptitude:

# aptitude install subversion \
    pkg-config \
    python \
    perl \
    g++ \
    bison \
    flex \
    gperf \
    libnss3-dev

Após instalar as dependências, escolha um diretório para colocar os fontes e compilar. Vou considerar que o diretório escolhido seja $HOME/chromium. Primeiramente crie o diretório e mude para ele:

$ mkdir $HOME/chromium
$ cd $HOME/chromium

Então obtenha o depot tools usando o comando svn:

$ svn co http://src.chromium.org/svn/trunk/depot_tools/linux depot_tools

Como alternativa, você pode baixar o depot tools em tar.gz.

Depois disso mude seus locales para “C” (necessário devido a um bug temporário nos scripts gclient, que interpretam a saída do subversion), e execute ./depot_tools/gclient config:

$ export LANG=C
$ export LANGUAGE=C
$ export LC_ALL=C
$ ./depot_tools/gclient config http://src.chromium.org/svn/trunk/src

O checkout dos arquivos via svn deve demorar algum tempo, dependendo de sua conexão. Caso esteja muito lento você pode também obtar por obter um snapshopt do SVN Checkout.

Após obter os fontes, para compilar execute:

$ cd $HOME/chromium/src/chrome
$ ../third_party/scons/scons.py Hammer

Como o projeto ainda está engatinhando, e os desenvolvedores estão “brincando” com o código, é bem comum que alguma coisa falhe nesta parte. Infelizmente será necessário um mínimo de conhecimento em C/C++ ou outras linguagens utilizadas para seguir adiante. Eu por exemplo, me deparei com alguns erros nos arquivos src/webkit/glue/webframe_impl.h e src/skia/effects/SkCullPoints.cpp, facilmente corrigidos removendo uma declaração typedef e adicionando alguns parênteses a uma condição, respectivamente. Estou postando meus DIFFs para caso alguém tenha o mesmo problema:

webframe_implh.diff
skcullpointscpp.diff

Após a compilação, executáveis criados durante o processo estarão disponíveis em $HOME/chromium/src/chrome/Hammer.

Como mencionado anteriormente, Ainda não existe uma versão funcional de navegador baseado no Chromium para Linux. A única coisa que você pode fazer no momento é executar alguns unittests:

$ cd $HOME/chromium/src/chrome
$ Hammer/base_unittests
$ Hammer/net_unittests

Para quem tiver interesse em colaborar com os esforços para termos um navegador baseado no Chromium para linux, não deixem de acessar a página de desenvolvimento para Linux, com alguns detalhes do desenvolvimento, e uma série de bugs aguardando ajuda.

Desta vez não tem screenshot…
Bem, já que insistem… aí vai um screenshot de um unittest:

chrome_baseunittest.jpg

Fonte: http://dev.chromium.org/developers/how-tos/build-instructions-linux

Se você gostou deste artigo, inscreva-se em meu RSS feed!

Singleton Pattern no PHP 4

Tags: , — @ 12:39 am

Já sabemos como funciona o singleton pattern no PHP 5, mas devido as capacidades limitadas de POO do PHP4, não é possível se utilizar do mesmo padrão de desenvolvimento neste, mas há um pequeno truque que podemos fazer para obter o mesmo resultado.

No PHP4 não é possível termos propriedades estáticas em classes, mas ainda é possível ter variáveis estáticas dentro de funções. Assim podemos criar uma função capaz de fazer o papel do singleton ao instanciar uma classe em um objeto estático. Veja o Exemplo:

function &singleton() {
    static $obj;
 
    if (!isset($obj)) {
        //instancia a classe, caso o objeto já não exista
        $obj = new stdclass;
    }
    return $obj;
}

No exemplo, eu usei a classe padrão stdclass do PHP, mas o mesmo funciona com qualquer classe definida pelo usuário. Você pode, inclusive, utilizar um array no lugar da variável $obj para usar a mesma função singleton para instanciar ou recuperar várias classes.

Note o operador de referência ‘&’ antes do nome da função. Ele é necessário para garantir que a função sempre retorne uma referência para o objeto estático, ao invés de criar um novo objeto, e também é necessário ao se atribuir o retorno da função a uma variável . Veja um exemplo de uso da função:

$foo =& singleton(); //cria um objeto
var_dump($foo);
 
$foo->property = 'SamuraiDio'; //atribui um valor a uma propriedade
var_dump($foo);
 
$bar =& singleton(); //recupera o objeto existe (não irá criar um novo)
var_dump($bar);

A saída do código acima, será como a seguir:

object(stdClass)(0) {
}
object(stdClass)(1) {
  ["property"]=>
  string(10) "SamuraiDio"
}
object(stdClass)(1) {
  ["property"]=>
  string(10) "SamuraiDio"
}

Note que a terceira chamadas a var_dump() ainda exibe o valor da propriedade, apesar de ser de outra variável. Isso ocorre porque nossa função singleton() não instancia a classe novamente, mas sim apenas retorna uma referência para o objeto já existente. Assim temos um Singleton Pattern functional também para PHP4.

NOTA: Mesmo com a possibilidade de usar Singleton no PHP4 utiizando-se desta técnica, é altamente recomendável atualizar suas instalações para PHP5, beneficiando-se com a maior capacidade e segurança da versão.

Fontes: http://www.weberdev.com/get_example-4014.html, http://br.php.net/manual/pt_BR/language.variables.scope.php#language.variables.scope.static

Se você gostou deste artigo, inscreva-se em meu RSS feed!

LightTPD + PHP5 no Debian (Part 1: mod_fastcgi)

Tags: , , — September 7, 2008 @ 11:17 pm

Já há algum tempo tenho curiosidade de testar outros servidores http como alternativa ao nosso conhecido Apache, e um que sempre me chamou atenção é o LightTPD, com a promessa de ser mais rápido e ter um consumo bem menor de memória e recursos do sistema.

Este fim de semana resolvi finalmente me aventurar e tentar migrar do Apache para o LightTPD. Apesar de ser uma servidor web bem mais simples que o Apache, as diferenças na configuração deste podem ser uma dor de cabeça para quem está acostumado com as do Apache, principalmente em se tratando do mod_rewrite e Virtual Hosts, por isso vou separar a post em quatro partes:

  1. Instalação básica do LightTPD com mod_fastcgi e utilização com PHP5;
  2. Configuração básica de Virtual Hosts, mod_userdir, e mod_evhost, possibilitando configuraçãode virtual hosts por usuários, por exemplo;
  3. Utilização do mod_rewrite em comparação com o Apache, e configuração deste para “urls limpas” com CakePHP Framework (aplicável também para outros Frameworks e CMSs);
  4. Benchmark. Testes de performance do LightTPD em comparação com o Apache.

Começando com a Parte 1, abordada neste post.

Primeiramente instale o lighttpd, e php5-cgi, juntamente com os módulos PHP que desejar (php5-gd, php5-mysql, etc). Diferente do Apache, o Lighttpd não possui um módulo próprio para executar scripts php, assim, estes serão tratados a partir do módulo fastcgi que, na prática, é mais rápido que o apache mod_php, e não interfere em seu modo de uso.

# aptitude install lighttpd php5-cgi

Se o servidor Apache, ou outro servidor web, estiver sendo executado na porta 80, a instalação gerará um erro e ficará incompleta, pois o apt tentará iniciar o LightTPD na porta 80, que já estará sendo utilizada.

A solução para isto é parar momentaneamente o Apache (/etc/init.d/apache2 stop) , instalar o LightTPD, e alterar a sua porta, para só então reinciar o Apache (/etc/init.d/apache2 start).

Para alterar a porta utilizada pelo LightTPD, basta editar o arquivo /etc/lighttpd/lighttpd.conf e descomentar e alterar a porta, mais ou menos na linha 70: server.port = 81.

Se você não parou o servidor Apache e recebeu um erro na instalação, basta alterar a porta do lightTPD como mostrado acima, e reiniciar a instalação (basta rodar o aptitude install novamente) .

LightTPD Placeholder pageApós concluída a instalação, você deverá ver a página teste do LightTPD acessando http://127.0.0.1/ (ou http://localhost/)  no seu navegador, agora só falta ativar o suporte para PHP5.

Assim como para o Apache, a instalação padrão do LightTPD no Debian coloca as configurações do servidor web em arquivos separados. O arquivo de configuração principal do LightTPD, como já vimos, fica em /etc/lighttpd/lighttpd.conf. Configurações adicionais ficam em /etc/lighttpd/conf-available, e devem sercriados links simbólicos para estes em /etc/lighttpd/conf-enabled para que estes sejam carregados. Assim, vamos habilitar o módulo fastcgi:

# cd /etc/lighttpd/conf-enabled
# ln -s ../conf-available/10-fastcgi.conf .
#

Depois disto edite o arquivo /etc/php5/cgi/php.ini procure e altere a diretiva cgi.fix_pathinfo (linha 533, mais ou menos) de 0 para 1. Esta é uma configuração auxiliar paradar suporte as variávels PATH_INFO e PATH_TRANSLATED, que originalmente não estão disponíveis para o PHP em modo CGI (alteração necessária para alguns Frameworks, como o CakePHP, funcionarem).

Após isto basta reiniciar o LightTPD (/etc/init.d/lighttpd restart) e começar a rodar seus scripts PHP normalmente, aproveitando  o ganho de performance e a economia de memória.

Se você gostou deste artigo, inscreva-se em meu RSS feed!