Como construir uma pubnix ou tilde: tutoriais, arquitetura, segurança e operação

October 31, 2026 · 30 min read

Uma pubnix — ou tilde server — é uma máquina Unix compartilhada na qual pessoas recebem contas shell, publicam páginas pessoais, usam ferramentas de terminal e formam uma comunidade. Construí-la não é apenas instalar OpenSSH e criar usuários: o operador passa a administrar um ambiente multiusuário, moderar abusos, controlar recursos, proteger dados privados e manter uma promessa de continuidade. Esta pesquisa reúne os melhores tutoriais e repositórios encontrados, avalia o que cada um realmente ensina e transforma as fontes em um roteiro de implantação seguro e realista.

Resumo executivo

O melhor ponto de partida encontrado é o guia oficial e atualizado do tilde.club, Build a tilde-style machine. Ele é raro por tratar não só de instalação, mas também de console de recuperação, administrador de emergência, regras, contas, páginas pessoais, limites, backup externo e teste de restauração. Sua implementação de referência usa Fedora Server, nginx e SELinux, começando com páginas estáticas. A organização oficial do projeto também mantém documentação do servidor, um /etc/skel de referência e o script makeuser.

Para o ambiente de Pablo, a rota mais pragmática é Debian Stable + OpenSSH + Apache mod_userdir + systemd/cgroups + quotas de disco + backup externo com restic. Ela reaproveita experiência e documentação já existentes em torno do runv e oferece a implementação mais direta do endereço https://dominio/~usuario/. O tutorial oficial do tilde.club deve continuar sendo usado como checklist conceitual, mesmo quando os comandos forem adaptados do Fedora/nginx para Debian/Apache.

A primeira versão deve oferecer somente:

contas aprovadas manualmente;
login por chave SSH;
páginas HTML/CSS estáticas em ~/public_html;
ferramentas Unix selecionadas;
quotas de armazenamento e limites de processos/memória;
regras, contato de abuso e processo de suspensão;
backup fora do servidor com restauração testada.

E-mail público, PHP, CGI, containers para usuários, portas individuais, bots permanentes, Gopher, Gemini, fóruns e IRC devem entrar em camadas posteriores. Uma conta shell não é uma sandbox: qualquer membro pode executar programas, observar informações públicas do sistema e tentar consumir recursos. Cgroups, quotas e permissões diminuem acidentes e abuso oportunista, mas usuários realmente hostis exigem isolamento mais forte em VMs ou containers separados.

Há também um risco web pouco lembrado: o Apache alerta que páginas de vários usuários em URLs ~usuario compartilham a mesma origem. JavaScript de uma página pode afetar outra página ou aplicações autenticadas no mesmo domínio. Portanto, a pubnix deve começar com conteúdo estático e sem aplicações sensíveis na mesma origem. Se futuramente houver JavaScript, cookies, PHP ou CGI, o ideal é dar a cada membro um subdomínio próprio, como usuario.pubnix.example, e manter o painel administrativo em outro domínio.

Metodologia e critérios

Foram pesquisados tutoriais, documentação de operadores reais, repositórios de infraestrutura, manuais oficiais de OpenSSH, Apache, systemd e restic, além de textos comunitários sobre a criação de tildes. As fontes foram avaliadas por:

autoria e proximidade com uma pubnix em operação;
atualização e compatibilidade com sistemas atuais;
abrangência: instalação, contas, segurança, recursos, backup e comunidade;
possibilidade de reproduzir as instruções;
explicitação de riscos e limitações;
separação entre configuração observada em produção e exemplo novo.

Um tutorial de cadastro de usuário ou uma página “como entrar” não foi tratado como guia de construção. Da mesma forma, scripts públicos foram considerados referências a auditar, não receitas para executar como root sem revisão. Esta pesquisa não instalou um servidor nem realizou teste de invasão; configurações finais precisam ser validadas em uma máquina de laboratório antes da abertura de contas.

O que realmente compõe uma pubnix

Uma pubnix mínima tem seis sistemas sobrepostos:

Camada	Função	Falha típica
Sistema base	Atualizações, rede, DNS, firewall e relógio	Servidor desatualizado ou inacessível após uma mudança
Identidade	Contas, grupos, chaves SSH e recuperação	Conta indevida, chave perdida ou privilégio excessivo
Publicação	`public_html`, TLS e permissões	Arquivo privado exposto ou conteúdo executável inseguro
Recursos	Disco, memória, CPU, processos e portas	Um membro derruba a experiência de todos
Operação	Logs, alertas, backup, restauração e documentação	O operador só descobre a falha quando já perdeu dados
Comunidade	Propósito, regras, moderação, entrada e saída	Infraestrutura funcional sem cultura ou sem governança

