Software Público Brasileiro: Manual de Operação (prod)

Universidade de Brasília

1 Introdução 1

2 Arquitetura 3

2.1 Servidores e serviços . . . 3

2.2 Gestão de configuração. . . 4

3 Implantação 5 3.1 Preparação da estação de trabalho . . . 5

3.2 Obtendo o repositório de configuração. . . 5

3.3 Preparação dos servidores . . . 6

3.4 Configuração do ambiente alvo . . . 6

3.5 Configuração do DNS . . . 7

3.6 Verificando o ambiente. . . 8

3.7 Nota sobre certificado SSL . . . 9

3.8 Primeira instalação . . . 9

3.9 Atualizações . . . 10

4 Manutenção 11 4.1 Mantendo o sistema atualizado . . . 11

4.2 Modificando configurações . . . 11 5 Backup 13 5.1 Procedimento de backup . . . 13 5.2 Procedimento de restauração. . . 13 6 Gestão do Firewall 15 6.1 Firewall Interno . . . 15 6.2 Comunicação externa . . . 16

Introdução

Bem-vindo a documentação do Portal do Software Público Brasileiro.

O Portal do Software Público Brasileiro (SPB) é uma plataforma de compartilhamento e colaboração no desenvolvi-mento de softwares. O projeto de evolução deste portal está sendo desenvolvido pela Universidade de Brasília. O SPB é composto de um conjunto de ferramentas com funcionalidades complementares, que são desenvolvidas de forma independentes pelas suas respectivas comunidades. Estas ferramentas estão sendo integradas pela nossa equipe de forma a apresentar uma experiência de usuário consistente.

• OColabé uma ferramenta especializada na integração de outras ferramentas. O Colab fornece um ponto central de autenticação de usuários para as demais ferramentas da plataforma, indexa informações das demais ferramen-tas para busca e gamificação, e fornece integração visual entre as diferentes ferramenferramen-tas que compõem o SOB. O Colab é um software livre criado no Brasil, que teve sua origem no Programa Interlegis do Senado Federal. • ONoosferoé uma plataforma para criação de redes sociais que conta com diversas funcionalidades de gestão

de conteúdo como blogs, galeria de imagens e vídeos, entre outros. O Noosfero também é um software livre criado no Brasil, iniciado em 2007 pelaCOLIVREe que hoje conta com uma comunidade de desenvolvimento que inclui o SERPRO, a Universidade de Brasília e o Fórum Brasileiro de Economia Solidária.

• OGitlabé uma plataforma para desenvolvimento colaborativo. Projetos no gitlab são mantidos em repositorios git, com gestão de tarefas (issue tracker), merge requests, gestão de marcos (milestones), suporte a integração com plataformas de integração contínua e notificações.

• OGNU Mailman é uma gerenciador de listas de email tradicionalmente usado por diversas organizações no Brasil e no mundo.

O restando deste manual descreve a arquitetura do SPB bem como os procedimentos necessários para sua implantação, manutenção, backup e restauração e gestão de firewall.

Arquitetura

A arquitetura do SPB consiste em 5 servidores, representados na figura a seguir.

2.1 Servidores e serviços

Esta seção é um trabalho em andamento. Ela cobrirá: • descrever arquitetura

• descrever papel de cada máquina • descrever conexões

2.2 Gestão de configuração

• adicionar links com o repositório de gestão de configuração • descrever repositório de gestão de configuração

• descrever como o chake funciona

Implantação

3.1 Preparação da estação de trabalho

Para gerenciar o SPB, é necessária uma estação de trabalho GNU/Linux, que pode ser Debian 8 ou posterior, Ubuntu 14.04 ou superior, ou CentOS 7 ou superior (e equivalentes como RHEL 7 ou superior, ou Fedora). O processo também pode ser feito em outros sistemas, desde que os pacotes equivalentes estejam instalados.

As seguintes ferramentas serão necessárias: • git: ferramenta de controle de versão. • chake: ferramenta de gestão de configuração. Para instalar em Debian/Ubuntu:

$ sudo apt-get install git ruby $ sudo gem install chake

Para instalar em CentOS/RHEL/Fedora:

$ sudo yum install git ruby $ sudo gem install chake

Além dessas ferramentas, será necessário um emulador de terminal. O emulador de terminal padrão do seu ambiente de trabalho, ou qualquer outro, vai servir.

3.2 Obtendo o repositório de configuração

