TP 2 – Gerenciamento de múltiplos sites web com um reverse proxy (proxy reverso) em um ambiente Linux

Tabela de conteúdos

• Contexto
• Objetivos da avaliação
• Instruções gerais
• Parte 1 – Instalação e configuração do Wiki.js
• Parte 2 – Configuração do reverse proxy NGINX
• Parte 3 – Validação, troubleshooting e análise
• Parte 4 – Questão de análise arquitetural
• Grade de avaliação
• Módulo Bônus 1 – Usuários de sistema vs usuários normais

---

CONTEXTO

Você é administrador de sistemas em uma empresa de serviços digitais. Sua missão é configurar um ambiente local hospedando três instâncias independentes do Wiki.js, cada uma representando um ambiente clássico de desenvolvimento de software:

• Ambiente de desenvolvimento (dev.site1.local)
• Ambiente de teste (test.site1.local)
• Ambiente de produção (prod.site1.local)

Cada instância do Wiki.js deve ser instalada manualmente em uma única máquina Ubuntu Server 24.04 LTS, conectada à sua própria base de dados MariaDB e exposta via um reverse proxy NGINX.

---

OBJETIVOS DA AVALIAÇÃO

• Dominar a instalação manual de um motor de wiki baseado em Node.js
• Gerenciar corretamente bancos de dados SQL distintos
• Automatizar a inicialização dos serviços via systemd
• Configurar um reverse proxy HTTP com subdomínios internos
• Diagnosticar erros frequentes de deploy
• Aplicar boas práticas de isolamento de serviço

Voltar à tabela de conteúdos

---

INSTRUÇÕES GERAIS

• Você trabalha em uma única máquina virtual Ubuntu 24.04
• Todas as instâncias devem ser independentes, sem conflito de portas
• Nenhum servidor deve ser exposto diretamente: apenas o proxy NGINX escuta na porta 80
• Os endereços *.site1.local devem funcionar via /etc/hosts
• Você deve seguir uma abordagem profissional, com estrutura, clareza e rigor

Voltar à tabela de conteúdos

---

PARTE 1 – INSTALAÇÃO E CONFIGURAÇÃO DO WIKI.JS (40 PONTOS)

1. Crie três usuários Linux dedicados: wikijs_dev, wikijs_test, wikijs_prod

2. Crie três bancos de dados distintos no MariaDB:

   • wikidb_dev, wikidb_test, wikidb_prod

3. Instale manualmente o Wiki.js em:

   • /var/www/dev.site1
   • /var/www/test.site1
   • /var/www/prod.site1

4. Modifique o arquivo config.yml de cada instância:

   • Porta diferente (3000, 3001, 3002)
   • bindIP: 127.0.0.1
   • Informações corretas de conexão ao banco

5. Crie e ative os serviços systemd:

   • wikijs-dev.service, wikijs-test.service, wikijs-prod.service

Voltar à tabela de conteúdos

---

PARTE 2 – CONFIGURAÇÃO DO REVERSE PROXY NGINX (30 PONTOS)

6. Configure o NGINX para servir os seguintes subdomínios:

Nome do host	Porta interna	Caminho local
dev.site1.local	3000	/var/www/dev.site1
test.site1.local	3001	/var/www/test.site1
prod.site1.local	3002	/var/www/prod.site1

7. Modifique /etc/hosts para apontar esses domínios para 127.0.0.1

8. Teste o acesso aos sites com um navegador ou curl

Voltar à tabela de conteúdos

---

PARTE 3 – VALIDAÇÃO, TROUBLESHOOTING E ANÁLISE (30 PONTOS)

9. Corrija os seguintes erros caso apareçam:

   • Indentação YAML incorreta
   • Problemas de conexão com o MariaDB
   • Porta já em uso
   • Permissões de arquivos insuficientes

10. Justifique as seguintes decisões:

    • Por que usar usuários diferentes para cada Wiki.js?
    • Por que preferir um reverse proxy ao invés de exposição direta?
    • Quais são os riscos de segurança se as portas forem expostas sem NGINX?

11. Proponha um método para proteger a instalação com HTTPS:

    • Uso do certbot
    • Configuração do bindIP
    • Papel do DNS público

Voltar à tabela de conteúdos

---

PARTE 4 – QUESTÃO DE ANÁLISE ARQUITETURAL (10 PONTOS)

Enunciado

Duas abordagens são possíveis para expor múltiplos ambientes:

Abordagem A: subdomínios → http://dev.site1.local, http://test.site1.local, http://prod.site1.local

Abordagem B: caminhos internos → http://site1.local/dev, http://site1.local/test, http://site1.local/prod

Questão

1. Compare as duas abordagens:

   a) Implicações técnicas principais (4 pontos) b) Casos de uso onde a abordagem B é tolerável, e quando ela é desaconselhada (3 pontos) c) Qual abordagem você recomenda e por quê? (3 pontos)

Voltar à tabela de conteúdos

---

GRADE DE AVALIAÇÃO

Critérios	Pontos
Wiki.js (x3) instalado e funcional	15
Bancos de dados distintos	10
Configuração correta do config.yml	10
Serviços systemd funcionais	5
NGINX reverse proxy configurado	15
/etc/hosts bem editado	5
Diagnóstico e resolução de erros	10
Justificativa técnica	10
Proposta HTTPS argumentada	10
Total	90

Análise da arquitetura	Pontos
Apresentação das diferenças	2
Casos de uso para cada abordagem	2
Análise de riscos e compatibilidade	2
Recomendação clara e motivada	4
Subtotal	10

---

MÓDULO BÔNUS 1 – Usuários de sistema vs usuários normais (humanos) no Linux

Convenção dos UID no Linux

