Projeto Quebre e Conserte

Administrador experiente é quem já viu o sistema quebrado e sabe por onde começar. Neste laboratório você vai causar seis panes de propósito, observar o sintoma, investigar a causa e consertar. É o treino mais próximo da vida real que existe.

---

Preparação: VM com ponto de restauração

Vamos criar a VM, instalar o nginx (usado no desafio 3) e tirar um snapshot chamado pronto. Sempre que um desafio sair do controle, você volta para ele.

$ multipass launch 26.04 --name lab --disk 10G --memory 2G
Launched: lab
$ multipass exec lab -- sudo apt-get install -y nginx
…
$ multipass stop lab
$ multipass snapshot lab --name pronto
Snapshot taken: lab.pronto
$ multipass start lab
$ multipass shell lab

Para voltar ao estado inicial a qualquer momento, no notebook:

$ multipass stop --force lab
$ multipass restore --destructive lab.pronto
Snapshot restored: lab.pronto
$ multipass start lab

O --force desliga a VM mesmo que ela não responda, como tirar da tomada. Use só no laboratório.

---

Desafio 1: um processo come 100% da CPU

1. Quebre

   O comando yes escreve "y" sem parar, o mais rápido que consegue. Mandando a saída para /dev/null (o "lixo" do sistema), ele vira um consumidor de CPU perfeito. O & joga o processo para o segundo plano.

   $ yes > /dev/null &
   [1] 2745                                          « [1] = número do job; 2745 = PID

2. Sintoma

   A VM fica lenta, e a carga (load average) sobe. As VMs do Multipass têm 1 CPU por padrão: carga perto de 1,00 significa CPU totalmente ocupada.

   $ uptime
    11:20:05 up 25 min,  1 user,  load average: 0.98, 0.45, 0.18   « último 1, 5 e 15 minutos

3. Diagnóstico

   Quem está consumindo? O top responde. Com -b -n 1 ele imprime uma vez só e sai, o que facilita ler:

   $ top -b -n 1 | head -9
   top - 11:20:31 up 25 min,  1 user,  load average: 0.99, 0.49, 0.20
   Tasks: 102 total,   2 running, 100 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 99.0 us,  1.0 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
   MiB Mem :   1967.5 total,   1302.2 free,    268.1 used,    397.2 buff/cache
   MiB Swap:      0.0 total,      0.0 free,      0.0 used.   1699.4 avail Mem
   
       PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
      2745 ubuntu    20   0    8384   1792   1792 R 100.0   0.1   0:31.42 yes      « o culpado
         1 root      20   0   22456  13312   9216 S   0.0   0.7   0:01.88 systemd

   Outra forma, sem o top:

   $ ps aux --sort=-%cpu | head -3
   USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
   ubuntu      2745 99.6  0.0   8384  1792 pts/0    R    11:19   0:58 yes
   root           1  0.1  0.6  22456 13312 ?        Ss   10:55   0:01 /sbin/init

4. Conserto

   Três formas de encerrar, da mais precisa para a mais ampla:

   $ kill 2745
   « pelo PID
   [1]+  Terminated              yes > /dev/null

   Comando	Quando usar
   kill 2745	Você sabe o PID exato.
   kill %1	O processo é um job deste mesmo terminal.
   pkill yes	Encerra todos os processos chamados yes.
   kill -9 2745	Só se o processo ignorar o kill normal. Veja kill e sinais.

   Confira: pgrep yes não mostra nada, e o uptime volta a cair em um ou dois minutos.

5. Lição

   CPU alta → top ou ps aux --sort=-%cpu → PID → kill. Antes de matar, pergunte: esse processo é importante? Um banco de dados em 100% talvez esteja só trabalhando muito.

---

Desafio 2: disco cheio

1. Quebre

   O fallocate reserva espaço para um arquivo instantaneamente, sem escrever nada. Vamos pedir exatamente o espaço livre que o df informa:

   $ df -h /
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/sda1       9.6G  2.3G  7.3G  24% /
   $ sudo fallocate -l $(df --output=avail -B1 / | tail -1) /var/tmp/lixo.img

   O $( … ) roda o df primeiro e coloca o resultado (o espaço livre em bytes) no lugar. O nome do disco (/dev/sda1) pode ser outro na sua VM.

2. Sintoma

   Programas começam a falhar de formas estranhas: arquivos não são salvos, o apt reclama, serviços não iniciam.

   $ echo "teste" > ~/teste.txt
   -bash: echo: write error: No space left on device
   $ df -h /
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/sda1       9.6G  9.6G     0 100% /                 « 100%: acabou o espaço

   Por que o root ainda consegue escrever um pouco?

   O ext4 reserva cerca de 5% do disco para o root, justamente para o administrador conseguir consertar a situação quando o disco enche.

