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=prod 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 `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 `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 `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/