Instalando o MySQL

O MySQL é um banco de dados extremamente versátil, usado para os mais diversos fins. Você pode acessar o banco de dados a partir de um script em PHP, através de um aplicativo desenvolvido em C ou C++, ou praticamente qualquer outra linguagem (até mesmo através de um Shell Script! :).

Existem vários livros publicados sobre ele, por isso vou me limitar a falar sobre a instalação e a configuração necessária para utilizá-lo em um servidor LAMP, em conjunto com o Apache e o PHP.

O primeiro passo é instalar o servidor MySQL propriamente dito:

# apt-get install mysql-server ou # yum install mysql-server

Você pode instalar também os pacotes "mysql-client" (o cliente que permite acessar os dados e fazer modificações no banco de dados) e o "mysql-navigator" (uma interface gráfica para ele).

Antes de iniciar o serviço, rode o comando "mysql_install_db", que cria a base de dados "mysql", usada para armazenar informações sobre todas as outras criadas posteriormente, e uma base chamada "test", que pode ser usada para testar o servidor:

# mysql_install_db

O passo seguinte é ativar o servidor:

# /etc/init.d/mysql start

No caso do Fedora, o serviço se chama "mysqld", ao invés de simplesmente "mysql", como no Debian:

# service mysqld start

O MySQL possui um usuário padrão chamado "root", que, assim como o root do sistema, tem acesso completo a todas as bases de dados e é usado para fazer a configuração inicial do sistema, assim como tarefas de manutenção. Esta conta inicialmente não tem senha, por isso você deve definir uma logo depois de iniciar o serviço, usando o comando "mysqladmin -u root password senha", incluindo a senha desejada diretamente no comando, como em:

# mysqladmin -u root password 123456

Se você precisar trocar a senha posteriormente, é necessário acrescentar o parâmetro "-p" antes do "password" e especificar a nova senha, como em:

# mysqladmin -u root -p password asdfg

Enter password:

Note que nesse caso o comando solicita a senha antiga antes de continuar, já que do contrário teríamos uma brecha óbvia de segurança.

Continuando, depois de definir a senha, o próximo passo é criar uma base de dados. Você pode instalar vários scripts diferentes (um fórum, um chat e um gestor de conteúdo, por exemplo) no mesmo servidor e, inclusive, várias cópias de cada um. Isso é cada vez mais utilizado, tanto dentro de sites que oferecem diversos serviços, quanto em servidores compartilhados, onde os responsáveis por cada site têm a liberdade de instalar os sistemas de sua preferência.

Existem muitas interfaces de administração para o MySQL, mas a forma mais elementar é usar o prompt de comando. Para acessar o prompt do MySQL, use o comando :

# mysql -u root -p

Enter password:

Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 43 to server version: 4.0.15-log Type 'help;' or '\h' for help. Type '\c' to clear the buffer. mysql>

Veja que o cabeçalho normal do bash foi substituído por um "mysql>", que lembra onde você está ;). Para sair, pressione "Ctrl+C" ou execute o comando "Bye".

Dentro do prompt, use o comando "create database" (criar base de dados), seguido pelo nome desejado. Neste exemplo, estou criando uma base de dados para usar na instalação do phpBB, que veremos a seguir. Um detalhe importante é que todos os comandos dados dentro do prompt do MySQL devem terminar com ponto-e-vírgula:

mysql> CREATE DATABASE phpbb; Query OK, 1 row affected (0.04 sec)

Para confirmar, use o comando "SHOW DATABASES;", que lista as bases de dados criadas no servidor, como em:

mysql> SHOW DATABASES;

+--------------------+ | Database | +--------------------+ | information_schema | | mysql | | phpbb | | test | +--------------------+

Note que além da base "phpbb" que criamos, existem mais três bases de dados, criadas durante a instalação. As bases "mysql" e "information_schema" são para uso interno do MySQL, incluindo o armazenamento das configurações (sendo um banco de dados, o MySQL usa a sí mesmo para armazenar suas configurações :), enquanto a base "test" é uma DB vazia, que pode ser usada para fins de teste.

Temos em seguida a questão das permissões de acesso. Nada impede que você sempre utilize a conta "root" do MySQL e inclusive configure os scripts instalados para o utilizarem. Entretanto, isso é extremamente inseguro, principalmente se você pretende instalar vários scripts e aplicativos no mesmo servidor, ou se as bases de dados serão acessadas por vários usuários.

O ideal é que cada base de dados tenha um usuário próprio e seja acessível apenas por ele. Se você vai instalar o phpBB (fórum) e o Xoops (gerenciador de conteúdo), por exemplo, crie duas bases de dados ("phpbb" e "xoops", por exemplo) e dois usuários separados, cada um com permissão para acessar uma das duas bases.