3. Diagnóstico

   Onde está o espaço? Comece pela raiz e vá descendo, sempre ordenando do menor para o maior:

   $ sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail -4
   183M	/snap
   1.6G	/usr
   7.5G	/var                                          « suspeito
   9.6G	/
   $ sudo du -xh --max-depth=1 /var 2>/dev/null | sort -h | tail -3
   211M	/var/lib
   7.3G	/var/tmp                                      « achou
   7.5G	/var
   $ ls -lh /var/tmp
   total 7.3G
   -rw-r--r-- 1 root root 7.3G Oct 15 11:25 lixo.img

   du

   Mede quanto as pastas ocupam (disk usage).

   -x

   Fica no mesmo disco; não entra em /proc, /sys nem outros discos.

   -h

   Tamanhos legíveis (M, G).

   --max-depth=1

   Mostra só um nível de subpastas.

   2>/dev/null

   Esconde avisos de pastas que não dá para ler.

   | sort -h | tail -4

   Ordena por tamanho e mostra só os 4 maiores.

   Atalho para achar arquivos gigantes direto: sudo find / -xdev -type f -size +1G 2>/dev/null.

4. Conserto

   $ sudo rm /var/tmp/lixo.img
   $ df -h /
   Filesystem      Size  Used Avail Use% Mounted on
   /dev/sda1       9.6G  2.3G  7.3G  24% /

   Na vida real, os culpados mais comuns são logs (sudo journalctl --vacuum-size=200M), o cache do apt (sudo apt clean), versões antigas de snaps e backups esquecidos.

5. Lição

   Erros estranhos em vários programas ao mesmo tempo? Rode df -h primeiro. Depois, desça com du até achar a pasta culpada.

---

Desafio 3: um serviço que não sobe

1. Quebre

   Vamos apagar um único ; da configuração do nginx. O sed -i edita o arquivo no lugar:

   $ sudo cp /etc/nginx/sites-available/default /root/default.bak
   « cópia de segurança
   $ sudo sed -i 's/listen 80 default_server;/listen 80 default_server/' /etc/nginx/sites-available/default
   $ sudo systemctl restart nginx
   Job for nginx.service failed because the control process exited with error code.
   See "systemctl status nginx.service" and "journalctl -xeu nginx.service" for details.

2. Sintoma

   $ curl localhost
   curl: (7) Failed to connect to localhost port 80 after 0 ms: Couldn't connect to server

   O site está fora do ar.

