From b3721a09117f10e93e75535f9f8e3563c140c41f Mon Sep 17 00:00:00 2001
From: fmkiotheka <fmkiotheka@inf.ufpr.br>
Date: Tue, 15 Oct 2024 10:21:01 -0300
Subject: [PATCH] feat: add vms and vm management

---
 source/index.md                |   8 ++
 source/pages/vms/management.md | 193 +++++++++++++++++++++++++++++++++
 2 files changed, 201 insertions(+)
 create mode 100644 source/pages/vms/management.md

diff --git a/source/index.md b/source/index.md
index eb39a4b..ab4ee3a 100644
--- a/source/index.md
+++ b/source/index.md
@@ -7,6 +7,14 @@
 :width: 500px
 ```
 
+```{toctree}
+:caption: Máquinas Virtuais
+:glob: true
+:maxdepth: 1
+
+pages/vms/*
+```
+
 ```{toctree}
 :caption: Conceitos
 :glob: true
diff --git a/source/pages/vms/management.md b/source/pages/vms/management.md
new file mode 100644
index 0000000..f79a24d
--- /dev/null
+++ b/source/pages/vms/management.md
@@ -0,0 +1,193 @@
+# Gerenciamento de Máquinas Virtuais
+
+A infraestrutura das máquinas virtuais do C3SL é gerenciada pelos roots, um
+grupo de professores e bolsistas que respondem pelo e-mail <root@c3sl.ufpr.br>.
+A responsabilidade de manutenção do sistema operante dentro da máquina virtual,
+porém, é atribuída aos responsáveis assinalados para a máquina virtual. Mas note que
+os roots regularmente intervém nas máquinas:
+
+* Diariamente, os arquivos relacionados ao acesso SSH das máquinas virtuais são
+sobrescritos por processos automatizados, então o controle de acesso SSH para
+as máquinas virtuais é feito pelos roots.
+* Os roots gerenciam um sistema de renovação automática de certificados via
+Let's Encrypt através de desafios de DNS. Usuários podem pedir a configuração
+desse serviço via e-mail.
+* O serviço Zabbix é instalado para monitoramento da máquina e envio de alertas
+aos responsáveis por exemplo para alertar sobre falta de espaço em disco ou
+alto uso de recursos computacionais.
+* Configuração de envio de e-mail utilizando a infraestrutura interna é gerenciada
+pelos roots, sendo que o envio de e-mail é liberado caso a caso, sendo a máquina
+configurada para enviar e-mail via sendmail.
+* Portas são liberadas no firewall mediante pedido. Inicialmente apenas o acesso
+interno é liberado, sendo necessário pedir a liberação de portas adicionais
+que estão sujeitas a nossa política de firewall.
+* Gerenciamento de registros de DNS e assinalamento de IPs. A máquina virtual
+recebe seu nome e IPs via DHCP, e o DNS é configurado pelos roots para ser
+{hostname}.c3sl.ufpr.br. Os IPv4s e IPv6s assinalados são públicos e tecnicamente
+acessíveis de qualquer lugar da Internet, sendo o único obstáculo o firewall.
+* Caso exista algum tipo de falha de segurança, ou algum alerta acenda,
+podem entrar na máquina e desligar a máquina virtual ou fazer atualização
+obrigatória de algum pacote.
+
+Pedidos de alteração do controle de acesso, envio de e-mail, liberação de portas
+no firewall, aumento dos recursos computacionais e dúvidas devem ser feitos por
+e-mail.
+
+## Política de portas do firewall
+
+Inicialmente, uma máquina virtual tem acesso pleno a serviços externos. Porém,
+o acesso de fora para dentro é completamente bloqueado, sendo possível acessar
+a máquina via SSH apenas através da rede interna do C3SL. Alterações nessa
+configuração devem ser feitas através de pedidos via <root@c3sl.ufpr.br> de
+acordo com as seguintes regras:
+
+* A liberação da portas de e-mail não é permitida. O envio de e-mails pode ser
+feito através do nosso relay, cuja configuração pode ser requisitada.
+* A liberação de portas para acesso externo SSH só é permitida caso haja
+necessidade de acesso para usuários externos ao Departamento de Informática,
+sendo cada situação avaliada caso a caso.
+* A liberação de portas HTTP/HTTPS é feita com a contrapartida de que todo
+acesso de dentro para fora é limitado. Acesso a servidores web assim devem ser
+intermediados pelo nosso proxy HTTP.
+
+## Proxy HTTP/HTTPS
+
+Temos uma máquina chamada httpproxy.c3sl.ufpr.br que pode ser usada para acessar
+uma quantidade limitada de domínios externos. Pode ser utilizadas as seguintes
+variáveis de ambiente:
+
+```
+http_proxy="http://httpproxy.c3sl.ufpr.br:3128"
+https_proxy="http://httpproxy.c3sl.ufpr.br:3128"
+```
+
+Essa configuração de proxy deve ser utilizada para produção mas é possível
+ter um acesso menos restrito gerenciado através da criação de um tunelamento SSH
+de dentro da máquina virtual:
+
+1. Acesse de dentro da máquina virtual um usuário do DINF via
+`ssh -D 9050 usr99@macalan -FN`, que abre uma porta SOCKS na porta 9050 para o
+mundo externo intermediado pela macalan.
+2. Ao utilizar aplicações rode usando a aplicação `proxychains4` antes do comando;
+este comando faz com que certas requisições sejam feitas através do tunelamento
+disponível na porta SOCKS 9050.
+3. Alguns comandos escapam esse controle mas respeitam as variáveis `http_proxy`
+e `https_proxy`. Você pode utilizar uma aplicação como o Privoxy para criar
+um Proxy HTTP/HTTPS que conversa com o proxy SOCKS do SSH utilizando a configuração
+`forward-socks4a / 127.0.0.1:9050` e as variáveis de ambiente de Proxy HTTP/HTTPS
+com valor `http://localhost:8118`.
+
+## Certificados TLS
+
+O nosso sistema de renovação de certificados TLS usando Let's Encrypt roda
+diariamente e realiza as seguintes etapas ao renovar o certificado:
+
+1. Coloca a cadeia de certificados públicos e intermediários gerados em
+`/etc/ssl/certs/c3sl.pem`.
+2. Coloca o certificado privado em `/etc/ssl/private/c3sl.pem`.
+3. Chama o executável `/etc/c3sl/upgrade-cert`. Para que isso funcione este
+executável deve ter permissão de execução (`chmod +x`). Use este executável
+para recarregar os seus serviços, por exemplo:
+
+   ```
+   #!/bin/bash
+   systemctl reload nginx
+   ```
+
+### Exemplo de configuração do nginx
+
+Para utilizar o certificado na porta 443, lembre-se da diretiva `ssl` e de
+escutar nos endereços IPv4 e IPv6:
+
+```
+server {
+    listen 443 ssl http2;
+    listen [::]:443 ssl http2;
+    server_name examplo.c3sl.ufpr.br;
+    ssl_certificate /etc/ssl/certs/c3sl.pem;
+    ssl_certificate_key /etc/ssl/private/c3sl.pem;
+}
+```
+
+É obrigatório mandar uma resposta de redirecionamento para toda requisição na
+porta 80 para a porta 443:
+
+```
+server {
+     listen  80;
+     listen [::]:80;
+     server_name exemplo.c3sl.ufpr.br;
+     location / { return 301 https://$host$request_uri; }
+}
+```
+
+### Exemplo de configuração do Apache
+
+Para utilizar o certificado na porta 443:
+
+```
+<VirtualHost _default_:443>
+    ServerName exemplo.c3sl.ufpr.br
+    SSLEngine on
+    SSLCertificateFile      /etc/ssl/certs/c3sl.pem
+    SSLCertificateKeyFile   /etc/ssl/private/c3sl.pem
+</VirtualHost>
+```
+
+É obrigatório mandar uma resposta de redirecionamento para toda requisição na
+porta 80 para a porta 443. Isso pode ser feito de duas maneiras. O método
+recomendado é fazer isso estaticamente, para cada `ServerName`:
+
+```
+<VirtualHost _default_:80>
+  ServerName exemplo.c3sl.ufpr.br
+  Redirect / https://exemplo.c3sl.ufpr.br/
+</VirtualHost>
+```
+
+Porém isso pode ser feito também de forma dinâmica:
+
+```
+<VirtualHost _default_:80>
+    RewriteEngine On
+    RewriteCond %{HTTPS} off
+    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI}
+</VirtualHost>
+```
+
+### Domínios externos
+
+Quando existe um domínio externo ao C3SL apontando para a máquina (sendo que
+é recomendado que isso seja feito através de um registro CNAME), os certificados
+TLS precisam ser gerados através do desafio do servidor web. Isso significa que
+será necessário importar um snippet como este do nginx na configuração, e criar
+todos os diretórios do caminho `/var/www/letsencrypt/.well-known/acme-challenge`
+para que a automação possa copiar arquivos para lá:
+
+```
+# Rule for legitimate ACME Challenge requests (like /.well-known/acme-challenge/xxxxxxxxx)
+# We use ^~ here, so that we don't check other regexes (for speed-up). We actually MUST cancel
+# other regex checks, because in our other config files have regex rule that denies access to files with dotted names.
+location ^~ /.well-known/acme-challenge/ {
+
+    # Set correct content type. According to this:
+    # https://community.letsencrypt.org/t/using-the-webroot-domain-verification-method/1445/29
+    # Current specification requires "text/plain" or no content header at all.
+    # It seems that "text/plain" is a safe option.
+    default_type "text/plain";
+
+    # This directory must be the same as in /etc/letsencrypt/cli.ini
+    # as "webroot-path" parameter. Also don't forget to set "authenticator" parameter
+    # there to "webroot".
+    # Do NOT use alias, use root! Target directory is located here:
+    # /var/www/common/letsencrypt/.well-known/acme-challenge/
+    root         /var/www/letsencrypt/;
+}
+
+# Hide /acme-challenge subdirectory and return 404 on all requests.
+# It is somewhat more secure than letting Nginx return 403.
+# Ending slash is important!
+location = /.well-known/acme-challenge/ {
+    return 404;
+}
+```
-- 
GitLab