Mentalite sysadmin : ce que l'IRC m'a appris

En 1999, j'ai installe mon premier serveur IRC sur un Pentium II avec 128 Mo de RAM et une connexion ADSL asymetrique. J'avais 16 ans, aucune formation, et un livre sur Unix que j'avais emprunte a la bibliotheque. Vingt-cinq ans plus tard, je gere des infrastructures pour des entreprises. Presque tout ce que je sais sur l'administration systeme, je l'ai appris en faisant tourner des serveurs IRC. Pas parce que les serveurs IRC sont complexes — mais parce qu'ils tombent de maniere instructive.

Comment ca a commence

Administrer un serveur IRC en 2000, c'etait une ecole pratique d'informatique. Vous appreniez TCP/IP parce qu'un netsplit vous forcait a comprendre le routage. Vous appreniez la securite parce qu'un script kiddie DDoSait votre serveur toutes les semaines. Vous appreniez le scripting parce que les taches repetitives (bannissement, maintenance, monitoring) devaient etre automatisees.

L'IRC est un excellent terrain d'apprentissage parce que les consequences des erreurs sont visibles immediatement. Si votre configuration TLS est mauvaise, les utilisateurs ne peuvent pas se connecter — et ils vous le disent dans les 30 secondes. Si votre firewall bloque le mauvais port, le reseau se coupe et tout le monde le voit. Le feedback est instantane.

Lecon 1 : la redundance

J'ai appris la redundance le jour ou mon unique serveur IRC est tombe a cause d'une panne de courant. Pas d'UPS, pas de serveur de backup. 200 utilisateurs deconnectes. Le serveur est revenu 4 heures plus tard. La moitie des utilisateurs ne sont jamais revenus.

Depuis ce jour, la regle est simple : tout composant critique doit exister en au moins deux exemplaires.

• Serveurs : Minimum deux, idealement trois. Chez des hebergeurs differents.
• DNS : Au moins deux serveurs DNS autoritaires. Si votre DNS tombe, personne ne trouve votre serveur, meme s'il fonctionne.
• Sauvegardes : La regle 3-2-1. Trois copies, deux supports differents, une hors-site.
• Chemins reseau : Si possible, des serveurs avec des upstream differents. Un probleme de peering chez un transit provider ne devrait pas couper tout le reseau.

Cette mentalite s'applique a toute infrastructure. Un site web a besoin du meme niveau de reflexion sur la redundance — serveurs, bases de donnees, CDN, DNS. La complexite augmente mais le principe reste le meme.

Lecon 2 : l'automatisation

La premiere tache que j'ai automatisee : le renouvellement des certificats TLS. Je l'oubliais systematiquement. Un jour, le certificat a expire et les utilisateurs TLS ont ete rejetes pendant 6 heures avant que quelqu'un me previenne.

La regle : si vous faites une tache plus de deux fois, automatisez-la.

# Ce que j'ai automatise sur mes serveurs IRC au fil des ans :

# 1. Renouvellement TLS (Let's Encrypt + cron)
# 2. Sauvegardes quotidiennes de la config et des services
# 3. Rotation des logs
# 4. Monitoring (Prometheus + alertes)
# 5. Deployment des mises a jour (script pull + compile + rehash)
# 6. Nettoyage des K-lines expirees
# 7. Rapports hebdomadaires (stats utilisateurs, incidents)

# L'automatisation n'est pas du luxe.
# C'est de la survie.
# Un administrateur qui fait tout manuellement
# finit par oublier quelque chose de critique.

# Outils :
# - cron : pour les taches periodiques
# - systemd timers : alternative moderne a cron
# - Ansible : pour les deployments multi-serveurs
# - scripts bash/python : pour tout le reste

Lecon 3 : la documentation

En 2005, le co-administrateur de notre reseau IRC a demissionne sans preavis. Il gerait les services (NickServ, ChanServ) et le hub central. La configuration n'etait documentee nulle part. Les mots de passe etaient dans sa tete. J'ai passe deux semaines a reconstituer la configuration en lisant les fichiers de conf, les logs, et en testant par essai-erreur.

