Comment héberger soi-même un serveur AIM

 (veronicaexplains.net)
1 points par GN⁺ 7 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Avec [Open OSCAR Server], il est possible de mettre en place un serveur AIM/ICQ sur un serveur Debian et de reconnecter plusieurs clients dans d’anciens environnements, dont Windows 98
  • Pour une petite exploitation, un VPS peu puissant suffit, mais pour l’utiliser avec des amis à l’extérieur, il faut le port par défaut 5190, une IP fixe ou un DNS dynamique, ainsi qu’une configuration de pare-feu adaptée à une exposition sur Internet
  • Dans settings.env, configurez OSCAR_LISTENERS et OSCAR_ADVERTISED_LISTENERS_PLAIN selon le mode LAN ou WAN, puis modifiez le client AIM pour qu’il se connecte à votre propre serveur au lieu des serveurs AOL fermés
  • Par défaut, il est possible de se connecter avec n’importe quel pseudonyme et mot de passe ; il faut donc activer l’authentification par mot de passe avec DISABLE_AUTH=false et gérer les comptes via l’API
  • Comme l’état du serveur est stocké dans une base de données SQLite et des fichiers de configuration, des sauvegardes complètes nocturnes ou une copie rsync après arrêt du serveur permettent de maintenir un environnement AIM restaurable

Pourquoi relancer AIM au lieu de Discord

  • Avant que les téléphones mobiles et les SMS ne se généralisent, de nombreuses activités, des projets scolaires aux relations sociales, se déroulaient dans des fenêtres AIM, ce qui a nourri une certaine nostalgie pour AIM
  • À la suite d’une expérience récente peu satisfaisante avec Discord, Open OSCAR Server a été testé, et il a permis de connecter plusieurs anciens clients à un serveur AIM/ICQ autohébergé
  • Le processus de mise en place a aussi été présenté dans une vidéo YouTube et une vidéo PeerTube, tandis qu’une vidéo séparée de Macintosh Librarian présente AIM lui-même plus en détail

Préparer un serveur Debian Trixie

  • La cible d’installation est Debian Trixie ; le processus d’installation du système d’exploitation lui-même n’est pas couvert
  • Si vous ne prévoyez pas de discuter avec des centaines de personnes, il est possible de l’exécuter même sur un VPS peu puissant
    • Au départ, le serveur était hébergé à domicile, puis il a été migré vers un VPS d’entrée de gamme lorsque le partage avec des amis a commencé
    • Il est probable qu’il fonctionne aussi sur Raspberry Pi, mais cela n’a pas été testé directement
  • Si vous l’exécutez à la maison ou derrière un pare-feu, il faut ouvrir le port par défaut 5190 auquel les clients AIM se connecteront
    • Certains clients ne permettent pas de changer facilement de port, il vaut donc mieux conserver le port par défaut
  • Dans un environnement domestique sans IP fixe, un DNS dynamique est nécessaire
    • Le service utilisé était No-IP, avec un résultat satisfaisant
    • Si le DNS dynamique ne vous est pas familier, un serveur cloud à 5 à 10 dollars par mois permet de bénéficier d’une IP fixe et d’une configuration plus simple
    • Quelle que soit l’approche choisie, le serveur doit être accessible via une IP fixe ou un domaine, et le port 5190 doit être ouvert
  • Les paramètres par défaut d’Open OSCAR Server sont pratiques pour tester sur un réseau domestique, mais ne conviennent pas à une exposition sur Internet
    • Jusqu’à ce que la configuration soit verrouillée, il est recommandé de n’autoriser que votre propre trafic et de refuser dans le pare-feu les connexions provenant d’autres sources

Installer Open OSCAR Server

wget [RELEASE URL]
  • [RELEASE URL] doit être remplacé par l’adresse réelle du fichier de release
  • Décompressez l’archive téléchargée avec tar
tar -zxvf open_oscar_server.X.XX.X.linux.x86_64.tar.gz
  • Remplacez X.XX.X par le numéro de version réel téléchargé

