Como hospedar seu próprio servidor AIM

 (veronicaexplains.net)
1 pontos por GN⁺ 7 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Com o [Open OSCAR Server], é possível montar um servidor AIM/ICQ em um servidor Debian e reconectar vários clientes de ambientes antigos, incluindo Windows 98
  • Para uma operação pequena, até um VPS modesto é suficiente, mas, para usar com amigos externos, é preciso ter a porta padrão 5190, um IP fixo ou DNS dinâmico, e configurações de firewall adequadas para exposição à internet
  • Ajuste OSCAR_LISTENERS e OSCAR_ADVERTISED_LISTENERS_PLAIN em settings.env conforme o modo LAN ou WAN, e altere o cliente AIM para se conectar ao seu próprio servidor em vez dos servidores AOL desativados
  • Por padrão, é possível fazer login com qualquer nome de tela e senha, então é necessário ativar a autenticação por senha com DISABLE_AUTH=false e gerenciar as contas pela API
  • Como o estado do servidor é salvo em um banco de dados SQLite e em arquivos de configuração, é possível manter um ambiente AIM recuperável com backups completos noturnos ou copiando via rsync após parar o servidor

Por que voltei a operar AIM em vez de Discord

  • Antes de celulares e mensagens de texto se popularizarem, muitas atividades, de projetos escolares a relações pessoais, aconteciam em janelas do AIM, e essa experiência levou à nostalgia pelo AIM
  • Depois de experiências recentes ruins com o Discord, testei o Open OSCAR Server e consegui conectar vários clientes antigos a um servidor AIM/ICQ próprio
  • O processo de configuração também foi abordado em um vídeo no YouTube e em um vídeo no PeerTube, enquanto um vídeo separado do Macintosh Librarian apresenta o próprio AIM em mais detalhes

Preparando um servidor Debian Trixie

  • O alvo da instalação é o Debian Trixie, e o processo de instalação do próprio sistema operacional não é abordado
  • Se você não pretende conversar com centenas de pessoas, dá para operar até em um VPS modesto
    • No início, hospedei em casa, mas, quando comecei a compartilhar com amigos, migrei para um VPS no plano mais básico
    • É possível que funcione também em um Raspberry Pi, mas não testei diretamente
  • Se for operar em casa ou atrás de um firewall, é preciso abrir a porta padrão 5190, pela qual os clientes AIM vão se conectar
    • Em alguns clientes, mudar a porta não é fácil, então é melhor manter a porta padrão
  • Em ambientes domésticos sem IP fixo, é necessário usar DNS dinâmico
    • O serviço que usei foi o No-IP, e fiquei satisfeito com o resultado
    • Se você não estiver familiarizado com DNS dinâmico, pode usar um servidor em nuvem de 5 a 10 dólares por mês para ter IP fixo e uma configuração mais simples
    • Seja qual for a opção, o servidor precisa ser acessível por um IP fixo ou domínio, e a porta 5190 deve estar aberta
  • Os padrões do Open OSCAR Server são convenientes para testes em uma rede doméstica, mas não são adequados para exposição à internet
    • Até travar as configurações, recomenda-se permitir apenas o seu próprio tráfego e negar no firewall conexões vindas de outras origens

Instalando o Open OSCAR Server

wget [RELEASE URL]
  • Substitua [RELEASE URL] pelo endereço real do arquivo da release
  • Extraia o arquivo baixado com tar
tar -zxvf open_oscar_server.X.XX.X.linux.x86_64.tar.gz
  • Substitua X.XX.X pelo número real da versão baixada

Configurando o modo de escuta e o endereço do servidor

  • Se for executar apenas na máquina local, entre no subdiretório extraído e rode diretamente
  • Para conectar clientes de outras máquinas, é preciso editar settings.env
  • O Open OSCAR Server oferece suporte a três modos de escuta de clientes
    • LOCAL: valor padrão, usado quando o cliente AIM e o servidor estão na mesma máquina
    • LAN: usado quando o servidor e os clientes AIM estão na mesma rede interna e não passam pela internet
    • WAN: usado para conectar clientes AIM de amigos externos pela internet
  • Em settings.env, configure duas variáveis em conjunto
    • OSCAR_LISTENERS: especifica como o Open OSCAR Server recebe conexões
    • OSCAR_ADVERTISED_LISTENERS_PLAIN: especifica o endereço do servidor que será informado a clientes como o AIM
  • Para um VPS público cujo domínio seja example.domain, a configuração pode ser assim
OSCAR_LISTENERS=WAN://0.0.0.0:5190
OSCAR_ADVERTISED_LISTENERS_PLAIN=WAN://example.domain:5190
  • Em uma rede interna, troque WAN por LAN e use o endereço IP atribuído ao servidor no lugar do domínio
  • Os modos das duas variáveis devem necessariamente corresponder, como LAN e LAN, ou WAN e WAN
    • Também é possível configurar os dois modos em ambas as variáveis
  • Depois de concluir as configurações, teste a execução do servidor com o comando a seguir
./open_oscar_server

Conectando o cliente AIM

  • Em várias versões do AIM, é possível trocar o servidor de login padrão login.oscar.aol.com, hoje desativado, por outro endereço
  • No AIM 5.1, o endereço do servidor é alterado pelo grande botão Configuration em Setup
  • Basta substituir o endereço do servidor de login padrão pelo endereço especificado em OSCAR_ADVERTISED_LISTENERS_PLAIN
  • Antes de reforçar a autenticação, é possível fazer login inserindo qualquer nome de tela e senha
  • As condições de acesso de outros usuários dependem do modo do servidor
    • No modo LAN, eles precisam estar na mesma rede do servidor
    • No modo WAN, é necessário fornecer acesso para que usuários externos consigam passar pelo firewall

