Instalação de (Ubuntu + Apache VirtualHosts + MySQL + PHP) num VPS

By borfast

Recentemente tive de mudar alguns sites para um VPS e decidi documentar as partes essenciais da mudança. De notar que o que aqui relato são apenas os passos essenciais, necessários para ter os sites online; isto é, não menciono configurações adicionais para segurança, partições da(s) drive(s), optimizações do desempenho, etc...

O objectivo é apenas o de servir como guia superficial para quem queira seguir meia dúzia de passos para ter uns sites a funcionar num VPS. No entanto quase tudo isto se aplica a sistemas que não sejam VPSs. Podem seguir-se os mesmos passos a partir da secção "Instalar Apache + PHP + MySQL", para instalar noutro tipo de máquina (no vosso computador, se quiserem). E mesmo assim os passos anteriores podem ser úteis, caso queiram saber como se faz alguma daquelas coisas.

O serviço de VPS que escolhi foi o da Linode (o link tem a minha referência, que me dará um crédito de $20 se alguém se fizer e mantiver cliente deles por 90 dias). Como sistema operativo optei pelo Ubuntu 8.10, por ser uma distribuição de Linux que conheço bem. Sim, podia ter instalado a 8.04, que é de LTS e portanto muito mais, exponencialmente mais, milhões de vezes mais própria para um servidor... mas 8.04 é uma sequência de números que não me agrada, pois é decrescente e isso dá azar devido às congeminações do universo para fazer com que as formigas falem e viagem até Marte. Por outras palavras, eu gosto de ter as coisas actuais, por isso F.O.A.D.. ;)

Assumo que quem esteja a seguir isto saiba mexer minimamente em Linux pela linha de comandos (se bem que não são necessários grandes conhecimentos). Assumo também que tenha acabado de instalar o sistema operativo no seu VPS (ou seja, que ainda não instalou nem configurou nada) e que já existam registos de DNS que apontem um domínio (omeuvps.com) e dois sub-domínios (site1.omeuvps.com e site2.omeuvps.com) para o VPS a ser utilizado. Não vou falar de configurações de DNS, até porque a Linode disponibiliza um excelente gestor de DNS.
Assumo ainda que esteja a utilizar o Ubuntu 8.10. As instruções deverão poder ser aplicadas facilmente a qualquer outra distribuição de Linux, particularmente Debian 4.0 ou derivadas desta. Eventualmente serão necessários comandos diferentes para recarregar os serviços, caso a distribuição utilizada seja da Red Hat/Fedora ou baseada no sistema deles mas quem for por esse caminho também consegue facilmente descobrir como se controlam os serviços nesses sistemas ou onde estão os ficheiros de configuração cuja localização não coincida com a que aqui descrevo.

Vamos lá então começar:
ssh root@omeuvps.com

Configurar o locale

Tendo já usado o Ubuntu server em VPSs anteriormente, sei que o sistema não vem com o "locale" configurado, portanto após a instalação, a primeira coisa que fazemos é corrigir o locale, usando os seguintes comandos:
locale-gen en_US.UTF-8
/usr/sbin/update-locale LANG=en_US.UTF-8

Com isso no sítio já podemos efectuar as restantes operações sem ficar com o ecrã cheio de mensagens de erro devido a o sistema não saber que locale queremos usar.

Novo utilizador

De seguida criamos um utilizador novo, para futuramente não entrarmos como root:
adduser eumesmo

Introduzimos os dados que nos são pedidos (geralmente só ponho o nome e o resto vai em branco) e voilá, temos um novo utilizador.

Convém podermos executar comandos como root, mesmo estando ligados com o nosso novo utilizador. Para isso utilizamos o comando sudo mas temos que dar ao novo utilizador permissões para o executar. Vamos lá então:
visudo

Com este comando entramos no editor de texto "vi", que por artes mágicas nos permite adicionar o nosso utilizador à lista de gajos poderosos que podem tirar partido do sudo. Para tal adicionamos a linha que está a bold (sim, bold e não essa borreguice do "negrito" que se diz por aí):
root ALL=(ALL) ALL
eumesmo ALL=(ALL) ALL