Na configuração de cada um, informe a base de dados a ser usada e o usuário e senha correspondente. Isso evita que eventuais problemas de segurança em um coloquem em risco também os dados referentes ao outro.

Outra situação comum é ao configurar um servidor com vários virtual hosts. Nesse caso, o webmaster de cada site vai precisar de uma ou mais bases de dados e, naturalmente, cada um vai precisar de um login próprio, com acesso apenas às suas próprias bases de dados.

Para criar um usuário "phpbb", com senha "12345" e dar a ele acesso à base de dados "phpbb" que criamos, use (dentro do prompt do MySQL) o comando:

mysql> GRANT ALL ON phpbb.* TO phpbb IDENTIFIED BY '12345'; (permita tudo na base phpbb para o usuário phpbb, identificado pela senha 12345)

Para trocar a senha posteriormente, use o comando:

mysql> SET PASSWORD FOR phpbb = PASSWORD('123456'); (defina senha para o usuário phpbb, onde a senha é 123456)

Este mesmo comando pode ser usado para trocar a senha do root, como em:

mysql> SET PASSWORD FOR root = PASSWORD('asdfgh');

Se mais tarde você precisar remover as permissões de acesso de um usuário anteriormente criado (em um site com vários webmasters, onde um se desligou da equipe, por exemplo) use o comando:

mysql> REVOKE ALL ON phpbb.* FROM phpbb; (remova todos os direitos para a base phpbb, para o usuário phpbb)

Para remover uma base de dados, use o comando "DROP DATABASE", como em:

mysql> DROP DATABASE phpbb;

Veja que os comandos usados dentro do prompt do MySQL seguem uma linguagem literal, usando palavras do inglês. Quem tem uma boa familiaridade com a língua tem bem mais facilidade em dominar os comandos.

Outra observação é que os comandos não são case sensitive. Tanto faz escrever "CREATE DATABASE phpbb;" ou "create database phpbb;". Escrever os comandos em maiúsculas é apenas uma forma de dar mais destaque a eles.

Depois dessa configuração inicial, você pode experimentar instalar um gerenciador gráfico para facilitar a manutenção do seu servidor MySQL. Uma boa opção neste caso é o phpMyAdmin.

Para instalá-lo, basta instalar o pacote "phpmyadmin", como em:

# apt-get install phpmyadmin

O pacote para instalação em outras distribuições, que não incluam o pacote por padrão, pode ser encontrado no:http://www.phpmyadmin.net/.

O phpMyAdmim é um script em PHP, que trabalha em conjunto com o Apache. O script de pós-instalação incluído no pacote do Debian faz a configuração inicial para você, perguntando se ele deve ser configurado para trabalhar em conjunto com o Apache (1.3), Apache-ssl (ainda na versão 1.3) ou Apache 2 (a opção correta em nosso caso). O SSL permite que a interface de administração seja acessada via https, onde os dados são transmitidos de forma encriptada, melhorando a segurança. Ao usar o Apache 2, o acesso via SSL fica automaticamente habilitado, desde que você tenha habilitado o SSL no servidor, como vimos há pouco.



Depois de instalado, acesse o endereço "http://127.0.0.1/phpmyadmin/" ou "https://127.0.0.1/phpmyadmin/" e você cairá na tela de administração do phpMyAdmin, onde você pode logar-se usando qualquer uma das contas registradas no MySQL. Use o root para tarefas administrativas, quando for necessário ter acesso a todas as bases ou fazer backup de tudo, e uma das contas restritas para acessar uma base específica. Por questões de segurança, a configuração padrão permite que ele seja acessado apenas localmente.



Uma observação importante é que ao ser usado em conjunto com o Apache, instalado no mesmo servidor que ele, o MySQL é acessado apenas localmente, através da interface de loopback. O Apache envia a requisição ao módulo PHP que faz o acesso ao banco de dados, tudo localmente. Nessa configuração o servidor MySQL não deve ficar disponível para a Internet. Configure o firewall para bloquear a porta 3306 usada pelo servidor MySQL, além de todas as outras portas que não forem explicitamente necessárias.

Caso o servidor MySQL vá ser utilizado por outros servidores (você pode configurar o phpBB e outros scripts para utilizarem um servidor MySQL externo), deixe a porta aberta apenas para os endereços IP dos servidores que forem ter acesso. Como os servidores dedicados sempre utilizam endereços fixos (ao contrário dos servidores domésticos), esta configuração fica mais simples. Para administrar seu servidor MySQL remotamente, o ideal é que se conecte ao servidor via SSH e faça todo o trabalho através dele. Se precisar acessar diretamente alguma ferramenta de configuração, como o Webmin ou o PhPMyAdmin, você pode criar um túnel (novamente usando o SSH) ligando a porta correspondente do servidor a uma porta da sua máquina e fazer o acesso através dela. Veremos em detalhes como usar o SSH e criar túneis encriptados mais adiante.