Mantendo o servidor sempre ativo com systemd

  • O Open OSCAR Server também fornece um serviço systemd que permite manter o servidor em execução mesmo depois que a conexão SSH é encerrada
  • Para instalar e configurar o serviço, siga a documentação de SYSTEMD do projeto

Ativando a autenticação por senha

  • Por padrão, senhas reais não são verificadas, então é preciso alterar DISABLE_AUTH no arquivo de serviço do systemd
  • Edite o arquivo de serviço completo no editor padrão com o comando a seguir
sudo systemctl edit --full ras.service
  • Em [Service], defina a variável de ambiente assim
Environment="DISABLE_AUTH=false"
  • Como o nome da variável usa uma dupla negação, para exigir autenticação o valor deve ser false
  • Depois de salvar o arquivo de serviço, recarregue a configuração do daemon do systemd
sudo systemctl daemon-reload
  • Teste novamente o login com o nome de tela e a senha existentes; se falhar, você pode criar um novo usuário pela API

Gerenciando usuários e senhas pela API

  • Depois de ativar a autenticação, gerencie usuários e senhas com a API do Open OSCAR Server e curl

  • Adicionar usuário

    curl -d'{"screen_name":"NEWUSERNAME", "password":"NEWPASSWORD"}' http://localhost:8080/user
    • A opção -d do curl envia dados POST
    • O corpo JSON inclui as chaves screen_name e password
    • O destino da requisição é o endpoint http://localhost:8080/user do servidor local

  • Alterar a senha de um usuário existente

    curl -X PUT -d'{"screen_name":"NEWUSERNAME", "password":"NEWPASSWORD"}' http://localhost:8080/user/password
    • Para atualizar um usuário existente, use -X PUT em vez de POST
    • Em screen_name, especifique um nome de tela que já exista
    • O endpoint de alteração de senha é http://localhost:8080/user/password
    • A API também oferece suporte a excluir usuários, adicionar salas de chat e outras funções; consulte a documentação do projeto para ver os demais recursos

Backup e recuperação

  • O estado principal do Open OSCAR Server consiste em um banco de dados SQLite e arquivos de configuração, o que torna o backup simples
  • Faço backup de todo o sistema do VPS todas as noites, e os testes de restauração funcionaram como esperado
  • Antes de grandes alterações, paro o servidor e copio todo o diretório de trabalho para a máquina de backup com rsync
  • Com o Borgmatic, é possível simplificar ainda mais o processo de backup, e pretendo abordar isso em detalhes em um post futuro

Leituras relacionadas

1 comentários

 
GN⁺ 7 시간 전
Comentários no Lobste.rs

  • Foi divertido de ler, mas achar que no passado não havia muitos tipos de mensageiro é um engano. Muita gente passou muito tempo no AIM ou no MSN, mas eu e meus amigos da escola não usávamos nenhum dos dois e migramos do ICQ para o IRC; a fragmentação dos serviços também não era particularmente melhor do que hoje

    • Mesmo assim, naquela época existiam clientes unificados que permitiam usar vários mensageiros em um só lugar
    • Verdade. Isso me fez lembrar de um post no LiveJournal que foi parar no Slashdot, em 2005, sobre como o servidor Jabber do Google Talk não tinha um plano adequado de federação entre servidores
      https://nugget.livejournal.com/97081.html
      Um mês depois, também houve um post de acompanhamento escrito após a resposta do Google
      https://nugget.livejournal.com/103322.html
    • Acho que havia uma grande diferença por região. Nos EUA era AIM, e na Europa, pelo que lembro, ICQ era mais comum

  • Também existe um vídeo sobre esse tema. Eu quase o enviei, mas fiquei em dúvida entre manter o título original, meio caça-cliques, ou usar o título fornecido pelo DeArrow

    • O título do vídeo não me pareceu necessariamente caça-cliques, mas em geral prefiro post de blog a vídeo

  • É interessante, mas, ao ler o texto, a resposta que eu esperava era: “e depois?”. Se não houver federação com outros servidores, fiquei curioso se todo mundo com quem você quer conversar precisa estar no mesmo servidor, ou se isso serve para falar sozinho

    • Não vejo qual seria o problema de se cadastrar em vários servidores. Na prática, o modelo que o Discord propõe também é assim

  • O texto não deixou de fora a captura de tela clássica que tinha de aparecer logo no começo. A praticidade e utilidade daquele software da época eram realmente muito bem lapidadas

  • Não tenho interesse no AIM em si, mas é divertido ver pessoas mexendo novamente em tecnologias antigas. Acabei olhando também outros textos do autor e parece que vou cair em mais vários buracos de exploração, o que também não parece ruim

  • Não sinto nenhuma saudade da era de ICQ e AIM em si, mas no fim daquele período houve uma breve era de ouro no setor. Graças ao XMPP, com federação entre servidores, e a gateways que ligavam a outros protocolos, você podia montar seu próprio servidor ou ter conta no servidor de outra pessoa e conversar com qualquer um
    Ainda era preciso manter as contas nas redes conectadas pelos gateways, mas na maioria dos casos bastava mexer nelas muito de vez em quando, e com uma única conta dava para falar com usuários de Google Talk, Facebook Messenger, ICQ e MSN. Só o Skype se recusava teimosamente a ser compatível
    Agora a cultura mudou de forma impressionante, a ponto de até o Signal, que é open source, bloquear clientes externos sem provocar a reação negativa que seria esperada; isso chega até a ser aceito como uma exigência razoável em certo grau. Parece que perdemos a era de ouro por não merecermos mais desfrutá-la.