Para iniciar, é necessário uma conta e usuário no SPB, com uma chave SSH configurada. Para obter o repositório de configuração, é necessário clonar o repositório com git:

$ git clone git@beta.softwarepublico.gov.br:softwarepublico/softwarepublico.git

A partir daqui, todos os passos serão executados de dentro do repositório, então se certifique que o seu shell está no diretório onde foi clonado o repositório:

3.3 Preparação dos servidores

• Os servidores precisam estar acessíveis por SSH. Caso necessário, podem ser feitas configurações do SSH em config/prod/ssh_configpara isso.

• O usuário que vai conectar via SSH nos servidores precisa:

– ter permissão de usar sudo sem a necessidade de digitar senha.

– ter acesso SSH configurado via chave SSH para evitar digitar senha, a partir da estação de trabalho utili-zada. Ou seja, a chave pública SSH da estação de trabalho deve ser copiada para cada servidor, e.g.:

$ ssh-copy-id reverseproxy $ ssh-copy-id integration $ ssh-copy-id social $ ssh-copy-id database $ ssh-copy-id email

• O sudo não deve estar configurado com a opção requiretty. Se houver uma linha como a seguinte em /etc/sudoers, ela deve ser removida (ou comentada, como preferir):

$ Defaults requiretty

• A máquina integration precisa ter o utilitário netcat. No CentOS 7, pode ser instalado o pacote nmap-ncat.

3.4 Configuração do ambiente alvo

O SPB tem o conceito de “ambientes”, que são diferentes instalações da mesma plataforma. Todas as in-formações específicas sobre um determinado ambiente estão centralizadas em arquivos dentro do diretório config/${ambiente}/. Por exemplo, o ambiente “local”, que se destina ao uso para desenvolvimento local com máquinas virtuais, possui o seguinte conteúdo:

$ find config/local/ | sort config/local/config.yaml config/local/ips.yaml config/local/ssh_config

Estes arquivos possuem a seguinte finalidade:

• config.yaml: Parâmetros gerais de configuração

• ips.yaml: Tabela de IP’s (na rede local) das máquinas que compõem o ambiente.