Instalando suporte a PHP

Instalando o suporte a PHP

No início, existiam apenas páginas html estáticas, com links atualizados manualmente. Depois surgiram os scripts CGI, geralmente escritos em Perl, que permitiram criar vários tipos de formulários e automatizar funções. Finalmente, surgiu o PHP, adotado rapidamente como a linguagem padrão para criação de todo tipo de página dinâmica, fórum ou gerenciador de conteúdo.

Além da linguagem ser bastante flexível, um script em PHP chega a ser mais de 100 vezes mais rápido que um script CGI equivalente, além de mais seguro. Em resumo, um script CGI é um executável, que precisa ser carregado na memória, executado e descarregado cada vez que é feita uma requisição. No caso do PHP, o interpretador fica carregado continuamente e simplesmente vai executando de forma contínua os comandos recebidos dos scripts incluídos nas páginas.

Para quem programa em Perl, existe a possibilidade de utilizar o mod-perl, instalável através do pacote "apache-mod-perl" ou "libapache2-mod-perl2". Assim como o PHP, o mod-perl é um módulo do Apache que fica continuamente carregado na memória, executando os scripts Perl de uma forma bem mais rápida e segura que os scripts CGI.

Mas, voltando ao assunto principal, no Debian o suporte a PHP é instalado através do pacote "php5" (ou "php4", de acordo com a versão escolhida). Para instalá-lo, basta usar o gerenciador de pacotes da distribuição em uso, como em:

# apt-get install php5

No caso do Fedora, é usado um pacote unificado, o "php", que inclui a versão mais recente do interpretador, eliminando a confusão:

# yum install php

Com o interpretador PHP instalado, falta instalar o módulo do Apache 2, que no Debian está disponível através do pacote "libapache2-mod-php4" ou "libapache2-mod-php5", como em:

# apt-get install libapache2-mod-php5

O módulo "libapache2-mod-php5" é instalado dentro da pasta "/usr/lib/apache2/modules/" e é ativado de uma forma diferente que no Apache 1.3. Ao invés de adicionar as linhas que ativam o módulo e criam as associações de arquivos no final do arquivo httpd.conf, são criados dois arquivos dentro da pasta "/etc/apache2/mods-available/", com, respectivamente, a ativação do módulo e as associações de arquivos. Para ativar o suporte a PHP, é preciso copiar ambos para a pasta "/etc/apache2/mods-enabled/":

# cd /etc/apache2/mods-available/ # cp -a php4.conf php4.load ../mods-enabled/

Como vimos, você pode automatizar esta etapa ativando o módulo através do a2enmod, que cria os links automaticamente:

# a2enmod php4 ou # a2enmod php5

Não se esqueça de atualizar a configuração do Apache:

# /etc/init.d/apache2 force-reload

O Fedora não utiliza as pastas "modules-available" e "modules-enabled" como no Debian. O módulo do Apache é instalado junto com o pacote "php", mas para ativá-lo é necessário adicionar a linha abaixo no final do arquivo "/etc/httpd/conf/httpd.conf":

AddType application/x-httpd-php .php .phps .php3 .phtml .html .htm .shtml .fds

O serviço "httpd" do Fedora também não suporta o parâmetro "force-reload". Ao invés disso, use simplesmente "service httpd reload".

A partir daí, o Apache continua exibindo diretamente páginas com extensão .htm ou .html, mas passa a entregar as páginas .php ou .phps ao interpretador php, que faz o processamento necessário e devolve uma página html simples ao Apache, que se encarrega de enviá-la ao cliente.

Estas páginas processadas são "descartáveis": cada vez que um cliente acessa a página, ela é processada novamente, mesmo que as informações não tenham sido alteradas. Dependendo do número de funções usadas e da complexidade do código, as páginas em PHP podem ser bastante pesadas. Não é incomum que um site com 300.000 pageviews diários (o que significa umas 20 a 30 requisições por segundo nos horários de pico) precise de um servidor dedicado, de configuração razoável.

Quase sempre, os sistemas desenvolvidos em PHP utilizam também um banco de dados MySQL ou Postgre SQL. Para utilizá-los, você precisa ter instalados (além do MySQL ou Postgre propriamente ditos) os módulos "php4-mysql" e "php4-pgsql" (ou respectivamente "php5-mysql" e "php5-pgsql" ao usar o PHP 5), que permitem aos scripts em PHP acessarem o banco de dados:

# apt-get install php5-mysql ou # apt-get install php5-pgsql

Não se esqueça de reiniciar o Apache, para que as alterações entrem em vigor:

# /etc/init.d/apache force-reload

No caso do Fedora, instale o pacote "php-mysql":

# yum install php-mysql

Para verificar se o PHP está realmente ativo (em qualquer versão do Apache), crie um arquivo de texto chamado "info.php" (ou outro nome qualquer, seguido da extensão .php) dentro da pasta do servidor web, contendo apenas a linha abaixo:

Salve o arquivo e abra a página através do navegador. A função "phpinfo", que usamos no arquivo, faz com que o servidor exiba uma página com detalhes do configuração do PHP e módulos ativos:



Depois de verificar, remova o arquivo, pois não é interessante que essas informações fiquem disponíveis ao público.

Ativando o SSL

Ativando o SSL

A configuração do SSL no Apache 2 é um pouco complicada, pois envolve a modificação de vários arquivos. Vou fazer um apanhado geral, sem explicar muito sobre a configuração de cada arquivo, já que eles são explicados individualmente mais adiante. Sugiro que leia este tópico novamente depois de terminar de ler todo o capítulo.

O primeiro passo é obter um certificado SSL. Você pode gerar seu próprio certificado, o que é rápido, grátis e indolor, ou adquirir um certificado reconhecido na Verisign ou outra entidade certificadora. O problema de usar um certificado caseiro é que os clientes receberão um aviso de "certificado não reconhecido" ao acessarem a página, emitido pelo próprio navegador. Um certificado reconhecido é caro, mas muitos provedores permitem que você utilize um certificado compartilhado pagando uma taxa anual.

Você pode obter também um certificado gratuito no: http://www.cacert.org/. Ele é reconhecido pela CAcert, mas o certificado raiz deles não vem pré-instalado na maioria dos navegadores, o que faz com que os clientes continuem recebendo a mensagem de certificado não válido ao acessar o servidor.

Para gerar um certificado caseiro, use o comando:

# apache2-ssl-certificate

No Debian Etch, o script apache2-ssl-certificate não está mais disponível. Nele, você usaria o comando "make-ssl-cert", especificando o arquivo com o template (/usr/share/ssl-cert/ssleay.cnf) e o arquivo onde o certificado será salvo (/etc/apache2/ssl/apache.pem, para gerar um certificado padrão para o servidor), como em:

# mkdir /etc/apache2/ssl/ # make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/apache.pem

Ele pergunta várias informações sobre a empresa e sua localização, que os clientes podem verificar quando acessam o site. Se, por acaso, o comando não estiver disponível, verifique a instalação do pacote "ssl-cert".

O próximo passo é ativar o módulo "ssl" dentro do Apache 2, o que pode ser feito rapidamente usando o comando "a2enmod". Atualize a configuração do servidor para que a alteração entre em vigor:

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

Abra agora o arquivo "/etc/apache2/ports.conf" e adicione a linha "Listen 443" (a porta usada pelo https), como em:

Port 80 Listen 443

Com isso, o Apache 2 já está configurado. Falta apenas ativar o uso do SSL dentro da configuração de cada host virtual, ou seja, cada página hospedada no servidor Apache 2. Para testar, vamos ativá-lo na página padrão que usamos para testar o servidor.

Abra o arquivo "/etc/apache2/sites-available/default". No início do arquivo, substitua a linha "NameVirtualHost *", por:

NameVirtualHost *:443 NameVirtualHost *:80

Isso explica que o Apache deve escutar tanto a porta 80 padrão, quanto a porta 443, usada pelo SSL. Logo em seguida, substitua a linha "", por:

Até aqui, dividimos a configuração em duas seções, uma para a porta 80, outra para a porta 443, usada pelo SSL, Falta agora adicionar a seção referente à configuração do SSL no final do arquivo:

DocumentRoot /var/www/ ErrorLog /var/log/apache2/error.log CustomLog /var/log/apache2/access.log combined SSLEngine on SSLCertificateFile /etc/apache2/ssl/apache.pem

Reinicie o servidor (/etc/init.d/apache2 restart) e acesse o endereço "https://127.0.0.1" para testar a configuração. Ao conectar, o navegador exibe um aviso "O certificado do servidor falhou no teste de autenticidade" ou similar, o que é normal ao usar um certificado caseiro.

Instalando o APACHE

Instalando o Apache