O texto comunitário So, You Wanna Make A Tilde? acerta ao colocar a pergunta “por quê?” antes da escolha do sistema operacional. Uma tilde para amigos, uma comunidade de arte textual e um laboratório de programação têm riscos, pacotes e regras diferentes. A identidade não nasce da quantidade de serviços, mas do motivo para as pessoas voltarem.

Os melhores tutoriais e materiais encontrados

As fontes abaixo foram ordenadas pela utilidade para quem realmente pretende operar o servidor, e não apenas conhecer ou usar uma pubnix.

1. Guia moderno do tilde.club — a referência principal

O guia oficial de construção é a fonte mais completa e atual. Ele usa Fedora Server e nginx, sugere para um pequeno grupo inicial 2 CPUs, 4 GiB de RAM e 60 GiB de SSD, exige console de recuperação independente do SSH, backup externo, contato publicado e decisão prévia sobre cadastros, uso aceitável, remoção de contas e limites de disco.

Seus melhores princípios são independentes da distribuição:

manter o SELinux ativo em uma instalação nova;
não colocar usuários comuns em wheel nem no grupo administrativo de Docker/Podman;
preparar /etc/skel antes de criar muitas contas;
começar com publicação estática;
criar dois membros descartáveis e testar acesso cruzado;
verificar SSH com uma segunda sessão antes de fechar a primeira;
tratar quota de disco, CPU, memória e processos como controles diferentes;
concluir uma restauração isolada antes de abrir inscrições;
registrar a versão de todo software instalado manualmente.

A página Web publishing aprofunda o mapeamento de ~usuario, permissões, SELinux, TLS, PHP-FPM e CGI. Ela recomenda home em 0711, public_html em 0755 e arquivos públicos em 0644, com diretórios privados em 0700 e arquivos privados em 0600. Também deixa claro que executar PHP de vários membros em um pool compartilhado não equivale a isolamento por usuário.

Veredito: melhor guia geral e melhor checklist operacional. A rota Fedora/nginx é a mais fiel à fonte; outras distribuições devem adaptar os comandos sem abandonar os testes.

2. Repositório do tilde.club — infraestrutura real para estudar

A organização verificada tildeclub reúne código e documentação usados por uma comunidade real. Os componentes mais úteis são:

tilde.club: documentação e configurações do servidor;
tilde.etcskel: arquivos iniciais para novas homes;
makeuser: criação de contas e integrações;
motd, site, Gopher e Gemini: exemplos de cultura e serviços.

O registro do sistema em produção é especialmente instrutivo porque distingue o que foi observado do que apenas é recomendado. Ele mostra uma máquina que acumulou OpenSSH, nginx, PHP, CGI, Postfix, Dovecot, Rspamd, SnappyMail, INN, Gopher, Gemini, ZNC, MariaDB, Valkey e Borgmatic — e documenta inconsistências e pontos ainda não comprovados. Isso é uma advertência útil: uma pubnix madura vira um conjunto de sistemas com ciclos de atualização e recuperação próprios.

Veredito: excelente para engenharia reversa e inspiração. Não copiar a árvore de /etc/skel ou scripts para produção sem revisar dependências, permissões, caminhos e integrações locais.

3. Segurança Unix do tilde.club — permissões compreensíveis

O tutorial Basic UNIX security the Tilde way explica permissões para membros e operadores. O padrão chmod 711 ~ impede listar a home, mas ainda permite atravessar o caminho conhecido até public_html. Isso não torna tudo privado: qualquer arquivo legível por “others” e cujo caminho seja conhecido ainda pode ser aberto.

O documento também reforça o uso de grupos Unix para colaboração. Em uma pubnix, o padrão mais seguro é criar um grupo primário privado por usuário e grupos adicionais apenas para projetos compartilhados. Um único grupo coletivo como primário aumenta o risco de arquivos acidentalmente graváveis ou legíveis por todos.

Veredito: melhor introdução curta para permissões e material ideal para o guia de boas-vindas dos membros.

4. Tildeverse Zine — propósito, sustentabilidade e limites