Na maioria das distribuições Linux modernas, os usuários são classificados de acordo com seu UID (User ID):

Faixa de UID	Tipo de conta	Exemplos
0	Superusuário	root
1 – 999	Contas de sistema / serviço	daemon, www-data, sshd, systemd-*, apache
≥ 1000	Usuários normais (humanos)	alice, bob, etudiant

info

Essa faixa é definida no arquivo /etc/login.defs da sua distribuição. Não é uma regra universal, mas uma convenção amplamente adotada (Debian, Ubuntu, RHEL, Fedora, etc.).

Como verificar as faixas na sua máquina

# Ver as faixas de UID definidas na sua distro
grep -E '^(UID_MIN|UID_MAX|SYS_UID_MIN|SYS_UID_MAX)' /etc/login.defs

Resultado típico no Ubuntu:

SYS_UID_MIN    100
SYS_UID_MAX    999
UID_MIN        1000
UID_MAX        60000

Contas de sistema (UID < 1000) – Características

As contas de sistema são criadas para executar serviços/demons, não para conexões humanas.

Indícios típicos de uma conta de sistema:

• UID baixo (< 1000)
• Shell = /usr/sbin/nologin ou /bin/false (sem login interativo)
• Sem diretório home real de usuário (ou um home “técnico”)
• Criada com useradd -r (flag system account)

Exemplos comuns:

Conta	Serviço	UID típico	Shell
root	Superusuário	0	/bin/bash
www-data	Apache / Nginx (Debian/Ubuntu)	33	/usr/sbin/nologin
apache	Apache (RHEL/CentOS)	48	/sbin/nologin
sshd	Servidor SSH	105	/usr/sbin/nologin
mysql	MariaDB / MySQL	27	/bin/false

Verificação rápida:

# Ver o UID e o shell de www-data
id www-data
getent passwd www-data
# Resultado: uid=33(www-data) gid=33(www-data) groups=33(www-data)

Contas normais / humanas (UID ≥ 1000) – Características

As contas humanas são criadas para pessoas que se conectam ao sistema.

Indícios típicos de uma conta humana:

• UID ≥ 1000
• Shell = /bin/bash ou /bin/sh
• Diretório home em /home/<username>
• Criada com useradd (sem o flag -r) ou adduser

Comandos úteis para listar e distinguir os tipos de usuários

Listar usuários humanos (UID ≥ 1000):

UID_MIN=$(awk '/^UID_MIN/{print $2}' /etc/login.defs)
awk -F: -v m="$UID_MIN" '$3>=m {print $1" (uid="$3")"}' /etc/passwd | sort -t'=' -k2 -n

Listar usuários de sistema (UID < 1000):

UID_MIN=$(awk '/^UID_MIN/{print $2}' /etc/login.defs)
awk -F: -v m="$UID_MIN" '$3<m {print $1" (uid="$3")"}' /etc/passwd | sort -t'=' -k2 -n

Listar contas sem login (tipicamente de serviços):

awk -F: '($7 ~ /(nologin|false)$/) {print $1" -> "$7}' /etc/passwd

Listar contas “provavelmente humanas” (home em /home + shell bash/sh):

awk -F: '($6 ~ /^\/home\//) && ($7 ~ /(bash|sh)$/) {print $1" home="$6" shell="$7}' /etc/passwd

Relação com o TP: Por que wikijs_dev, wikijs_test, wikijs_prod são contas de sistema?

Neste TP, os usuários do Wiki.js foram criados com o comando:

sudo useradd -r -m -s /bin/bash wikijs_dev
sudo useradd -r -m -s /bin/bash wikijs_test
sudo useradd -r -m -s /bin/bash wikijs_prod

Opção	Papel
-r	Cria uma conta de sistema → UID atribuído na faixa de sistema (< 1000)
-m	Cria um diretório home (útil para arquivos de configuração)
-s /bin/bash	Define o shell (aqui bash para facilitar o debug no TP)

dica

É o flag -r que faz a diferença! Sem -r, a conta seria um usuário normal (UID ≥ 1000). O flag -s apenas define o shell, não torna a conta “de sistema”.

Essas contas são “service accounts”: elas são responsáveis por executar os serviços Wiki.js, conforme definido nos arquivos systemd:

[Service]
User=wikijs_dev    # ← o serviço roda sob esta conta de sistema

Verificação:

# Ver o UID atribuído (deve ser < 1000)
id wikijs_dev
id wikijs_test
id wikijs_prod

# Ver qual usuário executa cada processo Wiki.js
ps -eo user,pid,cmd | grep '[n]ode'

# Verificar o status do serviço
systemctl status wikijs-dev

Recomendação em produção

Em produção, é preferível não dar um shell interativo para contas de serviço:

# Melhor prática (shell nologin)
sudo useradd -r -m -s /usr/sbin/nologin wikijs_dev
sudo useradd -r -m -s /usr/sbin/nologin wikijs_test
sudo useradd -r -m -s /usr/sbin/nologin wikijs_prod

Com /usr/sbin/nologin, ninguém pode abrir uma sessão interativa com essa conta, mas systemd e sudo -u wikijs_dev <comando> continuam funcionando normalmente. Esse é o princípio do menor privilégio.

Resumo

• useradd -r → conta de sistema (UID < 1000, destinada a serviço)
• useradd (sem -r) → conta humana (UID ≥ 1000, destinada a uma pessoa)
• -s → define o shell, não muda o tipo de conta
• As contas wikijs_* deste TP são contas de sistema responsáveis por executar o serviço Wiki.js
• Em produção: sempre usar -s /usr/sbin/nologin para contas de serviço

Voltar à tabela de conteúdos

---

TP criado em: Dezembro 2024