A primeira escolha é entre instalar o Apache 2, ou o Apache 1.3, que ainda é usado por muita gente. O Apache 2 traz muitas vantagens, sobretudo do ponto de vista do desempenho, mas, por outro lado, ele é incompatível com os módulos compilados para o Apache 1.3 e muitas opções de configuração são diferentes.

A questão dos módulos não chega a ser um grande problema hoje em dia, pois todos os principais módulos já foram portados, mas muita gente que aprendeu a configurar o Apache 1.3 se sente mais confortável com ele e, por isso, continua usando-o até hoje, apesar das vantagens da nova versão. Muitas distribuições continuam oferecendo as duas versões, de forma a satisfazer os dois públicos. No Debian, por exemplo, o Apache 1.3 é instalado através do pacote "apache", enquanto o Apache 2 (a versão recomendada) é instalado através do "apache2".

Ao instalar o Apache 2, o suporte a SSL é instalado automaticamente junto com o pacote principal (mas ainda é preciso ativá-lo na configuração, como veremos a seguir). Instale também o pacote apache2-utils, que contém diversos utilitários de gerenciamento que usaremos a seguir:

# apt-get install apache2 # apt-get install apache2-utils

Você vai precisar também do pacote "ssl-cert", necessário para ativar o suporte a SSL e gerar os certificados. Ele não é instalado por padrão ao fazer uma instalação enxuta do Debian ou Ubuntu:

# apt-get install ssl-cert

No Fedora, instale o pacote "httpd", que contém o Apache 2 e utilitários:

# yum install httpd

Seguindo os nomes dos pacotes, no Debian o serviço se chama "apache2", enquanto no Fedora se chama "httpd". Para reiniciar o servidor, você usaria respectivamente "/etc/init.d/apache2 restart" e "service httpd restart".

Acessando o endereço "http://127.0.0.1", você verá uma página de boas-vindas, que indica que o servidor está funcionando. Se não houver nenhum firewall no caminho, ele já estará acessível a partir de outros micros da rede local ou da internet.



Por enquanto temos apenas uma versão básica do Apache, que simplesmente exibe arquivos html. Por padrão, o diretório raiz do servidor Web é "/var/www" (no Debian) ou "/var/www/html" (no Fedora). A página "http://seu.servidor/index.html" é, na verdade, o arquivo "/var/www/index.html".

A principal característica do Apache é a modularidade. Ao invés de ser um aplicativo grande e complexo, que tenta desempenhar sozinho todas as funções, o Apache se limita a executar uma única tarefa: entregar páginas html e outros tipos de arquivos aos clientes. Qualquer outra coisa é invariavelmente feita por um módulo externo.

Por exemplo, quando você acessa uma página em PHP em um site que roda sobre um servidor Apache, ele (Apache) lê o arquivo no disco e repassa a requisição para o modphp, o módulo encarregado de processar arquivos PHP. Ele, por sua vez, aciona o interpretador PHP, que processa a página e a entrega, já processada, ao Apache, que, finalmente, a entrega ao cliente. Caso seja necessário acessar um banco de dados (como no caso de um fórum), entra em ação outro módulo, como o php4-mysql, que permite que o interpretador PHP acesse o banco de dados:



Pode parecer estranho que depois de toda essa volta, o Apache ainda consiga entregar a página processada em tempo hábil, mas é justamente essa divisão de tarefas que permite que o Apache seja tão rápido e seguro. O trabalho é dividido em várias partes e cada módulo é mantido separadamente por uma equipe que entende do assunto e zela pelo desempenho e confiabilidade do código. Graças a isso, é bastante raro que sejam descobertos problemas graves de segurança no Apache ou no interpretador PHP, por exemplo. Quase sempre, os problemas de segurança não estão no servidor Web em si, mas sim no gestor de conteúdo (phpNuke, Xoops, phpBB, etc.) usado.

No Apache 2, esta arquitetura modular é extendida também aos arquivos de configuração. No Apache 1.3, a configuração era centralizada no arquivo "/etc/apache/httpd.conf", enquanto no Apache 2 ela é dividida em vários arquivos. À primeira vista, a organização do Apache 2 parece muito mais complicada, mas depois de entender a coisa se revela muito mais simples e lógica:



Todos os arquivos de configuração estão organizados dentro do diretório "/etc/apache2". Dentro dele, temos as pastas "sites-available" e "sites-enabled", que contém a configuração dos sites hospedados; as pastas "mods-available" e "mods-enabled", que armazenam a configuração dos módulos; o arquivo "ports.conf", onde vai a configuração das portas TCP que o servidor vai escutar; o arquivo "apache2.conf", que armazena configurações diversas relacionadas ao funcionamento do servidor e a pasta "conf.d", que armazena arquivos com configurações adicionais.