O ensaio So, You Wanna Make A Tilde? não é um passo a passo de comandos, mas cobre o que os guias técnicos geralmente omitem: tempo, dinheiro, escolha entre máquina doméstica e VPS, manutenção de hardware, experiência do operador e identidade comunitária. Sua recomendação implícita é começar pequeno e não imitar todos os serviços de outra tilde.

Veredito: leitura obrigatória antes da compra do servidor; fraca como instalação, forte como desenho de comunidade.

5. tilde.institute — um modelo OpenBSD mais restritivo

A FAQ do tilde.institute revela decisões operacionais de uma pubnix OpenBSD: pacotes vêm da árvore de ports; ferramentas potencialmente abusivas podem ser recusadas; SMTP é local e pode ser acessado por túnel SSH; portas arbitrárias não são liberadas; serviços de usuário são permitidos enquanto não prejudiquem os demais; processos pesados podem ser reniciados ou encerrados.

Esse material não ensina a instalar uma pubnix inteira, mas demonstra como uma política simples reduz a superfície de suporte. OpenBSD com httpd, sshd, pf e ferramentas base é atraente para uma comunidade menor, desde que o operador já domine o sistema.

Veredito: melhor contraponto minimalista. Não é a melhor primeira plataforma para quem só conhece administração Linux.

6. Apache `mod_userdir` — a documentação obrigatória da rota Debian

A documentação oficial do Apache mod_userdir explica a tradução de /~usuario/ para ~/public_html, como ativar ou desativar usuários e por que UserDir disabled root é necessário. O alerta mais importante é sobre a mesma origem web: páginas de usuários diferentes podem interferir umas nas outras quando JavaScript, autenticação e conteúdo dinâmico compartilham domínio.

Veredito: tutorial curto, primário e indispensável para Apache. Deve ser lido junto com as recomendações gerais de segurança do servidor web.

7. OpenSSH, systemd e restic — os manuais que completam a pubnix

O manual oficial de sshd_config documenta AllowGroups, PermitRootLogin, AuthenticationMethods, limites de sessões e controles de encaminhamento. Ele também faz uma ressalva decisiva: bloquear TCP forwarding ou agent forwarding não cria segurança forte quando a pessoa já possui shell, pois ela pode executar seus próprios programas de rede.

A documentação de controle de recursos do systemd mostra como aplicar MemoryHigh, MemoryMax, CPUWeight, CPUQuota e TasksMax a slices. O manual de user@.service explica que cada UID recebe uma user-UID.slice, permitindo limites por membro.

Para recuperação, a documentação do restic cobre backup, inspeção de snapshots e restauração. Um job “verde” não basta: deve existir restauração periódica para um diretório isolado, com conferência de conteúdo, dono, grupo, modos e atributos estendidos.

Veredito: não são tutoriais de tilde, mas são as fontes primárias corretas para os controles que tutoriais comunitários frequentemente simplificam.

8. Ansible e automação de contas — somente depois do processo manual funcionar

O papel totaldebug.users exemplifica gerenciamento declarativo de usuários, grupos privados, homes, shells, chaves autorizadas, senhas bloqueadas e expiração. É útil quando a pubnix já possui um fluxo definido e precisa reproduzi-lo.

Automatizar cedo demais congela decisões ruins. Primeiro, criar e remover cinco contas de laboratório manualmente; depois, transformar os passos validados em um script idempotente ou papel Ansible próprio. O script oficial makeuser serve como estudo de integrações, não como substituto de uma especificação local.

Veredito: bom para a segunda fase. O inventário nunca deve conter chaves privadas, senhas em claro ou tokens.

9. SDF e envs.net — experiência do membro e políticas transparentes

O acervo de tutoriais do SDF e sua wiki são melhores como referência de produto que como documentação de infraestrutura. Eles mostram como ensinar shell, correio, páginas, Gopher, Gemini e IRC, além de liberar recursos progressivamente por níveis. Isso inspira um modelo no qual uma conta nova começa com privilégios pequenos e recebe rede, processos persistentes ou outros recursos depois de validação humana. O SDF não publica um runbook moderno que permita reconstruir seu backend inteiro.

O envs.net é um estudo de caso atual de transparência. Seu formulário de inscrição pede nome, contato, motivação e chave pública SSH; seus termos publicam usos proibidos e limites concretos. Os números não devem ser copiados sem medir o próprio host, mas o formato é exemplar: o membro sabe antes de entrar o que recebe, o que pode executar e como o abuso será tratado.

