Padr\xE3o Sarav\xE1 Vers\xE3o Debian
\xCDndice
Licen\xE7a
Esta
documenta\xE7\xE3o foi desenvolvida e escrita originalmente por Silvio Rhatto e pelo Coletivo
Sarav\xE1.
Copyright (c) Coletivo Sarav\xE1. \xC9 garantida a permiss\xE3o para copiar, distribuir e/ou modificar este documento sob os termos da Licen\xE7a de Documenta\xE7\xE3o Livre GNU (GNU Free Documentation License), Vers\xE3o 1.2 ou qualquer vers\xE3o posterior publicada pela Free Software Foundation; sem Se\xE7\xF5es Invariantes, Textos de Capa Frontal, e sem Textos de Quarta Capa. Uma c\xF3pia da licen\xE7a \xE9 inclu\xEDda na se\xE7\xE3o intitulada "GNU Free Documentation License".
O Padr\xE3o Sarav\xE1
O Padr\xE3o Sarav\xE1 foi feito originalmente para o sistema operacional slackware, ele \xE9 uma sistematiza\xE7\xE3o de configura\xE7\xE3o de servidores, gerenciadores de conte\xFAdo e aplica\xE7\xF5es diversas usados pelo Projeto Sarav\xE1. O padr\xE3o foi desenvolvido para:
- Ter o controle total dos pacotes utilizados e arquivos de configura\xE7\xE3o
- Uniformidade de administra\xE7\xE3o
- Sistema de gerenciamento de backups comum para que as m\xE1quinas de um projeto possam trocar dados
- Que um servidor seja configurado apenas uma vez e que suas configura\xE7\xF5es possam ser aproveitados para outras m\xE1quinas
- Que sites e servi\xE7os sejam armazenados de maneira regular para facilitar atualiza\xE7\xF5es e migra\xE7\xF5es
- Manter projetos e servi\xE7os isolados uns dos outros atrav\xE9s de servidores virtuais
- Tornar a instala\xE7\xE3o dos servidores facilmente replic\xE1vel
O Padr\xE3o Sarav\xE1 n\xE3o cont\xE9m a configura\xE7\xE3o completa para servidores, mas sim apenas o padr\xE3o de como os procedimentos devem ser efetuados, considerando que a configura\xE7\xE3o necess\xE1ria j\xE1 esteja em uso. O coletivo sysadmins do CMI Brasil optou por seguir esse padr\xE3o como proposta de processo para administra\xE7\xE3o do servidor marieta.
O Padr\xE3o Sarava Versao Debian - Marieta
Como sugerido no texto escrito na se\xE7\xE3o
introdu\xE7\xE3o - Administracao dos servidores da documenta\xE7\xE3o antiga do coletivo:
Introdu\xE7\xE3o - Administracao dos servidores O Indymedia \xE9 um projeto que utiliza muitos servidores espalhados pelo mundo todo. Para que n\xE3o haja confus\xE3o no que cada m\xE1quina hospeda e como ela foi configurada, \xE9 importamte que os procedimentos sejam bem documentados. Esta p\xE1gina cont\xE9m os procedimentos utilizados para configurar servidores administrados pelo Coletivo T\xE9cnico do CMI Brasil.
Esta documenta\xE7\xE3o est\xE1 longe de ser conclu\xEDda. Al\xE9m do que est\xE1 escrito aqui, \xE9 preciso criar procedimentos padr\xF5es para todas as tarefas. A exemplo do Projeto Sarav\xE1, que criou diversos padr\xF5es e do Riseup, que possui seu Grim\xF3rio Debian o Coletivo T\xE9cnico pode definir seus pr\xF3prios procedimentos. Fica como sugest\xE3o:
- Definir o Debian como distribui\xE7\xE3o de GNU/Linux padr\xE3o do Coletivo T\xE9cnico
- Usar, sempre que poss\xEDvel, o "jeito debian" de se fazer as coisas
- Criar uma pol\xEDtica de administra\xE7\xE3o padr\xE3o para todos os servidores
- Procurar sempre as solu\xE7\xF5es simples e dur\xE1veis
A seguir, fique com os procedimentos j\xE1 estabelecidos. Boa leitura!
Quando recebemos a doa\xE7\xE3o do servidor marieta, resolvemos adotar o procedimento da
documenta\xE7\xE3o do padrao sarava e suas sugest\xF5es de configura\xE7\xF5es de servidores usando vservers. O Coletivo Tecnico do CMI utiliza o sistema operacional Debian nos seus servidores e vservers, j\xE1 a documenta\xE7\xE3o padrao.sarava.org usa o slackware. Por causa dessa diferen\xE7a que modifica alguns procedimentos (por exemplo o script de atualizacao do kernel, repositorio de pacotes etc), resolvemos criar uma documenta\xE7\xE3o 'vers\xE3o debian'.
Visao Geral
Procedimento de instala\xE7\xE3o
Inicia-se com a instala\xE7\xE3o do sistema b\xE1sico do debian. A escolha da distribui\xE7\xE3o foi o Etch.
Na configura\xE7\xE3o do host de servicos que estavam de p\xE9 para o ip da maquina nos deparamos com alguns servicos que s\xE3o colocados pelo debian na instalacao padr\xE3o 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.
Posteriormente foi feito o upgrade para o debian 5.0 - Lenny.
exemplo debian-installer etch com raid 1 + lvm + criptografia de disco
segue o exemplo:
dois HDs 1 TB
particionamento igual para os dois HDs:
500 MB Raid 1 - /boot
2 GB Raid 1 criptografada com chave aleatoria - swap
Restante GB Raid 1 lvm
volume lvm1 20 GB - /
volume lvm2 restante GB - criptografada com Passphrase - /var/vservers
pensando numa maquina com alguns/umas adms apenas e focado em base de dados, apache.. por isso sem particao para /home onde poderia setar restricoes de execucao.
No instalacao do debian, no particionador (partman) \xE9 poss\xEDvel fazer o raid, lvm e criptografia com dm-crypt.
Cuidado em deixar como ide na bios e n\xE3o raid, pois vamos fazer via software.
Os passos s\xE3o:
- Escolher particionamento manual
- criar nova tabela de partic\xE3o para sda e sdb (no caso hds sata)
em sda:
- criar nova partic\xE3o primaria, no inicio, 500 MB, usar como raid
- criar nova partic\xE3o primaria, no inicio, 2 GB, usar como raid
- criar nova partic\xE3o primaria, no inicio, restante GB, usar como raid
repetir os passos acima para sdb.
- ir em configurar software raid
criar md device, escolher raid 1 e escolher sda1 e sdb1 (as duas de 500 MB)
repetir para os pares (sda2 e sdb2) e (sda3 e sdb3)
- voltar no particionador
- em Raid 1 device #0, entrar na particao de 500 MB e usar como ext2, /boot, blocos reservados: mudar para 0.
- em Raid 1 device #1, entrar na particao de 2 GB e configurar physical volume for encryption com chave aleatoria e depois setar para swap
- em Raid 1 device #2, configurar para physical volume for lvm
- ir agora em configure logical volume manager
create group volume: ex. vg_main - escolher a particao
create logical volume: colocar nome: root, setar para 20GB
create logical volume: colocar nome: vserver, usar tamanho restante
- finalizar e voltar ao particionador
- no volume da particao de 20 GB - colocar ext3 e /
- no outro volume escolher physical volume for encryption com passphrase e depois setar para /var/vservers
Seguir com o procedimento normal de instalac\xE3o. Sempre que reiniciar a maquina tem de colocar a senha criada no particionamento. \xC9 poss\xEDvel tamb\xE9m usar a chave em um pendrive.
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 \xE9 conforme apresentado abaixo no item atualiza\xE7\xE3o do kernel.
Atualiza\xE7\xE3o 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\xF3digo fontes do kernel ser\xE1 instalados em
/usr/src/linux-source-2.x.yy.tar.bz2
(onde 2.xx.yy \xE9 na verdade a vers\xE3o do kernel) e dois patches devem ser aplicados para habilitar o vserver no kernel (a motiva\xE7\xE3o para a aplica\xE7\xE3o 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\xE1ria, copie a configura\xE7\xE3o original (.config) para o novo diret\xF3rio tempor\xE1rio 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\xE3o que podemos desenvolver. Ser\xE1 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 \xE9 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\xE7\xE3o vai alterar o arquivo
/boot/grub/menu.lst
e configurar este novo kernel como padr\xE3o. Podemos alterar este arquivo, caso queiramos testar o novo kernel antes de coloc\xE1-lo em produ\xE7\xE3o.
Servidores Virtuais
Implementa\xE7\xE3o dos VServers
Os vservers est\xE3o no diret\xF3rio
/var/vservers
, e portanto mantemos o
/var
numa parti\xE7\xE3o separada, utilizando RAID 5.
Prepara\xE7\xE3o do host
Aplicamos o patch linux-image-2.6-vserver-amd64. Instalamos tamb\xE9m o util-vserver. Depois come\xE7amos a configurar o host seguindo as instru\xE7\xF5es da documenta\xE7\xE3o feita pelo [[http://riseuplabs.org/grimoire/vserver/][Riseup]] que tamb\xE9m usa Debian. Come\xE7amos da parte: [[http://riseuplabs.org/grimoire/vserver/preparing/#set_up_the_general_vserver_directories_including_the_barrier][para criar as barreiras de seguran\xE7a no vserver]].
Para entender mais sobre como funciona um vserver e o que s\xE3o estas coisas que estamos mencionando na documenta\xE7\xE3o, recomendamos a leitura do documento: [[http://slack.sarava.org/vservers][Linux VServers e seguran\xE7a por contexto]]
Seguindo o tutorial do Riseup, configuramos o host para que os servi\xE7os apontassem para o ip da maquina. Nessa jornada, aproveitamos para retirar alguns servi\xE7os que s\xE3o instalados automaticamente pelo Debian em sua instala\xE7ao. Retiramos o nfs-common para acabar com o rcp.statd e outras coisas que estavam rodando na Marieta por causa dele e tamb\xE9m o portmap, que funciona s\xF3 pro causa do nfs.
Antes de criar a primeira inst\xE2ncia de vserver, nos tivemos uma discuss\xE3o sobre usar um ip real para cada vserver ou compartilhar um \xFAnico ip real entre os vserver. O grande dilema foi que seria poss\xEDvel ter pelo menos uns 2/3 vservers com ip real, mas \xE9 muito dif\xEDcil conseguir mais ips do que isso, caso n\xF3s quisessemos expandir.
Por isso optamos em seguir um tutorial que explicasse como configurar o host para ter vservers que compartilhem um \xFAnico ip real (o ip da m\xE1quina).
O documento [[http://slack.sarava.org/vservers][Linux VServers e seguran\xE7a por contexto]] explica sobre isso e tambem em [[http://padrao.sarava.org/engine/SlackwareVservers][padrao.sarava slackware vservers]]
Apos instalacao do kernel com o patch e do util-vserver, importante setar o diretorio de instalacao dos vservers:
# mkdir /var/vservers
# rm /etc/vservers/.defaults/vdirbase
# ln -s /vservers/var /etc/vservers/.defaults/vdirbase
# setattr --barrier /var/vservers
Come\xE7amos criando o primeiro vserver, vserver mir. At\xE9 o momento o plano \xE9 criar tr\xEAs vservers:
* *MIR* - onde vamos rodar todos os servi\xE7os relacionados com o CMS MIR.
* *Backup* - para hospedar backups de outros coletivos e nosso pr\xF3prio backup
* *Mirror* - para hospedar espelhos de outros coletivos da rede.
Alguns passos da documentacao citada acima: Para ver contextos livres:
# vserver-stat
setando aplicacoes nao necessarias no vserver:
# REMOVE_PACKAGES="dhcp-client,iptables"
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\xE7a do proc
Retirado do documento - [[http://slack.sarava.org/vservers][Linux VServers e seguran\xE7a por contexto]]:
O proc \xE9 o sistema de arquivos que faz a interface entre o espa\xE7o do usu\xE1rio e as estruturas de dados do kernel. No proc ficam tipicamente listadas informa\xE7\xF5es como processos e estado da rede e podem ser utilizado para controlar par\xE2metros do kernel. \xC9 importante evitar que muitas dessas informa\xE7\xF5es estejam indispon\xEDveis dentro dos vservers e por padr\xE3o algumas dessas entradas (como as informa\xE7\xF5es de processos de outros contextos) j\xE1 estar\xE3o escondidas.
Mas a configura\xE7\xE3o padr\xE3o n\xE3o esconde tudo, deixando isso para ser realizado pelo administrador ou a um script. Essa "seguran\xE7a" do proc \xE9 feita com o comando setattr, anteriormente usado para criar a barreira dos vservers. Mudar a visibilidade das entradas no /proc nada mais \xE9 do que manipular os atributos extendidos dessas entradas, por isso o uso do setattr.
\xC9 prefer\xEDvel fazer essa parte, depois de termos colocado todos os servi\xE7os que queremos rodando dentro do vserver mir em funcionamento. Desta forma saberemos quais s\xE3o os que usam os arquivos desse diret\xF3rio e quais os que devemos impedir o acesso pelo vserver.
Compartilhando um \xFAnico ip real
Retirado do documento - [[http://slack.sarava.org/vservers][Linux VServers e seguran\xE7a por contexto]]:
Roteamento de rede
O roteamento de rede e o controle da banda para os vservers \xE9 feito com a infra-estrutura j\xE1 existente no GNU/Linux (iptables, iproute2, etc). Aqui consideramos o caso de vservers que tanto podem acessar m\xE1quinas remotas quanto receber conex\xF5es entrantes da internet.
A primeira medida \xE9 estabelecer a tradu\xE7\xE3o de endere\xE7os via NAT se o vserver n\xE3o possuir IP real. Isso \xE9 feito usualmente e depende do sistema de firewall que voc\xEA est\xE1 utilizando. O mais simples \xE9 um iptables direto. Considerando que a faixa de IPs para os seus vservers \xE9 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 \xE9 o endere\xE7o real da sua interface. Em seguida, temos que rotear as conex\xF5es entrantes para as respectivas aplica\xE7\xF5es 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\xE3o 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\xEDdo ao vserver, este tipo de roteamento n\xE3o \xE9 necess\xE1rio.
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\xE7\xF5es:
1. "Deixar uma parti\xE7\xE3o livre para um sistema reserva" - \xE9 uma boa dica do rhatto 2. Deixar uma parti\xE7\xE3o para boot em cada um dos 4 discos -> dica do zapata 3. Os vservers se encontram no diret\xF3rio
/var/vservers/
e por isso mantemos o
/var/
numa parti\xE7\xE3o separada e utilizamos RAID 5 que implementa redund\xE2ncia e soma de espa\xE7os.
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\xE7\xE3o |
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\xFAltiplos servi\xE7os, tais como abrigar uma poss\xEDvel morada alternativa para docs.indymedia.org e outros servi\xE7os. Pensamos na quest\xE3o da complexidade tamb\xE9m, 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\xE7o:
Por cima disso, seriam ent\xE3o:
- 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\xE7\xE3o feita dentro do vserver que hospeda os sites. A descri\xE7\xE3o est\xE1 aqui:
https://docs.indymedia.org/view/Sysadmin/VServerMirMarieta#webalizer
Servicos
Firewall
Come\xE7amos com o firewall, configurando o shorewall.
descri\xE7\xE3o: shorewall derteminar\xE1 a configura\xE7\xE3o b\xE1sica. shorewall \xE9 apenas uma ferramenta que configura iptables. shorewall permiter assim uma configura\xE7\xE3o de alto-n\xEDvel (mais amig\xE1vel)
instala\xE7\xE3o:
apt-get install shorewall shorewall-doc
configura\xE7\xE3o: 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 \xE9 uma parte de uma rede. Definimos 3 zones: fw \xE9 o firewall, net \xE9 a internet e vm \xE9 vms
editando policy
shorewall trabalha com uma "policy" para a politica geral e um arquivo "rules" como extens\xE3o 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\xE1fico saindo de eth1 mas n\xE3o 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\xE1 o risco dele nos impedir de acessar a m\xE1quina caso tenha alguma configurac\xE3o errada, ent\xE3o \xE9 recomend\xE1vel adicionar o ip de quem est\xE1 fazendo a configura\xE7\xE3o neste arquivo para estar fora das regras do shorewall por garantia.
testando e inicializando o shorewall
shorewall check
shorewall safe-start
Na pasta /usr/share/shorewall/ tem outros arquivos defaults. Por exemplo tem o rfc1918 que determina que certos endere\xE7os sejam reservados e n\xE3o sejam usados na intenet. \xC0s vezes \xE9 preciso editar esse arquivo copiando ele para /etc/shorewall/ para permitir que derterminada rede tamb\xE9m tenha acesso ao servidor, no caso de uma dmz por exemplo.
Apache
instala\xE7\xE3o
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\xE3o logar ip
por padr\xE3o 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\xE3o o apache faz log tb quando usu\xE1rio entra com url errada, para desabilitar isso deve-se editar em cada arquivo de configura\xE7\xE3o 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\xE7\xF5es necess\xE1rias
#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
obs: no comando openssl s\xE3o feitas algumas perguntas como nome do pa\xEDs, institui\xE7\xE3o.... e o common name que se o o site for acessado por
http://midiaindependente.org/ \xE9 midiaindependente.org, se quizer usar m\xFAltiplos dom\xEDnios como
http://dev.midiaindependente.org/,
http://ticket.midiaindependente.org/ ...usar no common name *.midiaindependente.org
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\xE9m 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)
Monitoramento da servidora com o Munin
Para monitoramento dos recursos de hardware, banda, load...
Instala\xE7\xE3o nos clientes ou maquinas virtuais:
apt-get install munin-node
configurando o munin-node:
vim /etc/munin/munin-node.conf
Alterando:
allow ^127\.0\.0\.1$
allow ^200\.200\.200\.200$ #IP do Munin Server
allow ^192\.168\.0\.101$
host 192.168.0.101
port 4949
Em seguida adicionar plugins para o apache que faltam:
cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/apache_* .
E reiniciar o servi\xE7o:
/etc/init.d/munin-node restart
Na m\xE1quina principal ou host ou servidor que ficar\xE1 o munin server:
apt-get install munin munin-node munin-plugins-extra
Configurando os pluigins que faltam (para monitorar os vservers - contidos em munin-plugins-extra instalado acima)
cd /etc/munin/plugins
ln -s /usr/share/munin/plugins/vserver_resources .
ln -s /usr/share/munin/plugins/vserver_loadavg .
ln -s /usr/share/munin/plugins/vserver_cpu_ .
configurando o munin-node:
vim /etc/munin/munin-node.conf
allow ^127\.0\.0\.1$
# host *
host 127.0.0.1
port 4949
E a configura\xE7\xE3o do servidor:
vim /etc/munin/munin.conf
# a simple host tree
[marieta.indymedia.org]
address 127.0.0.1
use_node_name yes
[mir.marieta.indymedia.org]
address 192.168.0.101
use_node_name yes
Reiniciar o servi\xE7o:
/etc/init.d/munin-node restart
Proteger a pasta munin de no apache: a2enmod auth_digest
htdigest -c /var/www/munin/.htpasswd munin nomeuser
vim /etc/apache2/sites-available/default
<Directory /var/www/munin/>
Options FollowSymLinks
AllowOverride None
#authentification
AuthType Digest
AuthName "munin"
AuthUserFile /var/www/munin/.htpasswd
require valid-user
</Directory>
/etc/init.d/apache2 restart
acessar em:
https://ip.da.servidora/munin
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\xE2metro JVM no script de sincronia
--
ToyaMileno - 07 Nov 2006
--
SilvioRhatto - 12 Dec 2006 - Transformei num manual de servidor gen\xE9rico
--
SilvioRhatto - 14 Dec 2006 - Atualiza\xE7\xE3o geral, reformula\xE7\xE3o
--
SilvioRhatto - 15 Dec 2006 - Introdu\xE7\xE3o
--
SilvioRhatto - 04 Jan 2007 - Atualiza\xE7\xE3o 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\xE7\xE3o e o texto sobre teste de espelho
--
SilvioRhatto - 19 Jan 2007 - Pequena altera\xE7\xE3o
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
--
DrebS - 21 Feb 2008 - Iniciei a parte do kernel, sugeri alguns t\xF3picos para serem cobertos e arrumei o /var no lugar de /vservers
--
MemBrana - 04 Apr 2008 - complementos
--
MemBrana - 22 Jun 2009 - recuperando o texto sobre o exemplo debian-installer etch com raid 1 + lvm + criptografia de disco
--
MemBrana - 23 Jun 2009 - ajuste na parte de criacao dos vservers
--
MemBrana - 19 Aug 2009 - add debian lenny, obs ssl, obs shorewall
--
MemBrana - 05 Nov 2009 - monitoramento com munin