O Apache é capaz de hospedar simultaneamente vários sites, cada um representado por um arquivo de configuração diferente. Imagine o caso de uma empresa de hosting que mantém um servidor com 2.000 pequenos sites. Quando cada cliente registra seu site e assina o plano de hospedagem, você cria um novo arquivo dentro da pasta "sites-available" com as configurações necessárias e um link para ele na pasta "sites-enabled".

Como os nomes sugerem, a primeira pasta armazena a configuração de todos os sites hospedados no servidor, mas apenas os sites que estiverem presentes na pasta "sites-enabled" ficam disponíveis. Quando é necessário suspender temporariamente um site por falta de pagamento, você simplesmente remove o link na pasta "sites-enabled", sem precisar mexer na configuração.

Ao invés de criar e remover os links manualmente, você pode usar os comandos "a2ensite" e "a2dissite", que fazem isso para você. Para ativar e desativar um site configurado no arquivo "/etc/apache2/sites-available/kurumin", por exemplo, os comandos seriam:

# a2ensite kurumin
(ativa)

# a2dissite kurumin
(desativa)

Quando o Apache é instalado, é criado por padrão o arquivo "/etc/apache2/sites-available/default", que contém a configuração de um site "raiz", que usa como diretório de páginas a pasta "/var/www". Se o seu servidor web vai hospedar um único site, então essa configuração é suficiente. Mas, caso você queira hospedar vários sites no mesmo servidor, é necessário criar uma pasta e um arquivo de configuração para cada site adicional.

Seu servidor pode, por exemplo, hospedar o "joao.com.br" e o "maria.com.br". Um servidor DNS, mantido por você, é configurado para responder pelos dois domínios, em ambos os casos dando o IP do seu servidor web. Na configuração do apache, criamos os arquivos "/etc/apache2/sites-available/joao" e "/etc/apache2/sites-available/maria", um utilizando a pasta "/var/www/joao" e "/var/www/maria".

Quando um visitante digita "http://joao.com.br", o servidor da Fapesp (que responde pelos domínios .br) vai passar a requisição para seu servidor DNS, que responde com o endereço do seu servidor web. Ao acessar o servidor, o navegador solicita o site "joao.com.br" e o servidor responde enviando o arquivo "/var/www/joao/index.html" ou "index.php" ao cliente.

Esta configuração parece bem complicada à primeira vista, mas na prática é relativamente simples. Veremos mais detalhes sobre a configuração de servidores Apache com vários domínios mais adiante.

Continuando, a mesma idéia das duas pastas separadas se aplica aos módulos. A pasta "mods-available" contém a configuração e scripts de inicialização para todos os módulos disponíveis, mas apenas os módulos referenciados (através de um link) na pasta "mods-enabled" são realmente carregados.

Muita gente simplesmente cria e deleta os links manualmente, mas isso pode ser feito mais rapidamente usando os comandos "a2enmod" e "a2dismod", que ativam e desativam módulos específicos. Para desativar o suporte a PHP, por exemplo, você usaria o comando:

# a2dismod php4

Para ativá-lo novamente, usaria:

# a2enmod php4

Uma vez que um determinado módulo é ativado, ele fica automaticamente disponível para todos os sites hospedados no servidor. Lembre-se de que, ao mexer na configuração dos módulos ou sites, é sempre necessário recarregar a configuração, para que a alteração entre em vigor:

# /etc/init.d/apache2 force-reload

Você tem o mesmo efeito se simplesmente reiniciar o Apache, mas isso não é aconselhável em um sistema de produção, pois vai derrubar temporariamente todos os sites hospedados no servidor ;). Note que, no Apache 1.3, toda a configuração de módulos e sites ia diretamente no arquivo httpd.conf, que o tornava muito mais complexo.

Outra configuração que foi desmembrada é a configuração de portas, que foi para o arquivo "ports.conf". Originalmente o arquivo vem com uma única linha:

Listen 80

É aqui que você altera a porta padrão do seu servidor ao disponibilizá-lo em uma conexão via ADSL (onde a operadora bloqueia a porta 80) ou adicionar novas portas, como faremos mais adiante ao ativar o SSL, por exemplo.

Alguns serviços de banda larga, como, por exemplo, o Speedy da Telefonica, bloqueiam a porta 80, obrigando os usuários a manter seus servidores em portas alternativas. Você pode também alterar a porta para manter o seu servidor um pouco mais secreto, principalmente se for utilizada uma porta acima de 1024, já que, além do endereço IP ou domínio, os visitantes precisariam saber também a porta do servidor. Ao usar uma porta diferente da padrão, é preciso incluir a porta usada na URL, como em: http://seu-site.com.br:8080.