Veredito: SDF é a melhor inspiração para onboarding e progressão de privilégios; envs.net é um ótimo modelo de formulário, AUP e limites publicados. Nenhum dos dois substitui o guia técnico do tilde.club.

Lacunas encontradas na pesquisa

Não existe um pacote completo e atual. Nenhum projeto encontrado cobre, de forma auditável e reproduzível, sistema base, inscrições, quotas, cgroups, publicação, moderação, backup e monitoramento.
tilde.team não expõe um playbook atual verificável. Há documentação de uso e serviços comunitários, mas não base pública suficiente para tratá-la como tutorial de reconstrução do host.
SDF documenta o membro, não o backend inteiro. Sua governança e experiência são valiosas; detalhes administrativos e de hardening não formam uma receita replicável.
Automação histórica precisa de auditoria. tilde.institute/admin-scripts, tildetown-admin e adminbot ajudam a levantar requisitos, mas são antigos ou incompletos para implantação direta em 2026.
Quase não há suítes de teste de abuso. O projeto local terá de criar testes para exaustão de processos e inodes, symlinks, leitura cruzada, listeners, limites de memória, restauração e conteúdo executável.
E-mail é subestimado. Tutoriais comunitários frequentemente não cobrem reputação, entregabilidade, spam e resposta a abuso com profundidade suficiente; correio externo deve ser um projeto separado.

Essa fragmentação não impede construir uma pubnix; apenas exige compor fontes primárias e documentar as decisões locais, em vez de procurar um instalador universal.

Três arquiteturas viáveis

Rota	Componentes	Vantagens	Limitações	Indicação
Debian Stable + Apache	OpenSSH, Apache `mod_userdir`, nftables, systemd, quotas, restic	Simples para `~usuario`, grande documentação, familiaridade e estabilidade	Exige cuidado com origem compartilhada; MAC menos integrado que SELinux na rota oficial	Recomendada para Pablo e para um MVP do runv
Fedora Server + nginx	OpenSSH, nginx, SELinux, firewalld, systemd, quotas, Borg/restic	É a rota do tutorial moderno do tilde.club; SELinux e documentação atual	Mapeamento de homes no nginx exige configuração explícita; ciclo de atualização mais curto	Melhor para reproduzir o guia oficial
OpenBSD	OpenSSH, `httpd`, `pf`, `relayd`, quotas e ferramentas base	Sistema coeso, superfície pequena, documentação excelente	Menor catálogo, diferenças operacionais e menos tutoriais completos de tilde	Operador experiente que quer comunidade pequena

Containers por membro parecem atraentes, mas mudam o produto: deixam de ser uma única máquina Unix compartilhada e criam uma plataforma de hospedagem com rede, imagens, volumes, atualizações e isolamento de containers. Além disso, conceder acesso ao socket Docker equivale, na prática, a oferecer controle privilegiado do host. Containers podem ser uma camada futura para aplicações específicas, nunca o grupo padrão de usuários.

Arquitetura recomendada para o primeiro servidor

O desenho abaixo privilegia recuperação, simplicidade e crescimento gradual, com componentes que podem ser substituídos sem refazer toda a comunidade.

Topologia

Internet
   |
firewall do provedor + nftables
   |
VPS Debian Stable
   |-- OpenSSH: contas shell e administração
   |-- Apache: site principal e /~usuario/
   |-- systemd-logind: sessões e slices por UID
   |-- quotas: armazenamento por usuário
   |-- journald/rsyslog: eventos operacionais
   `-- restic: backup cifrado para destino externo

Fora da VPS
   |-- console/recovery do provedor
   |-- repositório de configuração sem segredos
   |-- backup criptografado
   `-- cópia offline das chaves de recuperação

Tamanho inicial

A referência razoável é 2 vCPU, 4 GiB de RAM e 60 GiB de SSD para uma pequena comunidade, conforme o guia atual do tilde.club. Isso não é garantia de capacidade: compilação, bots, bancos, e-mail e jogos mudam drasticamente o consumo. Abrir primeiro para 5 a 10 pessoas e medir durante um mês é mais seguro que anunciar dezenas de contas.

Separação de papéis

root: sem login remoto direto; usado apenas por sudo e console de recuperação.
operador: conta administrativa com chave forte e MFA quando o processo estiver testado.
pubnix: grupo que autoriza login dos membros.
grupo privado por membro: mesmo nome e GID próprio.
contas de serviço: Apache, backup, Gopher, Gemini e outros sem shell interativo.
pubnix-suspensos: registro administrativo, não grupo com acesso.

