diff --git a/source/pages/proposals/gerenciamento-redes-netbox.md b/source/pages/proposals/gerenciamento-redes-netbox.md
new file mode 100644
index 0000000000000000000000000000000000000000..5260007e313d9d65cf4410d5801a5ec092a9aa57
--- /dev/null
+++ b/source/pages/proposals/gerenciamento-redes-netbox.md
@@ -0,0 +1,306 @@
+# PM002: Gerenciar a rede usando NetBox
+
+A rede do Departamento de Informática é complexa. Contamos hoje com por volta de
+56 VLANs e prefixos de IP correspondentes, além de por volta de 400 máquinas físicas
+e 125 máquinas virtuais. Tradicionalmente esse sistema foi gerenciado através
+de conjuntos de arquivos texto localizado nas máquinas responsáveis pelos serviços
+correspondentes junto de scripts que criavam as configurações das máquinas a
+partir desses arquivos texto. Porém com a necessidade de se desacoplar e
+distribuir serviços em máquinas diferentes, surgem algumas problemas:
+
+- Os arquivos texto precisam ser entendíveis pelas máquinas para gerar as
+configurações mas também alteráveis por seres humanos; o resultado é que erros
+de sintaxe ou erros semânticos desses arquivos geram falhas catastróficas.
+- A responsabilidade de evitar que falhas catastróficas como duplicação de nomes,
+IPs, MACs e outros identificadores únicos cai sobre os scripts ou do
+administrador que não tem absoluta ciência de todos os componentes da rede.
+- Informações sobre a mesma coisa ficam distribuídas entre as máquinas que
+gerenciam serviços diferentes; o serviço de virtualização, DHCP, DNS, firewall,
+backup e certificados SSL por exemplo precisam concordar ao menos na existência
+de um mesmo conjunto de máquinas virtuais. A responsabilidade de manter todos
+os serviços cientes da mesma informação cai sobre o administrador, que é falho.
+- Quando é necessário saber alguma informação sobre a descrição e usuário
+responsável por um certo item da rede, é necessário vasculhar os diversos
+arquivos de texto em busca de informação e no pior caso recorrer ao e-mail
+para ver se alguém sabe.
+- Para mexer nos arquivos texto, é necessário acesso às máquinas correspondentes
+e implica necessariamente acesso total. Não é possível ter nenhum tipo de controle
+de acesso nesse modelo, ou o acesso é total ou é inexistente.
+- Os arquivos texto não possuem controle de versão, tampouco controle de quem
+realizou as mudanças e não é possível saber exatamente quais serão os efeitos
+das mudanças a serem realizadas de antemão.
+
+Problemas resultado desse modelo de gerência acabam sendo:
+- Queda de serviços inesperada devido a problemas de sintaxe residuais
+de outra pessoa que esqueceu de rodar o script (Horácio "VLAN/DHCP")
+- Assinalamento de valores fora dos intervalos permitidos (Horácio "10.254.300.\*")
+- Descrição das máquinas inexistente (Horácio "Esqueceram de mim 2" e "Observatório")
+- Duplicação de nomes na rede (Horácio "DNS SPOOFING DETECTED!")
+- Duplicação de IPs na rede (Horácio "Redundância de roteamento", "Eu não aprendo com o erro alheio..." e "IPv4 na faixa de unknown-clients na XHIPES")
+- Gestão falha de backups e certificados SSL
+
+Vamos então focar nos pontos chave que precisam ser atendidos pela solução que
+desejamos usar:
+
+- Apresentação das informações é clara e 100% pesquisável
+- Consumível por máquinas para gerar arquivos de configuração
+- Integridade e consistência dos dados
+- Concentrar todas as informações da rede, sem buracos
+- Controle de versão das alterações feitas e preferencialmente por quem, quando
+e talvez até por qual razão
+- Etapas podem ser puladas em casos de emergência
+- É fácil reverter quando acontecer algum problema
+- Quando complexo, a complexidade é justificada
+
+Além disso, é importante também se atentar a como isso é resolvido em outras
+organizações. Uma importante leitura é um artigo antigo, dos anos 2000 que se
+chama [Bootstrapping an Infrastructure](http://www.infrastructures.org/papers/bootstrap/bootstrap.html).
+Já naquela época se estabeleceu um sistema de gerência com os componentes que
+hoje tem outro nome mas que são idênticos em natureza: um servidor "ouro" que
+configura todos os serviços com controle de versão.
+
+O que motivou essa proposta e busca por soluções foi a separação do servidor
+de DHCP e DNS que são extremamente acoplados. Já estava claro que era necessário
+estabelecer uma única fonte de verdade, e uma possibilidade seria mover os
+arquivos de texto para o servidor de DHCP que atualizaria o DNS por DDNS. A
+a solução é coerente e funciona, mas continuar a gestão nos arquivos de texto
+não é desejável devido aos problemas apontados anteriormente. Além disso,
+deixo claro que de nenhuma forma a gestão discutida aqui exclui a atualização
+do DNS pelo servidor DHCP, pois é uma estratégia que pode ser muito efetiva
+principalmente para redes internas mais pra frente.
+
+## NetBox
+
+O [NetBox](https://netboxlabs.com/docs/netbox/en/stable/) é uma solução de código
+aberto para modelar e documentar redes modernas. Ele combina gerenciamento
+de IPs (IPAM) e gerenciamento de infraestrutura de data center (DCIM). É possível
+estender todas as funcionalidades através de plugins e a sua principal funcionalidade
+é interação fácil através de APIs com qualquer software. Fiquei sabendo da
+sua existência conversando com o pessoal do POP.
+
+A proposta do NetBox é que ele seja a Única Fonte de Verdade (SSoT), isto é,
+qualquer pergunta que precisa ser feita sobre a rede, quem responde é o NetBox.
+Importante notar porém que ele não é feito para ser uma representação do mundo
+*atualizada em tempo real*. Ainda mais do que isso, o NetBox deve ser na verdade
+a representação do mundo *ideal*, como ele deveria ser. Isto porque o fluxo deve
+sempre ser: mudar o mundo da lua do NetBox, gerar as configurações baseadas
+neste mundo e assim fazer com que o mundo real seja sincronizado com o mundo
+que está no NetBox.
+
+Então sobre os pontos chave que precisam ser atendidos temos:
+
+- **Apresentação das informações é clara e 100% pesquisável:**
+
+  Da melhor forma possível. Para navegar pela rede é recomendado usar sua interface
+  web, mas interfaces em linha de comando como o [nbcli](https://github.com/nbcli/nbcli)
+  ou interfaces customizadas utilizando a API em Python [pynetbox](https://github.com/netbox-community/pynetbox)
+  devem ser feitas para atender as nossas necessidades. Como os administradores
+  atuais tem familiaridade com arquivos texto em formatos específicos, é relativamente
+  fácil de criar ferramentas de gestão que interoperam com o banco de dados do NetBox.
+
+- **Consumível por máquinas para gerar arquivos de configuração:**
+
+  Sim, sem problemas de sintaxe e semânticos pois os dados são fortemente tipados.
+
+- **Integridade e consistência dos dados:**
+
+  A fundação do NetBox é um modelo robusto do mundo real. Dispositivos podem ser
+  parte de racks, estão localizados em salas e tem interfaces de energia e de
+  rede que podem se ligar a outros dispositivos por meio de cabos.
+  IPs são vinculados a essas interfaces e fazem parte de prefixos de rede que
+  usa uma determinada VLAN. Esse emaranhado de relações permite contar a história
+  completa da rede e impedir que exista informação duplicada e incoerente.
+
+- **Concentrar todas as informações da rede, sem buracos**
+
+  Será possível integrar todas as informações, e expandir com plugins caso seja
+  interessante. Nativamente existe a provisão de contatos de responsáveis,
+  máquinas físicas, máquinas virtuais, IPs, VLANs, rackeamento do data center,
+  cabos de energia e conexões entre switches e patch panels. Com plugins temos
+  [mapas de pontos de redes](https://github.com/netbox-community/netbox-floorplan-plugin),
+  [gerenciamento de DNS](https://github.com/peteeckel/netbox-plugin-dns),
+  [armazenamento de documentação](https://github.com/jasonyates/netbox-documents),
+  [integração com Proxmox](https://github.com/netdevopsbr/netbox-proxbox),
+  [visualizador de conexões](https://github.com/netbox-community/netbox-topology-views) e
+  [mapa de discos](https://github.com/Zorlin/netbox-physical-storage). Não é necessário
+  ir tão longe pra várias coisas porém pois a funcionalidade de criar campos customizados em objetos já é poderosa.
+
+- **Controle de versão das alterações feitas e preferencialmente por quem, quando e talvez até por qual razão**
+
+  O NetBox mantém um log de alterações contendo o responsável pela mudança e qual foi exatamente a mudança.
+  E ao fazer a mudança, é possível especificar qual o motivo.
+
+- **Etapas podem ser puladas em casos de emergência**
+
+  Nada depende do NetBox funcionar. Ele é usado apenas como um banco de dados
+  de informações, e se ele falhar, o que será impossível fazer será apenas gerar
+  configurações novas de forma automática. Configurações manuais vão continuar
+  sendo possíveis.
+
+- **É fácil reverter quando acontecer algum problema**
+
+  Em caso de alguma alteração massiva problemática, é possível reverter para uma
+  versão anterior do banco de dados. Também faz parte do plano manter uma versão
+  do NetBox auxiliar rodando que sempre tem informações do dia anterior para
+  testar scripts ou reverter informações caso seja necessário. De toda forma note
+  que alterar o NetBox não altera imediatamente o que é configurado por ele,
+  pois existe uma camada de indireção.
+
+- **Quando complexo, a complexidade é justificada**
+
+  O modelo do NetBox realmente não é complexo e planejamos desativar todas as
+  funcionalidades que no momento não são interessantes (como por exemplo a opção
+  de ter vários grupos de VLANs diferentes). Pode ser trabalhoso a parte de
+  inventoriar algumas das coisas (mas podemos ser vagos com os detalhes) porém
+  é algo que os bolsistas com o tempo fazem e que a longo prazo só vai trazer benefícios.
+
+## Automação: Ansible e Git
+
+É evidente que o NetBox não faz nada por si só, ele é só um banco de dados.
+Os mesmos "scripts" que liam os arquivos texto e geravam os arquivos de configuração
+ainda vão ser pra sempre necessários e são a cola para permitir que o mundo
+ideal do NetBox se materialize. Mas aí entram os sistemas de configuração que
+já usamos fazem anos, como Salt e Ansible. O fluxo seria o seguinte:
+
+```{svgbob}
+:align: center
+
+                                                                                 Ansible
+.---------------.   .-----------------------.   .------------------.     .---------------------.
+|   "Root cria" |   |   "NetBox cria commit"|   |    "Root avalia" | ok  |     "Root ou robô"  |
+|  "informações"|-->|    "no Git com novas" |-->|   "configurações"|---->|   "implementa novas"|
+|   "no NetBox" | ^ |     "configurações"   |   |     "criadas"    |     |    "configurações"  |
+'---------------' | '-----------------------'   '------------------'     '---------------------'
+                  |                                       | errado,
+                  |                                       | arrumar!
+                  '---------------------------------------'
+```
+
+Com essa camada de indireção usando Git também facilitamos reverter para um
+estado anterior da configuração de algum serviço, basta reverter o commit e
+implementar configurações antigas. E note que caso o servidor de Git ou o NetBox
+esteja fora do ar, o administrador ainda pode alterar as configurações manualmente
+e implementá-las usando Ansible (que precisa somente de acesso SSH).
+
+Dependendo da periculosidade da operação, é possível que alguns tipos de mudanças
+possam ser feitas automaticamente ou depois de um certo intervalo de tempo. Adições
+de novos nomes não-conflitantes no DNS e no DHCP por exemplo pode ser considerada
+uma operação de baixo risco. Alterações ou remoções nestes mesmos segmentos podem
+exigir autorizações de mais um integrante da equipe de root para integrarem a
+branch principal do Git por exemplo.
+
+## Ajuste ao status quo
+
+É compreensível que existam alguns óbvios pontos de discórdia.
+
+### Eu não quero usar a interface web para mexer na rede
+
+Pois bem, o NetBox tem uma API magnífica que você pode usar sem encostar
+na interface web. O jeito mais simples de interagir com ela seria numa
+sessão interativa do Python, eu já tenho esse script aqui:
+
+```
+#!/usr/bin/env -S python3 -i
+import pynetbox
+import os
+
+nb = pynetbox.api(
+    'https://netbox.c3sl.ufpr.br',
+    token=os.environ['NETBOX_TOKEN']
+)
+```
+
+Por exemplo se eu quiser saber informações sobre a máquina `estrella`:
+
+```
+>>> import yaml
+>>> print(yaml.dump(dict(nb.dcim.devices.get(name='estrella'))))
+```
+```yaml
+created: '2024-05-03T11:18:28.600413-03:00'
+device_role:
+  name: Gerencial
+interface_count: 33
+primary_ip4:
+  address: 200.17.202.12/25
+  url: https://netbox.c3sl.ufpr.br/api/ipam/ip-addresses/1334/
+primary_ip6:
+  address: 2801:82:80ff:8001:ba59:9fff:fe89:f251/64
+  url: https://netbox.c3sl.ufpr.br/api/ipam/ip-addresses/1524/
+rack:
+  name: '7'
+  url: https://netbox.c3sl.ufpr.br/api/dcim/racks/1/
+site:
+  name: "Departamento de Inform\xE1tica"
+  url: https://netbox.c3sl.ufpr.br/api/dcim/sites/1/
+status:
+  value: active
+url: https://netbox.c3sl.ufpr.br/api/dcim/devices/49/
+```
+
+Ou pode se usar algo como o [nbcli](https://github.com/nbcli/nbcli):
+
+```console
+$ pipx run nbcli search estrella
+
+Device
+======
+Name      Status  Tenant  Site                         Rack  Role       Type  IP Address
+estrella  Active  -       Departamento de Informática  7     Gerencial  1U    2801:82:80ff:8001:ba59:9fff:fe89:f251
+
+Address
+=======
+IP Address                                Vrf  Status  Role  Tenant  DNS Name               Description
+200.17.202.12/25                          -    Active  -     -       estrella.c3sl.ufpr.br  -
+2801:82:80ff:8001:ba59:9fff:fe89:f251/64  -    SLAAC   -     -       estrella.c3sl.ufpr.br  -
+```
+
+De toda forma, creio que pode ser insuficiente para *algumas tarefas*.
+Será necessário desenvolver um conjunto de ferramentas um pouco mais customizado
+ao nosso gosto que pode se fundamentar no jeito que hoje as coisas são feitas.
+O que proponho como design é uma ferramenta do tipo:
+
+```console
+$ netboxadm edit vlan xlab6
+```
+
+Que abre num editor um arquivo do gênero:
+```yaml
+xlab6:
+  vid: 250
+  prefix: 10.254.250.0/24
+  gateway: 10.254.250.254
+  ipv4s:
+    2:
+      host: estrella
+    3:
+      host: urquell
+    11:
+      host: l1
+      mac: d0:94:66:bf:62:53
+    12:
+      host: l2
+      mac: d0:94:66:bf:63:8f
+    13:
+      host: l3
+      mac: d0:94:66:bf:5f:5b
+    14:
+      host: l4
+      mac: d0:94:66:bf:62:37
+    254:
+      host: estrella
+```
+
+Que pode ser editado, sendo as alterações refletidas no NetBox apropriadamente
+de forma análoga ao que temos hoje com os arquivos texto mas com os benefícios
+de detectar nomes e MACs duplicados na rede inteira. Fazer essa interface é
+curiosamente não muito difícil pois a parte de validar o que foi escrito fica
+pro NetBox.
+
+### E se o NetBox e/ou o sevidor Git falhar?
+
+Você pode ajustar o arquivo de configuração que está na sua cópia local do
+Git (ou copiar o arquivo da máquina) e alterar o que está na máquina manualmente
+ou via Ansible. Note que isso não é diferente do que acontece se um script
+que gera configuração a partir de arquivos texto falhar: você vai ter que
+editar as configurações.