Para fazer com que seu servidor escute também a porta 8080, você adicionaria uma nova linha, como em:

Listen 80
Listen 8080

No caso do Apache 1.3, a configuração da porta vai dentro do arquivo "/etc/apache/httpd.conf", na linha "Port 80". Basta alterar o 80 pela porta desejada, salvar o arquivo e reiniciar o Apache para que a alteração entre em vigor. Se você quiser que o servidor escute em várias portas simultaneamente, use a diretiva "Listen" para adicionar as portas desejadas, como em:

Port 80
Listen 1080

Finalmente, chegamos ao arquivo "apache2.conf", que agrupa o "resto" das configurações. É ele que você vai alterar quando, por exemplo, precisar ajustar o número de processos usados pelo Apache ou aumentar o número de conexões simultâneas permitidas pelo servidor.

Instalando um servidor LAMP

Instalando um servidor LAMP

Atualmente quase 70% dos servidores web do mundo rodam o Apache, a maior parte deles sobre o Linux. O Apache é um dos servidores web mais antigos, seguro e com inúmeros módulos, que adicionam suporte aos mais exóticos recursos.

A maioria das páginas atuais utiliza uma estrutura em PHP, freqüentemente com um banco de dados MySQL ou PostgreSQL. Existem, inclusive, muitos sistemas prontos, como o phpBB (fórum) e o PHP Nuke (e derivados) para gerenciamento de conteúdo, que podem ser instalados sem muita dificuldade depois que o servidor web já estiver rodando. Outro recurso muito usado é a encriptação de páginas em SSL, necessário para a criação de páginas seguras (usadas em lojas virtuais, por exemplo) e um sistema de estatísticas de acesso como o Webalizer.

Além do servidor web em si, você quase sempre vai precisar configurar também um servidor DNS, que responde pelo domínio do seu site ou empresa. Aprender a configurar o DNS corretamente é importante, caso contrário você pode ter problemas ao enviar e-mails (pela falta do DNS reverso), ou mesmo ter problemas mais graves com o registro do domínio.

A Apache permite hospedar vários sites no mesmo servidor, recurso que chamamos de virtual hosts. Apenas os sites mais acessados são capazes de saturar os recursos de um servidor dedicado de configuração razoável. Por isso, hospedar vários sites no mesmo servidor é uma forma de economizar recursos e trabalho.

Ao hospedar vários sites, passamos a ter dois novos problemas: precisamos oferecer alguma forma segura de acesso aos arquivos, para que os responsáveis possam atualizar suas páginas sem alterar arquivos dos vizinhos, e precisamos de um sistema de quotas, para que cada um tenha sua fatia justa de espaço em disco.

Criamos, então, vários logins de acesso e configuramos um servidor FTP, para que cada um tenha acesso a seus próprios arquivos, mas sem ter como alterar os demais. Apesar de muito usado, o FTP é inseguro. No capítulo 8 veremos como usar o SFTP e o SHFS, que permitem acesso seguro, através de um túnel encriptado.

Os três são, na verdade, servidores de arquivos de uso geral, que não estão limitados a uso em conjunto com um servidor web. É muito comum usar um servidor FTP para disponibilizar arquivos para download público, por exemplo.

Completando o time, temos o Quota, que permite limitar o espaço em disco usado por cada usuário, garantindo uma divisão justa dos recursos disponíveis. Ao atingir seu limite, o usuário recebe uma mensagem de "disco cheio", mesmo que ainda existam vários GB's livres no HD do servidor.

Localizando máquinas infectadas com o worm Conficker

No dia 1o. abril 2009 todas as midias estavam focadas em um único assunto relacionado a redes e internet. Todo o planeta estava em alerta por causa da ação de um worm chamado Conficker.

Nos maiores sites de notícias sobre informática e em todos os sites especializados no assunto segurança da informação surgiam a cada momento novos posts sobre este o worm.

Isto me lembra muito cerca de 09 anos atrás um worm devastador chamado Sircam, esse cara fez um estrago imenso na rede Petrobrás onde eu trabalhava na época.

Porém como não poderia deixar ser Fyodor e sua trupe criaram uma nova feature no NMAP Esta feature permite scanear uma rede a procura por hosts infectados com o worm Conficker.

Para isso digite o seguinte comando:

nmap -PN -T4 -p139,445 -n -v --script smb-check-vulns,smb-os-discovery --script-args safe=1 [Rede_Alvo]

Versão a ser utilizada: http://nmap.org/dist/nmap-4.85BETA9.tar.bz2