É útil ter um segundo administrador ou, no mínimo, um procedimento de emergência: acesso ao console, instruções de recuperação, contato do provedor, chave de backup e documentação do DNS. Essa pessoa não precisa operar diariamente, mas a comunidade não deve depender de uma única memória humana.

Tutorial de implantação em fases

As fases devem ser concluídas e testadas na ordem; serviços opcionais só entram depois que o núcleo estiver recuperável e observável.

Publicar uma página curta respondendo:

qual é o propósito da comunidade;
quem pode solicitar conta e como ocorre aprovação;
quais usos são permitidos e proibidos;
quais dados o operador registra;
se existe expectativa de backup ou disponibilidade;
quando uma conta inativa pode ser arquivada;
como denunciar abuso ou recuperar acesso;
como o projeto avisa manutenção e encerramento.

Proibições mínimas: mineração, spam, phishing, malware, varredura sem autorização, proxies públicos, violação deliberada de copyright, assédio, tentativa de obter dados de outros membros e consumo desproporcional de recursos. As regras também devem permitir experimentação legítima: compilar, programar, hospedar páginas, usar clientes IRC e executar pequenos processos são parte da razão de existir da pubnix.

Fase 1 — provisionar e garantir recuperação

Registrar o domínio e criar DNS para um nome como pubnix.example.
Criar uma VPS com console web ou modo de resgate independente do SSH.
Instalar Debian Stable mínimo e aplicar todas as atualizações.
Configurar hostname, sincronização de tempo e notificações de atualização.
Abrir inicialmente apenas SSH, HTTP e HTTPS.
Testar console e resgate antes de qualquer endurecimento.
Registrar versão do sistema, endereço, zona DNS, provedor e procedimento de reconstrução.

Não publicar AAAA até testar IPv6 de fora. Um serviço pode parecer protegido em IPv4 e ficar exposto por uma regra IPv6 esquecida. Se houver intenção de enviar e-mail diretamente, reverse DNS, SPF, DKIM e DMARC terão de entrar no planejamento.

Fase 2 — criar administração segura

O fluxo seguro é:

criar a conta administrativa com grupo privado;
instalar sua chave pública em .ssh/authorized_keys;
confirmar login e sudo em uma segunda sessão;
validar a configuração com sshd -t;
somente então desativar login de root e senha;
manter a sessão original aberta até o novo caminho funcionar.

Uma base de política pode incluir:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
AllowGroups pubnix-admin pubnix
X11Forwarding no
PermitTunnel no

Essas diretivas precisam ser compatíveis com a versão instalada e com qualquer arquivo em sshd_config.d. O comando sshd -T mostra a configuração efetiva. Se a comunidade quiser túneis SSH, agent forwarding ou automação sem TTY, cada recurso deve ser deliberadamente permitido e documentado; não confundir a desativação desses recursos com sandbox de usuário.

Fase 3 — preparar `/etc/skel`

O esqueleto mínimo de uma conta deve conter:

/etc/skel/
|-- .profile
|-- .bashrc
|-- .ssh/                 0700
|   `-- authorized_keys   0600, vazio
|-- public_html/          0755
|   `-- index.html        0644
|-- README.md
`-- WELCOME.txt

O conteúdo inicial deve ensinar como editar a página, mudar a shell, consultar quota, pedir pacote, encontrar as regras e falar com os operadores. Nunca colocar chave privada, segredo, token ou credencial compartilhada em /etc/skel. Testar o esqueleto criando um usuário descartável; mudanças posteriores no esqueleto não atualizam automaticamente homes já existentes.

Fase 4 — implantar publicação estática

Na rota Debian/Apache, ativar mod_userdir, desabilitar explicitamente root e usar public_html. A configuração conceitual é:

UserDir disabled root
UserDir public_html

<Directory /home/*/public_html>
    AllowOverride None
    Options -Indexes +SymLinksIfOwnerMatch
    Require all granted
</Directory>

Antes de aplicar, conferir a documentação da versão instalada, validar com apachectl configtest e testar em HTTP local. Em seguida, emitir certificado TLS, configurar renovação e verificar a renovação em modo de teste.

O modelo de permissões recomendado é:

Caminho	Modo	Motivo
`/home/usuario`	`0711`	permite atravessar até a web sem listar a home
`~/.ssh`	`0700`	somente o dono acessa
`~/.ssh/authorized_keys`	`0600`	chave pública autorizada protegida contra alteração alheia
`~/public_html`	`0755`	Apache atravessa e lê conteúdo público
arquivos web	`0644`	leitura pública, escrita só pelo dono
diretórios privados	`0700`	acesso apenas do dono
arquivos privados	`0600`	leitura e escrita apenas do dono

Testes obrigatórios com dois usuários descartáveis:

a página de cada um abre por HTTPS;
o usuário A não lista a home do usuário B;
arquivos privados conhecidos não são legíveis;
dotfiles, chaves e backups não são publicados;
symlinks para fora de public_html não expõem dados;
a página funciona após novo login e reinício do Apache.

Não habilitar .htaccess, CGI, SSI, PHP, listagem de diretório ou proxy reverso por membro no MVP. Cada recurso amplia a matriz de ataque e suporte.

Fase 5 — criar um processo de contas auditável

O formulário de entrada deve pedir somente o necessário: nome de usuário desejado, chave pública SSH, contato, breve motivo e aceite das regras. Evitar data de nascimento, documento, endereço e outros dados que não serão usados.

O processo de criação precisa:

validar nome por uma expressão conservadora, por exemplo ^[a-z][a-z0-9_]{2,15}$;
rejeitar nomes reservados e conflitos existentes;
criar usuário e grupo privado;
usar shell presente em /etc/shells;
instalar somente a chave pública recebida;
aplicar donos e modos corretos;
definir quota e limites de recursos;
registrar operador, data e identificador do pedido;
testar login sem conhecer a chave privada;
enviar instruções de boas-vindas sem segredo reutilizável.

Na primeira dezena de contas, fazer isso com checklist e revisão humana. Depois, converter o procedimento em script idempotente ou Ansible. O inventário deve armazenar estados desejados, não senhas em claro. Alterações e remoções devem passar pela mesma automação para evitar contas órfãs.

Fase 6 — limitar armazenamento, processos e memória

Quota de disco não controla CPU; ulimit não controla todo o consumo de uma sessão; nice é prioridade, não limite. Uma política completa combina:

quota por usuário e por grupo no sistema de arquivos;
TasksMax para impedir fork bombs;
MemoryHigh como pressão e MemoryMax como teto;
CPUWeight para justiça e, apenas quando necessário, CPUQuota;
limites de arquivos abertos e tamanho de processos via PAM/systemd;
monitoramento de inodes, não apenas de gigabytes.

O systemd agrupa processos de cada UID em user-UID.slice. É possível gerar um drop-in por membro, por exemplo:

[Slice]
TasksMax=256
MemoryHigh=1G
MemoryMax=1536M
CPUWeight=50

Os valores são ponto de partida, não números universais. Aplicar primeiro a uma conta de teste e confirmar com systemctl show user-UID.slice. Não colocar o administrador sob um limite que impeça recuperação. Para compilação e tarefas legítimas, limites muito baixos tornam a pubnix inútil; medir picos reais antes de endurecer.

Fase 7 — implantar backup e restauração

O backup deve sair da VPS e incluir:

/home, preservando donos, grupos, modos, ACLs e atributos;
/etc e configurações do firewall, SSH e web;
/usr/local, /opt e /srv quando usados;
site principal, documentação e fila de cadastros;
dumps consistentes de bancos, nunca apenas arquivos de banco em uso;
manifesto de usuários, UIDs, GIDs, shells, grupos e quotas;
timers, serviços e scripts locais;
lista de pacotes e versões de software manual.

O restic cifra e deduplica snapshots, mas a senha e a chave de recuperação precisam existir fora do host. Uma rotina madura tem backup diário, verificação periódica do repositório e restauração mensal de uma conta de teste para diretório isolado. Conferir não apenas o conteúdo, mas também UID/GID, permissões, ACLs, links e a capacidade de reconstruir o serviço web.

Snapshots do provedor ajudam em falhas rápidas, mas não substituem backup independente: podem desaparecer com a conta, com a região ou com um incidente no próprio provedor.

Fase 8 — abrir uma prévia privada

Convidar 5 a 10 pessoas conhecidas por 30 dias. Pedir que testem:

criação e troca de chaves;
publicação e remoção de páginas;
compilação pequena e processos persistentes permitidos;
consulta de quota;
documentação de boas-vindas;
canal de ajuda e denúncia;
recuperação de uma conta bloqueada;
manutenção anunciada e reinício.

Medir espaço, inodes, memória, carga, processos por UID, tentativas de autenticação, erros web, idade do último backup e expiração de certificados. A prévia deve produzir mudanças no runbook antes da abertura pública.

Segurança: o que os tutoriais simplificam

Os controles seguintes reduzem falhas e abuso, mas não transformam um host Unix compartilhado em ambiente adequado para inquilinos mutuamente hostis.

Shell compartilhada não isola adversários

Permissões Unix protegem arquivos quando estão corretas; não impedem que membros executem código, abram conexões, enumerem processos permitidos, explorem bugs locais ou tentem engenharia social. A pubnix deve ser uma comunidade com entrada moderada, não hospedagem anônima para pessoas mutuamente hostis.

Atualizações de kernel e bibliotecas são prioridade. Serviços extras devem usar contas próprias, privilégios mínimos e portas explicitamente aprovadas. Compiladores não devem ser removidos: o guia do tilde.club observa corretamente que programar é parte do propósito e que controle de recursos deve ser real, não um chmod improvisado.

O grupo Docker é administrativo

Membros não entram em docker, podman privilegiado, libvirt, lxd, wheel, sudo ou grupos que escrevem em configurações e sockets de serviços. Se alguém precisar de container, oferecer uma VM separada, um serviço raiz operado pela equipe ou uma plataforma rootless cuidadosamente desenhada.

Conteúdo web dinâmico precisa de identidade própria

PHP ou CGI executado como o usuário do servidor web permite que um membro leia dados de outro se as permissões estiverem erradas. Um pool PHP compartilhado não é isolamento. Antes de conteúdo executável, exigir:

subdomínio por usuário para separar origem;
pool/processo por UID;
socket e diretórios privados por usuário;
open_basedir apenas como defesa complementar, não fronteira principal;
limites de systemd e timeout;
negação de dotfiles, fontes e backups;
teste em tempo de execução de getuid()/posix_geteuid();
logs e procedimento para desligar rapidamente um pool.

Privacidade dos logs

Registrar o necessário para autenticação, capacidade e incidentes, com retenção publicada. Não guardar comandos de shell de todos os membros por padrão nem inspecionar conteúdo privado sem motivo e regra claros. Logs também contêm IPs, nomes, caminhos e tokens acidentalmente enviados; precisam de acesso restrito, rotação e prazo de exclusão.

Suspensão, remoção e resposta a abuso

Um procedimento previsível protege comunidade e operador:

suspender novos logins sem apagar dados;
encerrar processos do UID quando houver risco ativo;
bloquear chaves e processos persistentes;
preservar logs estritamente relevantes e registrar quem agiu;
verificar páginas, crons, units de usuário e chaves adicionais;
comunicar o membro quando isso não aumentar o risco;
permitir recurso quando apropriado;
arquivar ou excluir a conta conforme a política publicada.

Nunca “resolver” um incidente apagando imediatamente a home: isso destrói evidência, dificulta correção de falso positivo e pode eliminar o único exemplar do trabalho do membro. Para encerramento normal, oferecer prazo e uma forma segura de exportação. Para conteúdo ilegal ou risco imediato, seguir a legislação e o processo do provedor.

Serviços adicionais e ordem recomendada

Serviço	Quando adicionar	Principal custo oculto
MOTD e diretório de membros	No MVP	moderação e atualização
Gopher e Gemini estáticos	Depois da publicação web	mais daemons, TLS e documentação
IRC externo via cliente	No MVP	suporte a clientes e sessões persistentes
ZNC/Soju operado pela equipe	Após limites e backup	credenciais, portas, atualizações e abuso de rede
Correio local	Segunda fase	privacidade, quotas e clientes
Envio de e-mail à Internet	Somente com operação madura	reputação de IP, spam, PTR, SPF, DKIM, DMARC e filas
Git compartilhado	Segunda fase	permissões, quotas e backup
PHP/CGI	Depois de isolamento por usuário	execução de código, origem web e incidentes
Containers de aplicações	Projeto separado	privilégio, rede, imagens, volumes e atualizações
Servidor IRC próprio	Quando houver comunidade para mantê-lo	moderação, abuso e federação

A decisão do tilde.institute de manter SMTP apenas local e recusar portas arbitrárias mostra uma boa disciplina para o início. Usar um IRC já existente, como tilde.chat, também evita transformar o primeiro mês em uma operação de rede completa.

Monitoramento mínimo

O operador precisa receber alerta para:

indisponibilidade de SSH e HTTPS;
disco ou inodes acima de 80% e 90%;
memória sob pressão e OOM kills;
carga sustentada e crescimento anormal de processos;
muitas falhas de autenticação;
conta com uso muito acima da mediana;
backup atrasado, falho ou não verificado;
certificado perto de expirar;
atualizações de segurança pendentes;
novos listeners de rede não documentados.

O painel não precisa ser sofisticado. systemd timers, journalctl, ss, df, du, systemd-cgtop, smartctl quando houver acesso ao disco, um monitor externo e relatórios por e-mail já cobrem o início. O mais importante é existir uma pessoa responsável por responder.

Roteiro prático de 30 dias

O cronograma propõe um mês de laboratório e prévia privada antes de qualquer abertura pública ampla.

Semana 1 — laboratório

definir propósito, nome, regras e política de contas;
criar VPS de laboratório e testar console de recuperação;
instalar Debian, SSH, Apache e TLS;
criar dois usuários descartáveis;
executar testes de acesso cruzado e publicar uma página estática.

Semana 2 — operação

configurar quotas e slices por UID;
implementar backup externo com restic;
restaurar uma home em local isolado;
colocar configurações sem segredos em Git;
escrever runbooks de criação, suspensão, atualização e recuperação.

Semana 3 — prévia privada

convidar cinco pessoas;
medir recursos e corrigir documentação;
testar troca de chave, expiração e arquivamento;
simular perda do acesso SSH usando console do provedor;
realizar manutenção anunciada e validar comunicação.

Semana 4 — decisão de abertura

revisar métricas e incidentes;
ajustar quotas e pacotes;
confirmar segundo contato administrativo;
executar novo restore;
publicar status, regras, contato e formulário;
abrir poucas vagas, sem cadastro automático irrestrito.

Checklist de validação antes do primeiro membro público

Recomendações práticas

Construir primeiro uma tilde pequena e estática. SSH, ferramentas Unix e public_html já formam uma pubnix útil.
Usar Debian Stable + Apache no primeiro protótipo de Pablo, mantendo o tutorial Fedora/nginx do tilde.club como checklist de operação e segurança.
Separar a administração web da origem das páginas de membros. Para conteúdo dinâmico futuro, migrar membros para subdomínios individuais.
Aceitar contas manualmente no início. Cadastro automático aberto transforma spam e abuso em problema imediato.
Tratar limites como política de justiça, não como sandbox. Membros hostis precisam de VMs separadas.
Automatizar somente o processo já validado. Script de usuário deve ser idempotente, auditável e incapaz de interpretar entrada como comando.
Não oferecer e-mail externo, PHP ou containers no lançamento. Esses três recursos multiplicam suporte e superfície de ataque.
Fazer uma restauração antes da abertura. Backup sem restore é apenas uma esperança.
Projetar a comunidade para sobreviver ao operador. Documentação, segundo contato, domínio, backup e chaves de recuperação não podem existir apenas na cabeça de uma pessoa.
Criar uma identidade própria. O diferencial pode ser língua portuguesa, arte ANSI, escrita, projetos de small web, experimentos de terminal ou educação — não precisa ser uma lista maior de daemons.

Conclusão

Existe hoje um tutorial realmente forte para construir uma pubnix: o guia moderno do tilde.club, apoiado por seu repositório, documentação web, /etc/skel e scripts públicos. Ele deve ser a referência principal, mas não precisa determinar a distribuição. Para Pablo, Debian Stable e Apache formam o caminho mais direto por combinar familiaridade, estabilidade e mod_userdir; Fedora/nginx é a rota mais fiel ao operador de referência; OpenBSD é uma alternativa enxuta para uma segunda implementação.

O projeto deve começar como uma comunidade Unix pequena, com contas aprovadas, SSH por chave, páginas estáticas, recursos limitados, regras claras e backup restaurável. A medida correta de sucesso não é quantos serviços foram instalados, mas se dez pessoas conseguem conviver, publicar, aprender e confiar que o operador sabe recuperar a máquina. Depois que esse núcleo funcionar por algumas semanas, Gopher, Gemini, correio local, bouncer IRC e aplicações por usuário podem ser adicionados um de cada vez, cada qual com dono, limites, logs e plano de restauração.

Fontes consultadas

Nota sobre atualidade

Pesquisa concluída em 30 de outubro de 2026. Sistemas operacionais, pacotes, sintaxe de configuração e repositórios mudam; confirme os comandos na documentação da versão instalada e teste em laboratório antes de abrir contas públicas.

Did this resonate?

Related