Ruby on Rails

O Ruby on Rails, ou simplesmente Rails, é um meta-framework baseado na linguagem Ruby que facilita o desenvolvimento de páginas web dinâmicas. Não vou entrar em muitos detalhes sobre o framework ou sobre a parte do desenvolvimento, afinal, este não é o objetivo do livro, mas se você se interessou em desenvolver usando o framework, um bom lugar para começar é o http://www.rubyonrails.org/screencasts. A página contém alguns vídeos e apresentações com exemplos de desenvolvimento.

As páginas desenvolvidas usando o Rails podem rodar em diversas combinações de servidores web e bancos de dados. Vamos então à configuração necessária para rodá-las sobre o Apache e o MySQL.

O primeiro passo é instalar o interpretador Ruby, juntamente com o Rails e as bibliotecas relacionadas, incluindo o eruby, o rdoc e o libzlib-ruby:

# apt-get install ruby eruby rails libzlib-ruby rdoc irb rubygems

Em seguida instalamos a biblioteca libfcgi-ruby e o módulo fcgid que permite que o interpretador se comunique com o Apache:

# apt-get install libfcgi-ruby1.8 libapache2-mod-fcgid

Note que o “1.8” especifica a versão do pacote. A versão 1.8 é usada no Debian Etch, mas ela muda de acordo com a distribuição usada. Use a tecla TAB depois de digitar o “libfcgi-ruby” para ver as versões disponíveis, se for o caso.

Além do módulo fcgid (ativado automaticamente ao instalar o pacote), o Rails precisa também que os módulos include, ssl, rewrite e suexec estejam ativos na configuração do Apache. No Debian Etch, eles fazem parte do pacote principal, mas não vêm habilitados por padrão, o que pode ser feito rapidamente usando o a2enmod:

# a2enmod include
# a2enmod ssl
# a2enmod rewrite
# a2enmod suexec
# /etc/init.d/apache2 force-reload

Embora seja possível desenvolver aplicações simples em Rails sem usar um banco de dados, esta seria uma instalação capada, que não agradaria a muitos desenvolvedores. Para ter o ambiente completo, precisamos integrá-lo ao servidor MySQL, o que é feito através do módulo libmysql-ruby:

# apt-get install libmysql-ruby mysql-server

Se você ainda não tiver definido a senha de root do MySQL nos passos anteriores, aproveite para fazer isso agora:

# mysqladmin -u root password senha

Aproveite para criar uma base de dados dentro do servidor MySQL, que será usada mais tarde pela aplicação em Rails. Assim como no caso do WordPress e do phpBB, é aconselhável criar um usuário e uma base de dados separada para cada aplicativo que for rodar no servidor, mesmo que dentro do mesmo virtual host:

# mysql -u root -p <enter>

mysql> CREATE DATABASE rails1;
mysql> GRANT ALL ON rails1.* TO rails IDENTIFIED BY ‘rTk0uj03’;
mysql> FLUSH PRIVILEGES;

Com isso, a instalação do Rails está concluída. Para testar, crie um novo usuário, use o su para acessar o login criado e, dentro da pasta home, crie uma pasta para armazenar os projetos do Rails:

# adduser ruby
# su ruby
$ mkdir /home/ruby/rails

Para criar um aplicativo Rails de teste, acesse (ainda logado com o usuário criado) a pasta criada e execute o comando “rails”, seguido do nome do projeto e da opção “-d mysql” (que especifica o banco de dados que será utilizado), como em:

$ cd /home/ruby/rails
$ rails teste -d mysql

No final do processo, pressione Ctrl+D ou use o comando “exit” para encerrar a seção (e voltar a usar a conta de root). Como a pasta do projeto foi criada usando o login do usuário, falta um passo importante, que é fazer com que o usuário “www-data” seja o dono da pasta com o projeto. Para que o usuário continue podendo editar os arquivos apesar disso, ajustamos as permissões, de forma que o dono seja o usuário “www-data” e o grupo proprietário seja o grupo de mesmo nome do usuário, como em:

# chown -R www-data:ruby /home/ruby/rails

Como o usuário “ruby” faz parte do grupo “ruby”, ele continua sendo, indiretamente, o proprietário da pasta, através do grupo. Falta agora fazer com que o grupo tenha permissão para alterar o conteúdo da pasta, de forma que o usuário possa alterar os arquivos:

# chmod -R g+rw /home/ruby/rails

Note que usei o “-R” em ambos os comandos, de forma que as alterações sejam aplicadas de forma recursiva.

Com isso, o novo projeto está criado, falta apenas criar um virtual host no Apache apontando para a pasta, de forma que ele fique disponível para a web.

Ao criar o projeto “teste” dentro da pasta “/home/ruby/rails”, será criada a pasta “/home/ruby/rails/teste”, contendo os arquivos do projeto (veja que é possível criar vários projetos, cada um com sua própria pasta). Dentro dela, será criada a pasta “public”, que contém os arquivos que devem ser compartilhados. Os arquivos dentro dessa pasta devem ser configurados com permissão de leitura para todo mundo (o default na maioria das distribuições), de forma que o usuário “www-data”, usado pelo Apache, não tenha problema para lê-los ao exibir as páginas.

Para que o Rails funcione corretamente, é necessário que seja usada a opção “Options ExecCGI FollowSymLinks” na configuração do virtual host, de forma que a configuração seria:

<Virtualhost *:80>
ServerName rails.site.com.br
DocumentRoot /home/ruby/rails/teste/public
<Directory /home/ruby/rails/teste/public>
Options ExecCGI FollowSymLinks
AllowOverride all
Order allow,deny
Allow from all
</Directory>
</Virtualhost>

Como vimos anteriormente, nas distribuições derivadas do Debian a configuração do virtual host vai em um arquivo dentro da pasta “/etc/apache2/sites-available” e, depois de criada, é ativada usando o comando “a2ensite”, como em:

# a2ensite rails
# /etc/init.d/apache2 reload

Com tudo configurado, ao acessar o endereço do site você verá uma página de apresentação do Rails. A partir daí, o próximo passo seria editar o arquivo config/database.yml dentro da pasta do projeto, incluindo a base de dados, usuário e senha do MySQL e começar a desenvolver.

Ao criar um subdomínio dentro do site principal, como em “rails.gdhpress.com.br”, é necessário também atualizar a configuração do servidor DNS, como veremos em detalhes no capítulo sobre o Bind.

Concluindo, ao usar o Rails em um servidor com vários usuários, é importante checar as permissões de acesso dos arquivos, sobretudo as permissões do arquivo “config/database.yml” (dentro da pasta do projeto) que contém as senhas do banco de dados, de forma que um usuário não possa ver as senhas dos outros.

Se você criou todos os projetos usando usuários separados e ajustou as permissões de forma que o usuário www-data seja o dono da pasta e os usuários tenham acesso aos arquivos através do grupo (como vimos anteriormente), uma forma simples de impedir que um usuário leia os arquivos nas pastas dos demais é usar o comando “chmod -R o-r” para remover as permissões de leitura das pastas dos projetos para os demais usuários, como em:

# chmod -R o-r /home/ruby/rails