Depuis : tout est documente. Chaque serveur a un fichier de notes qui decrit la configuration, les particularites, les mots de passe (dans un gestionnaire), et les procedures de maintenance.

• Documentez les decisions, pas seulement les configurations. "sendq = 1M" est dans le fichier de conf. "Pourquoi sendq = 1M et pas 512K" n'y est pas. C'est cette information que vous cherchez quand vous re-evaluez un reglage deux ans plus tard.
• Documentez les procedures d'urgence. Que faire quand le hub tombe ? Que faire en cas de DDoS ? Que faire si un oper abuse de ses privileges ? Ces procedures doivent etre ecrites et accessibles AVANT la crise.
• Documentez pour les autres, pas pour vous. Vous savez pourquoi ce script fait ce qu'il fait. La personne qui le trouvera dans 5 ans ne le saura pas.

Lecon 4 : le monitoring

Vous ne pouvez pas gerer ce que vous ne mesurez pas. J'ai appris cette lecon quand un memory leak sur notre IRCd a fait crasher le serveur en pleine nuit — trois nuits de suite — avant que je realise que la memoire montait lentement depuis deux semaines.

Le monitoring minimum pour un serveur IRC (et par extension, pour tout service) :

• Disponibilite : Le service repond-il ? Check toutes les minutes.
• Ressources : CPU, memoire, disque, file descriptors. Tendances sur 7 jours minimum.
• Application : Nombre d'utilisateurs, messages par seconde, send queues. Les metriques specifiques a l'application revelent des problemes que les metriques systeme ne montrent pas.
• Alertes : Pas de monitoring sans alertes. Un dashboard que personne ne regarde ne sert a rien. Les alertes doivent aller ou quelqu'un les voit — email, SMS, notification push, ou... IRC.

Pour les organisations qui veulent mettre en place un monitoring professionnel sans y consacrer des semaines, des prestataires comme Koeki proposent un accompagnement technique qui couvre la mise en place d'outils d'observabilite adaptes a votre infrastructure.

Lecon 5 : la securite

Gerer un serveur IRC expose a Internet est une education acceleree en securite :

• Les attaques sont quotidiennes. Scans de ports, tentatives de brute force, floods, injection de commandes. Un serveur IRC est une cible permanente. Vous apprenez a penser comme un attaquant parce que vous en voyez tous les jours.
• La surface d'attaque doit etre minimale. Chaque service expose est un vecteur potentiel. N'ouvrez que les ports necessaires. Ne chargez que les modules necessaires. Ne donnez des privileges qu'aux personnes qui en ont besoin.
• Le privilege minimum est un principe de survie. Ne faites pas tourner l'IRCd en root. Ne donnez pas oper a quelqu'un "juste au cas ou". Chaque privilege est un risque.
• Les mises a jour de securite sont non-negociables. Un IRCd non patche avec une vulnerabilite connue est une invitation ouverte. Les CVE pour UnrealIRCd et InspIRCd sont rares mais critiques quand ils sortent.

# Checklist securite minimale pour tout serveur :

# 1. Pas de root pour les services applicatifs
sudo useradd -m -s /bin/bash monservice

# 2. Firewall restrictif (tout ferme par defaut)
iptables -P INPUT DROP
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPT  # SSH
iptables -A INPUT -p tcp --dport 6697 -j ACCEPT  # IRC TLS

# 3. TLS partout
# Pas de service en clair sur Internet. Jamais.

# 4. Mots de passe forts et uniques
# Gestionnaire de mots de passe obligatoire

# 5. Mises a jour automatiques pour l'OS
sudo apt install unattended-upgrades

# 6. Sauvegardes chiffrees hors-site
# 7. Monitoring avec alertes
# 8. Logs centralises et conserves

Lecon 6 : le facteur humain

La lecon la plus importante n'est pas technique. C'est que l'infrastructure est faite pour les gens. Un serveur IRC parfaitement configure mais avec une communaute toxique est un echec. Un serveur bancal mais avec une communaute soudee est un succes.

Ca s'applique a toute l'informatique. Le meilleur code du monde ne sert a rien si personne ne peut le maintenir. La meilleure infrastructure ne sert a rien si les utilisateurs ne savent pas l'utiliser. La technique est au service des humains, pas l'inverse.