3. Diagnóstico

   A própria mensagem de erro diz onde olhar. Siga em ordem:

   $ systemctl status nginx --no-pager | head -4
   × nginx.service - A high performance web server and a reverse proxy server
        Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
        Active: failed (Result: exit-code) since Thu 2026-10-15 11:31:02 UTC; 20s ago   « falhou
   $ sudo nginx -t
   nginx: [emerg] invalid parameter "listen" in /etc/nginx/sites-enabled/default:23
   nginx: configuration file /etc/nginx/nginx.conf test failed

   O nginx -t é o melhor amigo aqui: diz o arquivo e a linha. Sem o ;, o nginx juntou duas linhas numa só e estranhou a palavra listen no meio. O erro costuma apontar para a linha seguinte à que tem o problema. O número exato da linha pode variar.

   $ sudo sed -n '20,24p' /etc/nginx/sites-enabled/default
   server {
   	listen 80 default_server                         « falta o ;
   	listen [::]:80 default_server;

   Os mesmos detalhes aparecem no journal: sudo journalctl -u nginx -n 10 --no-pager.

4. Conserto

   $ sudo cp /root/default.bak /etc/nginx/sites-available/default
   $ sudo nginx -t
   nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
   nginx: configuration file /etc/nginx/nginx.conf test is successful
   $ sudo systemctl restart nginx
   $ curl -sI localhost | head -1
   HTTP/1.1 200 OK

5. Lição

   Serviço que não sobe → systemctl status → journalctl -u → teste de configuração do próprio programa (nginx -t, sshd -t, apachectl configtest). E sempre teste antes de reiniciar: com reload, uma configuração errada é recusada e o site antigo continua no ar.

---

Desafio 4: rede derrubada

1. Quebre (parte A: erro de digitação)

   A rede do Ubuntu Server é configurada pelo Netplan, em arquivos YAML. Veja o arquivo da VM e faça uma cópia:

   $ ls /etc/netplan/
   50-cloud-init.yaml
   $ sudo cat /etc/netplan/50-cloud-init.yaml
   network:
     version: 2
     ethernets:
       default:
         match:
           macaddress: "52:54:00:3a:9c:1f"
         dhcp4: true                                 « pega IP automático (DHCP)
   $ sudo cp /etc/netplan/50-cloud-init.yaml /root/netplan.bak
   $ sudo sed -i 's/dhcp4: true/dhcp44: true/' /etc/netplan/50-cloud-init.yaml

   O conteúdo exato do arquivo pode ser um pouco diferente na sua VM.

2. Sintoma e diagnóstico (parte A)

   Antes de aplicar, o Netplan valida o arquivo. O erro mostra arquivo, linha e coluna:

   $ sudo netplan generate
   /etc/netplan/50-cloud-init.yaml:8:7: Error in network definition: unknown key 'dhcp44'
         dhcp44: true
         ^

   Nada foi aplicado: a rede continua funcionando. Conserte com a cópia: sudo cp /root/netplan.bak /etc/netplan/50-cloud-init.yaml.

3. Quebre (parte B: configuração válida, mas errada)

   Agora um erro que o Netplan não tem como detectar: um IP fixo de outra rede. O arquivo é válido, mas a VM fica isolada. Para isso existe o netplan try: ele aplica a configuração e, se você não confirmar em 120 segundos, desfaz sozinho.

   $ sudo sed -i 's/dhcp4: true/dhcp4: false\n      addresses: [192.168.99.50\/24]/' /etc/netplan/50-cloud-init.yaml
   $ sudo netplan try
   Do you want to keep these settings?
   
   
   Press ENTER before the timeout to accept the new configuration
   
   
   Changes will revert in 120 seconds                « o terminal congela: a VM perdeu a rede

4. Sintoma e diagnóstico (parte B)

   A sessão para de responder, porque o multipass shell é uma conexão de rede. Não aperte nada. Espere os 120 segundos, feche o terminal e abra outro:

   $ multipass shell lab

   Ele volta a conectar porque o netplan try reverteu a configuração sozinho. Agora restaure o arquivo original:

   $ sudo cp /root/netplan.bak /etc/netplan/50-cloud-init.yaml
   $ sudo netplan apply
   $ ip -br addr show
   lo               UNKNOWN        127.0.0.1/8 ::1/128
   ens3             UP             10.85.140.27/24 metric 100 fe80::5054:ff:fe3a:9c1f/64

   Os nomes das interfaces e os endereços variam. O importante é a sua interface aparecer UP com o IP de antes.

5. Lição

   Em servidor remoto, nunca use netplan apply direto numa mudança arriscada. Use netplan try: o pior que acontece são dois minutos sem acesso. Se você tivesse usado apply aqui, a saída seria o snapshot; num servidor de verdade, o console do provedor.

---

Desafio 5: um administrador perdeu o sudo

1. Quebre

   Vamos criar a usuária aluna como administradora e depois tirá-la do grupo sudo. Usamos outra conta porque o usuário ubuntu da VM tem uma regra extra em /etc/sudoers.d/ e não perderia o acesso.

   $ sudo adduser --comment "" aluna
   …
   $ sudo usermod -aG sudo aluna
   $ sudo gpasswd -d aluna sudo
   Removing user aluna from group sudo

2. Sintoma

   $ su - aluna
   Password:

   $ sudo apt update
   [sudo: authenticate] Password:
   sudo: I'm sorry aluna. I'm afraid I can't do that   « a senha está certa, mas falta a permissão

3. Diagnóstico

   $ groups
   aluna users                                       « "sudo" sumiu da lista
   $ exit

4. Conserto

   Se existe outro administrador (aqui, o ubuntu):

   $ sudo usermod -aG sudo aluna
   $ groups aluna
   aluna : aluna sudo users

   A aluna precisa sair e entrar de novo para o grupo valer.

   Se ela era a única administradora, ninguém mais tem sudo. Num PC ou VM com tela, a saída é o modo de recuperação, que dá um terminal de root sem senha:

   1. Reinicie e segure Shift (BIOS) ou toque Esc (UEFI) para abrir o menu do GRUB.
   2. Escolha Advanced options for Ubuntu → a linha que termina em (recovery mode).
   3. No menu, escolha root – Drop to root shell prompt e aperte Enter.
   4. Rode os comandos abaixo e reinicie.

   #> mount -o remount,rw /
   « o disco começa só para leitura
   #> usermod -aG sudo aluna
   #> reboot

   A VM do Multipass não tem tela para o GRUB. Lá, a porta dos fundos é multipass exec lab -- sudo usermod -aG sudo aluna, que roda como ubuntu.

5. Lição

   Mantenha sempre dois administradores, ou tenha acesso ao console. Para editar /etc/sudoers, use sempre sudo visudo, que recusa salvar um arquivo com erro de sintaxe. Veja sudo.

---

Desafio 6: o fstab impede o sistema de ligar

1. Quebre

   O /etc/fstab lista os discos montados no boot. Vamos acrescentar um disco que não existe, identificado por um UUID inventado:

   $ sudo cp /etc/fstab /root/fstab.bak
   $ sudo mkdir /dados
   $ echo 'UUID=12345678-dead-beef-0000-123456789abc /dados ext4 defaults 0 2' | sudo tee -a /etc/fstab
   UUID=12345678-dead-beef-0000-123456789abc /dados ext4 defaults 0 2

2. Diagnóstico ANTES de reiniciar

   Esse é o hábito que salva servidores: depois de mexer no fstab, teste antes de reiniciar. Dois comandos fazem isso:

   $ sudo findmnt --verify
   /dados
      [E] unreachable source: UUID=12345678-dead-beef-0000-123456789abc: No such file or directory
      [W] cannot detect on-disk filesystem type
   
   0 parse errors, 1 error, 1 warning               « [E] = erro: isso vai dar problema no boot
   $ sudo mount -a
   mount: (hint) your fstab has been modified, but systemd still uses
          the old version; use 'systemctl daemon-reload' to reload.
   mount: /dados: can't find UUID=12345678-dead-beef-0000-123456789abc.

   O mount -a tenta montar tudo o que está no fstab, como o boot faria. Se ele falha aqui, o boot também vai falhar.

3. Sintoma (se você reiniciar mesmo assim)

   Para ver a pane completa, reinicie: sudo reboot. O boot espera o disco por 90 segundos e, sem encontrá-lo, entra no modo de emergência. Numa tela, você veria algo assim:

   A start job is running for /dev/disk/by-uuid/12345678-dead-beef-0000-123456789abc (1min 30s / 1min 30s)
   …
   You are in emergency mode. After logging in, type "journalctl -xb" to view
   system logs, "systemctl reboot" to reboot, or "exit" to continue bootup.
   Cannot open access to console, the root account is locked.
   See sulogin(8) man page for more details.
   
   Press Enter to continue.

   O SSH não sobe, então multipass shell lab fica tentando e não conecta.

4. Conserto

   Na VM do Multipass, que não tem tela, volte ao snapshot:

   $ multipass stop --force lab
   $ multipass restore --destructive lab.pronto
   Snapshot restored: lab.pronto
   $ multipass start lab

   Num PC ou VM com tela, use o modo de recuperação, como no desafio 5: GRUB → Advanced options → (recovery mode) → root. Depois:

   #> mount -o remount,rw /
   #> nano /etc/fstab
   « comente a linha com # ou apague
   #> findmnt --verify
   0 parse errors, 0 errors, 0 warnings
   #> reboot

5. Lição

   Três hábitos para o fstab:

   • Faça uma cópia antes de editar.
   • Rode sudo findmnt --verify e sudo mount -a antes de reiniciar.
   • Para discos que não são essenciais (HD externo, disco de backup), use a opção nofail: se o disco não estiver lá, o boot continua. Exemplo: UUID=… /dados ext4 defaults,nofail 0 2. Veja mount e fstab.

---

O roteiro de qualquer pane

O que você aprendeu

• Achar e encerrar um processo que trava a CPU.
• Descobrir o que encheu o disco descendo pelas pastas com du.
• Ler systemctl status, journalctl e o teste de configuração do nginx.
• Mudar a rede com segurança usando netplan try.
• Recuperar o sudo e consertar um fstab pelo modo de recuperação.
• Usar snapshots como rede de segurança.

Desafios extras

1. Encha a memória com stress-ng --vm 1 --vm-bytes 90% e observe o systemd-oomd agindo no journal.
2. Apague sem querer /etc/nginx/nginx.conf e recupere com sudo apt install --reinstall -o Dpkg::Options::="--force-confmiss" nginx-common.
3. Peça para alguém quebrar a VM sem contar o quê, e descubra sozinho.

Desfazer e limpar

$ multipass delete --purge lab

---

Exercícios