Caso alguém fique à nora sobre a utilização do vi, o truque é carregar na tecla 'i' quando se entra no editor, para que se entre no modo de edição propriamente dito. Depois é ir à linha onde queremos adicionar o texto, escrevê-lo, e sair novamente do modo de edição, bastando para isso carregar na tecla "Escape". Depois é carregar na sequência de teclas Shift + ':' e depois em 'w' + 'q' + Enter. O Shift + ':' faz com que entremos no modo de comandos, sendo o 'w' o comando para escrever (write) o ficheiro e o 'q' o comando para sair (quit) do vi. Na realidade o que estamos a escrever é apenas um comando, o comando 'wq' que equivale às duas operações que referi, efectuadas de seguida. Simples, não é? Quem é que precisa de gravar um ficheiro carregando simplesmente no Ctrl + 's', quando se pode ter esta confusão toda? Aposto que agora já percebem porque é que há tanta gente que quase tem como missão única na vida o fomentar a utilização do vi. Jesus Cristo usava o vi, de certeza. O resto é para 1us3rz. E para o Sócrates.

Mas voltando a assuntos mais interessantes...

Por uma questão de simplicidade, para não ter de escrever constantemente sudo antes de todos os comandos que ainda vamos ter de escrever, não vamos sair já da shell de root para a shell do novo utilizador. Algumas pessoas dirão que isso é um erro mas é por isso que eu sou feliz e elas não. Eu vivo para o perigo.

Configuração do servidor de SSH

Com o utilizador criado, é altura de configurar o acesso por SSH para não permitir que mais ninguém aceda a esse serviço. Para isso é necessário editar o ficheiro de configuração do servidor de SSH, ou seja, é necessário um editor de texto. Podíamos utilizar novamente o vi mas como não precisamos de fazer pastéis de bacalhau, vamos usar outra coisa (para além de pastéis de bacalhau, o vi também faz cafés e dá diplomas de cursos superiores - se o Sócrates soubesse disto, usava o vi e não as outras coisas lames). Pessoalmente gosto do nano mas o bicho não vem instalado de raíz na instalação base do Ubuntu server, portanto tratemos de o instalar...

Primeiro há que correr um
apt-get update
pois caso contrário o sistema ainda não sabe da esmagadora maioria dos pacotes que estão disponíveis. Depois segue-se um
apt-get upgrade
para garantir que temos as versões mais actuais de todos os pacotes. Por fim, um
apt-get install nano
fornece-nos um editor de texto simples para pessoas mais sãs do miolo.

Com o nano instalado podemos então editar a configuração do SSH para ficar um pouco mais seguro. Sim, eu sei que tinha dito que não ia falar de configurações adicionais para segurança mas isto não é adicional, isto é uma coisa que considero básica, por isso quem não gostar pode ir pentear macacos ;)

nano /etc/ssh/sshd_config

Para começar procuramos a linha que diz
PermitRootLogin yes
e alteramo-la para passar a dizer
PermitRootLogin no

Isto faz com que não se possa entrar como root através de SSH. Também alteramos a linha
X11Forwarding yes
para
X11Forwarding no

Não vamos usar o X, portanto não precisamos disto - e como boa regra de segurança, se não é necessário, desliga-se. Também se podia simplesmente remover a linha, dado que o default desta opção é o "no" que lá lhe pusemos. Próxima alteração:
UsePAM yes
para
UsePAM no

Para explicar este seria necessário explicar o que o PAM faz, por isso para quem souber, basta dizer que não queremos as sessões do PAM a trabalhar com o nosso servidor de SSH (penso que os motivos são óbvios); para quem não sabe, vão ter de confiar em mim... :D
Por fim, a última alteração consiste em adicionar uma linha que especifica quais os utilizadores que podem entrar no nosso servidor de SSH:
AllowUsers eumesmo

Como removemos a possibilidade de entrar como root e, por default, o servidor de SSH permite o login por parte de qualquer utilizador, convém definirmos quem queremos deixar entrar. Com esta opção especificada, o servidor de SSH permite o login apenas por parte dos utilizadores listados, rejeitando todos os outros.

