Tutorial de Ubuntu 26.04 / Configure um servidor e prepare a passagem de operação

A construção de um servidor é considerada completa quando outro administrador pode acessá-lo, modificá-lo e recuperá-lo. Este projeto final utiliza uma VM dedicada Ubuntu 26.04 LTS, instala apenas os serviços necessários e registra os resultados medidos de acesso, reinicialização e restauração em um documento de passagem de operação.

Defina o escopo e os critérios de aceitação

O projeto básico fornece administração SSH e um serviço web Nginx dentro de uma LAN. Prepare uma VM dedicada, console, plano de endereços, cliente de gerenciamento permitido e local de backup independente. Adicione HTTPS público somente se houver um domínio sob seu controle e uma rota de validação; escolha Samba ou contêineres quando necessário. Instalar todos os serviços não é o objetivo.

Configure na ordem de dependência com pequenas mudanças

1. Registre a versão, os dispositivos, o horário e os endereços pelo console; conclua atualizações e reinicialização necessária.
2. Identifique o escopo real do Netplan/NetworkManager e prepare console, backup e verificação com netplan try para alterações de endereço.
3. Verifique a autenticação por chave em uma nova sessão SSH antes de restringir a política; inspecione as portas realmente em escuta e a configuração de serviço/socket.
4. Instale apenas os serviços necessários; faça backup, valide e aplique a configuração. Restrinja clientes e portas reais no UFW e em firewalls externos.
5. Prepare backup/restauração independente e notificações de falha; mantenha uma linha de base antes do teste de reinicialização.

Se uma etapa falhar, investigue suas diferenças e logs antes de adicionar outra mudança. Mudanças simultâneas de porta, autenticação e firewall obscurecem a causa do acesso perdido e o rollback correto. Verifique se a rota de recuperação do console pode realmente ser aberta.

Separe as verificações locais do serviço LAN

Verifique o site 127.0.0.1:8080 da lição de Nginx no próprio servidor. Mapear alpha.example.test para 192.168.56.20 não expõe seu listener de loopback. Primeiro use --resolve no servidor para selecionar o hostname e o destino de loopback e verificar a resposta alpha-site. O laboratório de containers usa 8081; este exercício de LAN usa 8082.

curl --fail --show-error --resolve alpha.example.test:8080:127.0.0.1 http://alpha.example.test:8080/

Para verificações de LAN, prepare a rede exclusiva do host das lições 5/15 com servidor .20 e cliente Linux .10. Adicione o novo site abaixo na VM dedicada contendo o diretório raiz dos documentos da lição 23. Adapte consistentemente os endereços/caminhos verificados e verifique conflitos de portas primeiro. Arquivos existentes interrompem a operação. Se a validação ou a recarga falhar após a criação, o arquivo ou link já criado permanece no disco: inspecione-o e a cópia de segurança antes de decidir como restaurar, sem sobrescrever alterações de outras pessoas.

(
set -eu
site=/etc/nginx/sites-available/ubuntu-course-lan
enabled=/etc/nginx/sites-enabled/ubuntu-course-lan
sudo test -f /srv/ubuntu-course-alpha/index.html
if ! ip -4 -o address show | grep -Fq ' 192.168.56.20/24 '; then
    printf 'Configure the verified server lab address first.\n' >&2; exit 1
fi
for path in "$site" "$enabled"; do
    if sudo test -e "$path" || sudo test -L "$path"; then
        printf 'Existing lab site: inspect before changing.\n' >&2; exit 1
    fi
done
backup_dir=$(sudo mktemp -d /root/nginx-before-lan.XXXXXX)
sudo cp -a /etc/nginx "$backup_dir/"
printf 'LAN site backup: %s\n' "$backup_dir"
sudo sh -c 'set -C; cat > "$1"' sh "$site" <<'EOF'
server {
    listen 192.168.56.20:8082;
    server_name course-lab.example.test;
    root /srv/ubuntu-course-alpha;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}
EOF
sudo ln -s "$site" "$enabled"
sudo nginx -t
sudo systemctl reload nginx
sudo ss -lntp
printf 'LAN site backup: %s\n' "$backup_dir"
)

Adicione a regra abaixo em um ambiente com política UFW de negar entrada por padrão e acesso SSH preservado. Uma permissão ampla existente na porta 8082 invalida o teste de exclusão, então revise as regras reais. Não encaminhe essa porta da rede exclusiva do host para a internet.

sudo ufw allow from 192.168.56.10 to 192.168.56.20 port 8082 proto tcp
sudo ufw status numbered

Execute o curl abaixo a partir do cliente Linux permitido .10 e verifique a resposta alpha-site. Uma nova conexão de um cliente excluído, como o host .1, deve ser bloqueada pela política. Se nomes de host desconhecidos precisarem ser rejeitados, projete um host virtual de rejeição padrão separado; server_name não substitui filtragem ou autenticação.

