Sophia Host

O que distingue uma organização capaz de uma mera agregação de indivíduos não é o talento — o talento raramente é o factor limitante.

É a infraestrutura através da qual o conhecimento deixa de se perder, o esforço deixa de se duplicar, e o trabalho de cada um começa a capitalizar sobre o que outros já resolveram — infraestrutura que, quando fechada, impõe um tecto a esse processo, porque o que não pode ser examinado não pode ser melhorado, e o que não pode ser melhorado será inevitavelmente a razão pelo qual ficarão para trás.

Operação independente, fundação partilhada. É isso que esta infraestrutura torna possível.

IRC

Web

Duas ferramentas, propósitos distintos. A wiki retém conhecimento — estruturado, pesquisável, pertencente a quem o escreve. O quadro de projecto retém trabalho — tarefas, coordenação e o fio que liga ambos. Em conjunto formam o tecido conjuntivo entre o que as pessoas sabem e o que as pessoas fazem.

Knowledge Base

Uma base de conhecimento é, na sua forma mais simples, um repositório estruturado do que uma organização sabe — documentação, procedimentos, material de referência e o registo acumulado de decisões tomadas e problemas resolvidos. O valor de um tal sistema é proporcional à consistência com que é utilizado e à fiabilidade com que pode ser consultado; uma base de conhecimento que se fragmenta por diversas ferramentas, ou que depende da disciplina individual de cada colaborador para se manter coerente, tende para a entropia em vez da utilidade.

O que raramente se reconhece é que a escolha da plataforma não é neutra. A maior parte dos sistemas de conhecimento é construída sobre o pressuposto de que a informação flui de cima para baixo — que alguém decide o que é documentado, de que forma e quem pode consultar. Isto produz sistemas ordenados na aparência e frágeis na prática, porque as pessoas mais próximas do trabalho raramente são aquelas com o acesso ou o incentivo necessários para os manter actualizados. O conhecimento que efectivamente move uma organização — o raciocínio por detrás das decisões, as lições que não chegaram ao relatório, o contexto que torna um procedimento inteligível — tende a existir completamente fora desses sistemas.

Basilar é a plataforma sobre a qual esta base de conhecimento assenta, e o seu desenho reflecte um conjunto diferente de pressupostos. Cada página é um ficheiro simples, independente de infraestrutura de base de dados, o que torna o sistema portátil, recuperável e legível sem manutenção especializada. Os controlos de acesso operam ao nível da página e do grupo de forma nativa, pelo que a mesma instalação contém notas privadas, documentos de trabalho partilhados e material de referência aberto numa estrutura coerente — não por via de soluções alternativas, mas por desenho. Uma pessoa que trabalhe sozinha pode utilizá-lo como sistema de conhecimento pessoal. Uma pequena equipa pode utilizá-lo como superfície de trabalho partilhada. Uma organização maior pode utilizá-lo para conter a complexidade total do que sabe, com as fronteiras entre o aberto e o privado traçadas precisamente onde são necessárias.

Isto importa porque o conhecimento não respeita organigramas. A pessoa com a compreensão mais clara de um problema nem sempre é aquela com autoridade para o documentar, e a fronteira entre o que pertence a um departamento e o que pertence à organização é, na prática, raramente nítida. Um sistema capaz de acomodar isto — que permita contribuição sem exigir autorização, que permita privacidade sem exigir separação, que permita que a estrutura emerja do uso em vez de ser imposta antes dele — não é apenas mais conveniente. É mais honesto sobre a forma como o conhecimento efectivamente se move entre pessoas. Uma base de conhecimento que se fragmenta entre ferramentas ou que depende da disciplina individual tende para a entropia. A maioria das plataformas parte do princípio de que a informação flui de cima para baixo, produzindo sistemas ordenados que, na prática, são frágeis — os que estão mais próximos do trabalho raramente têm o acesso ou o incentivo para os manter atuais, e o conhecimento que realmente move a organização fica de fora.

O Basilar? inverte esta lógica. Os ficheiros planos tornam o sistema portátil e recuperável; os controlos de acesso ao nível da página e do grupo permitem que material privado, partilhado e aberto coexistam de forma nativa, sem artifícios. A contribuição não exige autorização, a privacidade não exige separação e a estrutura emerge do uso, em vez de ser imposta de antemão. Isto não é apenas mais conveniente. É mais honesto sobre a forma como o conhecimento realmente circula entre as pessoas.

Project

A coordenação de projectos corre em Kanboard. As tarefas transportam o seu contexto completo — ligações a páginas wiki relevantes, canais IRC e material de referência — para que o trabalho e o conhecimento que o sustenta permaneçam ligados em vez de dispersos. É utilizado para tarefas, para discussão estruturada dentro dessas tarefas, e para reunir pessoas que precisam de compreender o mesmo problema antes de o poder resolver.

Gopher

O Gopher não é uma escolha por tradição. É a escolha correcta para um sistema onde a documentação deve ser honesta sobre o que é: texto simples, sob controlo de versões, servido sem transformação.

