Software Público Brasileiro

Manutenção
==========

Mantendo o sistema atualizado
-----------------------------

É importante que não apenas os software relacionados ao Portal do SPB sejam
mantidos atualizados, mas também outros pacotes do sistema provenientes dos
repositórios oficiais da distribuição utilizada. Tais atualizações são
tratadas pelos scripts de gestão de configuração do ambiente, de modo que
para que se mantenha todo o sistema atualizado, basta seguir os passos de
atualização do Portal do SPB na seção de Implantação, ou seja::

    $ git pull
    $ rake converge SPB_ENV=@@SPB_ENV@@

Modificando configurações
-------------------------

Como descrito na seção de Implantação, as configurações específicas de
um determinado ambiente se encontram centralizadas nos arquivos presentes em
``config/${ambiente}/``, de modo que em caso de necessidade de alterações nas
configurações, deve-se recorrer a tais arquivos.

* ``config.yaml``

  * Administradores do sistema

  * Nome dos domínios (Portal, relay e mailman)

  * IP's externos para reverseproxy e relay

  * Porta de SSH para conexão interna à reverseproxy

  * Outras configurações relevantes para o sistema

* ``ips.yaml``

  * IP's (rede local) das máquinas descritas na seção de Arquitetura

* ``ssh_config``

  * Arquivo de configuração para conexões SSH.

Ao se modificarem configurações do ambiente que sejam permanentes, é
interessante que as mesmas sejam refletidas também nos repositórios de
gestão de configuração, para tal, contate os mantenedores do portal em
spb-dev@listas.softwarepublico.gov.br.

Obtendo logs
------------

Os seguintes arquivos a seguir contém logs relevantes para o Portal do SPB, de
modo que é interessante monitorá-los, note que os arquivos estão organizados
por máquinas.

* Social

  * /var/log/nginx/noosfero.access.log

  * /var/log/nginx/noosfero.error.log

  * /var/log/noosfero/\*

  * /var/log/rsnapshot

* Integration

  * /var/log/nginx/colab.access.log

  * /var/log/nginx/colab.error.log

  * /var/log/nginx/mailman.access.log

  * /var/log/nginx/mailman.error.log

  * /var/log/nginx/gitlab.access.log

  * /var/log/nginx/gitlab.error.log

  * /var/log/colab/colab.log

  * /var/log/gitlab-shell/gitlab-shell.log

  * /var/log/gitlab/unicorn.stderr.log

  * /var/log/gitlab/unicorn.stdout.log

  * /var/log/gitlab/application.log

  * /var/log/gitlab/production.log

  * /var/log/gitlab/sidekiq.log

  * /var/log/mailman/smtp

  * /var/log/mailman/qrunner

  * /var/log/mailman/error

  * /var/log/rsnapshot

* Database

  * /var/log/redis/redis.log

  * /var/lib/pgsql/data/pg_log/\*

* Reverseproxy

  * /var/log/nginx/ssl-\*.access.log

  * /var/log/nginx/ssl-\*.error.log

Alterando Limite de Upload das Ferramentas
------------

Nas ferramentas existe um limite de tamanho para upload dos arquivos.
Esta configuração é feita nos arquivos da receita de automação e pode
ser alterada. **Importante**: essa alteração é realizada na receita de
automação e pode causar efeitos colaterais durante o *converge*.


* **Gitlab**: o *template* `cookbooks/gitlab/templates/nginx.conf.erb` carrega as
configurações do servidor web. A variável `client_max_body_size` define
o limite de tamanho para uma requisição. O valor é definido com `<valor>m`,
exemplo `client_max_body_size = 20m`. Coloque `0` para desabilitar a checagem.
Consulte a documentação [Nginx](http://nginx.org/en/docs/http/ngx_http_core_module.html)
para mais informação.

* **Noosfero**: o procedimento é o mesmo definido para o **Gitlab**. O *template*
a ser alterado `cookbooks/noosfero/templates/nginx.conf.erb`. Outro arquivo a
ser alterado `cookbooks/noosfero/files/noosfero.yml` a variável `max_upload_size`
é definido em `<valor>MB`, exemplo `max_upload_size: 500MB`.

* **Reverseproxy**: todas as requisições passam pela máquina reverseproxy. Portanto
o maior limite de todas as aplicações deve ser colocado na configuração
do Nginx `cookbooks/reverse_proxy/templates/reverse_proxy.conf.erb` na variável
`client_max_upload_size`. O valor deve ser definido como `<valor>m`. Exemplo
`client_max_body_size = 500m` sendo 500m o maior limite entre as ferramentas.

Atualizando Certificado Digital
---------------

A atualização do certificado digital do Portal é feito através das receitas Chef
(especificamente esta: `cookbooks/reverse_proxy/recipes/default.rb`), e os mesmos
se tornam disponíveis na máquina `reverseproxy`. Entretanto deve-se estar atento
para o nome dos arquivos e o formato dos mesmos.

Ao gerar o certificado digital deverão ser gerados dois arquivos: o certificado
e a chave. O certificado deve estar no formato x509 e recomenda-se que a chave
seja gerada usando o algoritmo de criptografia RSA. Tendo isso, o nome dos arquivos
devem seguir o que é especificado na receita, que usa a variável
`node['config']['external_hostname']` do arquivo de configuração, sendo essa
variável o domínio do ambiente (por exemplo, 'softwarepublico.gov.br'). O nome
dos arquivos devem seguir o seguinte padrão:

+ Certificado: $external_hostname.crt (nome do domínio com extensão crt)
+ Chave: $external_hostname.key (nome do domínio com extensão key)

Com os arquivos no formato e nomenclatura corretos basta colocá-los no diretório
`cookbooks/reverse_proxy/files/host-reverseproxy/` e convergir o ambiente
normalmente.

Nota Ferramenta Gitlab
------------

Atualmente o SPB está utilizando o Gitlab versão 7.6.2 mantido no repositório
de pacotes RPM Softwarepublico `Copr Fedora` . O pacote é criado e mantido
pelo SPB, ou seja, a instancia do Gitlab contém as configurações necessárias
para a integração com as ferramenta e ambiente do SPB. Os pacotes de instação
providos pelo próprio Gitlab não tem a garantia de funcionamento com o SPB.

Há uma atualização do pacote Gitlab v8.5.0 disponível no projeto *eperimental* no
mesmo repositório ( Softwarepublico `Copr Fedora` ) . O serviço é instanciado
e é possível utiliza-lo em *stand alone*. Entretanto não foi realizado a
integração e testes do novo pacote com o ambiente e ferramentas do SPB.

.. _`Copr Fedora`: https://copr.fedorainfracloud.org/coprs/softwarepublico/