Se a máquina estiver limpa surgirá o aviso Conficker: Likely CLEAN

Senão surgirá Conficker: Likely INFECTED

Essa dica foi retirada do site Dicas-l e foi uma colaboração de Alexandro Silva.

Mantendo o horário do servidor sempre sincronizado (Atualizado).

Ao compartilhar arquivos na rede, manter os relógios das máquinas sincronizados passa a ser uma necessidade, afinal, se cada máquina está usando um horário diferente, fica impossível acompanhar as datas de modificações dos arquivos. Achar a versão mais recente de um determinado arquivo torna-se uma tarefa impossível e o trabalho de ferramentas diversas de backup fica prejudicado, sem falar nos logs do sistema e outros recursos que dependem do horário.

Felizmente, é muito simples manter os horários das máquinas sincronizados, graças a vários servidores NTP públicos, disponíveis pelo mundo. Os servidores principais, chamados de stratum 1, sincronizam seus relógios a partir de relógios atômicos ou um sistema de GPS e, por isso, são extremamente precisos. A seguir, temos os servidores stratum 2, servidores menores sincronizados a partir dos primeiros.

Você pode sincronizar o relógio da sua máquina rapidamente usando o comando "ntpdate -u", seguido pelo servidor desejado. O comando faz parte do pacote "ntp" ou "ntpd", instalado por padrão na maioria das distribuições. A opção "-u" faz com que seja usada uma porta alta, necessário se você acessa usando uma conexão compartilhada ou tem um firewall ativo.

Para facilitar as coisas, existe o servidor "pool.ntp.org", que serve como um load balancer, encaminhando as requisições para um servidor geograficamente próximo de você. Ao invés de ficar caçando servidores públicos no Google, você pode sincronizar diretamente a partir dele:

# ntpdate -u pool.ntp.org

8 Sep 14:12:29 ntpdate[20592]: step time server 128.208.109.7 offset -9.091791 sec

O Linux utiliza um sistema relativamente complexo para manter o horário do sistema. Ao invés de simplesmente confiar no horário informado pelo relógio da placa mãe, ele utiliza um sistema mais complexo, baseado no clock da placa mãe para calcular a passagem do tempo. Sempre que o sistema é desligado corretamente, diferenças no horário do sistema e no horário informado pelo relógio da placa mãe são salvas em um arquivo e recuperadas na hora do boot.

Em geral, este sistema é bem mais preciso e permite que o horário mantenha-se correto (desde que o micro não seja desligado) mesmo nos casos em que a bateria do setup está fraca e o relógio da placa mãe está atrasando.

No entanto, existem casos onde o sistema calcula o clock de forma incorreta, fazendo com que o relógio comece a adiantar ou atrasar, mesmo que o relógio da placa mãe esteja indicando o horário corretamente.

A solução, nestes casos, é rodar o comando ntpdate periodicamente, de forma que o horário seja sempre corrigido antes que as diferenças se acumulem. Neste caso, a melhor solução é fazer com que o cron execute o comando de hora em hora.

O jeito mais simples de fazer isso é criar um pequeno script dentro da pasta "/etc/cron.hourly/", cujo conteúdo é executado de hora em hora pelo cron. Crie o arquivo "/etc/cron.hourly/ntpdate", contendo as duas linhas a seguir:

#!/bin/sh ntpdate -u pool.ntp.org

Transforme-o em executável:

# chmod +x /etc/cron.hourly/ntpdate

O cron detecta mudanças nos arquivos automaticamente. Mas, se preferir, você pode forçar a atualização usando o comando:

# /etc/init.d/cron restart

Os servidores NTP atendem clientes de todo o mundo, independentemente do fuso horário, pois são configurados para utilizar um horário comum o UTC (Universal Time Zone). Os clientes ajustam o horário de acordo com o fuso horário local.

Naturalmente, para que isso funcione, é necessário que o fuso horário esteja configurado corretamente. A maioria das distribuições ajusta isso logo durante a instalação, mas você pode configurar o fuso horário do sistema através de vários utilitários, como o "tzconfig" ou o configurador do KDE (kcmshell clock), que aparece ao clicar com o botão direito sobre o relógio e acessar a opção "Mudar data e hora". Existem também vários clientes Windows que utilizam o protocolo NTP. Você pode baixar as versões oficiais no:

http://ntp.isc.org/bin/view/Main/ExternalTimeRelatedLinks

O protocolo NTP leva em conta o ping entre as máquinas e outros fatores para fazer as atualizações de forma extremamente precisa. Diferenças de sincronismo entre os servidores são sempre da ordem de poucos milésimos de segundo.