Isto é um exemplo de algo que, para aumentar um pouco o nível de segurança, eu faria de forma diferente: permitir logins apenas através de chaves encriptadas e não passwords, bem como alterar a porta do serviço de SSH. Para ir mais além até fechava a porta na firewall e punha-a a abrir por port knock. Na verdade fiz ambas ao configurar o meu VPS mas para este artigo isto chega. Como disse, só quero deixar aqui documentados os passos básicos.

EDIT @ 27 de Janeiro: Escrevi um artigo sobre como utilizar autenticação por chaves encriptadas para ligações SSH, caso alguém queira ir por esse caminho.

Resta-nos gravar o ficheiro. Como o nano não é um editor de texto para malucos, carregamos em Ctrl+'x', que é o comando para sair, e como qualquer editor de texto minimamente inteligente faria, o nano detecta que temos alterações que não gravámos e pergunta-nos se queremos gravá-las. Carregamos no 'y' para dizer que sim e carregamos no enter para confirmar o nome do ficheiro. Está feito.

Finalmente, reiniciamos o servidor de SSH:
/etc/init.d/ssh reload

Da próxima vez que entrarmos por SSH no nosso VPS, já não o poderemos fazer como root e as regras que alterámos já estarão em vigor.

Para informações mais completas sobre como configurar o servidor de SSH, é favor consultar a man page do bicho.

Firewall

O kernel do Linux tem uma firewall integrada, necessitando nós apenas de lhe dar as regras de acesso que queremos. Como o iptables, a ferramenta de gestão dessas regras, é um bicho relativamente complexo, vamos utilizar uma ferramenta bem mais simples, que agora vem com o Ubuntu: a Uncomplicated Firewall, ou ufw. Há quem diga que o iptables é simples e de facto aquilo não é muito complicado mas é preciso ler um bom bocado para entender o funcionamento da coisa. A ufw funciona para a maioria dos casos, que são mais simples. Para coisas mais complicadas confesso que ainda não a explorei, pois uso o iptables para esses casos.
Mais uma vez, na minha instalação dei passos adicionais para elevar o nível de segurança do servidor mas para aqui vou deixar apenas os passos para obter regras base para ter a firewall minimamente segura.

A instalação base do Ubuntu não traz a ufw de raíz, portanto temos de a instalar:
apt-get install ufw

Irão ver o iptables a ser instalado, juntamente com alguns outros pacotes que são necessários. E neste momento já podemos definir regras para a nossa firewall. Para começar podemos ver em que estado se enontra a firewall:
ufw status

A resposta deverá ser Status: not loaded. OK, já vamos corrigir isso. Vamos primeiro criar algumas regras. Para já só nos interessa aceitar ligações nas portas 22 (SSH) e 80 (HTTP):
ufw allow 22/tcp
ufw allow 80/tcp

De notar que só queremos permitir o acesso a essas portas através do protocolo TCP.
Tudo o resto queremos que seja descartado:
ufw default deny

Queremos ainda que a firewall escreva um log do que se vai passando, para podermos ter registos para análise, caso algo corra mal:
ufw logging on

E por fim ligamos a firewall:
ufw enable

A ufw vai perguntar-nos se queremos mesmo activar as regras, pois se não tivermos tido o cuidado de deixar aberta a porta de ligação por SSH, vamos perder a ligação ao servidor. Neste caso nem seria muito grave, pois a Linode fornece acesso aos seus VPSs através de uma consola via web, precisamente para permitir que os seus clientes corrijam problemas deste género. No entanto não vamos ter problemas, pois tivemos o cuidado de permitir explicitamente o acesso à porta 22.

Se fizermos agora
ufw status
já teremos uma resposta mais informativa:
To Action From
-- ------ ----
22/tcp ALLOW Anywhere
80/tcp ALLOW Anywhere

E com isto temos a nossa firewall minimamente configurada. Está então na hora de começar a instalar o software que vai servir os nossos sites.

Instalar Apache + PHP + MySQL

Não há muito a dizer sobre esta parte. A instalação deste software no Ubuntu é trivial:

apt-get install apache2 php5 php-pear php5-cli php5-gd php5-mhash php5-mysql php5-imagick php5-mcrypt php5-suhosin php5-recode php-apc mysql-server