Os mesmos ficheiros que existem no repositório estão em /var/gopher e nos directórios pessoais dos utilizadores. Não há conversão, não há pipeline de renderização, não há uma camada separada a manter — o que é escrito é o que é servido. Os utilizadores que preferem uma interface web acedem ao mesmo conteúdo através de uma sessão de terminal via ttyd, com o cgо a gerir a ligação. A interface muda; os ficheiros não.

É isto que significa a documentação ser parte do sistema e não apenas sobre ele.

gophernicus

O Gophernicus é instalado a partir dos ports e corre sob o seu próprio utilizador sem privilégios, gerido pelo inetd — nada persistente, nada para além do que a tarefa exige. Serve apenas ficheiros com permissão de leitura global a partir da raiz de documentos designada; o acesso é determinado pelo próprio sistema de ficheiros. A configuração completa, incluindo as opções escolhidas e a sua justificação, está documentada e disponível através do espaço Gopher.

Email

Comunicação interna, correctamente configurada. O sistema de correio recebe mensagens externas sem problemas — testado com os principais fornecedores — mas esse não é o seu propósito. Existe para troca interna, assinada e cifrada por omissão, entre contas no mesmo sistema.

smtpd

O agente de transferência de correio é o OpenSMTPD — sistema base, sem substituição justificada. Escuta nas portas 25, 465 e 587, com TLS obrigatório na submissão e disponível na recepção. O correio enviado é assinado com DKIM. O correio recebido sem rDNS válido, ou com rDNS confirmado inverso divergente, é marcado como junk antes de chegar a qualquer utilizador. Os utilizadores virtuais são geridos através de uma tabela passwd; a entrega passa para o Dovecot via LMTP. Cada decisão na configuração — regras de relay, postura dos listeners, gestão de IPv6 — está examinada e registada na documentação que a acompanha, não deixada ao pressuposto.

dovecot

O Dovecot trata de IMAP e LMTP. Recebe correio do OpenSMTPD através de um socket LMTP local e armazena-o em formato maildir em /var/vmail, organizado por domínio e utilizador. A autenticação utiliza o mesmo ficheiro passwd que o smtpd, com palavras-passe cifradas em bcrypt. O TLS é obrigatório em todas as ligações de clientes. A superfície de protocolos, os listeners activos e a configuração da classe de login estão cada um definidos ao que o sistema necessita e documentados em conformidade — nada fica activo por omissão sem examinação.

Shell

Acesso remoto, sem excessos. A configuração abaixo define como o sophia.host disponibiliza acesso shell: uma porta, um endereço, um método de autenticação. Nada fica aberto sem necessidade.

sshd

O SSH escuta na porta 1337 — uma escolha deliberada que evita o ruído constante de scans automatizados na porta padrão. Está ligado a um único endereço IPv4, com IPv6 explicitamente ausente e não apenas por omissão; o login root e a autenticação por palavra-passe estão ambos desactivados. O acesso requer uma chave SSH, e o daemon impõe permissões correctas em todos os ficheiros relevantes através do StrictModes. A configuração completa está disponível através do espaço Gopher.

Consulte como criar uma conta de utilizador no servidor.

Dev

Devido à política dos Estados Unidos, o git deixará de ser suportado em muitas plataformas. Por causa disto, e por causa da alternativa Unix got, vamos descontinuar o git.

Publicação de código e controlo de acesso, sem complexidade acessória. As ferramentas abaixo tratam do que cada uma foi concebida para fazer — distribuição pública, acesso autenticado e apresentação legível — cada uma a operar dentro dos seus próprios limites.

Visite a página git para instruções sobre como utilizar os serviços git do sophia.host.

git-daemon

O git-daemon serve repositórios públicos através do protocolo Git nativo — rápido, anónimo e de leitura apenas. Trata da distribuição pública sem sobrecarga de autenticação nem superfície de configuração desnecessária.

gitolite

O Gitolite gere o acesso autenticado a repositórios privados via SSH. Determina com precisão quem pode ler ou modificar que código, com uma configuração simples o suficiente para ser auditada e robusta o suficiente para ser fiável.

cgit

O cgit fornece uma interface web para navegar pelos repositórios públicos em /var/git. Não tem acesso aos repositórios privados do Gitolite — a separação é arquitectónica, não configurada — e apresenta código via HTTPS sem adicionar peso à pilha.

Network

TLS

A terminação TLS é gerida pelo relayd — sistema base, sem dependência externa. Acelera SSL/TLS para todos os serviços e encaminha para o backend apropriado inspeccionando o cabeçalho Host. Cada subdomínio tem o seu próprio par de chaves; os ficheiros de certificados são ligados simbolicamente para os caminhos que o relayd espera em /etc/ssl e /etc/ssl/private. Tanto IPv4 como IPv6 são tratados por definições de relay separadas que partilham o mesmo bloco de protocolo. As restrições de protocolo e o comportamento de verificação de estado são definidos explicitamente na configuração e documentados — as opções comentadas existem no registo precisamente porque a decisão de as incluir ou excluir foi tomada conscientemente, e não adiada.