Descobrindo a versão do Ubuntu:

Descobrindo informações da máquina:

Ou:

Para que todos os desenvolvedores possam atualizar um sistema através do Git, o clone do repositório NÃO deve incluir a conta pessoal de quem fizer a primeira instalação. Uma forma de fazer isso é editar o arquivo .git/config e retirar o trecho nome_usuario@ que ficar na seção [remote "origin"], associada à chave url. Por exemplo:

...
[remote "origin"]
    url = https://bitbucket.org/puc-rio/sapolio.git
    fetch = +refs/heads/*:refs/remotes/origin/*
...

Um túnel via ssh serve para ter acesso a uma máquina (ou porta de uma máquina) em uma rede inacessível diretamente, usando uma máquina intermediária que serve de ponte entre a sua local e a destino.

No nosso caso, como as duas únicas portas de acesso à máquina intermediária (Satoro) são as 32122 (ssh) e 80 (http), não temos como ter acesso externo a nenhuma outra máquina das redes da PUC. Assim, o jeito de chegar à máquina assinaturadigital-api.dsi.puc-rio.br, por exemplo, é fazer um túnel através do Satoro para redirecionar as conexões para ela.

Explicando:

porta local é a entrada do túnel, portanto é a porta que você deve usar para se conectar

máquina destino é a máquina que você quer alcançar

porta destino é a porta na máquina destino

seu usuário é o nome do usuário na máquina intermediária, que é quem vai fazer o redirecionamento

Em outras palavras, todas as conexões feitas através da porta local são redirecionadas pelo Satoro para a máquina destino.

Exemplo:

No navegador

Através dessa porta local chega-se à porta especificada na máquina destino através do túnel!

O Nobreak SMS (Senoidal Inteligente) do alfa possui um aplicativo para gerenciamento de energia. Ele pode ser acessado através do endereço:

alfa.vrac.puc-rio.br:7070/sms

Caso esta página não esteja abrindo o aplicativo, siga os passos abaixo para inicializá-lo.

O Nobreak SMS (Senoidal Inteligente) do alfa possui um aplicativo para gerenciamento de energia. Nele, são definidas algumas configurações de funcionamento do nobreak. Elas devem ser aplicadas na seguinte página:

http://alfa.vrac.puc-rio.br:7070/sms/editarTelaConfiguracoes.do

As configurações a serem aplicadas estão definidas abaixo.

Com esse recurso podemos iniciar as nossas máquinas remotamente, sendo necessário apenas o endereço MAC e o IP de broadcast da rede.

A geração automática da documentação é feita apenas para os arquivos na pasta modulos de cada sistema. As páginas são geradas pela ferramenta LDoc através de comandos como a seguir:

$ ldoc /home/ccpa-auto/<sistema>/modulos --dir /var/www/doc/<sistema>/

O acesso à máquina certificadora (139.82.9.51) deve ser feito através de ssh com o usuário sra, para o qual já fiz três pares de chaves, uma para cada um de nossos servidores: alfa, prod e satoro. As chaves públicas já estão instaladas na certificadora.

O esquema em funcionamento é simples e assíncrono: copia-se o(s) arquivo(s) que se deseja assinar para o diretório inbound na certificadora e, depois de algum tempo um arquivo de mesmo nome com sufixo _S deverá aparecer no diretório outbound assim como o original será apagado do inbound.

O nosso problema é que usamos dois usuários (do ponto de vista do S.O.) diferentes para as nossas "coisas": o ccpa-auto, para os programas de linha de comando; e o www-data, para tudo o que é disparado pela Web. Em geral a gente não se dá conta disso, mas o usuário que executa praticamente tudo é o usuário do Apache e, como tal, costuma ser configurado para não ter permissão para nada, justamente para evitar problemas de invasão e dar um mínimo de segurança. Assim, o www-data não está configurado para logar e não tem um interpretador de comandos definido, como pode ser constatado no /etc/passwd.

Dito isso, decidi instalar a chave privativa para o usuário ccpa-auto E TAMBÉM para o usuário www-data. Isso foi feito da seguinte forma:

• O diretório /home/ccpa-auto/.ssh_www-data precisa ter o dono www-data e não ter acesso a mais nenhum usuário (ou seja, permissão 0700);
• O arquivo id_rsa_www-data precisa ter o dono www-data e não ter acesso a mais nenhum usuário (ou seja, permissão 0600)
• Como o protocolo usado pelo ssh também verifica se o servidor é quem diz ser, é necessário termos pré-instalada a identificação da máquina no arquivo ~/.ssh/known_hosts (local do usuário) ou /etc/ssh/ssh_known_hosts (do sistema, que foi o que fiz)
• Por fim, ambos usuários precisam gravar os arquivos recuperados em algum lugar com as devidas permissões: /home/ccpa-auto/tmp. O diretório /tmp poderia ser usado SE o Apache não tivesse um mecanismo que faz os scripts acharem que estão escrevendo no /tmp, mas estão, na verdade, escrevendo em um diretório diferente.
• Resumindo:

  tomas@ccpa-vm:/home/ccpa-auto$ sudo ls -lad .ssh_www-data .ssh_www-data/id_rsa_www-data /etc/ssh/ssh_known_hosts tmp
  -rw-r--r-- 1 root     root       444 Feb 18 16:26 /etc/ssh/ssh_known_hosts
  drwx------ 2 www-data ccpa-auto 4096 Feb 18 16:25 .ssh_www-data
  -rw------- 1 www-data ccpa-auto 1679 Feb 18 16:25 .ssh_www-data/id_rsa_www-data
  drwxrwxrwx 2 tomas    ccpa-auto 4096 Mar 17 21:42 tmp
  

• O comando abaixo pode ser executado por um usuário real para consultar o conteúdo dos diretórios na máquina certificadora:

  sudo su - ccpa-auto -c "ssh sra@139.82.9.51 ls -l inbound/ outbound/"
  

  Explicando: o su serve para trocar para o usuário ccpa-auto e executar o comando indicado no parâmetro -c (código entre aspas), que, por sua vez, faz o login na máquina certificadora e executa o comando indicado no final (ls -l inbound/ outbound/)

Embora o certificado tenha validade de alguns anos, todo ano é necessário renová-lo (reissue) e atualizar os arquivos de configuração no servidor Web. Este processo depende de acesso ao site da empresa que gerou o certificado e da aprovação do RDC, já que foi configurado que eles são os administradores do domínio.

O RDC possui uma página com explicações bem crípticas sobre esse processo, mas que pode ajudar.

1. Verificar a validade atual:
   1. Acessar alguma página via HTTPS
   2. No cadeado da página (na barra da URL), clicar em Conexão Segura -> Mais informações (isso pode variar dependendo do navegador)
   3. Ver certificado
   4. Verificar a Validade; deve aparecer um período: "Não antes de" e "Não após"
2. Renovar o certificado
   1. Essa parte começa quando o Casanova repassar o e-mail de aviso de renovação, mas pode ser feita diretamente através do link:
      https://cheapsslsecurity.com/client/orderdtl.html?orderdetailid=466013
      1. Identificação: casanova@inf.puc-rio.br
         Senha que ele me passou!
      2. Em Manage Order | Validity, clicar no botão Reissue Now
         Irá aparecer uma tela com três passos: (1) Input CSR, (2) Select your server, e (3) Select the signature algorithm.
      3. Clicar em CSR Generation Tool
         Irá abrir uma outra aba/janela com os dados para a geração do CSR:
         • Common Name (Hostname): www.ccpa.puc-rio.br (CN)
         • Organization: PONTIFICIA UNIVERSIDADE CATOLICA DO RIO DE JANEIRO (O)
         • City/Locality: RIO DE JANEIRO (L)
         • State/Region: RIO DE JANEIRO (ST)
         • Country: BR (C)
         • Key Algorithm: RSA
         • Key Size: 2048
      4. Clicar em GENERATE CSR
      5. Download do .txt (www.ccpa.puc-rio.br.key)
      6. Copiar o CSR
   2. Paste do CSR no passo (1) dos três passos da página
   3. Selecionar o servidor Web: Apache
   4. Selecionar o algoritmo: SHA-512
   5. Clicar em Continue
      Isso irá fazer o site enviar um e-mail de confirmação para hostmaster@puc-rio.br
   6. Entrar em contato com o RDC (através do cat@puc-rio.br) e pedir para eles confirmarem (eles fazem essa confirmação diretamente no site ou através de e-mail)
   7. Na mesma página, onde aparecem os dados do certificado, ao lado de Status: Pending, clique em Refresh até que o status mude
   8. Clique no botão Download Certificate, que deverá surgir quando o status mudar; o arquivo deve ser um .zip
3. Instalar o novo certificado:
   1. Copiar os arquivos (.key baixado depois de gerar o CSR; e dois arquivos .crt dentre do .zip) para a pastar /etc/ssl/certs/ccpa/ no servidor:
      • www_ccpa_puc-rio_br.crt é o SSLCertificateFile
      • www.ccpa.puc-rio.br.key é o SSLCertificateKeyFile e deve ter permissão -rw------- 1 root root
      • DigiCertCA.crt é o SSLCertificateChainFile
      • Resumindo:

        tomas@ccpa-vm:/etc/ssl/certs/ccpa$ ls -l
        total 68
        -rw-r--r-- 1 root root  1958 Jan  8  2021 ccpa_01-2021.key
        -rw-r--r-- 1 root root  2362 Jan  8  2021 ccpa_01-2021.pem
        lrwxrwxrwx 1 root root    23 Jan 12  2022 ccpa_01-2022.crt -> www_ccpa_puc-rio_br.crt
        lrwxrwxrwx 1 root root    19 Jan 12  2022 ccpa_01-2022.key -> ccpa_puc-rio_br.key
        lrwxrwxrwx 1 root root    23 Feb  1  2023 ccpa_01-2023.crt -> www_ccpa_puc-rio_br.crt
        lrwxrwxrwx 1 root root    28 Feb  9 10:16 ccpa_01-2024.crt -> www_ccpa_puc-rio_br_2024.crt
        lrwxrwxrwx 1 root root    28 Feb  9 10:18 ccpa_01-2024.key -> www.ccpa.puc-rio.br_2024.key
        -rw------- 1 root root  1704 Jan 11  2022 ccpa_puc-rio_br.key
        -rw-r--r-- 1 root root  1720 Feb  9 10:14 DigiCertCA_2024.crt
        -rw-rw-r-- 1 root root  1934 Jan 12  2022 DigiCertCA.crt
        -rw-r--r-- 1 root root  1934 Jan  8  2021 intermediario_01-2021.crt
        lrwxrwxrwx 1 root root    14 Jan 12  2022 intermediario_01-2022.crt -> DigiCertCA.crt
        lrwxrwxrwx 1 root root    27 Feb  1  2023 intermediario_01-2023.crt -> intermediarioDigiCertCA.crt
        lrwxrwxrwx 1 root root    19 Feb  9 10:17 intermediario_2024.crt -> DigiCertCA_2024.crt
        -rw-rw-r-- 1 root root  2102 Jan 31  2023 intermediarioDigiCertCA.crt
        -rw-r--r-- 1 root root  2252 Feb  9 10:15 www_ccpa_puc-rio_br_2024.crt
        -rw------- 1 root root  1732 Feb  9 09:59 www.ccpa.puc-rio.br_2024.key
        -rw-rw-r-- 1 root root  2750 Jan 31  2023 www_ccpa_puc-rio_br.crt
        

   2. Atualizar o arquivo de configuração do Apache: /etc/apache2/sites-enabled/ccpa-ssl.conf:

              SSLCertificateFile    /etc/ssl/certs/ccpa/www_ccpa_puc-rio_br_2024.crt
              SSLCertificateKeyFile /etc/ssl/certs/ccpa/www.ccpa.puc-rio.br_2024.key
              SSLCertificateChainFile /etc/ssl/certs/ccpa/DigiCertCA_2024.crt
      

   3. Recarregar a configuração do Apache: sudo apache2ctl graceful