Depois de muitos pacotes extra para satisfazer dependências e após termos definido uma password para o MySQL, temos o Apache a correr com PHP 5 (e alguns módulos úteis, que caso não sejam necessários devem ser retirados, para poupar memória), o patch Suhosin para tornar o PHP um pouco mais seguro, o sistema de cache APC para o PHP, e o MySQL pronto a servir bases de dados.

Passar para o utilizador "normal"

Ainda vamos necessitar de executar alguns comandos como root mas como vamos começar a mexer em ficheiros que não o terão como dono (owner), vamos passar para o nosso utilizador normal, para não misturarmos permissões:
logout

De agora em diante entramos com o nosso utilizador normal:
ssh eumesmo@omeuvps.com

Neste momento devemos estar de volta à consola do nosso VPS e estamos prontos para começar a pôr os sites a funcionar.

Configurar os virtual hosts

Neste momento se acedermos a omeuvps.com já devemos ver uma página em branco, apenas com a frase "It works!" a bold.

Se quisermos ter apenas um site no servidor, podemos simplesmente adicionar ou editar ficheiros na directoria /var/www e está o assunto arrumado. No entanto, como estamos em crise, utilizar um VPS para apenas um site é um desperdício de recursos, pelo que queremos poder servir mais que um site a partir do mesmo vps. Para isso vamos usar virtual hosts do Apache.

Para ilustrar o processo de criação de um virtual host, vamos criar dois sites na directoria do nosso utilizador:
cd ~
mkdir websites
cd websites
mkdir site1
mkdir site1/html
mkdir site2
mkdir site2/html
cd site1/html
nano index.php

O primeiro comando não é estritamente necessário, apenas o incluí para o caso de um leitor mais distraído ter vagueado para fora da directoria inicial. As duas directorias site1 e site2 que foram criadas serão onde vamos guardar os ficheiros de cada site, sendo que os ficheiros que queremos que esteja acessíveis na web devem ficar dentro das respectivas directorias html.

Dentro do nano, vamos pôr uma única linha:
<?php phpinfo();
Antes de mais, não, não é necessário fechar a tag <?php. Certos estilos e regras de formatação de código de alguns projectos até proíbem explicitamente a utilização da tag ?>.

Ctrl + x e y para gravar o ficheiro e vamos agora criar um ficheiro simples no nosso site2:
cd ../site2/html
nano index.html

Dentro deste ficheiro podemos escrever seja o que for. Eu vou escrever "Pai Natal" dentro do meu. É mesmo só para testar se tudo está a funcionar correctamente.

Por fim vamos adicionar os nossos sites como virtual hosts:
sudo nano /etc/apache2/sites-available/site1
e dentro do nano colocamos isto:

DocumentRoot /home/eumesmo/websites/site1/html
ServerName site1.omeuvps.com

Ctrl + x e y para gravar o ficheiro e vamos repetir para o site2:
sudo nano /etc/apache2/sites-available/site2
e dentro do nano colocamos isto:

DocumentRoot /home/eumesmo/websites/site2/html
ServerName site2.omeuvps.com

Ctrl + x e y para gravar o ficheiro e vamos activar os virtual hosts:
sudo a2ensite site1
sudo a2ensite site2

O comando a2ensite apenas cria links para os ficheiros que criámos. Por exemplo, de /etc/apache2/sites-available/site1 para /etc/apache2/sites-enabled/site1.

Finalmente, vamos dizer ao Apache para reler os ficheiros de configuração, para que saiba que tem dois novos virtual hosts para servir:
sudo /etc/init.d/apache2 reload

A partir de agora e assumindo que o DNS foi configurado para tal, se acedermos a http://site1.omeuvps.com/ iremos ver as informações dadas pela função phpinfo(), e se acedermos a http://site2.omeuvps.com/ iremos ver "Pai Natal" numa página em branco.