• ssh_config: Configuração necessária para o SSH. Pode ser um arquivo caso não seja necessária nenhuma configuração especial para acessar as máquinas (e.g. se você está na mesma rede local que elas.

Vamos agora verificar o conteúdo de cada arquivo no ambiente prod. Primeiro, config.yaml:

admins:

- ["Nayanne Araújo", "nayanne.bonifacio@planejamento.gov.br"] - ["Marisa Souza dos Santos", "marisa.santos@planejamento.gov.br"] external_hostname: portal.softwarepublico.gov.br

external_ip: 189.9.151.64 alt_ssh_port: 55555

site_url: https://portal.softwarepublico.gov.br

colab_from_address: '"Portal do Software Publico" <noreply@portal.softwarepublico.gov.br>'

server_email: '"Portal do Software Publico" <noreply@portal.softwarepublico.gov.br>'

relay_hostname: relay.portal.softwarepublico.gov.br relay_ip: 189.9.151.68

external_outgoing_mail_relay: 189.9.150.53 external_outgoing_mail_domain: serpro.gov.br

Para nossa sorte, o significado de cada um dos campo acima deve ser autoexplicativo.

O arquivo ips.yaml contém uma tabela com os endereços IP de cada servidor da plataforma na rede local. Exemplo:

reverseproxy: 10.21.0.4 database: 10.21.0.6 social: 10.21.0.5 email: 10.21.0.7 integration: 10.21.0.8

Já o arquivo ssh_config contém opções padrão de configuração do ssh para conexão às máquinas:

Host * ForwardAgent yes Host reverseproxy Hostname 10.21.0.4 Port 55555 ProxyCommand ssh 189.9.151.64 -p 22 nc %h 55555 Host reverseproxy.unconfigured Hostname 189.9.151.64 Host integration Hostname 189.9.151.64 Host database Hostname 10.21.0.6

# connect via reverseproxy host

ProxyCommand ssh 189.9.151.64 -p %p nc %h 22 Host social

Hostname 10.21.0.5

# connect via reverseproxy host

ProxyCommand ssh 189.9.151.64 -p %p nc %h 22 Host email

Hostname 10.21.0.7

# connect via reverseproxy host

ProxyCommand ssh 189.9.151.64 -p %p nc %h 22

3.5 Configuração do DNS

A tabela a seguir foi gerada dinamicamente a partir da configuração do ambiente prod. As seguintes entradas precisam ser configuradas no DNS:

Tipo Entrada Aponta para A portal.softwarepublico.gov.br 189.9.151.64 A listas.portal.softwarepublico.gov.br 189.9.151.64 A relay.portal.softwarepublico.gov.br 189.9.151.68

Tipo Entrada Aponta para

MX portal.softwarepublico.gov.br relay.portal.softwarepublico.gov.br. MX listas.portal.softwarepublico.gov.br relay.portal.softwarepublico.gov.br. Tipo Entrada Aponta para

PTR 189.9.151.64 portal.softwarepublico.gov.br. PTR 189.9.151.68 relay.portal.softwarepublico.gov.br.

Tipo Entrada Deve conter

TXT (SPF: “v=spf1 ...”) portal.softwarepublico.gov.br include:serpro.gov.br TXT (SPF: “v=spf1 ...”) listas.portal.softwarepublico.gov.br include:serpro.gov.br

3.6 Verificando o ambiente

$ rake nodes SPB_ENV=prod

O comando acima deve dar o seguinte resultado:

integration ssh

email ssh

social ssh

database ssh

reverseproxy ssh

Note que todas as vezes que formos chamar rake, será preciso informar sobre qual ambiente desejamos operar (SPB_ENV=prod). Caso você for operar sobre apenas um ambiente, ou caso você queira evitar digitação, você pode criar um arquivo local.rake na raiz do repositório com o seguinte conteúdo:

ENV['SPB_ENV'] ||= 'prod'

Isto fará com que o valor e SPB_ENV seja sempre prod, a não ser que você informe na linha de comando. Daqui para frente, vamos sempre exibir o parâmetro SPB_ENV=prod, mas lembre-se que ele pode ser omitido se você tiver configurado o default em local.rake.

Para testar a conectividade às máquinas, podemos executar um comando nelas:

$ rake run SPB_ENV=prod $ <PROMPT PARA VOCÊ DIGITAR>

No prompt, entre um comando simples como sudo date. O resultado deve ser parecido com o seguinte:

$ rake run SPB_ENV=prod $ sudo date

integration: $ sudo date

integration: Qui Mai 14 18:59:19 BRT 2015 email: $ sudo date

email: Qui Mai 14 18:59:22 BRT 2015 social: $ sudo date

social: Qui Mai 14 18:59:24 BRT 2015 database: $ sudo date

Se o resultado se parece com o exemplo acima, e você não precisou digitar a sua senha nehuma vez, significa que 1) você conseguiu conectar em todas as máquinas e 2) o sudo sem senha está configurado corretamente. Está tudo certo para começar!

3.7 Nota sobre certificado SSL

O repositório de gestão de configuração não contém os par de chaves do cerficado SSL para o domínio por-tal.softwarepublico.gov.br. Antes de realizar a implantação, você deve colocar o par de chaves nos seguintes locais:

• cookbooks/reverse_proxy/files/host-reverseproxy/portal.softwarepublico.gov.br.crt: certificado (chave pública), em formato PEM.

• cookbooks/reverse_proxy/files/host-reverseproxy/portal.softwarepublico.gov.br.key: chave privada, em formato PEM.

Para uma melhor segurança da chave privada, e recomendado que a mesma seja criptografada com GnuPG, o que é suportado pela ferramente de implantação chake. Isso pode ser feito da seguinte maneira:

$ cd cookbooks/reverse_proxy/files/host-reverseproxy/ # criptografar:

$ gpg --encrypt --recipient XXXXXXXX --output portal.softwarepublico.gov.br.key.gpg portal.softwarepublico.gov.br.key # conferir que o conteúdo descriptografado está OK:

$ gpg --decrypt portal.softwarepublico.gov.br.key.gpg # apagar o arquivo sem criptografia:

$ rm portal.softwarepublico.gov.br.key # retornar ao diretório de origem $ cd

-XXXXXXXXdeve ser substituído pelo ID da chave que está sendo usada para criptografar.

Antes de fazer a implantação, o chake vai enviar a chave privada descriptografada apenas à máquina que vai ser o frontend HTTPS. Caso sua chave GnuPG necessite de uma senha para ser usada, ela será solicitada.

3.8 Primeira instalação

Uma vez configurados os parâmetros em config/prod/, podemos dar início à instalação. O primeiro passo é uma preconfiguração que precisamos fazer:

$ rake preconfig SPB_ENV=prod

Este comando vai fazer uma configuração inicial que é necessária para o resto do processo, e só é necessária fazer uma vez.

Depois de completo o procedimento acima, para aplicar as configurações a todos os servidores basta executar:

$ rake converge SPB_ENV=prod

O comando converge na verdade é o default, então o seguinte é equivalente:

Se você tiver configurado o ambiente prod no local.rake (ver instruções acima), então o comando seguinte, também equivalente, é muito mais simples:

$ rake

Todas as possibilidades de comandos serão listados se você executar rake -T. Consulte também a documentação do

chake.

3.9 Atualizações

Para atualizar o sistema, primeiro atualize o repositório de gestão de configuração:

$ git pull

Após isso, basta executar o comando converge novamente:

$ rake converge SPB_ENV=prod

Manutenção

4.1 Mantendo o sistema atualizado

4.2 Modificando configurações

Backup

O SPB possui rotinas automatizadas para backup e restore dos dados de todos os seus componentes. As seções a seguir descrevem estas rotinas. Ambos os procedimentos devem ser realizados num shell onde o diretório atual é o repositório de controle de versão do SPB.

5.1 Procedimento de backup

Suponha que estamos realizando um backup do ambiente de produção, chamado de prod; o comando para realizar um backup é o seguinte (note SPB_ENV=prod):

$ rake backup SPB_ENV=prod

Esta operação vai copiar arquivos e dumps dos bancos de dados do Noosfero, GitLab, Colab e Mailman, e copiá-los para um subdiretório chamado backups na sua estação de trabalho.

5.2 Procedimento de restauração

Importante: o procedimento de restauração é suportado apenas para uma versão idêntica da plataforma, ou seja, não é suportado fazer um backup de uma versão mais antiga da plataforma e restaurar esse backup numa versão mais recente da plataforma, e nem vice-versa.

O comando para restaurar um backup no ambiente prod é o seguinte:

$ rake restore SPB_ENV=prod

Esta operação vai restaurar o último backup realizado no ambiente chamado prod.

Importante: a restauração do backup irá apagar os dados existes no ambiente prod. Confira duas vezes antes de iniciar o procedimento.

Gestão do Firewall

6.1 Firewall Interno

O Portal do Software Público atualmente é composto por diversos serviços funcionando em diferentes servidores. Para o seu correto funcionamento é esperado que estes serviços se comuniquem através de TCP/IP.

Os scripts de instalação do Portal do Software Público também cuidam da manutenção das regras de firewall. Cada máquina possui um firewall (iptables) local que por padrão nega todos os tipos de conexão de entrada em todas as portas (INPUT rules) mas permite conexões de saída (OUTPUT rules).

Todas as regras de firewall são definidas no cookbook firewall. Para definir regras de comunidacação entre hosts locais, válidas para todos os ambientes (local, produção, homologação, testes, etc) são utilizados templates que podem ser encontrados em cookbooks/firewall/templates/. Para regras de filtro utilize o arquivo iptables-filter.erbe para regras de NAT o arquivo iptables-nat.erb.

Para adicionar regras específicas de cada ambiente (por exemplo, abrir uma porta diferente em homologação) utilize o arquivo config/prod/iptables-filter-rules. Este arquivo aceita apenas regras de filtro do tipo INPUT.

6.1.1 Comunicação Entre Serviços

Os serviços que compõe o portal e suas portas de entrada são descritos na tabela a seguir:

Destino Origem Serviço Porta

database integration Redis 6379

database integration PostgreSQL 5432

database social PostgreSQL 5432

social reverseproxy Nginx 80

social reverseproxy Nginx 443

integration reverseproxy Nginx 80 integration reverseproxy Nginx 443

email externa Postfix 25

reverseproxy externa Nginx 80

reverseproxy externa Nginx 443

6.2 Comunicação externa

Destino Serviço Porta

email Postfix 25

reverseproxy Nginx 80

reverseproxy Nginx 443

reverseproxy OpenSSH (git) 22 Outros firewalls da rede:

Além do firewall local é importante que os serviços com origem externa tenham suas portas de INPUT abertas em todos os firewalls da rede. No caso do host email a porta 25 também deve estar aberta para OUTPUT (alternativa-mente o Postfix pode ser configurado para enviar e-mails utilizando um relay interno).