Configurer le mode d’écoute et l’adresse du serveur

  • Si vous l’exécutez uniquement sur la machine locale, vous pouvez vous déplacer dans le sous-répertoire décompressé et le lancer directement
  • Pour connecter des clients depuis d’autres machines, il faut modifier settings.env
  • Open OSCAR Server prend en charge trois modes d’écoute client
    • LOCAL : valeur par défaut, utilisée lorsque le client AIM et le serveur sont sur la même machine
    • LAN : utilisé lorsque le serveur et les clients AIM sont sur le même réseau interne et ne passent pas par Internet
    • WAN : utilisé pour connecter via Internet les clients AIM d’amis extérieurs
  • Dans settings.env, deux variables doivent être configurées ensemble
    • OSCAR_LISTENERS : indique comment Open OSCAR Server écoute les connexions
    • OSCAR_ADVERTISED_LISTENERS_PLAIN : indique l’adresse du serveur à annoncer aux clients comme AIM
  • Pour un VPS public dont le domaine est example.domain, la configuration peut être la suivante
OSCAR_LISTENERS=WAN://0.0.0.0:5190
OSCAR_ADVERTISED_LISTENERS_PLAIN=WAN://example.domain:5190
  • Sur un réseau interne, remplacez WAN par LAN et utilisez l’adresse IP attribuée au serveur au lieu du domaine
  • Les modes des deux variables doivent impérativement correspondre, comme LAN et LAN, ou WAN et WAN
    • Il est aussi possible de configurer les deux modes dans les deux variables
  • Une fois la configuration terminée, lancez le serveur à l’essai avec la commande suivante
./open_oscar_server

Connecter un client AIM

  • Dans plusieurs versions d’AIM, il est possible de remplacer le serveur de connexion par défaut désormais fermé, login.oscar.aol.com, par une autre adresse
  • Dans AIM 5.1, l’adresse du serveur se modifie via le gros bouton Configuration de Setup
  • Il suffit de remplacer l’adresse du serveur de connexion par défaut par celle indiquée dans OSCAR_ADVERTISED_LISTENERS_PLAIN
  • Avant de renforcer l’authentification, il est possible de se connecter en saisissant n’importe quel pseudonyme et mot de passe
  • Les conditions d’accès des autres utilisateurs dépendent du mode du serveur
    • En mode LAN, ils doivent être sur le même réseau que le serveur
    • En mode WAN, il faut leur fournir un accès leur permettant de traverser le pare-feu

Exécuter le serveur en continu avec systemd

  • Open OSCAR Server fournit aussi un service systemd permettant de garder le serveur en fonctionnement même après la fermeture de la connexion SSH
  • Pour installer et configurer le service, suivez la documentation SYSTEMD du projet

Activer l’authentification par mot de passe

  • Par défaut, aucun vrai mot de passe n’est vérifié ; il faut donc modifier DISABLE_AUTH dans le fichier de service systemd
  • Modifiez l’intégralité du fichier de service dans l’éditeur par défaut avec la commande suivante
sudo systemctl edit --full ras.service
  • Sous [Service], définissez la variable d’environnement comme suit
Environment="DISABLE_AUTH=false"
  • Comme le nom de la variable est une double négation, sa valeur doit être false pour exiger l’authentification
  • Après avoir enregistré le fichier de service, rechargez la configuration du démon systemd
sudo systemctl daemon-reload
  • Réessayez de vous connecter avec le pseudonyme et le mot de passe existants ; en cas d’échec, vous pouvez créer un nouvel utilisateur via l’API

Gérer les utilisateurs et les mots de passe avec l’API

  • Après activation de l’authentification, les utilisateurs et mots de passe se gèrent avec l’API d’Open OSCAR Server et curl

  • Ajouter un utilisateur

    curl -d'{"screen_name":"NEWUSERNAME", "password":"NEWPASSWORD"}' http://localhost:8080/user
    • L’option -d de curl envoie des données POST
    • Le corps JSON contient les clés screen_name et password
    • La requête cible l’endpoint http://localhost:8080/user du serveur local

  • Modifier le mot de passe d’un utilisateur existant

    curl -X PUT -d'{"screen_name":"NEWUSERNAME", "password":"NEWPASSWORD"}' http://localhost:8080/user/password
    • Pour mettre à jour un utilisateur existant, utilisez -X PUT au lieu de POST
    • screen_name doit désigner un pseudonyme déjà existant
    • L’endpoint de changement de mot de passe est http://localhost:8080/user/password
    • L’API prend aussi en charge la suppression d’utilisateurs et l’ajout de salons de discussion ; les autres fonctionnalités sont décrites dans la documentation du projet