curl --fail --show-error --connect-timeout 5 --max-time 10 --resolve course-lab.example.test:8082:192.168.56.20 http://course-lab.example.test:8082/

Para limpeza, identifique e remova apenas este site e sua regra UFW, depois valide e recarregue o Nginx. Preserve o site localhost e outros serviços. Após a reinicialização, meça novamente os endereços, ouvintes reais e conexões permitidas/excluídas.

Crie uma pequena verificação de integridade HTTP

Salve o script completo abaixo como ~/check-web-lab.sh. Ele requer Bash/curl e recebe a URL real e o texto esperado. Para a verificação local da lição 23, faça backup de /etc/hosts, confira entradas existentes e mapeie alpha.example.test para 127.0.0.1 no próprio servidor; então execute bash ~/check-web-lab.sh http://alpha.example.test:8080/ alpha-site. O --resolve anterior afeta uma invocação de curl, não a resolução de nomes deste script.

set -eu
if [ "$#" -ne 2 ]; then
    printf "Usage: bash check-web-lab.sh URL EXPECTED_TEXT\n" >&2
    exit 2
fi
url=$1
expected=$2
case "$url" in
    http://*|https://*) ;;
    *) printf "Use an HTTP or HTTPS URL.\n" >&2; exit 2 ;;
esac
if [ -z "$expected" ]; then
    printf "Expected text must not be empty.\n" >&2
    exit 2
fi
body_file=$(mktemp)
trap 'rm -f -- "$body_file"' EXIT
if ! curl --fail --silent --show-error --connect-timeout 5 --max-time 10 "$url" -o "$body_file"; then
    printf "FAIL: request or TLS verification failed\n" >&2
    exit 1
fi
if ! grep -Fq -- "$expected" "$body_file"; then
    printf "FAIL: expected text missing\n" >&2
    exit 1
fi
printf "PASS: %s %s\n" "$(date -u +%FT%TZ)" "$url"

Sucesso retorna código de saída 0 e PASS; falha em solicitação, TLS ou corpo retorna 1, e argumentos inválidos retornam 2. Teste uma string esperada deliberadamente ausente para verificar a detecção de falhas. Uma verificação HTTP não substitui a gravação em banco de dados, login ou verificações de backup. Mantenha credenciais fora da URL e organize separadamente a coleta dos tempos de execução e do status de saída.

Para o teste de integridade da LAN, mapeie course-lab.example.test para 192.168.56.20 no /etc/hosts do cliente .10 ou no DNS controlado, e então execute bash ~/check-web-lab.sh http://course-lab.example.test:8082/ alpha-site. Preserve o arquivo hosts antes de editar e evite entradas duplicadas de nomes. Distinga URLs locais, da LAN e HTTPS públicas, e rejeição esperada de falha de serviço.

Registre testes de acesso, reinicialização e restauração

Teste a partir de clientes realmente permitidos e excluídos, assim como do próprio servidor. Mantenha a conexão SSH existente enquanto abre uma nova, depois agende e verifique uma reinicialização. Restaure backups em um local vazio separado e verifique conteúdo, permissões e comportamento específico do aplicativo. Mantenha verificações não realizadas como pendentes.

Use o guia de firewall do Ubuntu juntamente com registros de regras reais e testes de conexão.

Preencha a entrega com valores medidos

Use este modelo como ponto de partida para um registro de operações. Substitua os colchetes pelos valores observados e faça referência a um repositório secreto aprovado em vez de copiar segredos. Atribua propriedade e responsabilidade de recuperação; não apresente endereços de exemplo ou um sucesso presumido como resultado medido.

Sistema: [nome do host, finalidade, responsável]
Plataforma: [versão do Ubuntu, kernel, host da VM, acesso ao console]
Rede: [interface, serviço de rede, endereço, gateway, DNS]
Acesso: [clientes permitidos, porta SSH em escuta, local de custódia das chaves]
Serviços: [versões, caminhos de configuração, comandos de validação e recarga]
Exposição: [portas em escuta, regras UFW, firewall externo, portas de contêineres]
TLS: [nomes de host, renovação, monitoramento de validade e falhas]
Backup: [escopo, identidade do destino independente, retenção, custódia das chaves]
Teste de restauração: [data, destino, resultados de conteúdo, permissões e aplicação]
Aceitação: [teste, cliente, resultado esperado e observado, local das evidências]
Reversão: [limite da alteração, estado preservado, procedimento de restauração]
Pendências: [testes não realizados, riscos, responsável e data prevista]

Mantenha evidências de verificação com o histórico de alterações e pergunte se outro administrador pode preparar acesso, inspeção e recuperação apenas a partir do registro. Destinatários nomeados da notificação, intervalos de revisão/atualização/certificado/backup e responsáveis pelo trabalho pendente fazem com que a operação continuada seja independente da memória do construtor original.