Se alguém estiver a experimentar isto na sua máquina local, é pouco provável que tenha um domínio a apontar para o seu computador mas podemos sempre fazer uma pequena batota e pôr a coisa a funcionar:
sudo nano /etc/hosts
e adicionar o que está a bold
127.0.0.1 localhost
127.0.0.1 omeuvps.com
127.0.0.1 site1.omeuvps.com
127.0.0.1 site2.omeuvps.com

Na verdade isto até pode ser útil mesmo para quem utiliza um VPS, pois o sistema deixa de precisar de fazer queries de DNS para saber os IPs daqueles hosts, portanto também podem fazer estas alterações.

Daqui para a frente temos dois sites distintos a serem servidos pelo mesmo Apache. Para adicionar mais sites como virtual hosts é só repetir estes últimos passos.

Fim

E já está, foi longo mas espero que seja útil.

7 comments

By trimax (not verified)
1 year 6 weeks ago

Mais um excelente "post"!

Mais um excelente "post"! Quase que me convencias a abrir os cordões à bolsa (de onde virá esta expressão) para abrir uma conta na Linode e experimentar! Deve ter sido uma das tuas "postas" mais longas de sempre! LOL! Nunca me canso de ler estas pérolas de sabedoria linux-escas!

By borfast
1 year 6 weeks ago

Obrigado! :) Ando a ver se te

Obrigado! :)
Ando a ver se te convenço a não gastares dinheiro num Mac :P
Estou a brincar, já sabes o que penso quanto a isso: se te trouxer vantagens e for rentável, compra!

Quando a experimentares a Linode, se a vontade era para pores o Apache e companhia a correr, podes sempre fazer o mesmo num computador teu. Se for por quereres ver o interface de administração da Linode, também te posso fazer uma visita guiada ;)

By João Moreno (not verified)
1 year 6 weeks ago

Perfeito

Hey!

Está excelente. Há dias vim para Zurique e deixei em casa uma máquina a correr Ubuntu server para ir mandando para lá as minhas coisas todas... isto vai dar mesmo jeito. Obrigado.

Keep up.

By borfast
1 year 6 weeks ago

João, se tens a máquina

João, se tens a máquina ligada a uma rede onde estão outros computadores, ou se lá guardas documentos importantes, sugiro que implementes algumas medidas de segurança que eu não descrevi aqui.

Em primeiro lugar, arranja um sistema automático de backups, se não o tiveres já. rdiff-backup ou rsync são excelentes para isto.

Em segundo lugar e assumindo que não utilizas nenhum software que necessite que o servidor de SSH esteja a correr na porta 22, podes mudar esta porta para outro número qualquer acima de 1024 (desde que não tenhas lá outro software a correr, claro). Para o fazeres basta alterares a linha que diz "Port 22" no ficheiro de configuração do servidor. Ainda em relação à porta, se te quiseres dar a esse trabalho, podes também pô-la a abrir por port knocking, como refiro no texto.

Em cima disto, se não pretenderes aceder à máquina por SSH a partir de vários computadores diferentes, sugiro que utilizes ficheiros de chave encriptados. A desvantagem desta abordagem, ainda que muito mais segura do que somente a password, é que tens de ter o ficheiro da chave privada em qualquer computador de onde queiras aceder à tua máquina de casa, o que pode não ser muito prático.
Aliás, vou adicionar isto ao meu texto como um extra ;)

Ah, e nunca é demais repetir: backups! ;)

By João Moreno (not verified)
1 year 6 weeks ago

Genial

Ahaha obrigado por tudo!

Quanto aos backups, penso que não necessito, aquilo já são os meus backups e o resto são dados que não são críticos. :)

Quanto à porta, é uma excelente ideia, já tinha pensado nisso, mas ainda não arranjei o tempo para o fazer.

E quanto às chaves, sim já o tenho assim. :D

By borfast
1 year 6 weeks ago

OK, então parece que já estás

OK, então parece que já estás pronto a rolar :)

De qualquer modo escrevi mais um artigo, este sobre como usar chaves públicas e privadas para autenticação de ligações SSH:
http://www.borfast.com/blog/chaves-publicas-e-privadas-para-ssh

Vou adicionar o link a este, na secção da configuração do SSH.

By Anónimo (not verified)
21 weeks 1 day ago

Very useful man! Thanks!

Very useful man! Thanks!