Sauvegarde et restauration

  • L’état principal d’Open OSCAR Server étant constitué d’une base de données SQLite et de fichiers de configuration, la sauvegarde est simple
  • Des sauvegardes complètes du système VPS sont effectuées chaque nuit, et les tests de restauration ont fonctionné comme prévu
  • Avant de gros changements, le serveur est arrêté puis tout le répertoire de travail est copié avec rsync vers une machine de sauvegarde
  • Borgmatic peut simplifier le processus de sauvegarde, et fera l’objet d’un article de suivi plus détaillé

À lire aussi

1 commentaires

 
GN⁺ 7 시간 전
Commentaires sur Lobste.rs

  • Lecture amusante, mais ce serait une erreur de penser qu’à l’époque il n’y avait pas beaucoup de messageries. Beaucoup de gens ont passé énormément de temps sur AIM ou MSN, mais mes camarades de classe et moi n’utilisions ni l’un ni l’autre : nous sommes passés d’ICQ à IRC, et la fragmentation des services n’était pas vraiment meilleure qu’aujourd’hui

    • Cela dit, à l’époque, il existait des clients unifiés permettant d’utiliser plusieurs messageries au même endroit
    • C’est vrai. Ça me rappelle un billet LiveJournal que j’avais écrit en 2005, repris sur Slashdot, à propos du fait que le serveur Jabber de Google Talk n’avait pas de plan de fédération inter-serveurs approprié
      https://nugget.livejournal.com/97081.html
      Il y a aussi un billet de suivi écrit un mois plus tard, après avoir reçu une réponse de Google
      https://nugget.livejournal.com/103322.html
    • J’imagine qu’il y avait de grosses différences selon les régions. Dans mon souvenir, aux États-Unis c’était AIM, tandis qu’en Europe on utilisait surtout ICQ

  • Il existe aussi une vidéo sur ce sujet. J’ai failli la publier moi-même, mais j’hésitais entre garder le titre original, un peu putaclic, ou utiliser celui fourni par DeArrow

    • Le titre de la vidéo ne m’a pas forcément paru putaclic, mais en général je préfère les billets de blog aux vidéos

  • C’est intéressant, mais en lisant l’article, la réponse que j’attendais était : « et ensuite ? ». S’il n’y a pas de fédération avec d’autres serveurs, est-ce que toutes les personnes avec qui l’on veut discuter doivent être sur le même serveur, ou est-ce juste pour se parler à soi-même ?

    • Je ne vois pas quel est le problème à rejoindre plusieurs serveurs. En pratique, c’est aussi la structure que Discord dit adopter

  • Ils n’ont pas oublié la capture d’écran canonique qui devait absolument figurer au début de l’article. Le côté pratique et utile des logiciels de l’époque était vraiment bien peaufiné

  • AIM en soi ne m’intéresse pas, mais c’est agréable de voir des gens remettre les mains dans de vieilles technologies. En parcourant les autres articles de l’auteur, j’ai l’impression que je risque encore de tomber dans un marécage d’explorations diverses, et ça n’a pas l’air si mal

  • L’époque d’ICQ et d’AIM ne me manque pas du tout, mais vers la fin, le secteur a connu un bref âge d’or. Grâce à XMPP, qui permettait la fédération entre serveurs, et aux passerelles vers d’autres protocoles, on pouvait monter son propre serveur ou avoir un compte sur celui de quelqu’un d’autre et discuter avec n’importe qui
    Il fallait aussi conserver les comptes des réseaux reliés par passerelle, mais la plupart du temps quelques ajustements très occasionnels suffisaient, et avec un seul compte on pouvait discuter avec des utilisateurs de Google Talk, Facebook Messenger, ICQ et MSN. Seul Skype refusait obstinément toute compatibilité
    Aujourd’hui, la culture a changé de façon étonnante : même Signal, pourtant open source, bloque les clients externes, et cela ne suscite guère de vraie opposition ; c’est même perçu dans une certaine mesure comme une exigence raisonnable. On dirait que nous avons perdu cet âge d’or parce que nous ne méritons plus d’en profiter