Padrão Saravá Versão Debian
Índice
Licença
Esta
documentação foi desenvolvida e escrita originalmente por Silvio Rhatto e pelo Coletivo
Saravá.
Copyright (c) Coletivo Saravá. É garantida a permissão para copiar, distribuir e/ou modificar este documento sob os termos da Licença de Documentação Livre GNU (GNU Free Documentation License), Versão 1.2 ou qualquer versão posterior publicada pela Free Software Foundation; sem Seções Invariantes, Textos de Capa Frontal, e sem Textos de Quarta Capa. Uma cópia da licença é incluída na seção intitulada "GNU Free Documentation License".
O Padrão Saravá
O Padrão Saravá foi feito originalmente para o sistema operacional slackware, ele é uma sistematização de configuração de servidores, gerenciadores de conteúdo e aplicações diversas usados pelo Projeto Saravá. O padrão foi desenvolvido para:
- Ter o controle total dos pacotes utilizados e arquivos de configuração
- Uniformidade de administração
- Sistema de gerenciamento de backups comum para que as máquinas de um projeto possam trocar dados
- Que um servidor seja configurado apenas uma vez e que suas configurações possam ser aproveitados para outras máquinas
- Que sites e serviços sejam armazenados de maneira regular para facilitar atualizações e migrações
- Manter projetos e serviços isolados uns dos outros através de servidores virtuais
- Tornar a instalação dos servidores facilmente replicável
O Padrão Saravá não contém a configuração completa para servidores, mas sim apenas o padrão de como os procedimentos devem ser efetuados, considerando que a configuração necessária já esteja em uso. O coletivo sysadmins do CMI Brasil optou por seguir esse padrão como proposta de processo para administração do servidor marieta.
O Padrão Sarava Versao Debian - Marieta
Como sugerido no texto escrito na seção
introdução - Administracao dos servidores da documentação antiga do coletivo:
Introdução - Administracao dos servidores
O Indymedia é um projeto que utiliza muitos servidores espalhados pelo mundo todo. Para que não haja confusão no que cada máquina hospeda e como ela foi configurada, é importamte que os procedimentos sejam bem documentados. Esta página contém os procedimentos utilizados para configurar servidores administrados pelo Coletivo Técnico do CMI Brasil.
Esta documentação está longe de ser concluída. Além do que está escrito aqui, é preciso criar procedimentos padrões para todas as tarefas. A exemplo do
Projeto Saravá, que criou
diversos padrões e do
Riseup, que possui seu
Grimório Debian o
Coletivo Técnico pode definir seus próprios procedimentos. Fica como sugestão:
- Definir o Debian como distribuição de GNU/Linux padrão do Coletivo Técnico
- Usar, sempre que possível, o "jeito debian" de se fazer as coisas
- Criar uma política de administração padrão para todos os servidores
- Procurar sempre as soluções simples e duráveis
A seguir, fique com os procedimentos já estabelecidos. Boa leitura!
Quando recebemos a doação do servidor marieta, resolvemos adotar o procedimento da
documentação do padrao sarava e suas sugestões de configurações de servidores usando vservers. O Coletivo Tecnico do CMI utiliza o sistema operacional Debian nos seus servidores e vservers, já a documentação padrao.sarava.org usa o slackware. Por causa dessa diferença que modifica alguns procedimentos (por exemplo o script de atualizacao do kernel, repositorio de pacotes etc), resolvemos criar uma documentação 'versão debian'.
Visao Geral
Procedimento de instalação
Inicia-se com a instalação do sistema básico do debian. A escolha da distribuição foi o Etch.
Na configuração do host de servicos que estavam de pé para o ip da maquina nos deparamos com alguns servicos que são colocados pelo debian na instalacao padrão dele, todos os servicos estavam ligados com NFS e foram removidos:
apt-get remove nfs-common
apt-get remove portmap
Para verificar as portas abertas no servidor pode ser usando o comando
nmap.
Kernel
Inicialmente apenas foi instalado com apt-get o patch linux-image-2.6-vserver-amd64. Para compilar o kernel no modo debian o procedimento é conforme apresentado abaixo no item atualização do kernel.
Atualização do Kernel
Para atualizar o kernel, utilize o seguinte procedimento:
1. Atualize os pacotes de fontes do kernel.
apt-get update
apt-get upgrade
Estes comandos devem atualizar os pacotes
linux-image-2.x-versao e
linux-image-2.x-vserver-versao. Um pacote com o código fontes do kernel será instalados em
/usr/src/linux-source-2.x.yy.tar.bz2 (onde 2.xx.yy é na verdade a versão do kernel) e dois patches devem ser aplicados para habilitar o vserver no kernel (a motivação para a aplicação do segundo patch pode ser vista
aqui):
/usr/src/kernel-patches/all/2.x.yy/debian/features/all/vserver/vs-versao.patch.bz2
/usr/src/kernel-patches/all/2.x.yy/debian/debian/vserver-version.patch.bz2
2. Descompacte o fonte numa pasta de trabalho temporária, copie a configuração original (.config) para o novo diretório temporário criado, e depois compile com o comando:
time make-kpkg --initrd --append-to-version "string-de-identificacao" kernel_image
Onde
string-de-identificacao deve seguir um padrão que podemos desenvolver. Será gerado um arquivo chamado
linux-image-2.x.yy-string-de-identificacao_2.x.yy-string-de-identificacao-10.00.Custom_versao.deb (verificar o nome do pacote), que é um pacote no formato debian.
3. Instale o novo kernel com o dpkg:
dpkg -i ../linux-image-2.x.yy-string-de-identificacao_2.x.yy-string-de-identificacao-10.00.Custom_versao.deb
Esta instalação vai alterar o arquivo
/boot/grub/menu.lst e configurar este novo kernel como padrão. Podemos alterar este arquivo, caso queiramos testar o novo kernel antes de colocá-lo em produção.
Servidores Virtuais
Implementação dos VServers
Os vservers estão no diretório
/var/vservers, e portanto mantemos o
/var numa partição separada, utilizando RAID 5.
Preparação do host
Aplicamos o patch linux-image-2.6-vserver-amd64. Instalamos também o util-vserver. Depois começamos a configurar o host seguindo as instruções da documentação feita pelo [[http://riseuplabs.org/grimoire/vserver/][Riseup]] que também usa Debian. Começamos da parte: [[http://riseuplabs.org/grimoire/vserver/preparing/#set_up_the_general_vserver_directories_including_the_barrier][para criar as barreiras de segurança no vserver]].
Para entender mais sobre como funciona um vserver e o que são estas coisas que estamos mencionando na documentação, recomendamos a leitura do documento: [[http://slack.sarava.org/vservers][Linux VServers e segurança por contexto]]
Seguindo o tutorial do Riseup, configuramos o host para que os serviços apontassem para o ip da maquina. Nessa jornada, aproveitamos para retirar alguns serviços que são instalados automaticamente pelo Debian em sua instalaçao. Retiramos o nfs-common para acabar com o rcp.statd e outras coisas que estavam rodando na Marieta por causa dele e também o portmap, que funciona só pro causa do nfs.
Antes de criar a primeira instância de vserver, nos tivemos uma discussão sobre usar um ip real para cada vserver ou compartilhar um único ip real entre os vserver. O grande dilema foi que seria possível ter pelo menos uns 2/3 vservers com ip real, mas é muito difícil conseguir mais ips do que isso, caso nós quisessemos expandir.
Por isso optamos em seguir um tutorial que explicasse como configurar o host para ter vservers que compartilhem um único ip real (o ip da máquina).
O documento [[http://slack.sarava.org/vservers][Linux VServers e segurança por contexto]] explica sobre isso e tambem em [[http://padrao.sarava.org/engine/SlackwareVservers][padrao.sarava slackware vservers]]
Começamos criando o primeiro vserver, vserver mir. Até o momento o plano é criar três vservers:
* *MIR* - onde vamos rodar todos os serviços relacionados com o CMS MIR.
* *Backup* - para hospedar backups de outros coletivos e nosso próprio backup
* *Mirror* - para hospedar espelhos de outros coletivos da rede.
O comando para criar o vserver foi:
*vserver mir build -n mir --context 101 --hostname mir.marieta.indymedia.org --interface eth1:192.168.0.101/24 -m debootstrap -- -d etch*
Depois iniciamos:
*vserver mir start*
e entramos dentro do ambiente dele:
*vserver mir enter*
Segurança do proc
Retirado do documento - [[http://slack.sarava.org/vservers][Linux VServers e segurança por contexto]]:
O proc é o sistema de arquivos que faz a interface entre o espaço do usuário e as estruturas de dados do kernel. No proc ficam tipicamente listadas informações como processos e estado da rede e podem ser utilizado para controlar parâmetros do kernel. É importante evitar que muitas dessas informações estejam indisponíveis dentro dos vservers e por padrão algumas dessas entradas (como as informações de processos de outros contextos) já estarão escondidas.
Mas a configuração padrão não esconde tudo, deixando isso para ser realizado pelo administrador ou a um script. Essa "segurança" do proc é feita com o comando setattr, anteriormente usado para criar a barreira dos vservers. Mudar a visibilidade das entradas no /proc nada mais é do que manipular os atributos extendidos dessas entradas, por isso o uso do setattr.
É preferível fazer essa parte, depois de termos colocado todos os serviços que queremos rodando dentro do vserver mir em funcionamento. Desta forma saberemos quais são os que usam os arquivos desse diretório e quais os que devemos impedir o acesso pelo vserver.
Compartilhando um único ip real
Retirado do documento - [[http://slack.sarava.org/vservers][Linux VServers e segurança por contexto]]:
Roteamento de rede
O roteamento de rede e o controle da banda para os vservers é feito com a infra-estrutura já existente no GNU/Linux (iptables, iproute2, etc). Aqui consideramos o caso de vservers que tanto podem acessar máquinas remotas quanto receber conexões entrantes da internet.
A primeira medida é estabelecer a tradução de endereços via NAT se o vserver não possuir IP real. Isso é feito usualmente e depende do sistema de firewall que você está utilizando. O mais simples é um iptables direto. Considerando que a faixa de IPs para os seus vservers é a 192.168.0.X, use
iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -d 0/0 -j SNAT --to IP-DO-SERVIDOR
Onde IP-DO-SERVIDOR é o endereço real da sua interface. Em seguida, temos que rotear as conexões entrantes para as respectivas aplicações enjauladas. O comando
iptables --protocol tcp -t nat -A PREROUTING -i eth0 -s 0/0 -d IP-DO-SERVIDOR \
--dport PORTA -j DNAT --to-destination DESTINO:PORTA2
serve para direcionar uma conexão chegando no IP-DO-SERVIDOR na porta PORTA para o vserver de IP DESTINO na porta PORTA2. Nos casos em que o servidor possui mais de um IP real e um deles for atribuído ao vserver, este tipo de roteamento não é necessário.
script que automatiza esse procedimento
adicionado em /etc/rc.local:
# Enable SNAT for the internal network
/sbin/iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -d 0/0 -j SNAT --to IP-DO-SERVIDOR
# redirect PORTAxxx to the ssh daemon of vserver xxx
for i in `/usr/bin/seq 100 200`; do
iptables --protocol tcp -t nat -A PREROUTING -i eth1 -s 0/0 -d IP-DO-SERVIDOR \
--dport PORTA$i -j DNAT --to-destination DESTINO.$i:PORTA2
done
Este vserver hospeda todos os sites do Indymedia que usam o software MIR. Aqui voce vai encontrar a documentacao dos servicos que estao rodando nele: tomcat, apache, postgres.
Este vserver eh dedicado somente para hospedar backups locais e tambem para receber de outros servidores. A configuracao dos backups locais eh feita pelo software Backupninja que esta instalado no servidor principal, ou seja, na marieta, nao em um vserver. Ela esta explicada abaixo na secao '''Padrao Backups'''.
Hardware RAID
Particionamento RAID
Particionamento
Observações:
1. "Deixar uma partição livre para um sistema reserva" - é uma boa dica do rhatto
2. Deixar uma partição para boot em cada um dos 4 discos -> dica do zapata
3. Os vservers se encontram no diretório
/var/vservers/ e por isso mantemos o
/var/ numa partição separada e utilizamos RAID 5 que implementa redundância e soma de espaços.
Tabela de particionamento dos HD's sda (1,2,3), sdb (1,2,3), sdc (1,2,3) e sdd (1,2,3)
| sd (a,b,c,d) | nome partição | tamanho | filesystem |
|---|
| 1 | /boot | 500MB | ext2 |
| 2 | / | 20GB | ext3 |
| 3 | /swap | 2GB | Swap |
| 4 | /var | 477,5GB | ext3 |
RAID
Decidimos adotar uma mescla entre Raid 1 e Raid 5, justificado especialmente pela perspectiva que a Marieta pode ter de uso de múltiplos serviços, tais como abrigar uma possível morada alternativa para docs.indymedia.org e outros serviços. Pensamos na questão da complexidade também, optando por uma alternativa de menor complexidade.
Sendo assim, vamos particionar os 4 hds de 500gb da mesma forma.
Tabela de particionamento do RAID
md2 : active raid5 sda4[0] sdd4[3] sdc4[2] sdb4[1]
1399221120 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]
md1 : active raid1 sdb2[0] sdd2[3] sdc2[2] sda2[1]
19534976 blocks [4/4] [UUUU]
md0 : active raid1 sdb1[0] sdc1[3] sdd1[2] sda1[1]
489856 blocks [4/4] [UUUU]
No total temos de espaço:
Por cima disso, seriam então:
- RAID 1 para o /boot
- RAID 1 para o /, o sistema raiz do servidor (da marieta)
- RAID 5 para o /var
- SWAP por disco e com a mesma prioridade no fstab
Rede e monitoramento
DNS
Fazer:
*.marieta.indymedia.org to marieta
para ter mir.marieta.indymedia.org virtual hosts etc.
Controle de trafego
webalizer
Configuração feita dentro do vserver que hospeda os sites. A descrição está aqui:
https://docs.indymedia.org/view/Sysadmin/VServerMirMarieta#webalizer
Servicos
Firewall
Começamos com o firewall, configurando o shorewall.
descrição:
shorewall derteminará a configuração básica.
shorewall é apenas uma ferramenta que configura iptables.
shorewall permiter assim uma configuração de alto-nível (mais amigável)
instalação:
apt-get install shorewall shorewall-doc
configuração:
copiando arquivos de exemplo:
cp /usr/share/doc/shorewall/examples/two-interfaces/* /etc/shorewall/
gunzip interfaces.gz
gunzip masq.gz
gunzip policy.gz
gunzip rules.gz
editando zones
fw firewall
net ipv4
vm ipv4
uma zone é uma parte de uma rede. Definimos 3 zones:
fw é o firewall, net é a internet e vm é vms
editando policy
shorewall trabalha com uma "policy" para a politica geral e um arquivo "rules" como extensão desta.
no arquivo policy nos setamos qual zona pode comunicar com qual
vm net ACCEPT
$FW net ACCEPT
$FW vm ACCEPT
ou seja, a maquina virtual pode ir para internet e o firewall pode ir a net a maquina virtual.
editando rules
SSH/ACCEPT net $FW
Ping/ACCEPT net $FW
HTTP/ACCEPT net $FW
HTTPS/ACCEPT net $FW
DNAT net vm:IPINTERNO:PORTA tcp PORTAINTERNA
basicamente habilitando conexoes ssh da intenet bom como ping, http e https e conexoes da internet para o vserver mir na porta PORTAINTERNA
editando interfaces
net eth1 detect dhcp,tcpflags,norfc1918,routefilter,nosmurfs,logmartians
editado hosts
vm eth1:192.168.0.0/24
editando masq
mascarando todo tráfico saindo de eth1 mas não para 192.168.0.0/24 (the vm addresses) to be masqueraded with eth1's ip address:
eth1:!192.168.0.0/24 192.168.0.0/24
editando routestopped:
quando inicia-se o shorewall há o risco dele nos impedir de acessar a máquina caso tenha alguma configuracão errada, então é recomendável adicionar o ip de quem está fazendo a configuração neste arquivo para estar fora das regras do shorewall por garantia.
testando e inicializando o shorewall
shorewall check
shorewall safe-start
Apache
instalação
apt-get install apache2
editamos o /etc/apache2/ports.conf com:
Listen IPDOSERVIDOR:80
em seguida add os modulos no apache:(ln -s /etc/apache2/mods-available/nomedomodulo /etc/apache2/mods-enabled/.)
proxy.load
proxy.conf
proxy_http.load
não logar ip
por padrão a config do apache2 (/etc/apache2/apache2.conf) vem com as diretivas de log:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
* %a Remote IP-address
* %h Remote host
Estes devem serem removidas (no caso o %h)
ficando:
LogFormat "- %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "- %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent
para saber mais:
http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#formats
por padrão o apache faz log tb quando usuário entra com url errada, para desabilitar isso deve-se editar em cada arquivo de configuração dos sites (ex: /etc/apache2/sites-available/default) e alterar:
LogLevel warn
para:
LogLevel crit
configurar virtual host
cria-se um arquivo em /etc/apache2/sites-available/nomedosite
com por ex:
<VirtualHost *>
ServerName marieta.indymedia.org
<Location />
AllowOverride None
Order allow,deny
allow from all
</Location>
ProxyPass / http://192.168.0.101/
ProxyPassReverse / http://192.168.0.101/
</VirtualHost>
habilitar:
ln -s /etc/apache2/sites-available/nomedosite /etc/apache2/sites-enabled/.
apache2ctl start
ssl
instalações necessárias
#apt-get install openssl ssl-cert
#mkdir /etc/apache2/ssl
Gerar um arquivo marieta.pem com ambas chaves privada e certificado publica, valida 365 dias e sem necessidade de pedir senha (-nodes)
#openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/ssl/marieta.pem -keyout /etc/apache2/ssl/marieta.pem
chmod 600 marieta.pem
depois editar:
/etc/apache2/ports.conf
com:
Listen IPMARIETA:80
Listen IPMARIETA:443
Habilitar modolo ssl:
#ln -s /etc/apache2/mods-available/ssl.conf /etc/apache2/mods-enabled/.
#ln -s /etc/apache2/mods-available/ssl.load /etc/apache2/mods-enabled/.
#apachectl restart
Editar
/etc/apache2/sites-available/default
com:
NameVirtualHost *:80
NameVirtualHost *:443
<VirtualHost *:80>
....
</VirtualHost>
<VirtualHost *:443>
....
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/marieta.pem
</VirtualHost>
E nos demais virtualhost:
ex: site.indymedia.org
<VirtualHost *:80>
ServerName site.mir.marieta.indymedia.org
ServerAlias prod.site.indymedia.org www.site.indymedia.org site.indymedia.org
<Location />
AllowOverride None
Order allow,deny
allow from all
</Location>
ProxyPass / http://site.mir.marieta.indymedia.org/
ProxyPassReverse / http://site.mir.marieta.indymedia.org/
</VirtualHost>
<VirtualHost *:443>
ServerName site.mir.marieta.indymedia.org
ServerAlias prod.site.indymedia.org www.site.indymedia.org site.indymedia.org
<Location />
AllowOverride None
Order allow,deny
allow from all
</Location>
ProxyPass / http://site.mir.marieta.indymedia.org/
ProxyPassReverse / http://site.mir.marieta.indymedia.org/
</VirtualHost>
se tiver mais virtual host na config de um site deve-se incluir além da config acima o seguinte: (acontece com a config do brasil.indymedia.org na marieta):
<VirtualHost *:80>
ServerName xxx.midiaindependente.org
Redirect / http://prod.midiaindependente.org/yyyy/
</VirtualHost>
<VirtualHost *:443>
ServerName xxx.midiaindependente.org
Redirect / https://prod.midiaindependente.org/yyyy/
</VirtualHost>
<VirtualHost *:80>
ServerName xxxx.midiaindependente.org
Redirect / http://prod.midiaindependente.org/yyyy/...
</VirtualHost>
<VirtualHost *:443>
ServerName xxxx.midiaindependente.org
Redirect / https://prod.midiaindependente.org/yyyy/...
</VirtualHost>
#apachectl reload
Espelhamento de sites (proxy)
Padrao Backup
Procedimentos
1. backup postgres
roda/run -> 1 vez por dia
guarda/save
mir: /mnt/backup/postgress/ -> backup: /home/mir/postgress
vserver marieta: /home/mir/postgres
2. backup mir sites/media
roda/run -> 1 vez por dia
guarda/save
* uma copia localmente:
mir: /mnt/backup/site/media -> backup: /home/mir/site/media
* uma copia remotamente:
vserver marieta: /home/mir/site/media
3. backup mir sites
roda/run -> 1 vez por mes
guarda/save
mir: /mnt/backup/site -> backup: /home/mir/site
* uma copia remotamente:
vserver marieta: /home/mir/site
4. backup main server/servidor principal ('hosts' & 'vhosts' conf)
roda/run -> 1 vez por mes
guarda/save
* localmente:
marieta: /mnt/backup/ -> backup: /home/marieta/
Backupninja
Configuracoes existentes
Politica de administracao
Links/Documentacoes - Leitura
Historico de edicao
--
SilvioRhatto - 08 Dec 2004
--
VitoR - 09 Dec 2004
--
SilvioRhatto - 12 Nov 2005
--
PietroFerrari - 17 Nov 2005 (minor editing)
--
SilvioRhatto - 21 Sep 2006
--
SilvioRhatto - 31 Oct 2006 - adicionei parâmetro JVM no script de sincronia
--
ToyaMileno - 07 Nov 2006
--
SilvioRhatto - 12 Dec 2006 - Transformei num manual de servidor genérico
--
SilvioRhatto - 14 Dec 2006 - Atualização geral, reformulação
--
SilvioRhatto - 15 Dec 2006 - Introdução
--
SilvioRhatto - 04 Jan 2007 - Atualização dos scripts de sincronia
--
ToyaMileno - 09 Jan 2007 - Adicionei a parte de "testando o espelho" - feita pelo rhatto durante trocas de email sobre a configuracao do espelho no aletta
--
SilvioRhatto - 09 Jan 2007 - Arrumei a formatação e o texto sobre teste de espelho
--
SilvioRhatto - 19 Jan 2007 - Pequena alteração
Historico de edicao desta pagina
--
ToyaMileno - 04 Oct 2007 (coloquei a info da pagina sobre admin dos servidores (antiga) aqui dentro para nao perder essa informacao - precisa atualiza-la)
--
ToyaMileno - 05 Jan 2008 atualizei a parte da documentacao sobre raid
--
AndreBianchi - 21 Feb 2008 - Iniciei a parte do kernel, sugeri alguns tópicos para serem cobertos e arrumei o /var no lugar de /vservers
--
MemBrana - 04 Apr 2008 -
to top
